Essa semana tive dois clientes com o mesmo problema, utilizando RAC 11g e um dos nodes caiu e não voltou mais, ssh ok, ping ok e tudo redondinho, menos um detalhe que não esperava assim de imediato, BONDING configurado nas maquinas.
De acordo com o Doc RAC and Oracle Clusterware Best Practices and Starter Kit (Linux) [ID 811306.1] e o Linux: ARP cache issues with Red Hat “balance-alb (mode 6)” bonding driver [ID 756259.1] do metalink o bond mode 3 (para a interconnect) e o mode 6 (para a interconnect e public) devem ser evitados.
Testes de modo 3 para a interconexão privada provou que duplica todos os pacotes UDP e os transmite em cada caminho. Isto aumenta a sobrecarga de CPU para o processamento de dados da interligação desse modo fazendo a interligação menos eficiente. Os pacotes UDP duplicadas causadas pelo mode 3 expôs o Bug 7238620 (ORA-600 [2032]) e o Bug 9081436 (GC CR REQUEST WAIT CAUSING SESSIONS TO WAIT). Embora os problemas conhecidos com o mode 3 são isoladas para a interconexão, está fora de cogitação o seu uso para a rede pública também devido a ineficiências com o mode 3 mencionado ateriormente.
O mode 6 tem uma condição de corrida inerente com endereços IP flutuante causando problemas de failover com VIPs, SCAN VIPs e HAIP.
Conclusão: Não usar bond mode 3 e 6 para a rede em RAC´s de 10.1.0.2 a 11.2.0.4 em linux x86 e x86_64, para redes publicas e privadas.
Autor: Rafael Stoever
Bacharel em Sistema de Informação pela Uniasselvi, atualmente cursando Gerenciamento de Projetos em TI pela Pós Graduação Uniasselvi. Atuo como Analista de suporte a banco de dados – DBA pela Lumina Serviços em TI residente de Blumenau/ SC, OPN Certified Specialist, Certificado OCP 10g/11g/12c, OCE RAC10g e Linux 10g. Conhecimentos em Microsoft SqlSever, Mysql e programação web (php,asp).
