SQL Server提升事務複製效率優化（一）整體概述

  隨着公司業務的發展，數據量增加迅速，在解決Scale Out的同時，還要考慮到主從的複製延遲問題，儘可能降到1s之內知足線上業務，若是不調整，SQL Server默認的配置可能平均要3s左右。生產的複製架構採用的是推送方式進行事務複製，發佈服務器下面有4個從節點，兩兩指向同一虛擬IP，構成負載均衡，服務於不一樣的線上業務。對於4個節點，發佈庫和分法庫的壓力都很大，訂閱庫每秒I/O能達到5M，高峯時能達到數十兆。研究並試驗了一些時間，給出一些優化建議：

1.硬件、數據庫設計：

• 使用SSD磁盤，有錢的可使用PCI-e卡，SSD作RAID10，全部節點部署在內網。
• 更改事務隔離級別爲READ_COMMITTED_SNAPSHOT。說實話，SQL Server默認事務隔離級別是讀已提交，可是沒有多版本的概念，須要設置爲READ_COMMITTED_SNAPSHOT纔是咱們理解上的讀已提交。若是不設置這個，照樣會讀寫互相阻塞。     
• 在建立訂閱以前，先將目標數據庫的恢復模式改爲簡單，可以減小日誌

ALTER DATABASE [數據庫名稱] SET RECOVERY SIMPLE WITH NO_WAIT

2.發佈、訂閱設計：

• 僅發佈須要的數據，對於將日誌寫入數據庫並且還要同步複製的，DBA可直接拒絕。
• 表中存在大量非彙集索引，發佈時能夠不勾選複製非彙集索引選項。通過測試，雖然數據庫引擎是在應用完快照最後建立索引的，但建立時間很長，有時甚至會出錯。能夠在後期手工創建。咱們採用導出腳本方式，而後只保留非彙集索引的腳本在訂閱庫中創建。

• 若是資源容許，單獨創建一個分發服務器。發佈和分發服務器在一個服務器上會增長性能損耗，尤爲是分發服務器下面有多個訂閱服務器時。
• 分發庫默認是distribution庫，會有專門的做業對該庫進行清理，名字就叫「分發清除：distribution」。但這個進程清除分發庫的效率過低了，會致使分發庫積累大量數據，須要修改運行間隔和每次清楚的數據量。詳見以前的隨筆：distribution庫過大的問題
• 合理使用訂閱方式，若是選擇推送訂閱，勢必加大分發服務器的壓力，但延遲低 ；若是選擇請求訂閱，代理服務是在訂閱服務器上，減小了分發服務器壓力，但延遲會增長。
• 快照代理的生成。對於生成幾百GB數據庫的快照，採用SSD盤可能在10分鐘左右。但會形成很高的性能損耗，要在業務非高峯期生成快照。快照代理文件也要放在SSD盤上，若是資源容許，單獨一個驅動盤也能夠。
• 若是已經有備份了，那麼能夠經過備份直接來初始化訂閱，省去了生成快照和應用快照的步驟。
• 新發布新的表對象，對於發佈庫很大的狀況下從新初始化是不實際的，能夠增量發佈，詳見sqlserver同步後在不從新初始化快照的狀況下新增表
• 對於已發佈的表有批處理更新，一種方法是將批量更新分紅若干小批量執行，減少事務處理的數據量；另外一種方法是經過存儲過程執行更改，並將存儲過程發佈。推薦第一種
• 將項目分佈在多個發不上，這樣至關於變向的實現了多線程並行發佈，固然也能夠經過參數實現並行，下面會講到

3.參數優化：

• 下降複製代理的詳細級別，在初始測試、監視或調試期間除外。 減少分發代理或合併代理的 –HistoryVerboseLevel 參數和 –OutputVerboseLevel 參數。這樣能夠減小爲跟蹤代理歷史記錄和輸出而插入的新行數。相反，具備相同狀態的之前的歷史記錄消息將更新爲新的歷史記錄信息。提升測試、監視和調試的詳細級別，這樣就能夠得到有關代理活動的儘量多的信息。在系統開銷不是很大的狀況下，建議使用默認值1，自己這點對性能消耗能夠忽略。
• 增大快照代理的BcpBatchSize參數，-BcpBatch參數表示一個批事務的行數。
• 將快照代理的- MaxNetworkOptimization設置爲1，減小將沒必要要的信息發送到訂閱服務器上。
• 使用快照代理、分發代理的 –MaxBcpThreads 參數（指定的線程數不該超過計算機上的處理器數）。此參數指定建立和應用快照時能夠並行執行的大容量複製操做的數目。
• 爲分發代理使用 –SubscriptionStreams 參數。 –SubscriptionStreams 參數能夠顯著提升聚合複製吞吐量。它使到一臺訂閱服務器的多個鏈接能夠並行應用批量更改，同時在使用單線程時保持多個事務特徵的存在。若是有一個鏈接沒法執行或提交，則全部鏈接將停止當前批處理，並且代理將用單獨的流重試失敗的批處理。在重試階段完成以前，訂閱服務器上會存在臨時事務不一致。失敗的批處理成功提交後，訂閱服務器將恢復到事務一致狀態。官方文檔有這個參數，但增長這個參數報錯。
• 增大分發代理的 -CommitBatchSize 和CommitBatchThreshold參數的值。 提交一組事務的開銷是固定的；經過不常常提交大量事務，就能夠將開銷分散在大量數據上。可是，增大此參數的優點因應用更改的開銷由其餘因素（例如包含日誌的最大磁盤 I/O）限制而下降。另外，須要考慮如下權衡問題：任何致使分發代理從新開始的失敗必須回滾並從新應用大量事務。對於不可靠的網絡，越小的值致使失敗的概率越小，若是致使失敗，將回滾並從新應用較少許事務。
• 增大日誌讀取器代理的 -ReadBatchSize 參數的值。-ReadBatchSize 表示日誌讀取器代理和分發代理支持事務讀取和提交操做的批大小。批大小的默認值爲 500 個事務。日誌讀取器代理從日誌中讀取特定數量的事務，而無論這些事務是否標記爲複製。將大量事務寫入發佈數據庫，而其中只有一小部分標記爲複製時，則應使用 -ReadBatchSize 參數增長日誌讀取器代理的讀取批大小。此參數不適用於 Oracle 發佈服務器。
• 爲日誌讀取器代理使用 –MaxCmdsInTran 參數。–MaxCmdsInTran 參數指定日誌讀取器向分發數據庫寫入命令時組成一個事務的語句的最大數量。使用此參數可以使日誌讀取器代理和分發代理在訂閱服務器上應用命令時將發佈服務器上的大事務（由許多命令組成）分紅若干個較小的事務。指定此參數能夠減小分發服務器的爭用問題並縮短髮布服務器與訂閱服務器之間的滯後時間。因爲初始事務是以較小的單元應用的，訂閱服務器能夠在初始事務結束以前訪問一個較大的邏輯發佈服務器事務的行，於是會破壞事務的原子性。默認值爲 0，這將保持發佈服務器的事務邊界。官方文檔有該參數，但實際設置裏面沒有。
• 減少日誌讀取器代理和分發代理的 -PollingInterval 參數的值。 -PollingInterval 參數指定爲要複製的事務查詢已發佈數據庫的事務日誌的頻率。默認值爲 5 秒。若是減少此值，日誌的輪詢將更加頻繁，這會使事務從發佈數據庫傳遞到分發數據庫的滯後時間較低。可是，應該對較低滯後時間的須要和因頻繁輪詢致使的服務器上增長的負荷之間進行平衡。