深入淺出SQL Server Replication第三篇：事物復制實戰-建立Publisher
對於很多的SQL Server DBA而言，Replication不是什么新鮮的事物了，也是大家常常說的“復制”，很多的朋友已經在項目中使用。正如其他技術一樣：有人可以使用的好，有人會抱怨技術不行。
我們AgileSharp團隊也經過了不少高可用的案例， Replication還是非常有價值的。因此，我們整理了很多的資源，我們決定發布一系列的Replication文章，一是為了幫助大家了解Replication，另外也是為以后的講述高可用做個鋪墊。
在之前的文章中，我們已經對Replication做了總體的介紹，而且也講述了如何配置Distributor。那么在本篇文章中，我們將會講述如何配置Publisher。
Publisher可以看出是數據產生的源頭，也是Replication的核心，因為只有Publisher產生了變化，其他的組件的運行才有意義。可以想象得到：一個Publisher可以有很多的Publication，也就是說，一個發布服務器可以有多個發布。其實這一點很好的理解。
這一點拿生活的圖書訂閱就很好解釋了：我們不可能對出版社的所有書都感興趣，我們只是訂閱自己喜歡的書籍，而出版社同時又為很多的讀者提供訂閱服務器，即發布很多不同的書。
同理，因為一個Publisher發布服務器就是一個數據庫實例，這個實例中有多的對象是變化的，如表。但是很多的訂閱服務器並不是對所有的這些變化都感興趣，只對部分感興趣，所以，我們可以在這個發布服務器上面創建多個Publication發布，從而滿足不同的訂閱服務器。
在每一個Publication發布中有包含很多的Aritcle（項目），我們知道：項目用於標識發布中包含的數據庫對象。一次發布可以包含不同類型的項目，包括表、視圖、存儲過程和其他對象。當把表作為項目發布時，可以用篩選器限制發送到訂閱服務器的數據的列和行。
下面，就帶領大家一起創建一個Publication。
建立Publication
想要創建一個Publication，必須首先要將一個Publisher和Distributor進行關聯。我們在上一篇文章中已經講述了如何創建和配置Distributor，這里就在贅述。
誰可以創建一個Publication發布
要清楚，不是誰都可以創建Publication的。只有具有db_owner的角色的用戶才可以創建。
為了使得數據庫可以在Replication中使用，我們必須要進行一定的配置。我們在Publisher（發布服務器）的對象管理器中進行如下操作，如圖：
在Replication節點上面點擊右鍵，然后開始設置相關的內容，如下圖：
在彈出的窗口中包含了兩個選項。在”General”選項卡中，我們可以設置連接到Distributor的用戶的信息，因為Publisher連接到Distributor，肯定是通過某個用戶才能連過去的，我們在這里就可以設置這個用戶的密碼等信息。
在”Publication Databases”選項卡中，我們可以選擇哪個數據庫將會作為發布源來對外發布數據。並且，還可以選擇采用何種復制方式，如事務復制，合並復制。
創建新的Publication
配置好了Publisher之后，就可以創建一個Publication了，其實這個步驟，我們在第一篇文章中也做了簡要的展示，如圖：
然后根據向導一步步的創建，這里就不在重復，下面直接給出圖示：
我們這里演示的是事務復制的示例。
另外，在其中，還有一個另外的一個事務復制（Transaction publication with updatable subscriptions，事務復制的可更新訂閱）。
事務復制支持在訂閱服務器中通過可更新訂閱和對等復制來進行更新。下面介紹兩種可更新訂閱：
· 立即更新。必須連接發布服務器和訂閱服務器才能在訂閱服務器中更新數據。
· 排隊更新。不必連接發布服務器和訂閱服務器即可在訂閱服務器中更新數據。可以在訂閱服務器或發布服務器脫機時進行更新。
在訂閱服務器中更新數據時，首先將數據傳播到發布服務器，然后再傳播到其他訂閱服務器。如果使用立即更新，將使用兩階段提交協議立即傳播更改。如果使用排隊更新，更改將存儲在隊列中；當網絡連接可用時，再在發布服務器中異步應用排隊事務。由於更新異步傳播至發布服務器，所以發布服務器或另一台訂閱服務器有可能更新同一數據，而在應用更新時會發生沖突。將根據創建發布時設置的沖突解決策略檢測和解決沖突。
如果在新建發布向導中創建具有可更新訂閱的事務發布，將同時啟用立即更新和排隊更新。如果使用存儲過程創建發布，則可以啟用一個或兩個選項。創建發布的訂閱時，可以指定要使用的更新模式。如有必要，以后可以在兩種更新模式之間切換。
擇項目(Articles)
在上面的向導中選擇了Publication的類型之后，接下來就是要選擇把那些對象作為Article發布出去。一般而言，一個Article就是指代數據庫中的一個對象。在下圖中，在Articles向導頁中列出了可以發布的所有的對象：表，存儲過程，視圖，函數。
很多的時候，當我們的Articles都是選擇表，因為我們要把表中的改變的數據發布出去。對於表，我們也有更多的選擇，例如選擇那些字段，因為可能在表中有些數據是不變的，此時我們只要選擇那些數據常常改變的字段，減少不必要的數據傳輸。如圖：
另外，我們還可以點擊”Aritlces Properties”來設置更多有關Articles的選項，如圖：
那么，這里需要注意的就是：我們可以同時為很多的Article設置選項，也可以為某一個Article設置。
如果我們的選擇的Articles中包含表，那么我們可以在向導的下一步對表添加一些過濾條件，如圖所示:
Snapshot快照
在上面選擇和配置了Articles之后，下面就要思考一個“雞生蛋，蛋生雞”的問題：既然是把Publisher中的數據同步到Subscriber中，那么，在Subscriber上面首先一定要存在一個和Publisher一樣的數據庫，之后才能把Publisher中的改變同步過去。
在向導中的這個Snapshot步驟就是來在Subscriber中創建一個現有數據庫的快照的，創建快照的過程可以在立刻進行，也可以在向導完成之后在某個時刻運行，如圖：
在這里又有一些點需要注意。建立一個快照的時候，我們的Publication選擇的那些表會被加上鎖，如果那些表很大，那么這個加鎖的過程會很長，導致對表的讀寫都延時，而且會進行大量的讀寫日志的操作，從而消耗大量的CPU，磁盤I/O等資源。另外，如果表過大，在傳輸的過程中會嚴重消耗網絡資源，可能導致外部對數據庫的訪問被阻塞。
安全設置
設置了快照之后，下一步就要設置運行Publication的代理進程采用何種的身份進行運行。如圖：
在事務復制的Publication中涉及到的兩個代理分別是快照代理和日志讀取代理。
快照代理的任務就是把Publication中的數據移動到之間在Distributor中設置的快照文件夾和distribution數據庫中。為了實現這些操作，這里設置的用戶在publication涉及到的數據庫和distribution數據庫中都必須在db_owner角色中。而起這個用戶還必須對快照文件夾有寫的權限。
日志讀取代理主要用來把publication中的數據復制到distribution中，但是這個代理不需要訪問快照文件夾。所以，日志讀取代理的這個用戶只要在distribution數據庫中處於db_owner的角色就行了。
我們可以通過點擊“Security Setting”進行更多的設置，如圖：
設置完成之后，點擊下一步，直到完成。
最后結果如圖所示：
潛在問題分析
大家從上面的操作可以知道，建立一個Replication的應用需要花很多的步驟，步驟越多，可能出現的問題也就越多。其中最有可能出現問題的地方就是安全設置那一塊。所以，在配置之前已經要把用戶和對應的角色分配好，一般的建議是在采用SQL Server驗證方式來連接。