エラーで接続プールがリセットされる：18056、重大度：20、状態：46。＆パフォーマンスモニターカウンターが表示されない

Question

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
著作権（c）Microsoft Corporation
Windows NT 6.1（Build 7601：Service Pack 1）上のEnterprise Edition（64ビット）

私たちは、ウェブサイトの異なる部分を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 ##のセッションを再利用できませんでしたおよびAaron Bertrandによるこれ：トラブルシューティングエラー18456 。エラー番号は異なりますが、エラーIDは同じで、メッセージの数は同じです）。

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

接続文字列プールの数などを確認し、Perfmonのすべてのカウンターを.Net Data Provider for SqlServer。 defaultdomain9675をインスタンスに使用したので、Datacentreネットワーク用にシステムで生成されたID名であると想定して選択しました。残念ながら、すべてのカウンターはゼロを読み取っています。他のメインサーバーの1つで、接続プールが約10をホバリングしています。これは、そのような負荷のある正常なサーバーで予想されるものです。

私の質問は3倍です

Windows 2008 R2サーバーが表示されない理由を誰かが提案できますか.Net Data Provider for SqlServer？
権限を持たないログインは赤ニシンだと私がはっきりと信じているので、誰かがこれを経験しましたか？
Webサーバーの異なるグループが同じ接続文字列構文を持っているが、空白がわずかに異なる場合、サーバーは別の接続プールを使用するのでしょうか？

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

crummel4 · Answer

1-確かに言えない、自分を掘り下げるサーバーを見つけに行かなければならない。

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

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

別の可能性としては、TCP Chimneyに関する問題（古い、本当に解決されたかどうか不明、 http://support.Microsoft.com/kb/942861 を参照））が考えられます。オフロード設定。

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

Paul White 9 · Answer

_{コミュニティWikiの回答は、質問の作成者によるコメントとして最初に残されました}

私の場合、誰かが問題をトラブルシューティングするために詳細に切り替えたが、オフにするのを忘れた、暴走ロギングテーブルであることがわかりました。最終的には、1秒間に最大1000件のレコードがログに記録されました。

別のジョブが古いレコードをテーブルから削除しようとしました。削除しようとするとロックされ、接続プールのリソースを使い果たしてしまったすべての挿入をブロックしてしまうので、結局それ自体が結び目になってしまいました。

私が仕事を見つけ、そのサーバーでの権利を乱用した人の頭を叩き、仕事を止めるとすぐに、接続プールのすべてのエラーメッセージが止まりました。