oracle内部结构研究

fixlee

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

yc1001aaa

支持楼主一个的哩·！！！

blue_stone

支持一下, 搞内部研究的人很少

dingning239

貌似有用，但是听一些大师们说在生产环境中这样的恢复基本用不到，都是主机备机直接切换的，没有时间让数据库进行恢复

beyondfly

貌似有用，但是听一些大师们说在生产环境中这样的恢复基本用不到，都是主机备机直接切换的，没有时间让数据 ...
dingning239 发表于 2010-03-09 16:38

   
为什么不是负载均衡中的机器互相切换呢

dingning239

rac是另外一种模式啊

dingning239

看很多大师管理的库都是做了rac还做dg了