前言

最近被問到一個和複寫有關的問題，而經過實作後發現和以前的 SQL Server有不一樣的測試結果，所以本篇就來說明一下到底有何改變。

SQL Server的交易式複寫

在了解本期所講的主題之前，先稍微了解一下 Replication的機制。
Replication中文為複寫，也就是自動化加上匯入匯出，亦即自動匯入到別台 SQL Server稱為複寫，這個功能需要自動化方能完成。
複寫這個功能可以當做另外一種形式的備份，也可以當做資料分散的工具之一，本期要介紹的是交易式的複寫。

一般來說，複寫之中交易式複寫使用的人最多，因為它的延遲性是最低的，什麼叫做延遲性？也就是第一台 SQL Server資料有異動時，第二台 SQL Server何時會接收到資料，並且修改它的時間差。複寫並不在乎同一時間要有相同的資料，它只在乎最後資料要一致，因為複寫當初設計的目的是為了低速網路而存在，當第一台 SQL Server新增了十萬筆資料，可能第二台 SQL Server只有五萬筆，因為網路速度的關係，還沒有全部到達第二台 SQL Server。

而為什麼交易式複寫的延遲性會最低呢？在討論之前稍微提一下，複寫其實就是自動化的子系統，是由多個 subagent所組合而成，像交易複寫主要是由 snapshot agent、log reader agent、queue reader agent 以及 distribution agent所組合而成，當資料有異動時，log reader agent立刻將異動的資料送給 distribution agent處理，而distribution agent則是接收資料後立刻傳送到訂閱者端，預設 log reader agent是永遠啟動，而交易式複寫的 distribution agent則是預設收到資料會自動傳送到發送端。

稍微了解這個交易式複寫之後，本期的重點就在這個交易式複寫身上，也就是很多人常會問到的一個問題：當我們公司已經在做交易式複寫了，請問還可能，或是還能夠備份資料庫或是 log嗎？

這個要在以往，我幾乎會很肯定的跟你說：不行。因為各位想看看，剛才提到交易式複寫其中有一個 agent叫做 log reader agent，當資料表有異動時，log會被記錄下來，而 log reader就會發現其蹤影而將此 log記錄丟到散發者端，而備份資料庫的 log卻會導致 log在備份完成後被清除。

所以在之前的 SQL Server，有一個預存程序是在做這件事情，它的設計宗旨是如果你備份 log，log在還沒被清除前，交易複寫會先將 log裡的資訊丟入散發集，然後備份 log完成，不過這個必需是要設定的，預設這個功能並沒有被啟動，所以在之前的實作結果都是如果你已經有交易式複寫的話，則 log備份成功，然後交易複寫會失敗。

我們現在來實作一下，看看這樣的情況在 SQL Server 2012會不會出現。

首先，先定義一個快照目錄，如下圖：

接下來設定散發者時，把快照資料夾設定在這個 share folder

在設定複寫種類時，選擇交易式發行集：

選擇發行項時，我們這裡選擇 person.address資料表當做發行項：

精靈設定好之後，你應該可以在訂閱端看到資料表的產生。

這時，試著修改一下發行者的資料，你會發現 log reader agent將會啟動，表示它開始運作了，如下：

這時，請做一次完整資料庫備份，然後再修改一下發行者的資料，你會發現，這時的 log reader agent依舊正常的將資料複寫到訂閱者端。

好，我們不死心，來一個更狠的，使用 log 備份，備份完再試一下，修改發行者的資料，然後查看一下訂閱者資料是否有修改。

結果發現，一點影響也沒有，換句話說不會出現錯誤訊息，也不會使得複寫無法使用或是停用，感覺起來好像一點關係也沒有，這個就是結論。

至於這個功能是源自於哪個版本之後就改成目前這個樣子，目前並沒有答案，但可以肯定的是，至少在 SQL Server 2012之後，你可以放心的備份資料庫與複寫同時進行，不用擔心會出現錯誤的情況。