Oracle Cloud Infrastructure Documentation
Try Free Tier

Patch and Update an Exadata Cloud Infrastructure System

Parent topic: How-to Guides

User-Managed Maintenance Updates

Maintaining a secure Exadata Cloud Infrastructure instance in the best working order requires you to perform the following tasks regularly:

  • 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 Exadata Cloud Infrastructure System

Learn how to perform patching operations on Exadata database virtual machines and Database Homes by using the Console, API, or the CLI.

For information and instructions on patching the system by using the dbaascli utility, see Patching and Updating an Exadata Cloud Infrastructure System Manually.

For more information and examples for applying database quarterly patches on Exadata Cloud Infrastructure refer to My Oracle Support note: How to Apply Database Quarterly Patch on Exadata Cloud Service and Exadata Cloud at Customer Gen 2 (Doc ID 2701789.1).

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

  • Patching and Updating VM Cluster’s GI and Database Homes
    This topic explains how to perform patching operations on Exadata Cloud Infrastructure resources by using the Console, API, or the CLI.
  • 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.
  • Upgrading Exadata Grid Infrastructure
    This topic describes how to upgrade the Oracle Grid Infrastructure (GI) on an Exadata cloud VM cluster using the Oracle Cloud Infrastructure Console or API.
  • Upgrading Exadata Databases
    This topic describes the procedures to upgrade an Exadata database instance to Oracle Database 19c and Oracle Database 23ai by 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: Patch and Update an Exadata Cloud Infrastructure System

Patching and Updating VM Cluster’s GI and Database Homes

This topic explains how to perform patching operations on Exadata Cloud Infrastructure resources by using the Console, API, or the CLI.

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.

For information and instructions on patching the system by using the dbaascli utility, see Patching Oracle Grid Infrastructure and Oracle Databases Using dbaascli.

Parent topic: Patching and Updating an Exadata Cloud Infrastructure System

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

This topic describes the types of patching performed on an Exadata Cloud Infrastructure instances and provides instructions for completing the patching operations.

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

Oracle Grid Infrastructure (GI) Patching

Patching an Exadata Cloud 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

The cloud Exadata resource model the instance is using determines whether you patch the Grid Infrastructure on a DB system resource or a cloud VM cluster resource. VM clusters are used by the The New Exadata Cloud Infrastructure Resource Model DB systems can be easily migrated to the new resource model with no system downtime. Switch an Exadata DB system to the new Exadata resource model .

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 Exadata Cloud Infrastructure instances using the older DB system resource model, see To patch the Oracle Database software in a Database Home (DB system).

Best Practices for Patching Exadata Cloud 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 allows you to easily roll back the database to the previous version by moving it back to the old Database Home. See To move a database to another Database Home To patch a database by moving it to another 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 plus the three most recent older versions (N through N - 3). For example, if an instance is using Oracle Database 19c, and the latest version of 19c offered is 19.8.0.0.0, patches are available for versions 19.8.0.0.0, 19.7.0.0, 19.6.0.0 and 19.5.0.0.

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 Exadata Cloud Infrastructure

Customer-managed keys for Exadata Cloud 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:

  • Enable customer-managed keys when you create databases in Exadata Cloud 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 Data Guard on Exadata Cloud Infrastructure databases that use customer-managed keys, the primary and standby databases must be in the same realm.

Task 1. Create a Vault and a Master Encryption Key

Create a vault in the Vault service by following the instructions in To create a new vault in Oracle Cloud Infrastructure Documentation. When following these instructions, Oracle recommends that you create the vault in a compartment created specifically to contain the vaults containing customer-managed keys, as described in Before You Begin: Compartment Hierarchy Best Practice.

After creating the vault, create at least one master encryption key in the vault by following the instructions in To create a new master encryption key in Oracle Cloud Infrastructure Documentation. When following these instructions, make these choices:

  • Create in Compartment: Oracle recommends that you create the master encryption key in the same compartment as its vault; that is, the compartment created specifically to contain the vaults containing customer-managed keys.
  • Protection Mode: Choose an appropriate value from the drop-down list:
    • HSM to create a master encryption key that is stored and processed on a hardware security module (HSM).
    • Software to create a master encryption key that is stored in a software file system in the Vault service. Software-protected keys are protected at rest using an HSM-based root key. You may export software keys to other key management devices or to a different OCI cloud region. Unlike HSM keys, software-protected keys are free of cost.
  • Key Shape Algorithm: AES
  • Key Shape Length: 256 bits

