Oracle Recover Internal

SCN

SCN 存在于 Control file,Redo file,Data file,Block. SCN 是恢复数据库的唯一参照的变量 .

 

Control file headers

Control file 中的记录了 Redo file 和 Data file 的 SCN, 该 SCN 号码可能和真正的 Redo file 和 Data file 的 SCN 不一致

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

从这个例子里看出 , 文件 2 的 SCN 和其他文件不同 ,

 

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 file 的 SCN 信息 .

 

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 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 的状态 , 再决定想对应的恢复策略 . 恢复往往必须是一次成功的 , 通过仔细的分析 , 我觉得完全是可以做到的 .

————————————————————————————————

  出自 Parrotao  MSN: parrotao@hotmail.com Email: parrotao@hotmail.com