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 dabei die Maximum Availability Architecture (MAA) von Oracle. Die Autonomous AI Database on Dedicated Exadata Infrastructure 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. Autonomous AI Database on Dedicated Exadata Infrastructure wurde MAA Platinum 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.

Tabelle - SLAs/SLOs für Betriebszeit

Service Typ Betriebszeit (ohne Autonomous Data Guard) Betriebszeit (mit Autonomous Data Guard)

Autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur (Oracle Public Cloud-Deployments)

Service Level Agreement (SLA)

99,95%

Maximal 22 Minuten Ausfallzeit pro Monat.

99,995%

Maximal 132 Sekunden Ausfallzeit pro Monat.
Autonome KI-Datenbank auf Exadata Cloud@Customer, Autonome KI-Datenbank auf Oracle Database@AWS 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

(Sowohl Oracle Public Cloud- als auch 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 das Availability Service Level Agreement (SLA) gemäß den Betriebszeitspalten in der obigen Tabelle wird Oracle wirtschaftlich vertretbare Anstrengungen unternehmen, jeden dieser Services mit dem angegebenen Prozentsatz der monatlichen Betriebszeit während eines Kalendermonats zur Verfügung zu stellen (die "Serviceverpflichtung"). Wenn diese Serviceverpflichtung nicht erfüllt ist, sind Sie berechtigt, Servicegutschriften für diesen nicht konformen Service mit einem Servicegutschriftsprozentsatz zu erhalten. Die Werte für den Servicegutschriftsprozentsatz und andere Details finden Sie unter Oracle PaaS und IaaS Public Cloud Services-Pillar-Dokument.

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 on Dedicated Exadata Infrastructure ohne Autonomous Data Guard und mit Autonomous Data Guard beschrieben.

Tabelle - Standard-SLAs für High Availability Policy Recovery Time und Recovery Point

Fehler und Wartungsereignisse Service-Level Downtime (SLO) Maximal möglicher Datenverlust
Lokalisierte Ereignisse, einschließlich:
  • Fehler in der Exadata-Clusternetzwerktopologie
  • Fehler bei Speicher (Datenträger und Flash)
  • Fehler bei Datenbankinstanz
  • Fehler bei Datenbankserver
  • Periodische Software- und Hardwarewartungsupdates

Nahezu null

Null
Ereignisse, bei denen aus dem Backup wiederhergestellt werden muss, weil keine Standby-Datenbank 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 ohne Rolling-Modus oder Datenbankupgrades erforderlich sind

Bis das Nicht-Rolling-Softwareupdate- oder Datenbankupgradeereignis abgeschlossen ist.

Bei Upgrades, die ein Update der Zeitzonendatei enthalten, hängt die Ausfallzeit auf Serviceebene von der Menge der Zeitzonendaten ab, die während des Upgrades geändert werden.

Null

Tabelle - Autonomous Data Guard Recovery Time und Recovery Point SLAs/SLOs

Fehler und Wartungsereignisse Service-Level Downtime (RTO) Möglicher Datenverlust auf Serviceebene (RPO)
Lokalisierte Ereignisse, einschließlich:
  • Exadata-Clusternetzwerkstrukturfehler
  • Fehler bei Speicher (Datenträger und Flash)
  • Fehler bei Datenbankinstanz
  • Fehler bei Datenbankserver
  • Periodische Software- und Hardwarewartungsupdates

Null oder nahezu Null

Null
Ereignisse, die einen Failover auf die Standbydatenbank mit Autonomous Data Guard erfordern, 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
  • Ausfall von Availability-Domains oder Regionen (Regionaler Ausfallschutz ist nur verfügbar, wenn sich die Standbydatenbank regionsübergreifend befindet.)

Wenige Sekunden bis zwei Minuten
  • Null mit Schutzmodus für maximale Verfügbarkeit (verwendet synchronen Redo-Transport). Wird am häufigsten für regionsinterne Standby-Datenbanken verwendet.
  • Nahe null für Schutzmodus für maximale Performance (verwendet asynchronen Redo-Transport). Wird am häufigsten für regionsübergreifende Standby-Datenbanken verwendet.