SQLServer複製（二）--事務代理做業

以前的一篇已經介紹瞭如何配置複製，介紹了發佈者、分發者和訂閱者以及事務日誌運行的簡單關係。其中提到了複製代理，咱們這篇將詳細介紹複製代理，它是什麼？在事務複製的步驟中起到了什麼做用？

代理和工做

首先咱們要知道事務複製不是被SQLServer數據庫引擎執行的，而是被其餘外部的服務。這些服務中就包括了SQLServer 複製代理。

複製代理主要包括了快照代理、日誌讀代理和分發代理。雙向複製也使用了隊列-讀代理。

這些代理能夠理解爲在複製場景連接服務器而且促使數據移動的Windows 程序。在標準的複製安裝過程當中，由SQLServer代理來執行代理步驟。SQL Server代理有獨立的工做步驟模型（本地分發、遠程分發）。除此以外，有一些額外的做業在事務複製的配置階段將被建立。這些做業主要負責清理任務和探測問題的工做。

接下來咱們舉例來看一下那些做業將被在那些步驟來建立

本地分發模式

當你設置一個服務器爲分發服務器，有幾個做業須要被建立。圖1 顯示了徹底的列表，其中只有syspolicy_purge_history 不是複製的做業。全部其餘的做業都是被複制建立用來維護的做業。

 

圖1

遠程分發模式

當在發佈服務器上設置遠程分發的時候，只有一個維護做業被建立。如圖2所示，這個做業是用來刪除在發佈服務器上過時的元數據。

圖2

發佈

複製安裝的下一步就是建立發佈了，這裏須要兩個新的做業分在分發數據庫。如圖3所示，兩個的名字叫作「W7A\R2A-ReplA-1」 and 「W7A\R2A-ReplA-MyFirstPublication-1」表明了日誌讀和快照兩個代理。

圖3

經過在SQLServer 代理做業活動監視器中觀察category列，你能分辨出這些做業分別表明什麼嗎？圖4所示

圖4

推送訂閱

對於每個訂閱服務有一個額外的做業，這個做業表示了分發代理，以防推送訂閱的做業出問題。你能看到一個實例在圖5中。分發做業的名字叫作「W7A\R2A-ReplA-MyFirstPublication-W7C\R2A-2」。在訂閱模式下，全部的代理和做業都在分發數據庫上。

圖5

請求訂閱

以防在訂閱數據庫的分發代理的請求訂閱失效，如圖6配置，這個代理做業的名稱是W7A\R2A-ReplA-MyFirstPublication-W7C\R2A-ReplB-3E02694F-8281-4EBA-81CE-185B3BDE0830」。

 

圖6

若是你打算確認正在工做的分發代理，你能夠參考SQL Server代理做業活動監視器中的category 列。如圖7

圖7

代理

乍看，大量的做業和代理，每個做何不一樣事情在不一樣的時間。可是，當你本身觀察會發現僅有三個主要的做業在事務複製中：

快照代理，日誌讀代理和分發代理。圖8給出了三個代理的概覽

 

圖8

圖中綠色的箭頭表明讀取，紅色箭頭表示寫入。分發代理在分發數據庫仍是在訂閱服數據庫，取決於訂閱的模式。

快照代理

快照代理是在快照複製中起到重要做用。在事務複製和其餘全部複製類型中，快照代理被用來初始化同步。快照代理不是惟一的初始化同步方式，可是確實是最方便的方式。

建立一個快照包含兩個步驟。第一是將全部的訂閱端複製對象快照代理的刪除和建立的腳本放置在快照文件夾。它生成BCP文件後發表的全部表中的數據，全部生成的文件將被保存在分發數據庫，

運行這個語句在Ｌｉｓｔｉｎｇ１ 中的，看看每一個ＢＣＰ文件的條目。

對於快照複製而言當ＢＣＰ文件被生成時一個共享鎖被加在了全部發布的表上。這就容許快照代理去保證了事務的數據一致性，可是它鎖住了其餘全部同時想去寫入表數據的請求。取決於此次涉及的表的大小可能鎖的時間是至關大的。在快照複製中這是惟一的方式去保證事務一致性。

事務處理的一致性經過如下幾點來保證：

