Oracle Cloud Infrastructure Documentation

Patch and Update an Oracle Exadata Database Service on Exascale Infrastructure System

Parent topic: How-to Guides

User-Managed Maintenance Updates

Maintaining a secure Oracle Exadata Database Service on Exascale Infrastructure instance in the best working order requires you to perform regular maintanance.

The following tasks are required

  • Patching the Oracle Grid Infrastructure and Oracle Database software on the VM Cluster virtual machines. For information and instructions, see Patching and Updating VM Cluster’s GI and Database Homes.
  • Updating the operating system on the VM Cluster virtual machines. See Updating an Exadata Cloud VM Cluster Operating System for information and instructions.

Patching and Updating an Oracle Exadata Database Service on Exascale Infrastructure System

Learn how to perform patching operations on Exadata database virtual machines and Database Homes.

For more guidance on achieving continuous service during patching operations, see the Application Checklist for Continuous Service for MAA Solutions white paper.

Related Topics

Parent topic: Patch and Update an Oracle Exadata Database Service on Exascale Infrastructure System

Patching and Updating VM Cluster’s GI and Database Homes

Learn how to perform patching operations on Oracle Exadata Database Service on Exascale Infrastructure resources by using the Console or API.

Note

Oracle recommends patching databases by moving them to a Database Home that uses the target patching level. See To patch a database by moving it to another Database Home for instructions on this method of database patching.

Parent topic: Patching and Updating an Oracle Exadata Database Service on Exascale Infrastructure System

About Patching and Updating VM Cluster's GI and Database Homes

Learn about types of patching performed on an Oracle Exadata Database Service on Exascale Infrastructure instances and how to complete the patching operations.

Parent topic: Patching and Updating VM Cluster’s GI and Database Homes

Oracle Grid Infrastructure (GI) Patching

Patching an Oracle Exadata Database Service on Exascale Infrastructure instance updates the components on all the compute nodes in the instance. A VM cluster or DB system patch updates the Oracle Grid Infrastructure (GI) on the resource.

Note

You patch the Grid Infrastructure on the cloud VM cluster resource. VM clusters are used by the databases, which can be easily migrated to the new Grid Infrastructure resource with no system downtime.

Database Home Patching

A Database Home patch updates the Oracle Database software shared by the databases in that home.

Thus, you patch a database by either of the following methods:

  • Move the database to a Database Home that has the correct patch version. This affects only the database being moved.
  • Patching the Database Home the database is currently in. This affects all databases located in the Database Home being patched.

When patching a Database Home, you can use an Oracle-provided database software image to apply a generally-available Oracle Database software update, or you can use a custom database software image created by your organization to apply a specific set of patches required by your database. See Oracle Database Software Images for more information on creating and using custom images.

For instructions on performing patching operations, see To patch the Oracle Database software in a Database Home (cloud VM cluster). For Oracle Exadata Database Service on Exascale Infrastructure instances using the older DB system resource model, see To patch the Oracle Database software in a Database Home (DB system).

To Upgrade the Oracle Grid Infrastructure of a Cloud VM Cluster

Procedure for upgrading the Oracle Grid Infrastructure of a Cloud VM Cluster.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.
  3. Click Exadata VM Clusters.
  4. In the list of cloud VM clusters, click the name of the cluster you want to patch to display the cluster details.
  5. Under Version, click the View Patches link beside the Updates Available field.
  6. Click Updates to view the list of available patches and upgrades.
  7. Click the Actions icon (three dots) at the end of the row listing the Oracle Grid Infrastructure (GI) upgrade, then click Upgrade Grid Infrastructure.
  8. In the Upgrade Grid Infrastructure dialog, confirm you want to upgrade the GI by clicking Upgrade Grid Infrastructure. If you haven't run a precheck, you have the option of clicking Run Precheck in this dialog to precheck your cloud VM cluster prior to the upgrade.
Best Practices for Patching Oracle Exadata Database Service on Exascale Infrastructure Components

