# SQL Server Replikasyon Ortamında Değişiklik Yönetimi

Replikasyon yapısı olan bir ortamda veritabanı değişikliği yapmak standart ortamdan çok daha karmaşık. Yanlış yapılan bir değişiklik hem publisher hem subscriber'ı etkiler, replikasyonu durdurabilir ve veri tutarsızlığına yol açabilir.

Replikasyon Türleri ve Değişiklik Riski Snapshot Replikasyon Periyodik olarak tüm veri kopyalanır. Değişiklik yönetimi açısından en az riskli. Ama schema değişikliği snapshot döngüsünü etkileyebilir. Transactional Replikasyon Publisher'daki her DML değişikliği distribution database üzerinden subscriber'a iletilir. Bu ortamda schema değişikliği en dikkatli yönetilmesi gereken senaryo. Merge Replikasyon Her iki taraf da değişiklik yapabilir. Çakışma yönetimi zaten karmaşık. Üzerine bir de schema değişikliği eklendiğinde risk katlanır.

Transactional Replikasyon'da Schema Değişikliği Transactional replikasyonda publisher'a yapılan DDL değişikliklerinin subscriber'a da uygulanması gerekir. SQL Server bunu otomatik olarak replike eder ama dikkat edilmesi gereken noktalar var. sql-- Replikasyon durumunu kontrol et SELECT pub.name AS YayinAdi, art.name AS NesneAdi, sub.subscriber\_db AS AboneVeritabani, sub.subscription\_type AS AboneTipi, msd.distributor AS DagiticiSunucu FROM syspublications pub JOIN sysarticles art ON pub.pubid = art.pubid JOIN syssubscriptions sub ON art.artid = sub.artid CROSS JOIN msdb.dbo.MSdistpublishers msd; sql-- Replikasyon log reader gecikmesini kontrol et SELECT agent\_id, start\_time, time, comments, runstatus FROM distribution..MSlogreader\_history WHERE time > DATEADD(HOUR, -1, GETDATE()) ORDER BY time DESC;

Replikasyonlu Ortamda Değişiklik Öncesi Kontroller

1.  Replikasyon sağlığını doğrulayın Değişiklik öncesinde replikasyonun sağlıklı çalıştığından emin olun. Bekleyen işlemler, gecikme, hata durumu varsa önce bunlar çözülmeli.
    
2.  Değişikliğin replike edilip edilmeyeceğini belirleyin Tüm DDL değişiklikleri otomatik replike edilmez. Örneğin bazı index değişiklikleri subscriber'a yansımaz. Bu ayrımı önceden bilmek gerekir.
    
3.  Subscriber'da da değişiklik gerekiyor mu? Bazı durumlarda subscriber'da manuel müdahale gerekir. Bu adım deployment planına dahil edilmeli.
    

Değişiklik Sonrası Doğrulama sql-- Subscriber ile publisher arasındaki satır sayısı karşılaştırması -- Publisher'da SELECT COUNT(\*) AS PublisherSatirSayisi FROM dbo.HedefTablo;

\-- Subscriber'da aynı sorguyu çalıştırın -- SELECT COUNT(\*) AS SubscriberSatirSayisi FROM dbo.HedefTablo; Deployment sonrası en az 15 dakika replikasyon gecikmesini ve hata loglarını izleyin.

Replikasyonu Durdurma Kararı Bazı schema değişiklikleri için replikasyonu geçici durdurmak gerekebilir. Bu karar deployment planında açıkça belirtilmeli: durdurulacak mı, ne kadar süre, yeniden başlatma adımları neler? Bu karar değişiklik yönetim onay sürecinin bir parçası olmalı.

Sonuç Replikasyon ortamlarında değişiklik yönetimi ek kontroller ve koordinasyon gerektirir. Publisher, distribution ve subscriber'ın tamamı deployment planında yer almalı. Detaylı bilgi için: sqlchangeguard.com