Opzioni di ripristino di emergenza per i carichi di lavoro dei database Oracle

Questa guida descrive le opzioni di ripristino di emergenza disponibili per gli utenti Esecuzione di carichi di lavoro di database Oracle mission-critical in una Bare Metal Solution completamente gestito di Google Cloud.

Questa guida presuppone che tu stia utilizzando Oracle Enterprise Edition. Alcune delle funzionalità descritte in questa guida sono concesse in licenza separatamente al di fuori di una licenza Enterprise Edition. Alcune di queste funzionalità includono, a titolo esemplificativo a:

• Oracle Real Application Clusters
• Oracle Active Data Guard
• Compressione avanzata Oracle
• Oracle GoldenGate

Consulta i contratti di licenza Oracle per stabilire di quali funzionalità disponi l'utente può essere utilizzato quando si pianifica il ripristino di emergenza e l'alta disponibilità.

RTO e RPO dell'applicazione

Il ripristino di emergenza per le tecnologie di database Oracle deve essere determinato in base al Recovery Time Objective (RTO) e al Recovery Point Objective (RPO) di un'applicazione. In generale, RTO descrive la quantità di tempo di inattività accettabile per un sistema, mentre l'RPO indica la quantità di perdita di dati accettabile. Il costo e la complessità di un sistema aumentano con la diminuzione di ciascuno di questi valori. Per maggiori informazioni per informazioni su RTO e RPO, consulta le Nozioni di base sulla pianificazione di RE.

Le architetture etichettate come "RPO = 0" o "Nessuna perdita di dati" richiedono che i dati vengano scritti in più posizioni prima di essere considerati "committati" nel database. La latenza diventa un problema quando l'RPO si avvicina allo zero.

A meno che non venga presa in considerazione in modo appropriato durante la fase di progettazione, l'implementazione di un'architettura con zero perdita di dati può avere effetti negativi sulle prestazioni complessive dell'applicazione.

Alta disponibilità e ripristino di emergenza

L'alta disponibilità e il ripristino di emergenza sono concetti complementari quando progettando architetture di database affidabili. Nell'ambito di questa guida, per alta disponibilità si intende la capacità di un sistema di ripristinare da errori singoli o a cascata sul sistema. D'altra parte, i casi di emergenza il ripristino fa parte di un piano di continuità aziendale generale e si applica alle errori che potrebbero rendere non disponibili interi gruppi di sistemi. Il disaster recovery include un ambito più ampio a causa del numero di componenti integrati che devono essere recuperati in caso di disastro.

L'alta disponibilità va considerata la "prima linea di difesa" quando si progetta un sistema affidabile. Un'architettura di database a disponibilità elevata deve essere in grado a sostenere gli errori individuali e a continuare a funzionare senza causare tempi di inattività per l'applicazione. I componenti per l'alta disponibilità di un sistema devono includere, non si limitano a quanto segue:

• Alimentazione ridondante per hardware di server, rete o archiviazione
• Interfacce di rete, switch e cavi multipli
• Infrastrutture di archiviazione, controller e dispositivi di archiviazione su disco ridondanti
• Interconnessioni partner fault-tolerant tra Google Cloud e l'estensione della regione della soluzione Bare Metal
• Oracle RAC per impedire che gli errori del server disattivino un database

Un progetto di ripristino di emergenza deve includere procedure per il recupero da più errori cascading che rendono i componenti non disponibili. Ripristino di emergenza pianificazione deve considerare quanto segue:

• Mancate disponibilità a livello di regione
• Calamità naturali
• Incidenti che comportano l'interruzione completa di uno o più componenti di un'applicazione

Strumenti di ripristino di emergenza e alta disponibilità di Oracle

Di seguito sono riportati alcuni strumenti Oracle per il ripristino di emergenza e l'alta disponibilità:

• Cluster di applicazioni Oracle Real
• Gestione recupero Oracle
• Oracle Data Guard
• Database flashback
• Oracle GoldenGate

Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) viene utilizzato per scalare orizzontalmente i carichi di lavoro del database in modo che vengano gestiti da più server di database. I database che utilizzano RAC consentono una configurazione attiva/attiva tra i server all'interno di un'estensione della regione.

