SQL Server’ın Memory Clerk yapısı, her sorguya ihtiyacı olan “çalışma belleğini” (Query Grant) dağıtır. Eğer havuzda yeterli RAM yoksa, sorgu bir kuyruğa alınır.
- Pending: Sorgu kapıda bekliyor, henüz içeri alınmadı.
- Grant: Sorgu belleğini aldı ve çalışmaya başladı.
SQL Server’ın sorgu çalıştırmadan önce gerekli olan bellek kaynağını henüz almadığı durumları ifade eder. Bu bekleme türü, SQL Server’ın işlemi gerçekleştirmek için gerekli olan bellek kaynağını almak için bellek yönetimini tamamlamaya çalıştığı zaman meydana gelir. Bu bekleme türü, SQL Server bir işlem için gerekli olan bellek tahsisatını tamamlamadan işlemi başlatmaya çalıştığında görülür. Genellikle büyük sorgular veya işlemler sırasında, yeterli bellek kaynağı ayarlanamadığında oluşur.
Bu Durumun Temel Nedenleri:
- Eksik İstatistikler: SQL Server, 100 satır geleceğini sanıp 1 MB isterken, aslında 1 milyon satır gelmesi sonucu 1 GB belleğe ihtiyaç duyulması (veya tam tersi; yanlış tahminle devasa bellek rezerve edilmesi).
- Büyük Sıralama (Sort) ve Join İşlemleri: ORDER BY, GROUP BY ve HASH JOIN işlemleri RAM’e açtır.
- Paralellik (MAXDOP) Sorunları: Bir sorgu ne kadar çok işlemci çekirdeği kullanırsa, o kadar fazla “minimum bellek” talep eder.
- Yetersiz Fiziksel Bellek: Sunucunun RAM kapasitesinin, iş yükü için artık küçük kalması.
Bu sayacın yükseldiğini gördüğünüzde (genellikle PerfMon veya sys.dm_os_performance_counters üzerinden), şu adımları izlemelisiniz:
A. Bellek Bekleyen Sorguları Yakalayın
Hangi sorguların “Pending” durumunda olduğunu ve ne kadar bellek istediklerini şu anlık (real-time) görün:
SELECT
session_id,
requested_memory_kb / 1024.0 AS Requested_MB,
granted_memory_kb / 1024.0 AS Granted_MB,
request_time,
wait_order, -- Kuyruktaki sırası
timeout_sec -- Zaman aşımına ne kadar kaldı
FROM sys.dm_exec_query_memory_grants
WHERE grant_time IS NULL; -- Sadece bekleyenler
B. Sorgu Planlarını İnceleyin
Bekleyen sorguların planlarında “Warning” (Sarı ünlem) işareti arayın. Genellikle şu iki uyarıyı görürsünüz:
- Excessive Grant: Sorgu gereğinden fazla bellek istemiş.
- Spill to TempDB: Sorgu istediği belleği alamadığı için veriyi diske (TempDB) yazmış (bu, sistemin yavaşlamasının ana sebebidir).
C. İstatistikleri Güncelleyin
Hatalı bellek tahminlerini düzeltmenin en hızlı yolu budur:
UPDATE STATISTICS Tablo_Adi;
D. Uygulama ve Sunucu Ayarları
- MAXDOP Ayarı: Eğer sistemde çok fazla bekleyen sorgu varsa, MAXDOP değerini düşürerek her bir sorgunun başlangıçta talep ettiği minimum bellek miktarını azaltabilirsiniz.
- Min/Max Server Memory: SQL Server’ın işletim sistemiyle bellek kavgası etmediğinden emin olun.
- Index Kullanımı:
Sortişlemini ortadan kaldıracak uygun Non-Clustered Index yapıları oluşturun.
Özetle
| Durum | Çözüm Yolu |
| Kısa süreli sıçramalar | Genellikle anlık yoğunluktur, izlemeye devam edin. |
| Sürekli Pending durumu | Bellek tüketen sorguları (Large Scans/Sorts) optimize edin. |
| Büyük RAM talepleri | İstatistikleri güncelleyin ve MIN_GRANT_PERCENT ipuçlarını (hint) kontrol edin. |
| Donanım Yetersizliği | Yukarıdakiler çözüm olmuyorsa, fiziksel RAM eklemeyi düşünün. |
Diyelim ki bir raporlama uygulaması aynı anda 10 büyük sorgu gönderiyor. Her biri çalışmak için 500 MB memory grant istiyor. Ama toplamda sadece 2 GB memory grant alanı var. Bu durumda sadece 4 sorgu aynı anda çalışabilir, diğer 6 tanesi MEMORY_GRANT_PENDING durumunda bekler.
Başka makalede görüşmek dileğiyle..
“Gevşemeyin, üzülmeyin, inanmışsanız, mutlaka siz en üstünsünüzdür.” Al-i İmran Suresi; 139. Ayet
