Басейни підключення скидаються з помилкою: 18056, тяжкість: 20, стан: 46. Лічильники Perfmon не відображаються

Ми використовуємо автентифікацію SQL (щоб зменшити кількість пулів підключення) та рядки з'єднання .NET 4.0 для підключення до SQL Server Enterprise Edition 2012 SP1 на сервері Windows 2008 R2 Enterprise Server:

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
19 жовтня 13:38:57
Авторські права (c) Microsoft Corporation
Enterprise Edition (64-розрядна) для Windows NT 6.1 (Build 7601: Service Pack 1)

Ми використовуємо близько 50 серверів, розділених на 8 різних груп різних частин веб-сайту.

Наш веб-сайт використовує цей SQL Server для реєстрації даних відстеження відвідувань. Протягом останніх кількох днів він випустив такі повідомлення про скидання з'єднань:

Клієнт не зміг повторно використовувати сеанс із SPID 1327, який було скинуто для об'єднання з'єднань. Ідентифікатор відмови 46. Ця помилка, можливо, була викликана попередньою помилкою операції. Перевірте журнали помилок на помилкові операції безпосередньо перед цим повідомленням про помилку.

Журнал помилок читає:

Помилка: 18056, тяжкість: 20, стан: 46.
Клієнт не зміг повторно використовувати сеанс із SPID 959, який був скинутий для об'єднання з'єднань. Ідентифікатор відмови 46. Ця помилка, можливо, була викликана попередньою помилкою операції. Перевірте журнали помилок на помилкові операції безпосередньо перед цим повідомленням про помилку.
Помилка входу для користувача "xxxx". Причина: не вдалося відкрити базу даних "xxxxxxxx", налаштовану в об'єкт входу, під час повторної перевірки входу в з'єднання. [КЛІЄНТ: 10.xx.xx.xxx]

Після деякого копання я знайшов цей документ на блозі CSS: Як це працює: Помилка 18056 - Клієнт не зміг повторно використати сеанс із SPID ##, який був скинутий для об'єднання з'єднань, і цей Aaron Bertrand: Виправлення помилок 18456 . Я знаю, що кількість помилок різна, але ідентифікатор помилки однаковий, і кількість повідомлень однакова).

Ідентифікатор відмови 46 говорить про те, що вхід не мав дозволів. Наші входи за замовчуванням до основної бази даних, а ім'я db вказано в рядку з'єднання.

Я хотів перевірити кількість пулів підключення рядків і т. Д. І перевірив усі лічильники в Perfmon .Net Data Provider for SqlServer. Це лише дало мені можливість defaultdomain9675для екземпляра, тому я вибрав це, припускаючи, що це ідентифіковане системою ім'я для нашої мережі Datacentre. На жаль, всі лічильники читають нуль. На одному з інших наших основних серверів пул підключень коливається близько 10, що я очікував побачити на здоровому сервері з таким навантаженням.

Моє запитання в 3 рази

1. Хтось може підказати, чому сервер Windows 2008 R2 не відображається .Net Data Provider for SqlServer?

2. Хтось відчував це, оскільки я, очевидно, вважаю, що логін, який не має дозволів, є червоною оселедець?

3. Якщо різні групи веб-серверів мають однаковий синтаксис рядка підключення, але з дещо різним пробілом, чи це призведе до того, що сервер використовує інший пул з'єднань?

Налаштування мінімальної та максимальної пам'яті - 20 ГБ і 58 ГБ відповідно. Сервер - це виділений сервер бази даних з 64 Гб оперативної пам’яті. Я не думаю, що це проблема пам’яті, оскільки вікно має пристойну тривалість сторінки. Автоматичне закриття не ввімкнено. Сервер завжди працює: це веб-сайт 24x7 із великим використанням.

1 - не можу сказати точно, мені доведеться шукати сервер, щоб копатися в собі.

2 - так, я періодично бачу це в моєму середовищі, хоча ми ще не на sql 2012 у системах, з яких ми це бачимо. Ви також можете перевірити http://blogs.msdn.com/b/psssql/archive/2013/02/13/breaking-down-18065.aspx, хоча стан 46, схоже, пов'язаний із наявністю конкретної бази даних = xxx у рядок з'єднання, чи існує цей db?

У тому, як налаштована моя мережа, я підозрюю, що це автоматичне закриття сеансів tcp після 5 хвилин простою - це проблема - ні db, ні клієнт не закривають сеанс, тому пул з'єднання все ще вважає, що з'єднання відкрите і намагається використовувати лише для того, щоб знайти, що вже не є справді відкритим. Ви не згадуєте, як налаштована мережа між вашими веб-серверами та db, можливо, ваш випадок подібний.

Іншою можливістю може бути проблема (стара, не впевнена, чи коли-небудь справді вирішена, див. Http://support.microsoft.com/kb/942861 ) проблему щодо налаштувань TCP Chimney Offload.

3 - Я розумію, що об'єднання вимагає точних збігів рядків, тому пробіл та різний порядок параметрів можуть спричинити різні пули. (Якщо я помиляюся в цьому, будь ласка, повідомте мене.)

_{Відповідь Вікі спільноти спочатку залишила як коментар автора запитання}

У моєму випадку виявилося, що це втікача таблиця реєстрації, яку хтось перейшов у багатослівний, щоб усунути проблему, але забув її вимкнути. Це закінчилося веденням запису до 1000 записів в секунду.

Інша робота - спроба видалити старі записи із таблиці. в кінцевому підсумку потрапив у вузли, як замикався при спробі видалення, блокуючи всі ті вставки, у яких не вистачало ресурсів пулу з'єднань.

Як тільки я знайшов роботу, обрушив голову людині, яка зловживала своїми правами на цьому сервері, і зупинив роботу, усі повідомлення про помилки для пулів підключення припинилися.