Wcielenia wyjaśniono w odpowiedzi na inne pytanie na tej stronie. Odpowiedź wspomina o „osieroconych” wcieleniach:
… Istnieją inne czynniki, które powodują wcielenia osierocone i kopie zapasowe OBSOLETE…
Widzę z docs Oracle , który V$DATABASE_INCARNATIONzawiera STATUSkolumny, które mogą mieć wartości ORPHAN, CURRENTlub PARENT, które muszą być spokrewnieni.
Co to są „osierocone” inkarnacje i jakie kroki doprowadziłyby do powstania wiersza z STATUS= ORPHANw V$DATABASE_INCARNATION?
Odpowiedzi:
Poniżej znajduje się krótka grafika, której użyję do wyjaśnienia, kiedy sieroty powstają we wcieleniach bazy danych. Jest to odmiana grafiki, której użyłem do wyjaśnienia inkarnacji w mojej odpowiedzi na pytanie. Czy ktoś może mi wyjaśnić pojęcie „inkarnacja” w bazie danych Oracle w łatwy do zrozumienia sposób?
Mam nadzieję, że spodoba ci się podróż.
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 Gdzieś nieco po 13:00 (13:00) ktoś decyduje, że należy przywrócić bazę danych do godziny 12:00 (południe w południe). DBA albo uruchamia kilka poleceń RMAN, aby przywrócić bazę danych do tego momentu, albo klika swoją drogę przez fantastyczny GUI, aby zainicjować przywracanie / odzyskiwanie od zewnętrznego dostawcy.
RMAN pobiera PEŁNĄ kopię zapasową bazy danych i wszystkich kopii zapasowych dziennika archiwalnego z dysku / taśmy i przywraca je na dysk. W fazie odzyskiwania RMAN sprawdzi, czy wszystkie istotne informacje są dostępne, i przeniesie wszystkie zakończone transakcje do Punktu w czasie i cofnie wszystkie niedokończone transakcje do Punktu w Czasie, aby zapewnić spójność bazy danych.
Zanim baza danych będzie dostępna dla ogółu społeczeństwa, musi ona upewnić się, że wszystkie przyszłe kopie zapasowe nie będą kolidować z poprzednimi kopiami zapasowymi. Właśnie wtedy należy utworzyć nowe wcielenie i dzieje się to po wykonaniu następującego polecenia, aby otworzyć bazę danych:
ALTER DATABASE OPEN RESETLOGS;Możesz uruchomić następujący skrypt dla swojej instancji, aby odzyskać hierarchiczny widok (obecnych) inkarnacji:
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;Obecne wcielenie bazy danych będzie podobne do tego:
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 -> 2Za pomocą grafiki widzimy, że przeszliśmy ze ścieżki zawierającej wcielenie 1 na ścieżkę z wcieleniem 2, ponieważ otworzyliśmy bazę danych za pomocą, RESETLOGSa baza danych utworzyła nowe wcielenie.
Załóżmy jeszcze raz, że baza danych działa po pierwszej operacji przywracania / odzyskiwania i nieco po 15:00 (15:00) ktoś decyduje, że konieczne jest przywrócenie nowego przywracania / odzyskiwania do pełnej godziny o 15:00 (15:00) tego samego dnia.
RMAN przywróci pliki, odzyska bazę danych i uruchomi ALTER DATABASE OPEN RESETLOGSbazę danych z powrotem do trybu online. INCARNATION # zostanie teraz ustawione na 3, a pierwsza kopia zapasowa o godzinie 16:00 będzie zawierać informacje:
INCARNATION# 3
SCN# 500
Time......... 16:00Jeśli zapytamy o inkarnacje w bazie danych za pomocą powyższego skryptu, otrzymamy coś takiego:
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 -> 3Załóżmy jeszcze raz, że baza danych działa po drugim działaniu przywracania / odzyskiwania i nieco po 17:00 (17:00) ktoś decyduje, że konieczne jest nowe przywracanie / odzyskiwanie z powrotem do 14:00 (14:00) tego samego dnia.
RMAN przywróci pliki, przywróci bazę danych i uruchomi ALTER DATABASE OPEN RESETLOGSbazę danych z powrotem do trybu online. INCARNATION # zostanie teraz ustawione na 4, a pierwsza kopia zapasowa o godzinie 18:00 będzie zawierać informacje:
INCARNATION# 4
SCN# 400
Time......... 18:00Jeśli zapytamy o inkarnacje w bazie danych za pomocą powyższego skryptu, otrzymamy coś takiego:
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 -> 4Co się stało? Mamy sierotę!
Jeśli spojrzysz na grafikę, stoimy obecnie na placu o 18:00 (18:00) z Wcieleniem 4 i SCN 400. Teraz, jeśli pójdziesz tą linią z powrotem na początek, możesz zobaczyć, że przeszlibyśmy z wcielenia 4 z powrotem do inkarnacji 2, a następnie z powrotem do inkarnacji 1, czyli w momencie tworzenia bazy danych.
To także odpowiada (uproszczonemu) wynikowi moich skryptów.
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4Co się stało z wcieleniem 3? Czy Incarnation 3 jest zły, czy nieaktualny, czy co daje?
Nie, wcielenie 3 nie jest złe, jest po prostu osierocone.
Na większą skalę, z większą ilością czasu między kopiami zapasowymi a przywracaniem, nadal możesz przywracać / odzyskiwać bazę danych do punktu w czasie z linii wcielenia 3. Uruchomiłbyś następujące polecenie:
RESET DATABASE TO INCARNATION 3;... a następnie przywróć / przywróć bazę danych do tego momentu, tak jak w przypadku przywracania / odzyskiwania bazy danych.
Co do ORPHANstanu nie powiedzieć, jest to, że wcielenie 3 nie jest już związany z aktualnym stanem bazy danych z obecnego wcielenia 4. osierocony wcielenie 3 nie jest już konieczne, aby przywrócić / odzyskać bazę wzdłuż obecnego czasu.
Patrząc teraz na kopie zapasowe bazy danych w odniesieniu do osieroconego wcielenia, dobrze RMAN określa, że kopie zapasowe osieroconego wcielenia są OBSOLETOWANE. Ale to historia różnych pytań i odpowiedzi ...
ORPHAN, jeśli jest to wcielenie nieprądowe, które nie jest bezpośrednim przodkiem obecnego wcielenia.
Kroki ku reprodukcji:
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