Im Folgenden finden Sie eine kurze Grafik, anhand derer ich erläutere, wann Waisen in den Inkarnationen einer Datenbank erstellt werden. Es ist eine Variation der Grafik, mit der ich Inkarnationen in meiner Antwort auf die Frage erklärt habe. Kann mir jemand das Konzept „Inkarnation“ in der Oracle-Datenbank auf leicht verständliche Weise erklären?
Ich hoffe du genießt die Reise.
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
Wiederherstellen der Datenbank auf den Zeitpunkt (1)
Irgendwann kurz nach 13:00 Uhr (13:00 Uhr) entscheidet jemand, dass die Datenbank auf 12:00 Uhr (12:00 Uhr mittags) wiederhergestellt werden muss. Der DBA löst entweder eine Reihe von RMAN-Befehlen aus, um die Datenbank zu diesem Zeitpunkt wiederherzustellen, oder klickt sich durch eine fantastische Benutzeroberfläche, um eine Wiederherstellung / Wiederherstellung von einem Drittanbieter zu initiieren.
RMAN ruft die vollständige Sicherung der Datenbank und aller Archivprotokollsicherungen von der Festplatte / dem Band ab und stellt sie auf der Festplatte wieder her. In der Wiederherstellungsphase prüft RMAN, ob alle relevanten Informationen verfügbar sind, und leitet alle abgeschlossenen Transaktionen zum Zeitpunkt und alle nicht abgeschlossenen Transaktionen zum Zeitpunkt zurück, um sicherzustellen, dass sich die Datenbank in einem konsistenten Zustand befindet.
Bevor die Datenbank für die breite Öffentlichkeit geöffnet werden kann, muss die Datenbank sicherstellen, dass alle zukünftigen Sicherungen nicht mit den vorherigen Sicherungen in Konflikt stehen. In diesem Fall sollte eine neue Inkarnation erstellt werden. Dies geschieht, wenn Sie den folgenden Befehl ausführen, um die Datenbank zu öffnen:
ALTER DATABASE OPEN RESETLOGS;
Sie können das folgende Skript für Ihre Instanz ausführen, um eine hierarchische Ansicht Ihrer (aktuellen) Inkarnationen abzurufen:
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;
Die aktuelle Inkarnation der Datenbank sieht folgendermaßen aus:
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
Anhand der Grafik können wir sehen, dass wir vom Pfad mit der Inkarnation 1 zum Pfad mit der Inkarnation 2 gewechselt sind, weil wir die Datenbank mit geöffnet haben RESETLOGSund die Datenbank eine neue Inkarnation erstellt hat.
Wiederherstellen der Datenbank auf den Zeitpunkt (2)
Nehmen wir noch einmal an, die Datenbank läuft nach der ersten Wiederherstellungs- / Wiederherstellungsaktion weiter und kurz nach 15:00 Uhr (15:00 Uhr) entscheidet jemand, dass am selben Tag um 15:00 Uhr (15:00 Uhr) eine neue Wiederherstellung / Wiederherstellung auf die volle Stunde zurückgesetzt werden muss.
RMAN stellt die Dateien wieder her, stellt die Datenbank wieder her und startet eine ALTER DATABASE OPEN RESETLOGS, um die Datenbank wieder online zu schalten. Die INCARNATION # wird jetzt auf 3 gesetzt und die erste Sicherung um 16:00 Uhr enthält die folgenden Informationen:
INCARNATION# 3
SCN# 500
Time......... 16:00
Wenn wir die Inkarnationen in der Datenbank mit dem obigen Skript abfragen, erhalten wir ungefähr Folgendes:
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
Wiederherstellen der Datenbank auf den Zeitpunkt (3)
Nehmen wir noch einmal an, die Datenbank läuft nach der zweiten Wiederherstellungs- / Wiederherstellungsaktion weiter und kurz nach 17:00 Uhr (17:00 Uhr) entscheidet jemand, dass am selben Tag eine neue Wiederherstellung / Wiederherstellung bis 14:00 Uhr (14:00 Uhr) durchgeführt werden muss.
RMAN stellt die Dateien wieder her, stellt die Datenbank wieder her und startet eine ALTER DATABASE OPEN RESETLOGS, um die Datenbank wieder online zu schalten. Die INCARNATION # wird jetzt auf 4 gesetzt und die erste Sicherung um 18:00 Uhr enthält die folgenden Informationen:
INCARNATION# 4
SCN# 400
Time......... 18:00
Wenn wir die Inkarnationen in der Datenbank mit dem obigen Skript abfragen, erhalten wir ungefähr Folgendes:
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
Was ist passiert? Wir haben eine Waise!
Verwaiste Inkarnationen ...
Wenn Sie sich die Grafik ansehen, stehen wir derzeit um 18:00 Uhr (18 Uhr) mit der Inkarnation 4 und dem SCN 400 auf dem Platz. Wenn Sie nun dieser Linie bis zum Anfang folgen, können Sie sehen, dass wir von der Inkarnation gehen würden 4 Zurück zu Inkarnation 2 und dann zurück zu Inkarnation 1, wenn die Datenbank erstellt wurde.
Dies entspricht auch der (vereinfachten) Ausgabe meiner Skripte.
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
Was ist also mit Inkarnation 3 passiert? Ist die Inkarnation 3 schlecht oder abgestanden oder was gibt es?
Antworten
Nein, die Inkarnation 3 ist nicht schlecht, sie ist nur verwaist.
In größerem Maßstab mit mehr Zeit zwischen Sicherungen und Wiederherstellungen können Sie die Datenbank dennoch zu einem Zeitpunkt in der Inkarnationslinie 3 wiederherstellen / wiederherstellen. Sie würden den folgenden Befehl auslösen:
RESET DATABASE TO INCARNATION 3;
... und dann die Datenbank bis zu diesem Zeitpunkt wiederherstellen / wiederherstellen, wie Sie es bei einer anderen Datenbank tun / wiederherstellen würden.
Der ORPHANStatus sagt Ihnen, dass die Inkarnation 3 nicht mehr mit dem aktuellen Status der Datenbank mit der aktuellen Inkarnation 4 zusammenhängt. Die verwaiste Inkarnation 3 ist nicht mehr erforderlich, um die Datenbank entlang der aktuellen Zeitachse wiederherzustellen / wiederherzustellen.
... führen zu veralteten Backups
Wenn man sich nun die Datenbanksicherungen in Bezug auf die verwaiste Inkarnation ansieht, stellt RMAN fest, dass die Sicherungen der verwaisten Inkarnation OBSOLET sind. Aber das ist eine Geschichte für ein anderes Q & A ...
