by adonis
24. 四月 2014 15:57
前言
最近被問到一個和複寫有關的問題,而經過實作後發現和以前的 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之後,你可以放心的備份資料庫與複寫同時進行,不用擔心會出現錯誤的情況。

b0e90399-1cec-42d3-bd6f-c3a3cb12cbe0|0|.0
Tags: