通過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造成

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-1603865/，如需轉載，請註明出處，否則將追究法律責任。