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.
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
SPFILElocation 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:
- It disables Oracle RAC, Oracle RAC One Node, or Oracle Restart services.
- For Oracle RAC, it disables the cluster membership of all Oracle RAC database cluster member nodes in Oracle Clusterware.
- It shuts down the database, or all instances of the Oracle RAC database.
- 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.
- It updates the local instance to the new Oracle Database release binaries.
- It starts
srvctl upgrade databasefrom the local Oracle Database instance home, and upgrades the configuration of the Oracle Grid Infrastructure services to the new release.
- 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.
- 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.
- It 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.
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 3-2 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.