it-swarm.com.de

Was ist eine Waiseninkarnation?

Inkarnationen werden auf dieser Seite in eine Antwort bis eine andere Frage erklärt. Die Antwort erwähnt "verwaiste" Inkarnationen:

… Es gibt andere Faktoren, die zu ORPHANED-Inkarnationen und OBSOLETE-Backups führen…

Ich sehe aus den Oracle-Dokumenten , dass V$DATABASE_INCARNATION Eine STATUS Spalte enthält, die Werte von Orphan, CURRENT haben kann oder PARENT, die verwandt sein müssen.

Was sind 'verwaiste' Inkarnationen und welche Schritte würden zu einer Zeile mit STATUS = Orphan in V$DATABASE_INCARNATION Führen?

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, die ich verwendet habe, um Inkarnationen in meiner Antwort auf die Frage zu erklären. Kann mir jemand erklären das Konzept „Inkarnation“ in der Oracle-Datenbank auf leicht verständliche Weise?

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 RESETLOGS geöffnet haben und 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 setzt ein 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 setzt ein 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 Status Orphan 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 wiederherzustellen/wiederherzustellen die aktuelle Zeitleiste.

... 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 ...

8

RC_DATABASE_INCARNATION

Waisenkind, wenn dies eine nicht aktuelle Inkarnation ist, die kein direkter Vorfahr der aktuellen Inkarnation ist.

Schritte zum Reproduzieren:

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
7
Balazs Papp