About Infrastructure Maintenance

Oracle periodically updates all Oracle-managed infrastructure components on Oracle Data Infrastructure Cloud@Customer.

Oracle uses automated processes that follow best practices to apply product fixes and security fixes. These updates help protect data and support database availability, integrity, security, and Oracle Cloud compliance requirements. Automated maintenance also reduces the effort required to maintain the infrastructure.

Oracle-managed components can include physical server hosts, storage, network cards, Integrated Lights Out Management (ILOM) interfaces, and control plane Proxy Services VMs.

Oracle performs quarterly maintenance every three months and can include product fixes, enhancements, and security fixes.

Oracle provides advance notice for scheduled maintenance except in rare exceptional circumstances. Oracle also provides notifications for corresponding recommended updates for VMs in the VM Cluster.

Oracle schedules maintenance to preserve service availability when possible. Some updates can temporarily affect performance and throughput while individual components are unavailable. For example, server patching typically requires a restart. Oracle restarts servers in a rolling sequence when possible so the service remains available during the update process. Each server remains unavailable for a short time during restart, which reduces overall service capacity. Plan mitigations when applications cannot tolerate restarts. For example, shut down an application during server patching.

Quarterly maintenance

Oracle minimizes the impact of quarterly maintenance on your applications by using rolling maintenance operations that preserve database availability throughout the update process. Applications designed for high availability automatically and transparently migrate database connections to available instances without disruption, eliminating the need to schedule downtime.

Oracle schedules maintenance according to Oracle-defined maintenance policies. You can reschedule maintenance if unexpected business requirements arise.

By default, infrastructure maintenance is performed using rolling updates, starting with servers and then updating the storage.

Servers are updated one at a time, with at most one server offline at any time. For each host, the VMs are shut down, the server is updated and restarted, and then the VMs are started, while other servers remain operational. This approach does not impact applications designed for high availability, but older applications that are not written to handle rolling instance restarts can be impacted. This process continues until both the servers are updated.

After server maintenance is complete, storage maintenance begins. Storage disks are updated one at a time. Patching storage has no effect on database availability and therefore has no impact on your applications. However, rolling storage maintenance can reduce I/O performance while a storage disk is offline (reducing available I/O capacity) and while it is resynchronized after it returns to service (with small overhead on the Data Infrastructure servers). Properly sizing the database and storage to accommodate the additional work on servers not under maintenance will minimize, or eliminate, any performance impact.

While databases are expected to be available during rolling maintenance, automated maintenance verifies that Oracle Clusterware is running but does not verify that all database services and Pluggable Databases (PDBs) are available after a server is brought back online. Availability of database services and PDBs after maintenance can depend on the service definition. For example, a database service configured with preferred and available nodes may be relocated during maintenance and may not automatically relocate back to its original node after maintenance completes. Oracle recommends reviewing the documentation on achieving continuous availability for your applications to reduce potential impact. By following the guidelines, the impact of infrastructure maintenance should be limited to minor service degradation as servers are updated sequentially.

Oracle recommends following Maximum Availability Architecture (MAA) best practices and using Data Guard to ensure the highest availability for critical applications. For databases with Data Guard enabled, Oracle recommends separating the maintenance windows for the Data Infrastructures running the primary and standby databases. You may also perform a switchover before maintenance on the Data Infrastructure hosting the primary database to avoid impact on your primary database during infrastructure maintenance.

Prechecks are performed on Oracle Data Infrastructure Cloud@Customer infrastructure components before the maintenance window begins to identify issues that could prevent maintenance from succeeding. The infrastructure and all components remain online during prechecks. An initial precheck runs approximately two weeks before maintenance starts, and another runs approximately 24 hours before maintenance starts. If prechecks identify an issue that requires rescheduling, a notification is sent to the users who have subscribed to notifications.

Minimizing Maintenance Windows

• To minimize the number of maintenance windows (you have to negotiate those with end users), schedule the quarterly maintenance at the same time. The security maintenance will be blocked. The quarterly maintenance will update the Data Infrastructure servers in a rolling manner and will most likely skip the storage server. The security maintenance will follow up immediately and update the Data Infrastructure servers online and the storage servers in a rolling manner. The result is a single database and storage server restart in a single maintenance window.

• There are two exceptions to this.

  • If the quarterly maintenance contains the same storage server release, the quarterly maintenance will apply the storage server update, and the security maintenance will be skipped. From your perspective, this is still a single rolling restart in a single maintenance window.
  • The currently installed release on the storage servers is older than that contained in the quarterly maintenance, which in turn is older than that in the security maintenance. That would cause the quarterly maintenance to update the storage, and then the security maintenance to do it as well. This can only happen if you skipped a prior month’s security maintenance, because it requires the current image to be at least 2 months out of date. In such a scenario, you may want to schedule the security maintenance first and then the quarterly maintenance. This would result in one storage server restart, but two distinct maintenance windows — the first for the security maintenance, and then later the quarterly maintenance.
• If the Data Infrastructure is provisioned before Oracle schedules the security maintenance, then it will be eligible for security maintenance.