場景 需將 List<Model> 序列化為 XML 傳遞給預存程序批量處理。SQL Server 2005 對標準 XML 命名空間支援不足，需特

環境 SQL Server 2008 叢集（2 節點） Windows Server 2008 R2 網域環境 步驟一：SQL Server 網路設定啟用

簡介 交易記錄保證持久性與一致性，透過 Undo（回滾）與 Redo（重做）機制，支援災難復原與高可用性（鏡像、記錄傳送、Always On、複寫）。 記錄損

核心結論 任何形式的容錯移轉（叢集、鏡像、記錄傳送、SAN 複寫），執行中且未提交的交易都會被回滾，不會繼續執行。 各技術機制說明 技術容錯移轉過程交易結

核心誤區澄清 誤區：即時文件初始化可以在 SQL Server 內部通過配置「開啟」或「關閉」。 事實：IFI 由 SQL Server 啟動帳戶的

迷思 鏡像立即偵測故障並發起容錯移轉。 事實：偵測時間隨故障層級遞增 故障類型偵測機制預估偵測時間 主體 SQL Server 進程崩潰 鏡像每秒

迷思 鏡像偵測到故障後瞬間就能容錯移轉。 事實：容錯移轉耗時取決於 Redo 隊列大小 自動容錯移轉： 由鏡像伺服器發起（非見證伺服器），需「形成仲裁」（見

迷思來源 早期 Microsoft 官方文件與大量部落文建議「TempDB 檔案數 = CPU 核心數（1:1）」。但這源自 SQL CAT 團隊面對極大型客戶

迷思 資料庫設為 SQL Server 2000 相容模式（80）後，無法使用 DMV/DMF。 事實 相容模式僅影響 T-SQL 語法解析、查詢計劃行為等，

迷思 Checkpoint 只會將已提交交易的資料頁寫入磁碟。 事實 Checkpoint 會將自上次 Checkpoint 以來所有在記憶體中被修改的頁面（

迷思與事實對照 迷思事實 a) FileStream 資料可存放於遠端儲存 不可。 FileStream 容器（NTFS 資料夾）必須符合本機儲存策略

迷思 許多人認為：記錄鏈斷裂後（如切換至簡單復原模式、使用 BACKUP LOG WITH NO_LOG/TRUNCATE_ONLY、鏡像容錯移轉），必須執行完

核心結論 SQL Server 沒有任何操作能透過重啟服務、重啟 Windows、分離附加資料庫來修復資料損壞。損壞的頁面必須透過備份還原、DBCC 修復（可能

迷思：鎖升級是行鎖 → 頁鎖 → 表鎖 事實： SQL Server 2005 及之前版本，鎖升級直接從行鎖升級為表鎖，不經過頁鎖。 SQL Server 2

前言 還原是備份策略的終極驗證，但圍繞還原存在大量迷思。本文一次釐清 26 個關鍵迷思（對應字母 A-Z），助您建立正確還原觀念。 迷思清單與事實 代號迷

迷思一：填充因子永遠有效 事實： 填充因子僅在索引建立或重建時生效。SQL Server 儲存引擎不會持續維持頁面空閒空間符合填充因子。若強制維持，頁面一滿就必

核心觀念 SQL Server 的巢狀交易不是真正的巢狀。語法雖允許 BEGIN TRAN 巢狀、COMMIT 內層、ROLLBACK 內層，但引擎僅識別最外層

結論先行 BACKUP WITH CHECKSUM 絕不能替代 DBCC CHECKDB。 雖然備份時加上 WITH CHECKSUM 會驗證所有已配置頁面的校

迷思一：常見 DML 操作可被「最小記錄」 事實： 僅特定大量操作（如 BULK INSERT、SELECT INTO、CREATE INDEX、ALTER I

核心結論 對堆疊建立叢集索引後再刪除，以此整理碎片，是極度不建議的做法（僅次於收縮資料庫）。這會導致所有非叢集索引被重建兩次，造成嚴重效能衝擊與記錄膨脹。 為