本文主要將由SQL Server為你的合并復(fù)制功能提供改善途徑。當(dāng)然方法不只一種,但究其性能,最好的方法應(yīng)屬盡可能地運行合并代理。然而,當(dāng)你的用戶不在線時,你就無法運行合并代理,并且你應(yīng)該勸告你的用戶盡量頻繁進(jìn)行同步。那么就來看看以下的講解吧。
1、使用合適的配置文件(profile)
關(guān)于合并復(fù)制性能,你有幾種特定的配置文件可以用來解決特定的需求。要察看這些配置文件,右擊你的合并代理,選擇代理配置(profile),然后從以下列表中選擇合適的配置文件:
默認(rèn)的代理配置文件
高容量服務(wù)器對服務(wù)器的配置文件
行數(shù)和檢查總量確認(rèn)配置文件
行數(shù)確認(rèn)配置文件
緩慢鏈接代理配置文件
詳細(xì)歷史代理配置文件
Windows同步管理器配置文件
2、簡化你的過濾器
過濾器限制了發(fā)布者每次運行合并代理時需要同步的數(shù)據(jù)總量。如果你使用了過濾,那么確保你在過濾器上放置了索引,因為它們可以加強(qiáng)性能。
要簡化你的過濾器,你也許需要重新設(shè)計你的表。如果你在過濾器中使用了Host_name參數(shù),那么你可以在描述中使用合并代理中的HostName屬性來忽略主機(jī)名數(shù)值。確保匹配你的過濾器條件的每個字段都經(jīng)過索引,并且索引經(jīng)常更新。
3、增加批處理尺寸
要盡量增加你的批處理尺寸。當(dāng)Declarative Referential Integrity (DRI)發(fā)生的時候(這些錯誤是合并同步中常見的部分,并且在同步代理下一次運行的時候清除),通過阻止合并代理錯誤可以經(jīng)常性的改善整體性能。
UploadGenerationsPerBatch
DownloadGenerationsPerBatch
UploadReadChangesPerBatch
DownloadReadChangesPerBatch
UploadWriteChangesPerBatch
DownloadWriteChangesPerBatch
在你的合并代理的屬性頁上設(shè)置這些參數(shù)。
4、經(jīng)常性的重新索引合并表
經(jīng)常性的重新對MSmerge_contents, MSmerge_tombstone, MSmerge_genhistory 和 MSmerge_replinfo表進(jìn)行索引,改善整體復(fù)制性能。
5、限制沖突設(shè)置
限制你的合并復(fù)制沖突設(shè)置。要做到這一點,右擊你的合并復(fù)制,并選擇屬性。在Subscriptions最后部分,選擇在他們重新同步之前,你所期望的Subscriptions的掉線時間最小值。通常你會發(fā)現(xiàn)Subscribers會在掉線合適的時間之后,重新同步所需要的時間比他再次發(fā)送一個新的快照并重新啟動的時間要長。
6、使用可選的同步伙伴
可選的同步伙伴特性允許你的發(fā)布者離線(例如,服務(wù)離線),并且你的訂閱者連接到另一個備選的發(fā)布者,直到你的發(fā)布者重新在線。當(dāng)使用可選的同步伙伴的時候,這里有很多限制;例如,它不允許自動的識別范圍分割調(diào)整,并且當(dāng)發(fā)布者無法達(dá)到的時候,你不能自動地對你的訂閱者使用可選的同步伙伴進(jìn)行錯誤恢復(fù)。咨詢微軟支持來獲得更多有關(guān)如何安裝備用同步伙伴的信息。注意:這個特性只有在SQL Server2005中可以獲得。
7、為高可用性重新發(fā)表
由于使用可選的同步伙伴的限制,許多的復(fù)制拓?fù)湓O(shè)計者都在高可用性合并復(fù)制解決方案中掙扎。答案就是使用重新發(fā)布——讓訂閱者成為其他訂閱者的發(fā)布者。通過這種方式你就可以在總部有一個主發(fā)布者,每個區(qū)域有一個訂閱者(東、南、西、北區(qū)域),然后連接到每個州辦公室,并在這些區(qū)域的服務(wù)器中進(jìn)行同步。要做到這一點,你需要仔細(xì)選擇全球優(yōu)先級別來構(gòu)建拓?fù)浣Y(jié)構(gòu)。
講的很淺顯,但是相信對你會有所啟發(fā),有所幫助的。
北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |