109 积分	0 好友	9 主题

发消息

[备份恢复] 数据库恢复时内部到底是什么原理，请大神解惑

1^#

发表于 2017-11-10 15:40:30 | 查看: 8154| 回复: 1

测试环境：windows 2008 R2 Enterprise
数据库：oracle 11.2.0.1
在做数据库备份恢复测试时遇到一个问题，请大神解惑

过程说明如下：
=============================================================
先后对测试数据库做了一次全备份，增量备份，然后单独备份了归档日志，
list backup列出备份信息如下：
备份集列表
===================
BS 关键字  类型 LV 大小    设备类型经过时间完成时间
------- ---- -- ---------- ----------- ------------ ----------
59    Incr 0  958.34M DISK       00:01:38    10-11月-17
      BP 关键字: 59 状态: AVAILABLE  已压缩: NO  标记: TAG20171110T142447
段名:E:\BAK\BK_70_1_959696687
  备份集 59 中的数据文件列表
  文件 LV 类型 Ckp SCN Ckp 时间名称
（中间内容省略）
  1 70    14675881 10-11月-17 14751794 10-11月-17
  1 71    14751794 10-11月-17 14768014 10-11月-17

BS 关键字  类型 LV 大小    设备类型经过时间完成时间
------- ---- -- ---------- ----------- ------------ ----------
77    Full 9.61M    DISK       00:00:01    10-11月-17
      BP 关键字: 77 状态: AVAILABLE  已压缩: NO  标记: TAG20171110T144049
段名:E:\BAK\CNTR_88_1_959697649
  包括的控制文件: Ckp SCN: 15849107    Ckp 时间: 10-11月-17

BS 关键字  大小    设备类型占用时间完成时间
------- ---------- ----------- ------------ ----------
78    962.58M DISK       00:01:59    10-11月-17
      BP 关键字: 78 状态: AVAILABLE  已压缩: NO  标记: TAG20171110T144353
段名:E:\BAK\ARC_89_1_959697833

  备份集 78 中的已存档日志列表
  线程序列    低 SCN 时间下限下一个 SCN 下一次
  ---- ------- ---------- ---------- ---------- ---------
  1 72    14768014 10-11月-17 14866772 10-11月-17
  1 73    14866772 10-11月-17 14967901 10-11月-17
(中间内容太多，省略)
1 92    16795398 10-11月-17 16869352 10-11月-17

恢复过程如下：
SQL> shutdown immediate;
SQL> startup nomount;
C:\Users\Administrator>rman target /
RMAN> run {allocate channel ch0 type disk;
2> restore controlfile from 'E:\BAK\CNTR_88_1_959697649';
3> sql 'alter database mount';
4> }

由于最后的归档日志备份是在CNTR_88_1_959697649这一控制文件备份后完成后，因此，此时查看控制文件中记录的备份信息是没有最后一次的归档日志备份信息的，如下所示
RMAN> list backup;

使用目标数据库控制文件替代恢复目录

备份集列表
===================

（中间内容太多，省略）

BS 关键字  大小    设备类型占用时间完成时间
------- ---------- ----------- ------------ ----------
76    649.81M DISK       00:01:25    10-11月-17
      BP 关键字: 76 状态: AVAILABLE  已压缩: NO  标记: TAG20171110T143732
段名:E:\BAK\ARC_87_1_959697560

  备份集 76 中的已存档日志列表
  线程序列    低 SCN 时间下限下一个 SCN 下一次
  ---- ------- ---------- ---------- ---------- ---------
  1 57    13349601 10-11月-17 13455074 10-11月-17
  1 58    13455074 10-11月-17 13560936 10-11月-17
  1 59    13560936 10-11月-17 13666855 10-11月-17
  1 60    13666855 10-11月-17 13772471 10-11月-17
  1 61    13772471 10-11月-17 13874825 10-11月-17
  1 62    13874825 10-11月-17 13970815 10-11月-17
  1 63    13970815 10-11月-17 14073864 10-11月-17
  1 64    14073864 10-11月-17 14174150 10-11月-17
  1 65    14174150 10-11月-17 14276760 10-11月-17
  1 66    14276760 10-11月-17 14375674 10-11月-17
  1 67    14375674 10-11月-17 14477402 10-11月-17
  1 68    14477402 10-11月-17 14582332 10-11月-17
  1 69    14582332 10-11月-17 14675881 10-11月-17
  1 70    14675881 10-11月-17 14751794 10-11月-17
  1 71    14751794 10-11月-17 14768014 10-11月-17

RMAN>

恢复管理器完成。

接下来做Restore和Recover
C:\Users\Administrator>rman target /

已连接到目标数据库: ORA11 (DBID=902159900, 未打开)

RMAN> run {allocate channel ch0 type disk;
2> restore database;
3> recover database;
4> }

使用目标数据库控制文件替代恢复目录
分配的通道: ch0
通道 ch0: SID=1 设备类型=DISK

