Ultimamente tenho trabalhado mais com Oracle RAC do que PostgreSQL. Para quem não conhece, Oracle RAC é uma solução de cluster para banco de dados Oracle
Nessas minhas últimas semanas de manutenção, minhas impressões iniciais são:
1 - É uma caixa mágica que ninguém sabe como funciona por dentro.
2 - Os idiotas que desenvolveram não entendem porra nenhuma de System V.
3 - Heartbeat é para checar o estados dos nós de um cluster ou serviços, não para replicar dados dentro dele.
4 - Modificar o coreutils e incrementar biblioteca quer permite acesso como O_DIRECT é quase o mesmo que mandar o Sistema Operacional para o limbo, prá que um SO mesmo?
5 - OCFS (não o OCFS2) é uma bomba-relógio, se tem Oracle nele, tenha plano de saúde.
6 - Não adianta te enganarem, RAC não foi feito para trabalhar em rede WAN.
7 - Não se preocupe, alguns erro ORA-XXXX são considerados normais. (hã?) -
8 - Se sua rede não é confiável, esquece de usar RAC, ele irá cair e você demorará para entender onde está o problema. Na verdade, com um hardware intermediário ele já tem surtos psicóticos.
9 - Tenha uma bendita conta no Metalink, senão viverá menos dias diante ao caos.
10 - Se você não tem suporte nem da Oracle, nem Red Hat (Debian é mais rápido, quer apostar?), pode instalar em qualquer Linux decente que funciona igual ou mais rápido.
11 - Ainda bem que o PostgreSQL não é Oracle e não existe nenhum projeto estável que se inspire no RAC. 
Obs: Convença-me que estou errado, ficarei feliz com opiniões divergentes. 
on Sep 22nd, 2008 at 22:55
hmm, com a experiência que tive com Oracle eu concordo com quase tudo; eu não acho que O_DIRECT é jogar o SO pro limbo, though; I/O e memória RAM são o coração de um banco de dados, e é interessante que o banco de dados possa fazer buffering e caching mais eficientes do que a heurística do S.O. conseguiria fazer (e sem duplicá-la).
Eu não entendi bem os comentários 2 e 3; o que eles deveriam saber de System V, e você está falando que o RAC chama replicação de heartbeat?
on Sep 23rd, 2008 at 09:04
Kov, o que eu entendi do comentário 2 foi “pra que seguir o padrão que todo mundo usa? Nós somos da Oracle e podemos reinventar a roda”.
on Sep 23rd, 2008 at 09:37
Oi Fike, duas coisas:
1) Pelo que vi, o O_DIRECT permite acesso direto ao conteúdo de arquivos, fazendo com que, durante operações de leitura e escrita no disco, a transferência ocorra diretamente da aplicação para o disco, evitando as cópias de dados entre os contextos da aplicação e do kernel, mas isso apenas para escritas de DADOS. Toda a metainformação será mantida pelo kernel do sistema.
2)Eu concordo com a parte do “pra que o sistema operacional mesmo?” é uma questão de especializaçao. O sistema operacional provê ferramentas para a construção de sistemas. Como você não sabe de antemão que sistemas serão construídos, você vai prover um sistema de uso geral e parâmetros para adequação ao uso particular.
No entanto, algumas aplicações crescem e se especializam a um ponto em que a maior parte dos recursos de uso geral do sistema não fazem sentido. É o caso do oracle. A questão do POR QUÊ não se fazem aplicações como o oracle falarem diretamente com o hardware é puramente econômica e estratégica, não técnica. Acredite em mim.
on Sep 23rd, 2008 at 11:22
Pensando bem, um banco de dados é quase como que um ‘mini sistema operacional’ em si. O O_DIRECT é para permitir que a transfêrencia de dados entre sistema e HD aconteça com o mínimo de transferência do SO? O Sybase no Linux, que eu me lembre, só tinha uma performance razoável com raw devices. (vc formata a partição como um raw device e o sybase toma conta dela, sem interferência do s.o.). Bancos de dados fazem cache.. gerenciamente de memória… Enfim… De qualquer forma, não vou querer mexer em Oracle tão cedo.
on Sep 23rd, 2008 at 11:36
Nota: o metalink não é feito em rails, usando jruby?
on Sep 23rd, 2008 at 11:40
Caros,
Vocês estão corretos ao afirmarem sobre o O_DIRECT, a questão é manter o *coreutils* em separado e o uso indiscriminado do O_DIRECT, praticamente abstrai o uso do SO porque, no caso do Oracle, qualquer problema que ocorra, terá que ser tratado diretamente pela aplicação, sem o uso de ferramentas de depuração do SO.
Sobre o System V, kov, o RAC para adicionar/remover um nó tem que modificar o inittab. Não estou convencido que uma aplicação use o inittab para gerenciar os serviços ao invés do runlevel seja ao razoável.
O RAC usa a interface do Heartbeat para transferir os blocos das base de dados entre os nós. Em princípio seria de baixo tráfego mas de fato gera um grande tráfego e com qualquer problema na comunicação entre os nós, seja pelo Heartbeat ou RAC, você terá problemas de indisponibilidade.
Gostei do comentários de todos.
on Sep 24th, 2008 at 07:29
Alguns comentários:
1) Ele é tão caixa preta quanto outros bancos de dados proprietários. Existem extensa documentação falando sobre o cache fusion e coisas do tipo. Mas de fato…. ninguém vê o que está acontecendo. Pelo SO você fica completamente cego, ainda mais com o ASM. É claro que a Oracle tem suas próprias ferramentas guardadas a 7 chaves…
3) Bom… a Oracle deixa bem claro o que ela entende como cache fusion. Alias, toda a teoria de clusters shared all é assim mesmo. Acho que não adianta berrar aqui. A IBM também faz este tipo de cluster e tem até um hardware específico para concentrar o cache…
5) O OCFS já foi aposentado memso. O OCFS2 é muito superior. Tão superior que é proibido usar ele no Oracle Standard. Só na versão Enterprise você pode utiliza-lo.
6) Nunca vi nada na documentação da Oracle que citasse tal heresia. O que existe é o que eles vendem como “grid” que é fazer um stand by do RAC. O Stand by via WAN é tranquilo. A interconexão entre os nós do RAC é sagrada.
7) é verdade… é meio tosco. Ver os estados dos nós oscilando e achar normal é meio medonho no começo.
9) Manter um RAC sem metalink é como brincar todo dia de roleta russa. Eu não tentaria.
10) Bom… se você deveria usar o metalink… não deveria usar qualquer distro Linux. É triste que boas distribuições não sejam homologadas pela Oracle, mas é a vida. A questão não é a distribuição… é poder ter suporte da Oracle. Em ambiente de produção, você acaba não tendo muita escolha. Ou você vai criar um ambiente de alta disponibilidade com um software caixa preta sem suporte?
11) Será que o projeto do PGCluster II parou? A ideia era fazer um cluster shared all, não?
on Nov 3rd, 2008 at 01:14
Uma Nota,
O ASM substituiu (ou se acrescentou como općão) o ocfs como sistema de arquivos. Isto ocorreu entre o oracle rac 9i e o oracle rac10g.
O ASMLib é um gerenciador de volumes, o qual provê volumes (equivalente a devices) para o ASM (dentro do oracle). Realmente a Oracle reinventou a roda e agora utiliza um sistema de arquivos próprio, que faz todo o gerenciamento de dados (super-especializaćão??), mas desde que eu trabalho com o mesmo (a cerca de 18 meses) como Analista de suporte, tenho tido bom feedback dos DBA’s, com relaćão ao mesmo. Certamente é melhor utilizar ASMLib do que raw devices.