Oracle Cloud Infrastructure Documentation
Try Free Tier

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.

Patching requires moving the database to a new Database Home that has the correct patch version. This affects only the database being moved.

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

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

Frequently Asked Questions

Q: What is the purpose of the dbaascli database runDatapatch command?

A: The dbaascli database runDatapatch command is used to apply patches to an Oracle Database.

Q: What must be ensured before running the dbaascli database runDatapatch command?

A: Before running the command, ensure that all instances of the database are up and running.

Q: How do I specify which database to patch?

A: Use the --dbname option followed by the name of the database. For example:

--dbname myDatabase

Q: How do I resume a previously interrupted runDatapatch operation?

A: Use the --resume option to resume the previous run or the --sessionID option to specify a specific session ID. For example:

--resume

--sessionID 12345

Q: How can I skip certain PDBs when running the patch?

A: Use the --skipPdbs option followed by a comma-delimited list of PDB names to skip. For example:

--skipPdbs pdb1,pdb2

Q: How can I run the patch only on certain PDBs?

A: Use the --pdbs option followed by a comma-delimited list of PDB names to include. For example:

--pdbs pdb1,pdb2

Q: How do I apply or roll back a specific set of patches?

A: Use the --patchList option followed by a comma-delimited list of patch names to apply or roll back. For example:

--patchList patch1,patch2

Q: What does the --rollback option do?

A: The --rollback option rolls back the patches that were applied during the patching operation.

Q: What happens if some PDBs are closed during the patching operation?

A: If some PDBs are closed, you can use the --skipClosedPdbs option to skip patching those closed PDBs.

Q: Can I run prerequisite checks before applying patches?

A: Yes, use the --executePrereqs option to run prerequisite checks before applying the patch.

Q: How do I find out which session ID to resume a patch?

A: After a runDatapatch operation, the session ID is typically logged. Use the --sessionID option to specify that ID when resuming a patch. For example:

--sessionID 67890

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

Frequently Asked Questions

Q: What is the purpose of the dbaascli database addInstance command?

A: The dbaascli database addInstance command is used to add a new database instance to a specified node in an Oracle Exadata Database Service environment.

Q: What are the prerequisites for running the dbaascli database addInstance command?

A: The command must be run as the root user to have the necessary permissions to add a database instance.

Q: What does the --dbname option represent in this command?

A: The --dbname option specifies the name of the Oracle Database for which you want to add a new instance.

Q: What is the --node option used for in the dbaascli database addInstance command?

A: The --node option specifies the name of the node where the new database instance will be added.

Q: What is the purpose of the --newNodeSID option in this command?

A: The --newNodeSID option allows you to specify the SID (System Identifier) for the new database instance that will be created on the specified node.

Q: Is it mandatory to specify the --newNodeSID option when adding a new instance?

A: The --newNodeSID option is optional. If not provided, Oracle will automatically generate an SID for the new database instance.

Q: When should I use the dbaascli database addInstance command?

A: Use this command when you want to scale your database by adding a new instance to an additional node in a multi-node Oracle Database setup.

Q: Can I add multiple database instances to different nodes using this command?

A: Yes, you can run the command multiple times to add database instances to different nodes by specifying the appropriate --node and --dbname values.

Q: What happens if the node specified in the --node option is not available?

A: The command will fail if the specified node is not available or reachable. Ensure that the node is properly configured and accessible before running the command.

Q: Can this command be used in a Data Guard environment?

A: Yes, you can use the dbaascli database addInstance command in a Data Guard environment to add instances, but it is recommended to follow the necessary Data Guard guidelines for such configurations.

Q: Will this command cause database downtime?

A: Adding an instance to a new node typically does not cause downtime for the existing database instances, but itโ€™s recommended to check your environment for any specific dependencies.

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.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database getDetails command?

A: The dbaascli database getDetails command shows detailed information about a specified Oracle database, including the database name, node information, and pluggable database (PDB) details.

Q: Who can run the dbaascli database getDetails command?

A: The command can be run by the root user or the oracle user.

Q: What does the --dbname option specify in the dbaascli database getDetails command?

A: The --dbname option specifies the name of the Oracle database for which detailed information is being retrieved.

Q: What kind of information does the dbaascli database getDetails command provide?

A: The command provides details such as the database name, node information, and information about pluggable databases (PDBs) associated with the container database.

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

Frequently Asked Questions

Q: What is the purpose of the dbaascli database modifyParameters command?

A: The dbaascli database modifyParameters command is used to modify or reset Oracle Database initialization parameters.

Q: How do I specify the database for which I want to modify parameters?

A: You must use the --dbname option to specify the name of the database for which you want to modify or reset parameters.

Q: How can I modify database parameters using the modifyParameters command?

A: Use the --setParameters option followed by a comma-delimited list of parameters and their new values. For example:

--setParameters parameter1=valueA,parameter2=valueB

Q: How do I reset parameters to their default values using this command?

A: Use the --resetParameters option followed by a comma-delimited list of parameters to reset to their default values. For example:

--resetParameters parameter1,parameter2

Q: Can I modify parameters using a response file?

A: Yes, you can specify the absolute location of a response JSON file using the --responseFile option. The file should contain the parameters you want to modify.

Q: Is it necessary to take a backup before modifying parameters?

A: While not mandatory for all changes, if you are modifying critical or sensitive parameters, it's recommended to have a backup in place. You can use the --backupPrepared option to acknowledge that a backup has been prepared.

Q: Can I apply changes only to a specific instance in a multi-instance database?

A: Yes, you can specify the instance name using the --instance option. If this option is not used, the changes will be applied at the database level.

