Oracle Cloud Infrastructure Documentation

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.

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.
In addition, two key specialized characteristics of Exadata Fleet Update offer major intrinsic benefits:

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

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.

Collection lifecycle states:
  • 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.

Maintenance Cycle lifecycle states:
  • 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.
Action: A Maintenance Cycle has associated actions that can be scheduled to run or run on demand.
  • 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.
Action lifecycle states:
  • 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.

Maintenance method: Maintenance method determines how VMs in a VM Cluster are batched and which nodes are updated together when applying the software updates.
  • 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.

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.

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.

Note

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:

Procedure

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

  2. 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:
  3. 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:
  4. Schedule Apply Exadata Fleet Apply Action for the Exadata Fleet Update Collection of standby databases.
  5. 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.