c





 



 



Publicado por   e arquivado em 



,  , 

Bom, depois de escrever sobre algumas 




 


 , chegou a hora de fazer o inverso. Eis aqui algumas características do Oracle
que eu realmente sinto falta no PostgreSQL.

 !riggers 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
AUDI! 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 !ablespace !EMP e
UNDO. Isto permite um ajuste de desempenho melhor, particularmente
colocando o tablespace !EMP 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.
 Dine -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 OL!P 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 E!L, 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   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  
!! 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 
 que promete cobrir boa parte deste vácuo no PostgreSQL. No
entanto, já existem ferramentas como o " , 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.