Skip to main content
Enterprise applications
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Ripristino automatico di Oracle senza modalità di backup

PDF

Con il rilascio di Oracle 12c, il backup e il ripristino basati su Snapshot sono diventati ancora più semplici, eliminando la necessità di impostare il database in modalità di hot backup. Il risultato è la possibilità di pianificare backup basati su Snapshot direttamente sul sistema storage.

Sebbene la procedura di ripristino con backup a caldo sia più familiare per gli amministratori di database, da molto tempo è stato possibile utilizzare istantanee che non sono state create mentre il database era in modalità di backup a caldo. Per rendere il database coerente, sono stati necessari ulteriori passaggi manuali con Oracle 10g e 11g durante il ripristino. Con Oracle 12c, sqlplus e. rman contenere la logica aggiuntiva per riprodurre i log di archivio sui backup dei file dati che non erano in modalità hot backup.

Come indicato in precedenza, il ripristino di un backup a caldo basato su snapshot richiede due set di dati:

  • Un'istantanea dei file di dati creati in modalità backup

  • I log di archivio generati mentre i file di dati erano in modalità hot backup

Durante il ripristino, il database legge i metadati dai file di dati per selezionare i log di archivio richiesti per il ripristino.

Il ripristino automatico senza modalità di backup richiede set di dati leggermente diversi per ottenere gli stessi risultati:

  • Un'istantanea dei datafile.

  • Un set sincronizzato di file di log di archivio, controlfile e redo log. I file di log di archivio devono includere tutti i record dal momento in cui è stato creato lo snapshot del datafile, quindi fai attenzione a una pulizia troppo aggressiva dei log.

Durante il ripristino, il database legge i metadati dai datafile per identificare i record di log necessari e riproduce tutte le transazioni registrate.

NOTA:

Questo approccio può approssimare un recovery point-in-time, ma con una granularità limitata. Ad esempio, se inizi con i datafile in modalità backup, puoi far avanzare il database fino a qualsiasi transazione arbitraria.

Se usi l'approccio di ripristino automatico, senza usare la modalità di backup, devi ripristinare il database al punto dello snapshot del log. In circostanze normali, l'RPO sarebbe comunque pari a zero perché i log di archivio originali, i redo log e i controlfile sarebbero ancora disponibili nel filesystem attivo. Se fosse necessario eseguire un ripristino interamente dagli snapshot a causa della perdita di tutti i dati nei filesystem attivi, allora l'RPO sarebbe di un'ora.

== Struttura dei dati La struttura più semplice consiste nell'isolare i datafile in volumi dedicati, LUN o namespace NVMe. Le risorse di storage devono essere incontaminate da qualsiasi altro tipo di file. Questo serve a garantire che i datafile possano essere ripristinati rapidamente tramite un'operazione di SnapRestore senza distruggere un importante redo log, controlfile o archive log.

SAN presenta requisiti simili per l'isolamento dei datafile all'interno di risorse dedicate. Con un sistema operativo come Microsoft Windows che utilizza AFF storage, un singolo volume può contenere più LUN di datafile, ciascuno con un file system NTFS. Con altri sistemi operativi, in genere è presente un volume manager logico. Ad esempio, con Oracle ASM, l'opzione più semplice sarebbe quella di confinare i LUN di un gruppo di dischi ASM in un singolo volume che può essere sottoposto a backup e ripristinato come un'unità. Se sono necessari volumi aggiuntivi per motivi di prestazioni o gestione della capacità, la creazione di un gruppo di dischi aggiuntivo sul nuovo volume semplifica la gestione.

ASA non dispone di un'astrazione a livello di volume. Utilizza invece gruppi di coerenza. In molti casi, un singolo LUN o namespace NVMe può soddisfare i requisiti di gestione e prestazioni per un database. Se sono necessari più LUN o namespace, è possibile aggiungere risorse aggiuntive e raggrupparle in un gruppo di coerenza che diventa il container dei datafile.

Se queste linee guida vengono seguite, è possibile programmare gli snapshot direttamente sul sistema storage.

Attenzione: verificare che l'ASM spfile e. passwd i file non si trovano nel gruppo di dischi che ospita i file di dati. Ciò interferisce con la capacità di ripristinare selettivamente i dati e solo i file di dati.

== Procedura di ripristino locale—NFS La procedura di base è la seguente:

  1. Arrestare il database.

  2. Ripristina i volumi dei datafile, le LUN o gli spazi dei nomi allo snapshot immediatamente precedente al point-in-time di ripristino desiderato.

  3. Esegui alter database automatic;

Questa procedura presuppone che i log di archivio desiderati siano ancora presenti nel file system attivo. In caso contrario, è necessario ripristinare i registri di archivio, o. rman oppure sqlplus può essere indirizzato ai dati in .snapshot directory.

Inoltre, per i database di dimensioni inferiori, i file di dati possono essere recuperati da un utente finale direttamente da .snapshot Senza l'assistenza di tool di automazione o di un amministratore dello storage per eseguire un comando SnapRestore.

== Procedura di ripristino locale—SAN La procedura di base è la seguente:

  1. Arrestare il database.

  2. Chiudere i gruppi di dischi che ospitano i file di dati. La procedura varia a seconda del volume manager logico scelto. Con ASM, il processo richiede lo smontaggio del gruppo di dischi. Con Linux, i file system devono essere smontati e i volumi logici e i gruppi di volumi sono disattivati. L'obiettivo è quello di interrompere tutti gli aggiornamenti del gruppo di volumi di destinazione da ripristinare.

  3. Ripristinare i gruppi di dischi del file dati nello snapshot immediatamente prima del punto di ripristino desiderato.

  4. Riattivare i gruppi di dischi appena ripristinati.

  5. Esegui alter database automatic;

Questa procedura presuppone che i file di log di archivio desiderati siano ancora presenti nel file system attivo. In caso contrario, i file di log di archivio devono essere ripristinati portando offline i LUN di log di archivio ed eseguendo un ripristino. Questo è anche un esempio in cui risulta utile separare i file di log di archivio in volumi, LUN o namespace dedicati. Se i file di log di archivio condividono un gruppo di volumi con i redo log, questi ultimi devono essere copiati altrove prima del ripristino dell'intero set di LUN per evitare la perdita delle transazioni finali registrate.

== Esempio di ripristino completo Supponi che i file di dati siano stati danneggiati o distrutti e che sia necessario un ripristino completo. La procedura da seguire è la seguente:

[oracle@host1 ~]$ sqlplus / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size                  2924928 bytes
Variable Size            1040191104 bytes
Database Buffers          553648128 bytes
Redo Buffers               13848576 bytes
Database mounted.
SQL> recover automatic;
Media recovery complete.
SQL> alter database open;
Database altered.
SQL>