oracle数据库恢复_内部结构研究

Oracle Recover Internal[align=right] 转载于Parrotao [color=#000066]SCNSCN存在于Control file,Redo file,Data file,Block. SCN是恢复数据库的唯一参照的变量. [color=#000066]Control file headersControl file中的记录了Redo file和Data file的SCN,该SCN号码可能和真正的Redo file和Data file的SCN不一致[color=#000066]DumpALTER SESSION SET EVENTS 'immediate trace name controlf level 10';[color=#000066]Read Dump1. Checkpointed at scn: 0x0000.00057a802. 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:08Next scn: 0x0000.00057a7f 04/29/2004 01:08:38LOG 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:12LOG FILE #3:Low scn: 0x0000.0004dd74 02/15/2004 23:13:12Next 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 3590403590400x0000.00057a80 = 359040(10进位) [color=#000066]Data file headers[color=#000066]Dumpalter session set events 'immediate trace name FILE_HDRS level 10';[color=#000066]Read Dump在Dump文件里可以找到所有的数据文件的SCN号码Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56Checkpointed at scn: 0x0000.0005c903 05/07/2004 20:23:44Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56Checkpointed at scn: 0x0000.00061789 05/07/2004 21:19:56从这个例子里看出,文件2的SCN和其他文件不同, Select NEXT_CHANGE from v$log_history;从NEXT_CHANGE的输出就可以看到恢复的时候需要哪个Archive log文件了.
[color=#000066]Redo log headers[color=#000066]Dumpalter session set events 'immediate trace name REDOHDR level 10';[color=#000066]Read DumpLOG FILE #1:(name #1) /u01/oracle/8.1.7/OraHome/oradata/orcl/redo03.logThread 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. [color=#000066]Using backup control file我理解就是在恢复过程中,忽略Control file的SCN信息. [color=#000066]Advance Recover Step:Dump Data file HeaderData 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 Log的SCN是否涵盖Data file的SCN号, 并Check Disk cksum和Calc cksum是否一致. 如果Data file的SCN和Redo log的SCN可以对应上,并且Redo log的Chksum没有问题,那无疑是可以完全恢复的.如果Data file的SCN 小于Redo log的SCN的最小值,则需要Archive log进行恢复. Control file在整个恢复过程中用处不大,即使完全丢失去,也可以通过重建控制文件来得到必要的恢复信息. 建议在所有恢复之前,做Control file / Redo file / Data file的header倒出,确认现在整个数据库SCN的状态,再决定想对应的恢复策略.恢复往往必须是一次成功的,通过仔细的分析,我觉得完全是可以做到的.