Maintaining an Exadata Cloud Service Instance

User-Managed Maintenance Updates

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

Oracle-Managed Infrastructure Maintenance Updates

In addition to the maintenance tasks you perform, Oracle manages the patching and updating of all other infrastructure components, including the physical compute nodes (Dom0), the Exadata storage servers, and the Exadata network switches. This is referred to as infrastructure maintenance.

Oracle performs regular maintenance updates to the underlying infrastructure hosting the Exadata Cloud Service virtual servers. This infrastructure includes the physical host servers, the Exadata storage servers, the fabric switches in the Exadata Secure RDMA Fabric, and any control plane components. Maintenance updates may require a restart of the customer-managed guest virtual servers. The frequency of the updates depends on the region type, as follows:

  • Commercial regions: Oracle performs quarterly infrastructure maintenance updates.
  • Government regions: Oracle performs monthly infrastructure maintenance updates.
Important

To minimize disruption to your applications, you can use the OCI Console to specify the maintenance window during which the quarterly infrastructure updates take place.

Oracle releases critical security updates for Exadata on a monthly schedule. If updates for severe vulnerabilities to the infrastructure software are available, Oracle will attempt to apply those critical updates within 21 days of their availability. In most cases, critical security updates are performed while your Exadata system is online, and have no impact on the database servers running database workloads. Critical storage server security updates are applied in a rolling manner, and are not expected to affect database availability. Critical security updates are applied automatically, and cannot be deferred or scheduled. If a monthly critical security update will affect a running database server, Oracle will notify you prior to applying the update.

Overview of the Quarterly Infrastructure Patching Process

Infrastructure maintenance begins with patching of the Exadata compute nodes. By default, infrastructure compute nodes are updated in a rolling fashion, where a single node is shut down, patched, and then brought back online while other nodes remain operational. This process continues until all nodes are patched.

Optionally, for any scheduled infrastructure maintenance, you can configure the patching to take place in a non-rolling fashion. For the non-rolling option, all nodes are shut down at the same time and patched. Non-rolling patching reduces the total amount of time that infrastructure maintenance takes, but does involve system down time. Non-rolling patching must be set for each individual maintenance event, and cannot be set as the default patching method. See To set the node patching order for a scheduled infrastructure maintenance run for instructions.

After compute node patching completes, Oracle patches the storage nodes. Storage server patching does not impact compute node availability.

Oracle recommends reviewing the documentation on workload management, application continuity, and client failover best practices to reduce the potential for an outage with your applications. By following the guidelines in the documentation, the impact of infrastructure patching will be only minor service degradation due to connection loss as compute nodes are sequentially patched.

Oracle recommends that you follow the Maximum Availability Architecture (MAA) best practices and use Oracle Data Guard to ensure the highest availability for your critical applications. For databases with Oracle Data Guard enabled, Oracle recommends that you separate the patching windows for the infrastructure instances running the primary and standby databases, and perform a switchover prior to the maintenance operations for the infrastructure instance hosting the primary database, to avoid any impact to your primary database during infrastructure patching.

Note

Regardless of node patching method (rolling or non-rolling), Oracle does not verify that all database services and pluggable databases (PDBs) are available after a node is brought back online. This is because the availability of services and PDBs after patching can depend on the application service definition.

Approximate Times for Exadata Infrastructure Patching

Exadata Shape Configuration Rolling Patching Method (Approximate Time) Non-Rolling Patching Method (Approximate Time)

Quarter rack

5-6 hours 4 hours

Half rack

10 hours 4 hours

Full rack

20 hours 4 hours
Flexible shapes (X8M and higher) 1.5 hours per compute node + 1 hour per storage node 4 hours
Tip

Do not perform major maintenance operations on your databases or applications during the patching window, as these operations could be impacted by the rolling patch operations.

Scheduling Oracle-Managed Quarterly Infrastructure Updates

Exadata Cloud Service infrastructure updates are released on a quarterly basis for commercial regions, and monthly for government regions. You can set a maintenance window to determine the time your infrastructure maintenance will begin. You can also view scheduled maintenance runs, view the maintenance history of your Exadata Cloud Service instance, and manage maintenance contacts in the Oracle Cloud Infrastructure Console on the Exadata Infrastructure Details page. For more information:

Oracle may update your system apart from the these regular updates to apply time-sensitive changes such as security updates. While you cannot opt out of these infrastructure updates, Oracle alerts you in advance through the Cloud Notification Portal if there will be any impact to your system availability.

Monitoring Patching Operations Using Lifecycle State Information

The lifecycle state of your cloud Exadata infrastructure resource enables you to monitor when the patching operations begin and end. In the Oracle Cloud Infrastructure Console, you can see lifecycle state details messages on the Exadata Infrastructure Details page when a tool tip is displayed beside the Status field. You can also access these messages using the ListCloudExadataInfrastructuresAPI, and using tools based on the API, including SDKs and the OCI CLI.

During patching operations, you can expect the following:

  • If you specify a maintenance window, then patching begins at your specified start time. The patching process starts with a series of prerequisite checks to ensure that your system can be successfully patched. These checks take approximately 30 minutes to complete. While the system is performing the checks, the infrastructure resource's lifecycle state remains "Available," and there is no lifecycle state message.

    For example, if you specify that patching should begin at 8:00 a.m., then Oracle begins patching operations at 8:00, but the infrastructure resource's lifecycle state does not change from "Available" to "Maintenance in Progress" until approximately 8:30 a.m.

  • When Exadata compute node patching starts, the infrastructure resource's lifecycle state is "Maintenance in Progress", and the associated lifecycle state message is "The underlying infrastructure of this system (dbnodes) is being updated."
  • When cell storage patching starts, the infrastructure resource's lifecycle state is "Maintenance in Progress", and the associated lifecycle state message is "The underlying infrastructure of this system (cell storage) is being updated and this will not impact Database availability."
  • After cell patching is complete, the networking switches are patched one at a time, in a rolling fashion.
  • When patching is complete, the infrastructure resource's lifecycle state is "Available", and the Console and API-based tools do not provide a lifecycle state message.