Oracle Cloud Infrastructure Documentation

Availability Service Level Agreements (SLAs)

This topic describes the Service Level Agreements (SLAs) and Service Level Objectives (SLOs) for Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Oracle Autonomous Database runs on the Oracle Exadata Cloud infrastructure (Oracle Public Cloud and Oracle Exadata Cloud@Customer), leveraging Oracle’s Maximum Availability Architecture (MAA). Autonomous Database on Dedicated Exadata Infrastructure is engineered to return an application online following an unplanned outage or a planned maintenance activity within single-digit seconds.

Oracle Maximum Availability Architecture (MAA) is a set of best practices developed by Oracle engineers over many years for the integrated use of Oracle High Availability, data protection, and disaster recovery technologies. The key goal of Oracle MAA is to meet Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for Oracle databases and applications running on our system and database platforms using Oracle Cloud MAA architectures and solutions. Autonomous Database on Dedicated Exadata Infrastructure has been MAA Platinum validated and certified. See Maximum Availability Architecture and Autonomous Database Cloud for more details about Oracle MAA.

Uptime

The following table outlines the Service Level Agreement (SLA) and Service Level Objective (SLO) for Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Table 7-21 Uptime SLAs/SLOs

Service Type Uptime (without Autonomous Data Guard) Uptime (with Autonomous Data Guard)

Autonomous Database on Dedicated Exadata Infrastructure (Oracle Public Cloud deployments)

Service Level Agreement (SLA)

99.95%

A maximum of 22 minutes of downtime per month.

99.995%

A maximum of 132 seconds of downtime per month.
Autonomous Database on Exadata Cloud@Customer Service Level Objective (SLO)

99.95%

A maximum of 22 minutes of downtime per month.

99.995%

A maximum of 132 seconds of downtime per month.

Autonomous Database for Developers

(Both Oracle Public Cloud and Exadata Cloud@Customer deployments)

Service Level Objective (SLO)

99.5%

Not applicable

Autonomous Database for Developers is not supported with Autonomous Data Guard.

Note

For the Availability Service Level Agreement (SLA) under the Uptime columns in the above table, Oracle will use commercially reasonable efforts to have each such Service available with the indicated Monthly Uptime Percentage during any calendar month (the “Service Commitment”). If this Service Commitment is not met, you will be eligible to receive Service Credits for such Non-Compliant Service, with a Service Credit Percentage. Refer to Oracle PaaS and IaaS Public Cloud Services Pillar Document for the Service Credit Percentage values and other details.

Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

The following tables outline the target Recovery Time Objective (RTO) and Recovery Point Objective (RPO) SLAs/SLOs for different failure events for Autonomous Database on Dedicated Exadata Infrastructure without Autonomous Data Guard and with Autonomous Data Guard.

Table 7-22 Default High Availability Policy Recovery Time and Recovery Point SLAs/SLOs

Failure and Maintenance Events Service-Level Downtime (SLO) Maximum Viable Data Loss
Localized events, including:
  • Exadata cluster network topology failures
  • Storage (disk and flash) failures
  • Database instance failures
  • Database server failures
  • Periodic software and hardware maintenance updates

Near-zero

Zero
Events that require restoring from backup because the standby database does not exist:
  • Data corruptions
  • Full database failures
  • Complete storage failures
  • Availability domain (AD) for multi-AD regions

Minutes to hours

(without Autonomous Data Guard)

15 minutes

(without Autonomous Data Guard)

Events that require non-rolling software updates or database upgrades

Until the non-rolling software update or database upgrade event completes.

For the upgrades that include a time-zone file update, the service-level downtime depends on the amount of time-zone data that is modified during the upgrade.

Zero

Table 7-23 Autonomous Data Guard Recovery Time and Recovery Point SLAs/SLOs

Failure and Maintenance Events Service-level Downtime (RTO) Potential Service-level Data Loss (RPO)
Localized events, including:
  • Exadata cluster network fabric failures
  • Storage (disk and flash) failures
  • Database instance failures
  • Database server failures
  • Periodic software and hardware maintenance updates

Zero or Near Zero

Zero
Events that require failover to the standby database using Autonomous Data Guard, including:
  • Data corruptions (because Data Guard has automatic block repair for physical corruptions, a failover operation is required only for logical corruptions or extensive data corruptions)
  • Full database failures
  • Complete storage failures
  • Availability domain or region failures (Regional failure protection is only available if the standby is located across regions.)

Few seconds to two minutes
  • Zero with maximum availability protection mode (uses synchronous redo transport). Most commonly used for intra-region standby databases.
  • Near zero for maximum performance protection mode (uses asynchronous redo transport). Most commonly used for cross-region standby databases.

Parent topic: Reference