Benefits of AutoUpgrade Patching

• AutoUpgrade enables patching of all databases specified in the configuration file, in one operation.
• Resume capabilities are already included with AutoUpgrade.
• Restore capabilities are provided so that it is possible to roll back to the earlier release Oracle home:
  • Restore using the Guarantee Restore Point (GRP) generated during the patching process.
  • If a GRP is not present, then the Datapatch rollback functionality can also perform a restore. AutoUpgrade detects that a GRP does not exist, and automatically performs the restore using Datapatch. To enable a Datapatch rollback restore, set the restoration configuration option to no. For example: sales1.restoration=no.
• Oracle RAC management is provided automatically with AutoUpgrade.
• The error management reporting features of AutoUpgrade are extended to patching.
• The JSON status and progress reporting of AutoUpgrade are extended to patching.
• AutoUpgrade uses the Datapatch JSON status files to determine success or failure of each process, and reports those results to you at the completion of the process.

Features Supported for AutoUpgrade Patching

The following features are provided with AutoUpgrade Patching

• Patching of databases encrypted with Transparent Data Encryption (TDE).
• Hot Cloning/Relocate, which enables you to create PDBs from a Non-CDB, or from a PDB on a remote host.
• Proactive Fixups, which runs postfixups on the PDB as soon as the PDB is patched. Note that proactive fixups is currently not supported on Microsofts Windows.
• Multi-node patching and upgrades using Oracle Real Application Clusters (Oracle RAC), which enables AutoUpgrade to spread the workload across multiple nodes.
• Configuration management, by copying or merging the source Oracle home configuration files (tnsnames.ora, sqlnet.ora, and other files) to the target Oracle home.
• Analysis of the database before starting a patching procedure, to ensure patch readiness.
• Running fixups during production before patching, so that you reduce downtime. You can then use -mode upgrade to bypass running fixups and proceed directly to patching the database.
• Performing all patching tasks in Deploy mode, to achieve end-to-end patching.
• Enhanced reporting of the patching process, which enables you to diagnose errors more easily by using the datapatch_summary.log report.
• Datapatch log files found in the Datapatch summary JSON file are copied to the output file of the apply or rollback operational logs as follows:
  • Apply log format, where dbname is the name of the database: applydatapatchlogfiles#dbname.log
  • Rollback log format, where dbname is the name of the database: rollbackdatapatchlogfiles#dbname.log
• Datapatch output is logged to following operational logs:
  • Apply log format, where dbname is the name of the database: applyautoupgrade#dbname.log
  • Rollback log format, where dbname is the name of the database: rollbackautoupgrade#dbname.log
• Datapatch JSON output is logged to the following operational logs:
  • Apply log format, where dbname is the name of the database: applydatapatchsummary#dbname.log
  • Rollback log format, where dbname is the name of the database: rollbackdatapatchsummary#dbname.log
• Storage of all related patching log files produced by AutoUpgrade are stored in the dbupgrade directory.
• Standard Datapatch log files are stored in Oracle-base/cfgtoollogs/sqlpatch.
• Starting with AutoUpgrade 23.1, Patching is supported for single-instance databases on Microsoft Windows. It is not supported with Oracle Real Application Clusters (Oracle RAC).

Requirements and Restrictions for using AutoUpgrade Patching

• Downtime is required to use AutoUpgrade Patching:
  • After the patch operation is completed, the database is restarted.
  • Patching in normal mode enables the database to be available in the target home while the patching is proceeding.
  • Patching in upgrade mode requires the patching to be completed before the database is restarted in the target home.
  • During the patch operation, the CDB and PDBs are opened in normal mode after drain operations complete, and patching proceeds. However, rolling patching for Oracle Real Application Clusters is not supported at this time.
  • To enable PDBs to become available as soon as they are successfully patched, then ensure that you set the tune_settings option make_pdbs_avaliable to true in your configuration file. For example: sales3.tune_setting=proactive_fixups=true,make_pdbs_available=true
  • Because downtime is required, rolling upgrades of Oracle RAC are not supported at this time.
• AutoUpgrade can support a target RU or MRP that has additional patches applied. However, the source Oracle Database must be on an earlier RU or MRP than the target Oracle Database RU or MRP.
• AutoUpgrade does not move the listener to the new Oracle home. If needed, you must manually move the listener to the new Oracle home before you start AutoUpgrade.
• Installation and configuration of the target Oracle Database home must be complete before you can run RUs and MRPs on the target home using AutoUpgrade Patching. If a target RU is patched after it has been applied to the database, then you can no longer use AutoUpgrade Patching. Instead, you must use Datapatch to apply the updates.
• Performing rolling patches of Oracle Database (single-instance or Oracle RAC) is not supported. When you use AutoUpgrade Patching on a single-instance or Oracle RAC Oracle Database, AutoUpgrade's Oracle RAC management will shut down the database on all nodes.
• The target Oracle Database RU must be at least Oracle Database 19c, RU 19.3, or later releases. You cannot use AutoUpgrade Patching to perform RUs or MRPs to earlier Oracle Database releases.
• The effect of AutoUpgrade Patching on databases using Oracle Data Guard Physical Standby or Oracle Data Guard Logical Standby and Rolling Upgrade is the same as with using Datapatch. AutoUpgrade patching can be a part of the procedures.

  Note:

  Oracle recommends that you use Oracle Fleet Patching and Provisioning for databases deployed with Oracle Data Guard