Oracle strongly recommends that you create a separate master encryption key for each of your container databases (CDBs). Doing so makes management of key rotation over time much simpler.

Task 2. Create a Service Gateway, a Route Rule, and an Egress Security Rule

Create a service gateway in the VCN (Virtual Cloud Network) where your Oracle Exadata Database Service on Dedicated Infrastructure resources reside by following the instructions in Task 1: Create the service gateway in Oracle Cloud Infrastructure Documentation.

After creating the service gateway, add a route rule and an egress security rule to each subnet (in the VCN) where Oracle Exadata Database Service on Dedicated Infrastructure resources reside so that these resources can use the gateway to access the Vault service:

  1. Go to the Subnet Details page for the subnet.
  2. In the Subnet Information tab, click the name of the subnet's Route Table to display its Route Table Details page.
  3. In the table of existing Route Rules, check whether there is already a rule with the following characteristics:
    • Destination: All IAD Services In Oracle Services Network
    • Target Type: Service Gateway
    • Target: The name of the service gateway you just created in the VCN

    If such a rule does not exist, click Add Route Rules and add a route rule with these characteristics.

  4. Return to the Subnet Details page for the subnet.
  5. In the subnet's Security Lists table, click the name of the subnet's security list to display its Security List Details page.
  6. In the side menu, under Resources, click Egress Rules.
  7. In the table of existing Egress Rules, check whether there is already a rule with the following characteristics:
    • Stateless: No
    • Destination: All IAD Services In Oracle Services Network
    • IP Protocol: TCP
    • Source Port Range: All
    • Destination Port Range: 443

    If such a rule does not exist, click Add Egress Rules and add an egress rule with these characteristics.

Task 3. Create a Dynamic Group and a Policy Statement

To grant your Oracle Exadata Database Service on Dedicated Infrastructure resources permission to access customer-managed keys, you create an IAM dynamic group that identifies these resources and then create an IAM policy that grants this dynamic group access to the master encryption keys you created in the Vault service.

When defining the dynamic group, you identify your Oracle Exadata Database Service on Dedicated Infrastructure resources by specifying the OCID of the compartment containing your Exadata Infrastructure resource.

  1. Copy the OCID of the compartment containing your Exadata Infrastructure resource. You can find this OCID on the Compartment Details page of the compartment.
  2. Create a dynamic group by following the instructions in To create a dynamic group in Oracle Cloud Infrastructure Documentation. When following these instructions, enter a matching rule of this format:
    ALL {resource.compartment.id ='<compartment-ocid>'}

    where <compartment-ocid> is the OCID of the compartment containing your Exadata Infrastructure resource.

After creating the dynamic group, navigate to (or create) an IAM policy in a compartment higher up in your compartment hierarchy than the compartment containing your vaults and keys. Then, add a policy statement of this format:

allow dynamic-group <dynamic-group-name>
to manage keys
in compartment <vaults-and-keys-compartment>
where all {
target.key.id='<key_ocid>',
request.permission!='KEY_DELETE',
request.permission!='KEY_MOVE',
request.permission!='KEY_IMPORT',
request.permission!='KEY_BACKUP’
}

If you are using a replicated virtual private vault for the Oracle Data Guard deployment, add an additional policy statement in this format:

allow dynamic-group <dynamic-group>
to read vaults
in tenancy | compartment <vaults-and-keys-compartment>

where <dynamic-group> is the name of the dynamic group you created and <vaults-and-keys-compartment> is the name of the compartment in which you created your vaults and master encryption keys.

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-3 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>| --resetParameters <values> | --responseFile
[--backupPrepared]
[--instance]
[--allowBounce]
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.
  • --responseFile specifies the absolute location of the response JSON file to modify the database parameters
  • --backupPrepared acknowledges that a proper database backup is in place prior to modifying critical or sensitive parameters.
  • --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.
  • --allowBounce grants permission to bounce the database in order to reflect the changes on applicable static parameters.

Example 5-4 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-5 dbaascli database upgrade pre-upgrade requisite checks

dbaascli database upgrade --dbbname dbname --targetHome Target Oracle home location --executePrereqs
Prerequisites for Patching and Updating an Exadata Cloud Infrastructure System

The Exadata Cloud 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 Cloud Infrastructure Instances

You can use the Console to view the history of patch operations on Exadata Cloud Infrastructure instances, apply patches, and monitor the status of patch operations.

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

Patching Exadata Instances That Use the DB System Resource Model

The tasks in this section describe how to apply patches and monitor the status of patch operations on Exadata DB systems and their Database Homes.

