>> 連載トップページに戻る


～オラクルコンサルタントが語る～

シンジ＆アヤノの
実践データベース性能テストの極意：
Oracle Real Application Testingを使ってみよう


第 4回　SQL Performance Analyzer～SQLチューニング・アドバイザでチューニングする～

第3回では、実際にSQL Performance Analyzerを動かし、システム変更前後でのSQLパフォーマンスを比較するまでの手順について実施しました。
第4回では、次にその比較評価結果から性能が低下したSQLについて、SQL チューニング・アドバイザを利用して、チューニングを実施する手順について紹介します。
今回ご紹介するパートを全体のワークフロー図で示すと、以下（図１）のようになります。


図１　SPAワークフロー全体イメージ
pic 1

※注意
本記事に記載している内容は、Oracle Enterprise Manager Cloud Control 12cを用いたReal Application Testing機能のおおまかな操作手順とその動作結果イメージを理解していただくことを目的としています。使用するOracle Enterprise Manager のバージョンによって、操作手順が異なることがあります。システムおよびパッケージの開発や実行環境で使用する際には、関連ドキュメントを参照の上、実施してください。また、本記事は単に情報として提供されるものであり、内容に誤りがないことの保証や弊社サポート部門へのお問い合わせはできませんのでご理解ください。

1. SQLチューニング・アドバイザの実行

SQLパフォーマンス・アナライザの比較評価結果の画面下の部分から3本のSQLの性能が低下(バッファ読み取りが増加)していることが確認できます。低下したSQLに対しSQLチューニング・アドバイザ機能を利用してチューニングを実施します。まず、この画面から、 [SQLチューニング・アドバイザの実行]をクリックします（画面上：①）。
pic2

チューニング・タスクを作成するため、「チューニング・タスク名」に任意の名前を入力し、スケジュールは「即時」を選択して、[OK]をクリックします。本記事ではチューニング・タスク名を『SPA1_TUNE_REG_SQL』としています。
pic3

画面から、チューニング・タスクが作成されたことを確認できます。
pic4

[パフォーマンス] タブから、[アドバイザ・ホーム]をクリックします。
pic5

先ほど作成したチューニング・タスク、『SPA1_TUNE_REG_SQL』が画面に表示されますので、[名前]欄をクリックします。
pic6

次に、サマリー画面が表示されるので、[すべての結果の表示]をクリックします。
pic7

上記画面から[すべての結果の表示]をクリックすると、分析済みSQLの結果が表示されます。

2. チューニングの実装

ここからは、「１．SQLチューニング・アドバイザの実行」ステップで分析したSQLの結果からチューニングを実装する作業に入ります。
まず、[すべてのSQLプロファイルを実装]をクリックします。
pic8

次に、[はい]をクリックします。
pic9

SQLプロファイルが作成され、SQLチューニングのサマリー画面に戻ります。
pic10

「タイプの検索によるブレークダウン」で、SQLプロファイルのグラフが「実装済」になっていることが確認できます。
pic11


コラム：SQLプロファイルについて

アヤノ 今回、チューニングとしてSQLプロファイルを実装しましたが、そもそもSQLプロファイルってどういうものでしたっけ。 shinji-pic1
シンジ SQLプロファイルは、個別のSQLの実行計画を決定するための補助統計を持つものですね。通常のテーブルやインデックスの統計情報だけではオプティマイザによって適切な実行計画が選択されない場合に、SQLプロファイルに格納されている補助統計情報を使用することで、対応するSQL文に対して適切なチューニングがされた実行計画を生成できるようになるのです。
アヤノ なるほど。人の手でSQLに対してヒント句をつけて実行計画を制御するようなチューニングを、アプリケーション側を変更することなく、SQLプロファイルの実装によって自動でやってくれるのですね！


3. チューニング後SQLとのパフォーマンス比較

ここからは、チューニングを実装したSQLのパフォーマンスをSPAを利用し、システム変更前のSQL試行結果と比較します。
[パフォーマンス] タブから、[SQL] → [SQLパフォーマンス・アナライザ]をクリックします。
pic12

