Oracle 數據庫大恢復實戰：殺進程、清 IPC、10015 事件調整 SCN 強制拉庫

前言

誤操作導致數據庫無法正常開啟，常規 SHUTDOWN ABORT 失效時，需採用「殺核心進程 → 清理共享內存/信號量 → 事件 10015 調整 SCN → 介質恢復」的硬核方案。本文記錄真實故障處理全過程，供極端場景參考。

故障現象

執行 DBMS_BACKUP_RESTORE.ZERODBID(0) 後實例被 CKPT 終止，重啟報 ORA-01221，數據文件頭 DBID 被重置為 0。

處理步驟

1. 殺死所有 Oracle 核心進程

ps -ef | grep ora_
kill -9 14431 14433 14435 14437 14439 14441 14443 14445 14447 14449 14451 14453 14455 14460 14468 14470 13622

包括 PMON、SMON、DBWn、LGWR、CKPT、MMON、QMN 等所有後台進程。

2. 清理共享內存段與信號量 (IPC)

ipcs
# 輸出示例：
# Shared Memory Segments
# key        shmid      owner  perms  bytes      nattch  status
# 0xcc481b8c 1441796    ora10g 640    599785472  0
# 0x40b3b558 2818054    ora10g 640    1077936128 0
# Semaphore Arrays
# key        semid      owner  perms  nsems
# 0x0d908ec4 360448     ora10g 640    154

# 以 root 執行清理
ipcrm -m 1441796
ipcrm -m 2818054
ipcrm -s 360448

徹底釋放 IPC 資源，防止殘留導致再次啟動失敗。

3. 事件 10015：調整 SCN 強制打開

SQL> ALTER SESSION SET EVENTS '10015 TRACE NAME ADJUST_SCN LEVEL 1';
Session altered.
SQL> ALTER DATABASE OPEN;
-- 若報 ORA-01113 需介質恢復
SQL> RECOVER DATABASE;
Media recovery complete.
SQL> ALTER DATABASE OPEN;
Database altered.

原理：事件 10015 允許在 SCN 不一致時強制推進 SCN 打開數據庫，屬內部事件，極慎用，需 Oracle Support 指導。

4. 補充臨時文件

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/ora10g/app/oradata/ldbra/temp01.dbf' SIZE 50M REUSE;
Tablespace altered.

輔助手段：BBED 修復數據文件頭 DBID（極端情況）

若控制文件重建仍報 ORA-600 [kcvhvdf_1]，可用 BBED 直接修改數據文件頭 KCCFHDBI (DBID) 及 KCCFHFLG (Fuzzy 標記=0x2000 表示正常關閉)，再重建控制文件。

BBED> SET FILENAME '/ora10g/app/oradata/ldbra/system01.dbf'
BBED> SET BLOCK 1
BBED> MODIFY /X 0x58C7A0F7  -- 原 DBID 1488207495 的十六進制
BBED> MODIFY /X 0x2000 OFFSET 20  -- 設置 Fuzzy 標記

風險警示與事後複盤

• 極高風險：殺進程、清 IPC、10015、BBED 均屬非正規恢復手段，可能導致數據邏輯不一致。
• 必須備份：操作前對所有數據文件、控制文件、Redo Log 進行 OS 級冷備份。
• 事後驗證：DBVERIFY 校驗數據文件、ANALYZE TABLE ... VALIDATE STRUCTURE、導出/導入核心表驗證邏輯一致性。
• 根因修正：禁止直接調用 DBMS_BACKUP_RESTORE 內部包，變更 DBID 必須用 NID 工具 (DBNEWID)。

總結

「殺進程 → 清 IPC → 10015 事件 → RECOVER → 補 TEMP」是極端故障下的最後防線。敬畏數據，操作前必備份，操作後必驗證，事後必複盤，才是專業 DBA 的底線。