Oracle Cloud Infrastructure Documentation

Getting Started with Exadata Cloud Infrastructure Deployment

After completing the preparation tasks in Preparing for Exadata Cloud Infrastructure, get started with deploying your Exadata Cloud Infrastructure system following these procedures.

Tagging Oracle Exadata Database Service on Dedicated Infrastructure Resources

Tagging is a powerful foundational service for Oracle Cloud Infrastructure (OCI) that enables users to search, control access, and do bulk actions on a set of resources based on the tag.

Importance of Tagging

Using the Oracle Cloud Infrastructure (OCI) tagging system, you can tag resources per your organizational scheme allowing you to group resources, manage costs, and give insights into usage. Tags also help you build a governance model around security and Maximum Availability Architecture (MAA). As your organization expands its cloud footprint, it can become challenging to keep track of the deployment architectures, security best practices, MAA, application tier, and so on. Using metadata tags to identify workload attributes can help keep up with the security and availability of your tenancy without cost overruns.

To enable customers to manage OCI resources securely and cost-effectively, Oracle provides a set of pre-defined tags in line with best practices for tagging resources. These tags are grouped into two namespaces, the oracleStandard namespace, and the OracleApplicationName namespace. You can think of a tag namespace as a container for your tag keys.

Consider a scenario where your organization has multiple cloud resources such as Exadata Infrastructure, VM Cluster, DB Home, Oracle Database and VM Cluster Networks across multiple compartments in your tenancy. Suppose you wish to track these cloud resources for specific purposes, report on them, or take bulk actions. In that case, you will need a system that lets you group these resources based on different criteria such as environment, criticality, target users, application, etc. You can achieve this by applying appropriate tags to these resources.

For example, you may tag all resources in your development stack with Oracle-Standard.Environment=Dev or for a business-critical application stack set Oracle-Standard.Criticality=High or Extreme. In the event of service disruptions due to various reasons, you would then be able to quickly identify all OCI resources associated with an application or business function or be able to separate critical and non-critical workloads.

Tagging can also help you deploy optimized configurations based on workload attributes identified via tags. For example, database deployments for the PeopleSoft application require a specific configuration. Setting the ApplicationName and AppMajorVersion tags while deploying an Oracle Database can ensure that the database is configured and ready for the particular application, for example, PeopleSoft out of the box.

Moreover, integration with the Cloud Advisor OCI service can provide you with direct, deep insight into how well your cloud services adhere to the corporate guidelines and help your management govern with a vision. See Cloud Advisor Overview for more details.

Adding Tags

You can tag resources using the Oracle Cloud Infrastructure (OCI) console, command-line interface, or SDK.

There are many cloud resources that can be tagged in an Oracle Exadata Database Service on Dedicated Infrastructure deployment. Exadata Infrastructure, VM Cluster, DB Home, Oracle Database, Autonomous Exadata VM Cluster, Autonomous Container Database, Autonomous Database, and VM Cluster Networks are some of them. Tags can either be applied while creating the resources or modified later. For example, you can apply tags to an Autonomous Container Database (ACD) while provisioning the ACD or add them later from its Details page.

See How Tagging Works for more details on using tags. Tagging integrates with Oracle Cloud Infrastructure authorization system. You can use IAM policy controls to enable delegation or restriction of tag manipulation. See Authentication and Authorization to learn about the permissions required to work with defined and free-form tags. (Required) Enter introductory text here, including the definition and purpose of the concept.

Tip:

For a "try it out" tutorial that demonstrates implementing tags in Oracle Autonomous Database, refer to Lab 14: Oracle Standard Tags in Oracle Autonomous Database Dedicated for Fleet Administrators Workshop on Oracle LiveLabs.

Your tenancies come with a library of standard tags that would apply to most resources. These tags are currently available as a set of Tag Namespaces that your governance administrators can deploy. OCI best practices recommend applying these tags to all resources a standard tag can be applied to. Besides reporting and governance, OCI service automation can deliver workload-specific optimizations based on standard tag values.

For example, database deployments for the PeopleSoft application require a specific configuration. By setting the appropriate application tag key in the Oracle-ApplicationName tag namespace while deploying an Autonomous Database, can ensure that the database is configured ready for the particular application, for example, PeopleSoft out of the box.

Figure 4-1 Tagging Example

