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 che eseguono carichi di lavoro dei database Oracle mission-critical in un ambiente Bare Metal Solution.

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:

• Oracle Real Application Clusters
• Oracle Active Data Guard
• Oracle Advanced Compression
• Oracle GoldenGate

Consulta i contratti di licenza Oracle per determinare quali funzionalità hai il diritto di utilizzare durante la pianificazione del ripristino di emergenza e dell'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, il RTO descrive la quantità di tempo di riposo accettabile per un sistema, mentre il RPO descrive 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 ulteriori informazioni su RTO e RPO, consulta la sezione Nozioni di base sulla pianificazione del RE dati.

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 man mano che il 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 perdita zero 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 per la progettazione di architetture di database affidabili. Nel contesto di questa guida, l'alta disponibilità si riferisce alla capacità di un sistema di recuperare automaticamente da errori singoli o a cascata nel sistema. D'altra parte, il recupero di emergenza fa parte di un piano complessivo di continuità aziendale e si applica a guasti più gravi che possono rendere indisponibili 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à deve essere considerata la "prima linea di difesa" quando si progetta un sistema affidabile. Un'architettura di database ad alta disponibilità deve essere in grado di gestire singoli errori e continuare a funzionare senza causare tempi di riposo per l'applicazione. I componenti ad alta disponibilità di un sistema devono includere, a titolo esemplificativo:

• Alimentazione ridondante per hardware di server, rete o archiviazione
• Più interfacce di rete, switch e cavi
• Infrastrutture di archiviazione, controller e dispositivi di archiviazione su disco ridondanti
• Interconnessioni partner fault-tolerant tra Google Cloud e l'estensione della regione Bare Metal Solution
• 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. La pianificazione del ripristino di emergenza deve prendere in considerazione 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 Oracle per ripristino di emergenza e l'alta disponibilità

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

• Oracle Real Application Clusters
• Oracle Recovery Manager
• 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.

RAC viene in genere utilizzato per fornire alta disponibilità per i sistemi che devono essere protetti 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 Installare Oracle RAC sulla soluzione Bare Metal.

Oracle Recovery Manager

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 utilizzato per eseguire cloni di database, ripristino di un punto nel tempo o persino il recupero 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 è aperto. 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 di standby in una 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 Eseguire il deployment di Oracle Data Guard sulla soluzione Bare Metal.

FLASHBACK DATABASE

La funzionalità FLASHBACK DATABASE di Oracle Enterprise Edition consente agli amministratori di riavvolgere rapidamente un database a un punto in tempo specifico senza dover eseguire ripristini del 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 con errori viene ripristinato a un punto in tempo specifico coerente con i log sulla nuova primaria e viene eseguito il riaggiornamento in modo che possa effettuare la ricorrono completa.

Oracle GoldenGate

Oracle GoldenGate è uno strumento di replica logica che viene comunemente utilizzato per attivare i deployment multisito attivi/attivi o per spostare i dati tra piattaforme hardware. 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 sui sistemi di origine e di destinazione. GoldenGate non può essere utilizzato per la replica sincrona perché le transazioni vengono tradotte e applicate come SQL sul database di destinazione. Sebbene GoldenGate possa fornire un ritardo minimo per la replica, da solo non può garantire un RPO pari a zero.

Modelli di implementazione del ripristino di emergenza (solo database)

Oracle ha creato il framework Maximum Availability Architecture (MAA) per fornire modelli di ripristino di emergenza consigliati per il deployment di applicazioni e database.

Ciascuno dei seguenti modelli fornisce target RTO e RPO specifici:

• Modello di rame
• Modello Bronzo
• Modello Silver
• Modello Gold
• Modello Platinum

I modelli sono mappati a pattern di implementazione specifici che soddisfano i requisiti RPO e 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. I modelli Silver e di livello superiore includono database di standby in esecuzione in 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 essere ancora rispettati anche se viene implementato un database di riserva.

Modello in rame

Il modello Copper fornisce un deployment minimo per eseguire il backup dei database su supporti di archiviazione locale e copiarli in uno spazio di archiviazione esterno all'estensione della regione. Questo deployment richiede un approccio in due fasi, ma può essere eseguito tramite script per utilizzare l'Google Cloud SDK 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 completo, incrementale o di log di archivio trasferito dall'RE	Ore, a seconda delle dimensioni del database e della larghezza di banda assegnata a Partner Interconnect
	Catastrofi: errori di estensione della regione	Ultimo backup completo, incrementale o di log di archivio trasferito dall'RE	Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione della regione
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 utilizzano lo spazio di archiviazione nativo diGoogle Cloudper conservare i backup del 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 Oracle Backups con NFS e Cloud Storage. Google Cloud Filestore, che presenta le condivisioni NFS alle istanze della Bare Metal Solution, può essere utilizzato anche.

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 completo, incrementale o di log degli archivi	Ore, a seconda delle dimensioni del database e della larghezza di banda assegnata a Partner Interconnect
	Catastrofi: errori di estensione della regione	Ultimo backup completo, incrementale o di log degli archivi	Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione della regione
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

Deployment di bronzo 2: backup utilizzando Backup e RE

In questo deployment, il servizio di backup e RE viene utilizzato per archiviare i backup in Google Cloud. Il backup e RE 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.

