Пулы соединений сбрасываются с ошибкой: 18056, серьезность: 20, состояние: 46. & Счетчики производительности не отображаются

Мы используем проверку подлинности 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 октября 2012 г. 13:38:57
Авторские права (c) Microsoft Corporation
Enterprise Edition (64-разрядная версия) на Windows NT 6.1 (сборка 7601: пакет обновления 1)

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

Наш веб-сайт использует этот SQL Server для регистрации данных отслеживания посещений. За последние несколько дней он выдал следующие сообщения о сбросе пулов соединений:

Клиент не смог повторно использовать сеанс с SPID 1327, который был сброшен для пула соединений. Идентификатор ошибки - 46. Эта ошибка могла быть вызвана ошибкой предыдущей операции. Непосредственно перед этим сообщением об ошибках проверьте журналы ошибок на наличие ошибок.

Журнал ошибок гласит:

Ошибка: 18056, уровень серьезности: 20, состояние: 46.
Клиенту не удалось повторно использовать сеанс с SPID 959, который был сброшен для пула соединений. Идентификатор ошибки - 46. Эта ошибка могла быть вызвана ошибкой предыдущей операции. Непосредственно перед этим сообщением об ошибках проверьте журналы ошибок на наличие ошибок.
Не удалось войти в систему для пользователя 'xxxx'. Причина: не удалось открыть базу данных «xxxxxxxx», настроенную в объекте входа, при повторной проверке имени входа в соединении. [КЛИЕНТ: 10.xx.xx.xxx]

После некоторого поиска я нашел этот документ в блоге CSS: Как это работает: Ошибка 18056 - Клиенту не удалось повторно использовать сеанс с SPID ##, который был сброшен для пула соединений, и этот Аарон Бертран: Устранение ошибок 18456 , Я знаю, что номер ошибки отличается, но идентификатор ошибки совпадает с количеством сообщений идентичны).

Идентификатор сбоя 46 предполагает, что у входа не было разрешений. Наши логины по умолчанию имеют основную базу данных, а имя БД указывается в строке подключения.

Я хотел проверить количество пулов строк подключения и т. Д. И проверил все счетчики в Perfmon .Net Data Provider for SqlServer. Это только дало мне возможность defaultdomain9675для экземпляра, поэтому я выбрал это, предполагая, что это сгенерированное системой имя для нашей сети центра обработки данных. К сожалению, все счетчики читают ноль. На одном из наших других основных серверов пулы соединений колеблются около 10, что я ожидал увидеть на работоспособном сервере с такой нагрузкой.

Мой вопрос в 3 раза

1. Кто-нибудь может подсказать, почему Windows 2008 R2 Server не отображается .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 в строка соединения, эта база данных еще существует?

То, как настроена моя сеть, я подозреваю, что проблема заключается в автоматическом закрытии tcp-сессий после пяти минут простоя - проблема не в том, что ни db, ни клиент не закрывают сеанс, поэтому пул соединений все еще считает, что соединение открыто и пытается использовать это только, чтобы найти, что это действительно не открыто больше. Вы не упоминаете, как настроена сеть между вашими веб-серверами и БД, возможно, ваш случай похож.

Другой возможностью может быть (старая, не уверенная, если когда-либо действительно решенная, см. Http://support.microsoft.com/kb/942861 ) проблема с настройками TCP Chimney Offload.

3 - Насколько я понимаю, для объединения требуются точные совпадения строк, поэтому пробелы и другой порядок параметров могут привести к различным пулам. (Если я ошибаюсь, пожалуйста, дайте мне знать.)

_{Сообщество Wiki ответа изначально оставил как комментарий автора вопроса}

В моем случае это была таблица безудержных журналов, которую кто-то переключил на многословную для устранения проблемы, но забыл выключить. Это закончило регистрацией до 1000 записей в секунду.

Другая работа пыталась удалить старые записи из таблицы. закончил тем, что завел себя в узлы, так как блокировался при попытке удаления, блокируя все те вставки, у которых не хватало ресурсов пула соединений.

Как только я нашел работу, ударил человека, который злоупотребил своими правами на этом сервере, и остановил работу, все сообщения об ошибках для пулов соединений прекратились.