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

Cette rubrique décrit les contrats de niveau de service et les objectifs de niveau de service pour Oracle Autonomous AI Database sur une infrastructure d'Exadata dédiée.

Oracle Autonomous AI Database s'exécute sur l'infrastructure Oracle Exadata Cloud (Oracle Public Cloud, Multicloud et Oracle Exadata Cloud@Customer), tirant parti de l'architecture de disponibilité maximale (MAA) d'Oracle. La base de données Autonomous AI sur une infrastructure Exadata dédiée est conçue pour renvoyer une application en ligne suite à une panne 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 Autonomous AI 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 and 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 Oracle Autonomous AI Database sur une infrastructure Exadata dédiée.

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 de cloud public), OCI, @AWS et @Azure Contrat de Niveau de Service (SLA)

99,95%

Un maximum de 22 minutes de temps d'arrêt par mois.

99,995%

Un maximum de 132 secondes de temps d'arrêt par mois.

Autonomous AI Database on Exadata Cloud@Customer Objectif de niveau de service

99,95%

Un maximum de 22 minutes de temps d'arrêt par mois.

99,995%

Un maximum de 132 secondes de temps d'arrêt par mois.

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

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

Objectif de niveau de service 99,5%

Non applicable.

Autonomous AI Database for Developers n'est pas pris en charge avec Autonomous Data Guard.

Remarque : en ce qui concerne le Contrat de Niveau de Service de Disponibilité (SLA) sous les colonnes Temps de Disponibilité du tableau ci-dessus, Oracle déploiera des efforts raisonnables sur le plan commercial pour que chacun de ces Services soit disponible avec le Pourcentage de Temps de Disponibilité Mensuel indiqué pendant tout mois civil (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 sur les services Oracle PaaS et IaaS Public Cloud pour connaître les valeurs de pourcentage de crédit de service 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.

Evénements d'échec et de maintenance Temps d'arrêt de niveau de 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 du serveur de base de données
  • Mises à jour de maintenance logicielle et matérielle périodiques

Quasi nul Zéro

Evénements nécessitant 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 l'événement simultané de mise à jour logicielle ou de mise à niveau de base de données.

Pour les mises à niveau qui incluent une mise à jour de fichier de fuseau horaire, le temps d'arrêt au niveau du service dépend de la quantité de données de fuseau horaire qui est modifiée pendant la mise à niveau.

Zéro
Evénements d'échec et de maintenance Temps d'arrêt au niveau du service (objectif de délai de récupération) Perte de données potentielle au niveaux du service

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 du serveur de base de données
  • Mises à jour de maintenance logicielle et matérielle périodiques

Zéro ou proche de zéro 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 régionale contre les pannes n'est disponible que si la base de données de secours se trouve dans plusieurs régions).

De quelques secondes à deux minutes

  • Nulle pour la disponibilité maximale (utilise le type Redo Transport synchrone). S'applique généralement aux bases d'informations de secours intra-régions.
  • Presque nulle pour le mode de protection Performances maximales (utilise le type Redo Transport asynchrone). S'applique généralement aux bases d'informations de secours inter-régions.