Qu'est-ce qu'une incarnation orpheline?
Les incarnations sont expliquées dans ne réponse à ne autre question sur ce site. La réponse mentionne des incarnations "orphelines":
… Il y a d'autres facteurs qui se traduisent par des incarnations ORPHELÉES et des sauvegardes OBSOLÈTES…
Je vois dans la documentation Oracle que V$DATABASE_INCARNATION inclut une colonne STATUS qui peut avoir des valeurs de Orphan, CURRENT ou PARENT, qui doivent être liées.
Quelles sont les incarnations "orphelines" et quelles étapes entraîneraient une ligne avec STATUS = Orphan dans V$DATABASE_INCARNATION?
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 "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 (12 h 00). 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 RESETLOGS et 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 va restaurer les fichiers, récupérer la base de données et déclencher un ALTER DATABASE OPEN RESETLOGS pour remettre la base de données en ligne. 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 va restaurer les fichiers, récupérer la base de données et déclencher un ALTER DATABASE OPEN RESETLOGS pour remettre la base de données en ligne. 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.
Sur une 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 restaurez/récupérez la base de données à ce moment comme vous le feriez pour une autre restauration/récupération d'une base de données.
Ce que le statut Orphan 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 la chronologie actuelle.
... entraîne des sauvegardes obsolètes
Maintenant, en regardant les sauvegardes de la 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 ...
Orphelin s'il s'agit d'une incarnation non courante qui n'est pas un ancêtre direct de l'incarnation actuelle.
Étapes à reproduire:
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 CURRENT
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
3393014
SQL> shu immediate
Database closed.
Database dismounted.
Oracle instance shut down.
SQL> startup mount
Oracle instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 CURRENT
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
3393975
SQL> shu immediate
Database closed.
Database dismounted.
Oracle instance shut down.
SQL> startup mount
Oracle instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393200;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 PARENT
4 CURRENT
SQL> shu immediate
Database closed.
Database dismounted.
Oracle instance shut down.
SQL> startup mount
Oracle instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 Orphan
4 Orphan
5 CURRENT