掛掛不掛：附加被分離的疑疑數據庫——HACK 級應急恢復實戰

場景重現

1. 數據庫因日志損壞進入 SUSPECT (疑似) 狀態
2. 嘗試分離 → 附加修復 → 附加失敗 (錯誤 824/9003 等) 3. 嘗試重建日志 (`ATTACH_REBUILD_LOG`) → 仍失敗

核心原理

分離操作會清除 `sys.databases` 元數據，但 `.mdf` 物理文件仍存在。SUSPECT 狀態下分離，導致無法通過正常 `ATTACH` 流程恢復，因啟動恢復期要求日志完整。

HACK 級恢復步驟 (僅限應急、需配合備份驗證)

1. 建立同名空數據庫 (結構無關，僅佔位)

   CREATE DATABASE [AttchSuspectDatabase] ON PRIMARY 
       (NAME = 'AttchSuspectDatabase', FILENAME = 'C:\Data\AttchSuspectDatabase.mdf')
       LOG ON (NAME = 'AttchSuspectDatabase_log', FILENAME = 'C:\Data\AttchSuspectDatabase_log.ldf');

2. 離線並替換文件

   ALTER DATABASE [AttchSuspectDatabase] SET OFFLINE WITH ROLLBACK IMMEDIATE;
   -- 將原損壞庫的 .mdf 覆蓋剛建庫的 .mdf
   -- 保留新建庫的 .ldf (健康日志)

3. 上線並強制恢復

   ALTER DATABASE [AttchSuspectDatabase] SET ONLINE;
   -- 或 ALTER DATABASE [AttchSuspectDatabase] SET EMERGENCY;
   -- DBCC CHECKDB ('AttchSuspectDatabase', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;

4. 驗證數據完整性：`DBCC CHECKDB`、業務查詢抽樣、導出關鍵表
5. 立即完整備份，重建可信備份鏈

風險與警示

• 可能數據損失：未提交事務、日志中未刷盤數據丟失
• 事務一致性未保證：外鍵、約束可能違反
• 僅作最後手段：優先嘗試 `EMERGENCY` + `REPAIR`、頁級還原、備份恢復
• 生產環境必須經變更管理審批

正規恢復優先順序

1. 完整備份 + 日志備份鏈還原 (RPO=0 可達) 2. 頁級還原 (SQL 2005+ Enterprise) 3. `EMERGENCY` 模式 + `DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS` 4. 本文 HACK 方案 (無備份、無頁備份、極端情況)