數據庫復制機能測試 推送形式機能測試。本站提示廣大學習愛好者：（數據庫復制機能測試 推送形式機能測試）文章只能為提供參考，不一定能成為您想要的結果。以下是數據庫復制機能測試 推送形式機能測試正文
數據庫復制就是由兩台辦事器，主辦事器和備份辦事器，主辦事器修正後，備份辦事器主動修正，在之前的文章中曾經做了具體的解釋，這裡就不在反復，詳細請拜見
http://www.jb51.net/article/30661.htm
應用了數據庫復制的人，起首擔憂的就是主辦事器和備份辦事器的機能消費成績，自己也是對此非常擔心，查了半天，根本上沒發明相似的測試解釋，就本身測試了一下，上面為測試的成果，僅供參考
我采取的是數據庫推送的復制形式，上面測試頁是基於此形式
由於數據庫復制重要是I/O操作，所以在此測試重要測試辦事器的硬盤讀寫操作，此次測試重要監控的對象為
avg. disk queue length（下文簡稱為dql） 簡略可以懂得成磁盤數據吞吐量的內在表現。淺顯的遷就曲直線上隨意取兩個分歧的點，高的一點解釋正在的停止讀寫操作的量比擬年夜，反之，比擬小。
第一種情形：1秒鐘寫入一次數據，一次數據寫入三個表，輪回寫入10000條
進程：封閉復制，純真的寫入，dql均勻值最年夜值為：0.126
開啟復制，同步性的寫入 ， dql均勻值最年夜值為 ：0.132
結論：鑒於這類比例，1秒鐘一次是這類小數據庫的寫入，同步成績，我們可以完整疏忽了
第二種情形：疏忽期待時光，一次數據寫入三個表，逝世輪回寫入10000 次數據
進程 ：封閉復制，純真的寫入，第一次測試：dql均勻值最年夜值為：3.05-3.08 第二次測試：2.2-2.30
開啟復制，同步性的寫入 ， dql均勻值最年夜值為 ：3.06-3.10 第二次測試： 2.2-2.34
結論：可以因為兩次測試距離時光比擬長，機械的情形紛歧致，然則成果很顯著，都是相差不年夜
第三鐘情形：封閉復制，主辦事器寫入 10000 次數據 ，每次寫三個表，然後開啟辦事器，主辦事器的 dql根本沒變更，由於是復禮服務器寫數據，和主辦事器聯系關系性不年夜
就上述情形來看，復制根本上不會影響主辦事器的機能消費，然則，我們經由過程監控SQL Server Profiler 會發明，湧現年夜量的復制監督器，這類復制監督器，會異常消費辦事器的機能，形成辦事器遲緩，由於是推送形式，所以主辦事器要時辰監控本身的變更情形，而形成機能消費，以下圖
若何處理這個成績呢？我們起首會想到，削減主辦事器的監督頻率便可，翻開復制監督器，
右鍵--》宣布辦事器屬性設置，修正一下刷新速度，普通我們可以接收的是規模是30-60秒的延遲
修正後，我們在去SQL Server Profiler 檢查，就會發明根本上消費就會很少了
假如你的辦事器復制形式為定閱形式，那末你去--署理設置裝備擺設文件---》分發署理--外面去修正你的定閱時光便可
作者： cnblogs 習 慣
