oracle sql analyzeによる sql...

『『『『ORACLE SQL ANALYZE によるによるによるによる SQL チューニング』チューニング』チューニング』チューニング』

作成日：2000/2/20Ver.1.1

日本オラクル株式会社

ORACLE SQL ANALYZE による SQL チューニング　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Ve1.1

無断の複写・複製を禁じます。 ©日本オラクル

2

目次

1. はじめに ......................................................................................... 3

2. 本ドキュメントの目的 ................................................................... 3

3. はじめに ......................................................................................... 3

4. ORACLE SQL ANALYZE を利用する利点 ...................................... 3

4.1. 実行計画取得の手順を比較 ...........................................................................3

4.2. 実行計画の比較..............................................................................................5

4.3. パフォーマンス情報、統計値取得の手順を比較..........................................6

4.4. 統計情報の比較..............................................................................................8

4.5. ヒント・チューニングの手順を比較 ..........................................................10

4.6. 非効率 SQL の検出.......................................................................................11

4.7. ＳＱＬの自動チューニング .........................................................................11

5. チューニングの実際 ..................................................................... 13

5.1. シナリオ.......................................................................................................13

5.2. チューニング手順 ........................................................................................13

6. まとめ .......................................................................................... 25

7. 追補 .............................................................................................. 26

7.1. Oracle SQL Analyze v2.0.4 での機能追加、変更点..................................26



3

1. はじめに

本ドキュメントにおいて、追補を除いて、Oracle SQL Analyze とは、Oracle SQL Analyze v1.6 を指しま

す。

追補において、Oracle SQL Analyze v2.0.4 の機能追加、変更について説明します。

2. 本ドキュメントの目的

本ドキュメントは、ORACLE SQL ANALYZE リリース１．６の理解とその利用技術を深めることを目的として

います。対象者はオラクル RDBMS に習熟している必要があります。

3. はじめに

本ドキュメント内で、”ORACLE SQL ANALYZE”とは”ORACLE SQL ANALYZE リリース１．６”を意味しま

す。また、SQL チューニングの技法についての詳細は、『ORACLE8 Server チューニング　リリース 8.0』を参照してください。

4. ORACLE SQL ANALYZE を利用する利点

SQL チューニングは、深い知識が必要とされ、チューニング作業自体も煩雑になりがちでした。ORACLESQL ANALYZEは、チューニング作業の効率化を実現し、作業者をサポートする機能が装備されています。

従来の SQL ANALYZE を使用しないチューニング手順と比較することで、その利点を説明します。

4.1. 実行計画取得の手順を比較

ORACLE オプティマイザが選択する実行計画を調べることで、ORACLE による SQL 文の実行方法を

確認できます。コマンドを実行する方法と、ORACLE SQL ANALYZE を利用する方法がありますが、

下記にその手順を示します。SQL*PLUS・EXPLAIN PLAN を利用する場合は、いくつかの SQL 文を

使い分けなければならず、取得した実行計画のファイルの整理など、煩雑になりがちです。一方

ORACLE SQL ANALYZE は、全ての操作をマウスだけで行うことも可能なほど簡単で、取得した実行

計画もリポジトリに保存できるため管理も容易です。

(1) SQL*PLUS・EXPLAIN PLAN を利用した実行計画取得（従来の手順）

1. 事前準備：Plan_Table 表がない場合は、作成します。

2. 対象の SQL 文をエディタで編集し、”Explain plan for”句を加えて、Explain Plan コマンドを

作成します。

3. 作成した Explain Plan コマンドを SQL*PLUS から実行させます。

4. 実行の結果が Plan_table 表に格納されるので、SQL*PLUS で照会します。そのままの照会で

は、実行計画の把握は困難なので、ネスト・フォーマットさせる SQL 文で検索します。

5. 実行計画（照会の結果）を保存するためには、SQL*PLUS のスプール機能でファイルとして

保存します。



4

(2) SQL トレース・TKPROF、SQL*PLUS・AUTOTRACE（従来の手順）

