SQL服務器更換爲與數據轉換

Question

觸發我們有以下設置：

• 服務器SRV_1有兩個數據庫：OLTP數據庫DB_APP和報告數據庫DB_REP。
  DB_APP具有多個其中做一些數據轉換觸發器（非規範化，使用連接到其它表，以匹配非規範化的數據）和插入/更新數據到DB_REP
• SRV_1具有從DB_REP發佈數據
• 有事務複製在SRV_1一些工作，定期修改DB_REP基礎上的數據從DB_APP
• DB_REP不使用任何應用程序的數據，它只是用於複製的源
• 服務器SRV_2是認購DB_REP並使其可報告服務器給客戶。

問題是，DB_APP有少數表經常更新和觸發器使CPU負載非常沉重。最經常更新的表格之一每秒約有100次更新。

什麼是優化此設置的最佳方法？到目前爲止，我在想這樣的：

• 嘗試優化觸發器儘可能地（現在他們使用，如果存在檢查來執行插入/更新，我可以用MERGE替換）
• 創建索引視圖，而不是的觸發器和複製視圖從DB_APP到DB_REP
• 刪除觸發器，刪除DB_REP並使用複製存儲過程sp_msins_xxx直接從DB_APP發佈複製，實現數據轉換。我不確定是否可以在這些過程中查詢其他表格。以及如何處理工作？

Answer 1

我不認爲這是一個糟糕的設計，有一個單獨的數據庫用於複製，特別是當數據正在從事務性數據庫轉換時。

但我認爲使用觸發器填充複製的數據庫是不好的。我們曾經有過類似的設置，並且隨着交易量的增長，您發現性能會受到影響。

我不認爲它是從事務性數據庫直接複製的最佳想法 - 複製（事務性和合並無論如何）都使用觸發器本身，而轉換選項幾乎侷限於行和列過濾。你想要做的最後一件事是開始修改複製過程或觸發器！

我強烈建議將所有更新/轉換邏輯從觸發器中移出並存儲到可以從定期運行（例如過夜）的批量更新作業中調用的存儲過程。

這就是我們對大多數觸發器所做的事情，性能提升可能很大。我們的用戶不得不忍受一些數據不再是最新的事實，但在我們的案例中這不是一個大問題。