Setting an appropriate application tag key in the Oracle-ApplicationName tag namespace.

Oracle Standard Tags

Your tenancy governance administrators can deploy the standard tags at the tenancy level and may also mark certain tags as required, thereby enforcing tags on resources in those compartments. The following are the standard tags defined in the namespace called OracleStandard. For more information about importing standard tags, see To import standard tags under the Managing Tag Namespaces section.

Table 4-1 Oracle Standard Tags

Tag Key Tag Value Options Description

OracleStandard.Criticality
  • Extreme
  • High
  • Medium
  • Low

Enables tiering of resources in line with corporate application classification standards. Customer governance can use this tag for reporting and ensuring resources are configured as per the guideline for the tier they belong to.

For example, a database resource with OracleStandard.Criticality set to Extreme or High may require the highest availability SLA and may need to be configured with Autonomous Data Guard.

OracleStandard.Environment
  • Dev
  • Test
  • Prod
  • Pre-Prod
  • Staging
  • Trial
  • Sandbox
  • User Testing

Denotes a resource lifecycle. In the case of databases, it helps determine consolidation density, database distribution across containers, set maintenance plans, and manage clones.

OracleStandard.Sensitivity
  • Public
  • Internal
  • Sensitive
  • Highly Sensitive
  • Extremely Sensitive

An application or database classification tag. OracleStandard.Sensitivity set to Highly Sensitive may indicate that an access control list or certain Network Security Group (NSG) enforcement is mandatory to restrict access.

OracleStandard.Regulation

Refer to List of Compliance Regulations for values.

Denotes one or more compliance regulations that a resource must adhere to.

Tag administrators may add values to the list from the OCI Governance and Administration console. Refer to Using Predefined Values for more details.

OracleStandard.TargetUsers
  • Public
  • Customers
  • Partners
  • Company
  • Division
  • Department
  • Workgroup

Denotes the end users of a resource. Another form of resource classification that helps determine target users and allows governance teams to set corporate standards based on user or application type.

OracleStandard.EndUserCount
  • 1
  • 10
  • 100
  • 1000
  • 10000
  • 100000
  • 1000000
  • 1000000
  • 10000000

An approximate count of end-users. This tag helps determine the number of users impacted or the blast radius during an availability or security event. This also helps prioritize recovery efforts in the event of major outages affecting a large number of cloud resources.

OracleStandard.OwnerEmail

Free form tag. For example john.smith@acme.com or app_support_grp@acme.com

Denotes the email address of the resource owner.

OracleStandard.Org
  • HR
  • Finance
  • Marketing
  • Sales
  • Legal
  • R&D
  • Customer Suppport
  • Internal Support
  • Manufacturing

Identifies the customer's line of business or department that owns or uses the resource. This may help with cost aggregation reports and determining usage across business units.Tag administrators may add relevant values to the list from the OCI Governance and Administration console. Refer to Using Predefined Values for more details.

OracleStandard.CostCenter
  • 12345
  • WebMarketing

Freeform field for cost center.

OracleStandard.RecoveryTimeObjectiveMinutes

0-10080

Time in minutes. Denotes the maximum time within which the resource is required to recover from a failure.

OracleStandard.RecoveryPointObjectiveMinutes

0-1440

Time in minutes. Maximum data loss tolerance for a data store resource such as a database or a storage device.

List of Compliance Regulations

Table 4-2 List of Compliance Regulations

Regulation Description

PCI DSS

Payment Card Industry Data Security Standard

HIPAA

Health Insurance Portability and Accountability Act

ISO

International Standards Organization

SOC1

System and Organization Controls 1

SOC 2

System and Organization Controls 2

FedRamp

Federal Risk and Authorization Management Program

GLBA

Gramm–Leach–Bliley Act

CCPA

California Consumer Privacy Act

SOX

Sarbanes Oxley

NIST

National Institute of Standards and Technology - Cyber Security

FISMA

Federal Information Security Management

HITECH

Health Information Technology for Economic and Clinical Health Act

FERPA

Family Educational Rights and Privacy Act ( Student privacy)

FACTA

Fair and Accurate Credit Transaction Act

Texas HB300

Texas Medical Records Privacy Act

CIS

Center for Internet Security

CJIS

Criminal Justice Information Services Security Policy

C-TPAT

Customs-Trade Partnership Against Terrorism

COPPA

Children's Online Privacy Protection Act