Il RAC viene tipicamente utilizzato per fornire disponibilità elevata per i sistemi che da un singolo errore del server. A causa dell'approccio "tutto condiviso" (archiviazione condivisa e reti condivise) al clustering, un cluster RAC in esecuzione nell'ambiente Bare Metal Solution deve esistere all'interno di un singolo pod Bare Metal Solution. Ciò rende RAC una soluzione per i problemi di alta disponibilità, ma non soddisfa il requisito del ripristino di emergenza.

Per scoprire come configurare RAC per Bare Metal Solution, consulta: Installa Oracle RAC su Bare Metal Solution.

Gestore recupero Oracle

Oracle Recovery Manager (RMAN) è lo strumento principale per il backup e il recupero dei database Oracle grazie alla sua capacità di leggere il formato del file di dati proprietario di Oracle. Può essere usato per eseguire cloni di database, recupero point-in-time o e persino il ripristino di una singola tabella all'interno di un database Oracle.

RMAN è l'unico strumento che può essere utilizzato per eseguire i backup mentre il database è aperta. Viene utilizzato anche per gestire il catalogo dei file di backup disponibili per il recupero.

Oracle Data Guard

Oracle Data Guard esegue la replica del database in cluster RAC remoti o altre installazioni di database. Data Guard supporta i database in standby in un configurazione fisica o logica.

I database standby fisici sono copie blocco per blocco che consentono di aprire una copia del database per la scrittura; tutte le altre sono montate (ma non aperte) per applicare le modifiche o aperte in sola lettura per supportare le applicazioni di generazione di report.

Per scoprire come configurare Data Guard su Bare Metal Solution, consulta Esegui il deployment di Oracle Data Guard su Bare Metal Solution.

FLASHBACK DATABASE

La funzionalità FLASHBACK DATABASE di Oracle Enterprise Edition consente agli amministratori riavvolgere rapidamente un database a un momento specifico senza dover ripristinare i database che richiedono molto tempo.

Nel contesto del ripristino di emergenza, FLASHBACK DATABASE viene comunemente utilizzato in combinazione con Data Guard durante le operazioni di failover per il reintegro più rapido del database. Il database in errore viene riportato in un momento specifico coerente con i log della nuova istanza principale e il comando Ripeti viene spedito possono essere risincronizzate completamente.

Oracle GoldenGate

Oracle GoldenGate è uno strumento di replica logica di uso comune abilitando distribuzioni multisito attive/attive o spostando i dati tra l'hardware piattaforme di terze parti. Quando utilizzi GoldenGate, un processo extract nel database di origine acquisisce le modifiche nei log redo online e le scrive nelle modifiche ai file traccia, che vengono trasportate nel database di destinazione. Un processo replicat nel database di destinazione converte le transazioni dai file di coda in SQL ed esegue il codice SQL sul database di destinazione.

Questa architettura rende GoldenGate uno strumento potente per spostare i dati tra piattaforme di database o trasformarli durante la loro replica. A differenza di Data Guard, GoldenGate richiede l'installazione e la manutenzione di un software separato nella sistemi di origine e di destinazione. Impossibile utilizzare GoldenGate per la replica sincrona poiché le transazioni vengono tradotte e applicate come SQL database di destinazione. Sebbene GoldenGate sia in grado di fornire un ritardo minimo per la replica, GoldenGate da solo non può garantire un RPO pari a zero.

Modelli di deployment per il ripristino di emergenza (solo database)

Oracle ha creato il framework MAA (numero massimo di architetture di disponibilità massima) fornisce i modelli di ripristino di emergenza consigliati per il deployment applicazioni e database.

Ciascuno dei seguenti modelli fornisce target RTO e RPO specifici:

• Modello in rame
• Modello Bronzo
• Modello Silver
• Modello Gold
• Modello Platinum

I modelli sono mappati a pattern di deployment specifici che soddisfano i requisiti dell'RPO e dell'RTO in caso di interruzioni pianificate e non pianificate. Ogni carico di lavoro del database deve essere valutato in base ai requisiti di disponibilità e progettato con un modello corrispondente. È normale che i database di sviluppo utilizzino un modello con un livello di protezione inferiore rispetto alle controparti di produzione e QA.

