Veja, eu respeito o SGDB Oracle. Ele não apenas é um dos primeiros bancos de dados relacionais do mercado como também é robusto, confiável e possui uma miríade de recursos. Mas convenhamos, para um SGDB que está a tempos no mercado, algumas coisas são realmente incríveis. É claro que existem algumas explicações que dizem respeito a história de como o produto surgiu e muitas que tem mais haver com a estratégia de marketing da Oracle.

• A Oracle possui uma enorme documentação. Toda ela está disponível on-line para qualquer um baixar. O mesmo acontece com os softwares (não as atualizações, claro). Uma das coisas que eu aprecio na documentação da Oracle, são as suas recomendações quanto as melhores práticas. Algumas delas são específicas em relação ao seu produto, mas muito do que está lá se aplica a qualquer banco de dados. Dito isso, me explique: qual o motivo de tantos produtos da Oracle não seguirem as suas próprias recomendações. Você não acredita? Quem conhece as restrições das aplicações feitas em FORMS sabe do que eu estou falando. Agora imagine um ERP inteiro sem uma FK (chave estrangeira). Isso mesmo… o famoso ERP da Oracle não tem nenhuma. Alguém me explica isso?
• Eu falei bem da documentação da Oracle, não? Pois é, os caras fazem um bom trabalho nela. Mas tem um problema. Algumas coisas misteriosamente não estão lá. É quase inacreditável que eles esqueçam de documentar coisas tão importantes na documentação. Realmente não faz nenhum sentido. Vou lhes dizer que não é pouca coisa.
• Mais um detalhe bizarro sobre a documentação da Oracle. Você já olhou o manual de instalação deles? Bom, eles tem uma lista de dependências que devem ser instaladas para que você não falhe miseravelmente no meio do caminho. No entanto há algumas coisas bizarras lá. Eu nunca entendi o que o gnome-libs, o xscreensaver e o control-center fazem na lista de dependências. São completamente inúteis. Você definitivamente não precisa delas no seu servidor, mesmo que você queira usar o instalador gráfico. Ainda assim, se você cair na besteira de ler a documentação que acompanha os CDs do Oracle, ou a documentação que vem junto com os binários que você baixa no site, você pode encontrar sérios problemas no caminho. Algumas dependências simplesmente não estão descritas nesta versão da documentação, como você poderia esperar. Não esqueça, sempre olhas os “Release Notes” na documentação on-line. Particularmente, se você for fazer uma instalação em Linx com 64 bits, você me agradecerá muito por esta dica. Isto acontece porquê o instalador do Oracle de 64 bits roda em 32 bits. Surpresa, as dependências de 32 bits não estão na documentação original.
• Sim, o famoso processo de instalação do banco de dados está longe de ser um processo simples. Eu realmente não conheci o Oracle nas suas versões mais antigas. Só conheço ele a partir da versão 8. Não tenho nada contra as zilhões de recomendações de acertos no SO antes da instalação. Na verdade, isso é até bem bacana. Uso muito destas recomendações com outros SGDBs. Mas o instalador gráfico deles é simplesmente horrível. Porquê? É muito simples… ele força você a instalar a interface gráfica no seu servidor. Para os usuários do Windows, tudo bem, mas no mundo Unix isto é uma heresia. Para complicar ainda mais… o instalador é feito em Java e pesa uma tonelada. Fazer um instalador em modo texto não seria tão complexo assim. Não é que seja impossível fazer a instalação em modo texto. Claro que é possível. Mas você tem de criar um arquivo enorme de configurações que pode ser um inferno de editar, conforme forem as suas necessidades. Eu mesmo já criei alguns scripts para me ajudar a criar os arquivos de isntalação em modo texto. Daí para criar um instalador em modo texto seria realmente um pulo. Convenhamos que esta não seria uma tarefa árdua para a Oracle.
• O SQL*Plus número um dos DBAs Oracle. É claro que surgiram coisas mais amigáveis como o SQL Developer, mas o SQL*Plus é a única ferramenta em modo texto que você tem para utilizar. Eu realmente gosto muito das interfaces gráficas. Mas na hora do aperto elas não me servem muito. Quando preciso rodar uma rotina pesada ela também não me ajuda muito. E principalmente, quando quero fazer algum script rápido que acesse o SGDB, o SQL*Plus é uma mão na roda. Mas há um detalhe muito bizarro nele. Ele não tem suporte a biblioteca mais manjada das ferramentas em linha de comando: a ReadLine. Sem ela ou outra substituta a altura, voltamos para a idade do bit lascado. Até as setas do seu teclado perdem a utilidade. É realmente lastimável a perda de produtividade que este detalhe nos proporciona no dia a dia. Para quem está acostumado com o Bash, isto é simplesmente irritante.
• O metalink é a porta de entrada para um universo a parte da Oracle. Patches de segurança, zilhões de documentos sobre erros bizarros, uma maravilha. Só tem um problema. Parece que a Oracle usou seus próprios produtos para criar o seu site. E vou lhes dizer uma coisa… eles parecem que nunca utilizaram o gmail na vida. Definitivamente nunca ouviram falar em AJAX. Para completar, ainda usam FLASH para montar um site lento, feito e com uma péssima usabilidade. Depois que você se acostuma com o jeito tosco do site, até dá para se virar bem, a não ser é claro, que você esteja com um pepino enorme na mão e a sua conexão com a Internet esteja lenta. Se for esse o seu caso, vou lhe dizer qual é a forma de rezolver seus problemas de forma mais rápida, interativa e eficiente: entre no servidor de IRC da freenodes na sala #oracle. Você vai descobrir que o “suporte livre” realmente funciona.
• O padrão SQL já vai completar 20 anos em 2009. Ele surgiu em sua primeira versão oficial em 1989. Ficou famoso pela versão de 1992, e depois contou com mais duas grandes versões sendo a última em 2003. É verdade que a moral da ISO anda meio baixa nos últimos tempos. Mesmo assim, não há motivos para a Oracle ser tão lenta na adoção dos padrões. O tipo de dado TIMESTAMP surgiu apenas na versão 9i. O tratamento com os nulos, o nvarchar, a ausência do tipo inteiro e outras coisas estranhas do Oracle lhe garantem não conformidades significativas com o padrão SQL.
• A Oracle tem uma tara por arquivos binários que nenhum ser usuário possa ler. A coisa não se limita aos dispositivos crús (Raw Devices), vai dos backups com RMAN, ao rastreamento de erros com trace. Enfim, o negócio é confiar na Oracle…

