如何進行ora-01110錯誤的異?；謴?fù)

如何進行ora-01110錯誤的異?；謴?fù)，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

某日，生產(chǎn)數(shù)據(jù)庫服務(wù)器異常宕機，在重啟服務(wù)器開啟數(shù)據(jù)庫時報如下錯誤：

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'
恢復(fù)受損的文件.
SQL> recover tablespace system;//不一定需要，提示不要求恢復(fù)的時候，可以直接打開數(shù)據(jù)庫。
恢復(fù)系統(tǒng)表空間.
SQL> RECOVER DATABASE;
恢復(fù)數(shù)據(jù)庫.
SQL> ALTER DATABASE OPEN;
Database altered.

做這類操作時，不一定能成功。所以請一定先備份當(dāng)前狀態(tài)下所有數(shù)據(jù)文件、控制文件和日志文件，先做到保護現(xiàn)場，然后再做其他嘗試。

經(jīng)過冷備后，嘗試這種方法不行。咨詢Dbsnake后，嘗試異?；謴?fù)強行打開數(shù)據(jù)庫。
#su - oracle
$vi  /oracle/PRD/data1/init.ora 修改初始化參數(shù)
*._allow_resetlogs_corruption=FALSE
修改為*._allow_resetlogs_corruption=TRUE(#正常啟庫后修改為原值FALSE)
(這個參數(shù)允許在數(shù)據(jù)不一致的情況下打開)
*.undo_management='AUTO'
修改為*.undo_management='MANUAL'（#正常啟庫后修改為原值A(chǔ)UTO）
(這個參數(shù)是讓UNDO表空間由自動管理變手動管理)
增加此句
*._corrupted_rollback_segments=(_SYSSMU12$)(#正常啟庫后去掉此句)
(屏蔽出錯的事務(wù)回滾段,根據(jù)ALERT提示ORA-01555: snapshot too old: rollback segment number 12 with name "_SYSSMU12$" too small)
然后保存參數(shù)文件，重新打開庫，發(fā)現(xiàn)還是不行。檢查ALERT日志發(fā)現(xiàn)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值要比這個值大，所以設(shè)置值為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.  
數(shù)據(jù)庫成功打開。

去掉隱含參數(shù)，恢復(fù)初始參數(shù)。  
最后

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

File created.

SQL> startup

ORACLE instance started.

然后及時用EXP全庫導(dǎo)出以保護數(shù)據(jù),做DBV的數(shù)據(jù)校驗看是否有物理壞塊.
 

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

附SCN知識點:

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

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

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

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

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

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