日誌傳送：SQL Server 高可用性的核心支柱 — 架構、配置與運維精要

在資料庫高可用性 (HA) 技術棧中，**日誌傳送** 以「成熟穩定、版本相容性強、無 Enterprise Edition 授權限制 (Standard 版即可)」三大優勢，成為中小企業與混合雲架構的首選暖備份方案。本文結合實戰案例，深度解析三角色四步驟架構、關鍵配置參數、監控體系與故障演練流程。

架構核心：三角色四步驟

四步驟深度剖析

步驟 1：備份交易記錄 (主要伺服器)

• 排程頻率： RPO 決定。金融核心 1-5 分鐘；一般業務 15-60 分鐘
• 壓縮： SQL 2008+ **必須啟用** WITH COMPRESSION，減少 60-80% 傳輸體積
• 驗證： WITH CHECKSUM 偵測頁面損毀
• 監控關鍵： 備份作業失敗、備份耗時超過閾值、備份檔大小異常暴增 (可能大量異常交易)

步驟 2：複製記錄檔 (主要 → 次要)

• 觸發模式： 備份完成即觸發複製 (事件驅動) 或固定排程輪詢
• 網路優化： 跨資料中心建議啟用 BITS (Background Intelligent Transfer Service) 或專線/VPN QoS 保障頻寬
• 權限： SQL 服務帳號對共享資料夾 **讀/寫/刪除** 權限
• 監控關鍵： 複製延遲 (備份完成到檔案出現在次要端) > 閾值告警、複製失敗、磁碟空間不足

步驟 3：還原記錄 (次要伺服器)

• 模式選擇：
  • NORECOVERY：純暖備份，不可查詢，RTO 最短 (僅需切換連線)
  • STANDBY：唯讀待命，可供報表查詢，但還原期間會中斷連線，RTO 稍長
• 延遲還原 (Delay Restore)： 設定 @restore_delay (分鐘) 保護邏輯錯誤 (如誤刪表) 的回溯窗口
• 監控關鍵： 還原作業失敗、LSN 斷裂 (需重新初始化)、還原延遲超過 RPO

步驟 4：監控與告警 (監視伺服器)

• 集中檢視 msdb.dbo.log_shipping_monitor_* 歷史表
• 關鍵告警規則：
  • 備份/複製/還原作業失敗 → 立即通知 DBA
  • 備份延遲 > @backup_threshold (預設 60 分鐘)
  • 次要伺服器還原延遲 > @restore_threshold
  • LSN 間隙偵測 → 自動觸發重新初始化流程
• 郵件/Teams/Slack/Webhook 多通道推送

實戰配置參數建議表

故障切換演練標準流程 (季度必演)

1. 凍結主要端寫入： ALTER DATABASE [DB] SET READ_ONLY 或停止應用服務
2. 確認同步完成： 查詢次要端 SELECT * FROM msdb.dbo.log_shipping_secondary_databases WHERE secondary_database = 'DB' 確認 last_restored_latency 接近 0
3. 啟動次要資料庫： RESTORE DATABASE [DB] WITH RECOVERY (STANDBY 模式需此步；NORECOVERY 模式同樣需執行)
4. 修正孤立使用者： EXEC sp_change_users_login 'Auto_Fix', 'app_user' 或重建登入映射
5. 切換應用連線字串 / DNS / LB 指向次要伺服器
6. 驗證業務功能端到端
7. 記錄 RTO/RPO 實測值，更新演練報告
8. 切回 (Failback)： 重建原主要為新次要 (完整備份+還原+加入日誌傳送)

常見坑點與避雷

• VLF 過多： 記錄檔自動增長過小導致 VLF 數萬個 → 還原啟動極慢。預先規劃記錄檔大小、固定增量 (如 512MB/1GB)
• 備份鏈斷裂： 手動發出 BACKUP LOG ... WITH NO_LOG (已移除) 或切換復原模式 → 必須重新完整備份初始化
• 跨版本限制： 次要伺服器版本 **必須 ≥ 主要伺服器版本** (可高不可低)
• 大量載入操作： BULK INSERT/BCP/SELECT INTO 在簡易/大量記錄模式下不完整記錄 → 破壞日誌傳送。需臨時切換完整復原模式或暫停日誌傳送

結語

日誌傳送雖非「零資料損失」方案 (同步複寫/AlwaysOn 同步模式才能達到)，但以 **低成本、高相容、易運維** 特性，構建了可靠的「最後一道防線」。將其納入 HA 架構矩陣，配合定期演練、自動化監控、版本升級相容性測試，讓高可用性從口號落地為可度量的 SLA 承諾。