dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Home/Hata Teşhis Kütüphanesi/sqlserver-233-transport-level-error
SQL Server
SQL Server 2017–2022Ağ & İletişim
8 dk okuma
Msg 233, Level 20, State 0: A transport-level error has occurred when receiving results from the server

SQL Server Msg 233 — "Transport-level error" Sunucudan mı, Ağdan mı?

233 hatasının ağdan mı SQL Server'dan mı geldiğini ERRORLOG ve sys.dm_exec_sessions ile ayırt etme; eski havuz bağlantıları, keepalive ve MTU.

İnceleyen:Principal Database Reliability Architect
Test Edilen Sürümler: SQL Server 2022 CU15 & 2019 CU28 (Windows Server 2022 / RHEL 9 Docker)

Operasyonel Doğrulama & Güvenilirlik Standardı

Son Teknik İnceleme: 30 Ekim 2026
Test Edilen SürümlerSQL Server 2022 CU15 & 2019 CU28 (Windows Server 2022, Docker 29.7)
Gerekli YetkiVIEW SERVER STATE veya VIEW SERVER PERFORMANCE STATE, sp_readerrorlog erişimi
Risk Seviyesi
HighKesilen sorgu sırasında yapılan otomatik retry işlemleri, sunucuda commit edilmiş verilerde mükerrer kayda yol açabilir
Beklenen ÇıktıHatanın ağ katmanından (ERRORLOG boş) mı yoksa sunucu çöküşünden/AG failoverından mı geldiğinin kesin tespiti
Geri Dönüş (Rollback) Planı:İstemci bağlantı havuzu maxLifetime değerini ve OS KeepAlive parametrelerini ağ güvenlik duvarı kurallarına göre eşitleme
Microsoft Docs: Troubleshoot Transport-Level Errors
İlk 60 Saniye Teşhis Protokolü:

Hata mesajı semptomdur, kök neden değildir. Sunucuyu yeniden başlatmadan veya rastgele ayar değiştirmeden önce aşağıdaki "Nedeni ayırt eden tek sorgu"yu çalıştırarak gerçek senaryoyu netleştirin.

▸Belirti

plaintext
Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)

Aynı hata numarası farklı sağlayıcı (provider) metinleriyle fırlatılabilir; parantez içindeki kısım asıl kök neden ipucudur:

