快速檢查資料庫一致性

sjw1933發表於2020-09-04

檢查一:檢查點時間和Fuzziness

目的:確認資料庫檔案都恢復到預期時間點(PIT )並且他們是一致性(FUZZY=NO )。

SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;

FUZ STATUS  ERROR           REC CHECKPOINT_CHANGE# CHECKPOINT_TIME        COUNT(*)
--- ------- --------------- --- ------------------ -------------------- ----------
NO  ONLINE                                 5311260 31-AUG-2011 23:10:14          6
YES ONLINE                                 5311260 31-AUG-2011 23:10:14          1


a )確認 checkpoint_time / checkpoint_change #與預期的 UNTIL TIME / SCN 一致。如果不一致且有更多可用的歸檔日誌,請進一步恢復資料庫。

b )如果一些資料檔案FUZZY=YES,這意味著我們進一步的恢復

檢查二:資料檔案狀態

目的:確認需要recover 的檔案不是offline 狀態

SQL> select status, enabled, count(*) from v$datafile group by status, enabled ;

STATUS  ENABLED      COUNT(*)
------- ---------- ----------
SYSTEM  DISABLED            1
ONLINE  READ WRITE          4
RECOVER DISABLED            2

檢查三:Fuzzy

目的: Fuzzy 檢查

有時,對於所有恢復的資料檔案,可以看到 Fuzzy = NO 和相同的 checkpoint_change #,但 OPEN RESETLOGS 仍然失敗。例如以下資訊:

SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;

FUZ STATUS  ERROR           REC CHECKPOINT_CHANGE#      CHECKPOINT_TIME   COUNT(*)
--- ------- --------------- --- ------------------ -------------------- ----------
NO  ONLINE                                 5311260 31-AUG-2011 23:10:14          7


SQL> ALTER DATABASE OPEN RESETLOGS ;

ORA-01194: file 4 needs more recovery to be consistent
ORA-01110: data file 3: '/<path>/undotbs02.dbf'

因此我們要執行附加的fuzzy檢查:

                                             

那什麼情形下可以透過檢查?

a )以上查詢沒有返回結果

b) Min_PIT_SCN 的返回值小於 Checkpoint_Change#

真實案例如下:

select hxfil file#, substr(hxfnm, 1, 50) name, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN from x$kcvfh where fhafs!=0 ;

4-7

查詢最小一致性scn recover 即可解決

recover database untile scn 82419715478

總結

以上操作都檢查完畢後一般就可以順利開啟資料庫,不過在開啟過程中我們需要關注資料庫alert 日誌,確認沒有額外的報錯,比如臨時表空間問題。


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

相關文章