事務復制的特點
前面我們指出復制的本質就是從源數據庫向目標數據庫復制數據，但對不同的復制類型而言總是有差別的。從復制的具體內容來看快照復制是真正意義上的數據復制，不管采用何種數據接收方式（如將表刪除后再重建或刪除表中數據但保留表結構），在網絡中傳送的是數據。而事務復制在網絡中傳送的是事務（由一條或多條INSERT、 DELETE、 UPDATE）；從傳輸的數據量來看，事務復制僅將發生的變化傳送給訂購者，是一種增量復制，但快照復制卻將整個出版物復制給訂購者。
由于事務復制要不斷地監視源數據庫的數據變化，所以與快照復制相比，其服務器負載相應要重。
在事務復制中當出版數據庫發生變化時，這種變化就會被立即傳遞給訂購者，并在較短時間內完成（幾秒或更短），而不是像快照復制那樣要經過很長一段時間間隔。因此，事務復制是一種幾近實時地從源數據庫向目標數據庫分發數據的方法。由于事務復制的頻率較高，所以必須保證在訂購者與出版者之間要在可靠的網絡連接。
事務復制只允許出版者對復制數據進行修改（若設置了立即更新訂購者選項，則允許訂購者修改復制數據），而不像合并復制那樣，所有的節點（出版者和訂購者）都被允許修改復制數據，因此事務復制保證了事務的一致性。它所實現的事務一致性介于立即事務一致性和潛在事務一致性之間。
由于事務復制在極小的時延內把數據分發到訂購者，因此要求出版者與訂購者總是保持連接。但在快照復制中，由于相鄰兩次復制數據的傳遞間隔時間較長，則允許訂購者與出版者不必保持永久連接。
事務復制另外一個獨有特點是支持并行的快照處理，這也是SQL Server 2000 事務復制的新特征。正如在快照復制一節中所敘述的那樣，通常而言，在創建初始快照文件的整個處理過程中，都要在出版表上放置一個共享鎖來阻止對出版的更。新但事務復制所支持的并行快照處理卻允許在創建快照文件的整個過程中不必將共享鎖保持到快照文件創建結束之時。其具體過程是：在復制開始時，快照代理在出版表上放置共享鎖。當表示快照開始的事件被寫入事務日志時，該共享鎖即被釋放。這樣在隨后的時間，即使快照文件仍處于生成過程中，仍可以對出版表進行修改。由此可見，共享鎖在出版表時持續的時間很短。釋放共享鎖的時刻正是快照代理開始創建快照文件的時刻。在結束快照文件創建時。表明創建結束的事件被記錄到事務日志中。在從開始到結束的整個快照生成過程中所發生的影響出版表的事務將被日志閱讀代理發送到分發數據庫。
并行快照處理雖然允許在創建快照文件的過程中對出版表進行修改，但也因此而增加了快照處理的負載，降低了復制處理的性能，所以應在系統活動較少時，進行快照初始化處理。
16.4.2 事務復制的執行步驟
事務復制的執行主要需要三個代理：快照代理、日志閱讀代理、分發代理。
1 快照代理
快照代理從出版者獲取新的變化之前，必須使訂購數據庫的表與出版數據庫表具有相同的表結構和數據。因此快照代理首先要實現同步集合的初始化。SQL Server 只有在確認訂購者包含表描述與數據的快照文件后，才能進行事務復制。
2 日志閱讀代理
從出版者事務日志中搜索出帶有復制標志的事務，并將這些事務插入分發數據庫。
3 分發代理
分發代理將日志閱讀代理插入到分發數據庫中的事務分發到訂購者。
在事務復制中快照代理和分發代理的具體步驟與快照復制基本相同。事務復制中各代理按照以下的執行順序來協調工作完成事務復制（見圖16-53）。
（1） 當創建訂購時或到了創建出版物時，所規劃的時間快照代理就會被執行，快照代理在論文上放置共享鎖之后，便創建包含數據文件與描述文件的同步集合。描述文件主要是為了在訂購數據庫內創建與論文表相同的表結構。然后將：這兩個文件存儲在分發者的復制目錄下，并在分發數據庫中記錄同步作業。
（2） 日志閱讀代理可以連續不斷地運行或在出版物創建時規劃的時刻運行來監視數據變化。日志閱讀代理執行時，它首先閱讀出版物的事務日志，搜索出帶有復制標志的INSERT、 UPDATE、 DELETE 語句和其它修改事務。接著，日志閱讀代理將這些帶有復制標志的事務批拷貝至分發者的分發數據庫中。日志閱讀代理使用系統過程sp_replcmds 從日志中來獲取下一批帶有復制標志的命令。只有那些被提交的事務才送至分發數據庫。
在分發數據庫中的復制事務和出版者事務日志中有復制標志的事務是一一相對的。在 Msrepl_transactions 表中存儲的一個事務可由多個命令組成，每一條命令存儲在Msrepl_ commands 表中。在整個批事務成功寫入分發數據庫后，每一命令將被提交接著閱讀代理調用sp_repldone 系統過程來標明復制事務最終在哪里完成。最后代理標明在事務日志中的哪一行將被截掉。那些仍舊等待復制的行不會被截掉。從出版者刪除事務日志并不影響復制，因為只有那未標有復制的事務才會被清除。
（3） 事務命令一直存儲在分發數據庫中，除非分發代理從分發者將其推至訂購者數據庫或從訂購者將其拉到訂購者數據庫。
注意：分發代理第一次執行時的主要任務是訂購初始化，即將初始快照文件分發到訂購者。
分發代理僅用于復制而不包含任何用戶表，同時也不允許在分發數據庫中創建任何其它數據庫對象。
在出版者招待的將被復制的操作將按順序在訂購者上被執行、確保數據的最終一致性。
如果訂購事務出版物但卻沒有對訂購進行初始化，那么在出版者上自動定制的存儲過程都不能在訂購者上使用。相反必須在訂購者手工創建存儲過程。
16.4.3 存儲過程的復制
SQL Server 中除了可以復制表以外還可以復制存儲過程。在快照復制中，如果論文中包含存儲過程，則在復制過程中整個存儲過程將從出版者傳遞到訂購者。在事務復制中，如果論文中包含存儲過程，則在復制過程中傳遞給訂購者僅是一條存儲過程的執行語句，而不是由存儲過程的執行而引起變化了的數據。
如果某一存儲過程在執行后產生的結果集很大，我們會發現僅復制存儲過程的執行語句而不是大量的SQL 語句將帶來極大好處。不必再擔心大量的復制語句會占滿分發數據庫而引起事務丟失，也不再會因復制大量的SQL 語句而引起網絡傳輸性能的下降而感到沮喪。
下面的例子也許會幫助用戶更為深刻地理解復制存儲過程的優點。
假如數據庫的使用者打算修改出版物中某一表的10000 條記錄的某一列。如果不使用存儲過程復制，它的處理過程應是這樣的：當這些修改在出版者完成時，日志閱讀代理便會從事務日志中讀出這些帶有復制標志的上10000 條DELETE 語句以及相同數目的UPDATE 語句，并將它們送到分發數據庫，分發數據庫有限的空間立刻顯得有些局促起來如果您很不走運的話，分發數據庫會被添滿而導致復制中斷），然后分發代理再把這20000 條語句分發到訂購者，在分發時20000 語句爭先恐后地擠滿了網絡線路，我想您會體會到那種等待的滋味。
但是，如果利用存儲過程來實現這一修改，并在您的事務復制論文中添上該存儲過程，那么在網上傳遞上僅是一條EXEC 語句。
將一存儲過程定義成出版內容并不是一件困難事，只要在圖16-31 Specify Articles 對話框中選中Include Store 復選框即可。