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

在數據庫遇到ora-600[2662],scn不一致(又沒有日誌）的時候，咱們首先想到的就是去推動數據庫的scn,讓數據庫可以open起來,搶救其中的數據,可是因爲各類亂用的狀況,oracle scn的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.不實驗風險較大,請勿在生產環境上測試,負載後果自負

重慶思莊18年5月OCP認證培訓週末班正在授課，歡迎聯繫試聽！新的OCP週末班將於6月2日開課，火熱報名中，名額有限，請提早預約！更多詳情訪問思莊網站諮詢在線客服。