Утілення пояснюється у відповіді на інше питання на цьому сайті. У відповіді згадуються «осиротілі» втілення:
… Є й інші фактори, які призводять до оРФАНОВАНИХ втілень та резервного копіювання OBSOLETE…
Я бачу з документації Oracle , яка V$DATABASE_INCARNATIONвключає в себе STATUSстовпець , який може мати значення ORPHAN, CURRENTчи PARENT, які повинні бути пов'язані між собою .
Що таке "осиротілі" втілення та які кроки призведе до ряду з STATUS= ORPHANin V$DATABASE_INCARNATION?
Відповіді:
Далі йде коротка графіка, яку я буду використовувати для пояснення, коли діти-сироти створюються у втіленнях бази даних. Це різновид графіки, яку я використовував для пояснення втілень у своїй відповіді на питання Чи може хто-небудь пояснити мені поняття «втілення» в базі даних Oracle легко зрозумілим способом?
Сподіваюся, вам подобається подорож.
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 Десь трохи після 13:00 (13:00) хтось вирішить, що база даних повинна бути відновлена до 12:00 (12:00 полудня). DBA або встановлює купу команд RMAN для відновлення бази даних до цього моменту, або натискає шлях через фантастичний графічний інтерфейс, щоб ініціювати відновлення / відновлення у стороннього постачальника.
RMAN витягує ПОЛЮ резервну копію бази даних та всіх резервних копій журналу архіву з диска / стрічки та відновлює їх на диску. На етапі відновлення RMAN перевірить наявність всієї відповідної інформації та передасть усі готові транзакції до пункту «Час у часі» та поверне всі незавершені транзакції до пункту «Час у часі», щоб забезпечити відповідність базі даних.
Перед тим, як база даних може бути відкрита для широкого загалу, база даних повинна переконатися, що всі майбутні резервні копії не суперечать попереднім резервним копіям. Це коли слід створити нове втілення, і це відбувається, коли ви виконаєте наступну команду для відкриття бази даних:
ALTER DATABASE OPEN RESETLOGS;Ви можете запустити наступний скрипт проти свого примірника, щоб отримати ієрархічний вигляд ваших (поточних) втілень:
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;Поточне втілення бази даних буде подібним до цього:
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Використовуючи графіку, ми бачимо, що ми перейшли з шляху, що містить втілення 1, до шляху з втіленням 2, оскільки ми відкрили базу даних RESETLOGSі база даних створила нове втілення.
Давайте знову припустимо, що база даних продовжує працювати після першої дії відновлення / відновлення, і трохи після 15:00 (15:00) хтось вирішить, що потрібно того ж дня відновити / відновити назад до повної години о 15:00 (15:00) того ж дня.
RMAN відновить файли, відновить базу даних і розпочне відновлення ALTER DATABASE OPEN RESETLOGSбази даних в Інтернеті. УНІВЕРСАЦІЯ # тепер буде встановлено на 3, а перша резервна копія о 16:00 міститиме інформацію:
INCARNATION# 3
SCN# 500
Time......... 16:00Якщо ми запитаємо втілення в базі даних за допомогою наведеного вище сценарію, ми отримаємо щось подібне:
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Давайте знову припустимо, що база даних продовжує працювати після другої дії відновлення / відновлення, і трохи після 17:00 (17:00) хтось вирішить, що цього ж дня потрібно буде відновити / відновити назад до 14:00 (14:00).
RMAN відновить файли, відновить базу даних і розпочне відновлення ALTER DATABASE OPEN RESETLOGSбази даних в Інтернеті. УНІВЕРСАЦІЯ # буде встановлено на 4, а перша резервна копія о 18:00 міститиме інформацію:
INCARNATION# 4
SCN# 400
Time......... 18:00Якщо ми запитаємо втілення в базі даних за допомогою наведеного вище сценарію, ми отримаємо щось подібне:
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Що сталося? У нас сирота!
Якщо ви подивитесь на графіку, ми зараз стоїмо на площі о 18:00 (18:00) із Втіленням 4 та SCN 400. Тепер, якщо ви будете слідувати цьому рядку до початку, ви можете побачити, що ми пішли б із втілення 4 резервне копіювання до втілення 2, а потім назад до втілення 1, яке відбувається при створенні бази даних.
Це також відповідає (спрощеному) виводу моїх сценаріїв.
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4Отже, що сталося з втіленням 3? Чи втілення 3 погано чи несвіжий чи що дає?
Ні, втілення 3 непогане, це просто сирота.
У більш масштабному масштабі із збільшенням часу між резервними копіями та відновленнями ви все одно можете відновити / відновити базу даних до певного моменту в рядку втілення 3. Ви відкладете наступну команду:
RESET DATABASE TO INCARNATION 3;... а потім відновити / відновити базу даних до цього моменту, як і інші відновити / відновити базу даних.
Те, що ORPHANговорить вам статус, - це те, що втілення 3 більше не пов'язане з поточним станом бази даних з поточним втіленням. 4. Осиротіло втілення 3 більше не потрібно для відновлення / відновлення бази даних по поточній шкалі часу.
Тепер, дивлячись на резервні копії бази даних стосовно осиротілого втілення, RMAN визначає, що резервні копії осиротілого втілення є ОБОВ'ЯЗАНОМ. Але це історія для різних питань і відповідей ...
ОРФАН, якщо це непоточне втілення, яке не є прямим родоначальником поточного втілення.
Кроки до відтворення:
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