Você não concorda com as minhas observações? Diria que tem outros itens para acrescentar a lista? Coloque nos comentários então!

Coloquei hoje na área de downloads um arquivo contendo 3 diagramas que utilizei para explicar o funcionamento da parte de storage no Oracle RAC. Se alguém encontrar algum erro nos diagramas, por favor me avisem.

A Evans Data Corporation realizou uma pesquisa com 1400 usuário de bancos de dados em todo o mundo para saber o que eles acham dos principais SGDBs do mercado. A pesquisa virou matéria na InformationWeek que por sua vez foi comentada pelo Sr. Lewis Cunningham.

A pesquisa envolveu os seguintes bancos de dados:

• Informix Dynamic Server
• IBM DB2
• Microsoft SQL Server
• MySQL
• Oracle Database 10g or later
• PostgreSQL
• Sybase Adaptive Server

Os critérios de avaliação foram:

• Performance
• Funcionalidades de segurança
• Scalabilidade vertical
• Atomicidade
• Consistência
• Isolação de transações
• Durabilidade das transações
• Qualidade das ferramentas de modelagens
• Suporte ao XML
• Suporte a Multiplatforma
• Qualidade das ferramentas de gerenciamento inclusas no banco de dados
• Qualidade das ferramentas de gerenciamento avaliáveis por outros fornecedores
• Suporte a linguagens de programação

Antes de comentar sobre os resultados, é preciso dizer que a pesquisa é sobre a percepção dos usuários e não sobre testes de laboratório. portanto não reflete características reais dos softwares em questão e sim o que os seus usuários pensam deles.

Os resultados:

