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
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
restorecommand 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.
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:
- AutoUpgrade shuts down the database, or all instances of the Oracle RAC database.
- AutoUpgrade disables Oracle RAC, Oracle RAC One Node, or Oracle Restart services.
- 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.
- 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
- If the instance was a single-instance Oracle Database, then it starts up the instance in upgrade mode.
- 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
- AutoUpgrade upgrades the local Oracle Database Oracle home binaries to the new Oracle Database release binaries.
- AutoUpgrade runs
srvctl upgrade databasefrom the local Oracle Database home, and for Oracle RAC, upgrades the configuration of the Oracle RAC services to the new release.
- AutoUpgrade enables Oracle Grid Infrastructure services for the
srvctl enable database. For Oracle RAC, it adds the upgraded Oracle RAC database to the Oracle RAC cluster as a cluster member node.
- 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.
- 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.
- AutoUpgrade starts up the Oracle Database. For Oracle RAC, it starts all instances of Oracle Real Application Clusters on the cluster.
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.
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
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.oraand SCAN listeners, if needed.
- Configure Oracle Wallet certificates and management (if needed), and configure for automatic login.
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
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 (
and so on), keystores, and any other files located on file systems that are needed
for the Oracle RAC cluster.
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.
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
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.
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
DEFER mode all
ENABLED standby archive log destinations before starting the
upgrade process for both manually managed and Data Guard Broker managed standby
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-OFFto 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.
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 (
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