Parent topic: Using the Console to Patch and Update Exadata Cloud Infrastructure Instances

To patch the Oracle Grid Infrastructure on an Exadata DB system

How to apply patches and monitor the status of patch operations on Exadata DB systems

  1. Open the navigation menu. Click Oracle Database, then click Bare Metal, VM, and Exadata.
  2. Choose your Compartment.
  3. In the list of DB systems, click the name of the Exadata DB system you want to patch to display the DB system details.
  4. Under DB System Version, click the View link beside the Latest Patch Available field.
  5. Review the list of available patches for the DB system.
  6. 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.Apply: Applies the selected patch. Oracle highly recommends that you run the precheck operation for a patch before you apply it.
    • Run 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.
  7. 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 DB system's status displays as Updating. Lifecycle operations on the DB system and its resources might be temporarily unavailable. If patching completes successfully, the patch's status changes to Applied and the status of the DB system changes to Available. You can view more details about an individual patch operation by clicking Patch History.

To patch the Oracle Database software in a Database Home (DB system)

How to apply patches and monitor the status of patch operations on Exadata Database Homes for DB Systems.

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 it to another Database Home that uses the desired Oracle Database software configuration.

  1. Open the navigation menu. Click Oracle Database, then click Bare Metal, VM, and Exadata.
  2. Choose your Compartment.
  3. In the list of DB systems, click the name of the Exadata DB system with the Database Home you want to patch to display the DB system details.
  4. Under Resources, click Database Homes.
  5. Click the name of the Database Home you want to patch to display the Database Home details.
  6. Under Database Software Version, locate the Latest Patch Available field and click View.
  7. 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.
  8. 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.

  9. 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 Patch History.

Patching Exadata Instances That use the New Resource Model

The tasks in this section describe how to apply patches and monitor the status of patch operations on cloud VM clusters and their 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 Oracle Exadata Database Service on Dedicated 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 To move a database to another Database Home that uses the desired Oracle Database software configuration.
  1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated 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.

Patching Individual Oracle Databases in an Exadata Cloud Infrastructure Instance

This task explains how to patch a single Oracle Database in your Exadata Cloud Infrastructure instance by moving it to another Database Home.

For information on patching Database Homes, see To patch the Oracle Database software in a Database Home (cloud VM cluster)

Parent topic: Using the Console to Patch and Update Exadata Cloud Infrastructure Instances

To move a database to another Database Home

This task explains how to patch a single Oracle Database in your Exadata Cloud Infrastructure instance 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. For information on patching Database Homes, see Database Home Patching and .

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

    Cloud VM clusters ( The New Exadata Cloud Infrastructure Resource Model ): Under Oracle Exadata Database Service on Dedicated 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.

    DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find you want to access, and then click the name of the Exadata DB system that contains the database you want to move..

  4. Click More Actions, 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 Databse. When the operation completes, Database Home is updated with the current home. Datapatch is executed 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

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.

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

If your service instance uses the new resource model, the patch history available by navigating to the VM Cluster Details page. If your service instance uses the DB system resource model, the patch history is available by navigating to the DB System Details page.

  • 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.
  • To view the patch history of a DB system
    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. For a service instance using the DB system resource model, the patch history is available by navigating to the DB System Details page
  • 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. If your service instance uses the new resource model, the patch history available by navigating to the VM Cluster Details page.

Parent topic: Using the Console to Patch and Update Exadata Cloud Infrastructure Instances

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 Oracle Exadata Database Service on Dedicated 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.

Parent topic: Viewing Patch History

To view the patch history of a DB system

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. For a service instance using the DB system resource model, the patch history is available by navigating to the DB System Details page

  1. Open the navigation menu. Click Oracle Database, then click Bare Metal, VM, and Exadata.
  2. Choose your Compartment.
  3. In the list of DB systems, click the name of the Exadata DB system with the information you want to view to display the DB system details.
  4. Under DB System Version, click the View beside the Latest Patch Available field.
  5. Click Patch History.

The Patch History page displays the history of patch operations for that DB system and for the Database Homes on that DB system.

Parent topic: Viewing Patch History

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. If 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 Oracle Exadata Database Service on Dedicated Infrastructure
  2. Choose your Compartment.
  3. Navigate to the cloud VM cluster or DB system that contains the Database Home.

    • Cloud VM clusters (The Exadata Cloud Infrastructure Resource Model) Under Oracle Exadata Database Service on Dedicated 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.

    • DB systems Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

  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 Patch History (DB systems) or Update History (cloud VM clusters).
    The history page displays the history of patch operations for that Database Home and for the cloud VM cluster or DB system to which it belongs.