SQL トレース・TKPROF を使用して、実行計画を取得することもできます。手順は、4.3.(1)「SQLトレース・TKPROF を利用した手順」を参照してください。SQL*PLUS から AUTOTRACE 機能

を利用して、SQL 文を実行すると実行計画が取得できます。手順は、4.3.(2)「SQL*PLUS・

AUTOTRACE を利用した手順」を参照してください。

(3) ORACLE SQL ANALYZE を利用した実行計画取得

1. ORACLE SQL ANALYZE を起動します。

2. 「ナビゲータ」ウィンドウから対象のデータベースを選択します。

3. Plan_Table 表がない場合、ORACLE SQL ANALYZE は自動作成を行います。

4. チューニング・セッションを「新規作成」し、「SQL テキスト」ウィンドウに SQL 文を設

定します。

5. 「EXPLAIN PLAN の取得」を実行します。

6. 「Explain Plan」ウィンドウに実行計画が表示されます。

7. 実行計画を保存するためには、「リポジトリへの保存」を実行します。ORACLE EnterpriseManager リポジトリ・データベースに保存され、再び実行計画を確認することが可能になり

ます。



5

4.2. 実行計画の比較

ORACLE SQL ANALYZE には、実行計画の表示のみならず、「ウォーク・スルー」「ステップ説明」

「オブジェクト詳細」機能があり、実行計画の理解を助けます。

(1) SQL*PLUS・EXPLAIN PLAN で取得した実行計画（従来の手順）

実行計画に精通していないと理解は困難です。また、関連する表、索引についての情報を得るた

めには、新たに SQL*PLUS などでディクショナリ表を検索する必要があります。

PLAN

----------------------------------------------------------------------------------------------------

SELECT STATEMENT 19

SORT GROUP BY 19

HASH JOIN 15

TABLE ACCESS FULL 小分類マスタ 1

TABLE ACCESS BY INDEX ROW 日次売上集計 1678

BITMAP CONVERSION TO ROWIDS

BITMAP INDEX RANGE SCAN IDX_日次売上集計_1

(2) SQL トレース・TKPROF、SQL*PLUS・AUTOTRACE で取得した統計情報(従来の手順)

4.4.(1)「SQL トレース・TKPROF で取得した統計情報」、4.4.(2)「SQL*PLUS・AUTOTRACEで取得した統計情報」を参照してください。



6

(3) ORACLE SQL ANALYZE で取得した実行計画

SQL トレース・TKPROF と同じようなフォーマットで提示されますが、ORACLE SQL ANALYZEでは「プラン・ウォーク」機能によりステップの実行順序を明示化し、「ステップ説明」機能に

より各ステップでの実行内容をわかりやすく説明します。また、「オブジェクト詳細」機能によ

り、各ステップで利用される表や索引の構成要素を容易に取得することができます。

4.3. パフォーマンス情報、統計値取得の手順を比較

SQL 文実行時のリソース使用状況を調べることで、効率性を判断します。SQL トレース機能・TKPROFを利用して統計情報を取得する方法と ORACLE SQL ANALYZE を利用して取得する方法があります。

SQL トレースを利用する場合、初期値パラメータを変更し再起動させるか、アプリケーションのセッ

ション内で”alter session set sql_trace = true;”,”alter session set timed_statistics = true;”の SQL 文が実

行されている必要があります。ORACLE SQL ANALYZE では、実行計画を取得したチューニング・セ

ッションから「実行」をクリックするだけで統計情報を取得できます。

(1) SQL トレース・TKPROF を利用した手順（従来の手順）

1. 初期値パラメータ(init.ora)を編集し、”SQL_TRACE = TRUE”,”TIMED_STATISTICS = True”に変更。

1

1 セッション・レベルでトレースのオン、オフも可能です。

e.g. ”alter session set sql_trace = true; alter session set 　imed_statistics = true;”



7

2. ORACLE インスタンスを再起動させる。

