Oracle Patch , , , ,

Identificando Problemas na Execução do Datapatch com Sanity Check

A aplicação de um patch no Oracle Database, seja um patch de correção de bug ou um Release Update (RU), pode ser dividido em duas etapas: a etapa de patch dos binários e a etapa de execução de scripts (.sql, .plb, etc), que realiza o patch do dicionário de dados (também chamados de patches SQL) do banco de dados.

A etapa de patch dos binários é executada pelo OPatch, que faz as devidas alterações nos binários e um relink dos executáveis afetados da Oracle Home. Já o patch do dicionário de dados é executado pelo Datapatch, e foi implementado no Oracle 12c. Aqui é importante ressaltar que nem todos os patches necessitam realizar o patch do dicionário de dados, ou seja, a execução do Datapatch pode não ocorrer em alguns casos.

O Datapatch, quando necessário, é executado após a reinicialização do banco de dados após a aplicação do patch dos binários. Quando executado faz uma comparação entre o conteúdo do inventário do OPatch e os registros do dicionário de dados do banco, e então executa o rollback de patches que constam no dicionário de dados, mas não estão no inventário do OPatch, e aplica os patches que constam no inventário do OPatch, mas não no dicionário de dados. Podemos acessar as informações sobre patches SQL instalados no banco através da view DBA_REGISTRY_SQLPATCH.

Quando as coisas dão errado

Dadas as devidas introduções, agora vamos abordar um cenário onde as coisas não saem conforme o esperado.

Suponhamos que temos um ambiente Oracle Single Instance, que tem um standby físico, e estaremos aplicando a Release Update 19.20. Devido à configuração Data Guard, vamos utilizar o método de aplicação de patch conhecido como Standby-First Patch Apply, que basicamente consiste em:

  1. Aplicar o patch dos binários no standby;
  2. Realizar o switchover;
  3. Aplicar o patch dos binários no novo standby (antigo primário);
  4. Executar o Datapatch;

Para este cenário, conseguimos executar os três primeiros passos, porém ao rodar o Datapatch temos o seguinte cenário:

$ ./datapatch -verbose
SQL Patching tool version 19.20.0.0.0 Production on Tue Sep 21 03:00:00 2024
Copyright (c) 2012, 2023, Oracle.  All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_16694_2024_09_21_03_00_00/sqlpatch_invocation.log

Connecting to database...OK
Gathering database info...done

Note:  Datapatch will only apply or rollback SQL fixes for PDBs
       that are in an open state, no patches will be applied to closed PDBs.
       Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
       (Doc ID 1585822.1)

Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of interim SQL patches:
Interim patch 35471995 (DELETE OBSOLETE DOES NOT REMOVE OLD BACKUPSET AFTER APPLYING DBRU 19.18.0):
  Binary registry: Installed
  PDB CDB$ROOT: Not installed
  PDB PDB$SEED: Not installed
  PDB PDB1: Not installed
  PDB PDB2: Not installed

Current state of release update SQL patches:
  Binary registry:
    19.20.0.0.0 Release_Update 230715022800: Installed
  PDB CDB$ROOT:
    Applied 19.11.0.0.0 Release_Update 210413004009 successfully on 12-MAY-21 12.29.26.523648 AM
  PDB PDB$SEED:
    Applied 19.11.0.0.0 Release_Update 210413004009 successfully on 12-MAY-21 12.29.31.653621 AM
  PDB PDB1:
    Applied 19.11.0.0.0 Release_Update 210413004009 successfully on 12-MAY-21 12.29.31.653621 AM
  PDB PDB2:
    Applied 19.11.0.0.0 Release_Update 210413004009 successfully on 12-MAY-21 12.29.31.653621 AM

Adding patches to installation queue and performing prereq checks...done
Installation queue:
  For the following PDBs: CDB$ROOT PDB$SEED PDB1 PDB2 
    No interim patches need to be rolled back
    Patch 35320081 (Database Release Update : 19.20.0.0.230718 (35320081)):
      Apply from 19.11.0.0.0 Release_Update 210413004009 to 19.20.0.0.0 Release_Update 230715022800
    The following interim patches will be applied:
      35471995 (DELETE OBSOLETE DOES NOT REMOVE OLD BACKUPSET AFTER APPLYING DBRU 19.18.0)

Unsupported named object type for bind parameter at /u01/app/oracle/product/19.3.0/dbhome_1/sqlpatch/sqlpatch.pm line 4965.

Please refer to MOS Note 1609718.1 and/or the invocation log
/u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_16694_2024_09_21_03_00_00/sqlpatch_invocation.log
for information on how to resolve the above errors.

