Veritabanı yöneticileri genellikle Primary sunucudaki sorgu performansına odaklansalar da, Secondary replikalardaki veri tutarlılığı ve raporlama performansı tamamen Redo Process hızına bağlıdır. Redo Thread Blocking, verinin ikincil sunucuya ulaşmasına rağmen, veritabanına fiziksel olarak yazılmasının engellendiği kritik bir durumdur.
Primary sunucuda gerçekleşen her işlem (INSERT, UPDATE, DELETE) işlem günlüğüne (Transaction Log) kaydedilir ve Secondary replikaya gönderilir. Secondary tarafta bu log kayıtlarını okuyup veri sayfalarına uygulayan yapıya Redo Thread denir.
Normal şartlarda bu işlem asenkron veya senkron olarak hızla akar. Ancak, ikincil sunucu sadece bir “depo” değil, aynı zamanda “Read-Only” bir raporlama kaynağı olarak kullanılıyorsa, Redo Thread ile kullanıcı sorguları arasında bir çatışma başlar.
Redo Thread Blocking’in en yaygın sebebi Resource Contention (Kaynak Çatışması) dır. İkincil replika “Readable” (Okunabilir) moddayken, bir kullanıcı uzun süreli bir rapor çalıştırdığında, bu sorgu belirli veri sayfaları üzerinde Shared (S) Lock tutar. Redo Thread ise bu verileri güncellemek için bir Exclusive (X) Lock talep ettiğinde, kullanıcı sorgusunun bitmesini beklemek zorunda kalır.
Bu durum, Redo Lags (Yeniden İşleme Gecikmesi) oluşturur. Sonuç olarak Primary sunucuda commit edilen veri, Secondary sunucuda dakikalarca görünmeyebilir.
Bir veritabanında redo işleminin tıkandığını anlamak için standart sp_who2 veya sp_whoIsactive yeterli olmaz. Daha derinlemesine DMV (Dynamic Management Views) sorgularına ihtiyaç vardır.
Eğer sisteminizde yoğun miktarda REDO_THREAD_PENDING_WORK veya DIRTY_PAGE_TABLE_LOCK bekleme türleri görüyorsanız, redo mekanizması bir yerlere takılıyor demektir.
Aşağıdaki sorgu, ikincil replikada redo işlemini hangi oturumun (Session) engellediğini net bir şekilde gösterir:
SELECT
er.session_id AS BlockingSessionID,
er.start_time,
er.wait_type,
er.command,
est.text AS QueryText
FROM sys.dm_exec_requests er
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) est
WHERE er.command = 'DB STARTUP' -- Redo thread genellikle bu komutla görünür
OR er.wait_type LIKE 'REDO%';
Performance Monitor ile takip edilebilir. SQLServer:Database Replica -> Redo Bytes Remaining sayacının sürekli artması, verinin geldiğini ancak işlenemediğini (yani blocklandığını) gösteren en büyük kanıttır.
Bu sorunla karşılaştığınızda uygulayabileceğiniz stratejik çözüm yolları şunlardır:
1. Snapshot Isolation Seviyesini Zorunlu Kılın: SQL Server, Readable Secondary replikalarda okuma işlemlerini otomatik olarak Mapping to Snapshot moduna çeker. Ancak bazen karmaşık sorgular veya geçici tablolar bu mekanizmayı zorlayabilir. Sorgularınızın SET TRANSACTION ISOLATION LEVEL SNAPSHOT altında çalıştığından emin olun.
2. Uzun Süren Raporları Optimize Edin: Redo thread tek bir iş parçacığı (veya sınırlı sayıda paralel thread) olarak çalışırken, devasa bir SELECT sorgusu binlerce sayfayı kilitleyebilir. İkincil replikadaki eksik indeksleri tamamlamak, redo üzerindeki baskıyı azaltır.
3. Kill/Disconnect Stratejisi: Kritik sistemlerde RPO (Recovery Point Objective) hedefleri raporlama performansından daha önemlidir. Eğer Redo Lag kabul edilemez düzeye gelirse, engelleyen kullanıcı oturumunu KILL <session_id> komutuyla sonlandırmak gerekebilir.
4. Donanım Kaynaklarını Gözden Geçirin: Bazen bloklama değil, “yetişememe” söz konusudur. Eğer I/O alt yapısı Primary kadar güçlü değilse, redo thread disk kuyruğuna takılır. Secondary replikanın disk ve CPU gücünün Primary ile eşdeğer olması profesyonel bir zorunluluktur.
SQL Server 2016 ve sonrasında gelen Parallel Redo özelliği bu darboğazları büyük ölçüde azaltsa da, sayfa düzeyindeki kilitlenmeleri tamamen ortadan kaldırmaz.
Bu makalede Redo Thread Blocking kavramını detaylı bir şekilde görmüş olduk. Başka makalede görüşmek dileğiyle..
“Biz ona şah damarından daha yakınız.” Kaf-16