3. 対象の SQL 文を含むアプリケーションを実行。

4. アプリケーション実行で出力されたトレースを探索。

5. 探索したトレースから TKPROF コマンドで統計情報を抽出します。

6. 統計情報はレポート形式のファイルとして管理保存します。

(2) SQL*PLUS・AUTOTRACE を利用した手順（従来の手順）

1. 事前準備を行います。Plan_Table 表を作成、plustrce.sql を実行、plustrace ロールをユーザ

ーに付与します。

2. SQL*PLUS でデータベース接続後、”set autotrace on”に設定します。

3. SQL 文を SQL*PLUS から実行。

4. 統計情報を保存するためには、事前に”spool on”を設定し、そのスプール・ファイルを管理

します。

(3) ORACLE SQL ANALYZE を利用した手順


2. 「ナビゲータ」ウィンドウから対象のデータベースを選択します。

3. チューニング・セッションを「新規作成」し、SQL 文を「SQL テキスト」ウインドウに設

定します。

4. 「EXPLAIN PLAN の取得」を実行します。

5. 「実行」を行います。

6. 「統計」ウィンドウに統計情報が表示されます。

7. 統計情報を保存するためには、「リポジトリへの保存」を実行します。ORACLE EnterpriseManager リポジトリ・データベースに保存され、再び統計情報を確認することが可能になり

ます。



8

4.4. 統計情報の比較

(1) SQL トレース・TKPROF で取得した統計情報

select a."小分類コード" ,b."小分類通称" ,sum("販売合計額")

from

"日次売上集計" a ,"小分類マスタ" b where ((((a."店舗コード"= '001' and

a."大分類コード"= '002') and a."販売日" between TO_DATE('990625','yymmdd') and

(TO_DATE('990625','yymmdd')+7)) and a."小分類コード"=b."小分類コード") and

a."大分類コード"=b."大分類コード") group by a."小分類コード",b."小分類通称"

order by 1,2

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.07 0.07 39 245 0 0

Execute 1 0.01 0.01 0 0 0 0

Fetch 2 0.04 0.03 52 279 3 10

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 4 0.12 0.11 91 524 3 10

Misses in library cache during parse: 1

Optimizer goal: CHOOSE

Parsing user id: 20 (PCADM01)

Rows Execution Plan

------- ---------------------------------------------------

0 SELECT STATEMENT GOAL: CHOOSE

240 SORT (GROUP BY)

408 HASH JOIN

100 TABLE ACCESS GOAL: ANALYZED (FULL) OF '小分類マスタ'

240 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF

'日次売上集計'

240 BITMAP CONVERSION (TO ROWIDS)

597 BITMAP INDEX (RANGE SCAN) OF 'IDX_日次売上集計_1'

(2) SQL*PLUS・AUTOTRACE で取得した統計情報

SQL> set autotrace on

SQL> SELECT a."小分類コード", b."小分類通称", SUM("販売合計額")

2 FROM "日次売上集計" a, "小分類マスタ" b

3 WHERE a."店舗コード" = '001'

4 AND a."大分類コード" = '002'

5 AND a."販売日" between to_date('990625','yymmdd')

6 AND to_date('990625','yymmdd') + 7

7 AND a."小分類コード" = b."小分類コード"

8 AND a."大分類コード" = b."大分類コード"

9 GROUP BY a."小分類コード", b."小分類通称"

10 ORDER BY 1,2;



9

小分類小分類通称 SUM("販売合計額")

------ ------------------------------------------------------------ -----------------

001 インスタント－カップ系 22686

002 インスタント－非カップ系 17706

003 冷凍食品 8706

004 加工食品 19734

005 レトルト食品 45138

006 そば・うどん 28464

007 パスタ 28206

008 缶詰 5616

009 漬物 16938

010 その他 4638

10 行が選択されました。

実行計画

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=19 Card=16 Bytes=1008)

1 0 SORT (GROUP BY) (Cost=19 Card=16 Bytes=1008)