搜索恢复区中的所有文件
正在编制文件目录...
没有为文件编制目录

通道 ch0: 正在开始还原数据文件备份集
通道 ch0: 正在指定从备份集还原的数据文件
（内容太多，省略）
通通道 ch0: 还原完成, 用时: 00:00:16
完成 restore 于 10-11月-17

启动 recover 于 10-11月-17
通道 ch0: 正在开始还原增量数据文件备份集
通道 ch0: 正在指定从备份集还原的数据文件
（内容太多，省略）
通道 ch0: 正在读取备份片段 E:\BAK\BK_83_1_959697284
通道 ch0: 段句柄 = E:\BAK\BK_83_1_959697284 标记 = TAG20171110T143443
通道 ch0: 已还原备份片段 1
通道 ch0: 还原完成, 用时: 00:00:15
通道 ch0: 正在开始还原增量数据文件备份集
通道 ch0: 正在指定从备份集还原的数据文件
数据文件 00002 的还原目标: E:\APP\ADMINISTRATOR\ORADATA\ORA11\SYSAUX01.DBF
数据文件 00006 的还原目标: E:\APP\ADMINISTRATOR\ORADATA\ORA11\TESTTB.DBF
通道 ch0: 正在读取备份片段 E:\BAK\BK_84_1_959697399
通道 ch0: 段句柄 = E:\BAK\BK_84_1_959697399 标记 = TAG20171110T143443
通道 ch0: 已还原备份片段 1
通道 ch0: 还原完成, 用时: 00:00:04

正在开始介质的恢复

线程 1 序列 119 的归档日志已作为文件 E:\APP\ADMINISTRATOR\ORADATA\ORA11\REDO02.LOG 存在于磁盘上
线程 1 序列 120 的归档日志已作为文件 E:\APP\ADMINISTRATOR\ORADATA\ORA11\REDO03.LOG 存在于磁盘上
线程 1 序列 121 的归档日志已作为文件 E:\APP\ADMINISTRATOR\ORADATA\ORA11\REDO01.LOG 存在于磁盘上
Oracle 错误:
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORA11\SYSTEM01.DBF'

释放的通道: ch0
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: recover 命令 (在 11/10/2017 15:00:41 上) 失败
RMAN-06053: 无法执行介质恢复, 因为缺少日志
RMAN-06025: 没有找到线程 1 序列 81 的归档日志的备份以及起始 SCN 15668712 来还原
RMAN-06025: 没有找到线程 1 序列 80 的归档日志的备份以及起始 SCN 15569466 来还原
RMAN-06025: 没有找到线程 1 序列 79 的归档日志的备份以及起始 SCN 15468288 来还原
RMAN-06025: 没有找到线程 1 序列 78 的归档日志的备份以及起始 SCN 15370654 来还原
RMAN-06025: 没有找到线程 1 序列 77 的归档日志的备份以及起始 SCN 15269396 来还原
RMAN-06025: 没有找到线程 1 序列 76 的归档日志的备份以及起始 SCN 15168352 来还原
RMAN-06025: 没有找到线程 1 序列 75 的归档日志的备份以及起始 SCN 15068158 来还原
RMAN-06025: 没有找到线程 1 序列 74 的归档日志的备份以及起始 SCN 14967901 来还原
RMAN-06025: 没有找到线程 1 序列 73 的归档日志的备份以及起始 SCN 14866772 来还原
RMAN-06025: 没有找到线程 1 序列 72 的归档日志的备份以及起始 SCN 14768014 来还原

RMAN>
此时出错提示找不到序列号为72-81的归档日志，
查看数据文件头，发现数据文件中记录的checkpoint_change#如下
SQL> select name,checkpoint_change# from v$datafile_header;

NAME                                                       CHECKPOINT_CHANGE#
------------------------------------------------------------ ------------------
E:\APP\ADMINISTRATOR\ORADATA\ORA11\SYSTEM01.DBF                         13910668
E:\APP\ADMINISTRATOR\ORADATA\ORA11\SYSAUX01.DBF                         14507951
E:\APP\ADMINISTRATOR\ORADATA\ORA11\UNDOTBS01.DBF                      13910668
E:\APP\ADMINISTRATOR\ORADATA\ORA11\USERS01.DBF                            13910668
E:\APP\ADMINISTRATOR\ORADATA\ORA11\EXAMPLE01.DBF                      13910668
E:\APP\ADMINISTRATOR\ORADATA\ORA11\TESTTB.DBF                               14507951

已选择6行。

我的问题是，从checkpoint_change#来看，最小的是13910668，最大的是14507951，那么个人认为数据库在Recover阶段，应该会寻找checkpoint_change#在13910668---14507951之间的归档日志来修复数据文件，也就是说，我认为此时的报错应该是提示找不到序号为62及后面的归档日志啊？为什么数据库会首先去找Redo中的119，120，121,然后找序列号为72-81的归档日志呢？

请大神解惑，谢谢

分享0