Exadata Fleet Update Overview
Learn how to update all chosen components in the database stack in a single maintenance window
- Exadata Fleet Update Overview
Exadata Fleet Update provides you with a way to automate database cloud fleet updates without custom development. It also orchestrates updates across the stack in a single maintenance window. - Terms Associated with Exadata Fleet Update
Learn about what terms are used with Exadata Fleet Update. - Behavior of Exadata Fleet Update Service While Patching a Database in an Oracle Data Guard Environment
Learn about what terms are used with Exadata Fleet Update.
Exadata Fleet Update Overview
Exadata Fleet Update provides you with a way to automate database cloud fleet updates without custom development. It also orchestrates updates across the stack in a single maintenance window.
Exadata Fleet Update leverages the fleet update capabilities of Fleet Patching and Provisioning (FPP). Exadata Fleet Update offers a simple and uniform "look and feel" for operations across:
- Multiple database versions: All Oracle Database versions supported in the Cloud.
- Multiple database types: Oracle Real Application Clusters (Oracle RAC).
- Dynamic runtime environments: Exadata Fleet Update adjusts to shifting runtime environments such as instance failovers to other nodes, service failovers, unavailable nodes, and so on.
-
Resume: When patching across a cluster of nodes and/or a set of distributed database instances, if a failure occurs, it is difficult for the Fleet Administrators or Database Administrators to not only determine the cause of failure and resolve the issue such as
/tmp
space running low, but to figure out how far the patching has progressed and at what step the patching needs to be resumed in order to finish up the rest of the patching.Exadata Fleet Update comes to the rescue of Database Administrators. Internally, Exadata Fleet Update keeps checkpoints of every step of the patching process it performs, and records the results. You can retry the same operation from the console or by running the same CLI/API call after the original failure is resolved. Exadata Fleet Update tracks through these checkpoints, skips all of the successful steps, and resumes actions from the last failure point observed.
-
Rollback: When there is a failure in patching for various reasons, you may want to revert to the original software home. Exadata Fleet Update offers a very convenient and intuitive way of allowing you to perform a rollback operation by simply interchanging the source and target on the API. Exadata Fleet Update is able to internally determine that a rollback is needed and executes the required actions automatically.
Parent topic: Exadata Fleet Update Overview
Terms Associated with Exadata Fleet Update
Learn about what terms are used with Exadata Fleet Update.
Collection: A group of Exadata Fleet Update target resources, Oracle Database and Grid Infrastructure to patch.
- Creating: Collection is being created.
- Updating: Collection member targets or attributes are being updated.
- Active: Collection is ready to use and create Maintenance Cycle.
- Deleting: Collection deletion in progress.
- Failed: Collection creation has failed.
Targets: Exadata Infrastructure resources, Grid Infrastructure, and Oracle Database. Targets can be added from multiple compartments to a Collection.
Maintenance Cycle: A maintenance cycle represents a full software update event to a specific target version. A maintenance cycle will include actions to run prechecks, stage software, and apply the software update. The logs and trace files associated with the jobs performing these actions are made available to Oracle operations to identify, investigate, and resolve issues. Each Collection can have zero or more Maintenance Cycles. However, only one maintenance cycle can be active at a time for a Collection.
- Active: Maintenance Cycle is created.
- Updating: Attributes of a Maintenance Cycle are being updated.
- Maintenance In Progress: An action is running the Maintenance Cycle.
- Needs Attention: Indicates that a warning has been identified but has not yet been adequately addressed or resolved. You can either ignore the warning and proceed with the next action, or address the reported warnings and then retry the action marked as "needs attention."
- Succeeded: Apply update completed successfully. The Cleanup action would become available.
- Precheck (stage): Prechecks are run to identify issues such as software dependencies, one-off patch conflicts that need to be re-applied post-patching, and so on that may prevent the infrastructure maintenance from succeeding. Precheck can be run as part of Stage software and Apply update actions. It can also be run independently prior to running Stage software and Apply update actions. Note that running prechecks do not impact database availability.
- Stage software: Stages the target home software for the version or image selected on the Guest VMs in the collection. Note that running Stage software action does not impact database availability.
- Precheck (apply): Prechecks are run to identify issues such as software dependencies, one-off patch conflicts that need to be re-applied post-patching, and so on that may prevent the infrastructure maintenance from succeeding. Precheck can be run as part of Stage software and Apply update actions. It can also be run independently prior to running Stage software and Apply update actions. Note that running prechecks do not impact database availability.
- Apply update: Updates all Grid Infrastructure or Oracle Database targets in a collection. Staging software must have been completed successfully before applying the updates. The maintenance method and how the application connects to the database, using Application Continuity or not, determine whether an update impacts availability. Databases not being updated shouldn't have an impact on availability.
- Cleanup: Applies only if the Apply update action succeeds on
a target and no Database instances or Grid Infrastructure is running from the
Database or Grid Home. The Cleanup action will not delete the source Database
Home if it is not empty. In the console, the associated job would have a
Needs Attention status with a tooltip that states the Database Home
was not deleted because it's not empty.
Optionally, after the Maintenance Cycle completes successfully, you can manually delete the source Database Home by first manually deleting all the databases within it.
- Rollback and Remove targets: Applies only if Apply update fails on a target.
- Scheduled: An action is scheduled to run.
- Canceled: A scheduled action run is canceled.
- In Progress: A scheduled action runs or when an action is run on demand.
- Needs Attention: Indicates that a warning has been identified but has not yet been adequately addressed or resolved. You can either ignore the warning and proceed with the next action, or address the reported warnings and then retry the action marked as "needs attention."
- Succeeded: All jobs associated with a scheduled action or an action run on demand complete successfully.
- Failed: One or more jobs associated with a scheduled action or an action run on demand fail.
Jobs: Created to do the background processing initiated by the maintenance cycle actions. Jobs will allow visibility into the progress, associated messages, and errors of an action for the respective target.
Database Software Images: Customized Oracle Database software configuration that includes your chosen updates (Release Updates (RUs) and Monthly Recommended Patches (MRP)), and optionally, a list of one-off (or interim) patches or an Oracle Home inventory file. This reduces the time required to provision and configure your databases, and makes it easy for your organization to create an approved "gold image" for developers and database administrators.
- One node at a time (rolling): (Default) Database instances are updated on one VM in the cluster at a time while the other instances remain operational.
- Smart batch (rolling): Database instances are updated on one or more VMs at a time. VMs are batched based on the database services configured. This ensures that all services remain available as long as they are configured on multiple nodes while minimizing the total number of batches needed.
- Non-rolling: All database instances across all VMs in the cluster are updated in parallel incurring full downtime.
- 50/50 (rolling):
The
database instances on half of the VMs are updated in one batch, while the other
half in another batch. The two batches are determined by the configuration of
the database services. This ensures that all services remain available.
- Enable one batch at a time: Updates are applied to
one batch at a time.
After applying the update to the first batch, the Apply action will wait to be continued before starting the second batch.
- Enable one batch at a time: Updates are applied to
one batch at a time.
Maximum drain timeout (in seconds):: Drain Timeout in seconds between nodes. This would be used during a rolling update to provide time for database connection relocation. The drain timeout used will be the maximum of this value or the maximum configured drain timeout of the services running on a particular instance. Default is 600.
Infrastructure Fleet Admin: Manages one or more cloud Exadata Infrastructures in the customer OCI tenancy. Has privileges to view and manage these infrastructures in one or more compartments.
VM Cluster Fleet Admin: Manages one or more Exadata Cloud VM Clusters and the Exadata System and GI software on the VMs. Has privileges to view and manage these VM Clusters.
DB Fleet Admin: Manages one or more databases across one or more VM Clusters.
Parent topic: Exadata Fleet Update Overview
Behavior of Exadata Fleet Update Service While Patching a Database in an Oracle Data Guard Environment
Learn about what terms are used with Exadata Fleet Update.
To patch databases in an Oracle Data Guard Configuration, apply a software update to the standby database before applying a software update to the primary database.
Peer databases (primary and standby) cannot be included in the same Exadata Fleet Update Collection.
The patches must be Data Guard first installable. It is imperative to specify the exact same patches in the primary and standby maintenance cycles.
For more information, see:
- Use Oracle Data Guard with Exadata Database Service on Cloud@Customer
- Use Oracle Data Guard with Exadata Cloud Infrastructure
Procedure
- Create an Exadata Fleet Update Collection of standby databases, if such a
Collection does not already exist.
Create a separate Exadata Fleet Update Collection of primary databases, if such a Collection does not already exist.
In the case of cross-region Oracle Data Guard configuration, the Exadata Fleet Update Collections will exist in different regions.
For more information, see Create a Collection.
- Create a Maintenance Cycle for the Exadata Fleet Update Collection of standby
databases, specifying the desired goal version or database software image, and
complete Exadata Fleet Update Stage Action.
For more information, see:
- Create a Maintenance Cycle for the Exadata Fleet Update Collection of primary
databases, specifying the identical goal version or database software image, and
complete Exadata Fleet Update Stage Action.
For more information, see:
- Schedule Apply Exadata Fleet Apply Action for the Exadata Fleet Update Collection of standby databases.
- Upon the successful completion of Exadata Fleet Update Apply action for the Exadata Fleet Update Collection of standby databases, schedule Exadata Fleet Update Apply Action for the Exadata Fleet Update Collection of primary databases.
Parent topic: Exadata Fleet Update Overview