Acuerdos de nivel de servicio (SLA) de disponibilidad para Autonomous Database on Dedicated Exadata Infrastructure

En este tema se describen los acuerdos de nivel de servicio (SLA) y los objetivos de nivel de servicio (SLO) para Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Oracle Autonomous Database se ejecuta en Oracle Exadata Cloud infrastructure (Oracle Public Cloud, Multicloud y Oracle Exadata Cloud@Customer), aprovechando la arquitectura de máxima disponibilidad (MAA) de Oracle. Autonomous Database on Dedicated Exadata Infrastructure está diseñada para devolver una aplicación en línea tras una interrupción no planificada o una actividad de mantenimiento planificada en segundos de un solo dígito.

Oracle Maximum Availability Architecture (MAA) es un juego de mejores prácticas desarrollado por ingenieros de Oracle durante muchos años para el uso integrado de las tecnologías de alta disponibilidad, protección de datos y recuperación ante desastres de Oracle. El objetivo clave de Oracle MAA es cumplir los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) de las bases de datos y las aplicaciones de Oracle que se ejecutan en nuestro sistema y en plataformas de base de datos que utilizan arquitecturas y soluciones MAA de Oracle Cloud. Autonomous Database on Dedicated Exadata Infrastructure ha sido validada y certificada por MAA Platinum. Consulte Maximum Availability Architecture and Autonomous Database Cloud en Oracle Database 19c High Availability Overview and Best Practices o Oracle Database 23ai High Availability Overview and Best Practices para obtener más información sobre Oracle MAA.

Uptime

En la siguiente tabla se describe el acuerdo de nivel de servicio (SLA) y el objetivo de nivel de servicio (SLO) para Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Tabla: SLA/SLO de tiempo de actividad

Servicio Tipo Tiempo de actividad (sin Autonomous Data Guard) Tiempo de actividad (con Autonomous Data Guard)

Autonomous Database on Dedicated Exadata Infrastructure (despliegues de Oracle Public Cloud)

Acuerdo de Nivel de Servicio (SLA)

99,95%

Un máximo de 22 minutos de tiempo de inactividad al mes.

99,995%

Un máximo de 132 segundos de tiempo de inactividad al mes.
Autonomous Database en Exadata Cloud@Customer, Autonomous Database en Oracle Database@AWS Objetivo de nivel de servicio (SLO)

99,95%

Un máximo de 22 minutos de tiempo de inactividad al mes.

99,995%

Un máximo de 132 segundos de tiempo de inactividad al mes.

Autonomous Database para desarrolladores

(Despliegues de Oracle Public Cloud y Exadata Cloud@Customer)

Objetivo de nivel de servicio (SLO)

99,5%

No se aplica

Autonomous Database para desarrolladores no está soportado con Autonomous Data Guard.

Note:

Para el acuerdo de nivel de servicio (SLA) de disponibilidad en las columnas de tiempo de actividad de la tabla anterior, Oracle realizará todos los esfuerzos comercialmente razonables para que dicho servicio esté disponible con el porcentaje de tiempo de actividad mensual indicado durante cualquier mes natural (el "compromiso de servicio"). Si no se cumple este Compromiso de Servicio, podrá optar a recibir Créditos de Servicio por dicho Servicio no conforme, con un Porcentaje de Crédito de Servicio. Consulte la documentación central de los Servicios Public Cloud PaaS y IaaS de Oracle para conocer los valores del Porcentaje de Crédito por Servicio y otros detalles.

Objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO)

En las siguientes tablas se describen los SLA/SLO de objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) de destino para diferentes eventos de fallo para Autonomous Database on Dedicated Exadata Infrastructure sin Autonomous Data Guard y con Autonomous Data Guard.

Tabla: Tiempo de Recuperación de Política de Alta Disponibilidad por Defecto y SLA/SLO de Punto de Recuperación

Eventos de fallos y mantenimiento Tiempo de inactividad de nivel de servicio (SLO) Pérdida máxima de datos viable
Eventos localizados, incluidos:
  • Fallo de topología de red de cluster de Exadata
  • Fallos de almacenamiento (disco y flash)
  • Fallo de instancia de base de datos
  • Fallos de servidor de base de datos
  • Actualizaciones periódicas de mantenimiento de software y hardware

Casi cero

Cero
Eventos que requieren la restauración desde la copia de seguridad porque la base de datos en espera no existe:
  • Corrupciones de datos
  • Fallos de la base de datos completa
  • Fallos de almacenamiento completo
  • Dominio de disponibilidad (AD) para regiones de varios AD

Minutos a horas

(sin Autonomous Data Guard)

15 minutos

(sin Autonomous Data Guard)

Eventos que requieren actualizaciones de software o actualizaciones de base de datos sin acumulación

Hasta que finalice el evento de actualización de la base de datos o la actualización de software no sucesiva.

Para las actualizaciones que incluyen una actualización de archivo de zona horaria, el tiempo de inactividad del nivel de servicio depende de la cantidad de datos de zona horaria que se modifican durante la actualización.

Cero

Tabla: tiempo de recuperación y SLA/SLO de punto de recuperación de Autonomous Data Guard

Eventos de fallos y mantenimiento Tiempo de inactividad de nivel de servicio (RTO) Posible pérdida de datos de nivel de servicio (RPO)
Eventos localizados, incluidos:
  • Fallos de tejido de red de cluster de Exadata
  • Fallos de almacenamiento (disco y flash)
  • Fallo de instancia de base de datos
  • Fallos de servidor de base de datos
  • Actualizaciones periódicas de mantenimiento de software y hardware

Cero o casi cero

Cero
Eventos que requieren failover en la base de datos en espera mediante Autonomous Data Guard, incluidos:
  • Corrupciones de datos (dado que Data Guard tiene reparación automática de bloques para corrupciones físicas, solo se necesita una operación de failover para corrupciones lógicas o grandes corrupciones de datos)
  • Fallos de la base de datos completa
  • Fallos de almacenamiento completo
  • Fallos de dominio de disponibilidad o región (la protección contra fallos regionales solo está disponible si la base de datos en espera se encuentra entre regiones).

De unos segundos a dos minutos
  • Cero con modo de protección de máxima disponibilidad (utiliza el transporte de redo síncrono). Se utiliza con más frecuencia para bases de datos en espera dentro de la región.
  • Casi cero para el modo de protección de máximo rendimiento (utiliza el transporte de redo asíncrono). Se suele utilizar para bases de datos en espera entre regiones.