Operação diária e cenários de falha do Oracle RAC

Operação diária e resposta a falhas de um cluster Oracle RAC (Grid Infrastructure 19c) já instalado e em funcionamento: verificação de saúde, diagnóstico de node eviction, colocação de um node em manutenção, parada e partida planejadas do cluster inteiro, adição e remoção de nodes, gerenciamento de serviços (preferred/available, AC/TAC), alteração de SCAN/VIP/porta/interconnect, backup e restore de OCR/OLR, migração dos arquivos de OCR e voting. Não é um guia de instalação (antes, veja Instalação do RAC); para patch, use Rolling patch no RAC e, para disk groups, Operação diária do ASM. Cada cenário segue a ordem diagnóstico → rede de segurança → execução → validação → pós-operação.

Topologia: RAC existente com 2–8 nodes (Grid Infrastructure 19c; diferenças do 23ai/26ai nas notas)

Cenários

• Verificação de saúde do cluster (diária / antes de manutenção) — Não altera nada: são verificados a stack do Clusterware, os recursos, OCR/voting, ASM, interconnect, horário e os alertas recentes. Escolha como primeira ação na verificação diária, antes de cada manutenção e patch e quando chegar uma reclamação.
• Um node foi removido do cluster ou reiniciou sozinho (diagnóstico de eviction) — Somente leitura: escolha se um node reiniciou inesperadamente ou foi removido do cluster. Com o alert log do Clusterware, o ocssd.trc, os logs do sistema operacional e os valores de misscount/disktimeout, descobre-se se a causa raiz é rede, disco ou sistema operacional.
• Parar um node para manutenção e trazê-lo de volta — Escolha se for feito patch do sistema operacional, de kernel ou manutenção de hardware em um node. Os outros nodes continuam funcionando; os serviços da instância desse node são movidos e as sessões são encerradas ao fim do tempo de drain.
• Parar e iniciar o cluster inteiro de forma planejada — Escolha quando todos os nodes precisam ser desligados ao mesmo tempo, como em uma manutenção de SAN ou de data center. Downtime total: todos os bancos, o ASM e o Clusterware param em todos os nodes.
• Adicionar um novo node ao cluster — Escolha se um novo servidor vai entrar no cluster (aumento de capacidade, renovação de hardware). Sem downtime: verificações prévias (cluvfy), Grid home (addnode.sh), DB home e nova instância (dbca -addInstance).
• Remover um node do cluster — Escolha se um servidor vai sair do cluster de forma definitiva (devolução, falha de hardware). A instância é removida, o DB home e o Grid home são desinstalados desse node e o node é excluído do cluster; os outros nodes permanecem ativos.
• Adicionar, alterar, mover ou remover um serviço — Escolha para definir o serviço ao qual a aplicação se conecta, alterar seu posicionamento (preferred/available) ou a configuração de failover (TAF/Application Continuity), ou mover um serviço em execução para outra instância. O banco permanece aberto.
• Alteração de SCAN, VIP, porta do listener ou interconnect — Escolha se o nome/IPs do SCAN, o VIP de um node, a porta do listener ou a rede privada (interconnect) vão mudar. A alteração do interconnect exige parar o cluster inteiro; as demais causam uma breve interrupção das conexões.
• Fazer backup de OCR e OLR e verificar os backups — Sem downtime: backup manual do OCR, backup do OLR em cada node e cópia dos backups para fora dos discos do cluster. Escolha antes de qualquer operação de risco, como patch, adição/remoção de node ou alteração de rede.
• OCR corrompido ou disk group CRS perdido: restaurar a partir do backup — Escolha se o ocrcheck indicar corrupção, se o CRSD não subir (erros PROT-/PROC-) ou se o disk group CRS tiver sido totalmente perdido. O cluster inteiro para; o OCR é restaurado a partir do backup em modo exclusivo e, se o disk group foi perdido, o disk group, os arquivos de voting e o spfile do ASM são recriados.
• O Clusterware não sobe em um node: OLR corrompido — Escolha se, com os outros nodes em funcionamento, crsctl start crs não consegue subir o OHASD em apenas um node e ocrcheck -local retorna erro de OLR. Somente esse node é afetado: o OLR é restaurado a partir do backup.
• Mover os arquivos de OCR e voting para outro disk group — Sem downtime: ocrconfig -add/-delete e crsctl replace votedisk. Escolha na troca de storage (SAN), ao aumentar a redundância do disk group CRS ou para gravar o OCR também em um segundo disk group.

Antes de começar