Consider the following best practices:

  • Back up your databases before you apply any patches. For information about backing up the databases, see Managing Exadata Database Backups .
  • Patch a VM cluster or an Exadata DB system before you patch the Databases Homes and databases on that resource.
  • Before you apply any patch, run the precheck operation to ensure your VM cluster, Exadata DB system, or Database Home meets the requirements for that patch.
  • To patch a database to a version other than the database version of the current home, move the database to a Database Home running the target version. This technique requires less downtime, and enables you to easily roll back the database to the previous version by moving it back to the old Database Home.
  • For the Oracle Database and Oracle Grid Infrastructure major version releases available in Oracle Cloud Infrastructure, patches are provided for the current version, and the three most recent older versions (N through N - 3).

Parent topic: About Patching and Updating VM Cluster's GI and Database Homes

dbaascli database runDatapatch

To patch an Oracle Database, use the dbaascli database runDatapatch command.

Prerequisites

  • Before performing a runDatapatch operation, ensure that all of the database instances associated with the database are up and running.

  • Run the command as the root user.

Syntax

dbaascli database runDatapatch --dbname
[--resume]
    [--sessionID]
[--skipPdbs | --pdbs]
[--executePrereqs]
[--patchList]
[--skipClosedPdbs]
[--rollback]

Where:

  • --dbname specifies the name of the database
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --skipPdbs skips running the datapatch on a specified comma-delimited list of PDBs. For example: pdb1,pdb2...
  • --pdbs runs the datapatch only on a specified comma-delimited list of PDBs. For example: pdb1,pdb2...
  • --executePrereqs runs prerequisite checks
  • --patchList applies or rolls back the specified comma-delimited list of patches. For example: patch1,patch2...
  • --skipClosedPdbs skips running the datapatch on closed PDBs
  • --rollback rolls back the patches applied 
dbaascli database runDatapatch --dbname db19
Customer-Managed Keys in Oracle Exadata Database Service on Exascale Infrastructure

Customer-managed keys for Oracle Exadata Database Service on Exascale Infrastructure is a feature of Oracle Cloud Infrastructure (OCI) Vault service that enables you to encrypt your data using encryption keys that you control.

The OCI Vault service provides you with centralized key management capabilities that are highly available and durable. This key-management solution also offers secure key storage using isolated partitions (and a lower-cost shared partition option) in FIPS 140-2 Level 3-certified hardware security modules, and integration with select Oracle Cloud Infrastructure services. Use customer-managed keys when you need security governance, regulatory compliance, and homogenous encryption of data, while centrally managing, storing, and monitoring the life cycle of the keys you use to protect your data.

You can do the following:

  • Enable customer-managed keys when you create databases in Oracle Exadata Database Service on Exascale Infrastructure
  • Switch from Oracle-managed keys to customer-managed keys
  • Rotate your keys to maintain security compliance

Requirements

To enable management of customer-managed encryption keys, you must create a policy in the tenancy that allows a particular dynamic group to do so, similar to the following: allow dynamic-group dynamic_group_name to manage keys in tenancy.

Another policy is needed if the Vault being used by the customer is replicated (https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/replicatingvaults.htm). For vaults that are replicated, this policy is needed: allow dynamic-group dynamic_group_name to read vaults in tenancy

Limitations

To enable Oracle Data Guard on Oracle Exadata Database Service on Exascale Infrastructure databases that use customer-managed keys, the primary and standby databases must be in the same realm .

Related Topics

dbaascli database addInstance

To add the database instance on the specified node, use the dbaascli database addInstance command.

Prerequisite

  • Run the command as the root user.

Syntax

dbaascli database addInstance --dbname <value> --node <value> [--newNodeSID <value>]
Where:
  • --dbname specifies Oracle Database name
  • --node specifies the node name for the database instance
    • --newNodeSID specifies SID for the instance to add in the new node
dbaascli database convertToPDB

To convert the specified non-CDB database to PDB, use the dbaascli database convertToPDB command.

