エラーで接続プールがリセットされます：18056、重大度：20、状態：46。Perfmonカウンターが表示されない

SQL認証（接続プールの数を減らすため）と.NET 4.0接続文字列を使用して、Windows 2008 R2 Enterprise Server上のSQL Server Enterprise Edition 2012 SP1に接続しています。

Microsoft SQL Server 2012（SP1）-11.0.3000.0（X64）
2012年10月19日13:38:57
Copyright（c）Microsoft Corporation
Enterprise Edition（64ビット）on Windows NT 6.1（Build 7601：Service Pack 1）

Webサイトの異なる部分にある8つの異なるグループに分割された約50台のサーバーを使用します。

当社のWebサイトでは、このSQL Serverを使用して訪問追跡データを記録しています。過去数日間にわたって、接続プールのリセットに関する次のメッセージが吐き出されました。

クライアントは、接続プーリング用にリセットされたSPID 1327のセッションを再利用できませんでした。失敗IDは46です。このエラーは、以前の操作が失敗したことが原因である可能性があります。このエラーメッセージの直前に、失敗した操作のエラーログを確認します。

エラーログの読み取り：

エラー：18056、重大度：20、状態：46
。クライアントは、接続プーリング用にリセットされたSPID 959のセッションを再利用できませんでした。失敗IDは46です。このエラーは、以前の操作が失敗したことが原因である可能性があります。このエラーメッセージの直前に、失敗した操作のエラーログを確認します。
ユーザー 'xxxx'のログインに失敗しました。理由：接続でのログインの再検証中に、ログインオブジェクトで構成されたデータベース 'xxxxxxxx'を開くことができませんでした。[クライアント：10.xx.xx.xxx]

：いくつかの掘削後、私はCSSのブログにこの文書を発見したエラー18056 -クライアントが接続プーリングのためにリセットされたSPIDとのセッション##、再利用することができませんでした：それはしくみとアーロン・ベルトランこの1：トラブルシューティングエラー18456を。私はエラー番号が異なることを知っていますが、障害IDは同じであり、メッセージの数は同じです）。

失敗ID 46は、ログインに権限がなかったことを示しています。ログインはデフォルトでmasterデータベースになり、db名は接続文字列で指定されます。

接続文字列プールなどの数を確認したいと思い、Perfmonのすべてのカウンターを確認しました.Net Data Provider for SqlServer。defaultdomain9675インスタンスのオプションしか提供されなかったため、Datacentreネットワークのシステム生成ID名を想定しています。残念ながら、すべてのカウンターはゼロを読み取っています。他のメインサーバーの1つでは、接続プールは約10をホバリングしています。

私の質問は3倍です

1. Windows 2008 R2 Serverが表示されない理由を誰でも提案できます.Net Data Provider for SqlServerか？

2. 私が明らかに権限を持たないログインは赤いニシンであると信じているので、誰もこれを経験しましたか？

3. Webサーバーの異なるグループが同じ接続文字列構文を使用しているが、空白がわずかに異なる場合、サーバーは別の接続プールを使用しますか？

最小および最大メモリ設定は、それぞれ20GBおよび58GBです。サーバーは、64GBのRAMを備えた専用のデータベースサーバーです。ボックスには十分なページ期待があるように見えるので、メモリが問題だとは思わない。自動クローズは有効になっていません。サーバーは常に稼働しています。これは、使用率の高い24時間365日のWebサイトです。

1-確かに言うことができない、私は自分自身を掘るためにサーバーを見つける必要があります。

2-はい、私はこれを私の環境で定期的に見ていますが、SQL 2012ではまだこれを見ているシステムではありません。また、http：//blogs.msdn.com/b/psssql/archive/2013/02/13/breaking-down-18065.aspxを確認することもできますが、State 46は、特定のDatabase = xxx接続文字列、そのデータベースはまだ存在しますか？

ネットワークのセットアップ方法は、ネットワークが5分間アイドル状態になった後のtcpセッションの自動クローズが問題であると考えています-データベースもクライアントもセッションをクローズしていないため、接続プールは接続が開いていると考えて使用しようとします本当に開いていないことがわかるだけです。Webサーバーとdbの間のネットワークがどのように構成されているかは言及していませんが、おそらくあなたのケースは似ています。

別の可能性としては、TCP Chimney Offloadの設定に関する問題（古い、実際に解決されたかどうかは不明です。http：//support.microsoft.com/kb/942861を参照）が考えられます。

3-私の理解では、プーリングには正確な文字列の一致が必要であるため、空白とパラメーターの順序が異なると、プールも異なります。（私がそれについて間違っていたら、私に知らせてください。）

_{コミュニティのWikiの回答は、質問作成者が元々コメントとして残したものです}

私の場合は、誰かが問題をトラブルシューティングするために冗長に切り替えたが、スイッチを切るのを忘れていた暴走ログテーブルであることが判明しました。最終的に1秒間に最大1000レコードを記録しました。

別のジョブがテーブルから古いレコードを削除しようとしました。削除しようとするとロックアップし、接続プールのリソースを使い果たしたすべての挿入をブロックするため、最終的にはノットに陥りました。

ジョブを見つけて、そのサーバーの権限を悪用した人を頭の中で叩き、ジョブを停止するとすぐに、接続プールのすべてのエラーメッセージが停止しました。