• A Oracle ficou em primeiro lugar em todos os critérios. Com o lançamento do 11g no ano passado eu imagino que toda a campanha de marketing esteja ainda viva na memória das pessoas, mas a posição não é de toda desmerecida. Particularmente, acredito que as ferramentas de monitoramento e gerenciamento da Oracle sejam realmente excelentes. Mas acredito que nos itens relativos a ACID (Atomicidade, Consistência, Isolação e Durabilidade) o DB2 rodando em mainframes ainda seja lider absoluto. O DB2 ficou em segundo lugar, mostrando que a Oracle realmente conseguiu cativar os corações do pessoal de TI. Também senti falta da Teradata como competidor, que é líder na área de Data Warehouse e teriam batido a Oracle e o DB2 nesta área. Pelos ítens da pesquisa, o foco foi avaliar os competidores que se destacam na area de OLTP.

• O MySQL foi o terceiro SGDB mais bem avaliado no geral. Apesar disso ter ficado longe no ranking no que diz respeito a ACID, escalabilidade e funcionalidades de segurança. O que puxou sua nota para cima foi a sua avaliação em suporte multiplataforma (2º lugar), performance (3º lugar), qualidade de ferramentas fornecidas por 3ºs (3º lugar) e suporte a linguagens de programação. Acho que a avaliação reflete bem o status do MySQL, sua popularidade e suas características de bicicleta de velódromo: é leve e rápido, mas não tem freios, câmbio, etc. O lançamento do falcon é a promessa de mudar isso. Particularmente eu gostaria que o MySQL continuasse exatamente do jeito que ele é, pois se torna uma ótima opção em sites web dinâmicos, que não se preocupam muito com transações.

• O MS SQL Server foi mal em suporte multiplataforma (ok, isso é óbvio) e performance. Se destacou na parte das ferramentas de modelagem, gerenciamento e suporte a XML.

• O PostgreSQL não foi muito bem… foi mal avaliado nas ferramentas de gerenciamento, modelagem, suporte a XML. No entanto foi bem avaliado em ACID e em funcionalidades de segurança. Estas avaliações positivas são importantes, pois demonstram a percepção dos usuários de que o PostgreSQL é confiável. Uma zebra ocorreu na parte de suporte a plataformas, pois o PostgreSQL deveria ser melhor avaliado aqui. Veja por exemplo que ele roda em FreeBSD uma plataforma para poucos.

O PostgreSQL foi o que teve a segunda pior avaliação Mas estamos em 2008 e apesar do nome da pesquisa, ela foi conduzida em dezembro de 2007. Com o lançamento do PostgreSQL 8.3 algumas coisas mudam na avaliação: a performance melhorou muito e o suporte a XML também. Isto já seria motivo para o PostgreSQL subir vários pontos e encostar no Oracle e no DB2.

O que temos que perceber é que o PostgreSQL vem se desenvolvendo sobre terreno firme. Com a parte de ACID bem resolvida, é possível crescer sem ter que abrir mão da segurança. A performance do PostgreSQL vem crescendo numa taxa que o coloca entre os líderes desta categoria. Algumas funcionalidades que precisam ser melhoradas como a parte de particionamento de tabelas já estão sendo trabalhadas para a versão 8.4. Assim, o que os usuários ainda sentem falta (veja o histórico das listas do PostgreSQL e você verá que isto é recorrente) são de ferramentas de monitoramento, gerenciamento e modelagem. Ainda há muito o que se trabalhar nesta área. Mas acredito que isto seja uma questão que se resolverá. O PostgreSQL tem evoluído muito na quantidade de funções e tabelas de sistemas capazes de fornecer informações úteis para o DBA. O pgsnmpd deverá abrir as portas para o gerenciamento corporativo. O que falta são ferramentas mais amigáveis. Isto não será problema. Já vemos coisas muito promissoras neste sentido. O PostgreSQL está sedimentado sobre uma base sólida, a parte do acabamento virá naturalmente.

Antes que você saia instalando o Oracle 10g e colocando a mão na massa para valer, você deve avaliar um detalhe importante: Como será o seu ambiente de “Laboratório”. Já escrevi sobre a importância de se ter um ambiente de produção, um de homologação e um de teste. Agora é a vez de se criar um quarto ambiente. Vejamos como utilizá-lo e como ele se integra com os outros 3 ambientes já existentes.