Syntax

dbaascli database convertToPDB --dbname <value> [--cdbName <value>] [--executePrereqs]
        {
            [--copyDatafiles [--keepSourceDB]]|[backupPrepared]
        }
        [--targetPDBName <value>] [--waitForCompletion <value>] [--resume [--sessionID <value>]]
Where:
  • --dbname specifies the name of Oracle Database
  • --cdbName specifies the name of the target CDB in which the PDB will be created. If the CDB does not exist, then it will be created in the same Oracle home as the source non-CDB
  • --executePrereqs specifies to run only the pre-conversion checks
  • --copyDatafiles specifies to create a new copy of the data files instead of using the ones from the source database

    --keepSourceDB - to preserve the source database after completing the operation.

  • --backupPrepared - flag to acknowledge that a proper database backup is in place for the non CDB prior to performing the conversion to PDB.
  • --backupPrepared flag to acknowledge that a proper database backup is in place for the non-CDB prior to performing the conversion to PDB
  • --targetPDBName specifies the name of the PDB that will be created as part of the operation
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true|false
  • --resume specifies to resume the previous execution
    • --sessionID specifies to resume a specific session ID

Example 5-2 dbaascli database convertToPDB

To run pre-conversion prechecks:
dbaascli database convertToPDB --dbname ndb19 --cdbname cdb19 --backupPrepared --executePrereqs
To run a full conversion with a copy of the data files from the non-CDB:
dbaascli database convertToPDB --dbname tst19 --cdbname cdb19 --copyDatafiles
dbaascli database getDetails

This command shows the detailed information of a given database e.g. dbname, node information, pluggable databases information etc.

Prerequisites

Run the command as the root user or the oracle user

Syntax

dbaascli database getDetails --dbname <value>
Where :
  • --dbname - Oracle database name.
dbaascli database modifyParameters

To modify or reset initialization parameters for an Oracle Database, use the dbaascli database modifyParameters command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli database modifyParameters --dbname <value> 
{
--setParameters <values>[--instance <value>] [--backupPrepared] [--allowBounce]|
--resetParameters <values> [--instance <value>] [--backupPrepared] [--allowBounce]
}
--responseFile
[--backupPrepared]
[--instance]
[--allowBounce]
[--waitForCompletion]
Where:
  • --dbname specifies the name of the database.
  • --setParameters specifies a comma-delimited list of parameters to modify with new values. For example: parameter1=valueA,parameter2=valueB, and so on. For blank values use parameter1=valueA,parameter2='',etc.
  • --resetParameters specifies a comma-delimited list of parameters to be reset to their corresponding default values. For example, parameter1,parameter2, and so on.
  • --instance specifies the name of the instance on which the parameters will be processed. If not specified, then the operation will be performed at the database level.
  • --backupPrepared acknowledges that a proper database backup is in place prior to modifying critical or sensitive parameters.
  • --allowBounce grants permission to bounce the database in order to reflect the changes on applicable static parameters.
  • --waitForCompletion specify false to run the operation in background. Valid values : true|false.]

Example 5-3 dbaascli database modifyParameters

dbaascli database modifyParameters --dbname dbname --setParameters "log_archive_dest_state_17=ENABLE"
dbaascli database upgrade

