Availability Service Level Agreements (SLAs) für Autonomous Database on Dedicated Exadata Infrastructure

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

Oracle Autonomous Database wird auf der Oracle Exadata Cloud infrastructure (Oracle Public Cloud, Multicloud und Oracle Exadata Cloud@Customer) ausgeführt und nutzt dabei die Maximum Availability Architecture (MAA) von Oracle. Autonomous Database on Dedicated Exadata Infrastructure wurde entwickelt, um eine Anwendung nach einem ungeplanten Ausfall oder einer geplanten Wartungsaktivität innerhalb von Sekunden im einstelligen Bereich online zurückzugeben.

Oracle Maximum Availability Architecture (MAA) ist eine Gruppe von Best Practices, die Oracle-Techniker über viele Jahre für die integrierte Verwendung von Oracle High Availability, Datenschutz und Disaster-Recovery-Technologien entwickelt haben. 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 Database on Dedicated Exadata Infrastructure wurde von MAA Platinum validiert und zertifiziert. Weitere Informationen zu Oracle MAA finden Sie unter Maximale Verfügbarkeitsarchitektur und Autonomous Database Cloud in Oracle Database 19c High Availability Overview and Best Practices oder Oracle Database 23ai High Availability Overview and Best Practices.

Produktive Zeit

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

Tabelle - SLAs/SLOs für Betriebszeit

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

Autonomous Database on Dedicated Exadata Infrastructure (Oracle Public Cloud-Deployments)

Service Level Agreement (SLA)

99,95%

Maximal 22 Minuten Ausfallzeit pro Monat.

99,995%

Maximal 132 Sekunden Ausfallzeit pro Monat.
Autonomous Database auf Exadata Cloud@Customer, Autonomous Database auf Oracle Database@AWS Service Level Objective (SLO)

99,95%

Maximal 22 Minuten Ausfallzeit pro Monat.

99,995%

Maximal 132 Sekunden Ausfallzeit pro Monat.

Autonomous Database für Entwickler

(Sowohl Oracle Public Cloud- als auch Exadata Cloud@Customer-Deployments)

Service Level Objective (SLO)

99,5%

Nicht zutreffend

Autonomous Database 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 SLAs/SLOs für Recovery Time Objective (RTO) und Recovery Point Objective (RPO) für verschiedene Fehlerereignisse für Autonomous 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.