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

In questo argomento vengono descritti gli accordi sul livello di servizio (SLA, Service Level Agreement) e gli obiettivi sul livello di servizio (SLO, Service Level Objectives) per Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Oracle Autonomous Database viene eseguito su Oracle Exadata Cloud infrastructure (Oracle Public Cloud, Multicloud e Oracle Exadata Cloud@Customer), sfruttando la Maximum Availability Architecture (MAA) di Oracle. Autonomous 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 da ingegneri Oracle nel corso di molti anni per l'uso integrato delle tecnologie Oracle High Availability, protezione dei dati e disaster recovery. L'obiettivo principale di Oracle MAA è quello di soddisfare gli obiettivi RTO (Recovery Time Objectives) e RPO (Recovery Point Objectives) per i database e le applicazioni Oracle in esecuzione sulle nostre piattaforme di sistema e database utilizzando architetture e soluzioni MAA di Oracle Cloud. Autonomous Database sull'infrastruttura Exadata dedicata è stato convalidato e certificato da MAA Platinum. Per ulteriori dettagli su Oracle MAA, consulta Maximum Availability Architecture and Autonomous Database Cloud in Oracle Database 19c High Availability Overview and Best Practices o Oracle Database 23ai High Availability Overview and Best Practices.

Tempo di attività

Nella tabella seguente vengono descritti il Service Level Agreement (SLA) e il Service Level Objective (SLO) per Oracle Autonomous 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 Database sull'infrastruttura Exadata dedicata (Distribuzioni 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 Database su Exadata Cloud@Customer, Autonomous 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 Database per sviluppatori

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

SLO (Service Level Objective)

99,5%

Non applicabile

L'Autonomous Database per sviluppatori 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 dell'obiettivo RTO (Recovery Time Objective) e RPO (Recovery Point Objective) di destinazione per diversi eventi di errore per Autonomous Database sull'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.