SQL Patching tool complete on Tue Sep 21 03:00:00 2024

O Datapatch apresentou erros ao tentar a aplicação do SQL Patch na base. E agora?

Teste de sanidade

E não, quando falo em teste de sanidade, não me refiro à situação de estar com um problema na aplicação de um ambiente crítico às 4 da madrugada.

Nesse caso, para identificar o problema de maneira rápida e fácil, podemos utilizar uma das opções que o Datapatch nos oferece: o Sanity Check.

O sanity check realiza diversas verificações no ambiente e no banco de dados, analisando se o ambiente está pronto para receber o patch SQL, e nos mostra um report do que foi encontrado.

Para rodar o sanity check, usamos:

./datapatch -sanity_checks

Abaixo um exemplo da execução do sanity check:

./datapatch -sanity_checks
SQL Patching sanity checks version 19.20.0.0.0 on Tue 21 Sep 2024 03:00:00 AM -03
Copyright (c) 2021, 2024, Oracle.  All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sanity_checks_20240921_030000_24388/sanity_checks_20240921_030000_24388.log

Running checks
JSON report generated in /u01/app/oracle/cfgtoollogs/sqlpatch/sanity_checks_20240921_030000_24388/sqlpatch_sanity_checks_summary.json file
Checks completed. Printing report:

Check: DB Components status - OK (INFO)
  CDB$ROOT:
    COMPONENT,STATUS
    SDO,LOADING
  PDB$SEED:
    COMPONENT,STATUS
    SDO,LOADING
  PDB1:
    COMPONENT,STATUS
    SDO,LOADING
  PDB2:
    COMPONENT,STATUS
    SDO,LOADING

Check: PDB Violations - OK
Check: System invalid objects - OK
Check: Tablespace Status - OK
Check: Backup jobs - OK
Check: Temp Datafile exists - NOT OK (ERROR)
  Message: Temp datafile doesn't exist. It may cause issues when patching, please create it.
  PDB2:
    COUNT
    0
  PDBPROFILEMANAGER:
    COUNT
    0
Check: Temp Datafile Online - NOT OK (ERROR)
  Message: All temporary datafiles are offline or don't exist. Bring at least one online or create one for patching to succeed.
  PDB2:
    STATUS
    DEFAULT TEMPFILE(S) STATUS IS/ARE: OFFLINE OR NOT EXIST
  PDBPROFILEMANAGER:
    STATUS
    DEFAULT TEMPFILE(S) STATUS IS/ARE: OFFLINE OR NOT EXIST
Check: Datapump running - OK
Check: Container status - OK
Check: Encryption wallet - OK
Check: Dictionary statistics gathering - OK
Check: Scheduled Jobs - OK
Check: Golden Gate triggers - OK
Check: Logminer DDL triggers - OK
Check: Check sys public grants - OK
Check: Statistics gathering running - OK
Check: Optim dictionary upgrade parameter - OK
Check: Symlinks on oracle home path - OK
Check: Central Inventory - OK
Check: Queryable Inventory dba directories - OK
Check: Queryable Inventory locks - OK
Check: Queryable Inventory package - OK
Check: Queryable Inventory external table - OK
Check: Imperva processes - OK
Check: Guardium processes - OK
Check: Locale - OK

Refer to MOS Note and debug log
/u01/app/oracle/cfgtoollogs/sqlpatch/sanity_checks_20240921_030000_24388/sanity_checks_debug_20240921_030000_24388.log

SQL Patching sanity checks completed on Tue 21 Sep 2024 03:00:00 AM -03

Como podemos ver na saída do comando, temos vários checks sendo feitos, como validações no Oracle Inventory, status do container, PDB Violations, status de tablespaces, entre outros.

Neste caso em específico, a execução do datapatch estava sendo impactado devido à falta de temp files no ambiente primário. Esse problema é causado quando adicionamos temp files ao banco primário de uma configuração Data Guard, e o temp file não é adicionado manualmente ao standby (temp files não são replicados para o standby físico automaticamente, na versão 19c).

Como o report nos traz quais são os PDBs que não possuem temp files, podemos realizar a comparação entre os hosts primário e standby e realizar a adição dos temp files necessários. Uma vez resolvido os problemas apontados pelo sanity check, o datapatch executará normalmente.

Conclusão

Como a aplicação de patches em ambientes Oracle é uma tarefa do dia a dia do DBA, é essencial conhecer as ferramentas que estamos usando no processo e suas possibilidades. A ideia central desse artigo foi demontrar como essa funcionalidade do datapatch pode nos ajudar a economizar tempo no troubleshooting da aplicação dos patches SQL.

Um grande abraço a todos!

Tag

Publicar comentário