次に、第3回で作成したSQLパフォーマンス・アナライザのタスク「SPAT1」をクリックします。
pic13

次に、「SQL試行の作成」をクリックします。
pic14

「SQL試行名」に任意の名前を入力し、スケジュールは「即時」を選択して、「試行環境による結果の決定付け」の下にある「試行環境設定済み」にチェックを入れた状態で、「発行」をクリックします。
pic15

チューニング後のSQL試行が完了したら(「ステータス」列が「COMPLETED」になったら)、次に、「SQL試行比較の実行」をクリックします。
pic16

第3回で作成したシステム変更前のSQL試行を「試行１の名前」として選択し、今作成したチューニング後のSQL試行を「試行２の名前」として選択します。
比較メトリックで「バッファ読取り」を選択し、スケジュールは「即時」を選択した状態で、「発行」をクリックします。
pic17


コラム：SQL試行比較で選択する対象

アヤノ あれ？ここでSQL試行比較する対象は、SQLチューニング前とチューニング後ですよね？ ayano-pic1
シンジ そうです。ここでは「SQLチューニング後のSQL試行」と「システム変更前のSQL試行」を比較していますよね。SQLチューニング前後を比較することでも、そのチューニング効果の有無は確認できますが、ここで重要な確認観点は、システム変更によって性能が低下したSQLが、システム変更前のSQLと同等もしくはそれ以上に改善しているか、ということですね。システム変更前のSQLの性能がチューニングのひとつの目標値になるため、ここで比較すべき対象は、「システム変更前のSQL試行」になります。
アヤノ なるほど、たしかに。言われてみればそのとおりですね。

実行したSQL試行比較の[比較レポート]欄の眼鏡マークをクリックします。
pic18

眼鏡マークをクリックすると、比較評価結果が表示され、チューニング前の比較では性能が低下していたSQLがなくなっていることが確認できます。
pic19


コラム：SQLチューニング・アドバイザ機能

アヤノ SPAの結果画面からSQLチューニング・アドバイザのボタンを押下するだけで、こんなに簡単にチューニングが実装可能なのですね。
シンジ そうですよ。この機能は、Oracleがヒント句や実行計画を確認し、適切なSQLチューニングのアドバイスを施してくれる機能なので、SPAと組み合わせることで性能が低下しているSQLのチューニングが簡単にできます。
本記事の例では、SPAの結果から、3本のSQLの性能が低下がしていたことが確認できましたが、結果画面にある「SQLチューニング・アドバイザの実行」ボタンをクリックするだけで、この3本のSQLについてのアドバイスがもらえましたよね？この通りに実装するだけで、性能が低下していたSQLを改善することができます。
アヤノ EMの画面から簡単にチューニングが実装できるなんて、とっても素敵ですね。
シンジ SQLチューニングは、Oracle Database内部構造やチューニング手法、また業務処理やデータ特性など、必要になる知識が多岐にわたるので、データベース側でアドバイスをしてくれると、データベース管理者は比較的簡単にチューニングが実装できるので、運用コストも削減できますね。


4. まとめ

第３回でSQL Performance Analyzerを使って作成したシステム変更前後でのSQLパフォーマンス比較評価結果レポートから、パフォーマンス劣化しているSQLをSQLチューニング・アドバイザを用いてチューニングする手順について紹介しました。いかがでしたでしょうか。
SQL Performance Analyzerの結果から、簡単にSQLチューニング・アドバイザ機能を利用してチューニング実装を実行することがイメージいただけたかと思います。
個別SQLレベルでの性能検証、チューニングができたら、次はデータベース全体のパフォーマンステストを実施してみましょう。

アヤノ 次回からはDatabase Replayの説明ですね。こっちはわたしが担当しまーす！ shinji-ayano-pic1
シンジ おぉ、ではお願いします。
   
   

次回は、「第5回～Database Replay～ワークロードをキャプチャする～」です。
是非ご覧ください。


<< 第3回へ戻る

>> 連載トップページに戻る