弊社には、SQL Server 2005 (64 ビット) マシンでデッドロックが発生する原因となっていると思われるサードパーティの商用アプリケーションがあります。先週、ソフトウェア ベンダーによるソフトウェア管理の改善を目的とした 1 日半のトレーニングを終え、現在は SQL Server Profiler とトレース テンプレートを最大限に活用する方法について調査中です。
私の個人的なモットーは、「クライアントのサーバーにリモート接続する必要があるアプリケーションを開発しているソフトウェア ベンダーであれば、それは間違っている」というものです。残念ながら、現時点では選択肢はあまりありません。
これらの人々 (ソフトウェア ベンダー) について知れば知るほど、私は彼らに感心しなくなり、自分で「舞台裏」の仕事をしたいという気持ちが強くなります。たとえば、サーバーの速度が極端に低下するという問題が数か月間続いていますが、現時点では、システム上にトレース ファイルやトレース テンプレート ファイルはまったく見当たりません。
私の質問に移ります...
トレース ファイルを実行すると、サーバーのパフォーマンスに顕著な影響がありますか? 私の推測では、答えは「場合による」でしょう。その場合、私が作成した新しいトレース テンプレートで選択した「イベント」は次のとおりです。
- デッドロックグラフ
- ロック: デッドロック
- ロック: デッドロックチェーン
- RPC:完了
- SP: 完了
- SQL:バッチ完了
- SQL:バッチ開始
トレースはデッドロックが実際に発生する前に実行する必要がありますか、それともパフォーマンスが大幅に低下したことに気付いた時点でトレースを実行できますか?
現在、SQL ログを確認するためのヒントやテクニックについて調べています。これまであまり注意を払ってこなかったからです。SQL Server Management Studio で管理と SQL Server ログに移動しても、「デッドロック」や「デッドロック」などの表示は見つかりません。おそらく、デッドロックは発生していないのでしょう。デッドロックが SQL ログに表示されるかどうか、また、表示される場合は、エントリを見つけるために検索条件に何を使用できるか、誰か確認してもらえますか?
答え1
SQL Server でトレースを実行すると、SQL Server に影響します。基本的な経験則として、サーバー上で実行する操作はすべてリソースを消費します。SQL Server に対してトレースまたは SQL プロファイラーを実行すると、パフォーマンスの問題が発生する可能性がありますか? はい、フィルタリングが行われていない場合は、確かに発生します。
デッドロックの問題がある場合はオンにしますトレースフラグ 1204 および 1222これにより、デッドロックに関する情報がエラー ログに出力されます。パフォーマンスに影響するため、これらを常にオンのままにしないでください。エラー ログに出力される情報には、デッドロックの一部であったステートメントに関するすべての情報が記載されています。
答え2
診断ログを実行する場合、痕跡、それはより少ないリソースを消費しますプロファイラーしかし、いつものように、答えはサーバーの仕様と、通常の運用中に一度にどれだけの作業が行われているのかによって異なります。SQL 2005 のみを使用しているので、ハードウェアが少し古いと想定されます。つまり、運用ボックスで実行する場合は注意が必要です。問題のトラブルシューティングを半盲目的に行う場合や、新品のボックスで行う場合でさえ、これはあまりお勧めできません。
2 番目については、何かをキャプチャしようとしている場合は、診断を実行してから、デッドロックの原因を実行する必要があります (アプリケーション、またはアプリ全般の特定の理由またはイベントの種類に絞り込んでいると仮定します)。
残念ながら、#3 についてはあまり役に立ちません。