Entre os ambientes de banco de dados, o único que a Oracle não cobra pelo licenciamento é o laboratório. Além do ambiente de produção, a Oracle cobra licenças para o seu ambiente de testes, homologação, stand by, etc. Para isso, o seu ambiente de produção e desenvolvimento não podem depender em momento algum do laboratório. Esta é uma regra que deve estar clara. Então para que ele serve? Para testar unica e exclusivamente o SGDB e saber como ele se comporta. Você não vai utilizar o laboratório apenas para testar a migração do Oracle 9i para o 10g ou 11g. Você vai utilizar ele para validar cada novo patch de correção ou para testar funcionalidades que nunca foram exploradas antes.

De certa forma, o laboratório é o parque de diversões do DBA. Lá ele pode fazer uma carga com os dados reais das aplicações e levar o ambiente ao limite. Apesar disso, ele deve estar por perto não apenas durante um processo de migração. Você pode precisar dele quando menos espera. Imagine que você por um acaso do destino encontre um bug no Oracle e você tenha que aplicar um patch. Você não vai aplicar o patch direto no seu ambiente de produção/homologação/testes. Você vai testar primeiro ele no laboratório. Vai analisar se ele oferece impacto em outras aplicações. Se realmente vale a pena aplicar o patch ou se é melhor conviver com o bug do jeito que está, etc. Se um dia você resolver aplicar um
“patch set” que é o equivalente da Oracle a um “service pack” da Microsoft, os testes se tornam mais importantes ainda, pois você pode ter certeza que muitas características do SGDB vão sofrer alterações relevantes. O oracle 10g por exemplo está no “Release 2″ ou seja, na versão “10.2″. Já saíram alguns patch sets para o 10.2. Em março saiu o 3º patch set, estando hoje na versão “10.2.0.3″. Mas não despreze os pequenos patchs que você consegue aplicar em poucos minutos com o OPatch. Uma pequena alteração no CBO (Cost Base Optimizer) pode virar de ponta cabeça o desempenho de todas as suas consultas. E mais, um patch em uma área que pode não parecer diretamente relacionada com outra pode ter efeitos colaterais inesperados.

Em resumo, mexer no seu SGDB, seja qual for, exige muita responsabilidade e muitos testes. A validação destes testes deve ser feita de maneira progressiva. Nunca pense em mudar alguma coisa direto do laboratório para a produção. Vá com calma, independente se você está migrando de versão, de release, de point release ou mesmo aplicando um pequeno e inofensivo patch. O ideal é fazer os testes no laboratório e depois aplicar as alterações no ambiente de testes, homologação e por último na produção.

Bom, você pode ter se convencido de que ter o laboratório é necessário, não apenas para um projeto de migração de versão. Mas vai imaginar que o orçamento da empresa não vai comportar um servidor dedicado só para isso. Já vai lembrar de um servidor que estava para se aposentar ou até mesmo um desktop. Mas agora respire fundo e pense. Você vai conseguir realmente testar as funcionalidades que deseja neste ambiente? Quais as chances de você ter resultados diferentes do laboratório no ambiente de produção? Se pensar com cuidado, verá que um desktop está fora de cogitação para realizar testes. HDs IDE ou SATA (por mais eles estejam a cada dia mais rápidos, etc, etc, etc) não são opções viáveis para um servidor de laboratório. Você sempre deve se aproximar o máximo possível do seu ambiente de produção, mas… bom, todo orçamento tem limite. Então o que fazer?

A primeira coisa a se pensar é que se o seu servidor de produção vai migrar, então seria bom migrar para um novo hardware também. O seu servidor de laboratório poderá ser o novo servidor. Migrar o servidor de produção para uma nova versão na mesma máquina é muito arriscado. Você não tem como voltar atrás se alguma coisa der errado. Se você utilizar o novo servidor, fará o favor de testar bem o novo hardware e ter uma idéia realista de como será o desempenho dele num futuro próximo. Como um servidor de produção não deve estar ativo por mais de 3 ou 4 anos, o upgrade de hardware acaba muitas vezes casando com o upgrade de software. Além do mais, por tradição as novas versões com suas novas funcionalidades costumam trazer ganhos de performance acompanhados com aumento no consumo de recursos de hardware. No Oracle 11g por exemplo a exigência mínima de memória saltou de 512MB para 1GB.