Il modello Bronze è destinato ai database che non richiedono un RTO misurato in minuti. Il modello Silver e quello di livello superiore includono database in standby in esecuzione un sito remoto. Ogni modello incorpora la funzionalità dei modelli di livello inferiore. Ad esempio, il modello Bronze utilizza concetti di backup e ripristino che devono anche se viene eseguito il deployment di un database in standby.

Modello in rame

Il modello in rame offre un deployment minimo per il backup dei database nello spazio di archiviazione locale i contenuti multimediali e la copia nello spazio di archiviazione che risiede al di fuori dell'estensione della regione. Questo deployment richiede un approccio in due fasi, ma può essere eseguito tramite script per utilizzare l'SDK Google Cloud per automatizzare la trasmissione dei backup.

L'utilizzo di questo deployment aumenta anche il RTO a causa del recupero in due fasi obbligatorio. RMAN non può accedere direttamente ai backup, pertanto devono essere spostati in una posizione disponibile per RMAN prima che possa iniziare il recupero.

Interruzione	Tipo di interruzione	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Non pianificato	Errore recuperabile del nodo o dell'istanza	0	Tempo necessario per riavviare l'istanza
	Catastrofi: corruzioni	Ultimo backup Archivelog, incrementale o completo trasferito fuori dal RE	Ore, a seconda delle dimensioni del database e della larghezza di banda assegnata a Partner Interconnect
	Catastrofi: errori delle estensioni della regione	Ultimo backup Archivelog, incrementale o completo trasferito in uscita dall'account di recupero	Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione della regione online
Pianificata	Patch del database, aggiornamenti del sistema operativo/del firmware	0	Tempo necessario per aggiornare e riavviare l'istanza
	Upgrade importante del database	0	1-2 ore

Modello di bronzo

Il modello Bronze offre due opzioni di deployment. Entrambi usano Archiviazione nativa di Google Cloud per la conservazione dei backup dei database.

Deployment di bronzo 1: backup su spazio di archiviazione regionale

In questo deployment, i backup vengono scritti direttamente sui supporti esterni. Nella maggior parte dei casi, la destinazione di backup preferita è Cloud Storage con Cloud Storage FUSE, che presenta un bucket Cloud Storage come file system.

I consigli per l'utilizzo di Cloud Storage FUSE sono disponibili in Backup di Oracle con NFS e Cloud Storage. Puoi anche utilizzare Google Cloud Filestore, che presenta le condivisioni NFS alle istanze Bare Metal Solution.

Il seguente diagramma mostra un esempio di implementazione.

Interruzione	Tipo di interruzione	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Non pianificato	Errore recuperabile del nodo o dell'istanza	0	Tempo necessario per riavviare l'istanza
	Catastrofi: corruzioni	Ultimo backup di archivio, incrementale o completo	Ore, a seconda della dimensione del database e della larghezza di banda assegnata Partner Interconnect
	Catastrofi: errori delle estensioni della regione	Ultimo backup di archivio, incrementale o completo	Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione della regione online
Pianificata	Patch di database, aggiornamenti OS/FW	0	Tempo necessario per aggiornare e riavviare l'istanza
	Upgrade importante del database	0	1-2 ore

Deployment di livello bronzo 2: backup mediante backup e RE

In questo deployment, il servizio di backup e RE viene utilizzato per archiviare i backup in Google Cloud. Il backup e il DR offrono un approccio incrementale per sempre ai backup, che vengono archiviati su supporti ad alte prestazioni supportati da Cloud Storage per la conservazione a lungo termine.

Backup e DR offre anche un RTO più rapido rispetto all'archiviazione dei backup su Filestore o Cloud Storage, poiché può rendere immediatamente disponibili le immagini dei file di database per l'istanza Oracle. Il comando mount porta online rapidamente un database durante la copia di archiviazione, riducendo drasticamente l'RTO.

Il seguente diagramma mostra un esempio di implementazione.

Interruzione	Tipo di interruzione	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Non pianificato	Errore recuperabile del nodo o dell'istanza	0	Tempo necessario per riavviare l'istanza Secondi se utilizzi RAC
	Catastrofi: corruzioni	Ultimo backup completo, incrementale o di log degli archivi	Da minuti a ore, in base ai requisiti di prestazioni, alla dimensione del database e alla larghezza di banda assegnata Partner Interconnect
	Catastrofi: errori delle estensioni della regione	Ultimo backup completo, incrementale o di log degli archivi	Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione di regione online o della possibilità per il cliente di passare a un'altra estensione.
