Contrats de niveau de service de disponibilité pour une base de données d'IA autonome sur une infrastructure Exadata dédiée

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

Oracle Autonomous AI Database est exécuté sur l'infrastructure Oracle Exadata Cloud (Oracle Public Cloud, Multicloud et Oracle Exadata Cloud@Customer), en tirant parti de l'architecture de disponibilité maximale (MAA) d'Oracle. La base de données d'IA autonome sur une infrastructure Exadata dédiée est conçue pour renvoyer une application en ligne suite à une interruption non planifiée ou à une activité de maintenance planifiée en quelques secondes à un chiffre.

Oracle Maximum Availability Architecture (MAA) est un ensemble de meilleures pratiques développées par des ingénieurs Oracle depuis de nombreuses années pour assurer l'utilisation intégrée de technologies de haute disponibilité, de protection de données et d'une récupération après sinistre Oracle. L'objectif principal d'Oracle MAA est de répondre aux objectifs de délai de récupération (RTO) et de point de récupération (RPO) des bases de données et applications Oracle exécutées sur nos plates-formes de système et de base de données à l'aide des architectures et solutions Oracle Cloud MAA. La base de données d'IA autonome sur une infrastructure Exadata dédiée a été validée et certifiée MAA Platinum. Pour plus d'informations sur Oracle MAA, reportez-vous à Maximum Availability Architecture et Autonomous AI Database Cloud dans Oracle Database 19c High Availability Overview and Best Practices ou Oracle Database 26ai High Availability Overview and Best Practices.

Uptime

Le tableau suivant décrit le contrat de niveau de service et l'objectif de niveau de service pour l'infrastructure Oracle Autonomous AI Database on Dedicated Exadata.

Tableau - SLA/SLO de disponibilité

Service Type Temps d'activité (sans Autonomous Data Guard) Temps d'activité (avec Autonomous Data Guard)

Base de données d'IA autonome sur une infrastructure Exadata dédiée (déploiements Oracle Public Cloud)

Contrat de niveau de service

99,95%

Temps d'arrêt maximal de 22 minutes par mois.

99,995%

Temps d'arrêt maximal de 132 secondes par mois.
Base de données d'IA autonome sur Exadata Cloud@Customer, Base de données d'IA autonome sur Oracle Database@AWS Objectif de niveau de service

99,95%

Temps d'arrêt maximal de 22 minutes par mois.

99,995%

Temps d'arrêt maximal de 132 secondes par mois.

Base de données d'IA autonome pour les développeurs

(Déploiements Oracle Public Cloud et Exadata Cloud@Customer)

Objectif de niveau de service

99,5%

Non applicable.

La base de données IA autonome pour les développeurs n'est pas prise en charge avec Autonomous Data Guard.

Remarques :

Pour le contrat de niveau de service de disponibilité figurant dans les colonnes Temps d'activité du tableau ci-dessus, Oracle déploiera des efforts raisonnables sur le plan commercial pour que chaque service soit disponible avec le pourcentage de temps d'activité mensuel indiqué au cours de tout mois calendaire (l'"engagement de service"). Si cet engagement de service n'est pas respecté, vous pouvez recevoir des Crédits de service pour ce service non conforme, avec un pourcentage de crédit de service. Reportez-vous au document pilier des services cloud publics Oracle PaaS et IaaS pour connaître les valeurs de pourcentage de crédit fourniture et d'autres détails.

Objectif de délai de récupération (RTO) et objectif de point de récupération (RPO)

Les tableaux suivants décrivent les contrats de niveau de service/objectifs de point de récupération (RTO) et d'objectif de délai de récupération cible pour différents événements d'échec pour Autonomous AI Database on Dedicated Exadata Infrastructure sans Autonomous Data Guard et avec Autonomous Data Guard.

Tableau : Temps de récupération par défaut de la stratégie de haute disponibilité et contrats de niveau de service/points de récupération

Evénements d'échec et de maintenance Temps d'inactivité au niveau du service Perte de données viable maximale
Evénements localisés, notamment les suivants :
  • Echecs de la topologie réseau de cluster Exadata
  • Echecs de stockage (disque et Flash)
  • Echecs d'instance de base de données
  • Echecs de serveur de base de données
  • Mises à jour de maintenance logicielle et matérielle périodiques

Quasi nul

Zéro
Evénements qui nécessitent une restauration à partir d'une sauvegarde car la base de données de secours n'existe pas :
  • Altérations de données
  • Echecs de base de données complète
  • Echecs de stockage complet
  • Domaine de disponibilité pour les régions à plusieurs domaines de disponibilité

De quelques minutes à quelques heures

(sans Autonomous Data Guard)

15 minutes.

(sans Autonomous Data Guard)

Evénements nécessitant des mises à jour logicielles simultanées ou des mises à niveau de base de données

Jusqu'à la fin de la mise à jour simultanée du logiciel ou de l'événement de mise à niveau de la base de données.

Pour les mises à niveau qui incluent une mise à jour de fichier de fuseau horaire, le temps d'inactivité au niveau du service dépend de la quantité de données de fuseau horaire modifiées au cours de la mise à niveau.

Zéro

Tableau - Durée de récupération Autonomous Data Guard et contrats de niveau de service/points de récupération

Evénements d'échec et de maintenance Temps d'arrêt au niveau du service (TOR) Perte de données potentielle au niveau du service (RPO)
Evénements localisés, notamment les suivants :
  • Echecs de structure réseau de cluster Exadata
  • Echecs de stockage (disque et Flash)
  • Echecs d'instance de base de données
  • Echecs de serveur de base de données
  • Mises à jour de maintenance logicielle et matérielle périodiques

Zéro ou quasi nul

Zéro
Evénements nécessitant un basculement vers la base de données de secours à l'aide d'Autonomous Data Guard, notamment :
  • Altération des données (étant donné que Data Guard dispose d'une réparation automatique des blocs pour les altérations physiques, une opération de basculement n'est nécessaire qu'en cas d'altérations logiques ou d'altérations de données importantes)
  • Echecs de base de données complète
  • Echecs de stockage complet
  • Défaillances de domaine de disponibilité ou de région (la protection contre les pannes régionales n'est disponible que si la base de données de secours se trouve dans plusieurs régions.)

De quelques secondes à deux minutes
  • Zéro avec le mode de protection Disponibilité maximale (utilise le transport des informations de journalisation synchrone). S'applique généralement aux bases de données de secours intra-région.
  • Presque nulle pour le mode de protection Performances maximales (utilise le type Redo Transport asynchrone). S'applique généralement aux bases de données de secours inter-région.