SQL Server分佈式數據庫技術(LinkedServer,CT,SSB)

SQL Server自定義業務功能的數據同步

在不一樣業務需求的驅動下，數據庫的模塊化拆分將會面臨一些比較特殊的業務邏輯處理需求。例如，在數據庫層面的數據同步需求。同步過程當中，可能會有一些比較複雜的業務邏輯判斷。簡單介紹幾個SQL Server提供的數據同步功能。

1. 已連接服務（Linked Server）

經過連接數據庫能夠實現不一樣實例間數據的訪問和更新操做。一般會與OPENQUERY行集函數一塊兒使用，以免分佈式事務的干涉。不建議直接使用已連接服務來作遠程數據的更新操做，由於這須要使用到分佈式數據庫的事務管理。SQL Server的分佈式事務須要經過Windows的DTC（Distributed Transaction Controller，分佈式事務控制器）來管理和協調不一樣服務器，或者說不一樣數據庫實例間的資源和事務調整，其性能與普通的事務管理成幾何倍的增加。

如圖10-4，頁面是已連接服務的配置界面，能夠經過SSMS的Server Objects中的Linked Servers可視化頁面來進行配置。

圖11-4 數據庫的已連接服務

Provider是已連接服務器鏈接數據庫時使用的適配器的類型，如圖11-4中，左邊部分顯示的，列出了幾趾已有的適配器的類型。示例中，使用SQLOLEDB類型的適配器進行數據庫鏈接。

Security頁用來配置連接服務器的驗證信息，它包括如圖11-5中所示的4種模式的驗證方式。

Not be made

當選擇此認證模式時，已連接服務將使用本地服務的登錄用戶與遠程服務登錄用戶的映射配置列表中的帳號。如圖中，當選擇此模式時，本地將只能使用sa登錄時，模擬遠程服務的sa帳號的權限配置。

Without using a Security context

選擇此模式將不使用驗證模式，它只利用SQL Server服務的登錄帳號進行驗證，此服務要求在Windows服務啓動時，本地服務和遠程服務使用相同的登錄帳號。

Using current security context

當使用此模式時，要求本地和遠程服務都要有相同的帳號及密碼，一般這些配置爲Windows集成認證的時候使用。

Using this security context

使用此模式時，將使用下面配置的用戶和密碼進行登錄遠程服務。

本小節中只是簡略地介紹了關於這些配置的簡要步驟，要獲取更詳細的內容，請參考SQL Server聯機叢書（http://technet.microsoft.com/zh-cn/library/ff772782.aspx）。

圖11-5 連接服務器安全配置

1. 更改跟蹤（Change Tracking）

更改跟蹤是SQL Server 2008加入的一個輕量級的數據修改記錄功能，它是數據變動捕獲功能的縮減版本。它能夠將已修改數據的主鍵記錄在對應的視圖中，然後經過系統函數訪問該視圖，得到相應的變動數據。經過變動數據的記錄，能夠實現增量地處理複雜的業務邏輯，然後將數據結果保存到目標數據庫中。

示例代碼如代碼清單11-1中所示，開啓更改跟蹤是依據表來配置的，可是在配置表的更改跟蹤以前，須要將數據庫的更改跟蹤選項開啓，開啓數據庫更改跟蹤選項時，默認會將更改跟蹤記錄保留2天，並開啓自動清理的選項。

更改跟蹤能夠跟蹤到具體的字段更改配置，如代碼清單11-1中，TRACK_COLUMNS_UPDATED配置所示，當選項爲ON狀態時，將會記錄下更改跟蹤修改的字段，當爲OFF時，將不會記錄。

USE master

GO

ALTER DATABASE [AdventureWorks2008R2] SET CHANGE_TRACKING = ON (CHANGE_RETENTION = 2 DAYS,AUTO_CLEANUP = ON);

GO

USE AdventureWorks2008R2

GO

ALTER TABLE Person.BusinessEntity ENABLE CHANGE_TRACKING WITH(TRACK_COLUMNS_UPDATED = ON);

GO

 

UPDATE TOP(10) Person.BusinessEntity

