Oracle performs the updates to all of the Oracle-managed infrastructure components on Oracle Exadata Database Service on
Cloud@Customer.
Oracle performs periodic maintenance on your Exadata Cloud@Customer infrastructure to ensure it is free of potential issues that could affect database availability, integrity, and security. Updating the software running on the infrastructure with the latest product and security fixes protects your data and the overall compliance of the Oracle Cloud. These updates are performed in an automated way and include all the best practices, relieving you of the need to invest any effort in maintaining your infrastructure. Oracle updates include the physical database server hosts, storage servers, network fabric switches, management switches, power distribution units (PDUs), integrated lights-out management (ILOM) interfaces, and control plane servers.
Oracle performs two types of infrastructure maintenance:
Quarterly maintenance is applied every three months and can include product fixes, enhancements, and security fixes.
Monthly maintenance only applies critical security fixes that can be applied online to ensure components are maintained at the highest security standards with any security vulnerabilities fixed as soon as possible.
Quarterly Maintenance
Oracle minimizes the impact of quarterly maintenance on your applications using rolling maintenance operations, preserving database availability throughout the update process. Rolling maintenance reboots each database server, one at a time, with at most one server offline at any time. Applications designed for high availability automatically and transparently migrate their database connections between available database instances without disruption, eliminating the need for scheduling downtime. Storage server updates are also applied in a rolling manner. Rebooting storage servers has no effect on the database service, and thus has no impact on your applications.
Oracle allows you to fully control quarterly maintenance schedules, so you can schedule maintenance during a period which will have the least impact on your business users. You have full control and visibility over when quarterly maintenance will be applied, even allowing you to schedule the maintenance across multiple maintenance windows. Scheduling is simplified using a Maintenance Scheduling Policy, which aims to standardize scheduling across the fleet to ensure consistency and efficiency. By defining the policy once and applying it to multiple resources, it streamlines the scheduling process. You may also reschedule maintenance should unexpected business issues occur.
Monthly Security Maintenance
Monthly security maintenance is performed on the database servers online, with no reboot, and no impact to your applications. Monthly updates are applied to storage servers in a rolling manner, also with no impact to your applications.
Monthly security maintenance can also be scheduled at a specific time during the month, albeit in a single maintenance window. Oracle will publish a schedule for monthly maintenance at least one week prior to start of the maintenance period, and you can reschedule if required.
You may manage contacts who are notified regarding infrastructure maintenance, set a maintenance window to determine the time your quarterly infrastructure maintenance will begin, and also view scheduled maintenance runs and the maintenance history of your Exadata Cloud@Customer in the Oracle Cloud Infrastructure Console. For details regarding the infrastructure maintenance process and configuring the maintenance controls refer to the following:
Infrastructure Maintenance Contacts Maintenance contacts are required for service request based communications for hardware replacement and other maintenance events.
Maintenance Scheduling Policy Learn how to use the OCI Console to configure and manage maintenance scheduling policies. If a maintenance scheduling policy is used, all the scheduling preferences for the infrastructure maintenance are derived from the policy.
Using the Console to Configure Oracle-Managed Infrastructure Updates Full Exadata infrastructure software updates are scheduled on a quarterly basis. In addition, important security updates are scheduled monthly. While you cannot opt-out of these infrastructure updates, Oracle alerts you in advance through the Cloud Notification Portal and allows scheduling flexibility to help you plan for them.
About Oracle Managed Oracle Exadata Database Service on
Cloud@Customer Infrastructure Maintenance Updates
🔗
Oracle performs patches and updates to all of the Oracle-managed system components on Oracle Exadata Database Service on
Cloud@Customer.
In all but rare exceptional circumstances, you
receive advance communication about these updates to
help you plan for them. If there are corresponding
recommended updates for your VM cluster virtual
machines (VMs), then Oracle provides notifications
about them.
Wherever possible, scheduled updates are performed in a manner
that preserves service availability throughout the
update process. However, there can be some
noticeable impact on performance and throughput
while individual system components are unavailable
during the update process.
For example, database server patching typically requires a
reboot. In such cases, wherever possible, the
database servers are restarted in a rolling manner,
one at a time, to ensure that the service remains
available throughout the process. However, each
database server is unavailable for a short time
while it restarts, and the overall service capacity
diminishes accordingly. If your applications cannot
tolerate the restarts, then take mitigating action
as needed. For example, shut down an application
while database server patching occurs.
Overview of Monthly Security Maintenance Security maintenance, performed alongside the quarterly maintenance, is executed in months when important security updates are needed and includes fixes for vulnerabilities across all CVSS scores.
Overview of the Quarterly
Infrastructure Maintenance Process 🔗
By default, infrastructure maintenance updates the Exadata database server
hosts in a rolling fashion, followed by updating the storage servers.
Rolling infrastructure maintenance begins with the Exadata database server hosts. For the rolling maintenance method, database servers are updated one at a time. Each of the database server host's VMs is shut down, the host is updated, restarted, and then the VMs are started, while other database servers remain operational. This rolling maintenance does not impact applications designed for high availability. Older applications not written to handle a rolling instance restart can be impacted. This process continues until all servers are updated.
After database server maintenance is complete, storage server maintenance begins. For the rolling maintenance method, storage servers are updated one at a time and this does not impact database or application availability. However, the rolling storage server maintenance can result in reduced IO performance as storage servers are taken offline one at a time (reducing available IO capacity) and resynced when brought back online (small overhead on database servers). Properly sizing the database and storage infrastructure to accommodate increased work distributed to database and storage servers that are not under maintenance will minimize (or eliminate) any performance impact.
You can also choose non-rolling maintenance to update database and storage servers. The non-rolling maintenance method first updates your storage servers at the same time, then your database servers at the same time. Although non-rolling maintenance minimizes maintenance time, it incurs full system downtime while the storage servers and database servers are being updated.
Note that while databases are expected to be available during the rolling maintenance
process, the automated maintenance verifies 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. The availability of database services and PDBs after
maintenance can depend on the application service definition. For example, a database
service, configured with certain preferred and available nodes, may be relocated during
the maintenance and wouldn't automatically be relocated back to its original node after
the maintenance completes. Oracle recommends reviewing the documentation on
Achieving Continuous Availability for Your Applications on Exadata
Cloud Systems to reduce the potential for impact to your applications. By following the
documentation's guidelines, the impact of infrastructure maintenance will be only minor
service degradation as database servers are sequentially updated.
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 maintenance windows for the infrastructure instances running the primary
and standby databases. You may also perform a switchover prior to the maintenance
operations for the infrastructure instance hosting the primary database. This allows you
to avoid any impact on your primary database during infrastructure maintenance.
Prechecks are performed on the Exadata Cloud@Customer infrastructure components prior to the start of the maintenance window. The goal of the prechecks is to identify issues that may prevent the infrastructure maintenance from succeeding. The Exadata infrastructure and all components remain online during the prechecks. An initial precheck is run approximately two weeks prior to the maintenance start and another precheck is run approximately 24 hours prior to maintenance start. If the prechecks identify an issue that requires rescheduling the maintenance notification is sent to the maintenance contacts.
The time taken to update infrastructure components varies depending on the
number of database servers and storage servers in the Exadata infrastructure, the
maintenance method, and whether custom action has been enabled. The approximate times
provided are estimates. Time for custom action, if configured, is not included in the
estimates below. Database server maintenance time may vary depending on the time
required to shutdown each VM before the update and then start each VM and associated
resources after the update of each node before proceeding to the next node. The storage
server maintenance time will vary depending on the time required for the ASM rebalance,
which is not included in the estimates below. If issues are encountered during
maintenance this may also delay completion beyond the approximate time listed. In such a
situation, if Oracle cloud operations determine resolution would extend beyond the
expected window, they will send a notification and may reschedule the maintenance.
Security maintenance, performed alongside the quarterly maintenance, is executed in months when important security updates are needed and includes fixes for vulnerabilities across all CVSS scores.
Note
For more information about the CVE release matrix, see Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1).
To view the CVE release matrix specific to an Exadata Infrastructure version, click the Exadata version, for example, Exadata 23. Version-specific CVE release matrices are listed in the Notes column of the table.
Security maintenance, when needed, is scheduled to be applied during a 21-day window that begins between the 18th-21st of each month and will run till the 9th-12th of the next month. Customers will receive notification of the proposed schedule at least 7 days before the start of the monthly maintenance window and can reschedule monthly maintenance to another date in the window if desired. The monthly security maintenance process updates the physical database servers to fix critical security vulnerabilities and critical product issues. Monthly maintenance also updates storage servers to an Exadata Storage Software image that resolves known security vulnerabilities and product issues. No updates are applied to the customer-managed guest VMs. Monthly maintenance also updates storage servers to an Exadata Storage Software image that resolves known security vulnerabilities and product issues.
Updates to database servers are applied online via Ksplice technology, and have no impact to workloads running on the compute (database) servers, as database server security updates are applied online to the host server while your VM and all processes within the VM, including databases, remain up and running. Servers and VMs are not restarted. Updates to storage servers are applied in a rolling fashion. As with quarterly maintenance, the impact of rebooting storage servers should be minimal to applications.
While updating your services infrastructure, some operations including memory, and storage scaling, operating system and Grid Infrastructure patching (including prechecks), and elastic expansion of compute and storage servers may be blocked.
Note
CPU scaling and VM startup/shutdown are the only operations supported during monthly infrastructure maintenance.
Please plan to defer these operations until after the updates are complete. . If you attempt an affected operation, the console will notify you of the ongoing security updates. No software is updated in the guest VMs.
Understanding Monthly and Quarterly Maintenance in the Same Month 🔗
Special considerations are made when both quarterly and monthly security maintenance are scheduled to run in the same month. Quarterly maintenance will reapply any security fixes already applied by security maintenance, and neither quarterly nor monthly maintenance will apply a storage server update if the existing storage server version is the same or newer than the version contained in the update.
The contents of the updates applied during quarterly maintenance are determined at the start of the maintenance quarter and use the latest Exadata release from the month prior to the start of the maintenance quarter. If any additional security fixes are available at that time, those updates are included in the quarterly maintenance. That image is then used throughout the quarter. For example, the January release is used for quarterly maintenance in Feb, March, and April.
When quarterly maintenance is applied it is possible there are security updates previously installed on the database servers are not included in the quarterly maintenance release to be applied. In that case, the automation will apply the same security fixes to new release installed by the quarterly maintenance so there will not be any regression in security fixes. If the current image on the storage server is the same or newer than that to be applied by the quarterly or monthly security maintenance, that maintenance will be skipped for the storage servers.
If quarterly maintenance is scheduled within 24 hours of the time the monthly is scheduled, the scheduled monthly maintenance will be skipped, and the monthly update will instead be applied immediately following the quarterly maintenance.
When scheduled at the same time, the monthly update is executed immediately following the completion of the quarterly maintenance.
If monthly maintenance is scheduled to begin 0-24 hours ahead of the quarterly maintenance, then the monthly maintenance will not execute as scheduled, but instead, wait and be executed immediately following the quarterly maintenance. If the quarterly maintenance is subsequently rescheduled, then the monthly security maintenance will begin immediately. Oracle, therefore, recommends scheduling quarterly and monthly maintenance at the same time. As a result, if you reschedule the quarterly at the last moment, the monthly maintenance will run at the scheduled time instead of immediately upon editing the schedule. You can also reschedule the monthly security maintenance when rescheduling the quarterly maintenance as long as you keep the monthly within the current maintenance window. Monthly maintenance can be rescheduled to another time in the maintenance window, but cannot be skipped.
Monthly Security Maintenance before Quarterly Maintenance
To apply security maintenance before quarterly maintenance, reschedule the monthly security maintenance to occur more than 24 hours prior to the quarterly maintenance. The security maintenance will online apply security patches to the database servers with no impact to applications, and apply an update to the storage servers with minimal to no impact (may be slight performance degradation) on applications. The quarterly maintenance will follow as scheduled, and will perform rolling maintenance on the database servers, which will impact applications not written to handle a rolling reboot. As part of the quarterly maintenance, it will apply the same security updates to the database server that are already installed on the system (no security regression).
If you are concerned about getting the latest security updates applied, schedule the monthly security maintenance to run after the new monthly maintenance window opens (usually on the 21st of the month).
The impact of the monthly security maintenance rebooting the storage servers should be minimal, so impact to the applications during this month will only be due to the restart of the database servers during the quarterly maintenance. However, if you must coordinate a maintenance window with your end users for the security maintenance, this will require two maintenance windows.
Quarterly Maintenance before Monthly Security Maintenance
To run the quarterly maintenance before the monthly security maintenance, reschedule the security maintenance to run no earlier than 24 hours before the quarterly maintenance is scheduled to start. The security maintenance will be deferred until the quarterly maintenance is completed. The quarterly maintenance will perform rolling maintenance on the database servers, which will impact applications not written to handle a rolling reboot. The quarterly maintenance may or may not skip the storage server patching. That depends on if it is newer or older than the release currently installed. In most cases, the version installed should be newer than the version associated with the quarterly maintenance. Exceptions to this rule may occur if it is the first month of a maintenance quarter, or you skipped the security maintenance in one or more prior months. The security maintenance will run either immediately after the quarterly maintenance is completed, or when scheduled, whichever is later. It will apply online updates to the database servers (no application impact) and will likely update the storage servers in a rolling manner. In some corner cases. the quarterly maintenance may contain the same storage server release as the security maintenance and the security maintenance storage server updates will be skipped.
The impact to end users of running the quarterly maintenance before the security maintenance should be roughly the same as running the security maintenance first. The quarterly maintenance will be a disruptive event, but the security maintenance rebooting the storage servers should cause minimal disruption, and the security maintenance is applied to the database servers online. However, if you must coordinate a maintenance window with your end users for the security maintenance, this will require two maintenance windows. You can schedule those two maintenance windows to run back-to-back, to appear as single maintenance window to end users. To do this, reschedule the security maintenance to start at the same time (or up to 24 hours prior) as the quarterly maintenance. The security maintenance will be deferred until the quarterly maintenance is completed. Assuming you have been regularly applying monthly security maintenance, the storage servers will be skipped by the quarterly maintenance and will be updated by the security maintenance immediately upon the completion of the quarterly maintenance.
Minimizing Maintenance Windows
To minimize the number of maintenance windows (you have to negotiate those with end users), schedule the quarterly maintenance and monthly maintenance at the same time. The security maintenance will be blocked. The quarterly maintenance will update the database servers in a rolling manner and will most likely skip the storage server. The security maintenance will follow up immediately and update the database 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. 1. If the quarterly and monthly maintenance contain 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 reboot in a single maintenance window. 2. 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 reboot, but two distinct maintenance windows — the first for the security maintenance, and then later the quarterly maintenance.
To minimize the impact to your end users, always apply the monthly security updates, and in months where both are scheduled, schedule them at the same time.
Note
If the Exadata Infrastructure is provisioned before Oracle schedules the security maintenance, then it will be eligible for security maintenance.
Any time before the scheduled monthly Exadata Infrastructure maintenance, you can reschedule it.
Maintenance contacts are required for service request based communications
for hardware replacement and other maintenance events.
Add a primary maintenance contact and optionally add a maximum of nine secondary
contacts. Both the primary and secondary contacts receive all notifications
about hardware replacement, network issues, and software maintenance
runs.
You can promote any secondary contacts as the primary anytime you want. When you
promote a secondary contact to primary, the current primary contact will be
demoted automatically to secondary.
For more information, see: Using the Console to Create
Infrastructure and Managing Infrastructure Maintenance
Contacts.
Learn how to use the OCI Console to configure and manage maintenance scheduling policies. If a maintenance scheduling policy is used, all the scheduling preferences for the infrastructure maintenance are derived from the policy.
The Maintenance Scheduling Policy aims to standardize scheduling across the fleet, ensuring consistency and efficiency. By defining the policy once and applying it to multiple resources, it streamlines the scheduling process. The policy aligns with business best practices, scheduling maintenance activities in accordance with these standards. It also serves as a central repository for documenting and coordinating maintenance commitments with various stakeholders, enhancing compliance and efficiency. The centralized management of resources subscribing to the policy ensures adherence to compliance requirements, and any changes can be efficiently coordinated from a single location. Additionally, the policy improves communication about planned maintenance across different environments in the fleet, facilitating better coordination and awareness.
Note
If you use a scheduling policy, scheduling preferences defined locally on the infrastructure are not used by Oracle automation to apply quarterly updates.
Open the navigation menu. Under Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Click Create maintenance scheduling policy.
In the resulting Create maintenance scheduling policy window, enter the following:
Name: Enter a descriptive name for the policy.
Compartment: Choose a compartment where you want to create this resource.
Cadence: Choose a frequency.
Available options:
Every six months
Every quarter
Note
To use the scheduling policy to plan and automate quarterly infrastructure maintenance, you must create a policy with a 'Quarterly' cadence and a scheduled start month value set to 'February.'
Every month
Note
Six monthly cadence and monthly cadence are not supported for applying infrastructure maintenance updates.
Schedule start month: Choose a start month.
Oracle automation requires a quarterly maintenance schedule to start in February if this policy is used for infrastructure maintenance.
Maintenance window: Oracle automation will perform maintenance to run scheduled actions as per your maintenance windows defined in the schedule.
Month: Choose a month. The month selection option depends on the selected policy cadence. For a quarterly cadence, you can choose between the First, Second, or Third months of every quarter.
Week: A week for maintenance purposes starts on the 1st, 8th, 15th, and 22nd days of the month.
Day: You can choose between the week's days: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday.
Start time: Specify the start time when you want to begin maintenance.
Enforce window duration: With this option enabled, any scheduled action that goes over the configured window duration will be paused and re-scheduled to resume in a future maintenance window.
Note
If an update or action is already underway and cannot be paused and resumed without causing disruption, we will continue and complete the action. Oracle automation will reschedule any action planned to start after the configured window duration to a future maintenance window.
Show Advanced Options:
Tags: (Optional) You can choose to apply tags. If you have permission to create a resource, then you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, then skip this option (you can apply tags later) or ask your administrator.
Note
You can add additional maintenance windows to the scheduling policy after creation.
Delete a Maintenance Window of a Maintenance Scheduling Policy 🔗
Note
Only maintenance windows not used by any resources to plan and automate maintenance activity can be deleted from the policy. Any window already used by services to automate maintenance cannot be deleted.
Open the navigation menu. Under Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Click the name of the policy that you want to delete Maintenance windows.
The Maintenance windows section in the resulting Maintenance scheduling policy details page lists the maintenance windows associated with the policy.
Click the Actions menu (three dots) of the Maintenance window you want to delete and then select Delete.
On the resulting Delete maintenance window dialog, enter the name of the Maintenance window, and then click Delete maintenance window.
Using the Console to Configure
Oracle-Managed Infrastructure Updates 🔗
Full Exadata infrastructure software updates are scheduled on a quarterly
basis. In addition, important security updates are scheduled monthly. While you
cannot opt-out of these infrastructure updates, Oracle alerts you in advance through
the Cloud Notification Portal and allows scheduling flexibility to help you plan for
them.
For quarterly infrastructure maintenance, you can set a maintenance window to determine when the maintenance will begin. You can also edit the maintenance method, enable custom action, and view the scheduled maintenance runs and the maintenance history of your Exadata Cloud@Customer in the Oracle Cloud Infrastructure Console. For security maintenance, you may edit the scheduled start time within the 21-day window.
View or Edit Quarterly Maintenance Preferences To edit your Oracle Exadata Database Service on Cloud@Customer infrastructure quarterly maintenance preferences, be prepared to provide values for the infrastructure configuration. The changes you make will only apply to future maintenance runs, not those already scheduled.
To edit your Oracle Exadata Database Service on
Cloud@Customer infrastructure quarterly maintenance preferences, be prepared to provide values for the infrastructure configuration. The changes you make will only apply to future maintenance runs, not those already scheduled.
Open the navigation menu. Under Oracle Database, click
Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region
and the compartment where the Oracle Exadata infrastructure you want to edit is
located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to edit.
The
Infrastructure Details page displays information about the selected Oracle
Exadata infrastructure.
Click Edit Maintenance Preferences.
Edit Maintenance Preferences page
is displayed.
Note
Changes made to maintenance preferences apply only to future maintenance, not the maintenance that has already been scheduled.
On the Edit Maintenance Preferences page, configure the following:
Rolling: By default, Exadata Infrastructure is updated in a rolling fashion, one server at a time with no downtime.
Non-rolling: Update database and storage servers at the same time. The non-rolling maintenance method minimizes maintenance time but incurs full system downtime.
Enable custom action before performing maintenance on DB servers: Enable custom action only if you want to perform additional actions outside of Oracle’s purview. For maintenance configured with a rolling software update, enabling this option will force the maintenance run to wait for a custom action with a configured timeout before starting maintenance on each DB server. For maintenance configured with non-rolling software updates, the maintenance run will wait for a custom action with a configured timeout before starting maintenance across all DB servers. The maintenance run, while waiting for the custom action, may also be resumed prior to the timeout.
Custom action timeout (in minutes): Timeout available to perform custom action before starting maintenance on the DB Servers.
Note
Custom action timeout applies only to DB servers. Customer can specify a minimum 15 minutes and a maximum of 120 minutes of custom action time-out before DB server patching starts. Within this time, they can perform whatever actions they have planned. In case, they want to extend the custom action, they can extend the same by going to "edit maintenance window" option. If custom action is in progress, customer get 2 options - either extend Custom action timeout or resume maintenance window.
Default: 15 minutes
Maximum: 120 minutes
Click Save Changes.
Note
From the next maintenance run onwards, executions will occur according to Oracle's schedules.
Maintenance schedule: Define maintenance preferences for this infrastructure.
Note
Changes will take effect from the next maintenance run.
Configure maintenance preference: Define maintenance time preferences for each quarter. If more than one preference is defined for a quarter, Oracle automation will select one of them to perform maintenance on all components in your infrastructure.
Select at least one month every two quarters.
Specify a schedule: Choose your preferred week, weekday, start time, and lead time for infrastructure maintenance.
Optional. Under Week of the month, specify which week of the month, maintenance will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the month, and have a duration of 7 days. Weeks start and end based on calendar dates, not days of the week. Maintenance cannot be scheduled for the fifth week of months that contain more than 28 days. If you do not specify a day of the week, then Oracle will run the maintenance update on a weekend day to minimize disruption.
Optional. Under Day of the week, specify the day of the week on which the maintenance will occur. If you do not specify a day of the week, Oracle will run the maintenance update on a weekend day to minimize disruption.
Optional. Under Hour of the day, specify the hour during which the maintenance run will begin. If you do not specify a start hour, Oracle will pick the least disruptive time to run the maintenance update.
Under Notification Lead Time, specify the minimum number of weeks ahead of the maintenance event you would like to receive a notification message. Your lead time ensures that a newly released maintenance update is scheduled to account for your required minimum period of advanced notification.
Choose a maintenance method:
Rolling: By default, Exadata Infrastructure is updated in a rolling fashion, one server at a time with no downtime.
Non-rolling: Update database and storage servers at the same time. The non-rolling maintenance method minimizes maintenance time but incurs full system downtime.
Enable custom action before performing maintenance on DB servers: Enable custom action only if you want to perform additional actions outside of Oracle’s purview. For maintenance configured with a rolling software update, enabling this option will force the maintenance run to wait for a custom action with a configured timeout before starting maintenance on each DB server. For maintenance configured with non-rolling software updates, the maintenance run will wait for a custom action with a configured timeout before starting maintenance across all DB servers. The maintenance run, while waiting for the custom action, may also be resumed prior to the timeout.
Custom action timeout (in minutes): Timeout available to perform custom action before starting maintenance on the DB Servers.
Note
Custom action timeout applies only to DB servers. Customer can specify a minimum 15 minutes and a maximum of 120 minutes of custom action time-out before DB server patching starts. Within this time, they can perform whatever actions they have planned. In case, they want to extend the custom action, they can extend the same by going to "edit maintenance window" option. If custom action is in progress, customer get 2 options - either extend Custom action timeout or resume maintenance window.
Default: 15 minutes
Maximum: 120 minutes
Show advanced options:
Enable monthly security infrastructure maintenance: Select this check box to perform monthly security infrastructure maintenance.
Maintenance schedule: Use maintenance window preferences from a scheduling policy
During infrastructure provisioning, after the scheduling policy is selected, Oracle generates a recommended maintenance scheduling plan to apply updates to all the components in your infrastructure. The recommended plan schedules all DB Servers, followed by Storage Servers and Network Switches, into the maintenance windows from your policy based on duration. After provisioning the infrastructure, you can update the scheduling plan by editing the 'Maintenance Scheduling Plan' resource and customize the update to specific components to align with different windows in your scheduling policy.
Click Select policy.
In the resulting Select maintenance scheduling policy window, choose a compartment and a policy.
Changes will take effect from the next maintenance run.
You must confirm your choice by entering the currently used policy name in a confirmation dialog before making any changes that delete the associated maintenance plan created with the attached policy.
Changing from one scheduling policy to another scheduling policy after the recommended maintenance plan is created and saved for the infrastructure
Changing from using a scheduling policy to not using a policy and defining your maintenance preference in line with your infrastructure
Change from using the scheduling policy to not using the policy and apply updates as per the Oracle-managed schedule.
All of the above changes delete the scheduling plan for your infrastructure created with the current policy, and you will lose any customizations made to the Oracle recommended plan if you attach the same policy later.
Click Save Changes.
If you switch from rolling to non-rolling
maintenance method, then Confirm Non-rolling Maintenance Method dialog is
displayed.
Enter the name of the infrastructure in the field provided to confirm
the changes.
Manage Quarterly Maintenance Plan using Scheduling Policy 🔗
After the scheduling policy is selected, Oracle generates a recommended maintenance scheduling plan to apply updates to all the components in your infrastructure.
The recommended plan schedules all DB Servers, followed by Storage Servers and Network Switches, into the maintenance windows from your policy based on duration. You can update the maintenance scheduling plan and customize the update to specific components to align with different windows in your scheduling policy.
Edit Maintenance Plan Scheduled Actions To edit scheduled actions of an Exadata Cloud@Customer Infrastructure maintenance scheduling plan, use this procedure.
To view the quarterly maintenance scheduling policy for your infrastructure, use this procedure.
Open the navigation menu. Under Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to view the quarterly maintenance scheduling policy.
The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure. In the Maintenance section, find the Quarterly Maintenance Schedule policy.
Change the Quarterly Maintenance Scheduling Policy 🔗
To change the quarterly maintenance scheduling policy for your infrastructure, use this procedure.
Open the navigation menu. Under Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to view the quarterly maintenance scheduling policy.
The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure. In the Maintenance section, find the Quarterly Maintenance Schedule policy.
Click Edit Maintenance Preferences.
The Customer Managed Schedule and Use maintenance window preferences from a scheduling policy are selected as part your policy selection.
Click Select Policy.
Select an existing policy or create a policy and select it.
Click Save Changes.
Note
Changes will take effect from the next maintenance run.
To change from one scheduling policy to another scheduling policy after the recommended maintenance plan is created and saved for the infrastructure, you must confirm your choice by entering the currently used policy name in a confirmation dialog before.
Policy change deletes the scheduling plan created with the current policy for your infrastructure, and you will lose any customizations made to the Oracle recommended plan if you attach the same policy later.
To view the maintenance scheduling plan for your infrastructure, use this procedure.
Open the navigation menu. Under Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to view maintenance scheduling plan.
The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure.
Under Resources, click Maintenance scheduling plan.
The Maintenance scheduling Plan section displays the maintenance scheduling plan associated with the infrastructure. The details include maintenance windows associated with the plan, lifecycle state, duration in hours, scheduled actions, and the estimated time.
Note
If all infrastructure components are not scheduled for an update in the maintenance scheduling plan, you will see a banner in the console indicating the components missing from the plan, and the plan will reflect a 'Needs Attention' lifecycle state.
If the missing components are not included in the plan before Oracle automation schedules the next quarterly maintenance run, they will be automatically added to an 'Unplanned' maintenance window for that quarter's maintenance run.
To edit scheduled actions of an Exadata Cloud@Customer Infrastructure maintenance scheduling plan, use this procedure.
Open the navigation menu. Under Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to view maintenance scheduling plan.
The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure.
Under Resources, click Maintenance scheduling plan.
In the Maintenance scheduling plan section, click the Actions menu (three dots) of the Maintenance window you want to edit action, and select Edit scheduled actions.
In the resulting Edit scheduled actions window, do the following:
Add a scheduled action:
Create new action: When you are creating a new maintenance action, you can choose to add components already scheduled to update in different maintenance windows to a new window.
Select action type:
DB Server Exadata full software update
Configure maintenance method:
Rolling: By default, Exadata Infrastructure is updated in a rolling fashion, one server at a time with no downtime.
Non-rolling: Update database and storage servers at the same time. The non-rolling maintenance method minimizes maintenance time but incurs full system downtime.
Enable custom action before performing maintenance on DB servers: Enable custom action only if you want to perform additional actions outside of Oracle’s purview. For maintenance configured with a rolling software update, enabling this option will force the maintenance run to wait for a custom action with a configured timeout before starting maintenance on each DB server. For maintenance configured with non-rolling software updates, the maintenance run will wait for a custom action with a configured timeout before starting maintenance across all DB servers. The maintenance run, while waiting for the custom action, may also be resumed prior to the timeout.
Custom action timeout (in minutes): Timeout available to perform custom action before starting maintenance on the DB Servers.
Note
Custom action timeout applies only to DB servers. Customer can specify a minimum 15 minutes and a maximum of 120 minutes of custom action time-out before DB server patching starts. Within this time, they can perform whatever actions they have planned. In case, they want to extend the custom action, they can extend the same by going to "edit maintenance window" option. If custom action is in progress, customer get 2 options - either extend Custom action timeout or resume maintenance window.
Default: 15 minutes
Maximum: 120 minutes
Add DB Servers:
Select DB Servers: Updates to selected DB Servers will be moved from their currently scheduled window to the window you are adding the maintenance action.
Storage Server Exadata full software update
Configure maintenance method:
Rolling: By default, Exadata Infrastructure is updated in a rolling fashion, one server at a time with no downtime.
Non-rolling: Update database and storage servers at the same time. The non-rolling maintenance method minimizes maintenance time but incurs full system downtime.
Note
All storage servers in the infrastructure must be scheduled to update in a single maintenance action to apply non-rolling storage updates. While these updates are applied, your database workloads will incur complete downtime.
Select storage server from: Select a window from where you want to add storage servers from.
Select maintenance action to add from: Select the action from where you want to add storage servers from.
Select number of storage servers to add: Select the number of storage servers to add to this action.
Network switch software update: A banner with the message "Network switch update is already scheduled for the selected maintenance window." if the network switch software update is already scheduled in the chosen maintenance window.
Move action from another window: When you are moving an action, you can choose to move all components scheduled to update in a specific window to a new window.
Select the window to move action from: Choose a window from the maintenance run.
Select the action to move: Choose a specific action from the maintenance window to move.
Remove a scheduled action: Click the Actions menu (three dots) of the maintenance action, and then select Remove.
Note
Any action can be removed as long as there are no components scheduled for update in that action.
Any window can be removed as long as there are no actions scheduled for update in that window.
Edit a scheduled action:
Click the Actions menu (three dots) of the maintenance action type Db server full software update, Storage server full software update, and Network switch software update, and then select Edit scheduled action.
Learn how to view and edit the time of the next scheduled
maintenance.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Choose your Compartment.
Click Exadata Infrastructure.
In the list of Exadata Infrastructures, find the infrastructure you want to set
the next scheduled maintenance window for and click its highlighted name.
The Infrastructure Details page displays information about the selected
Oracle Exadata infrastructure.
Note
An information block is displayed 6 hours before the start of a
maintenance run, regardless of whether you've chosen rolling or
non-rolling maintenance method. When the maintenance begins, it is
automatically removed.
On the Infrastructure Details page, under Maintenance, click the view
link in the Next Quarterly Maintenance field.
The Exadata Infrastructure Maintenance page is displayed.
Note
If you've opted to use a Scheduling Policy, link to the policy will appear. Click the link to view the Maintenance scheduling policy details. To edit a maintenance window, refer to the topics listed under Manage Quarterly Maintenance Run created from Scheduling Plan.
On the Exadata Infrastructure Maintenance page, scheduled maintenance
details are listed.
Target DB Server Version and Target Storage Server
Version: These fields display the Exadata software version to be
applied by the scheduled maintenance. The version applied will be the most
recent certified update for Exadata infrastructures in the cloud. If the
next quarterly update is not yet certified when the maintenance is
scheduled, then the versions may show "LATEST" until the new quarterly
update becomes available. Once the update becomes available the new version
will be displayed.
To find information on the Database Server Exadata software version or the
Storage Server Exadata software version, see My Oracle Support note
Exadata Database Machine and Exadata Storage Server Supported
Versions (Doc ID 888828.1).
To change the next scheduled maintenance settings, click Edit Maintenance
Run.
On the Edit Maintenance page, do the following:
Select a maintenance method, Rolling or Non-rolling.
Note
If you select the Non-rolling option, an information
block appears stating that components will be updated
simultaneously, resulting in full system downtime.
Enable custom action before performing maintenance
on DB servers: Enable custom action only if you want to
perform additional actions outside of Oracle’s purview. For
maintenance configured with a rolling software update, enabling this
option will force the maintenance run to wait for a custom action
with a configured timeout before starting maintenance on each DB
server. For maintenance configured with non-rolling software
updates, the maintenance run will wait for a custom action with a
configured timeout before starting maintenance across all DB
servers. The maintenance run, while waiting for the custom action,
may also be resumed prior to the timeout.
Custom action timeout (in minutes):
Maximum timeout available to perform custom action before
starting maintenance on the DB Servers.
Default: 30 minutes
Maximum: 120
minutes
To reschedule the next quarterly maintenance run, enter
a date and time in the Scheduled Start time field.
The following restrictions apply:
Oracle expects to be able to perform infrastructure
maintenance at least once per quarter. You should not
defer maintenance beyond the end of a maintenance
quarter unless unexpected issues prevent your
accommodating it before the next maintenance
quarter.
In the event unexpected issues prevent your
accommodating the scheduled infrastructure maintenance
run, you can reschedule the infrastructure maintenance
to another date no more than 180 days from the prior
infrastructure maintenance. Since normal maintenance
should be performed quarterly, this provides
approximately 90 additional days for you to reschedule
the infrastructure maintenance. Oracle strongly
recommends you not schedule maintenance at or close to
the 180 day limit, as you will have no flexibility to
reschedule further if additional unexpected issues
arise.
If a new maintenance release is announced prior to your
rescheduled maintenance run, the newer release will be
applied on your specified date.
You can reschedule your maintenance to take
place earlier than it is currently scheduled. You cannot
reschedule the maintenance if the current time is within
2 hours of the scheduled maintenance start time.
Oracle reserves certain dates each quarter
for internal maintenance operations, and you cannot
schedule your maintenance on these dates.
Click Save Changes.
To view estimated maintenance time details for various components, click the
View link is displayed in the Total Estimated Maintenance Time
field.
The View link is displayed in the Total Estimated Maintenance
Time field only if the Maintenance Method is Rolling.
The Estimated Maintenance Time Details page is displayed
with details that include:
Total Estimated Maintenance Time
Database Servers Estimated Maintenance Time
Storage Servers Estimated Maintenance Time
Network Switches Estimated Maintenance Time
Order in which components are updated. In rolling
maintenance, components are updated in the sequence displayed
To view the number of VMs that will be restarted as part
of Database Server maintenance, click the Show details
link.
The VM Location dialog is
displayed.
In the VM Cluster Name field, you can find out
what VM cluster a particular VM belongs to.
Click Close.
Click Close to close the Estimated Maintenance Time Details
page.
View and Edit Maintenance While Maintenance is In Progress While maintenance is in progress, you can enable or disable custom action and change the custom action timeout. While maintenance is waiting for a custom action, you can resume the maintenance prior to the timeout or extend the timeout.
View and Edit Maintenance While Maintenance is Waiting for Custom Action While maintenance is in progress, you can enable or disable custom action and change the custom action timeout. While maintenance is waiting for custom action, you can resume the maintenance prior to the timeout or extend the timeout.
View and Edit Maintenance While Maintenance is In Progress 🔗
While maintenance is in progress, you can enable or disable custom action and change the custom action timeout. While maintenance is waiting for a custom action, you can resume the maintenance prior to the timeout or extend the timeout.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the
compartment where the Oracle Exadata infrastructure you want to edit is
located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to edit.
The Infrastructure Details page displays information about the
selected Oracle Exadata infrastructure.
Note
Maintenance In Progress status is displayed in the
Next Quarterly Maintenance field.
Click the View link in the Next Quarterly Maintenance field.
The Exadata Infrastructure Maintenance page is displayed.
Click Edit Maintenance Run.
Edit Maintenance page is displayed.
Note
You can only make edits to the custom action configuration, not the maintenance method or scheduled start time. Enabling or disabling the custom action or modifying the custom action timeout while maintenance is in progress will apply to all database servers that have yet to be updated.
On the Edit Maintenance page, do the following:
Enable custom action before performing maintenance on DB servers: Enable custom action only if you want to perform additional actions outside of Oracle’s purview. For maintenance configured with a rolling software update, enabling this option will force the maintenance run to wait for a custom action with a configured timeout before starting maintenance on each DB server. For maintenance configured with non-rolling software updates, the maintenance run will wait for a custom action with a configured timeout before starting maintenance across all DB servers. The maintenance run, while waiting for the custom action, may also be resumed prior to the timeout.
Custom action timeout (in minutes): Timeout available to perform custom action before starting maintenance on the DB Servers.
Default: 30 minutes
Maximum: 120 minutes
Click Save Changes.
If you have configured the rolling maintenance method, then the View link is displayed in the Total Estimated Maintenance Time field.
Click View.
Estimated Maintenance Time Details page is displayed with details that include:
Total Estimated Maintenance Time
Database Servers Estimated Maintenance Time
Storage Servers Estimated Maintenance Time
Network Switches Estimated Maintenance Time
Order in which components are updated. In rolling maintenance, components are updated in the sequence displayed.
View and Edit Maintenance While Maintenance is Waiting for Custom Action 🔗
While maintenance is in progress, you can enable or disable custom action and
change the custom action timeout. While maintenance is waiting for custom action, you can
resume the maintenance prior to the timeout or extend the timeout.
Open the navigation menu. Under Oracle Database, click Exadata Cloud at
Customer.
Select Region and Compartment, and provide the region and the
compartment where the Oracle Exadata infrastructure you want to edit is
located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to edit.
The Infrastructure Details page displays information about the
selected Oracle Exadata infrastructure.
Note
Maintenance In Progress status is displayed in the Next
Maintenance field.
Click the View link in the Next Quarterly Maintenance field.
Exadata Infrastructure Maintenance page is displayed.
Note
Editing a maintenance run is not available while waiting for custom action.
While maintenance is waiting for custom action, an information block is displayed. The information block is removed after the maintenance resumes.
On the information block, do one of the following:
Click Resume Maintenance Now to resume the maintenance, proceeding to the next database server.
Resume Maintenance dialog is displayed. Click Resume Maintenance Now.
Click Extend Custom Action Timeout.
You can extend timeout multiple times within the maximum allowable time of 2 hours. If you try extending beyond the maximum limit, then the system displays the Cannot Extend Custom Action Timeout dialog indicating that the custom action timeout has already been extended to the maximum allowable 2 hours and you cannot extend it further.
Learn how to view and edit the next scheduled security
maintenance.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the
compartment where the Oracle Exadata infrastructure you want to edit is
located.
Choose your Compartment.
Click the name of the Exadata infrastructure that you want to view maintenance
details.
The Infrastructure Details page displays information about the selected
Oracle Exadata infrastructure.
Quarterly and monthly maintenance details are displayed under the
Maintenance section. Monthly security maintenance is labeled as
Next Security Maintenance.
On the Infrastructure Details page, under Maintenance, click the
view link in the Next Security Maintenance field.
The Exadata Infrastructure Maintenance page is displayed. The Exadata
Infrastructure Maintenance page includes details such as Type: Monthly
Security Maintenance, Scheduled Start Time, and so on.
To reschedule monthly security maintenance, click the Edit link in the
Scheduled Start Time field and pick a new date within the 21-day
cycle.
Note
Certain black-out dates are not available for security maintenance and
are grayed out in the rescheduling calendar.
Edit Maintenance Start Time dialog is displayed.
Select a date and then click Save Changes.
To view the maintenance history, click Maintenance History.
The Maintenance History page displays details including the type of
maintenance, Monthly or Quarterly.
When a monthly security maintenance is in progress, the Infrastructure
resource state will be Available.
Learn how to view the maintenance history for an Oracle Exadata Database Service on
Cloud@Customer Infrastructure.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Choose your Compartment.
Click Exadata Infrastructure.
In the list of Exadata Infrastructures, find the infrastructure you want to
view the maintenance history and click its highlighted name.
The Infrastructure Details page displays information about the selected
Oracle Exadata infrastructure.
On the Infrastructure Details page, under Maintenance, click the
view link in the Next Quarterly Maintenance field.
The Exadata Infrastructure Maintenance page is
displayed.
On the Exadata Infrastructure Maintenance page, click Maintenance
History to see a list of past maintenance events including details on
their completion state and the target database and storage server
versions.
To find information on the Database Server Exadata software
version or the Storage Server Exadata software version, see My Oracle
Support note Exadata Database Machine and Exadata Storage
Server Supported Versions (Doc ID 888828.1).
View Maintenance Windows Associated with a Maintenance Run 🔗
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Choose a compartment from the Compartment filter.
Under Maintenance, click Activity.
The resulting Activity page lists maintenance updates scheduled to run in the chosen compartment.
Click the name of the activity you want to view associated maintenance windows.
The Maintenance Windows section in the resulting Maintenance run page lists the maintenance windows associated with the chosen activity.
Start time (UTC): Window start time in UTC For example, Sun, Jun 23, 2024, 18:30:58 UTC.
The following restrictions apply:
Oracle expects to be able to perform infrastructure maintenance at least once per quarter. You should not defer maintenance beyond the end of a maintenance quarter unless unexpected issues prevent your accommodating it before the next maintenance quarter.
In the event unexpected issues prevent your accommodating the scheduled infrastructure maintenance run, you can reschedule the infrastructure maintenance to another date no more than 180 days from the prior infrastructure maintenance. Since normal maintenance should be performed quarterly, this provides approximately 90 additional days for you to reschedule the infrastructure maintenance. Oracle strongly recommends you not schedule maintenance at or close to the 180 day limit, as you will have no flexibility to reschedule further if additional unexpected issues arise.
If a new maintenance release is announced prior to your rescheduled maintenance run, the newer release will be applied on your specified date.
You can reschedule your maintenance to take place earlier than it is currently scheduled. You cannot reschedule the maintenance if the current time is within 2 hours of the scheduled maintenance start time.
Oracle reserves certain dates each quarter for internal maintenance operations, and you cannot schedule your maintenance on these dates.
Type: Planned vs Unplanned. All windows created from the infrastructure maintenance scheduling plan or added by you to this maintenance run are 'Planned' windows. All other windows Oracle automation creates to address failures, duration enforcement, or unforeseen events are defined as 'Unplanned' windows. Always review activities scheduled to run in an 'Unplanned' window.
Maintenance action: The summary of actions scheduled to update in a given window.
The server name identifies updates scheduled for DB servers. For example, Apply full update to DB servers dbServer-1 and dbServer-2. The storage server updates are identified as count since all storage servers have identical storage layouts. For example, Apply full update to 2 Storage Servers. The Network switches are updated as a pair and cannot be scheduled to update in different actions or maintenance windows. For example, Apply full update to 2 Network switches.
Estimated time: The estimated time for Oracle automation to complete maintenance actions scheduled to apply updates to all infrastructure components across all windows in the maintenance run.
Edit Maintenance Window Associated with a Maintenance Run 🔗
Note
You can update the window configuration, like window schedule start time, duration, and duration enforcement, while the window is still in the 'Scheduled' life cycle state. Once the window is in progress, you cannot make changes to the configuration. You can choose to cancel a running maintenance for a window. Details covered in the Cancel Maintenance Window Associated with a Maintenance Run section.'
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Choose a compartment from the Compartment filter.
Under Maintenance, click Activity.
The resulting Activity page lists maintenance activities in the chosen compartment.
Click the name of the activity you want to view associated maintenance windows.
The Maintenance Windows section in the resulting Maintenance run page lists the maintenance windows associated with the chosen activity.
Click the Actions menu (three dots) of the Maintenance window you want to edit, and then select Edit maintenance window.
In the resulting Edit maintenance window dialogs, update the Maintenance window start time, Duration in hours, and Enforce window duration fields
Edit Maintenance Actions of a Maintenance Window Associated with a Maintenance Run 🔗
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Choose a compartment from the Compartment filter.
Under Maintenance, click Activity.
The resulting Activity page lists maintenance activities in the chosen compartment.
Click the name of the activity you want to view associated maintenance windows.
The Maintenance Windows section in the resulting Maintenance run page lists the maintenance windows associated with the chosen activity.
Click the Actions menu (three dots) of the Maintenance window you want to edit, and then select Edit maintenance actions. The resulting Edit maintenance action page displays the list of actions. You can either add more actions or delete the existing ones.
To add actions:
Click Add actions.
Do the following in the resulting Add maintenance action window:
Create new action: When you are creating a new maintenance action, you can choose to add components already scheduled to update in different maintenance windows to a new window.
Select action type:
DB Server Exadata full software update
Configure maintenance method:
Rolling: By default, Exadata Infrastructure is updated in a rolling fashion, one server at a time with no downtime.
Non-rolling: Update database and storage servers at the same time. The non-rolling maintenance method minimizes maintenance time but incurs full system downtime.
Enable custom action before performing maintenance on DB servers: Enable custom action only if you want to perform additional actions outside of Oracle’s purview. For maintenance configured with a rolling software update, enabling this option will force the maintenance run to wait for a custom action with a configured timeout before starting maintenance on each DB server. For maintenance configured with non-rolling software updates, the maintenance run will wait for a custom action with a configured timeout before starting maintenance across all DB servers. The maintenance run, while waiting for the custom action, may also be resumed prior to the timeout.
Custom action timeout (in minutes): Timeout available to perform custom action before starting maintenance on the DB Servers.
Note
Custom action timeout applies only to DB servers. Customer can specify a minimum 15 minutes and a maximum of 120 minutes of custom action time-out before DB server patching starts. Within this time, they can perform whatever actions they have planned. In case, they want to extend the custom action, they can extend the same by going to "edit maintenance window" option. If custom action is in progress, customer get 2 options - either extend Custom action timeout or resume maintenance window.
Default: 15 minutes
Maximum: 120 minutes
Add DB Servers:
Select DB Servers: Updates to selected DB Servers will be moved from their currently scheduled window to the window you are adding the maintenance action.
Storage Server Exadata full software update
Configure maintenance method:
Rolling: By default, Exadata Infrastructure is updated in a rolling fashion, one server at a time with no downtime.
Non-rolling: Update database and storage servers at the same time. The non-rolling maintenance method minimizes maintenance time but incurs full system downtime.
Note
All storage servers in the infrastructure must be scheduled to update in a single maintenance action to apply non-rolling storage updates. While these updates are applied, your database workloads will incur complete downtime.
Select storage server from: Select a window from where you want to add storage servers from.
Select maintenance action to add from: Select the action from where you want to add storage servers from.
Select number of storage servers to add: Select the number of storage servers to add to this action.
Network switch software update: A banner with the message "Network switch update is already scheduled for the selected maintenance window." if the network switch software update is already scheduled in the chosen maintenance window.
Move action from another window: When you are moving an action, you can choose to move all components scheduled to update in a specific window to a new window.
Select the window to move action from: Choose a window from the maintenance run.
Select the action to move: Choose a specific action from the maintenance window to move.
To delete an action:
Click the Actions menu (three dots) of the maintenance action, and then select Remove.
Note
Any action can be removed as long as there are no components scheduled for update in that action.
Any window can be removed as long as there are no actions scheduled for update in that window.
View and Edit Maintenance While Maintenance is In Progress 🔗
While maintenance is in progress, you can enable or disable custom action and change the custom action timeout. While maintenance is waiting for a custom action, you can resume the maintenance prior to the timeout or extend the timeout.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to edit.
The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure.
Note
Maintenance In Progress status is displayed in the Next Quarterly Maintenance field.
Click the View link in the Next Quarterly Maintenance field.
You will be on the maintenance run details page that is in progress.
Click Maintenance windows on the Maintenance Run details page.
Identify the maintenance window that's in progress
Click the Actions menu (three dots) and select Edit maintenance action.
Click the Actions menu (three dots) and select Edit custom action configuration.
In the resulting Edit custom action configuration page, enter Custom action in minutes.
Note
While maintenance is in progress you can only change the custom action time for DB Server action type. You cannot change the custom action time for support this option for any other action type.
View and Edit Maintenance While Maintenance is Waiting for Custom Action 🔗
While maintenance is in progress, you can enable or disable custom action and change the custom action timeout. While maintenance is waiting for a custom action, you can resume the maintenance prior to the timeout or extend the timeout.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
Click Exadata Infrastructure.
Click the name of the Exadata infrastructure that you want to edit.
The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure.
Note
Maintenance In Progress status is displayed in the Next Quarterly Maintenance field.
Click the View link in the Next Quarterly Maintenance field.
You will be on the maintenance run details page that is in progress.
In the resulting Maintenance Run details page, click Maintenance actions under Resources.
While maintenance is waiting for custom action, an information block is displayed. And, you cannot edit the maintenance while waiting for customer action. The information block is removed after the maintenance resumes.
On the information block, do the following:
Click Resume Maintenance Now to resume the maintenance, proceeding to the next database server.
Resume Maintenance dialog is displayed. Click Resume Maintenance Now.
Click Extend Custom Action Timeout.
You can extend timeout multiple times within the maximum allowable time of 2 hours. If you try extending beyond the maximum limit, then the system displays the Cannot Extend Custom Action Timeout dialog indicating that the custom action timeout has already been extended to the maximum allowable 2 hours and you cannot extend it further.
To cancel a Maintenance Window Associated with a Maintenance Run, follow these steps:
Note
You can cancel a running maintenance while the scheduled updates for a window are in progress. Canceling the maintenance while the updates are in progress allows you to reschedule all actions that have not yet started to a future maintenance window of your choice. You can choose a new start time and duration to finish all the actions rescheduled from the maintenance window you decided to cancel.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Choose a compartment from the Compartment filter.
Under Maintenance, click Activity.
The resulting Activity page lists maintenance activities in the chosen compartment.
Click the name of the activity you want to view associated maintenance windows.
The Maintenance Windows section in the resulting Maintenance run page lists the maintenance windows associated with the chosen activity.
Click the Actions menu (three dots) of the Maintenance window you want to cancel, and then select Cancel maintenance window.
To cancel a Maintenance Run While In Progress, follow these steps:
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Choose a compartment from the Compartment filter.
Under Maintenance, click Activity.
The resulting Activity page lists maintenance activities in the chosen compartment.
Click the name of the 'In Progress' activity you want to cancel.
Click Maintenance windows on the Maintenance Run details page.
Identify the maintenance window that's in progress.
Click the Actions menu (three dots) and select Cancel maintenance window.
On the resulting Cancel maintenance run window, reconfigure Maintenance window start time.
Select the Enforce window duration check box to pause and re-schedule any scheduled action that goes over the configured window duration to resume in a future maintenance window.
Click Reschedule maintenance run.
Note
The maintenance run will complete the current operation. All remaining actions scheduled for this window will be rescheduled to a new maintenance window.
View Maintenance Activity in a Compartment 🔗
Note
Maintenance activity lists all the maintenance updates scheduled to run for all infrastructure resources in a given compartment for the selected Exadata cloud service.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Choose a compartment from the Compartment filter.
Under Maintenance, click Activity.
The resulting Activity page lists maintenance activities in the chosen compartment.
View Maintenance History Details in a Compartment 🔗
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Under Maintenance, click Scheduling policy.
The resulting Scheduling Policy page displays the list of policies.
Choose a compartment from the Compartment filter.
Under Maintenance, click History.
The resulting History page lists maintenance run status (Succeeded or Failed) and other details of the maintenance activities in the chosen compartment.
In case of a failure, automation will mark the run as 'Failed' and automatically reschedule a new window with the remaining components that needs update to the target version. The same update order is carried over.
Click the Actions menu (three dots) of the maintenance activity you want to view details.
The resulting Maintenance History page displays the details of the chosen maintenance activity.
Review and Respond to Unplanned Maintenance Activity 🔗
Unplanned maintenance activity when infrastructure is scaled after maintenance is planned
After scaling your infrastructure by adding DB or storage servers, you may need to update your maintenance scheduling plan to include these new components. If any infrastructure component is missing from the maintenance plan, a warning will appear in the infrastructure maintenance plan details section.
When Oracle automation creates the maintenance run for the quarter, any components not included in the maintenance plan will be automatically added to an 'Unplanned' maintenance window. This ensures that all components have the correct system software applied each quarter, maintaining OCI software compliance.
You can edit the scheduled start time of the 'Unplanned' window or move the updates for the missing components to an existing planned window as needed.
Unplanned maintenance activity when a scheduled update fails to apply
If a scheduled update fails, the Oracle operations team will engage, evaluate the failure, and reschedule the failed update along with any unfinished updates to a future maintenance window. Oracle automation will mark this rescheduled window as 'Unplanned' and notify you to review the rescheduled maintenance activity.
You can edit the 'Unplanned' window's scheduled start time or move the failed and unfinished updates to an existing planned window as needed.
Unplanned maintenance when schedule activity exceeds enforced window duration
For maintenance windows configured with duration enforcement, Oracle automation will check if the estimated time to execute and apply the scheduled update is sufficient within the remaining window duration. If not, Oracle automation will automatically reschedule all unfinished updates to a future 'Unplanned' window, mark the current window as 'Duration Exceeded,' and notify you to review the rescheduled maintenance activity.
Any updates already in progress will continue past the enforced window duration to ensure a consistent state of the underlying resources.
Monitor Infrastructure Maintenance
Using Lifecycle State Information 🔗
The lifecycle state of your Exadata Infrastructure resource enables you to
monitor when the maintenance of your infrastructure resource begins and ends.
In the Oracle Cloud Infrastructure Console, you can see lifecycle state
details messages on the Exadata Infrastructure Details page when a tooltip is
displayed beside the Status field. You can also access these messages using the
ListExadataInfrastructures API, and using tools based on the API,
including SDKs and the OCI CLI.
During infrastructure maintenance operations, you can expect the
following:
If you specify a maintenance window, then patching begins at
your specified start time. The infrastructure resource's lifecycle state
changes from Available to Maintenance in Progress.
Note
The
prechecks are now done prior to the start of the maintenance.
When Exadata database server maintenance 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 storage server maintenance 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 storage server maintenance is complete, the networking
switches are updated one at a time, in a rolling fashion.
When maintenance is complete, the infrastructure resource's
lifecycle state is Available, and the Console and API-based tools do not
provide a lifecycle state message.
Receive Notifications about Your
Infrastructure Maintenance Updates 🔗
There are two ways to receive notifications. One is through email to
infrastructure maintenance contacts and the other one is to subscribe to the
maintenance events and get notified.
Oracle schedules maintenance run of your infrastructure based on
your scheduling preferences and sends email notifications to all your
infrastructure maintenance contacts. You can login to the console and view
details of the schedule maintenance run. Appropriate maintenance related
events will be generated as Oracle prepares for your scheduled maintenance
run, for example, precheck, patching started, patching end, and so on. For
more information about all maintenance related events, see Oracle
Exadata Cloud@Customer Events. In case, if there are any
failures, then Oracle reschedules your maintenance run, generates related
notification, and notifies your infrastructure maintenance contacts.
For more information about Oracle Cloud Infrastructure Events, see
Overview of Events. To receive additional notifications
other than the ones sent to infrastructure maintenance contacts, you can
subscribe to infrastructure maintenance events and get notified using the
Oracle Notification service, see Notifications Overview.