To upgrade an Oracle Database, use the dbaascli database upgrade command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli database upgrade --dbname <value> 
{--targetHome <value> | --targetHomeName <value>}
{ [--executePrereqs | --postUpgrade | --rollback]}
{[--standBy | --allStandbyPrepared]}
{[--upgradeOptions <value>]  | [--standBy]}
[--removeGRP]
[--increaseCompatibleParameter]
[--resume [--sessionID <value>]]
[--waitForCompletion <value>]
Where:
  • --dbname (mandatory) specifies the name of the database.
  • --targetHome specifies the target Oracle home location
  • --targetHomeName specifies the name of the target Oracle Database home
  • --standBy use this option to upgrade standby databases in Data Guard configurations
  • --allStandbyPrepared required for Data Guard configured primary databases. Flags to acknowledge that all the required operations are performed on the standby databases prior to upgrading primary database
  • --removeGRP automatically removes the Guaranteed Restore Point (GRP) backup only if the database upgrade was successful
  • --increaseCompatibleParameter automatically increases the compatible parameter as part of the database upgrade. The parameter will get increased only if the database upgrade was successful
  • --executePrereqs runs only the preupgrade checks
  • --postUpgrade use this option if postupgrade fails and needs to rerun the postupgrade steps
  • --rollback reverts an Oracle Database to its original Oracle home
  • --upgradeOptions use this option to pass DBUA-specific arguments to perform the Oracle Database upgrade. Refer to the corresponding Oracle documentation for the supported arguments and options.

    --standby

  • --resume to resume the previous execution
  • --sessionID to resume a specific session id.
  • --waitForCompletion specify false to run the operation in background. Valid values : true|false.

Example 5-4 dbaascli database upgrade pre-upgrade requisite checks

dbaascli database upgrade --dbbname dbname --targetHome Target Oracle home location --executePrereqs
Prerequisites for Patching and Updating an VM Cluster

The Oracle Exadata Database Service on Exascale Infrastructure instance requires access to the Oracle Cloud Infrastructure Object Storage service, including connectivity to the applicable Swift endpoint for Object Storage

Oracle recommends using a service gateway with the VCN to enable this access. For more information, see these topics:
Note

Ensure that the following conditions are met to avoid patching failures:
  • The /u01 directory on the database host file system has at least 15 GB of free space for the execution of patching processes.
  • The Oracle Clusterware is up and running on the VM cluster.
  • All nodes of the VM cluster are up and running.
Using the Console to Patch and Update Exadata Database Service on Exascale Infrastructure VM Clusters

You can use the Console to view the history of patch operations on Oracle Exadata Database Service on Exascale InfrastructureOracle Exadata Database Service on Exascale Infrastructure VM clusters apply patches, and monitor the status of patch operations.

Parent topic: Patching and Updating VM Cluster’s GI and Database Homes

To patch the Oracle Grid Infrastructure on an Exadata cloud VM cluster

How to apply patches and monitor the status of patch operations on cloud VM clusters.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.
  3. Click Exadata VM Clusters.
  4. In the list of cloud VM clusters, click the name of the cluster you want to patch to display the cluster details.
  5. Under Version, click the View Patches link beside the Updates Availablefield.
  6. Review the list of available patches for the cloud VM cluster.
  7. Click the Actions menu for the patch you are interested in, and then click one of the following actions:

    • Run Precheck: Check for any prerequisites to make sure that the patch can be successfully applied.

    • Update Grid Infrastructure: Applies the selected patch. Oracle highly recommends that you run the precheck operation for a patch before you apply it.

  8. Confirm when prompted.
The patch list displays the status of the operation. While a patch is being applied, the patch's status displays as Patching and the cloud VM cluster's status displays as Updating. Lifecycle operations on the cluster and its resources might be temporarily unavailable. If patching completes successfully, the patch's status changes to Applied and the status of the cluster changes to Available. You can view more details about an individual patch operation by clicking Update History.

To patch the Oracle Database software in a Database Home

Note

