如果嚴格限制頻寬使用量，則兩邊DB的資料差距會太大，而且時間會拖很長

我們試過將頻寬限制在256K，

結果有兩三個table"要一個小時" 後才收到replication的更新log

這個對你有幫助嗎？
http://technet.microsoft.com/zh-tw/library/cc280449.aspx

您是要做備份? 還是要做同步 OLTP?

我們是要做DB同步

做同步交易的話, 通常不會跨 WAN 複寫, 會用 message queue 的方式, 把整包 transaction 丟到另一端.

老實說，您說的做法我還真的沒聽說過，您是指log shipping ?? 還是指DB replication?? 我們採用的是DB replication by transaction (交易式複寫)

真的要做複寫, 建議用外部儲存體(SAN)所提供的異地複寫功能, 會比 SQL 的可靠.
我也很想用SAN，只是已經投資不少經費在這台SQL Server上，實在沒辦法再架SAN

另外, 也可考慮兩端架設 WAN Optimizer (WAN acceleratio) 硬體設備, 這類設備可以建立壓縮, 您的軟體就不必去管壓縮. 效能可能提昇 20~30 倍. 您可以找 Riverbed, Blue Coat, F5...這些廠商問問看...
老實說，我們已經有了，是用Riverbed，但不知道您有沒有使用上的經驗，FTP的session他可以壓縮到80% up，但SQL的流量，他壓不到15%

如果複寫無可避免, 又只能用 SQL 內建功能的話, 升級到 Server 2008 + SQL 2008 可能會有幫助. 但是沒有人可以保證提升多少? 關鍵還是在於您的頻寬需求量, 不管再怎麼壓縮, 也沒有人可以把資料壓到趨近於 0.

既然無法提升設備, 那就提升頻寬吧. 畢竟企業的資料量增加, 代表企業的業務活動也增加, 有活動, 就會耗用資源, 資源不增加, 勢必阻礙企業的活動.

至於 Server 2008 + SQL 2008 可以提升多少? 微軟做過一些實驗, 可以參考:
http://technet.microsoft.com/en-us/library/dd263442.aspx
裡面有詳細的實驗數據.

不過您注意看一下, 他這個跨國實驗裡, 頻寬的 Latency Time, 最佳是 1ms (同一州內), 最差的 加州<->杜拜 也有 150ms (可以簡單用 Ping 回應的 TTL Time 來參考), 如果您的頻寬無法達到這種程度, 恐怕也無法套用這個實驗的結果.

而且實驗用的資料量只有 1GB, 如果您的 Transaction 量比這還多, 您還是得要增加頻寬, 才能縮短時間.

至於 Riverbed 壓不到 15% 的問題, 如果您餵給 Riverbed 的資料, 是已經壓縮過的話 (例如: 啟用了 SQL 的壓縮), 他當然就無法壓得更多, 就如前面所說的, 資料不可能無限度的被壓縮下去.

還有, 你們的 Riverbed 有買 SQL ACCELERATOR SOFTWARE MODULE 嗎?