• AutoUpgrade supports physically moving a database to different hardware. When the database is moved to a different target system, AutoUpgrade Patching can be used with the -mode upgrade option. However, when the database is moved to a different system, AutoUpgrade is unable to perform a restore of the database. In that case, the upgrade options for patching follow the same rules that apply for upgrading your database.
• In describing AutoUpgrade, this documentation generally refers to AutoUpgrade performing upgrades. When AutoUpgrade performs patching, patching is functionally similar to upgrades. Accordingly, references to upgrades in this guide or in diagrams are applicable to both upgrade and patching with AutoUpgrade Patching.
• Performing patching with AutoUpgrade Patching supports all AutoUpgrade -mode options except the preupgrade mode, which is only supported for upgrades.
• When patching or upgrading relocatable PDBs the configuration file cannot contain a mixture of patch clone PDBs and upgraded clone PDBs. The configuration for the clone PDBs must be either all upgrade clones, or all patched clones.

• AutoUpgrade patching supports only one catctl_options setting, -n number, where number is the number of processes to use for parallel operations. The catctl_options=-n setting enables you to control the total number of PDBs that you want to run concurrently during the patching process. The default is CPU_COUNT divided by 2. For example if CPU_COUNT is set to 24 then by default, 12 PDBs (Datapatch instances) can run concurrently during the patching process.

  To overwrite the default, add prefix.catctl_options to your configuration file with a value for the number of concurrent Datapatch instances you want to run. For example, to configure AutoUpgrade to run 6 PDBs (Datapatch instances) for the patch operations specified with the prefix sales, overriding the default, add the following line to your configuration file:

  sales.catctl_options=-n 6 

  Caution:

  For 19.13 and earlier release updates (RUs), Oracle strongly recommends that you set the catctl_options parameter for patching operations.

  With 19.13 and earlier RUs, the default value of SQL*Plus processors allocated to each Datapatch instance is CPU_COUNT multiplied by two (CPU_COUNT*2) processors for each Datapatch instance that AutoUpgrade starts. This default SQL*Plus processor allocation can quickly overload your system. To restrict system resources allocated to the patch operation, restricting how many Datapatch instances running simultaneously is the only option. For RU 19.13 and later, only one SQL*Plus process is started for each instance of Datapatch. This change enables AutoUpgrade to run more PDBs in parallel without consuming a large amount of system resources.

Security Characteristics of AutoUpgrade Patching

• The user running AutoUpgrade Patching must have the SYSDBA system privilege to log into the database, and run the patching operation. For an Oracle Real Application Clusters database, the user must be the owner of the source and target Oracle Database Oracle homes.
• The same security rules that apply for upgrades also apply with AutoUpgrade Patching.

Performance Characteristics of AutoUpgrade Patching

• The speed of deploying an RU or MRP depends on the number of PDBs in a CDB, and on changes in the release update or release update revision. If the number of changes from the source RU or MRP patches are relatively few, then deployment of patches should be quick. If the patches have many changes, then applying the patches requires more time.
• Because AutoUpgrade Patching includes a number of additional automated procedures, release update deployment is slightly slower than running Datapatch manually. For example, AutoUpgrade Patching automatically includes recompiling invalid objects, and configuring Oracle RAC management on the target system.

What Happens If AutoUpgrade Patching Rolls Back a Release Update

• AutoUpgrade uses the Guarantee Restore Point (GRP) generated during the patch process to roll back to the earlier release Oracle home.
• If no GRP is created, then AutoUpgrade automatically calls Datapatch to rollback the changes.

Processes Performed During AutoUpgrade Patching Stages

• GRP When restoration=YES is set in the AutoUpgrade configuration file, creates a Guaranteed Restore Point (GRP) in the database before applying the patches.
• PREACTIONS Runs any actions defined by the before_action parameter in the AutoUpgrade configuration file.
• PRECHECKS Runs the patching prechecks.
• PREFIXUPS Runs the fixups for any failing prechecks that have an automated fixup.
• EXTRACT Extracts the base image that will be used to create the new target Oracle home.
• DBTOOLS Installs a newer version of OPatch into the target Oracle home, if necessary.
• INSTALL Installs the new target Oracle home by running runInstaller in silent mode.
• ROOH (Optional) Installs the read-only Oracle home.
• OH_PATCHING Installs each of the necessary patches into the Oracle home.
• OPTIONS Synchronizes the binary options from the source ORACLE_HOME with the newly created target ORACLE_HOME. The supported options include the following:
  • ASM (Oracle Automatic Storage Management)
  • OLAP (Online Analytic Processing)
  • PART (Partitioning)
  • RAT (Oracle Real Application Testing)
  • UNIAUD (Unified Auditing)
• ROOTSH (Optional) Uses sudo to run the root.sh script from the target ORACLE_HOME as well as the orainstRoot.sh script when needed. If sudo requires a password, then running this script will fail, and reminders are given to the user to run these scripts after patching is complete.
• DB_PATCHING Runs a second copy of AutoUpgrade without the -patch option to move the database from the source Oracle home to the target Oracle home.
• POSTCHECKS Runs the patching postchecks.
• POSTFIXUPS Runs the fixups for any failing postchecks that have an automated fixup.
• UPGRMAN (Optional): Perform manual upgrades.
• POSTACTIONS Runs any actions defined by the after_action parameter in the AutoUpgrade configuration file.
• DROPGRP Drops the guaranteed restore point (GRP) if one was created by AutoUpgrade Patching, and if drop_grp_after_patching=YES is set in the AutoUpgrade configuration file.

AutoUpgrade Patching Status and Progress Files

Status and progress files are available in the directory that you specify in the AutoUpgrade configuration file with the configuration parameter global.global_log_dir. The location of these files are placed as follows, where global-log is the directory path specified by global.global_log_dir:

global_log/cfgtoollogs/patch/auto/status/

AutoUpgrade with the -patch parameter

AutoUpgrade patching using the -patch parameter performs out-of-place patch maintenance, which is Oracle's recommended method of patching. In out-of-place patching, AutoUpgrade creates a new target Oracle home using a base image of the database's initial release. It installs the patches that you specify, and then moves the source database to the new target Oracle home. In addition, you can use AutoUpgrade for patch maintenance for database releases where you are unable to use FPP or DBCA.

To use AutoUpgrade patching, your system should be consistent with the following requirements:

• Single-Instance Oracle Database
• Oracle Release 19c (19.3) or later release

In this scenario, you use AutoUpgrade Patching to download the patch, deploy the patch, and start the patching operation.

global.global_log_dir=/logs/patching
global.keystore=/secure/keystore
upg1.sid=DB19X
upg1.source_home=/databases/19x/dbhome_1
upg1.target_home=/databases/19x/dbhome_2
upg1.folder=/storage/patches
upg1.download=YES

global.global_log_dir=/logs/patching
upg1.sid=DB19X
upg1.source_home=/databases/19x/dbhome_1
upg1.target_home=/databases/19x/dbhome_2
upg1.folder=/storage/patches
upg1.patch=RU,OPATCH
upg1.download=NO

java -jar autoupgrade.jar -patch -config config.cfg -mode deploy

   AutoUpgrade Patching 24.1.240816 launched with default internal options
   Processing config file ...
   Loading AutoUpgrade Patching keystore

   -----------------------------
   Downloading files to /patches
   -----------------------------
   DATABASE RELEASE UPDATE 19.24.0.0.0
       File: p36582781_190000_Linux-x86-64.zip - VALIDATED

   DATAPUMP BUNDLE PATCH 19.24.0.0.0
       File: p36682332_1924000DBRU_Generic.zip - VALIDATED

   OJVM RELEASE UPDATE 19.24.0.0.0
       File: p36414915_190000_Linux-x86-64.zip - VALIDATED

   OPatch 12.2.0.1.43 for DB 19.0.0.0.0 (Jul 2024)
       File: p6880880_190000_Linux-x86-64.zip - VALIDATED
   -----------------------------

   +-----------------------------------------+
   | Starting AutoUpgrade Patching execution |
   +-----------------------------------------+
   1 Non-CDB(s) will be processed
   Type 'help' to list console commands
   patch> Job 100 completed
   ------------------- Final Summary --------------------
   Number of databases            [ 1 ]

   Jobs finished                  [1]
   Jobs failed                    [0]
   Jobs restored                  [0]
   Jobs pending                   [0]

   ---- Drop GRP at your convenience once you consider it is no longer needed ----
   Drop GRP from DB19X: drop restore point AU_PATCHING_9212_DB19X1919000


   Please check the summary report at:
   /logs/patching/cfgtoollogs/patch/auto/status/status.html
   /logs/patching/cfgtoollogs/patch/auto/status/status.log