Inoltre, Backup e RE offre 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. La funzionalità di montaggio e migrazione consente di mettere rapidamente online un database e di copiarlo nuovamente sui supporti di archiviazione di produzione, riducendo drasticamente il 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 alcuni minuti a diverse ore, a seconda dei requisiti di prestazioni, delle dimensioni del database e della larghezza di banda assegnata a Partner Interconnect
	Catastrofi: errori di estensione della regione	Ultimo backup completo, incrementale o di log degli archivi	Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione della regione o della possibilità per il cliente di passare a un'altra estensione della regione.
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 del 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 standby. 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 viene monitorata da un processo di osservatore Data Guard, che può essere eseguito.

Il modello Silver ha il vantaggio di garantire la disponibilità del database in caso di guasto regionale totale, ma le operazioni di failover e switchover potrebbero influire sulle prestazioni dell'applicazione con l'aumento della latenza di rete tra i server dell'applicazione e il database. È raramente consigliabile eseguire applicazioni e database di supporto in regioni diverse. 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 per il recupero di emergenza tra regioni prevede in genere procedure manuali a causa del numero di componenti da spostare.

Nel modello Silver, potresti comunque dover prevedere tempi di inattività o finestre di manutenzione durante le attività di applicazione dei patch trimestrali. L'introduzione di Oracle RAC può ridurre il tempo di riposo per le patch o gli errori del server.

Il seguente diagramma mostra un esempio di configurazione.

La configurazione di esempio nel diagramma mostra i database RAC in esecuzione nelle regioni us-west2 e us-east4. La replica viene configurata utilizzando Data Guard asincrono. Tutto il traffico tra Bare Metal Solution e Google Cloud transita attraverso un'Partner Interconnect e il traffico tra regioni viaggia sulla dorsale della rete di Google. I server delle applicazioni sono configurati in ogni regione, ma in genere vengono arrestati nella regione di ripristino di emergenza 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 alcuni minuti a diverse 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 importante 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 al di fuori dell'estensione della regione del database principale. L'istanza farsync inoltra quindi il ripristino al database di standby nella regione remota per l'applicazione in modo asincrono.

Un'istanza di sincronizzazione remota non è una copia completa del database e, pertanto, non può gestire il traffico delle applicazioni. L'istanza di sincronizzazione remota viene utilizzata per fornire una posizione tollerante ai guasti in cui le modifiche al database vengono scritte in modo sincrono, consentendo una soluzione senza 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. Posizionare l'istanza di sincronizzazione remota in una zona Compute Engine in prossimità del database principale aggiunge una 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 principale in esecuzione in 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 remota è configurata per inviare il riaggiornamento in modo asincrono a un database 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 di estensione della regione	0	Da alcuni minuti a diverse ore, a seconda del failover regionale 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 importante del database	0	1-2 ore Minuti se utilizzi DBMS_ROLLING per eseguire l'upgrade.

Modello Platinum

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

Deployment Platinum 1: Data Guard con failover a inizio 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 di riserva all'interno della regione consente di eseguire operazioni di failover e switchover del database senza influire sulle applicazioni. Durante le modifiche del ruolo del database, le applicazioni configurate in conformità con le considerazioni del cliente di Oracle si ricollegano automaticamente al nuovo database principale senza richiedere intervento manuale. Le applicazioni configurate correttamente registrano meno di 2 minuti di tempo di riposo durante un evento di failover.

Anche se il database di riserva in Compute Engine non esegue RAC, deve essere dimensionato in modo da supportare il normale traffico delle applicazioni quando è in esecuzione come database principale. Questa istanza può essere eseguita con una forma più piccola mentre opera come standby e viene eseguita in modalità di scalabilità durante gli eventi di failover oppure può essere eseguita sempre a piena capacità. 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 rapido viene configurato su un'istanza Compute Engine che esegue il broker Data Guard con un osservatore. L'osservatore esegue un client Oracle di base con connessioni a tutti i database principali e di riserva. Se l'osservatore rileva un errore nel database principale, avvia un failover su uno dei database di standby. Il database di standby in esecuzione su Compute Engine deve essere configurato come destinazione di failover preferita quando utilizzi il deployment di livello Gold.

Oracle consiglia di posizionare l'osservatore in una regione separata dai database principali e di standby. Ciò fornisce la migliore protezione contro i guasti regionali e gli eventi di partizione della rete. Se non è possibile usare una terza regione, l'osservatore deve essere installato nella regione principale e deve essere eseguito in una zona diversa da quella del near-site standby.

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 di standby near-site in esecuzione sull'istanza Compute Engine nella regioneus-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 nella regione us-central1.

La replica sincrona è configurata per il database in standby all'interno della regione in esecuzione sull'istanza Compute Engine e la replica asincrona è configurata per la 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. L'osservatore è configurato in una terza regione e mantiene la connettività a tutti i database nella configurazione. Le istanze dell'applicazione sono configurate nella regione principale e si connettono al database principale sul server Bare Metal Solution (o al database sull'istanza Compute Engine durante le operazioni di failover e switchover). 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	< 60 secondi
	Catastrofi: errori di estensione della regione	0	< 60 secondi
Pianificata	Patch del database, aggiornamenti del sistema operativo / del firmware	0	Tempo necessario per aggiornare e riavviare l'istanza. Secondi se utilizzi RAC
	Upgrade importante 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. Le implementazioni attive/attive tipicamente richiedono un design sofisticato di schema e applicazione per sfruttare un'implementazione del database su più siti. Molte applicazioni preconfezionate 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. È possibile eseguire il deployment di database standby locali in esecuzione in Compute Engine utilizzando 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 importante del database	0	0