Pianificata	Patch del database, aggiornamenti del sistema operativo/del firmware	0	Tempo necessario per aggiornare e riavviare l'istanza
	Upgrade importante del database	0	1-2 ore

Argento

Il modello Silver introduce la replica dei database utilizzando Oracle Data Guard. Data Guard fornisce la replica del database in tempo reale con uno o più database che fungono da database di riserva. Poiché Data Guard si basa sul trasporto e sull'applicazione delle modifiche al database man mano che si verificano, il RPO può essere quasi nullo. Il modello Silver si basa sulla replica asincrona. L'utilizzo della replica sincrona garantisce la perdita zero dei dati, ma il tempo necessario per inviare i dati tra le regioni in genere aumenta il tempo di risposta dell'applicazione oltre i limiti accettabili.

La funzionalità di failover rapido di Data Guard è in grado di eseguire operazioni di failover automatico se un database principale non è disponibile per un periodo di tempo definito dall'utente. La configurazione è monitorata da un data Guard di un processo di osservazione, che può essere eseguito.

Il modello Silver ha il vantaggio di garantire che il database sia disponibile di un errore a livello di regione totale, ma le operazioni di failover e cambio influire sulle prestazioni dell'applicazione poiché la latenza di rete tra le applicazioni aumenta il numero di server e database. Raramente è consigliato eseguire applicazioni supportando database in diverse regioni. Sebbene il RTO per il database possa essere inferiore a 1 minuto, in caso di failover dell'applicazione potrebbero essere necessari da alcuni minuti a diverse ore prima che i servizi siano completamente operativi. Nella maggior parte dei casi, l'esecuzione di piani di failover di ripristino di emergenza tra regioni prevede in genere procedure manuali a causa del numero di componenti da spostare.

Nel modello Silver, potresti comunque prendere tempi di inattività o periodi di manutenzione durante le attività trimestrali di applicazione delle patch. Oracle RAC può ridurre i tempi di inattività per l'applicazione di patch o errori del server.

Il seguente diagramma mostra un esempio di configurazione.

La configurazione di esempio nel diagramma mostra i database RAC in esecuzione us-west2 e us-east4 regioni. La replica è configurata utilizzando Data Guard asincrono. Tutto il traffico tra Bare Metal Solution e Google Cloud transita in un Partner Interconnect e viaggia tra regioni sulla rete backbone della rete Google. I server delle applicazioni sono configurati in ogni regione, ma in genere vengono arrestati nella regione di disaster recovery finché non viene dichiarato un evento di failover.

Interruzione	Tipo di interruzione	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Non pianificato	Errore recuperabile del nodo o dell'istanza	0	Tempo necessario per riavviare l'istanza Secondi se utilizzi RAC
	Catastrofi: corruzioni	< 60 secondi	Da minuti a ore, a seconda del failover dell'applicazione.
	Catastrofi: errori di estensione della regione	< 60 secondi	Da alcuni minuti a diverse ore, a seconda del failover dell'applicazione.
Pianificata	Patch del database, aggiornamenti del sistema operativo/del firmware	0	Tempo necessario per aggiornare e riavviare l'istanza. Secondi se utilizzi RAC
	Upgrade principale del database	0	1-2 ore Minuti se utilizzi DBMS_ROLLING per eseguire l'upgrade.

Modello Gold

Se temi la perdita di dati nel modello Silver, puoi optare per il modello Gold che utilizza un'istanza di sincronizzazione remota per fornire la replica sincrona a un'istanza in esecuzione in Google Cloud Compute Engine.

Un'istanza di sincronizzazione remota include un file di controllo del database e un insieme di log di reimpostazione standby che vengono eseguiti geograficamente vicino al database principale. Questa istanza è configurata per ricevere il riaggiornamento in modo sincrono con bassa latenza, consentendo di registrare tutte le modifiche all'esterno dell'estensione della regione del database principale. L'istanza far sync inoltra quindi il ripristino al database di standby nella regione remota per l'applicazione in modo asincrono.

