Bağlantı havuzları Hata: 18056, Önem derecesi: 20, Durum: 46 ile sıfırlanıyor. & Perfmon Sayaçları gösterilmiyor

Windows 2008 R2 Enterprise Server'da SQL Server Enterprise Edition 2012 SP1'e bağlanmak için SQL Authentication (bağlantı havuzlarının sayısını azaltmak için) ve .NET 4.0 bağlantı dizgilerini kullanıyoruz:

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
Eki 19 2012 13:38:57
Telif Hakkı (c)
Windows NT 6.1'deki Microsoft Corporation Kurumsal Sürüm (64-bit) (Yapı 7601: Service Pack 1)

Bir web sitesinin 8 farklı gruba ayrılan yaklaşık 50 sunucusunu kullanıyoruz.

Web sitemiz ziyaret izleme verilerini günlüğe kaydetmek için bu SQL Server kullanıyor. Son birkaç gün içinde bağlantı havuzlarını sıfırlama hakkında aşağıdaki mesajları tükürdü:

İstemci SPID 1327 ile bağlantı havuzlaması için sıfırlanmış bir oturumu yeniden kullanamadı. Hata kimliği 46'dır. Bu hata, daha önceki bir işlem başarısızlığından kaynaklanmış olabilir. Bu hata iletisinden hemen önce hata işlemlerinde hata günlüklerini kontrol edin.

Hata günlüğü okur:

Hata: 18056, Önem derecesi: 20, Durum: 46.
İstemci, bağlantı havuzu için sıfırlanmış SPID 959 oturumunu yeniden kullanamadı. Hata kimliği 46'dır. Bu hata, daha önceki bir işlem başarısızlığından kaynaklanmış olabilir. Bu hata iletisinden hemen önce hata işlemlerinde hata günlüklerini kontrol edin.
'Xxxx' kullanıcısı için giriş başarısız oldu. Neden: Bağlantıdaki oturumu yeniden doğrularken, oturum açma nesnesinde yapılandırılmış olan 'xxxxxxxx' veritabanı açılamadı. [İSTEMCİ: 10.xx.xx.xxx]

Bazı araştırmalardan sonra, bu belgeyi CSS blogunda buldum: Nasıl Çalışıyor: Hata 18056 - İstemci, SPID ## ile bağlantı havuzlaması için sıfırlanan bir oturumu tekrar kullanamadı ve bunu Aaron Bertrand: Sorun Giderme Hatası 18456 . Hata numarasının farklı olduğunu biliyorum ama başarısızlık kimliği mesajların aynı olduğu ile aynı.

Hata ID 46, giriş bilgilerinin izinsiz olduğunu gösterir. Varsayılan olarak ana veritabanına giriş yapar ve db adı bağlantı dizesinde belirtilir.

Bağlantı dizgisi havuzları vb. Sayısını kontrol etmek istedim ve Perfmon'daki tüm sayaçları kontrol ettim .Net Data Provider for SqlServer. Bana sadece defaultdomain9675örnek seçeneği verdi , bu yüzden bunun bir veri merkezi ağımız için üretilen bir kimlik adı olduğunu farz ettim. Ne yazık ki tüm sayaçlar sıfır okuyor. Diğer ana sunuculardan birinde, bağlantı havuzları 10 civarında seyrediyor, bu da bu tür bir yükle sağlıklı bir sunucuda görmeyi beklediğim gibi.

Benim sorum 3 kat

1. Windows 2008 R2 Sunucusunun neden gösterilmediğini kimse söyleyebilir .Net Data Provider for SqlServermi?

2. Açıkçası izinsiz giriş yapmanın kırmızı bir ringa balığı olduğuna inandığım için kimse bunu tecrübe etti mi?

3. Farklı web sunucusu grupları aynı bağlantı dizesi sözdizimine sahipse ancak biraz farklı boşluklarla, bu, sunucunun başka bir bağlantı havuzu kullanmasına neden olur mu?

Minimum ve maksimum bellek ayarları sırasıyla 20GB ve 58GB'dir. Sunucu 64 GB RAM'e sahip özel bir veritabanı sunucusudur. Kutunun iyi bir sayfa beklentisine sahip gibi göründüğü için hafızanın bir sorun olduğunu sanmıyorum. Otomatik kapanma etkin değil. Sunucu her zaman çalışır durumda: Bu, yoğun kullanılan 24x7 bir web sitesidir.

1 - kesin olarak söyleyemem, kendime kazılacak bir sunucu bulmalıyım.

2 - evet, bunu periyodik olarak çevremde görüyorum, ancak sql 2012'de değiliz, ancak bunu gördüğümüz sistemlerde görüyoruz. Devlet 46’nın belirli bir Veri Tabanı’nın belirli bir Veritabanına sahip olması ile ilgili görünse de http://blogs.msdn.com/b/psssql/archive/2013/02/13/breaking-down-18065.aspx adresini de kontrol etmek isteyebilirsiniz . bağlantı dizesi, bu db hala var mı?

Ağımın kurulma şekli, ağın 5 dakika boşta kalmasının ardından ağın otomatik tcp oturumlarını kapatmasından şüpheleniyorum - sorun ne db ne de müşteri oturumu kapatıyor, böylece bağlantı havuzu hala bağlantının açık olduğunu düşünüyor ve kullanmaya çalışıyor Sadece artık gerçekten açık olmadığını bulmak için. Web sunucuları ve db arasındaki ağın nasıl yapılandırıldığından bahsetmiyorsunuz, belki de durumunuz benzer.

Başka bir olasılık, TCP Baca Boşaltma ayarları hakkında (eski, hiç çözülüp çözülmediğinden emin değilseniz, bkz. Http://support.microsoft.com/kb/942861 ) sorunu olabilir.

3 - Anlayışım havuzlama tam dize eşleşmeleri gerektiriyor, bu nedenle boşluk ve farklı parametre sırası farklı havuzlara neden oluyor. (Bu konuda yanılıyorsam, lütfen bana bildirin.)

_{Topluluk Wiki sorusu asıl soru yazar tarafından yorum olarak bırakıldı}

Benim durumumda, bir sorunu gidermek için birisinin ayrıntılı bir hale getirdiği, ancak kapatmayı unuttuğu kaçak bir kayıt masası olduğu ortaya çıktı. Saniyede 1000 kayıt kaydı yapıldı.

Başka bir iş, eski kayıtları tablodan silmeye çalışıyordu. silmeye çalışırken, bağlantı havuzu kaynaklarının tükettiği tüm bu ekleri engelleyerek kendini budaklara kilitlemeye başladı.

İş bulduktan hemen sonra, sunucudaki haklarını kötüye kullanan kişiyi tokatladı ve işi durdurdu, bağlantı havuzları için tüm hata mesajları durdu.