Oracle RAC 19c: Release Update rolling (opatchauto)

Aplica a Release Update trimestral do GI a um cluster RAC 19c de 2–8 nós em execução, sem downtime (rolling): atualização do OPatch, verificação de conflitos com opatchauto analyze, backup do OCR e ponto de retorno, aplicação nó a nó com realocação dos serviços, conclusão do datapatch em um único nó, verificação e rollback quando necessário. Para instância única e Oracle Restart, use o guia "Aplicar uma Release Update (RU) do Oracle Database 19c"; a RU do OJVM não é rolling e exige uma parada separada.

Topologia: RAC 19c existente de 2–8 nós

Antes de começar

• O README da RU foi lido: versão mínima do OPatch, problemas conhecidos, one-offs pré-requisitos, o patch separado do OJVM (a RU do OJVM não é rolling e exige uma parada separada). No My Oracle Support, "Oracle Database 19c Important Recommended One-off Patches" (Doc ID 555.1) e o guia de download de RU (Doc ID 2118136.2) foram verificados para esta RU.
• Em todos os nós existem … e p6880880_190000_Linux-x86-64.zip (OPatch atual) em …; os arquivos foram verificados com os valores SHA-256 do MOS.
• O sistema de arquivos dos GI e DB homes tem pelo menos 20 GB livres (confira o valor no README) e /tmp tem pelo menos 1 GB livre. …Há espaço em … para os backups dos homes.…
• O cluster está saudável: CRS online em todos os nós, nenhum recurso em OFFLINE, todas as instâncias abertas. Enquanto um nó estiver parado durante o patch, os demais têm capacidade para assumir toda a carga.
• Os serviços da aplicação estão definidos de forma que, em cada nó, possam passar para outra instância (preferred/available ou uniform), e as aplicações se conectam via SCAN + nome do serviço (com FAN/AC, as sessões são movidas sem interrupção).
• O banco de dados tem um backup RMAN atual e os archived logs; foi feito um backup do OCR. A janela de manutenção está aprovada; um blackout foi ativado no Enterprise Manager.
• Nenhuma outra operação opatch/opatchauto está em execução; não há arquivos de lock nos homes.
• Se o banco de dados tiver um standby Data Guard, o cluster (ou servidor) standby recebe o patch primeiro (Standby-First, MOS 1265700.1); o primary recebe o patch depois, com este guia, e o datapatch é executado somente no primary.

Fases do guia

• Verificações prévias — Registrar o nível de patch atual (Clusterware) · Listar os patches dos homes (…) · Registrar o histórico de SQL patches e os objetos inválidos
• Preparação: RU, OPatch e análise — Descompactar a RU (…) · Atualizar o OPatch no GI home (…) · Atualizar o OPatch no DB home (…) · Executar a análise de conflitos e pré-requisitos (…)
• Backup e ponto de retorno — Fazer um backup manual do OCR · Criar um guaranteed restore point · Fazer backup dos GI e DB homes (…)
• Verificação e conclusão — Garantir que as PDBs estejam abertas · Executar o datapatch somente em um nó · Verificar o registro de SQL patches · Recompilar os objetos inválidos (se necessário) · Verificar o estado de patch do cluster · Retornar os serviços à distribuição preferida …
• Rollback (somente se necessário) — Rollback: executar o opatchauto rollback (…) · Rollback: executar o datapatch (um único nó) · Rollback: verificar o resultado · Último recurso: retornar o banco de dados ao restore point