PIPED Act, or PIPEDA

Personal Information Protection and Electronic Documents Act

GDPR

General Data Protection Regulation

PIPL

Personal Information Protection Law

Oracle Application Name Tags

Table 4-3 Oracle Application Name Tags

Tag Key Tag Value Options Description

Hyperion
  • 11.2
  • 11.1

Denotes the version of the Hyperion application.

JD Edwards
  • 9.2
  • 9.1
  • 9.0

Denotes the version of the JD Edwards application.

Oracle_E-Business_Suite
  • 12.2
  • 12.1
  • 12.1
  • 11i

Denotes the version of the Oracle E-Business Suite application.

PeopleSoft
  • 9.2
  • 9.1

Denotes the version of the PeopleSoft application.

Siebel
  • 8.2
  • 8.1

Denotes the version of the Siebel application.

Other_Oracle_Application

Free form tag in string format.

Can be used to denote any application other than those listed above. You can enter the application name as a string value.

Cloud Infrastructure Maintenance Updates

Oracle performs the updates to all of the Oracle-managed infrastructure components on Exadata Cloud Infrastructure.

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 Infrastructure in the Oracle Cloud Infrastructure Console. For details regarding the infrastructure maintenance process and configuring the maintenance controls refer to the following:

Parent topic: Getting Started with Exadata Cloud Infrastructure Deployment

About Oracle-managed Exadata Cloud Infrastructure Maintenance

Oracle performs patches and updates to all of the Oracle-managed system components on Exadata Cloud Infrastructure.

Oracle patches and updates include the physical database server hosts, Exadata Storage Servers, Network Fabric Switches, management switch, power distribution units (PDUs), integrated lights-out management (ILOM) interfaces, and Control Plane Servers. This is referred to as infrastructure maintenance.

The frequency of the updates depends on the region type, as follows:

  • Commercial regions: Oracle performs full quarterly infrastructure updates and monthly security infrastructure updates.
  • Government regions: Oracle performs monthly full infrastructure maintenance updates.

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.

Note

Customers using Exadata Database on Dedicated Infrastructure in Oracle Cloud Infrastructure (OCI) US Government (OC2) and US Department of Defense (OC3) regions can use the OCI console to reschedule monthly and quarterly patching events.

At this time specifying a maintenance schedule, all so known as “Setting Patch Management Schedule for Exadata Cloud Infrastructure”, is still not available in the OCI US Government (OC2) and US DOD (OC3) realms for Exadata patch management. For more information on Exadata Database on Dedicated Infrastructure on Patch Management Rescheduling can be found here.

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.

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.

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 impacts older applications not written to handle a rolling instance outage. 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 do not impact VM cluster VM's availability. However, the rolling storage server maintenance can result in reduced IO performance as storage servers are taken offline (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 not under maintenance will minimize (or eliminate) any performance impact.

Note

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 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 5 days 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.

Note

Do not perform major maintenance operations on your databases or applications during the patching window, as these operations could be impacted by the infrastructure maintenance operations
  • Time Estimates for Quarterly Maintenance Windows
    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.

Related Topics

Parent topic: Cloud Infrastructure Maintenance Updates

Time Estimates for Quarterly Maintenance Windows

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

Note

The timeframes mentioned below can change if Oracle cloud operations determine that additional maintenance work is needed. If additional time is necessary, Oracle will send a customer notification in advance to inform customers that additional time will be required for the next quarterly maintenance window.

Table 4-4 Approximate Times for Exadata Infrastructure Maintenance

Exadata Shape Configuration Rolling Patching Method (Approximate Time) Non-Rolling Patching Method (Approximate Time)
Quarter rack 5-6 hours 4-7 hours
Half rack 10 hours 4-7 hours
Full rack 20 hours 4-7 hours
Flexible shapes (X8M and higher) 1.5 hours per compute node + 1 hour per storage node 4-7 hours

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.

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. Application of security updates takes about 15 minutes per DB server host, plus 60 minutes per storage server depending on the I/O activity. 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.

Using the Console to Configure Oracle-Managed Infrastructure Updates

Software updates are scheduled quarterly and monthly. You can use the the console to schedule and plan for them.

Full Exadata Cloud Infrastructure software updates are scheduled on a quarterly basis for commercial regions, and monthly for government regions. 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, view the scheduled maintenance runs and the maintenance history, and manage maintenance contacts in the in the Exadata Infrastructure Details page of the Oracle Cloud Infrastructure Console.