1. 一旦快照的進程開始，一個表鎖將被加到全部發布包含的表上。而後一個快照進程開始的標識將被寫入發佈數據庫的日誌文件裏面。在標記記錄完之後這個鎖將被釋放。BCP文件將被生成並不帶有表鎖。可是更多細粒度且短暫的鎖將被將在頁或者行級別上。
2. BCP文件建立完成後，另外一個標記被寫入到發佈數據庫的日誌文件中，它標識着快照進程的結束。對於複製的表，全部已提交的更改將被記錄在日誌文件中且在日誌文件中的兩個標記中間，而後經過日誌讀代理複製到發佈數據庫。
3. 當去應用快照到訂閱數據庫的時候，經過使用以前的腳本在快照文件夾中刪除並重建表。而後來自BCP文件的數據被複制到這些表裏，同時一個表鎖住所有的表。伴隨着鎖，最後一個環節是分發代理使用快照產生之間捕捉的日誌數據來保證全部的表在事務處理一致性。

經過SQL Server默認的爲每一個發佈執行的快招代理建立SQL的代理做業。這些做業的命名依據一下模式：<Server>-<Publication Database>-<Publication>-<number>。固然你也能夠手工建立開啓一個代理或者安排它過一段時間執行。

日誌-讀代理

日誌-讀代理是負責將全部發生改變的發佈數據庫的對象的事務處理以複製事物日誌記錄的形式複製到分發數據庫。正如咱們知道的，每一次數據庫任何對象發生變化首先記錄到數據庫的事務日誌中，而後纔會將改變實如今真是數據頁上面。這是任何關係數據庫的原子性的核心部分。

一樣的，在複製的發佈系統經過將發佈的複製對象的改變的事務日誌最終發送到訂閱數據庫的目標對象上。

假如一個DML改變或者DDL改變發生在非發佈數據庫的發佈對象上，則這些改變的日誌記錄會被標記一個複製的狀態，這些非複製對象的將不會被標記也就不會被複制到分發數據庫，即便他們在一個事務裏面。

 

假如你已經配置好了複製，請注意你發佈數據庫的日誌文件的大小，你可使用下面的查詢來看是否複製正在阻止日誌記錄從新使用。假如

log_reuse_wait_desc 列中包含了值R‘REPLICATION’，則複製發生了不被預期的日誌增加，寫操做將被阻止。

在複製數據庫中首次配置複製發佈的期間，SQLServer將建立一個單一的SQL代理做業來執行日誌-讀代理。命名格式以下：<Publisher>-<Publication Database>-<number>。全部其餘在這個數據庫的發佈將重用這個做業。這個做業被默認安排與SQLServer一同啓動，根據咱們以前的理論這意味着它老是在運行順序中優先執行，而且你不該該改變這個常規。

分發代理

 

分發代理負責將數據傳送從分發數據庫傳送到訂閱數據庫。分發代理鏈接分發服務器而且讀取改變的記錄。而後它鏈接訂閱服務器將改變以相同的順序在再次實現，順序在單一訂閱服務器是被保證的。可是假如你有兩個發佈在相同的數據庫的不一樣對象上，而且有兩個相同訂閱數據庫的訂閱，則順序只被保證在每個發佈裏面，而再也不屬於獨立發佈的語句中（如，一個sp關係到兩個表的改變，而這兩個表屬於不一樣的複製發佈，則對於每一個表的修改記錄是按順序進行而兩個表的之間沒有前後順序）。

按照默認模式，SQLServer建立一個做業爲每一個訂閱去執行分發代理。這個做業有兩種執行模式。

(「Push Subscription」) 這種模式的命名管慣例：<Publisher>-<Publication Database>-<Publication>-<Subscriber>-<number>

(「Pull Subscription」)而這種則看起來有點不一樣：<Publisher>-<Publication Database>-<Publication>-<Subscriber>-<Subscription Database>-<GUID>

 

Jobs（做業）

 

正如文章開頭提到的那些做業，這些額外的做業是複製系統所須要的，咱們應該有所瞭解主要如下幾個，具體的做用請參考MSDN我就不一一解釋了，以下：

• Agent history clean up
• Distribution clean up
• Expired subscription clean up
• Replication agents checkup 

總結

在這片文章裏，我介紹了複製代理做業的內部邏輯，咱們可以瞭解到每一個做業代理的目的和做用，這對咱們理解複製的細節和優化維護複製有很是大的幫助，尤爲是實際生產環境中的特殊狀況提供了底層的應對機制。複製做爲SQLServer高可用的一個應用功能爲跨服務器跨實例跨系統等提供了很是好的實用價值。接下來我將繼續深刻的瞭解複製的其餘用途和細節。