web-dev-qa-db-ja.com

SQL Serverのトレースは運用環境で「有害」と見なされていますか？

コンテキスト：注意深いDBA

私たちは何度か買収されており、最新の支配者には、運用データベースサーバーを注意深く保護するDBAがいます。

全体的にこれは良いです。

ただし、開発者とDBAの間で1点の競合が発生しました。本番データベースサーバーに対してトレースを実行しません。

開発者としての私たちの経験：SQLサーバートレース+ RMLユーティリティは素晴らしい

以前は、アプリケーションインスタンスの動作が遅い場合、.sqlスクリプトを介してトレースを実行し、出力を圧縮して、MicrosoftのRMLユーティリティで処理していました。

GUIベースのプロファイラーツールは実行しないでください。パフォーマンスが大幅に低下します（データベースはGUIの更新を待つ必要があります）。これらのトレースは、単にデータベースサーバーのローカルファイルシステムへの「ログアクティビティ」です。スクリプトは、一度に所定の分数（たとえば、10分）トレースを実行します。

トレースとRMLユーティリティの組み合わせは非常に効果的です。レポートは使いやすいです。これはhotspots（以下を参照）を示し、レポートは有用な情報を提供し、実際の実行計画などにドリルダウンできるようにします。Oracleよりもはるかに優れていますオファー（または少なくとも数年前）。

（ホットスポット：クエリに1/10秒かかるが、40万回実行される場合、30秒かかる1回実行されたクエリよりもレポートの上位に表示されます。）

私は長年にわたって少しパフォーマンスの仕事をしてきました。私の経験では、「実際の負荷がかかっている実際のデータベース」から「実際のデータ」を取得することは、プログラマーが「推測」し、想像する問題をシミュレートするよりも優先されます。これが、SQL Serverのトレースが問題を解決するためのかなりの「特効薬」であると私が思う理由です。

私の質問

  • 本番環境でのSQL Serverトレースの実行に対する主な正当な懸念事項は何ですか（ディスクがいっぱいになる、パフォーマンスが低下するなど）。
  • これらの懸念は有効ですか？もしそうなら、どのようにそれらに対処できますか？
  • トレースして「実際の問題」をプロファイリングすることは、状況の理解と解決に向けた最も明確なステップのようです。代替案は何ですか？
sql-serverperformanceprofiler
5
user331465

RMLユーティリティの最新バージョン（現在（ 9.04.0051 ））は拡張イベントのトレースをサポートしているため、DBAと協力していくつかの制御されたトレースを実行できます。ヘルプファイルのスクリーンショット： enter image description here

ただし、RMLで提供されるデフォルトのトレーステンプレートにはステートメントレベルのイベント（SQL:StmtStarting、SQL:StmtCompleted、SP:StmtStarting、SP:StmtCompleted）、つまりproc。これにより、たとえば、大きなテーブル全体で実行されているSELECTステートメントのスカラー関数など、間違った条件下でサーバーが簡単に機能しなくなる可能性があります。

拡張イベント（XE）は2012年より前のバージョンでは少し制限されていましたが、より軽量です。 SQLステートメントレベルのイベントでは、非常に負荷の高いワークロード（sqlserver.sp_statement_starting、sqlserver.sp_statement_completed、sqlserver.sql_statement_starting、sqlserver.sql_statement_completed）のオーバーヘッドが引き続き発生するため、注意が必要です。実行プランのキャプチャ（sqlserver.query_post_execution_showplan）も集中的になる可能性があります。提供されており、イベントが少ないXETraceCaptureDefLightWeight.sqlテンプレートの使用を検討してください。

要約すると、XEに移行し、RMLの最新バージョンで提供される軽量のXE定義を使用することをお勧めします。

6
wBob

開発者とdbaの間で1点の競合が発生しました。本番データベースサーバーに対してトレースを実行しません。

これは、DBAにトレースを要求する内容に依存します（私はサーバー側のトレースについてのみ話しています）。

24時間年中無休のトレースが実行されているため、最小限のものをキャプチャして、特定のシナリオのトラブルシューティングに役立ちます。ユーザーエラーメッセージ、ログイン、アプリケーション。データベースを別のサーバーに移動する場合や、サーバーを使用停止にする場合などに役立ちます。

私はDBAであるため、実行計画やステートメントレベルの実行などをキャプチャするトレースは実行しません。これらのイベントにより、サーバーがダウンする可能性があります。代わりに、 sp_whoisactive-ログをテーブルに記録 を使用するか、または GlennのDMVクエリ を使用して、tsqlエージェントジョブを定期的に実行できます。これにより、サーバーのベースラインを設定し、異常を簡単に特定できます。

彼のブログの投稿 SQLトレースと拡張イベントの「オブザーバーオーバーヘッド」の測定 -ジョナサンケハイアスは結論

SQL Server 2012で実行されているシステムの場合、拡張イベントはオーバーヘッドを最小限に抑え、SQLトレースと同様のイベントと列の機能を提供します。

したがって、SQL Server 2012以降を使用している場合は、すべてのトレースを同等の拡張イベントに移行することをお勧めします（これは、現在実装中のプロセスです）。

本番環境でMSSQLトレースを実行することに対する主な正当な懸念は何ですか？ （ディスクをいっぱいにする、パフォーマンスを低下させるなど）

いいえ、主な関心事は、トレースするように構成したイベントです。また、すべてのトレースファイルを別のサーバーに配置するジョブを作成し、RMLユーティリティを使用してPRODサーバーから離れた場所でトレースファイルを処理することもできます。 WMIアラート を設定して、別のサーバーにそのトレースファイルをプッシュおよびプッシュすることもできます。

これらの懸念は有効ですか？もしそうなら、どのようにそれらに対処できますか

ファイルのサイズとロールオーバー時間の上限を指定しない場合は、ディスク容量も問題になります。上限MBが指定されておらず、一定の時間経過後にロールオーバーしない場合、トレースファイルは静かに大きくなります。

トレースして「実際の問題」をプロファイリングすることは、状況の理解と解決に向けた最も明確なステップのようです。代替案は何ですか？

AaronとwBobが述べたように、 プロファイラ（サーバー側トレース）からXEventsへのジャンプ（Erin's PASS 2014ビデオ）。

補足として、トレースデータを分析するための別の方法は、 SQLNexus または ClearTrace を使用することです。

1
Kin Shah