Parent topic: Cloud Infrastructure Maintenance Updates

View or Edit Quarterly Infrastructure Maintenance Preferences for Exadata Cloud Infrastructure

To edit your Oracle Exadata Database Service on Dedicated Infrastructure infrastructure 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.

  1. Open the navigation menu. Under Oracle Database, click Oracle Exadata Database Service on Dedicated Infrastructure.
    Note

    Specifying maintenance preferences is not available in Government regions.
  2. Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
  3. Click Exadata Infrastructure.
  4. Click the name of the Exadata infrastructure that you want to edit.

    The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure.

  5. 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. To modify scheduled maintenance, see View or Edit a Scheduled Maintenance for Exadata Cloud Infrastructure.
  6. On the Edit Maintenance Preferences page, configure the following:
    • 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.

        Default: 30 minutes

        Maximum: 120 minutes

    • Maintenance schedule:
      • No preference: The system assigns a date and start time for infrastructure maintenance.
      • Specify a schedule: Choose your preferred month, week, weekday, start time, and lead time for infrastructure maintenance.
        Note

        Specifying a maintenance schedule is not available in Government regions.
        • Under Maintenance months, specify at least one month for each quarter during which Exadata infrastructure maintenance will take place. You can select more than one month per quarter. If you specify a long lead time for advanced notification (for example, 4 weeks), you may wish to specify 2 or 3 months per quarter during which maintenance runs can occur. This will ensure that your maintenance updates are applied in a timely manner after accounting for your required lead time. Lead time is discussed in the following steps.
        • 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 week of the month, Oracle will run the maintenance update in a week 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 Start hour, 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 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.
  7. Click Save Changes.

    If you switch from rolling to non-rolling maintenance method, then Confirm Non-rolling Maintenance Method dialog is displayed.

    1. Enter the name of the infrastructure in the field provided to confirm the changes.
    2. Click Save Changes.
To set the automatic monthly maintenance schedule for Exadata Cloud Infrastructure

This task describes how to set the maintenance schedule for a cloud Exadata infrastructure resource.

  1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure.

  2. Navigate to the Cloud Exadata infrastructure you want to access:

    In the Oracle Exadata Database Service on Dedicated Infrastructure section, click Exadata Infrastructure. In the list of infrastructure resources, find the infrastructure you want to access and click its highlighted name to view its details page.

    On the resource details page, under Maintenance, click the View link in the Next Security Maintenance field. The Next Security Maintenance will only show a scheduled time if a Monthly maintenance is scheduled. Customers will get a minimum of 7 days advance notice prior to monthly maintenance, and will then be able to reschedule during the 3 week window.
  3. In the Cloud Exadata Infrastructure pane, you will see the Scheduled Start Time
  4. In the Scheduled Start Time field, click Edit.
  5. In the Edit Maintenance Start Time dialog, enter a new date and time in the Scheduled start time field. The Maintenance run can be rescheduled to start within: 3 Weeks, 15th to 6th of next month, any blocked dates/weekends, any other validations will block the UI/API.
  6. Save Changes.
To view or edit the properties of the next scheduled quarterly maintenance for Exadata Cloud Infrastructure

