通过DUMP文件头来观察FILE OFFLINE,TABLESPACE OFFLINE,HOT BACKUP的区别(1)

oradebug dump FILE_HDRS n;
alter system set set event='immediate trace FILE_HDRS LEVEL n';


N=1: The control file’s entry of the data file. This appears before the string FILE 
HEADER, and is not shown on the slide. It will be covered in the control file dump. 
N=2: The control file’s entry and generic header. This has been covered in the 
previous slide, and is not shown on the above slide. 
N=3: The control file’s entry, generic header, and the header information in the data 
file. This causes the file tobe opened and read if the database is only mounted. 


LEVEL 1的DUMP 只会DUMP CONTROFILE FILE中关于数据文件的信息，我们先只分析一样CONTROFILE中关于DATAFILE HEADER的信息
这里我进行3个不同操作
1、USER01.DBF 进行了ALTER DATABASE DATAFILE OFFLINE的操作。
2、testo1.dbf 进行了ALTER TABLESPACE OFFLINE的操作，就是整个表空间的OFFLINE操作，OFFLINE DATAFILE是需要RECOVERY的但是OFFLINE TABLESPACE 不需要。
3、testo2.dbf 进行了BEGIN BACKUP 操作。


用于进行比较


首先查看status状态信息，
USER01.DBF 为1C 此状态为OFFLINE DATAFILE的状态
testo1.dbf 为80 此状态为OFFLINE TABLESPACE的状态
testo2.dbf 为e  此状态和ONLINE没有两样


然后进行CHECKPOINT的比较
USER01.DBF CHECKPOINT SCN为361c02，但是STOP SCN为36403d，这是最后脏数据写盘的SCN可以发现他们并不相同，如果查看视图
SQL> select CHECKPOINT_CHANGE#,LAST_CHANGE#,OFFLINE_CHANGE# from v$datafile where file#=4; CHECKPOINT_CHANGE# LAST_CHANGE# OFFLINE_CHANGE# ------------------ ------------ ---------------            3546114      3555389         1923486 SQL> select to_char('3555389','xxxxxxx'),to_char('3546114','xxxxxxx'),to_char('3555389','xxxxxxx') from dual; TO_CHAR('3555389','XXXXXXX') TO_CHAR('3546114','XXXXXXX') TO_CHAR('3555389','XXXXXXX') ---------------------------- ---------------------------- ----------------------------   36403d                       361c02                       36403d 我们可以看到同样的信息,这也说明v$datafile的这部分信息来自于控制文件


testo1.dbf CHECKPINT SCN为003642cb，STOP SCN 为003642cb，这表明进行TABLESPACE OFFLINE进行了一次CHECKPOINT来保证各个TABLESPACE
各个数据文件的数据一致，这应该就是为什么OFFLINE TABLESPACE 不需要RECOVERY的原因，但是Offline scn: 0x0000.001d599e并没有改变，
这里的Offline scn和Online Checkpointed at scn应该对应的是V$DATAFILE的OFFLINE_CHANGE#和ONLINE_CHANGE#字段，只有在下一次进行ONLINE 的时候这里才会更改,同样查看一下 SQL> select CHECKPOINT_CHANGE#,LAST_CHANGE#,OFFLINE_CHANGE# from v$datafile where file#=9;
CHECKPOINT_CHANGE# LAST_CHANGE# OFFLINE_CHANGE#
------------------ ------------ ---------------
           3556043      3556043         1923486


SQL> select to_char('3556043','xxxxxxx'),to_char('3556043','xxxxxxx'),to_char('1923486','xxxxxxx') from dual;
TO_CHAR('3556043','XXXXXXX') TO_CHAR('3556043','XXXXXXX') TO_CHAR('1923486','XXXXXXX')
---------------------------- ---------------------------- ----------------------------
  3642cb                       3642cb                       1d599e


可以完全对应上的


最后来看一下testo2.dbf他是进行了BEGIN BACKUP的操作，可以看到
Checkpoint cnt:196 scn: 0x0000.003642ba 02/24/2015 08:48:08
Stop scn: 0xffff.ffffffff 02/20/2015 15:19:43
这里和ONLINE的文件没有什么两样，只是BEGIN BACKUP 额外做了一次 full checkpoint，来记录开始热备的SCN，这一点在视图V$BACKUP中可以看到，同时应该记录到 DATAFILE HEADER中，而未在 CONTROLFILE 的记录中，我这里DUMP是 CONTROLFILE中的信息，随后会进行 DATAFILE HEADER的DUMP。 STOP SCN 如果全为F(SCN时BASE SCN+WRAP SCN，WRAP SCN 为高4位BASE SCN为低8位)则这个SCN是代表的最大SCN， 这说明要么文件正在被正常使用，或者异常的关闭了数据库SHOW DOWN ABORT，造成没有来得及进行CHECKPOINT，这也是为什么STOP ABORT会造成 V$DATAFILE中 LAST SCN 异常的原因，等会可以看一下。
最后关注一点
Hot Backup end marker scn: 0x0000.00000000，这里未找到官方解释，字面意思为热备结束后记录的SCN，可以测试一下。
如下是CONTROLFILE DATAFILE HEADER 关于3种模式的DUMP。


