Dakikalarca Takılı Kalan SQL Sorgusu Nasıl Önlenir?

Bu satırları okuyunca tanıdık geldi mi? Bu bir edge case değil. IT ortamlarında yaşanan, ekiplerin haftalarca sessizce acı çektiği, ancak disk dolduğunda ya da kullanıcılar şikâyet ettiğinde fark edilen gerçek bir problem. Ve maalesef, genel altyapı izleme araçları bu tür sorunlar için kör noktalarla doludur, yetersiz kalır.

Bu yazıda hem bu sorunun teknik anatomisini hem de SolarWinds Database Observability ailesinin — özellikle SQL Sentry'nin — SQL sorgusu ve benzeri krizleri gerçekleşmeden nasıl tespit edebildiğini ele alacağız.

Kullanılan Monitoring Aracı Neden Yetmedi?

PRTG ve benzeri altyapı izleme araçları CPU, RAM, disk I/O ve network gibi OS düzeyindeki metrikleri izlemek için tasarlanmıştır. Bu metrikler normal görünüyorken SQL Server içinde felaket büyüyor olabilir. Bunun nedeni SQL Server'ın kendi içinde son derece karmaşık bir kaynak yönetim katmanına sahip olmasıdır.

Dakikalar boyunca takılı kalan SQL sorgusu büyük ihtimalle bir lock zincirinde bekliyordu. Bunu PRTG'den görmek mümkün değildir, çünkü OS seviyesinde hiçbir şey anormal görünmez.

SQL Server'da Sessiz Ölüm: Wait Statistics

SQL Server, SQL sorgusu hangi nedenden dolayı bekliyor, bunu wait statistics aracılığıyla kayıt altına alır. Bunlar sys.dm_exec_requests, sys.dm_os_wait_stats ve sys.dm_exec_sessions gibi DMV'lerde (Dynamic Management Views) yaşar.

Bu sorguyu manuel olarak çalıştırmak tek başına bir şey ifade etmez problemi anlık değil, sürekli ve otomatik olarak izlemek gerekir. İşte bu noktada altyapı araçları ile gerçek bir database observability platformu arasındaki fark ortaya çıkıyor.

SQL Sentry Ne Görür?

SQL Sentry, SolarWinds'in Database Observability ailesinin SQL Server'a özel bileşenidir. OS düzeyi metriklerinin çok ötesinde, SQL Server motorunun içini gerçek zamanlı olarak izler.

Gerçek Zamanlı İzlenen Boyutlar

• Top SQL & Query Plans: Hangi sorgu ne kadar süredir çalışıyor, query planı son çalışmadan bu yana değişti mi?
• Blocking Chains: Hangi session kimi bloklıyor? Blok zincirinin kök nedeni nerede?
• Wait Statistics: LCK_M_X, PAGEIOLATCH, CXPACKET gibi wait type'ları gerçek zamanlı analiz
• Deadlock Grafiği: Deadlock'ları XML yerine görsel olarak analiz edin, tarihsel geçmiş saklansın
• Transaction Log Kullanımı: Log'un neden dolduğu, hangi session'ın log alanı tükettiği
• Tempdb Basıncı: Tempdb allocation failure'larını önceden tespit
• Index Kullanım Analizi: Eksik index önerileri, kullanılmayan index tespiti

• 01

  DMV (sys.dm_exec_requests): Ham veri kaynağı.

• 02

  SQL Sentry Engine Analizi: Verinin yorumlanması ve korelasyonu.

• 03

  Eşik Aşımı — Alarm: Anormal durumun tespiti.

• 04

  Otomatik Aksiyon veya Bildirim: İlgili ekiplerin uyarılması.

• 05

  Kök Neden Analizi: Sorunun kaynağının bulunması ve çözümü.

Alarm Yapılandırması

SQL Sentry'de "30 saniyeden uzun süren herhangi bir sorgu için alarm üret" kuralı doğrudan UI'dan oluşturulabilir. Sadece bu değil — blocking chain'de kökte kim var, hangi wait type'ı neden bu kadar uzun, log kullanımı kritik eşiği geçti mi gibi composite condition'lar da tanımlanabilir. Alarm tetiklendiğinde sadece bildirim almakla kalmaz; ilgili query metni, execution plan ve session detayları da anlık olarak görüntülenebilir.

Blocking Chain'i Anlamak: Görünmez Kriz

Reddit'teki senaryoda büyük ihtimalle şu oldu: Bir sorgu explicit transaction içinde çalışıyordu ve bir satır/sayfa üzerinde LCK_M_X (exclusive lock) tutuyordu. Ardından network kesilmesi, uygulama crash'i ya da başka bir neden session'ı zombie durumuna düşürdü. Transaction ne commit ne rollback etti. Lock tutulmaya devam etti.

SQL Sentry bu zinciri canlı görsel bir grafik olarak gösterir. Kök blocker kim, kaç session etkileniyor, toplam bekleme süresi ne kadar — bunların hepsi tek bir ekranda. Üstelik geçmiş blocking event'leri de saklanır; incident sonrasında "o gece tam olarak ne olmuştu?" sorusunu cevaplayabilirsiniz.

Database Observability Ailesi: Bütünleşik Güç

SQL Sentry tek başına güçlüdür, ama SolarWinds'in Database Observability ailesi bunun çok ötesine geçer. Database Performance Analyzer (DPA), query-level wait time'ı tarihsel olarak analiz eder ve hangi sorgunun ne zaman neden yavaşladığını saatler/günler geriye dönük olarak gösterir.

• SQL Sentry: Gerçek zamanlı izleme, blocking, deadlock, query plan analizi — SQL Server içinin X-ray'i
• Database Performance Analyzer: Tarihsel wait analizi, trend tespiti, kapasite planlaması
• SolarWinds Observability: Full-stack görünürlük — infrastructure + application + database tek platformda
• Database Mapper: Dependency haritası — hangi uygulama hangi database'i hangi sorgu ile hit ediyor

Bu aile bir arada kullanıldığında sadece "şu an sorun var" demez — "bu sorun neden oluştu, ne zaman başladı, hangi query plan değişikliği tetikledi, hangi uygulama deployment'ından sonra kötüleşti" sorularını da cevaplar. Reactive monitoring'den proactive observability'ye geçiş, tam da bu bütünleşik yaklaşımla mümkün olur.

Hemen Yapabileceğiniz 3 Şey

SQL Sentry kurulu olsun ya da olmasın, bu üç yapılandırma SQL Server ortamınızı çok daha sağlıklı bir noktaya taşır:

• Query timeout zorunlu kılın: Uygulama katmanında CommandTimeout mutlaka set edilmeli. Hiçbir query sonsuz çalışmamalı — bu hem uygulama hem de DBA tarafında ortak bir kural olmalı.
• Blocked process threshold: SQL Server'ın kendi blocked process threshold ayarını 20-30 saniyeye set edin. Bu, SQL Server'ın kendi Extended Events mekanizmasını devreye sokar ve SQL Sentry ile entegre çalışır.
• Transaction log monitoring: Log dosyasının boyutunu ve büyüme hızını PRTG'de değil, SQL düzeyinde izleyin — hangi session log alanını tüketiyor bilmeden sadece boyutu bilmek yetersizdir.