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 ].
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]
WITH (TRACK_COLUMNS_UPDATED = ON)
ALTER TABLE [AdventureWorks].[Sales].[SalesOrderDetail]
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,
) 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 (
) AS c_soh
INNER JOIN [AdventureWorks].[Sales].[SalesOrderHeader] soh
ON soh.SalesOrderID = c_soh.SalesOrderID
WHERE @salesOrderID = c_soh.SalesOrderID
FOR XML PATH ('SalesOrderHeader'),
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
--Create a dialog to send all the transactions on
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)
-- TRIGGER for initiating the change tracking demo
CREATE TRIGGER ChangeTrackingTrigger
AFTER INSERT, DELETE, UPDATE
DECLARE @conversationHandle uniqueidentifier;
SELECT TOP (1) @conversationHandle = conversationHandle
SEND ON CONVERSATION @conversationHandle
MESSAGE TYPE [AsynchTriggerMessageType]
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 SendChanges
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);
SELECT TOP (1) @last_sync_version = lastVersion
SET @TotalDialogs = 4;
--Create a cursor on the change table for [SalesOrderHeader]
CURSOR FORWARD_only READ_ONLY
FOR SELECT SalesOrderID FROM
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
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
WHERE ID = @dialogHandleID;
--Capture last version info
SELECT @next_baseline = SYS_CHANGE_VERSION
FROM CHANGETABLE (
@last_sync_version) as c_soh
WHERE @salesOrderID = SalesOrderID;
--Send the message using Broker
SEND ON CONVERSATION @dialogHandle
MESSAGE TYPE [RealTimeDImessagetype](@changeReportXML);
UPDATE LastVersion SET lastVersion = @next_baseline;
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.
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
ELSE IF message type is ‘ERROR’ THEN
IF service name is ‘RealTime_DI_Initiator_Service’ THEN
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
END CONVERSATION ;
ELSE IF message type is ‘Asynchronous triggering’ THEN
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 ProcessMessagesDW
DECLARE @handle uniqueidentifier;
DECLARE @messageBody XML;
DECLARE @tableMessages TABLE(
DECLARE cursorMessages CURSOR
FOR SELECT conversation_handle,
ORDER BY queuing_order;
INTO @tableMessages), TIMEOUT 1000;
IF(@@ROWCOUNT = 0)
FETCH NEXT FROM cursorMessages
INTO @handle, @messageBody;
IF(@@FETCH_STATUS != 0)
-- <Message transformation>
DELETE FROM @tableMessages;
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]
CROSS APPLY soh.nodes('SalesOrderDetail') N2(SOD)
N1.SOH.value('CustomerType', '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.
Data tracking: Change tracking
Change notification: Triggers and Service Broker
Reliable data movement: Service Broker
Activation: Internal, Blocking with WAITFOR RECEIVE
Transformation: TSQL with XML support
The complete code list for the demo can be found on the following link [ http://www.codeplex.com/SQLSrvSrvcBrkr/Release/ProjectReleases.aspx?ReleaseId=15139 ].
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.