揭密备份恢复的原理！

easonmy

下面的试验说明了什么道理?
我做了两个试验: 想达到的目的是: redolog没有完全写入datafiles, 不应用任何redolog不完全恢复这些datafiles. 但试验二为什么不能成功呢?


1: 试验一成功)

--DB在open状态时, RMAN全备份DB, 自动备份当前controlfile.
--shutdown DB后,删除所有数据库文件
--RMAN restore controfile, RMAN restore DB.
--不完全恢复DB成功(不应用任何redolog)

2: 试验二不成功)

--DB在 shutdown abort 后: 删除controlfile, redolog, 只保留当前 datafile.
--重建controlfile, 不完全恢复DB(不应用任何redolog)
--不成功, 必须得应用redolog才能openDB.




3: 下面是两个试验的步骤, 请帮我解释一下其中的道理.

1): 试验一(成功)

DB在open状态: rman backup DB,and autobackup controlfile;
shudown DB
RMAN>restore conrtrolfile and mount it;
RMAN>restore DB;

--下面是此时controlfile和datafile_header相关的SCN:

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
            741632

SQL> select name, checkpoint_change#,last_change# from v$datafile;

NAME                                                    CHECKPOINT_CHANGE# LAST_CHANGE#
------------------------------------------------------- ------------------ ------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSTEM01.DBF                  741651
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\UNDOTBS01.DBF                 741651
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSAUX01.DBF                  741651
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\USERS01.DBF                   741651

SQL> select name,checkpoint_change# from v$datafile_header;

NAME                                                    CHECKPOINT_CHANGE#
------------------------------------------------------- ------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSTEM01.DBF                  741651
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\UNDOTBS01.DBF                 741651
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSAUX01.DBF                  741651
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\USERS01.DBF                   741651


-- 下面是此时dump controlfile 和 datafile_header 相关的SCN:

--dump controlfile:   
database_scn 741632
datafile_scn:
ckpt_count:194,  ckpt_scn:741651,  stop_scn:ffff
ckpt_count:155,  ckpt_scn:741651,  stop_scn:ffff
ckpt_count:192,  ckpt_scn:741651,  stop_scn:ffff
ckpt_count:191,  ckpt_scn:741651,  stop_scn:ffff

--dump datafile header:
datafile_scn:
ckpt_count:194,  ckpt_scn:741651,  stop_scn:ffff
ckpt_count:155,  ckpt_scn:741651,  stop_scn:ffff
ckpt_count:192,  ckpt_scn:741651,  stop_scn:ffff
ckpt_count:191,  ckpt_scn:741651,  stop_scn:ffff


-- 不应用redolog恢复成功
recover database until cancel using backup controlfile;
cancel

Media recovery cancelled.






2): 试验二(没有成功)

shutdown abort
delete all controlfile and redolog

startup nomount
create new controlfile from tracefile;

--下面是此时controlfile和datafile_header相关的SCN:

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
                 0

SQL> select name, checkpoint_change#,last_change# from v$datafile;

NAME                                                    CHECKPOINT_CHANGE# LAST_CHANGE#
------------------------------------------------------- ------------------ ------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSTEM01.DBF                  690962
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\UNDOTBS01.DBF                 690962
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSAUX01.DBF                  690962
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\USERS01.DBF                   690962


SQL> select name,checkpoint_change# from v$datafile_header;

NAME                                                    CHECKPOINT_CHANGE#
------------------------------------------------------- ------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSTEM01.DBF                  690962
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\UNDOTBS01.DBF                 690962
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSAUX01.DBF                  690962
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\USERS01.DBF                   690962


-- 下面是此时dump controlfile 和 datafile_header 相关的SCN:

--dump controlfile:   
database 0
datafile:
ckpt_count:175, ckpt_scn:690962, stop_scn:ffff
ckpt_count:136, ckpt_scn:690962, stop_scn:ffff
ckpt_count:173, ckpt_scn:690962, stop_scn:ffff
ckpt_count:172, ckpt_scn:690962, stop_scn:ffff

--dump datafile header:
datafile:
ckpt_count:175, ckpt_scn:690962, stop_scn:ffff
ckpt_count:136, ckpt_scn:690962, stop_scn:ffff
ckpt_count:173, ckpt_scn:690962, stop_scn:ffff
ckpt_count:172, ckpt_scn:690962, stop_scn:ffff


-- 不应用redolog不能恢复成功(必须得应用active和current的log,才可打开数据库,为什么呢?)

SQL> recover database until cancel using backup controlfile;
ORA-00279: change 690962 generated at 04/16/2009 09:48:40 needed for thread 1
ORA-00289: suggestion : E:\ARCHIVE\ARC00005_0684254321.1
ORA-00280: change 690962 for thread 1 is in sequence #5


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\SYSTEM01.DBF'

warehouse

其实试验二不成功的原因在于：你执行的是shutdown abort...

easonmy

原帖由 warehouse 于 2009-4-17 08:32 发表
其实试验二不成功的原因在于：你执行的是shutdown abort...

大哥, 我就是不明白为什么abort后不行呀.
理论上abort后数据文件不一致,因为datafile_header上的stop_scn=ffffff, 必须要用redolog同步它们.
但rman备份的datafile_header的stop_scn也是fffff呀, 但却可以不应用redo而恢复. 它们的区别在于哪里呢?
这个不一致oracle是怎么进行判断的呢? 具体是哪个指标说明了它不一致呢??

warehouse

原帖由 easonmy 于 2009-4-17 09:07 发表



大哥, 我就是不明白为什么abort后不行呀.
理论上abort后数据文件不一致,因为datafile_header上的stop_scn=ffffff, 必须要用redolog同步它们.
但rman备份的datafile_header的stop_scn也是fffff呀, 但却可以不应用redo而恢复. 它们的区别在于哪里呢?
这个不一致oracle是怎么进行判断的呢? 具体是哪个指标说明了它不一致呢??

试验一shutdown db也是abort？

easonmy

试验结果:  rman 备份shutdown abort 后的DB, restore后, 恢复必须应用redolog才能打开.
这说明: abort后的DB是不一致的, 必须用redolog去恢复DB到一致状态.

但我想知道的是oracle怎么判断出这个DB是不一致的呢?
把此时的DB_header  dump下来, 哪些指标能够说明当前这个DB是abort后的, 是不一致的呢??

原帖由 warehouse 于 2009-4-17 15:34 发表


试验一shutdown db也是abort？

easonmy

比如说:  
我现在给你了一个DB(所有datafiles), 和一个controlfile的创建脚本(当然不给这个脚本也可以),
要你把这个DB打开(不用隐含参数).

如果你现在没办法打开这个DB, 你怎么说服我是由于这个DB本身不一致(abort后的),而没法打开它??

easonmy

dump 的 datafile_header中有这样几个条目:

-- start_scn(time)
-- stop_scn(time)
-- recover_time

1: 当各datafile的stop_scn有值且相同时, 显然这个DB是一致的,oracle可以直接打开它.

2: 当stop_scn是null时
----- 若 recover_time < start_scn(time): 说明这个DB是不一致的. 没法直接打开
----- 若 recover_time > start_scn(time): 说明在start_scn和stop_scn之间有可能有一个SCN在这个点上DB是一致的. 数据库可以打开到这个SCN点上. 但我在dump中没有发现这个SCN, 只有发现recover_time, 但recover_time 并不能确切说明DB的一致性.

望指点 !!!!!

[ 本帖最后由 easonmy 于 2009-4-17 16:38 编辑 ]

snowfox326

很好很经典！

liuya1985liuya

好贴 学习了

kisschina

强大................