none
SQL Server Replication問題請教! RRS feed

  • 問題

  • Dears! 請教各位下列問題:

    1.如果兩台都在同一個Lan上的SQL Server設定【交易式】replication,是不是只要【發行端】有異動,就會同步到【訂閱端】?

    2.承1,一般正常情況下交易會有延遲嗎?如果有的話延遲時間會是多久呢?

    3.如果【交易式】複寫的訂閱者Fail掉了,當訂閱者再上線之後,之間所miss掉的資料會自動再進行同步嗎?

    4.承1,如果設定【交易式】replication,為避免交易的丟失而造成資料不同步的問題,是否需要排定【快照式】replication來彌補這個問題?

    5.承3,【快照式】replication傳遞的資料是上一次同步之後所異動的部份,還是所有的資料都會再全部重傳?

    以上數個問題還請各位新進不吝指教,感恩~~
    2009年12月8日 上午 07:38

解答

  • Dear DannyLee

    交易式的複寫必須視設計的方式是以點對點的交易複寫,還是有以Transact-SQL sp_addsubscription 的 @loopback_detection 的交易複寫,若是前者是會雙向複寫,而後者則只能由剸行端到訂閱端。

    交易延遲的時間則視伺服器的效能而有所異,若是在lan的延遲您幾乎沒感覺

    若交易式複寫的訂閱者離線了,只要它的(訂閱發行集)發行集還在就會自動同步,若是發行集是屬於派送式發行集則必須重新初始化。

    若您望在交易複寫失敗的話,透過快照集的方式,那麼這個就是屬於合併式複寫了,快照式的複寫是單向的傳遞,若您指定好了快照發行集就會直接將在發行集當下產生出來的快照,將訂閱者的資料庫同步掉

    下面是小弟寫的劣帖實作SQL Server 2008資料庫複寫實作,若有任何問題歡迎您再提出!
    SQL Server 2008 複寫實作

    另外,下面的連結是TechNet的複寫設計和實作的概觀
    http://technet.microsoft.com/zh-tw/library/ms151847.aspx

    Jason的電腦健身房 沒有永遠的安全 沒有永遠的弱點 有牌的神經病
    2009年12月8日 下午 03:06
  • This may happen in non-replicated table, ensure new pkey value is unique in the table.
    2009年12月9日 上午 04:16

所有回覆

  • Dear DannyLee

    交易式的複寫必須視設計的方式是以點對點的交易複寫,還是有以Transact-SQL sp_addsubscription 的 @loopback_detection 的交易複寫,若是前者是會雙向複寫,而後者則只能由剸行端到訂閱端。

    交易延遲的時間則視伺服器的效能而有所異,若是在lan的延遲您幾乎沒感覺

    若交易式複寫的訂閱者離線了,只要它的(訂閱發行集)發行集還在就會自動同步,若是發行集是屬於派送式發行集則必須重新初始化。

    若您望在交易複寫失敗的話,透過快照集的方式,那麼這個就是屬於合併式複寫了,快照式的複寫是單向的傳遞,若您指定好了快照發行集就會直接將在發行集當下產生出來的快照,將訂閱者的資料庫同步掉

    下面是小弟寫的劣帖實作SQL Server 2008資料庫複寫實作,若有任何問題歡迎您再提出!
    SQL Server 2008 複寫實作

    另外,下面的連結是TechNet的複寫設計和實作的概觀
    http://technet.microsoft.com/zh-tw/library/ms151847.aspx

    Jason的電腦健身房 沒有永遠的安全 沒有永遠的弱點 有牌的神經病
    2009年12月8日 下午 03:06
  • For first point, you can set replication in real time or in batch mode.
    2009年12月8日 下午 08:36
  • 謝謝以上兩位的回覆!

    拜讀完 Huang Jason 兄的文章後,我實際測試了一下:

    1.如果設定為交易式的複寫,在Lan的環境真的幾乎沒有什麼延遲,在訂閱者的Table中資料很快就異動了!

    但是如果今天將訂閱者主機關機,在發行者這邊的table,就無法進行資料的新增(如下圖)? 【PS.方式為發送訂閱】





    3.如果設定為合併式的複寫,就算同步的排程設定為連續執行,但是資料在數十秒鐘之後,才會同步到到另外一台主機!

    請問關於上面第3點的部份,是否有參數可以調整,讓合併式複寫的速度能像交易式複寫那麼快呢?

    還是說合併式複寫本來主要就是設計給離線資料庫同步使用,所以其缺陷就是同步的速度不快呢?以上問題敬請各位不吝賜教!感恩~~
    2009年12月9日 上午 02:51
  • Is pkey an identity column? You need reseed it with 'dbcc checkident' if so.
    2009年12月9日 上午 03:03
  • 再請教一下,如果【快照集資料夾】一開始使用預設值,現在想要改成放置到D磁碟機的話,應該如何修改呢? 感恩 .....
    2009年12月9日 上午 03:15
  • Take look at publisher properties, may able to make change there.
    2009年12月9日 上午 03:50
  • Is pkey an identity column? You need reseed it with 'dbcc checkident' if so.
    您好!

    該欄位屬性是Primary key,但不是identity欄位~~
    2009年12月9日 上午 03:52
  • This may happen in non-replicated table, ensure new pkey value is unique in the table.
    2009年12月9日 上午 04:16
  • This may happen in non-replicated table, ensure new pkey value is unique in the table.

    感謝您的回覆,我又重新建立一個Table來測試,結果就正常了,再次感謝!
    2009年12月9日 上午 06:31
  • Dear DannyLee

    合併式複寫可以說是綜合了快照及交易複寫的優體,但是對於效能上來說,就有比較大的差別了,因為SQL會在有任何變更的動作上主動的與成員做確認

    並且會自動將資料丟遞給其它成員做複寫,因此會有反應較慢的問題。

    而提升效能的部份,因為各台SQL Server所能發揮的效能還是有差別,可以透過下面的這個連結內容來做一個增強:
    http://msdn.microsoft.com/zh-tw/library/ms152770.aspx


    Jason的電腦健身房 沒有永遠的安全 沒有永遠的弱點 有牌的神經病
    2009年12月9日 上午 09:23
  • Dear DannyLee

    您可以在複寫發行集的進階內容中找到你發行快照集的位址,但是記得還是要寫成網路路徑才可以進行存取(快照集存放的路徑必須共享出來)。
    Jason的電腦健身房 沒有永遠的安全 沒有永遠的弱點 有牌的神經病
    2009年12月9日 上午 09:25