Ниже приведен краткий рисунок, который я буду использовать, чтобы объяснить, когда в инкарнациях базы данных создаются сироты. Это разновидность рисунка, который я использовал для объяснения воплощений в своем ответе на вопрос. Может ли кто-нибудь объяснить мне понятие «воплощение» в базе данных 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
Восстановление базы данных на определенный момент времени (1)
Где-то чуть позже 13:00 (13:00) кто-то решает, что база данных должна быть восстановлена до 12:00 (12 часов дня). Администратор базы данных либо запускает несколько команд 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и база данных создала новое воплощение.
Восстановление базы данных на определенный момент времени (2)
Давайте снова предположим, что база данных продолжает работать после первого действия по восстановлению / восстановлению, и немного позже 15:00 (15:00) кто-то решает, что необходимо восстановить новое восстановление / восстановление до полного часа в 15:00 (15:00) того же дня.
RMAN восстановит файлы, восстановит базу данных и отправит ее ALTER DATABASE OPEN RESETLOGSобратно в оперативный режим. Теперь для параметра INCARNATION # будет установлено значение 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
Восстановление базы данных на определенный момент времени (3)
Давайте снова предположим, что база данных продолжает работать после второго действия восстановления / восстановления, и немного позже 17:00 (17:00) кто-то решает, что необходимо новое восстановление / восстановление до 14:00 (14:00) того же дня.
RMAN восстановит файлы, восстановит базу данных и отправит ее ALTER DATABASE OPEN RESETLOGSобратно в оперативный режим. Теперь для параметра INCARNATION # будет установлено значение 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 определяет, что резервные копии потерянного воплощения OBSOLETE. Но это история для другого вопроса и ответов ...