SQL Server’da ASYNC_NETWORK_IO(Network IO), SQL Server’ın veriyi hazırlayıp göndermeye hazır olduğu, ancak istemcinin (uygulama, rapor ekranı veya kullanıcı) bu veriyi yeterince hızlı çekemediği durumlarda oluşur.
Yaygın kanının aksine, bu bekleme tipi genellikle ağınızın yavaş olduğu anlamına gelmez. Daha çok, “istemcinin veriyi işleme kapasitesinin” düşük olduğunu gösterir.
SQL Server bir sorgu sonucunu istemciye gönderirken, veriyi Network Output Buffer (Ağ Çıkış Tamponu) adı verilen bir alana koyar. Eğer uygulama bu veriyi okuyup tamponu boşaltmazsa, tampon dolar ve SQL Server durup beklemek zorunda kalır.
En yaygın karşılaşılan ve Network IO denildiğinde kastedilen asıl bekleme tipi ASYNC_NETWORK_IO‘dur.
Hangi oturumların bu bekleme tipine takıldığını görmek için şu sorguyu kullanabilirsiniz:
SELECT session_id, wait_type, wait_time, last_wait_type, status
FROM sys.dm_exec_requests
WHERE wait_type = 'ASYNC_NETWORK_IO';En Yaygın Nedenler:
- “Row-by-Row” İşleme (RBAR): Uygulamanın SQL’den gelen binlerce satırı tek tek (while read döngüsü gibi) okuyup aralarda ağır işlemler yapması.
- Gereksiz Büyük Veri Çekme: Uygulamanın sadece 10 satıra ihtiyacı varken SELECT * ile 1 milyon satır talep etmesi.
- Büyük Veri Kümelerini Ekranda Gösterme: Bir raporun veya grid ekranının 100.000 satırı aynı anda yüklemeye çalışması.
- Uygulama Sunucusu CPU/RAM Darboğazı: Uygulamanın çalıştığı sunucunun çok meşgul olması nedeniyle gelen veriyi kuyruktan alamaması.
Bu bekleme tipini çözmek için genellikle SQL Server tarafında değil, uygulama kodu veya sorgu tasarımı tarafında değişiklik yapmak gerekir:
A. Sorgu Sonucunu Filtreleyin
Uygulamanın gerçekten tüm o verilere ihtiyacı var mı?
- SELECT * yerine sadece gerekli sütunları, tüm satırlar yerine TOP veya OFFSET-FETCH ile sayfalama (paging) kullanarak veriyi çekin.
B. Uygulama Kodunu Optimize Edin
Uygulama, SQL’den veri çekerken araya uzun süren işlemler koymamalıdır.
- Kötü Yaklaşım: Veriyi oku -> API’ye gönder -> Log yaz -> Sıradaki satırı oku.
- İyi Yaklaşım: Tüm veriyi bir listeye/belleğe hızlıca al -> Bağlantıyı serbest bırak -> İşlemleri sonra yap.
C. “Batch” İşlemlerini Gözden Geçirin
Eğer bir INSERT INTO … SELECT işlemi yapıyorsanız ve hedef sunucu başka bir ağ üzerindeyse (Linked Server gibi), veri aktarım hızı ASYNC_NETWORK_IO olarak yansıyabilir.
D. Ağ Yapılandırmasını Kontrol Edin
Nadiren de olsa, sorun gerçekten fiziksel olabilir.
- Network Interface Card (NIC) ayarlarında “Half-Duplex” yerine “Full-Duplex” kullanıldığından emin olun.
- SQL Server ve Uygulama Sunucusu arasındaki ağ gecikmesini (Latency) kontrol edin.
Özetle
| Belirti | Olası Neden | Aksiyon |
| Yüksek bekleme süresi + Çok satırlı sonuç | Uygulama veriyi yavaş tüketiyor. | Sorguya WHERE veya TOP ekleyin. |
| Uygulama tarafında donma | RBAR (Satır satır okuma) yükü. | Veriyi toplu (bulk) çekip bellekte işleyin. |
| Büyük dosya/imaj çekme | Ağ bant genişliği sınırı. | Dosyaları sıkıştırarak veya parçalı gönderin. |
Bu beklemeyi kendi bilgisayarınızda bir Management Studio (SSMS) penceresinde devasa bir tabloyu sorgularken de görebilirsiniz. SSMS, gelen milyonlarca satırı ekrana çizmeye (rendering) çalışırken SQL Server’ı bekletir. Bu, ağın değil, SSMS’in çizim hızının yavaşlığıdır.
Başka makalede görüşmek dileğiyle..
“O, gökleri görebileceğiniz herhangi bir destek olmadan (duracak şekilde) yarattı, sizi dengede tutması için yere sağlam dağlar yerleştirdi, orada her türlü canlının çoğalmasını sağladı. Biz, gökten su indirip (bununla) yeryüzünde her türden faydalı bitkiler bitirdik.”Lokman-10