This patching procedure updates the Oracle Database software for all databases located in the Database Home. To patch an individual database, you can move a database to another Database home using the Oracle Database software configuration that you want to have.
  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.
  3. Click Exadata VM Clusters.
  4. In the list of cloud VM clusters, click the name of the cluster you want to patch to display the cluster details.
  5. Under Resources, click Database Homes.
  6. Click the name of the Database Home you want to patch to display the Database Home details.
  7. Under Database Software Version, locate the Latest Patch Available field and click View.
  8. Review the available patches for the Database Home. You can choose to patch using an Oracle-provided software image or a custom software image. Oracle-provide images are generally available release updates. Custom software images are created by your organization with a specified set of patches. See Oracle Database Software Images for information on creating custom software images. The image you use to patch must be based on either the latest version of the Oracle Database software release or one of the three prior versions of the release.

  9. Click the Actions menu at the end of the table row that lists the patch you are interested in, and then click one of the following actions:

    • Precheck: Check for any prerequisites to make sure that the patch can be successfully applied.
    • Apply: Applies the selected patch. Oracle highly recommends that you run the precheck operation for a patch before you apply it.

  10. Confirm when prompted.

    The patch list displays the status of the operation. While a patch is being applied, the status of the patch displays as Patching and the status of the Database Home and the databases in it display as Updating. During the operation, each database in the home is stopped and then restarted. If patching completes successfully, the patch's status changes to Applied and the Database Home's status changes to Available. You can view more details about an individual patch operation by clicking Update History.

To patch individual Oracle Databases in Oracle Exadata Database Service on Exascale Infrastructure

You can patch a single Oracle Database in your Oracle Exadata Database Service on Exascale Infrastructure by moving it to another Database Home.

You can move a database to any Database Home that meets at either of the following criteria:

  • The target Database Home uses the same Oracle Database software version (including patch updates) as the source Database Home
  • The target Database Home is based on either the latest version of the Oracle Database software release used by the database, or one of the three prior versions of the release

Moving a database to a new Database Home brings the database up to the patch level of the target Database Home.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.
  3. Navigate to the database you want to move.:

    Under Oracle Exadata Database Service on Exascale Infrastructure, click Exadata VM Clusters. In the list of VM clusters, click the name of the VM cluster that contains the database you wan to move.

  4. Click More Actions, and then click Move to Another Home.
  5. Select the target Database Home.
  6. Click Move Database.

  7. Confirm the move operation.

    The database is moved in a rolling fashion. The database instance will be stopped, node by node, in the current home and then restarted in the destination home. While the database is being moved, the Database Home status displays as Moving Database. When the operation completes, the Database Home is updated with the current home. Datapatch is run automatically, as part of the database move, to complete post-patch SQL actions for all patches, including one-offs, on the new Database Home. If the database move operation is unsuccessful, then the status of the database displays as Failed, and the Database Home field provides information about the reason for the failure.

Viewing Patch History of Exadata Database Service on Exascale Infrastructure

Each patch history entry represents an attempted patch operation and indicates whether the operation was successful or failed. You can retry a failed patch operation. Repeating an operation results in a new patch history entry.

You can view patch history by navigating to the VM Cluster Details page.

Patch history views in the Console do not show patches that were applied by using command line tools such as dbaascli.

Parent topic: Using the Console to Patch and Update Exadata Database Service on Exascale Infrastructure VM Clusters

To view the patch history of a cloud VM cluster

Each patch history entry represents an attempted patch operation and indicates whether the operation was successful or failed.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.
  3. Click Exadata VM Clusters.
  4. In the list of cloud VM clusters, click the name of the cluster you want to patch to display the cluster details.
  5. Under Version, click the View Patches link beside the Updates Available field.

  6. Click Update History.

    The Update History page displays the history of patch operations for that cloud VM cluster and for the Database Homes on that cloud VM cluster.

To view the patch history of a Database Home
Each patch history entry represents an attempted patch operation and indicates whether the operation was successful or failed. You can retry a failed patch operation. Repeating an operation results in a new patch history entry. When your service instance uses the new resource model, the patch history available by navigating to the VM Cluster Details page.
  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.
  3. Navigate to the cloud VM cluster that contains the Database Home.

    Under Oracle Exadata Database Service on Exascale Infrastructure, click Exadata VM Clusters. In the list of VM clusters, find the VM cluster you want to access and click its highlighted name to view the details page for the cluster.

  4. Under Resources, click Database Homes.
  5. Click the name of the Database Home you want to view to display the Database Home details.
  6. Under Database Software Version, click View by the Latest Patch Available field.
  7. Click Update History.
    The history page displays the history of patch operations for that Database Home and for the cloud VM cluster to which it belongs.