plaintext
(provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) (provider: TCP Provider, error: 0 - The specified network name is no longer available.) (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
ÖNEMLİ
Severity (Önem Derecesi) 20: Bu hatanın Level 20 olması kritiktir. SQL Server'da 20 ve üzeri önem derecesi, bağlantının (oturumun) geri dönülemez biçimde koptuğunu ve devam ettirilemeyeceğini gösterir. İstemci aynı soket üzerinden işlem yürütemez.

Sağlayıcı Hata Kodlarının Anlamı

  • •121 — The semaphore timeout period has expired: TCP yığını yanıt beklemekten vazgeçti. Ağ yolu koptu: Güvenlik duvarı (firewall) boşta kalan TCP oturumunu sessizce düşürdü, VPN tüneli koptu, NAT tablosu temizlendi, ağ kartı uyku moduna girdi veya MTU boyutu uyuşmazlığı var.
  • •64 — The specified network name is no longer available: Karşı uç tamamen kayboldu: SQL Server servisi aniden çöktü, sanal sunucu (VM) vMotion/failover sırasında donduruldu veya sunucu yeniden başladı.
  • •10054 — An existing connection was forcibly closed by the remote host: Karşı uçtan bir TCP RST paketi ulaştı: Bir DBA SPID'i KILL etti veya aradaki bir ağ cihazı (IPS/Proxy) bağlantıyı kesti.

▸Nedenini Doğrulayan Adım: ERRORLOG'da Karşılığı Var mı?

Bu hatanın en belirgin özelliği, istemcide kopma yaşanırken SQL Server motorunda bazen hiçbir iz bırakmamasıdır. Bu iz yokluğu aslında en büyük teşhis aracıdır:

sql
EXEC sp_readerrorlog 0, 1, N'233'; EXEC sp_readerrorlog 0, 1, N'closed';
  1. 1ERRORLOG'da Hiçbir Kayıt Yok: SQL Server soketin koptuğunu bile fark etmemiştir. Sorun kesinlikle ağ katmanında (güvenlik duvarı zaman aşımı, VPN, istemci tarafı soket düşüşü) yaşanmıştır. Sunucuda SQL Server ayarlarıyla oynamak zaman kaybıdır.
  2. 2ERRORLOG'da Eşleşen Kayıt Var: Sunucu ölü bir sokete yazmaya çalıştığını kaydetmiştir. Bu durumda logda AlwaysOn Availability Group (AG) failover kayıtlarını, SQL Server is terminating because of... bildirimlerini veya bellek baskısını arayın:
sql
SELECT ar.replica_server_name, ars.role_desc, ars.connected_state_desc, ars.last_connect_error_description FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ar.replica_id = ars.replica_id;

Yarı Açık (Half-Open) Bağlantı Testi

İstemci hata aldığı halde SQL Server oturumu açık görüyor mu?

sql
SELECT session_id, login_name, host_name, program_name, status, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE is_user_process = 1 ORDER BY last_request_start_time DESC;

İstemci Msg 233 ile düştüğü halde SQL Server tarafında oturum sleeping olarak duruyorsa, tipik bir yarı açık (half-open) soket durumu vardır: Sunucu karşı tarafın koptuğunu henüz anlayamamıştır. Bu, Windows TCP KeepAlive süresinin çok uzun olduğunun kesin kanıtıdır.


▸Adım Adım Çözüm ve Ağ Sertleştirme

1. Havuzdaki Eski Bağlantıları Emekliye Ayırın

En sık senaryo: Uygulama bağlantı havuzunda (ADO.NET, HikariCP, c3p0) saatlerdir bekleyen bir oturum, aradaki kurumsal güvenlik duvarı (Firewall) tarafından sessizce (RST göndermeden) düşürülür. Havuz bunu bilmez, bağlantıyı yeni bir HTTP isteğine verir ve istek anında Msg 233 alır. Çözüm: Bağlantı havuzunun Connection Lifetime / maxLifetime değerini güvenlik duvarının boşta kalma eşiğinden (örneğin 30 dakika ise 15 dakikaya) daha kısa tutun.

2. İşletim Sistemi TCP KeepAlive Süresini Düşürün

Windows varsayılan TCP KeepAlive süresi 2 saattir (7,200,000 ms). Kurumsal ağ cihazları ise boşta kalan oturumları genellikle 5 ila 30 dakika arasında düşürür. Bu farkı kapatmak için hem istemci hem de SQL Server işletim sisteminde kayıt defteri üzerinden KeepAlive değerini optimize edin:

plaintext
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters KeepAliveTime = 300000 (DWORD, 5 dakika) KeepAliveInterval = 1000 (DWORD, 1 saniye)

3. MTU Boyutunu Test Edin

Özellikle bulut VPC'leri, IPsec VPN ve tüneller üzerinden bağlanan istemcilerde küçük sorgular (SELECT 1) sorunsuz çalışırken, büyük veri çeken sorgular aniden semaphore timeout verir. Paket parçalanmasını yasaklayarak test edin:

bash
ping -f -l 1472 <sql-server-ip>

Paket boyutu aşıldığında hata alınıyorsa ağ kartı veya tünel MTU ayarını (örn. 1400) düşürün.

4. Ağ Kartı Enerji Tasarrufunu Kapatın

Sunucu ve sanallaştırma hipervizöründe ağ kartlarının (NIC) "Energy Efficient Ethernet", "Green Ethernet" veya uyku modlarını devre dışı bırakın.

UYARI
Retry Riski: Msg 233 geçici bir hata olarak sınıflandırılabilir; ancak bu hata bir veri yazma (UPDATE / INSERT) sırasında ortaya çıktıysa, sunucu işlemi COMMIT etmiş ama yanıt istemciye dönerken hat kopmuş olabilir. Otomatik retry yapmak mükerrer kayıtlara yol açar. İstemci tarafında idempotency doğrulaması yapmadan körlemesine retry tetiklemeyin.

▸İlgili Hata Rehberleri & Hub Bağlantıları

Diğer Veritabanı Hata Teşhisleri

Kriz anında başvurabileceğiniz diğer doğrulanmış hata rehberleri.

Tüm Hatalar (50)