Parent topic: Viewing Patch History

Using the API to Patch an Exadata Cloud Infrastructure Instance

Use these API operations to manage patching the following Exadata resources: cloud VM clusters, DB systems, 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 (for systems using the new resource model):

DB systems:

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.

Parent topic: Patching and Updating an Exadata Cloud Infrastructure System

Supported Software Versions and Update Restrictions

Minimum requirements for updating to Exadata image release 23.1.0.0.0 (Oracle Linux 8-based image):

Note

These are just the minimum requirements. If you want to update Grid Infrastructure and/or Oracle Database to meet the Exadata 23.1 requirements, then the recommendation is to update to the latest available versions of Grid Infrastructure and Oracle Database, and not to the minimum.
  • Exadata Image (Guest OS): Exadata image release 22.1.0 (May 2022) or 21.2.10 (March 2022). Systems running versions older than 21.2.10 will first need to upgrade to at least 22.1.0 (May 2022) or 21.2.10 (March 2022) before updating to 23.1.0.0.0. This applies to both storage and database servers.
    • In addition to performing minor version updates to the Exadata VM Cluster images, you can update to a new major version if the currently installed version is 19.2 or higher. For example, if the VM cluster is on version 20, then you can update it to version 21.
    • The latest 4 (N to N-3) or more minor versions of each major version of the VM Cluster images are available through the console to apply.
  • Oracle Grid Infrastructure: Exadata image release 23.1.0.0.0 supports the following minimum or newer Oracle Grid Infrastructure versions.
    • Release 19c: Version 19.15, April 2022 Release Update (RU) and newer (Default)
    • Release 21c: Version 21.6, April 2022 Release Update (RU) and newer
  • Oracle Database: Exadata System Software 23.1 supports the following minimum versions or newer for new database installations.
    • Release 19c: Version 19.15, April 2022 Release Update (RU) and newer (Default)
    • Additional supported database releases under Market Driven Support or Quarterly Updates exception approval:
      • Release 12.2.0.1, Release Update (RU) 12.2.0.1.220118 (Jan 2022)
      • Release 12.1.0.2, Bundle Patch 12.1.0.2.220719 (Jul 2022) - requires patch 30159782
      • Release 11.2.0.4, Bundle Patch 11.2.0.4.210119 (Jan 2021) - requires patch 30159782, patch 33991024
  • If you have an Exadata infrastructure maintenance operation scheduled to start within the next 24 hours, then the Exadata Image update feature is not available.
  • Once 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.
    Note

    Upgrade to Exadata System Software 23.1 for Exadata Cloud Infrastructure will be available with February 2024 update cycle.
Updating the Operating System using the Console

Note

Once 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 Oracle Exadata Database Service on Dedicated Infrastructure
  2. Under Oracle Exadata Database Service on Dedicated 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 Grid Infrastructure

This topic describes how to upgrade the Oracle Grid Infrastructure (GI) on an Exadata cloud VM cluster using the Oracle Cloud Infrastructure Console or API.

Upgrading allows you to provision Oracle Database Homes and databases that use the most current Oracle Database software. For more information on Exadata cloud VM clusters and the new Exadata resource model, see Overview of X8M, X9M, and X11M Scalable Exadata Infrastructure .

Parent topic: Patching and Updating an Exadata Cloud Infrastructure System

Prerequisites for Upgrading Exadata Grid Infrastructure

To upgrade your GI to Oracle Database 19c, you must be using the Oracle Linux 7 operating system for your VM cluster.

For more information on upgrading the operating system, see the following document:

About Upgrading Oracle Grid Infrastructure

Upgrading the Oracle Grid Infrastructure (GI) on a VM cluster involves upgrading all the compute nodes in the instance. The upgrade is performed in a rolling fashion, with only one node being upgraded at a time.

  • Oracle recommends running an upgrade precheck to identify and resolve any issues that would prevent a successful upgrade.
  • You can monitor the progress of the upgrade operation by viewing the associated work requests.
  • If you have an Exadata infrastructure maintenance operation scheduled to start within the next 24 hours, then the GI upgrade feature is not available.
  • During the upgrade, you cannot perform other management operations such as starting, stopping, or rebooting nodes, scaling CPU, provisioning or managing Database Homes or databases, restoring a database, or editing IORM settings. The following Data Guard operations are not allowed on the VM cluster undergoing a GI upgrade:
    • Enable Data Guard
    • Switchover
    • Failover to the database using the VM cluster (a failover operation to standby on another VM cluster is possible)
