2011-04-20 15:25 sql server 複製，映象，日誌傳輸及故障轉移叢集區別

一, 資料庫複製

         SQL Server 2008資料庫複製是透過釋出/訂閱的機制進行多臺伺服器之間的資料同步，我們把它用於資料庫的同步備份。這裡的同步備份指的是備份伺服器與主伺服器進行 實時資料同步，正常情況下只使用主資料庫伺服器，備份伺服器只在主伺服器出現故障時投入使用。它是一種優於檔案備份的資料庫備份解決方案。

            SQL Server的複製分為種：

1. 快照發布:

      釋出伺服器按預定的時間間隔向訂閱伺服器傳送已釋出資料的快照。每隔一段時間將訂閱資料庫中的相應表中的資料全部刪除，然後將自己相應表中的全部插到訂閱資料庫中

     使用快照複製本身是最合適的：

           1）很少更改資料。
           2）在一段時間內允許具有相對釋出伺服器已過時的資料副本。
           3）複製少量資料。
          4）在短期內出現大量更改。

         在資料更改量很大，但很少發生更改時，快照複製是最合適的。 例如，如果某銷售組織維護一個產品價格列表且這些價格每年要在固定時間進行一兩次完全更新，那麼建議在資料更改後複製完整的資料快照。 對於給定的某些型別的資料，更頻繁的快照可能也比較適合。 例如，如果一天中在釋出伺服器上更新相對小的表，但可以接受一定的滯後時間，則可以在夜間以快照形式傳遞更改。  

          釋出伺服器上快照複製的連續開銷低於事務複製的開銷，因為不用跟蹤增量更改。 但是，如果要複製的資料集非常大，那麼若要生成和應用快照，將需要使用大量資源。 評估是否使用快照複製時，需要考慮整個資料集的大小以及資料的更改頻率。

 

 

2. 事務釋出:

    在訂閱伺服器收到已釋出資料的初始快照後，釋出伺服器將事務流式傳輸到訂閱伺服器。

     事務複製通常從釋出資料庫物件和資料的快照開始。 建立了初始快照後，接著在釋出伺服器上所做的資料更改和架構修改通常在修改發生時（幾乎實時）便傳遞給訂閱伺服器。 資料更改將按照其在釋出伺服器上發生的順序和事務邊界應用於訂閱伺服器，因此，在釋出內部可以保證事務的一致性。

    以下各種情況下適合採用事務複製：

         1). 希望發生增量更改時將其傳播到訂閱伺服器。
         2). 從釋出伺服器上發生更改，至更改到達訂閱伺服器，應用程式需要這兩者之間的滯後時間較短。
         3). 應用程式需要訪問中間資料狀態。 例如，如果某一行更改了五次，事務複製將允許應用程式響應每次更改（例如，激發觸發器），而不只是響應該行最終的資料更改。
          4).釋出伺服器有大量的插入、更新和刪除活動。
          5).釋出伺服器或訂閱伺服器不是 SQL Server 資料庫（例如，Oracle）。

    預設情況下，事務釋出的訂閱伺服器應視為只讀，因為更改將不會傳播回釋出伺服器。 但是，事務複製確實提供了允許在訂閱伺服器上進行更新的選項

 

3.  具有可更新訂閱的事務釋出:

    在 SQL Server 訂閱伺服器收到已釋出資料的初始快照後，釋出伺服器將事務流式傳輸到訂閱伺服器。來自訂閱伺服器的事務被應用於釋出伺服器。

 

4.  合併釋出:

         在訂閱伺服器收到已釋出資料的初始快照後，釋出伺服器和訂閱伺服器可以獨立更新已釋出資料。更改會定期合併。Microsoft SQL Server Compact Edition 只能訂閱合併釋出。

       與事務複製相同，合併複製通常也是從釋出資料庫物件和資料的快照開始， 並且用觸發器跟蹤在釋出伺服器和訂閱伺服器上所做的後續資料更改和架構修改。 訂閱伺服器在連線到網路時將與釋出伺服器進行同步，並交換自上次同步以來發布伺服器和訂閱伺服器之間發生更改的所有行。

         合併複製通常用於伺服器到客戶端的環境中。 合併複製適用於下列各種情況：

           1).  多個訂閱伺服器可能會在不同時間更新同一資料，並將其更改傳播到釋出伺服器和其他訂閱伺服器。
            2). 訂閱伺服器需要接收資料，離線更改資料，並在以後與釋出伺服器和其他訂閱伺服器同步更改。
            3). 每個訂閱伺服器都需要不同的資料分割槽。
            4). 可能會發生衝突，並且在衝突發生時，您需要具有檢測和解決衝突的能力。
            5). 應用程式需要最終的資料更改結果，而不是訪問中間資料狀態。 例如，如果在訂閱伺服器與釋出伺服器進行同步之前，訂閱伺服器上的行更改了五次，則該行在釋出伺服器上僅更改一次來反映最終資料更改（也就是第五次更改的值）。

            合併複製允許不同站點自主工作，並在以後將更新合併成一個統一的結果。 由於更新是在多個節點上進行的，同一資料可能由釋出伺服器和多個訂閱伺服器進行了更新。 因此，在合併更新時可能會產生衝突，合併複製提供了多種處理衝突的方法

 

      

      複製的缺點： 表有主鍵，而且表結構日後不能更改，如果架構穩定也是不錯的，如果有很多張表那就比較麻煩了

 

   複製方法及過程：

