今回はデータ件数の異なるテーブルを結合条件に指定した場合に、from句で指定するテーブルの順番によって、パフォーマンスにどれくらいの違いが出るのか検証します。 ・テーブル結合を含むSELECT文の実行時間を計測 (1)INとEXISTSについて テーブルを結合するようなSQLを実行する際、パフォーマンスを考慮しfrom句で指定するテーブルの順番を考え直すといった場面があるかと思います。 SQL 実行計画解析、EXPLAIN、表走査、索引走査. Bツリー索引では、NULL値は格納されていませんのでNULL比較(IS NULL、IS NOT NULL)をWHERE句の条件に指定すると索引は使用されせん。また、NOT(!=、<>なども)を使用した場合も索引は使用されません。これは、指定した条件に一致しないものを求めることになるため、フルスキャンの方が速いという判断からです。そのため、NULL比較をしなくても良いようにNULL値に意味を持たせないようにして下さい。また、NOTは別の条件に変えることを検討して下さい(例えば、INやORに置き換えるなどです。ただし、「(4)INリストまたはORを使用している」で説明しているように、値指定が多くなると効率が悪くなるので、注意して下さい)。できれば使用しなくても良いように設計して下さい。 それでは、次回まで、ごきげんよう。. ○ select * from dept where dept_id = :dept_id; ○ select * from emp where salary between 0 and 3000; × select dept_id, sum( salary ) from emp group by dept_id having dept_id = 'D02'; ○ select a.emp_id, a.emp_name from emp a; ○ select a.emp_id, a.emp_name from emp a order by salary; × select distinct a.emp_id, a.dept_id from emp a,dept b, × select distinct a.emp_id, a.dept_id from emp a. Please try again. パフォーマンスの監視とチューニング Monitor and Tune for Performance. コストベース・オプティマイザ採用のOracle11gでオプティマイザ・ヒントを用いて、「from句の順番=Oracleが検索するテーブルの順番」によって、パフォーマンスにどれくらいの違いが出るのかを検証します。, Oracleのオプティマイザは、データベースへの問い合わせ時にデータに対して最適なアクセス方法を考えてくれる機能です。その種類として、前述しました「ルールベース・オプティマイザ」と「コストベース・オプティマイザ」についても少し触れておきます。, Oracle10g以降はサポートされていないとはいえ、初期化パラメータ次第ではまだRBOを利用できるので、利用しているところは多いかもしれません。 追加検証でも5回実行して平均値を採用しますが、検証結果では平均値のみ公開します。, 特筆すべきは1つ目に1000000件を指定した場合ですね。2つ目に指定した件数に関わらず実行時間がかかってしまっています。, 今回の検証結果では、以下のようになりました。 ・100件 Oracle SQLチューニング講座(1) Oracle SQLチューニング講座(1)-2. ステム モニター (perfmon とも呼ばれます) を使用して、パフォーマンス カウンターで, Using System Monitor (also known as perfmon) to measure the performance of, すべてのページ フィードバックを表示, エンタープライズ全体の管理の自動化, Automated Administration Across an Enterprise, 以前のバージョンのドキュメント. 今回は、詳しく聞きたいというご要望のありました「パフォーマンスの良いSQL文ついて」まとめて説明しようと思います。すべてのパターンについて解説はできませんが、第4回で少し説明した実行計画を使用して説明しますので、実行計画などを見るときの参考にもして下さい。 このサイトを検索 . Guest Author. ・10000件 今回はSQL文のノウハウの一部について説明しました。他にも(PL/SQLなど)いろいろありますが、またの機会とさせていただきます。まだ暑いですが皆さま体調に気を付けて下さい。次回も頑張りますのでよろしくお願いします。質問をお待ちしています。 ョンの数です。, 1 秒当たりの接続リセットの合計数です。, 生成された重複する tempdb 行セット ID の数です。, プラン生成時にプラン ガイドを受け付けることができなかったプラン実行の 1 秒当たりの数です。, プラン ガイドを使用してクエリ プランが生成されたプラン実行の 1 秒当たりの数です。, Microsoft SQL Server のパフォーマンス監視. これは索引が使用されない場合もありますが、効率が悪い索引アクセスになる場合もあります。以下のようにINリストやORを使用している場合には、1回のフルスキャン又はアクセス範囲の大きい索引範囲スキャンを行う場合よりも、値指定された回数の索引一意スキャン(又はアクセス範囲の小さい索引範囲スキャン)の方が効率が良い場合があります。, 以下のSQL文のようにUNION ALLを使用することで、そのようにアクセスさせることができます。ただし、INリストに多数の値指定をしていたり、ORで多数連結している場合はUNION ALLのオーバーヘッドが大きくなるので注意して下さい。, これについては、オプティマイザがOR-EXPANSION(OR拡張)として自動的に行ってくれるようになっています(以下のように実行計画にCONCATENATIONと出力されるとOR拡張が行われたことを意味します)ので、明示的にUNION ALLを指定する必要はありませんが、このような動作になっていることは知っておくと良いと思います。OR拡張を行っていないときはUSE_CONCATヒントで明示的にOR拡張を行ってみると効果があるかもしれません。また、NO_EXPANDヒントを使用してOR拡張を使用しないようにもできます。オプティマイザ統計が正確でないために誤った判断をする場合もありますので知っておくと便利かと思います。, ■3.その他の参考になること ルールに従うという所が見えやすくて分かりやすいからですかね。, ※以降の表記は下記の通り省略します。 Buffer pool 5G 4385.18 5.5% 33% Buffer pool 30G (All data in cache) 36784.76 36% 8% アクセス頻度の高いデータをメモリに格納 • DBT-2 ベンチマーク (更新処理が多数) • 20-25GBの”ホット”なデータ (200 warehouses, 1時間実行) • Nehalem 2.93GHz x 8 cores, MySQL 5.5.2, 4 RAID1+0 HDDs Oracle University 無償オンラインセミナー(11月) ご存知ない方のために、ここで索引スキップ・スキャンについて簡単に説明します。 (2)列を演算(関数を使用)している Oracle University の無償オンラインセミナーに参加しませんか。11月は限定で ORACLE MASTER SQL文の見直し. ■2.索引を使用しない →SQL実行画面の「実行計画ボタン」をクリックすると確認できます。, 上記の通りfrom句の順番を変えても変化はありませんので、今回の検証ではオプティマイザ・ヒントを付けてfrom句の順番でアクセスする順番が変わるようにしました。, from句の順番と今回の検証方法について触れたところで、遅くなりましたが今回実行するSQLは以下の通りです。, データ件数の多いテーブルに、先にアクセスするSQLの方が、かなり時間がかかる結果となりました。その差は歴然ですね。, 今回は検証を追加し、データ件数にバリエーションを増やして、様々な組み合わせで実行時間を計測します。 ・100000件 db2batchとは?SQLスクリプトを実行し、計測結果を出力するツール。スクリプト内にメタ情報を設定することで、様々な条件でパフォーマンスを計測できる優れもの。基本的なdb2batchの使い方サンプル簡単なSQLスクリプトファイルを作って、db2batchで実行させてみる。 そうなると、SQL分のチューニングが自動的に行われ、from句の順番を考慮する機会はほとんど無くなりつつあります。, では今回の検証は取りやめに……しません!! まずは、良いSQL文とはどのようなものなのかを説明します。簡単に言うとリソースをできるだけ使用しないようにすることですが、なかなか難しいと思いますので参考になるポイントをまとめてみました。 Microsoft SQL Server 2005 に関するパフォーマンス測定値 . 津島博士のパフォーマンス講座 第78回 Oracle DatabaseのJSONについて, Maximum Security Zonesで、クラウドのセキュリティ対策の弱体化を防ぐ, 列c3に(チェックする文字位置が固定であればLIKEをSUBSTR関数にして)ファンクション索引を作成する. ・CBOの場合はアクセス順が変わらない場合がある(オプティマイザの判断), 今回の検証では、オプティマイザ・ヒントを利用して「from句の順番=アクセスする順番」が変わることで、パフォーマンスに違いが出ることが確認できました。 データの内容、件数、処理内容などによっては結果が異なるかと思われますが、今回の検証結果ではデータ件数を考慮した実行SQLのメンテナンスが非常に重要であることがわかりました。, また、from句で指定する順番のうち、一つ目のテーブルに大きく影響を受けるということが確認できました。 ・1000件 ・一つ目にアクセスするテーブルの影響が大きい 【データ件数バリエーション】 「コストベース・オプティマイザ」 → 「CBO」, 今回は格納されているデータ件数の異なるテーブルを用意し、そのテーブルを結合するSQL文の実行時間を、from句の指定順番を変えながら計測します。, ・サンプルテーブルにそれぞれ100件、100万件のデータを作成 - CYBER SECURITY)による"Prevent a weak cloud security posture with Maximum 以下の二つのSQL文は実行結果が同じですが、実行方法は異なります。, 上記の【1】のSQL文は、以下のSQLと同じように実行されます。実行計画を見ると一意性処理(HASH UNIQUE)が行われているのが分かります。一意性処理は、副問合せの結果件数が多いと負荷が大きくなるので注意する必要があります。そのような場合は、オプティマイザが一意性処理しないように(【2】のように)実行すると思いますが、知っておくと便利だと思います。それから、「(2)結合は件数を絞り込んでから」の説明にあるように、重複データが多い場合は効率が良い可能性があることを知っておいて下さい。, (2)結合は件数を絞り込んでから 「ルールベース・オプティマイザ」 → 「RBO」 sqlのコーディング方法を統一して、キャッシュ上で共有されるようにしましょう。 下記4つのSQLは、処理内容は同じですが、それぞれ、メモリ上にキャッシュされ、再利用されません。 いつものようにSI Object Browserのデータ生成機能を使って準備します。(第1回参照), ②実行SQLを準備 11/27/2018; この記事の内容. Gold DBA のセミナー、Oracle Certified... 津島博士のパフォーマンス講座 Indexページ ▶▶ ②実行SQLを準備 実行SQLの準備ですが、前述したようにCBOでは自動的に最適なアクセスパスを判断するため、from句の順番を変えても実行計画が変わらず、パフォーマンスに影響し辛くなっています。 実際に実行計画を確認してみましょう。 Oracle SQLチューニング講座(5) SQLトレースの解析. 皆さんこんにちは、まだまだ暑いですが体調はいかがでしょうか。私はどうにか頑張っております。 サーバーのパフォーマンスと利用状況の監視 Server Performance and Activity Monitoring. db2batchとは?SQLスクリプトを実行し、計測結果を出力するツール。スクリプト内にメタ情報を設定することで、様々な条件でパフォーマンスを計測できる優れもの。基本的なdb2batchの使い方サンプル簡単なSQLスクリプトファイルを作って、db2batchで実行させてみる。 索引は先頭からの条件指定でないと使用されませんが、この機能を使用することで指定していない先頭の部分をスキップして索引を使用します。具体的にどのようにして索引を使用するかというと、列c1,c2の複合索引があるテーブルに次のSQL文を実行したとします。, このとき列c1の値が'A'と'B'だとすると、内部的には以下のSQL文のように実行して索引スキャンを行います。つまり、先頭の値のカーディナリティが高いと効率が悪いことになります(そのような場合や条件のヒット率が高い場合はオプティマイザが選択しないようにすると思います)。, (4)INリストまたはORを使用している 次の指標は、 Microsoft SQL Server 2005 システムで監視できます。 Process(sqlservr)\% Processor Time % Processor Time は、このプロセスのすべてのスレッドが命令を実行するためにプロセッサを使用した経過時間の割合です。 はじめに. 件数が多いテーブルの結合は負荷が大きいため、件数を少なくしてから行った方が良いです。ただし、すべてのSQL文がそのように処理されるとは限りません。例えば、以下のSQL文はWHERE句の条件(B.c2 = 10)であまりデータを絞り込めない場合には、そのようには実行されません。ただし、tab2.c1(GROUP BYを行わないテーブルの結合列)が重複キーが多い場合には、SQL文を書き換えることで件数を少なくしてから結合することができます。, 以下のSQL文に変更すると効率が良くなる場合があります(これは少し高度だと思いますが、同じ結果になることを理解できるようになると、いろいろ工夫できるようになると思います。さすがにオプティマイザもここまでは変換しませんから、私は最後の手段として結構行うことがあります)。, (3)ソート処理はできるだけ少ない件数で行う 以下のような列の演算をしているSQL文では索引は使用されません。これは、演算結果の値とその値のオプティマイザ統計が格納されていないため索引を使用することができないからです。, 置き換えができない場合には、以下のようなファンション索引を作成することで索引が使用されます。ただし、あまり闇雲に作成するのではなく、できるだけ演算や関数を使用しないようにして下さい(第6回で説明したように、索引が多いと更新時のオーバーヘッドが増えてしまいます)。, それから、明示的に関数を使用していない場合でも、比較する型が異なることによる暗黙的なデータ型変換が行われている場合もあります。その場合でも索引は使用されませんので注意して下さい(例えば、文字型に数字を比較するとTO_NUMBER関数が実行されてしまうなどです)。 確認にはSI Object Browserの実行計画画面が便利です。 まずは生成データを下記の通り設定しました。 高速にアクセスするには、索引を使用してアクセスするのが一般的ですから、索引が使用されないSQL文を記述しないことです。そのため、どのようなときに索引が使用されないかを知っておくことも大事になります。それから、テーブルの結合やソート処理はリソースへの負荷が大きいので、効率の悪いアクセスをしないように注意が必要です。これについては、オプティマイザが良いSQL文に置き換えてくれる場合もあると思いますが、知っておくと役に立ちそうなことを、「3.その他の参考になること」として少しまとめておきました。 Oracle SQL パフォーマンス. また、対象のデータベースは「Oracle」とします。, と、ここまで説明してご存知の方からはすぐに、「Oracleのバージョンやオプティマイザの種類によって結果が異なるのではないか。」とご指摘をいただきます。 ソート処理は負荷が大きい処理になりますので、できるだけ少ないデータで行った方が高速になります。例えば、上位100件だけ出力したいときなどは以下のように記述すると良いです。ソート領域に100件しか格納しないので、ソート処理の負荷を軽減できます。, それから、パラレル処理を行う場合には注意が必要です。パラレル・ソート処理を行うときは、パラレス・スレーブ・プロセスに対してデータをレンジ分割するので、データ値によっては偏ってしまいます。そのような場合にはパラレル処理が効率よく動作しません(あまりパラレル効果がありません)。以下のSQL文の実行計画を見るとGROUP BYとORDER BYは1回のソートで処理されているので(SORT GROUP BY)、一見効率良いように思えるかもしれませんが、GROUP BYをハッシュ分割で実行(HASH GROUP BY)してレコード数を少なく(GROUP BY列の重複度が高くないと少なくならないので注意)してからORDER BY(SORT ORDER BY)を行った方が効率よい場合もあります。これはハッシュ分割の方が偏りが少ないからです。アクセスする件数が多く、ソート処理でプロセスにデータが偏っている場合は効果が良い可能性があることを知っておいて下さい。, 以下のSQL文のようにインラインビューを使用することでHASH GROUP BYを行うようにできます。NO_MERGEヒントは念のため(インラインビューがマージされないようにするために指定しています)です。, ■4.ANSI準拠の結合文 Sign in|Recent Site Activity|Report Abuse|Print Page|Powered By Google Sites, 処理内容が同じSQLでも、大文字/小文字/空白や改行の数が異なると、別々にキャッシュされてしまい、解析済みのSQLが共有されなくなるので、その分パフォーマンスが低下する。, 下記4つのSQLは、処理内容は同じですが、それぞれ、メモリ上にキャッシュされ、再利用されません。, SQLで、変数の値を設定する場合は、バインド変数を使用することによって、SQLが共有されます。, ※バインド変数の指定方法は、JAVA、SQLPLUS、ProCなど実行環境で異なる, 」を使用すれば、大文字/小文字/空白や改行の数を統一や、バインド変数を使用しなくても、, SELECTで*を使用すると、解析/IOともにパフォーマンスが低下するので、必要な項目のみ指定します。, 但し、COUNT(列名)は、指定した列がNULLの場合は、カウントしないので、プライマリキー項目などのNOT NULL列を指定する。, BETWEENは、指定された範囲評価の操作が1回で済むのに対し、ANDは複数回の操作となるので、ANDよりBETWEENの使用を検討する, HAVINGは非常に重い処理なので、集計結果の判定以外は、HAVING句よりWHERE句の使用を検討する。, UNIONはSELECTの結果をマージした後に、暗黙のソート処理をして重複データを排除しますが、重複データが無いことが分かっている場合は、暗黙のソート処理を回避するために、UNION ALLを使用する, や、GROUP BY、INTERSEST、MINUS等にも暗黙のソート処理が実行されるので、極力使用を避けた方が良い。, ROWIDとは、データベース内のレコードのアドレスを表すOracleの内部的な管理情報です。, その為、WHERE句にROWIDを使用すると、テーブルのレコードに最速でアクセスできます。, 但し、Export/Importや表の移動(alter table moveコマンド)などでROWIDは変更されてしまう為、ROWIDの使用は、SELECTでデータを取得後に再度アクセスする場合などに限定されます。, ORDER BY句に列番号で指定した場合、SQL解析時に読み替え処理が発生するのでパフォーマンス低下に繋がる, DISTINCTは、条件に一致するレコードを取り出し暗黙のソート処理後に重複レコードを排除することに対し、EXISTS句は条件に一致するレコード1件でもあればそこで処理は終了する為、暗黙のソート処理をしない分、DISTINCTに比べると負荷が小さくなる, 、INTERSEST、MINUS等は暗黙のソート処理が実行されるので、極力使用を避けた方が良い。, NOT IN句は、内部的にソートマージの結合をすることでテーブルをフルスキャンするのに対し、NOT EXISTS句は条件に一致するレコード1件でもあればそこで処理は終了する為、NOT IN句に比べると負荷が小さくなる, Bツリー・インデックスの中にはNULL値は存在しないので、WHERE句に「IS NULL」を指定するとINDEXは使用されない。, ORDER BY 句で指定する項目は、全てINDEXに含まれ、かつ、NOT NULL項目の場合は、高速にソートされます。, WHERE句で指定した、列の型とデータの型が異なる場合、ORACLEは自動的に型変換を実行するが、型を自動変換する場合はINDEXが使用されない。, ● ORDER BY句の指定列が全てINDEXに指定ないと、ソートにINDEXが使用されない. ■1.良いSQL文とは ここからは、基本はオプティマイザが行ってくれるので気にする必要はないかもしれませんが、常にオプティマイザが行ってくれるとは限りませんので(第5回で説明したオプティマイザ統計が常に正確であるとは限りませんので)、次のようなSQL文を書き換えて速くする方法や考え方を説明しておきます。, それでは、それぞについて説明していきます。 07/18/2016; この記事の内容. 津島博士のパフォーマンス講座 第9回 良いSQLについて . (3)後方一致(中間一致)条件を使用している (1)NULL比較やNOT(!=)を使用している 今回の検証では単純なテーブルと、単純な結合方法でのSQL実行であったため、このようなパフォーマンスの差が顕著に出たものと考えますが、パフォーマンスの良い順番にアクセスするという考えは正しかったということになります。, ただ、RBOを採用しているDBでは自動的に行っている部分が大きく、なかなか意識しない部分になりますので、もしCBOを採用する場合には少しでも参考にしていただければ幸いです。. SQLのチューニングといえばインデックスをとりあえず作成する。 ... 5. ・1000000件, 各データ件数の格納されたテーブルを、from句の1つ目と2つ目に指定してSQLを実行します。 皆さんこんにちは、まだまだ暑いですが体調はいかがでしょうか。私はどうにか頑張っております。 今回は、詳しく聞きたいというご要望のありました「パフォーマンスの良いSQL More than 3 years have passed since last update. 津島博士のパフォーマンス講座 Indexページ . ・データ件数によって、アクセスする順番でパフォーマンスに違いが出る パフォーマンスの良いSQLを記述しよう [SQLServer] SQL SQLServer チューニング. 皆さんこんにちは、今年は10月から気温が低いので、日々の急激な寒暖差に身体がついていけませんね。今回は、Oracle... ※本記事は、Paul Toal (DISTINGUISHED SOLUTION ENGINEER 最後に、ANSI準拠の結合文について説明します。これは、どちらが速いとかではないのですが、間違いやすいので説明しようと思います。特にOracle8i以前のバージョンから使用している方は、外部結合はOracle独自の構文(以下のようにWHERE句で外部結合演算子(+)を指定する。この例はtab1が優先テーブルとしてすべてのレコードを返します)を使用すると思われるため、あまり使い慣れていないかもしれませんので、間違いないようにして下さい。慣れるとこちらの方が使いやすいと思います。, 特に、外部結合するとき結合前に非優先テーブルを条件で絞り込むようなSQL文だと間違いやすいので注意して下さい。これをANSI準拠スタイルで記述するとどうなると思いますか。以下の二つのSQL文を想像すると思いますが(一見同じ結果になると思われるかもしれませんが)、結果が異なってしまう場合がありますので注意して下さい。, 【1】は外部結合した後に条件チェック(tab2.b = 10)を行いますが、【2】は外部結合しながら条件チェックを行います。この例だと、実行結果は以下のように異なってしまい、【2】の方が正しいということになります。これは、外部結合は優先テーブルのすべての行を返すために、非優先テーブルに存在しなかったものをNULLとします。そのため、結合後に非優先テーブルを条件チェックするとNULLのレコードも排除されてしまうからです(この例だと、tab1.aの値が2,4,5のレコードです)。, ■5.おわりに チューニングの方向、プログラムチューニング. 実行SQLの準備ですが、前述したようにCBOでは自動的に最適なアクセスパスを判断するため、from句の順番を変えても実行計画が変わらず、パフォーマンスに影響し辛くなっています。, 実際に実行計画を確認してみましょう。 ・from句の指定順を変えて実行時間を計測 後述しますが、Oracle10g以降の場合は「ルールベース・オプティマイザ(RBO)」がサポートされなくなり、「コストベース・オプティマイザ(CBO)」が主流となっています。 ョンの設定 (SQL Server Profiler), Set Global Trace Options (SQL Server Profiler), トレース ファイルに含めるイベントとデータ列の指定 (SQL Server Profiler), Specify Events and Data Columns for a Trace File (SQL Server Profiler), トレースを実行するための Transact-SQL スクリプトの作成 (SQL Server Profiler), Create a Transact-SQL Script for Running a Trace (SQL Server Profiler), トレース結果のファイルへの保存 (SQL Server Profiler), Save Trace Results to a File (SQL Server Profiler), トレース ファイルの最大ファイル サイズの設定 (SQL Server Profiler), Set a Maximum File Size for a Trace File (SQL Server Profiler), トレース結果のテーブルへの保存 (SQL Server Profiler), Save Trace Results to a Table (SQL Server Profiler), トレース テーブルの最大テーブル サイズの設定 (SQL Server Profiler), Set a Maximum Table Size for a Trace Table (SQL Server Profiler), トレース内のイベントへのフィルターの適用 (SQL Server Profiler), Filter Events in a Trace (SQL Server Profiler), フィルター情報の表示 (SQL Server Profiler), View Filter Information (SQL Server Profiler), フィルターの変更 (SQL Server Profiler), イベントの開始時刻に基づいたイベントのフィルター選択 (SQL Server Profiler), Filter Events Based on the Event Start Time (SQL Server Profiler), イベントの終了時刻に基づいたフィルターでのイベントの選択 (SQL Server Profiler), Filter Events Based on the Event End Time (SQL Server Profiler), トレースでのサーバー プロセス ID (SPIDs) のフィルター選択 (SQL Server Profiler), Filter Server Process IDs (SPIDs) in a Trace (SQL Server Profiler), トレースに表示される列の構成 (SQL Server Profiler), Organize Columns Displayed in a Trace (SQL Server Profiler), SQL Server Profiler を使用してトレースを開始、一時停止、および停止するには, To start, pause, and stop traces by using SQL Server Profiler, サーバーへの接続後の自動的なトレースの開始 (SQL Server Profiler), Start a Trace Automatically after Connecting to a Server (SQL Server Profiler), トレースの一時停止 (SQL Server Profiler), トレースの停止 (SQL Server Profiler), 一時停止または停止したトレースの再開 (SQL Server Profiler), Run a Trace After It Has Been Paused or Stopped (SQL Server Profiler), SQL Server Profiler を使用してトレースを開き、トレースの表示方法を構成するには, To open traces and configure how traces are displayed by using SQL Server Profiler, トレース ファイルを開く (SQL Server Profiler), トレース テーブルを開く (SQL Server Profiler), トレース ウィンドウの消去 (SQL Server Profiler), Clear a Trace Window (SQL Server Profiler), トレース ウィンドウを閉じる (SQL Server Profiler), Close a Trace Window (SQL Server Profiler), トレース定義の既定値の設定 (SQL Server Profiler), Set Trace Definition Defaults (SQL Server Profiler), トレース表示の既定値の設定 (SQL Server Profiler), Set Trace Display Defaults (SQL Server Profiler), SQL Server Profiler を使用してトレースを再生するには, To replay traces by using SQL Server Profiler, トレース ファイルを再生する (SQL Server Profiler), Replay a Trace File (SQL Server Profiler), トレース テーブルを再生する (SQL Server Profiler), Replay a Trace Table (SQL Server Profiler), 一度に単一のイベントの再生 (SQL Server Profiler), Replay a Single Event at a Time (SQL Server Profiler), ブレークポイントまでの再生 (SQL Server Profiler), Replay to a Breakpoint (SQL Server Profiler), カーソルまでの再生 (SQL Server Profiler), Transact-SQL スクリプトの再生 (SQL Server Profiler), Replay a Transact-SQL Script (SQL Server Profiler), SQL Server Profiler を使用してトレース テンプレートを作成、変更、および使用するには, To create, modify, and use trace templates by using SQL Server Profiler, トレース テンプレートの作成 (SQL Server Profiler), Create a Trace Template (SQL Server Profiler), トレース テンプレートの変更 (SQL Server Profiler), Modify a Trace Template (SQL Server Profiler), 実行中のトレースからのテンプレートの作成 (SQL Server Profiler), Derive a Template from a Running Trace (SQL Server Profiler), トレース ファイルまたはトレース テーブルからのテンプレートの作成 (SQL Server Profiler), Derive a Template from a Trace File or Trace Table (SQL Server Profiler), トレース テンプレートのエクスポート (SQL Server Profiler), Export a Trace Template (SQL Server Profiler), トレース テンプレートのインポート (SQL Server Profiler), Import a Trace Template (SQL Server Profiler), SQL Server Profiler トレースを使用してサーバーのパフォーマンスを収集および監視するには, To use SQL Server Profiler traces to collect and monitor server performance, トレース中の値列またはデータ列の検索 (SQL Server Profiler), Find a Value or Data Column While Tracing (SQL Server Profiler), Deadlock Graph の保存 (SQL Server Profiler), Save Deadlock Graphs (SQL Server Profiler), Showplan XML イベントを個別に保存する方法 (SQL Server Profiler), Save Showplan XML Events Separately (SQL Server Profiler), Showplan XML Statistics Profile イベントを個別に保存 (SQL Server Profiler), Save Showplan XML Statistics Profile Events Separately (SQL Server Profiler), トレースからのスクリプトの抽出 (SQL Server Profiler), Extract a Script from a Trace (SQL Server Profiler), トレースと Windows パフォーマンス ログ データの関連付け (SQL Server Profiler), Correlate a Trace with Windows Performance Log Data (SQL Server Profiler), すべてのページ フィードバックを表示, クイック スタート:SQL Server 拡張イベント, 以前のバージョンのドキュメント.