Di seguito è riportato un breve grafico che userò per spiegare quando gli orfani vengono creati nelle incarnazioni di un database. È una variante del grafico che ho usato per spiegare le incarnazioni nella mia risposta alla domanda Qualcuno può spiegarmi il concetto di "incarnazione" nel database Oracle in modo facile da capire?
Spero che ti piaccia il viaggio.
restore db +-----+ +-----+ +-----+
recover db | 2>3 | --> | 3 | --> | 3 | --> ...
resetlogs +-----+ +-----+ +-----+ ^
^ Incarn 3 3 | 3
/ SCN # 500 600 | 700
/ |
/ |
restore db +-----+ +-----+ +-----+ |
recover db | 1>2 | -------> | 2 | --> | 2 | --> ... |
resetlogs +-----+ +-----+ +-----+ ^ |
^ Incarn. 2 \ 2 | 2 |
/ SCN # 300 \ 400 | 500 |
/ \ | |
/ + --------------------+ |
+-----+ +-----+ +-----+ | \ +-----+ | +-----+
--> | 1 | --> | 1 | --> | 1 | --> ... | +-> | 2>4 | --> | 4 |
+-----+ +-----+ +-----+ ^ | restore db +-----+ | +-----+
Incarn. 1 1 1 | 1 2 | recover db | 4
SCN # 100 200 300 | 400 400 | resetlogs | 400
| | |
Backup 11:00 ----- 12:00 ----- 13:00 ----- 14:00 ----- 15:00 ----- 16:00 ----- 17:00 ----- 18:00
| | |
Restore/ (1) (2) (3)
Recovery
Ripristino del database in tempo reale (1)
Da qualche parte leggermente dopo le 13:00 (13:00) qualcuno decide che il database deve essere ripristinato alle 12:00 (mezzogiorno in punto). Il DBA avvia una serie di comandi RMAN per ripristinare il database fino a quel momento o fa clic su una fantastica GUI per avviare un ripristino / ripristino da un fornitore di terze parti.
RMAN recupera il backup COMPLETO del database e tutti i backup del registro archivio dal disco / nastro e li ripristina sul disco. Nella fase di recupero RMAN verificherà che tutte le informazioni pertinenti siano disponibili e eseguirà il roll forward di tutte le transazioni finite al Point in Time e il rollback di tutte le transazioni non finite al Point in Time, per garantire che il database sia in uno stato coerente.
Prima che il database possa essere aperto al pubblico, il database deve assicurarsi che tutti i backup futuri non siano in conflitto con i backup precedenti. Questo è quando dovrebbe essere creata una nuova incarnazione e succede quando si esegue il comando seguente per aprire il database:
ALTER DATABASE OPEN RESETLOGS;
Puoi eseguire il seguente script sull'istanza per recuperare una vista gerarchica delle tue (attuali) incarnazioni:
set pages 50 --- repeat header every 50 records
set lines 230 --- set lines(ize) length to 230
column path format a40 --- set column path to alpha-numeric 40
alter sessiosn set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
--- set date format of date columns to something more detailed
select
INCARNATION#,
PRIOR_INCARNATION#,
RESETLOGS_CHANGE#,
RESETLOGS_TIME,
STATUS,
SYS_CONNECT_BY_PATH(INCARNATION#, ' -> ') Path
FROM v$database_incarnation
WHERE LEVEL >=1 START WITH INCARNATION# = '1'
CONNECT BY PRIOR INCARNATION# = PRIOR_INCARNATION#
ORDER BY LEVEL, Path, RESETLOGS_TIME;
L'attuale incarnazione del database sarà simile a questa:
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-27 13:20:00 CURRENT -> 1 -> 2
Usando la grafica possiamo vedere che ci siamo spostati dal percorso contenente l'incarnazione 1 al percorso con l'incarnazione 2, perché abbiamo aperto il database con RESETLOGSe il database ha creato una nuova incarnazione.
Ripristino del database per indicare il tempo (2)
Supponiamo di nuovo che il database continui a funzionare dopo la prima azione di ripristino / ripristino e leggermente dopo le 15:00 (15:00) qualcuno decida che è necessario ripristinare un nuovo ripristino / ripristino all'ora intera alle 15:00 (15:00) dello stesso giorno.
RMAN ripristinerà i file, ripristinerà il database e partirà ALTER DATABASE OPEN RESETLOGSper riportare il database online. L'INCARNATION # sarà ora impostato su 3 e il primo backup alle 16:00 conterrà le informazioni:
INCARNATION# 3
SCN# 500
Time......... 16:00
Se interroghiamo le incarnazioni nel database usando lo script sopra otterremo qualcosa del genere:
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-27 13:20:00 PARENT -> 1 -> 2
3 2 400 2018-07-27 15:20:00 CURRENT -> 1 -> 2 -> 3
Ripristino del database in tempo reale (3)
Supponiamo di nuovo che il database continui a funzionare dopo la seconda azione di ripristino / recupero e leggermente dopo le 17:00 (17:00) qualcuno decida che è necessario un nuovo ripristino / recupero alle 14:00 (14:00) dello stesso giorno.
RMAN ripristinerà i file, ripristinerà il database e partirà ALTER DATABASE OPEN RESETLOGSper riportare il database online. L'INCARNATION # sarà ora impostato su 4 e il primo backup alle 18:00 conterrà le informazioni:
INCARNATION# 4
SCN# 400
Time......... 18:00
Se interroghiamo le incarnazioni nel database usando lo script sopra otterremo qualcosa del genere:
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-16 13:20:00 PARENT -> 1 -> 2
3 2 400 2018-07-17 15:20:00 ORPHAN -> 1 -> 2 -> 3
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
Cos'è successo? Abbiamo un orfano!
Incarnazioni orfane ...
Se guardi il grafico, siamo attualmente in piedi sulla piazza alle 18:00 (18:00) con l'Incarnazione 4 e l'SCN 400. Ora se segui quella linea fino all'inizio, puoi vedere che saremmo passati dall'incarnazione 4 eseguire il backup fino all'incarnazione 2 e quindi nuovamente all'incarnazione 1, ovvero quando è stato creato il database.
Ciò corrisponde anche all'output (semplificato) dei miei script.
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
Quindi cosa è successo con l'incarnazione 3? L'Incarnazione 3 è cattiva o viziata o cosa dà?
Risposta
No, l'incarnazione 3 non è male, è solo orfana.
Su una scala più ampia con più tempo tra backup e ripristini, è ancora possibile ripristinare / ripristinare il database fino a un certo punto nel lignaggio dell'incarnazione 3. Si dovrebbe impostare il seguente comando:
RESET DATABASE TO INCARNATION 3;
... e poi ripristina / ripristina il database fino a quel momento come faresti con un altro ripristino / ripristino di un database.
Ciò che lo ORPHANstato ti dice è che l'incarnazione 3 non è più correlata allo stato corrente del database con l'attuale incarnazione 4. L'incarnazione orfana 3 non è più necessaria per ripristinare / ripristinare il database lungo la linea temporale corrente.
... Risultato in backup obsoleti
Ora, guardando i backup del database in relazione all'incarnazione orfana, bene RMAN determina che i backup dell'incarnazione orfana sono OBSOLETE. Ma questa è una storia per una diversa domanda e risposta ...