Mas, você vai querer manter um laboratório só para testar novas versões ou patch. Você pode querer começar a testar o 11g só para verificar qual tipo de ganho sua empresa terá e decidir se vale a pena migrar mais rápido (eu diria que daqui a um ano é rápido para uma versão nova como o 11g) ou esperar mais tempo. Você vai querer manter o laboratório ativo para testar patchs de segurança e outros que venham a aparecer. A partir do lançamento da versão 10.2.0.3 em março de 2007, já foram publicados mais de 400 patchs até setembro. Isto é sério ao ponto de ambientes críticos manterem equipes especializadas em aplicações de patchs, pois saber o que aplicar, quando e como não é tão simples quanto parece. Se quiser manter um laboratório para esta finalidade, você pode pensar em fazer algumas concessões como possuir até metade do espaço em disco original no ambiente de produção. Um corte deste tipo exigirá que você carregue as tabelas das aplicações com uma fração das linhas originais. Isto pode dar um certo trabalho, pois você terá que manter as restrições de integridade entre as tabelas intactas. Neste caso, você deve se lembrar que você não tem testes de desempenho válidos neste ambiente. Os planos de consulta irão mudar radicalmente no ambiente de produção. Se você for aplicar as alterações validadas num servidor de laboratório limitado mas aplicar as alterações primeiro no ambiente de testes e depois no servidor de homologação, você poderá resolver os problemas de desempenho no ambiente de homologação antes de chegar no ambiente de produção. Isto é claro, se o ambiente de homologação for realmente semelhante ao ambiente de produção.

Em uma empresa menor, pode ser inviável manter 4 ambientes. O custo para se manter 4 servidores para cada ambiente de produção é bem pesado. Ninguém disse que brincar de banco de dados seria barato, mas existe uma regra em TI que deve sempre ser lembrada: “O valor do cofre não pode ser maior que valor dos objetos que você quer guardar nele”. O custo/benefício deve ser avaliado. Principalmente os riscos devem ser avaliados:

• Migrar de versão de banco de dados nem sempre é uma opção se você deseja continuar a ter suporte do seu fornecedor. Você pode desejar migrar de versão atraído por novas funcionalidades ou aumento de desempenho. Mas é fato que todo software deixa de receber suporte e atualizações de segurança depois de um tempo. No caso da Oracle, é seguro estar na penúltima versão. Com o lançamento do 11g, está na hora de pensar seriamente em migrar para o 10g, uma vez que o 9i será descontinuado pela Oracle.
• Migrar de hardware a cada 3 ou 4 anos não é uma opção. Você pode até continuar utilizando o servidor depois deste período para operações menos críticas, mas este não costuma ser o caso dos bancos de dados em produção. Os DBAs podem e devem se considerar privilegiados na hora de fatiar o orçamento de investimento na área de TI.
• Você nunca vai conseguir testar 100% o desempenho da sua aplicação no laboratório, o que significa que você sempre vai estar sujeito gargalos imprevistos. Por outro lado, de 90 a 99% dos problemas (dependendo do tipo de testes que você executou) podem ser detectados com testes de desempenho. É muito mais fácil lidar com 1% a 10% de problemas no ambiente de produção, do que 100%.
• Considere seriamente a possibilidade de realizar operação paralela entre ambiente de produção e laboratório por um ciclo do software - como um mês numa folha de pagamento - incluindo a época de fechamento - como a geração de rotinas anuais. Negocie isto com os usuários da aplicação e exponha francamente para eles qual é o risco de não fazê-lo. Imagine uma base de dados de contabilidade que você migre e só depois de quase um ano, no fechamento do ano fiscal, você descobre sérios problemas. Distribua o risco!
• Quanto maior o seu gargalo de desempenho no ambiente de produção, maior será o desejo de migrar para novas versões. Ambientes onde o desempenho é sempre crítico e uma preocupação constante devem investir pesado no ambiente de laboratório e homologação.

Se você chegou aqui e acha tudo isso uma extravagancia e desperdício de recursos, lembre-se que em geral os testes por mais que tenham sido feitos com esmero (o que em geral não acontece na prática), eles nunca simulam o ambiente real de forma fidedigna. Uma expressão que traduz isso muito bem é “Shit happens“. E quem já viu, sabe que certas situações não podem ser expressadas com vocabulário formal. A questão no final será: você poderia ter prevenido isso? A resposta a esta pergunta lhe dirá se você continuará ou não empregado!

Bom, 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.