Un'istanza di sincronizzazione lontana non è una copia completa del database e, di conseguenza, non può fornire assistenza il traffico dell'applicazione. L'istanza di sincronizzazione a distanza viene utilizzata per fornire una tolleranza di errore posizione in cui le modifiche al database devono essere scritte in modo sincrono, consentendo soluzione che non richiede la perdita di dati. Quando esegui la replica sincrona nell'istanza di sincronizzazione remota, le transazioni non vengono confermate nel database principale finché le modifiche non sono state ricevute e confermate nell'istanza di sincronizzazione remota.

In genere, le istanze Compute Engine vengono selezionate come candidate per l'hosting di un'istanza di sincronizzazione remota. Collocare l'istanza di sincronizzazione a distanza in una zona di Compute Engine la vicinanza al database primario aumenta la latenza minima (in genere inferiore a 1,5 ms) e protegge dagli errori all'interno dell'estensione della regione.

Il seguente diagramma mostra un esempio di implementazione.

La configurazione di esempio nel diagramma mostra un database RAC primario in esecuzione us-west2 con applicazioni in esecuzione in Compute Engine. Un'istanza Compute Engine all'interno di us-west2 esegue un'istanza di sincronizzazione remota, ricevendo il recupero sincrono. L'istanza di sincronizzazione lontana è configurata per inviare il comando Ripeti in modo asincrono a un RAC in esecuzione nella regione us-east4. Le istanze dell'applicazione sono configurate nella regione us-east4 su Compute Engine per gestire il traffico delle applicazioni in caso di disastro.

Interruzione	Tipo di interruzione	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Non pianificato	Errore recuperabile del nodo o dell'istanza	0	Tempo necessario per riavviare l'istanza Secondi se utilizzi RAC
	Catastrofi: corruzioni	0	Da alcuni minuti a diverse ore, a seconda del failover regionale dell'applicazione.
	Catastrofi: errori delle estensioni della regione	0	Da minuti a ore, a seconda del failover a livello di regione dell'applicazione.
Pianificata	Patch del database, aggiornamenti del sistema operativo/del firmware	0	Tempo necessario per aggiornare e riavviare l'istanza. Secondi se utilizzi RAC
	Upgrade principale del database	0	1-2 ore Minuti se utilizzi DBMS_ROLLING per eseguire l'upgrade.

Modello Platinum

Il modello Platinum offre due opzioni di implementazione. Ogni opzione di deployment offre protezione utilizzando una tecnologia diversa e presenta caratteristiche RTO e RPO diverse.

Deployment Platinum 1: Data Guard con failover ad avvio rapido

Il deployment Platinum 1 si basa sul deployment del modello Gold aggiungendo un secondo database di standby Data Guard nella regione locale che viene eseguito su un'istanza Compute Engine. Questa configurazione utilizza la replica sincrona tra il database principale e quello di standby in esecuzione in Compute Engine, garantendo una perdita di dati pari a zero all'interno della regione principale.

La creazione di un database in standby nella regione consente il failover e il cambio del database senza incidere sulle applicazioni. Durante il ruolo del database modifiche, applicazioni configurate in base Le considerazioni relative al client Oracle si riconnettono automaticamente al nuovo database principale senza richiedono un intervento manuale. Le applicazioni configurate correttamente registrano meno di 2 minuti di tempo di riposo durante un evento di failover.

Mentre il database in standby in Compute Engine non esegue RAC, deve essere dimensioni per supportare il normale traffico dell'applicazione quando è in esecuzione come per configurare un database. Questa istanza può essere eseguita con una forma più piccola operando come sono in standby e hanno fatto lo scale up durante gli eventi di failover oppure vengono eseguite al pieno della capacità volte. La modifica delle dimensioni dell'istanza durante un evento di failover influisce negativamente sul RTO, poiché l'istanza deve essere riavviata durante l'operazione di ridimensionamento.

Il failover ad avvio rapido è configurato su un'istanza Compute Engine che esegue Data Guard broker con un osservatore. L'osservatore esegue un client Oracle di base con connessioni a tutti i database principali e in standby. Se l'osservatore rileva un in caso di errore nel database principale, avvia un failover a uno dei server o Microsoft SQL Server. Il database di standby in esecuzione su Compute Engine deve essere configurato come destinazione di failover preferita quando si utilizza il deployment di livello Gold.

