Maintaining an Exadata DB System
User Managed Maintenance Updates
Maintaining a secure Exadata DB system in the best working order requires you to perform the following tasks regularly:
- Patching the Oracle Grid Infrastructure and Oracle Database software on the Exadata compute nodes. See Patching an Exadata DB System Manually and Oracle Clusterware Configuration and Administration for information and instructions.
- Updating the operating system and the tooling on the compute nodes. See Updating an Exadata DB System for information and instructions.
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 InfiniBand switches. This is referred to as DB system infrastructure maintenance.
Overview of the Infrastructure Patching Process
Infrastructure maintenance begins with patching of the Exadata compute nodes. Compute nodes are updated in a rolling fashion, with a single node being shut down, patched, and then brought back online while other nodes remain operational. This process continues until all nodes are patched. After compute node patching completes, Oracle patches the storage nodes. Storage server patching does not impact compute node availability.
Note that while databases are expected to be available during the patching process, Oracle does not verify that all database services and pluggable databases are available after a node is brought back online, as these can depend on the application service definition. 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 documentation's guidelines, 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 Data Guard to ensure the highest availability for your critical applications. For databases with 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. This allows you to avoid any impact to your primary database during infrastructure patching.
The approximate time for patching operations is as follows:
- Quarter rack: 5 hours
- Half rack: 10 hours
Full rack: 20 hours
Typically, Exadata compute nodes require 1.5 hours each for patching, and storage servers require 1 hour each.
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 Infrastructure Updates
Exadata Cloud Service updates are released on a quarterly basis. You can set a maintenance window to determine the time your quarterly infrastructure maintenance will begin. You can also view scheduled maintenance runs and the maintenance history of your DB system in the Oracle Cloud Infrastructure Console. For more information, see the following:
- To set the automatic maintenance schedule for Exadata DB system infrastructure
- To view or edit the time of the next scheduled maintenance for Exadata DB system infrastructure
- To view the maintenance history of Exadata DB system infrastructure
In exceptional cases, Oracle might need to update your system apart from the regular quarterly 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 to help you plan for them.
Monitoring Patching Operations Using Lifecycle State Information
The lifecycle state of your DB system allows you to monitor when the patching of your DB system begins and ends. In the Oracle Cloud Infrastructure Console, you can see lifecycle state details messages on the DB System Details page when a tooltip is displayed beside the Status field. You can also access these messages using the ListDbSystems API, and using tools based on the API, including SDKs and the OCI CLI. The following OCI CLI command allows you to list your DB systems:
oci db system get --db-system-id <ocid>.
During patching operations, you can expect the following:
If you specify a maintenance window, 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 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., Oracle begins patching operations at 8:00, but your system'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 DB system lifecycle state is "Maintenance in Progress", and the associated lifecycle state message is "The underlying infrastructure of this dbsystem (dbnodes) is being updated."
- When cell storage patching starts, the DB system lifecycle state is "Maintenance in Progress", and the associated lifecycle state message is "The underlying infrastructure of this dbsystem (cell storage) is being updated and this will not impact Database availability."
- After cell patching is complete, the Infiniband switches are patched one at a time, in a rolling fashion.
- When patching is complete, the DB system lifecycle state is "Available", and the Console and API-based tools do not provide a lifecycle state message.
For More Information
For information about the update policy, and details such as the duration and impact on your system's availability and performance, see Oracle Database Cloud Exadata Service Supported Software Versions and Planning for Updates.