Using the API to Patch an Oracle Exadata Database Service on Exascale Infrastructure Instance

Use these API operations to manage patching the following Exadata resources: cloud VM clusters, databases, and Database Homes.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Cloud VM clusters:

Databases:

  • UpdateDatabase - Use this operation to patch a database by moving it to another Database Home

Database Homes:

For the complete list of APIs for the Database service, see Database Service API.

Updating an Exadata Cloud VM Cluster Operating System

Exadata VM cluster image updates allow you to update the OS image on your Exadata cloud VM cluster nodes in an automated manner from the OCI console and APIs.

This automated feature simplifies and speeds up VM cluster patching, makes patching less error-prone, and eliminates the need to use Patch Manager.

When you apply a patch, the system runs a precheck operation to ensure your cloud VM cluster, Exadata DB system, or Database Home meets the requirements for that patch. If the precheck is not successful, the patch is not applied, and the system displays a message that the patch cannot be applied because the precheck failed. A separate precheck operation that you can run in advance of the planned update is also available.

Updating the Operating System using the Console

Note

After the VM cluster is upgraded to Exadata Database Service Guest VM OS 23.1, you will be able to add a new VM or a new database server to this VM cluster if Exadata Cloud Infrastructure is running an Exadata System Software version 22.1.16 and later.

Upgrade to Exadata System Software 23.1 for Exadata Cloud Infrastructure will be available with February 2024 update cycle.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Under Oracle Exadata Database Service on Exascale Infrastructure, click Exadata VM Clusters.
  3. In the list of cloud VM clusters, click the name of the cluster that you want to patch to display the details page.
  4. In the Version section, to the right of the Updates Available, click View Updates to display the Updates page.
  5. Review the list of available software updates and locate the OS patch you are applying.
  6. Click the Actions icon (three dots) at the end of the row listing the patch you are interested in, and then click one of the following actions:
    • Run Precheck. Precheck checks the prerequisites to ensure that the patch can be successfully applied. Oracle highly recommends that you run the precheck operation before you apply a patch. The reason is that things can change in a database at any time, and the precheck you run just before running a patch may find errors that the previous precheck did not find
      Note

      If the precheck fails, the system displays a message in the Apply Exadata OS Image Update dialog that the last precheck has failed. Oracle recommends that you run the precheck again. Click the Actions icon (three dots) at the end of the row listing the OS patch to view the dialog.
    • Apply Exadata OS Image Update. This link displays the Apply Exadata Image Update dialog that you use to apply the patch. The dialog shows the name of the database system you are patching, the current version of the database, and the new version of the database after the patch is applied. To start the process, click Apply Exadata OS Image Update.
    • Copy OCID. This copies the Oracle Cloud ID. This can be used when troubleshooting a patch or to give to Support when contacting them.
      Note

      While the patch is running:

      • Run Precheck and Apply OS Image Update are not available. When the patch has completed, these actions are available again.
      • If the Exadata infrastructure containing this VM cluster is scheduled for maintenance that conflicts with the patching operation, the patch fails and the system displays a message explaining why. After the infrastructure maintenance is complete, run the patch operation again.
  7. Confirm when prompted.

The patch list displays the status of the operation in the Version section of the database details page. Click View Updates to view more details about an individual patch status and to display any updates that are available to run. If no new updates are available, the system displays a message that says No Updates Available.

Upgrading Exadata Databases

Oracle Database releases on Oracle Exadata Database Service on Exascale Infrastructure can be upgraded using the Console and the API.

The upgrade is accomplished by moving the Exadata database to a Database Home that uses the target software version.

Related Topics

Parent topic: Patching and Updating an Oracle Exadata Database Service on Exascale Infrastructure System

Prerequisites to Upgrade Oracle Databases

