In addition to Change Data
Capture, SQL Server 2008 also introduces Change Tracking. Change
Tracking is a lightweight solution that provides an efficient change
tracking mechanism for applications. Although they are similar in name,
the purposes of Change Tracking and Change Data Capture are different.
Change Data Capture is an
asynchronous mechanism that uses the transaction log to record all the
changes to a data row and store them in change tables. All intermediate
versions of a row are available in the change tables. The information
captured is stored in a relational format that can be queried by client
applications such as ETL processes.
Change Tracking, in
contrast, is a synchronous mechanism that tracks modifications to a
table but stores only the fact that a row has been modified and when. It
does not keep track of how many times the row has changed or the values
of any of the intermediate changes. However, having a mechanism that
records that a row has changed, you can check to see whether data has
changed and obtain the latest version of the row directly from the table
itself rather than querying a change capture table.
Note
Unlike Change Data
Capture, which is available only in the Enterprise, Datacenter, and
Developer Editions of SQL Server, Change Tracking is available in all
editions.
Change Tracking operates
by using tracking tables that store a primary key and version number
for each row in a table that has been enabled for Change Tracking.
Applications can then check to see whether a row has changed by looking
up the row in the tracking table by its primary key and see if the
version number is different from when the row was first retrieved.
One of the common uses of Change
Tracking is for applications that have to synchronize data with SQL
Server. Change Tracking can be used as a foundation for both one-way and
two-way synchronization applications.
One-way
synchronization applications, such as a client or mid-tier caching
application, can be built to use Change Tracking. The caching
application, which requires data from a SQL Server database to be cached
in other data stores, can use Change Tracking to determine when changes
have been made to the database tables and refresh the cache store by
retrieving data from the modified rows only to keep the cache
up-to-date.
Two-way synchronization
applications can also be built to use Change Tracking. A typical example
of a two-way synchronization application is the occasionally connected
application—for example, a sales application that runs on a laptop and
is disconnected from the central SQL Server database while the
salesperson is out in the field. Initially, the client application
queries and updates its local data store from the SQL Server database.
When it reconnects with the database later, the application synchronizes
with the database, and data changes will flow from the laptop to the
database and from the database to the laptop. Because data changes
happen in both locations while the client application is disconnected,
the two-way synchronization application must be able to detect
conflicts. A conflict occurs if the same data is changed in both data
stores in the time between synchronizations. The client application can
use Change Tracking to detect conflicts by identifying rows whose
version number has changed since the last synchronization. The
application can implement a mechanism to resolve the conflicts so that
the data changes are not lost.
Implementing Change Tracking
To use Change Tracking, you must
first enable it for the database and then enable it at the table level
for any tables for which you want to track changes. Change Tracking can
be enabled via T-SQL statements or through SQL Server Management Studio.
To enable Change Tracking for
a database in SSMS, right-click on the database in Object Explorer to
bring up the Properties dialog and select the Change Tracking page. To
enable Change Tracking, set the Change Tracking option to True (see Figure 1).
Also on this page, you can configure the retention period for how long
SQL Server retains the Change Tracking information for each data row and
whether to automatically clean up the Change Tracking information when
the retention period has been exceeded.
Change Tracking can also be enabled with the ALTER DATABASE command:
ALTER DATABASE AdventureWorks2008R2
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON)
After enabling Change Tracking
at the database level, you can then enable Change Tracking for the
tables for which you want to track changes. To enable Change Tracking
for a table in SSMS, right-click on the table in Object Explorer to
bring up the Properties dialog and select the Change Tracking page. Set
the Change Tracking option to True to enable Change Tracking (see Figure ). The TRACK_COLUMNS_UPDATED
option specifies whether SQL Server should store in the internal Change
Tracking table any extra information about which specific columns were
updated. Column tracking allows an application to synchronize only when
specific columns are updated. This capability can improve the efficiency
and performance of the synchronization process, but at the cost of
additional storage overhead. This option is set to OFF by default.
Change Tracking can also be enabled via T-SQL with the ALTER TABLE command:
USE [AdventureWorks2008R2]
GO
ALTER TABLE [dbo].[MyCustomer]
ENABLE CHANGE_TRACKING WITH(TRACK_COLUMNS_UPDATED = ON)
Tip
To determine which tables and databases have Change Tracking enabled, you can use the sys.change_tracking_databases and sys.change_tracking_tables catalog views.
