关闭

Oracle Recover Internal

2178人阅读 评论(0) 收藏 举报
SCN
SCN存在于Control file,Redo file,Data file,Block. SCN是恢复数据库的唯一参照的变量.
 
Control file headers
Control file中的记录了Redo fileData fileSCN,SCN号码可能和真正的Redo fileData fileSCN不一致
Dump
ALTER SESSION SET EVENTS 'immediate trace name controlf level 10';
Read Dump
1.      Checkpointed at scn: 0x0000.00057a80
2.      Incmplt recovery scn: 0x0000.00000000(如果恢复过该号码不是0)
3.      Redo in Control file
THREAD #1 - status:0x7 thread links forward:0 back:0
#logs:3 first:1 last:3 current:2 last used seq#:0x9b
 
LOG FILE #1:
Low scn: 0x0000.00052c26 04/28/2004 20:54:08
Next scn: 0x0000.00057a7f 04/29/2004 01:08:38
LOG FILE #2:
 (name #2) /u01/oracle/8.1.7/OraHome/oradata/orcl/redo02.log
 Thread 1 redo log links: forward: 3 backward: 1
 siz: 0x3e8 seq: 0x0000009b hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00052c26
 Low scn: 0x0000.00057a7f 04/29/2004 01:08:38
 Next scn: 0xffff.ffffffff 02/15/2004 23:13:12
LOG FILE #3:
Low scn: 0x0000.0004dd74 02/15/2004 23:13:12
Next scn: 0x0000.00052c26 04/28/2004 20:54:08
 
4.      Data file in Control file
[oracle@Oracle udump]$ grep "Checkpoint cnt" ora_569.trc | more
 Checkpoint cnt:3073 scn: 0x0000.00057a80 04/29/2004 01:08:38
 Checkpoint cnt:2993 scn: 0x0000.00057a80 04/29/2004 01:08:38
 Checkpoint cnt:2993 scn: 0x0000.00057a80 04/29/2004 01:08:38
 Checkpoint cnt:2993 scn: 0x0000.00057a80 04/29/2004 01:08:38
 Checkpoint cnt:2993 scn: 0x0000.00057a80 04/29/2004 01:08:38
 Checkpoint cnt:2993 scn: 0x0000.00057a80 04/29/2004 01:08:38
 Checkpoint cnt:730 scn: 0x0000.00057a80 04/29/2004 01:08:38
 Checkpoint cnt:42 scn: 0x0000.00057a80 04/29/2004 01:08:38
 
SQL> select CHECKPOINT_CHANGE# from v$datafile;
 
CHECKPOINT_CHANGE#
------------------
            359040
            359040
            359040
            359040
            359040
            359040
            359040
359040
0x0000.00057a80 = 359040(10进位)
 
Data file headers
Dump
alter session set events 'immediate trace name FILE_HDRS level 10';
Read Dump
Dump文件里可以找到所有的数据文件的SCN号码
 [oracle@Oracle udump]$ grep "Checkpointed at scn" ora_779.trc | grep -v Backup | grep -v Online | grep -v Creation
Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56
Checkpointed at scn: 0x0000.0005c903 05/07/2004 20:23:44
Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56
Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56
Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56
Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56
Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56
Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56
从这个例子里看出,文件2SCN和其他文件不同,
 
Select NEXT_CHANGE from v$log_history;
NEXT_CHANGE的输出就可以看到恢复的时候需要哪个Archive log文件了.
 
Redo log headers
Dump
alter session set events 'immediate trace name REDOHDR level 10';
Read Dump
LOG FILE #1:
(name #1) /u01/oracle/8.1.7/OraHome/oradata/orcl/redo03.log
Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x3e8 seq: 0x00000004 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0006660a
 Low scn: 0x0000.0006b455 05/08/2004 01:58:48
 Next scn: 0xffff.ffffffff 05/07/2004 23:57:51
 FILE HEADER:
        Software vsn=135294976=0x8107000, Compatibility Vsn=135290880=0x8106000
        Db Id=989524584=0x3afaf268, Db Name='ORCL'
        Control Seq=9645=0x25ad, File size=1000=0x3e8
        File Number=1, Blksiz=512, File Type=2 LOG
 descrip:"Thread 0001, Seq# 0000000004, SCN 0x00000006b455-0xffffffffffff"
 thread: 1 nab: 0xffffffff seq: 0x00000004 hws: 0x2 eot: 1 dis: 0
 reset logs count: 0x1f5383b0 scn: 0x0000.0006178b
 Low scn: 0x0000.0006b455 05/08/2004 01:58:48
 Next scn: 0xffff.ffffffff 05/07/2004 23:57:51
 Enabled scn: 0x0000.0006178b 05/07/2004 22:48:16
 Thread closed scn: 0x0000.0006b455 05/08/2004 01:58:48
 Log format vsn: 0x8000000 Disk cksum: 0x49b4 Calc cksum: 0x49b4
通过Cksum就可以发现Logfile是不是有问题.
Next scn如果是0xffff.ffffffff的话,表示该Log是当前的Online redo log.
 
Using backup control file
我理解就是在恢复过程中,忽略Control fileSCN信息.
 
Advance Recover Step:
Dump Data file Header
Data file Checkpoint 如果不一样,说明必须用Archive/Redo Log进行恢复
Check V$LOG_archive 找出对应的Archive Log.
如果在V$LOG_archive中没有对应的记录,则说明需要Online Redo Log进行恢复
 
Data file Checkpoint 一样,
Dump Redo log file header, 确认当前的Redo LogSCN是否涵盖Data fileSCN, Check Disk cksumCalc cksum是否一致.
 
如果Data fileSCNRedo logSCN可以对应上,并且Redo logChksum没有问题,那无疑是可以完全恢复的.
如果Data fileSCN 小于Redo logSCN的最小值,则需要Archive log进行恢复.
 
Control file在整个恢复过程中用处不大,即使完全丢失去,也可以通过重建控制文件来得到必要的恢复信息.
 
建议在所有恢复之前,Control file / Redo file / Data fileheader倒出,确认现在整个数据库SCN的状态,再决定想对应的恢复策略.恢复往往必须是一次成功的,通过仔细的分析,我觉得完全是可以做到的.
————————————————————————————————
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:23205次
    • 积分:340
    • 等级:
    • 排名:千里之外
    • 原创:8篇
    • 转载:15篇
    • 译文:0篇
    • 评论:1条
    文章分类