SQL Server Always On Availability Groups (AG) kurulumu sırasında karşınıza çıkan Distributed Transaction Coordinator (DTC) desteği, özellikle birden fazla veritabanı veya sunucu arasında tutarlılık gerektiren işlemler için kritik bir rol oynar.
Normal şartlarda, bir Always On yapısında “Distributed Transaction” (Dağıtık İşlem) yönetimi karmaşıktır. DTC, atomisiteyi (ACID prensiplerinden Atomicity) sağlar. Yani, bir işlem birden fazla veritabanını veya farklı sunucuları etkiliyorsa; ya tüm işlemler başarıyla tamamlanır ya da bir hata durumunda hepsi geri alınır (rollback).
Neden Seçmelisiniz:
- Cross-Database Transactions: Aynı SQL örneği içindeki farklı veritabanları arasında işlem yapıyorsanız.
- Linked Servers: Farklı sunuculardaki SQL Server’lar arasında veri transferi ve güncelleme yapılıyorsa.
- Microservices: Uygulamanız aynı anda birden fazla DB’ye yazma ihtiyacı duyuyorsa.
Eğer kurulum sihirbazında veya T-SQL ile DTC_SUPPORT = PER_DB seçeneğini işaretlerseniz, sadece SQL üzerinde bir ayar yapmış olmazsınız; Windows seviyesinde de bazı hazırlıklar yapmanız gerekir:
Her cluster düğümünde MSDTC hizmetinin çalışıyor ve ağ üzerinden iletişime açık olması gerekir.
- dcomcnfg komutuyla Component Services’ı açılır.
Gelen ekranda Computers > My Computer > Distributed Transaction Coordinator > Local DTC properties’avgirilir.
Gelen ekranda Security sekmesinde aşağıdaki özelliklerin seçilmesi gerekmektedir.
- Network DTC Access (İşaretli)
- Allow Inbound / Allow Outbound (İşaretli)
- No Authentication Required (Genelde sorunsuz iletişim için tercih edilir)
DTC desteği SQL Server 2016 SP2 ile stabilize olmuştur. Eğer SQL Server 2017 veya 2022 (sizin kullandığınız sürüm gibi) kullanıyorsanız, veritabanı düzeyinde DTC desteğini aktif etmelisiniz.
Örnek Senaryo ile Açıklayalım:
Bir bankacılık uygulamasını düşünün:
- Veritabanı A: Müşteri bakiye bilgileri.
- Veritabanı B: İşlem kayıtları (Log).
Bir havale işlemi sırasında para A veritabanından düşerken, işlem kaydı B veritabanına yazılır. Eğer Always On yapısında DTC seçilmezse ve işlem sırasında bir failover (sunucu değişimi) yaşanırsa, para A’dan düşebilir ama B’ye kayıt yazılmayabilir. DTC, bu iki işlemin “tek bir bütün” olarak yönetilmesini sağlar.
Kurulumdan sonra bir AG’de DTC desteğini kontrol etmek veya değiştirmek isterseniz şu komutu kullanabilirsiniz:
ALTER AVAILABILITY GROUP [AG_ADINIZ]
SET (DTC_SUPPORT = PER_DB);
GODTC Aktif Etmenin Avantajları
1. Veri Bütünlüğü ve Tutarlılık (Atomicity)
En büyük avantajı, “ya hep ya hiç” kuralını garanti etmesidir. Birden fazla veritabanını etkileyen bir işlem (transaction) sırasında sunucu çökse veya Failover gerçekleşse bile, DTC sayesinde veriler askıda kalmaz. Ya tüm düğümlerde commit edilir ya da tamamen geri alınır.
2. Karmaşık Uygulama Desteği
Modern ERP, CRM veya Mikroservis mimarileri genellikle tek bir işlemde birden fazla DB’ye dokunur. DTC aktif olduğunda, yazılımcıların uygulama katmanında karmaşık “hata yönetimi” (error handling) kodları yazmasına gerek kalmaz; SQL Server bu yükü üstlenir.
3. Otomatik Kurtarma (Automatic Recovery)
Failover sonrası “In-doubt” (şüpheli) durumda kalan işlemler, DTC sayesinde otomatik olarak çözümlenir. Manuel olarak KILL komutu kullanmak veya veritabanı tutarlılığını elle kontrol etmek zorunda kalmazsınız.
DTC Aktif Etmenin Dezavantajları
DTC kullanmanın bir bedeli vardır. Bu özellik, doğası gereği sisteme ek yük getirir:
1. Latency (Gecikme) Artışı
DTC, “Two-Phase Commit” (2PC) protokolünü kullanır. Bir işlem tamamlanmadan önce tüm katılımcı birimlerden (DB’ler veya sunucular) “hazır” onayı gelmesi beklenir. Bu çift aşamalı onay mekanizması, işlemin milisaniyeler bazında daha uzun sürmesine neden olur.
2. Kilitlenmeler (Blocking) ve Deadlock Riski
DTC tarafından yönetilen bir işlem ağdaki bir sorun veya gecikme nedeniyle beklemeye girerse, bu işlemle ilgili tüm tablolar ve kayıtlar kilitli (lock) kalır. Bu da diğer kullanıcıların aynı verilere erişmesini engelleyerek sistemde Blocking kuyruklarına yol açabilir.
3. Ağ Trafiği ve RPC Yükü
DTC, düğümler arasında yoğun bir Remote Procedure Call (RPC) trafiği oluşturur. Eğer SQL Server’larınız arasındaki network gecikmesi yüksekse, DTC performansı ciddi şekilde aşağı çeker.
4. Yönetimsel Karmaşıklık
- Firewall: RPC dinamik portlarının ve port 135’in açık olması gerekir.
- Hizmet Bağımlılığı: MSDTC servisi durursa, ona bağlı olan tüm cross-database işlemler hata verir ve durur.
PER_DB ayarı, SQL Server’ın her veritabanı için ayrı bir Transaction ID izlemesini sağlar. Bu, özellikle Always On failover süreçlerinde işlemin yarıda kalmamasını garanti eder.
Eğer uygulamanız sadece tek bir veritabanı üzerinde çalışıyorsa veya veritabanları arası BEGIN DISTRIBUTED TRANSACTION gibi komutlar kullanmıyorsanız, bu özelliği kapalı (None) tutmanız performans açısından en doğrusudur.
Ancak, Always On yapınızda birden fazla DB arasında INSERT/UPDATE yapan tetikleyiciler (triggers) veya Linked Server yapısı varsa, performans kaybını göze alarak DTC_SUPPORT = PER_DB seçeneğini aktif etmelisiniz.
Başka makalede görüşmek dileğiyle..
Kötülüğe iyilikle karşılık verin.Fussilet-34