• Há acesso root em todos os nodes e login shell com os usuários grid/oracle (sudo -iu grid); os perfis de grid e oracle carregam o ambiente do Grid/DB home.
• Antes de começar, o cluster está saudável: CRS online em todos os nodes e nenhum recurso parado que deveria estar ativo. Caso contrário, resolva o problema antes com a verificação de saúde.
• A janela de manutenção e o registro de mudança foram aprovados; as equipes de aplicação foram avisadas; o blackout foi aberto no sistema de monitoramento. …Esta operação causa downtime total.…
• Há backup RMAN atualizado do banco e backups dos archive logs… (adicionar/remover instância altera o redo thread e a tablespace de undo)….
• Há um backup do OCR (…) guardado fora dos discos do cluster, ou se conhece o caminho do backup automático em um disk group íntegro. …Para o disk group CRS, há discos livres em número suficiente para a redundância …, visíveis em todos os nodes.…
• O novo node (…) tem a mesma versão de sistema operacional e o mesmo kernel dos nodes existentes; a preparação do sistema operacional da instalação do RAC e a preparação do storage foram feitas; os nomes das interfaces pública/privada são os mesmos; os LUNs compartilhados também foram apresentados a este node; o endereço VIP … está livre.
• O horário aproximado do incidente é conhecido. Se o AHF (TFA) estiver instalado, a coleta de diagnóstico é feita com um único comando; caso contrário, os logs são analisados manualmente.

Fases do guia

• Verificação de saúde do cluster — Verificar a stack do Clusterware em todos os nodes · Listar o estado dos recursos · Verificar o estado do banco, dos serviços e dos listeners · Verificar a integridade de OCR, voting e OLR · Verificar o ASM e a ocupação dos disk groups · Verificar a configuração de rede e a sincronização de horário …
• Parar o cluster inteiro — Registrar o estado antes de parar · Fazer backup manual do OCR (rede de segurança) · Parar todos os bancos de dados · Parar o Clusterware em todos os nodes · Parar o OHASD (…) · Executar a manutenção
• Iniciar o cluster inteiro — Iniciar o Clusterware (…) · Aguardar todos os nodes entrarem no cluster · Validar que os bancos de dados subiram · Comparar os recursos após a partida
• Preparação do novo node e verificações prévias — Registrar a configuração atual do cluster · Validar a preparação do sistema operacional do novo node · Adicionar o novo node ao /etc/hosts (…) · Estender a equivalência SSH do usuário grid ao novo node · Estender a equivalência SSH do usuário oracle ao novo node · Enviar o RPM cvuqdisk para o novo node …
• Estender o Grid Infrastructure ao novo node — Fazer backup manual do OCR (rede de segurança) · Estender o Grid home ao novo node (addnode.sh) · Executar o orainstRoot.sh (novo node) · Executar o root.sh (novo node) · Configurar o ambiente do grid no novo node · Validar o novo node no cluster
• DB home e nova instância — Estender o DB home ao novo node · Executar o root.sh do DB home (novo node) · Configurar o ambiente do oracle no novo node · Adicionar a nova instância (dbca -addInstance) · Adicionar a nova instância à configuração dos serviços · Validar a nova instância
• Após a adição do node — Fazer backup do OLR do novo node · Fazer backup do OCR da nova configuração · Atualizar o monitoramento, os backups e as rotinas de operação
• Remover a instância e o DB home — Esvaziar os serviços de … (a instância permanece aberta) · Remover a instância (dbca -deleteInstance) · Restringir o inventário do DB home ao node alvo (…) · Remover o DB home (deinstall -local) (…) · Atualizar o inventário do DB home nos nodes restantes
• Remover o Clusterware do node alvo — Verificar o estado de pin e, se necessário, desfazê-lo · Remover o Grid home (deinstall -local) (…) · Remover o node da definição do cluster · Validar a remoção e remover o VIP remanescente
• Após a remoção do node — Fazer backup do OCR da nova configuração · Limpar os resíduos e atualizar os registros
• Serviço: diagnóstico — Mostrar a configuração atual dos serviços
• Serviço: execução — Adicionar e iniciar o serviço · Alterar o posicionamento e as configurações do serviço · Iniciar o serviço conforme o novo posicionamento · Mover o serviço para outra instância · Parar e remover o serviço
• Serviço: validação — Validar que o serviço aparece no banco e no listener
• Alteração de rede: diagnóstico e rede de segurança — Registrar a configuração de rede atual · Fazer backup manual do OCR (rede de segurança) · Fazer backup do perfil GPnP (…)
• Alterar o nome / os IPs do SCAN — Validar a nova resolução do SCAN · Recriar os SCAN VIPs e listeners com os novos valores · Atualizar o remote_listener do banco · Validar a conexão pelo SCAN
• Backup de OCR e OLR — Mostrar os backups atuais do OCR e o local de backup · Fazer backup manual do OCR · Copiar o último backup manual para fora do cluster e validá-lo · Fazer backup manual do OLR (…) · Fazer backup também do spfile e do arquivo de senhas do ASM
• Restore do OCR: diagnóstico — Verificar o estado do OCR e do Clusterware · Verificar o disk group e os discos pelo lado do ASM · Validar o backup a ser restaurado
• Restore do OCR: execução — Parar o Clusterware (…) · Iniciar o Clusterware em modo exclusivo no node 1 · Abrir o ASM com um arquivo de parâmetros temporário (se o spfile foi perdido) · Recriar o disk group … · Restaurar o OCR a partir do backup · Recriar os arquivos de voting …
• Restore do OCR: validação e pós-operação — Validar o cluster e o OCR · Verificar as alterações posteriores ao backup · Fazer um novo backup do OCR e eliminar a causa raiz