主页 / dba / 问题 / 213317
Accepted
Jack Douglas
Asked: 2018-07-27 07:34:02 +0800 CST

什么是孤儿化身？

  • 772

化身在本网站上另一个问题的回答中进行了解释。答案提到了“孤儿”化身：

…还有其他因素会导致 ORPHANED 化身和 OBSOLETE 备份…

我从 Oracle 文档中看到，V$DATABASE_INCARNATION其中包含一个STATUS列，该列的值必须为ORPHAN、CURRENT或PARENT，这必须是相关的。

什么是“孤儿”化身，哪些步骤会导致STATUS= ORPHANin出现一行V$DATABASE_INCARNATION？

oracle recovery

2 个回答

  1. Best Answer

    下面是一个简短的图形，我将用它来解释何时在数据库的化身中创建孤儿。这是我在回答问题时用来解释化身的图形的变体，谁能以易于理解的方式向我解释 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（下午 1 点）之后的某个地方，有人决定必须将数据库恢复到 12:00（中午 12 点）。DBA 要么启动一堆 RMAN 命令来将数据库恢复到那个时间点，要么通过出色的 GUI 单击他的方式来启动来自第 3 方供应商的恢复/恢复。

    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（下午 3 点）之后不久，有人决定需要在同一天的 15:00（下午 3 点）重新开始一个新的恢复/恢复到整小时。

    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

    恢复数据库到时间点（三）

    让我们再次假设数据库在第二次恢复/恢复操作之后继续运行，并且在 17:00（下午 5 点）之后，有人决定需要在同一天的 14:00（下午 2 点）进行新的恢复/恢复。

    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（下午 6 点），带着 Incarnation 4 和 SCN 400。现在如果你沿着这条线回到开头，你可以看到我们将从 incarnation 开始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 确定孤立实例的备份已过时。但这是一个不同的问答的故事......

    • 8

  2. RC_DATABASE_INCARNATION

    ORPHAN 如果这是一个非当前化身，它不是当前化身的直接祖先。

    重现步骤：

    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

相关问题