以前にこの問題が発生したことがありますが、基本的に接続が十分に速く閉じられていないことがわかりました (接続を開いたままにしてガベージコレクションを待つことは、実際にはベストプラクティスではありません)。
今、私は再びそれを取得していますが、接続を開いたままにしている場所を見つけることができないようです. その時までに、データベースが古い接続をクリアしたというエラーが表示されるため、最後のコマンドでロックされたすべての接続が表示されません (前回この問題が発生したときに非常に役立ちました)。
問題のあるコードを見つけることができるように、何が起こっているのかを追跡するためにコードまたはデータベースをどのように計測できるか考えていますか?
提供しているエラーは、実際には開いたままの接続を示しているわけではありません。アプリケーションが予想するよりも時間がかかっているクエリがある可能性が高くなります。応答を待つ時間を増やすことができ、SQLを使用して最も負担の大きいクエリを見つけることができます。
うまくいけば、たくさんのクラスではなく、1つのデータアクセス層クラスがあり、それぞれが独自の接続を作成しますよね？どの言語を使用していますか？C＃を使用している場合、この問題の最大の原因はDataReadersとこれらのオブジェクトを上位層に返すことです。ほとんどの場合、一部のクライアントクラスは、DALクラスから受信したDataReaderを閉じておらず、接続が開いたままになっている/ロックされたままになっています。返されるDataReaderを追跡し、クライアントクラスがそれらを適切に閉じ/破棄していることを確認します。
また、Disposableパターンを実装し、場合によってはデータ（...テーブル、...セット、...リーダー）オブジェクトの代わりにPOCOを返すことで、データアクセス層を再設計することも考え始めます。