SQL Server Replikasyon Ortamında Değişiklik Yönetimi
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
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
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.
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.
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