SQL Server Blocking Nasıl Tespit Edilir?

Blocking neden uygulamayı bir anda yavaşlatır?

SQL Server'da bir oturumun tuttuğu lock başka bir oturumun ihtiyaç duyduğu kaynakla çakıştığında blocking oluşur. Kısa blocking normal transaction davranışının parçasıdır. Problem, bloklayan transaction uzun sürdüğünde veya arkasında çok sayıda istek biriktiğinde başlar. Uygulamada timeout görülürken sunucu CPU'su düşük kalabilir; bu yüzden yalnızca kaynak grafikleri problemi göstermeyebilir.

Yaygın nedenler arasında commit edilmeyen transaction, büyük bir batch update, uygun index kullanamayan değişiklik sorgusu ve kullanıcı etkileşimi boyunca açık tutulan transaction bulunur. Amaç kilidi hemen sonlandırmak değil, bloklayan oturumu ve transaction'ın iş etkisini güvenli biçimde anlamaktır.

Bloklayan oturumu DMV üzerinden bulun

Aşağıdaki salt-okunur sorgu aktif istekleri, bekleme türünü ve blocking session kimliğini gösterir. Sorgu SQL Server içindir. DMV erişimi için gerekli izinleri kontrol edin ve önce test ortamında deneyin. blocking_session_id değeri sıfırdan büyük olan satırlar başka bir oturumu bekliyordur.

Tek bir snapshot yeterli değildir. Aynı ilişkinin kaç saniye sürdüğünü ve bekleyen oturum sayısının artıp artmadığını zaman içinde izleyin. Kısa süreli lock ile kullanıcı etkisi yaratan blocking zincirini ancak bu şekilde ayırabilirsiniz.

• wait_type ve wait_time değerini birlikte değerlendirin.
• En üstteki blocker'ın açık transaction süresini kontrol edin.
• Oturumu sonlandırmadan önce rollback etkisini hesaplayın.

SELECT
    session_id,
    blocking_session_id,
    wait_type,
    wait_time,
    status,
    total_elapsed_time
FROM sys.dm_exec_requests
WHERE blocking_session_id > 0
ORDER BY wait_time DESC;

KILL komutu ilk refleks olmamalı

Bloklayan oturumu sonlandırmak bekleyen istekleri serbest bırakabilir, fakat açık transaction geri alınırken yeni bir yük ve uzun rollback süresi oluşabilir. Oturum kritik bir finansal işlem veya deployment parçasıysa veri tutarlılığı ve uygulama davranışı ayrıca değerlendirilmelidir. Önce sorgu sahibini, transaction başlangıcını, etkilenen satırları ve geri dönüş planını doğrulayın.

Kalıcı çözüm çoğu zaman transaction kapsamını küçültmek, batch boyutunu azaltmak, erişim sırasını tutarlı hale getirmek veya sorgunun doğru index ile daha az satıra dokunmasını sağlamaktır. Isolation level değişikliği ise etkileri anlaşılmadan uygulanmamalıdır.

Blocking alarmı nasıl tasarlanmalı?

Her lock için alarm üretmek gürültü yaratır. Daha doğru alarm; blocking süresi, bekleyen oturum sayısı ve kullanıcı etkisini birlikte kullanır. Örneğin normal iş yükünüz için anlamlı bir süreyi aşan ve arkasında büyüyen bir kuyruk oluşturan blocker uyarı üretmelidir. Eşik, internetten alınan sabit bir sayı değil kendi production davranışınız olmalıdır.

Bildirimde sunucu ve veritabanı adı, blocker session, wait türü, süre, bekleyen oturum sayısı ve ilgili dashboard bağlantısı bulunmalıdır. Böylece nöbetçi DBA problemi tekrar keşfetmek yerine doğrudan doğrulamaya başlayabilir.

Moon blocking sinyalini görünür hale getirir

moon, SQL Server, PostgreSQL ve MongoDB için DBA'lar tarafından geliştirilen düşük ek yüklü bir monitoring agent'ıdır. SQL Server'da önemli sinyalleri sürekli izlemek, anlık DMV sorgusunun kaçıracağı kalıcı blocking davranışını görmeye yardımcı olur. Bildirimler Slack, PagerDuty veya webhook üzerinden ilgili ekibe yönlendirilebilir.

Monitoring blocking'i kendi başına düzeltmez; doğru anda doğru bağlamı sağlar. Sorun tekrarlandığında süre, yoğunluk ve iş yükü ilişkisini görmek kök nedeni bulmayı kolaylaştırır.