SQL Server 2005インスタンス上で実行されているアプリケーションがあり、このアプリケーション(未発表)が週に数回、SQL Serverをフリーズさせます。 SQL Serverサービスを再起動することすらできません。マシン全体を再起動する必要があります。
言うまでもなく、クエリウィンドウを開いてsp_who2
を実行して原因を見つけることはできません。問題が再発するまで数日かかる場合があります。 SQL Serverがフリーズする原因を追跡するために、どのような種類のログを記録できますか?
exec xp_readerrorlog
は、再起動後に何が起こったかを表示するだけなので、あまり役に立ちません。
フリーズ時には、CPUは90〜97%で固定され、メモリは最大8 GBです。サーバーの容量は12 GBですが、SQL Serverの最大値は8192に設定されています。
SQL Serverには専用の管理接続があります。 方法:SQL Server Management Studioで専用管理者接続を使用する を参照してください。 DACは、事前に予約された個別のリソース(メモリ、CPU、IOポートなど))を正確に使用するため、サーバーが「フリーズ」している場合でも使用できます。DACから次のクエリを実行できますスパイクの原因を特定できます。
サーバーを再起動すると、ERRORLOGは削除されず、リサイクルされます。シャットダウン前のエラーログは通常ERRORLOG.1
、次にERRORLOG.2
など、現在のフォルダと同じフォルダにあります。それを開いて、ファイルの末尾を調べてください。以前の再起動ログはおそらくまだそこにあります。調べて、何が見つかるかを確認してください。また、.mdmp
同じ場所にあるファイル...
あなたの状況であなたに最も役立つ2つのルートを調べることをお勧めします:
PERFMONカウンターを監視します-特に% Processor Time
とともに SQLDiag
SQL Server 2005サーバーでは、SQLDiagユーティリティが次のフォルダーにSQLDiag.exeファイルとして存在します– [systemroot]\Program Files\Microsoft SQL Server\90\Tools\Binn。 SQL Server 2008ボックスでは、SQLDiagは[systemroot]\Program Files\Microsoft SQL Server\100\Tools\Binnの下にあります。 SQLDiagは、収集するデータを指定するために使用できるXML構成ファイルを使用します。
疑わしい場合は、 プロセスモニター を実行します。また、 ProcDump は、特定のプロセスのダンプを取得するのに役立ちます。 sysinternalsの非常に便利なツール。
ProcDumpにはパラメータ-c
プロセスのダンプを作成するCPUしきい値。
優れたリファレンス:
PerfMonを使用して、いくつかのSQL Serverカウンターを追跡できます。
http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/
最もリソースを集中的に使用するクエリのプランキャッシュを確認することをお勧めしますが、前回の再起動以降のクエリのみが表示されます。ただし、そのうちの1つが正しい方向を示している可能性があります。
http://www.brentozar.com/responder/get-top-resource-sumption-queries/
エラーログを読むこともできます。
http://msdn.Microsoft.com/en-us/library/ms187109%28v=sql.90%29.aspx