http://www.cnblogs.com/dudu/archive/2010/08/26/1808540.html

http://www.cnblogs.com/killkill/archive/2009/07/17/1525733.html

 http://dufei.blog.51cto.com/382644/84645

http://www.cnblogs.com/wangdong/archive/2008/10/24/1318740.html

 二，資料庫映象：

        資料庫映象：

            優點是系統能自動發現主伺服器故障，並且自動切換至映象伺服器。

            缺點是配置複雜，映象資料庫中的資料不可見（在SQL Server Management Studio中，只能看到映象資料庫處於映象狀態，無法進行任何資料庫操作，最簡單的查詢也不行。想眼見為實，看看映象資料庫中的資料是否正確都不行。只 有將映象資料庫切換主資料庫才可見）

         相對於日誌傳送，資料庫映象顯然更高一級。在最簡單的形式下，它其實與日誌傳送的工作原理相似，但是生產伺服器傳送事務到映象伺服器的頻率要高得多，這意味著更新速度也要快很多。

　　對於資料庫映象來說，故障轉移功能也是需要手動完成。但是你可以新增第三個SQL Server，稱為witness。Witness可以作為一個普通的SQL Server，但是一直留意著其它兩個映象伺服器。當主映象發生故障，witness可以讓第二個映象接管操作，類似一種自動的故障轉移。

　　在故障轉移時，任何進行中的客戶端事務都將重新啟動，而由於在這一過程中仍然存在著延遲，映象伺服器也不能保證百分之百不丟失資料。

 

三，資料庫日誌傳輸：

          作為高可用性的最低階形式，日誌傳送(log shipping)本質上是SQL Server複製功能的一種延伸

          允許解決方案提供商建立多個資料庫副本。日誌傳輸能夠將次資料庫日誌副本同步傳送到SQL Server例項上。然後這些日誌會在次伺服器上重放，從而保持資料庫副本是最新的。

　　有一些解決方案提供商使用日誌傳輸作為克服資料庫映象缺點的方法。資料庫映象是很好的技術，但是它只允許我們實現一個資料庫副本。映象可以接近實時的方式進行，所以資料庫修改可以快速地寫到次資料庫上。如果客戶資料庫損壞或資料庫記錄意外刪除，那麼這可能會造成問題。

　　日誌傳輸有兩個主要的優點。首先，解決方案提供商能夠實現一種延遲，這樣日誌就不會即時重放。這是很重要的，因為如果主(或映象)資料庫出現問題，日誌可以在重放之前攔截，因此可以防止問題擴散。

　　日誌傳輸第二個主要的優點是它支援實現多個資料庫副本。有一些單位使用日誌傳輸作為在備份資料中心維護資料庫副本的方法，這能夠防止主資料中心出現問題時發生資料丟失。

　　 雖然日誌傳輸透過是作為資料庫映象的補充措施，但是它是一種獨立的技術，它可以不依賴於映象技術而獨立使用。

         

 

四，故障轉移叢集

          叢集技術是微軟可用性的最高階形式，它需要你設定一個Windows叢集。

　　在叢集中並不會涉及傳輸以及映象，取而代之，兩臺或更多的電腦將會彼此連線在一個共享的外部儲存器中，通常是儲存區域網路(SAN)。資料庫檔案就存放在這個共享儲存器上，同樣設定的SQL Server例項都執行在叢集節點上。

　　叢集中的所有節點中，實際上只有一個節點是一直處在活動狀態的，如果這個節點發生故障，其它的節點將啟動相應的SQL Server例項，並連線共享儲存器的資料檔案。而整個故障轉移過程往往只有幾秒鐘時間，對於任何給定的SQL Server例項，Windows叢集技術都可以確保客戶端始終注視活動的節點。

　　叢集技術非常複雜，但它是實現高可用的最高效技術。與前面介紹的兩個功能相比，叢集依賴於一個單一的資料庫檔案集。如果這些檔案損壞了，故障轉移也不能起作用了，因為故障轉移的例項同損壞的檔案是一樣的。而使用映象與日誌傳送，你可以對檔案進行實時複製，因此不必擔心檔案損壞的問題。SQL Server中，檔案遭到損壞的情況很少發生，因此我認為叢集應該還是一個不錯的選擇。

 

           缺點的。其中一個重要的問題是故障恢復的實現是非常昂貴的。Microsoft只在那些透過Windows Server認證的硬體上才支援故障恢復。  另一個問題是它要求使用共享儲存

come from: