Aplicando Patch em um Engineered System

Thu, 16 Aug 2018 16:54:11 -0300

Todo mundo no mundo de Oracle DBA sabe o valor chave de usar um Engineered System, tipo Exadata ou Supercluster.

Em um banco mission critical on-premises, como DBA a gente precisa consolidar muitos bancos, plataforma em diferentes versões dentro de um Engineered System.

No mundo Engineered System a gente tem diferentes tipos de patch deployment que consiste em um grupo de muitos outros patches pra diferentes versões de bancos / aplicações / sistema / serviços. Eles são chamados de Oracle Engineered Systems Quarterly Patch Deployment (QPD).

A vantagem chave de usar QPD é ficar com os best practices patches que foram recomendados pela Oracle. O QDP fica disponível pra download a cada 4 meses e se você tem um contrato, você pode deixar a Oracle aplicar pra você via contrato ACS / platinum. Mais informações, você pode ver em https://www.oracle.com/assets/as-quarterly-patch-deployment-3042102.pdf.

Experiências pessoais aplicando patch em Engineered Systems (Exadata, Supercluster) Eu tenho algumas experiências aplicando patch em muitos ambientes, sejam sistemas Exadata ou Supercluster.

Primeiro, eu sempre tiro um exachk. É extremamente importante comparar o quão saudável está seu ambiente antes de aplicar. Sempre baixa o último disponível no MOS “Oracle Exadata Database Machine exachk or HealthCheck (Doc ID 1070954.1)”

Segundo, eu recomendo a leitura dessas notas:

Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1)

Oracle SuperCluster Supported Software Versions - All Hardware Types (Doc ID 1567979.1)

PS. nessas notas tem algumas referências a outros Engineered Systems. Se você tem no seu ambiente, por favor dá uma olhada no MOS.

Então antes de baixar, como em todo patch eu recomendo extremamente ler o README de cada patch antes de começar (parece óbvio, mas eu conheço muitos DBAs que não seguem essa regra secreta) e seguir os prechecks como a Oracle recomenda, tipo espaço, checar se tem algum conflito com outro patch, etc.

Algumas dicas baseadas na minha experiência pessoal - Na maioria dos casos, durante o patching alguns erros relacionados com datapatch (no apply do banco) acontecem. Não fica com medo e dá uma olhada em:

Queryable Patch Inventory - Issues/Solutions for ORA-20001: Latest xml inventory is not loaded into table (Doc ID 1602089.1)

12.1 : Datapatch Fails with ERROR “KUP-04004,KUP-04017,KUP-04118,KUP-04095,ORA-29913”," fatal: libjli.so or libpicl.so.1: open failed" (Doc ID 2085653.1)

- Se você tem um ambiente segregado, sempre aplica patches em DEV ou UAT primeiro.

Exemplos de apply de patch no banco

=====

Não fica com medo se você tomar um erro. Acontece com todo mundo:

Log file for this invocation: /u01/app/grid/cfgtoollogs/sqlpatch/sqlpatch_2278_2018_08_16_14_39_41/sqlpatch_invocation.log

Connecting to database…OK 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

Queryable inventory could not determine the current opatch status. Execute ‘select dbms_sqlpatch.verify_queryable_inventory from dual’ and/or check the invocation log /u01/app/grid/cfgtoollogs/sqlpatch/sqlpatch_2278_2018_08_16_14_39_41/sqlpatch_invocation.log for the complete error. Prereq check failed, exiting without installing any patches.

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

SQL Patching tool complete on Thu Aug 16 14:39:59 2018

=====

É tão bom quando tudo funciona como planejado:

Log file for this invocation: /u01/app/grid/cfgtoollogs/sqlpatch/sqlpatch_23787_2018_08_16_14_47_57/sqlpatch_invocation.log

Current state of SQL patches: Bundle series DBBP: ID 180717 in the binary registry and not installed in any PDB

Adding patches to installation queue and performing prereq checks… Installation queue: For the following PDBs: CDB$ROOT PDB$SEED Nothing to roll back The following patches will be applied: 27547374 (DATABASE BUNDLE PATCH 12.1.0.2.180717)

Installing patches… Patch installation complete. Total patches installed: 2

Validating logfiles… Patch 27547374 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/app/grid/cfgtoollogs/sqlpatch/27547374/22329708/27547374_apply__MGMTDB_CDBROOT_2018Aug16_14_48_44.log (no errors) Patch 27547374 apply (pdb PDB$SEED): SUCCESS logfile: /u01/app/grid/cfgtoollogs/sqlpatch/27547374/22329708/27547374_apply__MGMTDB_PDBSEED_2018Aug16_14_52_35.log (no errors) SQL Patching tool complete on Thu Aug 16 14:55:29 2018

=====

Até breve! :-)

Documento de datas de release foi atualizado!!

Mon, 13 Mar 2017 18:33:13 -0300

Continuando o post do Hanganalyze: 12.2 on-prem disponível para download, vemos que o documento de data de release foi atualizado no MOS (742060.1).

Basicamente Oracle 12.2 foi lançado para cloud (em março de 2017 para on-premises) e 12.2 tem suporte até 2021.

Então agora é hora de pensar e planejar o upgrade dos bancos 11.2.0.4 e 12.1.0.2, claro que se a aplicação for compatível também! :-)

Lembrem que agora o programa de Recertificação da Oracle segue as datas de schedule (mais informação vocês podem ver nesse video).

My-Oracle-Support on Café Com Cloud

Aplicando Patch em um Engineered System

Documento de datas de release foi atualizado!!