关于数据文件头信息记录

这个测试的起因是一些朋友讨论,Oracle在恢复时从何处获得日志文件名信息.

因为如果在重建控制文件的过程中,控制文件中的信息显然已经被清空了.

参考链接:

http://www.itpub.net/showthread.php?threadid=232777

下面是一些简单测试及说明.

1.转储控制文件头

 

[oracle@jumper udump]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.3.0 - Production on Thu Jun 17 15:27:37 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production

SQL> ALTER SESSION SET EVENTS ' IMMEDIATE TRACE NAME FILE_HDRS LEVEL 10';

Session altered.

 

notes:

ALTER SESSION SET EVENTS ' IMMEDIATE TRACE NAME FILE_HDRS LEVEL 10';

用于转储数据文件头信息.

 

2.获得以下跟踪文件信息(仅摘录system表空间记录,请注意红色部分):

 

 

DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1557 scn: 0x0000.014338dc 06/13/2004 01:19:38
Stop scn: 0xffff.ffffffff 06/13/2004 01:18:07
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
FILE HEADER:
Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
Db ID=1052178311=0x3eb6f787, Db Name='HSJF'
Activation ID=0=0x0
Control Seq=18062=0x468e, File size=38400=0x9600
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
Creation at scn: 0x0000.000000ae 07/16/2003 03:40:10
Backup taken at scn: 0x0000.01301f8d 05/12/2004 00:16:20 thread:1
reset logs count:0x1f6f3ead scn: 0x0000.013b46fe recovered at 06/06/2004 22:45:27
status:0x4 root dba:0x004001a1 chkpt cnt: 1557 ctl cnt:1556
begin-hot-backup file size: 38400
Checkpointed at scn: 0x0000.014338dc 06/13/2004 01:19:38
thread:1 rba:(0x6a.18fd.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Backup Checkpointed at scn: 0x0000.01301f8d 05/12/2004 00:16:20
thread:1 rba:(0x2ac.1f42.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 05/05/2004 18:09:43
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00

 

 

3.注意这里的RBA信息

rba:(0x6a.18fd.10)

我们注意RBA信息由三部分组成:

1.日志文件序号 4 bytes

2.日志文件块号 4 bytes

3.日志记录偏移量 2 bytes

这部分信息可以参考Steve Adams的站点:

http://www.ixora.com.au/notes/rba.htm

那么在这里,我们就可以得到日志文件的sequence号,在重建控制文件恢复时,Oracle就可以由此获得归档信息

提示需要的归档文件号.

对于本例:

thread:1 rba:(0x6a.18fd.10)

0x6a = 106

这就是log sequence了

从数据库的日志文件序号中我们可以看到:

 

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /opt/oracle/oradata/hsjf/archive
Oldest online log sequence 104
Next log sequence to archive 106
Current log sequence 106