Review and change the properties of the Exadata Cloud Infrastructure scheduled quarterly maintenance.

  1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure.”
  2. Navigate to the Cloud Exadata infrastructure or DB system you want to access:

    Cloud Exadata infrastructure ( new resource model ): Under Exadata at Oracle Cloud, click Exadata Infrastructure. In the list of infrastructure resources, find the infrastructure you want to access and click its highlighted name to view its details page.

    DB systems: Under Bare Metal, VM, and Exadata, click DB Systems. In the list of DB systems, find the Exadata DB system you want to access, and then click its name to display details about it.

    The Infrastructure Details page displays information about the selected Oracle Exadata infrastructure.

  3. On the resource details page, under Maintenance, click the View link in the Next Quarterly Maintenance field.

    The Exadata Infrastructure Maintenance page is displayed.

  4. 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).

    For each scheduled Exadata Infrastructure resource maintenance event, the Maintenance page lists the following details:

    • The status of the event
    • The OCID of the event
    • The scheduled start time and date of the event
    • Click Patch Now to start the maintenance event immediately. When prompted, click Run Maintenance to confirm that you want to start the event now.

    If a maintenance event is already in progress on one or more of the VM Clusters hosted by an Exadata Infrastructure resource when a maintenance event on that resource is to start, the Exadata Infrastructure resource maintenance event is queued and begins immediately after all VM Cluster maintenance events complete.

  5. To change the next scheduled maintenance settings, click Edit Maintenance Run.
  6. On the Edit Maintenance page, do the following:
    • Select a maintenance method, Rolling or Non-rolling.
      Note

      If you select the Non-rolling option, 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

        Minimum: 15 minutes

        Maximum: 120 minutes

    • To reschedule the next maintenance run, enter a date and time in the Scheduled Start time field.
      The following restrictions apply:
      • You can reschedule the infrastructure maintenance to a date no more than 180 days from the prior infrastructure maintenance. 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.
  7. 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
    • Order in which components are updated. In rolling maintenance, components are updated in the sequence displayed
    1. 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.

    2. In the VM Cluster Name field, you can find out what VM cluster a particular VM belongs to.
    3. Click Close.
  8. Click Close to close the Estimated Maintenance Time Details page.
To view the maintenance history of an Exadata Cloud Infrastructure resource

This task describes how to view the maintenance history for a cloud Exadata infrastructure or DB system. resource.

  1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure.

  2. Navigate to the Cloud Exadata infrastructure or DB system you want to access:

    Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata Infrastructure. In the list of infrastructure resources, find the infrastructure you want to access and click its highlighted name to view its details page.

  3. On the resource details page, under Bare Metal,VM, and Exadata, click the Maintenance History.
  4. The Maintenance jobs, State and type of patching are displayed.
View and Edit Quarterly Maintenance While Maintenance is In Progress or 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.

  1. Open the navigation menu. Under Oracle Database, click Oracle Exadata Database Service on Dedicated Infrastructure.
  2. Select Region and Compartment, and provide the region and the compartment where the Oracle Exadata infrastructure you want to edit is located.
  3. Click Exadata Infrastructure.
  4. 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.

View and Edit Maintenance While Maintenance is In Progress
  1. Click the View link in the Next Maintenance field.

    The Exadata Infrastructure Maintenance page is displayed.

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

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

        Minimum: 15 minutes

        Maximum: 120 minutes

  4. Click Save Changes.

    If you have configured the rolling maintenance method, then the View link is displayed in the Total Estimated Maintenance Time field.

    1. 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.
    2. Click Close.
View and Edit Maintenance While Maintenance is Waiting for Custom Action
  1. Click the View link in the Next 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.
  2. On the information block, do one of the following:
    1. Click Resume Maintenance Now to resume the maintenance, proceeding to the next database server.

      Resume Maintenance dialog is displayed. Click Resume Maintenance Now.

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

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 ListCloudExadataInfrastructures 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, schedule reminder, patching started, patching end, and so on. For more information about all maintenance related events, see Oracle Cloud Exadata Infrastructure 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.

Managing Infrastructure Maintenance Contacts

Learn to manage your Exadata infrastructure maintenance contacts.

Parent topic: Cloud Infrastructure Maintenance Updates

To manage maintenance contacts in an Exadata Cloud Infrastructure

Manage contacts for Exadata infrastructure maintenance notifications using the Console.

To prevent an Exadata infrastructure administrator from being overwhelmed by system update notifications, you can specify up to 10 email addresses of people to whom maintenance notifications are sent.

  1. Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure.
  2. In the Oracle Exadata Database Service on Dedicated Infrastructure section, click Exadata Infrastructure to display a list of Exadata infrastructures in the default compartment. You can select a different compartment from the Compartment drop-down located in the List Scope section.
  3. In the list of Exadata infrastructure resources, find the infrastructure you want to access and click its highlighted name to view its details page.
  4. In the Maintenance section, click Manage in the Customer Contacts field to display the Manage Contacts dialog.
  5. Click the Add Contacts button to display a field in which to enter a valid email address. You can have up to 10 maintenance contacts for each Exadata infrastructure.
  6. To edit an email address, in the Manage Contacts dialog, select the box preceding the email address you want to edit and click the Edit button.
  7. To remove an email address from the list, in the Manage Contacts dialog, select the box preceding the email address you want to remove and click the Remove button.