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 di database Oracle mission critical in un ambiente Bare Metal Solution.
Questa guida presuppone che tu stia eseguendo 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 quando pianifichi 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 all'RTO (Recovery Time Objective) e all'RPO (Recovery Point Objective) di un'applicazione. In generale, il RTO descrive la quantità di tempo di inattività accettabile per un sistema, mentre l'RPO descrive la quantità di perdita di dati accettabile. Il costo e la complessità di un sistema aumentano man mano che ciascuno di questi valori diminuisce. Per ulteriori informazioni su RTO e RPO, consulta Principi diREl DR.
Le architetture etichettate come "RPO = 0" o "zero data loss" richiedono che i dati vengano scritti in più posizioni prima di essere considerati "commit" nel database. La latenza diventa un problema man mano che l'RPO si avvicina allo zero.
Se non viene presa in considerazione correttamente durante la fase di progettazione, l'implementazione di un'architettura senza perdita di dati può avere effetti negativi sulle prestazioni complessive dell'applicazione.
Alta disponibilità e ripristino di emergenza
L'alta affidabilità e il ripristino di emergenza sono concetti complementari nella progettazione di architetture di database affidabili. Nel contesto di questa guida, l'alta disponibilità si riferisce alla capacità di un sistema di ripristinarsi automaticamente da errori singoli o a cascata. D'altra parte, il ripristino di emergenza fa parte di un piano di continuità aziendale generale e si applica a guasti più gravi che potrebbero rendere non disponibili interi gruppi di sistemi. Il disaster recovery ha un ambito più ampio a causa del numero di componenti integrati che devono essere recuperati in caso di disastro.
L'alta affidabilità deve essere considerata la "prima linea di difesa" quando si progetta un sistema affidabile. Un'architettura di database a disponibilità elevata deve essere in grado di sostenere i singoli guasti e continuare a funzionare senza causare tempi di inattività per l'applicazione. I componenti di alta disponibilità di un sistema devono includere, a titolo esemplificativo:
- Alimentazione ridondante in server, rete o hardware di archiviazione
- Interfacce di rete, switch e cavi multipli
- Tessuti di archiviazione, controller e dispositivi di archiviazione ridondanti
- Partner Interconnect con tolleranza agli errori 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 processi per il ripristino da più errori a cascata che rendono i componenti non disponibili. La pianificazione del ripristino di emergenza deve tenere conto di quanto segue:
- Interruzioni regionali
- 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 di alta disponibilità e ripristino di emergenza di Oracle:
- 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 di regione.
RAC viene in genere utilizzato per fornire alta disponibilità per i sistemi che devono proteggersi da un singolo errore del server. A causa dell'approccio "shared everything" (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 risolve il requisito di ripristino di emergenza.
Oracle Recovery Manager
Oracle Recovery Manager (RMAN) è lo strumento principale per il backup e il ripristino dei database Oracle grazie alla sua capacità di leggere il formato proprietario dei file di dati di Oracle. Può essere utilizzato per eseguire cloni di database, recupero point-in-time o anche il recupero di una singola tabella all'interno di un database Oracle.
RMAN è l'unico strumento che può essere utilizzato per eseguire 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 di 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 reporting.
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
di ripristinare rapidamente un database a un momento specifico senza dover
eseguire ripristini di 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 un reintegro più rapido del database. Il database non riuscito viene ripristinato a un momento specifico
coerente con i log del nuovo database primario e viene inviato il redo in modo che
possa essere risincronizzato completamente.
Oracle GoldenGate
Oracle GoldenGate è uno strumento di replica logica comunemente utilizzato per
abilitare deployment multisito attivo/attivo o spostare dati tra piattaforme
hardware. Quando utilizzi GoldenGate, un processo extract sul database di origine acquisisce le modifiche nei redo log online e le scrive nei file di traccia delle modifiche, che vengono trasferiti al database di destinazione. Un processo replicat sul database di destinazione converte le transazioni dai file di coda in SQL ed esegue l'SQL sul database di destinazione.
Questa architettura rende GoldenGate uno strumento potente per spostare i dati tra piattaforme di database o trasformarli durante la 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 nel database di destinazione. Sebbene GoldenGate possa fornire un ritardo minimo per la replica, GoldenGate da solo non può garantire un RPO pari a zero.
Modelli di deployment del disaster recovery (solo database)
Oracle ha creato il framework Maximum Availability Architecture (MAA) per fornirti modelli di ripristino di emergenza consigliati per il deployment delle tue applicazioni e dei tuoi database.
Ciascuno dei seguenti modelli fornisce target RTO e RPO specifici:
I modelli sono mappati su pattern di deployment specifici che soddisfano l'RPO e l'RTO in caso di interruzioni pianificate e non pianificate. Ogni workload del database deve essere valutato in base ai requisiti di disponibilità e progettato con un modello corrispondente. È comune che i database di sviluppo utilizzino un modello con un livello di protezione inferiore rispetto alle controparti di produzione e controllo qualità.
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 comunque seguiti anche se viene implementato un database di standby.
Modello in rame
Il modello in rame fornisce un deployment minimo per eseguire il backup dei database su supporti di archiviazione locali e copiarli in uno spazio di archiviazione che si trova al di fuori dell'estensione della regione. Questo deployment richiede un approccio in due fasi, ma può essere creato uno script per utilizzare Google Cloud SDK per automatizzare la trasmissione dei backup.
L'utilizzo di questo deployment aumenta anche il RTO a causa del ripristino in due fasi richiesto. RMAN non può accedere direttamente ai backup, quindi devono essere spostati in una posizione disponibile per RMAN prima che possa iniziare il ripristino.
| 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 |
| Disastri: corruzioni | Ultimo backup archivelog, incrementale o completo che è stato trasferito fuori dal RE | Ore, a seconda delle dimensioni del database e della larghezza di banda assegnata a Partner Interconnect | |
| Disastri: errori di estensione delle regioni | Ultimo backup archivelog, incrementale o completo trasferito all'esterno del RE | Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione della regione | |
| Pianificata | Patch del database, aggiornamenti del sistema operativo / firmware | 0 | Tempo necessario per aggiornare e riavviare l'istanza |
| Aggiornamento principale 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 Bronze 1: backup su spazio di archiviazione regionale
In questo deployment, i backup vengono scritti direttamente su 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 suggerimenti per l'utilizzo di Cloud Storage FUSE sono disponibili in Backup Oracle con NFS e Cloud Storage. Google Cloud È possibile utilizzare anche Filestore, che presenta condivisioni NFS alle istanze Bare Metal Solution.
Il seguente diagramma mostra un esempio di deployment.
| 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 |
| Disastri: corruzioni | Ultimo backup archivelog, incrementale o completo | Ore, a seconda delle dimensioni del database e della larghezza di banda assegnata a Partner Interconnect | |
| Disastri: errori di estensione delle regioni | Ultimo backup archivelog, incrementale o completo | Giorni / settimane, a seconda del tempo necessario per ripristinare l'estensione della regione | |
| Pianificata | Patch del database, aggiornamenti del sistema operativo/firmware | 0 | Tempo necessario per aggiornare e riavviare l'istanza |
| Aggiornamento principale del database | 0 | 1-2 ore |
Deployment Bronze 2: backup utilizzando Backup e RE
In questo deployment, il servizio di Backup e DR viene utilizzato per archiviare i backup in Google Cloud. Backup and RE offre un approccio incrementale permanente ai backup, che vengono archiviati su supporti ad alte prestazioni supportati da Cloud Storage per la conservazione a lungo termine.
Backup and RE 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. La funzionalità di montaggio e migrazione porta rapidamente un database online durante la copia di nuovo sul supporto di archiviazione di produzione, riducendo drasticamente l'RTO.
Il seguente diagramma mostra un esempio di deployment.
| 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 |
| Disastri: corruzioni | Ultimo backup archivelog, incrementale o completo | Da minuti a ore, a seconda dei requisiti di prestazioni, delle dimensioni del database e della larghezza di banda assegnata a Partner Interconnect | |
| Disastri: errori di estensione delle regioni | Ultimo backup archivelog, incrementale o completo | 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 / firmware | 0 | Tempo necessario per aggiornare e riavviare l'istanza |
| Aggiornamento principale del database | 0 | 1-2 ore |
Silver
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, l'RPO può essere quasi pari a zero. Il modello Silver si basa sulla replica asincrona; l'utilizzo della replica sincrona garantisce la perdita di zero dati, ma il tempo impiegato per inviare i dati tra le regioni in genere porta 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 automatiche se un database primario non è disponibile per un periodo di tempo definito dall'utente. La configurazione viene monitorata da un processo di osservazione Data Guard, che può essere eseguito.
Il modello Silver offre il vantaggio di garantire che il database sia disponibile in caso di errore regionale totale, ma le operazioni di failover e switchover potrebbero influire sulle prestazioni dell'applicazione man mano che aumenta la latenza di rete tra i server delle applicazioni e il database. È raramente consigliabile eseguire applicazioni e database di supporto in regioni diverse. Anche se l'RTO per il database potrebbe essere inferiore a 1 minuto, i casi di failover dell'applicazione potrebbero richiedere da minuti a ore prima che i servizi siano completamente funzionali. Nella maggior parte dei casi, l'esecuzione di piani di failover di ripristino di emergenza tra regioni diverse in genere comporta processi manuali a causa del numero di componenti spostati.
Nel modello Silver, potresti comunque riscontrare tempi di inattività o finestre di manutenzione durante le attività di applicazione di patch trimestrali. L'introduzione di Oracle RAC può ridurre i tempi di inattività per l'applicazione di patch o i guasti del server.
Il seguente diagramma mostra una configurazione di esempio.
La configurazione di esempio nel diagramma mostra i database RAC in esecuzione nelle regioni
us-west2 e us-east4. La replica è configurata utilizzando Data Guard
asincrono. Tutto il traffico tra Bare Metal Solution e Google Cloud
transita attraverso Partner Interconnect e il traffico tra regioni viene trasmesso
tramite il backbone della rete 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 |
| Disastri: corruzioni | < 60 sec | Da minuti a ore, a seconda del failover dell'applicazione. | |
| Disastri: errori di estensione delle regioni | < 60 sec | Da minuti a ore, a seconda del failover dell'applicazione. | |
| Pianificata | Patch del database, aggiornamenti del sistema operativo / firmware | 0 | Tempo necessario per aggiornare e riavviare l'istanza.
Secondi se utilizzi RAC |
| Aggiornamento principale del database | 0 | 1-2 ore
Minuti se utilizzi |
Modello Gold
Se ti preoccupa 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 redo di standby che vengono eseguiti geograficamente vicino al database principale. Questa istanza è configurata per ricevere il redo in modo sincrono con bassa latenza, consentendo la registrazione di tutte le modifiche al di fuori dell'estensione della regione del database principale. L'istanza di sincronizzazione remota inoltra quindi il redo al database di standby nella regione remota da applicare 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 agli errori in cui le modifiche al database vengono scritte in modo sincrono, consentendo una soluzione senza perdita di dati. Quando viene eseguita la replica sincrona nell'istanza di sincronizzazione remota, le transazioni non vengono eseguite nel database principale finché le modifiche non vengono ricevute ed eseguite nell'istanza di sincronizzazione remota.
Le istanze Compute Engine vengono in genere selezionate come candidate per ospitare un'istanza di sincronizzazione remota. Il posizionamento dell'istanza di sincronizzazione remota in una zona Compute Engine in stretta prossimità del database primario 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 deployment.
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 la sincronizzazione
sincrona. L'istanza di sincronizzazione remota è configurata per inviare redo 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 dell'applicazione 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 |
| Disastri: corruzioni | 0 | Da minuti a ore, a seconda del failover regionale dell'applicazione. | |
| Disastri: errori di estensione delle regioni | 0 | Da minuti a ore, a seconda del failover regionale dell'applicazione. | |
| Pianificata | Patch del database, aggiornamenti del sistema operativo / firmware | 0 | Tempo necessario per aggiornare e riavviare l'istanza.
Secondi se utilizzi RAC |
| Aggiornamento principale del database | 0 | 1-2 ore
Minuti se utilizzi |
Modello Platinum
Il modello Platinum offre due opzioni di deployment. Ogni opzione di deployment fornisce protezione utilizzando una tecnologia diversa e presenta caratteristiche RTO e RPO diverse.
Deployment Platinum 1: Data Guard con failover rapido
Il deployment Platinum 1 si basa sul deployment del modello Gold aggiungendo un secondo database standby Data Guard nella regione locale in esecuzione su un'istanza Compute Engine. Questa configurazione utilizza la replica sincrona tra il database principale e lo standby in esecuzione in Compute Engine, garantendo la perdita zero di dati all'interno della regione principale.
La creazione di un database di standby nella regione consente di eseguire operazioni di failover e switchover del database senza influire sulle applicazioni. Durante le modifiche al ruolo del database, le applicazioni configurate in conformità con le considerazioni sul client di Oracle si riconnettono automaticamente al nuovo database primario senza richiedere un intervento manuale. Le applicazioni configurate correttamente subiscono un tempo di inattività inferiore a 2 minuti durante un evento di failover.
Sebbene il database di standby in Compute Engine non esegua RAC, deve essere dimensionato per supportare il normale traffico dell'applicazione quando viene eseguito come database primario. Questa istanza può essere eseguita con una forma più piccola mentre funziona come standby e viene scalata durante gli eventi di failover oppure può essere eseguita a piena capacità in qualsiasi momento. Il ridimensionamento 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 è 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 primari e di standby. Se l'osservatore rileva un errore nel database principale, avvia un failover a uno dei database di standby. Il database di standby in esecuzione su Compute Engine deve essere configurato come target di failover preferito quando utilizzi il deployment di livello Gold.
Oracle consiglia di posizionare l'osservatore in una regione separata dai database primario e di standby. Ciò fornisce la migliore protezione contro errori regionali ed eventi di partizionamento della rete. Se una terza regione non è possibile, l'osservatore deve essere installato nella regione principale, in esecuzione in una zona diversa dallo standby near-site.
Il seguente diagramma mostra un esempio di deployment.
Il deployment di esempio mostrato nel diagramma è costituito da quanto segue:
- Un database primario 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 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 nella regione
us-central1.
La replica sincrona è configurata per il database di standby nella regione in esecuzione
sull'istanza Compute Engine, mentre la replica asincrona è configurata per
la regione remota. In ogni caso, il redo viene inviato dal database principale allo standby; il redo non viene inoltrato da un database di 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 primaria e si connettono al database primario 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 dell'applicazione 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 |
| Disastri: corruzioni | 0 | < 60 sec | |
| Disastri: errori di estensione delle regioni | 0 | < 60 sec | |
| Pianificata | Patch del database, aggiornamenti del sistema operativo / firmware | 0 | Tempo necessario per aggiornare e riavviare l'istanza.
Secondi se utilizzi RAC |
| Aggiornamento principale del database | 0 | 1-2 ore
Minuti se utilizzi |
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 database di gestire le sessioni di lettura e scrittura 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 eseguire il commit di 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 software aggiuntivo sui server di database Oracle. Le implementazioni active/active in genere richiedono una progettazione sofisticata di schemi e applicazioni per sfruttare un'implementazione di database multisito. Molte applicazioni preconfigurate non supportano questo tipo di architettura.
I deployment che dipendono da GoldenGate per tutta la replica non possono supportare un RPO con perdita di dati pari a zero a causa della natura asincrona della replica logica. I database di standby locali in esecuzione in Compute Engine utilizzando Data Guard possono essere implementati per fornire un RPO pari a zero con la replica sincrona.
Il seguente diagramma mostra un esempio di deployment.
| 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 |
| Disastri: corruzioni | Da secondi a minuti
0 se utilizzi Data Guard in ogni località |
0 | |
| Disastri: errori di estensione delle regioni | Da secondi a minuti
0 se utilizzi Data Guard in ogni località |
0 | |
| Pianificata | Patch del database, aggiornamenti del sistema operativo / firmware | 0 | Tempo necessario per aggiornare e riavviare l'istanza.
Secondi se utilizzi RAC |
| Aggiornamento principale del database | 0 | 0 |