如何進行ora-01110錯誤的異常恢復

如何進行ora-01110錯誤的異常恢復，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

某日，生產數據庫服務器異常宕機，在重啟服務器開啟數據庫時報如下錯誤：

SQL> startup                                                          

ORACLE instance started.                                   

Total System Global Area 1.6911E+10 bytes                            

Fixed Size                    2113696 bytes                          

Variable Size              8472498016 bytes                          

Database Buffers           8422162432 bytes                          

Redo Buffers                 14659584 bytes                          

Database mounted.                                                     

ORA-01113: file 1 needs media recovery                               

ORA-01110: data file 1: '/oracle/PRD/data1/system_1/system.data1'

有一種解決方法是這樣的
SQL> RECOVER DATAFILE  '/oracle/PRD/data1/system_1/system.data1'
恢復受損的文件.
SQL> recover tablespace system;//不一定需要，提示不要求恢復的時候，可以直接打開數據庫。
恢復系統表空間.
SQL> RECOVER DATABASE;
恢復數據庫.
SQL> ALTER DATABASE OPEN;
Database altered.

做這類操作時，不一定能成功。所以請一定先備份當前狀態下所有數據文件、控制文件和日志文件，先做到保護現場，然后再做其他嘗試。

經過冷備后，嘗試這種方法不行。咨詢Dbsnake后，嘗試異常恢復強行打開數據庫。
#su - oracle
$vi  /oracle/PRD/data1/init.ora 修改初始化參數
*._allow_resetlogs_corruption=FALSE
修改為*._allow_resetlogs_corruption=TRUE(#正常啟庫后修改為原值FALSE)
(這個參數允許在數據不一致的情況下打開)
*.undo_management='AUTO'
修改為*.undo_management='MANUAL'（#正常啟庫后修改為原值AUTO）
(這個參數是讓UNDO表空間由自動管理變手動管理)
增加此句
*._corrupted_rollback_segments=(_SYSSMU12$)(#正常啟庫后去掉此句)
(屏蔽出錯的事務回滾段,根據ALERT提示ORA-01555: snapshot too old: rollback segment number 12 with name "_SYSSMU12$" too small)
然后保存參數文件，重新打開庫，發現還是不行。檢查ALERT日志發現SCN號不一致, 下一步推進SCN值。
查看估算SCN值
SQL> select dbms_flashback.get_system_change_number()/(1024*1024*1024) from dual; 

     DBMS_FLASHBACK.GET_SYSTEM_CHAN  

           ——————————  

              3.185796233  

估值為3.18NG,推進的SCN值要比這個值大，所以設置值為4

$vi  /oracle/PRD/data1/init.ora 增加此句  
*._minimum_giga_scn=4

再然后嘗試打開庫  
SQL> startup mount pfile='/oracle/PRD/data1/init.ora';  
ORACLE instance started.

SQL> recover database until cancel;

SQL> alter database open resetlogs;  
Database altered.  
數據庫成功打開。

去掉隱含參數，恢復初始參數。  
最后

SQL> create spfile from pfile='/oracle/PRD/data1/init.ora';

File created.

SQL> startup

ORACLE instance started.

然后及時用EXP全庫導出以保護數據,做DBV的數據校驗看是否有物理壞塊.
 

以上方法僅限特殊情況下的應用，請慎重參考。

附SCN知識點:

1、Oracle的SCN在每秒16384次commit的情況下可以維持534年，每秒16384次commit是Oracle早先認為的任何系統的極限commit強度；

2、Oracle里SCN的起點是1988年1月1日；

3、_minimum_giga_scn=n的含義是把SCN往前推進到nG，但請注意，只有在SCN小于nG的時候才會用到這個隱含參數，反之則Oracle會置這個隱含參數于不顧。

SCN原理:在安全關閉數據庫的過程中，系統會執行一個檢查點動作，這時所有數據文件的終止scn都會設置成數據文件頭中的那個啟動scn的值。在數據庫重新啟動的時候，Oracle將文件頭中的那個啟動scn與數據庫文件檢查點scn進行比較，如果這兩個值相互匹配，oracle接下來還要比較數據文件頭中的啟動scn和控制文件中數據文件的終止scn。如果這兩個值也一致，就意味著所有數據塊多已經提交，所有數據庫的修改都沒有在關閉數據庫的過程中丟失，因此這次啟動數據庫的過程也不需要任何恢復操作，此時數據庫就可以打開了。當所有的數據庫都打開之后，存儲在控制文件中的數據文件終止scn的值再次被更改為null，這表示數據文件已經打開并能夠正常使用了。

但在異常當機的情況下,由于最后一次檢查點未進行或進行中間被中止,因而在控制文件,就存在部分的數據文件stop SCN為最大值,在數據庫重新啟動后,會檢查控制文件中對應每個數據文件的stop SCN,如果stop SCN不等于控制文件中對應每個數據文件的checkpoint SCN,就會使用日志文件redo從checkpoint SCN開頭到stop SCN為止的全部數據庫操作.當數據庫發現SCN不一致，應該是redo log文件中的SCN>=數據文件中的SCN.在定位到底是使用哪一個redo log文件時,就用到了日志文件頭中的low scn,next scn,也就是說要使用的redo log 的low scn ,next scn必須包含數據文件重做所須的change vector.  在確定了哪個數據文件須redo,oracle會比較change vector中的SCN和數據文件數據塊中的SCN,如果change vector的SCN小于數據塊的scn,則跳過此change vector,否則redo。

看完上述內容，你們掌握如何進行ora-01110錯誤的異常恢復的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！