2 1 HASH JOIN (Cost=15 Card=16 Bytes=1008)

3 2 TABLE ACCESS (FULL) OF '小分類マスタ' (Cost=1 Card=10 Bytes=230)

4 2 TABLE ACCESS (BY INDEX ROWID) OF '日次売上集計' (Cost=1678 Card=155 Bytes=6200)

5 4 BITMAP CONVERSION (TO ROWIDS)

6 5 BITMAP INDEX (RANGE SCAN) OF 'IDX_日次売上集計_1'

統計表示

----------------------------------------------------------

909 recursive calls

4 db block gets

524 consistent gets

89 physical reads

0 redo size

728 bytes sent via SQL*Net to client

824 bytes received via SQL*Net from client

4 SQL*Net roundtrips to/from client

11 sorts (memory)

0 sorts (disk)

10 rows processed

(3) ORACLE SQL ANALYZE で取得した統計情報

SQL トレース・TKPROF の「Query」「Current」の値は、ORACLE SQL ANALYZE では、合計

値が「論理ブロック読込み」として表示されます。

ORACLE SQL ANALYZE では、「UGA メモリー」「PGA メモリー」「ソート」等の統計値が付

加されていますので、判断材料がより多く提供されることになります。ORACLE SQL ANALYZE



10

を利用せずに、これらの統計値を得るためには、bstat/estat 等で収集する必要があります。

ORACLE SQL ANALYZE は Parse,Execute についての統計値は表示しません。それらの情報が必

要な場合は SQL トレース・TKPROF を利用することになります。

4.5. ヒント・チューニングの手順を比較

ORACLE Server(7.3 以降)では、SQL にヒント文を加えることで、オプティマイザにより効率的なア

クセス・パスを選択させることができます。しかし、ヒント・チューニングには、いくつか注意すべ

き点があります。ヒント文の構文誤りは、SQL の構文誤りのようなエラー、ワーニングは一切出力さ

れませんので、充分な構文チェックが必要とされます。また、そのヒント文の効果を確認するために

は、実行計画、統計情報の収集が必要となります。ORACLE SQL ANALYZE は、それらの注意点を解

消して、ヒント・チューニングの作業を容易にします。

(1) SQL*PLUS を利用したヒント・チューニング(従来の手順)

1. マニュアルを参照しヒント文とその構文を確認します。

2. SQL*PLUS から対象の SQL 文にヒント文を組み込みます。

3. ヒント文の誤りがないことを確認します。

4. 実行計画、統計情報を取得します。

5. 予想と異なる実行計画だった場合、再度ヒント文の構文を確認します。

(2) ORACLE SQL ANALYZE を利用したヒント・チューニング


2. 「新規作成」または「類似作成」でチューニング・セッションを作成します。

3. 「SQL テキスト」ウインドウに SQL 文を設定します。



11

4. ヒント・ウィザードを起動します。

5. リストからヒント文を選択し、パラメータがある場合もリストから選択します。

「SQL テキスト」ウィンドウを直接編集することなくヒント文を組み込むため、構文誤りを

犯す危険性がありません。

6. 実行計画、統計情報を取得します。

4.6. 非効率 SQL の検出

Orale SQL ANALYZE は「Top SQL」機能によって、実行済み SQL 文を「ディスク読み込み」「バッ

ファ・キャッシュ・ヒット率」「バッファ読み取り」「解析呼び出し」「実行」「処理された行」の

コストの高い順にソートできます。そこから SQL 文を選択後、チューニング・セッションを作成し、

チューニング作業へ瞬時に着手できます。

同様な操作を ORACLE SQL ANALYZE を利用せずに行うためには、ディクショナリ表 V$SQL_AREAなどを SQL*PLUS などで検索照会しなければなりません。

4.7. ＳＱＬの自動チューニング

ORACLE SQL ANALYZE はＳＱＬ文の構文上のパフォーマンス問題を指摘し自動的に修正を施し、適



12

