This article discusses how to use various SQL technologies to accomplish real time data integration between SQL Server instances. It provides a set of sample code to help users with their development. The document focuses on the usage of each technology which is incorporated into the data integration service. Please refer to provided links for detail information about the technologies.
Real time data integration definition
Real time data integration supports event-driven data movement and transformation between SQL Server instances which host databases with different schemas. The data integration should be transparent to source systems without significantly impacting the systems when events are captured and delivered. The technique also supports an intermediate format which allows decoupling of schemas between source and destination systems. It allows either system to change schemas without breaking the application in the other system. The data integration provides fast and efficient data delivery to a destination in an event-driven model, without polling the source system for new data.
Sales data integration
The real time data integration demo shows the sales data integration between the databases, AdventureWorks (AW) and AdventureWorksDW (AWDW). The data integration service catches the sales data change on AW, and transforms the data in the schema supported in AW onto a general XML format. The service sends the data in XML onto AWDW, and transforms it to correspond to the AWDW schema.
The demo uses the sample databases on SQL Server. Please refer to the link for the detail information about the databases [http://msdn.microsoft.com/en-us/library/ms124659.aspx]. Users can download and install the databases for SQL Server 2008 from the following link [http://technet.microsoft.com/en-us/library/ms124501(SQL.100).aspx].
Techniques
Change tracking
Change tracking provides a mechanism to query for changes to data and to access information related to the changes. This solution provides answer to the following questions. What rows have changed for a user table? What are the latest data in the rows? Change Tracking requires small amount of storage for each changed row, while it only works for getting the latest data. Please refer to the following link for detail information about Change Tracking [http://msdn.microsoft.com/en-us/library/bb933874(SQL.100).aspx]. If an application requires information about all the changes and the intermediate values of the changed data then it should use Change Data Capture (CDC). Please refer to the following document for the comparison of two techniques [http://msdn.microsoft.com/en-us/library/cc280519(SQL.100).aspx]. We plan to write another document which shows how to use CDC as a change tracking option. The following code block shows how to enable Change Tracking on the database and table levels.
ALTER
DATABASE AdventureWorks SET CHANGE_TRACKING = ON (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON)ALTER
TABLE [AdventureWorks].[Sales].[SalesOrderHeader] ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = ON)ALTER
TABLE [AdventureWorks].[Sales].[SalesOrderDetail] ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = ON)Changed data in XML
After setting change tracking on a database and tables the change tables are populated with the data change information when data is inserted, deleted or updated on the tables. The data integration service uses the following code block to fetch the change information and create an XML file with the data change. Using CHANGETABLE function it creates change tracking information for the tables, ‘SalesOrderHeader’ and ‘SalesOrderDetail’. The code generates an XML document containing the information using the FOR XML mode. In the XML file the root, top-level element is named with ‘Sales’, and each sales order header corresponds to an element named with ‘SalesOrderHeader’. A ‘SalesOrderHeader’ element contains one or more ‘SalesOrderDetail’ elements which describe the data change information on the table, ‘SalesOrderDetail’. INNER JOIN clauses make sure that all the change data information is retrieved from the tables.
SET
@changeReportXML =(
SELECT
SYS_CHANGE_OPERATION, c_soh.SalesOrderID, ( SELECT SYS_CHANGE_OPERATION, c_sod.SalesOrderID,c_sod
(
CHANGES
[AdventureWorks].[Sales].[SalesOrderDetail],@last_sync_version
)
AS c_sod INNER JOIN [AdventureWorks].[Sales].[SalesOrderDetail] sod ON sod.SalesOrderDetailID = c_sod.SalesOrderDetailID WHERE c_soh.SalesOrderID = c_sod.SalesOrderID FOR XML PATH ('SalesOrderDetail'),type
, ELEMENTS XSINIL ) FROM CHANGETABLE (CHANGES
[AdventureWorks].[Sales].[SalesOrderHeader],@last_sync_version
)
AS c_soh INNER JOIN [AdventureWorks].[Sales].[SalesOrderHeader] soh ON soh.SalesOrderID = c_soh.SalesOrderID WHERE @salesOrderID = c_soh.SalesOrderID FOR XML PATH ('SalesOrderHeader'),root
('Sales'),ELEMENTS XSINIL);
Change notification
SQL Server provides several mechanisms for notifying data change to an application. For example, Trigger [http://msdn.microsoft.com/en-us/library/ms189599.aspx] and Query Notification (QN) [http://msdn.microsoft.com/en-us/library/ms130764.aspx]. Trigger provides a simple way for the notification, while only supporting synchronous mechanism. QN supports asynchronous notification and rich filtering semantics. However QN cannot be configured in TSQL within SQL Server. In the Real Time Data integration demo we use a technique integrating Service Broker and Trigger. It provides a simple way to support event notification implementing asynchronous semantic in TSQL within SQL Server. The following code block shows the event notification on the demo.
CREATE
TABLE ConversationHandle(
conversationHandle uniqueidentifier);--Create a dialog to send all the transactions on
BEGIN
TRANSACTION DECLARE @conversationHandle uniqueidentifier --Create a new conversation on the table BEGIN DIALOG @conversationHandle FROM SERVICE AsynchTriggerInitiatorService TO SERVICE N'AsynchTriggerTargetService' ON CONTRACT [AsynchTriggerContract] WITH ENCRYPTION = OFF; INSERT ConversationHandle (conversationHandle)VALUES
(@conversationHandle)COMMIT
;-- TRIGGER for initiating the change tracking demo
CREATE
TRIGGER ChangeTrackingTriggerON
[AdventureWorks].[Sales].[SalesOrderHeader]AFTER
INSERT, DELETE, UPDATEAS
BEGIN
TRANSACTION; DECLARE @conversationHandle uniqueidentifier; SELECT TOP (1) @conversationHandle = conversationHandleFROM
ConversationHandle; SEND ON CONVERSATION @conversationHandleMESSAGE
TYPE [AsynchTriggerMessageType]COMMIT
;Reliable data movement
Service Broker provides asynchronous and reliable data movement. It supports TSQL programming model built on SQL Server database engine. Please refer to the following link for the detail information about Service Broker [http://technet.microsoft.com/en-us/sqlserver/bb671396.aspx].
The data integration service uses multiple conversations for message delivery to increase throughput. Using multiple dialogs brings the data parallelism on the receiving side. Multiple threads can receive and process the messages in the dialogs independently. However, initiating the conversations brings load to a system. Therefore right amounts of conversations should be chosen smartly. In the real time data integration demo we choose four conversations for processing the messages with high throughput. In the real time data integration service we initiate four dialogs, and store them onto a table. The demo uses the dialogs for sending messages about changed data information. Please refer to the following code block for the dialog creation. The following code blocks present the procedure for sending an XML message using Service Broker. The procedure uses the four conversations evenly distributed messages based on the sales order ID ( SET @dialogHandleID = @salesOrderID % 4) . Because messages for the same sales order ID are delivered in a single conversation it is guaranteed that the messages are delivered exactly once in order manner.
CREATE
PROCEDURE SendChangesAS
BEGIN
DECLARE @last_sync_version bigint; DECLARE @salesOrderID bigint; DECLARE @dialogHandleID INT; DECLARE @dialogHandle uniqueidentifier; DECLARE @changeReportXML XML; DECLARE @next_baseline bigint; DECLARE @TotalDialogs INT; DECLARE @logMsg VARCHAR(MAX); BEGIN TRANSACTION; SELECT TOP (1) @last_sync_version = lastVersionFROM LastVersion;
SET @TotalDialogs = 4; --Create a cursor on the change table for [SalesOrderHeader] DECLARE cursorChangeOrderHeader CURSOR FORWARD_only READ_ONLY FOR SELECT SalesOrderID FROM CHANGETABLE (CHANGES [SalesOrderHeader], @last_sync_version) AS Cursor_CH
ORDER BY SYS_CHANGE_VERSION;
--Open the cursor on the change table for [SalesOrderHeader] --Loop for each changed sales order id OPEN cursorChangeOrderHeader WHILE(1=1) BEGIN FETCH NEXT FROM cursorChangeOrderHeader INTO @salesOrderID; --If there is no more changed sales order then exit IF (@@FETCH_STATUS != 0) BREAK;--<Fetching changed data and creating XML file.>
--<Please refer to the code block on section 2.a.1.>
--Find the conversation handle for the sales order--from the dialog handle table
SET @dialogHandleID = @salesOrderID % @TotalDialogs; SELECT @dialogHandle = dialogHandle FROM DialogHandles WHERE ID = @dialogHandleID; --Capture last version info SELECT @next_baseline = SYS_CHANGE_VERSIONFROM CHANGETABLE (
CHANGES[AdventureWorks].[Sales].[SalesOrderHeader],
@last_sync_version) as c_soh
WHERE @salesOrderID = SalesOrderID;
--Send the message using Broker
SEND ON CONVERSATION @dialogHandleMESSAGE TYPE [RealTimeDImessagetype](@changeReportXML);
END CLOSE cursorChangeOrderHeader; DEALLOCATE cursorChangeOrderHeader; UPDATE LastVersion SET lastVersion = @next_baseline; COMMIT;END
;Activation
Activation allows message processing logic to be launched when a message arrives on a Service Broker queue. When an internal activation is used for processing messages a stored procedure is declared on a Service Broker queue, and invoked on a background thread when a message arrives. A user can also specify an executable for processing the messages as an external activator. For example, SQL Server Integration Services (SSIS) can be used as an external activation procedure to process messages. Please refer to the following link for the code sample and document of External Activator [http://www.codeplex.com/SQLSrvSrvcBrkr/Release/ProjectReleases.aspx?ReleaseId=3853].
In the real time data integration services demo we use internal activators to process event notification messages on the initiator service as well as changed data information messages on the target service. We briefly mention how the services process the messages in the activation procedures.
- Message processing in the initiator
The real time data integration initiator handles messages from two different services. One of the services is an asynchronous event notification service, and the other is a real time data integration target service. A single service in the initiator handles the message from the two different sources based on message types and service names. The following pseudo-code block describes the message processing logic in the initiator.
WHILE
there is any message on ‘RealTime_DI_Initiator_queue’RECEIVE a message FROM the queue
IF message type is ‘EndDialog’ THEN
END CONVERSATION
ELSE IF message type is ‘ERROR’ THEN
IF service name is ‘RealTime_DI_Initiator_Service’ THEN
Raise error;Create a new dialog;
Resend pending messages using the dialog;
Replace old dialog with the new one;
END CONVERSATION (old dialog);
IF service name is ‘Asynchronous_Trigger_Target_Service’ THEN
Raise error;
END CONVERSATION;
ELSE IF message type is ‘Asynchronous triggering’ THEN
RECEIVE
WHERE conversation_handle is identical with this message’s handle
EXEC SendChanges PROCEDURE
The message processing procedure in the real time data integration target receives messages from a target queue, and transforms the messages from the XML format into a supported schema. A simple and straightforward way to process messages is to receive a message from the queue and to transform it one by one until all the messages are processed on the queue. However, the mechanism may hurt the performance of the data integration target. Instead of receiving a single message and transform it the data integration target service uses a cursor-based processing mechanism. It receives all the messages from the target queue, and stores in a temporary table. A cursor iterates the table to fetch a message and process it to covert from an XML format to a desired schema. The following code block shows the activation procedure on the target.
CREATE
PROCEDURE ProcessMessagesDWAS
BEGIN
DECLARE @handle uniqueidentifier; DECLARE @messageBody XML; DECLARE @tableMessages TABLE(queuing_order
BIGINT, conversation_handle UNIQUEIDENTIFIER,message_body
VARBINARY(MAX)); DECLARE cursorMessages CURSORFORWARD_ONLY
READ_ONLY FOR SELECT conversation_handle,message_body
FROM @tableMessages ORDER BY queuing_order; WHILE(1=1) BEGIN BEGIN TRANSACTION; WAITFOR(RECEIVEqueuing_order
, conversation_handle,message_body
FROM [RealTimeDItargetqueue] INTO @tableMessages), TIMEOUT 1000;IF(@@ROWCOUNT = 0) BEGIN COMMIT; BREAK; END OPEN cursorMessages; WHILE(1=1) BEGIN FETCH NEXT FROM cursorMessages INTO @handle, @messageBody; IF(@@FETCH_STATUS != 0)
-- <Message transformation>
END
CLOSE cursorMessages;
DELETE FROM @tableMessages; COMMIT; END DEALLOCATE cursorMessages;END
Data transformation
After receiving messages the target service transforms the received messages, and populates tables with the changed data information from the messages. The received messages are in XML format. The service processes each of the messages to obtain required information from the message using TSQL language coupled with integrated XML support. The following code block shows a sample of the transformation using TSQL. On this example, the transformation is occurred only for the data insert event.
INSERT
INTO [AdventureWorksDW].[dbo].[FactInternetSales]SELECT
N1
.SOH.value('CustomerID[1]', 'int')AS
[CustomerKey] ,N2.SOD.value('SpecialOfferID[1]', 'int')AS [PromotionKey]
,N2.SOD.value('CarrierTrackingNumber[1]','NCHAR(9)')
AS
CarrierTrackingNumber,N1.SOH.value('PurchaseOrderNumber[1]','NVCHAR(25)')
AS
[CustomerPONumber]FROM
@messageBody
.nodes('/Sales/SalesOrderHeader') N1(SOH)CROSS
APPLY soh.nodes('SalesOrderDetail') N2(SOD)WHERE
N1
.SOH.value('CustomerType[1]', 'CHAR') = 'I'AND
N2.SOD.value('SYS_CHANGE_OPERATION[1]','CHAR')='I'SQL Server Integration Services (SSIS) also provides the data transformations. SSIS supports various forms of data transformation between heterogeneous sources. Please refer to the following link for more detail information about SSIS [http://technet.microsoft.com/en-us/sqlserver/bb671392.aspx].
This document discusses about real-time data integration technologies with the coordination of a set of powerful SQL Server technologies. The service provides reliable and transparent data integration between instances. The service is composed with the following technologies.
The complete code list for the demo can be found on the following link [http://www.codeplex.com/SQLSrvSrvcBrkr/Release/ProjectReleases.aspx?ReleaseId=15139].