プログラマとプロマネのあいだ

プログラマもやるし、プロマネもやるし、たまに似非アーキとか営業っぽいこともやる

SQLパフォーマンスアナライザをガイド付きワークフローで実行してみる

SQLパフォーマンスアナライザとは、マニュアルによると、

データベースのアップグレードまたは索引の追加などのシステム変更によって、SQL文の実行計画が変更されることがあり、SQLパフォーマンスに重大な影響を与えることがあります。場合によっては、システム変更によってSQL文が低下し、SQLパフォーマンスが低下することがあります。また、システム変更によってSQLパフォーマンスが向上することもあります。SQLパフォーマンスのシステム変更による、影響を正確に予想できるため、SQL文が低下する場合に事前にシステムをチューニングしたり、SQL文のパフォーマンスが向上する場合のパフォーマンス利得を評価し、測定できます。
12 SQLパフォーマンスの影響分析

とのことなので、ここでは索引の追加による影響を見てみたいと思います。

SQLパフォーマンス・アナライザメニューを開く

パフォーマンス > SQLパフォーマンス・アナライザでたどれます。
下図は、SQLチューニング・セットの関連ページからたどった場合。

SQLパフォーマンス・アナライザメニューページ

ここでは、ガイド付きワークフローをクリックします。

SQLパフォーマンス・アナライザガイド付きワークフロー


SQLチューニング・セットに基づくSQLパフォーマンス・アナライザのタスクの作成

アナライザの名前と、対象となるSQLチューニング・セットを選択します。
名前: SQLPA_TEST01(あとで参照する用に付ける名前、何でも良い)
説明: 適当
SQLチューニング・セット: 以前作成したSTS04を指定

初期環境でSQLチューニング・セットをリプレイ

索引の追加前に実行(SQLチューニング・セットのリプレイ)します。

索引の追加

こんな索引を作ってみました。

SQL> create index idx_bonus on bonus(ename);

索引が作成されました。

SQL>

っていうか、なんでBONUS表ってempnoがキーじゃないのだろうか。。

変更された環境でSQLチューニング・セットをリプレイ

索引の追加後に実行(SQLチューニング・セットのリプレイ)します。

ステップ2とステップ3を比較

そのまま実行ボタンをクリック。

試行比較レポートの表示

実行時間に変化はありませんでしたが、実行計画が変更されています。


さらにSQLIDをクリックすると、詳細なレポートが表示されます。

■詳細

■変更前後の実行計画

SQLパフォーマンスアナライザ使えそうですが

索引を追加した結果、参照系は速くなるでしょうが、更新系は遅くなりますよね。一般的に。
DMLはどうするのだろう?という疑問が残りますね。。