Accordi sul livello di servizio di disponibilità (SLA) per Autonomous AI Database su un'infrastruttura Exadata dedicata

Questo argomento descrive gli accordi sul livello di servizio (SLA) e gli obiettivi sul livello di servizio (SLO) per Oracle Autonomous AI Database on Dedicated Exadata Infrastructure.

Oracle Autonomous AI Database viene eseguito sull'infrastruttura Oracle Exadata Cloud (Oracle Public Cloud, Multicloud e Oracle Exadata Cloud@Customer), sfruttando la Maximum Availability Architecture (MAA) di Oracle. Autonomous AI Database on Dedicated Exadata Infrastructure è progettato per restituire un'applicazione in linea in seguito a un'indisponibilità non pianificata o a un'attività di manutenzione pianificata in secondi a una cifra.

Oracle Maximum Availability Architecture (MAA) è un insieme di best practice sviluppate dai tecnici Oracle per molti anni per l'uso integrato delle tecnologie Oracle di alta disponibilità, protezione dei dati e disaster recovery. L'obiettivo chiave di Oracle MAA è quello di raggiungere gli Recovery Time Objectives (RTO) e Recovery Point Objectives (RPO) per i database e le applicazioni Oracle in esecuzione sul nostro sistema e sulle piattaforme di database utilizzando le architetture e le soluzioni Oracle Cloud MAA. Autonomous AI Database on Dedicated Exadata Infrastructure è stato convalidato e certificato MAA Platinum. Per ulteriori dettagli su Oracle MAA, consulta Maximum Availability Architecture e Autonomous AI Database Cloud in Oracle Database 19c High Availability Overview and Best Practices o Oracle Database 26ai High Availability Overview and Best Practices.

Tempo di attività

La tabella seguente delinea l'accordo sul livello di servizio (SLA) e l'obiettivo del livello di servizio (SLO) per Oracle Autonomous AI Database on Dedicated Exadata Infrastructure.

Tabella - SLA/SLO tempo di attività

Servizio Type Tempo di attività (senza Autonomous Data Guard) Tempo di attività (con Autonomous Data Guard)

Autonomous AI Database on Dedicated Exadata Infrastructure (implementazioni di Oracle Public Cloud)

Service Level Agreement (SLA)

99,95%

Un massimo di 22 minuti di inattività al mese.

99,995%

Un massimo di 132 secondi di inattività al mese.
Autonomous AI Database su Exadata Cloud@Customer, Autonomous AI Database su Oracle Database@AWS SLO (Service Level Objective)

99,95%

Un massimo di 22 minuti di inattività al mese.

99,995%

Un massimo di 132 secondi di inattività al mese.

Autonomous AI Database per sviluppatori

(Entrambe le distribuzioni di Oracle Public Cloud ed Exadata Cloud@Customer)

SLO (Service Level Objective)

99,5%

Non applicabile

Autonomous AI Database for Developers non è supportato con Autonomous Data Guard.

Nota

Per l'accordo sul livello del servizio di disponibilità (SLA, Availability Service Level Agreement) nelle colonne Uptime della tabella precedente, Oracle compirà ogni sforzo ragionevole dal punto di vista commerciale per rendere disponibile ciascun servizio con la percentuale di tempo di attività mensile indicata durante qualsiasi mese di calendario ("Impegno per il servizio"). Se questo impegno di servizio non viene soddisfatto, l'utente avrà diritto a ricevere Crediti di servizio per tale servizio non conforme, con una percentuale di credito del servizio. Per conoscere i valori della percentuale di credito del servizio e altri dettagli, consulta il documento pillar sui servizi cloud pubblici Oracle PaaS e IaaS.

Obiettivo tempo di recupero (RTO) e obiettivo punto di recupero (RPO)

Le tabelle riportate di seguito descrivono gli SLA/SLO RTO (Recovery Time Objective) e RPO (Recovery Point Objective) di destinazione per eventi di errore diversi per Autonomous AI Database su un'infrastruttura Exadata dedicata senza Autonomous Data Guard e con Autonomous Data Guard.

Tabella - SLA/SLO predefiniti per tempo di recupero e punto di recupero dei criteri ad alta disponibilità

Eventi di errore e manutenzione Tempo di inattività a livello di servizio (SLO) Perdita di dati massima
Eventi localizzati, tra cui:
  • Errori della topologia di rete cluster Exadata
  • Errori di storage (disco e flash)
  • Errori dell'istanza del database
  • Errore del database server
  • Aggiornamenti periodici di manutenzione hardware e software

Quasi zero

Zero
Eventi che richiedono il ripristino dal backup perché il database di standby non esiste:
  • Danneggiamenti dei dati
  • Errori del database completi
  • Completamento degli errori di storage
  • Dominio di disponibilità (AD) per aree multi-AD

minuti a ore

(senza Autonomous Data Guard)

15 minuti

(senza Autonomous Data Guard)

Eventi che richiedono aggiornamenti software o database non in sequenza

Fino al completamento dell'evento di aggiornamento del software o del database non in sequenza.

Per gli aggiornamenti che includono un aggiornamento del file del fuso orario, il tempo di inattività a livello di servizio dipende dalla quantità di dati del fuso orario modificati durante l'aggiornamento.

Zero

Tabella - SLA/SLO dei tempi di recupero e dei punti di recupero di Autonomous Data Guard

Eventi di errore e manutenzione Tempo di inattività a livello di servizio (RTO) Potenziale perdita di dati a livello di servizio (RPO)
Eventi localizzati, tra cui:
  • Errori fabric di rete cluster Exadata
  • Errori di storage (disco e flash)
  • Errori dell'istanza del database
  • Errore del database server
  • Aggiornamenti periodici di manutenzione hardware e software

Zero o quasi zero

Zero
Eventi che richiedono il failover nel database di standby utilizzando Autonomous Data Guard, tra cui:
  • Danni dei dati (poiché Data Guard dispone di una riparazione automatica dei blocchi per i danneggiamenti fisici, è necessaria un'operazione di failover solo per i danneggiamenti logici o per i danneggiamenti estesi dei dati)
  • Errori del database completi
  • Completamento degli errori di storage
  • Errori a livello di dominio di disponibilità o area (la protezione da errori regionali è disponibile solo se il database di standby si trova in più aree geografiche).

Da pochi secondi a due minuti
  • Zero con la massima modalità di protezione della disponibilità (utilizza il trasporto di redo sincrono). Utilizzato più comunemente per i database di standby intraregionali.
  • Quasi zero per la modalità di protezione massima delle prestazioni (utilizza il trasporto di redo asincrono). Utilizzato più comunemente per i database di standby tra più aree.