Skip to main content
Change tracking records which rows changed, by primary key, and the operation. Artie then reads each changed row’s current values from the table. Use this method only if you can’t enable CDC capture instances.

What you’ll need

  • SQL Server 2012 and later, or Azure SQL Managed Instance, or Amazon RDS for SQL Server
  • A service account with SELECT and VIEW CHANGE TRACKING on each replicated table
  • Change tracking enabled on the database and on each table you replicate
  • A primary key on each replicated table. Primary keys override isn’t supported with change tracking.

What change tracking captures

Change tracking tells Artie that a row changed, not how. For each poll, Artie gets one change per primary key:
  • Inserts and updates carry the row’s values at the time Artie reads it, not at the time of the change. If a row was updated three times between polls, the destination gets only the last version.
  • Deletes carry only the primary key.
  • The event timestamp is when Artie read the change, not when it was committed.
  • Rows deleted right after a change can arrive first as an update with only the primary key set and every other column NULL. The delete follows on the next poll.
If you need every intermediate change or before values, use capture instances.

Setup

1

Create a service account

Grant VIEW CHANGE TRACKING on each replicated table. See Microsoft’s change tracking security requirements.
2

Enable change tracking on the database

Set the retention to cover the longest time your pipeline could be paused or down. We recommend 7 days.
If change tracking isn’t enabled on the database, the pipeline stops with change tracking is not enabled on database "ANALYTICS", run: ALTER DATABASE [ANALYTICS] SET CHANGE_TRACKING = ON. Run the statement above.
If the pipeline is stopped for longer than the retention period, the changes it hadn’t read yet are cleaned up. When it starts again, Artie continues from the oldest version still available and logs persisted sync version is older than minValidVersion, resetting to minValidVersion. Changes in between aren’t replicated. Trigger a backfill of the affected tables to fix the destination.
3

Enable change tracking on each table

If any selected table doesn’t have change tracking, the pipeline stops with change tracking is not enabled on tables [<tables>], run ALTER TABLE <table> ENABLE CHANGE_TRACKING for each. The message lists every selected table that’s missing it. Run the statement above for each one.
4

Enter the connection in Artie

In Source, enter the Host, Port (default 1433), Username, Password and database. Under Replication method, select Change tracking.If you use an Always On availability group, enter the listener as the host. See High availability and failover.

Advanced

  • Every 2.5 seconds (Poll interval (ms)), Artie checks CHANGE_TRACKING_CURRENT_VERSION(). If it has moved, Artie reads each table with CHANGETABLE(CHANGES …) from the last version it saved, joined to the table on the primary key.
  • Artie reads up to 10 tables at once (Concurrency), with up to 10 idle connections kept open (Max idle connections).
  • Artie saves each table’s version only after every table in the poll has been written to its Kafka buffer. If the pipeline restarts, it replays from the saved versions, so some changes can arrive twice. The destination merges on the primary key, so the result is the same.
Artie reads the table’s columns when the pipeline starts. A column added later isn’t replicated until the pipeline restarts. Redeploy the pipeline after you add a column.
To check how much space change tracking uses for a table, see Microsoft’s change tracking cleanup and troubleshooting guide.

Limitations

  • Intermediate updates and before values aren’t captured. See What change tracking captures.
  • Primary keys override isn’t supported. Artie joins on the table’s real primary key.
  • If the pipeline is down longer than the change tracking retention period, the cleaned-up changes are lost. Backfill the affected tables.