を使用してコードから呼び出すストアド プロシージャが多数ありますExecuteNonQuery。
それはすべて良かったのですが、今日、2 つのストアド プロシージャが断続的にタイムアウトし始めました。
タイムアウトになりました。操作が完了する前にタイムアウト期間が経過したか、サーバーが応答していません。ステートメントは終了されました。
管理スタジオから手動で sp を実行しても問題ありません。
私のデータベースでは最近何も変更されていません-私のコマンドタイムアウトはデフォルトのものです。
どんな手掛かり？
編集
SP に対するテーブルが実行されています。それは巨大です --> 15 ギグ。ボックスを再起動しました-同じ問題ですが、今回は SP を Management Studio から実行することもできません。
ありがとう！
これらのプロシージャを再コンパイルしてみてください。私はそのような問題を数回経験し、問題の原因を見つけられませんでしたが、再コンパイルは常に役に立ちます。
編集：
proc を再コンパイルするには、管理スタジオに移動し、プロシージャを開いて変更し、F5 キーを押すか、次のコマンドを実行します。EXEC sp_recompile 'proc_name'
管理スタジオは、実行するクエリ/コマンドに無限のタイムアウトを設定します。コードからのデータベース接続には、コマンド オブジェクトで変更できるデフォルトのタイムアウトがあります。
これは、多くの場合、次のことに関連する可能性があります。
SET オプションにより、特定のインデックス タイプが使用できなくなる可能性があります (たとえば、「昇格された」xml/udf クエリを含む、永続化された計算列のインデックス)。
コマンドタイムアウトを設定していますか? 最近、このプロセスに時間がかかる原因となっているデータベース内の何かが変更されましたか?
ロックの問題を診断する必要がある場合は、sp_lock などを使用する必要があります。
procs の 1 つのソースを共有できますか?
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx
わかりました-これが最終的に修正した方法です。
4,500 万のレコードを持つテーブルのクラスター化されたインデックスが SQL サーバーを停止していました。コードからのすべての挿入により、回答で説明されている厄介なタイムアウトが発生しました。タイムアウトの許容値を増やしてもスケーラビリティの問題は解決しないので、インデックスをいじって、主キーのクラスター化されたインデックスを非クラスター化することで状況のロックを解除しました。
これがどのように問題を解決したかをよりよく理解するために、これに関するコメントをいただければ幸いです。
データベースの統計を更新する必要がある場合があります。また、テーブルのインデックスは最近変更されましたか?
SP の実行計画をチェックして、ボトルネックを見つけられるかどうかを確認します。以前は正常に動作していたとしても、より効率的に動作するように調整できる可能性があります。
また、どのくらいのデータが返されますか? 過去に、累積レポートが結果セットにより多くのデータを持ち始めるまで表示されなかった、不十分に設計された SQL に関する問題がありました。あなたのSPが何をしているのかわからないので、これが可能かどうかはわかりませんが、調査することは言及する価値があります.
その上で SQL プロファイラーを取得し、Management Studio で実行した場合とアプリ経由で実行した場合の結果を比較します。
私の場合、操作テーブルのクラスタ インデックスを再編成したところ、タイムアウトの問題は解決しました。また、select * from tableクエリ時間は 2 秒に短縮されました。インデックスを再編成する前は、ほぼ 30 秒でした +