切な結合方法のヒント文を追加します（5.2.(3)「結合方法」参照）。ＳＱＬチューニングに精通した

人のみが行えたチューニング作業を自動で行うことができます。



13

5. チューニングの実際

実際に ORACLE SQL ANALYZE を利用した SQL チューニングの手法を紹介します。

5.1. シナリオ

スループットが遅い Pro*c アプリケーション・プログラムが特定できました。そのアプリケーション・

プログラムが実行している SQL 文を調査し、もしチューニングの余地があれば、チューニングを施し

ます。

5.2. チューニング手順

(1) 現在の実行計画と統計情報を取得

(A) ORACLE SQL ANALYZE 起動。

(B) チューニング・セッション作成。

対象のデータベースに接続後、「新規作成」で新規にチューニング・セッションを開き

ます。

(C) ＳＱＬ文格納

アプリケーション・プログラムのソースから SQL 文をカットアンドペーストで「SQLテキスト」ウィンドウへコピーします。



14

「SQL テキスト」ウィンドウのホスト変数は編集し直さず、そのままにします。



15

(D) 実行計画取得。

「EXPLAIN PLAN の取得」で実行計画を取得します。

実行計画から、この SQL 文は、２つの表を全表検索し、ハッシュ・ジョインで結合する手

順であることがわかります。



16

統計情報を取得するために「実行」を行います。

ホスト（バインド）変数を持つ SQL 文の「実行」を行うとホスト変数へ値を入力させるウ

ィンドウが起動するので、適当な値をホスト変数へ設定します。



17

統計値が表示されます。

条件句のホスト変数への値が妥当なものであったことを確認するために「実行結果」を

開き評価します。



18

(2) 構文上のチューニング

構文上 SQL のパフォーマンスを落としている要素がないか確認し修正します。ORACLE SQLANALYZE はそれらの作業をウィザードによって自動的に行います。

(A) 構文上の問題点

「チューニング・ウィザード」にしたがって作業を進めると自動的に構文上の「チュー

ニングルール違反」を指摘し、SQL が書き直されます。

「trunc()関数と trunc()関数の比較」を指摘されました。



19

SQL 文が問題点を排除した形式に書き直され、元の SQL 文と比較できます。

“trunc( 販売日 ) = trunc(add_month(sysdate,:h_cnt))” の部分が ” 販売日 betweentrunc(add_months(sysdate,:h_cnt)) and trunc(add_months(sysdate,:h_cnt))”に変更されてい

ます。実行計画を確認すると、”日次売上集計”表は全走査から”IDX_日次売上集計_1”索引の

索引検索に変更されています。



20

(B) 統計情報から効果を確認。

変更前後の SQL 文を実行させ、統計情報を取得し、比較します。

「経過時間」「論理ブロック読み込み」とも大幅に減少しています。



21

(3) 結合方法

ウィザードに従って進むと、自動的に最適な結合ヒント文が追加されます。

変更後の SQL には、ヒント文”/*+ orderd use_nl(b) index(b) */”が追加されています。

実行計画を比較するとハッシュ・ジョイン結合からネステッド・ループ結合へ変更されています。

統計値で比較するために「実行」を行います。



22

(4) ヒント・チューニング

これまでに取得した実行計画などから、より効率があがると思われる実行計画を想定し、それを

実現させるヒント文を追加させます。

(A) 実行計画想定の情報

より効率のよい実行計画を想定するための資料として、これまでの実行計画の「オブジ

ェクト詳細」を利用します。

チューニング・ウィザードで推奨された実行計画では、”小分類マスタ”表を索引検索してい

ましたが、「オブジェクト詳細」から”小分類マスタ”表は２ブロック、１００行しかないこ

とが判明したので、全表走査の方が効率が良いのではないかと推測します。

(B) ヒント文追加

チューニング・ウィザードで推奨された SQL 文をコピーし、ヒント・ウィザードを利用し

ヒント文を追加、変更します。

「類似作成」により SQL 文をコピーした新規チューニング・セッションを開き、ヒン