Review the list of prerequsites to upgrade an Oracle Exadata Database Service on Exascale Infrastructure Oracle Database instance.

  • You must have an available Oracle Database Home that uses the four most recent versions of Oracle Database available. See To Create a new Oracle Database Home in an existing Oracle Exadata Database Service on Exascale Infrastructure Instance for information on creating a Database Home. You can use Oracle-published software images or a custom database software image based on your patching requirements to create Database Homes.
  • You must ensure that all pluggable databases in the container database that is being upgraded can be opened. Pluggable databases that cannot be opened by the system during the upgrade can cause an upgrade failure.

  • If you are upgrading databases in a manually-created Data Guard association (an association not created using the Console or APIs), the following apply:

    • The databases must be registered with the Cloud tooling.
    • Redo apply needs to be disabled during the upgrade of both the primary and standby.
    • If you have configured an observer, then the observer needs to be disabled prior to upgrade.
Before you start the upgrade, your Oracle Database configuration must be configured with the following settings:
  • The database must be in archive log mode.
  • The database must have flashback enabled.

To learn more about these settings, see the Oracle Database documentation for your database release.

About Upgrading a Database

For database software version upgrades, note the following:

  • Database upgrades involve database downtime. Keep this in mind when scheduling your upgrade.
  • Oracle recommends that you back up your database and test the new software version on a test system or a cloned version of your database before you upgrade a production database. See to create an on-demand full backup of a database for information on creating an on-demand manual backup.
  • Oracle recommends running an upgrade precheck operation for your database prior to attempting an upgrade so that you can discover any issues that need mitigation prior to the time you plan to perform the upgrade. The precheck operation does not affect database availability and can be performed at any time that is convenient for you.

  • If your databases uses Data Guard, you can upgrade either the primary or the standby first. To upgrade a primary, follow the steps in To upgrade or precheck an Exadata database. To upgrade a standby, follow the steps in To move a database to another Database Home

  • If your databases uses Data Guard, upgrading a primary or standby will disable redo apply during the upgrade operation. After you upgrade both the primary and standby, redo apply and open mode are re-enabled. Oracle recommends checking the redo apply and open mode configuration after upgrading.

  • An upgrade operation cannot take place while an automatic backup operation is underway. Before upgrading, Oracle recommends disabling automatic backups and performing a manual backup. See to configure automatic backups for a database and To create an on-demand full backup of a database for more information.
  • After upgrading, you cannot use automatic backups taken prior to the upgrade to restore the database to an earlier point in time.

Parent topic: Upgrading Exadata Databases

How the Upgrade Operation Is Performed by the Database Service

During the upgrade process, the Database service does the following:

  • Executes an automatic precheck. This allows the system to identify issues needing mitigation and to stop the upgrade operation.
  • Sets a guaranteed restore point, enabling it to perform a flashback in the event of an upgrade failure.
  • Moves the database to a user-specified Oracle Database Home that uses the desired target software version.
  • Runs the Database Upgrade Assistant (DBUA) software to perform the upgrade.
  • For databases in Data Guard associations, redo apply is disabled until both the primary and standby databases are successfully upgraded, at which point redo apply is re-enabled by the system. The system then enables Open Mode after redo apply is enabled.
Rolling Back an Oracle Database Unsuccessful Upgrade

If your upgrade does not complete successfully, then you have the option of performing a rollback.

Details about the failure are displayed on the Database Details page in the Console, allowing you to analyze and resolve the issues causing the failure.

A rollback resets your database to the state prior to the upgrade. All changes to the database made during and after the upgrade will be lost. The rollback option is provided in a banner message displayed on the database details page of a database following an unsuccessful upgrade operation. See Using the Console to Roll Back a Failed Database Upgrade for more information.

For standby databases in Oracle Data Guard associations, rollback is accomplished by moving the standby back to the original Database Home. See To move a database to another Database Home for instructions.

After Upgrading an Oracle Database