Oracle consiglia di posizionare l'osservatore in una regione separata dalla primari e in standby. Ciò fornisce la migliore protezione contro i guasti regionali e gli eventi di partizione della rete. Se una terza regione non possibile, l'osservatore deve essere installato nella regione principale, in esecuzione in una diversa da quella di standby vicino al sito.

Il seguente diagramma mostra un esempio di implementazione.

Il deployment di esempio mostrato nel diagramma è costituito da quanto segue:

• Un database principale che esegue RAC sul server Bare Metal Solution nella regione us-west2.
• Un database in standby vicino al sito in esecuzione sull'istanza Compute Engine in Regione us-west2.
• Un database di standby remoto in esecuzione sul server Bare Metal Solution nella regione us-east4.
• L'osservatore Data Guard in esecuzione sull'istanza Compute Engine in us-central1 regione.

La replica sincrona è configurata per il database in standby nella regione in esecuzione sull'istanza Compute Engine e la replica asincrona è configurata regione remota. In ogni caso, il riaggiornamento viene inviato dal database principale a quello standby; il riaggiornamento non viene inoltrato da un database standby all'altro. La l'osservatore è configurato in una terza regione e mantiene la connettività o i database nella configurazione. Le istanze delle applicazioni vengono configurate regione principale e connettiti al database principale sul server Bare Metal Solution (o al database sull'istanza Compute Engine durante il failover e il cambio operazioni). Le istanze dell'applicazione sono configurate nella regione us-east4 in Compute Engine per gestire il traffico delle applicazioni in caso di emergenza.

Interruzione	Tipo di interruzione	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Non pianificato	Errore recuperabile del nodo o dell'istanza	0	Tempo necessario per riavviare l'istanza Secondi se utilizzi RAC
	Catastrofi: corruzioni	0	< 60 secondi
	Catastrofi: errori di estensione della regione	0	&lt; 60s
Pianificata	Patch del database, aggiornamenti del sistema operativo/del firmware	0	Tempo necessario per aggiornare e riavviare l'istanza. Secondi se utilizzi RAC
	Upgrade principale del database	0	1-2 ore Minuti se utilizzi DBMS_ROLLING per eseguire l'upgrade.

Deployment Platinum 2: GoldenGate per la replica

Il deployment Platinum 2 si basa sull'utilizzo di Oracle GoldenGate per la replica. Poiché GoldenGate non esegue la replica a livello di blocco. Consente a ogni servizio di database di leggere e scrivere le sessioni delle applicazioni in modo indipendente. Replica le modifiche in modo bidirezionale, consentendo una configurazione del database attiva/attiva.

Le applicazioni devono essere convalidate accuratamente prima di impegnarsi in un deployment attivo/attivo e devi tenere conto del rilevamento e della risoluzione dei conflitti.

A differenza di Data Guard, GoldenGate richiede l'installazione e la manutenzione di un software aggiuntivo sui server di database Oracle. Deployment attivi/attivi richiedono in genere una progettazione sofisticata di applicazioni e schemi per ottenere del deployment di un database multisito. Molte applicazioni predefinite non supportano questo tipo di architettura.

I deployment che dipendono da GoldenGate per tutta la replica non possono supportare un RPO senza perdita di dati a causa della natura asincrona della replica logica. Locale è possibile eseguire il deployment dei database in standby in esecuzione su Compute Engine mediante Data Guard per fornire un RPO pari a zero con la replica sincrona.

Il seguente diagramma mostra un esempio di implementazione.

Interruzione	Tipo di interruzione	RPO (Recovery Point Objective)	RTO (Recovery Time Objective)
Non pianificato	Errore recuperabile del nodo o dell'istanza	0	Tempo necessario per riavviare l'istanza
	Catastrofi: corruzioni	Secondi in minuti 0 se utilizzi Data Guard in ogni località	0
	Catastrofi: errori di estensione della regione	Secondi in minuti 0 se utilizzi Data Guard in ogni località	0
Pianificata	Patch del database, aggiornamenti del sistema operativo/del firmware	0	Tempo necessario per aggiornare e riavviare l'istanza. Secondi se utilizzi RAC
	Upgrade principale del database	0	0