Using the console to upgrade your Grid Infrastructure

You can use the Console to perform a precheck prior to upgrading your Oracle Grid Infrastructure (GI), and to perform the GI upgrade operation.

To Precheck your Cloud VM Cluster prior to Upgrading

  1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated 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. 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 Run Precheck.
  8. In the Confirm dialog, confirm you want to upgrade to begin the precheck operation.
To Upgrade the Oracle Grid Infrastructure of a Cloud VM Cluster

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

Note

  • When planning to upgrade your Grid Infrastructure to 23ai, make sure that for each ASM diskgroup, compatible.rdbms has a value set to 19.0.0.0 and later.
  • Minimum requirements for upgrading Grid Infrastructure from 19c to 23ai:
    • Exadata Guest VM running Exadata System Software 23.1.8
    • Exadata Infrastructure running Exadata System Software 23.1.x
  1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated 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.
Using the API to Upgrade the Grid Infrastructure in a VM Cluster

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 upgrade the Oracle Grid Infrastructure in a cloud VM clusters and view the cluster's update history.

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

Upgrading Exadata Databases

This topic describes the procedures to upgrade an Exadata database instance to Oracle Database 19c and Oracle Database 23ai by 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.

Note

This topic applies only to Exadata Cloud Infrastructure instances using the new resource model. For information on converting an Exadata DB system to the new resource model, see Switching an Exadata DB System to the New Resource Model and APIs.

For Oracle Database release and software support timelines, see Release Schedule of Current Database Releases (Doc ID 742060.1) in the My Oracle Support portal.

Parent topic: Patching and Updating an Exadata Cloud Infrastructure System

Prerequisites to Upgrade Oracle Databases

Review the list of prerequisites to upgrade an Exadata Cloud Infrastructure Oracle Database instance.

  • To upgrade to 19c, Oracle Linux 7 is the minimum requirement, and to upgrade to 23ai, Oracle Linux 8 is the minimum requirement. For detailed instructions on manually updating the operating system, refer to How to Update the Exadata System Software (DomU) to 19 from 18 on the Exadata Cloud Service in OCI (My Oracle Support Doc ID 2521053.1).
  • The Oracle Grid Infrastructure can be version 19c or 23ai for Oracle Database 19c. However, the Oracle Grid Infrastructure must be version 23ai for Oracle Database 23ai. See Upgrading Exadata Grid Infrastructure for instructions on using the Oracle Cloud Infrastructure Console or API to upgrade Grid Infrastructure. If patches are available for your Grid Infrastructure, Oracle recommends applying them prior to performing a database upgrade.
  • You must have an available Oracle Database Home that uses the four most recent versions of Oracle Database 19c or Oracle Database 23ai available in Oracle Cloud Infrastructure. See To Create a new Oracle Database Home in an existing Exadata Cloud 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. See Updating Tooling on an Exadata Cloud Service Instance for more information.
    • Redo apply needs to be disabled during the upgrade of both the primary and standby. For Oracle 11.2 and 12.1 databases, the Data Guard configuration also has to be disabled.
    • If you have configured an observer, the observer needs to be disabled prior to upgrade.
Your Oracle database must be configured with the following settings in order to upgrade:
  • The database must be in archive log mode.
  • The database must have flashback enabled.

See the Oracle Database documentation for your database's release version to learn more about these settings.

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.
  • If you are upgrading an database that uses version 11.2 software, the resulting version 19c database will be a non-container database (non-CDB).

Related Topics

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 19c Database Home. These variables should be automatically updated during the upgrade process.
  • If you are upgrading a non-container database to Oracle Database version 19c, 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, 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.

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. See To move a database to another Database Home for details.

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

  3. UnderOracle Exadata Database Service on Dedicated 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.

    Note

    If your database is in an Exadata Cloud Infrastructure instance that does not use the new Exadata resource model, you will need to switch the instance to the new model before you can upgrade your database.

  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 Oracle Exadata Database Service on Dedicated 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

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

  3. Under Oracle Exadata Database Service on Dedicated 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.

    Note

    If your database is in an Exadata Cloud Infrastructure instance that does not use the new Exadata resource model , you will need to switch the instance to the new Exadata resource model before you can upgrade your database.

  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 Exadata Cloud Infrastructure database, you must specify DB_HOME as the upgrade source.

Was this article helpful?