經過修改控制文件scn推動數據庫scn

在數據庫遇到ora-600[2662],scn不一致(又沒有日誌）的時候，咱們首先想到的就是去推動數據庫的scn,讓數據庫可以open起來,搶救其中的數據,可是因爲各類亂用的狀況,oraclescn的pach出來後(11.2.0.4,12.0.1.0默認就屏蔽)，屏蔽了之前大部分傳統的推動scn的方法(adjust_scn, _minimum_giga_scn),如今可以推動scn的有oradebug,bbed,修改控制文件.本文就列舉經過ue修改控制文件scn來推動數據庫scn的方法.

數據庫當前scn

idle> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# 271743118 idle> shutdown abort ORACLE 例程已經關閉。

分析控制文件中scn

這裏咱們能夠看到加粗部分爲數據庫scn

SQL>select to_number('10327a59','xxxxxxxxx') from dual; TO_NUMBER('10327A59','XXXXXXXXX') 271743577

這裏的scn值和在數據庫中查詢的值有小差異,由於查詢時間點和我徹底關閉數據庫有個時間差,而這個時間差有scn變化.細紅框部分爲控制文件對塊的驗證信息

修改控制文件scn和驗證信息

驗證信息修改成所有0,scn信息你能夠根據你的需求去修改,這裏把數據庫的scn修改成57253932971026,按照數據庫的原理,啓動後的scn應該稍微大於該scn值.

SQL>select to_number('341278563412','xxxxxxxxxxxxxxxxx') from dual; TO_NUMBER('341278563412','XXXXXXXXXXXXXXXXX') 57253932971026

啓動數據庫

idle> startup mount ORACLE 例程已經啓動。 Total System Global Area 400846848 bytes Fixed Size 2440024 bytes Variable Size 289408168 bytes Database Buffers 100663296 bytes Redo Buffers 8335360 bytes 數據庫裝載完畢。 idle> recover database; 完成介質恢復。 idle> alter database open; 數據庫已更改。 idle> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# 57253932991028

數據庫啓動後查詢scn爲57253932991028(數據庫當前scn)果真微大於57253932971026(修改控制文件scn),證實咱們經過修改控制文件scn,實現數據庫scn推近徹底OK.不實驗風險較大,請勿在生產環境上測試,負載後果自負