SQL Server Change Tracking: Ne Zaman Kullanılır, Nasıl Açılır, CDC’den Farkı Nedir?

Bir mobil uygulamanın, bir önbelleğin, bir arama indeksinin ya da bir veri ambarının SQL Server’daki değişiklikleri takip etmesi gerektiğinde ilk akla gelen çözüm genellikle trigger’lar, UpdatedAt kolonları ve el yapımı log tablolarıdır. SQL Server’ın bu iş için yerleşik ve hafif bir özelliği vardır: Change Tracking. Doğru senaryoda trigger’lardan çok daha az kodla ve daha güvenilir şekilde “son senkronizasyondan beri hangi satırlar değişti?” sorusunu yanıtlar.

Bu rehberde Change Tracking’in ne kaydettiğini ve ne kaydetmediğini, Change Data Capture’dan farkını, nasıl açılacağını, güvenilir bir senkronizasyon sorgusunun nasıl yazılacağını ve üretimde dikkat edilmesi gereken noktaları anlatıyoruz.

Change Tracking Ne Kaydeder?

Change Tracking, bir tabloda hangi satırın değiştiğini ve değişikliğin türünü (insert, update, delete) kaydeder. Değişen satırı primary key değeriyle tanımlar; satırın yeni hâlini almak için uygulama bu anahtarla kaynak tabloya join yapar. İsteğe bağlı olarak bir update’te hangi kolonların değiştiği de kaydedilebilir.

Change Tracking şunları kaydetmez:

• Satırın eski değerlerini ya da ara değerlerini.
• Bir satırın iki senkronizasyon arasında kaç kez değiştiğini; yalnızca değiştiğini.
• Değişikliği kimin yaptığını.

Bir kolonu aynı değere set eden bir UPDATE bile değişiklik olarak kaydedilir.

Change Tracking mi, CDC mi, Temporal Table mı?

Kısacası; “son senkronizasyondan beri ne değişti, en güncel hâli ver” yeterliyse Change Tracking, her değişikliğin değerlerine ihtiyaç varsa CDC, satırın geçmişte belirli bir andaki hâli gerekiyorsa temporal table doğru araçtır.

Change Tracking Nasıl Açılır?

Önce veritabanı düzeyinde, ardından izlenecek her tablo için açılır:

ALTER DATABASE SatisDB
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

ALTER TABLE dbo.Musteri
ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = ON);

-- Tutarlı senkronizasyon için snapshot isolation
ALTER DATABASE SatisDB SET ALLOW_SNAPSHOT_ISOLATION ON;

CHANGE_RETENTION, değişiklik bilgisinin ne kadar süre tutulacağını belirler. Bu süre, en uzun senkronizasyon aralığınızdan, istemcilerin çevrimdışı kalabileceği en uzun süre de hesaba katılarak, daha uzun olmalıdır. TRACK_COLUMNS_UPDATED, hangi kolonların değiştiğini de kaydeder ama ek alan kullanır; yalnızca gerçekten ihtiyaç varsa açın.

Güvenilir Bir Senkronizasyon Sorgusu

Senkronizasyon yapan uygulama, her çalışmada bir sonraki sefere kullanacağı versiyon numarasını saklar. Doğru kalıp üç şeyi birlikte yapar: işlemi snapshot isolation içinde çalıştırır, son versiyonun hâlâ geçerli olduğunu kontrol eder ve değişiklikleri kaynak tabloyla birleştirir:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN;

DECLARE @last_sync bigint = 1500;   -- uygulamanın sakladığı son versiyon
DECLARE @current   bigint = CHANGE_TRACKING_CURRENT_VERSION();

IF @last_sync < CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID(N'dbo.Musteri'))
BEGIN
    -- Değişiklik bilgisi temizlenmiş: tam yeniden yükleme gerekir
    SELECT N'FULL_RELOAD' AS action;
END
ELSE
BEGIN
    SELECT ct.MusteriId, ct.SYS_CHANGE_OPERATION, m.Ad, m.Sehir
    FROM CHANGETABLE(CHANGES dbo.Musteri, @last_sync) AS ct
    LEFT JOIN dbo.Musteri AS m ON m.MusteriId = ct.MusteriId;   -- silinen satırlar NULL döner
END

SELECT @current AS next_sync_version;   -- uygulama bunu saklar
COMMIT;

Snapshot isolation, versiyonu okuduğunuz an ile değişiklikleri okuduğunuz an arasında gelen yeni işlemlerin sonucu karıştırmasını önler.

Üretimde Dikkat Edilmesi Gerekenler

• Senkron ek yük: Change Tracking bilgisi, DML işleminin kendisiyle aynı transaction içinde yazılır. Çok yoğun yazma alan tablolarda bu ek yükü test edin.
• İç tablolar büyüyebilir: Her izlenen tablonun bir iç (side) tablosu ve veritabanı genelinde bir commit tablosu vardır. Otomatik temizlik geride kalırsa bu tablolar büyür ve sorgular yavaşlar.
• Manuel temizlik: Otomatik temizliğin yetişemediği durumlar için sys.sp_flush_CT_internal_table_on_demand prosedürü vardır.
• Kısa retention, uzun kesinti: Retention’ı kısa tutmak alanı korur ama uzun süre çevrimdışı kalan istemcileri tam yüklemeye zorlar. İkisi arasında bilinçli bir denge kurun.

İç tabloların boyutunu izlemek için:

SELECT OBJECT_NAME(it.parent_object_id) AS tracked_table,
       it.name AS internal_table,
       SUM(ps.row_count) AS row_count,
       SUM(ps.reserved_page_count) * 8 / 1024.0 AS reserved_mb
FROM sys.internal_tables AS it
JOIN sys.dm_db_partition_stats AS ps ON ps.object_id = it.object_id
WHERE it.internal_type_desc = N'CHANGE_TRACKING'
GROUP BY it.parent_object_id, it.name
ORDER BY reserved_mb DESC;

Hangi Tablolarda Açık? Nasıl Kapatılır?

-- Change Tracking açık veritabanları ve tablolar
SELECT DB_NAME(database_id) AS database_name, is_auto_cleanup_on,
       retention_period, retention_period_units_desc
FROM sys.change_tracking_databases;

SELECT OBJECT_SCHEMA_NAME(object_id) + N'.' + OBJECT_NAME(object_id) AS table_name,
       is_track_columns_updated_on
FROM sys.change_tracking_tables;

-- Kapatmak: önce tablolar, sonra veritabanı
ALTER TABLE dbo.Musteri DISABLE CHANGE_TRACKING;
ALTER DATABASE SatisDB SET CHANGE_TRACKING = OFF;

Kontrol Listesi

• İhtiyaç “hangi satır değişti” ise Change Tracking, “hangi değerler değişti” ise CDC seçildi.
• İzlenen tabloların primary key’i var.
• Retention süresi en uzun senkronizasyon aralığından uzun.
• Senkronizasyon snapshot isolation içinde çalışıyor ve MIN_VALID_VERSION kontrol ediliyor.
• İç tabloların boyutu ve otomatik temizlik izleniyor.