如何終止 SQL Server 資料庫漫長的恢復過程 (緊急手冊)

⚠️ 警告：以下操作將導致資料不一致，僅限極端情況 (如恢復卡住數天、業務損失大於資料風險) 使用。務必先嘗試耐心等待、檢查錯誤日誌、確認硬體健康。生產環境請優先從可靠備份還原。

適用場景

• 大型交易 (大量 UPDATE/DELETE) 被強制終止 (KILL) 或伺服器意外重啟
• 資料庫啟動時進入「恢復中」狀態，持續數小時無進展
• 錯誤日誌無明顯錯誤，但 sp_who2/sys.dm_exec_requests 顯示 ROLLBACK 持續進行

緊急終止恢復步驟 (Sybase ASE 語法，SQL Server 需轉換)

注意： 原文為 Sybase ASE 指令。SQL Server **不支援直接更新系統表**。SQL Server 對應做法如下：

SQL Server 正規做法：強制資料庫進入緊急模式並重建日誌

-- 1. 設為緊急模式 (僅 sysadmin 可執行)
ALTER DATABASE [YourDB] SET EMERGENCY;
GO

-- 2. 設為單用戶模式 (斷開其他連線)
ALTER DATABASE [YourDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- 3. 執行 DBCC CHECKDB 修復 (允許資料遺失)
DBCC CHECKDB ([YourDB], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

-- 4. 恢復多用戶模式
ALTER DATABASE [YourDB] SET MULTI_USER;
GO

關鍵風險： REPAIR_ALLOW_DATA_LOSS 可能刪除損壞頁面、截斷交易、導致邏輯不一致。執行前 **必須** 先複製資料庫檔案 (.mdf/.ldf) 到安全位置備份。

原文 Sybase 步驟 (僅供參考)

-- 1. 備份 master 資料庫 (極重要！)
DUMP DATABASE master TO "/usr/sybase/master.dup"
GO

-- 2. 以 sa 登入 isql，允許系統表更新
SP_CONFIGURE "allow updates", 1
GO

BEGIN TRAN
GO
USE master
GO
UPDATE sysdatabases
SET status = -32768  -- 設為 bypass recovery 模式
WHERE name = "pubs2"
GO

IF @@ROWCOUNT = 1
    COMMIT
ELSE
    ROLLBACK
GO

事後必做清單

1. 立即完整備份 修復後的資料庫
2. DBCC CHECKDB 驗證邏輯一致性
3. 應用層驗證 關鍵業務流程端到端測試
4. 根因分析 為何出現超長恢復？(缺少索引、大量無提交交易、I/O 子系統故障、記錄檔自動增長過慢)
5. 預防措施：啟用瞬間初始化、優化長交易、監控 VLF 數量、配置間接檢查點

替代方案優先順序

1. 耐心等待 (大多數情況最終會完成)
2. 從最後可用備份還原 + 套用記錄備份 (RPO 最小)
3. 啟用資料庫鏡像/可用性群組的次要複本故障轉移 (HA 架構)
4. 最後才考慮本文緊急修復

資料庫恢復是 ACID 中 Durability 的最後防線，輕易繞過它將動搖資料信任基石。請謹慎決策，保留審計軌跡。