DATA FILE #4: 
  (name #16) /oradata/xuexi/users01.dbf
creation size=0 block size=8192 status=0x1c head=16 tail=16 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:509 scn: 0x0000.00361c02 02/24/2015 04:33:52
 Stop scn: 0x0000.0036403d 02/24/2015 08:30:22
 Creation Checkpointed at scn:  0x0000.000027b9 10/22/2005 21:45:00
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 .. 00000000
 Offline scn: 0x0000.001d599e prev_range: 0
 Online Checkpointed at scn:  0x0000.001d599f 10/04/2013 22:14:48
 thread:1 rba:(0x1.2.0)
 enabled  threads:  01000000 .. 00000000
 Hot Backup end marker scn: 0x0000.00000000
 aux_file is NOT DEFINED 
 
DATA FILE #9: 
  (name #11) /oradata/xuexi/XUEXI/datafile/testo1.dbf
creation size=0 block size=8192 status=0x80 head=11 tail=11 dup=1
 tablespace 11, index=9 krfil=9 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:202 scn: 0x0000.003642cb 02/24/2015 08:48:22
 Stop scn: 0x0000.003642cb 02/24/2015 08:48:22
 Creation Checkpointed at scn:  0x0000.001b4e8c 08/10/2013 20:37:14
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 .. 00000000
 Offline scn: 0x0000.001d599e prev_range: 0
 Online Checkpointed at scn:  0x0000.001d599f 10/04/2013 22:14:48
 thread:1 rba:(0x1.2.0)
 enabled  threads:  01000000 .. 00000000
 Hot Backup end marker scn: 0x0000.00000000
 aux_file is NOT DEFINED 
 
DATA FILE #10: 
  (name #10) /oradata/xuexi/XUEXI/datafile/testo2.dbf
creation size=0 block size=8192 status=0xe head=10 tail=10 dup=1
 tablespace 12, index=10 krfil=10 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:196 scn: 0x0000.003642ba 02/24/2015 08:48:08
 Stop scn: 0xffff.ffffffff 02/20/2015 15:19:43
 Creation Checkpointed at scn:  0x0000.001b525b 08/10/2013 21:20:44
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 .. 00000000
 Offline scn: 0x0000.001d599e prev_range: 0
 Online Checkpointed at scn:  0x0000.001d599f 10/04/2013 22:14:48
 thread:1 rba:(0x1.2.0)
 enabled  threads:  01000000 .. 00000000
 Hot Backup end marker scn: 0x0000.00000000
 aux_file is NOT DEFINED 
DUMP OF TEMP FILES: 1 files in database
最后来测试一下几个问题
1、V$DATAFILE LAST SCN 异常关闭为空 shutdown abort观察 所有文件 Stop scn: 0xffff.ffffffff 而V$DATAFILE中的OFFLINE_CHANGE#没有更新，


所以STOP DATABASE（正常情况下），OFFLINE DATAFILE,OFFLINE TABLESAPCE都会更新
此信息




2、OFFLINE_CHANGE#和ONLINE_CHANGE#会在 online的时候更新
SQL> recover datafile 4;
Media recovery complete.
SQL> alter database datafile 4 online;
SQL> alter tablespace testo1 online;
Tablespace altered


这样我们对DATAFILE 4进行了ONLINE他是默认的USER表空间唯一的数据文件，
同时对TESTO1表空间进行了ONLINE
SQL> select CHECKPOINT_CHANGE#,LAST_CHANGE#,OFFLINE_CHANGE#,online_change# from v$datafile where file# in (4,9);
CHECKPOINT_CHANGE# LAST_CHANGE# OFFLINE_CHANGE# ONLINE_CHANGE#
------------------ ------------ --------------- --------------
           3558940                      1923486        1923487
           3558898                      3556043        3558898
DUMP 观察
FILE 4(DATAFILE ONLINE)
Offline scn: 0x0000.001d599e prev_range: 0
Online Checkpointed at scn:  0x0000.001d599f 10/04/2013 22:14:48
无改变


FILE 9(TABLESPACE ONLINE)
Offline scn: 0x0000.003642cb prev_range: 0
Online Checkpointed at scn:  0x0000.00364df2 02/24/2015 10:13:27
已经更改，并且OFFLINE SCN已经更改为上一次我们SCN:3642cb,而ONLINE后同样
进行了一次CHECKPOINT记录了其ONLINE的SCN


所以offline scn和Online Checkpointed at scn仅仅对TABLESPACE 这样的OFFLINE有效。




3、Hot Backup end marker scn会在END BACKUP 后跟新
SQL> alter tablespace testo2 end backup;
Tablespace altered
DUMP 观察
Hot Backup end marker scn: 0x0000.00000000
可以看到END后任然没有任何变化，不知道何用。


最后我们看一下此信息中还包含了
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
不能恢复的SCN，一般是NOLOGGING造成