Aplicação de Release Update (RU) no Oracle Database 19c

Release Update trimestral em um banco de dados 19c de instância única ou Oracle Restart (Grid Infrastructure + ASM): atualização do OPatch, verificações prévias de conflito e de espaço, backup do ORACLE_HOME e guaranteed restore point, opatch apply (opatchauto no Oracle Restart), OJVM RU opcional, datapatch, utlrp e verificação. Inclui o caminho out-of-place, que reduz o downtime (instalar em um novo home e trocar), e os passos de reversão (rollback) para cada caminho. Se RAC for selecionado, direciona para o guia de RAC para aplicação rolling nó a nó.

Topologia: 1 servidor (instância única ou Oracle Restart); para RAC, o guia de rolling patch

Antes de começar

• Arquivos de patch em …: …GI RU ……DB RU ………, OJVM RU ……, OPatch …… e, para o novo home, o arquivo de instalação base LINUX.X64_193000_db_home.zip…. Confira o número do patch na MOS e leia o README do RU do início ao fim (a versão mínima do OPatch, os problemas conhecidos e os passos adicionais estão no README).
• As versões compatíveis com o novo RU dos one-off patches recomendados na MOS 555.1 foram baixadas; sabe-se se os one-offs do home atual conflitam com o novo RU (um one-off em conflito exige uma nova versão preparada sobre o RU).
• O nível de patch atual e o estado do banco de dados estão registrados; todos os componentes VALID.
• Há espaço livre de pelo menos 15 GB no sistema de arquivos do ORACLE_HOME (o OPatch guarda os arquivos antigos em .patch_storage), o equivalente ao tamanho do home em …… e pelo menos 15 GB para o novo home….
• Para o restore point, o banco de dados está em modo ARCHIVELOG e há espaço livre suficiente na FRA (para os flashback logs gerados durante o patch).
• Existe um backup RMAN bem-sucedido e testado das últimas 24 horas.
• Janela de manutenção aprovada; equipes das aplicações cientes do downtime; monitoramento (EM/agent) em blackout; jobs agendados (cron, DBMS_SCHEDULER) parados.
• Se possível, foi feito um snapshot do servidor (VM).
• Se o banco de dados tiver standby Data Guard, a ordem do patch foi planejada: primeiro o home do standby recebe o patch (Standby-First, MOS 1265700.1), o primary recebe depois e o datapatch roda apenas no primary. Sem standby, este item é ignorado.
• Cluster saudável e instâncias abertas em todos os nós; os pré-requisitos detalhados do patch de RAC estão no guia Oracle RAC 19c rolling Release Update.
• Condições do Standby-First (MOS 1265700.1): o README do RU diz 'Data Guard Standby-First Installable' (os Release Updates têm essa característica; para one-offs, consulte o README de cada um)…; o OJVM RU do 19c não é Standby-First incondicionalmente (veja a nota abaixo)…; a diferença de patch entre primary e standby será mantida apenas durante a transição (curta); o datapatch rodará uma única vez, apenas no primary, depois que todos os standbys e o primary estiverem com o patch.… Os binários do novo RU estão instalados em todos os standbys deste primary e os standbys continuam o apply.…

Fases do guia

• RAC: validar o ambiente e passar ao guia de rolling patch — Validar o cluster e os nós · Aplicar o guia de rolling patch de RAC
• Verificações prévias — Verificar o nível de patch atual (DB home) · Verificar o nível de patch atual (Grid home) · Verificar o estado do banco de dados e o histórico de patches SQL · Verificar o papel e o estado do apply do standby (standby Data Guard) · Verificar o estado do Data Guard (primary) · Verificar que o novo RU está instalado nos standbys …
• Backup e ponto de retorno — Verificar os backups RMAN · Parar o Redo Apply (standby Data Guard) · Criar guaranteed restore point · Criar o guaranteed restore point (standby)
• Aplicação: in-place (opatch apply) — Parar o banco de dados e o listener · Fazer backup do ORACLE_HOME e do inventário · Aplicar o RU (opatch apply) · Aplicar o OJVM RU · Iniciar o listener e o banco de dados · Iniciar o listener e o standby em MOUNT e ligar o apply
• Aplicação: in-place (Oracle Restart, opatchauto) — Parar o Oracle Restart (para o backup) · Fazer backup do Grid home, do DB home e do inventário · Iniciar o Oracle Restart · Aplicar o GI RU (opatchauto) · Aplicar o OJVM RU ao DB home · Iniciar o Redo Apply (standby Data Guard)
• Aplicação: out-of-place (novo home) — Criar o diretório do novo home · Descompactar o software base e atualizar o OPatch · Preparar o response file do novo home · Instalar o novo home com o RU · Executar o root.sh (novo home) · Comparar os patches dos homes antigo e novo …
• Patch no nível SQL (datapatch) — Executar o datapatch · Recompilar os objetos inválidos (utlrp) · Não executar o datapatch no standby · Verificar que as alterações SQL chegam aos standbys
• Verificação — Verificar o nível de patch dos binários · Verificar o nível de patch dos binários (Grid home) · Verificar o registro de patches SQL e os objetos · Verificar no standby que o apply continua com os novos binários · Verificar o alert log · Executar os testes da aplicação …
• Encerramento — Remover o restore point · Remover o restore point (standby) · Fazer a limpeza
• Rollback (apenas se necessário) — Parar o banco de dados e o listener · Reverter os patches (opatch rollback) · Reverter os patches (opatchauto rollback) · Voltar ao home antigo · Iniciar o standby em MOUNT com os binários antigos e iniciar o apply · Iniciar e reverter os patches SQL (datapatch) …