Q: Will the database need to be bounced (restarted) after modifying parameters?

A: For some static parameters, a database bounce is required. You can use the --allowBounce option to grant permission for the database to bounce if necessary.

Q: What happens if I don't allow the database to bounce when changing static parameters?

A: If you do not use the --allowBounce option when modifying static parameters, the changes will not take effect until the next manual database restart.

Q: Can I resume modifying parameters if an earlier session was interrupted?

A: No, this command does not support session resumption. You will need to re-run the command from the beginning.

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.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database upgrade command?

A: The dbaascli database upgrade command is used to upgrade an Oracle Database to a new version.

Q: What are the prerequisites for using the dbaascli database upgrade command?

A: You must run the command as the root user and connect to an Exadata Cloud@Customer virtual machine using SSH.

Q: How do I specify the database that needs to be upgraded?

A: Use the --dbname option followed by the name of the database. For example:

--dbname myDatabase

Q: How can I specify the target Oracle home for the upgrade?

A: You can specify the target Oracle home location with the --targetHome option or the name of the target Oracle Database home with the --targetHomeName option.

Q: What does the --standBy option do?

A: The --standBy option is used to upgrade standby databases in Data Guard configurations.

Q: What is the purpose of the --allStandbyPrepared flag?

A: The --allStandbyPrepared flag acknowledges that all required operations on standby databases have been performed before upgrading the primary database in a Data Guard configuration.

Q: What does the --removeGRP option do?

A: The --removeGRP option automatically removes the Guaranteed Restore Point (GRP) backup if the database upgrade is successful.

Q: When should I use the --increaseCompatibleParameter option?

A: Use the --increaseCompatibleParameter option to automatically increase the compatible parameter during the database upgrade, provided the upgrade is successful.

Q: What does the --executePrereqs option do?

A: The --executePrereqs option runs only the pre-upgrade checks to ensure that the database is ready for the upgrade.

Q: How do I handle a failed post-upgrade step?

A: Use the --postUpgrade option to rerun the post-upgrade steps if the initial post-upgrade attempt fails.

Q: What is the purpose of the --revert option?

A: The --revert option reverts the Oracle Database to its original Oracle home, undoing the upgrade.

Q: How can I pass additional arguments specific to DBUA for the upgrade?

A: Use the --upgradeOptions option to pass DBUA-specific arguments for the Oracle Database upgrade. Refer to the Oracle documentation for supported arguments and options.

Q: Is it mandatory to specify the target Oracle home for the upgrade?

A: Yes, you must specify either the --targetHome or --targetHomeName to indicate the target Oracle home for the upgrade.

Q: What should I do if I need to perform a pre-upgrade check but not proceed with the upgrade?

A: Use the --executePrereqs option to perform only the pre-upgrade checks without proceeding with the actual upgrade.

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 Available field.
  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.
  9. View or Download Logs for the move operation
    To view the status of a job or to download the logs for a job, use this procedure.

    To view the status of a job or to download the logs for a job, use this procedure.

    1. Go to the VM Cluster details page of the cluster by clicking the cluster name for which you want to check the job logs for the Grid Infrastructure patch operation. The Grid Infrastructure details page is displayed.
    2. Under Resources, click Associated resources. There will be a resource with the name fsujob<*>. Click the Actions icon (Action menu icon), and then click View log. The View log page is displayed.

    The log is refreshed every two minutes automatically. Click Refresh log to refresh the logs on demand. Click Download log to download the log.

  10. If necessary, you can retry a failed Oracle Grid Infrastructure operation.

    The steps to retry a failed Grid Infrastructure operation are as follows:

    1. Click View or Download Job Logs. Check the job logs for the Apply ExaDB VM Cluster GI Patch operation to understand the reason for the failure. See: Incident Logs and Trace Files.
    2. Resolve the issue. After addressing the underlying issue, you can retry the failed operation.
    3. Retry the Grid Infrastructure updates Operation: To retry the failed Grid Infrastructure patching, initiate the Apply Grid Infrastructure Patch operation again, selecting the same Grid Infrastructure update as in the previous attempt.
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. For more information, see:

To move a database to another 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.
    Note

    When you update the software release of databases by moving them to a target Database Home, Oracle recommends that you use Database Homes, which run the latest (N) to 3 versions from the latest (N-3) release update (RU) versoins. Only database homes provisioned with database Release Updates (RUs) that meet this best practice criterion are available as target homes to move your 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.

  8. View or Download Logs for the move operation.

    To view the status of a job or to download the logs for a job, use this procedure.

    1. Go to the VM Cluster details page of the cluster where the database is configured and click the name of the database for which you want to check the job logs for the move operation. The Database details page is displayed.
    2. Under Resources, click Work requests.
    3. In the Work requests section, click the Update Database Operation for which you want to view or download logs. The Update Database Work request details page is displayed.
    4. Under Resources, click Associated resources. There will be a resource with fsujob<*> name.
    5. Click the Actions icon (Actions icon), and then click View log. The View log page is displayed.

    The log is refreshed every two minutes automatically. Click Refresh log to refresh the logs on demand. Click Download log to download the log.

  9. If necessary, you can retry a failed Database Move operation.

    The steps to retry a failed database move operation are as follows:

    1. Click View or Download Job Logs. Check the job logs for the Database Move to understand the reason for the failure. See: Incident Logs and Trace Files.
    2. Resolve the issue. After addressing the underlying issue, you can retry the failed move operation.
    3. Retry the database move operation. To retry the failed Database Move operation, initiate the Move Database step again, selecting the same target home as in the previous attempt.
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.
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 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.
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.

Was this article helpful?