Availability Service Level Agreements (SLAs) für autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur

In diesem Thema werden die Service Level Objectives (SLOs) für Oracle Autonomous AI Database on Dedicated Exadata Infrastructure und Service Level Objectives (SLOs) beschrieben.

Oracle Autonomous AI Database wird auf der Oracle Exadata Cloud-Infrastruktur (Oracle Public Cloud, Multicloud und Oracle Exadata Cloud@Customer) ausgeführt und nutzt die Maximum Availability Architecture (MAA) von Oracle. Die autonome KI-Datenbank auf einer dedizierten Exadata-Infrastruktur ist so konzipiert, dass eine Anwendung nach einem ungeplanten Ausfall oder einer geplanten Wartungsaktivität innerhalb von Sekunden online zurückgegeben wird.

Oracle Maximum Availability Architecture (MAA) ist eine Gruppe von Best Practices, die von Oracle Ingenieuren über viele Jahre für die integrierte Verwendung von Oracle High Availability, Datenschutz und Disaster-Recovery-Technologien entwickelt wurden. Das Hauptziel von Oracle MAA ist die Erfüllung von Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) für Oracle-Datenbanken und -Anwendungen, die auf unseren System- und Datenbankplattformen mit Oracle Cloud MAA-Architekturen und -Lösungen ausgeführt werden. Autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur wurde MAA Platin validiert und zertifiziert.

Weitere Informationen zu Oracle MAA finden Sie unter Maximum Availability Architecture and Autonomous AI Database Cloud in Oracle Database 19c High Availability Overview and Best Practices oder Oracle Database 26ai High Availability Overview and Best Practices.

Produktive Zeit

In der folgenden Tabelle sind das Service Level Agreement (SLA) und das Service Level Objective (SLO) für Oracle Autonomous AI Database on Dedicated Exadata Infrastructure aufgeführt.

Service	Typ	Betriebszeit (ohne Autonomous Data Guard)	Betriebszeit (mit Autonomous Data Guard)
Autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur (Public Cloud-Deployments), OCI, @AWS und @Azure	Servicelevel-Vereinbarung (SLA)	99,95% Maximal 22 Minuten Ausfallzeit pro Monat.	99,995% Maximal 132 Sekunden Ausfallzeit pro Monat.
Autonomous AI Database on Exadata Cloud@Customer	Service Level Objective (SLO)	99,95% Maximal 22 Minuten Ausfallzeit pro Monat.	99,995% Maximal 132 Sekunden Ausfallzeit pro Monat.
Autonome KI-Datenbank für Entwickler (Public Cloud- und Exadata Cloud@Customer-Deployments)	Service Level Objective (SLO)	99,5%	Nicht zutreffend Autonome KI-Datenbank für Entwickler wird mit Autonomous Data Guard nicht unterstützt.

Hinweis: Für den Servicelevel-Vertrag (SLA) der Verfügbarkeit gemäß den Spalten "Betriebszeit" in der obigen Tabelle unternimmt Oracle wirtschaftlich zumutbare Anstrengungen, um jeden dieser Services mit dem angegebenen Prozentsatz der monatlichen Betriebszeit während eines Kalendermonats (die "Serviceverpflichtung") zur Verfügung zu stellen. Wenn diese Serviceverpflichtung nicht erfüllt wird, sind Sie berechtigt, Servicegutschriften für diesen nicht konformen Service mit einem Servicegutschriftsprozentsatz zu erhalten. In der Pillar-Dokumentation zu Oracle PaaS und IaaS Public Cloud Services finden Sie die Werte für den Prozentsatz der Servicegutschrift und weitere Details.

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

In den folgenden Tabellen werden die Ziel-SLAs für Recovery Time Objective (RTO) und Recovery Point Objective (RPO) für verschiedene Ausfallereignisse für Autonomous AI Database auf dedizierter Exadata-Infrastruktur ohne Autonomous Data Guard und mit Autonomous Data Guard beschrieben.

Fehler und Wartungsereignisse	Ausfallzeit auf Serviceebene (SLO)	Maximal möglicher Datenverlust
Lokalisierte Ereignisse, einschließlich: Fehler in der Exadata-Clusternetzwerktopologie Speicher-(Datenträger- und Flash-)Fehler Fehler in Datenbankinstanz Datenbankserverfehler Periodische Software- und Hardwarewartungsupdates	Nahezu null	Null
Ereignisse, die aus dem Backup zurückgeschrieben werden müssen, weil die Standbydatenbank nicht vorhanden ist: Datenbeschädigungen Die ganze Datenbank betreffende Fehler Den ganzen Speicher betreffende Fehler Availability-Domain (AD) für Multi-AD-Regionen	Minuten bis Stunden (ohne Autonomous Data Guard)	15 Minuten (ohne Autonomous Data Guard)
Ereignisse, für die Softwareupdates oder Datenbankupgrades im Nicht-Rolling-Modus erforderlich sind	Bis das Nicht-Rolling-Softwareupdate oder das Datenbankupgradeereignis abgeschlossen ist. Bei Upgrades, die eine Aktualisierung der Zeitzonendatei umfassen, hängt die Ausfallzeit auf Serviceebene von der Menge der Zeitzonendaten ab, die während des Upgrades geändert werden.	Null

Fehler und Wartungsereignisse	Ausfallzeit (RTO) auf Serviceebene	Potenzieller Datenverlust (RPO) auf Serviceebene
Lokalisierte Ereignisse, einschließlich: Fehler bei Exadata-Clusternetzwerkstruktur Speicher-(Datenträger- und Flash-)Fehler Fehler in Datenbankinstanz Datenbankserverfehler Periodische Software- und Hardwarewartungsupdates	Null oder nahe Null	Null
Ereignisse, für die ein Failover zur Standbydatenbank mit Autonomous Data Guard erforderlich ist, einschließlich: Datenbeschädigungen (da Data Guard automatische Blockreparaturen für physische Beschädigungen vornimmt, ist ein Failover-Vorgang nur für logische Beschädigungen oder umfangreiche Datenbeschädigungen erforderlich) Die ganze Datenbank betreffende Fehler Den ganzen Speicher betreffende Fehler Availability-Domain- oder Regionsfehler (Regionaler Ausfallschutz ist nur verfügbar, wenn sich die Standbydatenbank regionsübergreifend befindet.)	Wenige Sekunden bis zwei Minuten	Null-Schutzmodus für maximale Verfügbarkeit (verwendet synchronen Redo-Transport). Wird am häufigsten für regionsinterne Standbydatenbanken verwendet. Nahe null für Schutzmodus für maximale Performance (verwendet asynchronen Redo-Transport). Wird am häufigsten für regionsübergreifende Standbydatenbanken verwendet.