SET ModifiedDate=ModifiedDate;

GO

 

SELECT *

FROM CHANGETABLE(CHANGES Person.BusinessEntity,0) AS o;

GO

 

代碼清單11-1 設置更改跟蹤

圖11-6 更改跟蹤查詢結果

代碼清單11-1中的執行結果如圖11-6中所示，使用CHANGETABLE能夠得到對應表的更改歷史，更改歷史會將原有表的主鍵記錄下來，如圖11-6中BusinessEntityID字段所示。

關於更改跟蹤的詳細信息，能夠參考一下SQL Server聯機叢書。

1. Service Broker

Service Broker是SQL Server自帶的消息隊列機制，經過Service Broker能夠實現數據實例與實例間的通信，同時也能夠做爲數據庫實例與應用程序的消息傳遞機制。

同時，Service Broker是隊列機制實現的，能夠保證消息的執行順序，對於具備事務性要求的數據同步，Service Broker將是很理想的一個數據同步實現。

如代碼清單11-2中所示，配置了Service Broker在同實例下的同步配置。配置包括建立消息類型（Message Type），建立消息規則（Contract），隊列（Queue）以及服務（Server）。其層級結構如圖11-7中所示，首先，消息是存放在隊列中的，每一個隊列都須要一個惟一的服務對應，服務將成爲找到對應的標識。服務與服務間通信時，須要指定相同的，相互能夠識別到的消息規則，這些規則會指定對應的消息通信的類型。其工做的流程，如圖11-8中所示。

圖11-7 Service Broker的組件組成

圖11-8 Service Broker的工做原理

當須要進行隊列傳輸前，須要開啓一個會話（Conversation），經過會話記錄下對應的服務標識，標識從源服務發送到目標服務。找到會話標識後即可以找到對應的隊列。

開啓會話之後，進行消息發送，對於數據庫實例來講，只須要將消息寫入到發送隊列就能夠了。消息被寫入到發送隊列後，後續的工做都交給Service Broker來處理。

當消息進入發送隊列，Service Broker根據會話記錄的服務標識，找到目標服務，並將消息拆分爲多個消息片段，將消息發送到目標服務，服務接收完成全部的消息後，將消息寫入到目標隊列中。在寫入到目標隊列後，消息傳遞就結束了。後續的工做便交給應用處理了。

應用須要調用接收消息的命令，將消息從接收隊列中取出，並進行一系列的後續業務工做。

關於Service Broker能夠參考SQL Server聯機叢書（http://technet.microsoft.com/zh-cn/library/ms166104(v=SQL.105).aspx）。

下面的代碼是一份在同一實例下進行Service Broker配置以及測試的腳本，能夠參考一下代碼，並結合上圖11-8中的工做原理參考Service Broker的工做方式。

use master

go

alter database AdventureWorks2008R2 set enable_broker with rollback immediate;

go

 

use AdventureWorks2008R2

go

 

create message type ReceiveMsgType validation = none;

create message type SendMsgType validation = none;

 

go

create contract SampleContract(SendMsgType sent by initiator,ReceiveMsgType sent by target,FraudEndOfStream sent by initiator);

go

 

create queue SampleTargetQue;

create service SampleTargetSrv on queue SampleTargetQue(SampleContract);

go

 

create queue SampleInitQue;

create service SampleInitSrv on queue SampleInitQue(SampleContract);

go

 

/********************************Send Test********************************************

declare @handle uniqueidentifier,@msg varchar(8000) = 'this is a test message!';

 

begin dialog conversation @handle

from service SampleInitSrv

to service 'SampleTargetSrv'

on contract SampleContract

with encryption = off;

 

send on conversation @handle

message type SendMsgType(@msg)

 

**********************************************************************************/

 

/*****************************Receive Test*************************************************

declare @receivemsg varchar(8000),@Handle uniqueidentifier;

waitfor(receive top(1) @Handle = conversation_handle,

            @receivemsg = Message_Body

            from SampleTargetQue),timeout 1000

end conversation @handle;

select @receivemsg;

 

**********************************************************************************/

代碼清單11-2 同實例下的Service Broker配置