AutoUpgrade and Oracle Database Configuration Options

When you run AutoUpgrade, it determines the type of database (Oracle Database, Oracle Database Standalone with Oracle ASM, or Oracle RAC), and performs an upgrade for that type of database

• Oracle RAC Requirements for Upgrade with AutoUpgrade
  To determine if AutoUpgrade can upgrade your Oracle Real Application Clusters (Oracle RAC) database, review the use case requirements.
• AutoUpgrade Process Flow for Oracle Grid Infrastructure Configurations
  When AutoUpgrade detects Oracle RAC, Oracle RAC One Node, or Oracle Restart, it proceeds to perform upgrade steps required for all Oracle RAC instances.
• Non-CDB to PDB Upgrade Guidelines and Examples
  Before conversion, back up your datafiles and database, and follow the guidelines for your source Oracle Database release.
• AutoUpgrade and Oracle Data Guard
  The AutoUpgrade utility that you download from My Oracle Support can simplify the upgrade process for your primary and secondary databases configured for Oracle Data Guard.

Oracle RAC Requirements for Upgrade with AutoUpgrade

To determine if AutoUpgrade can upgrade your Oracle Real Application Clusters (Oracle RAC) database, review the use case requirements.

Requirements for Using AutoUpgrade with Oracle RAC Databases

Starting with Oracle Database 19c, using AutoUpgrade 19.8 or later, you can use AutoUpgrade to perform upgrades of Oracle RAC systems. However, your system must meet all of the following requirements:

• Must be either a Linux or Unix-based system. Microsoft Windows systems are not supported.
• Use Oracle Automatic Storage Management (Oracle ASM) as its storage management system, with the SPFILE location placed on Oracle ASM.
• Meet the upgrade requirements to upgrade to the new Oracle Database release.

Note:

At the time of this release, Oracle RAC database upgrades from non-CDB to PDB deployments of Oracle RAC using AutoUpgrade are not supported.

AutoUpgrade Process Flow for Oracle Grid Infrastructure Configurations

When AutoUpgrade detects Oracle RAC, Oracle RAC One Node, or Oracle Restart, it proceeds to perform upgrade steps required for all Oracle RAC instances.

When you start AutoUpgrade, it detects when Oracle Database is configured with Oracle Grid Infrastructure, either as a cluster member node member in Oracle Real Application Clusters (Oracle RAC), or an Oracle RAC One Node configuration, or an Oracle Grid Infrastructure for a Standalone Server (Oracle Restart) configuration. When AutoUpgrade detects Oracle Grid Infrastructure, it performs the following steps, in sequence:

1. It disables Oracle RAC, Oracle RAC One Node, or Oracle Restart services.
2. For Oracle RAC, it disables the cluster membership of all Oracle RAC database cluster member nodes in Oracle Clusterware.
3. It shuts down the database, or all instances of the Oracle RAC database.
4. For Oracle RAC, it starts the local Oracle Database instance with the cluster parameter set to TRUE. For Oracle RAC One Node or Oracle Grid Infrastructure for a standalone server, it starts the local database instance.
5. It updates the local instance to the new Oracle Database release binaries.
6. It starts srvctl upgrade database from the local Oracle Database instance home, and upgrades the configuration of the Oracle Grid Infrastructure services to the new release.
7. It enables Oracle Grid Infrastructure services for the database, using srvctl enable database. For Oracle RAC, it adds the upgraded Oracle RAC database to the Oracle RAC cluster as a cluster member node.
8. It recreates the server parameter file (SPFILE) with the updated parameters, and the parameter options you previously set for your Oracle Grid Infrastructure environment not affected by the release update.
9. It starts up the Oracle Database. For Oracle RAC It starts all instances of Oracle Real Application Clusters on the cluster.

Note:

Before you start AutoUpgrade on an Oracle Grid Infrastructure for a standalone server (Oracle Restart, Oracle RAC One Node, or Oracle RAC Database, you must upgrade Oracle Grid Infrastructure to a release equal to or more recent than the Oracle Database release to which you are upgrading.

Non-CDB to PDB Upgrade Guidelines and Examples

Before conversion, back up your datafiles and database, and follow the guidelines for your source Oracle Database release.

To ensure that no data is lost during the conversion, Oracle strongly recommends that allow time in your upgrade plan to implement your backup strategy before you use AutoUpgrade to perform a non-CDB upgrade and conversion.

Guidelines for Upgrade Planning

The non-CDB-to-PDB conversion and upgrade process is not recoverable. To ensure a proper upgrade and conversion, and to reduce unexpected downtime, Oracle strongly recommends that you address any error conditions found during the analyze phase.

If you do not set the target_pdb_copy_option in your AutoUpgrade configuration file, then the database conversion uses the same file location and file names that are used with existing database files. To prevent potential data loss, ensure that your data is backed up, and consider your file placement plans before starting AutoUpgrade.

GRP and Upgrades from Non-CDB to Multitenant Architecture

• During the upgrade, AutoUpgrade creates a guaranteed restore point (GRP) that is available only in the context of the upgrade stage of the AutoUpgrade Deploy workflow. To ensure against any potential data loss, you must implement your backup strategy before starting AutoUpgrade.
• Database conversion from non-CDB to the multitenant architecture is performed during the AutoUpgrade Drain stage. After this stage is complete, the GRP that AutoUpgrade creates is removed, and it is not possible to use the AutoUpgrade restore command to restore the database. In the event that you require a recovery to the earlier non-CDB Oracle Database release, you must be prepared to recover the database manually.

Example 3-3 Upgrading and Converting a Non-CDB to Oracle Database 19c Using Multitenant Architecture

During the Deploy conversion and upgrade workflow, AutoUpgrade version 19.9 and later creates a GRP, and runs the Prefixup stage. If any part of the Deploy workflow up to the Prefixup stage completion fails, then AutoUpgrade can restore the database back to the GRP created at the start of the deployment.

However, after the Prefixup stage is complete, the upgraded database is plugged in to the target release Oracle Database container database (CDB) to complete conversion. As soon as the non-CDB is plugged into the CDB, the GRP is no longer valid, and is dropped.

If anything goes wrong during the plug-in, then AutoUpgrade cannot recover and restore the database. You must restore the database manually.

AutoUpgrade and Oracle Data Guard

The AutoUpgrade utility that you download from My Oracle Support can simplify the upgrade process for your primary and secondary databases configured for Oracle Data Guard.

• How AutoUpgrade Performs Oracle Data Guard Upgrades
  AutoUpgrade can detect Oracle Data Guard configurations, and defer shipping logs to standby databases configured for the primary database.
• Steps AutoUpgrade Completes for Oracle Data Guard Upgrades
  The steps that AutoUpgrade completes vary, depending on whether standby databases are managed manually, or through Data Guard Broker.
• Steps After the Primary Database is Upgraded
  For Oracle Data Guard upgrades, after you upgrade the primary database you must complete these procedures.

How AutoUpgrade Performs Oracle Data Guard Upgrades

AutoUpgrade can detect Oracle Data Guard configurations, and defer shipping logs to standby databases configured for the primary database.

AutoUpgrade automatically detects the presence of an Oracle Data Guard deployment, and whether that deployment is configured manually, or uses Data Guard Broker to manage and monitor Oracle Data Guard configurations.

When you set the parameter defer_standby_log_shipping to yes (the default) in the configuration file, AutoUpgrade can defer the log-shipping to configured standby databases, both when Oracle Data Guard is configured manually, and when Oracle Data Guard is configured through Data Guard Broker.

Preparation Before AutoUpgrade Upgrades of Databases with Oracle Data Guard

Before you begin the upgrade, to be prepared in case of a failure during the primary database upgrade, or in case the primary database must be reverted to the source Oracle home, ensure that your standby databases are protected and recoverable.

Steps AutoUpgrade Completes for Oracle Data Guard Upgrades

The steps that AutoUpgrade completes vary, depending on whether standby databases are managed manually, or through Data Guard Broker.

For Oracle Data Guard earlier release (source) databases where Oracle Data Guard is managed manually, or through Data Guard Broker, to manage log-shipping to standby databases, you can set defer_standby_log_shipping=yes in your AutoUpgrade configuration file. (This is the defaut value). However, the specific actions that AutoUpgrade takes vary, depending on how you manage standby databases.

Note:

For standby databases managed either manually or through Data Guard Broker, after the upgrade completes, you must run ENABLE DATABASE database-name; on each of the standby archive log destinations after successful upgrade on the primary database, and perform all steps needed to have standby databases upgraded through the redo log apply.

Manually Managed Oracle Data Guard Standby Databases

When it detects an Oracle Data Guard configuration, AutoUpgrade places in DEFER mode all VALID and ENABLED standby archive log destinations before starting the upgrade process for both manually managed and Data Guard Broker managed standby databases.

Data Guard Broker-Managed Oracle Data Guard Standby Databases

When the source Oracle Database release is Oracle Database 12c Release 1 (12.1) or later, and there are Oracle Data Guard standby databases that are managed using Data Guard Broker, AutoUpgrade completes the following actions:

• The primary database state is set to TRANSPORT-OFF to all standby databases configured with Data Guard Broker
• The Data Guard Broker files are copied from the source Oracle home to the target Oracle home.

When the source Oracle Database release is earlier than Oracle Database 12c Release 1 (12.1), and there are Oracle Data Guard standby databases that are managed using Data Guard Broker, AutoUpgrade completes the following actions:

• DISABLE FAST_START FAILOVER
• DISABLE CONFIGURATION
• SET DG_BROKER_START=FALSE
• SET TRANPORT OFF for all standby databases configured with Data Guard broker.
• Copies the Data Guard broker files from the source Oracle home to target Oracle home.

Note:

For all source Oracle Database releases, if the Data Guard Broker files are located outside of the Oracle home, then files are not found and copied.

Steps After the Primary Database is Upgraded

For Oracle Data Guard upgrades, after you upgrade the primary database you must complete these procedures.

• Ensure that redo transport is enabled on the primary database, so that the upgrade is applied to the standby databases.
• Check that the archives are applied, and that there is a minimal gap. Oracle recommends that Apply Lag and Transport Lag is not bigger than 5 minutes.

Example 3-4 Checking Redo Transport Service Status

To check the status of the redo transport services on the primary database, use the Data Guard broker command-line interface (DGMGRL) LogXptStatus monitorable property. For example:

DGMGRL> SHOW DATABASE 'sales1' 'LogXptStatus' ;

Example 3-5 Checking Apply Lag and Transport Lag

To check that the archives are applied, and verify that Apply Lag and Transport Lag is not bigger than 5 minutes, log in to the primary database and submit a SQL query similar to the following:

[oracle]$ sqlplus / as sysdba
SYS@sales1>

SET LINESIZE 200
COL VALUE FOR A30
SELECT NAME,VALUE,TIME_COMPUTED,DATUM_TIME FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag';

The result should be similar to this output:

NAME VALUE TIME_COMPUTED DATUM_TIME
-------------- -------------- --------------------- --------------------
transport lag +00 00:00:00 timestamp timestamp
apply lag +00 00:01:07 timestamp timestamp