After a successful upgrade, note the following:

  • Check that automatic backups are enabled for the database if you disabled them prior to upgrading. See Customizing the Automatic Backup Configuration for more information.
  • Edit the Oracle Database COMPATIBLE parameter to reflect the new Oracle Database software version. See What Is Oracle Database Compatibility? for more information.
  • If your database uses a database_name.env file, ensure that the variables in the file have been updated to point to the new Database home. These variables should be automatically updated during the upgrade process.
  • If you are upgrading a non-container database, you can convert the database to a pluggable database after converting. See How to Convert Non-CDB to PDB (Doc ID 2288024.1) for instructions on converting your database to a pluggable database.
  • If your old Database Home is empty and will not be reused, then you can remove it. See Using the Console to Delete an Oracle Database Home for more information.
  • For databases in Data Guard associations, check the open mode and redo apply status after the upgrade is complete.
Using the Console to Upgrade a Database

Procedures to precheck and upgrade a database, rollback a failed upgrade, and view the upgrade history.

Parent topic: Upgrading Exadata Databases

To upgrade or precheck an Exadata database

Procedure to upgrade or precheck an Exadata database.

The following steps apply to databases for which either of the following apply:

  • The database is the primary database in a Data Guard association
  • The database is not part of a Data Guard association

To upgrade a standby database in a Data Guard configuration, move the standby to a Database Home using the Oracle Database version you are upgrading to.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.

  3. UnderOracle Exadata Database Service on Exascale Infrastructure, click Exadata VM Clusters. In the list of VM clusters, click the name of the VM cluster that contains the database you want to upgrade.

  4. In the list of databases on the details page of the VM cluster, click the name of the database you want to upgrade to view the Database Details page.
  5. Click More Actions, then Upgrade.

  6. In the Upgrade Database dialogue, select the following:

    • Oracle Database version: The drop-down selector lists only Oracle Database versions that are compatible with an upgrade from the current software version the database is using. The target software version must be higher than the database's current version.

    • Target Database Home: Select a Database Home for your database. The list of Database Homes is limited to those homes using the most recent versions of Oracle Database 19c software. Moving the database to the new Database Home results in the database being upgraded to the major release version and patching level of the new Database Home.

  7. Click one of the following:

    • Run Precheck: This option starts an upgrade precheck to identify any issues with your database that need mitigation before you perform an upgrade.
    • Upgrade Database: This option starts upgrade operation. Oracle recommends performing an upgrade only after you have performed a successful precheck on the database.
To roll back a failed database upgrade

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Exascale Infrastructure .
  2. Choose your Compartment.
    A list of VM Clusters is displayed for the chosen Compartment.
  3. In the list of VM clusters, click the name of the VM cluster that contains the database with the failed upgrade.
  4. Find the database that was unsuccessfully upgraded, and click its name to display details about it.
  5. The database must display a banner at the top of the details page that includes a Rollback button and details about what issues caused the upgrade failure.
  6. Click Rollback.
  7. In the Confirm rollback dialog, confirm that you want to initiate a rollback to the previous Oracle Database version.
To view the the upgrade history of a database

To view upgrade history for databases on Exadata Database Service on Exascale Infrastructure, use this procedure.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Exascale Infrastructure
  2. Choose your Compartment.

  3. Under Oracle Exadata Database Service on Exascale Infrastructure, click Exadata VM Clusters. In the list of VM clusters, click the name of the VM cluster that contains the database you want to upgrade.

  4. In the list of databases on the details page of the VM cluster, click the name of the database for which you want to view the upgrade history.
  5. On the Database Details page, under Database Version, click the View link that is displayed for databases that have been upgraded. This link does not appear for databases that have not been updated.

    The Updates History page is displayed. The table displayed on this page shows precheck and upgrade operations performed on the database.

Using the API to upgrade Databases

Use the following APIs to manage database upgrades:

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage database upgrades:

For the complete list of APIs for the Database service, see Database Service API.

Note

When using the UpgradeDatabase API to upgrade an Oracle Exadata Database Service on Exascale Infrastructure database, you must specify DB_HOME as the upgrade source.