ORA-1122/ORA-1208 資料檔案頭寫丟失故障
一、 資料庫告警日誌09:22分出現報錯：
Thu Feb 25 09:22:04 2016
Errors in file /opt/oracle/app/oracle/diag/rdbms/cspora/cspora10/trace/cspora10_ckpt_165762.trc:
ORA-01171: datafile 163 going offline due to error advancing checkpoint
ORA-01122: database file 163 failed verification check
ORA-01110: data file 163: '/dev/rlv_index062'
ORA-01208: data file is an old version - not accessing current version
資料庫alert log報錯ORA-1122/ORA-1208
CKPT
程式執行checkpoint時檢查資料檔案header記錄的SCN值是否與控制檔案中記錄的資料檔案header的SCN值同步，如果發現控制檔案內容與資料檔案內容一致，那麼將最新checkpoint scn寫人控制檔案和資料檔案header，如果發現不一致，那麼會報錯ORA-1122/ORA-1208。
我們以第一個出現問題的資料檔案#163為例分析：
ORA-1208
說明控制檔案中記錄的資料檔案#163的Checkpoint scn (scn: 0x0b5b.4b96748e (十進位制12486738080910) 02/25/2016 09:00:40) 大於資料檔案#163 header的Checkpoint scn (scn: 0x0b5b.4b819fa1 (十進位制12486736715681) 02/25/2016 07:31:25).
資料檔案#163 header中記錄的Checkpoint scn 是一個比較舊的值。
透過CKPT trace檔案可以說明資料檔案#163 header中記錄的Checkpoint是一箇舊的值:
*** 2016-02-25 09:22:03.942
V10 STYLE FILE HEADER: File Number=163, Blksiz=8192, File Type=3 DATA
Checkpointed at scn: 0x0b5b.4b819fa1 02/25/2016 07:31:25 <==========Checkpointed at scn: 0x0b5b.4b819fa1
<======
資料檔案#163 header中記錄的Checkpoint scn: 0x0b5b.4b819fa1 (十進位制12486736715681) 02/25/2016 07:31:25
DATA FILE #163: (name #172) /dev/rlv_index062
Checkpoint cnt:142959 scn: 0x0b5b.4b96748e 02/25/2016 09:00:40 <========Checkpoint scn: 0x0b5b.4b96748e
<======
控制檔案中記錄的資料檔案#163的Checkpoint scn: 0x0b5b.4b96748e (十進位制12486738080910) 02/25/2016 09:00:40
說明資料檔案#163 header中記錄的Checkpoint scn是一箇舊值。
ORA-1122/ORA-1208
是一種由於ORACLE以外的問題導致checkpoint scn 沒有成功寫入資料檔案header，或者寫入資料檔案header後，又被ORACLE以外軟體將舊的資料block覆蓋。
二、 進一步論證
透過下面的測試模擬資料庫以外的問題導致了lost write（寫丟失）能夠重現問題ORA-1208。
1.
重建新的資料檔案 datafile#6
create tablespace test datafile '/u03/oradata/fsdb/test01.dbf' size 10M;
select file#,name from v$datafile;
FILE# NAME
---------- --------------------------------------
6 /u03/oradata/fsdb/test01.dbf
2. 手動執行checkpoint，然後檢視datafile#6 header記錄的SCN和控制檔案中記錄的SCN是一致的：
--手動執行checkpoint
alter system checkpoint;
--查詢v$datafile_header，檢查datafile header:
select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1073505
2 1073505
3 1073505
4 1073505
5 1073505
6 1073505 <===SCN 1073505
--dump header資訊來檢查datafile header:
alter session set events 'immediate trace name file_hdrs level 10';
DATA FILE #6:
name #10: /u03/oradata/fsdb/test01.dbf
Checkpoint cnt:3 scn: 0x0000.00106161 03/02/2016 17:10:37
<===scn: 0x0000.00106161 （十六進位制） ==>轉換為十進位制 1073505
以上2種方法驗證datafile#6 header記錄的SCN 1073505
-- 控制檔案中記錄的資料檔案Checkpoint scn
alter session set events 'immediate trace name controlf level 8';
DATA FILE #6:
name #10: /u03/oradata/fsdb/test01.dbf
creation size=1280 block size=8192 status=0xe head=10 tail=10 dup=1
tablespace 7, index=7 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:3 scn: 0x0000.00106161 03/02/2016 17:10:37<===1073505
<===scn: 0x0000.00106161（十六進位制） ==>轉換為十進位制 1073505
以上說明 datafile#6 header記錄的SCN和控制檔案中記錄的SCN是一致的 1073505
3. DD備份datafile#6 header block，因此datafileheader6.dd備份檔案中儲存的資訊是SCN=1073505 (一箇舊的SCN)
dd if=/u03/oradata/fsdb/test01.dbf of=/tmp/datafileheader6.dd bs=8192 skip=1 count=1 conv=notrunc
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.00201189 s, 4.1 MB/s
4. 手動執行checkpoint，讓checkpoint SCN增長，然後檢視datafile#6 header記錄的SCN和控制檔案中記錄的SCN是一致的：
SQL> alter system checkpoint;
System altered.
--確認當前datafile#6 header記錄資訊
SQL> alter session set events 'immediate trace name file_hdrs level 10';
Session altered.
DATA FILE #6:
name #10: /u03/oradata/fsdb/test01.dbf
creation size=1280 block size=8192 status=0xe head=10 tail=10 dup=1
tablespace 7, index=7 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:4 scn: 0x0000.001063e8 03/02/2016 17:21:53 <====1074152
<===scn: 0x0000.001063e8 （十六進位制） ==>轉換為十進位制 1074152
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1074152
2 1074152
3 1074152
4 1074152
5 1074152
6 1074152 <===
6 rows selected.
以上2種方法驗證datafile#6 header記錄的SCN已經增長到 1074152
-- 控制檔案中記錄的資料檔案Checkpoint scn
alter session set events 'immediate trace name controlf level 8';
DATA FILE #6:
name #10: /u03/oradata/fsdb/test01.dbf
creation size=1280 block size=8192 status=0xe head=10 tail=10 dup=1
tablespace 7, index=7 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:4 scn: 0x0000.001063e8 03/02/2016 17:21:53<====1074152
<===scn: 0x0000.001063e8 （十六進位制） ==>轉換為十進位制 1074152
以上資訊說明datafile#6 header記錄的SCN和控制檔案中記錄的SCN都增長，並且保持一致的 1074152
同時說明當觸發checkpoint後，資料庫可以自動同步datafile#6 header和控制檔案中的scn值，並且保持一致，沒有任何問題。
5. 模擬lost write
alter system flush buffer_cache;
用舊的datafile#6 header block (儲存的資訊是SCN=1073505 (一箇舊的SCN))來替換當前的block
# dd if=/tmp/datafileheader6.dd of=/u03/oradata/fsdb/test01.dbf bs=8192 count=1 seek=1 conv=notrunc
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.00228945 s, 3.6 MB/s
--替換後，驗證當前資料檔案6 header block已經是一箇舊scn：
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1074152
2 1074152
3 1074152
4 1074152
5 1074152 <====其他datafile是current SCN
6 1073505 <====old SCN
6 rows selected.
6. 手動執行checkpoint報錯：
SQL> alter system checkpoint;
alter system checkpoint
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 3679
Session ID: 1 Serial number: 9
--分析alert log日誌：
Wed Mar 02 17:30:08 2016
Beginning global checkpoint up to RBA [0x49.3aed.10], SCN: 1074328
Read of datafile '/u03/oradata/fsdb/test01.dbf' (fno 6) header failed with ORA-01208
Rereading datafile 6 header failed with ORA-01208
Errors in file /u01/app/oracle/diag/rdbms/fsdb/fsdb/trace/fsdb_ckpt_3052.trc:
ORA-63999: data file suffered media failure
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: '/u03/oradata/fsdb/test01.dbf'
ORA-01208: data file is an old version - not accessing current version
<==== 問題重現，報錯ORA-01122/ORA-01208 資料檔案過舊
--分析CKPT trace檔案 /u01/app/oracle/diag/rdbms/fsdb/fsdb/trace/fsdb_ckpt_3052.trc
datafile 6 header 記錄的SCN：
Rereading datafile 6 header failed with ORA-01208
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=1117087836=0x4295685c, Db Name='FSDB'
Activation ID=0=0x0
Control Seq=10639=0x298f, File size=1280=0x500
File Number=6, Blksiz=8192, File Type=3 DATA
....
Checkpointed at scn: 0x0000.00106161 03/02/2016 17:10:37
<====記錄的scn是一箇舊scn
控制檔案記錄的SCN資訊：
DATA FILE #6:
name #10: /u03/oradata/fsdb/test01.dbf
creation size=1280 block size=8192 status=0xe head=10 tail=10 dup=1
tablespace 7, index=7 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:4 scn: 0x0000.001063e8 03/02/2016 17:21:53
<=====最新SCN資訊
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29863023/viewspace-2216734/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 電腦檔案丟失資料恢復資料恢復
- 新建的表空間(或資料檔案)丟失以及控制檔案丟失，有新建表空間(或資料檔案)前的控制文
- 檔案傳輸軟體如何有效防止資料丟失？
- Sql Server資料庫檔案丟失的恢復方法SQLServer資料庫
- MongoDB資料庫報錯，資料庫檔案丟失資料恢復案例MongoDB資料庫資料恢復
- DATA GUARD主庫丟失資料檔案的恢復(3)
- DATA GUARD主庫丟失資料檔案的恢復(1)
- DATA GUARD主庫丟失資料檔案的恢復(2)
- 資料丟失如當頭棒喝，資料備份重如山！
- macOS Big Sur系統如何恢復丟失的資料檔案？Mac
- 關於丟失表空間資料檔案的處理方式
- Oracle impdp遷移資料後主鍵丟失故障處理Oracle
- 【資料庫資料恢復】Sql Server資料庫檔案丟失的資料恢復過程資料庫資料恢復SQLServer
- 【資料庫資料恢復】mdb_catalog.wt檔案丟失的MongoDB資料恢復案例資料庫資料恢復MongoDB
- 【伺服器資料恢復】xfs檔案系統資料丟失的資料恢復案例伺服器資料恢復
- 【北亞資料恢復】MongoDB資料遷移檔案丟失的MongoDB資料恢復案例資料恢復MongoDB
- 檔案丟失不用怕：超實用的Mac資料恢復軟體！Mac資料恢復
- 資料庫資料恢復—MongoDB資料庫檔案丟失，啟動報錯的資料恢復案例資料庫資料恢復MongoDB
- 資料庫併發寫入問題-丟失更新與寫入偏差資料庫
- 將企業檔案共享解決方案與資料丟失防護配對
- win10桌面檔案丟失怎麼辦_win10開機桌面檔案丟失如何找回Win10
- Google Drive存在未知故障，導致部分使用者丟失雲盤資料Go
- Oracle歸檔檔案丟失導致OGG不用啟動Oracle
- 丟失的隨身碟檔案如何恢復？
- Sqlserver系統資料庫和使用者資料庫日誌檔案全部丟失的恢復SQLServer資料庫
- 伺服器不同的故障導致資料丟失都怎麼解決的伺服器
- 分割槽丟失資料恢復資料恢復
- 硬碟資料丟失如何恢復？硬碟
- Elasticsearch 如何保證寫入過程中不丟失資料的Elasticsearch
- 【虛擬機器資料恢復】Hyper-V虛擬化檔案丟失的資料恢復案例虛擬機資料恢復
- win10 ppt檔案丟失怎麼恢復_win10 ppt文件丟失如何找回Win10
- 救援丟失的Docx和Xlsx檔案的最佳方法
- Oracle 目錄許可權丟失故障恢復Oracle
- Oracle undo 表空間資料檔案丟失強制啟動資料庫（沒有未提交的事務）Oracle資料庫
- java資料list寫入檔案Java
- 【伺服器資料恢復】SAN LUN對映出錯導致檔案系統資料丟失的資料恢復案例伺服器資料恢復
- 重組raid會丟失資料嗎AI
- 如何找回分割槽丟失的資料