SQL Server 複寫錯誤「無法同時更新 text/ntext/image 欄位與叢集鍵」：快照複寫替代方案

環境：三地 (美國/荷蘭/深圳) SQL Server 異動複寫，Web 升級後頻繁報錯：

The query processor could not produce a query plan from the optimizer 
because a query cannot update a text, ntext, or image column and a clustering key at the same time.

根因分析

• 問題資料表 XXX_article 含 ntext 欄位 (文章內容)。
• 應用程式同一個 UPDATE 陳述式同時修改 ntext 欄位與叢集索引鍵 (如 ArticleID 或 CategoryID)。
• SQL Server 查詢最佳化器無法為此模式產生有效執行計畫，導致複寫代理程式套用交易失敗。

官方限制說明

單一 UPDATE 陳述式不支援同時更新 LOB 型別 (text/ntext/image/varchar(max)/varbinary(max)) 與叢集索引鍵欄位。需拆分為兩個 UPDATE。

解決方案：改用快照複寫

1. 停止該資料表的異動複寫發行項。
2. 建立快照複寫發行項針對 XXX_article。
3. 設定排程 (如每日離峰時段) 產生快照並發送至訂閱端。

快照複寫不透過交易記錄逐筆重播，而是整表覆寫，繞過單一 UPDATE 限制。

替代方案：應用層拆分 UPDATE (需開發配合)

-- 原寫法 (失敗)
UPDATE XXX_article SET Content = @Content, CategoryID = @CatID WHERE ArticleID = @ID;

-- 拆分為兩步 (成功)
UPDATE XXX_article SET CategoryID = @CatID WHERE ArticleID = @ID;
UPDATE XXX_article SET Content = @Content WHERE ArticleID = @ID;

優點：保留異動複寫即時性。
缺點：需修改應用程式碼、部署協調成本高。

最佳實務建議

1. 資料表設計：避免將 LOB 欄位與叢集索引鍵置於同一資料表，或將 LOB 移至獨立資料表 (垂直分區)。
2. 複寫策略分層：核心交易表用異動複寫，LOB 重表用快照/合併複寫。
3. 升級前驗證：應用程式變更上線前，在測試環境完整跑複寫驗證。
4. 監控告警：設定複寫代理程式錯誤郵件通知，第一時間發現同步中斷。

此案例說明資料型別、索引設計與複寫機制的深度耦合，架構階段即應考量複寫相容性。