RESOURCE_SEMAPHORE_QUERY_COMPILE, SQL Server’ın sorgu derleme sırasında bellek kaynaklarını almak için beklediği bir durumdur. Sorgular çalıştırılmadan önce SQL Server, sorgu planlarını oluştururken belirli bir miktarda bellek kullanır. Eğer bellek yeterli değilse, bu bekleme türü devreye girer. Bu bekleme türü genellikle çok karmaşık sorgular veya çok sayıda işlem sırasında görülür. SQL Server, sorgu derleme sırasında gerekli olan bellek kaynaklarını tahsis edemediğinde bu bekleme türü meydana gelir. Bu tür beklemeleri minimize etmek için sorgu karmaşıklığını azaltmak, gereksiz karmaşık işlemlerden kaçınmak ve sorgu optimizasyonu yapmak faydalı olacaktır. Ayrıca, bellek tahsisatını artırmak da çözüm olabilir.
Kısaca, SQL Server’da bir sorgu derlenirken (yani execution plan hazırlanırken) yeterli derleme belleği (compile memory) tahsis edilemediği için beklemesi gereken durumlarda ortaya çıkar.
Yani özetle:
“Sorgu derlenmek istiyor ama derleme işlemini yapmak için yeterli bellek yok, o yüzden sıraya alınıyor.”
SQL Server, sistemin kilitlenmesini önlemek için aynı anda kaç tane “ağır” derleme işleminin yapılabileceğine dair bir limit (gatekeeper) koyar. Eğer bu limit aşılırsa, yeni gelen derleme talepleri bu bekleme tipiyle sıraya alınır.
Neden görülür:
- Aşırı Karmaşık Sorgular: Binlerce satırlık, onlarca tabloyu birbirine bağlayan devasa SQL metinleri.
- Plan Cache Şişmesi: Sürekli değişen parametrelerle (Literal SQL) gönderilen sorguların her seferinde yeniden derlenmesi.
- Yetersiz RAM: Sunucunun genel bellek miktarının düşük olması.
- Ad-hoc Sorgu Yoğunluğu: Uygulamanın sp_executesql kullanmak yerine sürekli farklı string’lerle sorgu göndermesi.
- Plan cache sık sık temizleniyorsa (örneğin RECONFIGURE, DBCC FREEPROCCACHE, sp_recompile)
Eğer bu bekleme tipini sıkça görüyorsanız, çözüm stratejinizi şu üç adıma ayırmalısınız:
A. Sorunlu Sorguları Teşhis Edin
Hangi sorguların derleme aşamasında takıldığını veya çok fazla derleme belleği harcadığını şu sorguyla bulabilirsiniz:
SELECT
s.session_id,
s.text,
r.wait_type,
r.wait_time,
r.granted_query_memory
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) s
WHERE r.wait_type = 'RESOURCE_SEMAPHORE_QUERY_COMPILE';
B. Sorgu Optimizasyonu ve Parametrizasyon
- Parametrizasyon Kullanın: Uygulama tarafında sorguları parametreli gönderin. Bu sayede SQL Server planı bir kez derler ve cache’ten kullanır. Parameter Sniffing sorunlarına dikkat etmek.
- Optimize for Ad Hoc Workloads: Eğer çok fazla küçük ve tek seferlik sorgunuz varsa, sunucu seviyesinde optimize for ad hoc workloads ayarını aktif ederek Plan Cache’in gereksiz şişmesini engelleyin. İlgili makale
- Sorguları Basitleştirin: Bir sorguda 50’den fazla JOIN veya çok uzun WHERE IN (1, 2, … 5000) listeleri varsa, bunları geçici tablolara (#temp_table) bölerek derleme yükünü azaltın.
- Query Store aktifse plan sabitlemeyi (plan forcing) düşünmek.
C. Bellek Yönetimi (Sistem Seviyesi)
- Plan Cache’i Temizlemeyi Deneyin (Geçici Çözüm): Eğer sistem tıkanmışsa DBCC FREPROCCACHE komutu belleği boşaltabilir (Dikkat: Tüm planlar silineceği için kısa süreli bir CPU yükü yaratır).
- Max Server Memory: SQL Server’ın toplam belleğinin yeterli olduğundan ve işletim sistemi tarafından baskılanmadığından emin olun.
Özet Karşılaştırma
| Bekleme Tipi | Hangi Aşamada? | Neden Bekliyor? |
| RESOURCE_SEMAPHORE | Çalıştırma (Execution) | Veriyi işlemek için RAM bulamıyor. |
| RESOURCE_SEMAPHORE_QUERY_COMPILE | Planlama (Compilation) | Planı oluşturmak için RAM bulamıyor. |
Bu makalede RESOURCE_SEMAPHORE_QUERY_COMPILE bekleme tipini detaylı bir şekilde görmüş olduk. Başka makalede görüşmek dileğiyle..
“Kim zerre kadar iyilik yapmışsa onu görür.”Zilzal Suresi; 7. Ayet
