背景

某項目Oracle數(shù)據(jù)庫掛了。現(xiàn)象：

• 登錄不了（重置了密碼，orapwd命令）
• 啟動提示控制文件不一致（復(fù)制了備份的控制文件，但這步有問題）
• 控制文件損壞（發(fā)現(xiàn)有數(shù)據(jù)文件也有損壞，去除后能夠建立控制文件）
• 清理了日志文件
• 恢復(fù)了數(shù)據(jù)文件
• 修改了_allow開頭的隱藏參數(shù)
• 打開數(shù)據(jù)報ORA-00600 [2662]錯誤

沒有RMAN備份，沒有expdp導(dǎo)出。只能硬著頭皮強制恢復(fù)。

一、強制打開數(shù)據(jù)庫的關(guān)鍵步驟

如果實在要強制打開數(shù)據(jù)庫，參考如下關(guān)鍵點，再有其他錯誤就要一個一個看了，很麻煩。

步驟1：允許resetlogs時有臟數(shù)據(jù)

_alter system set "_allow_resetlogs_corruption"=true scope=spfile;

這個參數(shù)允許在open resetlogs時數(shù)據(jù)文件中有不一致數(shù)據(jù)。Oracle官方不建議使用，但沒備份的時候，這就是最后一根稻草。

步驟2：處理ORA-01555錯誤

如果出現(xiàn)ORA-01555錯誤導(dǎo)致數(shù)據(jù)庫無法open，設(shè)置：

_CORRUPTED_ROLLBACK_SEGMENTS
undo_management = 'MANUAL'

把回滾段標(biāo)記為損壞，用MANUAL模式繞過自動undo管理。

步驟3：處理ORA-600 [2662]——SCN不一致

ORA-600 [2662]是SCN不一致的典型錯誤。參數(shù)含義：

SCN的計算公式：

SCN = (SCN_WRAP × 4294967296) + SCN_BASE

其中4294967296 = 2^32。SCN_WRAP是高位，SCN_BASE是低位。當(dāng)SCN_BASE足夠大時，SCN_WRAP就會加1。

處理方法：先通過多次重啟open的方法來觀察Current SCN BASE增長速度。如果Current SCN BASE和dependent SCN BASE相差不遠(yuǎn)，重啟幾次數(shù)據(jù)庫就可能打開。

步驟4：用10015事件加速SCN增長

如果差距較遠(yuǎn)，mount之后執(zhí)行：

alter session set events '10015 trace name adjust_scn level 10';

然后嘗試open。這個事件會加速Current SCN BASE的增長。

步驟5：啟用錯誤模擬讓10015事件生效

如果加入10015事件adjust_scn之后，Current SCN BASE增長還是很慢，某些版本必須加入：

_allow_error_simulation = TRUE

才能使10015事件生效。

步驟6：用_smu_debug_mode加速SCN WRAP增長

如果Current SCN BASE增長還是很慢：

_smu_debug_mode = 268435456

這個參數(shù)直接增長SCN WRAP，需要和_allow_error_simulation=true同時使用。

步驟7：用_minimum_giga_scn大步推進(jìn)

_minimum_giga_scn = n

把SCN向前推進(jìn)nG。只有Current SCN和dependent SCN相差nG時這個參數(shù)才起作用，否則無效。

步驟8：處理ORA-600[6006]和ORA-600[4137]

如果SCN號一致以后報ORA-600[6006]或ORA-600[4137]，需要添加：

*.event="10513 trace name context forever,level 2"
*.db_block_checking=false

步驟9：open resetlogs后的建議

對于open resetlogs打開以后的數(shù)據(jù)庫，最好將業(yè)務(wù)用戶導(dǎo)出以后重建數(shù)據(jù)庫，以防止數(shù)據(jù)庫出現(xiàn)不可預(yù)知的錯誤。Oracle官方建議是open resetlogs之后需要重建數(shù)據(jù)庫。

二、Oracle 11.2.0.4的SCN改法——oradebug實戰(zhàn)

上面的參數(shù)方法在某些版本不夠直接。Oracle 11.2.0.4可以用oradebug直接修改SGA中的SCN值。

第一步：計算目標(biāo)SCN的十六進(jìn)制值

SQL> select to_char(2723797,'XXXXXXXXXXXXXXXX') from dual;

TO_CHAR(2723797,'
-----------------
           298FD5

2723797的十六進(jìn)制是0x298FD5。

第二步：設(shè)置oradebug跟蹤自己的進(jìn)程

SQL> oradebug setmypid
Statement processed.

第三步：查看當(dāng)前SGA中的SCN值

SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 ...

當(dāng)前SCN是0，數(shù)據(jù)庫處于mount狀態(tài)。

第四步：用oradebug poke直接修改SCN

SQL> oradebug poke 0x06001AE70 8 0x0000000000298FD5
BEFORE: [06001AE70, 06001AE78) = 00000000 00000000
AFTER:  [06001AE70, 06001AE78) = 00298FD5 00000000

poke命令的參數(shù)：地址、長度、新值。8表示8字節(jié)。

第五步：驗證修改后的SCN

SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00298FD5 00000000 ...

SCN已經(jīng)從0變成了0x298FD5（即2723797）。

第六步：打開數(shù)據(jù)庫

SQL> alter database open;

Database altered.

第七步：驗證checkpoint SCN

SQL> select checkpoint_change#, checkpoint_change#/1024/1024/1024 SCN_WARP
     from v$database;

CHECKPOINT_CHANGE#   SCN_WARP
------------------ ----------
           2723798 .002536735

數(shù)據(jù)庫成功打開，checkpoint SCN已經(jīng)更新。

參數(shù)速查表

反思

這次恢復(fù)最終沒有完全成功。但過程中學(xué)到的教訓(xùn)：

1. 沒有備份就不要碰生產(chǎn)數(shù)據(jù)庫——這次是從"沒備份"開始的災(zāi)難鏈
2. SCN是Oracle的心跳——理解SCN的WRAP/BASE結(jié)構(gòu)是處理ORA-600[2662]的前提
3. oradebug poke是核武器——直接修改SGA內(nèi)存，用錯了數(shù)據(jù)庫就徹底廢了
4. 強制恢復(fù)后的數(shù)據(jù)庫不可信——Oracle官方建議重建，這不是建議，是忠告

結(jié)果：未完全恢復(fù)，但積累了寶貴的強制恢復(fù)經(jīng)驗

以上就是Oracle數(shù)據(jù)庫無備份強制恢復(fù)的實戰(zhàn)指南的詳細(xì)內(nèi)容，更多關(guān)于Oracle無備份強制恢復(fù)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論