Patching an Engineered System

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

Everyone in Oracle DBA world knows the key value of use an Engineered System, such as Exadata or Supercluster.

In a mission critical on premises database, as a DBA we need to consolidate many databases, plataform in different versions into an Engeneed system.

In a Engeneered System world we have different types of patch deployment that consists in a group of many other patches for differents versions of databases / applications / system /services. They are called Oracle Engineered Systems Quarterly Patch Deployment (QPD).

The key advantage of using QPD is stay with best practices patches that was recommeded by Oracle. The QDP are available for download every 4 months and if you have a contract, you can let Oracle apply for you via ACS / platinum contract. More information, you can see in https://www.oracle.com/assets/as-quarterly-patch-deployment-3042102.pdf.

Personal experiences on Engineered Systems(Exadata, Supercluster) patch apply I have some few experiences on patch apply in many enviroments even Exadata or Supercluster systems.

First, I always take an exachk. It’s extremely important to compare how health your environment are before apply. Always download the last available on MOS “Oracle Exadata Database Machine exachk or HealthCheck (Doc ID 1070954.1)”

Second, I recommend this note lecture:

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. in this notes there are some references to others Engeneered Systems. If you have on your enviroment, please take a look on MOS.

So before download, as every patch I extremaly recomments read the README of each patch before start (it seems obvious, but I knew many DBAs that don’t follow this secret rule) and follow the prechecks as Oracle recommendations such as space, check if there are any conflict with another patch, etc.

Some tips based on my personal experience - In most of cases, during patching some errors related by datapatch (on Database apply) occurs. Don’t be affraid and take a look at:

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)

- If you have a segregated environment, always apply patches on DEV or UAT environment.

Examples of database patch apply

=====

Don’t be affraid if you get an error. It’s happen with everyone:

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

=====

It’s so good when everything was work as design:

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

=====

See you soon! :-)

Release schedules dates document was updated!!

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

Continue Hanganalyze’s post: 12.2 on-prem available for download, we see that realease date document was update on MOS (742060.1).

Basically Oracle 12.2 was released for cloud (in March 2017 for premises) and 12.2 have been supported until 2021.

So, now it’s time to think about and plan to upgrade databases 11.2.0.4 and 12.1.0.2, of course if application was compatible too! :-)

Remember, now Oracle Recertification program follow the schedules date (more information you could see in this video).

Exadata on Café Com Cloud

Patching an Engineered System

Release schedules dates document was updated!!