Voici un court graphique que j'utiliserai pour expliquer quand des orphelins sont créés dans les incarnations d'une base de données. C'est une variation du graphique que j'ai utilisé pour expliquer les incarnations dans ma réponse à la question. Quelqu'un peut-il m'expliquer le concept d '«incarnation» dans la base de données Oracle d'une manière facile à comprendre?
J'espère que vous apprécierez le voyage.
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
Restauration de la base de données à un point dans le temps (1)
Quelque part légèrement après 13 h 00 (13 h 00), quelqu'un décide que la base de données doit être restaurée à 12 h 00 (midi). Le DBA déclenche un tas de commandes RMAN pour restaurer la base de données à ce moment-là ou clique sur son chemin à travers une interface graphique fantastique pour lancer une restauration / récupération à partir d'un fournisseur tiers.
RMAN récupère la sauvegarde complète de la base de données et toutes les sauvegardes du journal d'archivage à partir du disque / bande et les restaure sur le disque. Au cours de la phase de récupération, RMAN vérifiera que toutes les informations pertinentes sont disponibles et reportera toutes les transactions terminées au point dans le temps et restituera toutes les transactions non terminées au point dans le temps, pour garantir que la base de données est dans un état cohérent.
Avant que la base de données puisse être ouverte au grand public, la base de données doit s'assurer que toutes les sauvegardes futures n'entrent pas en conflit avec les sauvegardes précédentes. C'est à ce moment qu'une nouvelle incarnation doit être créée et cela se produit lorsque vous exécutez la commande suivante pour ouvrir la base de données:
ALTER DATABASE OPEN RESETLOGS;
Vous pouvez exécuter le script suivant sur votre instance pour récupérer une vue hiérarchique de vos incarnations (actuelles):
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'incarnation actuelle de la base de données sera similaire à ceci:
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
En utilisant le graphique, nous pouvons voir que nous sommes passés du chemin contenant l'incarnation 1 au chemin avec l'incarnation 2, car nous avons ouvert la base de données avec RESETLOGSet la base de données a créé une nouvelle incarnation.
Restauration de la base de données à un point dans le temps (2)
Supposons à nouveau que la base de données continue de fonctionner après la première action de restauration / récupération et légèrement après 15h00 (15h00), quelqu'un décide qu'il doit effectuer une nouvelle restauration / récupération à l'heure complète à 15h00 (15h00) le même jour.
RMAN restaurera les fichiers, récupérera la base de données et déclenchera une ALTER DATABASE OPEN RESETLOGSremise en ligne de la base de données. L'INCARNATION # sera désormais défini sur 3 et la première sauvegarde à 16h00 contiendra les informations:
INCARNATION# 3
SCN# 500
Time......... 16:00
Si nous interrogeons les incarnations dans la base de données en utilisant le script ci-dessus, nous obtiendrons quelque chose comme ceci:
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
Restauration de la base de données à un point dans le temps (3)
Supposons à nouveau que la base de données continue de fonctionner après la deuxième action de restauration / récupération et légèrement après 17h00 (17h00), quelqu'un décide qu'il doit y avoir une nouvelle restauration / récupération à 14h00 (14h00) le même jour.
RMAN restaurera les fichiers, récupérera la base de données et déclenchera une ALTER DATABASE OPEN RESETLOGSremise en ligne de la base de données. L'INCARNATION # sera désormais défini sur 4 et la première sauvegarde à 18h00 contiendra les informations:
INCARNATION# 4
SCN# 400
Time......... 18:00
Si nous interrogeons les incarnations dans la base de données en utilisant le script ci-dessus, nous obtiendrons quelque chose comme ceci:
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
Que s'est-il passé? Nous avons un orphelin!
Incarnations orphelines ...
Si vous regardez le graphique, nous sommes actuellement sur la place à 18h00 (18h00) avec l'Incarnation 4 et le SCN 400. Maintenant, si vous suivez cette ligne depuis le début, vous pouvez voir que nous passerions de l'incarnation 4 revenir à l'incarnation 2, puis redescendre à l'incarnation 1, qui correspond à la création de la base de données.
Cela correspond également à la sortie (simplifiée) de mes scripts.
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
Que s'est-il donc passé avec l'incarnation 3? L'incarnation 3 est-elle mauvaise ou périmée ou qu'est-ce qui donne?
Réponse
Non, l'incarnation 3 n'est pas mauvaise, elle est juste orpheline.
À plus grande échelle, avec plus de temps entre les sauvegardes et les restaurations, vous pouvez toujours restaurer / récupérer la base de données à un moment précis dans la lignée de l'incarnation 3. Vous définiriez la commande suivante:
RESET DATABASE TO INCARNATION 3;
... puis restaurer / récupérer la base de données à ce point dans le temps comme vous le feriez pour une autre restauration / récupération d'une base de données.
Ce que le ORPHANstatut vous dit, c'est que l'incarnation 3 n'est plus liée à l'état actuel de la base de données avec l'incarnation actuelle 4. L'incarnation orpheline 3 n'est plus requise pour restaurer / récupérer la base de données le long de la chronologie actuelle.
... entraîne des sauvegardes obsolètes
En regardant maintenant les sauvegardes de base de données par rapport à l'incarnation orpheline, bien RMAN détermine que les sauvegardes de l'incarnation orpheline sont OBSOLÈTES. Mais c'est une histoire pour un Q & A différent ...