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

Questo argomento descrive i Service Level Agreement (SLA) e gli Service Level Objectives (SLO) per Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata.

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 da 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 and 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 riportata di seguito 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.

Servizio	Type	Tempo di attività (senza Autonomous Data Guard)	Tempo di attività (con Autonomous Data Guard)
Autonomous AI Database on Dedicated Exadata Infrastructure (Distribuzioni di cloud pubblico), OCI, @AWS e @Azure	Accordo livello del servizio (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	Obiettivo livello dell'assistenza (SLO)	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 (Distribuzioni di Cloud pubblico ed Exadata Cloud@Customer)	Obiettivo livello dell'assistenza (SLO)	99,5%	Non applicabile Autonomous AI Database for Developers non è supportato con Autonomous Data Guard.

Nota: per l'Accordo sul livello di servizio disponibilità (SLA) nelle colonne Tempo di attività della tabella precedente, Oracle compirà ogni ragionevole sforzo 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, si sarà idonei a ricevere crediti di servizio per tale servizio non conforme, con una percentuale di credito del servizio. Fare riferimento al documento di base sui servizi cloud pubblici Oracle PaaS e IaaS per i valori della percentuale di credito del servizio e altri dettagli.

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

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.

Eventi di errore e manutenzione	Tempo di inattività a livello di servizio (SLO)	Perdita massima dati fattibile
Eventi localizzati, tra cui: Errori della topologia di rete del cluster Exadata Errori di storage (disco e flash) Errori istanza di database Errori del database server Aggiornamenti periodici di manutenzione software e hardware	Quasi zero	Zero
Eventi che richiedono il ripristino dal backup perché il database di standby non esiste: Corruzioni dei dati Errori completi del database Errori di storage completi Dominio di disponibilità (AD) per aree con più AD	Da minuti ad ore (senza Autonomous Data Guard)	15 minuti (senza Autonomous Data Guard)
Eventi che richiedono aggiornamenti software non in sequenza o aggiornamenti del database	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

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 del fabric di rete del cluster Exadata Errori di storage (disco e flash) Errori istanza di database Errori del database server Aggiornamenti periodici di manutenzione software e hardware	Zero o quasi zero	Zero
Eventi che richiedono il failover al database di standby utilizzando Autonomous Data Guard, tra cui: Corruzioni dei dati (poiché Data Guard dispone di una riparazione automatica dei blocchi per danneggiamenti fisici, è necessaria un'operazione di failover solo per danneggiamenti logici o estesi danneggiamenti dei dati) Errori completi del database Errori di storage completi Errori del dominio di disponibilità o dell'area (la protezione dagli errori regionali è disponibile solo se lo standby si trova in più aree).	Pochi secondi a due minuti	Zero con la modalità di protezione della massima disponibilità (utilizza il trasporto redo sincrono). Utilizzato più di frequente per i database in standby intraregionale. Quasi zero per la modalità di protezione massima delle prestazioni (utilizza il trasporto redo asincrono). Utilizzato più di frequente per i database di standby tra più aree.