1. Database Upgrade Guide
  2. Using AutoUpgrade for Oracle Database Upgrades
  3. AutoUpgrade and Oracle Database Configuration Options

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

Parent topic: Using AutoUpgrade for Oracle Database Upgrades

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 4-4 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.

Parent topic: AutoUpgrade and Oracle Database Configuration Options

AutoUpgrade Process Flow for Oracle Grid Infrastructure Managed 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.

Note:

Choosing this upgrade option requires downtime of the clustered database while AutoUpgrade completes upgrades of database instances, and system configuration. If you use Oracle Enterprise Manager, then you must reconfigure it after the upgrade.

When AutoUpgrade detects that the Oracle Database is an Oracle Clusterware resource, it performs the following steps, in sequence:

  1. AutoUpgrade shuts down the database, or all instances of the Oracle RAC database.
  2. AutoUpgrade disables Oracle RAC, Oracle RAC One Node, or Oracle Restart services.
  3. If the Oracle Clusterware resource is Oracle RAC, then AutoUpgrade disables the cluster membership of all Oracle RAC database cluster member nodes in Oracle Clusterware.
  4. AutoUpgrade starts up the Oracle Database instance:
    • If the instance was an Oracle RAC cluster member, then it starts the local Oracle Database instance in upgrade mode, and with the cluster parameter set to FALSE.
    • If the instance was a single-instance Oracle Database, then it starts up the instance in upgrade mode.
  5. AutoUpgrade upgrades the local Oracle Database Oracle home binaries to the new Oracle Database release binaries.
  6. AutoUpgrade runs srvctl upgrade database from the local Oracle Database home, and for Oracle RAC, upgrades the configuration of the Oracle RAC services to the new release.
  7. AutoUpgrade 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. AutoUpgrade recreates the server parameter file (SPFILE) with the updated parameters, and the parameter options you previously set for your environment that are not affected by the release upgrade.
  9. If the Oracle Database was a member of an Oracle RAC cluster, then AutoUpgrade repeats this process on each other cluster member node, until all cluster members are upgraded and added back to the cluster, and the SPFILE is recreated on each cluster member node.
  10. AutoUpgrade 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.

Parent topic: AutoUpgrade and Oracle Database Configuration Options

Oracle RAC Requirements for Upgrade with AutoUpgrade

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

Requirements for Using AutoUpgrade with Oracle RAC Databases

You can use AutoUpgrade to perform upgrades of Oracle RAC or Oracle Real Application Clusters One Node 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.
  • Must meet the upgrade requirements to upgrade to the new Oracle Database release.
  • Must be registered and managed through the Server Control (SRVCTL) utility.

Required Tasks for Database Administrators to Use AutoUpgrade

As the database administrator, you must complete the following tasks:

  • Create an adequate backup strategy to prevent data loss from any problems resulting from the upgrade.
  • Configure Listener and Transparent Network Substrate (TNS) files, both for local tnsnames.ora and SCAN listeners, if needed.
  • Configure Oracle Wallet certificates and management (if needed), and configure for automatic login.

Related Topics

Parent topic: AutoUpgrade and Oracle Database Configuration Options

Preparing for Oracle RAC Upgrades Using AutoUpgrade

Review to find what information you must collect before the upgrade, and other upgrade preparation guidelines.

To use AutoUpgrade for Oracle Real Application Clusters (Oracle RAC) upgrades, in which Oracle Automatic Storage Management (Oracle ASM) is also upgraded, ensure that you collect information as needed before the upgrade, and be prepared to provide information during the upgrade.

Scope Limits for AutoUpgrade and Oracle RAC

  • AutoUpgrade does not perform upgrades of the Oracle Clusterware component of Oracle Grid Infrastructure. Before you start AutoUpgrade to upgrade your Oracle RAC database, you must first complete a successful Oracle Grid Infrastructure upgrade to the new release.

File System Preparation Before Upgrades Using AutoUpgrade

AutoUpgrade can identify the PFILE and SPFILE files shared on Oracle ASM. AutoUpgrade recreates the SPFILE as part of the upgrade. If you are sharing files on the cluster using Oracle ASM, then you do not need to complete this procedure.

Copy all of the network files (listener.ora, tnsnames.ora, sqlnet.ora, oranfstab, ldap.ora, ifile, and so on), keystores, and any other files located on file systems that are needed for the Oracle RAC cluster.

Parent topic: AutoUpgrade and Oracle Database Configuration Options

AutoUpgrade and Oracle Data Guard

Starting with Oracle Database 21c, AutoUpgrade can simplify the upgrade process for your primary and secondary databases configured for Oracle Data Guard.

Parent topic: AutoUpgrade and Oracle Database Configuration Options

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 no (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.

Parent topic: AutoUpgrade and Oracle Data Guard

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 (the default is no). 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

For Oracle Data Guard standby databases supported for direct upgrade, 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

For Oracle Database releases supported for direct upgrade with 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.

Note:

If the Data Guard Broker files are located outside of the Oracle home, then files are not found and copied.

Parent topic: AutoUpgrade and Oracle Data Guard

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 4-5 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 4-6 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

Related Topics

Parent topic: AutoUpgrade and Oracle Data Guard

How to Run AutoUpgrade Using the Fast Deploy Option

To minimize database downtime, you can upgrade your database by running AutoUpgrade using the Fast Deploy option.

Starting with AutoUpgrade 21.2, if your applications require minimal downtime, you can now upgrade with less downtime by using Fast Deploy. With the Fast Deploy option, you can run the prechecks and prefixups while the database is still online. After the fixups run on the source database, you can then run AutoUpgrade in Deploy mode, and skip the prechecks and prefixups stages, so that only the actual upgrade requires downtime.

Note:

Oracle recommends that you run AutoUpgrade using standard analyze and deploy checks. If you choose to use the Fast Deploy method, then be aware that there is a slight risk that running AutoUpgrade in the preupgrade Analyze mode may not detect an issue that can cause issues later. Assess that risk, and take precautions accordingly.

  1. Create your AutoUpgrade configuration file, providing information about your source and target systems, and your upgrade preferences. In the steps that follow, that file name is myconfig.cfg.

  2. Analyze the database using Analyze mode.

    – java -jar autoupgrade.jar -config myconfig.cfg -mode analyze

  3. Run the preupgrade fixups using Fixups mode.

    – java -jar autoupgrade.jar -config myconfig.cfg -mode fixups

  4. Upgrade the database using Upgrade mode.

    – java -jar autoupgrade.jar -config myconfig.cfg -mode upgrade

    As this command runs, the database experiences downtime.

Parent topic: AutoUpgrade and Oracle Database Configuration Options