Oracle Recover Internal

转载 2006年06月07日 16:38:00
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的状态,再决定想对应的恢复策略.恢复往往必须是一次成功的,通过仔细的分析,我觉得完全是可以做到的.
————————————————————————————————
  出自 Parrotao  MSN: parrotao@hotmail.com Email: parrotao@hotmail.com

相关文章推荐

Tracing Oracle Internal Calls

  • 2011年03月04日 20:32
  • 418KB
  • 下载

oracle备份恢复之recover database的四条语句区别

oracle备份恢复之recover database的四条语句区别   2011-09-20 11:27:48|  分类: Oracle备份恢复 |  标签: |字号大中小 订阅 ...

Oracle 9i Backup and Recover Lab Scripts

  • 2008年08月01日 01:18
  • 310KB
  • 下载

oracle 10g 报错:ORA-00257: archiver error. Connect internal only, until freed

今天在公司,突然同事告诉我数据库无法登录了,想想这段时间没有动过库,为什么无法登录呢?一边想是什么问题,一边连接测试登录。 首先报错:ORA-00257: archiver error. Conne...

oracle redo internal

  • 2011年10月14日 23:04
  • 525KB
  • 下载

Oracle8i Internal 封面&第一章

简介: 本书基于Oracle 8i和Oracle 8.1版本,包括了详细的,难以找寻到的关于Oracle 内部结构的信息(数据结构,算法,隐含参数,以及文档上未说明的系统统计信息)。 主要议题包括...
  • empoli
  • empoli
  • 2012年10月07日 13:40
  • 481

How Oracle Store Number internal?

Oracle在数据库内部通过相应的算法转换来进行数据存储,本文简单介绍Oracle的Number型数值存储及转换.这个内容是为了回答留言板上的2119号问题. 我们可以通过DUMP函数来转换数字...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Oracle Recover Internal
举报原因:
原因补充:

(最多只允许输入30个字)