ト・ウィザードを起動します。



23

すでに追加されているヒント文がリストされるので、そこから”index(b PK_小分類マス

タ)”を削除します。

全表走査のヒント文を追加します。ヒント文はリストから選択可能で、説明も記述され

ているのでマニュアルで確認する必要がありません。

全表走査のヒント文“FULL”を選択します。

　



24

ヒント文のパラメータ値もリストから選択することができます。

全表走査の対象表をパラメータとしてリストから選択します。

(C) ヒント文追加変更後の実行計画、統計情報を取得。

変更後の実行計画を取得し、想定した実行計画との相違を確認します。想定通りであれば、

「実行」を行い統計値を比較します。また、他にも想定可能な実行計画がある場合は、ヒン

ト・チューニングを繰り返します。



25

(5) チューニングの確定

「実行」で得られる「経過時間」「CPU 時間」「物理ブロック読み込み」の統計情報は、厳密に

言えば、実行時のデータベースの環境、つまりデータ・ブロックのキャッシュに左右されます。

したがって、厳格に同条件下でテストするためには、各 SQL 文の実行前にデータベースの再起

動を行い、キャッシュをリフレッシュさせます。ここでは、そこまで厳格性を求めず、データ・

ブロックがキャッシュされている状態のまま、数回「実行」を行い、「経過時間」の平均値で判

断することとしました。

ヒント・ウィザードによる変更後（右）の方が「論理ブロック読込み」も多く、「経過時間」も

遅くなってしまったので、チューニング・ウィザードによる変更直後（左）のＳＱＬ文を採用す

るすることに決定します。また、チューニング作業の履歴として、実行計画、統計値を「リポジ

トリに保存」しておきます。

6. まとめ

このように、ORACLE SQL ANALYZE は、ＳＱＬチューニングに必要な機能がほとんど網羅されています。

いくつかのツールを使い分けながらの作業より効率的です。ＳＱＬ文、ヒント文の自動推奨の機能は、チュー

ニング作業における試行錯誤を軽減します。



26

7. 追補

7.1. Oracle SQL Analyze v2.0.4 での機能追加、変更点

SQL Analyze v1.6 と v2.0.4 の主な相違点を下記に記述します。

(1) Oracle Enterprise Manager v2.0.4 のアーキテクチャ

Oracle SQL Analyzet のベースとなる Oracle Enterprise Manager のアーキテクチャが変更されま

した。

v1.6 ではコンソールとリポジトリデータベースの２階層であったものが、v2.0.4 ではコンソール、

マネージメントサーバー、リポジトリデータベースの３階層になりました。このことにより、リ

ポジトリデータベースへの複数ユーザーの接続が可能になりました。

(2) SQL 履歴

v1.6 では負荷の高い SQL 文などを探索するときには TopSQL のみを対象としていましたが、

v2.0.4 から SQL 履歴が追加されました。TopSQL が対象データベースの現在格納されている SQLｷｬｯｼｭなのに対して、SQL 履歴とは、データベースの SQLｷｬｯｼｭの情報をリポジトリに蓄積した

ものです。したがって、TopSQL ではｷｬｯｼｭから外れた SQL 文は分析対象外となっていたものが、

SQL 履歴を利用することでそれらを分析対象とすることができます。



27

(3) 索引推奨事項

v2.0.4 から索引推奨事項の機能が追加されました。

索引推奨事項は、Oracle のコストベース・オプティマイザで使われる索引をチューニングするた

めのものです。

①「SQL」→「索引推奨事項を取得」

SQL 文内でアクセスされる表を特定し、それらの表を参照する SQL 文が他にないか、データベ

ースの SQL 履歴を走査し、それらを索引要件の評価に使用します。

②「SQL」→「推奨スクリプトの生成」

推奨スクリプトが生成されます。このスクリプト・ファイルを svrmgr、sql*plus から実行するこ

とで、索引推奨事項の実装が完了します。

oracle sql analyzeによる sql...

Documents