Oracle
 sql >> Database >  >> RDS >> Oracle

Meccanismo Segue da Oracle quando prendiamo il backup a caldo

Backup a caldo significa che il sistema è attivo e funzionante e che gli aggiornamenti procedono normalmente

Vorrei qui spiegare il meccanismo seguito da Oracle quando eseguiamo il backup a caldo

Backup manuale

Avvio manuale dell'hotbackup con il comando seguente per un tablespace

alter tablespace USERS inizia il backup;

Succedono poche cose in quel momento
1)DBWn controlla il tablespace (scrive tutti i blocchi sporchi a partire da un determinato SCN)

2)CKPT interrompe l'aggiornamento del campo SCN del checkpoint nelle intestazioni del file di dati e inizia invece ad aggiornare il campo SCN del checkpoint di Hot Backup
Le intestazioni del file di dati che contengono l'SCN dell'ultimo checkpoint completato non vengono aggiornate mentre un file è in modalità di backup a caldo . Ciò consente al processo di ripristino di comprendere quali file di registro di ripristino dell'archivio potrebbero essere necessari per ripristinare completamente questo file.

3) LGWR inizia a registrare le immagini complete dei blocchi modificati la prima volta che un blocco viene modificato dopo essere stato scritto da DBWn
La prima volta che un blocco viene modificato in un file di dati che è in modalità di backup a caldo, l'intero blocco viene scritto nel ripetere i file di registro, non solo i byte modificati. Normalmente vengono scritti solo i byte modificati (un vettore di ripristino). Nella modalità di backup a caldo, l'intero blocco viene registrato per la prima volta. Questo perché puoi entrare in una situazione in cui il processo che copia il file di dati e DBWR stanno lavorando sullo stesso blocco contemporaneamente.
Diciamo che lo sono e il fattore di lettura del blocco del sistema operativo è 2K . Il programma di backup va a leggere un blocco Oracle da 8k. Il sistema operativo gli dà 4k. Nel frattempo — DBWR ha chiesto di riscrivere questo blocco. il sistema operativo pianifica che la scrittura DBWR avvenga in questo momento. L'intero blocco di 8k viene riscritto. Il programma di backup ricomincia a funzionare (qui OS multitasking) e legge gli ultimi 4k del blocco. Il programma di backup ha ora un blocco fratturato:la testa e la coda risalgono a due punti temporali.
Oracle non può gestirlo durante il ripristino. Quindi, registriamo l'intera immagine del blocco in modo che durante il ripristino, questo blocco venga completamente riscritto da redo ed è almeno coerente con se stesso. Possiamo recuperarlo da lì.

Punto importante nel backup a caldo

1) Per limitare l'effetto di questa registrazione aggiuntiva, è necessario assicurarsi di posizionare solo uno spazio tabella alla volta in modalità backup e portare lo spazio tabella fuori dalla modalità backup non appena è stato eseguito il backup. Ciò ridurrà il numero di blocchi che potrebbero dover essere registrati al minimo possibile.

2) Se il tablespace è in modalità hotbackup e il database viene interrotto. E poi provi ad avviare, si lamenterà del ripristino poiché il file di dati SCN di quel tablespace sarà più vecchio, quindi per avviare il database, dobbiamo prima terminare il backup di quel tablespace. Aggiorna semplicemente il checkpoint SCN con Hot Backup Checkpoint SCN
Backup del gestore di ripristino
Non è necessario mettere il tablespace in modalità hotbackup per eseguire il backup utilizzando la modalità hotback
Poiché RMAN è uno strumento Oracle, sanno come gestire il caso di blocco fratturato, quindi non scrive frammenti di blocco o blocchi parziali nel backup, scrive l'immagine del blocco coerente completa sul supporto di backup. Quindi il gestore del ripristino non ha bisogno di registrare il blocco completo nel file di registro di ripristino. Quindi significa un enorme risparmio nella registrazione di ripristino dal caso di hotbackup manuale

Inoltre rman non blocca l'intestazione del file di dati, continua a fare il checkpoint altrettanto regolarmente, ma esegue un checkpoint nel tablespace.

Il backup RMAN annota l'SCN iniziale,Absolute Fuzzy SCN (che è lo stesso dell'SCN iniziale all'inizio) quando inizia il backup e poiché i blocchi vengono salvati nel file di dati, il blocco viene controllato per l'SCN, se è maggiore dell'inizio SCN, Absolute Fuzzy SCN viene aggiornato con quel numero. Lo stesso vale per tutti i blocchi, quando viene eseguito il backup dell'intero file di dati, entrambi i numeri vengono archiviati nell'intestazione del backup.

Quindi, ogni volta che RMAN ha ripristinato questi backup, sanno che sa da quale SCN inizia a finire SCN, deve recuperare il file di dati di sicuro

Quindi fondamentalmente non c'è alcun sovraccarico come un aumento della registrazione nel backup a caldo RMAN.

Lo stesso vale per il backup dell'immagine con RMAN