- 01Row count yalnız toplam satır sayısını doğrular; veri değerlerinin doğru taşındığını kanıtlamaz.
- 02Cross-engine checksum karşılaştırmasında NULL, timestamp, decimal, encoding ve string representation iki tarafta da aynı şekilde normalize edilmelidir.
- 03Büyük tablolar tek global hash yerine primary-key range, partition veya batch bazında doğrulanmalıdır.
- 04CDC sırasında replication progress ile validation progress ayrı izlenmeli; final write freeze sonrasında son karşılaştırma yapılmalıdır.
- 05Teknik validation business-level reconciliation ve kritik application transaction testleriyle birlikte tamamlanmalıdır.
Kısaca
CDC tabanlı database migration'da veri doğrulama, yalnız satır sayısı eşit mi kontrolü değildir. Production seviyesinde güvenli doğrulama için row count, checksum/hash, alan bazlı karşılaştırma, referential integrity, business-level reconciliation ve kritik transaction testleri birlikte kullanılmalıdır.
Dynamis Teknoloji'de doğrulamayı üç aşamada ele alıyoruz:
- Full load sonrası baseline
- CDC sırasında sürekli fark takibi
- Final write freeze sonrasında cutover validation
Amaç, hedef veritabanının yalnız dolmuş olduğunu değil, iş açısından doğru ve kullanılabilir durumda olduğunu kanıtlamaktır.
Neden row count tek başına yeterli değildir?
Kaynak ve hedefte aynı sayıda satır olması veri değerlerinin doğru taşındığını kanıtlamaz.
Örneğin her iki tarafta da 1.000.000 satır olabilir fakat:
- bazı tarih alanları timezone nedeniyle kaymış olabilir,
- decimal scale farklı olabilir,
- NULL değerler default değere dönüşmüş olabilir,
- string encoding farkı oluşmuş olabilir,
- boolean alanlar farklı normalize edilmiş olabilir,
- bazı kolonlar truncate edilmiş olabilir,
- computed/generated alanlar farklı hesaplanmış olabilir.
Bu nedenle row count yalnız ilk seviye sağlık kontrolüdür.
Doğrulama katmanları
1. Row count
Her kritik tabloda kaynak ve hedef satır sayısını karşılaştırın. Bu kontrol hızlıdır ve büyük farkları hemen gösterir; fakat eşit row count, verinin doğru olduğu anlamına gelmez.
2. Checksum veya hash
Belirli kolonları normalize edip deterministik bir representation üzerinden hash üretin. Aynı kolon sırası ve aynı normalization ile iki tarafta hash üretildiğinde veri değerlerinin eşleşip eşleşmediği daha güçlü biçimde görülebilir.
3. Field-level comparison
Özellikle kritik business alanlarında gerçek value comparison çalıştırın: müşteri bakiyesi, sipariş toplamı, invoice status, payment reference veya subscription state gibi.
4. Referential integrity
Foreign key constraint olmasa bile orphan kayıtları kontrol edin.
5. Business reconciliation
Teknik karşılaştırmanın yanında iş seviyesinde özet metrikleri karşılaştırın: aktif müşteri sayısı, açık invoice toplamı, günlük order sayısı veya toplam bakiye gibi.
6. Application transaction testleri
Gerçek uygulama akışlarını hedef database üzerinde çalıştırın: login, kayıt oluşturma, güncelleme, rapor, ödeme veya faturalama gibi.
Checksum nedir?
Checksum veya hash, bir veri setinin deterministik özetini üretir. Pratikte SHA-256 gibi güçlü hash algoritmaları tercih edilebilir. Ancak önemli nokta algoritmadan önce aynı verinin iki motorda aynı şekilde normalize edilmesidir.
SQL Server ve PostgreSQL arasında neden aynı veri farklı hash üretebilir?
Cross-engine migration'da bunun yaygın nedenleri şunlardır:
- character encoding,
- NULL representation,
- trailing spaces,
- decimal precision ve scale,
- timestamp ve timezone formatı,
- boolean representation,
- binary serialization.
Bu nedenle cross-engine hash karşılaştırmasından önce canonical bir format tanımlanmalıdır.
Canonical representation nasıl tasarlanır?
- Kolon sırasını sabitleyin.
- NULL için sabit marker kullanın.
- Tarih/saat alanlarını UTC ve tek formata normalize edin.
- Decimal alanları sabit scale ile formatlayın.
- Boolean değerleri tek forma indirin.
- String encoding'i tek forma indirin.
- Delimiter ve escape kuralını iki tarafta aynı uygulayın.
- Sonuç üzerinde aynı hash algoritmasını çalıştırın.
Tek bir global checksum yeterli mi?
Genellikle hayır. Bütün tablo için tek checksum üretmek fark olduğunu gösterebilir ama farkın nerede olduğunu söylemez.
Daha iyi yaklaşım:
- primary-key range,
- partition,
- tarih aralığı,
- logical shard,
- batch
bazında checksum üretmektir.
Büyük tablolar nasıl doğrulanmalı?
Milyarlarca satırı tek sorguda hashlemek source ve target üzerinde ciddi yük oluşturabilir.
Büyük tablolarda şu sıra daha verimlidir:
- Row count
- Min/max primary key
- Batch count
- Batch checksum
- Fark çıkan batch'te field comparison
Ayrıca validation query'lerinin CPU, disk I/O, replication lag ve lock davranışına etkisi izlenmelidir.
Random sampling yeterli mi?
Hayır. Random sample hızlı sanity check için faydalıdır ancak nadir bozulmaları kaçırabilir. Final validation sistematik range/hash veya business-level reconciliation ile desteklenmelidir.
Full load sonrası ne doğrulanmalı?
- table count
- row count
- schema completeness
- index state
- nullability
- default values
- sequence/identity
- büyük tablo batch checksum
- failed table
- truncated value
Bu aşamada bulunan hata CDC başlamadan veya cutover'a yaklaşmadan çözülmelidir.
CDC sırasında validation nasıl yapılır?
CDC aktifken veri sürekli değiştiği için iki sistem tam aynı anda compare edilmeyebilir. AWS DMS gibi araçlar source ve target verisini karşılaştırabilir ve mismatch durumlarını raporlayabilir. Ancak aktif write trafiği devam ederken transient mismatch ve validation lag görülebilir.
Bu yüzden validation metriğini replication lag ile birlikte okuyun.
Validation lag nedir?
CDC task hedefe veriyi uygulamış olabilir ancak validation process henüz aynı noktaya gelmemiş olabilir.
Bu nedenle iki ayrı ilerleme vardır:
- replication progress
- validation progress
Cutover öncesi validation backlog'unun da kabul edilen seviyeye gelmesi gerekir.
Final write freeze sonrası ne yapılmalı?
Final cutover öncesi bütün writer'lar durdurulduğunda en güvenilir karşılaştırma penceresi oluşur.
Bu aşamada:
- Replication lag kabul edilen sınırda olmalı.
- Validation lag kapanmalı.
- Kritik tablo row count eşleşmeli.
- Kritik batch hash eşleşmeli.
- Referential integrity kontrolü geçmeli.
- Business totals eşleşmeli.
- Sequence/identity state doğrulanmalı.
- Kritik transaction testleri hazır olmalı.
Referential integrity neden ayrıca kontrol edilmeli?
Heterojen migration'da foreign key'ler geçici olarak disable edilmiş olabilir. Bu durumda child row taşınmış fakat parent row eksik kalmış olabilir. Orphan invoice item, order, user role veya lookup kayıtları ayrıca kontrol edilmelidir.
Sequence ve identity doğrulaması
Target'ta row count doğru olsa bile sequence/identity state yanlış olabilir. Örneğin max ID 5.000.000 iken next sequence 4.000.000 ise ilk yeni insert duplicate key üretebilir.
Final validation'da source current identity, target max key ve target sequence next value karşılaştırılmalıdır.
Timestamp ve timezone nasıl doğrulanmalı?
Cross-engine migration'da tarih/saat alanları sık hata üretir. UTC/local time, offset, fractional seconds ve application serialization davranışı kontrol edilmelidir.
Decimal ve finansal alanlar
Finansal migration'da precision, scale, rounding ve aggregate total birlikte doğrulanmalıdır. Business reconciliation için toplam bakiye veya invoice total gibi özetler faydalıdır; ancak batch veya tarih bazlı karşılaştırma daha güvenlidir.
Text ve collation farkları
SQL Server collation ile PostgreSQL locale/collation davranışları farklı olabilir. Migration sonrası case-insensitive arama, Türkçe I/İ, accent, sort order ve unique constraint davranışları application testlerinde kontrol edilmelidir.
Soft delete ve status alanlarını unutmayın
Bazı sistemler fiziksel delete yerine is_deleted, active, status veya archived_at gibi alanlar kullanır. Row count eşit olsa bile business active count farklı olabilir.
Hangi tablolar öncelikli doğrulanmalı?
Tier 1 — Business critical
- payment
- invoice
- order
- customer
- authentication
- entitlement
Tier 2 — Operational
- audit
- queue state
- job state
- reporting base tables
Tier 3 — Rebuildable
- cache
- temp
- derived analytics
Validation effort risk bazlı dağıtılmalıdır.
Mismatch bulunursa ne yapılmalı?
Önce farkı lokalize edin:
- Hangi tablo?
- Hangi PK range?
- Row missing mi, value mismatch mi?
- Source ve target timestamp ne?
- CDC event uygulanmış mı?
- Transformation rule etkisi var mı?
- Data type conversion mı?
- Application write devam etmiş mi?
Sonra selective reload, batch resync, transformation fix veya manual reconciliation uygulanabilir.
Validation query'leri versiyonlanmalı mı?
Evet. Her kontrol için query, expected result, owner, runtime, source/target output ve pass/fail sonucu proje dosyasının parçası olmalıdır.
Otomatik validation ile manuel validation arasındaki fark
Migration araçları teknik consistency için değerlidir. Ancak bir aracın invoice toplamının business beklentisiyle eşleşip eşleşmediğini veya login akışının doğru çalıştığını bilmesi mümkün değildir.
Final kabul şu iki katmanı birlikte içermelidir:
- otomatik teknik validation
- business/application validation
SQL Server → PostgreSQL özelinde neye dikkat edilmeli?
SQL Server'dan PostgreSQL'e geçiş rehberi içindeki şu noktalar validation planına dahil edilmelidir:
- identity/sequence
- datetime/datetimeoffset
- money/numeric
- bit/boolean
- uniqueidentifier/uuid
- computed/generated columns
- T-SQL logic
- trigger
- collation
CDC cutover ile validation nasıl bağlanır?
Database Cutover: CDC ile Planlı Geçiş sürecinde doğru sıra şöyledir:
- Full load
- Baseline validation
- CDC
- Continuous validation
- Write freeze
- Final replication catch-up
- Final validation
- Connection switch
- Application smoke test
- Observation / rollback decision
Dynamis'te veri doğrulama yaklaşımı
Dynamis'in Database Migration hizmetinde validation planını migration başlamadan önce tanımlarız.
Discovery sırasında:
- kritik tablolar,
- primary key yapısı,
- business totals,
- referential dependencies,
- acceptable mismatch,
- transaction criticality,
- verification runtime
çıkarılır.
Ardından automated row/table validation, batch checksum, business reconciliation ve critical transaction test kombinasyonu hazırlanır.
Amaç migration aracının completed yazması değil, business verisinin gerçekten doğru hedefe taşındığını kanıtlamaktır.
Sık yapılan hatalar
Row count eşitse tamam demek: Value corruption veya conversion hatasını kaçırabilir.
Cross-engine hash'te raw string kullanmak: Format ve encoding farkları false mismatch üretir.
Bütün tabloyu tek hash ile kontrol etmek: Farkın nerede olduğunu bulmayı zorlaştırır.
Validation sorgularıyla production'ı yavaşlatmak: Batch ve düşük yük penceresi kullanın.
CDC aktifken transient mismatch'i permanent hata sanmak: Validation lag ve transaction timing'i kontrol edin.
Business totals kontrol etmemek: Teknik olarak eşleşen data iş açısından yanlış olabilir.
Final write freeze sonrası validation yapmamak: En güvenilir compare penceresini kaçırırsınız.
Sırada ne var
- Database Cutover: CDC ile Planlı Geçiş
- SQL Server'dan PostgreSQL'e geçiş
- Cloud Migration Checklist
- Database migration hizmeti
Kaynaklar
Kaynaklar
- 1.AWS DMS data validationAmazon Web Services · 2026-09-25
- 2.Monitoring AWS DMS tasksAmazon Web Services · 2026-09-25
- 3.HASHBYTES (Transact-SQL)Microsoft Learn · 2026-09-25
- 4.PostgreSQL pgcrypto digest functionsPostgreSQL Global Development Group · 2026-09-25
Sık sorulan sorular
Database migration doğrulamasında row count tek başına yeterli mi?
Hayır. Row count yalnız kaynak ve hedefte toplam satır sayısının eşleşip eşleşmediğini gösterir. Aynı sayıda satır olsa bile kolon değerleri, NULL/default davranışı, timezone dönüşümü, numeric precision veya character encoding yanlış taşınmış olabilir. Bu nedenle row count; checksum/hash, alan bazlı karşılaştırma, referential integrity ve kritik iş transaction testleriyle birlikte kullanılmalıdır.
Checksum ile database migration verisi nasıl doğrulanır?
Kaynak ve hedefte aynı normalize edilmiş kolon seti aynı hash algoritmasıyla işlenir ve sonuçlar karşılaştırılır. Karşılaştırma yapılırken kolon sırası, NULL temsili, tarih/saat formatı, decimal precision, character encoding ve delimiter kullanımı iki tarafta da aynı olmalıdır. Büyük tablolarda tek bir global hash yerine primary-key aralıkları veya partition bazlı hash üretmek, farkı lokalize etmeyi kolaylaştırır.
SQL Server ve PostgreSQL arasında aynı checksum neden farklı çıkabilir?
Aynı görünen değerler motorlar arasında farklı byte dizilerine dönüşebilir. String encoding, collation, trailing space, NULL gösterimi, timestamp formatı, timezone, decimal scale, boolean ve binary değerlerin serialize edilme şekli hash sonucunu değiştirebilir. Bu nedenle cross-engine validation için önce canonical bir representation tanımlanmalı ve iki tarafta da aynı normalization uygulanmalıdır.
Büyük tablolarda veri doğrulama nasıl yapılmalı?
Milyarlarca satırlık tabloda tek sorguyla tüm tabloyu hashlemek kaynak ve hedef üzerinde gereksiz yük yaratabilir. Doğrulamayı primary-key aralığı, partition, tarih dilimi veya kontrollü batch'lere bölün. Önce row count ve range bazlı özetleri karşılaştırın; fark görülen segmentlerde daha ayrıntılı hash veya alan karşılaştırması çalıştırın. Validation sorgularının production yüküne etkisi ayrıca izlenmelidir.
CDC sırasında veri doğrulama ne zaman yapılmalı?
İlk full load sonrasında baseline doğrulama yapılmalı, CDC devam ederken mismatch ve validation lag izlenmeli, final cutover öncesi write freeze sonrasında son doğrulama çalıştırılmalıdır. Kaynak hâlâ aktif olarak değişirken tüm tabloyu aynı anda karşılaştırmak tutarsız snapshot üretebilir; bu nedenle kullanılan aracın validation semantics'i ve transaction consistency modeli bilinmelidir.