ago
30
2007
16 características do Oracle que fazem falta no PostgreSQL
Publicado por Telles e arquivado em Banco de Dados, Oracle, PostgreSQLBom, depois de escrever sobre algumas vantagens do PostgreSQL em relação ao Oracle, chegou a hora de fazer o inverso. Eis aqui algumas características do Oracle que eu realmente sinto falta no PostgreSQL.
- Triggers de sistema. O Oracle possui a capacidade de disparar gatilhos quando você inicia o SGDB, quando um usuário se conecta, quando realiza uma operação de DDL, etc. Isso ajuda muito para quem quer realizar auditorias e construir alguns esquemas especiais de segurança. Além disso, o Oracle possui o AUDIT que que é um comando que utiliza uma estrutura pronta para auditar diferentes eventos;
- O PostgreSQL também tem ferramentas para gerar logs, mas o Oracle realiza isso com maior nível de controle, permitindo especificar uma sessão específica. Isto ajuda muito para monitorar uma ação específica dentro de um ambiente de produção.
- O Oracle permite de indicar um tablespace separado para o Tablespace TEMP e UNDO. Isto permite um ajuste de desempenho melhor, particularmente colocando o tablespace TEMP em outro disco em aplicações de BI que fazem consultas enormes. É claro que você consegue fazer isto no PostgreSQL utilizando links simbólicos, mas esta não é a forma mais elegante de se fazer isto. A versão 8.3 do PostgreSQL já deve trazer avanços neste sentido.
- Fine -Grained Access, é uma ferramenta do Oracle que permite o acesso a determinadas linhas de uma tebela de acordo com o perfil do usuário conectado. Este é um recurso interessante que em aplicações corporativas podem ajudar um bocado.
- Maior flexibilidade na definição dos arquivos de log de transação. No Oracle é possível determinar o tamanho e o local de cada log, além de fazer um espelhamento se você desejar. O PostgreSQL permite alterar o tamanho dos arquivos de log alterando um parâmetro no código fonte e também é possível criar links simbólicos para alterar a posição dos arquivos de log. No entanto, acho que o Oracle tem uma solução mais robusta neste ponto.
- O Oracle tem a possibilidade de criar tablespaces com diferentes tamanhos de bloco e buffers específicos para cada tamanho de bloco. Num ambiente que mistura características de OLTP com BI, isto pode ser interessante. É claro que oideal seria separar os dois ambientes em servidores distintos. No entanto esta opção confere ao Oracle uma flexibilidade adicional no ajuste de performance e uso do disco.
- SQLLoader é uma ferramenta para importação de grandes volumes de dados em arquivos texto em diversos formatos. E uma ferramenta realmente robusta e flexível que pode lhe ajudar a fazer ETL, migrar dados de plataformas distintas, etc.
- O Oracle permite a paralelização de operações pesadas, incluindo backups lógicos, importações via SQLLoader, consultas longas, etc. No PostgreSQL, você tem o PGPool II que permite a paralelização de consultas pesadas, mas não tem ferramentas para outras situações. Você também pode disparar duas operações de backup lógico em separado definindo partes diferentes do banco de dados para a operação. No entanto, crieio que a opção de paralelização seja uma alternativa interessante.
- O RAC (Real Aplication Cluster) é uma solução conhecida de cluster de banco de dados no Oracle. O RAC é uma solução que permite escalar o Oracle horizontalmente além de prover uma considerável tolerância a falhas. O PostgreSQL tem a capacidade de escalar verticalmente melhor que o Oracle, mas não tem ainda uma solução para escalar horizontalmente, nem uma solução para tolerância a falhas que seja síncrona, apesar de em Linux existirem soluções para isto. Existe um projeto chamado PGCluster II que promete fazer uma implementação semelhante ao RAC no PostgreSQL.
- As ferramentas de monitoramento da Oracle são realmente úteis. A partir do Oracle 10g o “Database Control” tem facilidades realmente interessantes e acredito que a versão 11g tenha melhorado mais ainda isso. Existe um projeto chamado Cedrus que promete cobrir boa parte deste vácuo no PostgreSQL. No entanto, já existem ferramentas como o Munin, que fazem um bom monitoramento do servidor e possui algumas extensões para o Oracle, PostgreSQL e MySQL, além de ser simples criar novas extensões.
- Ajuste automático de memória. O Oracle possui alguns parâmetros de inicialização se ajustam limites de memória para o Oracle e deixa ele distribuir este espaço entre as diversas áreas internas. Isto realmente pode simplificar muito o trabalho do DBA. Já ouvi falar que o pessoal da SUN tem interesse em investir em mecanismos deste tipo no PostgreSQL, mas isto ainda deverá levar alguns anos para se concretizar.
- Os índices do tipo bitmap ajudam muito em colunas de baixa cardinalidade e poucas gravações. O PostgreSQL tinha programado para implementar esta funcionalidade na versão 8.3 mas adiou para a versão 8.4. No entanto os índices bitmap são utilizados na memória (mas não em disco) no PostgreSQL em durante uma busca.
- O Particionamento de tabelas do Oracle também tem algumas vantagens sobre o particionamento do PostgreSQL como o particionamento por hash e outras funcionalidades que ajudam a dar manutenção em tabelas particionadas.
- Controle de transações dentro de um bloco PL/SQL. Isto é algo que me faz falta no PostgreSQL quando você precisa de funções mais complexas. No PostgreSQL todo o bloco PL roda dentro de uma única transação, enquanto do Oracle você pode declarar o begin, commit, rollback e savepoint dentro do PL/SQL.
- Visões materializadas, são coisas possíveis de serem feitas utilizando-se gatilhos e funções no PostgreSQL, mas é bem mais fácil quando você já tem uma estrutura sintática pronta para isso como no Oracle.
- O Jobs Scheduler é ferramentas do Oracle que permite o disparo de ações específicas através do agendamento em horário específico, se repetindo ou não em intervalos programados. Muitas pessoas resolvem esta ausência utilizando o CRON do Linux, mas o Job Scheduler tem uma série de funcionalidades interessantes, além de permitir tratar tudo via SQL.
É claro que o Oracle tem a mania de abocanhar o mundo e oferece uma miríade de funcionalidades, algumas exóticas e certamente algumas que eu não conheço. Se você sentiu falta de algum item, por favor deixe a sugestão nos comentários. Muito do que está aqui acaba sendo importante para quem pretende migrar de Oracle para PostgreSQL e não sabe se vai encontrar as funcionalidades que espera.
Tags: comparison, Oracle, PostgreSQL
Posts (RSS)
Na primeira deve ser auditoria onde autitoria, certo?
As funções analíticas tb seriam uma boa.
É Celso, é verdade. Acredito que quando penso em ferramentas de monitoramento, estou englobando isso. Mas talvez eu não tenha sido muito preciso, uma vez que as ferramentas analíticas podem existir sem as ferramentas de monitoramento, mas não o contrário.
Valeu pela contribuição.
Caro Ribamar, preciso parar de escrever com pressa (é que a discussão na lista do PostgreSQL está tão interessante que eu queria aproveitar o momento). Mas vou ver se tomo vergonha na cara e começo pelo menos a usar um corretor ortográfico. Obrigado pelos toques!
Ah… sim, não deixem de acompanhar a discussão na lista do PostgreSQL que está muito bacana.
Flashback quey.
Com certeza é um recurso que deixa qualquer um louco :
Ex.: select codproduto,qtdestoque from estoque as of timestamp trunc (sysdate + (8 / 24))
Como estava a tabela de estoque hoje às 8:00hs da manhã.
Esse recurso já salvou minha vida, uma vez, achei que estava logado na base de desenvolvimento, porém era a base de produção, zerei todo o estoque…
Resolvi tão rápido que o pessoal nem percebeu, consultei como estava a base antes de ter dado o comando e fiz um “ctrl+z”. Se fosse outro banco teria que voltar backup, e provavelmente seria demitido.
Índices bitmap tá sendo um parto heim? Nunca precisei de transações dentro de procedures, mas penso serem bem úteis. Uma coisa que é um pouco chatinha no PostgreSQL é o fato de sempre usar o collate do initdb para ordenações
Mas um dia nós chegamos lá!
Olá, eu não conheço quase nada no PostgreSQL, mas conheço um pouco de Oracle. Ai vai a pergunta. O PostgreSQL possui as features de Flashback (Database, Table, Transaction e Query)? Esse é uma dos recursos que eu mais gosto no Oracle.
É meu caro Fábio… é verdade. Nada de flashback no PostgreSQL por enquanto. É uma funcionalidade importante que faltou na lista.
O que mais sinto falta são os monitoradores mesmo. No DB2 há um ‘caminhão’ de coisas que dá para monitorar na base toda ou apenas numa conexão.
Aqui vai uma dica, para quem precisa monitorar o que um determinado usuário está mandando para o banco no ODBC, por exemplo:
set log_statement="all"
Muita gente acha que esse parâmetro pode ser definido apenas no postgresql.conf, mas ele pode também ser definido por conexão.
Depois é só setar o log_line_prefix com o que se quer (por ex.: “”) e capturar nos logs tudo o que passa pelo server apenas daquela conexão.
Abraço.
Opa,
Acho que faltou ai a parte de caracteres, no Oracle a parte de charset é bem complexa.
As possibilidades para definicões de língua, território e parâmetros afins fazem muita falta quando várias pessoas (com línguas diferentes) acessam o banco ajudam muito.
Faltou citar o RMAN, que é uma mão na roda pra backup. Claro que sempre com o modo ARCHIVELOG. Um RMAN no PostgreSQL seria muito bom, já teria me facilitado a vida algumas vezes.
Outra coisa seriam os parâmetros dinâmicos, no Oracle muita coisa é dinâmica e você pode alterar em tempo real. Shared servers (sem haver com o RAC) também fazem uma falta no PostgreSQL.
Profiles de usuários também ajudam. Mas nessa parte acho que o PostgreSQL dá uma lavada. O vínculo de esquema e usuário no Oracle é muito forte (eles tem o mesmo nome), no caso do PostgreSQL são separados (e nada que um search_path não resolva).
Até mais.
O PostgreSQL tem a maioria das opções de localização que o Oracle, basta ver isso na documentação. O PostgreSQL tem o suporte a UTF-8 já há um bom tempo também. E tem algo que eu realmente não gosto no Oracle é ter que usar o NVARCHAR ou o NCHAR. Realmente a Oracle complica muito isso. Eu tenho a impressão que a Oracle criou isso para suprir deficiências no tratamento com caracteres multibyte.
O RMAN realmente é algo interessante, mas eu acho que só vale a pena mesmo se você precisa de backp incremental. Caso contrário, você pode se virar muito bem com seus próprios scripts. A razão de eu prefirir os scripts é que o formato do backup gerado pelo rman só pode ser utilizado por ele. Uma vez utilizando o RMAN, você está preso a ele. Eu realmente prefiro ter mais controle da situação. Este é um dos motivos para eu não ter citado o ASM. Particularmente o pessoal do PostgreSQL optou por não desenvolver o armazenamento em RAW Devices. O motivo é mais ou menos o mesmo de evitar o RMAN, além da filosofia de que o PostgreSQL desenvolve um SGDB e não um SO. Para desenvolver SO, já exite muita gente fazendo um excelente trabalho.
Os parâmetros dinâmicos o PostgreSQL também suporta, por sessão, por transação, por banco de dados ou por usuário. Com isso, a parte de perfis é contornada com tranquilidade. O fato de poder setar parâmetros por usuário ou ROLE, atende a boa parte dos recursos dos perfis de forma bastante simples e elegante. Mas é claro que isto poderia avançar um pouco mais.
Opa,
Concordo com muita coisa que você falou. A parte de ROLES do PostgreSQL dá um show na da Oracle. Quanto as partes dos parâmetros, acho que não me expliquei direito, estava falando da gerência da instância. No Oracle você tem mais controle, mais parâmetros dinâmicos estão disponíveis do que no PostgreSQL. Ai também tem um exagero, são parâmetros demais no Oracle
Quanto ao RMAN, você captou a idéia, backup incremental. Claro que os backupsets são uma mão na roda quanto ao uso de disco, mas como você falou. Só o RMAN entende. E outra coisa incremental só com o bendito ARCHIVELOG. Sim o ASM é algo estranho, confuso demais. Por exemplo, se você tem problema em um controlfile e quer copiar um sobre o outro, em S.O. isso é muito fácil.. mas no ASM? Via SQL… acho que não dá muito certo. E se o ASM der problema?
Já com os caracteres, o unicode é um santo remédio. O que eu quis falar é que com o Oracle você pode mudar muitos mais parâmetros do que no PostgreSQL, você tem mais controle (pode até criar um charset prórpio). Sorts, index’s, territórios e outros. Sim, também concordo que N*** da vida são bem chatos
E concordo com você, quem faz banco deve se preocupar com o banco de dados, e não com coisas/fazer coisas do S.O.
Meu tempo anda curto para ler de forma mais acentuada mas esse item SQLLoader existe semelhante feito pelo pessoal da NTT: Pgboulkload
-http://pgfoundry.org/projects/pgbulkload/
A questão do SQLLoader da Oracle não é simplesmente a velocidade, mas sim flexibilidade. Com o Loader você pode importar arquivos com colunas de tamanho fixo sem separadores, fazer conversão de tipos de dados on the fly e o mais importante, gerar um arquivo com as linhas que deram problema. O Loader é uma ferramenta muito poderosa com toneladas de opções. Uma coisa interessante para quem está preocupado com desempenho é que você pode separar os dados de entrada em vários arquivos e paralelizar (em disco e processador) a importação. São algumas coisas que o PostgreSQL ainda não faz. O Bizgres Loader já tem boa parte destas características e espero vê-las incorporadas diretamente no PostgreSQL em breve.
Grande Telles!
Muito bom esse teu espaço, hein!
Eis uma lista de features do Oracle que o PostgreSQL não possui, em ordem de prioridade:
1. Tablespace UNDO: considero a “galinha dos ovos de ouro” da Oracle. Nenhum outro SGBD consegue minimizar tanto a contenção do servidor!
2. Backup Diferencial: backup físico no PostgreSQL só temos FULL e transacional. Não existe esse meio termo…
3. Datafiles Freezing: o nosso pg_start_backup() bloqueia o cluster inteiro. No Oracle podemos fazer isso para um determinado tablespace apenas, reduzindo a quantidade de LOGs de transação criados nesse período.
4. Particionamento: infelizmente ainda não temos uma solução out-of-box para particionamento de tabelas. Utilizar aquele artifício de herança é de lascar…
5. Visões materializadas: como seria bom se tivesse isso no core do PostgreSQL…
6. COUNT(): essa função de agregação que os programadores têm verdadeira tara pode simplesmente tornar-se um pesadelo para o DBA! Não sei como o Oracle trata essa questão, mas no PostgreSQL é um calcanhar de Aquiles por provocar full scans…
7. Transações em PLs: pra quem faz uso excessivo de processamentos em funções, isso faz uma tremenda falta, provocando a secção de uma procedure em diversas no PostgreSQL.
8. Funções analíticas: às vezes dá pra “se virar”, construindo-as em PL/pgSQL, mas não é a mesma coisa em questões de desempenho…
9. Cluster tables: diferentemente de outros SGBDs, o Oracle consegue armazenar fisicamente juntas estruturas relacionadas, como tabelas de Pedidos e Linhas de Pedidos.
10. Backup dump inconsistente: no PostgreSQL o pg_dump sempre faz as cópias com consistência. Eliminando isso talvez dê uma acelerada no processo.
11. Raw devices: antigamente achava que não suportá-los era uma falta do PostgreSQL. Acompanhando a pg_hackers vi que o Oracle a suporta por uma questão histórica. Reinventar um sistema de arquivos não é tarefa para o time do PostgreSQL.
12. Nested tables: não conheço muito disso o suficiente para comentar.
13. Sinônimos: não existe no PostgreSQL simplesmente porque é desnecessário nele! A variável de sessão search_path é muito mais interessante, na minha opinião.
Abraço,
Hjort
Ola amigos..
Trabalho com PLs nos dois lados..
Gosto de ambas, mas falando serio..
SOU BEM MAIS AS FUNCIONALIDADES DO PgSQL.
O Oracle não acho tão flexivel. E isso me atrapalha muito.
Tomara que melhorem MESMO nas proximas versoes.
Viva a PgSQL
=)
[...] escrevi dois posts comparando o Oracle com o PostgreSQL eu tive os melhores comentários deste blog aqui e aqui. Este foi um dos assuntos mais gratificantes em termos de retorno, pois os comentários [...]
Olá,
Também, poderiamos colocar a questão de consultas hierárquicas, utilizadas quando temos uma tabela Auto-Relacionada. O Oracle possui algumas cláusulas(CONNECT BY, START WITH PRIOR) que facilitam este processo. Já o Postgres devemos implementar uma função recursiva ou procurar alguma biblioteca de terceiros que tenha alguma solução semelhante.
Flw!
Parabéns a todos,
tudo que está escrito fica dentro das diferenças mesmo.
Mas como DBA o que eu realmente sinto falta no PostgreSQL e tenho no Oracle
para pequenos e médios são o RMAN e o RAC.
Abraços