Oracle Databaseパフォーマンス・チューニング・ガイド, 10g

Oracle® Database
パフォーマンス・チューニング・ガイド
10g リリース 1（10.1）
部品番号 : B12449-01
2004 年 1 月
Oracle Database パフォーマンス・チューニング・ガイド , 10g リリース 1（10.1）
部品番号 : B12449-01
原本名 : Oracle Database Performance Tuning Guide, 10g Release 1 (10.1)
原本部品番号 : B10752-01
原本協力者 : Valarie Moore, James Barlow, Vladimir Barriere, Eric Belden, Qiang Cao, Sunil Chakkappen,
Sumanta Chatterjee, Alvaro Corena, Benoit Dageville, Dinesh Das, Karl Dias, Vinayagam Djegaradjane,
Harvey Eneman, Bjorn Engsig, Mike Feng, Cecilia Gervasio, Bhaskar Ghosh, Ray Glasstone, Leslie
Gloyd, Connie Dialeris Green, Joan Gregoire, Lester Gutierrez, Lex de Haan, Karl Haas, Brian Hirano,
Lilian Hobbs, Andrew Holdsworth, Mamdouh Ibrahim, Hakan Jacobsson, Christopher Jones, Srinivas
Kareenhalli, Feroz Khan, Stella Kister, Herve Lejeune, Yunrui Li, Juan Loaiza, Diana Lorentz, George
Lumpkin, Joe McDonald, Bill McKenna, Mughees Minhas, Sujatha Muthulingam, Gary Ngai, Michael
Orlowski, Kant C. Patel, Richard Powell, Mark Ramacher, Shankar Raman, Uri Shaft, Vinay Srihari,
Sankar Subramanian, Margaret Susairaj, Hal Takahara, Venkateshwaran Venkataramani, Nitin
Vengurlekar, Stephen Vivian, Simon Watt, Andrew Witkowski, Graham Wood, Khaled Yagoub, and
Mohamed Zait
Copyright © 2000, 2003 Oracle Corporation. All rights reserved.
制限付権利の説明
このプログラム（ソフトウェアおよびドキュメントを含む）には、オラクル社およびその関連会社に所
有権のある情報が含まれています。このプログラムの使用または開示は、オラクル社およびその関連会
社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権と工業
所有権に関する法律により保護されています。
独立して作成された他のソフトウェアとの互換性を得るために必要な場合、もしくは法律によって規定
される場合を除き、このプログラムのリバース・エンジニアリング、逆アセンブル、逆コンパイル等は
禁止されています。
このドキュメントの情報は、予告なしに変更される場合があります。オラクル社およびその関連会社は、
このドキュメントに誤りが無いことの保証は致し兼ねます。これらのプログラムのライセンス契約で許
諾されている場合を除き、プログラムを形式、手段（電子的または機械的）
、目的に関係なく、複製また
は転用することはできません。
このプログラムが米国政府機関、もしくは米国政府機関に代わってこのプログラムをライセンスまたは
使用する者に提供される場合は、次の注意が適用されます。
U.S. GOVERNMENT RIGHTS
Programs, software, databases, and related documentation and technical data delivered to U.S.
Government customers are "commercial computer software" or "commercial technical data" pursuant to
the applicable Federal Acquisition Regulation, and agency-specific supplemental regulations. As such,
use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and
technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license
agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial
Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood
City, CA 94065.
このプログラムは、核、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションへの
用途を目的としておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを
安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じ
ることは使用者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、
オラクル社およびその関連会社は一切責任を負いかねます。
Oracle は Oracle Corporation およびその関連会社の登録商標です。その他の名称は、Oracle
Corporation または各社が所有する商標または登録商標です。
目次
はじめに ..........................................................................................................................................................................
xv
対象読者 ................................................................................................................................................................... xvi
このマニュアルの構成 ........................................................................................................................................... xvi
関連ドキュメント ................................................................................................................................................... xix
表記規則 .................................................................................................................................................................... xx
Oracle のパフォーマンスの新機能
.......................................................................................................... xxiii
Oracle Database 10g リリース 1（10.1）のパフォーマンス・チューニングに関連した新機能および
機能更新 .................................................................................................................................................................
xxiv
第 I 部 パフォーマンス・チューニング
1
パフォーマンス・チューニングの概要
パフォーマンス・チューニングの概要 ............................................................................................................... 1-2
パフォーマンス計画 ....................................................................................................................................... 1-2
インスタンスのチューニング ....................................................................................................................... 1-2
SQL チューニング .......................................................................................................................................... 1-5
パフォーマンス・チューニング機能およびツールの概要 ............................................................................... 1-6
自動パフォーマンス・チューニング機能 ................................................................................................... 1-6
その他の Oracle ツール ................................................................................................................................. 1-8
i
第 II 部 パフォーマンス計画
2
パフォーマンスを考慮した設計と開発
オラクル社の新しい方法論 ...................................................................................................................................
投資の選択肢について ...........................................................................................................................................
拡張性について .......................................................................................................................................................
拡張性とは .......................................................................................................................................................
2-2
2-2
2-3
2-3
システムの拡張性 ........................................................................................................................................... 2-4
拡張性を妨げる要因 ....................................................................................................................................... 2-6
システム・アーキテクチャ ................................................................................................................................... 2-7
ハードウェア・コンポーネントとソフトウェア・コンポーネント ....................................................... 2-7
要件に合った正しいシステム・アーキテクチャの構成 ......................................................................... 2-10
アプリケーション設計の原則 ............................................................................................................................ 2-13
アプリケーション設計の簡潔さ ................................................................................................................. 2-13
データのモデル化 ......................................................................................................................................... 2-14
表および索引の設計 ..................................................................................................................................... 2-14
ビューの使用 ................................................................................................................................................. 2-17
SQL の実行効率 ............................................................................................................................................ 2-17
アプリケーションの実装 ............................................................................................................................. 2-19
アプリケーション開発の傾向 ..................................................................................................................... 2-21
ワークロードのテスト、モデル化および実装 ................................................................................................. 2-22
データのサイズ設定 ..................................................................................................................................... 2-22
ワークロードの見積り ................................................................................................................................. 2-23
アプリケーションのモデル化 ..................................................................................................................... 2-24
設計のテスト、デバッグおよび検証 ......................................................................................................... 2-24
新規アプリケーションの配置 ............................................................................................................................. 2-26
ロールアウトの方法 ..................................................................................................................................... 2-26
パフォーマンス・チェックリスト ............................................................................................................. 2-26
3
パフォーマンス改善方法
Oracle のパフォーマンス改善方法 ...................................................................................................................... 3-2
Oracle のパフォーマンス改善方法の手順 .................................................................................................. 3-3
パフォーマンスを概念的にモデル化する際の意思決定プロセスの例 ................................................... 3-5
Oracle システムにおける誤りの上位 10 項目 ............................................................................................ 3-6
ii
パフォーマンスの緊急の問題に対処する方法 ................................................................................................... 3-9
パフォーマンスの緊急の問題に対処する方法の手順 ............................................................................... 3-9
第 III 部 インスタンスのパフォーマンスの最適化
4
パフォーマンスを考慮したデータベースの構成
初期インスタンス構成のパフォーマンスの考慮事項 ....................................................................................... 4-2
初期化パラメータ ........................................................................................................................................... 4-2
UNDO 領域の構成 ......................................................................................................................................... 4-4
REDO ログ・ファイルのサイズ指定 .......................................................................................................... 4-5
追加表領域の作成 ........................................................................................................................................... 4-5
適切なパフォーマンスを得る表の作成とメンテナンス ................................................................................... 4-7
表圧縮 ............................................................................................................................................................... 4-7
未使用領域の解放 ........................................................................................................................................... 4-8
データの索引付け ........................................................................................................................................... 4-9
共有サーバーのパフォーマンスの考慮事項 ..................................................................................................... 4-10
ディスパッチャ固有のビューを使用する競合の識別 ............................................................................. 4-11
共有サーバー・プロセスの競合の識別 ..................................................................................................... 4-13
5
自動パフォーマンス統計
データ収集の概要 ................................................................................................................................................... 5-2
データベース統計 ........................................................................................................................................... 5-3
オペレーティング・システム統計 ............................................................................................................... 5-5
統計の解釈 ....................................................................................................................................................... 5-7
自動ワークロード・リポジトリ ......................................................................................................................... 5-10
Oracle Enterprise Manager を使用した自動ワークロード・リポジトリへのアクセス .................... 5-12
API によるスナップショットおよびベースライン・データの管理 ..................................................... 5-13
Workload Repository のビュー .................................................................................................................. 5-15
Workload Repository レポート .................................................................................................................. 5-16
iii
6
自動パフォーマンス診断
Automatic Database Diagnostic Monitor の概要 ............................................................................................ 6-2
Automatic Database Diagnostic Monitor ......................................................................................................... 6-3
ADDM の分析結果 ......................................................................................................................................... 6-4
ADDM の例 ..................................................................................................................................................... 6-5
ADDM の設定 ................................................................................................................................................. 6-6
Oracle Enterprise Manager を使用した ADDM へのアクセス ............................................................... 6-7
ADDM を使用したデータベース・パフォーマンスの問題の診断 ......................................................... 6-8
ADDM 情報を表示するビュー ................................................................................................................... 6-11
7
メモリーの構成と使用方法
メモリー割当ての問題について ........................................................................................................................... 7-2
Oracle メモリー・キャッシュ ...................................................................................................................... 7-2
自動共有メモリー管理 ................................................................................................................................... 7-3
キャッシュ・サイズの動的な変更 ............................................................................................................... 7-4
アプリケーションの考慮事項 ....................................................................................................................... 7-6
オペレーティング・システムのメモリー使用量 ....................................................................................... 7-6
構成の繰返し ................................................................................................................................................... 7-7
バッファ・キャッシュの構成と使用方法 ........................................................................................................... 7-8
バッファ・キャッシュの効果的な使用 ....................................................................................................... 7-8
バッファ・キャッシュのサイズ設定 ........................................................................................................... 7-8
バッファ・キャッシュ・アドバイザ統計の解釈および使用方法 ......................................................... 7-13
複数バッファ・プールについて ................................................................................................................. 7-15
V$DB_CACHE_ADVICE 内のバッファ・プール・データ ................................................................... 7-17
バッファ・プール・ヒット率 ..................................................................................................................... 7-17
プール内に多くのバッファを持つセグメントの判断 ............................................................................. 7-18
KEEP プール .................................................................................................................................................. 7-19
RECYCLE プール ......................................................................................................................................... 7-20
共有プールとラージ・プールの構成および使用方法 ..................................................................................... 7-21
共有プールの概念 ......................................................................................................................................... 7-22
共有プールの効果的な使用方法 ................................................................................................................. 7-25
共有プールのサイズ設定 ............................................................................................................................. 7-29
共有プール統計の解釈 ................................................................................................................................. 7-35
ラージ・プールの使用 ................................................................................................................................. 7-36
iv
CURSOR_SPACE_FOR_TIME の使用 ...................................................................................................... 7-40
セッション・カーソルのキャッシュ ......................................................................................................... 7-41
予約プールの構成 ......................................................................................................................................... 7-42
除去防止のためのラージ・オブジェクトの保存 ..................................................................................... 7-44
既存のアプリケーション用の CURSOR_SHARING .............................................................................. 7-45
接続の維持 ..................................................................................................................................................... 7-47
REDO ログ・バッファの構成および使用 ........................................................................................................ 7-47
ログ・バッファのサイズ設定 ..................................................................................................................... 7-48
ログ・バッファの統計 ................................................................................................................................. 7-49
PGA メモリー管理 ............................................................................................................................................... 7-49
自動 PGA メモリーの構成 .......................................................................................................................... 7-51
OLAP_PAGE_POOL_SIZE の構成 ............................................................................................................ 7-66
8
I/O 構成および設計
I/O の理解 ................................................................................................................................................................ 8-2
I/O の基本構成 ........................................................................................................................................................ 8-2
オペレーティング・システムまたはハードウェアのストライプ化を使用したファイルの
レイアウト ....................................................................................................................................................... 8-2
手動による I/O の分散 .................................................................................................................................. 8-6
ファイルを分割する場合 ............................................................................................................................... 8-7
3 つの構成サンプル ........................................................................................................................................ 8-9
Oracle Managed Files .................................................................................................................................. 8-10
データ・ブロック・サイズの選択 ............................................................................................................. 8-11
9
オペレーティング・システム・リソース
オペレーティング・システムのパフォーマンスの問題の理解 ....................................................................... 9-2
オペレーティング・システムのキャッシュの使用 ................................................................................... 9-2
メモリー使用量 ............................................................................................................................................... 9-4
オペレーティング・システムのリソース・マネージャの使用 ............................................................... 9-4
オペレーティング・システムの問題の解決 ....................................................................................................... 9-6
UNIX ベースのシステムのパフォーマンスに関するヒント ................................................................... 9-6
Windows システムのパフォーマンスに関するヒント ............................................................................. 9-6
ミッドレンジおよびメインフレーム・コンピュータのパフォーマンスに関するヒント ................... 9-7
CPU について ......................................................................................................................................................... 9-7
コンテキストのスイッチング ..................................................................................................................... 9-10
v
システムの CPU 使用率の調査 .......................................................................................................................... 9-11
メモリー管理のチェック ............................................................................................................................. 9-11
I/O 管理のチェック ..................................................................................................................................... 9-12
ネットワーク管理のチェック ..................................................................................................................... 9-12
プロセス管理のチェック ............................................................................................................................. 9-12
10
パフォーマンス・ビューを使用したインスタンスのチューニング
インスタンスのチューニング手順 ..................................................................................................................... 10-2
問題の定義 ..................................................................................................................................................... 10-3
ホスト・システムの検査 ............................................................................................................................. 10-4
Oracle 統計の調査 ........................................................................................................................................ 10-7
変更の実装および測定 ............................................................................................................................... 10-12
Oracle 統計の解釈 .............................................................................................................................................. 10-13
負荷の検査 ................................................................................................................................................... 10-13
待機イベント統計を使用したボトルネックへのドリルダウン ........................................................... 10-14
待機イベントおよび潜在的な原因の表 ................................................................................................... 10-16
追加された統計情報 ................................................................................................................................... 10-18
待機イベント統計 ...............................................................................................................................................
SQL*Net イベント ......................................................................................................................................
buffer busy waits ........................................................................................................................................
db file scattered read ..................................................................................................................................
db file sequential read ...............................................................................................................................
10-21
10-22
10-24
10-26
10-28
direct path read および direct path read temp ...................................................................................... 10-30
direct path write および direct path write temp .................................................................................... 10-31
enqueue（enq:）待機 ................................................................................................................................ 10-32
free buffer waits .......................................................................................................................................... 10-35
ラッチ・イベント .......................................................................................................................................
log file parallel write ..................................................................................................................................
library cache pin .........................................................................................................................................
library cache lock ........................................................................................................................................
log buffer space ...........................................................................................................................................
log file switch ..............................................................................................................................................
log file sync ..................................................................................................................................................
rdbms ipc reply ...........................................................................................................................................
10-38
10-43
10-43
10-44
10-44
10-45
10-46
10-46
アイドル待機イベント ....................................................................................................................................... 10-47
vi
11
ネットワークのチューニング
接続モデルについて ............................................................................................................................................. 11-2
共有サーバー構成 ......................................................................................................................................... 11-2
ネットワークの問題の検出 ................................................................................................................................. 11-6
動的パフォーマンス・ビューを使用したネットワークのパフォーマンスの向上 ............................. 11-6
待機時間および帯域幅 ................................................................................................................................. 11-7
ネットワークの問題の解決 ................................................................................................................................. 11-9
ネットワークのボトルネックの検出 ......................................................................................................... 11-9
ネットワークのボトルネックの分析 ....................................................................................................... 11-11
配列インタフェースの使用方法 ............................................................................................................... 11-14
セッション・データ・ユニットのバッファ・サイズの調整 ............................................................... 11-14
TCP.NODELAY の使用方法 ..................................................................................................................... 11-14
Connection Manager の使用 ..................................................................................................................... 11-15
第 IV 部　SQL
文の最適化
部　12
SQL チューニングの概要
SQL チューニングの概要 .................................................................................................................................... 12-2
チューニングの目的 ............................................................................................................................................. 12-2
ワークロードの削減 ..................................................................................................................................... 12-2
ワークロードの均衡化 ................................................................................................................................. 12-3
ワークロードのパラレル化 ......................................................................................................................... 12-3
高負荷 SQL の識別 ............................................................................................................................................... 12-3
多くのリソースを消費する SQL の識別 ................................................................................................... 12-3
識別した SQL に関するデータの収集 ....................................................................................................... 12-5
自動 SQL チューニング機能 ............................................................................................................................... 12-6
効率的な SQL 文の開発 ....................................................................................................................................... 12-7
オプティマイザ統計の確認 ......................................................................................................................... 12-8
実行計画の検討 ............................................................................................................................................. 12-8
SQL 文の再構成 ............................................................................................................................................ 12-9
ヒントによるアクセス・パスおよび結合順序の制御 ........................................................................... 12-17
索引の再構成 ............................................................................................................................................... 12-21
トリガーおよび制約の変更または無効化 ............................................................................................... 12-21
データの再構成 ........................................................................................................................................... 12-21
vii
実行計画の長期的な保持 ........................................................................................................................... 12-21
データへのアクセスを最小限に削減 ....................................................................................................... 12-22
13
自動 SQL チューニング
自動 SQL チューニングの概要 ........................................................................................................................... 13-2
問合せオプティマイザのモード ................................................................................................................. 13-2
チューニング分析のタイプ ......................................................................................................................... 13-3
SQL Tuning Advisor ........................................................................................................................................... 13-6
入力ソース ..................................................................................................................................................... 13-6
チューニング・オプション ......................................................................................................................... 13-7
アドバイザ出力 ............................................................................................................................................ 13-7
Oracle Enterprise Manager を使用した SQL Tuning Advisor へのアクセス ..................................... 13-7
SQL Tuning Advisor API の使用方法 ....................................................................................................... 13-8
API による SQL プロファイルの管理 ............................................................................................................ 13-10
SQL プロファイルの受入れ ...................................................................................................................... 13-10
SQL プロファイルの変更 .......................................................................................................................... 13-11
SQL プロファイルの削除 .......................................................................................................................... 13-11
SQL Tuning Set .................................................................................................................................................. 13-11
Oracle Enterprise Manager を使用した SQL Tuning Set へのアクセス ............................................ 13-12
SQL Tuning Set の管理 .............................................................................................................................. 13-12
SQL チューニング情報ビュー .......................................................................................................................... 13-15
14
問合せオプティマイザ
オプティマイザ操作 ............................................................................................................................................. 14-2
オプティマイザの目標の選択 ............................................................................................................................. 14-3
OPTIMIZER_MODE 初期化パラメータ ................................................................................................... 14-4
問合せオプティマイザの目標変更に対するオプティマイザ SQL のヒント ....................................... 14-5
データ・ディクショナリ内の問合せオプティマイザ統計 ..................................................................... 14-6
問合せオプティマイザ機能の有効化および制御 ............................................................................................. 14-6
問合せオプティマイザ機能の有効化 ......................................................................................................... 14-6
問合せオプティマイザの動作の制御 ......................................................................................................... 14-8
問合せオプティマイザについて ......................................................................................................................... 14-9
問合せオプティマイザの構成要素 ........................................................................................................... 14-10
実行計画の読み方と理解 ........................................................................................................................... 14-15
viii
問合せオプティマイザのアクセス・パスについて ....................................................................................... 14-18
全表スキャン ............................................................................................................................................... 14-18
ROWID スキャン ....................................................................................................................................... 14-20
索引スキャン ............................................................................................................................................... 14-21
クラスタ・アクセス ................................................................................................................................... 14-27
ハッシュ・アクセス ................................................................................................................................... 14-27
サンプル表スキャン ................................................................................................................................... 14-27
問合せオプティマイザによるアクセス・パスの選択方法 ................................................................... 14-28
結合について ....................................................................................................................................................... 14-29
問合せオプティマイザによる結合文の実行方法 ................................................................................... 14-29
問合せオプティマイザによる結合の実行計画の選択方法 ................................................................... 14-30
ネステッド・ループ結合 ........................................................................................................................... 14-31
ハッシュ結合 ............................................................................................................................................... 14-33
ソート / マージ結合 .................................................................................................................................. 14-34
デカルト結合 ............................................................................................................................................... 14-35
外部結合 ....................................................................................................................................................... 14-36
15
オプティマイザ統計の管理
統計について ......................................................................................................................................................... 15-2
自動統計収集 ......................................................................................................................................................... 15-3
GATHER_STATS_JOB ................................................................................................................................. 15-3
自動統計収集を使用可能にする方法 ......................................................................................................... 15-4
統計収集時の考慮事項 ................................................................................................................................. 15-4
手動統計収集 ......................................................................................................................................................... 15-6
DBMS_STATS プロシージャによる統計の収集 ...................................................................................... 15-6
統計を収集する時期 ................................................................................................................................... 15-10
システム統計 ....................................................................................................................................................... 15-10
統計の管理 ........................................................................................................................................................... 15-12
前のバージョンの統計のリストア ........................................................................................................... 15-12
統計のエクスポートとインポート ........................................................................................................... 15-13
統計のリストアとインポートまたはエクスポートの相違点 ............................................................... 15-14
表統計またはスキーマ統計のロック ....................................................................................................... 15-14
統計の設定 ................................................................................................................................................... 15-14
動的サンプリングを使用した統計の見積り ........................................................................................... 15-15
統計の欠落の処理 ....................................................................................................................................... 15-17
ix
統計の参照 ........................................................................................................................................................... 15-18
表、索引および列の統計 ........................................................................................................................... 15-18
ヒストグラムの表示 ................................................................................................................................... 15-19
16
索引およびクラスタの使用方法
索引パフォーマンスについて ............................................................................................................................. 16-2
論理構造のチューニング ............................................................................................................................. 16-2
SQL Access Advisor を使用した索引のチューニング ............................................................................ 16-3
索引を付ける列と式の選択 ......................................................................................................................... 16-3
コンポジット索引の選択 ............................................................................................................................. 16-5
索引を使用する文の記述 ............................................................................................................................. 16-6
索引を使用しない文の記述 ......................................................................................................................... 16-6
索引の再作成 ................................................................................................................................................. 16-7
索引の縮小 ..................................................................................................................................................... 16-7
一意でない索引による一意性の規定 ......................................................................................................... 16-8
ENABLE NOVALIDATE 制約の使用方法 ............................................................................................... 16-8
パフォーマンスを考慮したファンクション索引の使用方法 .......................................................................
パフォーマンスを考慮したパーティション索引の使用方法 .......................................................................
パフォーマンスを考慮した索引構成表の使用方法 .......................................................................................
パフォーマンスを考慮したビットマップ索引の使用方法 ...........................................................................
パフォーマンスを考慮したビットマップ結合索引の使用方法 ...................................................................
パフォーマンスを考慮したドメイン索引の使用方法 ...................................................................................
パフォーマンスを考慮したクラスタの使用方法 ...........................................................................................
パフォーマンスを考慮したハッシュ・クラスタの使用方法 .......................................................................
17
16-10
16-11
16-12
16-12
16-13
16-13
16-14
16-15
オプティマイザ・ヒント
オプティマイザ・ヒントの理解 ......................................................................................................................... 17-2
ヒントの型 ..................................................................................................................................................... 17-3
ヒントの指定方法 ......................................................................................................................................... 17-3
ビューでのヒントの使用方法 ................................................................................................................... 17-10
オプティマイザ・ヒントの使用方法 ............................................................................................................... 17-12
最適化アプローチと目標のヒント ........................................................................................................... 17-12
アクセス・パスに関するヒント ............................................................................................................... 17-14
問合せの変換に関するヒント ................................................................................................................... 17-22
結合順序のヒント ....................................................................................................................................... 17-30
x
結合操作のヒント ....................................................................................................................................... 17-31
パラレル実行のヒント ............................................................................................................................... 17-35
その他のヒント ........................................................................................................................................... 17-40
18
プラン・スタビリティの使用方法
実行計画を保持するためのプラン・スタビリティの使用 ............................................................................. 18-2
プラン・スタビリティでのヒントの使用 ................................................................................................. 18-2
アウトラインの格納 ..................................................................................................................................... 18-3
プラン・スタビリティを使用可能にする方法 ......................................................................................... 18-4
提供されるパッケージを使用したストアド・アウトラインの管理 ..................................................... 18-4
アウトラインの作成 ..................................................................................................................................... 18-5
ストアド・アウトラインの使用および編集 ............................................................................................. 18-6
アウトライン・データの照会 ..................................................................................................................... 18-9
アウトライン表の移動 ............................................................................................................................... 18-10
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用 ....................................... 18-12
RBO から問合せオプティマイザへの移行 ............................................................................................. 18-12
問合せオプティマイザを使用している場合の新規 Oracle リリースへの移行 ................................. 18-13
19
EXPLAIN PLAN の使用方法
EXPLAIN PLAN について ................................................................................................................................. 19-2
実行計画の変化理由 ..................................................................................................................................... 19-3
排除行数の最少化 ......................................................................................................................................... 19-3
実行計画以外の考慮事項 ............................................................................................................................. 19-4
EXPLAIN PLAN の制限事項 ...................................................................................................................... 19-5
PLAN_TABLE 出力表 ......................................................................................................................................... 19-5
EXPLAIN PLAN の実行 ..................................................................................................................................... 19-6
EXPLAIN PLAN での文の指定 .................................................................................................................. 19-6
EXPLAIN PLAN での別の表の指定 .......................................................................................................... 19-6
PLAN_TABLE 出力の表示 ................................................................................................................................. 19-7
PLAN_TABLE 出力のカスタマイズ .......................................................................................................... 19-8
EXPLAIN PLAN 出力の読み方 ......................................................................................................................... 19-9
EXPLAIN PLAN によるパラレル実行の表示 ............................................................................................... 19-10
EXPLAIN PLAN によるパラレル問合せの表示 .................................................................................... 19-11
EXPLAIN PLAN によるビットマップ索引の表示 ....................................................................................... 19-13
xi
EXPLAIN PLAN によるパーティション・オブジェクトの表示 ............................................................... 19-14
EXPLAIN PLAN によるレンジ・パーティション化およびハッシュ・パーティション化の
表示の例 ....................................................................................................................................................... 19-14
コンポジット・パーティション・オブジェクトでのプルーニング情報の例 ................................... 19-16
パーシャル・パーティション・ワイズ結合の例 ................................................................................... 19-18
フル・パーティション・ワイズ結合の例 ............................................................................................... 19-20
INLIST ITERATOR および EXPLAIN PLAN の例 ............................................................................... 19-21
ドメイン索引および EXPLAIN PLAN の例 ........................................................................................... 19-22
PLAN_TABLE 列 ............................................................................................................................................... 19-23
20
アプリケーション・トレース・ツールの使用方法
End to End Application Tracing ....................................................................................................................... 20-2
Oracle Enterprise Manager を使用した End to End Application Tracing へのアクセス .................. 20-3
API およびビューを使用した End to End Application Tracing の管理 .............................................. 20-3
trcsess ユーティリティの使用方法 .................................................................................................................... 20-7
trcsess の構文 ................................................................................................................................................ 20-8
trcsess の出力例 ............................................................................................................................................ 20-9
SQL トレースと TKPROF について ............................................................................................................... 20-10
SQL トレース機能について ...................................................................................................................... 20-10
TKPROF について ...................................................................................................................................... 20-11
SQL トレース機能と TKPROF の使用方法 ................................................................................................... 20-12
手順 1: トレース・ファイル管理用の初期化パラメータの設定 .......................................................... 20-12
手順 2: SQL トレース機能を使用可能にする方法 ................................................................................. 20-15
手順 3: TKPROF によるトレース・ファイルのフォーマット ............................................................. 20-16
手順 4: TKPROF 出力の解釈 ..................................................................................................................... 20-21
手順 5: SQL トレース機能統計の格納 ..................................................................................................... 20-27
TKPROF の解釈における誤りの回避 ............................................................................................................. 20-30
引数トラップの回避 ................................................................................................................................... 20-30
読取り一貫性トラップの回避 ................................................................................................................... 20-30
スキーマ・トラップの回避 ....................................................................................................................... 20-31
タイム・トラップの回避 ........................................................................................................................... 20-32
トリガー・トラップの回避 ....................................................................................................................... 20-33
xii
TKPROF の出力例 ............................................................................................................................................. 20-33
TKPROF ヘッダーのサンプル .................................................................................................................. 20-33
TKPROF 本体のサンプル .......................................................................................................................... 20-33
TKPROF サマリーのサンプル .................................................................................................................. 20-36
用語集
索引
xiii
xiv
はじめに
この章には、次の項目が含まれます。
■
対象読者
■
このマニュアルの構成
■
関連ドキュメント
■
表記規則
xv
対象読者
『Oracle Database パフォーマンス・チューニング・ガイド』は、Oracle の運用、メンテナン
スおよびパフォーマンスの担当者を対象としています。このマニュアルでは、パフォーマン
ス・ツールを使用して、SQL を適切に作成およびチューニングし、インスタンスのパフォー
マンスを最適化して、Oracle パフォーマンスを向上させる方法を詳しく説明します。また、
優れたパフォーマンスを実現するための初期データベースの作成方法を説明するとともに、
パフォーマンス関連の参照情報を示します。データベース管理者、アプリケーション設計者
およびプログラマに役立つガイドです。
Oracle データベースをすばやく簡単に監視およびチューニングする方法については、
『Oracle Database 2 日でデータベース管理者』を参照してください。
このマニュアルの構成
このマニュアルには、次の章が含まれます。
「Oracle のパフォーマンスの新機能」
Oracle パフォーマンスに対する最新の拡張機能と、このマニュアルの更新情報の要約です。
第 I 部「パフォーマンス・チューニング」
第 I 部では、パフォーマンス・チューニングの概要を説明します。
第 1 章「パフォーマンス・チューニングの概要」
パフォーマンス・チューニングの概要です。
第 II 部「パフォーマンス計画」
第 II 部では、Oracle のパフォーマンスを向上させるために、優れたアプリケーションを設計
することから開始し、統計を使用してアプリケーション・パフォーマンスを監視する方法を
説明します。ここでは、Oracle のパフォーマンス改善方法のみでなく、パフォーマンスの緊
急の問題に対処する方法についても説明します。
第 2 章「パフォーマンスを考慮した設計と開発」
Oracle アプリケーションを設計する際に考慮が必要なパフォーマンス上の問題を説明しま
す。
第 3 章「パフォーマンス改善方法」
Oracle のパフォーマンス改善方法について説明します。
xvi
第 III 部「インスタンスのパフォーマンスの最適化」
第 III 部では、優れたパフォーマンスの実現のためのデータベースの作成および構成方法に
ついて説明します。ここでは、Oracle システム関連のパフォーマンス・ツールに関する情報
を提供し、Oracle インスタンスのパフォーマンスを最適化するために、データベース・シス
テムの様々な要素をチューニングする方法について説明します。
第 4 章「パフォーマンスを考慮したデータベースの構成」
共有サーバー、UNDO セグメントおよび一時表領域に関する考慮事項を含む、データベー
ス設計時のパフォーマンス上の考慮事項をいくつか説明します。
第 5 章「自動パフォーマンス統計」
Oracle では、パフォーマンス・エンジニアがインスタンスとデータベースのパフォーマンス
に関する情報を収集できるように、多数のツールを提供しています。この章では、パフォー
マンス・データの収集の重要性と、用意されている Oracle 機能について説明します。
第 6 章「自動パフォーマンス診断」
Oracle では、パフォーマンス・エンジニアがデータベースのパフォーマンスを監視し、診断
できるようにする多数のツールを提供しています。この章では、使用可能な Oracle 機能およ
びツールについて説明します。
第 7 章「メモリーの構成と使用方法」
データベース構造体にメモリーを割り当てる方法について説明します。
第 8 章「I/O
構成および設計」
章「
基本的な I/O 概念を紹介し、データベースの様々な部分の I/O 要件について説明し、I/O
サブシステムの設計のための構成例を示します。
第 9 章「オペレーティング・システム・リソース」
Oracle のパフォーマンスを最適化するためにオペレーティング・システムをチューニングす
る方法を説明します。
第 10 章「パフォーマンス・ビューを使用したインスタンスのチューニング」
パフォーマンス・チューニングに使用される手法について説明します。また、Oracle 統計と
待機イベントについても説明します。
第 11 章「ネットワークのチューニング」
チューニングに影響を与える様々な接続モデルとネットワーク上の問題点について説明しま
す。
xvii
第 IV 部「SQL
部「
文の最適化」
第 IV 部では、SQL 文の理解と管理に役立つ情報を示し、Oracle SQL 関連のパフォーマン
ス・ツールに関する情報を示します。
第 12 章「SQL
チューニングの概要」
章「
SQL チューニングの概要について説明します。
第 13 章「自動 SQL チューニング」
Oracle の自動 SQL チューニング機能について説明します。
第 14 章「問合せオプティマイザ」
SQL 処理、Oracle による最適化および SQL 文の実行を Oracle オプティマイザが選択する方
法について説明します。
第 15 章「オプティマイザ統計の管理」
問合せオプティマイザにとって統計が重要である理由、および統計の収集方法と使用方法を
説明します。
第 16 章「索引およびクラスタの使用方法」
索引とクラスタの作成方法と、どのような場合にそれらを使用するかを説明します。
第 17 章「オプティマイザ・ヒント」
問合せオプティマイザのヒントを使用して Oracle パフォーマンスを拡張する方法に関する
推奨事項を説明します。
第 18 章「プラン・スタビリティの使用方法」
パフォーマンス特性を維持するためにプラン・スタビリティ（ストアド・アウトライン）を
使用する方法を説明します。
第 19 章「EXPLAIN
PLAN の使用方法」
章「
SQL 文 EXPLAIN PLAN の使用方法およびその出力のフォーマット方法を説明します。
第 20 章「アプリケーション・トレース・ツールの使用方法」
Oracle サーバーで実行するアプリケーションの監視およびチューニングに役立つ、基本的な
2 つのパフォーマンス診断ツール、SQL トレース機能と TKPROF の使用方法を説明します。
xviii
関連ドキュメント
このマニュアルを読む前に、
『Oracle Database 概要』、
『Oracle Database 2 日でデータベース
管理者』
、『Oracle Database アプリケーション開発者ガイド - 基礎編』および『Oracle
Database 管理者ガイド』をお読みください。
Oracle Enterprise Manager とそのオプションのアプリケーションの詳細は、
『Oracle
Enterprise Manager 概要』を参照してください。
データ・ウェアハウス環境をチューニングする方法の詳細は、
『Oracle データ・ウェアハウ
ス・ガイド』を参照してください。
このマニュアルに記載されている例の多くは、Oracle のインストール時にデフォルトでイン
ストールされるシード・データベースのサンプル・スキーマを使用しています。これらのス
キーマがどのように作成されているか、およびその使用方法については、
『Oracle Database
サンプル・スキーマ』を参照してください。
Oracle エラー・メッセージの詳細は、『Oracle Database エラー・メッセージ』を参照してく
ださい。Oracle エラー・メッセージのマニュアルは、HTML 版のみご利用いただけます。
Oracle マニュアル CD のエラー・メッセージ・マニュアルにアクセスする場合、範囲ごとに
エラー・メッセージを参照できます。範囲を検索した後、ブラウザの検索機能を使用して
メッセージを検索します。インターネットに接続している場合は、Oracle オンライン・マ
ニュアルのエラー・メッセージ検索機能を使用して、特定のエラー・メッセージを検索でき
ます。
リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関
連ドキュメントは、OTN-J（Oracle Technology Network Japan）から、無償でダウンロード
できます。OTN-J を使用するには、オンラインでの登録が必要です。登録は、次の Web サ
イトから無償で行えます。
http://otn.oracle.co.jp/membership/
すでに OTN-J のユーザー名およびパスワードを取得している場合は、次の URL で OTN-J
Web サイトのドキュメントのセクションに直接接続できます。
http://otn.oracle.co.jp/document/
xix
表記規則
この項では、このマニュアルの本文およびコード例で使用される表記規則について説明しま
す。この項の内容は次のとおりです。
■
本文の表記規則
■
コード例の表記規則
本文の表記規則
本文では、特定の項目が一目でわかるように、次の表記規則を使用します。次の表に、その
規則と使用例を示します。
表記規則
意味
太字
太字は、本文中に定義されている用語およ この句を指定すると、索引構成表
索引構成表が作成されます。
索引構成表
び用語集に記載されている用語を示します。
イタリック体
イタリック体は、構文の句やプレースホル
ダを示します。
parallel_clause を指定できます。
固定幅フォントの大文字は、システム指定
の要素を示します。このような要素には、
パラメータ、権限、データ型、Recovery
Manager キーワード、SQL キーワード、
SQL*Plus またはユーティリティ・コマン
ド、パッケージおよびメソッドがあります。
また、システム指定の列名、データベース・
オブジェクト、データベース構造、ユー
ザー名およびロールも含まれます。
NUMBER 列に対してのみ、この句を指定できます。
固定幅フォントの
大文字
固定幅フォントの
小文字
xx
固定幅フォントの小文字は、実行可能ファ
イル、ユーザーが指定する要素のサンプル
を示します。このような要素には、コン
ピュータ名およびデータベース名、ネット・
サービス名および接続識別子があります。
また、ユーザーが指定するデータベース・
オブジェクトとデータベース構造、列名、
パッケージとクラス、ユーザー名とロール、
プログラム・ユニットおよびパラメータ値
も含まれます。
例
Uold_release.SQL を実行します。
old_release はアップグレードの前にインストール
していたリリースです。
BACKUP コマンドを使用して、データベースの
バックアップを作成できます。
USER_TABLES データ・ディクショナリ・ビュー
内の TABLE_NAME 列を問い合せます。
ROLLBACK_SEGMENTS パラメータを指定します。
DBMS_STATS.GENERATE_STATS プロシージャを
使用します。
sqlplus と入力して、SQL*Plus をオープンしま
す。
hr.departments 表には、department_id、
department_name および location_id 列があ
ります。
QUERY_REWRITE_ENABLED 初期化パラメータを
true に設定します。
oe ユーザーとして接続します。
コード例の表記規則
コード例は、SQL、PL/SQL、SQL*Plus または他のコマンドライン文の例です。次のように
固定幅フォントで表示され、通常のテキストと区別されます。
SELECT username FROM dba_users WHERE username = 'MIGRATE';
次の表に、コード例で使用される表記規則とその使用例を示しています。
表記規則
意味
[]
大カッコで囲まれている項目は、1 つ以上の DECIMAL (digits [ , precision ])
オプション項目を表します。大カッコは、
入力しないでください。
{}
中カッコで囲まれている項目は、そのうち
の 1 つが必須であることを表します。中
カッコは、入力しないでください。
{ENABLE | DISABLE}
|
縦線は、大カッコまたは中カッコ内の複数
の選択項目の区切りに使用します。項目の
うちの 1 つを入力します。縦線は、入力し
ないでください。
{ENABLE | DISABLE}
...
■
その他の記号
イタリック体
[COMPRESS | NOCOMPRESS]
水平の省略記号は、次のいずれかを示しま
す。
■
.
.
.
例
例に直接関係のないコードの一部が省
略されている。
CREATE TABLE ...AS subquery;
コードの一部を繰り返すことができる。 SELECT col1, col2, ..., coln FROM
employees;
垂直の省略記号は、例に直接関連しない複
数の行が省略されていることを示します。
SQL> SELECT NAME FROM V$DATAFILE;
NAME
-----------------------------------/fsl/dbs/tbs_01.dbf
/fs1/dbs/tbs_02.dbf
.
.
.
/fsl/dbs/tbs_09.dbf
9 rows selected.
大カッコ、中カッコ、縦線および省略記号
以外の記号は、記載されているとおりに入
力する必要があります。
acctbal NUMBER(11,2);
イタリック体は、特定の値を指定する必要
があるプレースホルダや変数を示します。
CONNECT SYSTEM/system_password
acct
CONSTANT NUMBER(4) := 3;
DB_NAME = database_name
xxi
表記規則
意味
例
大文字
大文字は、システム指定の要素を示します。
これらの要素は、ユーザー定義の要素と区
別するために大文字で示されます。大カッ
コ内にないかぎり、表示されているとおり
の順序および綴りで入力します。ただし、
大 / 小文字が区別されないため、小文字で
も入力できます。
SELECT last_name, employee_id FROM
employees;
小文字は、ユーザー指定のプログラム要素
を示します。たとえば、表名、列名または
ファイル名などです。
SELECT last_name, employee_id FROM
employees;
小文字
注意 : プログラム要素には、大文字と小文
字を組み合せて使用するものもあります。
これらの要素は、記載されているとおりに
入力してください。
xxii
SELECT * FROM USER_TABLES;
DROP TABLE hr.employees;
sqlplus hr/my_hr_password
CREATE USER mjones IDENTIFIED BY
ty3MU9;
Oracle のパフォーマンスの新機能
この項では、Oracle Database 10g リリース 1（10.1）のパフォーマンスに関連した新機能に
ついて説明するとともに、追加情報の掲載場所も記載しています。この項で説明する機能と
拡張機能は、データベースのパフォーマンスを最適化することを目標としています。
Oracle Database 10g リリース 1（10.1）のすべての新機能のサマリーは、『Oracle Database
新機能』を参照してください。
xxiii
Oracle Database 10g リリース 1（
（10.1）のパフォーマンス・
）のパフォーマンス・
チューニングに関連した新機能および機能更新
10g リリース 1（10.1）におけるパフォーマンスに関連した新機能および機能更新は次のとお
りです。
■
自動パフォーマンス診断およびチューニング機能
これらの機能には、自動統計収集、Automatic Database Diagnostic Monitor および自動
SQL チューニングが含まれます。自動ワークロード・リポジトリは、問題検出と自己
チューニングのためのパフォーマンス統計を収集、処理およびメンテナンスします。
Automatic Database Diagnostic Monitor（ADDM）は、Oracle システムの診断とチュー
ニングに必要な労力を軽減します。SQL Tuning Advisor 機能により、SQL 文をすばや
く効率的に最適化する手法が提供されます。新しいパフォーマンス機能およびツールの
概要は、1-6 ページの「パフォーマンス・チューニング機能およびツールの概要」を参
照してください。
■
アプリケーションのエンド・トゥ・エンド・トレース
End to End Application Tracing 機能は、過度の処理負荷の原因（高負荷の SQL 文など）
を、クライアント識別子、サービス、モジュールまたはアクション別に識別します。こ
の機能により、多層環境におけるパフォーマンスの問題のデバッグ作業が簡素化されま
す。20-2 ページの「End to End Application Tracing」を参照してください。
■
trcsess ユーティリティ
trcsess コマンドライン・ユーティリティは、指定された条件に基づいて、選択され
たトレース・ファイルからのトレース情報を整理統合します。20-7 ページの「trcsess
ユーティリティの使用方法」を参照してください。
■
自動オプティマイザ統計収集
この機能により、オブジェクトのオプティマイザ統計の収集が自動化されます。統計が
失効または欠落しているオブジェクトが自動的に分析されるため、管理者は分析対象お
よび対象外のオブジェクトを追跡したり、手動で分析を実行する必要がありません。
15-3 ページの「自動統計収集」を参照してください。
■
自動共有メモリー管理
自動共有メモリー管理により、自己チューニング・アルゴリズムを介したシステム・グ
ローバル領域（SGA）メモリー関連パラメータの構成作業が簡素化されます。データ
ベース構成が簡素化され、使用可能なメモリーの使用効率が最大化され、パフォーマン
スは改善されます。7-3 ページの「自動共有メモリー管理」を参照してください。
xxiv
■
ルールベースの最適化（RBO）の廃止
RBO は機能としてはサポートされなくなりました。RBO は Oracle 10g リリース 1
（10.1）内に存続しますが、サポートされていない機能です。RBO に対しては、コード変
更も不具合の修正も行われていません。Oracle では、問合せオプティマイザのみがサ
ポートされます。Oracle Database 10g リリース 1（10.1）上で動作するアプリケーショ
ンは、すべてこのオプティマイザを使用する必要があります。
RBO のサポート停止による影響をいくつか示します。
–
OPTIMIZER_MODE 初期化パラメータ値として CHOOSE および RULE がサポートさ
れなくなり、この値が RULE または CHOOSE に設定されている場合はアラート・ロ
グに警告が示されます。この 2 つのパラメータ値はまだ残っていますが、将来のリ
リースで削除されます。オプティマイザ・モードのパラメータの詳細は、14-4 ペー
ジの「OPTIMIZER_MODE 初期化パラメータ」を参照してください。
–
ALL_ROWS が、OPTIMIZER_MODE 初期化パラメータのデフォルト値です。
–
CHOOSE および RULE オプティマイザ・ヒントがサポートされなくなりました。こ
の 2 つのヒントはまだ残っていますが、将来のリリースで削除されます。
–
今までルールベース・オプティマイザ（RBO）に依存していたアプリケーション
は、問合せオプティマイザに移行する必要があります。
関連項目 :
■
■
『Oracle Database アップグレード・ガイド』
■
Oracle Metalink の RBO サポート停止通知
■
18-12 ページ「RBO から問合せオプティマイザへの移行」
動的サンプリング
OPTIMIZER_DYNAMIC_SAMPLING 初期化パラメータのデフォルト設定は、2 になりま
した。動的サンプリングの使用時期および使用方法の詳細は、15-15 ページの「動的サン
プリングを使用した統計の見積り」を参照してください。
■
CPU コストの計算
–
オプティマイザのデフォルト・コスト・モデルは CPU+I/O になり、コスト単位は
時間になりました。14-9 ページの「問合せオプティマイザについて」を参照してく
ださい。
xxv
■
■
■
新しいオプティマイザ・ヒント
–
17-47 ページの「SPREAD_MIN_ANALYSIS」に、スプレッドシートの分析オプ
ションを示します。
–
17-33 ページの「USE_NL_WITH_INDEX」に、ネステッド・ループ結合を示しま
す。
–
17-44 ページの「QB_NAME」に、問合せブロック名を示します。
–
17-23 ページの「NO_QUERY_TRANSFORMATION」により、オプティマイザはす
べての問合せ変換をスキップします。
–
17-32 ページの「NO_USE_NL」
、17-34 ページの「NO_USE_MERGE」
、17-35 ペー
ジの「NO_USE_HASH」
、17-20 ページの「NO_INDEX_FFS」、17-22 ページの
「NO_INDEX_SS」および 17-28 ページの「NO_STAR_TRANSFORMATION」の各
ヒントにより、オプティマイザは実行計画から該当する操作を除外します。
–
17-21 ページの「INDEX_SS」
、17-21 ページの「INDEX_SS_ASC」および 17-22
ページの「INDEX_SS_DESC」の各ヒントにより、オプティマイザは実行計画に索
引スキップ・スキャン操作を使用します。
オプティマイザ・ヒントの更新
–
構文に表または索引の引数を使用するヒントは、表または索引の拡張仕様を使用す
るように更新されています。17-7 ページの「グローバル表のヒントの指定方法」お
よび 17-9 ページの「複合索引ヒントの指定方法」を参照してください。
–
一部のヒントでは、オプションの問合せブロック引数を使用できます。17-5 ページ
の「ヒントにおける問合せブロックの指定方法」を参照してください。
オプティマイザ・ヒントの名前変更
17-36 ページの「NO_PARALLEL」
、17-39 ページの「NO_PARALLEL_INDEX」および
17-25 ページの「NO_REWRITE」の各ヒントは、名前が変更されています。
NOPARALLEL、NOPARALLEL_INDEX および NOREWRITE の各ヒントは非推奨のため、
使用しないでください。
■
その他の非推奨オプティマイザ・ヒント
AND_EQUAL、HASH_AJ、MERGE_AJ、NL_AJ、HASH_SJ、MERGE_SJ、NL_SJ、
EXPAND_GSET_TO_UNION、ORDERED_PREDICATES、ROWID および STAR の各ヒント
は非推奨のため、使用しないでください。
■
待機モデルの改善
動的パフォーマンス・ビューが新しく設けられたり更新されています。既存の
V$EVENT_NAME、V$SESSION および V$SESSION_WAIT ビューが変更されています。
V$ACTIVE_SESSION_HISTORY、V$SESS_TIME_MODEL、V$SYS_TIME_MODEL、
V$SYSTEM_WAIT_CLASS、V$SESSION_WAIT_CLASS、V$EVENT_HISTOGRAM、
V$FILE_HISTOGRAM および V$TEMP_HISTOGRAM の各ビューが新しく追加されていま
す。
xxvi
関連項目 :
■
■
動的パフォーマンス・ビューの詳細は、
『Oracle Database リファレン
ス』を参照してください。
■
5-4 ページ「Active Session History（ASH）」
■
10-8 ページ「待機イベント統計を含む動的パフォーマンス・ビュー」
SAMPLE 句の拡張
複雑な SELECT 文に SAMPLE 句を指定できるようになりました。14-27 ページの「サン
プル表スキャン」を参照してください。
■
ハッシュ・パーティション化されたグローバル索引
新しいハッシュ方式により、マルチ・ユーザー OLTP 環境で索引内の少数のリーフ・ブ
ロックに競合が多い場合の索引のパフォーマンスが向上します。16-11 ページの「パ
フォーマンスを考慮したパーティション索引の使用方法」を参照してください。
■
Oracle Trace の廃止
Oracle Trace は、機能として選択できなくなりました。データベース・アクティビティ
のトレースには、かわりに SQL トレースまたは TKPROF を使用してください。このマ
ニュアルでは、Oracle Trace に関する章が削除されています。第 20 章「アプリケーショ
ン・トレース・ツールの使用方法」を参照してください。
xxvii
xxviii
第I部
パフォーマンス・チューニング
第 I 部では、パフォーマンス・チューニングの概要を説明します。
第 I 部には次の章が含まれます。
■
第 1 章「パフォーマンス・チューニングの概要」
1
パフォーマンス・チューニングの概要
この章では、パフォーマンス・チューニングの概要を説明します。
この章には次の項があります。
■
パフォーマンス・チューニングの概要
■
パフォーマンス・チューニング機能およびツールの概要
パフォーマンス・チューニングの概要
1-1
パフォーマンス・チューニングの概要
パフォーマンス・チューニングの概要
このガイドは、Oracle Database システムのパフォーマンス・チューニングに関する情報を
提供します。この項には次の項目があります。
■
パフォーマンス計画
■
インスタンスのチューニング
■
SQL チューニング
パフォーマンス計画
このガイドのインスタンスまたは SQL のチューニングの項に進む前に、必ず第 II 部「パ
フォーマンス計画」に目を通しておいてください。オラクル社では、長年にわたる設計およ
びパフォーマンス経験に基づき、パフォーマンスに関する方法論を設計しました。この項で
は、システム・パフォーマンスを大幅に向上させる明瞭で簡単なアクティビティについて説
明します。次の項目について説明しています。
■
投資対効果
■
拡張性
■
システム・アーキテクチャ
■
アプリケーション設計の原理
■
ワークロードのテスト、モデル化および実装
■
新規アプリケーションの配布
インスタンスのチューニング
このガイドの第 III 部「インスタンスのパフォーマンスの最適化」では、Oracle データベー
ス・インスタンスのチューニングおよび最適化に関連する要素について説明します。
インスタンスのチューニングを検討している場合、パフォーマンス上の問題を引き起こす可
能性のあるボトルネックを回避するため、データベース・システムの初期設計には注意する
必要があります。さらに、次の点も考慮する必要があります。
■
データベース構造体へのメモリーの割当て
■
データベースの様々な部分の I/O 要件の判断
■
データベースのパフォーマンスを最適化するためのオペレーティング・システムの
チューニング
データベース・インスタンスをインストールおよび構成した後、パフォーマンス関連の問題
をチェックするために動作しているデータベースを監視する必要があります。
1-2　Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンス・チューニングの概要
パフォーマンスの原理
パフォーマンス・チューニングでは、システムの初期構成に対して異なる（ただし関連性が
ある）方法を必要とします。システムの構成では、初期システムの構成が機能的なものにな
るように整理された手順に従ってリソースを割り当てます。
チューニングを開始するには、最も影響のあるボトルネックを識別し、適切な変更を行って
そのボトルネックの影響を低減するかまたは排除します。チューニングは通常、システムが
本番開始以前か、または稼働状態になった後で事後的に行われます。
ベースライン
最も効率的なチューニングの方法は、パフォーマンスの問題が生じた場合に比較に使用でき
るパフォーマンス・ベースラインを確立することです。データベース管理者（DBA）の多く
は、自分のシステムを熟知し、ピークの使用期間を簡単に識別できます。たとえば、ピーク
期間は 10.00am ～ 12.00pm である場合、また 1.30pm ～ 3.00pm である場合もあります。こ
れには、深夜の 12.00am から 6.00am までのバッチ・ウィンドウが含まれることがあります。
サイトでこのような高負荷の時間を識別し、このような時間のパフォーマンス・データを収
集する監視ツールをインストールすることが重要です。アプリケーションが QA サイクル中
の初期のトライアル段階にある時点から、データ収集を構成することが最適です。それ以外
の場合は、システムが最初に稼働したときに、このデータ収集を構成する必要があります。
収集されたベースライン・データには、次の内容が含まれていることが理想的です。
■
アプリケーション統計（トランザクション・ボリューム、応答時間）
■
データベース統計
■
オペレーティング・システム統計
■
ディスク I/O 統計
■
ネットワーク統計
自動ワークロード・リポジトリでは、ベースラインは将来比較するために保持されるスナッ
プショットの範囲により識別されます。5-10 ページの「自動ワークロード・リポジトリ」を
参照してください。
症状および問題点
パフォーマンス・チューニングの一般的な誤りは、ある問題の症状を現実の問題自体である
と思い違いをすることです。多くのパフォーマンス統計はこの症状を示すこと、およびこの
症状を識別することが修正を実施するために十分なデータではないことを認識することが重
要です。たとえば、次のようにします。
■
低速な物理 I/O
一般に、この原因はディスクの構成が適切ではないことにあります。しかし、チューニ
ングが適切ではない SQL から発行された、これらのディスク上の大量の不要な物理
I/O が原因になっている可能性もあります。
パフォーマンス・チューニングの概要
1-3
パフォーマンス・チューニングの概要
■
ラッチの競合
インスタンスを再構成して、ラッチの競合をチューニングできることはほとんどありま
せん。むしろ、ラッチの競合は通常、アプリケーションの変更により解決されます。
■
過剰な CPU 使用率
過剰な CPU 使用率は通常、システム上にアイドル状態の CPU がほとんどないことを意
味します。この原因として、システムのサイズ設定が不適切であること、SQL 文が
チューニングされていないこと、またはアプリケーション・プログラムが不十分である
可能性があります。
チューニングの時期
チューニングには次の 2 種類があります。
■
プロアクティブな監視
■
ボトルネックの解消
プロアクティブな監視 プロアクティブな監視は通常、定期的にスケジュールされた間隔で
行われます。この場合、システム動作とリソースの使用量が変化したかどうかを識別するた
めに多数のパフォーマンス統計が調べられます。プロアクティブな監視は、プロアクティブ
なチューニングとも呼ばれます。
通常は、進行中の重大な問題が監視により明らかにならないかぎり、監視によりシステムの
構成が変化することはありません。状況によっては、経験豊富なパフォーマンス・エンジニ
アが統計のみで潜在的な問題点を識別できますが、通常はパフォーマンスの低下を伴いま
す。
明らかなパフォーマンスの低下がないときに、事前のアクションとしてシステムを試行した
り微調整することは危険なアクティビティであり、不必要にパフォーマンスを低下させる可
能性があります。システムを微調整することは事後チューニングと考えられ、事後チューニ
ングの手順に従う必要があります。
監視は通常、大きな容量計画の調査の一環です。この場合、リソース使用を調べて、アプリ
ケーションが使用されている方法、およびアプリケーションがデータベース・リソースとホ
スト・リソースを使用している方法の変化を調べます。
ボトルネックの解消 チューニングは通常、パフォーマンスの問題の修正を意味します。た
だし、チューニングは、分析、設計、コーディング、生産およびメンテナンスの各段階を通
じて、アプリケーションのライフサイクルの一部である必要があります。多くの場合、
チューニング段階はシステムが本番に入るまで残されます。このとき、チューニングは事後
対応処理になります。この場合、最も重要なボトルネックが識別され、修正されます。
チューニングの目的は通常、リソース使用量を減らしたり、操作を完了する経過時間を減ら
すことにあります。いずれの場合も、目標は特定のリソースの有効利用を向上することにあ
ります。一般に、パフォーマンスの問題は特定のリソースの過剰使用によって発生します。
1-4　Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンス・チューニングの概要
そのリソースは、システム内のボトルネックとなります。ボトルネックと潜在的な修正を識
別するには、様々な多くの段階があります。それらについては次の項で説明します。
競合の様々な形態は症状であり、次のいずれかを変更することで修正できることに注意して
ください。
■
アプリケーションまたはアプリケーションの使用方法の変更
■
Oracle の変更
■
ホスト・ハードウェア構成の変更
多くの場合、ボトルネックを解決する最も効果的な方法は、アプリケーションを変更するこ
とです。
SQL チューニング
このガイドの第 IV 部「SQL 文の最適化」では、SQL 文のチューニングおよび最適化のプロ
セスについて説明します。
多くのクライアント / サーバー・アプリケーションのプログラマが SQL をメッセージ言語
とみなすのは、問合せが発行され、データが戻されるためです。しかし、クライアント・
ツールでは非効率的な SQL 文が生成される場合がよくあります。したがって、データベー
ス SQL 処理エンジンについて理解することは、最適な SQL を作成するために必要です。こ
のことは特に、大量トランザクション処理システムについて言えます。
一般に、OLTP アプリケーションから発行される SQL 文では、一度にわずかな行しか実行さ
れません。要求する行を索引で正確に指示できれば、最短のパスからこれらの行に効率よく
アクセスする計画を作成できます。意思決定支援システム（DSS）環境では、表の行のほと
んどにアクセスする場合が多いため、選択性は重要視されません。そのような状況では、全
表スキャンが一般的であり、索引は使用しません。このマニュアルは、主として、OLTP タ
イプのアプリケーションを中心に説明しています。DSS 環境、および DSS と OLTP の混合環
境の詳細は、
『Oracle データ・ウェアハウス・ガイド』を参照してください。
問合せオプティマイザおよび実行計画
SQL 文が Oracle データベースで実行される場合、Oracle 問合せオプティマイザでは、問合
せで指定した参照オブジェクトおよび条件に関連した多くの要素が考慮され、最も効率のよ
い実行計画が判断されます。この判断は、SQL 文の処理で重要なステップであり、実行時間
が大きく変化します。
評価プロセスでは、問合せオプティマイザにより、システム上に収集された統計が確認さ
れ、最適なデータ・アクセス・パスおよびその他の考慮事項が判断されます。問合せオプ
ティマイザの実行計画を、SQL 文に挿入されたヒントで上書きできます。
パフォーマンス・チューニングの概要
1-5
パフォーマンス・チューニング機能およびツールの概要
パフォーマンス・チューニング機能およびツールの概要
効果的なデータの収集と解析は、パフォーマンスの問題を識別して修正するために不可欠で
す。Oracle では、パフォーマンス・エンジニアがデータベースのパフォーマンスに関する情
報を収集できるようにする多数のツールを提供しています。Oracle では、データ収集の他
に、パフォーマンスの監視、問題の診断およびアプリケーションのチューニングのための
ツールも提供しています。
Oracle の収集および監視機能は大部分が自動的なもので、Oracle バックグラウンド・プロセ
スにより管理されます。自動統計収集機能と自動パフォーマンス機能を使用可能にするには、
STATISTICS_LEVEL 初期化パラメータを TYPICAL または ALL に設定する必要があります。
収集ツールおよびチューニング・ツールからの出力の管理と表示には、Oracle Enterprise
Manager、または API とビューを使用します。使用しやすいため、Oracle Enterprise
Manager Database Control をお薦めします。
関連項目 :
■
■
■
■
データベースの監視、診断およびチューニングについては、
『Oracle
Database 2 日でデータベース管理者』を参照してください。
Oracle Enterprise Manager で使用可能な監視および診断ツールの詳細
は、
『Oracle Enterprise Manager 概要』を参照してください。
DBMS_ADVISOR、DBMS_SQLTUNE および DBMS_WORKLOAD_
REPOSITORY パッケージの詳細は、
『PL/SQL パッケージ・プロシー
ジャおよびタイプ・リファレンス』を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
自動パフォーマンス・チューニング機能
Oracle には、次の自動パフォーマンス・チューニング機能があります。
■
■
■
自動ワークロード・リポジトリ（AWR）では、問題の検出および自己チューニングを
目的として、パフォーマンス統計が収集、処理および保守されます。5-10 ページの「自
動ワークロード・リポジトリ」を参照してください。
Automatic Database Diagnostic Monitor（ADDM）では、Oracle データベースにおい
て考えられるパフォーマンス上の問題について、AWR によって収集された情報が分析
されます。6-3 ページの「Automatic Database Diagnostic Monitor」を参照してくださ
い。
SQL Tuning Advisor では、SQL 文を変更しないで SQL 文を素早く効率的に最適化する
ことが可能です。13-6 ページの「SQL Tuning Advisor」を参照してください。
1-6　Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンス・チューニング機能およびツールの概要
■
■
■
■
SQL Access Advisor では、マテリアライズド・ビュー、索引およびマテリアライズド・
ビュー・ログについてアドバイスが提供されます。SQL Access Advisor の詳細は、12-6
ページの「SQL Access Advisor」および『Oracle データ・ウェアハウス・ガイド』を参
照してください。
End to End Application Tracing では、特定のユーザー、サービスまたはアプリケーショ
ン・コンポーネントに関して、システム上の過剰なワークロードが識別されます。20-2
ページの「End to End Application Tracing」を参照してください。
障害となっている問題が検出されると、サーバー生成アラートにより自動的に通知が提
供されます。サーバー生成アラートを使用したデータベース操作の監視の詳細は、
『Oracle Database 管理者ガイド』を参照してください。
Oracle Enterprise Manager からその他のアドバイザを起動できます。たとえば、メモ
リー・アドバイザは、インスタンスのメモリーを最適化します。通常、メモリー・アド
バイザが使用されるのは、データベースの自動メモリー管理が設定されていない場合で
す。その他のアドバイザは、平均リカバリ時間（MTTR）の最適化、セグメントの縮小
および UNDO 表領域の設定に使用されます。Oracle Enterprise Manager で使用可能な
アドバイザの詳細は、
『Oracle Enterprise Manager 概要』を参照してください。
Oracle Enterprise Manager Database Control からアドバイザにアクセスする手順は、次
のとおりです。
■
■
■
「Database」
」ページの最下部で、
「Related Links」
」の下の「
「Advisor Central」
」リン
クをクリックします。
「Advisor Central」
」ページで、アドバイザ・リンクの 1 つをクリックできます。
Oracle Enterprise Manager の「Performance」ページには、リアルタイム監視および診
断に関するホスト、インスタンス・サービス名およびスループット情報が表示されま
す。このページは、選択した間隔で自動的に、または手動でリフレッシュするように設
定できます。Oracle Enterprise Manager で使用可能な「Performance」ページの詳細は、
『Oracle Enterprise Manager 概要』を参照してください。
パフォーマンス・チューニングの概要
1-7
パフォーマンス・チューニング機能およびツールの概要
その他の Oracle ツール
この項では、パフォーマンスの問題の判断に使用できるその他の Oracle ツールについて説
明します。
V$ パフォーマンス・ビュー
V$ ビューは、すべての Oracle パフォーマンス・チューニング・ツールで使用されるパ
フォーマンス情報ソースです。V$ ビューは、インスタンスの起動時に初期化されたメモ
リー構造に基づいています。メモリー構造および構造を表すビューは、インスタンスが存続
する間、Oracle により自動的にメンテナンスされます。V$ パフォーマンス・ビューを使用
して問題を診断しチューニングする方法は、第 10 章「パフォーマンス・ビューを使用した
インスタンスのチューニング」を参照してください。
関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リ
ファレンス』を参照してください。
注意 : パフォーマンス・データの収集には自動ワークロード・リポジト
リを使用することをお薦めします。これらのツールは、パフォーマンスの
分析に必要なすべてのデータを収集するように設計されています。
1-8　Oracle Database パフォーマンス・チューニング・ガイド
第 II 部
パフォーマンス計画
第 II 部では、Oracle のパフォーマンスを向上させるために、優れたアプリケーションを設計
することから開始し、統計情報を使用してアプリケーション・パフォーマンスを監視する方
法を説明します。ここでは、Oracle のパフォーマンス改善方法のみでなく、パフォーマンス
の緊急の問題に対処する方法についても説明します。
第 II 部には次の章が含まれます。
■
第 2 章「パフォーマンスを考慮した設計と開発」
■
第 3 章「パフォーマンス改善方法」
2
パフォーマンスを考慮した設計と開発
優れたシステム・パフォーマンスは設計段階で決まり、その効果は使用しているシステムが
存続するかぎり持続します。パフォーマンスの問題については、最初の設計段階で綿密に検
討することにより、本番でのシステムのチューニングが容易になります。
この章には次の項があります。
■
オラクル社の新しい方法論
■
投資の選択肢について
■
拡張性について
■
システム・アーキテクチャ
■
アプリケーション設計の原則
■
ワークロードのテスト、モデル化および実装
■
新規アプリケーションの配置
パフォーマンスを考慮した設計と開発
2-1
オラクル社の新しい方法論
オラクル社の新しい方法論
コンピュータ・システムの規模が拡大して複雑になり、ビジネス・アプリケーションでのイ
ンターネットの役割が重要になるに従い、システムのパフォーマンスはますます重要になっ
ています。このような状況に対応するために、オラクル社では長年にわたる設計およびパ
フォーマンス経験に基づき、パフォーマンスに関する方法論を確立しました。この方法論は、
システム・パフォーマンスを大幅に向上させる、明瞭で簡潔なアクティビティについて説明
したものです。
パフォーマンス計画は、その効果によって異なります。業務システムや意思決定支援システ
ムなどのようにシステムの目的が異なると、求められるパフォーマンス・スキルも異なりま
す。このマニュアルでは、データベース設計者、管理者またはパフォーマンス・エンジニア
が重点的に考慮する必要がある事柄について説明します。
システムのパフォーマンスは、設計してシステムに組み込むものです。偶然にパフォーマン
スがよくなるわけではありません。パフォーマンスの問題は、通常、システム・リソースの
競合、またはシステム・リソースを使い切ったことが原因で発生します。システム・リソー
スを使い切ると、そのシステムは、高いレベルのパフォーマンスに拡張できなくなります。
ここで説明する新しいパフォーマンス方法論は、データベースの慎重な計画と設計に基づい
ており、システム・リソースを使い切ったことが原因で停止時間が発生するのを防止しま
す。リソースの競合を除去することによって、ビジネス要件を満たすレベルまでシステムを
スケーラブルにすることができます。
投資の選択肢について
高性能のプロセッサ、メモリーおよびディスク・ドライブが比較的安価に入手できることか
ら、安易なシステム・リソースの追加購入によって、パフォーマンスを改善しようとする傾
向があります。多くの場合、新しい CPU、メモリーまたはディスク・ドライブの増設に
よって、確かにパフォーマンスは一時的には改善されます。しかし、ハードウェア増設によ
るパフォーマンスの改善は、目の前の問題の短期的解決にすぎません。アプリケーションに
対する需要と負荷が増加し続けると、近い将来、同様の問題に直面する可能性が非常に高く
なります。
状況によっては、ハードウェアを増設してもシステムのパフォーマンスがまったく改善され
ない場合もあります。システム設計が不適切な場合、追加のハードウェアをいくつ割り当て
てもパフォーマンスは改善されません。ハードウェアを追加購入する前に、アプリケーショ
ン内でシリアライズや単一スレッド化が行われていないことを確認してください。長期的に
は、各ビジネス・トランザクションで使用する物理リソース数の観点からみて、アプリケー
ションの効率を上げるほうが一般的には効果的です。
2-2　Oracle Database パフォーマンス・チューニング・ガイド
拡張性について
拡張性について
拡張性という用語は、開発環境の様々な状況で使用されます。次の項では、アプリケーショ
ン設計者とパフォーマンス・エンジニアを対象にした拡張性について説明します。
拡張性とは
拡張性とは、より多くのワークロードを処理するためのシステムの能力で、それと比例して
システム・リソースの使用が増大します。つまり、スケーラブルなシステムでは、ワーク
ロードが 2 倍になると、そのシステムで使用するリソースも 2 倍になります。これは当たり
前のようですが、システム内で競合が発生すると、元のワークロードに対し、リソースの使
用が 2 倍よりも多くなる場合があります。
リソースの競合によって拡張性が低くなる例を次に示します。
■
ユーザー数の増加に伴い、アプリケーションでかなりの同時実行性管理が要求される
場合
■
ロック・アクティビティが増加した場合
■
データ整合性に関するワークロードが増加した場合
■
オペレーティング・システムのワークロードが増加した場合
■
データ量の増加に伴い、トランザクションでデータ・アクセスの増加が要求される場合
■
SQL と索引の不適切な設計が原因で、同じ戻り行数に対する論理 I/O 数が増加した場合
■
データベース・オブジェクトのメンテナンス時間が長くなったことで、可用性が低下し
た場合
アプリケーションのワークロードが増加してもこれ以上のスループットが不可能という点ま
でシステム・リソースを使い切った場合、そのアプリケーションはスケーラブルでないと言
います。このようなアプリケーションでは、スループットが固定化し、応答時間が長くなり
ます。
リソースを使い切った例を次に示します。
■
ハードウェアを使い切った場合
■
大量トランザクションでの表スキャンによって、ディスク I/O 不足が発生する場合
■
■
■
過剰なネットワーク要求によって、ネットワークとスケジューリングにボトルネックが
発生する場合
メモリー割当てによって、ページングとスワッピングが発生する場合
プロセスやスレッドの過剰な割当てによって、オペレーティング・システムのスラッシ
ングが発生する場合
パフォーマンスを考慮した設計と開発
2-3
拡張性について
このことから、アプリケーション設計者は、ユーザー数やデータ量に関係なく同一リソース
を使用するように設計し、限界を超える負荷をシステム・リソースに与えないようにする必
要があります。
システムの拡張性
インターネット経由でアクセスできるアプリケーションでは、パフォーマンスや可用性の要
件がさらに複雑になります。インターネット専用に設計および作成されたアプリケーション
もありますが、一般会計アプリケーションなどの典型的なバック・オフィス・アプリケー
ションであっても、データの一部またはすべてをオンラインで利用できるようにすることが
必要な場合があります。
インターネット時代のアプリケーションの特徴は、次のとおりです。
■
1 日 24 時間、1 年 365 日の可用性
■
同時ユーザー数が予測不可能で正確な把握が困難
■
容量の計画が困難
■
あらゆるタイプの問合せが選択可能
■
多層アーキテクチャ
■
ステートレスなミドルウェア
■
短い開発期間
■
最小限のテスト時間
図 2-1 は、需要が増大するときの典型的なワークロード成長曲線を示しています。アプリ
ケーションは、ワークロードの増大に伴い拡張できる必要があります。また、増大する需要
をサポートするためにハードウェアが追加されたときにも拡張できることが必要です。設計
に失敗すると、ハードウェア・リソースの増設や再設計に関係なく、実装が限界に達する可
能性があります。
2-4　Oracle Database パフォーマンス・チューニング・ガイド
拡張性について
図 2-1 ワークロード成長曲線
アプリケーションは非常に短期間での開発が要求され、テストや評価の時間も限定されてい
ます。しかし、一般的に、不適切な設計は、将来、システムの再構築や再実装を招くことに
なります。アーキテクチャや実装に制限があることがわかっているアプリケーションをイン
ターネット上に配置し、ワークロードが需要予測を超えている場合は、将来、確実に障害が
発生します。ビジネスの観点からは、低いパフォーマンスは顧客を失うことにつながりま
す。Web ユーザーの場合、7 秒以内に応答がないと、ユーザーの興味は二度と喚起できませ
ん。
多くの場合、新規の実装に移行するためにシステムを停止する間のコストも含めて、システ
ムを再設計するコストは、最初からシステムを適切に構築する場合のコストを上回ります。
ここでの教訓は単純明快です。開発の当初から拡張性に留意して設計と実装を行うというこ
とです。
パフォーマンスを考慮した設計と開発
2-5
拡張性について
拡張性を妨げる要因
アプリケーションを作成するとき、設計者とアーキテクトは、可能なかぎり完全な拡張性に
近づけることを目指す必要があります。この完全な拡張性は線状の拡張性と呼ばれ、システ
ムのスループットが CPU の数に比例するものです。
線状の拡張性にすることは、設計者の制御の及ばない部分があるため、実際には不可能で
す。しかし、アプリケーションの設計や実装に可能なかぎりスケーラブルにしておくと、現
在も、将来においても、ハードウェア・コンポーネントの拡張や CPU テクノロジの発展と
ともにパフォーマンス目標を達成できます。
線状の拡張性を妨げる要因
1.
不適切なアプリケーションの設計、実装および構成
アプリケーションは、拡張性に最も大きく影響します。たとえば、次のような影響があ
ります。
■
■
■
スキーマ設計が不適切であると、SQL にコストがかかり、拡張性を持ちません。
トランザクション設計が不適切であると、ロックおよびシリアライズの問題が発生
します。
接続管理が不適切であると、応答時間が長くなり、システムの信頼性が低下しま
す。
問題となるのは、設計のみではありません。アプリケーションの物理的な実装が弱点に
なる場合があります。たとえば、次のような場合があります。
■
システムが誤った I/O 方針のまま本番環境で使用される場合。
■
テスト時に生成された実行計画とは異なる実行計画が本番環境で使用される場合。
■
■
2.
実行時のメモリーの解放を十分に考慮せずに大量のメモリー割当てを行う、メモ
リー集中型アプリケーションによって、過剰な量のメモリーが使用される場合。
非効率的なメモリー使用やメモリー・リークによって、動作中の仮想メモリー・サ
ブシステムに高いストレスがかかる場合。このようなストレスは、パフォーマンス
や可用性に影響を与えます。
ハードウェア・コンポーネントの誤ったサイズ指定
ハードウェア価格の低下に伴い、どのハードウェア・コンポーネントについても容量計
画が不適切で問題になるということは少なくなっています。ただし、容量が大きすぎる
と、システムでワークロードが増大したときに、拡張性の問題が隠されてしまう場合が
あります。
2-6　Oracle Database パフォーマンス・チューニング・ガイド
システム・アーキテクチャ
3.
ソフトウェア・コンポーネントの制限
すべてのソフトウェア・コンポーネントに、拡張性およびリソース使用上の制限があり
ます。このことは、アプリケーション・サーバー、データベース・サーバーおよびオペ
レーティング・システムでも同様です。アプリケーションの設計では、ソフトウェアの
処理能力を超えた要求をしないでください。
4.
ハードウェア・コンポーネントの制限
ハードウェアは、完全にはスケーラブルになりません。ほとんどのマルチプロセッサ・
マシンでは、限られた数の CPU では線状の拡張性に近いものを実現できますが、ある
数を超えると、CPU の追加でパフォーマンスが全体的には向上しても、数に比例しな
くなります。さらに続けて追加していくと、ある時点からパフォーマンスは向上しなく
なり、むしろ低下する場合もあります。この動作は、ワークロードとオペレーティン
グ・システムの設定に深く関連しています。
注意 : 前述の要因は、スケーラブルでないシステムのチューニングにお
いてオラクル社のサーバー・パフォーマンス・グループが得た経験を基に
したものです。
システム・アーキテクチャ
システムのアーキテクチャには、主要な部分が 2 つあります。
■
ハードウェア・コンポーネントとソフトウェア・コンポーネント
■
要件に合った正しいシステム・アーキテクチャの構成
ハードウェア・コンポーネントとソフトウェア・コンポーネント
この項では、ハードウェア・コンポーネントとソフトウェア・コンポーネントについて説明
します。
ハードウェア・コンポーネント
今日の設計者とアーキテクトは、多層環境の各層でハードウェアのサイズ指定と容量計画を
行う必要があります。バランスの取れた設計を実現するのは、アーキテクトの責任です。こ
れは、橋の設計に似ています。橋の設計者は、橋に関する様々なペイロードや構造上の要件
をすべて考慮する必要があります。橋の強度は、最も弱いコンポーネントの強度にしかなり
ません。このため、橋は、すべてのコンポーネントがその設計上の限界に同時に達するよう
に、バランスよく設計されています。
ハードウェアには、主に次のコンポーネントが含まれます。
■
CPU
■
メモリー
パフォーマンスを考慮した設計と開発
2-7
システム・アーキテクチャ
■
I/O サブシステム
■
ネットワーク
CPU CPU は 1 つ以上使用されており、その処理能力は、携帯端末に見られるような単純な
CPU のものから高性能サーバーの CPU のものまで様々です。他のハードウェア・コンポー
ネントのサイズは、通常、システム上の CPU の倍数になります。第 9 章「オペレーティン
グ・システム・リソース」を参照してください。
メモリー データベース・サーバーとアプリケーション・サーバーには、データをキャッ
シュしたり、長時間のディスク・アクセスを避けるために、十分な量のメモリーが必要で
す。第 7 章「メモリーの構成と使用方法」を参照してください。
I/O サブシステム I/O サブシステムは、クライアント PC のハード・ディスクから高性能な
ディスク・アレイまで様々あります。ディスク・アレイは、毎秒数千回の I/O を実行できる
うえ、複数の I/O パスおよびホット・プラグ可能なミラー化ディスクという冗長性から、可
用性も得られます。第 8 章「I/O 構成および設計」を参照してください。
ネットワーク システム内のコンピュータは、すべて、モデム回線から高速社内 LAN に到る
までのネットワークに接続しています。ネットワーク仕様に関する主な考慮点は、帯域幅
（通信量）と待機時間（速度）です。第 11 章「ネットワークのチューニング」を参照してく
ださい。
ソフトウェア・コンポーネント
コンピュータに共通のハードウェア・コンポーネントがあるように、アプリケーションにも
共通の機能コンポーネントがあります。ソフトウェアの開発を機能コンポーネントごとに分
割することで、アプリケーションの設計やアーキテクチャが理解しやすくなります。システ
ムのコンポーネントの中には、アプリケーションの実装の高速化や、共通コンポーネントの
再作成の防止のために購入された既成のソフトウェアによって実行されるものもあります。
ソフトウェア・コンポーネントとハードウェア・コンポーネントの違いは、ハードウェア・
コンポーネントが 1 つのタスクしか実行しないのに対して、ソフトウェアはその 1 つ 1 つが
様々なソフトウェア・コンポーネントの役割を実行できるということです。たとえば、ディ
スク・ドライブはデータの格納と取出ししか行いませんが、クライアント・プログラムは
ユーザー・インタフェースを管理し、ビジネス・ロジックを実行できます。
ほとんどのアプリケーションに、次に関するコンポーネントが含まれています。
■
ユーザー・インタフェースの管理
■
ビジネス・ロジックの実装
■
ユーザー要求とリソース割当ての管理
■
データおよびトランザクションの管理
2-8　Oracle Database パフォーマンス・チューニング・ガイド
システム・アーキテクチャ
ユーザー・インタフェースの管理 これは、アプリケーション・ユーザーの目に触れること
が最も多いコンポーネントです。これには、次のものがあります。
■
ユーザーが使用するスクリーンの描画
■
ユーザー・データの収集とビジネス・ロジックへのデータの転送
■
データ入力の検証
■
アプリケーションのレベル間または状態間のナビゲーション
ビジネス・ロジックの実装 これに関するコンポーネントは、アプリケーション機能の中心
となるコア・ビジネス・ルールを実装します。このコンポーネントでのエラーは、修復に相
当なコストを要する場合があります。このコンポーネントは、宣言型アプローチとプロシー
ジャ型アプローチの組合せで実装されます。宣言アクティビティの例としては、一意キーと
外部キーの定義があります。また、プロシージャ・ベースのロジックの例としては、値引計
画の実装があります。
このコンポーネントの一般的な機能は、次のとおりです。
■
リレーショナル表構造へのデータ・モデルの移行
■
リレーショナル表構造での制約の定義
■
ビジネス・ルールを実装するプロシージャ型ロジックのコーディング
ユーザー要求とリソース割当ての管理 このコンポーネントは、すべてのソフトウェアに実
装されます。ただし、アプリケーション設計の影響を受ける要求やリソースがある一方で、
影響を受けない要求やリソースもあります。
マルチ・ユーザー・アプリケーションでは、ユーザー要求によるリソース割当てのほとんど
は、データベース・サーバーまたはオペレーティング・システムで処理されます。ただし、
ユーザー数や使用パターンが不明または急増している大規模アプリケーションの場合、シス
テム・アーキテクトはどのソフトウェア・コンポーネントも過負荷や不安定にならないよう
に事前に対処する必要があります。
このコンポーネントの一般的な機能は、次のとおりです。
■
データベースとの接続管理
■
効率的な SQL の実行（カーソルと SQL の共有）
■
クライアント状態情報の管理
■
ハードウェア・リソース間でのユーザー要求のロード・バランシング
■
ハードウェアおよびソフトウェア・コンポーネントに対する操作目標の設定
■
タスクの非同期実行のための永続キューイング
パフォーマンスを考慮した設計と開発
2-9
システム・アーキテクチャ
データおよびトランザクションの管理 このコンポーネントは、主にデータベース・サー
バーとオペレーティング・システムが管理します。
このコンポーネントの一般的な機能は、次のとおりです。
■
ロックとトランザクション・セマンティクスを使用した、データへの同時アクセス
■
索引およびメモリー・キャッシュを使用した、データへの最適化アクセス
■
ハードウェア障害時のデータ変更の記録
■
データに対して定義されているルールの適用
要件に合った正しいシステム・アーキテクチャの構成
初期のシステム・アーキテクチャを構成する作業は、反復的な処理です。アーキテクトは、
予算やスケジュールの制約内でシステム要件を満たす必要があります。対話型ユーザーが
データベースの内容に基づいてビジネスの取引や意思決定を行うシステムの場合、ユーザー
要件が主体のアーキテクチャになります。システム上に対話型ユーザーがほとんどいない場
合は、プロセス主体のアーキテクチャになります。
対話型ユーザー・アプリケーションの例を、次に示します。
■
経理アプリケーションや会計帳簿アプリケーションョン
■
注文入力システム
■
電子メール・サーバー
■
Web ベースの小売販売アプリケーション
■
取引システム
プロセス主体のアプリケーションの例を、次に示します。
■
公共料金支払システム
■
不正検出システム
■
ダイレクト・メール
多くの点で、プロセス主体のアプリケーションのほうが、ユーザー・インタフェース要素が
ないのでマルチ・ユーザー・アプリケーションよりも設計が容易です。しかし、目的がプロ
セス指向であるため、大量のデータや様々な成功要因の扱いに慣れていないアーキテクチト
は混乱することがあります。プロセス主体のアプリケーションでは、ユーザー・ベースのア
プリケーションとデータ・ウェアハウス・アプリケーションの両方で使用されるスキルを利
用します。したがって、このマニュアルでは、対話型ユーザー向けの新しいシステム・アー
キテクチャについて、重点的に説明します。
2-10　Oracle Database パフォーマンス・チューニング・ガイド
システム・アーキテクチャ
注意 : システム・アーキテクチャの生成は、決定論的なプロセスではあ
りません。ビジネス要件、テクノロジの選択肢、既存のインフラストラク
チャやシステム、さらに予算や人員などの実際の物理リソースなどを慎重
に考慮する必要があります。
次の質問は、システム・アーキテクチャに関する完全なガイドではありませんが、アーキテ
クチャについて考える場合の参考になります。これらの質問では、アーキテクチャ、実装し
やすさ、さらにシステムの全体的なパフォーマンスと可用性に対して、ビジネス要件がどの
ように影響を及ぼすかを示しています。たとえば、次のようにします。
■
システムでサポートするユーザーは何人ですか ?
ほとんどのアプリケーションは、次のいずれかのカテゴリに該当します。
–
ごく少数のユーザーが使用率の低いマシンまたは専用マシンを使用する場合
このタイプのアプリケーションでは、通常、ユーザーは 1 人です。この場合のアプ
リケーション設計の重点は、応答時間を短くし、しかもアプリケーションの管理を
最小限に抑えることで、シングル・ユーザーの生産性をできるだけ高くすることに
あります。このようなアプリケーションのユーザーは、相互に介入することはほと
んどなく、リソースの競合も最小限に抑えられます。
–
中規模から大規模の数の社内ユーザーが共有アプリケーションを使用する場合
このタイプのアプリケーションでは、ユーザー数は、社内でシステムを実際に使用
してビジネスを行う従業員の数に限定されます。したがって、ユーザー数は予測可
能です。ただし、信頼性のあるサービスを提供することが、ビジネスにとっては必
須です。ユーザーは共有リソースを使用するため、アプリケーション設計では、大
量のシステム・ロード下での応答時間、各セッションで使用されるリソースの増大
および将来の拡張のための余地に重点を置きます。
–
無数のユーザーがインターネット上に存在する場合
このタイプのアプリケーションでは、すべてのシステム・コンポーネントがそれぞ
れの限界を超えないように設計する必要があります。1 つでも限界を超えるとボト
ルネックが発生し、システムが停止したり不安定になることがあります。このよう
なアプリケーションでは、複合的なロード・バランシング、ステートレスなアプリ
ケーション・サーバーおよび効率的なデータベース接続管理が必要です。さらに、
統計情報とガバナーを使用して、システムの過負荷が原因でユーザー要求が満たさ
れない場合にユーザーがフィードバックを受け取るようにする必要があります。
■
ユーザーとの対話方式は何ですか ?
ユーザー・インタフェースの選択肢は、単純な Web ブラウザからカスタム・クライア
ント・プログラムまで様々です。
パフォーマンスを考慮した設計と開発
2-11
システム・アーキテクチャ
■
ユーザーはどこに位置しますか ?
ユーザー間の距離は、ネットワーク待機時間に対処するためのアプリケーションの設計
方法に影響します。また、ユーザーの位置は、1 日の中でピークの時間帯、つまりバッ
チ機能やシステム・メンテナンス機能を実行できない時間帯の決定にも影響を与えま
す。
■
ネットワーク速度はどの程度ですか ?
ネットワーク速度は、データ量に影響を与え、アプリケーション・サーバーやデータ
ベース・サーバーとのユーザー・インタフェースの対話特性にも影響を与えます。対話
主体のユーザー・インタフェースでは、キー・ストロークごとまたはフィールド・レベ
ルの妥当性チェックごとにバックエンド・サーバーと通信します。対話が少ないインタ
フェースは、画面ごとに送受信を行うモデルで機能します。通信速度が遅いネットワー
クでは、対話主体のユーザー・インタフェースを使用しても満足なデータ入力速度は得
られません。
■
ユーザーがアクセスするデータ量はどれくらいで、そのデータの中で読取り専用データ
が占める割合はどの程度ですか ?
オンラインでの問合せのデータ量は、表や索引の設計からプレゼンテーション層にいた
る設計のあらゆる局面に影響を与えます。データベースのサイズによってユーザーの応
答時間が影響されないように設計する必要があります。アプリケーションが主として読
取り専用の場合は、アプリケーション・サーバーのローカル・キャッシュへのレプリ
ケーションとデータ配分が有効な選択肢になります。また、これにより、主要トランザ
クション・サーバーでのワークロードが削減されます。
■
ユーザー応答時間の要件は何ですか ?
ユーザー・タイプに関する考慮が重要です。ユーザーが経営者で、瞬時に意思決定を行
うために正確な情報を必要とする場合は、ユーザー応答時間の妥協は許されません。
データ入力操作を行うユーザーなど、他のタイプのユーザーの場合は、それほど高いパ
フォーマンスは必要としません。
■
ユーザーは 1 日 24 時間のサービスを期待していますか ?
取引が 1 日 24 時間行われている今日のインターネット・アプリケーションの場合、24
時間連続稼働は必須です。ただし、1 つのタイム・ゾーンでのみ稼働する企業システム
の場合は、終業後にシステムを停止できます。終業後のシステム停止時間を利用して、
バッチ処理やシステム管理を実行できます。このような場合は、連続稼働システムでな
い方が経済的です。
■
変更はすべてリアルタイムで行う必要がありますか ?
ユーザーの応答時間内にトランザクションを実行する必要があるか、またはキューに入
れて非同期で実行できるかを判断することが重要です。
次の質問は二次的な質問です。これらは設計にも影響を及ぼしますが、予算や実装しやすさ
の面に、より大きく影響します。たとえば、次のようにします。
2-12　Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
■
データベースの規模はどの程度ですか ?
データベースの規模は、データベース・サーバー・マシンのサイズ決定に影響します。
大規模データベースを持つシステムでは、ワークロードから判断されるマシンよりも大
型のマシンを用意することが必要になる場合があります。これは、大規模データベース
に伴う管理オーバーヘッドが、主としてデータベース・サイズに比例するためです。表
および索引が大きくなると、許容できる時間内に表を再編成したり索引を作成する必要
があるため、必要な CPU の数もそれに比例して増加します。
■
ビジネス・トランザクションで必要とされるスループットはどの程度ですか ?
■
可用性に関する要件は何ですか ?
■
このアプリケーションを作成して管理するためのスキルはありますか ?
■
予算上の制約からどのような妥協が求められますか ?
アプリケーション設計の原則
この項では、アプリケーション作成時に必要な設計上の決定事項を説明します。
アプリケーション設計の簡潔さ
アプリケーションは、設計と開発を伴う他の製品となんら変わりはありません。通常、適切
に設計された構造、マシンおよびツールには信頼性があり、使用方法やメンテナンスが容易
で、概念的にも簡潔です。ごく一般的に表現すると、設計が適切に見えるものは、実際にも
適切に設計されていると言えます。アプリケーションの作成では、この原則を常に覚えてお
いてください。
設計に関しては、次の点を考慮してください。
■
■
■
■
■
表の設計が複雑で、誰も完全に理解できない場合、その表の設計は不適切であると言え
ます。
SQL 文が非常に長く、どのオプティマイザでもリアルタイムに効率よく最適化できない
場合、その SQL 文、基になるトランザクションまたは表の設計が不適切であると言え
ます。
表に索引があり、同じ列が繰り返し参照される場合は、索引の設計が不適切であると言
えます。
問合せを送信したときに、オンライン・ユーザーにとって必要な迅速な応答能力がな
かった場合は、ユーザー・インタフェースまたはトランザクションの設計が不適切であ
ると言えます。
ソフトウェアの多くの層で、データベース・コールがアプリケーション・ロジックから
離れて抽象化される場合は、ソフトウェアの開発方法が不適切であると言えます。
パフォーマンスを考慮した設計と開発
2-13
アプリケーション設計の原則
データのモデル化
データのモデル化は、リレーショナル・アプリケーションの適切な設計に不可欠です。デー
タ・モデルは、実際のビジネスに即した表現である必要があります。正しいデータ・モデル
については、様々な議論の余地があります。重要なことは、最も頻繁に行われるビジネス・
トランザクションの影響を受けるエンティティをモデル化の主な対象にすることです。モデ
ル化フェーズでは、あまり重要でないデータ要素のモデル化に時間を取られることがあり、
開発の準備期間が延長される結果になります。モデル化ツールを使用すると、スキーマ定義
をすばやく生成できます。また、短期間でプロトタイプを作成する必要がある場合に便利で
す。
表および索引の設計
表の設計は、主に、主要トランザクションの柔軟性とパフォーマンスの間でバランスを取る
作業です。データベースの柔軟性を保持しながら予想外のワークロードに対処できるように
するには、表の設計をデータ・モデルとほぼ同じようにする必要があり、最低でも第 3 正規
形に正規化しておく必要があります。ただし、ユーザーが必要とする特定のトランザクショ
ンでは、パフォーマンス向上のために選択的な非正規化が求められることがあります。
この技法の例としては、事前に結合された表の格納、導出列の追加および集計値がありま
す。Oracle には、クラスタ化機能とマテリアライズド・ビュー機能により、集計データと事
前結合データの格納に関するオプションが多数用意されています。これらの機能によって、
より簡潔な表の設計を最初から採用できます。
ここでも、優れたパフォーマンスを実現できるように、ビジネス上重要な表に重点的にリ
ソースを使用する必要があります。重要でない表の場合は、アプリケーション開発を迅速に
進めるためにも、設計に簡略な方法を採用できます。ただし、プロトタイプおよびテストの
結果、重要でない表でパフォーマンスの問題が発生する場合は、ただちに設計を修正する必
要があります。
索引の設計も、アプリケーション設計者が生成した SQL に基づく、主として反復的なプロ
セスです。ただし、主キー制約を適用する索引や個人名など既知のアクセス・パターンに対
する索引を作成することから開始することも可能です。アプリケーションの開発が進み、実
サイズのデータでテストを実行すると、特定の問合せのパフォーマンスを改善する必要が生
じますが、これには適切な索引の作成が解決策になることがあります。新たに索引を作成す
るときに索引の設計に関して考慮する点を、次に示します。
■
索引への列の追加または索引構成表の使用
■
異なる索引タイプの使用
■
索引のコストの算出
■
索引内のシリアライズ
■
索引内の列の順序付け
2-14　Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
索引への列の追加または索引構成表の使用
問合せをスピードアップする簡単な方法の 1 つは、実行計画から表アクセスを排除して論理
I/O の数を減らすことです。これは、問合せによって参照されるすべての列を索引に追加す
ることで実現できます。これらの列は、選択リスト列、および結合またはソートに必要な列
です。この方法は、時間がかかる I/O を削減して、オンライン・アプリケーションの応答時
間を短縮する場合に特に役立ちます。これは、適切なサイズのデータを使用してアプリケー
ションを初めてテストするときに最も効果を発揮します。
この技法を最も積極的に使用しているのが、索引構成表（IOT）の作成です。ただし、IOT
のリーフ・サイズの増加が I/O 削減効果を妨げないように注意する必要があります。
異なる索引タイプの使用
選択できる索引のタイプはいくつかあり、それぞれ特定の状況に応じた利点があります。各
タイプの索引に関連したパフォーマンスの考慮点を、次のリストに示します。
B ツリー索引 標準的な索引タイプです。主キー索引および選択的な索引に最も適していま
す。B ツリー索引を連結索引として使用すると、索引列順にソートされたデータを取り出す
ことができます。
ビットマップ索引 この索引は、カーディナリティが低いデータに適しています。この索引
は、圧縮技法によって最小限の I/O で多数の ROWID を生成できます。選択列以外の列に対
するビットマップ索引を組み合せることによって、最小限の I/O と多数の ROWID で AND
演算と OR 演算を効率よく実行できます。ビットマップ索引は、索引内で問合せを満たすこ
とができるため、COUNT() を使用した問合せで特に効果的です。
ファンクション索引 この索引では、ベース・データ上の関数から導出された値に対する B
ツリー経由でアクセスできます。ファンクション索引では NULL の使用に制限があり、問合
せオプティマイザを使用可能にしておく必要があります。
ファンクション索引は、複合列への問合せで導出される結果を生成する場合や、データベー
スへのデータの格納方法における制限を克服する場合に、特に役立ちます。このような問合
せの例として、
（販売価格 － 値引）×数量から算出された特定の値を超える注文の明細項目
（表内の列）の問合せがあります。別の例としては、UPPER 関数をデータに適用した、大 /
小文字を区別しない検索があります。
パーティション索引 グローバル索引のパーティション化によって、パーティション・プ
ルーニングが索引アクセス内で発生し、I/O を削減できます。レンジ・パーティション化ま
たはリスト・パーティション化を適切に定義すると、正しい索引パーティションが高速で索
引スキャンされるため、問合せ時間を大幅に短縮できます。
逆キー索引 この索引は、挿入アプリケーションでの索引のホットスポットを除去するよう
に設計されています。この索引は、挿入パフォーマンスに優れていますが、索引レンジ・ス
キャンには使用できません。
パフォーマンスを考慮した設計と開発
2-15
アプリケーション設計の原則
索引のコストの算出
索引構造の作成とメンテナンスにはコストがかかり、ディスク領域、CPU および I/O 容量
などのリソースを消費します。設計者は、索引のメンテナンスにかかるコストより、索引の
使用による利点が上回るように設計する必要があります。
索引のメンテナンスにかかるコストを見積る簡単な目安があります。それは、索引キーに対
して INSERT、DELETE または UPDATE を実行することでメンテナンスされる索引では、索
引ごとに、表に対する実際の DML 操作で使用されるリソースの 3 倍のリソースが必要にな
る、というものです。つまり、3 つの索引がある表に INSERT 操作を行うと、索引がない表
に INSERT 操作を行う場合に比べて、10 倍近く処理が遅くなるということです。DML の場
合、特に INSERT 主体のアプリケーションでは、問合せと INSERT 操作のパフォーマンスと
の間のバランスを取る必要があるため、索引の設計は十分に検討する必要があります。
関連項目 : 索引の使用を監視する方法の詳細は、
『Oracle Database 管理
者ガイド』を参照してください。
索引内のシリアライズ
順序またはタイムスタンプを使用して索引付きキー値を生成すると、データベースのホッ
ト・スポット問題が生じ、応答時間やスループットに影響を与える場合があります。これ
は、通常、キーが単調に増加することによるもので、結果として索引は適度に増加します。
この問題を回避するには、索引の全範囲にわたって挿入するキーを生成します。これによっ
て、スケーラブルで領域を効率よく使用するバランスの取れた索引になります。これには、
逆キー索引を使用するか、接頭辞および順序値にサイクル順序を使用します。
索引内の列の順序付け
設計者は、索引作成の規則を柔軟に定義する必要があります。状況に応じて、次のいずれか
の方法で索引内のキーに順序を付けます。
1.
選択頻度の高い列から順序を付けます。これによって、必要な ROWID に最小限の I/O
で最も速くアクセスできるため、通常はこの方法を使用します。この方法は、主として
主キーや選択頻度の高いレンジ・スキャンに使用します。
2.
列に順序を付け、データをクラスタ化またはソートして I/O を削減します。大規模なレ
ンジ・スキャンでは、通常、選択頻度の低い順に列に順序を付けるか、取り出す順に
データをソートすると、I/O を削減できます。第 16 章「索引およびクラスタの使用方
法」を参照してください。
2-16　Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
ビューの使用
ビューを使用すると、アプリケーションの設計がスピードアップされ簡潔になります。簡単
なビュー定義により、データの取出し、表示、収集および格納処理を優先するプログラマ
が、複雑なデータ・モデルから解放されます。
ただし、ビューは、クリーンなプログラミング・インタフェースを提供する一方で、最適と
はいえないリソース集中型の問合せの原因になる場合があります。ビューの最も不適切な使
用例は、ビューが他の複数のビューを参照し、その複数のビューが問合せ内で結合されてい
る場合です。多くの場合、開発者はビューを使用せずに表から直接問合せを満たすことがで
きます。ビューが持つ本来の特性により、通常は、オプティマイザによる最適な実行計画の
生成が困難になります。
SQL の実行効率
システム開発の設計およびアーキテクチャ・フェーズでは、アプリケーション開発者が SQL
の実行効率を理解していることが重要です。これには、開発環境が次の特性をサポートして
いる必要があります。
■
適切なデータベース接続管理
データベースへの接続は、コストが高くスケーラブルでない操作です。このため、デー
タベースへの同時接続数はできるだけ少なくする必要があります。アプリケーションの
初期化時にユーザーが 1 人接続しているという単純なシステムが理想的です。しかし、
Web ベース・アプリケーションや多層アプリケーションでは、複数のアプリケーショ
ン・サーバーが使用されてユーザーへのデータベース接続が多重化しているため、接続
数を少なくするのは困難です。このようなタイプのアプリケーションでは、データベー
ス接続をプールし、ユーザー要求ごとに接続が再確立されないように設計する必要があ
ります。
■
適切なカーソルの使用と管理
ユーザー接続のメンテナンスも、システムでの解析アクティビティの最小化にとっては
同じように重要です。解析とは、SQL 文を解釈し、その SQL 文の実行計画を作成する
処理です。この処理には、構文検査、セキュリティ検査、実行計画の生成、共有プール
への共有構造のロードなど、多くのフェーズがあります。解析操作には、次の 2 種類が
あります。
■
■
ハード解析 : SQL 文が初めて送信され、共有プール内に一致するものがない場合で
す。ハード解析は、解析に関連するすべての操作を実行するため、最もリソース集
中型であり、スケーラブルではありません。
ソフト解析 : SQL 文が初めて送信され、共有プール内に一致するものがある場合で
す。別のユーザーが以前に実行した結果が一致することがあります。SQL 文は共有
されるため、パフォーマンスが向上します。ただし、ソフト解析では、システム・
リソースを消費する構文検査やセキュリティ検査が必要であり、理想的とは言えま
せん。
パフォーマンスを考慮した設計と開発
2-17
アプリケーション設計の原則
解析はできるだけ最小限にする必要があるため、アプリケーション開発者は、SQL 文を
1 回解析し、その SQL 文を繰り返して実行するようにアプリケーションを設計してくだ
さい。これは、カーソルを使用して行います。経験のある SQL プログラマであれば、
カーソルのオープンと再実行の概念を理解しています。
アプリケーション開発者は、SQL 文が共有プール内で共有されるようにする必要もあり
ます。これを行うには、問合せの中で実行ごとに変化する部分をバインド変数として表
します。これを行わないと、SQL 文は 1 回解析された後、他のユーザーから再利用され
ない可能性があります。SQL の共有を確実にするには、SQL 文ではバインド変数を使
用し文字列リテラルは使用しないようにします。たとえば、次のようにします。
文字列リテラルがある文は、次のとおりです。
SELECT * FROM employees
WHERE last_name LIKE 'KING';
バインド変数がある文は、次のとおりです。
SELECT * FROM employees
WHERE last_name LIKE :1;
次の例は、単純な OLTP アプリケーションでのテスト結果です。
Test
#Users Supported
No Parsing all statements
270
Soft Parsing all statements
150
Hard Parsing all statements
60
Re-Connecting for each Transaction
30
このテストは、4 台の CPU を搭載したマシンで実行されました。システム上の CPU の
数が増えると、差異も大きくなります。SQL 文の最適化の詳細は、第 12 章「SQL
チューニングの概要」を参照してください。
2-18　Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
アプリケーションの実装
開発環境およびプログラミング言語の選択は、開発チームのスキルと、アプリケーションの
指定時に決定したアーキテクチャにより決定します。ただし、簡単なパフォーマンス管理規
則がいくつかあり、これに従うと、スケーラブルで高パフォーマンスのアプリケーションの
実現につながります。
1.
ソフトウェア・コンポーネントに適した開発環境を選択し、その環境によってパフォー
マンスに関する設計が制限されないようにしてください。設計が制限される場合は、選
択した言語または環境が不適切であると言えます。
■
ユーザー・インタフェース
プログラミング・モデルには、HTML 生成からウィンドウ・システムの直接コール
まで様々なモデルがあります。開発方法では、ユーザー・インタフェース・コード
の応答時間に重点を置く必要があります。HTML または Java をネットワークで送
信する場合は、ネットワーク通信量や対話を最小限に抑えるようにしてください。
■
ビジネス・ロジック
Java や PL/SQL などのインタープリタ型言語は、ビジネス・ロジックのエンコー
ドには理想的です。これらの言語は完全に移植可能であるため、ロジックのアップ
グレードが比較的簡単にできます。どちらの言語も構文が豊富で、読みやすく解析
しやすいコードを作成できます。ビジネス・ロジックで複雑な数学関数が必要な場
合は、コンパイラ型バイナリ言語が必要になる場合があります。ビジネス・ロジッ
ク・コードは、クライアント・マシン、アプリケーション・サーバーおよびデータ
ベース・サーバーに配置できます。ただし、アプリケーション・サーバーに配置す
るのが最も一般的です。
■
ユーザー要求とリソース割当て
これがプログラミング言語によって影響を受けることはほとんどありませんが、
データベース接続やカーソル管理を隠すツールや第 4 世代言語では、非効率的なメ
カニズムが使用されることがあります。このようなツールや環境を評価するとき
は、データベース接続モデルおよびカーソルやバインド変数の使用方法をチェック
してください。
■
データ管理とトランザクション
これに関しては、プログラミング言語による影響はほとんどありません。
2.
ソフトウェア・コンポーネントを実装するときは、その機能を実装するようにし、他の
コンポーネントに関連付けられている機能は実装しないでください。他のコンポーネン
トの機能を実装すると、設計や実装が最適でなくなります。これはすべてのコンポーネ
ントに当てはまります。
パフォーマンスを考慮した設計と開発
2-19
アプリケーション設計の原則
3.
機能のギャップをそのまま放置したり、検討中のソフトウェア・コンポーネントを設
計、実装またはテストで使用しないでください。多くの場合、ギャップは、アプリケー
ションを展開するか、実際のボリュームでテストするまで検出されません。このギャッ
プは、通常、アーキテクチャまたは当初のシステム仕様が不適切であることを示しま
す。データ・アーカイブ / パージ・モジュールは、初期のシステム設計、作成および実
装時には最も無視されやすいモジュールです。
4.
プロシージャ型ロジックを実装するときは、C、Java、PL/SQL などの手続き型言語で
実装するようにします。データ・アクセス（問合せ）またはデータ変更（DML）を実装
するときは、SQL を使用します。これは、プロシージャ型コードとデータ・アクセス
（非プロシージャ型 SQL）コードが混在しているビジネス・ロジック・モジュール特有
の規則です。SQL アクセスにプロシージャ型ロジックを使用することも考えられます
が、これはリソースを多く消費する SQL になる傾向があります。DECODE ケース文を含
む SQL 文は、多くの場合、最適化が必要です。大量の OR 述語または集合演算子
（UNION や MINUS など）を含む文も同様です。
5.
頻繁にアクセスし、変更がほとんどなく、繰り返し取り出すのにコストがかかるデータ
は、キャッシュします。ただし、キャッシュ・メカニズムは使いやすくして、元の方法
でデータにアクセスするよりもコストが実際に低くなるようにしてください。これは、
頻繁に使用するデータ値はリモート・データ・ストアまたはコストがかかるデータ・ス
トアから繰り返し取り出すよりも、キャッシュするかローカルに格納する必要があるす
べてのモジュールにあてはまります。
ローカルにキャッシュするデータの一般的な候補例をいくつか示します。
■
■
■
■
■
本日の日付。SELECT SYSDATE FROM DUAL が、データベースにかかるワークロー
ドの 60% 以上を占めることもあります。
現行ユーザー名。
税率、値引率、位置情報など、繰り返し使用するアプリケーション変数および定
数。
ローカルでのデータ・キャッシュは、さらに、アプリケーション・サーバー中間層
へのローカル・データ・キャッシュの作成へ発展させることができます。これによ
り、中央のデータベース・サーバーの負荷が減ります。ただし、ローカル・キャッ
シュを作成するときは、パフォーマンス上の利点がなくなるほどキャッシュが複雑
にならないように注意してください。
ローカル順序の生成
キャッシュを使用する場合は、設計上の意味を考慮してください。たとえば、ユーザー
が午前 0 時に接続して日付がキャッシュされた場合、その日付値は無効になります。
6.
コンポーネント間のインタフェースを最適化し、すべてのコンポーネントが最もスケー
ラブルな構成で使用されるようにします。この規則に説明はほとんど不要で、すべての
モジュールとインタフェースに当てはまります。
2-20　Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
7.
外部キー参照を使用します。アプリケーションから参照整合性を適用するのはコストが
かかります。外部キー参照は、子の列値を親から選択してその存在を確認することで、
メンテナンスできます。Oracle が提供する外部キー制約（SQL は使用していません）
は、高速で、しかも簡単に宣言でき、ネットワークの通信は発生しません。
8.
End to End Application Tracing で使用するアクション名およびモジュール名の設定を検
討してください。設定すると、ワークロードの問題を柔軟にトレースできます。20-2
ページの「End to End Application Tracing」を参照してください。
アプリケーション開発の傾向
今日のアプリケーション開発には、2 つの大きな特徴があります。1 つは、コンパイラ型の
C または C++ アプリケーションにかわって Java の使用が増えていること、もう 1 つは、ス
キーマ設計に影響を与えるオブジェクト指向手法の使用が増えていることです。
Java はコードの移植性に優れ、高い可用性をプログラマに提供します。ただし、Java にはパ
フォーマンスに影響することが多数あります。Java はインタプリタ型言語であるため、C 言
語などのコンパイラ型言語に比べてロジックの実行速度が遅くなります。その結果、クライ
アント・マシンでのリソース使用率が増大します。このため、強力な CPU をクライアン
ト・マシンや中間層マシンに設置する必要があり、プログラマは効率的なコードを作成する
ようにさらに注意を払う必要があります。
Java はオブジェクト指向言語であるため、データ・アクセスはビジネス・ロジックを実行し
ないクラスに分離されやすくなります。この結果、プログラマは、使用するデータ・アクセ
ス・メソッドの効率を認識せずにそのメソッドを呼び出す可能性があります。これにより、
データベース・アクセスが最小限になり、データベースへのインタフェースには最も簡潔で
単純なインタフェースが使用される傾向があります。
このタイプのソフトウェア設計では、常にすべての WHERE 述語が問合せに効率的に組み込
まれるとは限らず、行のフィルタ処理は Java プログラムで実行されます。これはかなり非
効率的です。さらに、DML 操作、特に INSERT 操作では単一の INSERT が実行され、配列
インタフェースは使用できません。これが、プロシージャ・コールによりさらに非効率的に
なることがあります。データベースとのデータのやりとりでは、実際のデータベース・コー
ルよりも多くのリソースが使用されます。
一般に、最善の総合的トランザクション設計を実現するには、データ・アクセス・コールを
ビジネス・ロジックの次に配置するのが最適です。
プログラミング・レベルでのオブジェクト指向の採用は、Oracle サーバー内にオブジェクト
指向データベースを作成することに発展しています。これは、オブジェクト構造を BLOB 内
に格納し、データベースを索引付きカード・ファイルとしてのみ効率的に使用するという
ケースから、Oracle オブジェクト・リレーショナル機能を使用するというケースまで、様々
な形で現れています。
オブジェクト指向アプローチをスキーマ設計に採用する場合は、リレーショナル格納モデル
の柔軟性が失われないように注意してください。多くの場合、スキーマ設計でのオブジェク
ト指向アプローチにより、データ構造にかなりの非正規化が生じ、相当なメンテナンスが必
要になり、オブジェクトに関連付けられた REF ポインタも必要になります。このような設計
パフォーマンスを考慮した設計と開発
2-21
ワークロードのテスト、モデル化および実装
は、多くの場合、リレーショナル格納方式に置き換わる前の階層データベースやネットワー
ク・データベースの設計に戻ることを意味します。
要約すると、データベースにデータを長期間格納し、同一スキーマに対する非定型問合せま
たはアプリケーション開発をある程度予期している場合は、リレーショナル格納方式によっ
て最善のパフォーマンスと柔軟性が得られることがわかります。
ワークロードのテスト、モデル化および実装
この項では、ワークロードの見積り、モデル化、実装およびテストについて説明します。
データのサイズ設定
不適切なサンプル・セットを使用すると、可変長データを扱うときにサイズの見積りを誤る
ことがあります。また、データ量の増加に伴い、キーの長さも大幅に長くなり、列サイズの
見積りに変更が生じます。
システムは、本番稼働が始まると、データベース規模の拡大、特に索引の増加は予想が困難
になります。表は時間とともに増大し、索引は、キーの生成、挿入パターンおよび行の削除
というアプリケーションの個々の動作によって変化します。最悪のケースは、昇順キーを使
用して行を挿入してから、一部の行を残してほとんどの行を表の左側から削除した場合で
す。これによって、ギャップと無駄な領域が残ります。索引をこのように使用している場合
は、オンラインの索引再作成機能の使用方法を理解してください。
優れた DBA であれば、オブジェクトごとに領域割当てを監視し、増大して制御できなくな
る可能性のあるオブジェクトを探します。アプリケーションを十分に理解することで、急速
にまたは予測を超えて増大する可能性のあるオブジェクトを発見できます。これは、あらゆ
るシステムのパフォーマンス計画と可用性計画の両方で重要なことです。本番データベース
を実装するときは、対話型ユーザーがアプリケーションを使用しているときに領域管理が最
小限になるように設計する必要があります。これは、データ・セグメント、一時セグメント
およびロールバック・セグメントのすべてに当てはまります。
2-22　Oracle Database パフォーマンス・チューニング・ガイド
ワークロードのテスト、モデル化および実装
ワークロードの見積り
容量計画やテスト用のワークロードの見積りは、黒魔術にもたとえられます。見積りに関連
する変数の数を考えると、正確な見積りがほとんど不可能であることが容易に理解できま
す。それでも、設計者は、マシンと CPU の数、メモリーおよびディスク・ドライブの数を
指定し、最終的にはアプリケーションを展開する必要があります。サイズ設定に使用する技
法はいくつかあり、それぞれに利点があります。サイズを設定するときは、少なくとも 2 つ
の方法を使用して意思決定プロセスを検証し、サポート用ドキュメントを準備することをお
薦めします。
類似システムからの推定
これは完全に経験に基づくアプローチで、特性が類似しており、パフォーマンスが把握され
ている既存のシステムを基礎システムとして使用します。このシステムの仕様を、サイズ設
定の担当者が既知の相違点に応じて変更します。このアプローチでは、既存のシステムと関
連する部分は参考になりますが、相違点のある部分を扱うときにはほとんど参考になりませ
ん。
このアプローチは、巨大なビル、船舶、橋梁、石油掘削装置などの大規模エンジニアリング
分野のほとんどすべてで、エンジニアリング・プロジェクトのコストを見積るときに使用さ
れています。参照システムがサイズの点で計画しているシステムと大きな差がある場合は、
コンポーネントのいくつかが設計上限を超えてしまう可能性があります。
ベンチマーク
ベンチマーク・プロセスは、リソースと時間をかなり消費し、必ずしも正確な結果が得られ
るとはかぎりません。開発初期またはプロトタイプの段階でアプリケーションをベンチマー
クでシミュレーションすると、実際の本番システムの場合とは似て非なるものを計測する危
険性があります。意外に聞こえると思いますが、オラクル社では長年にわたりデータベース
開発組織とともに顧客アプリケーションのベンチマークを行っていますが、ベンチ・マー
ク・アプリケーションと実際の本番システムとの間に明確な相関関係はまだ認められていま
せん。これは、開発プロセスでアプリケーションの非効率な点がいくつか組み込まれてしま
うことが主な原因です。
しかし、ベンチマークは、許容可能なレベルの精度でシステムのサイズを設定するためには
有効に利用されています。特に、ベンチマークは、システムの負荷が最大になったときの実
際の I/O 要求数の判断やリカバリ処理のテストに効果があります。
ベンチマークでは、その性質上、システムの全コンポーネントに対してそれぞれの上限まで
ストレスがかけられます。すべてのコンポーネントにストレスがかけられていくに従って、
ベンチマーク中にアプリケーションの設計および実装のエラーがすべて明らかになります。
また、ベンチマークでは、データベース、オペレーティング・システムおよびハードウェ
ア・コンポーネントもテストされます。ほとんどのベンチマークが急ぎで実行されるため、
システム・コンポーネントが失敗すると障害や問題が発生すると考えてください。ベンチ
マークは実施者にストレスがかかる作業であり、ベンチマークから最大限の結果を得るには
豊富な経験が必要です。
パフォーマンスを考慮した設計と開発
2-23
ワークロードのテスト、モデル化および実装
アプリケーションのモデル化
アプリケーションのモデル化は、複雑な数学的モデル化から、封筒の裏を使用するような典
型的な単純計算まで多岐にわたります。どちらの方法にもメリットがあり、一方は高い精度
を目標とし、もう一方は大まかな見積りを作成します。デメリットは、どちらも実装エラー
や効率の悪さが考慮されないことです。
見積りやサイズ設定のプロセスは、正確性に欠ける技法です。しかし、このプロセスを精査
することで、ある程度知的な見積りを行うことができます。見積りプロセス全体としては、
誤った SQL のコーディング、不適切な索引の設計または不適切なカーソル管理によるアプ
リケーションの非効率は考慮されていません。優れたサイズ設定担当者であれば、アプリ
ケーションの非効率性に対応する余裕を組み入れます。優れたパフォーマンス・エンジニア
であれば、非効率性を見つけて、現実に近い見積りを作成します。アプリケーションの非効
率性を検出するプロセスの詳細は、
「Oracle のパフォーマンス改善方法」を参照してくださ
い。
設計のテスト、デバッグおよび検証
テスト・プロセスは、主に機能テストと安定性テストで構成されます。このプロセスの途中
で、パフォーマンス・テストが実施されます。
アプリケーションのパフォーマンス・テストを実行するときの簡単な規則を説明したリスト
を次に示します。適切に文書化されていると、この情報は、アプリケーション稼働後の本番
アプリケーションと容量計画プロセスにとって重要な情報になります。
■
■
Automatic Database Diagnostic Monitor（ADDM）と SQL Tuning Advisor を使用した
設計の検証
現実的なデータ量とデータ配分によるテスト
すべてのテストは、データが完全に含まれている表を使用して行う必要があります。テ
スト用データベースには、データ量や表のカーディナリティという点で本番システムと
同様のデータを入れておく必要があります。本番と同様の索引をすべて作成し、スキー
マ統計を正しく入力します。
■
正しいオプティマイザ・モードの使用
すべてのテストは、本番で使用するオプティマイザ・モードで実行する必要がありま
す。オラクル社では、問合せオプティマイザを重点的に研究開発してきました。した
がって、問合せオプティマイザの使用をお薦めします。
■
シングル・ユーザーのパフォーマンスのテスト
アイドル状態または使用率が低いシステムでのシングル・ユーザーのパフォーマンスが
許容範囲にあるかテストします。シングル・ユーザーのパフォーマンスが理想的な条件
下で許容範囲に達しない場合、リソースを共有するマルチ・ユーザーの状況で満足なパ
フォーマンスになることはあり得ません。
2-24　Oracle Database パフォーマンス・チューニング・ガイド
ワークロードのテスト、モデル化および実装
■
全 SQL 文の計画の取得と文書化
各 SQL 文の実行計画を取得します。一部の SQL メトリックは、文を最低 1 回実行して
取得する必要があります。このプロセスを使用して、オプティマイザが適切な実行計画
を取得することと、SQL 文の相対コストが CPU 時間と物理 I/O 数の観点から把握され
ていることを検証します。このプロセスは、将来的に最も多くのチューニングやパ
フォーマンス作業が必要になる、使用量の多いトランザクションを識別するのに役立ち
ます。プラン・スタビリティの詳細は、第 18 章「プラン・スタビリティの使用方法」
を参照してください。
■
マルチ・ユーザーのテスト
ユーザーのワークロードやプロファイルがまだ完全に定量化されていない可能性がある
ため、このプロセスを正確に実行するのは困難です。しかし、DML 文を実行するトラ
ンザクションをテストして、ロックの競合やシリアライズの問題がないことは確認する
必要があります。
■
正しいハードウェア構成でのテスト
できるだけ本番システムに近い構成でテストすることが重要です。これは、ネットワー
ク待機時間、I/O サブシステム帯域幅およびプロセッサのタイプと速度についてテスト
する場合に特に重要です。このテストを正確に行わないと、潜在的なパフォーマンスの
問題を正しく分析できません。
■
安定した状態でのパフォーマンスの測定
ベンチマークを行うときは、安定した状態でパフォーマンスを測定することが重要で
す。各ベンチマークの実行には開始フェーズが必要です。このフェーズでは、ユーザー
がアプリケーションに接続し、アプリケーションでの作業を徐々に開始します。このプ
ロセスによって、安定した状態になる前に、頻繁にキャッシュされるデータをキャッ
シュに初期化し、解析などの 1 回実行するのみの操作を完了しておくことができます。
同様に、ベンチマークの実行後には終了フェーズが必要です。このフェーズでは、リ
ソースをシステムから解放し、ユーザーは作業を終了して接続を切断します。
パフォーマンスを考慮した設計と開発
2-25
新規アプリケーションの配置
新規アプリケーションの配置
この項では、アプリケーションの配置に関して設計で必要な決定事項について説明します。
ロールアウトの方法
新しいアプリケーションをロールアウトするときは、次の 2 つの方法が一般的です。
■
■
ビッグ・バン・アプローチ : 全ユーザーが一度に新しいシステムに移行します。
トリクル・アプローチ : ユーザーは既存のシステムから新しいシステムに徐々に移行し
ます。
いずれの方式にもメリットとデメリットがあります。ビッグ・バン・アプローチでは、必要
な規模でアプリケーションを十分にテストしておく必要がありますが、旧システムは完全に
使用されなくなるため、旧システムからのデータの変換と旧システムとの同期が最小限で済
みます。トリクル・アプローチでは、ワークロードの増加に伴い拡張性の問題をデバッグで
きますが、移行中に旧システムとの間でデータを相互に移行する必要性が発生することがあ
ります。
いずれの方法も、それぞれ移行実施中にシステムの停止につながるリスクがあるため、どち
らかを推奨することは困難です。トリクル・アプローチでは、実際のユーザーが新しいアプ
リケーションに移行するにつれてユーザー・プロファイルを作成できるので、システムを再
構成しても、その影響を受けるのは移行済ユーザーのみです。この方式は、初期の段階で移
行したユーザーの作業に影響を与えますが、サポート・サービスの負荷は限定されます。こ
れは、スケジュール外の停止が発生しても、影響を受けるユーザーの割合が小さいことを意
味します。
新規アプリケーションのロールアウト方法は、ビジネスごとに判断してください。採用する
方式には、それぞれ固有の長所と短所があります。テストを重ねて、そのテストから得られ
た知識が増えるほど、最善のロールアウト方式を判断できるようになります。
パフォーマンス・チェックリスト
ロールアウト・プロセスを支援するため、タスク・リストを作成してください。リスト上の
タスクを正しく実行すると、本番で良好なパフォーマンスが得られる可能性が高くなり、問
題が発生した場合にもアプリケーションをすばやくデバッグできます。たとえば、次のよう
にします。
1.
本番データベース用の制御ファイルを作成するときは、MAXINSTANCES、
MAXDATAFILES、MAXLOGFILES、MAXLOGMEMBERS および MAXLOGHISTORY をロール
アウトで予測されるよりも大きい値に設定することで、データベースの成長に対応しま
す。この結果、ディスク領域の使用量が増えて制御ファイルも大きくなりますが、後で
これらを緊急に拡張する必要が生じたときに時間を節約できます。
2.
ブロック・サイズをアプリケーションの開発時に使用した値に設定します。本番同様の
データ量でテストが完了し、現在の SQL 実行計画が正しい場合は、スキーマ統計を開
発 / テスト環境から本番データベースにエクスポートします。
2-26　Oracle Database パフォーマンス・チューニング・ガイド
新規アプリケーションの配置
3.
最小限の初期化パラメータを設定します。他のパラメータはデフォルトのままにしてお
くのが理想的です。チューニングをさらに行う必要がある場合は、システムの負荷が少
ないときに示されます。初期構成でのパラメータの設定の詳細は、第 4 章「パフォーマ
ンスを考慮したデータベースの構成」を参照してください。
4.
データベース・オブジェクトの記憶領域オプションを設定して、ブロック競合の管理に
備えます。INSERT/UPDATE/DELETE 操作が頻繁に発生する表と索引を作成するには、
自動セグメント領域管理を使用する必要があります。ロールバック・セグメントの競合
を回避するには、自動 UNDO 管理を使用する必要があります。UNDO セグメントと一
時セグメントの詳細は、第 4 章「パフォーマンスを考慮したデータベースの構成」を参
照してください。
5.
すべての SQL 文が最適であることを検証し、そのリソース使用を把握します。
6.
データベースに接続しているミドルウェアとプログラムの接続管理が効率的であること
と、ログオン / ログオフが繰り返されていないことを確認します。
7.
SQL 文でカーソルが効率的に使用されていることを確認します。各 SQL 文は、1 回解析
された後、繰り返して実行されるものです。これが正しく行われない原因として最も一
般的なものは、バインド変数が正しく使用されていないことか、WHERE 句の述語が文字
列リテラルとして送信されていることです。プリコンパイラを使用してアプリケーショ
ンを開発している場合は、アプリケーションをプリコンパイルする前に、
MAXOPENCURSORS、HOLD_CURSOR および RELEASE_CURSOR の各パラメータがデフォ
ルト値から再設定されていることを確認します。
8.
すべてのスキーマ・オブジェクトが開発環境から本番データベースに正しく移行されて
いることを確認します。これには、表、索引、順序、トリガー、パッケージ、プロシー
ジャ、ファンクション、Java オブジェクト、シノニム、権限付与およびビューが含まれ
ます。テスト中に変更を加えた場合は、その変更が本番システムにも加えられているこ
とを確認します。
9.
システムをロールアウトした直後に、データベースとオペレーティング・システムの統
計用ベースライン・セットを設定します。最初の統計データにより、設計およびロール
アウト・プロセスで設定した前提事項が検証または訂正されます。
最初のボトルネック（必ず 1 つはあります）の予測を開始し、Oracle のパフォーマンス改善
方法に従ってパフォーマンスを改善します。
パフォーマンスを考慮した設計と開発
2-27
新規アプリケーションの配置
2-28　Oracle Database パフォーマンス・チューニング・ガイド
3
パフォーマンス改善方法
この章では、Oracle のパフォーマンス改善方法について説明します。
この章には次の項があります。
■
Oracle のパフォーマンス改善方法
■
パフォーマンスの緊急の問題に対処する方法
パフォーマンス改善方法
3-1
Oracle のパフォーマンス改善方法
Oracle のパフォーマンス改善方法
Oracle のパフォーマンス方法論は、使用している Oracle システムにおけるパフォーマンス
上の問題を特定するのに役立ちます。この方法論には、ボトルネックの識別とその修正が含
まれています。システムの変更は、ボトルネックの存在を確認した後に行うことをお薦めし
ます。
パフォーマンスの改善は、本質的に反復的なプロセスです。このため、最初のボトルネック
を取り除いても、別のボトルネックが明らかになる可能性があり、パフォーマンスがすぐに
は改善されないことがあります。また、シリアライズ・ポイントが効率の悪い共有メカニズ
ムに移動したことによって、パフォーマンスが低下する場合もあります。経験を重ね、ボト
ルネックの除去方法に厳密に従うことにより、アプリケーションをデバッグしてスケーラブ
ルにすることができます。
パフォーマンスの問題は、通常、スループットの不足または許容範囲を超えたユーザー /
ジョブ応答時間（あるいはその両方）が原因で発生します。問題は、アプリケーション・モ
ジュール間でローカルに発生する場合も、システム全体にわたる場合もあります。
データベース統計やオペレーティング・システム統計を調べる前に、システムで最も重要な
コンポーネントからのフィードバックを取得することが重要です。つまり、システムのユー
ザーと、アプリケーション・コストを最終的に負担する人々からのフィードバックです。
ユーザーからの典型的なフィードバックには、次のような報告が含まれます。
■
オンライン・パフォーマンスがあまりに低いため、部下が業務を遂行できない。
■
請求作業にかかる時間が長すぎる。
■
■
Web トラフィックが多くなると、応答時間が許容できないほど遅くなり、このままでは
顧客を失ってしまう。
現在、1 日に 5000 件の取引を行っているが、システムが限界を超えている。来月は全
ユーザーにロールアウトする予定で、取引数は 4 倍になる見込みである。
このような率直なフィードバックがあると、パフォーマンスの改善作業を成功させる重要な
要因を容易に設定できます。パフォーマンスの目標およびパフォーマンス・エンジニアに
とっての最終基準を決定することで、パフォーマンス・プロセスの管理がすべてのレベルで
簡潔になり円滑に運びます。このような重要な成功要因は、システム統計ではなく現実的な
ビジネス目標の観点から定義した方が効果的です。
前述した典型的なユーザー・フィードバックに対する実際のビジネス目標を、次にいくつか
示します。
■
■
■
請求作業は、3 時間で 1,000,000 件を処理する必要がある。
Web サイトのピーク時には、1 回のページ・リフレッシュに対する応答時間は 5 秒以内
にする。
システムでは、8 時間で 25,000 件の取引を処理可能にする。
3-2　Oracle Database パフォーマンス・チューニング・ガイド
Oracle のパフォーマンス改善方法
最終的な満足度は、システム・パフォーマンスに関するユーザーの認識で判断されます。パ
フォーマンス・エンジニアの役割は、パフォーマンスを低下させるボトルネックを取り除く
ことです。ボトルネックの原因としては、限られた共有リソースの非効率的な使用、または
シリアライズの原因となる共有リソースの不適切な使用が考えられます。すべての共有リ
ソースには限りがあるため、パフォーマンス・エンジニアの目標は、共有リソースを効率的
に活用して、ビジネス処理件数を最大にすることです。高いレベルでは、データベース・
サーバー全体を共有リソースとみなすことができます。逆に、低いレベルでは、1 台の CPU
やディスクを共有リソースとみなすことができます。
Oracle のパフォーマンス改善方法は、パフォーマンス目標を達成するまで、または目標の達
成が不可能と判断されるまで適用できます。このプロセスは非常に反復的なプロセスであ
り、システムのパフォーマンスにほとんど影響のない調査も行うことになります。重要なボ
トルネックを正確かつ適時に特定できるスキルを身に付けるには、時間と経験が必要です。
ただし、利用できるデータや統計を軽視すると、たとえ経験が豊かな技術者でもその経験が
裏目に出ることがあります。このような技術者は、根拠のない思い込みと慣習でデータベー
スをチューニングしようとします。これは、データベースのチューニング方法としては非常
に危険でコストもかかり、成功するとは考えられません。
Automatic Database Diagnostic Monitor（ADDM）は、パフォーマンス改善方法の各部を実
装し、統計を分析して、重大なパフォーマンスの問題の自動診断を提供します。ADDM を使
用すると、システム・パフォーマンスの改善に伴う所要時間を大幅に短縮できます。ADDM
の詳細は、第 6 章「自動パフォーマンス診断」を参照してください。
今日のシステムは多様で複雑であるため、パフォーマンス分析のための絶対的な法則は定義
できません。本質的に、Oracle のパフォーマンス改善方法は、作業の方法を定義するもので
あり、確定した一連の法則を定義するものではありません。ボトルネックの検出における唯
一の法則は、法則がないということです。優れたパフォーマンス・エンジニアは、提供され
たデータを利用し、様々な角度から検討してパフォーマンスの問題を判断します。
Oracle のパフォーマンス改善方法の手順
1.
次に示す初期標準チェックを実行します。
a.
ユーザーから率直なフィードバックを取得します。パフォーマンス・プロジェクト
の適用範囲、最終的なパフォーマンス目標、さらに将来のパフォーマンス目標を決
定します。このプロセスは、今後の容量計画にとっての鍵です。
b.
パフォーマンスがよいときと悪いときの両方で、オペレーティング・システム、
データベースおよびアプリケーションの統計をフルセットでシステムから取得しま
す。すべての統計を取得できない場合は、可能な範囲で取得します。使用できる統
計がないのは、犯罪捜査で証拠がないのと同じです。証拠がないと、捜査が困難に
なり時間もかかります。
c.
ユーザー・パフォーマンスに関連している全マシンのオペレーティング・システム
が健全であることをチェックします。オペレーティング・システムの健全性を
チェックすることにより、フルに使用されているハードウェアやオペレーティン
グ・システムのリソースを探します。過剰使用のリソースを症状としてリストし、
パフォーマンス改善方法
3-3
Oracle のパフォーマンス改善方法
後で分析します。さらに、すべてのハードウェアでエラーや診断症状がないことを
チェックします。
2.
Oracle で最もよく見られる誤りの上位 10 項目をチェックし、問題となる可能性のある
ものが 1 つでもないか判断します。問題となる可能性がある場合は、症状としてリスト
し、後で分析します。これらの項目をリストに含めるのは、問題となる可能性が高いた
めです。ADDM では、これらの上位 10 項目のうち 9 項目が自動的に検出されレポート
されます。第 6 章「自動パフォーマンス診断」および 3-6 ページの「Oracle システムに
おける誤りの上位 10 項目」を参照してください。
3.
症状を手がかりにして、システムで発生している状況の概念モデルを作成し、パフォー
マンスの問題の原因を把握します。3-5 ページの「パフォーマンスを概念的にモデル化
する際の意思決定プロセスの例」を参照してください。
4.
一連の修正処理とシステムに対して予想される動作を提示し、アプリケーションに対し
て最も有効な処理から順に適用します。ADDM により、各推奨事項と予測されるメリッ
トが生成されます。パフォーマンス改善作業の原則は、変更は一度に 1 つのみとし、変
更前後の差異を測定することです。ただし、システム停止時間に制約があり、この方法
を忠実に実行できないことがあります。一度に複数の変更を適用する場合は、それぞれ
の変更を切り離すようにしてください。これにより、それぞれの変更の効果を個別に検
証できます。
5.
変更により期待された効果があることを検証し、ユーザーがパフォーマンスの改善を認
識したかどうかを確認します。ユーザーが認識しない場合は、さらにボトルネックを探
し、アプリケーションをより正確に把握できるまで、概念モデルの微調整を続けます。
6.
パフォーマンス目標が達成されるまで、または他の制約によって達成が不可能になるま
で、前述の最後の 3 つの手順を繰り返します。
この方法によって、最大のボトルネックが特定され、パフォーマンスの改善に対する客観的
アプローチが使用されます。重要なことは、アプリケーションの効率を高め、リソース不足
とボトルネックを取り除くことにより、パフォーマンスを大幅に改善することです。このプ
ロセスでは、インスタンスのチューニングにより最低限のパフォーマンスの向上（10% 未
満）が期待でき、アプリケーションの効率の悪さを切り離すことで大幅なパフォーマンスの
向上（100% 以上）が期待できます。
3-4　Oracle Database パフォーマンス・チューニング・ガイド
Oracle のパフォーマンス改善方法
パフォーマンスを概念的にモデル化する際の意思決定プロセスの例
概念的なモデル化は、ほとんど決定論的なプロセスです。しかし、パフォーマンスのチュー
ニング経験を重ねるに従い、準拠する必要のある規則は実際にはないことがわかるようにな
ります。様々な統計を解析して最適な意思決定を行うには、柔軟で機敏なアプローチが必要
になります。
迅速かつ簡単なパフォーマンス・チューニング・アプローチには、Automatic Database
Diagnostic Monitor（ADDM）を使用します。ADDM を使用すると、Oracle システムが自動
的に監視され、パフォーマンスの問題が発生した場合は解決のための推奨事項が提供されま
す。たとえば、データベース管理者がユーザーからシステム・パフォーマンスが低下したと
いう苦情を受け取ったとします。データベース管理者は、ただ最新の ADDM レポートを調
べ、問題を解決するにはどの推奨事項を実装すればよいかを確認します。Oracle システムの
監視と診断に役立つ機能については、第 6 章「自動パフォーマンス診断」を参照してくださ
い。
次の手順は、パフォーマンス・エンジニアが自動診断機能を使用せずにボトルネックを調べ
る方法を示しています。これらの手順は、あくまでも手動プロセスのガイドラインです。パ
フォーマンス・エンジニアは、経験を積みながら、それを関連する手順に追加していきま
す。この分析では、オペレーティング・システム統計とデータベース統計が収集されている
ことが前提です。
1.
負荷がまったくないか少ないマシンで、応答時間またはバッチ実行時間はシングル・
ユーザーにとって許容できる範囲ですか ?
許容範囲外の場合は、アプリケーションのコードまたは設計が最適でないと考えられま
す。また、これは、システム・リソースを共有するマルチ・ユーザーの状況では、まっ
たく受け入れられません。このような場合は、アプリケーションの内部統計を取得し、
SQL トレースと SQL 計画の情報を取得します。開発者とともに、データ、索引および
トランザクションの SQL 設計に関する問題を調査し、バッチ処理またはバックグラウ
ンド処理の遅延の可能性について調査します。
2.
CPU がすべて使用されていますか ?
カーネル使用率が 40% を超えた場合は、ネットワーク転送、ページング、スワッピン
グまたはプロセス・スラッシングについてオペレーティング・システムを調べます。そ
れ以外の場合は、ユーザー領域内の CPU 使用率を調べます。CPU を消費するデータ
ベース以外のジョブ（バックアップ、ファイル変換、印刷キューなど）がマシン上で発
生して、CPU 共有リソースの量を制限していないかどうかをチェックします。データ
ベースが CPU のほとんどを使用していることを確認した後、CPU 使用率が上位の SQL
を調べます。これらの文が、今後の分析の基礎になります。SQL および SQL を送信す
るトランザクションが、最適に実行されているかどうかをチェックします。Oracle で
は、V$SQL に CPU 統計が示されます。
関連項目 : V$SQL の詳細は、
『Oracle Database リファレンス』を参照し
てください。
パフォーマンス改善方法
3-5
Oracle のパフォーマンス改善方法
アプリケーションが最適で、SQL が効率的に実行されている場合は、一部の作業をピー
ク時以外に再スケジュールするか、大型のマシンの使用を検討してください。
3.
この段階で、CPU リソースが完全には使用されていないのに、システム・パフォーマン
スがまだ不十分ですか ?
不十分な場合は、サーバー内にシリアライズされた、スケーラブルでない動作がありま
す。サーバーから WAIT_EVENTS 統計を取得し、最大のシリアライズ・ポイントを確認
します。シリアライズ・ポイントがない場合、問題はデータベースの外にある可能性が
高く、これを重点的に調査する必要があります。WAIT_EVENTS をなくすには、アプリ
ケーション SQL を修正し、データベース・パラメータをチューニングします。このプ
ロセスは非常に反復的で、WAIT_EVENTS を系統的にドリルダウンして、シリアライ
ズ・ポイントを取り除く技術を必要とします。
Oracle システムにおける誤りの上位 10 項目
この項では、Oracle システムで最もよく見受けられる誤りをリストします。Oracle のパ
フォーマンス改善方法に従うことで、これらの誤りはすべて回避できます。これらの誤りを
システム内で見つけた場合は、アプリケーション内でパフォーマンス改善の効果のある箇所
を再設計します。Oracle システムの診断とチューニングに役立つ機能については、1-6 ペー
ジの「自動パフォーマンス・チューニング機能」を参照してください。待機イベント・デー
タにより、パフォーマンスに影響を与えるような問題の症状が明らかになりますが、その詳
細は、第 10 章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照
してください。
1.
不適切な接続管理
アプリケーションで、データベースとの対話ごとに接続と切断が行われることがありま
す。この問題は、アプリケーション・サーバー内のステートレス・ミドルウェアで多く
発生します。この問題がパフォーマンスに与える影響はけた違いに大きく、まったくス
ケーラブルではありません。
2.
カーソルと共有プールの不適切な使用
カーソルを使用しないと、解析が繰り返し行われることになります。バインド変数を使
用しないと、すべての SQL 文のハード解析が行われます。この問題がパフォーマンス
に与える影響は甚だしく、まったくスケーラブルではありません。カーソルをオープン
するバインド変数とともにカーソルを使用し、繰り返し実行します。動的 SQL を生成
するアプリケーションは疑ってみます。
3.
不適切な SQL
不適切な SQL とは、アプリケーション要件よりも多くのリソースを使用する SQL で
す。たとえば、意思決定支援システム（DSS）による問合せが 24 時間以上実行されてい
る場合や、オンライン・アプリケーションからの問合せに 1 分以上かかる場合などがあ
ります。大量のシステム・リソースを使用する SQL は、改善の可能性があるかどうかを
調査する必要があります。ADDM により高負荷の SQL が識別され、SQL Tuning
3-6　Oracle Database パフォーマンス・チューニング・ガイド
Oracle のパフォーマンス改善方法
Advisor を使用して改善に関する推奨事項を提供できます。第 6 章「自動パフォーマン
ス診断」および第 13 章「自動 SQL チューニング」を参照してください。
4.
標準以外の初期化パラメータの使用
このようなパラメータは、不適切なアドバイスや不正確な前提に基づいて実装されてい
ることがあります。ほとんどのシステムでは、許容範囲内のパフォーマンスを提供する
ために、基本的なパラメータ・セットのみが使用されます。特に、ラッチに対する
SPIN_COUNT に関連するパラメータとマニュアルに記載されていないオプティマイザ機
能は、多くの問題の原因となり、このためにかなりの調査が必要になることがありま
す。
また、初期化パラメータ・ファイルに設定したオプティマイザ用パラメータが、実証済
の最適実行計画をオーバーライドしてしまう可能性があります。このため、スキーマ、
スキーマ情報およびオプティマイザの設定はグループとしてまとめて管理し、一貫した
パフォーマンスになるようにします。
関連項目 :
■
■
■
5.
初期化パラメータおよびデータベース作成の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照
してください。
初期インスタンス構成でのパラメータと設定の詳細は、4-2 ページの
「初期インスタンス構成のパフォーマンスの考慮事項」を参照してく
ださい。
誤ったデータ I/O の取得
多くのサイトが、使用可能ディスク上にデータベースを適切にレイアウトしていませ
ん。また、ディスクを I/O 帯域幅ではなくディスク領域によって構成し、ディスク数を
誤って指定しているサイトもあります。第 8 章「I/O 構成および設計」を参照してくだ
さい。
6.
REDO ログの設定の問題
多くのサイトが、数も少なくサイズも小さい REDO ログを使用して運用されています。
REDO ログのサイズが小さいと、システム・チェックポイントがバッファ・キャッシュ
と I/O システムに高い負荷をかけ続けることになります。REDO ログの数が少なすぎる
と、アーカイブが間に合わないので、データベースはアーカイブ・プロセスが追い付く
まで待機します。パフォーマンスの観点からの REDO ログのサイズ設定の詳細は、第 4
章「パフォーマンスを考慮したデータベースの構成」を参照してください。
パフォーマンス改善方法
3-7
Oracle のパフォーマンス改善方法
7.
空きリスト、空きリスト・グループ、トランザクション・スロット（INITRANS）また
はロールバック・セグメントの不足による、バッファ・キャッシュ内でのデータ・ブ
ロックのシリアライズ
この問題は、INSERT 操作が多いアプリケーション、ブロック・サイズを 8KB 以上に上
げたアプリケーション、またはアクティブ・ユーザーの数が多くロールバック・セグメ
ントの数がほとんどないアプリケーションで特によく見受けられます。自動セグメント
領域管理（ASSM）と自動 UNDO 管理を使用して、この問題を解決します。
8.
時間のかかる全表スキャン
大量の全表スキャンまたは対話型のオンライン操作での全表スキャンで時間がかかる場
合は、トランザクション設計が不適切であるか、索引が欠落しているか、SQL 最適化が
不十分です。時間のかかる表スキャンは、本質的に I/O 集中型で、スケーラブルではあ
りません。
9.
大量の再帰的（SYS）SQL
SYS によって実行される大量の再帰的 SQL は、エクステント割当てなどの領域管理操
作が発生していることを示します。これはスケーラブルではなく、ユーザーの応答時間
に影響を与えます。ローカル管理表領域を使用して、エクステント割当てによる再帰的
SQL を減らしてください。別のユーザー ID で実行される再帰的 SQL は、SQL および
PL/SQL である可能性が高く、問題ではありません。
10. 配置および移行時のエラー
アプリケーションが必要以上にリソースを使用する場合、その原因の多くは、表を所有
するスキーマが開発環境または古い実装から正しく移行されていないことにあります。
この例としては、索引の欠落や不正確な統計があります。このようなエラーは、不適切
な実行計画や、ユーザー対話パフォーマンスの低下につながります。パフォーマンスが
わかっているアプリケーションを移行するときは、DBMS_STATS パッケージを使用して
スキーマ統計をエクスポートし、プラン・スタビリティを維持します。
ADDM では、この種のエラーが直接検出されることはありませんが、それによる高負
荷 SQL は明らかになります。
3-8　Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスの緊急の問題に対処する方法
パフォーマンスの緊急の問題に対処する方法
この項では、パフォーマンスに関する緊急事態に対処する方法について説明します。アプリ
ケーション・パフォーマンスの確立と改善の方法については、すでに詳細に説明しました。
しかし、緊急時には、システム・コンポーネントの変化によって、信頼性の高い予測可能な
システムが予測不可能でユーザー要求を満たせないシステムに変化します。
このような場合のパフォーマンス・エンジニアの役割は、何が変化したかをすばやく判断
し、適切な処理を行って、通常のサービスをできるだけ早く再開することです。多くの場
合、緊急の処理が必要であり、パフォーマンス改善方法を厳密に実行することは現実的では
ありません。
パフォーマンス・エンジニアは、パフォーマンスの問題にただちに対処した後、十分なデ
バッグ情報を収集して、その問題をより明らかに把握するか、それができない場合は、少な
くとも同じ問題が再発しないようにする必要があります。
緊急のパフォーマンスの問題をデバッグする方法は、このマニュアルの前の章で説明したパ
フォーマンス改善方法と同じです。ただし、急を要するという問題の性質上、様々な段階で
簡便法が使用されます。デバッグ・プロセスの進行中に見つかった事実を詳細にメモし記録
しておくことが、後で行う分析と修正作業の正当化には不可欠です。これは、医師が患者の
容態を克明に記録して、将来の参照資料として役立てるのと同じです。
パフォーマンスの緊急の問題に対処する方法の手順
パフォーマンスの緊急の問題に対処する方法は、次のとおりです。
1.
パフォーマンスの問題を調査し、問題の症状を収集します。このプロセスには、次の作
業が含まれます。
■
■
■
2.
システムのパフォーマンスが低下した状況について、ユーザー・フィードバックを
収集します。問題がスループットか応答時間かを調べます。
「パフォーマンスが正常だった時点から何が変化しましたか ?」という質問をユー
ザーにします。この質問に対する答が、問題の手がかりになることがあります。た
だし、状況が悪化する中で先入観のない答を得るのは難しいことがあります。問題
の前と後で取得された参照データ（収集済の統計やログ・ファイル）を見つけるよ
うにします。
自動チューニング機能を使用して問題を診断および監視します。Oracle システムの
診断とチューニングに役立つ機能については、1-6 ページの「自動パフォーマンス・
チューニング機能」を参照してください。また、Oracle Enterprise Manager のパ
フォーマンス機能を使用すると、上位の SQL およびセッションを識別できます。
アプリケーション・システムの全コンポーネントのハードウェア使用が健全であること
をチェックします。CPU 使用率が最も高いコンポーネントをチェックし、システムの
全コンポーネントについて、ディスクとメモリーの使用およびネットワーク・パフォー
マンスをチェックします。このプロセスによって、問題の原因となっている層をすばや
く特定できます。問題がアプリケーション内で発生している場合は、分析の重点をアプ
パフォーマンス改善方法
3-9
パフォーマンスの緊急の問題に対処する方法
リケーションのデバッグへ移します。それ以外の場合は、データベース・サーバーの分
析に進みます。
3.
データベース・サーバーが CPU 上で制約を受けているかどうか、待機イベントで待機
し続けているのかを判断します。データベース・サーバーが CPU 上で制約を受けてい
る場合は、次の点を調べます。
■
■
■
オペレーティング・システム・レベルで大量の CPU を消費しているセッション
（V$SESS_TIME_MODEL でデータベースの CPU 使用率を調べます。）
データベース・レベルで多数のバッファ取得を実行しているセッションまたは文
（V$SESSTAT および V$SQL を調べます。
）
最適ではない SQL の実行の原因となった実行計画の変更（特定が困難な場合もあり
ます。
）
■
初期化パラメータの誤設定
■
コード変更または全コンポーネントのアップグレードによるアルゴリズムの問題
データベース・セッションがイベントを待機している場合は、V$SESSION_WAIT にリ
ストされている待機イベントに従って、シリアライズの原因を判断します。V$ACTIVE_
SESSION_HISTORY ビューには、サンプリングされたセッション・アクティビティの履
歴が含まれており、問題が終了してシステムが通常の操作に戻った後も診断に使用でき
ます。ライブラリ・キャッシュに大量の競合がある場合は、データベースにログオンし
たり SQL を送信するのが不可能なことがあります。このような場合は、履歴データを
使用して、そのラッチで競合が突然発生した原因を判断します。ほとんどが I/O 待機の
場合は、V$ACTIVE_SESSION_HISTORY を調べて、すべての入出力を実行するセッ
ションで実行中の SQL を判断します。待機イベントの詳細は、第 10 章「パフォーマン
ス・ビューを使用したインスタンスのチューニング」を参照してください。
4.
緊急時の処理を適用して、システムを安定化します。これには、アプリケーションの一
部をオフラインにする処理や、システムに適用できるワークロードを制限する処理が含
まれます。また、システムの再起動や処理中のジョブの停止も含まれることがありま
す。これらの処理は、当然、サービス・レベルに影響を与えることになります。
5.
システムが安定していることを確認します。システムを変更したり制限した場合は、シ
ステムが安定したことを確認し、データベースに関する参照統計情報を収集します。次
に、このマニュアルの前の章で説明した厳密なパフォーマンス改善方法に従って、すべ
ての機能とユーザーをシステムに戻します。このプロセスを完了するには、アプリケー
ションの大幅な再設計が必要になることがあります。
3-10　Oracle Database パフォーマンス・チューニング・ガイド
第 III 部
インスタンスのパフォーマンスの最適化
第 III 部では、Oracle インスタンスのパフォーマンスを最適化するために、データベース・
システムの様々な要素をチューニングする方法について説明します。
第 III 部には次の章が含まれます。
■
第 4 章「パフォーマンスを考慮したデータベースの構成」
■
第 5 章「自動パフォーマンス統計」
■
第 6 章「自動パフォーマンス診断」
■
第 7 章「メモリーの構成と使用方法」
■
第 8 章「I/O 構成および設計」
■
第 9 章「オペレーティング・システム・リソース」
■
第 10 章「パフォーマンス・ビューを使用したインスタンスのチューニング」
■
第 11 章「ネットワークのチューニング」
4
パフォーマンスを考慮したデータベースの
構成
この章では、パフォーマンスを考慮してデータベースを構成するための、オラクル社の方法
論の概要を説明しています。Oracle データベース・インスタンスのパフォーマンスの修正は
後でも可能ですが、データベースの初期構成をニーズにあわせて適切に行うことによって、
パフォーマンス目標の多くは達成可能です。
この章には次の項があります。
■
初期インスタンス構成のパフォーマンスの考慮事項
■
適切なパフォーマンスを得る表の作成とメンテナンス
■
共有サーバーのパフォーマンスの考慮事項
パフォーマンスを考慮したデータベースの構成
4-1
初期インスタンス構成のパフォーマンスの考慮事項
初期インスタンス構成のパフォーマンスの考慮事項
この項では、パフォーマンスに重要な影響を与えるデータベース・インスタンスの初期構成
オプションについて説明します。
Database Configuration Assistant（DBCA）を使用してデータベースを作成する場合、提供
されるシード・データベースには必要な基本的初期化パラメータが組み込まれており、この
章で説明するパフォーマンス推奨事項を満たしています。
関連項目 :
■
■
Database Configuration Assistant を使用したデータベース作成の詳細
は、
『Oracle Database 2 日でデータベース管理者』を参照してくださ
い。
データベース作成プロセスの詳細は、
『Oracle Database 管理者ガイド』
を参照してください。
初期化パラメータ
実行中の Oracle インスタンスは、初期化パラメータ・ファイルで設定される初期化パラ
メータを使用して構成されます。これらのパラメータは、パフォーマンスへの影響を含め、
実行中のインスタンスの動作に影響を与えます。一般的に、関連する設定をほとんど持たな
い非常に単純な初期化ファイルでは、ほとんどの状況に対応できます。表 4-2 に示すきわめ
て少数のパラメータを除き、初期化ファイルはパフォーマンス・チューニングを行う最初の
場所ではありません。
表 4-1 に、最小初期化ファイルで必要なパラメータを示します。これらのパラメータは必須
ですが、パフォーマンスに影響を与えません。
表 4-1 パフォーマンスに影響を与えない必要な初期化パラメータ
パラメータ
説明
DB_NAME
データベースの名前。これは、環境変数 ORACLE_SID に一致する必要
があります。
DB_DOMAIN
インターネット・ドット表記法による、データベースの場所。
OPEN_CURSORS
1 セッション当たりのカーソル（アクティブな SQL 文）の最大数に対
する制限。設定はアプリケーションにより異なり、推奨値は 500 です。
CONTROL_FILES
異なるディスク・ドライブ上に少なくとも 2 つのファイルを含めるよ
うに設定して、制御ファイルの消失による障害を防ぎます。
DB_FILES
データベースに割り当てることのできるファイルの最大数に設定しま
す。
関連項目 : 初期化パラメータの管理の詳細は、『Oracle Database 管理者
ガイド』を参照してください。
4-2　Oracle Database パフォーマンス・チューニング・ガイド
初期インスタンス構成のパフォーマンスの考慮事項
表 4-2 に、パフォーマンスの考慮事項として設定する、最も重要なパラメータを示します。
表 4-2 パフォーマンスに影響を与える重要な初期化パラメータ
パラメータ
説明
COMPATIBLE
互換性を維持しておく Oracle サーバーのリリースを指定します。
このパラメータを使用すると、新しい機能を自分の環境でテスト
せずに、ただちに本番システムで新しいリリースで改善された機
能を利用できるようになります。アプリケーションが Oracle の特
定のリリース用に設計されていて、実際にはそれ以降のリリース
の Oracle をインストールする場合は、このパラメータをアプリ
ケーション設計時のリリースに設定してください。
DB_BLOCK_SIZE
データベース・ファイルに格納され、SGA にキャッシュされる
Oracle データベース・ブロックのサイズを設定します。値の範囲
はオペレーティング・システムにより異なりますが、一般的に 2
の累乗の 2048 ～ 16384 の範囲です。共通値は、トランザクション
処理システムの場合は 4096 または 8192 で、データベース・ウェ
アハウス・システムの場合はさらに大きい値となります。
SGA_TARGET
すべての SGA コンポーネントのサイズ合計を指定します。SGA_
TARGET が指定されている場合、バッファ・キャッシュ（DB_
CACHE_SIZE）、Java プール（JAVA_POOL_SIZE）、ラージ・プー
ル（LARGE_POOL_SIZE）および共有プール（SHARED_POOL_
SIZE）のメモリー・プールは、自動的にサイズ設定されます。
7-3 ページの「自動共有メモリー管理」を参照してください。
PGA_AGGREGATE_TARGET
インスタンスに添付されたすべてのサーバー・プロセスに利用で
きるターゲット集計 PGA メモリーを指定します。PGA メモリー
管理の詳細は、7-49 ページの「PGA メモリー管理」を参照してく
ださい。
PROCESSES
そのインスタンスで起動できるプロセスの最大数を設定します。
このパラメータは、他のパラメータ値の多くがこのパラメータか
ら導出されるため、設定する最も重要なプライマリ・パラメータ
となります。
SESSIONS
これは、デフォルトで PROCESSES の値から設定されます。ただ
し、共有サーバーを使用する場合は、導出された値では不十分で
ある可能性があります。
UNDO_MANAGEMENT
システムで使用する UNDO 領域管理モードを指定します。AUTO
モードの使用をお薦めします。
UNDO_TABLESPACE
インスタンス起動時に使用される UNDO 表領域を指定します。
パフォーマンスを考慮したデータベースの構成
4-3
初期インスタンス構成のパフォーマンスの考慮事項
関連項目 :
■
■
■
第 7 章「メモリーの構成と使用方法」
初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照
してください。
STREAMS_POOL_SIZE 初期化パラメータの詳細は、『Oracle Streams
概要および管理』を参照してください。
UNDO 領域の構成
読取り一貫性、リカバリおよび実際のロールバック文の情報を保持するために、UNDO 領
域が必要です。この情報は 1 つ以上の UNDO 表領域に保持されます。
Oracle では、UNDO データの管理を完全に自動化する、自動 UNDO 管理を提供していま
す。自動 UNDO 管理モードで動作するデータベースは、UNDO セグメントを透過的に作成
および管理します。自動 UNDO 管理を使用することをお薦めするのは、データベース管理
を大幅に簡素化し、UNDO（ロールバック）セグメントの手動チューニングの必要がないた
めです。ロールバック・セグメントを使用する手動 UNDO 管理がサポートされるのは、下
位互換性のためです。
CREATE DATABASE 文に UNDO TABLESPACE 句を追加すると、UNDO 表領域が設定されま
す。自動 UNDO 管理モードでデータベースを処理するには、UNDO_MANAGEMENT 初期化パ
ラメータを AUTO に設定します。
V$UNDOSTAT ビューには、UNDO 領域を監視およびチューニングするための統計が含まれ
ています。このビューを使用して、現行のワークロードに必要な UNDO 領域の大きさをよ
り的確に見積ることができます。この情報を使用して、システム内の UNDO 使用量を簡単
にチューニングすることもできます。V$ROLLSTAT ビューには、UNDO 表領域内の UNDO
セグメントの動作に関する情報が含まれています。
関連項目 :
■
■
■
UNDO 管理アドバイザの詳細は、
『Oracle Database 2 日でデータベー
ス管理者』および Oracle Enterprise Manager オンライン・ヘルプを
参照してください。
自動 UNDO 管理を使用した UNDO 領域の管理の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
動的パフォーマンスの V$ROLLSTAT および V$UNDOSTAT ビューの詳
細は、
『Oracle Database リファレンス』を参照してください。
4-4　Oracle Database パフォーマンス・チューニング・ガイド
初期インスタンス構成のパフォーマンスの考慮事項
REDO ログ・ファイルのサイズ指定
REDO ログ・ファイルのサイズは、パフォーマンスに影響を与えます。これは、データベー
ス・ライター・プロセスおよびアーカイバ・プロセスの動作は REDO ログ・サイズに依存
するためです。一般的に、大きい REDO ログ・ファイルのほうがパフォーマンスが向上し
ます。ログ・ファイルのサイズが小さすぎると、チェックポイント・アクティビティが増加
し、パフォーマンスを低下させるます。
REDO ログ・ファイルのサイズは LGWR のパフォーマンスに影響を与えませんが、DBWR
およびチェックポイントの動作に影響を与える可能性があります。チェックポイントの頻度
には、ログ・ファイルのサイズや FAST_START_MTTR_TARGET 初期化パラメータの設定な
ど、複数の要因が影響します。インスタンスのリカバリ時間を制限するために FAST_
START_MTTR_TARGET パラメータが設定されている場合、Oracle は自動的に必要に応じて
チェックポイントを頻繁に試行しようとします。この場合は、ログ・ファイルが小さすぎる
ことによるチェックポイントの追加発生を防ぐために、ログ・ファイルを十分なサイズに設
定する必要があります。最適なサイズは、V$INSTANCE_RECOVERY ビューから OPTIMAL_
LOGFILE_SIZE 列を問い合せることで取得できます。また、Oracle Enterprise Manager
Database Control の「
「Redo Log Groups」
」ページからも、サイズ設定のアドバイスを取得で
きます。
REDO ログ・ファイルに特定のサイズを推奨できない場合もありますが、100MB ～数 GB の
範囲内にある REDO ログ・ファイルが妥当であると考えられます。システムが生成する
REDO の量に従って、オンライン REDO ログ・ファイルをサイズ設定します。およその目
安として、多くても 20 分ごとに 1 回ログを切り替えます。
関連項目 : REDO ログの管理の詳細は、
『Oracle Database 管理者ガイド』
を参照してください。
追加表領域の作成
Database Configuration Assistant（DBCA）を使用してデータベースを作成する場合、提供
されるシード・データベースには必要な表領域すべてが自動的に組み込まれます。DBCA を
使用しないように選択した場合は、初期データベースの作成後に追加表領域を作成する必要
があります。
すべてのデータベースには、SYSTEM および SYSAUX 表領域に加えて複数の表領域が必要
です。これらの追加表領域は次のとおりです。
■
■
■
ソートなどに使用される一時表領域
読取り一貫性、リカバリおよびロールバック文に関する情報を格納するための UNDO
表領域
実際のアプリケーションで使用する 1 つ以上の表領域
ほとんどの場合、アプリケーションにはいくつかの表領域が必要です。多数のデータファイ
ルを持つ非常に大きな表領域の場合は、複数の ALTER TABLESPACE x ADD DATAFILE Y 文
をパラレルに実行することもできます。
パフォーマンスを考慮したデータベースの構成
4-5
初期インスタンス構成のパフォーマンスの考慮事項
表領域の作成時、表領域を構成するデータファイルは特殊な空のブロック・イメージで初期
化されます。テンポラリ・ファイルは初期化されません。
この初期化は、すべてのデータファイルが、その全体に書込みを行えるようにするためです
が、シリアルに行うと、長い処理になる可能性があります。したがって、複数の CREATE
TABLESPACE 文を同時に実行して、表領域の作成処理を高速化します。永続的な表の場合、
表領域作成時にローカルまたはグローバルのいずれかのエクステント管理を選択するかで、
パフォーマンスに大きな影響を与える可能性があります。読取り操作と比べて、普通または
大規模な、挿入、変更または削除操作を行う永続的な表領域の場合は、ローカル・エクステ
ント管理を選択する必要があります。
永続的な表領域の作成 : 自動セグメント領域管理
永続的な表領域では、自動セグメント領域管理を使用することをお薦めします。これらの表
領域（ビットマップ表領域と呼ばれる）は、ビットマップ・セグメント領域管理が行われる
ローカル管理表領域です。
関連項目 :
■
■
空き領域管理の詳細は、
『Oracle Database 概要』を参照してください。
表領域の自動セグメント領域管理の作成および使用の詳細は、
『Oracle Database 管理者ガイド』を参照してください。
一時表領域の作成
一時表領域を正しく構成すると、ディスク・ソートのパフォーマンスの最適化に役立ちま
す。一時表領域はディクショナリ管理を行うこともローカル管理を行うこともできます。
UNIFORM エクステント・サイズが 1MB の、ローカル管理の一時表領域を使用することをお
薦めします。
一時表領域アクティビティを監視して、一時セグメントに割り当てられているエクステント
の数をチェックする必要があります。1 つのアプリケーションで一時表が広範囲に使用され
ている場合は、多くのユーザーが一時表を同時に使用している場合と同様に、エクステン
ト・サイズを 256KB などの小さい値に設定できます。これは、使用のたびに少なくとも 1 つ
のエクステントが必要になるためです。一時表領域はすべてサイズが均一のローカル管理エ
クステントで作成されるため、EXTENT MANAGEMENT LOCAL 句は一時表領域ではオプション
です。SIZE のデフォルトは 1MB です。
関連項目 :
■
■
■
一時表領域の管理の詳細は、
『Oracle Database 管理者ガイド』を参照
してください。
一時表領域の詳細は、
『Oracle Database 概要』を参照してください。
TEMPORARY 句を含む CREATE 文および ALTER TABLESPACE 文の使用
の詳細は、
『Oracle Database SQL リファレンス』を参照してくださ
い。
4-6　Oracle Database パフォーマンス・チューニング・ガイド
適切なパフォーマンスを得る表の作成とメンテナンス
適切なパフォーマンスを得る表の作成とメンテナンス
アプリケーションをインストールする際、最初のステップで、必要なすべての表および索引
を作成します。表のようなセグメントを作成すると、データのために領域がデータベース内
に割り当てられます。後続のデータベース操作によってデータ容量が増大し、割り当てられ
た領域を上回るようになると、Oracle はそのセグメントを拡張します。
表および索引を作成する際には、次の点に注意してください。
■
表領域の自動セグメント領域管理の指定
最高のパフォーマンスが得られるよう、Oracle によって自動的にセグメント領域が管理
されます。
■
記憶領域オプションの注意深い設定
アプリケーションでは、表または索引の用途によって記憶領域オプションを慎重に設定
する必要があります。この設定には、PCTFREE の値の設定が含まれます。自動セグメ
ント領域管理を使用すると、PCTUSED を指定する必要がありません。
注意 : 空きリストの使用はお薦めしません。自動セグメント領域管理を
使用するには、ローカル管理表領域を作成し、セグメント領域管理の句を
AUTO に設定します。
表圧縮
ヒープ構成表は、どのような種類のアプリケーションにも透過的な圧縮形式で格納できま
す。表圧縮は、主に読取り専用の環境向けに設計されたものであり、DML 操作では処理の
オーバーヘッドの原因となる可能性もあります。ただし、多くの読取り操作で、特にシステ
ムが I/O バウンドである場合は、パフォーマンスが向上します。
データベース・ブロック内の圧縮データは自己完結型です。これは、ブロック内の圧縮され
ていないデータの再現に必要な情報がすべてそのブロック内にあることを意味します。ブ
ロックは、バッファ・キャッシュ内でも圧縮された状態で保持されます。表圧縮により、
ディスク記憶域のみでなく、メモリー使用量、特にバッファ・キャッシュ要件も削減されま
す。表へのアクセスに必要な I/O 操作の量が削減され、バッファ・キャッシュ・ヒットの確
立が高まることで、パフォーマンスの向上が実現します。
圧縮係数の見積り
表圧縮は、個々のブロック内の列値の繰返しを解消することによって機能します。ブロック
内のすべての行と列の重複値は、ブロックの先頭にある、そのブロックのシンボル表と呼ば
れるものに一度格納されます。こうした値の出現箇所はすべて、シンボル表への簡単な参照
で置き換えられます。繰返しの値が多いブロックほど圧縮率が高くなります。
大規模な表を圧縮する前に、予測される圧縮係数を見積もる必要があります。圧縮係数は、
圧縮されていない形式で情報を格納するために必要なブロック数を、圧縮記憶域に必要なブ
パフォーマンスを考慮したデータベースの構成
4-7
適切なパフォーマンスを得る表の作成とメンテナンス
ロック数で除算した値として定義されます。圧縮される表を代表する少数のデータ・ブロッ
クをサンプリングし、圧縮されていない場合と圧縮された場合の各ブロックの平均レコード
数を比較することで、圧縮係数を見積もることができます。これまでの経験では、およそ
1000 のデータ・ブロックを使用することで、きわめて正確な圧縮係数の見積りが可能である
ことがわかっています。サンプリングのブロック数が多いほど、見積り結果が正確になる点
に注意してください。
関連項目 : ブロック・グループ・サンプリング構文 SAMPLE
BLOCK(x,y) の例は、
『Oracle Database SQL リファレンス』を参照して
ください。
チューニングによる圧縮率向上
Oracle では、多くの場合、特別なチューニングなしで、優れた圧縮係数を達成しています。
データベース管理者またはアプリケーション開発者は、実際に圧縮が行われる際にレコード
を再構成することによって、圧縮係数のチューニングを試行できます。チューニングを行う
と、圧縮係数が若干改善されるケースもあれば大きく改善されるケースもあります。
圧縮係数を高めるには、データベース・ブロック内の値の繰返しの可能性を高くする必要が
あります。達成できる圧縮係数は、特定の列または列のペアのカーディナリティ（列値の繰
返しの可能性を表す）およびこれらの列の行の平均長さによって異なります。Oracle の表圧
縮では、単一列の重複値が圧縮されるだけでなく、可能な場合は、複数列値のペアの使用が
試行されます。データ配分について熟知していない場合、最適な順序の予測は非常に困難で
す。
関連項目 : 表圧縮およびパーティションの詳細は、『Oracle データ・ウェ
アハウス・ガイド』を参照してください。
未使用領域の解放
一般に、時間経過とともにセグメント領域が断片化されたり、更新および削除操作の結果と
してセグメントに多数の空き領域が生じます。このようにして粗密に移入されたオブジェク
トは、問合せおよび DML 捜査中にパフォーマンスを低下させる可能性があります。
Oracle Database にはセグメント・アドバイザが用意されており、オブジェクト内の領域の
断片化レベルに基づいて、オブジェクトに解放可能な領域があるかどうかのアドバイスを提
供します。
関連項目 : セグメント・アドバイザの詳細は、『Oracle Database 管理者
ガイド』および『Oracle Database 2 日でデータベース管理者』を参照して
ください。
4-8　Oracle Database パフォーマンス・チューニング・ガイド
適切なパフォーマンスを得る表の作成とメンテナンス
オブジェクトに解放可能な領域がある場合は、データベース・セグメントを圧縮して縮小す
るか、またはデータベース・セグメントの終わりにある未使用領域を割当て解除できます。
関連項目 :
■
■
未使用領域の解放については、
『Oracle Database 管理者ガイド』を参
照してください。
データベース・セグメントの縮小または未使用領域の割当て解除に使
用する SQL 文の詳細は、『Oracle Database SQL リファレンス』を参
照してください。
データの索引付け
最も効率的な索引の作成方法は、データがロードされた後に索引を作成することです。そう
すると、領域管理が大幅に簡単になり、行が挿入されるたびに索引がメンテナンスされるこ
ともありません。これは、SQL*Loader により自動的に行われますが、他の方法で初期デー
タをロードする場合は、手動で行う必要があります。また、索引の作成は、CREATE INDEX
文の PARALLEL 句を使用してパラレルで実行します。ただし、SQL*Loader ではこれを実行
できないため、データのロード後に索引を手動でパラレルに作成する必要があります。
関連項目 : SQL*Loader の詳細は、
『Oracle Database ユーティリティ』を
参照してください。
ソート用データのメモリーの指定
データを含む表での索引の作成中に、データをソートする必要があります。このソートは、
すべての使用可能なメモリーをソートに使用する場合に最も高速に行われます。PGA_
AGGREGATE_TARGET 初期化パラメータを設定して、SQL 作業領域の自動サイズ指定を使用
可能にすることをお薦めします。
関連項目 :
■
■
PGA メモリー管理の詳細は、7-49 ページの「PGA メモリー管理」を
参照してください。
PGA_AGGREGATE_TARGET 初期化パラメータの詳細は、『Oracle
Database リファレンス』を参照してください。
パフォーマンスを考慮したデータベースの構成
4-9
共有サーバーのパフォーマンスの考慮事項
共有サーバーのパフォーマンスの考慮事項
共有サーバーを使用すると、プロセス数と、サーバー・マシンで消費されるメモリー量が削
減されます。共有サーバーは、多数の OLTP ユーザーが断続的なトランザクションを実行す
るシステムに有効です。
また、データベースへの単位時間当たりの接続数が高いシステムでは、一般的に専用サー
バーよりも共有サーバーを使用する方が適しています。共有サーバーでは、接続要求を受け
るよりも前に同時接続要求を処理するためのディスパッチャが使用可能な状態になっていま
す。一方、専用サーバーの場合は、接続固有の専用サーバーが、接続要求ごとに順次初期化
されます。
共有サーバー・アーキテクチャを使用すると、特定のデータベース機能のパフォーマンスが
改善することも、または多少低下することもあります。たとえば、パラレル実行がアクティ
ブな場合、セッションが別の共有サーバーに移行できないことがあります。
クライアントからの要求が処理された後もセッションを移行できない場合があります。これ
はすべてのユーザー情報が、UGA に格納されているとは限らないためです。サーバーがク
ライアントからの要求の処理を待機していた場合、UGA に格納されていなかったユーザー
状態にはアクセスできません。これを回避するために、個々の共有サーバーは、しばしば
ユーザー・セッションにバインドされた状態を続ける必要があります。
関連項目 :
■
■
共有サーバーの管理の詳細は、
『Oracle Database 管理者ガイド』を参
照してください。
共有サーバー用のディスパッチャの構成の詳細は、
『Oracle Net
Services 管理者ガイド』を参照してください。
ある種の機能を使用する場合、あるサーバーがセッションに長期間バインドされる可能性が
あるため、追加の共有サーバーを構成する必要が生じる場合があります。
この項では、Oracle のアーキテクチャで使用するプロセスの競合を低減する方法について説
明します。
■
ディスパッチャ固有のビューを使用する競合の識別
■
共有サーバー・プロセスの競合の識別
4-10　Oracle Database パフォーマンス・チューニング・ガイド
共有サーバーのパフォーマンスの考慮事項
ディスパッチャ固有のビューを使用する競合の識別
次のビューによってディスパッチャのパフォーマンス統計が提供されます。
■
V$DISPATCHER は、ディスパッチャ・プロセスの一般的な情報を提供します。
■
V$DISPATCHER_RATE は、ディスパッチャ・プロセスの統計を提供します。
V$DISPATCHER_RATE ビューは、いくつかのカテゴリについてディスパッチャ統計の現在、
平均および最大の値を含みます。接頭辞 CUR_ が付いている統計は、現在のサンプルの統計
です。接頭辞 AVG_ が付いている統計は、コレクション期間が開始してからの統計の平均値
です。接頭辞 MAX_ が付いている統計は、統計収集が開始してからのこれらのカテゴリでの
最大値です。
ディスパッチャのパフォーマンスを調べるには、V$DISPATCHER_RATE ビューを問い合せ
て、最大値と現在の値を比較します。現在のシステム・スループットが適切な応答時間を提
供し、このビューの現在の値が平均値に近くかつ最大値を下回る場合、共有サーバー環境は
最適にチューニングされていると考えられます。
現在の値と平均値が最大値を大きく下回る場合は、ディスパッチャ数の削減を検討してくだ
さい。反対に、現在の値と平均値が最大値に近い場合は、ディスパッチャを追加する場合が
あります。システム使用率が低い期間と高い期間の両方で V$DISPATCHER_RATE 統計を調
べてみることを一般規則としてお薦めします。共有サーバーの負荷パターンを識別した後
で、それに従ってパラメータを調整します。
必要であれば、システムのストレス・テストを実行し、定期的に V$DISPATCHER_RATE 統
計をポーリングすることによってワークロードをシミュレートすることもできます。これら
の統計の正しい解釈方法は、プラットフォームごとに異なります。アプリケーションの種類
が変わると、V$DISPATCHER_RATE に記録される統計値も大幅に異なる可能性があります。
関連項目 :
■
■
V$DISPATCHER および V$DISPATCHER_RATE ビューの詳細は、
『Oracle Database リファレンス』を参照してください。
統計を監視する Oracle Tuning Pack アプリケーションの詳細は、
『Oracle Enterprise Manager 概要』を参照してください。
パフォーマンスを考慮したデータベースの構成
4-11
共有サーバーのパフォーマンスの考慮事項
ディスパッチャ・プロセスの競合の低減
競合を低減するには、次の点を考慮してください。
■
ディスパッチャ・プロセスの追加
ディスパッチャ・プロセスの総数は、MAX_DISPATCHERS 初期化パラメータの値で制限
されます。ディスパッチャ・プロセスを追加する前に、この値を増やす必要がある場合
があります。
■
接続プーリングの使用可能化
システム負荷が増加し、ディスパッチャ・スループットが最大限になった場合は、すぐ
にディスパッチャを追加することが必ずしも適切とはかぎりません。そのかわりに、接
続プーリングによってより多くのユーザーをサポートできるようにディスパッチャを構
成することを検討してください。
■
セッション多重化の有効化
多重化は、Connection Manager プロセスで、複数ユーザーから個別のディスパッチャ
へのネットワーク・セッションを確立およびメンテナンスする場合に使用されます。た
とえば、いくつかのユーザー・プロセスが Connection Manager プロセスからの 1 つの
接続を経由して 1 つのディスパッチャに接続できます。ディスパッチャ・プロセスが最
大限に使用されるため、セッションの多重化は有効です。多重化は、ディスパッチャ間
のデータベース・リンク・セッションを多重化する場合にも役立ちます。
関連項目 :
■
■
■
ディスパッチャ・プロセスの構成の詳細は、
『Oracle Database 管理者
ガイド』を参照してください。
接続プーリングの構成の詳細は、
『Oracle Net Services 管理者ガイド』
を参照してください。
DISPATCHERS および MAX_DISPATCHERS パラメータの詳細は、
『Oracle Database リファレンス』を参照してください。
4-12　Oracle Database パフォーマンス・チューニング・ガイド
共有サーバーのパフォーマンスの考慮事項
共有サーバー・プロセスの競合の識別
この項では、共有サーバーの競合を識別する方法を説明します。
要求キューにおいて待機時間が一貫して増加する場合、それは共有サーバーの競合を示しま
す。待機時間のデータを調べるには、動的パフォーマンス・ビュー V$QUEUE を使用します。
このビューには、共有サーバーの要求キューのアクティビティを示す統計が含まれます。デ
フォルトでは、ユーザー SYS および SYSTEM のような、SELECT ANY TABLE システム権限
を持っているユーザーのみがこのビューを利用できます。表 4-3 は、要求の待機時間と
キュー内の要求の数を示す列をリストしたものです。
表 4-3 V$QUEUE 内の待機時間と要求列
列
WAIT
TOTALQ
説明
キューに存在していた全要求についての待機時間の合計
（100 分の 1 秒単位）
キューに存在していた要求の総数
アプリケーションの実行時に次の SQL 文を発行して、この統計を数回監視してください。
SELECT DECODE(TOTALQ, 0, 'No Requests',
WAIT/TOTALQ || ' HUNDREDTHS OF SECONDS') "AVERAGE WAIT TIME PER REQUESTS"
FROM V$QUEUE
WHERE TYPE = 'COMMON';
この問合せは、次のような計算結果を戻します。
AVERAGE WAIT TIME PER REQUEST
----------------------------.090909 HUNDREDTHS OF SECONDS
この結果から、要求は処理される前に要求キューにおいて平均 0.09 待機したことがわかりま
す（単位は 100 分の 1 秒）
。
また、次の問合せを発行することによって、現在実行中の共有サーバーの数が判断できま
す。
SELECT COUNT(*) "Shared Server Processes"
FROM V$SHARED_SERVER
WHERE STATUS != 'QUIT';
この問合せの結果を次に示します。
Shared Server Processes
----------------------10
パフォーマンスを考慮したデータベースの構成
4-13
共有サーバーのパフォーマンスの考慮事項
共有サーバーでのリソース競合を検出した場合は、まず、共有プールとラージ・プールを調
査し、これがメモリー競合でないことを確認します。パフォーマンスが改善されない場合
は、共有サーバー・プロセス競合を低減するためにさらにリソースを作成してください。そ
の場合は、オプションのサーバー・プロセス初期化パラメータを変更します。
■
MAX_DISPATCHERS
■
MAX_SHARED_SERVERS
■
DISPATCHERS
■
SHARED_SERVERS
関連項目 : 共有サーバー・プロセスの初期化パラメータの設定の詳細は、
『Oracle Database 管理者ガイド』を参照してください。
4-14　Oracle Database パフォーマンス・チューニング・ガイド
5
自動パフォーマンス統計
この章では、パフォーマンス統計の収集について説明します。この章には次の項がありま
す。
■
データ収集の概要
■
自動ワークロード・リポジトリ
関連項目 : データベースの監視およびチューニングについては、『Oracle
Database 2 日でデータベース管理者』を参照してください。
自動パフォーマンス統計
5-1
データ収集の概要
データ収集の概要
パフォーマンスの問題を効果的に診断するには、統計が使用可能である必要があります。
Oracle では、システム、セッションおよび個々の SQL 文について様々なタイプの累積的な
統計が収集されます。また、セグメントとサービスに関する累積的な統計も追跡されます。
このような有効範囲内でパフォーマンスの問題を分析する場合、通常は、問題となる期間中
の統計の変化（デルタ値）を調べます。特に、期間開始時における統計の累積値と終了時に
おける累積値の違いを調べます。
統計の累積値は、通常、V$SESSTAT および V$SYSSTAT ビューなどの動的パフォーマンス・
ビューを介して使用できます。動的ビューの累積値は、データベース・インスタンスの停止
時にリセットされることに注意してください。自動ワークロード・リポジトリ（AWR）は、
セッション・レベルを除くすべてのレベルでほとんどの統計の累積値とデルタ値を自動的に
存続させます。この処理は定期的に繰り返され、その結果は AWR スナップショットと呼ば
れます。スナップショットにより取得されるデルタ値は、期間中の各統計の変化を表します。
5-10 ページの「自動ワークロード・リポジトリ」を参照してください。
Oracle では、測定値と呼ばれるタイプの統計も収集されます。測定値は、なんらかの累積統
計における変化の率として定義されます。この率は、時間、トランザクションまたはデータ
ベース・コールなど、様々な単位で測定できます。たとえば、1 秒当りのデータベース・
コール数は測定値です。測定値は一部の V$ ビューに表示されます。この種のビューに表示
される値は、短い時間間隔（通常は 60 秒）での平均値です。最新の測定値の履歴は V$
ビューを介して使用でき、そのデータの一部は AWR スナップショットでも存続されます。
Oracle で収集される第 3 のタイプの統計データは、サンプル・データです。このサンプリン
グは、Active Session History（ASH）サンプラにより実行されます。ASH は、すべてのアク
ティブ・セッションの現在の状態をサンプリングします。このデータはメモリーに収集され、
V$ ビューからアクセスできます。また、AWR スナップショット処理で永続的に格納できる
ように書き出されます。5-4 ページの「Active Session History（ASH）」を参照してくださ
い。
パフォーマンスの問題に関する強力な診断手段は、統計的ベースラインを使用することで
す。統計的ベースラインは、通常はシステムがピーク負荷で正常に動作している期間中に取
得された統計的割合の集合です。パフォーマンスの低下期間中に取得された統計をベースラ
インと比較すると、大幅に値が大きくなっていて問題の原因だと思われる特定の統計を検出
しやすくなります。
AWR では、1 対または特定範囲の AWR スナップショットをベースラインとして指定して保
持可能にすることで、ベースライン・データの取得がサポートされます。ベースラインとし
て選択する期間は慎重に考慮してください。システムのピーク負荷を適切に表すベースライ
ンを選択する必要があります。将来、これらのベースラインをパフォーマンス低下期間中に
取得されたスナップショットと比較できます。
Oracle Enterprise Manager は、動的パフォーマンス・ビューにリアルタイム・データと
AWR 履歴表からの履歴データを表示するための推奨ツールです。また、Enterprise Manager
では、オペレーティング・システムとネットワークの統計データを取得して、AWR データ
との相関付けもできます。
5-2　Oracle Database パフォーマンス・チューニング・ガイド
データ収集の概要
データベース統計
データベース統計には、データベースの負荷のタイプ、およびデータベースで使用される内
部リソースと外部リソースに関する情報が提供されます。この項では、より重要な統計につ
いて説明します。
待機イベント
待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示
すために、サーバー・プロセス / スレッドによって増やされる統計です。待機イベント・
データは、ラッチの競合、バッファの競合、I/O の競合などのパフォーマンスに影響を与え
ると思われる様々な問題の症状を表します。
待機イベントに関する高水準の分析を容易にするために、イベントはクラス別にグループ化
されています。待機イベント・クラスには、Administrative、Application、Cluster、
Commit、Concurrency、Configuration、Idle、Network、Other、Scheduler、System I/O、
および User I/O があります。
待機クラスは、一般に待機イベントで問題を解決するために適用される共通の解決策に基づ
きます。たとえば、排他 TX ロックは通常はアプリケーション・レベルの問題であり、HW
ロックは通常は構成の問題です。
次のリストに、一部のクラスでの一般的な待機例を示します。
■
Application: 行レベル・ロックまたは明示的ロック・コマンドが原因のロック待機。
■
Commit: コミット後の REDO ログ書込み確認の待機。
■
Idle: SQL*Net message from client など、セッションがアクティブでないことを示
す待機イベント。
■
Network: ネットワーク上でのデータ送信の待機。
■
User I/O: ディスクからのブロック読取りの待機。
関連項目 : Oracle 待機イベントの詳細は、『Oracle Database リファレン
ス』を参照してください。
時間モデル統計
Oracle システムをチューニングする場合は、コンポーネントごとに固有の統計セットがあり
ます。システム全体を調べるには、共通の比較尺度が必要です。このため、ほとんどの
Oracle アドバイザおよびレポートでは、統計が時間単位で記述されます。また、V$SESS_
TIME_MODEL および V$SYS_TIME_MODEL ビューには、時間モデル統計が用意されていま
す。共通の時間という尺度で計測すると、データベース操作に対する影響を数量化して識別
できます。
最も重要な時間モデル統計は DB time です。この統計はインスタンスのワークロード合計の
インジケータであり、データベース・コールの合計所要時間を表します。この統計は、アイ
自動パフォーマンス統計
5-3
データ収集の概要
ドル待機イベント（アイドル状態でないユーザー・セッション）で待機していない全セッ
ションの CPU タイムと待機時間を集計することで計算されます。
DB time は、インスタンスの起動時から累積的に測定されます。DB time はアイドル状態で
ない全ユーザー・セッションの時間の合計として計算されるため、インスタンス起動後の実
際の経過時間を超える場合があります。たとえば、30 分実行されているインスタンスに 4 つ
のアクティブ・ユーザー・セッションがあり、その累積 DB time が約 120 分となる場合が
あります。
Oracle システムのチューニングは、データベース上でユーザーが実行する一部のアクション
について所要時間を短縮すること、または単に DB time を短縮することを目的としていま
す。他の時間モデル統計は、ログオン操作、ハード解析およびソフト解析など、特定のアク
ションへの影響を（時間単位で）数量化した情報を提供します。
関連項目 : V$SESS_TIME_MODEL および V$SYS_TIME_MODEL ビューの
詳細は、
『Oracle Database リファレンス』を参照してください。
Active Session History（
（ASH）
）
V$ACTIVE_SESSION_HISTORY ビューには、インスタンス内でサンプリングされたセッ
ション・アクティビティが表示されます。アクティブ・セッションは毎秒サンプリングされ、
SGA の循環バッファに格納されます。データベースに接続中で、Idle 待機クラスに属さない
イベントを待機中のセッションは、アクティブ・セッションとみなされます。これには、サ
ンプリング時に CPU にあったセッションが含まれます。
各セッションのサンプルは一連の行で、V$ACTIVE_SESSION_HISTORY ビューは、サンプ
ルごとに各アクティブ・セッションについて 1 行を、最後のセッション・サンプルの行から
順番に戻します。アクティブ・セッションのサンプルは SGA の循環バッファに格納されるた
め、システム・アクティビティが多いほど、循環バッファにセッション・アクティビティを
格納できる秒数は短くなります。つまり、セッション・サンプルが V$ ビューに表示される
期間、または V$ ビューに表示されるセッション・アクティビティの秒数は、データベー
ス・アクティビティに全面的に依存します。
自動ワークロード・リポジトリ（AWR）スナップショットの一部として、V$ACTIVE_
SESSION_HISTORY の内容もディスクにフラッシュされます。大規模なシステム・アクティ
ビティ中は、この V$ ビューの内容が極端に大きくなる可能性があるため、ディスクには
セッション・サンプルの一部のみが書き込まれます。
アクティブ・セッションのみを取得することで、システム上で許可されるセッション数では
なく、実行される作業に直接関連するサイズで管理可能なデータ・セットが表示されます。
Active Session History を使用すると、V$ACTIVE_SESSION_HISTORY ビューの現行データ
と DBA_HIST_ACTIVE_SESS_HISTORY ビューの履歴データの両方を検査して詳細な分析を
実行でき、通常、ワークロードを再現してパフォーマンス・トレース情報を追加収集する必
要がありません。ASH に表示されるデータは、次のように、取得する各種ディメンションで
ロール・アップできます。
■
SQL 文の SQL 識別子
■
オブジェクト数、ファイル数およびブロック数
5-4　Oracle Database パフォーマンス・チューニング・ガイド
データ収集の概要
■
待機イベント識別子およびパラメータ
■
セッション識別子およびセッション・シリアル番号
■
モジュールおよびアクション名
■
セッションのクライアント識別子
■
サービス・ハッシュ識別子
関連項目 : V$ACTIVE_SESSION_HISTORY ビューの詳細は、
『Oracle
Database リファレンス』を参照してください。
システム統計とセッション統計
V$SYSSTAT および V$SESSTAT ビューを使用すると、システム・レベルとセッション・レ
ベルで多数の累積的データベース統計を使用できます。
関連項目 : V$SYSSTAT および V$SESSTAT ビューの詳細は、
『Oracle
Database リファレンス』を参照してください。
オペレーティング・システム統計
オペレーティング・システム統計は、オペレーティング・システム自体のパフォーマンスの
みでなく、システムの主要ハードウェア・コンポーネントの使用率やパフォーマンスも提供
します。この情報は、CPU サイクルや物理メモリーなどのリソースがすべて使用される可
能性を検出し、ディスク・ドライブなどの周辺機器のパフォーマンスの低下を検出するため
に重要です。
オペレーティング・システム統計は、ハードウェアやオペレーティング・システムの稼働状
態のみを示します。システム・パフォーマンスの分析担当者の多くは、ハードウェア・リ
ソースの不足に対してハードウェアを増設することで対応します。これは、オペレーティン
グ・システム統計に示される一連の症状に対する対処療法です。医師が診断を下すときに患
者の体温、脈拍および身体的痛みを参考にするのと同じように、オペレーティング・システ
ム統計は診断ツールとみなすのが最適です。ボトルネックを識別するには、パフォーマンス
分析の対象となっているシステム内の全サーバーのオペレーティング・システム統計を収集
します。
オペレーティング・システム統計には次のものが含まれます。
■
CPU 統計
■
仮想メモリー統計
■
ディスク統計
■
ネットワーク統計
オペレーティング・システム統計の収集ツールについては、5-7 ページの「オペレーティン
グ・システムのデータ収集ツール」を参照してください。
自動パフォーマンス統計
5-5
データ収集の概要
CPU 統計
CPU 使用率は、チューニング・プロセスで最も重要なオペレーティング・システム統計で
す。システム全体の CPU 使用率と、マルチプロセッサ環境での各 CPU の使用率を取得しま
す。各 CPU の使用率から、シングル・スレッドおよび拡張性の問題を検出できます。
ほとんどのオペレーティング・システムでは、CPU 使用率を、ユーザー領域またはユー
ザー・モードでの経過時間と、カーネル領域またはカーネル・モードでの経過時間でレポー
トします。この追加統計情報を使用すると、CPU 上で実際に何が実行されているかをより
詳細に分析できます。
Oracle データ・サーバー・システムでは、通常はアプリケーションが 1 つのみ実行され、
サーバーはユーザー領域でデータベース・アクティビティを実行します。データベース要求
に対するサービスの提供に必要なアクティビティ（スケジューリング、同期、I/O、メモ
リー管理、プロセス / スレッドの作成と破棄など）は、カーネル・モードで実行されます。
すべての CPU がフルに活用されているシステムでは、健全な Oracle システムの場合、その
65% から 95% がユーザー領域で実行されます。
V$OSSTAT ビューではデータベース内のマシン・レベルの情報が収集され、ハードウェア・
レベルのリソースに問題があるかどうかを容易に判断できます。V$SYS_TIME_MODEL には、
Oracle データベースによる CPU 使用率の統計が表示されます。両方の統計セットを使用す
ると、Oracle データベースや他のシステムのアクティビティが CPU の問題の原因となって
いるかどうかを判断できます。
仮想メモリー統計
仮想メモリー統計は、主として、システム上でページングまたはスワッピングのアクティビ
ティがほとんど発生していないことを検証するために使用します。ページングまたはスワッ
ピングが発生すると、システム・パフォーマンスは急速かつ予想外に低下します。
個々のプロセスのメモリー統計を使用すると、プログラミングの失敗でプロセス・ヒープか
ら取得したメモリーを割当て解除できなかったことによるメモリー・リークを検出できま
す。この統計を使用すると、システムが起動後に安定状態に達した後、メモリー使用量が増
加していないことを確認できます。このメモリー使用量増加の問題は、中間層マシンの共有
サーバー・アプリケーションで、セッション状態が複数のユーザーの対話にまたがって存続
するために、メモリーの割当てが完全に解除されないという完了時状態情報がある場合は、
特に深刻です。
ディスク統計
データベースは一連のディスク上に常駐しているため、データベースのパフォーマンスに
とっては I/O サブシステムのパフォーマンスが非常に重要になります。ほとんどのオペレー
ティング・システムでは、ディスク・パフォーマンスに関する詳細な統計が提供されます。
最も重要なディスク統計は、現在の応答時間とディスク・キューの長さです。この統計は、
ディスクが最適な状態で実行されているか、または過度の使用状態にあるかを示します。
I/O システムの通常のパフォーマンスを測定します。1 ブロックの読取りに関する標準値は、
使用中のハードウェアに応じて 5 ～ 20 ミリ秒です。ハードウェアが通常のパフォーマンス値
5-6　Oracle Database パフォーマンス・チューニング・ガイド
データ収集の概要
を大幅に上回る応答時間を示している場合は、不適切な状態で実行されているか過度の使用
状態にあります。これがボトルネックです。ディスク・キューが 2 つを超えると、そのディ
スクがシステムのボトルネックになる可能性があります。
ネットワーク統計
ネットワーク統計はディスク統計とほぼ同じように使用でき、ネットワークまたはネット
ワーク・インタフェースが過負荷になっているかどうか、または最適に実行されているかど
うかを判断できます。今日のネットワーク・アプリケーションでは、ネットワーク待機時間
が実際のユーザー応答時間の大部分を占めることがあります。このため、この統計は重要な
デバッグ・ツールです。11-6 ページの「動的パフォーマンス・ビューを使用したネットワー
クのパフォーマンスの向上」を参照してください。
オペレーティング・システムのデータ収集ツール
表 5-1 は、UNIX でのオペレーティング・システム統計収集ツールを示します。Windows
NT/2000 の場合は、パフォーマンス・モニタ・ツールを使用します。
表 5-1 オペレーティング・システム統計収集用の UNIX ツール
コンポーネント UNIX ツール
CPU
sar、vmstat、mpstat、iostat
メモリー
sar、vmstat
ディスク
sar、iostat
ネットワーク
netstat
統計の解釈
最初にパフォーマンス・データを調査するときは、統計を調べることによって潜在的な理論
を構築できます。統計の解釈が正しいかどうかを確認する 1 つの方法は、他のデータとのク
ロスチェックを行うことです。これにより、統計またはイベントが実際に対象のものである
かどうかがわかります。
ここではいくつかの陥りやすい誤りについて説明します。
■
ヒット率
チューニングを行う場合は、問題があるかどうかを容易に判断するために、比率を計算
することが一般的です。そのような率には、バッファ・キャッシュ・ヒット率、ソフト
解析率およびラッチ・ヒット率があります。これらの率を、パフォーマンス・ボトル
ネックがあるかどうかを厳密に判断する識別子として使用しないでください。むしろ、
インジケータとして使用してください。ボトルネックがあるかどうかを識別するには、
他の関連する証拠を調べる必要があります。7-11 ページの「バッファ・キャッシュ・
ヒット率の計算」を参照してください。
自動パフォーマンス統計
5-7
データ収集の概要
■
時間統計のある待機イベント
インスタンス・レベルで TIMED_STATISTICS を TRUE に設定すると、Oracle サー
バーはすでに使用できる待機カウントの他にイベントの待機時間を収集します。この
データは、イベントの合計待機時間をパフォーマンス・データ収集間の総経過時間と比
較する場合に役立ちます。たとえば、待機イベントが 2 時間の期間のうちのわずか 30
秒であれば、このイベントが待機時間別に順序付けされるときに最高ランクの待機イベ
ントであっても、このイベントを調べて得られるものはほとんどありません。ただし、
イベントが 45 分間のうちの 30 分であれば、そのイベントは調べる価値があります。
10-21 ページの「待機イベント統計」を参照してください。
注意 : 初期化パラメータ STATISTICS_LEVEL が TYPICAL または ALL
に設定されている場合、データベースの時間統計が自動的に収集されま
す。STATISTICS_LEVEL を BASIC に設定した場合に時間統計の収集を有
効化するには、TIMED_STATISTICS を TRUE に設定する必要があります。
STATISTICS_LEVEL を BASIC に設定すると、多数の自動機能が無効にな
ることに注意してください。この設定はお薦めしません。
DB_CACHE_ADVICE、TIMED_STATISTICS または TIMED_OS_
STATISTICS を明示的に初期化パラメータ・ファイルに、または ALTER_
SYSTEM や ALTER SESSION を使用して設定した場合、その値は
STATISTICS_LEVEL から導出された値を上書きします。
■
Oracle 統計とその他の要因の比較
統計を調べる場合、統計に価値があるかどうかに影響を与える他の要因を考慮すること
が重要です。そのような要因には、ユーザー負荷やハードウェア能力があります。待機
時間が 45 分間のスナップショットのうちの 30 分間であったイベントでも、システム上
に 2000 人のユーザーがいて、ホスト・ハードウェアが 64 ノード・マシンであった場合
は問題とはみなされないことがあります。
■
時間統計のない待機イベント
TIMED_STATISTICS が正しくない場合、イベントの待機時間は使用できません。した
がって、各イベントを待機した時間数で待機イベントを順序付けることのみ可能です。
最大待機回数を持つイベントが潜在的なボトルネックを示すことがありますが、主要な
ボトルネックとは言えません。これはイベントを長時間待つ場合に発生する可能性があ
りますが、そのイベントを待つ合計待機時間は短時間です。その逆も成り立ちます。待
機回数が少ないイベントは、その待機時間が合計待機時間の大きな割合を占めている場
合に問題になることがあります。比較のために使用する待機時間がなければ、待機イベ
ントが実際に重要かどうかの判断は困難です。
5-8　Oracle Database パフォーマンス・チューニング・ガイド
データ収集の概要
■
アイドル待機イベント
Oracle では、いくつかの待機イベントを使用して、Oracle サーバー・プロセスがアイド
ル状態であるかどうかを示します。一般に、これらのイベントはパフォーマンスの問題
を調べるときは有効でなく、待機イベントを調べるときは無視する必要があります。
10-47 ページの「アイドル待機イベント」を参照してください。
■
計算済統計
計算済統計（割合、トランザクションごとに正規化された統計、比率など）を解釈する
場合は、計算済統計を実際の統計カウントと相互検査することが重要です。その検査
で、導出レートが実際に重要かどうかが確認されます。通常、小さな統計カウントによ
り、異常な比率を除外できます。たとえば、最初の検査で、ソフト解析率 50% は、一
般に潜在的なチューニング領域を示します。ただし、データ収集期間にハード解析が 1
つとソフト解析が 1 つのみあった場合、この領域が重要な領域でないことを統計カウン
トが示していても、ソフト解析率は 50% になります。この場合、統計カウントが低い
ため、比率は重要ではありません。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-7 ページの「統計収集のレ
ベルの設定」を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
自動パフォーマンス統計
5-9
自動ワークロード・リポジトリ
自動ワークロード・リポジトリ
自動ワークロード・リポジトリ（AWR）では、問題の検出および自己チューニングを目的
として、パフォーマンス統計が収集、処理および保守されます。このデータはメモリーと
データベースの両方に格納されます。収集されたデータは、レポートとビューの両方に表示
できます。5-15 ページの「Workload Repository のビュー」および 5-16 ページの「Workload
Repository レポート」を参照してください。
AWR により収集され処理される統計は、次のとおりです。
■
■
■
■
■
データベース・セグメントのアクセス統計と使用統計を決定するオブジェクト統計。
アクティビティの時間使用に基づく時間モデル統計。V$SYS_TIME_MODEL および
V$SESS_TIME_MODEL ビューに表示されます。
V$SYSSTAT および V$SESSTAT ビューで収集されるシステム統計とセッション統計の一
部。
システム上で最大負荷を生成している SQL 文。経過時間や CPU タイムなどの基準に基
づきます。
最新のセッション・アクティビティの履歴を表す Active Session History（ASH）統計。
AWR では、1 時間ごとにパフォーマンス・データのスナップショットが自動的に生成され、
Workload Repository に統計が収集されます。スナップショットを手動で作成することもで
きますが、通常は必要ありません。スナップショット間隔内のデータは、Automatic
Database Diagnostic Monitor（ADDM）によって分析されます。6-3 ページの「Automatic
Database Diagnostic Monitor」を参照してください。
AWR は、スナップショット間の違いを比較し、システム負荷への影響に基づいて収集する
SQL 文を判別します。これにより、期間中に収集する必要のある SQL 文の数が減少します。
自動ワークロード・リポジトリによる使用領域は、次のように複数の要因によって決定され
ます。
■
特定の時点におけるシステム内のアクティブ・セッション数
■
スナップショット間隔
スナップショット間隔により、スナップショットの収集頻度が決定されます。スナップ
ショット間隔が短いほど頻度が高くなり、自動ワークロード・リポジトリにより収集さ
れるデータ量が増大します。
■
履歴データの保存期間
保存期間により、このデータが消去前に保持されている期間が決定されます。保存期間
が長いほど、自動ワークロード・リポジトリによる領域使用量が増大します。
デフォルトでは、スナップショットは 1 時間ごとに収集され、データベースに 7 日間保存さ
れます。これらのデフォルト設定では、同時アクティブ・セッション数が平均 10 の標準的な
システムの場合、AWR データ用に約 200 ～ 300 MB の領域が必要になる可能性があります。
スナップショット間隔と保存期間のデフォルト値は、どちらも変更できます。AWR 設定の
5-10　Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリ
変更については、5-12 ページの「Oracle Enterprise Manager を使用した自動ワークロード・
リポジトリへのアクセス」および 5-14 ページの「スナップショット設定の変更」を参照して
ください。
スナップショット間隔を長くして保存期間を短縮すると、自動ワークロード・リポジトリの
領域使用量を減らすことができます。保存期間を短縮する場合は、Oracle の複数の自己管理
機能が AWR データの正常な機能に依存することに注意してください。十分なデータがない
と、次のようなコンポーネントと機能の妥当性および正確さに影響する可能性があります。
■
Automatic Database Diagnostic Monitor
■
SQL Tuning Advisor
■
UNDO アドバイザ
■
セグメント・アドバイザ
可能な場合は、少なくとも 1 つのワークロード・サイクル全体で収集できるように、AWR
保存期間を十分な長さに設定することをお薦めします。システムのワークロード・サイクル
が平日に OLTP ワークロード、週末にバッチ・ジョブというような週単位になっている場
合、デフォルトの AWR 保存期間である 7 日を変更する必要はありません。ただし、月末の
帳簿締め処理時にシステムの月次ピーク負荷が発生する場合は、保存期間を 1 か月に設定す
る操作が必要になることがあります。
例外的な状況では、スナップショット間隔を 0（ゼロ）に設定して、自動スナップショット
収集を完全にオフにすることができます。この場合、ワークロードおよび統計データの自動
収集は停止され、Oracle の自己管理機能の大部分が動作しなくなります。また、スナップ
ショットも手動で作成できなくなります。このため、自動スナップショット収集はオフにし
ないことをお薦めします。
自動ワークロード・リポジトリからベースラインを作成し、一般的なパフォーマンス期間を
収集することが重要です。ベースラインは、一定範囲のスナップショットにより指定され、
パフォーマンス上の問題が発生したときに他の類似するワークロード期間と比較するために
保持されます。
自動ワークロード・リポジトリを使用可能にするには、STATISTICS_LEVEL 初期化パラ
メータを TYPICAL または ALL に設定する必要があります。この値を BASIC に設定すると、
DBMS_WORKLOAD_REPOSITORY パッケージのプロシージャを使用して AWR を手動で収集
できます。ただし、STATISTICS_LEVEL パラメータを BASIC に設定すると、セグメント統
計やメモリー・アドバイザ情報など、多数のシステム統計のメモリー内収集機能がオフにな
るため、手動で収集したスナップショットにはこれらの統計が含まれず、不完全なものにな
ります。
関連項目 : STATISTICS_LEVEL 初期化パラメータの詳細は、『Oracle
Database リファレンス』を参照してください。
自動パフォーマンス統計
5-11
自動ワークロード・リポジトリ
AWR により収集されるデータに加えて、「Maintenance」ウィンドウのスケジュール済ジョ
ブとして、DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC プロシージャにより自動
オプティマイザ統計収集が実行されます。15-3 ページの「自動統計収集」を参照してくださ
い。
Oracle Enterprise Manager を使用した自動ワークロード・リポジトリへの
アクセス
Oracle Enterprise Manager Database Control から自動ワークロード・リポジトリにアクセス
する手順は、次のとおりです。
■
「Administration」
」ページで、
「Workload」
」の下の「
「Workload Repository」
」リンクを選
択します。「Automatic Workload Repository」
」ページから、スナップショットを管理、
または AWR の設定を変更できます。
■
■
スナップショットを管理するには、「Snapshots」
」または「
「Preserved Snapshot
Sets」
」の横のリンクをクリックします。「Snapshots」
」または「
「Preserved
Snapshot Sets」
」ページで、次の操作ができます。
*
スナップショットまたは保存済スナップショット・セット（ベースライン）情
報を表示します。
*
「Actions」
」プルダウン・メニューを使用して様々なタスクを実行します。たと
えば、既存のスナップショット範囲から追加のスナップショット、保存済ス
ナップショット・セットを作成したり、ADDM タスクを実行して特定範囲の
スナップショットまたは保存済スナップショット・セットの分析を実行しま
す。
AWR の設定を変更するには、「Edit」
」ボタンをクリックします。「Edit Settings」
」
ページで、
「Snapshot Retention」
」期間と「
「Snapshot Collection」
」間隔を設定でき
ます。
関連項目 : Oracle Enterprise Manager で使用可能な監視および診断ツー
ルの詳細は、
『Oracle Enterprise Manager 概要』および Oracle Enterprise
Manager オンライン・ヘルプを参照してください。
5-12　Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリ
API によるスナップショットおよびベースライン・データの管理
自動ワークロード・リポジトリ管理用の主インタフェースは Oracle Enterprise Manager
Database Control ですが、監視機能は DBMS_WORKLOAD_REPOSITORY パッケージのプロ
シージャで管理できます。
Oracle データベースのスナップショットは自動生成されます。ただし、DBMS_WORKLOAD_
REPOSITORY プロシージャを使用して、Automatic Database Diagnostic Monitor で使用さ
れるスナップショットおよびベースラインを手動で作成、削除および変更できます。スナッ
プショットおよびベースラインは、パフォーマンスの比較に使用される、特定の期間の履歴
データのセットです。
これらのプロシージャを起動するには、DBA ロールが付与されている必要があります。
関連項目 : DBMS_WORKLOAD_REPOSITORY パッケージの詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参
照してください。
スナップショットの作成
自動生成されたスナップショットとは異なる時点の統計を収集する場合は、CREATE_
SNAPSHOT プロシージャにより、手動でスナップショットを作成できます。たとえば、次の
ようにします。
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
この例では、インスタンスのスナップショットがただちに作成され、フラッシュ・レベル
は、デフォルトのフラッシュ・レベルである TYPICAL に指定されます。このスナップ
ショットは、DBA_HIST_SNAPSHOT ビューに表示できます。
スナップショットの削除
DROP_SNAPSHOT_RANGE プロシージャを使用して、一定範囲のスナップショットを削除で
きます。スナップショット ID とデータベース ID のリストを表示するには、DBA_HIST_
SNAPSHOT ビューを確認します。たとえば、次の範囲のスナップショットを削除できます。
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 22,
high_snap_id => 32, dbid => 3310949047);
END;
/
この例では、削除するスナップショット ID の範囲は 22 ～ 32 に指定されています。オプ
ションのデータベース識別子は 3310949047 です。dbid の値を指定しない場合は、デフォ
ルト値としてローカル・データベース識別子が使用されます。
自動パフォーマンス統計
5-13
自動ワークロード・リポジトリ
DROP_SNAPSHOT_RANGE プロシージャがコールされると、スナップショット範囲で指定さ
れた期間に属する Active Session History データ（ASH）もパージされます。
スナップショット設定の変更
指定したデータベース ID について、スナップショット生成の間隔および保存を調整できま
すが、こうすると Oracle 診断ツールの精度に影響する可能性があるので注意してください。
INTERVAL の設定は、スナップショットの自動生成の頻度（分単位）に影響します。
RETENTION の設定は、スナップショットが Workload Repository に格納される時間の長さ
（分単位）に影響します。この設定を調整するには、MODIFY_SNAPSHOT_SETTINGS プロ
シージャを使用します。たとえば、次のようにします。
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
interval => 30, dbid => 3310949047);
END;
/
この例では、保存期間は 43200 分（30 日）に指定され、各スナップショットの間隔は 30 分
に指定されています。NULL が指定された場合、既存の値は保存されます。オプションの
データベース識別子は 3310949047 です。dbid の値を指定しない場合は、デフォルト値と
してローカル・データベース識別子が使用されます。DBA_HIST_WR_CONTROL ビューを使
用すると、データベース・インスタンスの現在の設定を確認できます。
ベースラインの作成と削除
ベースラインは、CREATE_BASELINE プロシージャで作成されます。ベースラインは、一連
のスナップショットの単なるパフォーマンス・データであり、パフォーマンス上の問題が発
生したときに、類似する他のワークロード期間と比較するために保持されて使用されます。
DBA_HIST_SNAPSHOT ビューで既存のスナップショットを検討し、使用するスナップ
ショットの範囲を決定できます。たとえば、次のようにします。
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 270,
end_snap_id => 280, baseline_name => 'peak baseline',
dbid => 3310949047);
END;
/
この例では、270 は開始スナップショットの順序番号であり、280 は終了スナップショット
の順序です。peak baseline はベースラインの名前であり、3310949047 はオプションの
データベース識別子です。dbid の値を指定しない場合は、デフォルト値としてローカル・
データベース識別子が使用されます。
ベースラインが作成されると、一意のベースライン ID が新規ベースラインに自動的に割り
当てられます。ベースライン ID とデータベース識別子は、DBA_HIST_BASELINE ビューに
表示されます。
5-14　Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリ
ベースラインに関連付けられたスナップショットのペアは、ベースラインを明示的に削除す
るまで保持されます。DROP_BASELINE プロシージャによりベースラインを削除できます。
たとえば、次のようにします。
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'peak baseline',
cascade => FALSE, dbid => 3310949047);
END;
/
この例では、peak baseline はベースラインの名前であり、FALSE はベースラインのみが
削除されることを指定しています。TRUE は、削除操作によって、ベースラインに関連付け
られたスナップショットのペアとベースラインが削除されることを指定しています。
3310949047 は、オプションのデータベース識別子です。
Workload Repository のビュー
通常、AWR データは Oracle Enterprise Manager 画面または AWR レポートで表示します。
ただし、次のビューで統計を表示できます。
■
V$ACTIVE_SESSION_HISTORY
このビューには、1 秒ごとにサンプリングされたアクティブなデータベース・セッショ
ンのアクティビティが表示されます。5-4 ページの「Active Session History（ASH）」を
参照してください。
■
V$ 測定値ビューでは、システムのパフォーマンスを追跡するための測定値データが示
されます。
測定値ビューは、イベント、イベント・クラス、システム、セッション、サービス、
ファイルおよび表領域の測定値など、様々なグループに編成されています。これらのグ
ループは、V$METRICGROUP ビューで識別されます。
■
DBA_HIST ビュー
DBA_HIST ビューには、データベースに格納されている履歴データが含まれます。この
グループのビューには次のようなものがあります。
■
■
■
■
DBA_HIST_ACTIVE_SESS_HISTORY には、最新のシステム・アクティビティに関
するメモリー内 Active Session History の内容の履歴が表示されます。
DBA_HIST_BASELINE には、システム上に収集されたベースラインに関する情報が
表示されます。
DBA_HIST_DATABASE_INSTANCE には、データベース環境に関する情報が表示さ
れます。
DBA_HIST_SNAPSHOT には、システム内のスナップショットの情報が表示されま
す。
自動パフォーマンス統計
5-15
自動ワークロード・リポジトリ
■
DBA_HIST_SQL_PLAN には、SQL 実行計画が表示されます。
■
DBA_HIST_WR_CONTROL には、AWR 制御用の設定が表示されます。
関連項目 : 動的および静的なデータ・ディクショナリ・ビューの詳細は、
『Oracle Database リファレンス』を参照してください。
Workload Repository レポート
Oracle Enterprise Manager を使用するか次の SQL スクリプトを実行して、AWR レポートを
表示できます。
■
■
awrrpt.sql SQL スクリプトでは、一定範囲のスナップショット ID の統計を表示する、
HTML またはテキストのレポートが生成されます。
awrrpti.sql SQL スクリプトでは、指定されたデータベースおよびインスタンスの一
定範囲のスナップショット ID の統計を表示する、HTML またはテキストのレポートが
生成されます。
AWR レポートを実行するには、DBA ロールが付与されている必要があります。
レポートは複数のセクションにわかれています。HTML レポートには、セクション間ですば
やくナビゲートできるようにリンクが組み込まれています。レポートの内容には、選択した
範囲のスナップショットに関するシステムのワークロード・プロファイルが含まれます。
注意 : 指定した範囲のスナップショットにワークロード・アクティビ
ティのないデータベースに対してレポートを実行すると、一部のレポート
統計について 0 より小さいか 100 を超えるパーセンテージが計算される場
合があります。この結果は、単にその統計に意味のある値がないことを意
味します。
awrrpt.sql レポートの実行
一定範囲のスナップショット ID のテキスト・レポートを生成するには、SQL プロンプトか
ら awrrpt.sql スクリプトを実行します。
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定する必要があ
ります。
Enter value for report_type: text
スナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days: 2
5-16　Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリ
リストが表示されると、ワークロード・リポジトリ・レポートの開始スナップショット ID
と終了スナップショット ID の入力が要求されます。
Enter value for begin_snap: 150
Enter value for end_snap: 160
次に、デフォルトのレポート名を確定するか、またはレポート名を入力します。次の例では
デフォルト名が確定されています。
Enter value for report_name:
Using the report name awrrpt_1_150_160
ワークロード・リポジトリ・レポートが生成されます。
awrrpti.sql レポートの実行
スナップショット ID の範囲を入力する前にデータベースおよびインスタンスを指定する場
合は、SQL プロンプトで awrrpti.sql スクリプトを実行して、テキスト・レポートを生成
します。
@$ORACLE_HOME/rdbms/admin/awrrpti.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定します。その
後、データベース ID およびインスタンス番号のリストが表示され、次のようになります。
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id
Inst Num DB Name
Instance
----------- -------- ------------ -----------3309173529
1 MAIN
main
3309173529
1 TINT251
tint251
Host
-----------dlsun1690
stint251
プロンプトに、データベース識別子（dbid）およびインスタンス番号（inst_num）の値を
入力します。
Enter value for dbid: 3309173529
Using 3309173529 for database Id
Enter value for inst_num: 1
次に、awrrpt.sql スクリプトと同様に日数とスナップショット ID の入力が要求され、入
力するとテキスト・レポートが生成されます。5-16 ページの「awrrpt.sql レポートの実行」
を参照してください。
自動パフォーマンス統計
5-17
自動ワークロード・リポジトリ
5-18　Oracle Database パフォーマンス・チューニング・ガイド
6
自動パフォーマンス診断
この章では、Oracle の自動パフォーマンス診断およびチューニング機能について説明しま
す。
この章には次の項があります。
■
Automatic Database Diagnostic Monitor の概要
■
Automatic Database Diagnostic Monitor
関連項目 : Automatic Database Diagnostic Monitor を使用するための
Oracle Enterprise Manager インタフェースなど、データベースの監視、診
断およびチューニングの詳細は、
『Oracle Database 2 日でデータベース管
理者』を参照してください。
自動パフォーマンス診断
6-1
Automatic Database Diagnostic Monitor の概要
Automatic Database Diagnostic Monitor の概要
システムに問題が発生した場合、システムに変更を加える前に問題を正確かつ適時に診断す
ることが重要です。通常、データベース管理者（DBA）は単に症状を調べ、問題を修復する
ために即時にシステムの変更を開始します。ただし、長い間の経験から、実際の問題を最初
に正確に診断すると、その解決に成功する可能性が大幅に高まることが判明しています。
Oracle システムの場合、問題の正確な診断に必要な統計データは自動ワークロード・リポジ
トリ（AWR）に保存されます。Automatic Database Diagnostic Monitor（ADDM）では
AWR データが定期的に分析され、パフォーマンス問題の根本的な原因を突き止め、その解
決に関する推奨事項が提供されて、システムのうち正常な領域が識別されます。AWR はパ
フォーマンスに関する履歴データのリポジトリであるため、ADDM を使用してイベント発
生後にパフォーマンスの問題を分析できます。これにより、問題の再現に必要な時間とリ
ソースの節約になります。5-10 ページの「自動ワークロード・リポジトリ」を参照してくだ
さい。
ADDM 分析は AWR スナップショットが作成されるたびに実行され、結果がデータベース
に保存されます。分析結果を表示するには、Oracle Enterprise Manager を使用する方法と、
SQL*Plus セッションでレポートを表示する方法があります。
多くの場合、データベース管理者はパフォーマンスの問題に関して通知を受け取った時点
で、まず ADDM 出力を調べる必要があります。ADDM には次の利点があります。
■
デフォルトで 1 時間ごとの自動パフォーマンス診断レポート
■
数十人のチューニング専門家に基づく問題の診断
■
問題の影響と推奨事項による利点の時間ベースの数量化
■
症状ではなく根本的な原因の特定
■
問題の根本的な原因の処理に関する推奨事項
■
システムのうち正常な領域の特定
■
診断処理中のシステムに対する最小限のオーバーヘッド
チューニングは反復的なプロセスであり、ある問題を修復したことが原因でシステムの他の
部分へのシフトにボトルネックが発生する可能性があることを認識することが重要です。
ADDM 分析による利点があるとしても、システム・パフォーマンスが許容レベルに達する
までには複数のチューニング・サイクルを必要とする場合があります。ADDM による利点は
本番システムに適用されるのみでなく、開発およびテスト・システムでもパフォーマンスの
問題を早期に警告できます。
6-2　Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
Automatic Database Diagnostic Monitor
Automatic Database Diagnostic Monitor（ADDM）は、全体的なチューニング・ソリュー
ションを提供します。ADDM 分析は、特定のインスタンス上で作成された 1 対の AWR ス
ナップショットで定義される期間に対して実行できます。分析はトップ・ダウン方式で実行
され、最初に症状が識別されてから、パフォーマンスの問題の根本的な原因に到達するまで
詳細化されます。
分析の目標は、DB time と呼ばれる 1 つのスループット測定値を減少させることです。DB
time は、データベース・サーバーでユーザー要求の処理にかかった累積時間です。これに
は、アイドル状態でないユーザー・セッションすべての待機時間と CPU タイムが含まれま
す。DB time は、V$SESS_TIME_MODEL および V$SYS_TIME_MODEL ビューに表示されま
す。
関連項目 :
■
■
■
V$SESS_TIME_MODEL および V$SYS_TIME_MODEL ビューの詳細は、
『Oracle Database リファレンス』を参照してください。
時間モデル統計および DB time については、5-3 ページの「時間モデ
ル統計」を参照してください。
サーバー・プロセスについては、
『Oracle Database 概要』を参照して
ください。
個々のユーザー応答時間のチューニングは ADDM の対象でないことに注意してください。
個々のユーザー応答時間のチューニングには、トレース・テクニックを使用します。20-2
ページの「End to End Application Tracing」を参照してください。
DB time の短縮により、データベース・サーバーで同じリソースを使用してサポートできる
ユーザー要求の数が増加し、スループットが改善されます。ADDM によりレポートされる問
題は、それに関係する DB time の量でソートされます。DB time の大部分に関係しないシス
テム領域は、正常領域としてレポートされます。
ADDM では、次のようなタイプの問題が考慮されます。
■
■
CPU のボトルネック : システム CPU が Oracle または他のアプリケーションによりバイ
ンドされているかどうか。
過小なメモリー構造 : SGA、PGA、バッファ・キャッシュなど、Oracle メモリー構造が
十分なサイズに設定されているかどうか。
■
I/O 能力の問題 : I/O サブシステムが予想どおりに動作しているかどうか。
■
高負荷の SQL 文 : システム・リソースを過剰に使用している SQL 文があるかどうか。
■
高負荷の PL/SQL 実行およびコンパイルと、高負荷の Java 使用率。
■
RAC 固有の問題 : グローバル・キャッシュのホット・ブロックとオブジェクトはどう
なっているか。相互接続遅延の問題があるかどうか。
自動パフォーマンス診断
6-3
Automatic Database Diagnostic Monitor
■
■
アプリケーションによる Oracle の不適切な使用 : 不適切な接続管理、過剰な解析または
アプリケーション・レベルのロック競合による問題があるかどうか。
データベース構成の問題 : 不適切なログ・ファイル・サイズの設定、アーカイブの問題、
過剰なチェックポイントまたは不適切なパラメータ設定を示す兆候があるかどうか。
■
同時実行性の問題 : バッファ・ビジーの問題があるかどうか。
■
様々な問題領域のホット・オブジェクトおよび上位 SQL。
ADDM では、システムの正常領域も文書化されます。たとえば、システムのパフォーマンス
にほとんど影響しない待機イベント・クラスが識別され、早期段階でチューニング考慮事項
から削除されます。これにより、システム全体のパフォーマンスに影響しない項目に対する
時間および労力の節約になります。
ADDM では、問題の診断に加えて可能な解決策も推奨されます。該当する場合は複数の解決
策が推奨され、データベース管理者はその中から選択できます。ADDM では、推奨事項の生
成中にシステムに対する様々な変更が考慮されます。次のような推奨事項があります。
■
ハードウェア変更 : CPU の追加または I/O サブシステム構成の変更
■
データベース構成 : 初期化パラメータ設定の変更
■
■
■
スキーマ変更 : 表または索引のハッシュ・パーティション化、あるいは自動セグメント
領域管理（ASSM）の使用
アプリケーション変更 : 順序付けのためのキャッシュ・オプションの使用またはバイン
ド変数の使用
その他のアドバイザの使用 : 高負荷 SQL に対する SQL Tuning Advisor の実行、または
ホット・オブジェクトに対するセグメント・アドバイザの実行
ADDM の分析結果
ADDM の分析結果は、一連の検出結果として表示されます。ADDM の分析結果の例は、6-5
ページの例 6-1 を参照してください。ADDM の検出結果は、それぞれ次の 3 つのタイプのい
ずれかに属します。
■
問題 : データベース・パフォーマンスの問題の根本的な原因を記述する検出結果
■
症状 : 1 つ以上の問題を検出するための情報を含む検出結果
■
情報 : システムの正常領域のレポートに使用される検出結果
問題の検出結果はそれぞれ、その検出結果のパフォーマンスの問題に起因する影響を DB
time に占める割合の見積りとして数量化したものです。問題の検出結果を推奨事項のリス
トに関連付けて、パフォーマンスの問題による影響を軽減できます。各推奨事項にはそれぞ
れメリットがあります。このメリットは、その推奨事項を実装した場合に節約できる DB
time の割合を見積ったものです。推奨事項のリストには、同じ問題に関する様々な代替解
決策が含まれる場合があります。特定の問題を解決するために推奨事項をすべて適用する必
要はありません。
6-4　Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
推奨事項は、アクションおよび理論的根拠で構成されます。見積もられたメリットを得るた
めには、推奨事項のアクションをすべて適用する必要があります。理論的根拠は、一連のア
クションの推奨理由を説明し、提案された推奨事項の実装に関する追加情報を提供するため
に使用されます。
ADDM の例
例 6-1 に示す ADDM レポートの次のセクションを検討します。
例 6-1 ADDM レポートの例
FINDING 1: 31% impact (7798 seconds)
-----------------------------------SQL statements were not shared due to the usage of literals. This resulted in
additional hard parses which were consuming significant database time.
RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)
ACTION: Investigate application logic for possible use of bind variables
instead of literals. Alternatively, you may set the parameter
"cursor_sharing" to "force".
RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033 were found to be
using literals. Look in V$SQL for examples of such SQL statements.
この例で、検出結果は特定の根本的な原因を示しています。SQL 文のリテラルの使用は、分
析期間中の DB time 合計の約 31% に影響があると見積もられています。
この検出結果には、アクション 1 つおよび理論的根拠 1 つで構成される推奨事項が関連付け
られています。アクションでは検出された問題の解決策が指定され、その最大メリットは分
析期間中の DB time の 31% 以内と見積もられます。メリットは、検出結果の影響に占める
割合ではなく、DB time 合計に占める割合として表示されることに注意してください。理論
的根拠は、リテラルを使用していてこのパフォーマンスの問題を引き起こした可能性のある
SQL 文を追跡するための追加情報を提供します。データベース管理者は、問題の原因と思わ
れる SQL 文について指定の計画ハッシュ値を使用すると、少数のサンプル文をすばやく検
査できます。
特定の問題に複数の原因がある場合は、ADDM により複数の問題と症状の検出結果がレ
ポートされることがあります。この場合、複数の検出結果による影響には、DB time が同じ
割合で含まれる可能性があります。検出結果のパフォーマンスの問題はオーバーラップして
いる場合があるため、レポートされた検出結果の影響を合算すると、DB time の 100% を超
える場合があります。たとえば、システムで多数の読取り I/O が実行される場合、ADDM
では、I/O アクティビティによる DB time の 50% に関係する SQL 文が 1 つの検出結果とし
てレポートされ、DB time の 75% に関係する小さいサイズのバッファ・キャッシュが別の
検出結果としてレポートされる場合があります。
問題の検出結果に複数の推奨事項が関連付けられている場合は、それぞれに問題の代替解決
策が含まれていることがあります。この場合、推奨事項によるメリットの合計は検出結果の
影響よりも大きいことがあります。
自動パフォーマンス診断
6-5
Automatic Database Diagnostic Monitor
該当する場合は、ADDM アクションで複数の解決策が推奨され、データベース管理者はそ
の中から選択できます。この例では、最も有効な解決策はバインド変数を使用することです。
ただし、通常、アプリケーションを変更することは困難です。CURSOR_SHARING 初期化パ
ラメータの値を変更する方が実装が容易で、大幅な改善が可能です。
ADDM の設定
Automatic Database Diagnostic Monitor はデフォルトで使用可能になり、STATISTICS_
LEVEL 初期化パラメータにより制御されます。Automatic Database Diagnostic Monitor を
使用可能にするには、STATISTICS_LEVEL パラメータを TYPICAL または ALL に設定する
必要があります。デフォルト設定は TYPICAL です。STATISTICS_LEVEL を BASIC に設定
すると、ADDM を含めて多数の Oracle 機能が無効になります。この設定はお薦めしませ
ん。
関連項目 : STATISTICS_LEVEL 初期化パラメータの詳細は、『Oracle
Database リファレンス』を参照してください。
ADDM による I/O パフォーマンス分析は、1 つの引数 DBIO_EXPECTED に部分的に依存し
ます。この引数では、I/O サブシステムのパフォーマンス予測を記述します。DBIO_
EXPECTED の値は、1 つのデータベース・ブロックを読み取るための平均所要時間（マイク
ロ秒単位）です。Oracle ではデフォルト値の 10 ミリ秒が使用されます。この値は、最新の
ほとんどのハード・ドライブに適しています。極端に古いハードウェアや超高速の RAM
ディスクなど、ハードウェアが大きく異なっている場合は、異なる値を使用することを考慮
してください。
DBIO_EXPECTED パラメータの適切な設定を判断する手順は、次のとおりです。
1.
ハードウェアについて、1 データベース・ブロックを読み取るための平均所要時間を測
定します。この測定の対象はランダム I/O であり、標準ハード・ドライブを使用してい
る場合はシーク時間が含まれることに注意してください。ハード・ドライブの標準値は
5000 ～ 20000 マイクロ秒です。
2.
後続のすべての ADDM 実行について値を 1 度設定します。たとえば、測定値が 8000 マ
イクロ秒の場合は、次のコマンドを SYS ユーザーとして実行する必要があります。
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
'ADDM', 'DBIO_EXPECTED', 8000);
6-6　Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
Oracle Enterprise Manager を使用した ADDM へのアクセス
Automatic Database Diagnostic Monitor への主インタフェースは、Oracle Enterprise
Manager Database Control です。Oracle Enterprise Manager Database Control から
Automatic Database Diagnostic Monitor にアクセスする手順は、次のとおりです。
■
■
■
■
「Database Home」
」ページの「
「Performance Analysis」
」には、最後の分析期間に関する
ADDM の検出結果が表示されます。各検出結果に関連付けられているリンクをクリック
すると、その検出結果に対する推奨事項を含む詳細ページを表示できます。
Oracle Enterprise Manager の「
「Database」
」ページでは、最下部の「
「Related Links」
」に
ある「
「Advisor Central」
」リンクをクリックできます。「Advisor Central」
」ページでは、
以前の ADDM タスクを検索したり、
「ADDM」
」リンクをクリックして新規タスクを作
成できます。
「Database Performance」
」ページでは、「Sessions: Waiting and Working」
」グラフの真
下にあるクリップボード・アイコンをクリックして ADDM 分析を表示できます。
「Workload Repository Snapshots」
」ページから、選択したスナップショットまたは保存
済スナップショット（ベースライン）セットに対する ADDM タスクを実行できます。
■
■
「Administration」
」ページで、
「Workload」
」の下の「
「Automatic Workload
Repository」
」リンクをクリックします。
「Automatic Workload Repository」
」ページで、
「Snapshots」
」または「
「Preserved
Snapshot Sets」
」の横のリンクをクリックします。
– 「Snapshots」
」ページでは、「Actions」
」プルダウン・メニューから「
「Create
ADDM Task」
」を選択できます。次に、分析する期間に対応する開始スナップ
ショットと終了スナップショットを選択します。
– 「Preserved Snapshot Sets」
」ページでは、
「Actions」
」プルダウン・メニューか
ら「
「Create ADDM Task」
」を選択できます。次に、分析する期間に対応する保
存済スナップショット・セットを選択します。
関連項目 : Oracle Enterprise Manager で使用可能な監視および診断ツー
ルの詳細は、
『Oracle Enterprise Manager 概要』および Oracle Enterprise
Manager オンライン・ヘルプを参照してください。
自動パフォーマンス診断
6-7
Automatic Database Diagnostic Monitor
ADDM を使用したデータベース・パフォーマンスの問題の診断
次の要件が満たされている場合は、データベース・パフォーマンスの問題を診断するため
に、任意の 2 つの AWR スナップショットにまたがって ADDM 分析を実行できます。
■
■
作成中にどちらのスナップショットでもエラーが発生しておらず、まだ消去されていな
いこと。
2 つのスナップショット間で停止および起動アクションが発生していないこと。
前夜の午後 7 時から午後 9 時までデータベースのパフォーマンスが不十分だったとユーザー
が不満を述べている場合の使用例を考えてみます。この期間中のデータベース・パフォーマ
ンスを診断する最初のステップでは、その期間の ADDM 分析を実行する必要があります。
特定の期間に対して ADDM 分析を実行する場合に最も単純な方法は、Oracle Enterprise
Manager GUI を使用することです。ADDM は、$ORACLE_
HOME/rdbms/admin/addmrpt.sql スクリプトおよび DBMS_ADVISOR パッケージ API を
使用して手動でも実行できます。SQL スクリプトと API は、ADVISOR 権限を付与されてい
る任意のユーザーが実行できます。
関連項目 : DBMS_ADVISOR パッケージの詳細は、『PL/SQL パッケージ・
プロシージャおよびタイプ・リファレンス』を参照してください。
addmrpt.sql を使用した ADDM の実行
前述の使用例で ADDM 分析を起動するには、単に SQL プロンプトから addmrpt.sql スク
リプトを実行します。
@$ORACLE_HOME/rdbms/admin/addmrpt.sql
addmrpt.sql レポートを実行して使用例の特定の期間を分析する場合は、次の操作が必要
です。
1.
レポートで最初に表示される最新スナップショット・リストから、前夜の午後 7 時以前
に作成された最後のスナップショットと、午後 9 時以降に作成された最初のスナップ
ショットを識別します。出力は、次のようなものです。
Listing the last 3 days of Completed Snapshots
...
Snap
Instance
DB Name
Snap Id
Snap Started
Level
------------ ------------ --------- ------------------ ----main
MAIN
136 20 Oct 2003 18:30
1
137 20 Oct 2003 19:00
1
138 20 Oct 2003 19:30
1
139 20 Oct 2003 20:00
1
140 20 Oct 2003 20:30
1
141 20 Oct 2003 21:00
1
142 20 Oct 2003 21:30
1
6-8　Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
2.
開始スナップショットの要求に対して午後 7 時に最も近いスナップショット ID を指定
し、終了スナップショットの要求に対して午後 9 時のスナップショット ID を指定しま
す。
Enter value for begin_snap: 137
Begin Snapshot Id specified: 137
Enter value for end_snap: 141
End
Snapshot Id specified: 141
3.
レポート名の指定を求めるプロンプトに対してレポート名を入力するか、デフォルト名
を受け入れます。
Enter value for report_name:
Using the report name addmrpt_1_137_145.txt
Running the ADDM analysis on the specified pair of snapshots ...
Generating the ADDM report for this analysis ...
レポート名を指定すると、特定期間の ADDM 分析が実行されます。分析が終了すると、テ
キストの ADDM 分析レポートが表示されます。このレポートを検討して、データベースに
影響している上位のパフォーマンスの問題および可能な解決策を確認できます。
非対話型モードによる addmrpt.sql レポートの実行手順は、$ORACLE_
HOME/rdbms/admin/addmrpt.sql ファイルの先頭を参照してください。
DBMS_ADVISOR API を使用した ADDM の実行
特定の ADDM 分析を実行するために、DBMS_ADVISOR API を使用して独自の PL/SQL プ
ログラムを記述できます。DBMS_ADVISOR プロシージャを使用すると、ADDM タスクなど、
任意のアドバイザ・タスクを作成して実行できます。アドバイザ・タスクは、ユーザーによ
るすべてのチューニング作業を管理する Workload Repository 内の実行可能データ領域で
す。
DBMS_ADVISOR パッケージの典型的な使用方法では、次の操作が必要です。
■
■
DBMS_ADVISOR.CREATE_TASK を使用して、ADDM など、特定タイプのアドバイザ・
タスクを作成します。
DBMS_ADVISOR.SET_TASK_PARAMETER を使用して、START_SNAPSHOT および END_
SNAPSHOT パラメータなど、特定タイプのタスクを実行するための必須パラメータを設
定します。
■
DBMS_ADVISOR.EXECUTE_TASK を使用してタスクを実行します。
■
DBMS_ADVISOR.GET_TASK_REPORT を使用して結果を表示します。
前述の使用例では、PL/SQL ファンクションを記述して、指定した期間に最も近い時点で作
成されたスナップショットを自動的に識別してから ADDM を実行できます。この PL/SQL
ファンクションは、次のようなものです。
自動パフォーマンス診断
6-9
Automatic Database Diagnostic Monitor
例 6-2 1 対のスナップショットに対して ADDM 分析を実行するためのファンクション
CREATE OR REPLACE FUNCTION run_addm(start_time IN DATE, end_time IN DATE )
RETURN VARCHAR2
IS
begin_snap
NUMBER;
end_snap
NUMBER;
tid
NUMBER;
-- Task ID
tname
VARCHAR2(30);
-- Task Name
tdesc
VARCHAR2(256);
-- Task Description
BEGIN
-- Find the snapshot IDs corresponding to the given input parameters.
SELECT max(snap_id)INTO begin_snap
FROM DBA_HIST_SNAPSHOT
WHERE trunc(end_interval_time, 'MI') <= start_time;
SELECT min(snap_id) INTO end_snap
FROM DBA_HIST_SNAPSHOT
WHERE end_interval_time >= end_time;
--- set Task Name (tname) to NULL and let create_task return a
-- unique name for the task.
tname := '';
tdesc := 'run_addm( ' || begin_snap || ', ' || end_snap || ' )';
--- Create a task, set task parameters and execute it
DBMS_ADVISOR.CREATE_TASK( 'ADDM', tid, tname, tdesc );
DBMS_ADVISOR.SET_TASK_PARAMETER( tname, 'START_SNAPSHOT', begin_snap );
DBMS_ADVISOR.SET_TASK_PARAMETER( tname, 'END_SNAPSHOT' , end_snap );
DBMS_ADVISOR.EXECUTE_TASK( tname );
RETURN tname;
END;
/
例 6-2 の PL/SQL ファンクション run_addm では、指定した期間に最も近い時点で作成さ
れたスナップショットが検出され、その期間に対して ADDM 分析が実行されます。また、
このファンクションでは、分析を実行した ADDM タスクの名前も戻されます。
PL/SQL ファンクション run_addm を使用して午後 7 時から午後 9 時まで ADDM を実行
し、テキストの分析レポートを生成するには、次のような SQL 文を実行できます。
6-10　Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
例 6-3 特定の 1 対のスナップショットに対する ADDM 分析レポートの実行
-- set SQL*Plus variables and column formats for the report
SET PAGESIZE 0 LONG 1000000 LONGCHUNKSIZE 1000;
COLUMN get_clob FORMAT a80;
-- execute run_addm() with 7pm and 9pm as input
VARIABLE task_name VARCHAR2(30);
BEGIN
:task_name := run_addm( TO_DATE('19:00:00 (10/20)', 'HH24:MI:SS (MM/DD)'),
TO_DATE('21:00:00 (10/20)', 'HH24:MI:SS (MM/DD)') );
END;
/
-- execute GET_TASK_REPORT to get the textual ADDM report.
SELECT DBMS_ADVISOR.GET_TASK_REPORT(:task_name)
FROM DBA_ADVISOR_TASKS t
WHERE t.task_name = :task_name
AND t.owner = SYS_CONTEXT( 'userenv', 'session_user' );
DBMS_ADVISOR.GET_TASK_REPORT ファンクションは CLOB を戻すため、ADDM レポー
ト全体を表示するには、SQL*Plus システム変数 LONG を十分な大きさの値に設定する必要
があることに注意してください。
ADDM 情報を表示するビュー
一般に、Oracle Enterprise Manager または ADDM レポートを使用して、Automatic
Database Diagnostic Monitor からの出力および情報を表示します。ただし、ADDM 情報は
DBA_ADVISOR ビューを使用して表示できます。このグループのビューには次のようなもの
があります。
■
DBA_ADVISOR_TASKS
このビューでは、タスク ID、タスク名および作成日時など、既存のタスクに関する基
本情報が示されます。
■
DBA_ADVISOR_LOG
このビューには、ステータス、進捗、エラー・メッセージおよび実行時間などの現行タ
スクの情報が含まれます。
■
DBA_ADVISOR_RECOMMENDATIONS
このビューには、完了した診断タスクの結果と、実行ごとに識別された問題に対する推
奨事項が表示されます。推奨事項は、RANK 列の順序どおりに参照する必要があります。
この順序は、推奨事項における問題の重要性を伝えているためです。BENEFIT 列には、
推奨事項を実行した場合のシステムに対する利点が示されます。
自動パフォーマンス診断
6-11
Automatic Database Diagnostic Monitor
■
DBA_ADVISOR_FINDINGS
このビューには、診断モニターで発見されたすべての事実と症状が、特定の推奨事項と
ともに表示されます。
関連項目 : 静的なデータ・ディクショナリ・ビューの詳細は、『Oracle
Database リファレンス』を参照してください。
6-12　Oracle Database パフォーマンス・チューニング・ガイド
7
メモリーの構成と使用方法
この章では、Oracle メモリー・キャッシュにメモリーを割り当てる方法とこれらのキャッ
シュの使用方法について説明します。Oracle メモリー・キャッシュを適切にサイズ設定して
効率的に使用すると、データベースのパフォーマンスが大幅に向上します。
SGA_TARGET および PGA_AGGREGATE_TARGET 初期化パラメータを使用するシステムには、
自動メモリー構成をお薦めします。ただし、システムのメモリー・プールは手動で調整でき
ます。そのプロセスはこの章に記載されています。
この章には次の項があります。
■
メモリー割当ての問題について
■
バッファ・キャッシュの構成と使用方法
■
共有プールとラージ・プールの構成および使用方法
■
REDO ログ・バッファの構成および使用
■
PGA メモリー管理
関連項目 : Oracle データベースのメモリー・アーキテクチャの詳細は、
『Oracle Database 概要』を参照してください。
メモリーの構成と使用方法
7-1
メモリー割当ての問題について
メモリー割当ての問題について
Oracle はメモリー・キャッシュ内およびディスク上に情報を格納します。メモリー・アクセ
スは、ディスク・アクセスよりはるかに高速です。ディスク・アクセス（物理 I/O）は、メ
モリー・アクセスに比べ、時間がかかります（通常は約 10 ミリ秒）。また、物理 I/O では、
デバイス・ドライバやオペレーティング・システムのイベント・スケジューラのパス長のた
めに必要な CPU リソースも増加します。このため、頻繁にアクセスされるオブジェクトに
対するデータ要求は、ディスク・アクセスではなく、メモリー・アクセスで要求するほうが
効率的です。
パフォーマンスの目標は、必要なデータがメモリー内にある可能性を高くしたり、必要な
データを取り出すプロセスをさらに効率的にし、できるだけ多くの物理 I/O オーバーヘッド
を削減することです。
自動メモリー管理の使用をお薦めします。任意のメモリー・プール・サイズを設定する前
に、次の点を確認してください。
■
7-3 ページ「自動共有メモリー管理」
■
7-49 ページ「PGA メモリー管理」
メモリー割当てを構成する必要がある場合は、Oracle Enterprise Manager に更新用のメモ
リー・アドバイザが用意されています。Oracle Enterprise Manager Database Control からメ
モリー・アドバイザにアクセスする手順は、次のとおりです。
■
■
「Database」
」ページの最下部で、
「Related Links」
」の下の「
「Advisor Central」
」リンクを
クリックします。
「Advisor Central」
」ページで「
「Memory Advisor」
」リンクをクリックし、「Memory
Parameters SGA」
」および「
「PGA」
」ページにアクセスできます。
Oracle メモリー・キャッシュ
パフォーマンスに影響を与える主な Oracle メモリー・キャッシュは次のとおりです。
■
共有プール
■
ラージ・プール
■
Java プール
■
バッファ・キャッシュ
■
ストリーム・プール・サイズ
■
ログ・バッファ
■
プロセス・プライベート・メモリー（ソートやハッシュ結合に使用されるメモリーな
ど）
7-2　Oracle Database パフォーマンス・チューニング・ガイド
メモリー割当ての問題について
自動共有メモリー管理
自動共有メモリー管理は、SGA の構成を簡素化する、推奨のメモリー構成です。自動共有メ
モリー管理を使用するには、SGA_TARGET 初期化パラメータをゼロ以外の値に設定し、
STATISTICS_LEVEL 初期化パラメータを TYPICAL または ALL に設定します。SGA_
TARGET パラメータの値は、SGA 専用にするメモリーの容量に設定する必要があります。自
動 SGA 管理では、システム上のワークロードに応じて次のメモリー・プールにメモリーが
適切に配分されます。
■
データベース・バッファ・キャッシュ（デフォルト・プール）
■
共有プール
■
ラージ・プール
■
Java プール
自動的にチューニングされるこれらのメモリー・プールをゼロ以外の値に設定すると、その
値が自動共有メモリー管理における最小レベルとして使用されます。アプリケーション・コ
ンポーネントが最小限のメモリーで正常に機能できる場合は、最小値に設定します。
SGA_TARGET は動的パラメータであり、Oracle Enterprise Manager または ALTER SYSTEM
コマンドによって変更できます。SGA_TARGET は、SGA_MAX_SIZE 初期化パラメータの値
以下に設定できます。SGA_TARGET の値の変更により、自動的にチューニングされたメモ
リー・プールが自動的にサイズ変更されます。
関連項目 :
■
■
自動 SGA 管理の詳細は、『Oracle Database 概要』を参照してくださ
い。
システム・グローバル領域（SGA）の管理の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
SGA_TARGET を 0（ゼロ）に設定すると、自動共有メモリー管理は無効になり、メモリー・
プールは、DB_CACHE_SIZE、SHARED_POOL_SIZE、LARGE_POOL_SIZE および JAVA_
POOL_SIZE 初期化パラメータを使用して手動でサイズ設定できます。7-4 ページの「キャッ
シュ・サイズの動的な変更」を参照してください。
次のプールは手動でサイズ設定されるコンポーネントで、自動共有メモリー管理の影響は受
けません。
■
■
ログ・バッファ
KEEP、RECYCLE などのその他のバッファ・キャッシュおよびその他のブロック・
サイズ
■
ストリーム・プール
■
固定 SGA およびその他の内部割当て
メモリーの構成と使用方法
7-3
メモリー割当ての問題について
メモリー・プールを手動でサイズ設定するには、DB_KEEP_CACHE_SIZE、DB_RECYCLE_
CACHE_SIZE、DB_nK_CACHE_SIZE、STREAMS_POOL_SIZE および LOG_BUFFER 初期化
パラメータを設定する必要があります。これらのプールに割り当てられたメモリーは、自動
共有メモリー管理で、自動的にチューニングするメモリー・プールの値を計算する際に、
SGA_TARGET に使用可能な総量から差し引かれます。
関連項目 :
■
■
■
初期化パラメータの管理の詳細は、
『Oracle Database 管理者ガイド』
を参照してください。
STREAMS_POOL_SIZE 初期化パラメータの構成の詳細は、
『Oracle
Streams 概要および管理』を参照してください。
Java のメモリー使用量の詳細は、
『Oracle Database Java 開発者ガイ
ド』を参照してください。
キャッシュ・サイズの動的な変更
システムで自動共有メモリー管理が使用されていない場合、共有プール、ラージ・プール、
バッファ・キャッシュおよびプロセス・プライベート・メモリーのサイズを動的に再構成す
ることを選択できます。次の各項では、キャッシュ・サイズ設定の詳細について説明します。
■
バッファ・キャッシュの構成と使用方法
■
共有プールとラージ・プールの構成および使用方法
■
REDO ログ・バッファの構成および使用
DB_CACHE_ADVICE、JAVA_POOL_SIZE、LARGE_POOL_SIZE、LOG_BUFFER および
SHARED_POOL_SIZE などの初期化構成パラメータを使用して、これらのメモリー・キャッ
シュのサイズを構成できます。これらのパラメータの値も、ALTER SYSTEM 文で動的に構成
できます（起動後に静的に設定されるログ・バッファ・プールおよびプロセス・プライベー
ト・メモリーを除く）
。
共有プール、ラージ・プール、Java プールおよびバッファ・キャッシュのメモリーは、グラ
ニュル単位で割り当てられます。SGA サイズが 1GB より小さい場合、グラニュル・サイズ
は 4MB です。SGA サイズが 1GB 以上の場合、グラニュル・サイズは 16MB に変化します。
グラニュル・サイズは、インスタンスの起動時に計算されて固定されます。このサイズは、
インスタンスの存続期間中は変化しません。
SGA で現在使用されているグラニュルのサイズは、ビュー V$SGA_DYNAMIC_COMPONENTS
によって表示できます。それと同じグラニュルのサイズが SGA のすべての動的コンポーネ
ントで使用されます。
7-4　Oracle Database パフォーマンス・チューニング・ガイド
メモリー割当ての問題について
SGA の総サイズは、SGA_MAX_SIZE パラメータの値まで拡張できます。SGA_MAX_SIZE が
設定されていない場合は、必要であれば、1 つのキャッシュのサイズを減らして、そのメモ
リーを別のキャッシュに再割当てできます。SGA_MAX_SIZE は、全コンポーネントの集計
にデフォルト設定されています。
注意 :
SGA_MAX_SIZE は、動的にサイズ変更できません。
インスタンスで使用できる最大メモリー量は、インスタンス起動時に SGA_MAX_SIZE 初期
化パラメータで決定されます。SGA_MAX_SIZE は、すべてのメモリー・コンポーネント
（バッファ・キャッシュや共有プールなど）の合計よりも大きいサイズに指定できます。指
定しない場合、SGA_MAX_SIZE は、これらのコンポーネントで使用される実際のサイズに
デフォルト設定されます。すべてのコンポーネントで使用される合計メモリーよりも大きい
値に SGA_MAX_SIZE を設定すると、別のキャッシュのサイズを小さくせずにキャッシュ・
サイズを動的に大きくできます。
関連項目 : 動的 SGA の管理の詳細は、オペレーティング・システムのマ
ニュアルを参照してください。
動的サイズ変更操作に関する情報の表示
次のビューは、動的 SGA サイズ変更操作に関する情報を提供します。
■
■
■
■
V$SGA_CURRENT_RESIZE_OPS: 現在進行中の SGA サイズ変更操作に関する情報。動的
SGA コンポーネントの拡張または縮小操作があります。
V$SGA_RESIZE_OPS: 実行済の最新の 400 件の SGA サイズ変更操作に関する情報。これ
には現在進行中の操作は含まれません。
V$SGA_DYNAMIC_COMPONENTS: SGA の動的コンポーネントに関する情報。このビュー
では、起動後のすべての実行済 SGA サイズ変更操作に基づく情報が要約されます。
V$SGA_DYNAMIC_FREE_MEMORY: 今後の動的 SGA サイズ変更操作で使用可能な SGA メ
モリーの量に関する情報。
関連項目 :
■
■
動的 SGA の詳細は、『Oracle Database 概要』を参照してください。
これらのビューの列の詳細は、
『Oracle Database リファレンス』を参
照してください。
メモリーの構成と使用方法
7-5
メモリー割当ての問題について
アプリケーションの考慮事項
メモリー構成では、アプリケーションの要求に適したキャッシュをサイズ設定することが重
要です。逆に、アプリケーションのキャッシュの使用率をチューニングすると、リソース要
件を大幅に削減できます。Oracle メモリー・キャッシュを効率的に使用すると、これらの
キャッシュを保護するラッチ、CPU、I/O システムなどの関連リソースに対する負荷も削減
できます。
最高のパフォーマンスを得るために、次のことを考慮してください。
■
■
オペレーティング・システムおよびデータベース・リソースを最も効率的に使用するよ
うに、キャッシュを最適に設計する必要があります。
Oracle メモリー構造に対するメモリーの割当ては、アプリケーションの要求を最もよく
反映する必要があります。
既存のアプリケーションに対する変更または追加を行う場合は、変更されたアプリケーショ
ンの要求を満たすために Oracle メモリー構造のサイズ変更が必要な場合があります。
アプリケーションが Java を使用する場合、Java プールのデフォルト構成を変更する必要が
あるかどうかを調べる必要があります。Java のメモリー使用量の詳細は、『Oracle Database
Java 開発者ガイド』を参照してください。
オペレーティング・システムのメモリー使用量
大半のオペレーティング・システムでは、次のことを考慮することが重要です。
ページングの削減
ページングは、新しいページをメモリーにロードできるようにするため、オペレーティン
グ・システムがメモリー常駐ページをディスクに転送する場合に行われます。多くのオペ
レーティング・システムは、実メモリーに格納しきれない大量の情報を収容するために、
ページングを行います。大半のオペレーティング・システムでは、ページングはパフォーマ
ンスを低下させます。
オペレーティング・システムのユーティリティを使用して、オペレーティング・システムを
調べ、システム上に多数のページングがあるかどうかを確認します。ページングが多数ある
場合は、システム上の総メモリー量が、メモリーを割り当てたすべてを保持できるほど十分
に大きくない場合があります。システム上の全体のメモリーを増やすか、割り当てたメモ
リー量を減らします。
主メモリーへの SGA の格納
SGA の目的は、迅速なアクセスのためにメモリー内にデータを格納することなので、SGA
は主メモリー内に存在する必要があります。SGA のページがディスクにスワップされると、
データに迅速にアクセスできなくなります。多くのオペレーティング・システムでは、ペー
ジングによる損失は、大規模な SGA がもたらす利益をかなり上回ります。
7-6　Oracle Database パフォーマンス・チューニング・ガイド
メモリー割当ての問題について
注意 : LOCK_SGA パラメータを使用すると、SGA が物理メモリーにロッ
クされるため、ページ・アウトを防止できます。
SGA とその各内部構造に割り当てられるメモリー量を確認するには、次の SQL*Plus 文を入
力します。
SHOW SGA
この文の出力例を次に示します。
Total System Global Area
Fixed Size
Variable Size
Database Buffers
Redo Buffers
840205000
279240
520093696
318767104
1064960
bytes
bytes
bytes
bytes
bytes
個々のユーザーへの十分なメモリーの割当て
SGA をサイズ設定する場合は、個々のサーバー・プロセスとその他のプログラムがシステム
上で作動するように十分なメモリーを使用できるようにします。
関連項目 : オペレーティング・システムのメモリー使用方法のチューニ
ングの詳細は、オペレーティング・システムのハードウェアとソフトウェ
アのマニュアル、およびオペレーティング・システム固有の Oracle マ
ニュアルを参照してください。
構成の繰返し
メモリーの割当てを構成する場合は、アプリケーションの要求により異なりますが、Oracle
メモリー構造に使用可能なメモリーを配分します。Oracle の構造にメモリーを配分すると、
Oracle が動作するために必要な物理 I/O の量に影響を与える可能性があります。最初にメ
モリーを適切に構成すると、I/O システムが効果的に構成されているかどうかも表示されま
す。
プロセスをひととおり実行した後で、メモリー割当てのステップを繰り返すことが必要とな
る可能性もあります。実行を繰り返すことによって、後のステップの変更に基づいて前のス
テップの調整が可能となります。たとえば、バッファ・キャッシュのサイズを小さくする
と、共有プールなど別のメモリー構造のサイズを大きくできます。
メモリーの構成と使用方法
7-7
バッファ・キャッシュの構成と使用方法
バッファ・キャッシュの構成と使用方法
様々なタイプの操作について、Oracle ではバッファ・キャッシュを使用してディスクから読
み取られたブロックを格納します。ソートやパラレル読込みなどの特定操作の場合には、
Oracle ではバッファ・キャッシュはバイパスされます。バッファ・キャッシュを使用する操
作について、この項では次の項目を説明します。
■
バッファ・キャッシュの効果的な使用
■
バッファ・キャッシュのサイズ設定
■
バッファ・キャッシュ・アドバイザ統計の解釈および使用方法
■
複数バッファ・プールについて
バッファ・キャッシュの効果的な使用
バッファ・キャッシュを効果的に使用するには、不要なリソース使用を回避するようにアプ
リケーションの SQL 文をチューニングする必要があります。これを確認するには、頻繁に
実行される SQL 文と、多数のバッファ取得を実行する SQL 文がチューニングされたかどう
かを検証します。
関連項目 : この確認を行う方法の詳細は、第 12 章「SQL チューニングの
概要」を参照してください。
バッファ・キャッシュのサイズ設定
新規にインスタンスを構成する場合は、バッファ・キャッシュの適切なサイズがわかってい
ません。通常、データベース管理者はキャッシュ・サイズの最初の見積りを行い、次にイン
スタンス上で代表的なワークロードを実行し、関連する統計を調べて、キャッシュが構成過
小か構成過大かを調べます。
バッファ・キャッシュ・アドバイザの統計
多数の統計が、バッファ・キャッシュ・アクティビティの調査に使用できます。これらの統
計には次のものがあります。
■
V$DB_CACHE_ADVICE
■
バッファ・キャッシュ・ヒット率
7-8　Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
V$DB_CACHE_ADVICE の使用
このビューは、DB_CACHE_ADVICE 初期化パラメータが ON に設定されているときに移入さ
れます。このビューは、潜在的なバッファ・キャッシュ・サイズ範囲のシミュレーションに
よるミス率を示します。
このビューには、シミュレートされたキャッシュ・サイズのそれぞれの独自の行と、その
キャッシュ・サイズに対して発生すると予測された物理 I/O アクティビティがあります。
DB_CACHE_ADVICE パラメータは動的であるため、特定のワークロードのアドバイザ・デー
タを収集できるように、アドバイザ機能を動的に有効にしたり、無効にできます。
このアドバイザ機能には、多少のオーバーヘッドが伴います。アドバイザ機能を有効にする
と、追加の記録が必要なため、CPU の使用量はわずかに増加します。
Oracle では、DBA ベースのサンプリングを使用して、キャッシュ・アドバイザ統計を収集
します。サンプリングを使用すると、ブックキーピングに関連する CPU およびメモリーの
オーバーヘッドが大幅に減少します。サンプリングは、開始時のバッファの数が少ないバッ
ファ・プールでは使用しません。
V$DB_CACHE_ADVICE を使用するには、パラメータ DB_CACHE_ADVICE を ON に設定し、
インスタンス上で代表的なワークロードを実行するようにします。V$DB_CACHE_ADVICE
ビューを問い合せる前にワークロードを安定化できるようにします。
次の SQL 文は、様々なキャッシュ・サイズについてデフォルト・バッファ・プールに対す
る I/O 要件の予測を戻します。
COLUMN
COLUMN
COLUMN
COLUMN
size_for_estimate
buffers_for_estimate
estd_physical_read_factor
estd_physical_reads
FORMAT
FORMAT
FORMAT
FORMAT
999,999,999,999 heading 'Cache Size (MB)'
999,999,999 heading 'Buffers'
999.90 heading 'Estd Phys|Read Factor'
999,999,999 heading 'Estd Phys| Reads'
SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads
FROM V$DB_CACHE_ADVICE
WHERE name
= 'DEFAULT'
AND block_size
= (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size')
AND advice_status = 'ON';
次の出力は、キャッシュが現行サイズの 304MB ではなく 212MB である場合、物理読込みの
予測数が 1.74 倍、つまり 74% 増加することを示しています。つまり、キャッシュ・サイズ
を 212MB に減少させることは望ましくありません。
ただし、キャッシュ・サイズを 334MB に増やすと、読取り数は 0.93 倍、つまり 7% 減少す
ることになります。ホスト・マシン上でさらに 30MB 使用可能で、SGA_MAX_SIZE 設定で増
分が許可されている場合は、デフォルトのバッファ・キャッシュ・プール・サイズを 334MB
に増やすことをお薦めします。
メモリーの構成と使用方法
7-9
バッファ・キャッシュの構成と使用方法
Estd Phys
Estd Phys
Cache Size (MB)
Buffers Read Factor
Reads
---------------- ------------ ----------- -----------30
3,802
18.70 192,317,943
60
7,604
12.83 131,949,536
91
11,406
7.38
75,865,861
121
15,208
4.97
51,111,658
152
19,010
3.64
37,460,786
182
22,812
2.50
25,668,196
212
26,614
1.74
17,850,847
243
30,416
1.33
13,720,149
273
34,218
1.13
11,583,180
304
38,020
1.00
10,282,475
334
41,822
.93
9,515,878
364
45,624
.87
8,909,026
395
49,426
.83
8,495,039
424
53,228
.79
8,116,496
456
57,030
.76
7,824,764
486
60,832
.74
7,563,180
517
64,634
.71
7,311,729
547
68,436
.69
7,104,280
577
72,238
.67
6,895,122
608
76,040
.66
6,739,731
10% of Current Size
Current Size
200% of Current Size
このビューは、潜在的な各キャッシュ・サイズの物理読込み数を予測する情報を提供して、
キャッシュのサイズ設定を支援します。このデータには物理読込みファクタが含まれていま
す。これは、バッファ・キャッシュが所定の値にサイズ変更された場合、現行の物理読込み
回数がその分のみ変化すると予測されるファクタです。
注意 : Oracle では、物理読込みは必ずしもディスク読込みを意味しませ
ん。物理読込みは、ファイル・システム・キャッシュからで済む場合があ
ります。
キャッシュ内でのブロックの検出成功とキャッシュのサイズ間の関係は、必ずしも滑らかな
分布を示しません。バッファ・プールをサイズ設定するときは、キャッシュ・ヒット率の向
上にまったく貢献しない（または、ほとんど貢献しない）追加バッファは使用しないでくだ
さい。7-11 ページの図 7-1 の例では、キャッシュ・サイズの増分の狭い帯状部分のみが考慮
に値することを示しています。
7-10　Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
図 7-1 物理 I/O とバッファ・キャッシュ・サイズ
図 7-1 を調べると、次のことがわかります。
■
■
ポイント A からポイント B へバッファを増やす場合の利点は、ポイント B からポイント
C へバッファを増やす場合よりかなり大きくなります。
ポイント A と B およびポイント B と C との間の物理 I/O の減少は、グラフの点線で示さ
れるように滑らかではありません。
バッファ・キャッシュ・ヒット率の計算
バッファ・キャッシュ・ヒット率では、ディスク・アクセスを行わずにバッファ・キャッ
シュ内で要求されたブロックが検出された頻度を計算します。この率は、動的なパフォーマ
ンス・ビュー V$SYSSTAT から選択したデータを使用して計算されます。バッファ・キャッ
シュ・ヒット率を使用して、V$DB_CACHE_ADVICE で予測されたように物理 I/O を検証で
きます。
メモリーの構成と使用方法
7-11
バッファ・キャッシュの構成と使用方法
表 7-1 の統計は、ヒット率の計算に使用されます。
表 7-1 ヒット率を計算するための統計
統計
説明
consistent gets from cache
バッファ・キャッシュからのブロックに対して読取り一貫性が
要求された回数。
db block gets from cache
バッファ・キャッシュからの CURRENT ブロックが要求された
回数。
physical reads cache
バッファ・キャッシュにアクセスする結果となった、データ・
ブロックへのアクセス要求の総数。
例 7-1 は V$SYSSTAT 表から直接選択した値を使用して単純化したもので、ある期間の値を
選択したものではありません。アプリケーションの実行中のある期間にわたるこれらの統計
の差分を計算し、それらの統計を使用してヒット率を判断することが最良の方法です。
関連項目 : ある期間内の統計の収集の詳細は、第 6 章「自動パフォーマ
ンス診断」を参照してください。
例 7-1 バッファ・キャッシュ・ヒット率の計算
SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME IN ('db block gets from cache', 'consistent gets from cache', 'physical
reads cache');
問合せの出力の値を使用し、次の計算式でバッファ・キャッシュ・ヒット率を計算します。
1 - (('physical reads cache') / ('consistent gets from cache' + 'db block gets from cache')
関連項目 : V$SYSSTAT ビューの詳細は、
『Oracle Database リファレン
ス』を参照してください。
7-12　Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
バッファ・キャッシュ・アドバイザ統計の解釈および使用方法
バッファ・キャッシュ・サイズの増減を考慮する前に、調べるファクタは多数あります。た
とえば、V$DB_CACHE_ADVICE データおよびバッファ・キャッシュ・ヒット率を調べる必
要があります。
低いキャッシュ・ヒット率は、キャッシュのサイズを大きくすることがパフォーマンスに有
益であることを意味しません。キャッシュ・ヒット率の高いことが、ワークロードに対して
キャッシュが適切にサイズ設定されていることを示しているとはかぎりません。
バッファ・キャッシュ・ヒット率を解釈する場合は、次の点を考慮する必要があります。
■
■
■
大きな表や索引を繰り返しスキャンすると、キャッシュ・ヒット率を低下させる可能性
があります。バッファ取得数が多く、頻繁に実行される SQL 文を調べて、実行計画が
最適なものであるか確認します。可能であれば、1 つのパスですべての処理を実行する
か、SQL 文を最適化して、頻繁にアクセスされるデータを繰り返しスキャンしないよう
にします。
可能であれば、頻繁にアクセスされるデータをクライアント・プログラムまたは中間層
にキャッシュして、同じデータを再問合せしないようにします。
長い全表スキャンでアクセスされた Oracle ブロックは、最低使用頻度（LRU）リストの
最後に配置され、リストの先頭には配置されません。このようにして、これらのブロッ
クは、索引参照または小規模な表スキャンを実行するときに読み込まれるブロックより
も早く除去されます。バッファ・キャッシュ・データの解析では、有効な大規模全表ス
キャン時の低いヒット率についても考慮する必要があります。
注意 : 小規模表のスキャンは、一定のサイズのしきい値を使用して、表
に対して実行されるスキャンです。小規模表とは、最大でバッファ・
キャッシュの 2% か 20 のいずれかの、大きい方と定義されます。
■
■
OLTP アプリケーションを実行するどの大容量データベースでも、常にほとんどの行は 1
回ないし 0 回しかアクセスされません。このことを基準に考えると、ブロックを使用後
に長期間メモリーに保存することは、ほとんど意味がありません。
バッファ・キャッシュ・サイズを継続して増やすことはよくある間違いです。全表ス
キャンや、バッファ・キャッシュを使用しない操作を実行している場合は、このように
値を増やしても何の効果もありません。
メモリーの構成と使用方法
7-13
バッファ・キャッシュの構成と使用方法
バッファ・キャッシュに割り当てられたメモリーの増加
一般規則として、キャッシュ・ヒット率が低く、全表スキャンを実行しないようにアプリ
ケーションがチューニングされている場合は、キャッシュのサイズを増やすことを検討して
ください。
キャッシュ・サイズを増やすには、まず DB_CACHE_ADVICE 初期化パラメータを ON に設定
し、キャッシュ統計を安定させます。V$DB_CACHE_ADVICE ビュー内のアドバイザ・デー
タを調べて、実行する物理 I/O の量を大幅に減少させるために必要な次の増分を決定しま
す。ホスト・オペレーティング・システムにページングさせずに必要な余分なメモリーを
バッファ・キャッシュに割り当てることができる場合は、このメモリーを割り当てます。
バッファ・キャッシュに割り当てられたメモリーの量を増やすには、DB_CACHE_SIZE 初期
化パラメータの値を増やします。
必要であれば、インスタンスをシャットダウンせずに、バッファ・プールを動的にサイズ変
更してこの変更を行います。
注意 : キャッシュを大幅に（20 パーセント以上）サイズ変更すると、古
いキャッシュ・アドバイザ値は破棄されて、新しいサイズに設定されま
す。大幅にサイズ変更しない場合は、古いキャッシュ・アドバイザ値は既
存の値を補間することで新しいサイズに調整されます。
DB_CACHE_SIZE パラメータは、データベースの標準ブロック・サイズのデフォルト・
キャッシュのサイズを指定します。データベースの標準ブロック・サイズとは異なるブロッ
ク・サイズを持つ表領域を作成して使用するには（トランスポータブル表領域をサポートす
る場合など）
、使用するブロック・サイズごとに個別のキャッシュを構成する必要がありま
す。DB_nK_CACHE_SIZE パラメータを使用して、必要な標準以外のブロック・サイズを構
成できます（n は 2、4、8、16 または 32 のいずれかで、n は標準ブロック・サイズではあり
ません）
。
注意 : キャッシュ・サイズを選択するプロセスは、キャッシュがデフォ
ルトの標準ブロック・サイズ・キャッシュ、KEEP または RECYCLE
キャッシュ、標準以外のブロック・サイズ・キャッシュのいずれかにかか
わらず同様です。
関連項目 : DB_nK_CACHE_SIZE パラメータの使用方法の詳細は、
『Oracle Database リファレンス』および『Oracle Database 管理者ガイド』
を参照してください。
7-14　Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
バッファ・キャッシュに割り当てられたメモリーの削減
キャッシュ・ヒット率が高い場合、キャッシュが十分大きく、最も頻繁にアクセスされる
データも保持できる状態になっています。V$DB_CACHE_ADVICE データをチェックして、
キャッシュ・サイズを削減すると物理 I/O 数が大幅に増えるかどうかを調べます。物理 I/O
への影響がなければ、別のメモリー構造にメモリーを必要とする場合に、キャッシュ・サイ
ズを削減しても、良好なパフォーマンスを維持できます。バッファ・キャッシュを小さくす
るには、DB_CACHE_SIZE パラメータの値を変更してキャッシュのサイズを削減します。
複数バッファ・プールについて
一般に、ほとんどのシステムでは 1 つのデフォルト・バッファ・プールが適切です。ただ
し、アプリケーションのバッファ・プールについて詳しい知識を持つユーザーは、複数バッ
ファ・プールを構成すると有益な場合があります。
非定型アクセス・パターンを持つセグメントの場合、それらのセグメントからのブロックを
2 つの異なるバッファ・プールである KEEP プールと RECYCLE プールに格納します。セグ
メントのアクセス・パターンは、常にアクセスされるか（すなわち、ホット）
、またはほと
んどアクセスされない（たとえば、1 日に 1 回のみバッチ・ジョブでアクセスされる大きな
セグメント）というように、非定型である可能性があります。
複数バッファ・プールによって、これらの違いに対処できます。KEEP バッファ・プールを
使用してバッファ・キャッシュ内の頻繁にアクセスされるセグメントをメンテナンスし、
RECYCLE バッファ・プールを使用してオブジェクトがキャッシュ内の領域を不必要に占有
するのを防ぐことができます。オブジェクトがキャッシュに関連付けられると、そのオブ
ジェクトのすべてのブロックがそのキャッシュに置かれます。特定のバッファ・プールに割
り当てられていないオブジェクトのために、DEFAULT バッファ・プールがメンテナンスさ
れています。デフォルト・バッファ・プールのサイズは、DB_CACHE_SIZE です。各バッ
ファ・プールは、同じ LRU 置換方針を使用します（たとえば、KEEP プールがそのプールに
割り当てられたすべてのセグメントを格納するほど十分大きくない場合、最も古いブロック
がキャッシュから除去されます）
。
オブジェクトを適切なバッファ・プールに割り当てると、次の操作を実行できます。
■
I/O の低減または排除
■
個別のキャッシュに対するオブジェクトの隔離または制限
大きいセグメントへのランダム・アクセス
非常に大きいセグメントに大きい索引レンジ・スキャンまたは非有界索引レンジ・スキャン
でアクセスすると、LRU 除外方法では問題が発生する可能性があります。大規模とは、
キャッシュのサイズと比較して大きいという意味です。非順次物理読込みのかなりの割合
（10% を超える割合）を 1 つのセグメントが占有する場合、そのセグメントは大規模である
と考えられます。大規模セグメントに対するランダム読込みは、他のセグメントのデータを
含むバッファがキャッシュから除去される原因となります。大規模セグメントは、キャッ
シュの大きな割合を消費しますが、キャッシングによる利益はありません。
メモリーの構成と使用方法
7-15
バッファ・キャッシュの構成と使用方法
非常に頻繁にアクセスされるセグメントは、バッファが頻繁にアクセスされるのでキャッ
シュから除去されないため、大規模セグメントの読込みの影響を受けません。ただし、その
問題は、大規模セグメントの読込みによるバッファの除外を免れるほど頻繁にはアクセスさ
れないウォーム・セグメントに影響を与えます。この問題を解決するオプションは、次の 3
つです。
1.
アクセスされたオブジェクトが索引である場合は、索引に選択性があるかどうかを調べ
ます。選択性がない場合は、さらに選択性のある索引を使用するように SQL 文を
チューニングします。
2.
SQL 文をチューニングすると、大きいセグメントを個別の RECYCLE キャッシュに移動
できるので、その他のセグメントに影響を与えません。RECYCLE キャッシュは
DEFAULT バッファ・プールよりも小さくし、DEFAULT バッファ・プールよりも迅速に
バッファを再利用する必要があります。
3.
大規模セグメントではまったく使用されない別の KEEP キャッシュに小さなウォーム・
セグメントを移動する方法もあります。KEEP キャッシュをサイズ設定して、キャッ
シュでのミスを最小におさえられます。特定の問合せによってアクセスされるセグメン
トを KEEP キャッシュに置き、除去されないようにすることで、その問合せの応答時間
をより予測可能にすることができます。
Oracle Real Application Cluster のインスタンス
データベース・インスタンスごとに複数バッファ・プールを作成できます。データベースの
各インスタンスについて、必ずしも同じバッファ・プール・セットを定義する必要はありま
せん。インスタンスごとにバッファ・プールのサイズを変えることも、バッファを定義しな
いこともできます。それぞれのアプリケーション要件に従って、各インスタンスをチューニ
ングします。
複数バッファ・プールの使用方法
オブジェクトのデフォルト・バッファ・プールを定義するには、STORAGE 句の BUFFER_
POOL キーワードを使用します。この句は、CREATE TABLE および ALTER TABLE、
CLUSTER、および INDEX の各 SQL 文に有効です。バッファ・プールを指定すると、そのオ
ブジェクトに対して読み込まれたブロックは、すべてそのプールに配置されます。
バッファ・プールがパーティション表または索引に対して定義されている場合、オブジェク
トの各パーティションは、特定のバッファ・プールで上書きされないかぎり、表または索引
定義からバッファ・プールを継承します。
オブジェクトのバッファ・プールが ALTER 文を使用して変更された場合、変更されたセグ
メントのブロックを現在格納しているすべてのバッファは、ALTER 文を発行する前にあった
バッファ・プールに残ります。新たにロードされたブロック、および除去されて再ロードさ
れたブロックは、新しいバッファ・プールに入ります。
関連項目 : STORAGE 句での BUFFER_POOL の指定については、
『Oracle
Database SQL リファレンス』を参照してください。
7-16　Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
V$DB_CACHE_ADVICE 内のバッファ・プール・データ
V$DB_CACHE_ADVICE を使用すると、インスタンス上に構成されたすべてのプールをサイ
ズ設定できます。初期キャッシュ・サイズを見積もり、代表的なワークロードを実行し、次
に使用する必要のあるプールの V$DB_CACHE_ADVICE ビューを単純に問い合せます。
たとえば、KEEP プールからデータを問い合せるには、次のようにします。
SELECT SIZE_FOR_ESTIMATE, BUFFERS_FOR_ESTIMATE, ESTD_PHYSICAL_READ_FACTOR, ESTD_PHYSICAL_READS
FROM V$DB_CACHE_ADVICE
WHERE NAME
= 'KEEP'
AND BLOCK_SIZE
= (SELECT VALUE FROM V$PARAMETER WHERE NAME = 'db_block_size')
AND ADVICE_STATUS = 'ON';
バッファ・プール・ヒット率
V$SYSSTAT のデータは、すべてのバッファ・プールに対する論理読込みと物理読込みを 1
つの統計セットとして表します。バッファ・プールのヒット率を個々に決定するには、
V$BUFFER_POOL_STATISTICS ビューを問い合せます。このビューは、論理読込みと論理
書込みの回数に関するプールごとの統計をメンテナンスします。
バッファ・プール・ヒット率は、次の計算式を使用して決定できます。
1 - (physical_reads/(db_block_gets + consistent_gets))
次の問合せを使用して比率を計算できます。
SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio"
FROM V$BUFFER_POOL_STATISTICS;
関連項目 : V$BUFFER_POOL_STATISTICS ビューの詳細は、
『Oracle
Database リファレンス』を参照してください。
メモリーの構成と使用方法
7-17
バッファ・キャッシュの構成と使用方法
プール内に多くのバッファを持つセグメントの判断
V$BH ビューは、SGA 内に現在常駐するすべてのブロックのデータ・オブジェクト ID を示
します。プール内にバッファを多く持つセグメントを判断するには、この項で説明する 2 つ
の方法のいずれかを使用します。すべてのセグメントのバッファ・キャッシュ使用パターン
を確認する（方法 1）か、特定のセグメントの使用パターンを調べます（方法 2）。
方法 1
次の問合せでは、ある時点でバッファ・キャッシュ内に常駐するすべてのセグメントのブ
ロック数をカウントします。バッファ・キャッシュ・サイズによっては、このカウントに多
数のソート領域を必要とする可能性があります。
COLUMN OBJECT_NAME FORMAT A40
COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999
SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS
FROM DBA_OBJECTS o, V$BH bh
WHERE o.DATA_OBJECT_ID = bh.OBJD
AND o.OWNER
!= 'SYS'
GROUP BY o.OBJECT_NAME
ORDER BY COUNT(*);
OBJECT_NAME
NUMBER_OF_BLOCKS
---------------------------------------- ---------------OA_PREF_UNIQ_KEY
1
SYS_C002651
1
..
DS_PERSON
78
OM_EXT_HEADER
701
OM_SHELL
1,765
OM_HEADER
5,826
OM_INSTANCE
12,644
方法 2
次の手順に従って、ある時点で個々のオブジェクトによって使用されるキャッシュの割合を
決定してください。
1.
次の問合せを入力して、セグメントの Oracle 内部オブジェクトの数を検索します。
SELECT DATA_OBJECT_ID, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE OBJECT_NAME = UPPER('segment_name');
2 つのオブジェクトが同じ名前を持つことがあるため（異なる型のオブジェクトの場
合）
、OBJECT_TYPE 列を使用して目的のオブジェクトを識別します。
7-18　Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
2.
SEGMENT_NAME に対するバッファ・キャッシュ内のバッファ数を検索します。
SELECT COUNT(*) BUFFERS
FROM V$BH
WHERE OBJD = data_object_id_value;
data_object_id_value が手順 1 からの場合。
3.
インスタンス内にあるバッファ数を検索します。
SELECT NAME, BLOCK_SIZE, SUM(BUFFERS)
FROM V$BUFFER_POOL
GROUP BY NAME, BLOCK_SIZE
HAVING SUM(BUFFERS) > 0;
4.
バッファの総数に対するバッファの比率を計算し、現在 SEGMENT_NAME で使用され
ているキャッシュの割合を取得します。
% cache used by segment_name = [buffers(Step2)/total buffers(Step3)]
注意 : この手法は、1 つのセグメントに対してのみ有効です。パーティ
ション・オブジェクトについては、パーティションごとに問合せを実行す
る必要があります。
KEEP プール
アプリケーションに頻繁に参照されるセグメントがある場合は、KEEP バッファ・プールと
呼ばれる個別のキャッシュにそれらのセグメントのブロックをキャッシュします。メモリー
は、DB_KEEP_CACHE_SIZE パラメータを必要なサイズに設定することで KEEP バッファ・
プールに割り当てられます。KEEP プールのメモリーは、デフォルト・プールのサブセット
ではありません。保持できる一般的なセグメントは、頻繁に使用される小さい参照表です。
アプリケーション開発者と DBA は、どの表が候補かを判断できます。
7-18 ページの「プール内に多くのバッファを持つセグメントの判断」で説明するように、
V$BH を問い合せて、候補表からブロック数をチェックできます。
注意 :
NOCACHE 句は、KEEP キャッシュ内の表に影響を与えません。
KEEP バッファ・プールの目的は、メモリー内にオブジェクトを保存して、I/O 操作を避け
ることにあります。したがって、KEEP バッファ・プールのサイズは、バッファ・キャッ
シュに保持するオブジェクトによって異なります。KEEP バッファ・プールのおおよそのサ
イズは、このプールに割り当てられるすべてのオブジェクトで使用されるブロックを加算す
ることで計算できます。セグメントに関する情報を収集する場合、DBA_TABLES.BLOCKS
と DBA_TABLES.EMPTY_BLOCKS を問い合せて使用されるブロック数を判断できます。
メモリーの構成と使用方法
7-19
バッファ・キャッシュの構成と使用方法
ヒット率を計算するには、前述の問合せを使用してシステム・パフォーマンスの 2 つのス
ナップショットを時間をおいて取ります。物理読込み（physical reads）、ブロック取得
（block gets）および一貫取得（consistent gets）について、古い値から新しい値を
引いて、これらの結果を使用してヒット率を計算します。
100% のバッファ・プール・ヒット率が最適とは限りません。KEEP バッファ・プールのサイ
ズを減らしても、十分に高いヒット率が維持されることがよくあります。KEEP バッファ・
プールから除去されたブロックは、別のバッファ・プールに割り当ててください。
注意 : オブジェクトのサイズが大きくなった場合に、KEEP バッファ・
プールに入りきらなくなることがあります。この場合、キャッシュからブ
ロックが失われ始めます。
各オブジェクトをメモリー内に保持するとトレードオフが発生します。頻繁にアクセスされ
るブロックをキャッシュに保持することは有効ですが、頻繁に使用しないブロックを保持す
ると、よりアクティブな他のブロックのためのスペースが減ることになります。
RECYCLE プール
メモリーに残さないセグメントに属するブロック用の RECYCLE バッファ・プールを構成で
きます。RECYCLE プールは、ほとんどスキャンされないか頻繁に参照されないセグメント
に適しています。アプリケーションがラージ・オブジェクトのブロックをランダム方式でア
クセスする場合は、バッファ・プールに格納されているブロックが除去される前に再利用で
きる可能性は（使用可能物理メモリーの量の制約により）ほとんどありません。これはバッ
ファ・プールのサイズに関係なくあてはまります。したがって、そのオブジェクトのブロッ
クはキャッシュしないでください。これらのキャッシュ・バッファは、他のオブジェクトに
割り当てることができます。
メモリーは、DB_RECYCLE_CACHE_SIZE パラメータを必要なサイズに設定することで
RECYCLE バッファ・プールに割り当てられます。この RECYCLE バッファ・プールのメモ
リーは、デフォルト・プールのサブセットではありません。
あまり早くメモリーからブロックを破棄しないでください。バッファ・プールが小さすぎる
と、トランザクションまたは SQL 文が実行を完了する前に、ブロックがキャッシュから除
外されてしまう可能性があります。たとえば、アプリケーションが表から値を選択し、その
値を使用してデータを処理し、レコードを更新する場合があります。SELECT 文の後でブ
ロックがキャッシュから削除された場合は、更新を実行するために再度ディスクから読み込
む必要があります。ブロックは、ユーザー・トランザクションの所要時間中は保存される必
要があります。
7-20　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
共有プールとラージ・プールの構成および使用方法
異なるタイプのデータをキャッシュするには、共有プールを使用します。キャッシュされた
データには、PL/SQL ブロックおよび SQL 文のテキストおよび実行可能フォーム、ディク
ショナリ・キャッシュ・データおよびその他のデータが含まれています。
共有プールを適切な大きさにして使用すると、次の 4 つの方法でリソース使用量を低減でき
ます。
1.
SQL 文がすでに共有プールに存在する場合は解析オーバーヘッドをなくせます。このた
め、ホスト上の CPU リソースとエンド・ユーザーの経過時間が節約されます。
2.
リソース使用のラッチングが大幅に減少して、拡張性がさらに増大します。
3.
すべてのアプリケーションが SQL 文およびディクショナリ・リソースの同一プールを
使用するので、共有プール・メモリーの必要量が低減されます。
4.
共有プールのディクショナリ要素はディスク・アクセスが不要なので、I/O リソースが
節約されます。
この項では、次の項目について説明します。
■
共有プールの概念
■
共有プールの効果的な使用方法
■
共有プールのサイズ設定
■
共有プール統計の解釈
■
ラージ・プールの使用
■
CURSOR_SPACE_FOR_TIME の使用
■
セッション・カーソルのキャッシュ
■
予約プールの構成
■
除去防止のためのラージ・オブジェクトの保存
■
既存のアプリケーション用の CURSOR_SHARING
■
接続の維持
メモリーの構成と使用方法
7-21
共有プールとラージ・プールの構成および使用方法
共有プールの概念
共有プールの主なコンポーネントは、ライブラリ・キャッシュとディクショナリ・キャッ
シュです。ライブラリ・キャッシュは、最近参照された SQL と PL/SQL コードの実行可能
な（解析またはコンパイルされた）形式を格納します。ディクショナリ・キャッシュは、
データ・ディクショナリから参照されたデータを格納します。ライブラリ・キャッシュや
ディクショナリ・キャッシュなどの共有プール内のキャッシュの多くは、必要に応じてサイ
ズを自動的に増減します。共有プールに空き領域がない場合は、新しいエントリを受け入れ
るために古いエントリがこれらのキャッシュから除去されます。
データ・ディクショナリ・キャッシュまたはライブラリ・キャッシュでのキャッシュ・ミス
は、バッファ・キャッシュでのミスよりも影響が大きくなります。このため、頻繁に使用さ
れるデータがキャッシュされるように共有プールをサイズ設定する必要があります。
共有サーバー、パラレル問合せ、Recovery Manager など、共有プールで大きいメモリーの
割当てを行う機能は多数あります。ラージ・プールと呼ばれる個別のメモリー領域を構成し
て、これらの機能で使用される SGA メモリーを区別することをお薦めします。
関連項目 : ラージ・プールの構成の詳細は、7-36 ページの「ラージ・
プールの使用」を参照してください。
共有プールからのメモリーの割当ては、チャンクで行われます。このため、1 つの連続領域
を必要とせずにラージ・オブジェクト（5k より多い）をキャッシュにロードできるので、フ
ラグメント化のために十分な連続メモリーが不足する可能性が減ります。
Java、PL/SQL または SQL の各カーソルが、まれに、5k より大きい共有プールから割当て
を行う場合があります。このような割当てを最も効率よく行うために、Oracle では、少量の
共有プールを区別しています。このメモリーは、共有プールに十分な領域がない場合に使用
します。共有プールの区別された領域は予約プールと呼ばれます。
関連項目 : 共有プールの予約領域の詳細は、7-42 ページの「予約プール
の構成」を参照してください。
ディクショナリ・キャッシュの概念
データ・ディクショナリ・キャッシュに格納されている情報には、ユーザー名、セグメント
情報、プロファイル・データ、表領域情報および順序番号が含まれています。また、ディク
ショナリ・キャッシュはスキーマ・オブジェクトを説明する情報すなわちメタデータも格納
します。メタデータが使用されるのは、SQL カーソルの解析時か PL/SQL プログラムのコ
ンパイル時です。
7-22　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
ライブラリ・キャッシュの概念
ライブラリ・キャッシュは、SQL カーソル、PL/SQL プログラムおよび Java クラスの実行
可能な形式を保持します。この項では、チューニングを中心に説明します。チューニングは
カーソル、PL/SQL プログラムおよび Java クラスに関連するためです。これらをまとめて
アプリケーション・コードと呼びます。
アプリケーション・コードを実行するとき、既存のコードが以前に実行されており、共有で
きる場合は、そのコードを再利用しようとします。解析された文の表現がライブラリ・
キャッシュ内に存在し、共有できる場合は、既存のコードを再利用します。これは、ソフト
解析またはライブラリ・キャッシュ・ヒットと呼ばれています。既存のコードを使用できな
い場合は、アプリケーション・コードの新しい実行可能バージョンを作成する必要がありま
す。これは、ハード解析またはライブラリ・キャッシュ・ミスと呼ばれています。SQL 文と
PL/SQL 文を共有できる場合の詳細は、7-23 ページの「SQL 共有基準」を参照してくださ
い。
ライブラリ・キャッシュ・ミスは、SQL 文を処理するときの解析ステップまたは実行ステッ
プのいずれかで発生します。アプリケーションが SQL 文の解析コールを行うとき、解析さ
れた文の表現がライブラリ・キャッシュにまだ存在しない場合、Oracle はその文を解析し、
共有プールに解析されたフォームを格納します。これはハード解析です。可能な場合は、す
べての共有可能な SQL 文が共有プール内にあることを確認して、解析コールのライブラリ・
キャッシュ・ミスを低減できます。
アプリケーションが SQL 文に対して実行コールを作成し、すでに作成された SQL 文の実行
可能な部分が別の文のための場所を作成するためにライブラリ・キャッシュから除去（すな
わち、割当て解除）された場合、Oracle はその文を暗黙に再解析し、新しい共有 SQL 領域
を作成し、実行します。この場合も、ハード解析が発生します。通常は、ライブラリ・
キャッシュに割り当てるメモリーを増やすことによって実行コールのライブラリ・キャッ
シュ・ミスを低減できます。
ハード解析を実行するには、ソフト解析の実行時より多くのリソースを使用します。ソフト
解析に使用するリソースには、CPU およびライブラリ・キャッシュ・ラッチ取得が含まれ
ます。ハード解析に必要なリソースには、追加の CPU、ライブラリ・キャッシュ・ラッチ
取得および共有プール・ラッチ取得が含まれます。ハード解析およびソフト解析については、
2-17 ページの「SQL の実行効率」を参照してください。
SQL 共有基準
Oracle は、発行される SQL 文または PL/SQL ブロックが共有プールに現在存在する別の文
と同じかどうかを自動的に判断します。
比較のために、次のステップが実行されます。
1.
発行された文のテキストは、共有プール内の既存の文と比較されます。
2.
文のテキストがハッシュされます。一致するハッシュ値がない場合、SQL 文は共有プー
ル内に現在存在せず、ハード解析が実行されます。
メモリーの構成と使用方法
7-23
共有プールとラージ・プールの構成および使用方法
3.
共有プール内の既存の SQL 文に一致するハッシュ値がある場合は、一致した文のテキ
ストが、ハッシュされた文のテキストと比較され、それらが同一であるかどうかが確認
されます。SQL 文や PL/SQL ブロックのテキストは、空白、大文字小文字の区別、コ
メントも含め、完全に同一である必要があります。たとえば、次の文は同じ共有 SQL
領域を使用できません。
SELECT * FROM employees;
SELECT * FROM Employees;
SELECT * FROM employees;
通常は、リテラルのみ異なる SQL 文は同じ共有 SQL 領域を使用できません。たとえ
ば、次の SQL 文は同じ SQL 領域に変換されません。
SELECT count(1) FROM employees WHERE manager_id = 121;
SELECT count(1) FROM employees WHERE manager_id = 247;
唯一の例外は、CURSOR_SHARING パラメータが SIMILAR または FORCE に設定されて
いる場合です。CURSOR_SHARING パラメータが、SIMILAR または FORCE に設定され
ている場合、類似の文は SQL 領域を共有できます。CURSOR_SHARING を使用する場合
のコストと効果については、この項の後半で説明します。
関連項目 : CURSOR_SHARING パラメータの詳細は、『Oracle Database リ
ファレンス』を参照してください。
4.
発行された文で参照されたオブジェクトは、共有プール内のすべての既存の文の参照済
オブジェクトと比較され、それらのオブジェクトが同一であるかどうかが確認されま
す。
SQL 文や PL/SQL ブロック内でスキーマ・オブジェクトを参照する際には、同じス
キーマ内の同じオブジェクトである必要があります。たとえば、2 人のユーザーが次の
SQL 文を発行するとします。
SELECT * FROM employees;
各ユーザーに独自の employees 表がある場合、文はユーザーごとに異なる表を参照す
るので、この文は同一とみなされません。
5.
SQL 文の中のバインド変数は、名前、データ型および長さで一致している必要がありま
す。
たとえば、次の文で同じ共有 SQL 領域を使用できないのは、バインド変数名が異なる
ためです。
SELECT * FROM employees WHERE department_id = :department_id;
SELECT * FROM employees WHERE department_id = :dept_id;
7-24　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
多くの Oracle 製品（Oracle Forms やプリコンパイラなど）は、文をデータベースに渡
す前に SQL を変換します。首尾一貫した SQL 文の集合が生成されるように、文字は大
文字に統一して変換され、空白は圧縮され、バインド変数は改名されます。
6.
セッションの環境は同一である必要があります。たとえば、SQL 文は、同一の最適化目
標を使用して最適化する必要があります。
共有プールの効果的な使用方法
共有プールの重要な目的は、SQL 文と PL/SQL 文の実行可能バージョンをキャッシュする
ことです。これにより、ハード解析にリソースを使用することなく、同じ SQL または
PL/SQL コードを複数回実行できるので、CPU、メモリーおよびラッチの使用が大幅に減少
します。
また、共有プールは、データ・ウェアハウス・アプリケーションで非共有 SQL をサポート
できます。これらのアプリケーションでは、同時実行性が低くリソース使用率の高い SQL
文が実行されます。このような状況では、リテラル値を持つ非共有 SQL を使用することを
お薦めします。バインド変数ではなくリテラル値を使用すると、オプティマイザは優れた列
選択性の見積りを行えるので、最適なデータ・アクセス・プランを提供します。
関連項目 : 『Oracle データ・ウェアハウス・ガイド』
OLTP システムでは、共有プールと関連リソースを効率的に使用できるようにする方法が多
数あります。次の項目についてアプリケーション開発者と検討し、共有プールが効果的に使
用されるようにする方法を決定します。
■
共有カーソル
■
単一のユーザーのログインおよび修飾表の参照
■
PL/SQL の使用方法
■
DDL の実行の回避
■
キャッシュ順序番号
■
カーソルのアクセスおよび管理
同時実行性の高い OLTP システムで共有プールを効率よく使用すると、解析関連アプリケー
ションの拡張性の問題が発生する確率が大幅に低減します。
メモリーの構成と使用方法
7-25
共有プールとラージ・プールの構成および使用方法
共有カーソル
同じアプリケーションを実行する複数のユーザーのために共有 SQL を再利用すると、ハー
ド解析が回避されます。ソフト解析は、共有プール・ラッチやライブラリ・キャッシュ・
ラッチなどのリソース使用量を大幅に減少させます。カーソルを共有するには、次のことを
行います。
■
可能な場合、SQL 文ではリテラルではなくバインド変数を使用します。たとえば、次の
2 つの文は字面が完全には一致しないので、同じ共有領域は使用できません。
SELECT employee_id FROM employees WHERE department_id = 10;
SELECT employee_id FROM employees WHERE department_id = 20;
リテラルをバインド変数と置換すると、2 回実行可能な SQL 文が 1 つのみ生成されま
す。
SELECT employee_id FROM employees WHERE department_id = :dept_id;
注意 : バインド変数を使用するためにコードをリライトすることが実際
的ではない既存のアプリケーションについては、CURSOR_SHARING 初期
化パラメータを使用してハード解析のオーバーヘッドをある程度回避でき
ます。詳細は、7-45 ページの「既存のアプリケーション用の CURSOR_
SHARING」を参照してください。
■
■
■
■
多数のユーザーが動的な非共有の SQL 文を発行するようなアプリケーションを設計しな
いようにしてください。通常、大半のユーザーが必要とするデータの大部分は、事前に
設定されている問合せを使用して満たすことができます。そのような機能が必要な場合
は、動的 SQL を使用します。
アプリケーションのユーザーが最適化アプローチと目標を各セッションに対して変更し
ないことを確認してください。
アプリケーション開発者に対し、次のポリシーを設定します。
–
SQL 文と PL/SQL ブロックに対して、バインド変数のネーミング規則と、スペー
シング規定を標準化します。
–
可能な場合、ストアド・プロシージャを使用することを考慮してください。そうす
れば、同じストアド・プロシージャを発行している複数のユーザーが、同じ共有
PL/SQL 領域を自動的に使用します。ストアド・プロシージャは解析済フォームに
格納されているため、ストアド・プロシージャを使用すると実行時間の解析が減少
します。
同一であっても共有されていない SQL 文について V$SQL_SHARED_CURSOR を問い合せ
ることで、カーソルが共有されない理由を判断できます。この理由には、オプティマイ
ザの設定とバインド変数の不整合などがあります。
7-26　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
単一のユーザーのログインおよび修飾表の参照
ユーザーが独自のユーザー ID でデータベースにログインするような大きい OLTP システム
では、パブリック・シノニムを使用するのではなく、明示的にセグメントの所有者を修飾す
ると有益です。これにより、ディクショナリ・キャッシュ内のエントリ数が大幅に削減され
ます。たとえば、次のようにします。
SELECT employee_id FROM hr.employees WHERE department_id = :dept_id;
表名を認定する別の方法として、個々のユーザー ID ではなく単一のユーザー ID でデータ
ベースに接続します。ユーザー・レベルの検証は、中間層でローカルに行われます。個別の
ユーザー ID の数を削減した場合も、ディクショナリ・キャッシュ上の負荷は低減します。
PL/SQL の使用方法
ストアド PL/SQL パッケージを使用すると、多数のユーザーが個々にユーザー・サインオン
とパブリック・シノニムを持つシステムにおける、拡張性の問題を克服できます。これは、
パッケージがコール元ではなく所有者として実行されるため、ディクショナリ・キャッシュ
の負荷がかなり削減されるためです。
注意 : 拡張性の問題を克服するには、定義者権限パッケージの使用をお
薦めします。ディクショナリ・キャッシュの負荷軽減の利点は、実行者権
限パッケージの場合ほど顕著ではありません。
DDL の実行の回避
ピーク時間に使用率の高いセグメントで DDL 操作を実行しないようにします。そのような
セグメントで DDL を実行すると、多くの場合、依存 SQL は無効にされるため、以降の実行
で再度解析されることになります。
キャッシュ順序番号
頻繁に更新される順序番号に十分なキャッシュ領域を割り当てると、ディクショナリ・
キャッシュ・ロックの回数が大幅に減るため、拡張性が向上します。CREATE SEQUENCE 文
または ALTER SEQUENCE 文の CACHE キーワードを使用して、各順序のキャッシュ済エント
リ数を構成できます。
関連項目 : CREATE SEQUENCE 文および ALTER SEQUENCE 文の詳細は、
『Oracle Database SQL リファレンス』を参照してください。
メモリーの構成と使用方法
7-27
共有プールとラージ・プールの構成および使用方法
カーソルのアクセスおよび管理
使用している Oracle アプリケーション・ツールにより異なりますが、アプリケーションが
解析コールを実行する頻度を制御できます。
アプリケーションが、カーソルをクローズする、または新しい SQL 文に既存のカーソルを
再利用する頻度は、セッションで使用されるメモリー量と、時には、そのセッションで実行
される解析の量にも影響を与えます。
（異なる SQL 文の）カーソルをクローズまたは再利用するアプリケーションは、カーソルを
オープンした状態を保つアプリケーションほどセッション・メモリーを必要としません。逆
に、そのようなアプリケーションでは、解析コールをより多く実行し、そのための追加の
CPU および Oracle リソースを使用する可能性があります。
頻繁に実行されない SQL 文に関連するカーソルをクローズしたり、他の文に再利用できる
のは、その文を再実行（および再解析）する可能性が低いからです。
再実行される SQL 文を含むカーソルがクローズまたは別の文に再利用される場合は、追加
の解析コールが必要になります。カーソルがオープンされた状態であれば、解析コールを発
行するためのオーバーヘッドを発生させずに、カーソルを再利用できます。
カーソルの管理を行う方法は、アプリケーション開発ツールにより異なります。次の項で
は、いくつかのツールで使用される方法を紹介します。
関連項目 :
■
■
各ツールの詳細は、ツール固有のマニュアルを参照してください。
カーソル共有 SQL の詳細は、
『Oracle Database 概要』を参照してくだ
さい。
OCI による解析コールの低減 Oracle Call Interface（OCI）を使用する場合、再実行するカー
ソルはクローズおよび再オープンしないでください。そのかわりに、カーソルをオープンし
たままにし、実行前にリテラル値をバインド変数に変更してください。
既存の SQL 文が今後再実行される場合は、新しい SQL 文に文ハンドルを再利用しないよう
にしてください。
Oracle プリコンパイラによる解析コールの低減 Oracle プリコンパイラを使用する場合、プ
リコンパイラ句を設定して、いつカーソルをクローズするかを制御できます。Oracle モード
では、プリコンパイラ句は次のとおりです。
■
HOLD_CURSOR = YES
■
RELEASE_CURSOR = NO
■
MAXOPENCURSORS = 希望の値
ANSI モードでは、HOLD_CURSOR と RELEASE_CURSOR の値が切り替えられますが、これ
はお薦めしません。
7-28　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
プリコンパイラ句は、プリコンパイラ・コマンドライン上またはプリコンパイラ・プログラ
ム内で指定できます。これらの句により、様々な方法で、プログラムの実行中にカーソルを
管理できます。
関連項目 : これらの句の詳細は、使用している言語のプリコンパイラ・
マニュアルを参照してください。
SQLJ による解析コールの低減 文を用意し、バインド変数に新しい値を使用して文を再実行
します。カーソルは、セッション中はオープンのままです。
JDBC による解析コールの低減 新しいリテラル値は、再実行のためにカーソルにバインドで
きるので、カーソルを再実行する場合は、カーソルをクローズしないでください。別の方法
として、JDBC は setStmtCacheSize() メソッドを使用して JDBC クライアント内に SQL
文キャッシュを提供しています。このメソッドを使用して、JDBC は JDBC プログラムに対
してローカルな SQL 文キャッシュを作成します。
関連項目 : JDBC SQL 文キャッシュの使用方法の詳細は、
『Oracle
Database JDBC 開発者ガイドおよびリファレンス』を参照してください。
Oracle Forms による解析コールの低減 Oracle Forms で、カーソル管理の一部を管理できま
す。トリガー・レベル、フォーム・レベルまたは実行時のいずれかで、この管理を実施でき
ます。
共有プールのサイズ設定
新規にインスタンスを構成する場合、作成する共有プール・キャッシュの適切なサイズを知
ることはできません。通常、DBA はキャッシュ・サイズの最初の見積りを行い、次にイン
スタンス上で代表的なワークロードを実行し、関連する統計を調べて、キャッシュが過小構
成か過大構成かを調べます。
OLTP アプリケーションの多くでは、共有プール・サイズはアプリケーション・パフォーマ
ンスにとって重要な要因です。意思決定支援システム（DSS）のような、ごく少数の不連続
な SQL 文を発行するアプリケーションでは、共有プールのサイズはそれほど重要ではあり
ません。
共有プールが小さすぎると、使用可能領域の限度を補うために、追加リソースを使用するこ
とになります。このため、CPU とラッチングのリソースが使用され、競合が発生します。
共有プールは、頻繁にアクセスされるオブジェクトをキャッシュするためにちょうど十分な
大きさであることが最適です。共有プールに大量の空きメモリーを持つことは、メモリーの
無駄になります。データベースの稼働後に統計を調べる際、DBA はこの点についてワーク
ロード内に該当する箇所がないかチェックする必要があります。
メモリーの構成と使用方法
7-29
共有プールとラージ・プールの構成および使用方法
共有プール : ライブラリ・キャッシュの統計
共有プールをサイズ設定するときの目標は、メモリーを割り当てすぎずに、複数回実行され
る SQL 文がライブラリ・キャッシュにキャッシュされるようにすることです。
以前にキャッシュされ、すでに除去された SQL 文の再ロード（すなわち、再解析）の量の
統計は、V$LIBRARYCACHE ビューの RELOADS 列に示されます。効果的に SQL を再利用す
るアプリケーションでは、システムが最適な共有プール・サイズを持ち、RELOADS 統計が 0
（ゼロ）に近い値を示します。
V$LIBRARYCACHE ビューの INVALIDATIONS 列は、ライブラリ・キャッシュのデータが無
効にされ、再解析された回数を示しています。INVALIDATIONS は 0（ゼロ）に近い値であ
る必要があります。つまり、共有できた可能性のある SQL 文が、ある操作（たとえば、
DDL）により無効にされたことを意味します。この統計は、ピーク・ロード中の OLTP シス
テム上では、0（ゼロ）に近い値となります。
別の重要な統計は、ピーク時の共有プール内の空きメモリー量です。空きメモリー量は、共
有プールの空きメモリーを参照する V$SGASTAT から問い合せることができます。空きメモ
リーは、システム上に再ロードを発生させない程度で、できるだけ小さい値である必要があ
ります。
最終的には、ライブラリ・キャッシュの全般的なインジケータは、ライブラリ・キャッ
シュ・ヒット率で表されます。この値は、この項で説明されているその他の統計、および
ハード解析率や、共有プールまたはライブラリ・キャッシュのラッチ競合があるかどうかな
どのその他のデータとともに考慮する必要があります
これらの統計の詳細は、次の項で説明します。
V$LIBRARYCACHE
動的パフォーマンス・ビュー V$LIBRARYCACHE を調べることで、ライブラリ・キャッシュ
のアクティビティを反映する統計を監視できます。これらの統計は、最新のインスタンス起
動以降のライブラリ・キャッシュのアクティビティを反映しています。
このビューの各行には、ライブラリ・キャッシュ内に保持される項目の 1 つに対応する統計
が収録されます。各行ごとに記述される項目は、NAMESPACE 列の値によって識別されます。
次の NAMESPACE 値を持つ行は、SQL 文と PL/SQL ブロックのライブラリ・キャッシュのア
クティビティを反映します。
■
SQL AREA
■
TABLE/PROCEDURE
■
BODY
■
TRIGGER
他の NAMESPACE 値を持つ行は、Oracle が依存関係のメンテナンスのために使用するオブ
ジェクト定義に対するライブラリ・キャッシュのアクティビティを反映します。
7-30　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
関連項目 : 動的パフォーマンス・ビュー V$LIBRARYCACHE の詳細は、
『Oracle Database リファレンス』を参照してください。
各 NAMESPACE を個々に調べるには、次の問合せを使用します。
SELECT NAMESPACE, PINS, PINHITS, RELOADS, INVALIDATIONS
FROM V$LIBRARYCACHE
ORDER BY NAMESPACE;
この問合せの出力例を次に示します。
NAMESPACE
PINS
PINHITS
RELOADS INVALIDATIONS
--------------- ---------- ---------- ---------- ------------BODY
8870
8819
0
0
CLUSTER
393
380
0
0
INDEX
29
0
0
0
OBJECT
0
0
0
0
PIPE
55265
55263
0
0
SQL AREA
21536413
21520516
11204
2
TABLE/PROCEDURE
10775684
10774401
0
0
TRIGGER
1852
1844
0
0
ライブラリ・キャッシュ・ヒット率を計算するには、次の計算式を使用します。
Library Cache Hit Ratio = sum(pinhits) / sum(pins)
ライブラリ・キャッシュ・ヒット率の計算式を使用すると、キャッシュ・ヒット率は次のよ
うになります。
SUM(PINHITS)/SUM(PINS)
---------------------.999466248
注意 : これらの問合せでは、ある時間間隔で収集された統計ではなく、
インスタンス起動時からのデータを戻します。時間間隔の統計の方が、よ
り的確に問題を特定できます。
関連項目 : ある時間間隔の情報を収集する方法の詳細は、第 6 章「自動
パフォーマンス診断」を参照してください。
メモリーの構成と使用方法
7-31
共有プールとラージ・プールの構成および使用方法
戻されたデータを調べると、次のことがわかります。
■
■
■
■
SQL AREA の NAMESPACE では、21,536,413 回の実行がありました。
11,204 回の実行でライブラリ・キャッシュ・ミスが発生したため、文またはブロックを
暗黙的に再解析するか、またはライブラリ・キャッシュから除去されている場合は、オ
ブジェクト定義を再ロード（すなわち、RELOAD）する必要があります。
SQL 文は 2 回無効化されたため、再度ライブラリ・キャッシュ・ミスが発生しました。
ヒット率は約 99.94% です。これは、実行の 0.06% のみが再解析されたことを意味しま
す。
共有プールの空きメモリーの容量は、V$SGASTAT でレポートされます。次の問合せを使用
してこのビューの現在の値についてレポートを作成します。
SELECT * FROM V$SGASTAT
WHERE NAME = 'free memory'
AND POOL = 'shared pool';
この出力例を次に示します。
POOL
NAME
BYTES
----------- -------------------------- ---------shared pool free memory
4928280
共有プール内に使用可能な空きメモリーが常にある場合、プールのサイズを増やしても、効
果はほとんど（または、まったく）ありません。また、共有プールがいっぱいというだけで
は、問題があるとはいえません。これは、適切に構成されたシステムであることを示してい
る場合があります。
共有プールのアドバイザ統計
ライブラリ・キャッシュに使用可能なメモリー量は、Oracle インスタンスの解析率に大きな
影響を与えます。共有プールのアドバイザ統計から、データベース管理者はライブラリ・
キャッシュ・メモリーについての情報を得ることができ、共有プールのサイズ変更が共有
プール内のオブジェクトの除去にどのように影響するかを予測できます。
共有プールのアドバイザ統計では、共有プール・メモリーにおけるライブラリ・キャッシュ
の使用率が追跡され、異なるサイズの共有プールでライブラリ・キャッシュがどのように動
作するかが予測されます。2 つの固定ビューにより、ライブラリ・キャッシュのメモリー使
用量、現在の確保量、共有プールの LRU リスト上にある量、さらに共有プールのサイズ変
更により損失または獲得できる時間を判別する情報が提供されます。
共有プールのアドバイザ統計では、次のビューが使用できます。共有プール・アドバイザを
オンにすると、これらのビューにはあらゆるデータが表示されます。共有プール・アドバイ
ザをオフにすると、それらの統計がリセットされます。
7-32　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
V$SHARED_POOL_ADVICE このビューには、共有プールのサイズを変更した場合の、見積り解
析時間に関する情報が表示されます。サイズの範囲は、同じ時間間隔で、現在の共有プー
ル・サイズまたは確保されたライブラリ・キャッシュ・メモリー量の 10% のうち大きい方
の値から、現在の共有プール・サイズの 200% までです。時間間隔の値は、共有プールの現
在のサイズによって異なります。
V$LIBRARY_CACHE_MEMORY このビューには、別の NAMESPACE のライブラリ・キャッシュ
のメモリー・オブジェクトに割り当てられるメモリーに関する情報が表示されます。メモ
リー・オブジェクトとは、効率的な管理を行うためのメモリーの内部グループ化です。ライ
ブラリ・キャッシュ・オブジェクトは 1 つ以上のメモリー・オブジェクトで構成されます。
V$JAVA_POOL_ADVICE および V$JAVA_LIBRARY_CACHE_MEMORY これらのビューには、Java に
使用されるライブラリ・キャッシュ・メモリーについての情報を追跡し、Java プールのサイ
ズ変更が解析率に及ぼす影響を予測する、Java プール・アドバイザ統計が含まれます。
V$JAVA_POOL_ADVICE には、プールのサイズを変更した場合の、Java プールの見積り解析
時間に関する情報が表示されます。サイズの範囲は、同じ時間間隔で、現在の Java プール・
サイズまたは確保された Java ライブラリ・キャッシュ・メモリー量の 10% のうち大きい方
の値から、現在の Java プール・サイズの 200% までです。時間間隔の値は、Java プールの現
在のサイズによって異なります。
関連項目 : 動的パフォーマンス・ビュー V$SHARED_POOL_ADVICE、
V$LIBRARY_CACHE_MEMORY、V$JAVA_POOL_ADVICE および V$JAVA_
LIBRARY_CACHE_MEMORY の詳細は、『Oracle Database リファレンス』を
参照してください。
共有プール : ディクショナリ・キャッシュの統計
共有プールがライブラリ・キャッシュに対して適切にサイズ設定されている場合、その設定
はディクショナリ・キャッシュ・データに対しても適切であるのが普通です。
データ・ディクショナリ・キャッシュ・ミスは、いくつかの場合に予想されます。インスタ
ンス起動時は、データ・ディクショナリ・キャッシュにデータは含まれていません。した
がって、発行された SQL 文からキャッシュ・ミスが発生する可能性があります。キャッ
シュに読み込まれるデータが増えると、キャッシュ・ミスの可能性は減少します。最終的
に、データベースは、最も頻繁に使用されるディクショナリ・データがキャッシュ内に存在
する安定状態に到達します。この時点で、キャッシュ・ミスはほとんど発生しません。
V$ROWCACHE ビューの各行は、データ・ディクショナリ項目について単一のタイプの統計を
収録します。これらの統計は、直前のインスタンス起動以降のデータ・ディクショナリ・ア
クティビティを反映しています。データ・ディクショナリ・キャッシュの使用と有効性を反
映する V$ROWCACHE ビューの中の列を表 7-2 にリストします。
メモリーの構成と使用方法
7-33
共有プールとラージ・プールの構成および使用方法
表 7-2 V$ROWCACHE 列
列
説明
PARAMETER
特定のデータ・ディクショナリ項目を識別します。各行で、この列
の値は接頭辞 dc_ が付いた項目です。たとえば、ファイル記述の統
計を含む行では、この列の値は dc_files です。
GETS
対応する項目に関する情報への要求の総数を示します。たとえば、
ファイル記述の統計を含む行では、この列はファイル記述データへ
の要求の総数を持ちます。
GETMISSES
キャッシュで満たされなかったデータ要求で、I/O を必要とするも
のの個数を示します。
MODIFICATIONS
ディクショナリ・キャッシュ内のデータが更新された回数を示しま
す。
次の問合せによって、アプリケーションの実行中、ある期間にわたって V$ROWCACHE
ビューの統計を監視してください。導出された列 PCT_SUCC_GETS は、項目固有のヒット率
と考えることができます。
column parameter format a21
column pct_succ_gets format 999.9
column updates format 999,999,999
SELECT
,
,
,
,
FROM
WHERE
GROUP
parameter
sum(gets)
sum(getmisses)
100*sum(gets - getmisses) / sum(gets)
sum(modifications)
V$ROWCACHE
gets > 0
BY parameter;
pct_succ_gets
updates
この問合せの出力例を次に示します。
PARAMETER
SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS
UPDATES
--------------------- ---------- -------------- ------------- -----------dc_database_links
81
1
98.8
0
dc_free_extents
44876
20301
54.8
40,453
dc_global_oids
42
9
78.6
0
dc_histogram_defs
9419
651
93.1
0
dc_object_ids
29854
239
99.2
52
dc_objects
33600
590
98.2
53
dc_profiles
19001
1
100.0
0
dc_rollback_segments
47244
16
100.0
19
dc_segments
100467
19042
81.0
40,272
dc_sequence_grants
119
16
86.6
0
7-34　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
dc_sequences
dc_synonyms
dc_tablespace_quotas
dc_tablespaces
dc_used_extents
dc_user_grants
dc_usernames
dc_users
26973
6617
120
581248
51418
76082
216860
376895
16
168
7
10
20249
18
12
22
99.9
97.5
94.2
100.0
60.6
100.0
100.0
100.0
26,811
0
51
0
42,811
0
0
0
サンプル問合せが戻したデータを調べると、次のことがわかります。
■
■
使用済エクステント、空きエクステントおよびセグメントには、多数のミスと更新があ
ります。つまり、インスタンスに大量の動的な領域の拡張があったことを示していま
す。
取得成功率およびその統計と、実際の取得数との比較に基づくと、共有プールはディク
ショナリ・キャッシュ・データを適切に格納できる大きさがあります。
次の計算式を使用して、総合的ディクショナリ・キャッシュ・ヒット率も計算できますが、
すべてのキャッシュにわたるデータを合計すると、より細かいデータの粒度は失われます。
SELECT (SUM(GETS - GETMISSES - FIXED)) / SUM(GETS) "ROW CACHE" FROM V$ROWCACHE;
共有プール統計の解釈
共有プール統計は実行可能な調整方法を示します。この項ではそのうちのいくつかについて
説明します。
メモリー割当ての増加
共有プールのメモリー量を増やすと、ライブラリ・キャッシュとディクショナリ・キャッ
シュの両方で使用できるメモリー量が増えます。
ライブラリ・キャッシュへの追加のメモリー割当て 共有 SQL 領域がそれらの SQL 文を解析
した後にキャッシュ内に残るようにするには、V$LIBRARYCACHE.RELOADS 値が 0（ゼロ）
に近くなるまでライブラリ・キャッシュに利用できるメモリー量を増やします。ライブラ
リ・キャッシュに利用できるメモリーを増やすには、SHARED_POOL_SIZE 初期化パラメー
タの値を増やしてください。このパラメータの最大値はオペレーティング・システムによっ
て異なります。この処置によって、実行のための SQL 文と PL/SQL ブロックの暗黙的な再
解析が減少します。
共有 SQL 領域に利用可能な追加のメモリーを利用するために、セッションに対して許可さ
れるカーソル数を増やすこともあります。その場合は、初期化パラメータ OPEN_CURSORS
の値を増やします。
メモリーの構成と使用方法
7-35
共有プールとラージ・プールの構成および使用方法
データ・ディクショナリ・キャッシュへの追加のメモリーの割当て GETS と GETMISSES 列
を監視することによって、キャッシュ・アクティビティを調べてください。ディクショナ
リ・キャッシュが頻繁にアクセスされる場合、GETS の合計に対する GETMISSES の割合は、
アプリケーションによって異なりますが、10% あるいは 15% より低くしてください。
次のすべてに当てはまる場合は、キャッシュに利用できるメモリー量を増やすことを考慮し
てください。
■
■
アプリケーションは共有プールを効果的に使用している。7-25 ページの「共有プールの
効果的な使用方法」を参照してください。
システムは安定状態に達し、項目固有のヒット率が低く、ヒット率の低いキャッシュへ
の取得数が多い。
初期化パラメータ SHARED_POOL_SIZE の値を増やして、データ・ディクショナリ・キャッ
シュに利用できるメモリーを増やします。
メモリー割当ての減少
RELOADS が 0 に近く、共有プール内の空きメモリーが少ない場合、共有プールは、最も頻
繁にアクセスされるデータを保持できる十分な大きさがあります。
常に共有プールに多数の空きメモリーがある場合、このメモリーを他の場所に割り当てるた
めに共有プールのサイズを小さくしても、良好なパフォーマンスを維持できます。
共有プールを小さくするには、SHARED_POOL_SIZE パラメータの値を変更してキャッシュ
のサイズを小さくします。
ラージ・プールの使用
共有プールとは異なり、ラージ・プールには LRU リストがありません。Oracle は、ラー
ジ・プールからオブジェクトを除去しようとしません。
インスタンスが次のいずれかを使用する場合は、ラージ・プールの構成を考慮してくださ
い。
■
パラレル問合せ
パラレル問合せでは、共有プール・メモリーを使用してパラレル実行メッセージ・バッ
ファをキャッシュします。
関連項目 : パラレル問合せによるラージ・プールのサイズ設定の詳細は、
『Oracle データ・ウェアハウス・ガイド』を参照してください。
7-36　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
■
Recovery Manager
Recovery Manager は、共有プールを使用してバックアップおよびリストア操作時に
I/O バッファをキャッシュします。I/O サーバー・プロセスと、バックアップおよびリ
ストア操作では、Oracle は数百 KB 単位でバッファを割り当てます。
関連項目 : Recovery Manager を使用する場合のラージ・プールのサイズ
設定の詳細は、
『Oracle Database Recovery Manager リファレンス』を参
照してください。
■
共有サーバー
共有サーバー・アーキテクチャでは、各クライアント・プロセスのセッション・メモ
リーが共有プールに含まれています。
共有サーバー・アーキテクチャでのラージ・プールと共有プールの
チューニング
Oracle では共有サーバー・セッション・メモリーに共有プールからメモリーを割り当てるた
め、ライブラリ・キャッシュとディクショナリ・キャッシュに使用可能な共有プール・メモ
リーの量が減少します。別のプールからこのセッション・メモリーを割り当てると、Oracle
は、主に共有 SQL のキャッシングのために共有プールを使用できるので、共有 SQL キャッ
シュの減少によるパフォーマンス・オーバーヘッドは発生しません。
共有サーバー関連のユーザー・グローバル領域（UGA）の割当てには、共有プールではなく
ラージ・プールの使用をお薦めします。共有プールは、Oracle によって、共有 SQL や
PL/SQL プロシージャなど、他の目的のシステム・グローバル領域（SGA）メモリー用に割
り当てられるためです。共有プールのかわりにラージ・プールを使用すると、共有プールの
断片化も減少します。
ラージ・プールに共有サーバー関連の UGA を格納するには、初期化パラメータ LARGE_
POOL_SIZE に値を指定します。どのプール（共有プールまたはラージ・プール）にオブ
ジェクト用のメモリーが存在するかを確認するには、V$SGASTAT で列 POOL をチェックし
ます。ラージ・プールはデフォルトで構成されません。最小値は 300K です。ラージ・プー
ルを構成しないと、共有サーバー・ユーザー・セッション・メモリーに共有プールが使用さ
れます。
ラージ・プールの大きさは、同時にアクティブとなるセッションの数を基準に構成します。
各アプリケーションは、必要なセッション情報メモリー量がそれぞれ異なり、ラージ・プー
ルあるいは SGA の構成はメモリー要件を反映する必要があります。たとえば、アクティブ
な各セッションのセッション情報を格納するために共有サーバーが 200 ～ 300K を必要とす
ると仮定します。100 個のセッションが同時にアクティブになると予想される場合、30M の
ラージ・プールを構成するか、ラージ・プールを構成しない場合は、共有プールを増やして
ください。
メモリーの構成と使用方法
7-37
共有プールとラージ・プールの構成および使用方法
注意 : 共有サーバー・アーキテクチャを使用する場合、ラージ・プール
を構成した場合でも、Oracle によって各構成セッションに一定量のメモ
リー（約 10K）が共有プールから割り当てられます。CIRCUITS 初期化パ
ラメータは、データベースで許可される同時共有サーバー接続最大数を指
定します。
関連項目 :
■
■
ラージ・プールの詳細は、
『Oracle Database 概要』を参照してくださ
い。
初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照
してください。
共有サーバーの UGA 記憶域のための効果的な設定の判別 Oracle が使用する UGA の厳密な
容量は、各アプリケーションによって異なります。ラージ・プールまたは共有プールの効果
的な設定を判別するには、一般的なユーザーでの UGA の使用状況を観察して、その容量を
ユーザー・セッションの見積り数に乗算します。
共有サーバーの使用により共有メモリーの使用が増加するとしても、合計のメモリー使用量
は減少します。これは、プロセス数が減少するので、専用サーバー環境と比較した場合に共
有サーバーでは PGA メモリーの使用量が減るためです。
注意 : 共有サーバーを使用したソートのパフォーマンスを最高にするに
は、SORT_AREA_SIZE と SORT_AREA_RETAINED_SIZE を同じ値に設定
します。これによって、ソート結果をディスクに書き込むのではなくラー
ジ・プールに留めておきます。
V$SESSTAT ビューでのシステム統計のチェック Oracle では、セッションに使用された全メ
モリーの統計が収集され、動的パフォーマンス・ビュー V$SESSTAT に格納されます。表
7-3 はこれらの統計をリストしたものです。
表 7-3 メモリーを反映した V$SESSTAT 統計
統計
説明
session UGA memory
この統計の値は、セッションに割り当てられたメモリー容
量です（単位はバイト）。
Session UGA memory max
この統計の値は、セッションに割り当てたメモリー容量の
最大値です（単位はバイト）
。
7-38　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
値を検索するには、V$STATNAME を問い合せます。共有サーバーを使用している場合、次の
問合せを使用して、どの程度共有プールを大きくするか判断できます。アプリケーションの
実行中に、次の問合せを発行してください。
SELECT SUM(VALUE) || ' BYTES' "TOTAL MEMORY FOR ALL SESSIONS"
FROM V$SESSTAT, V$STATNAME
WHERE NAME = 'session uga memory'
AND V$SESSTAT.STATISTIC# = V$STATNAME.STATISTIC#;
SELECT SUM(VALUE) || ' BYTES' "TOTAL MAX MEM FOR ALL SESSIONS"
FROM V$SESSTAT, V$STATNAME
WHERE NAME = 'session uga memory max'
AND V$SESSTAT.STATISTIC# = V$STATNAME.STATISTIC#;
また、これらの問合せでは、動的パフォーマンス・ビュー V$STATNAME から選択して、
session memory と max session memory の内部識別子を取得します。次にこれらの問
合せの結果例を示します。
TOTAL MEMORY FOR ALL SESSIONS
----------------------------157125 BYTES
TOTAL MAX MEM FOR ALL SESSIONS
-----------------------------417381 BYTES
最初の問合せの結果は、現在、全セッションに割り当てられているメモリーは 157,125 バイ
トであることを示しています。この値は、セッションが Oracle に接続されている方法にそ
の位置が依存するメモリーの全体の容量です。セッションが専用サーバー・プロセスで接続
されている場合、このメモリーはユーザー・プロセスのメモリーの一部です。セッションが
共有サーバー・プロセスで接続されている場合、このメモリーは共有プールの一部です。
2 番目の問合せの結果は、全セッションのメモリーの最大サイズの合計が 417,381 バイトで
あることを示しています。2 番目の結果は、いくつかのセッションが最大の容量を割り当て
た後でメモリーを割当て解除したため、最初の結果よりも大きくなっています。
共有サーバー・アーキテクチャを使用している場合、これらの問合せの結果を使用してどの
程度共有プールを大きくするか判断できます。全セッションがほとんど同時にそれらの最大
割当てに到達しそうでないかぎり、2 番目の値よりも最初の値の方がよい見積りになります。
PRIVATE_SGA の設定による各ユーザー・セッションのメモリー使用量の制限 PRIVATE_SGA
リソース制限を設定して、各クライアント・セッションによる SGA のメモリー使用量を制
限できます。PRIVATE_SGA によって、1 セッションで SGA から使用されるメモリーのバイ
ト数が定義されます。ただし、ほとんどの DBA はユーザー単位での SGA 消費量の制限は行
わないため、このパラメータを使用することはほとんどありません。
メモリーの構成と使用方法
7-39
共有プールとラージ・プールの構成および使用方法
関連項目 : PRIVATE_SGA リソース制限の設定の詳細は、
『Oracle
Database SQL リファレンス』の「ALTER RESOURCE COST 文」を参照し
てください。
3 層の接続でのメモリー使用の低減 接続ユーザーが非常に多数の場合は、3 層の接続を実装
することでメモリー使用を低減できます。これはトランザクション処理（TP）モニター使用
の副産物であり、ロックやコミットされていない DML を複数のコールにわたって保持でき
ないため、純粋なトランザクション・モデルでしか実現できません。共有サーバー環境には
次の利点があります。
■
■
■
TP モニターに比べてアプリケーション設計の制限が大幅に少なくなります。
ユーザーがサーバーのプールを共有できるので、オペレーティング・システム・プロセ
ス数とコンテキストの切替えが大幅に減ります。
共有サーバー・モードでさらに多くの SGA が使用される場合でも総メモリー使用量が
大幅に減ります。
CURSOR_SPACE_FOR_TIME の使用
ライブラリ・キャッシュ・ミスがない場合も、初期化パラメータ CURSOR_SPACE_FOR_
TIME の値を true に設定することによって実行コールを高速化できる可能性があります。
このパラメータは、新しい SQL 文の領域を作成するために、ライブラリ・キャッシュから
カーソルの割当てを解除するかどうかを指定します。CURSOR_SPACE_FOR_TIME の値には
次の意味があります。
■
■
CURSOR_SPACE_FOR_TIME が false に設定されていると（デフォルト）
、SQL 文に対
応付けられているアプリケーション・カーソルがオープンされているかどうかにかかわ
らず、ライブラリ・キャッシュからカーソルの割当てを解除できます。この場合、
Oracle では、SQL 文を含むカーソルがライブラリ・キャッシュ内にあることを検証する
必要があります。
CURSOR_SPACE_FOR_TIME を true に設定すると、その文に関連するすべてのアプリ
ケーション・カーソルがクローズされる場合のみカーソルの割当てを解除できます。こ
の場合、カーソルに関連するアプリケーション・カーソルがオープンしている間はその
カーソルの割当てを解除できないため、カーソルがキャッシュ内にあるかどうかを確認
する必要はありません。
パラメータの値を true に設定することで、Oracle 側の時間が少し短縮されるので、わずか
ながら実行コールのパフォーマンスが改善する可能性があります。この値は、対応付けられ
ているアプリケーション・カーソルがクローズされるまでカーソルの割当て解除も防ぎま
す。
実行コールでライブラリ・キャッシュ・ミスがあった場合は、CURSOR_SPACE_FOR_TIME
の値を true に設定しないでください。そのようなライブラリ・キャッシュ・ミスは、共有
プールが十分大きくないので同時にオープンしている全カーソルの共有 SQL 領域を保持で
きないことを示しています。値が true であり、共有プール内に新しい SQL 文のための領域
7-40　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
がない場合、文は解析されず、共有メモリーがなくなったことを示すエラーが Oracle に
よって戻されます。値が false であり、そして新しい文のための領域がない場合には、
Oracle が既存のカーソルの割当てを解除します。カーソルの割当てを解除するとライブラ
リ・キャッシュ・ミスが後で発生します（カーソルが再度実行される場合のみ）が、SQL 文
が解析できないため、アプリケーションを停止させるエラーよりも望ましい対処と言えま
す。
各ユーザーに利用できるプライベート SQL 領域のメモリー量が不十分な場合、CURSOR_
SPACE_FOR_TIME の値を true に設定しないでください。また、この値は、オープンして
いるカーソルに対応付けられているプライベート SQL 領域の割当て解除も防ぎます。同時
にオープンしているすべてのカーソルのプライベート SQL 領域が使用可能メモリーを満た
しているために、新しい SQL 文の領域がない場合は、文を解析できません。Oracle は、メ
モリーが十分にないことを示すエラーを戻します。
セッション・カーソルのキャッシュ
アプリケーションから何度も同じ SQL 文で解析コールが発行される場合、セッション・
カーソルの再オープンがシステム・パフォーマンスに影響を及ぼすことがあります。パ
フォーマンスへの影響を最小限に抑えるために、セッション・カーソルをセッション・カー
ソル・キャッシュに保存できます。これらのカーソルは、アプリケーションによりクローズ
されており、再利用できます。フォーム間で切替えを行うと、最初のフォームに関連するす
べてのセッション・カーソルがクローズされるため、この機能は、Oracle Forms が使用され
ているアプリケーションで特に有用です。
Oracle では、ライブラリ・キャッシュをチェックして、指定の文で 3 回以上の解析要求が発
行されたかどうかを識別します。発行された場合、Oracle では、文に関連するセッション・
カーソルをキャッシュすることを想定し、カーソルをセッション・カーソル・キャッシュに
移動します。同じセッションでその SQL 文の解析要求が続けて出されると、セッション・
カーソル・キャッシュ内のカーソルが検索されます。
セッション・カーソルのキャッシュを使用可能にするには、初期化パラメータ SESSION_
CACHED_CURSORS を設定する必要があります。このパラメータの値は、キャッシュに保持
されるセッション・カーソルの最大数を指定する正の整数です。LRU のアルゴリズムでは、
必要に応じてセッション・カーソル・キャッシュ内の項目を除去し、新しい項目のための空
間を作成します。
また次の文を使用すると、セッション・カーソル・キャッシュを動的に使用可能にすること
もできます。
ALTER SESSION SET SESSION_CACHED_CURSORS = value;
セッション・カーソル・キャッシュがインスタンスに対して十分な大きさであるかどうかを
判断するには、V$SYSSTAT ビュー内のセッション統計（session cursor cache hits）
を調べます。この統計では、解析コールによってセッション・カーソル・キャッシュ内で
カーソルが検出された回数を数えます。この統計で、セッションの合計解析コール数が相対
的に低い割合である場合には、SESSION_CACHED_CURSORS を大きい値に設定してくださ
い。
メモリーの構成と使用方法
7-41
共有プールとラージ・プールの構成および使用方法
予約プールの構成
非常に大きいメモリーの要求は小さいチャンクに分割されますが、システムによっては、メ
モリーの連続チャンク（たとえば、5KB 以上）を検索する必要性が依然存在する場合があり
ます（デフォルトの最小予約プールの割当ては 4400 バイトです）。
共有プールに十分な空き領域がない場合は、この要求を満たすための十分な空きメモリーを
検索する必要があります。この操作では、検出可能期間にラッチ・リソースを保持するた
め、メモリー割当てで他の同時動作に対して多少の影響が生じる可能性があります。
したがって、共有プールに十分な領域がない場合、Oracle は使用できる共有プールに内部的
に小さいメモリー領域を予約します。この予約プールによって、大きいチャンクの割当てが
より効率的に行われます。
デフォルトでは、小さな予約プールを構成します。このメモリーは、PL/SQL およびトリ
ガーのコンパイルなどの操作や、Java オブジェクトのロード時の一時領域に使用できます。
予約プールから割り当てられたメモリーが解放されると、予約プールに戻ります。
予約されるデフォルトの領域量を変更する必要はほとんどありません。ただし、必要であれ
ば、SHARED_POOL_RESERVED_SIZE 初期化パラメータを設定して予約プール・サイズを変
更できます。このパラメータは、極端に大きい割当て用の領域を共有プール内に確保しま
す。
大きい割当ての場合、Oracle は次の順序で共有プールへの領域の割当てを試行します。
1.
共有プールの予約されていない部分。
2.
予約プール。共有プールの予約されていない部分に十分な領域がない場合は、予約プー
ルに十分な領域があるかどうかチェックされます。
3.
メモリー。共有プールの予約されていない部分と予約された部分に十分な領域がない場
合は、Oracle は割当てのために十分なメモリーの解放を試みます。次に、共有プールの
予約されていない部分と予約されている部分が再試行されます。
SHARED_POOL_RESERVED_SIZE の使用
SHARED_POOL_RESERVED_SIZE のデフォルト値は SHARED_POOL_SIZE の 5% です。つま
り、デフォルトでは、予約リストは構成されています。
SHARED_POOL_RESERVED_SIZE を SHARED_POOL_SIZE の半分を超える量に設定すると、
Oracle はエラー信号を出します。予約プールにメモリーをあまり多くは予約できません。た
だし、オペレーティング・システムのメモリー容量が共有プールのサイズを制約する場合が
あります。一般的には、SHARED_POOL_RESERVED_SIZE は SHARED_POOL_SIZE の 10％
に設定します。すでに共有プールのチューニングを済ませている場合、ほとんどのシステム
ではこの値で十分です。この値を大きくすると、データベースは共有プールからメモリーを
取り出します。
（このため、それより小さい割当てに使用可能な予約されていない共有プー
ルのメモリーの量が減少します。
）
7-42　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
V$SHARED_POOL_RESERVED ビューの統計を使用すると、これらのパラメータをチューニ
ングするのに役立ちます。SGA のサイズを大きくするための空きメモリーが豊富にあるシス
テムでは、REQUEST_MISSES の値を 0（ゼロ）にすることが目標です。オペレーティング・
システム・メモリーに制約があるシステムの場合は、REQUEST_FAILURES をなくすことが
目標で、少なくともこの値が増加しないようにします。
これらの目標値が達成できない場合は、SHARED_POOL_RESERVED_SIZE の値を増やしてく
ださい。また、予約リストは共有プールから取られるため、SHARED_POOL_SIZE の値も同
じだけ増やします。
関連項目 : LARGE_POOL_SIZE パラメータ設定の詳細は、『Oracle
Database リファレンス』を参照してください。
SHARED_POOL_RESERVED_SIZE が小さすぎる場合
REQUEST_FAILURES の値がゼロよりも大きく、増加している場合は、予約プールが小さす
ぎます。SHARED_POOL_RESERVED_SIZE と SHARED_POOL_SIZE の値をそれぞれ増やす
と、これを解決できます。これらのパラメータで選択する設定は、システムの SGA サイズ
の制約によって異なります。
SHARED_POOL_RESERVED_SIZE の値を増やすと、予約リストで利用可能なメモリーの容量
が増えます。予約リストからメモリーを割り当てないユーザーには影響がありません。
SHARED_POOL_RESERVED_SIZE が大きすぎる場合
予約リストに割り当てられているメモリーが多すぎることがあります。次の場合です。
■
REQUEST_MISSES がゼロの場合（または増加しない場合）
■
FREE_MEMORY の最小値が SHARED_POOL_RESERVED_SIZE の 50% 以上になる場合
これらの条件のどちらかが真の場合、SHARED_POOL_RESERVED_SIZE の値を減らします。
SHARED_POOL_SIZE が小さすぎる場合
V$SHARED_POOL_RESERVED 固定ビューを使用すると、SHARED_POOL_SIZE の値が小さす
ぎる場合を示すこともできます。これは REQUEST_FAILURES がゼロより大きいかあるいは
増加しているような場合です。
予約リストを使用可能にしている場合は、SHARED_POOL_RESERVED_SIZE の値を減らしま
す。予約リストを使用可能にしていない場合は、SHARED_POOL_SIZE を増やします。
メモリーの構成と使用方法
7-43
共有プールとラージ・プールの構成および使用方法
除去防止のためのラージ・オブジェクトの保存
エントリが共有プールにロードされた後は、それを移動することはできません。エントリが
ロードされ、除去されると、空きメモリーが断片化されることもあります。
共有プールを管理するには、PL/SQL パッケージ DBMS_SHARED_POOL を使用します。共有
SQL 領域と共有 PL/SQL 領域は、古くなると LRU アルゴリズムによって共有プールから除
去されます（これはデータベース・バッファの場合と似ています）
。パフォーマンスを改善
したり、再解析が行われないようにするために、サイズの大きい SQL 領域または PL/SQL
領域が古くなって共有プールから除去されないようにすることが可能です。
DBMS_SHARED_POOL パッケージを使用すると、オブジェクトが共有メモリー内に維持され
るため、これらのオブジェクトは通常の LRU メカニズムによって除去されることはありま
せん。DBMS_SHARED_POOL パッケージを使用し、SQL 領域と PL/SQL 領域をメモリーの断
片化が発生する前にロードすると、オブジェクトはメモリー内に維持されます。こうするこ
とによって、メモリーが確実に使用可能になり、SQL 領域と PL/SQL 領域の除去後にこれ
らの領域にアクセスする場合に、ユーザーの応答時間中に突然原因不明のスローダウンが発
生するのを防ぐことができます。
DBMS_SHARED_POOL パッケージは、次の場合に便利です。
■
■
■
STANDARD や DIUTIL パッケージなどの大きな PL/SQL オブジェクトをロードする場合。
大きな PL/SQL オブジェクトがロードされる場合で、領域を確保するために小さなオブ
ジェクトを共有プールから除去する必要がある場合は、ユーザーの応答時間に影響が現
れます。場合によっては、このような大きなオブジェクトをロードするには、メモリー
が十分でないこともあります。
頻繁に実行されるトリガー。頻繁に使用する表のコンパイル済トリガーを共有プール内
に維持できます。
DBMS_SHARED_POOL が順序もサポートする場合。共有プールから順序が除去されると、
順序番号が失われます。DBMS_SHARED_POOL は、共有プール内に順序を保持し、順序
番号の消失を防ぎます。
DBMS_SHARED_POOL パッケージを使用して SQL 領域または PL/SQL 領域を確保するには、
次の手順を実行してください。
1.
メモリー内に確保しておくパッケージまたはカーソルを決定します。
2.
データベースを起動します。
3.
DBMS_SHARED_POOL.KEEP をコールしてオブジェクトを確保します。
この手順により、保存されているオブジェクトがロードされる前にシステムの共有メモ
リーが使用し尽くされないことが保証されます。その結果、オブジェクトをインスタン
スの早い時期に確保することにより、大きなメモリー領域を共有プールの中央に確保す
るために発生する可能性のある、メモリーの断片化を防ぐことができます。
関連項目 : DBMS_SHARED_POOL プロシージャの使用方法の詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参
照してください。
7-44　Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
既存のアプリケーション用の CURSOR_SHARING
解析の第 1 段階の 1 つは、文のテキストを共有プール内の既存の文と比較して、その文を共
有できるかどうかを確認することです。文をテキストとして比較し、なんらかの点で異なる
場合は、文は共有されません。
例外は、CURSOR_SHARING パラメータが SIMILAR または FORCE に設定されている場合で
す。このパラメータを使用する場合、まず共有プールがチェックされ、共有プールに同一の
文があるかどうかが確認されます。同一の文が検出されないと、共有プール内で類似する文
が検索されます。類似する文があると、解析チェックが引き続き行われ、カーソルの実行可
能フォームを使用できるかどうかが検証されます。文がない場合は、文の実行可能フォーム
を生成するためにハード解析が必要になります。
類似 SQL 文
いくつかのリテラル値以外が同一である文は、類似文と呼ばれます。CURSOR_SHARING パ
ラメータが SIMILAR または FORCE に設定されると、類似文は解析フェーズでテキスト・
チェックを省略します。テキストの類似性では、共有は保証されません。SQL 文の新しい
フォームでは、解析フェーズの残りのステップを実行して、既存の文の実行計画が新しい文
にも同じように適用できるかどうかを確認する必要があります。
関連項目 : 実行される各種チェックの詳細は、7-23 ページの「SQL 共有
基準」を参照してください。
CURSOR_SHARING
CURSOR_SHARING を EXACT に設定すると、SQL 文はテキストがまったく同一の場合にのみ
SQL 領域を共有できます。これはデフォルトの動作です。この設定では、類似文は共有でき
ません。テキストとしての完全に同一の文のみ共有できます。
CURSOR_SHARING を SIMILAR または FORCE に設定すると、類似文が SQL を共有できま
す。SIMILAR と FORCE の違いは、実行計画を機能低下させることなく SIMILAR が類似す
る文に SQL 領域を共有させるという点です。CURSOR_SHARING を FORCE に設定すると、
類似文に実行可能な SQL 領域を共有するように強制します。この方法には、潜在的に実行
計画の機能を低下させる可能性があります。したがって、計画が最適なものではなくなる可
能性があってもカーソル共有率の向上を優先する場合に、FORCE を最後の手段として使用し
てください。
CURSOR_SHARING を使用する場合
CURSOR_SHARING 初期化パラメータにより一部のパフォーマンス問題を解決できる場合が
あります。初期化パラメータには、FORCE、SIMILAR および EXACT（デフォルト）の値が
あります。このパラメータの使用は、多数の類似 SQL 文を持つ既存のアプリケーションに
とっては有益です。
メモリーの構成と使用方法
7-45
共有プールとラージ・プールの構成および使用方法
注意 : 複雑な問合せを使用している場合は、DSS 環境で CURSOR_
SHARING を FORCE に設定することはお薦めしません。また、CURSOR_
SHARING が SIMILAR または FORCE に設定されると、スター型変換はサ
ポートされません。詳細は、14-6 ページの「OPTIMIZER_FEATURES_
ENABLE パラメータ」を参照してください。
最適な解決方法は、CURSOR_SHARING パラメータに依存するのではなく、共有可能な SQL
を書くことです。これは、CURSOR_SHARING によってハード解析がなくなる分、使用され
るリソース量は大幅に削減されますが、共有プール内で類似文を検索するために、ソフト解
析の一部としてある程度の追加作業が必要になるからです。
注意 : CURSOR_SHARING を SIMILAR または FORCE に設定すると、
（SELECT 文に指定した）リテラルを含む選択された式の最大長
（DESCRIBE からの戻り値）が増加します。ただし、戻されたデータの実
際の長さは変わりません。
次の質問の両方に該当する場合は、CURSOR_SHARING を SIMILAR または FORCE に設定す
ることを考慮してください。
1.
共有プール内にリテラルの値のみが異なる文がありますか。
2.
応答時間は、ライブラリ・キャッシュ・ミス数が非常に多いために遅くなっています
か。
注意 : CURSOR_SHARING を FORCE または SIMILAR に設定すると、
CURSOR_SHARING が EXACT に設定された状態で生成されたリテラルを持
つアウトラインは使用されません。
CURSOR_SHARING=FORCE または SIMILAR でストアド・アウトラインを
使用するには、FORCE または SIMILAR に設定された CURSOR_SHARING
でアウトラインを生成するか、CREATE_STORED_OUTLINES パラメータ
でアウトラインを生成する必要があります。
CURSOR_SHARING = SIMILAR（または FORCE）を使用すると、多数の類似文を持ついくつ
かのアプリケーション上でのカーソルの共有を大幅に向上できるため、メモリー使用量が削
減され、解析が高速になり、ラッチ競合が減少します。
7-46　Oracle Database パフォーマンス・チューニング・ガイド
REDO ログ・バッファの構成および使用
接続の維持
中間層を持つ大きな OLTP アプリケーションでは、データベース要求ごとに接続と切断を行
うのではなく、接続を維持するようにします。永続的な接続を維持することで、ラッチなど
の CPU リソースとデータベース・リソースが節約されます。
関連項目 : 重要なオペレーティング・システム統計の説明は、5-5 ページ
の「オペレーティング・システム統計」を参照してください。
REDO ログ・バッファの構成および使用
バッファ・キャッシュ内のデータ・ブロックに変更を行うサーバー・プロセスでは、REDO
データをログ・バッファに生成します。LGWR は、次のいずれかに当てはまる場合に、
REDO ログ・バッファからオンライン REDO ログにエントリをコピーする書込みを開始し
ます。
■
■
■
ログ・バッファの 1/3 が満たされる。
LGWR が、COMMIT または ROLLBACK を実行するサーバー・プロセスによって通知され
る。
DBWR が、書込みをするように LGWR に通知する。
LGWR が REDO ログ・ファイルに REDO ログ・バッファから REDO エントリを書き込むと
き、ユーザー・プロセスはディスクに書き込まれたメモリー内のエントリ上に新しいエント
リをコピーできます。REDO ログへのアクセスが激しいときでも、通常 LGWR は高速に書
込みを行い、新しいエントリのバッファ内の領域が利用できることを保証します。
大きいバッファにより、新しいエントリのための領域がある可能性が高くなります。また、
LGWR に、REDO レコードを効率よく書き出す機会を与えます（大規模な更新を行うシス
テム上の小さすぎるログ・バッファは、LGWR が REDO を継続的にディスクにフラッシュ
することになり、ログ・バッファは 2/3 が空白のままになります）
。
高速のプロセッサと比較的低速のディスクを持つマシンでは、REDO ログ・ライターによっ
てバッファの一部がディスクに移動される時間に、プロセッサがバッファの残りにデータを
挿入していることがあります。この状況では、大きいログ・バッファは低速のディスクの影
響を一時的に隠すことがあります。次のような方法も選択できます。
■
■
チェックポイント機能またはアーカイブ・プロセスを改善する。
すべてのオンライン・ログを高速の RAW デバイスに移動するなどの方法で、ログ・ラ
イターのパフォーマンスを改善する。
REDO ログ・バッファの有効利用の簡単な例を示します。
■
■
ログ・ライターが REDO ログ・エントリを効率的に書き込めるようにする、バッチ・
ジョブに対する一括コミット操作
大量のデータをロードするときの NOLOGGING 操作の使用
メモリーの構成と使用方法
7-47
REDO ログ・バッファの構成および使用
REDO ログ・バッファのサイズは、初期化パラメータ LOG_BUFFER で決定されます。ログ・
バッファ・サイズは、インスタンス起動後には変更できません。
図 7-2 REDO ログ・バッファ
ログ・バッファのサイズ設定
大量のデータを挿入、変更または削除するアプリケーションは、通常、デフォルトのログ・
バッファ・サイズを変更する必要があります。ログ・バッファは総 SGA サイズと比較する
と小さく、中規模サイズのログ・バッファは、多数の更新を実行するシステムでのスルー
プットを大幅に向上させます。
そのようなシステムにおける合理的な最初の見積りはデフォルト値に対するもので、次のと
おりです。
MAX(0.5M, (128K * number of cpus))
大半のシステムでは、ログ・バッファを 1MB より大きくサイズ設定しても、パフォーマン
スの利点が得られません。バッファ・サイズを増やしても、パフォーマンスまたはリカバリ
能力に対してマイナスの影響を及ぼしません。単に追加のメモリーが使用されます。
7-48　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
ログ・バッファの統計
統計 REDO BUFFER ALLOCATION RETRIES は、ユーザー・プロセスが REDO ログ・バッ
ファ内の領域の使用を待機した回数を反映します。この統計は、動的パフォーマンス・
ビュー V$SYSSTAT で問い合せることができます。
次の問合せによって、アプリケーションの実行中に、ある程度の期間にわたってこれらの統
計を監視します。
SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME = 'redo buffer allocation retries';
redo buffer allocation retries の値は、ある時間間隔に対して 0（ゼロ）に近い値
である必要があります。この値が一貫して増分する場合は、プロセスが REDO ログ・バッ
ファ内の領域を待機する必要があったということです。この待機は、ログ・バッファが小さ
すぎること、あるいはチェックポイント機能が原因となっていることがあります。必要であ
れば、初期化パラメータの LOG_BUFFER の値を変更することによって、REDO ログ・バッ
ファのサイズを大きくできます。このパラメータの値はバイト単位で表されます。あるい
は、チェックポイント機能またはアーカイブ・プロセスを改善してください。
別のデータ・ソースは、log buffer space 待機イベントがインスタンスの待機時間におけ
る重要な要因でないことをチェックするためのものです。重要な要因でなければ、バッ
ファ・サイズはほぼ適切です。
PGA メモリー管理
プログラム・グローバル領域（PGA）は、サーバー・プロセスのデータおよび制御情報を含
むプライベート・メモリー領域です。この領域に対するアクセスはそのサーバー・プロセス
に対して排他的であり、そのかわりの役割を果たす Oracle コードでのみ読取りおよび書込
みが行われます。そのような情報の例として、カーソルのランタイム領域があります。カー
ソルを実行するたびに、そのカーソルを実行するサーバー・プロセスの PGA メモリー領域
内に、そのカーソルのための新しいランタイム領域が作成されます。
注意 : ランタイム領域の一部は、共有サーバーを使用するときに SGA 内
に配置できます。
複雑な問合せ（たとえば、意思決定支援の問合せ）の場合、ランタイム領域の大部分が、次
のようなメモリー集約型演算子で割り当てられた作業領域に使用されます。
■
ソート・ベース演算子（たとえば、ORDER BY、GROUP BY、ROLLUP およびウィンドウ
機能）
■
ハッシュ結合
■
ビットマップ・マージ
メモリーの構成と使用方法
7-49
PGA メモリー管理
■
ビットマップ作成
■
一括ロード操作で使用される書込みバッファ
ソート演算子は、作業領域（ソート領域）を使用して一連の行のメモリー内ソートを実行し
ます。同様に、ハッシュ結合演算子は作業領域（ハッシュ領域）を使用して、ハッシュ表を
左側から入力して作成します。
作業領域のサイズは、制御およびチューニングできます。一般に、作業領域を大きくする
と、メモリー消費量は増えますが特定の演算子のパフォーマンスを大幅に向上できます。作
業領域のサイズは、関連する SQL 演算子で割り当てられた入力データや補助メモリー構造
を十分収容できるほど大きなサイズが理想的です。これが作業領域の最適サイズとされま
す。作業領域のサイズが最適なサイズより小さい場合は、入力データの部分に対して追加の
パスが実行されるので、応答時間は増えます。これは、作業領域のワン・パス・サイズと呼
ばれます。ワン・パスしきい値以下の場合は、作業領域のサイズが入力データ・サイズに比
べて小さすぎる場合に入力データに対する複数のパスが必要です。このため、演算子の応答
時間が大幅に増加する可能性があります。これは、作業領域のマルチ・パス・サイズと呼ば
れます。たとえば、10GB のデータをソートするシリアル・ソート操作では、最適なサイズ
で実行するには 10GB よりも少し多めが必要で、ワン・パスで実行するには少なくとも
40MB が必要です。このソートが 40MB より少ない取得を行う場合は、入力データに対して
複数のパスを実行する必要があります。
目標は、最適なサイズ（たとえば、90% を超える、または OLTP システム固有の場合は
100%）で大半の作業領域を動作させ、その一部をワン・パス・サイズ（たとえば、10% 未
満）で動作させることです。マルチ・パスの実行は避けてください。大きなソートとハッ
シュ結合を実行する DSS システムの場合であっても、ワン・パスの実行のメモリー要件は相
対的に少ない量です。妥当な PGA メモリー量で構成されたシステムは、入力データに対し
てマルチ・パスを実行する必要がありません。
自動 PGA メモリー管理により、PGA メモリーの割当て方法が単純化され改善されます。デ
フォルトでは、PGA メモリー管理は有効化されます。このモードでは、SGA メモリー・サ
イズの 20% をベースとして、作業領域専用の PGA メモリーのサイズが動的に調整されま
す。最小値は 10MB です。
注意 : 下位互換性のために、PGA_AGGREGATE_TARGET 初期化パラメー
タを 0（ゼロ）に設定して、自動 PGA メモリー管理を無効にできます。
自動 PGA メモリー管理が無効になっている場合は、SORT_AREA_SIZE 初
期化パラメータなどの関連 _AREA_SIZE パラメータを使用して作業領域
の最大サイズを設定できます。
PGA_AGGREGATE_TARGET、SORT_AREA_SIZE、HASH_AREA_SIZE、
BITMAP_MERGE_AREA_SIZE および CREATE_BITMAP_AREA_SIZE 初期
化パラメータの詳細は、
『Oracle Database リファレンス』を参照してくだ
さい。
7-50　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
自動 PGA メモリーの構成
自動 PGA メモリー管理モードで実行する場合、すべてのセッションの作業領域のサイズ設
定と *_AREA_SIZE パラメータは、そのモードで動作するすべてのセッションで無視されま
す。インスタンスでアクティブな作業領域に使用できる PGA メモリーの総量は、指定時間
に、PGA_AGGREGATE_TARGET 初期化パラメータから自動的に導出されます。この量は、シ
ステムの他のコンポーネントで割り当てられた PGA メモリー（たとえば、セッションで割
り当てられた PGA）の量を PGA_AGGREGATE_TARGET から減算した値に設定されます。次
に、その結果の PGA メモリーは、それぞれ特定のメモリー要件に基づいて個々のアクティ
ブな作業領域に割り当てられます。
自動 PGA メモリー管理モードにおいて Oracle が主な目標としたものは、SQL 作業領域に割
り当てられる PGA メモリーの量を動的に制御することで、DBA が設定した PGA_
AGGREGATE_TARGET の制限を尊重することです。これと同時に、使用する PGA メモリー
（キャッシュ・メモリー）の量が最適である作業領域の数を最大にして、すべてのメモリー
集中型 SQL 操作のパフォーマンスを最大限に引き出す試みも行っています。パラメータ
PGA_AGGREGATE_TARGET で DBA により設定された PGA メモリーの制限が低すぎて、マ
ルチ・パスを実行して PGA メモリーの消費をさらに削減して、PGA のターゲット制限を尊
重する必要がある場合を除き、残りの作業領域は、ワン・パス・モードで実行されます。
新規インスタンスを構成する場合には、PGA_AGGREGATE_TARGET の適切な設定を正確に知
ることは困難です。この設定は、次の 3 つの段階を実行して判別します。
1.
PGA_AGGREGATE_TARGET の最初の見積りは経験に基づいて行う。デフォルトでは、
SGA サイズの 20% が使用されます。ただし、この初期設定は、大規模 DSS システムに
は小さすぎる場合があります。
2.
インスタンスで代理のワークロードを実行し、Oracle により収集された PGA 統計を使
用してパフォーマンスを監視して、最大 PGA サイズが高く構成されたか低く構成され
たかを確認する。
3.
Oracle PGA のアドバイスの統計を使用して、PGA_AGGREGATE_TARGET をチューニン
グする。
関連項目 : PGA_AGGREGATE_TARGET 初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照してください。
これについては、次の項で詳しく説明します。
■
PGA_AGGREGATE_TARGET の初期設定
■
自動 PGA メモリー管理のパフォーマンスの監視
■
PGA_AGGREGATE_TARGET のチューニング
メモリーの構成と使用方法
7-51
PGA メモリー管理
PGA_AGGREGATE_TARGET の初期設定
Oracle インスタンスに使用できる総メモリー量に基づいて、PGA_AGGREGATE_TARGET 初
期化パラメータの値（たとえば、100000KB、2500MB、50GB など）を設定する必要があり
ます。この値は後からインスタンス・レベルでチューニングしたり動的に変更できます。例
7-2 に一般的な状況を示します。
例 7-2 PGA_AGGREGATE_TARGET の初期設定
Oracle インスタンスが 4 GB の物理メモリーを持つシステム上で動作するように設定されて
いると仮定します。そのメモリーの一部は、オペレーティング・システムと同じハードウェ
ア・システムで動作しているその他の Oracle 以外のアプリケーションに残しておく必要が
あります。たとえば、使用可能なメモリーの 80%（3.2 GB）のみを Oracle インスタンス専
用にできます。
次に、残りのメモリーを SGA と PGA に分割する必要があります。
■
■
OLTP システムの場合、PGA メモリーの割合は使用可能なメモリーの総量の一部（例 :
20% が PGA 用、80% が SGA 用）とするのが普通です。
メモリー集中型の大きな問合せを実行する DSS システムの場合、PGA メモリーには総
量の最大 70%（この例では最大 2.2GB）までを使用できます。
PGA_AGGREGATE_TARGET パラメータの適切な初期値の例を次に示します。
■
OLTP の場合 : PGA_AGGREGATE_TARGET = (total_mem * 80%) * 20%
■
DSS の場合 : PGA_AGGREGATE_TARGET = (total_mem * 80%) * 50%
total_mem はシステムで使用可能な物理メモリーの総量です。
この例では、4GB の total_mem の値を使用することにより、PGA_AGGREGATE_TARGET を
DSS システムの場合は 1600MB に、OLTP システムの場合は 655MB に初期設定できます。
自動 PGA メモリー管理のパフォーマンスの監視
チューニング・プロセスを開始する前に、Oracle で収集される主要統計の監視および解釈方
法を理解して、自動 PGA メモリー管理のパフォーマンスを評価する場合の参考にする必要
があります。そのための動的パフォーマンス・ビューの例を次に示します。
■
V$PGASTAT
■
V$PROCESS
■
V$SQL_WORKAREA_HISTOGRAM
■
V$SQL_WORKAREA_ACTIVE
■
V$SQL_WORKAREA
7-52　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
V$PGASTAT このビューは、PGA メモリー使用量および自動 PGA メモリー・マネージャに関
するインスタンス・レベルの統計を示します。たとえば、次のようにします。
SELECT * FROM V$PGASTAT;
この問合せの出力例を次に示します。
NAME
VALUE UNIT
-------------------------------------------------------- ---------- -----------aggregate PGA target parameter
41156608 bytes
aggregate PGA auto target
21823488 bytes
global memory bound
2057216 bytes
total PGA inuse
16899072 bytes
total PGA allocated
35014656 bytes
maximum PGA allocated
136795136 bytes
total freeable PGA memory
524288 bytes
PGA memory freed back to OS
1713242112 bytes
total PGA used for auto workareas
0 bytes
maximum PGA used for auto workareas
2383872 bytes
total PGA used for manual workareas
0 bytes
maximum PGA used for manual workareas
8470528 bytes
over allocation count
291
bytes processed
2124600320 bytes
extra bytes read/written
39949312 bytes
cache hit percentage
98.15 percent
V$PGASTAT に表示される主な統計は次のとおりです。
■
■
■
aggregate PGA target parameter: これは初期化パラメータ PGA_AGGREGATE_
TARGET の現在の値です。デフォルト値は、SGA サイズの 20% です。このパラメータを
0（ゼロ）に設定すると、PGA メモリーの自動管理は無効になります。
aggregate PGA auto target: 自動モードで実行する作業領域に使用できる PGA メ
モリーの量を示します。この量は、PGA_AGGREGATE_TARGET パラメータの値と現在の
作業領域のワークロードから導出されます。したがって、Oracle で継続的に調整されま
す。この値が PGA_AGGREGATE_TARGET と比べて小さい場合、多くの PGA メモリーが
システムの他のコンポーネント（たとえば、PL/SQL や Java メモリー）で使用され、
ソート作業領域にはメモリーがほとんど残されていません。自動モードで実行される作
業領域には十分な PGA メモリーが残されている必要があります。
global memory bound: AUTO モードで実行された作業領域の最大サイズを示します。
この値は、作業領域のワークロードの現在の状態を反映するように継続的に調整されま
す。通常は、システム内のアクティブな作業領域の数が増えると、グローバル・メモ
リー・バウンドが縮小します。一般的には、グローバル・バウンドの値は 1MB を下回
らないようにする必要があります。1MB 未満になった場合は、PGA_AGGREGATE_
TARGET の値を増やす必要があります。
メモリーの構成と使用方法
7-53
PGA メモリー管理
■
■
■
total PGA allocated: インスタンスによって割り当てられた現在の PGA メモリー量
を示します。通常この値は、PGA_AGGREGATE_TARGET の値未満に維持されます。ただ
し、作業領域のワークロードが急速に増えている場合や、初期化パラメータ PGA_
AGGREGATE_TARGET の設定値が小さすぎる場合は、少量かつ短時間、その値を超過し
た PGA が割り当てられることがあります。
total freeable PGA memory: 割当て済で解放可能な PGA メモリーの量を示しま
す。
total PGA used for auto workareas: 自動メモリー管理モードで実行する作業領
域で現在消費されている PGA メモリーの量を示します。この数値から、PGA メモリー
の他のコンシューマ（たとえば、PL/SQL や Java）で消費されるメモリーの量を判断で
きます。
PGA other = total PGA allocated - total PGA used for auto workareas
■
■
■
■
over allocation count: この統計は、インスタンスの起動時から累積されます。
PGA_AGGREGATE_TARGET の値が小さすぎて、前述の等式の PGA other コンポーネン
トと、作業領域のワークロードを実行するために必要な最小メモリーに対応できない場
合は、PGA メモリーの過剰割当てとなる可能性があります。その場合、Oracle は初期
化パラメータ PGA_AGGREGATE_TARGET を満たすことができないため、追加の PGA メ
モリーを割り当てる必要があります。過剰割当てが発生した場合は、アドバイス・
ビュー V$PGA_TARGET_ADVICE の情報を使用して、PGA_AGGREGATE_TARGET の値を
増やす必要があります。
total bytes processed: インスタンスの起動後にメモリー集中型 SQL 演算子によっ
て処理されたバイト数を示します。たとえば、ソート操作の入力サイズが、処理された
バイト数によって示されます。この数値は cache hit percentage 測定値を計算する
場合に使用します。
extra bytes read/written: 作業領域が最適に実行できない場合は、1 つ以上の余
分なパスが入力データで実行されています。extra bytes read/written は、インス
タンス起動後にこれらのパスで処理されたバイト数を示します。この数値は cache hit
percentage を計算する場合にも使用します。total bytes processed に比べて小
さい値であることが理想的です。
cache hit percentage: この測定値は Oracle によって計算され、PGA メモリー・コ
ンポーネントのパフォーマンスを反映します。この値はインスタンスの起動時から累積
されます。値が 100% の場合は、インスタンス起動後にシステムが実行したすべての作
業領域で、最適な量の PGA メモリーが使用されたことを意味します。それが理想的で
すが、純粋な OLTP システムなどの場合を除き、そのようになることはほとんどありま
せん。実際には、PGA メモリーの総サイズによって、ワン・パスやマルチ・パスを実
行する作業領域も発生します。作業領域が最適に実行できない場合は、1 つ以上の余分
なパスが入力データで実行されています。その場合、入力データのサイズと実行された
余分なパス数に比例して cache hit percentage が低下します。例 7-3 に、余分なパ
スによって cache hit percentage が受ける影響を示します。
7-54　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
例 7-3 キャッシュ・ヒット率の計算
4 つのソート操作が実行され、そのうちの 3 つは小さく（1MB の入力データ）
、1 つは大きい
（100MB の入力データ）という場合の単純事例を示します。4 つの操作で処理されるバイト
数（BP）は 103MB です。小さなソートの 1 つがワン・パスを実行すると、1MB の入力デー
タで余分なパスが実行されます。この 1MB という値は、extra bytes read/written
（EBP）の数を示します。cache hit percentage は次の計算式で計算されます。
BP x 100 / (BP + EBP)
この場合の cache hit percentage は 99.03% で、ほぼ 100% です。他のすべてのソートを
最適に実行している間、余分なパスを実行する小さなソートが 1 つであったことがこの値に
反映されています。したがって、cache hit percentage はほぼ 100% になりますが、そ
れはこの 1MB の余分なパスがわずかなオーバーヘッドであるためです。一方、大きなソー
トがワン・パスを実行するソートの場合、EBP は 1MB ではなく 100MB となり、cache hit
percentage は 50.73% に低下しますが、それはこの余分なパスがもたらす影響が大きくな
るためです。
V$PROCESS このビューでは、インスタンスに接続されている Oracle プロセス 1 つにつき行
が 1 つあります。PGA_USED_MEM 列、PGA_ALLOC_MEM 列、PGA_ALLOC_MEM 列および
PGA_MAX_MEM 列を使用して、これらのプロセスの PGA メモリー使用量を監視できます。
たとえば、次のようにします。
SELECT PROGRAM, PGA_USED_MEM, PGA_ALLOC_MEM, PGA_FREEABLE_MEM, PGA_MAX_MEM
FROM V$PROCESS;
この問合せの出力例を次に示します。
PROGRAM
PGA_USED_MEM PGA_ALLOC_MEM PGA_FREEABLE_MEM PGA_MAX_MEM
-------------------------------------- ------------ ------------- ---------------- ----------PSEUDO
0
0
0
0
oracle@dlsun1690 (PMON)
314540
685860
0
685860
oracle@dlsun1690 (MMAN)
313992
685860
0
685860
oracle@dlsun1690 (DBW0)
696720
1063112
0
1063112
oracle@dlsun1690 (LGWR)
10835108
22967940
0
22967940
oracle@dlsun1690 (CKPT)
352716
710376
0
710376
oracle@dlsun1690 (SMON)
541508
948004
0
1603364
oracle@dlsun1690 (RECO)
323688
685860
0
816932
oracle@dlsun1690 (q001)
233508
585128
0
585128
oracle@dlsun1690 (QMNC)
314332
685860
0
685860
oracle@dlsun1690 (MMON)
885756
1996548
393216
1996548
oracle@dlsun1690 (MMNL)
315068
685860
0
685860
oracle@dlsun1690 (q000)
330872
716200
65536
716200
oracle@dlsun1690 (TNS V1-V3)
635768
928024
0
1255704
oracle@dlsun1690 (CJQ0)
533476
1013540
0
1144612
oracle@dlsun1690 (TNS V1-V3)
430648
812108
0
812108
メモリーの構成と使用方法
7-55
PGA メモリー管理
V$SQL_WORKAREA_HISTOGRAM このビューには、インスタンス起動後に、最適なメモリー・
サイズ、ワン・パス・メモリー・サイズおよびマルチ・パス・メモリー・サイズで実行され
た作業領域の総数を示します。このビューの統計は、作業領域の最適なメモリー要件によっ
て定義されるバケットに副分割されます。各バケットは、列 LOW_OPTIMAL_SIZE および
HIGH_OPTIMAL_SIZE の値で指定された最適メモリー要件の範囲によって識別されます。
例 7-4 および例 7-5 で、V$SQL_WORKAREA_HISTOGRAM の 2 種類の使用方法を示します。
例 7-4 V$SQL_WORKAREA_HISTOGRAM への問合せ : 空でないバケット
最適に実行する（キャッシュされる）には 3MB のメモリーを必要とするソート操作の事例
を示します。このソートで使用される作業領域に関する統計は、LOW_OPTIMAL_SIZE =
2097152（2 MB）および HIGH_OPTIMAL_SIZE = 4194303（4 MB - 1 バイト）で定義さ
れるバケットに配置されます。これは 3MB が最適サイズの範囲内に収まるためです。統計
は作業領域のサイズでセグメント化されます。最適、ワン・パスまたはマルチ・パスの各
モードで作業領域を実行する場合のパフォーマンスの影響は、その作業領域のサイズに大き
く依存するためです。
次の問合せでは、空でないすべてのバケットの統計が示されます。空のバケットは述語
where total_execution != 0 で削除されます。
SELECT LOW_OPTIMAL_SIZE/1024 low_kb,
(HIGH_OPTIMAL_SIZE+1)/1024 high_kb,
OPTIMAL_EXECUTIONS, ONEPASS_EXECUTIONS, MULTIPASSES_EXECUTIONS
FROM V$SQL_WORKAREA_HISTOGRAM
WHERE TOTAL_EXECUTIONS != 0;
この問合せの結果を次に示します。
LOW_KB HIGH_KB OPTIMAL_EXECUTIONS ONEPASS_EXECUTIONS MULTIPASSES_EXECUTIONS
------ ------- ------------------ ------------------ ---------------------8
16
156255
0
0
16
32
150
0
0
32
64
89
0
0
64
128
13
0
0
128
256
60
0
0
256
512
8
0
0
512
1024
657
0
0
1024
2048
551
16
0
2048
4096
538
26
0
4096
8192
243
28
0
8192
16384
137
35
0
16384
32768
45
107
0
32768
65536
0
153
0
65536 131072
0
73
0
131072 262144
0
44
0
262144 524288
0
22
0
7-56　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
1024 ～ 2048KB のバケットでは、551 の作業領域で最適な量のメモリーが使用されたこと、
またワンパス・モードで実行されたものが 16 ある一方で、マルチ・パス・モードで実行さ
れたものはなかったことがこの問合せ結果に示されています。また、1MB 未満のすべての作
業領域が最適モードで実行できたことも示されています。
例 7-5 V$SQL_WORKAREA_HISTOGRAM への問合せ : 最適パーセント
V$SQL_WORKAREA_HISTOGRAM を使用すると、起動後に作業領域が最適、ワン・パスまた
はマルチ・パスの各モードで実行された回数の割合を調べることもできます。この問合せで
は、一定のサイズ（最適メモリー要件が最低 64KB）の作業領域のみ考慮されます。
SELECT optimal_count, round(optimal_count*100/total, 2) optimal_perc,
onepass_count, round(onepass_count*100/total, 2) onepass_perc,
multipass_count, round(multipass_count*100/total, 2) multipass_perc
FROM
(SELECT decode(sum(total_executions), 0, 1, sum(total_executions)) total,
sum(OPTIMAL_EXECUTIONS) optimal_count,
sum(ONEPASS_EXECUTIONS) onepass_count,
sum(MULTIPASSES_EXECUTIONS) multipass_count
FROM v$sql_workarea_histogram
WHERE low_optimal_size > 64*1024);
この問合せの出力例を次に示します。
OPTIMAL_COUNT OPTIMAL_PERC ONEPASS_COUNT ONEPASS_PERC MULTIPASS_COUNT MULTIPASS_PERC
------------- ------------ ------------- ------------ --------------- -------------2239
81.63
504
18.37
0
0
この結果には、最適な量のメモリーを使用して実行できるのは、これらの作業領域の
81.63% であることが示されています。残り（18.37%）はワン・パスで実行されました。マ
ルチ・パスで実行されたものはありませんでした。これは望ましい状態ですが、その理由は
次のとおりです。
■
■
マルチ・パス・モードでは、パフォーマンスが大幅に低下する可能性があります。マル
チ・パスの作業領域が多いと、関連付けられた SQL 演算子の応答時間に大きな悪影響
があります。
ワンパスの実行では多量のメモリーを必要としません。ワンパス・モードで 1GB のデー
タをソートする場合に必要なメモリーはわずか 22MB です。
V$SQL_WORKAREA_ACTIVE このビューを使用すると、インスタンスでアクティブな（または
実行中の）作業領域を表示できます。小さいアクティブなソート（64KB 以下）はビューか
ら除外されます。すべてのアクティブな作業領域のサイズを正確に監視したり、それらの作
業領域が一時セグメントに流用されているかどうかを判断するには、このビューを使用しま
す。例 7-6 に、このビューの代表的な問合せを示します。
メモリーの構成と使用方法
7-57
PGA メモリー管理
例 7-6 V$SQL_WORKAREA_ACTIVE への問合せ
SELECT to_number(decode(SID, 65535, NULL, SID)) sid,
operation_type OPERATION,
trunc(EXPECTED_SIZE/1024) ESIZE,
trunc(ACTUAL_MEM_USED/1024) MEM,
trunc(MAX_MEM_USED/1024) "MAX MEM",
NUMBER_PASSES PASS,
trunc(TEMPSEG_SIZE/1024) TSIZE
FROM V$SQL_WORKAREA_ACTIVE
ORDER BY 1,2;
この問合せの出力例を次に示します。
SID
OPERATION
ESIZE
MEM
MAX MEM PASS
TSIZE
--- ----------------- --------- --------- --------- ----- ------8
GROUP BY (SORT)
315
280
904
0
8
HASH-JOIN
2995
2377
2430
1
20000
9
GROUP BY (SORT)
34300
22688
22688
0
11
HASH-JOIN
18044
54482
54482
0
12
HASH-JOIN
18044
11406
21406
1 120000
この出力は、作業領域がワンパス・モードで動作しているハッシュ結合（PASS 列）を、
セッション 12（列 SID）が実行していることを示しています。この作業領域は現在、
11406KB のメモリー（MEM 列）を使用しており、過去に最大 21406KB の PGA メモリー
（MAX MEM 列）を使用しました。また、サイズ 120000KB の一時セグメントにも流用されて
います。最終的に、列 ESIZE には、PGA メモリー・マネージャが予測する、このハッシュ
結合での最大メモリー使用量が示されます。この最大値は、PGA メモリー・マネージャが
ワークロードに基づいて動的に計算します。
作業領域を割当て解除したとき、すなわち、関連する SQL 演算子の実行が完了したときに、
作業領域は V$SQL_WORKAREA_ACTIVE ビューから自動的に削除されます。
V$SQL_WORKAREA 実行計画が 1 つ以上の作業領域を使用するカーソルがロードされるたび
に、累積された作業領域の統計がメンテナンスされます。作業領域が割当て解除されるたび
に、V$SQL_WORKAREA 表がその作業領域の実行統計で更新されます。
V$SQL_WORKAREA を V$SQL と結合して、作業領域をカーソルに関連付けることができま
す。V$SQL_PLAN とも結合でき、計画のどの演算子が作業領域を使用しているかを正確に判
断できます。
例 7-7 に、V$SQL_WORKAREA 動的ビューでの代表的な問合せを 3 つ示します。
7-58　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
例 7-7 V$SQL_WORKAREA への問合せ
次の問合せでは、最もキャッシュ・メモリーを必要とする上位 10 個の作業領域を検索しま
す。
SELECT *
FROM
( SELECT
FROM
ORDER
WHERE ROWNUM
workarea_address, operation_type, policy, estimated_optimal_size
V$SQL_WORKAREA
BY estimated_optimal_size )
<= 10;
次の問合せでは、ワン・パスまたはマルチ・パスで実行された 1 つ以上の作業領域を持つ
カーソルを検索します。
col sql_text format A80 wrap
SELECT sql_text, sum(ONEPASS_EXECUTIONS) onepass_cnt,
sum(MULTIPASSES_EXECUTIONS) mpass_cnt
FROM V$SQL s, V$SQL_WORKAREA wa
WHERE s.address = wa.address
GROUP BY sql_text
HAVING sum(ONEPASS_EXECUTIONS+MULTIPASSES_EXECUTIONS)>0;
特定のカーソルのハッシュ値とアドレスを使用することにより、関連する作業領域に関する
情報を含むカーソル実行計画が次の問合せで表示されます。
col "O/1/M" format a10
col name format a20
SELECT operation, options, object_name name,
trunc(bytes/1024/1024) "input(MB)",
trunc(last_memory_used/1024) last_mem,
trunc(estimated_optimal_size/1024) optimal_mem,
trunc(estimated_onepass_size/1024) onepass_mem,
decode(optimal_executions, null, null,
optimal_executions||'/'||onepass_executions||'/'||
multipasses_executions) "O/1/M"
FROM V$SQL_PLAN p, V$SQL_WORKAREA w
WHERE p.address=w.address(+)
AND p.hash_value=w.hash_value(+)
AND p.id=w.operation_id(+)
AND p.address='88BB460C'
AND p.hash_value=3738161960;
メモリーの構成と使用方法
7-59
PGA メモリー管理
OPERATION
-----------SELECT STATE
SORT
HASH JOIN
TABLE ACCESS
TABLE ACCESS
OPTIONS NAME
input(MB) LAST_MEM OPTIMAL_ME ONEPASS_ME O/1/M
-------- -------- --------- -------- ---------- ---------- -----GROUP BY
SEMI
FULL
ORDERS
FUL
LINEITEM
4582
4582
51
1000
8
5976
16
5194
16 16/0/0
2187 16/0/0
アドレスおよびハッシュ値は、問合せでパターンを指定することにより V$SQL ビューから
取得できます。たとえば、次のようにします。
SELECT address, hash_value
FROM V$SQL
WHERE sql_text LIKE '%my_pattern%';
PGA_AGGREGATE_TARGET のチューニング
初期化パラメータ PGA_AGGREGATE_TARGET のチューニングを容易にするため、次の 2 種
類の PGA アドバイス・パフォーマンス・ビューが提供されています。
■
V$PGA_TARGET_ADVICE
■
V$PGA_TARGET_ADVICE_HISTOGRAM
これらのビューを調べれば、経験的な方法で PGA_AGGREGATE_TARGET の値をチューニン
グする必要がありません。このビューの内容を使用すると、PGA_AGGREGATE_TARGET の値
を変更したときに、主な PGA 統計がどのような影響を受けるかを調べることができます。
どちらのビューでも、可能性のある高い値および低い値を評価するため、予測に使用する
PGA_AGGREGATE_TARGET の値は、そのパラメータの現在の値の分数または倍数から導出さ
れます。予測に使用される値の範囲は、10MB ～最大 256GB です。
Oracle は、ワークロードの履歴を記録し、その履歴を異なる値の PGA_AGGREGATE_
TARGET でシミュレートすることによって PGA アドバイス・パフォーマンス・ビューを生
成します。このシミュレーション・プロセスはバックグラウンドで実行され、ワークロード
の履歴を継続的に更新してシミュレーション結果を生成します。その結果は V$PGA_
TARGET_ADVICE または V$PGA_TARGET_ADVICE_HISTOGRAM に問い合せることによって
任意の時点で表示できます。
PGA アドバイス・パフォーマンス・ビューの自動生成を有効化するには、次のパラメータ
が設定されていることを確認してください。
■
■
PGA_AGGREGATE_TARGET。自動 PGA メモリー管理が有効化されます。初期値の設定
は、7-52 ページの「PGA_AGGREGATE_TARGET の初期設定」を参照してください。
STATISTICS_LEVEL。TYPICAL（デフォルト）または ALL に設定します。このパラ
メータを BASIC に設定すると、PGA パフォーマンス・アドバイス・ビューの生成がオ
フになります。
7-60　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
これらの PGA アドバイス・パフォーマンス・ビューの内容は、インスタンス起動時または
PGA_AGGREGATE_TARGET の変更時にリセットされます。
注意 : シミュレーションに実際の実行のすべての要素を含めることはで
きません。したがって、導出された統計が、実際のパフォーマンス統計に
完全には一致しない場合があります。PGA_AGGREGATE_TARGET を変更し
た後は、常にシステムを監視して、新しいパフォーマンスが予測どおりで
あるかどうかを確認してください。
V$PGA_TARGET_ADVICE このビューでは、初期化パラメータ PGA_AGGREGATE_TARGET の値
を変更した場合に、V$PGASTAT の統計 cache hit percentage および over allocation
count がどのような影響を受けるかを予測します。例 7-8 に、このビューの代表的な問合せ
を示します。
例 7-8 V$PGA_TARGET_ADVICE への問合せ
SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb,
ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc,
ESTD_OVERALLOC_COUNT
FROM V$PGA_TARGET_ADVICE;
この問合せの出力例を次に示します。
TARGET_MB
---------63
125
250
375
500
600
700
800
900
1000
1500
2000
3000
4000
CACHE_HIT_PERC
-------------23
24
30
39
58
59
59
60
60
61
67
76
83
85
ESTD_OVERALLOC_COUNT
-------------------367
30
3
0
0
0
0
0
0
0
0
0
0
0
この問合せの結果は図 7-3 に示すように図示できます。
メモリーの構成と使用方法
7-61
PGA メモリー管理
図 7-3 V$PGA_TARGET_ADVICE の図示
7-62　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
この曲線は、PGA_AGGREGATE_TARGET の増加による PGA cache hit percentage の向
上状況を示しています。グラフ内の影付きの部分は over allocation ゾーンで、列
ESTD_OVERALLOCATION_COUNT の値が 0（ゼロ）以外になります。これは PGA メモリー
の最低所要量にも達しないほど PGA_AGGREGATE_TARGET が小さいことを示します。PGA_
AGGREGATE_TARGET を over allocation ゾーンに設定すると、メモリー・マネージャに
よってメモリーが過剰割当てされ、実際に消費された PGA メモリーが設定された制限を超
過します。したがって、PGA_AGGREGATE_TARGET の値をそのゾーンに設定しても意味があ
りません。この例では、PGA_AGGREGATE_TARGET は最低 375MB に設定する必要がありま
す。
注意 : PGA cache hit percentage の理論的な最大値が 100% の場合
でも、作業領域の実際の最大サイズには制限があります。したがって、
PGA_AGGREGATE_TARGET の値をさらに増やしても、理論的な最大値に達
しない場合があります。これが発生するのは、最適メモリー要件が大き
く、cache hit percentage の値が低いヒット率（90% など）に下がる
可能性のある大規模 DSS システムのみです。
over allocation を超えると、PGA cache hit percentage が急速に増加します。これ
は最適、またはワン・パスで実行される作業領域の数が増加し、マルチ・パス実行の数が減
少するためです。この例では、500MB 付近で曲線の変化が発生していますが、これはほとん
どの（場合によってはすべての）作業領域が最適、または少なくともワン・パスで実行可能
になるポイントに対応しています。その変化以降も cache hit percentage は低いペース
で増加し、先細りが始まり、PGA_AGGREGATE_TARGET の増加によるわずかな向上しか見ら
れないポイントに達します。図 7-3 に、PGA_AGGREGATE_TARGET が 3GB に達したときの
その状態を示します。この時点の cache hit percentage は 83% で、PGA メモリーを
1GB 増やしてもわずか（2%）しか向上しません。この例では、PGA_AGGREGATE_TARGET
の最適値は 3GB と考えられます。
PGA_AGGREGATE_TARGET は、最適値に設定するか、少なくとも over allocation ゾー
ンより上の領域の可能な最大値に設定するのが理想的です。一般的には、PGA cache hit
percentage は 60% 以上に設定します。60% の時点でシステムは、理想的な状況で実際に
処理する必要のあるバイト数のほぼ 2 倍の量を処理するためです。この例では、PGA_
AGGREGATE_TARGET を最低 500MB から 3GB にできるだけ近く設定するのが理想的です。
ただし、PGA_AGGREGATE_TARGET パラメータの正しい設定は、実際には PGA コンポーネ
ントにどれだけのメモリーを使用できるかによって異なります。一般的に、PGA メモリー
を追加する場合は、共有プールまたはバッファ・キャッシュの場合と同様に、一部の SGA
コンポーネントのメモリーを減らす必要があります。これは Oracle インスタンスに使用す
る全メモリーが、システムで使用できる物理メモリー量の制約を受ける場合があるためで
す。したがって、システム内で使用可能なメモリーと、様々な SGA コンポーネントのパ
フォーマンス（共有プールのアドバイザの統計およびバッファ・キャッシュ・アドバイザの
統計で監視）という、より大きな視点で、PGA メモリーの増量の決定を下す必要がありま
す。メモリーを SGA から取得できない場合は、システムへの物理メモリーの追加を検討し
ます。
メモリーの構成と使用方法
7-63
PGA メモリー管理
関連項目 :
■
7-32 ページ「共有プールのアドバイザ統計」
■
7-8 ページ「バッファ・キャッシュのサイズ設定」
PGA_AGGREGATE_TARGET のチューニング方法 PGA_AGGREGATE_TARGET をチューニングす
る場合は、チューニング・ガイドラインとして次の手順に従います。
1.
メモリーが過剰割当てされないよう PGA_AGGREGATE_TARGET を設定します。過剰割
当てゾーンに設定しないでください。例 7-8 では、PGA_AGGREGATE_TARGET は最低
375MB に設定する必要があります。
2.
過剰割当てを解消した後、応答時間の要件およびメモリーの制約に基づいて PGA
cache hit percentage を極力最大化します。例 7-8 では、PGA に割当て可能なメモ
リーに制限 X があると仮定しています。
■
■
この制限 X が最適値を超過している場合は、PGA_AGGREGATE_TARGET を最適値に
設定します。この時点では、PGA_AGGREGATE_TARGET へのメモリー割当ての増加
に伴う有益性はごくわずかです。例 7-8 で 10GB を PGA 専用とする場合は、PGA_
AGGREGATE_TARGET を最適値である 3GB に設定します。残りの 7GB は SGA 専用
となります。
制限 X が最適値より小さい場合は、PGA_AGGREGATE_TARGET を X に設定します。
例 7-8 で 2GB のみを PGA 専用とする場合は、PGA_AGGREGATE_TARGET を 2GB
に設定し、cache hit percentage 75% を受け入れます。
さらに、Oracle で収集され、インスタンスの起動時から累積されるほとんどの統計と同様
に、時間間隔の初めと終わりにおけるビューのスナップショットを取得できます。その時間
間隔の予測値は次のように導出できます。
estd_overalloc_count = (difference in estd_overalloc_count between the two snapshots)
(difference in bytes_processed between the two snapshots)
estd_pga_cache_hit_percentage = ----------------------------------------------------------------(difference in bytes_processed + extra_bytes_rw between the two snapshots )
V$PGA_TARGET_ADVICE_HISTOGRAM このビューは、初期化パラメータ PGA_AGGREGATE_
TARGET の値を変更したときに、パフォーマンス・ビュー V$SQL_WORKAREA_HISTOGRAM
に表示される統計がどのように影響を受けるかを予測します。動的ビュー V$PGA_TARGET_
ADVICE_HISTOGRAM を使用すると、予測に使用する一連の PGA_AGGREGATE_TARGET 値に
おける、最適、ワン・パス、マルチ・パスの各作業領域の予測実行回数に関する詳細情報を
表示できます。
V$PGA_TARGET_ADVICE_HISTOGRAM ビューは V$SQL_WORKAREA_HISTOGRAM ビューと
同じであり、予測に使用する PGA_AGGREGATE_TARGET 値を示す 2 つの追加列があります。
したがって、PGA_AGGREGATE_TARGET の希望値を選択するための追加の述語を使用し、
7-64　Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
V$SQL_WORKAREA_HISTOGRAM ビューに対して実行される任意の問合せがこのビューで使
用できます。
例 7-9 V$PGA_TARGET_ADVICE_HISTOGRAM への問合せ
次の問合せでは、初期化パラメータ PGA_AGGREGATE_TARGET の値を現在の値の 2 倍に設
定したときの、V$SQL_WORKAREA_HISTOGRAM の予測内容が表示されます。
SELECT LOW_OPTIMAL_SIZE/1024 low_kb, (HIGH_OPTIMAL_SIZE+1)/1024 high_kb,
estd_optimal_executions estd_opt_cnt,
estd_onepass_executions estd_onepass_cnt,
estd_multipasses_executions estd_mpass_cnt
FROM v$pga_target_advice_histogram
WHERE pga_target_factor = 2
AND estd_total_executions != 0
ORDER BY 1;
この問合せの出力例を次に示します。
LOW_KB
-----8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
HIGH_KB
------16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
ESTD_OPTIMAL_CNT
---------------156107
148
89
13
58
10
653
530
509
227
176
133
66
15
0
0
ESTD_ONEPASS_CNT
---------------0
0
0
0
0
0
0
0
0
0
0
16
103
47
48
23
ESTD_MPASS_CNT
-------------0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
この出力は、PGA_AGGREGATE_TARGET を 2 のべき乗で増加させると、16MB 未満のすべて
の作業領域を最適モードで実行できることを示しています。
関連項目 : 『Oracle Database リファレンス』
メモリーの構成と使用方法
7-65
PGA メモリー管理
V$SYSSTAT および V$SESSTAT
V$SYSSTAT ビューと V$SESSTAT ビューの統計は、最適なメモリー・サイズ、ワン・パス・
メモリー・サイズおよびマルチ・パス・メモリー・サイズで実行された作業領域の総数を示
します。これらの統計は、インスタンスまたはセッションが開始された後から累積されま
す。
次の問合せは、インスタンスの開始後にこれらのモードで作業領域が実行された回数の総数
とパーセンテージを示します。
SELECT name profile, cnt, decode(total, 0, 0, round(cnt*100/total)) percentage
FROM (SELECT name, value cnt, (sum(value) over ()) total
FROM V$SYSSTAT
WHERE name like 'workarea exec%');
この問合せの出力例を次に示します。
PROFILE
CNT PERCENTAGE
----------------------------------- ---------- ---------workarea executions - optimal
5395
95
workarea executions - onepass
284
5
workarea executions - multipass
0
0
OLAP_PAGE_POOL_SIZE の構成
OLAP_PAGE_POOL_SIZE 初期化パラメータは、OLAP セッションに割り当てられている
ページング・キャッシュの最大サイズをバイト単位で指定します。
パフォーマンス上の理由のため、通常は、小さい OLAP ページング・キャッシュを構成し、
DB_CACHE_SIZE を使用して大きいデフォルト・バッファ・プールを設定することが望まし
い対処です。4 MB の OLAP ページング・キャッシュが標準的で、そのうちの 2 MB はメモ
リー・リソースが制限されたシステムに使用されます。
関連項目 : 『Oracle OLAP アプリケーション開発者ガイド』
7-66　Oracle Database パフォーマンス・チューニング・ガイド
8
I/O 構成および設計
I/O サブシステムは、Oracle データベースに不可欠なコンポーネントです。基本的な I/O
概念を紹介し、データベースの様々な部分の I/O 要件について説明し、I/O サブシステムの
設計のための構成例を示します。
この章には次の項があります。
■
I/O の理解
■
I/O の基本構成
I/O 構成および設計
8-1
I/O の理解
I/O の理解
多くのソフトウェア・アプリケーションのパフォーマンスは、本質的にディスク I/O によっ
て制限されます。CPU タイムの大部分を I/O アクティビティが完了するまでの待機に使用
するアプリケーションは I/O バウンドと呼ばれます。
Oracle は、適切に作成されたアプリケーションのパフォーマンスが、I/O で制限されないよ
うに設計されています。I/O システムが最大限またはそれに近い状態で動作しており、許容
時間内に I/O リクエストに対応できない場合は、I/O のチューニングを行うと、アプリケー
ションのパフォーマンスを向上できます。ただし、アプリケーションが I/O バウンドではな
い場合（たとえば、CPU が制限要因である場合）、I/O をチューニングしてもパフォーマン
スを改善できません。
I/O システムを設計するときは、次のデータベース要件を考慮してください。
■
ディスクの最小容量などの記憶域
■
継続的（24 時間× 7 日）または営業時間のみなどの可用性
■
I/O スループットやアプリケーション応答時間などのパフォーマンス
多くの I/O 設計では、パフォーマンスが問題とならないと仮定して記憶域要件および可用性
要件の計画を立てています。ただし、これに該当しない場合もあります。構成するディスク
およびコントローラの数は I/O スループットおよび冗長性の要件で判断することが最適で
す。この場合、ディスクのサイズは記憶域要件で判断できます。
I/O の基本構成
この項では、収集する基本情報およびシステムの I/O 構成を定義するときの決定事項につい
て説明します。必要な可用性、リカバリ能力およびパフォーマンスは維持しながら、できる
だけ単純な構成を維持します。構成が複雑になるに従って、管理、メンテナンスおよび
チューニングが困難になります。
オペレーティング・システムまたはハードウェアのストライプ化を使用し
たファイルのレイアウト
オペレーティング・システムに LVM ソフトウェアまたはハードウェア・ベースのストライ
プ化がある場合、これらのツールを使用して I/O を分散できます。LVM またはハードウェ
ア・ストライプ化を使用するときの決定事項には、ストライプ深度
ストライプ深度およびストライプ幅
ストライプ幅が含
ストライプ深度
ストライプ幅
まれます。
■
■
ストライプ深度は、ストライプのサイズで、ストライプ単位とも呼ばれます。
ストライプ幅は、ストライプ深度とストライプ・セットを構成するドライブ数の積で
す。
8-2　Oracle Database パフォーマンス・チューニング・ガイド
I/O の基本構成
これらの値を適切に選択して、システムが必要なスループットを維持できるようにします。
Oracle データベースにおける適切なストライプ深度は、256KB ～ 1MB です。ストライプ深
度によって、得られるアプリケーションの利点の種類が異なります。最適なストライプ深度
およびストライプ幅は、次の項目により異なります。
■
要求された I/O サイズ
■
I/O リクエストの同時実行性
■
物理ストライプ境界とブロック・サイズ境界との位置合せ
■
提案されたシステムの管理可能性
要求された I/O サイズ
表 8-1 に、I/O サイズの設定で使用できる Oracle およびオペレーティング・システムのパラ
メータを示します。
表 8-1 Oracle およびオペレーティング・システム操作パラメータ
パラメータ
説明
DB_BLOCK_SIZE
単一ブロック I/O リクエストのサイズ。また、このパラメータを
マルチブロック・パラメータと組み合せて使用して、マルチブ
ロック I/O リクエスト・サイズを決定します。
OS ブロック・サイズ
REDO ログおよびアーカイブ・ログ操作の I/O サイズを決定し
ます。
最大 OS I/O サイズ
単一 I/O リクエストのサイズに上限を設けます。
DB_FILE_MULTIBLOCK_
READ_COUNT
全表スキャンの最大 I/O サイズは、このパラメータに DB_
BLOCK_SIZE を乗算して計算されます（上限値は、オペレーティ
ング・システムの制限を受けます）。
SORT_AREA_SIZE
ソート操作のための I/O サイズおよび同時実行性を決定します。
HASH_AREA_SIZE
ハッシュ操作のための I/O サイズを決定します。
I/O サイズの他に、同時実行性の程度も理想的なストライプ深度を調べる上で役立ちます。
ストライプ幅およびストライプ深度を選択する場合は、次の点を考慮してください。
■
同時実行性の低い（順次）システムでは、単一 I/O が同じディスクに 2 回アクセスしな
いようにします。たとえば、ストライプ幅が 4 つのディスクであり、ストライプ深度が
32k であると仮定します。1MB の単一 I/O リクエスト（たとえば、全表スキャンの場
合）が Oracle サーバー・プロセスで発行された場合、ストライプ内の各ディスクは要
求されたデータを戻すために 8 回 I/O を実行する必要があります。このような状況を回
避するために、平均 I/O のサイズは、ストライプ深度とストライプ幅の積より小さいサ
イズにしてください。そうでない場合は、オペレーティング・システムに対して Oracle
I/O 構成および設計
8-3
I/O の基本構成
が単一 I/O リクエストを行うと、同じディスクに対して複数の物理 I/O リクエストが
発生します。
■
同時実行性が高い（ランダム）システムでは、単一 I/O リクエストが複数の物理 I/O
コールに分解されないようにしてください。そうでなければ、システムで実行される物
理 I/O リクエスト数が何倍にもなり、I/O 応答時間が大幅に下がります。
I/O リクエストの同時実行性
従来の OLTP 環境などの高度な小さい同時 I/O リクエストが存在するシステムでは、ストラ
イプ深度を大きく保つことが有効です。I/O サイズより大きいストライプ深度を使用するこ
とは粗密なストライプ化と呼ばれます。同時実行性の高いシステムのストライプ深度は次の
ようになります。
n * DB_BLOCK_SIZE
n は 1 より大
粗密なストライプ化ではアレイ内の 1 ディスクで複数の I/O リクエストに対応できます。こ
の方法では、一連のストライプ化ディスクで多数の同時 I/O リクエストに対応でき、I/O
セットアップ・コストも最小限で済みます。粗密なストライプ化では全体的な I/O スルー
プットが最大化されます。全表スキャンの場合も同様に、ストライプ深度が大きく、かつ 1
つのドライブで対応可能な場合は、マルチブロック読込みが有益です。DSS 環境のパラレル
問合せも、粗密なストライプ化の候補です。これは、それぞれ個別の I/O を発行する個々の
プロセスが多数存在するためです。粗密なストライプ化は、同時要求が少ないシステムで使
用されると、ホット・スポットが生成される可能性があります。
従来の DSS 環境や同時実行性の低い OLTP システムなどの大きい I/O リクエストがほとん
ど存在しないシステムでは、ストライプ深度を小さく保つことが有益です。これはファイン
グレイン・ストライプ化と呼ばれます。そのようなシステムのストライプ深度は次のように
表されます。
n * DB_BLOCK_SIZE
n はマルチブロック読込みパラメータ（DB_FILE_MULTIBLOCK_READ_COUNT など）より
も小さくなります。
ファイングレイン・ストライプ化では、複数のディスクで単一 I/O リクエストを処理できま
す。ファイングレイン・ストライプ化では、個々の I/O リクエストまたは応答時間のパ
フォーマンスが最大化されます。
物理ストライプ境界とブロック・サイズ境界との位置合せ
一部の Oracle ポートでは、Oracle ブロック境界がストライプと揃わない可能性があります。
ストライプ深度が Oracle ブロックのサイズと同じである場合、Oracle から発行された単一
I/O によって 2 つの物理 I/O 操作が発生する場合があります。
これは、OLTP 環境では最適ではありません。1 つの論理 I/O で物理 I/O が 1 つのみ発生す
る確率が高くなるようにするには、最小のストライプ深度が Oracle ブロック・サイズの少
8-4　Oracle Database パフォーマンス・チューニング・ガイド
I/O の基本構成
なくとも 2 倍である必要があります。表 8-2 に、ランダム・アクセスおよび順次読取りでお
薦めする最小ストライプ深度を示します。
表 8-2 最小ストライプ深度
ディスク・アクセス
最小ストライプ深度
ランダム読込みおよび書込み
最小ストライプ深度は、Oracle ブロック・サイズの 2 倍です。
順次読取り
最小ストライプ深度は、Oracle ブロック・サイズを乗算した
DB_FILE_MULTIBLOCK_READ_COUNT の値の 2 倍です。
関連項目 :
プラットフォームの固有のマニュアル
提案されたシステムの管理可能性
LVM の場合、最も管理の簡単な構成は、使用可能なすべてのディスク上に単一ストライプ
化ボリュームを構成したものです。この場合、ストライプ幅はすべての使用可能なディスク
を包含します。すべてのデータベース・ファイルはそのボリューム内に常駐し、効果的に負
荷を均等分散します。この単一ボリューム・レイアウトは、ほとんどの状況で適切なパ
フォーマンスを実現します。
単一ボリューム構成は、RAID 1 などの簡単なリカバリを可能にする RAID 技術と併用する
場合のみ有効です。それ以外の場合、単一のディスクを失うことはすべてのファイルを同時
に失うことであり、完全なデータベースのリストアおよびリカバリを実行する必要があるこ
とを意味します。
パフォーマンスの他に、管理性の問題があります。システムの設計で、ディスクを簡単に追
加できるようにして、データベースの拡張を可能にする必要があります。課題は、負荷のバ
ランスを維持しながら拡張を行うことです。
たとえば、初期構成で、64 個の 16GB のディスク上に単一ストライプ化ボリュームを作成す
る必要があるとします。これはプライマリ・データの 1TB の合計ディスク領域になります。
場合によっては、システムが動作した後に、将来のデータベース拡張を可能にするためにさ
らに 80GB（すなわち、5 つのディスク）を追加する必要があります。
この領域をデータベースで使用できるようにするオプションには、5 つの新しいディスクを
含む第 2 のボリュームの作成があります。ただし、これらの新しいディスクがその上に配置
されたファイルに必要な I/O スループットを保持できない場合、I/O ボトルネックが発生す
る可能性があります。
もう 1 つのオプションは、元のボリュームのサイズを増やすことです。LVM は高度になり
つつあり、ストライプ幅の動的な再構成を可能にするので、システムがオンライン中にディ
スクを追加できます。このため、本番環境で単一ストライプ化ボリューム上にすべてのファ
イルを配置できるようになってきました。
I/O 構成および設計
8-5
I/O の基本構成
LVM がストライプへのディスクの動的な追加をサポートできない場合は、より小さく管理
しやすいストライプ幅を選択する必要があります。そのようにすると、新しいディスクを追
加する場合、ストライプ幅だけシステムを拡張できます。
前述の例で、8 個のディスクがより管理しやすいストライプ幅といえます。これは、8 個の
ディスクで 1 秒間に必要な数の I/O を維持できる場合のみ可能です。したがって、追加の
ディスク領域が必要なときは、別の 8 ディスク・ストライプを追加して、ボリューム間で
I/O のバランスを維持できます。
注意 : ストライプ幅が小さくなるほど、ボリューム上にファイルを分散
する時間の必要性が高くなり、このプロシージャは手動による I/O の分散
に近づきます。
手動による I/O の分散
システムに LVM またはハードウェアのストライプ化がない場合、各ファイルの I/O 要件に
従ってファイルを分散することにより、使用可能なディスク間で I/O を手動でバランス化す
る必要があります。ファイルの配置に関する決定を行うには、データベース・ファイルの
I/O 要件および I/O システムの機能についてよく理解している必要があります。このような
データに慣れておらず、解析対象の代表的なワークロードを取得できない場合は、まず推定
を行い、次に使用量がわかったときにこのレイアウトをチューニングします。
ディスクを手動でストライプ化するには、ファイルの記憶域要件を I/O 要件と関連付ける必
要があります。
1.
ファイルおよびディスクのサイズをチェックして、データベースのディスク記憶域要件
を評価します。
2.
1 ファイル当たりの予測 I/O スループットを識別します。最高の I/O 率を持つファイル
および多数の I/O を持たないファイルを判断します。I/O 率を均等にするために、すべ
ての使用可能なディスク上にファイルをレイアウトします。
手動 I/O 分散の一般的な方法として、頻繁に使用される表をその索引から分離することが
挙げられます。これは正しくありません。一連のトランザクション中は、索引が読み込まれ
てから表が読み込まれます。これらの I/O は順次に発生するので、表と索引を同じディスク
上に格納しても競合は発生しません。データファイルには索引や表データが含まれているた
め、これを単純に分離するだけでは十分ではありません。ファイルを分離する決定は、その
ファイルの I/O 率がデータベースのパフォーマンスに影響を与える場合にのみ行ってくださ
い。
8-6　Oracle Database パフォーマンス・チューニング・ガイド
I/O の基本構成
ファイルを分割する場合
オペレーティング・システムのストライプ化または手動 I/O 分散を使用するかどうかに関係
なく、I/O システムまたは I/O レイアウトが要求された I/O 率をサポートできない場合は、
I/O 率の高いファイルをそれ以外のファイルから分離する必要があります。このようなファ
イルは計画段階かシステムの本稼働後に確認できます。
ファイルを分離する決定は、I/O 率、リカバリ能力の問題、管理可能性の問題によってのみ
影響を受けます（たとえば、LVM がストライプ幅の動的な再構成をサポートしない場合、
同一構成の新しいストライプを作成して n 個のディスクを追加できるように、さらに小さい
ストライプ幅を作成する必要がある場合があります）
。
ファイルを分離する前に、ボトルネックが実際に I/O の問題であるかどうかを検証します。
ボトルネックの調査から生成されたデータでは、最高の I/O 率を持つファイルを識別しま
す。
関連項目 :
12-3 ページ「高負荷 SQL の識別」
表、索引および TEMP 表領域
I/O の多いファイルが表および索引を含む表領域に属するデータファイルである場合は、こ
れらのファイルの I/O を SQL のチューニングまたはアプリケーション・コードのいずれか
で削減できるかどうかを識別します。
I/O の多いファイルが TEMP 表領域に属するデータファイルである場合は、このアクティビ
ティを回避するためにディスク・ソートを実行する SQL 文をチューニングするか、あるい
はソートをチューニングするかを調べます。
不要な I/O を回避するようにアプリケーションをチューニングした後、I/O レイアウトが引
き続き必要なスループットを維持できない場合は、I/O の多いファイルの分離を考慮してく
ださい。
関連項目 :
12-3 ページ「高負荷 SQL の識別」
REDO ログ・ファイル
I/O の多いファイルが REDO ログ・ファイルである場合は、REDO ログ・ファイルをその
他のファイルから分離することを考慮してください。可能な構成には、次のことが含まれて
います。
■
■
すべての REDO ログを、他のファイルのない 1 つのディスクに置きます。可用性も考慮
します。すなわち、リカバリ能力の目的で、同じグループのメンバーは異なる物理ディ
スクおよびコントローラ上にあることが必要です。
他のファイルを格納しない個別のディスク上に各 REDO ログ・グループを置きます。
I/O 構成および設計
8-7
I/O の基本構成
■
■
オペレーティング・システムのストライプ化ツールを使用して、複数のディスクにまた
がって REDO ログ・ファイルをストライプ化します（この場合、手動ストライプ化は
不可能です）
。
REDO ログに RAID 5 を使用しないでください。
REDO ログ・ファイルは、ログ・ライター（LGWR）プロセスで順次書き込まれます。同じ
ディスクに対する同時実行アクティビティが存在しない場合、この操作はさらに高速にでき
ます。REDO ログ・ファイルに別々の専用ディスクを割り当てると、さらにチューニングし
なくても通常は LGWR が円滑に実行されます。システムが非同期 I/O をサポートせず、こ
の機能が現在構成されていない場合、この機能を使用することが有効かどうかを確認しま
す。LGWR に関連するパフォーマンス上のボトルネックはめったにありません。
アーカイブ REDO ログ
アーカイバが遅い場合、アーカイバ読込みと LGWR 書込みが分離されるようにして、アー
カイバ・プロセスと LGWR の間の I/O 競合を防止することが賢明です。これは、ログを代
替ドライブに置くことで達成されます。
たとえば、システムに 4 つの REDO ログ・グループが存在し、各グループが 2 つのメン
バーを持っているとします。個別ディスク・アクセスを作成するには、8 つのログ・ファイ
ルにそれぞれ 1a、1b、2a、2b、3a、3b、4a、4b のラベルを付けてください。この場合、最
低でも 4 つのディスクと、アーカイブ・ファイル用に 1 つのディスクが必要です。
図 8-1 は、競合を最小限にするために、ディスク間で REDO メンバーを分散する方法を示し
ています。
図 8-1 ディスク間での REDO メンバーの分散
8-8　Oracle Database パフォーマンス・チューニング・ガイド
I/O の基本構成
この例では、LGWR はログ・グループ 1（メンバー 1a と 1b）から切り替えられ、ロ
グ・グループ 2（2a と 2b）に書込みを行います。同時に、アーカイバ・プロセスはグ
ループ 1 から読込みをして、アーカイブ先に書込みを行います。REDO ログ・ファイル
がどのようにして競合から分離されているかに注意してください。
注意 : REDO ログ・ファイルをミラー化する、すなわち各 REDO ログ・
ファイルの複数のコピーを別々のディスク上に保持することで、LGWR が
大幅に遅くはなりません。LGWR は、各ディスクに対して並列して書込み
を行い、並列書込みの各部が完了するまで待機します。したがって、並列
書込みが、最も長い単一のディスク書込みよりも長くなることはありませ
ん。
REDO ログはシリアルに書き込まれるので、REDO ログ・アクティビティ専用のドライ
ブでは一般にヘッドの移動はわずかです。このため、ログ書込みのスピードが大幅に向
上します。
3 つの構成サンプル
この項では、I/O システムを構成する高水準の例を 3 つ示します。これらの例には、ディス
ク・トポロジやストライプ深度などを定義する計算例が含まれています。
すべてのディスクにまたがったすべての内容のストライプ化
I/O 構成の最も簡単なアプローチは、すべての使用可能ディスクにまたがってストライプ化
された、1 つの大きなボリュームを作成することです。リカバリ能力を考慮して、ボリュー
ムがミラー化されます（RAID 1）
。ディスク当たりのストライプ化の単位は、頻繁な I/O 操
作のための最大 I/O サイズより大きくする必要があります。そうすると、ほとんどの場合は
十分なパフォーマンスが得られます。
異なるディスクへのアーカイブ・ログの移動
アーカイブ・ログが他のファイルと同じディスク・セット上でストライプ化されている場
合、REDO ログがアーカイブされる際、これらのディスク上の I/O リクエストが影響を受け
るおそれがあります。個別のディスクにアーカイブ・ログを移動する場合の利点は次のとお
りです。
■
■
非常に高速なアーカイブを実行できます（順次 I/O を使用）
。
アーカイブ先のディスク上で応答時間が低下しても、その影響を受けるものは他にあり
ません。
アーカイブ・ログ用のディスク数は、アーカイブ・ログ生成頻度およびアーカイブ記憶域の
必要量により決定されます。
I/O 構成および設計
8-9
I/O の基本構成
個別のディスクへの REDO ログの移動
更新の多い OLTP システムでは、REDO ログは書込み中心です。他のディスクおよびアーカ
イブ REDO ログ・ファイルから分離されたディスクに REDO ログ・ファイルを移動すると、
次の利点があります。
■
■
REDO ログの書込みは、可能なかぎり高速で行われます。したがって、トランザクショ
ン処理のパフォーマンスは最高になります。
REDO ログの書込みが他の I/O で損なわれることはありません。
REDO ログ用のディスク数は、ほとんどの場合に、現行技術のディスク・サイズと比較して
一般に小さい REDO ログ・サイズで決定されます。一般に、2 つのディスクを持つ構成
（フォルト・トレランスのために 4 つのディスクにミラー化など）で十分です。特に、2 つの
ディスク上で REDO ログ・ファイルを交互に使用すると、1 つのファイルに REDO ログ情
報を書き込む場合、アーカイブの完了した REDO ログの読込みが妨げられません。
Oracle Managed Files
ファイル・システムを使用してすべての Oracle データを取り込むシステムの場合、データ
ベース管理は Oracle Managed Files を使用して簡単に行えます。表領域、テンポラリ・ファ
イル、オンライン・ログおよび制御ファイルについては、Oracle は内部的に標準ファイル・
システム・インタフェースを使用して、必要に応じてファイルを作成および削除します。管
理者は、特定のタイプのファイルに使用するファイル・システム・ディレクトリのみを指定
します。データファイルについてはデフォルトの場所を 1 つ、制御ファイルおよびオンライ
ン REDO ログ・ファイルについては複数の場所を最大 5 つ指定できます。
Oracle では、一意のファイルが作成された後、そのファイルが不要になると削除されます。
このため、管理者が誤ったファイルを指定したことにより発生する破損、および廃止された
ファイルで消費される無駄なディスク領域が減り、テスト・データベースおよび開発データ
ベースの作成が簡素化されます。また、オペレーティング・システム固有のファイル名を
SQL スクリプトに設定する必要がないため、ポータブルなサード・パーティのツールの開発
を容易にします。
新しいファイルは管理ファイルとして作成できますが、古いファイルは古い方法で管理され
ます。したがって、データベースには Oracle Managed Files と手動管理ファイルの両方を配
置できます。
注意 :
Oracle Managed Files は、RAW デバイスでは使用できません。
8-10　Oracle Database パフォーマンス・チューニング・ガイド
I/O の基本構成
Oracle Managed Files のチューニング
Oracle Managed Files をチューニングする場合はいくつかの点に注意する必要があります。
■
■
■
■
Oracle Managed Files ではファイル・システムを使用する必要があるため、DBA はデー
タのレイアウト方法は管理しません。したがって、ファイル・システムを正しく構成す
ることが重要です。
Oracle Managed Files システムは、ストライプ化をサポートする LVM 上に構築する必要
があります。ロード・バランシングおよびスループットの向上のために、Oracle
Managed Files システム内のディスクをストライプ化する必要があります。
Oracle Managed Files は、動的に拡張可能な論理ボリュームをサポートする LVM 上で使
用するときに最高の機能を発揮します。それ以外の場合は、論理ボリュームをできるだ
け大きく構成する必要があります。
Oracle Managed Files は、ファイル・システムに大きな拡張可能なファイルがある場合、
最高の機能を発揮します。
関連項目 : Oracle Managed Files の使用方法の詳細は、
『Oracle Database
管理者ガイド』を参照してください。
データ・ブロック・サイズの選択
8K のブロック・サイズはほとんどのシステムにとって最適です。ただし、OLTP システムで
はより小さなブロック・サイズを、DSS システムではより大きなブロック・サイズを使用す
ることがあります。この項では、最適なパフォーマンスを得るためにデータベース・ブロッ
ク・サイズを選択するときの考慮事項を説明します。
注意 : 管理性の問題があるため、単一データベース・インスタンスでの
複数のブロック・サイズの使用はお薦めしません。
読込み
データのサイズとは関係なく、目標は必要なデータを取り出すために必要な読込み回数を最
小にすることです。
■
■
■
■
行が小さく、アクセスがきわめてランダムな場合は、小さなブロック・サイズを選択し
ます。
行が小さく、アクセスがきわめて順次である場合は、大きなブロック・サイズを選択し
ます。
行が小さく、アクセスがランダムかつ順次である場合は、大きなブロック・サイズを選
択するのが有効です。
行が大きい（たとえば、ラージ・オブジェクト（LOB）データが含まれている）場合
は、大きなブロック・サイズを選択します。
I/O 構成および設計
8-11
I/O の基本構成
書込み
同時実行性の高い OLTP システムで、大きなブロック・サイズを使用する場合は、
INITRANS、MAXTRANS および FREELISTS の適切な値について検討します。これらのパラ
メータは、ブロック内で許可されている更新の同時実行性の程度に影響を与えます。ただ
し、自動セグメント領域管理を使用する場合は、FREELISTS の値を指定する必要はありま
せん。
選択する必要があるブロック・サイズが不明な場合、多数のトランザクションを処理するシ
ステムでは、8KB のデータベース・ブロック・サイズを試行してください。これは優れた妥
協案であり、通常は有効です。8KB を超えるサイズが必要なのは LOB データを処理するシ
ステムのみです。
関連項目 : 使用しているプラットフォームの最小および最大のブロック・
サイズは、オペレーティング・システム固有の Oracle マニュアルを参照
してください。
ブロック・サイズの長所と短所
表 8-3 は、様々なブロック・サイズの長所と短所を説明します。
表 8-3 ブロック・サイズの長所と短所
ブロック・
サイズ
小さい
長所
行数が少なく大量のランダム・アクセスに メタデータ（すなわち、ブロック・ヘッダー）による
適しています。
比較的大きな領域のオーバーヘッドがあります。
ブロック競合が低減されます。
大きい
短所
行が大きい場合にはお薦めできません。1 行がブロッ
クに収まらない場合、1 ブロック当たりの格納行数が
わずかになったり、さらには行の連鎖が発生する可能
性があります。
オーバーヘッドが少ないため、データを格 ブロック・サイズが大きい場合に少数の行にランダ
納する空間が多くなります。
ム・アクセスすると、バッファ・キャッシュ内の領域
が消費されます。たとえば、8KB のブロック・サイズ
1 回の I/O でバッファ・キャッシュに多数
と 50 バイトの行サイズでは、ランダム・アクセスを行
の行を読み込めます（行サイズおよびブ
うときにバッファ・キャッシュ内の 7,950 バイトが消
ロック・サイズにより異なります）。
費されます。
順次アクセスまたは非常に大きな行（LOB
OLTP 環境で使用される索引ブロックには適しません。
データなど）に適しています。
これは、索引リーフ・ブロック上のブロック競合が増
えるためです。
8-12　Oracle Database パフォーマンス・チューニング・ガイド
9
オペレーティング・システム・リソース
この章では、Oracle データベース・サーバーのパフォーマンスを最適化するためにオペレー
ティング・システムをチューニングする方法を説明します。
この章には次の項があります。
■
オペレーティング・システムのパフォーマンスの問題の理解
■
オペレーティング・システムの問題の解決
■
CPU について
■
システムの CPU 使用率の調査
関連項目 :
■
■
使用しているプラットフォーム固有の Oracle マニュアルおよび使用し
ているオペレーティング・システム・ベンダーのマニュアル
オペレーティング・システム統計情報の重要性の詳細は、5-5 ページ
の「オペレーティング・システム統計」を参照してください。
オペレーティング・システム・リソース
9-1
オペレーティング・システムのパフォーマンスの問題の理解
オペレーティング・システムのパフォーマンスの問題の理解
オペレーティング・システムのパフォーマンスの問題は、一般にプロセス管理、メモリー管
理およびスケジューリングに関係します。Oracle インスタンスをチューニングした後で、さ
らにパフォーマンスを改善する必要がある場合は、作業方法を検証するか、システム時間の
短縮を試行してください。I/O 帯域幅、CPU 能力およびスワップ・スペースが十分にあるこ
とを確認してください。ただし、オペレーティング・システムをさらにチューニングして
も、それがアプリケーションのパフォーマンスに大きな効果を与えることは期待できませ
ん。単にオペレーティング・システムをチューニングするよりも、Oracle の構成またはアプ
リケーションを変更する方が、オペレーティング・システムの効率を大きく変えます。
たとえば、アプリケーションで buffer busy waits が非常に頻繁に発生する場合は、システ
ム・コールの回数が増加します。アプリケーションをチューニングすることで buffer busy
waits を削減すると、システム・コールの数が減少します。
関連項目 : 使用しているプラットフォーム固有の Oracle マニュアルおよ
び使用しているオペレーティング・システム・ベンダーのマニュアル
オペレーティング・システムのキャッシュの使用
オペレーティング・システムとデバイス・コントローラが提供するデータ・キャッシュは、
Oracle のキャッシュ管理と直接は衝突しません。ただし、パフォーマンスにほとんど利益に
ならないですし、これらの構造ではリソースが消費されます。このことは、UNIX ファイ
ル・システムにデータベース・ファイルがある UNIX システムで最も顕著です。デフォルト
では、すべてのデータベース I/O はファイル・システム・キャッシュ内を通過します。一部
の UNIX システムでは、ファイル・システムへの直接 I/O が使用可能です。これによって、
データベース・ファイルは、ファイル・システム・キャッシュをバイパスして UNIX ファイ
ル・システム内でアクセスできます。これによって CPU リソースを節約でき、ファイル・
システム・キャッシュを、プログラム・テキストやスプール・ファイルなどのデータベース
以外のアクティビティ専用にできます。
この問題は Windows では発生しません。データベースから要求されたファイルは、すべて
ファイル・システム内のキャッシュをバイパスします。
Oracle バッファ・キャッシュのバッファ・ブロックの存在により、オペレーティング・シス
テムのキャッシュは冗長になる場合がありますが、Oracle が Oracle バッファ・キャッシュ
を使用しないこともよくあります。このような場合に、UNIX またはオペレーティング・シ
ステムのキャッシュがバイパスされる直接 I/O、またはオペレーティング・システムの
キャッシュが使用されない RAW デバイスを使用すると、オペレーティング・システムの
バッファリングを使用したときより、パフォーマンスが劣化することがあります。その場合
の例をいくつか示します。
9-2　Oracle Database パフォーマンス・チューニング・ガイド
オペレーティング・システムのパフォーマンスの問題の理解
■
一時表領域での読込みまたは書込み
■
NOCACHE LOB に格納されるデータ
■
パラレル問合せスレーブで読み込まれるデータ
オペレーティング・システム・レベルでキャッシュするファイルと、キャッシュしないファ
イルを混在させる必要がある場合があります。
非同期 I/O
同期 I/O では、I/O リクエストがオペレーティング・システムに発行されても、書込みの完
了が確認されないかぎり書込みプロセスによってブロックされます。処理はその後で継続で
きます。非同期 I/O で、I/O リクエストが発行されて処理されている間は処理が継続されま
す。ボトルネックを回避できる場合は非同期 I/O を使用します。
プラットフォームには、デフォルトで非同期 I/O をサポートしているもの、特殊な構成が必
要なもの、基礎となる一定のファイル・システム・タイプでのみ非同期 I/O をサポートして
いるものがあります。
FILESYSTEMIO_OPTIONS 初期化パラメータ
FILESYSTEMIO_OPTIONS 初期化パラメータを使用して、ファイル・システムのファイルに
ついて非同期 I/O あるいは直接 I/O を、有効化または無効化することができます。このパ
ラメータは、プラットフォーム固有であり、それぞれのプラットフォームに最適なデフォル
ト値が設定されています。このパラメータは、動的に変更して、デフォルト設定を更新でき
ます。
FILESYTEMIO_OPTIONS は、次のいずれかの値に設定できます。
■
■
ASYNCH: ファイル・システム・ファイル上の非同期 I/O を有効にします。非同期 I/O
では、転送に対する時間的な要件はありません。
DIRECTIO: ファイル・システム・ファイル上の直接 I/O を有効にします。直接 I/O で
は、バッファ・キャッシュがバイパスされます。
■
SETALL: ファイル・システム・ファイル上の非同期および直接 I/O を有効にします。
■
NONE: ファイル・システム・ファイル上の非同期および直接 I/O を無効にします。
関連項目 : 詳細は使用しているプラットフォーム固有のマニュアルを参
照してください。
オペレーティング・システム・リソース
9-3
オペレーティング・システムのパフォーマンスの問題の理解
メモリー使用量
メモリー使用量は、バッファ・キャッシュの制限と初期化パラメータの両方の影響を受けま
す。
バッファ・キャッシュの制限
UNIX バッファ・キャッシュはオペレーティング・システムのメモリー・リソースを消費し
ます。あるバージョンの UNIX では、UNIX バッファ・キャッシュに一定量のメモリーを割
り当てることができますが、現在ではより複雑なメモリー管理メカニズムが使用されるのが
普通です。通常これらの管理メカニズムでは、I/O をキャッシュするために空きメモリー・
ページを使用できます。そのようなシステムでは、オペレーティング・システムのレポー
ト・ツールは空きメモリーがないことを示すのが普通で、通常は問題になりません。プロセ
スがより多くのメモリーを必要とする場合、通常は I/O データをキャッシュするメモリーが
開放されて、そのプロセス・メモリーを割り当てることができます。
メモリー使用量に影響を与えるパラメータ
Oracle セッションから要求されるメモリーは多数の要因に依存します。一般的に、大きな要
因には次のものがあります。
■
オープン・カーソルの数
■
PL/SQL で使用されるメモリー（PL/SQL 表など）
■
SORT_AREA_SIZE 初期化パラメータ
Oracle では、PGA_AGGREGATE_TARGET 初期化パラメータを使用することにより、セッ
ションのメモリー使用量をより完全に制御できます。
オペレーティング・システムのリソース・マネージャの使用
一部のプラットフォームではオペレーティング・システム・リソース・マネージャが提供さ
れます。これらは、CPU のリソース割当てに優先順位を付けることによってピーク負荷使
用パターンの影響を少なくするように設計されています。これらは通常、ユーザーがアクセ
ス可能なリソースと各ユーザーがこれらのリソースのどの程度を消費可能かを統括する、管
理方針を実装します。
オペレーティング・システム・リソース・マネージャは、ドメインや類似のファシリティと
は異なります。ドメインは、1 つのシステム内で 1 つ、あるいは複数のまったく別の環境を
提供します。ディスク、CPU、メモリーおよびその他すべてのリソースがドメイン専用と
なっており、他のドメインからアクセスできません。他の類似のファシリティは、異なる領
域、通常個別の CPU またはメモリー領域へのシステム・リソースの一部として完全に分離
されています。ドメインと同様、個別のリソース領域はその領域に割り当てられた処理専用
となっています。プロセスは境界を超えて移行できません。ドメインとは異なり、その他す
べてのリソース（通常はディスク）は、システムのすべてのパーティションからアクセスで
きます。
9-4　Oracle Database パフォーマンス・チューニング・ガイド
オペレーティング・システムのパフォーマンスの問題の理解
Oracle はドメイン内で実行される他、パーティション化されたメモリー（RAM）リソース
の割当てが動的でなく、固定されている場合は、その他の不完全なパーティション構造体内
で実行されます。
注意 : Oracle は、メモリーが動的に割り当てられるリソース・パーティ
ション環境ではサポートされません。
オペレーティング・システム・リソース・マネージャは、リソースのグローバル・プール
内、通常はドメインあるいはシステム全体内でのリソース割当てに優先順位を設定します。
プロセスはグループに割り当てられ、グループはリソース・プール内の任意の場所にあるリ
ソースに割り当てられます。
注意 : オペレーティング・システム・リソース・マネージャのメモリー
管理および割当てファシリティと Oracle との併用はサポートされません。
Oracle インスタンス内でリソース割当て機能を提供する Oracle Database
Resource Manager は、オペレーティング・システムのリソース・マネー
ジャと併用することはできません。
注意 : オペレーティング・システム・リソース・マネージャで実行され
ている場合、Oracle は各インスタンスが専用オペレーティング・システ
ム・リソース・マネージャ・グループあるいは管理エンティティに割り当
てられている場合にのみサポートされます。また、すべてのインスタンス
のプロセスを実行している専用エンティティは、1 つの優先順位（または
リソース使用）レベルで実行される必要があります。異なる優先順位レベ
ルの個別の Oracle プロセスの管理は、サポートされません。インスタン
スの破壊などの重大な結果が発生します。
関連項目 :
■
■
オペレーティング・システムのリソース・マネージャ、および Oracle
と Oracle Database Resource Manager と併用して動作するリソース割
当て / 割当て解除機能の全リストについては、システム・ベンダーお
よび Oracle の代理店にお問い合せください。Oracle は特定リリース・
レベルとこれらのシステム機能との互換性を保証しません。
Oracle Database Resource Manager の詳細は、
『Oracle Database 管理
者ガイド』を参照してください。
オペレーティング・システム・リソース
9-5
オペレーティング・システムの問題の解決
オペレーティング・システムの問題の解決
この項では、様々なシステムでのチューニングのヒントを示します。次の項目について説明
します。
■
UNIX ベースのシステムのパフォーマンスに関するヒント
■
Windows システムのパフォーマンスに関するヒント
■
ミッドレンジおよびメインフレーム・コンピュータのパフォーマンスに関するヒント
プラットフォーム固有の問題をよく理解し、使用しているオペレーティング・システムが提
供するパフォーマンス・オプションを認識してください。
関連項目 : 使用しているプラットフォーム固有の Oracle マニュアルおよ
び使用しているオペレーティング・システム・ベンダーのマニュアル
UNIX ベースのシステムのパフォーマンスに関するヒント
UNIX システムでは、オペレーティング・システムが費やす時間量（システム・コールの処
理およびプロセス・スケジューリングの実行）とアプリケーションが実行する時間量の妥当
な比率を確立するようにしてください。システム・モードではなく、アプリケーション・
モード（ユーザー・モードとも呼ばれる）での実行に大部分の時間を費やすことを目標とし
てください。
各モードで消費される時間の比率は、潜在する問題の徴候にすぎず、次の項目に関係してい
る可能性があります。
■
ページングまたはスワッピング
■
実行しているオペレーティング・システム・コールが多すぎる状態
■
実行しているプロセスが多すぎる状態
このような条件が存在する場合は、アプリケーションの実行に使用できる時間は少なくなり
ます。オペレーティング・システム側の時間を多く解放するほど、アプリケーションが実行
できるトランザクションの量が増えます。
Windows システムのパフォーマンスに関するヒント
UNIX ベースのシステムと同様に、Windows システムでは、アプリケーション・モードの
時間とシステム・モードの時間の比率を適切に設定してください。Windows 管理パフォー
マンス・ツールで多数の要因を容易に監視できます。CPU、ネットワーク、I/O およびメモ
リーはすべて、これらの領域でのボトルネックを容易に回避できるように同じグラフ上に表
示されます。
9-6　Oracle Database パフォーマンス・チューニング・ガイド
CPU について
ミッドレンジおよびメインフレーム・コンピュータのパフォーマンスに関
するヒント
メインフレームのページング・パラメータを検討し、Oracle がパラメータの非常に大きな作
業セットを利用できることを覚えておいてください。
VAX または VMS 環境での空きメモリーは、どのオペレーティング・システム・プロセスに
も実際にマップされていないメモリーです。ビジーなシステムでは、1 つ以上の現行のアク
ティブ・プロセスに属するページを空きメモリーが含むことがよくあります。これがアクセ
スされると「ソフト・ページ・フォルト」が発生し、ページにはそのプロセスの作業セット
が組み込まれます。プロセスが作業セットを拡張できない場合は、プロセスによって現在
マップされているページの 1 つを空きセットに移動する必要があります。
任意の数のプロセスが、作業セット内に共有メモリーのページを持つことができます。した
がって、作業セットのサイズの合計が使用可能メモリーを著しく超過することがあります。
Oracle サーバーの実行中は、SGA、Oracle カーネル・コードおよび Oracle Forms ランタイ
ム実行可能ファイルは一般にすべて共有可能であり、アクセスされるページのおよそ 80%
または 90% に相当します。
CPU について
CPU の問題を扱うには、まずシステムが使用する CPU リソースの量について、適切な見積
りを設定します。次に、十分な CPU リソースが使用可能かどうかを判断し、システムがい
つリソースを使用しすぎているかを認識します。最初に、次の 3 つのシステムの状況につい
て Oracle インスタンスが利用する CPU リソースの量を判断します。
■
システムがアイドル状態（Oracle のアクティビティがほとんど存在しないか、Oracle 以
外のアクティビティが存在する）の場合
■
システムが平均ワークロードの場合
■
システムがピーク・ワークロードの場合
自動ワークロード・リポジトリ、Statspack または UTLBSTAT/UTLESTAT ユーティリティを
使用して、様々なワークロードのスナップショットを取得できます。UNIX の vmstat、
sar および iostat や、Windows の管理パフォーマンス監視ツールなどのオペレーティン
グ・システム・ユーティリティは、自動ワークロード・リポジトリ、Statspack、
UTLBSTAT/UTLESTAT などと同じ間隔で実行し、統計全体の補完ビューを提供する必要が
あります。
関連項目 :
■
■
5-10 ページ「自動ワークロード・リポジトリ」
Oracle ツールの詳細は、第 6 章「自動パフォーマンス診断」を参照し
てください。
オペレーティング・システム・リソース
9-7
CPU について
システムの CPU 使用率のレベルを評価するときには、ワークロードが重要な要因となりま
す。ピーク・ワークロード時には、CPU 使用率が 90% の場合アイドルは 10% であり、待機
時間が発生するのは受容できます。低ワークロード時に使用率が 30% となるのも理解でき
ます。しかし、システムが標準のワークロードで高い使用率を示している場合は、ピーク・
ワークロードに耐える余裕がありません。次に、図 9-1 において、午前 10:00 と午後 2:00 に
ピークとなるアプリケーションのワークロードの時間に伴う変化の例を示します。
図 9-1 平均のワークロードおよびピーク・ワークロード
この例のアプリケーションでは、1 日に 8 時間作業するユーザーが 100 人います。各ユー
ザーが 5 分ごとに 1 つのトランザクションを入力すると、1 日のトランザクションは 9,600
になります。8 時間にわたってシステムは 1 時間当たり 1,200 のトランザクションをサポー
トする必要があり、1 分当たり平均 20 トランザクションをサポートする必要があります。需
要率が一定の場合は、この平均ワークロードを満たすようにシステムを構築します。
ただし、使用率のパターンは一定ではないので、この場合、1 分当たり 20 トランザクション
というのは単なる最低条件と考えられます。達成する必要があるピークの割合が 1 分当たり
120 トランザクションの場合は、このピーク・ワークロードをサポートできるシステムを構
成する必要があります。
9-8　Oracle Database パフォーマンス・チューニング・ガイド
CPU について
この例で、ワークロードがピークのときに Oracle が CPU リソースの 90% を使用するとしま
す。その場合、ワークロードが平均の期間では、次の等式が示すように、Oracle は使用可能
な CPU リソースの 15% を使用するにすぎません。
20 tpm / 120 tpm * 90% = 15% of available CPU resource
ここで、tpm は 1 分当たりのトランザクション数を表します。
システムが 20 tpm を達成するために CPU リソースの 50% を必要とする場合は、問題があ
ります。これでは、CPU の 90% を使用しても 1 分当たり 120 トランザクションを処理でき
ません。ただし、CPU の 15% のみを使用して 20 tpm を達成するようにこのシステムを
チューニングした場合は、
（線状の拡張性を前提とすると）CPU リソースの 90% を使用して
1 分当たり 120 トランザクションを処理できます。
アプリケーションを使用するユーザーが増加するにつれて、ワークロードがかつてのピー
ク・レベルにまで上昇する可能性があります。そのときには、実際には以前よりも高くなっ
た新しいピークの割合に対応できる CPU 能力はありません。
CPU 能力の問題は、次の場合にも発生します。
■
■
チューニング（過剰消費となっている CPU の問題を検出し、解決するプロセス）する
場合。9-11 ページの「システムの CPU 使用率の調査」を参照してください。
システム・アーキテクチャの変更など、ハードウェア容量を増加する場合。
関連項目 : システム・アーキテクチャの向上の詳細は、2-7 ページの「シ
ステム・アーキテクチャ」を参照してください。
■
CPU のリソース割当てに優先順位を付けることにより、ピーク負荷使用パターンの影響
を少なくする場合。Oracle Database Resource Manager は、データベース・ユーザーと
アプリケーション間で CPU リソースを割り当て、管理することによって、これを行い
ます。
関連項目 : Oracle Database Resource Manager の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
オペレーティング・システム・リソース
9-9
CPU について
コンテキストのスイッチング
Oracle では、この項で説明する複数のコンテキストのスイッチング機能があります。
ポスト・ウェイト・ドライバ
Oracle プロセスは、別の Oracle プロセスをポスト（メッセージの送信）でき、さらにポス
トされるのを待機できる必要があります。
たとえば、フォアグラウンド・プロセスが LGWR をポストして、指定の時点までのブロッ
クをすべて書き出してコミットを承認するよう、LGWR に通知する必要があります。
このポスト・ウェイト・メカニズムは、UNIX のセマフォを使用して実装するのが普通です
が、これらのセマフォがリソース集中型である場合があります。したがって、一部のプラッ
トフォームでは、ポスト・ウェイト・ドライバを提供しています。通常は、ポスト・ウェイ
ト・インタフェースを簡単に実装できるカーネル・デバイス・ドライバが提供されます。
メモリーマップ済システム・タイマー
Oracle では、システム時間を問い合せてタイミング情報を得る必要が生じる場合がありま
す。その場合、オペレーティング・システム・コールが実行され、比較的コストのかかるコ
ンテキストのスイッチングが発生することがあります。一部のプラットフォームでは、メモ
リーマップ済タイマーを実装し、プロセス仮想アドレス空間のアドレスに現在のタイミング
情報を収集します。このメモリーマップ済タイマーから時間を読み込む方が、システム・
コールのコンテキストのスイッチングのオーバーヘッドよりも経済的です。
1 回のコールで複数の非同期 I/O を発行するリスト I/O インタフェース
リスト I/O とは、1 回のシステム・コールで複数の非同期 I/O リクエストを発行できる
Application Program Interface です。個別のシステム・コールで複数の I/O リクエストを発
行する必要がありません。この機能の主な利点は、コンテキストのスイッチングの所要回数
が減少することです。
9-10　Oracle Database パフォーマンス・チューニング・ガイド
システムの CPU 使用率の調査
システムの CPU 使用率の調査
Oracle の統計は、Oracle セッションの CPU 使用率のみをレポートしますが、使用可能な
CPU リソースには、システム上で実行しているすべてのプロセスが影響します。このため、
Oracle 以外の要因をチューニングするとパフォーマンスが向上することがあります。
オペレーティング・システムの監視ツールを使用して、システム全体で実行されているプロ
セスを確認してください。システムの負荷が非常に高い場合は、この項で後述するメモ
リー、I/O およびプロセス管理の各項目をチェックしてください。
多くの UNIX ベースのシステムにある sar -u などのツールを使用すると、システム全体で
の CPU 使用率のレベルを調べることができます。UNIX での CPU 使用率は、ユーザー時
間、システム時間、アイドル時間および I/O の待機時間を示す統計で説明されます。ワーク
ロードが標準または低いときに、アイドル時間と I/O の待機時間が両方とも 0 に近い（5%
未満である）場合は、CPU の問題が存在します。
Windows では、管理パフォーマンス・ツールを使用して CPU 使用率を監視します。この
ユーティリティは、プロセッサ時間、ユーザー時間、特権時間（privileged time）、割込み時
間および DPC 時間の統計を提供します
注意 : この項では、ほとんどの UNIX ベース・システムおよび Windows
システムにおける CPU 使用率のチェック方法を説明します。その他のプ
ラットフォームについては、使用しているオペレーティング・システムの
マニュアルを参照してください。
メモリー管理のチェック
次のメモリー管理項目をチェックします。
ページングとスワッピング
UNIX の sar あるいは vmstat などのユーティリティ、または Windows の管理パフォーマ
ンス・ツールなどを使用して、ページングとスワッピングの原因を調査します。
大きすぎるページ表
UNIX では、処理領域が大きくなりすぎると、ページ表が大きくなりすぎることがありま
す。これは Windows システムでは問題になりません。
オペレーティング・システム・リソース
9-11
システムの CPU 使用率の調査
I/O 管理のチェック
スラッシングは I/O 管理の課題です。マシンのスラッシング（メモリー内外のスワッピング
およびページング処理）が発生しないように、ワークロードをメモリーに適合させてくださ
い。オペレーティング・システムは固定サイズのタイム・スライスをユーザーのプロセスに
割り当て、プロセスはそのタイム・スライス中に CPU リソースを使用できます。プロセス
が実行可能かどうか、および必要な構成要素がすべてマシンにあるかどうかを確認するとき
に、プロセスが大半の時間を浪費すると、実際の作業の実行に割り当てられる時間はわずか
50% となることがあります。
関連項目 :
第 8 章「I/O 構成および設計」
ネットワーク管理のチェック
クライアント / サーバーのラウンドトリップをチェックします。メッセージを処理する際に
はオーバーヘッドが発生します。アプリケーションで多数のメッセージを生成し、ネット
ワークを介して送信する必要がある場合、メッセージ送信の待機時間によって CPU のオー
バーロードが発生することがあります。この問題を軽減するには、多数のラウンドトリップ
を実行せずに、複数のメッセージをまとめます。たとえば、配列挿入、配列フェッチなどを
使用できます。
プロセス管理のチェック
この項で説明するいくつかのプロセス管理の項目をチェックする必要があります。
スケジューリングとスイッチング
オペレーティング・システムはスケジューリングおよびスイッチング処理に大量の時間を消
費することがあります。使用しているプロセスが多すぎる場合があるので、オペレーティン
グ・システムの使用方法を検証してください。Windows システムでは、Oracle プロセス以
外の大量のプロセスによってサーバーが過負荷にならないようにしてください。
コンテキストのスイッチング
オペレーティング・システム固有の特性によって、システムがコンテキストのスイッチング
に大量の時間を消費することがあります。コンテキストのスイッチングは、特に超大規模
SGA の場合には不経済です。インスタンス当たりのプロセスが 1 つのみである Windows で
は、コンテキストのスイッチングは問題になりません。すべてのスレッドが同じページ表を
共有します。
オペレーティング・システムの新規プロセスの開始
オペレーティング・システムの新規プロセスを開始する際には高いコストがかかります。プ
ログラマは、単一目的のプロセスを生成し、そのプロセスを終了後に、また新規のプロセス
を生成することがよくあります。この場合、そのつどプロセスの再生成と破壊が行われま
す。この方法では、特に大規模な SGA を持つアプリケーションで CPU が集中して使用され
9-12　Oracle Database パフォーマンス・チューニング・ガイド
システムの CPU 使用率の調査
ます。これは、そのたびにページ表を構築する必要があるからです。共有メモリーを確保ま
たはロックするときは、すべてのページにアクセスする必要があるため、問題が増大しま
す。
たとえば、1GB の SGA がある場合は、4KB ごとにページ表のエントリがあり、1 つのペー
ジ表のエントリは 8 バイトになります。エントリのサイズの合計は（1G ÷ 4KB）× 8 バイ
トになります。ページ表がロードされていることを絶えず確認する必要があるので、これは
不経済になります。
オペレーティング・システム・リソース
9-13
システムの CPU 使用率の調査
9-14　Oracle Database パフォーマンス・チューニング・ガイド
10
パフォーマンス・ビューを使用した
インスタンスのチューニング
データベースの初期構成後は、インスタンスのチューニングがパフォーマンスのボトルネッ
クを解消するために重要になります。この章では、Oracle パフォーマンス・メソッドに基づ
いたチューニング・プロセスを説明します。
この章には次の項があります。
■
インスタンスのチューニング手順
■
Oracle 統計の解釈
■
待機イベント統計
■
アイドル待機イベント
パフォーマンス・ビューを使用したインスタンスのチューニング
10-1
インスタンスのチューニング手順
インスタンスのチューニング手順
次に、インスタンスのチューニング用の Oracle パフォーマンス・メソッドの主な手順を示
します。
1.
問題の定義
パフォーマンス問題の範囲についてユーザーから候補フィードバックを取得します。
2.
ホスト・システムの検査 および Oracle 統計の調査
■
■
■
3.
オペレーティング・システム、データベースおよびアプリケーション統計一式を取
得後に、パフォーマンスの問題の徴候を探すためにデータを調べます。
一般的なパフォーマンス・エラーのリストを検討して、収集されたデータが問題に
影響を与えていることを示しているかどうかを確認します。
収集されたパフォーマンス・データを使用して、何がシステムで起こっているかを
示す概念モデルを構築します。
変更の実装および測定
行う変更および変更を実装した場合に予測される結果を提示します。次に、変更を実装
してアプリケーション・パフォーマンスを測定します。
4.
手順 1 で定義したパフォーマンスの目的が達成されたかどうかを判断します。達成され
ていない場合は、パフォーマンスの目標が達成されるまで手順 2 と 3 を繰り返します。
関連項目 : このパフォーマンス・メソッドの理論的な説明および共通エ
ラーのリストについては、3-2 ページの「Oracle のパフォーマンス改善方
法」を参照してください。
この章の後半では、Oracle の動的パフォーマンス・ビューを使用したインスタンスのチュー
ニングについて説明します。ただし、拡張機能リストによる統計の収集、監視およびチュー
ニングには、自動ワークロード・リポジトリおよび Automatic Database Diagnostic Monitor
を使用することをお薦めします。5-10 ページの「自動ワークロード・リポジトリ」および
6-3 ページの「Automatic Database Diagnostic Monitor」を参照してください。
注意 : サイトに自動ワークロード・リポジトリおよび Automatic
Database Diagnostic Monitor 機能がない場合は、Statspack を使用して
Oracle インスタンス統計を収集できます。
10-2　Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
問題の定義
ソリューションの実装を試みる前に、チューニング調査の目的と問題の性質をよく理解して
おくことが不可欠です。これについて理解していないと、事実上、効果的な変更は実装でき
ません。この段階で収集されたデータを使用して、次に行うこと、および調査する事象を簡
単に決定できます。
次のデータを収集します。
1.
パフォーマンスの目的を識別します。
許容できるパフォーマンスの測定尺度は何ですか ?1 時間、または 1 秒間当たり何件の
トランザクションで、応答時間が必要なパフォーマンス・レベルを満たしますか ?
2.
問題の範囲を識別します。
スローダウンで何が影響を受けますか ? たとえば、インスタンス全体は低速ですか ? そ
れは、特定のアプリケーション、プログラム、特定の操作またはシングル・ユーザーで
すか ?
3.
問題が発生したときの時間帯を識別します。
その問題はピーク時間のみ明白ですか ? パフォーマンスはその日の経過に伴って低下し
ますか ? スローダウンは徐々に（月または週の単位で）発生しましたか、または突然発
生しましたか ?
4.
スローダウンを検証します。
これは、問題の範囲の識別に役立ち、問題の修復のために実装された変更により実際に
改善されたかどうかを判断するときの比較結果の測定基準としての役割を果たします。
一貫して再生可能な応答時間またはジョブ実行時間の測定値を検索します。プログラム
の動作が正常だったときよりタイミングがどのくらい悪化していますか ?
5.
変更を識別します。
パフォーマンスが許容可能になった後に変化した内容を識別します。これにより、潜在
的な原因を素早くつきとめることができます。たとえば、オペレーティング・システム
のソフトウェア、ハードウェア、アプリケーション・ソフトウェアまたは Oracle リ
リースがアップグレードされましたか ? さらに多くのデータがシステムにロードされた
か、データ・ボリュームまたはユーザー人口が増加しましたか ?
このフェーズの終わりまでに、症状についてよく理解しておく必要があります。症状をプロ
グラムまたはプログラム・セットにローカルなものとして識別できる場合、その問題はイン
スタンス全体のパフォーマンスの問題とは異なる方法で処理されます。
関連項目 : アプリケーションまたはユーザーに固有なパフォーマンスの
問題の解決については、第 12 章「SQL チューニングの概要」を参照して
ください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-3
インスタンスのチューニング手順
ホスト・システムの検査
データベース・サーバーに対する負荷とデータベース・インスタンスを調べてください。オ
ペレーティング・システム、I/O サブシステムおよびネットワーク統計を検討してくださ
い。これらの領域を調べると、調査する価値のあるものは何かが容易にわかります。多層の
システムでは、アプリケーション・サーバーの中間層ホストも調べてください。
ホスト・ハードウェアを調べると、システム内のボトルネックがよくわかります。このた
め、相互参照と以降の診断に役立つ Oracle パフォーマンス・データを判断できます。
調べるデータには、次のものがあります。
CPU の使用率
アイドル状態の CPU が大量にある場合、I/O、アプリケーションまたはデータベースのボト
ルネックが存在する可能性があります。ただし、wait I/O はアイドル状態の CPU とみなす
必要があります。
CPU 使用率が高い場合は、CPU が効果的に使用されているかどうかを判断してください。
CPU 使用率の大部分は、CPU 使用率の高い少数のプログラムによるものですか、または均
等に分散されたワークロードで CPU が消費されていますか ?
CPU が使用頻度の高い少量のプログラムで使用されている場合は、プログラムを調べて原
因を判断してください。一部のプロセスのみが 1 つの CPU の能力全体を使用しているかど
うかを確認してください。プロセスによっては、この情報は CPU またはプロセスにより
ワークロードがバインドされていることを示している場合があり、プロセス・アクティビ
ティを分割またはパラレル化することで解決できます。
Oracle 以外のプロセス プログラムが Oracle のプログラムではない場合は、それらのプログ
ラムがそのような量の CPU を必要としているかどうかを識別してください。必要としてい
る場合は、プログラムの実行をピーク以外の時間に遅らせることができるかどうかを判断し
ます。また、これらの CPU 集中型プロセスを識別すると、I/O、ネットワークおよびページ
ングなど、リソースを使用している特定のアクティビティと、それが Oracle ワークロード
にどのように関連付けられるかを絞り込むことができます。
Oracle プロセス 少量の Oracle プロセスがほとんどの CPU リソースを使用する場合は、
SQL_TRACE と TKPROF を使用して SQL 文または PL/SQL 文を識別し、特定の問合せまた
は PL/SQL のプログラム・ユニットをチューニングできるかどうかを確認します。たとえ
ば、CPU を多く使用するようなキャッシュ内の多数のデータ読込み（論理読込み）に関連
した SELECT 文があった場合、その文の SQL の最適化により CPU の集中的な使用を回避で
きます。
10-4　Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
Oracle CPU 統計 Oracle CPU 統計は、複数の V$ ビューで使用できます。
■
■
■
V$SYSSTAT は、すべてのセッションにおける Oracle の CPU 使用率を示します。CPU
used by this session 統計は、すべてのセッションで使用されている CPU の集計を
示します。parse time cpu 統計は、解析に使用された総 CPU タイムを示します。
V$SESSTAT は、各セッションにおける Oracle の CPU 使用率を示します。このビューを
使用して、特にどのセッションが CPU の大部分を使用しているかを判断します。
Oracle Database Resource Manager を実行している場合、V$RSRC_CONSUMER_GROUP
は、各コンシューマ・グループの CPU 使用率の統計を示します。
CPU 統計の解釈 CPU タイムと実時間が異なることを認識することが重要です。8 つの CPU
を使用する場合、実時間の所定の時間に、8 分の CPU タイムが利用できます。Windows お
よび UNIX では、これはユーザー時間またはシステム時間（Windows では特権モード）と
なります。したがって、システム上のすべてのプロセス（スレッド）で使用される平均
CPU タイムは、1 分の実時間間隔当たり 1 分を超える可能性があります。
ある時点での Oracle が使用したシステムの時間の長さはわかります。したがって、8 分が使
用可能で Oracle がそのうちの 4 分を使用している場合は、総 CPU タイムの 50% が Oracle
によって使用されていることがわかります。ユーザーのプロセスがその時間を消費していな
い場合は、他のプロセスが消費しています。CPU タイムを使用しているプロセスを識別し、
原因を解明し、それらのプロセスのチューニングを試行してください。第 20 章「アプリ
ケーション・トレース・ツールの使用方法」を参照してください。
CPU 使用率が多数の Oracle サーバー・プロセスに均一に分散している場合は、V$SYS_
TIME_MODEL ビューを調べると、最長時間が消費されているプロセスを正確に把握できま
す。10-16 ページの表 10-1「待機イベントおよび潜在的な原因」を参照してください。
I/O の問題の検出
過度にアクティブな I/O システムは、2 より大きいディスク・キューの長さ、すなわち、20
～ 30 ミリ秒を超えるディスク・サービス時間でわかります。I/O システムが過度にアク
ティブである場合、さらに多くのディスク間に I/O を分散させることで利益を得られる潜在
的なホット・スポットの有無をチェックします。また、これらのリソースを使用して、プロ
グラムのリソース要件を少なくして負荷を減らせるかどうかも識別します。
オペレーティング・システムの監視ツールを使用して、システム全体で実行されているプロ
セスを判別し、すべてのファイルに対するディスク・アクセスを監視してください。データ
ファイルと REDO ログ・ファイルを保持しているディスクは、Oracle に関連しないファイ
ルも保持している可能性があります。データベース・ファイルを含むディスクに対する過度
のアクセスを減らしてください。Oracle 以外のファイルへのアクセスは、V$ ビューを介し
てではなく、オペレーティング・システムの機能を介してのみ監視できます。
多数の UNIX システム上の sar -d（または iostat）や Windows システム上の管理パ
フォーマンス監視ツールなどのユーティリティは、システム全体の I/O 統計を調べます。
関連項目 : プラットフォームで使用可能なツールのオペレーティング・
システムのマニュアル
パフォーマンス・ビューを使用したインスタンスのチューニング
10-5
インスタンスのチューニング手順
V$SYSTEM_EVENT の Oracle 待機イベント・データをチェックして、トップの待機イベント
が I/O 関連かどうかを確認します。I/O 関連イベントには、db file sequential read、
db file scattered read、db file single write、db file parallel write および
log file parallel write が含まれます。これらはいずれも、データファイルおよびロ
グ・ファイルに対して実行された I/O に対応するイベントです。これらの待機イベントのう
ちのいずれかが高い平均時間に該当する場合は、I/O の競合を調べる必要があります。
自動ワークロード・リポジトリ・レポート内の I/O セクションでホスト I/O システム・
データを相互参照し、ホット・データファイルおよび表領域を識別します。さらに、オペ
レーティング・システムから報告された I/O 時間と、Oracle から報告された時間とを比較
して、それらに一貫性があるかどうかを確認します。
I/O の問題によって、I/O に関連しない待機イベントが明らかになる場合もあります。たと
えば、バッファ・キャッシュ内で空きバッファを検出できない場合や、ディスクへのログ書
込みが完了するまでの待機時間が長い場合も、I/O 問題の症状を示す場合があります。I/O
システムを再構成する必要があるかどうかを調べる前に、I/O システム上の負荷を減らせる
かどうかを判断します。Oracle I/O 負荷を減らすには、V$SQLAREA ビューを問い合せるか、
または自動ワークロード・リポジトリ・レポートの 'SQL ordered by Reads' セクションを確
認して、多数の物理読取りを実行する SQL 文を調べます。これらの文を調べて、I/O の回
数を減らすようにこれらの SQL 文をチューニングする方法を調べます。
SQL 文で発生した Oracle に関連する I/O の問題がある場合は、それをチューニングしてく
ださい。Oracle サーバーが使用可能な I/O リソースを使用していない場合、I/O をすべて
使用しているプロセスを識別します。プロセスが I/O をすべて使用している理由を判断し、
次にこのプロセスをチューニングします。
関連項目 :
■
■
■
■
第 12 章「SQL チューニングの概要」
動的パフォーマンス・ビュー V$SQLAREA の詳細は、
『Oracle
Database リファレンス』を参照してください。
第 8 章「I/O 構成および設計」
散布読取りと順次読取りの違いと、それが I/O に与える影響は、
10-26 ページの「db file scattered read」および 10-28 ページの「db
file sequential read」を参照してください。
ネットワーク
オペレーティング・システムのユーティリティを使用して、ネットワーク・ラウンドトリッ
プの ping 時間と衝突数を調べます。ネットワークで応答時間の大幅な遅延が発生している
場合は、考えられる原因を調べてください。
ネットワーク負荷を減らすには、大きいデータ転送をピーク時間外へスケジュールするか、
リモート・ホストに対して要求当たり 1 回ずつ（またはそれ以上）アクセスせずに、要求を
バッチ処理するようにアプリケーションをコーディングします。
10-6　Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
Oracle 統計の調査
問題の診断の一貫性が保たれるようにするには、Oracle 統計を調べてオペレーティング・シ
ステムの統計と相互参照してください。ただし、目標が Oracle インスタンスをチューニング
することにあれば、修正アクションを実装する前に Oracle 統計を調べて Oracle の観点から
リソース・ボトルネックを識別します。10-13 ページの「Oracle 統計の解釈」を参照してく
ださい。
チューニング中に使用する一般的な Oracle データ・ソースを次に示します。
統計収集のレベルの設定
Oracle では、初期化パラメータ STATISTICS_LEVEL を提供し、データベース内で主要統計
収集またはアドバイザをすべて制御します。このパラメータでは、データベースに統計収集
レベルを設定します。
STATISTICS_LEVEL の設定に応じて、次のように一定のアドバイザ機能または統計が収集
されます。
■
■
■
BASIC: アドバイザ機能も統計も収集されません。監視機能および多数の自動機能が使用
禁止になります。重要な Oracle 機能が使用禁止になるため、この設定は使用しないこ
とをお薦めします。
TYPICAL: これはデフォルト値であり、すべての主要統計が収集され、データベース全
体のパフォーマンスが最高になります。ほとんどの環境では、この設定で十分です。
ALL: TYPICAL 設定を使用して収集されるすべてのアドバイザ機能と統計に加えて、オ
ペレーティング・システム時間統計および行ソース実行統計が含まれます。
関連項目 :
■
■
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
STATISTICS_LEVEL、DB_CACHE_ADVICE、TIMED_STATISTICS ま
たは TIMED_OS_STATISTICS 初期化パラメータを設定する場合の考
慮事項は、5-7 ページの「統計の解釈」を参照してください。
V$STATISTICS_LEVEL このビューには、STATISTICS_LEVEL で制御される統計またはアドバ
イザ機能のステータスがリストされます。
関連項目 : 動的パフォーマンス・ビュー V$STATISTICS_LEVEL の詳細
は、
『Oracle Database リファレンス』を参照してください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-7
インスタンスのチューニング手順
待機イベント
待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示
すために、サーバー・プロセスまたはスレッドによって増やされる統計です。待機イベン
ト・データは、ラッチの競合、バッファの競合、I/O の競合などのパフォーマンスに影響を
与えると思われる様々な問題の症状を表します。ただし、これらの問題は実際の原因でな
く、問題の症状にすぎないことに注意してください。
待機イベントは、クラス別にグループ化されています。待機イベント・クラスには、
Administrative、Application、Cluster、Commit、Concurrency、Configuration、Idle、
Network、Other、Scheduler、System I/O、および User I/O があります。
サーバー・プロセスは、次の症状に対して待機します。
■
リソースが使用可能になるまで（バッファやラッチなど）
■
アクションが完了するまで（I/O など）
■
実行する追加作業（クライアントが次に実行する SQL 文を提供するまで待機する場合な
ど）サーバー・プロセスが追加作業の待機中であることを識別するイベントのことをア
イドル・イベントと呼びます。
関連項目 : Oracle 待機イベントの詳細は、『Oracle Database リファレン
ス』を参照してください。
待機イベント統計には、イベントを待機した回数や、イベントが完了するまでの待機時間が
あります。TIMED_STATISTICS 初期化パラメータを true に設定すると、各リソースを待
機した時間も表示されます。
ユーザー応答時間をできるだけ少なくするには、イベントが完了するまでサーバー・プロセ
スが待機する時間を減らします。すべての待機イベントが同じ待機時間を持っているとはか
ぎりません。したがって、発生回数の多い待機イベントより、最大の合計時間を持つイベン
トを調べるほうが重要です。通常は、少なくともパフォーマンスの監視中に TIMED_
STATISTICS 動的パラメータを true に設定することが最善です。STATISTICS_LEVEL の
設定の詳細は、10-7 ページの「統計収集のレベルの設定」を参照してください。
待機イベント統計を含む動的パフォーマンス・ビュー
待機イベント統計について、これらの動的パフォーマンス・ビューの問い合せを行うことが
できます。
■
V$ACTIVE_SESSION_HISTORY
V$ACTIVE_SESSION_HISTORY ビューには、1 秒ごとにサンプリングされたアクティ
ブなデータベース・セッションのアクティビティが表示されます。5-4 ページの
「Active Session History（ASH）
」を参照してください。
10-8　Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
■
V$SESS_TIME_MODEL および V$SYS_TIME_MODEL
V$SESS_TIME_MODEL および V$SYS_TIME_MODEL ビューには、データベース・コー
ルの所要時間合計である DB time など、時間モデル統計が含まれます。
■
V$SESSION_WAIT
V$SESSION_WAIT ビューには、アクティブ・セッションが待機中のリソースまたはイ
ベントが表示されます。
■
V$SESSION
V$SESSION ビューには、V$SESSION_WAIT ビューに含まれているのと同じ待機統計が
含まれています。該当する場合、このビューには、セッションが現在待機中のオブジェ
クトの詳細情報（オブジェクト番号、ブロック番号、ファイル番号および行番号）と現
在の待機の原因となったブロックしているセッションも含まれます。
■
V$SESSION_EVENT
V$SESSION_EVENT ビューは、セッションが開始した後に待機したすべてのイベントの
サマリーを示します。
■
V$SESSION_WAIT_CLASS
V$SESSION_WAIT_CLASS ビューは、待機数および各セッションの待機イベントの各ク
ラスで消費される時間を示します。
■
V$SESSION_WAIT_HISTORY
V$SESSION_WAIT_HISTORY ビューは、各アクティブ・セッションの最後の 10 個の待
機イベントを示します。
■
V$SYSTEM_EVENT
V$SYSTEM_EVENT ビューは、インスタンス起動後のインスタンスの、全イベント待機
のサマリーを示します。
■
V$EVENT_HISTOGRAM
V$EVENT_HISTOGRAM ビューには、待機数、最大待機時間および子カーソルごとの合
計待機時間を示すヒストグラムが表示されます。
■
V$FILE_HISTOGRAM
V$FILE_HISTOGRAM ビューには、ファイルごとに 1 ブロック読取り中の待機回数を示
すヒストグラムが表示されます。
■
V$SYSTEM_WAIT_CLASS
V$SYSTEM_WAIT_CLASS ビューは、待機数に対するインスタンス全体の総時間および
待機イベントの各クラスで消費される時間を示します。また、このビューはセッション
が待機しているオブジェクト番号も示します。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-9
インスタンスのチューニング手順
■
V$TEMP_HISTOGRAM
V$TEMP_HISTOGRAM ビューには、テンポラリ・ファイルごとに 1 ブロック読取り中の
待機回数を示すヒストグラムが表示されます。
関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リ
ファレンス』を参照してください。
パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・
データを調査します。最大時間がリストされるイベントは、多くの場合、パフォーマンス・
ボトルネックを顕著に示しています。たとえば、V$SYSTEM_EVENT を参照することで、多
くの buffer busy waits が発生していると気づくことがあります。おそらく、多数のプロ
セスが同じブロックに挿入しようとするときに、各プロセスが他のプロセスの挿入を待機し
てからでないと挿入できないことが原因です。問題となっているオブジェクトに自動セグメ
ント領域管理またはパーティション化を使用することで解決する可能性があります。
V$SESSION_WAIT、V$SESSION_EVENT および V$SYSTEM_EVENT の各ビューの差異の説
明は、10-21 ページの「待機イベント統計」を参照してください。
システム統計
システム統計は通常、パフォーマンスの問題の原因をさらに示すものを見つけるために、待
機イベント・データとともに使用されます。
たとえば、最大の待機イベント（待機時間の点で）が buffer busy waits イベントである
ことを V$SYSTEM_EVENT が示している場合、V$WAITSTAT ビューで使用できる特定のバッ
ファ待機統計を調べて、どのブロック・タイプが最大の待機カウントと最大の待機時間を
持っているかを識別します。
ブロック・タイプを識別した後、問題の発生中に V$SESSION をリアルタイムで調べるか、
問題の発生後に V$ACTIVE_SESSION_HISTORY および DBA_HIST_ACTIVE_SESS_
HISTORY を調べ、表示されたオブジェクト番号を使用して競合されたオブジェクトも識別
します。このデータの組合せは、適切な修正アクションを示しています。
統計は、多数の V$ ビューで使用できます。次の内容を含む共通ビューもあります。
V$ACTIVE_SESSION_HISTORY このビューには、1 秒ごとにサンプリングされたアクティブな
データベース・セッションのアクティビティが表示されます。5-4 ページの「Active Session
History（ASH）」を参照してください。
V$SYSSTAT これには、ロールバック、論理および物理 I/O、解析データなど、Oracle の様々
な部分の統計全体が含まれています。バッファ・キャッシュ・ヒット率などの比率を計算す
るには、V$SYSSTAT からのデータを使用します。
V$FILESTAT これには、ファイル当たりの I/O 回数や平均読込み時間など、ファイルごとの
詳細なファイル I/O 統計が含まれています。
10-10　Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
V$ROLLSTAT これには、詳細なロールバック・セグメントおよび UNDO セグメント統計が含
まれています。
V$ENQUEUE_STAT これには、エンキューが要求された回数やエンキューを待機した回数、待
機時間など、各エンキューの詳細なエンキュー統計が含まれています。
V$LATCH これには、各ラッチが要求された回数やラッチを待機した回数など、各ラッチの詳
細なラッチ使用統計が含まれています。
関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リ
ファレンス』を参照してください。
セグメント・レベルの統計
個別のセグメントに関連するパフォーマンス問題に焦点をあてるのに役立つ、セグメント・
レベルの統計を収集できます。セグメント・レベルの統計を収集して表示することは、イン
スタンスで競合度の高い表あるいは索引を効果的に識別するための優れた方法です。
パフォーマンスの問題を識別するために待機イベントおよびシステム統計を表示した後で、
セグメント・レベルの統計を使用して問題の原因となっている特定の表または索引を検索で
きます。バッファ・ビジー待機が、大半の待機時間の原因になっていることを V$SYSTEM_
EVENT が示している例を考えます。buffer busy waits の原因になっているトップ・セグメン
トを V$SEGMENT_STATISTICS から選択できます。これにより、それらのセグメントの問
題の解決に集中できます。
セグメント・レベルの統計は、次の動的ビューを使用して問い合せます。
■
■
■
V$SEGSTAT_NAME このビューには収集するセグメント統計と、各種統計（たとえばサ
ンプル統計など）のプロパティがリストされます。
V$SEGSTAT これは非常に効率的で、リアルタイム監視が可能なビューであり、統計
値、統計名およびその他の基本情報が表示されます。
V$SEGMENT_STATISTICS ユーザーが扱いやすい統計値のビューです。V$SEGSTAT の
すべての列の他、ここにはセグメント所有者や表領域名に関する情報があります。統計
の理解は容易になりますが、コストがより高くなります。
関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リ
ファレンス』を参照してください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-11
インスタンスのチューニング手順
変更の実装および測定
チューニングを実施した後、多くの場合、問題を軽減できると思われる 2 つまたは 3 つの変
更を識別できます。どの変更が最高の利益を提供するかを識別するには、一度に 1 回の変更
を実装することをお薦めします。変更の効果は、問題定義段階でみられたベースライン・
データ測定と対照して測定する必要があります。
一般に、パフォーマンスの問題を持つ大半のサイトでは、一度に重複した変更を実装するの
で、どの変更が利益を実現したかを識別できません。これはすぐに問題になることはありま
せんが、どの変更が最も効果をあげ、どのような作業を優先する必要があるかを知ることは
不可能なので、今後同様の問題が発生した場合に大きな障害になります。
個別に変更を実装できない場合は、異なる変更の効果の測定を試みてください。たとえば、
変更された問合せのパフォーマンスを向上するために新しい索引を作成する効果とは別に、
REDO の生成を最適化するために初期化変更を行う効果を測定します。SQL がチューニング
され、オペレーティング・システムのディスク・レイアウトが変更され、初期化パラメータ
も同時に変更されている場合は、オペレーティング・システムをアップグレードすることの
利益は測定できません。
パフォーマンス・チューニングは反復的なプロセスです。インスタンス・ワイドのパフォー
マンスの問題を解決する万全策が見つかることはほとんどありません。ほとんどの場合、あ
るボトルネックを解決しても別の（ときにはさらに悪い）問題が発生するため、優れたパ
フォーマンスにはパフォーマンス・チューニング段階を反復する必要があります。
いつチューニングを停止するかを知ることも重要です。パフォーマンスの最も優れた測定
は、統計が理想的な値にどの程度近いかではなく、ユーザーの理解力です。
10-12　Oracle Database パフォーマンス・チューニング・ガイド
Oracle 統計の解釈
Oracle 統計の解釈
インスタンスにパフォーマンスの問題があった時を示す統計を収集します。比較のための
ベースライン・データをすでに収集してある場合は、問題のワークロードを最も代表する
ベースラインからのデータと、現行のデータを比較できます。
2 つのレポートを比較する場合、それらのレポートが、システムを比較できるようなワーク
ロードか確認してください。
関連項目 :
5-2 ページ「データ収集の概要」
負荷の検査
待機イベントは通常、最初に検査するデータです。ただし、ベースライン・レポートがある
場合は、負荷が変化したかどうかをチェックします。ベースラインがあるかどうかにかかわ
らず、リソースの使用率が高いかどうかを確認すると便利です。
調査する負荷関連の統計には、redo size、session logical reads、db block
changes、physical reads、physical writes、parse count (total)、parse count
(hard) および user calls があります。このデータは、V$SYSSTAT から問合せが行われま
す。秒ごとおよびトランザクションごとに、このデータを正規化することが最も有効です。
自動ワークロード・リポジトリ・レポートの「ロード・プロファイル」の項を参照してくだ
さい。データは、トランザクションおよび秒ごとに正規化されています。
負荷の変更
秒ごとの負荷プロファイル統計は、スループットの変化（すなわち、インスタンスの作業実
行量が毎秒ごとに増えているかどうか）を示します。トランザクションごとの統計は、アプ
リケーション特性の変化をベースライン・レポートからの対応する統計と比較することで識
別します。
高いアクティビティ率
アクティビティ率が非常に高いかどうかを識別するには、秒ごとに正規化した統計を調べま
す。包括的に高い値を推薦することが難しいのは、しきい値が各サイトで異なり、アプリ
ケーション特性、CPU の個数と速度、オペレーティング・システム、I/O システムおよび
Oracle リリースで異なるからです。
次に、いくつかの一般化された例を示します（許容値は各サイトで異なります）
。
■
秒当たり 100 を超えるハード解析率は、非常に大量なハード解析がシステム上にあるこ
とを示します。高いハード解析率は重大なパフォーマンスの問題を発生させるので、調
査する必要があります。通常は、高いハード解析率に共有プール上のラッチの競合とラ
イブラリ・キャッシュ・ラッチが伴います。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-13
Oracle 統計の解釈
■
■
ライブラリ・キャッシュおよび共有プール・ラッチ・イベント（latch: library
cache、latch: library cache pin、latch: library cache lock および
latch: shared pool）の待機時間の合計が、V$SYSSTAT に表示される統計の DB
time に比べて大きいかどうかを調べます。大きい場合は、自動ワークロード・リポジ
トリ・レポートの SQL ordered by Parse Calls セクションを調べます。
高いソフト解析率は、秒当たり 300 以上の率になる可能性があります。不必要なソフト
解析もアプリケーションの拡張性を制限します。最適な方法として、SQL 文をセッショ
ン当たり 1 回ソフト解析し、何回も実行します。
待機イベント統計を使用したボトルネックへのドリルダウン
Oracle が何かの待機を処理する場合は必ず、定義済待機イベント・セットの 1 つを使用し、
待機を記録します。これらの待機イベントは、待機クラス別にグループ化されます。Idle 待
機クラスには、実行する作業がなく、さらに作業が実行されるのを待っている場合にプロセ
スが待機するイベントすべてがグループ化されます。アイドル状態でないイベントはリソー
スあるいはアクションが完了するまでの非生産的な待機時間を示します。
注意 : すべての症状が待機イベントによって証明されるわけではありま
せん。チェックできる統計については、10-18 ページの「追加された統計情
報」を参照してください。
待機イベント・データを使用する最も効率的な方法は、待機時間別にイベントを順序付けす
ることです。この方法は、TIMED_STATISTICS が true に設定されているときのみ可能で
す。設定しない場合は、待機イベントを待機数別に順位付けします。これは、一般的に問題
を最もよく表す順序付けではありません。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-7 ページの「統計収集のレ
ベルの設定」を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
どこで時間が消費されているかが判明してから、次の手順を実行してください。
1.
V$SYSTEM_EVENT のデータ収集を調べます。対象のイベントは、待機時間別に順位付
けする必要があります。
待機時間の最も大きいパーセンテージを持つ待機イベントを識別します。待機時間の
パーセンテージを決定するには、アイドル・イベント（Null event、SQL*Net
message from client、SQL*Net message to client および SQL*Net more data
to client など）を除くすべての待機イベントの合計待機時間を追加します。各イベン
10-14　Oracle Database パフォーマンス・チューニング・ガイド
Oracle 統計の解釈
トの待機時間をすべてのイベントの総待機時間で除算し、5 つの最も重要なイベントの
相対的なパーセンテージを計算します。
.
関連項目 :
■
■
■
アイドル待機イベントのリストは、10-47 ページの「アイドル待機イ
ベント」を参照してください。
V$EVENT_NAME ビューの説明は、
『Oracle Database リファレンス』を
参照してください。
待機イベント情報の詳細は、
『Oracle Database リファレンス』を参照
してください。
別の方法として、自動ワークロード・リポジトリ・レポートの先頭の「トップ 5 待機イ
ベント」の項を参照してください。この項では、待機イベント（アイドル・イベントを
除く）を自動的に順序付けし、相対的なパーセンテージを計算します。
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~
% Total
Event
Waits
Time (s) Call Time
-------------------------------------- ------------ ----------- --------CPU time
559
88.80
log file parallel write
2,181
28
4.42
SQL*Net more data from client
516,611
27
4.24
db file parallel write
13,383
13
2.04
db file sequential read
563
2
.27
状況によっては、同程度のパーセンテージを持つイベントがいくつか存在する場合があ
ります。このため、すべてのイベントが同じタイプのリソース要求（たとえば、すべて
が I/O 関連イベント）に関連している場合に、追加の証拠を提供できます。
2.
これらのイベントの待機数と平均待機時間を見てください。たとえば、I/O 関連イベン
トの場合、平均時間が I/O システムが低速であるかどうかを識別するのに役立つ場合も
あります。次に、自動ワークロード・リポジトリ・レポートの「Wait Event」の項から
引用した、このデータの例を示します。
Event
Waits Timeouts
--------------------------- --------- --------log file parallel write
2,181
0
SQL*Net more data from clie
516,611
0
db file parallel write
13,383
0
Avg
Total Wait
wait
Waits
Time (s)
(ms)
/txn
---------- ------ --------28
13
41.2
27
0
9,747.4
13
1
252.5
パフォーマンス・ビューを使用したインスタンスのチューニング
10-15
Oracle 統計の解釈
3.
トップの待機イベントは、次に調査する場所を識別します。表 10-1 に、一般的な待機イ
ベントを示します。高負荷 SQL を調べることもお薦めします。
4.
待機イベントで指示される関連データを調べて、このデータから得られる他の情報を確
認します。この情報が待機イベント・データとの一貫性を持っているかどうかを判断し
ます。ほとんどの場合、パフォーマンス・ボトルネックの潜在的な原因に関する理論の
展開を開始するためのデータは十分にあります。
5.
この理論が有効であるかどうかを判断するには、利用可能な他の統計ですでに調べた
データの一貫性をクロスチェックします。適切な統計は問題により異なりますが、通常
は V$SYSSTAT やオペレーティング・システム統計などにある、負荷のプロファイル関
連のデータが含まれています。他のデータとのクロスチェックを行って、展開中の理論
を肯定または否定します。
待機イベントおよび潜在的な原因の表
表 10-1 に、待機イベントと考えられる原因との関連付けの他、次に検討するのに最も有益と
思われる Oracle データの概要を示します。
表 10-1 待機イベントおよび潜在的な原因
待機イベント
一般的な領域
考えられる原因
検索 / 調査
buffer busy
waits
バッファ・
キャッシュ、
DBWR
バッファ・タイプによって
異なります。たとえば、索
引ブロックの待機は、昇順
に基づく主キーが原因であ
る場合があります。
問題が発生している間に V$SESSION を調べ、
競合したブロックのタイプを判別します。
free buffer
waits
バッファ・
キャッシュ、
DBWR、I/O
db file
scattered read
低速な DBWR
（おそらく I/O に起因）
小さすぎるキャッシュ
I/O、SQL 文の チューニングが適切ではな
い SQL
チューニング
低速な I/O システム
db file
I/O、SQL 文の チューニングが適切ではな
sequential read チューニング
い SQL
低速な I/O システム
10-16　Oracle Database パフォーマンス・チューニング・ガイド
オペレーティング・システム統計を使用して書
込み時間を調べます。キャッシュが小さすぎる
ことの証拠があるかどうかについてバッファ・
キャッシュ統計をチェックします。
V$SQLAREA を調べて、多数のディスク読込みを
実行する SQL 文があるかどうかを確認します。
I/O システムと V$FILESTAT をクロスチェック
して、長い読込み時間をチェックします。
V$SQLAREA を調べて、多数のディスク読込みを
実行する SQL 文があるかどうかを確認します。
I/O システムと V$FILESTAT をクロスチェック
して、長い読込み時間をチェックします。
Oracle 統計の解釈
表 10-1 待機イベントおよび潜在的な原因（続き）
待機イベント
一般的な領域
考えられる原因
検索 / 調査
ロック
エンキューのタイプにより
異なる
V$ENQUEUE_STAT を参照します。
SQL の解析または共有
V$SQLAREA を調べて、比較的多数の解析コール
または多数の子カーソルを使用する SQL 文があ
るかどうかを確認します（VERSION_COUNT
列）。V$SYSSTAT の解析統計と毎秒の対応する
割合を調べます。
log buffer
space
ログ・バッファ 小さいログ・バッファ
の I/O
低速な I/O システム
V$SYSSTAT の統計 redo buffer allocation
retries をチェックします。メモリーの構成の
章の、ログ・バッファの構成の項をチェックし
てください。オンライン REDO ログを格納する
ディスクをチェックして、リソースの競合の有
無をチェックします。
log file sync
I/O、コミット
過剰
enqueue 待機
（enq: で始まる
待機）
ライブラリ・キャッ ラッチの競合
シュ・ラッチ待機 :
library cache、
library cache
pin および
library cache
lock
オンライン・ログを格納す
る低速なディスク
バッチされないコミット
オンライン REDO ログを格納するディスクを
チェックして、リソースの競合の有無をチェッ
クします。V$SYSSTAT から毎秒のトランザク
ション数（コミット数＋ロールバック数）を
チェックします。
関連項目 :
■
■
表 10-1 にリストした各イベントの詳細およびクロスチェックするその
他の情報は、10-21 ページの「待機イベント統計」を参照してくださ
い。
動的パフォーマンス・ビューの詳細は、
『Oracle Database リファレン
ス』を参照してください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-17
Oracle 統計の解釈
追加された統計情報
対応する待機イベントを持たないパフォーマンスの問題を示すことのできる統計は多数あり
ます。
REDO ログ領域要求統計
V$SYSSTAT 統計の redo log space requests は、サーバー・プロセスが REDO ログ・
バッファ内の領域を待機するのではなく、オンライン REDO ログ内の領域を待機する必要
があった回数を示します。この統計と待機イベントの大きい値は、LGWR ではなく、チェッ
クポイント、DBWR、アーカイバ・アクティビティをチューニングする必要があることの標
識として使用する必要があります。ログ・バッファのサイズを増やしても効果がありませ
ん。
読取り一貫性
システムは、一貫したビューを維持するために、ブロックの変更内容のロールバックに長時
間を費やすことがあります。次の状況を考慮してください。
■
多数の小さいトランザクションがあり、変化が起こっている同じ表のバックグラウンド
内でアクティブな長時間実行問合せが動作している場合、表の一貫読取りイメージを取
得するために、問合せはこれらの変化を頻繁にロールバックする必要がある場合があり
ます。次の V$SYSSTAT 統計を比較して、変化が発生しているかどうかを判断します。
■
■
■
consistent changes 統計は、そのブロック上で読取り一貫性を実行するために、
データベース・ブロックがロールバック・エントリを適用した回数を示します。多
数の consistent changes を生成するワークロードは、多数のリソースを使用す
る可能性があります。
consistent gets 統計は、一貫したモードでの論理読込み数をカウントします。
大きいロールバック・セグメントがほとんどない場合、システムはトランザクションが
どの SCN にコミットされたかを正確に知るために、遅延ブロックのクリーンアウト時
に長時間かけてトランザクション表をロールバックする可能性があります。トランザク
ションのコミット時には、変更されたブロックすべてがコミット SCN で即時に更新さ
れるとはかぎりません。この場合は、ブロックの読取り時または更新時に必要に応じて
更新されます。これを遅延ブロック・クリーンアウトと呼びます。
次の V$SYSSTAT 統計の比率は、1 に近い値であることが必要です。
ratio = transaction tables consistent reads - undo records applied /
transaction tables consistent read rollbacks
解決策は、自動 UNDO 管理を使用することをお薦めします。
10-18　Oracle Database パフォーマンス・チューニング・ガイド
Oracle 統計の解釈
■
ロールバック・セグメントが十分にない場合、ロールバック・セグメント（ヘッダーま
たはブロック）の競合が発生します。この問題は、次のようにすると明らかになりま
す。
■
■
WAITS 数を V$ROLLSTAT 内の GETS 数と比較する方法。GETS に対する WAITS の比
率は小さい値である必要があります。
V$WAITSTAT を調べて、CLASS 'undo header' のバッファに対して多数の WAITS
があるかどうかを確認する方法。
解決策は、自動 UNDO 管理を使用することをお薦めします。
継続行による表フェッチ
V$SYSSTAT 内の table fetch continued row 統計数をチェックして、移行行または連鎖
行を検出できます。少数の連鎖行（1% 以下）は、システム・パフォーマンスに影響を与え
る可能性はほとんどありません。ただし、連鎖行のパーセンテージが大きいと、パフォーマ
ンスに影響を与える可能性があります。
ブロック・サイズより大きい行の連鎖は避けられません。そのようなデータについては、ブ
ロック・サイズのより大きい表領域の使用を考慮してください。
ただし、小さい行の場合は、適切な領域パラメータとアプリケーション設計を使用すること
で連鎖を回避できます。たとえば、キー値が入力され、かつその他のほとんどの列が NULL
である行を、実際のデータで更新しないでください。その行のサイズが大きくなります。そ
の場合は初めからデータが入力された行を挿入します。
UPDATE 文が行のデータ量を増やし、行がそのデータ・ブロックに収まらなくなった場合、
Oracle は行全体を保持するのに十分な空き領域を持つ別のブロックを見つけようとします。
そのようなブロックが利用可能であれば、Oracle は新しいブロックへ行全体を移動します。
これを行の移行と呼びます。行が大きすぎて利用可能なブロックに収まらない場合、Oracle
はその行を複数の断片に分割し、各断片を別々のブロックに格納します。これを行の連鎖と
呼びます。行は挿入時にも連鎖される可能性があります。
移行と連鎖は、特に次の場合のパフォーマンスに影響があります。
■
■
移行と連鎖の原因となる UPDATE 文のパフォーマンスはよくありません。
移行行または連鎖行が追加入出力を実行するため、これらの行を選択する問合せをしま
す。
サンプルの出力表 CHAINED_ROWS の定義が、配布媒体上の使用可能な SQL スクリプトに収
録されています。このスクリプトの一般的な名前は UTLCHN1.SQL ですが、正確な名前と位
置は使用しているプラットフォームによって異なります。出力表は、CHAINED_ROWS 表と
同じ列名、データ型およびサイズである必要があります。
移行行を回避するには、PCTFREE を増やします。ブロック内に使用可能な空き領域を多く
残しておくと、行の拡張に対処できます。削除割合が高い表と索引を再編成すなわち再作成
することもできます。頻繁に行が削除される表の場合は、データブロックに部分的に空き領
域が生じることがあります。行を挿入し後から拡張する場合、行の削除されたブロックにそ
パフォーマンス・ビューを使用したインスタンスのチューニング
10-19
Oracle 統計の解釈
の行が挿入されることがありますが、拡張の余地はありません。表を再編成すると主な空き
領域を完全に空のブロックにできます。
注意 :
PCTUSED は、PCTFREE の反対の意味ではありません。
関連項目 :
■
■
PCTUSED の詳細は、『Oracle Database 概要』を参照してください。
表の再編成の詳細は、
『Oracle Database 管理者ガイド』を参照してく
ださい。
解析関連の統計
アプリケーションの解析が長くなるほど、競合の可能性が高くなり、システムの待機時間が
長くなります。parse time CPU（CPU 解析時間）が CPU タイムの大半を占める場合、
SQL 文の実行ではなく解析に時間が消費されています。この場合には、アプリケーションは
リテラル SQL を使用しているために SQL を共有できないか、または共有プールの構成が適
切でないことがあります。
関連項目 :
第 7 章「メモリーの構成と使用方法」
Oracle による解析に費やす時間の範囲を識別するために、多数の統計が利用できます。
V$SYSSTAT から解析関連の統計の問合せを行います。たとえば、次のようにします。
SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME IN ( 'parse time cpu', 'parse time elapsed',
'parse count (hard)', 'CPU used by this session' );
解析が問題となるかどうかの判断を助けるために計算される、様々な比率があります。
■
parse time CPU / parse time elapsed
この比率は、解析に費やされる時間のうちのどのくらいが、ラッチなどのリソースに対
する待機ではなく、解析操作自体によるものかを示します。比率 1 は良好であり、経過
時間が競合率の高いリソースを待機するために費やされなかったことを示します。
■
parse time CPU / CPU used by this session
この比率は、Oracle サーバー・プロセスで使用される CPU 全体のうちのどのくらいが
解析関係の操作で費やされたかを示します。0（ゼロ）に近い値ほど良好であり、CPU
の大部分が解析に費やされないことを示します。
10-20　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
待機イベント統計
V$SESSION、V$SESSION_WAIT、V$SESSION_EVENT および V$SYSTEM_EVENT の各
ビューは、どのようなリソースを待機したかに関する情報を表示し、構成パラメータ
TIMED_STATISTICS が true に設定されている場合は、各リソースを待機した時間に関す
る情報も表示されます。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-7 ページの「統計収集のレ
ベルの設定」を参照してください。
V$ ビューおよび Oracle 待機イベントの詳細は、
『Oracle Database リ
ファレンス』を参照してください。
パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・
データを調査します。最大時間がリストされるイベントは、多くの場合、パフォーマンス・
ボトルネックを顕著に示しています。
次の各ビューには、同じデータの関連する（ただし、異なる）ビューが含まれています。
■
■
■
■
V$SESSION は、各現行セッションのセッション情報をリストします。このビューには、
現在待機されているイベントか、各セッションで最後に待機されたイベントがリストさ
れます。また、このビューには、セッションのブロックの情報も含まれます。
V$SESSION_WAIT は、現在の状態ビューです。このビューには、現在待機されている
イベントか、各セッションで最後に待機されたイベントがリストされます。
V$SESSION_EVENT は、各セッションで待機されるイベントの累積履歴をリストしま
す。セッションが終了した後、そのセッションに対する待機イベント統計はこのビュー
から削除されます。
V$SYSTEM_EVENT は、インスタンスの起動以降にインスタンス全体（すなわち、ロー
ルアップされた、すべてのセッション待機イベント・データ）により待機されるイベン
トと回数をリストします。
V$SESSION_WAIT は現在の状態ビューであるため、V$SESSION_EVENT または
V$SYSTEM_EVENT よりも細かい単位の情報も含まれています。このビューには、P1、P2 お
よび P3 の 3 つのパラメータ列で現行イベントの追加識別データが含まれています。
たとえば、V$SESSION_EVENT はセッション 124（SID=124）が db file scattered read
で多く待機していたことを示すことはできますが、どのファイルとブロック番号かは示しま
せん。ただし、V$SESSION_WAIT は P1 内のファイル番号、P2 内に読み込まれたブロック
番号および P3 内に読み込まれたブロック数を示します（P1 と P2 により待機イベントがど
のセグメントに対して発生するかを判断できます）
。
この章では、V$SESSION_WAIT の使用例を中心に説明します。ただし、時間間隔のパ
フォーマンス・データの収集と、パフォーマンスおよび容量分析のためにこのデータを保存
することをお薦めします。この形式のロールアップ・データの問合せは、自動ワークロー
パフォーマンス・ビューを使用したインスタンスのチューニング
10-21
待機イベント統計
ド・リポジトリにより V$SYSTEM_EVENT ビューから行います。5-10 ページの「自動ワーク
ロード・リポジトリ」を参照してください。
最も一般的に発生するイベントについては、この章で、大 / 小文字を区別するアルファベッ
ト順にリストして説明します。調べる対象の他のイベント関連データも含まれています。各
イベント名に使用する大 / 小文字区別は、V$SYSTEM_EVENT ビューでの表示と同一です。
関連項目 : V$SYSTEM_EVENT ビューの詳細は、『Oracle Database リファ
レンス』を参照してください。
SQL*Net イベント
次のイベントは、データベース・プロセスがデータベース・リンクまたはクライアント・プ
ロセスからの確認を待機していることを示します。
■
SQL*Net break/reset to client
■
SQL*Net break/reset to dblink
■
SQL*Net message from client
■
SQL*Net message from dblink
■
SQL*Net message to client
■
SQL*Net message to dblink
■
SQL*Net more data from client
■
SQL*Net more data from dblink
■
SQL*Net more data to client
■
SQL*Net more data to dblink
これらの待機がシステム上で、または応答時間の問題に対処しているユーザーに対して、待
機時間の大部分を占めている場合、ネットワークまたは中間層がボトルネックになる可能性
があります。
クライアント関連のイベントは、SQL*Net message from client イベントで説明したと
おりに診断する必要があります。dblink 関連のイベントは、SQL*Net message from
dblink イベントで説明したとおりに診断する必要があります。
SQL*Net message from client
これはアイドル・イベントですが、このイベントを診断に使用できるときに何が問題でない
かを説明することが重要です。このイベントは、サーバー・プロセスがクライアント・プロ
セスからの処理を待機していることを示します。ただし、このイベントが、長い応答時間を
経験しているユーザーの待機時間の大半を生成している状況がいくつかあります。その原因
は、ネットワーク・ボトルネックまたはクライアント・プロセスでのリソース・ボトルネッ
クのいずれかである可能性があります。
10-22　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
ネットワーク・ボトルネック ネットワーク・ボトルネックは、アプリケーションによって
サーバーとクライアントとの間で多量の通信が発生し、ネットワークの待機時間（ラウンド
トリップの時間）が長い場合に発生する可能性があります。症状には次のものがあります。
■
■
このイベントに対する多数の待機
データベースとクライアント・プロセスは、時間のほとんどがアイドル状態（ネット
ワーク通信待ち状態）です。
ネットワーク・ボトルネックを軽減するには、次のことを試行します。
■
■
■
アプリケーションをチューニングしてラウンドトリップを軽減します。
待機時間を削減するためのオプション（たとえば、VSAT リンクとは反対の地上回線）
を探索します。
通信量の大きいコンポーネントを待機時間の少ないリンクに移動するように、システム
構成を変更します。
クライアント・プロセス上のリソース・ボトルネック クライアント・プロセスがリソース
の大半を使用している場合、データベース内で実行できることはありません。症状には次の
ものがあります。
■
待機数は多くなくても、待機時間は長い。
■
クライアント・プロセスは、リソースを多く使用している。
場合によっては、クライアント・プロセスで使用される CPU の量により、待機している
ユーザーのトラッキングのための待機時間がわかります。この場合のクライアントという用
語は、n 層アーキテクチャにおける、データベース・プロセス（中間層、デスクトップ・ク
ライアント）以外の任意のプロセスを指します。
SQL*Net message from dblink
このイベントは、セッションがリモート・ノードにメッセージを送り、データベース・リン
クからの応答を待機している状態であることを意味します。この時間は、次の理由で増える
可能性があります。
■
ネットワーク・ボトルネック
詳細は、10-22 ページの「SQL*Net message from client」を参照してください。
■
リモート・ノードで SQL を実行するのに要する時間
リモート・ノードで実行されている SQL を確認することが有益です。リモート・デー
タベースにログインし、データベース・リンクで作成されたセッションを検索し、その
セッションで実行される SQL 文を調べます。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-23
待機イベント統計
■
ラウンドトリップ・メッセージの数
セッションとリモート・ノード間の各メッセージにより、遅延時間が長くなり、処理
オーバーヘッドが増加します。交換されるメッセージの数を減らすには、配列フェッチ
と配列挿入を使用します。
SQL*Net more data to client
サーバー・プロセスは、クライアントにさらに多くのデータまたはメッセージを送信しま
す。クライアントに対する以前の操作も送信されました。
関連項目 : ネットワーク最適化の詳細は、『Oracle Net Services 管理者ガ
イド』を参照してください。
buffer busy waits
この待機は、複数のプロセスが同時にアクセスしようとしているバッファ・キャッシュ内
に、いくつかのバッファがあることを示しています。バッファのクラスごとに、待機統計に
ついて V$WAITSTAT を問い合せます。buffer busy waits を持つ共通のバッファ・クラスと
して、data block、segment header、undo header および undo block などがありま
す。
次の V$SESSION_WAIT パラメータ列をチェックします。
■
P1 － ファイル ID
■
P2 － ブロック ID
■
P3 － クラス ID
原因
考えられる原因を判別するには、最初に V$SESSION を問い合せて、セッションが buffer
busy waits を待機しているときの ROW_WAIT_OBJ# の値を識別します。たとえば、次のよ
うにします。
SELECT row_wait_obj#
FROM V$SESSION
WHERE EVENT = 'buffer busy waits';
競合対象のオブジェクトとオブジェクト型を識別するには、V$SESSION から戻される ROW_
WAIT_OBJ# の値を使用して DBA_OBJECTS を問い合せます。たとえば、次のようにします。
SELECT owner, object_name, subobject_name, object_type
FROM DBA_OBJECTS
WHERE data_object_id = &row_wait_obj;
10-24　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
処置
必要な処置は、競合対象のクラスと実際のセグメントにより異なります。
セグメント・ヘッダー 競合がセグメント・ヘッダー上にある場合、これは最も起こりうる
空きリストの競合です。
ローカルに管理されている表領域で自動セグメント領域管理を行えば、PCTUSED、
FREELISTS および FREELIST GROUPS の各パラメータを指定する必要はありません。可能
であれば、手動領域管理から自動セグメント領域管理（ASSM）に切り替えます。
自動セグメント領域管理を使用できない（たとえば、表領域でディクショナリ領域管理を使
用している）場合は、次の情報が関係します。
空きリストは、通常セグメントの様々なエクステント内に存在するブロックを含む空きデー
タ・ブロックのリストです。空きリストは、空き領域が PCTFREE に達していないブロック、
または使用済領域が PCTUSED を下回っているブロックで構成されます。FREELISTS パラ
メータでプロセスの空きリスト数を指定します。FREELISTS のデフォルト値は 1 です。最
大値はデータ・ブロック・サイズによって決まります。
そのセグメントの空きリストに対する現在の設定を見つけるには、次を実行します。
SELECT
FROM
WHERE
AND
SEGMENT_NAME, FREELISTS
DBA_SEGMENTS
SEGMENT_NAME = segment name
SEGMENT_TYPE = segment type;
空きリスト、または空きリスト数の増分を設定します。さらに空きリストを追加しても問題
が軽減されない場合は、空きリスト・グループを使用します（このようにすると、単一のイ
ンスタンス内でも違いが出る可能性があります）
。Oracle Real Application Clusters を使用す
る場合は、インスタンスごとに独自の空きリスト・グループを持っていることを確認しま
す。
関連項目 : 自動セグメント領域管理、空きリスト、PCTFREE および
PCTUSED の詳細は、『Oracle Database 概要』を参照してください。
データ・ブロック 表または索引（セグメント・ヘッダーではない）に対する競合がある場
合、次のようにします。
■
■
昇順インデックスを調べます。これは、多数のプロセスによって同じ点に挿入される索
引です。たとえば、キー値に順序番号ジェネレータを使用する索引をチェックしてくだ
さい。
自動セグメント領域管理（ASSM）またはグローバル・ハッシュ・パーティション索引
を使用するか、空きリストを増やして複数のプロセスが同じブロック内に挿入されない
ようにすることを検討してください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-25
待機イベント統計
UNDO ヘッダー ロールバック・セグメント・ヘッダーに対する競合の場合
■
自動 UNDO 管理を使用しない場合は、さらにロールバック・セグメントを追加してく
ださい。
undo block ロールバック・セグメント・ブロックに対する競合の場合
■
自動 UNDO 管理を使用しない場合は、ロールバック・セグメント・サイズを大きくす
ることを検討してください。
db file scattered read
このイベントは、ユーザー・プロセスが SGA 内のバッファ・キャッシュにバッファを読み
取り、物理 I/O コールが戻るまで待機することを意味します。db file scattered read
は、データを複数の不連続メモリー位置に読み取るために散布読取りを発行します。散布読
取りは通常、マルチブロック読取りです。全体スキャンの他、
（索引の）高速全スキャンで
も行うことができます。
db file scattered read 待機イベントは、全体スキャンが発生していることを識別しま
す。バッファ・キャッシュへの全体スキャンを実行すると、読み取られたブロックは物理的
に相互に接近していないメモリー位置に読み取られます。そのような読取りが散布読取り
コールと呼ばれるのは、ブロックがメモリー全体に分散されているからです。対応する待機
イベントが「db file scattered read（DB ファイル散布読取り）」と呼ばれるのは、このため
です。バッファ・キャッシュへの全体スキャンのためのマルチブロック（最大で DB_FILE_
MULTIBLOCK_READ_COUNT ブロック）読取りは、db file scattered read に対する待機として
現れます。
次の V$SESSION_WAIT パラメータ列をチェックします。
■
P1 － 絶対ファイル番号
■
P2 － 読み込まれるブロック
■
P3 － ブロック数（1 より大きい値である必要がある）
処置
健全なシステムでは、物理読込み待機がアイドル待機後の最大待機である必要があります。
ただし、小さい索引付きアクセスを行う必要のある運用（OLTP）システム上に、ダイレク
ト読込み待機（パラレル問合せを持つ全表スキャンを意味する）または db file
scattered read 待機があるかどうかも確認してください。
システム上の過剰な I/O 負荷を示す他の要素として、次のものがあります。
■
■
低いバッファ・キャッシュ・ヒット率
ユーザーへの応答時間を長くしている待機時間のほとんどを発生させている待機イベ
ント
10-26　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
過剰な I/O の管理
過剰な I/O 待機を処理する方法はいくつかあります。有効性の順に示すと、これらの方法は
次のとおりです。
1.
SQL チューニングによる I/O アクティビティの削減。
2.
ワークロードの管理による、I/O を実行する必要性の削減。
3.
DBMS_STATS パッケージを使用したシステム統計の収集。これにより、問合せオプティ
マイザでは、全体スキャンを使用する、可能なアクセス・パスのコストを正確に計算で
きます。
4.
Automatic Storage Management の使用。
5.
さらに多くのディスクを追加することによる、各ディスクの I/O 数の削減。
6.
既存のディスク間への I/O の再配分による I/O ホット・スポットの削減。
関連項目 :
第 8 章「I/O 構成および設計」
最初に行うことは、I/O を削減するためのチャンスを見つけることです。これらのイベント
を待機するセッションを実行して SQL 文の調査を開始し、V$SQLAREA から多数の物理 I/O
を実行する文を調べます。過剰な I/O を実行し、実行計画にマイナスの影響を与える可能性
のある要因として、次のものがあります。
■
不適切に最適化された SQL
■
索引の欠落
■
表の高度な並列度（スキャン方向へオプティマイザを偏らせる）
■
オプティマイザの正確な統計がないこと
■
DB_FILE_MULTIBLOCK_READ_COUNT 初期化パラメータの設定値が全体スキャンには
大きすぎること
不十分な I/O 分散
I/O を削減する他、ディスク間のファイルの I/O 分散も調べます。I/O はディスク間に均等
に分散されていますか、あるいは、いくつかのディスク上にホット・スポットがありますか ?
データベースの I/O リクエストを満たすだけの十分な個数のディスクがありますか ?
データベースによる I/O 操作（読込みと書込み）の総数を調べ、それと使用したディスク数
を比較します。必ず、LGWR プロセスと ARCH プロセスの I/O アクティビティを含めてく
ださい。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-27
待機イベント統計
I/O を待機しているセッションで実行された SQL 文の検索
次の問合せを使用して、ある時点でどのセッションが I/O を待機しているかを判断します。
SELECT SQL_ADDRESS, SQL_HASH_VALUE
FROM V$SESSION
WHERE EVENT LIKE 'db file%read';
I/O を必要とするオブジェクトの検索
考えられる原因を判別するには、最初に V$SESSION を問い合せて、セッションが db file
scattered read を待機しているときの ROW_WAIT_OBJ# の値を識別します。たとえば、
次のようにします。
SELECT row_wait_obj#
FROM V$SESSION
WHERE EVENT = 'db file scattered read';
競合対象のオブジェクトとオブジェクト型を識別するには、V$SESSION から戻される ROW_
WAIT_OBJ# の値を使用して DBA_OBJECTS を問い合せます。たとえば、次のようにします。
SELECT owner, object_name, subobject_name, object_type
FROM DBA_OBJECTS
WHERE data_object_id = &row_wait_obj;
db file sequential read
このイベントは、ユーザー・プロセスが SGA 内のバッファ・キャッシュにバッファを読み
取り、物理 I/O コールが戻るまで待機することを意味します。順次読取りは、単一ブロック
読取りです。
単一ブロック I/O は通常、索引を使用した結果です。エクステント境界のため、すなわち、
バッファがすでにバッファ・キャッシュ内に存在するために全表スキャン・コールが単一ブ
ロック・コールに切り捨てられることはほとんどありません。これらの待機は、'db file
sequential read' としても表示されます。
次の V$SESSION_WAIT パラメータ列をチェックします。
■
P1 － 絶対ファイル番号
■
P2 － 読み込まれるブロック
■
P3 － ブロック数（1 とする必要がある）
関連項目 : 過剰 I/O の管理、不十分な I/O 分散、および I/O を発生させ
る SQL と I/O が実行されるセグメントの検索の詳細は、10-26 ページの
「db file scattered read」を参照してください。
10-28　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
処置
健全なシステムでは、物理読込み待機がアイドル待機後の最大待機である必要があります。
ただし、パラレル問合せを持つ、全表スキャンに近いスキャンの必要な大きいデータ・ウェ
アハウス上に、db file sequential reads があるかどうかも確認してください。
図 10-1 は、次の待機イベント間の違いを示したものです。
■
■
■
db file sequential read（1 つの SGA バッファに読み込まれる単一ブロック）
db file scattered read（多数の不連続 SGA バッファに読み込まれるマルチブロッ
ク）
direct read（PGA への単一またはマルチブロック読込み、SGA のバイパス）
図 10-1 scattered read、
、sequential read および direct read
パフォーマンス・ビューを使用したインスタンスのチューニング
10-29
待機イベント統計
direct path read および direct path read temp
あるセッションがバッファをディスクから PGA に直接読み込む（SGA 内のバッファ・
キャッシュとは反対）場合、このイベント上で待機します。I/O サブシステムが非同期 I/O
をサポートしない場合、各待機は物理読込み要求に対応します。
I/O サブシステムが非同期 I/O をサポートする場合、このプロセスでは読込み要求の発行
を、PGA にすでに存在するブロックの処理に重複させることができます。プロセスがディ
スクからまだ読み込まれていない PGA 内のブロックにアクセスしようとする場合、待機
コールを発行し、このイベントの統計を更新します。したがって、待機数は必ずしも読込み
要求数と同じではありません（db file scattered read および db file sequential
read とは異なります）。
次の V$SESSION_WAIT パラメータ列をチェックします。
■
P1 － 読込みコールの File_id
■
P2 － 読込みコールの Start block_id
■
P3 － 読込みコール内のブロック数
原因
これは次の状況で発生します。
■
■
■
ソートが大きすぎてメモリーに収まらないため、ソート・データの一部がディスクに直
接書き出される。そのデータは、ダイレクト読込みで後から再度読み込まれます。
パラレル・スレーブが、データのスキャンに使用される。
サーバー・プロセスが、I/O システムがバッファを戻すより早くバッファを処理する。
これは過負荷の I/O システムを示します。
処置
file_id は、読込みが TEMP 表領域内のオブジェクトに対するものか、パラレル・スレー
ブによる全表スキャンに対するものかを示します。これは、大きいデータ・ウェアハウス・
サイトに対する最大待機です。ただし、ワークロードが DSS ワークロードではない場合は、
これが発生している理由を調べます。
ディスクでのソート 待機が発生しているセッションで、現在実行されている SQL 文を調べ
て、ソートの原因を確認します。ソートを生成する SQL 文を検索するために、
V$TEMPSEG_USAGE を問い合せます。また、ソートのサイズを決定するセッションに関する
V$SESSTAT からの統計を問い合せます。SQL 文をチューニングしてソートを削減できるか
どうかを確認します。WORKAREA_SIZE_POLICY が MANUAL である場合、システム（ソート
が大きすぎない場合）または個々のプロセスの SORT_AREA_SIZE を大きくすることを検討
します。WORKAREA_SIZE_POLICY が AUTO である場合、PGA_AGGREGATE_TARGET を大
きくするかどうかを調べます。7-49 ページの「PGA メモリー管理」を参照してください。
10-30　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
全表スキャン 高い並列度で表を定義すると、全表スキャンをパラレル・スレーブで検索す
るようにオプティマイザを偏らせることができます。ダイレクト・パス読取りを使用して読
み取るオブジェクトをチェックします。全表スキャンがワークロードの有効な部分である場
合は、I/O サブシステムが並列度に対して適切に構成されているかどうかを確認します。
ディスクのストライプ化または Automatic Storage Management（ASM）を使用していない
場合は、ディスクのストライプ化を使用することを考慮してください。
ハッシュ領域サイズ ハッシュ結合を呼び出す問合せ計画の場合、過剰な I/O は HASH_
AREA_SIZE が小さすぎることから発生する可能性があります。WORKAREA_SIZE_POLICY
が MANUAL である場合、システムまたは個々のプロセスの HASH_AREA_SIZE を大きくする
ことを検討してください。WORKAREA_SIZE_POLICY が AUTO である場合、PGA_
AGGREGATE_TARGET を大きくするかどうかを調べます。
関連項目 :
■
10-27 ページ「過剰な I/O の管理」
■
7-49 ページ「PGA メモリー管理」
direct path write および direct path write temp
プロセスがバッファを PGA から直接書き込む（バッファ・キャッシュからバッファを書き
込む DBWR とは反対）場合、プロセスは書込みコールが完了するまでこのイベント上で待
機します。ダイレクト・パス書込みを実行できる操作には、ソートがディスクに移動すると
き、パラレル DML 操作時、ダイレクト・パス INSERT、パラレル作成表の選択時、および
いくつかの LOB 操作があります。
ダイレクト・パス読込みと同様に、I/O サブシステムが非同期書込みをサポートする場合、
待機数は発行された書込みコール数と同じではありません。セッションが PGA 内のすべて
のバッファを処理し、I/O リクエストが完了するまで作業を継続できない場合、セッション
は待機します。
関連項目 : ダイレクト・パス・インサートの詳細は、『Oracle Database
管理者ガイド』を参照してください。
次の V$SESSION_WAIT パラメータ列をチェックします。
■
P1 － 書込みコールの File_id
■
P2 － 書込みコールの Start block_id
■
P3 － 書込みコール内のブロック数
パフォーマンス・ビューを使用したインスタンスのチューニング
10-31
待機イベント統計
原因
これは次の状況で発生します。
■
ソートが大きすぎ、メモリー内に収まらないため、ディスクに書き込まれる。
■
オブジェクトを作成 / 移入するために、パラレル DML が発行される。
■
ダイレクト・パス・ロード。
処置
大きいソートについては、10-30 ページの「ディスクでのソート」を参照してください。
パラレル DML については、ディスク間の I/O 分散をチェックし、I/O サブシステムが並列
度の大きさに対して適切に構成されているかどうかを確認してください。
enqueue（
（enq:）待機
）待機
エンキューは、データベース・リソースへのアクセスを調整するロックです。このイベント
は、セッションが別のセッションで保持されているロックを待機していることを示します。
エンキュー名は待機イベント名の一部として enq: enqueue_type - related_details 形
式で含まれています。次の関連 TX タイプなど、同じエンキュー・タイプを異なる目的で保
持できる場合があります。
■
enq: TX - allocate ITL entry
■
enq: TX - contention
■
enq: TX - index contention
■
enq: TX - row lock contention
V$EVENT_NAME ビューには、すべての enq: 待機イベントのリストが表示されます。
次の V$SESSION_WAIT パラメータ列で追加情報を確認できます。
■
P1 － ロックの TYPE（または名前）および MODE
■
P2 － ロックのリソース識別子 ID1
■
P3 － ロックのリソース識別子 ID2
関連項目 : Oracle エンキューの詳細は、
『Oracle Database リファレン
ス』を参照してください。
10-32　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
ロックおよびロック・ホルダーの検索
ロックを保持するセッションを見つけるには、V$LOCK の問合せを行います。イベント・エ
ンキューを待機するすべてのセッションでは、REQUEST <> 0 を持つ V$LOCK 内に行があり
ます。次の 2 つの問合せのうちの 1 つを使用して、ロックを保持しているセッションとロッ
クを待機しているセッションを検索します。
エンキュー待機がある場合は、次の文を使用することによりこれらを確認できます。
SELECT * FROM V$LOCK WHERE request > 0;
待機中のロックのホルダーおよびウェイタのみを表示するには、次の文を使用します。
SELECT DECODE(request,0,'Holder: ','Waiter: ') ||
sid sess, id1, id2, lmode, request, type
FROM V$LOCK
WHERE (id1, id2, type) IN (SELECT id1, id2, type FROM V$LOCK WHERE request > 0)
ORDER BY id1, request;
処置
適切な処置は、エンキューのタイプにより異なります。
ST エンキュー 競合されたエンキューが ST エンキューである場合、問題は動的な領域割当
てにある可能性が最も高いと言えます。セグメントにそれ以上空き領域がない場合、Oracle
はセグメントにエクステントを動的に割り当てます。このエンキューは、ディクショナリ管
理表領域にのみ使用します。
このリソースに対する競合を解決するには、次のようにします。
■
■
一時（すなわち、ソート）表領域が TEMPFILES を使用するかどうかを確認します。使
用しない場合は、TEMPFILES を使用するように切り替えます。
動的に拡張するセグメントを含む表領域がディクショナリ管理表領域の場合は、ローカ
ル管理表領域を使用するように切り替えます。
関連項目 : TEMPFILE およびローカル管理表領域の詳細は、
『Oracle
Database 概要』を参照してください。
■
■
ローカル管理表領域に切り替えることができない場合は、拡張するオブジェクトの次の
エクステント・サイズを、一定の領域割当てを回避できる十分な大きさに変更すること
によって、ST エンキュー・リソースの使用量を減らすことができます。どのセグメント
が常に拡張するかを判断するには、すべての SEGMENT_NAME について DBA_SEGMENTS
ビューの EXTENTS 列を監視します。領域使用情報の表示の詳細は、『Oracle Database
管理者ガイド』を参照してください。
セグメント内の領域を事前に割り当てます。たとえば、ALTER TABLE ALLOCATE
EXTENT SQL 文でエクステントを割り当てる方法などです。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-33
待機イベント統計
HW エンキュー HW エンキューは、セグメントの最高水位標を超える領域の割当てをシリア
ライズする場合に使用します。
■
■
V$SESSION_WAIT.P2 / V$LOCK.ID1 は表領域番号です。
V$SESSION_WAIT.P3 / V$LOCK.ID2 は、領域が割り当てられるオブジェクトのセグ
メント・ヘッダーの相対 DBA です。
これがオブジェクトの競合点である場合、エクステントの手動割当てにより問題が解決され
ます。
TM エンキュー TM ロック上の待機の最も一般的な理由は、制約される列が索引付けされな
い場合の外部キー制約に関係している傾向があります。この問題を回避するには、外部キー
列を索引付けします。
TX エンキュー これらのロックは、トランザクションがその最初の変更を開始するときに排
他的に取得され、トランザクションが COMMIT または ROLLBACK を行うまで保持されます。
■
モード 6 の TX の待機は、あるセッションが別のセッションですでに保持されている行レ
ベル・ロックを待機しているときに発生します。これは、あるユーザーがある行を更新
または削除し、別のセッションがその行を更新または削除する場合に発生します。この
タイプのエンキュー待機は、待機イベント enq: TX - row lock contention に対応し
ます。
解決方法は、ロックをすでに保持している最初のセッションに COMMIT または
ROLLBACK を実行させることです。
■
モード 4 の TX の待機は、セッションがブロック内で ITL（必要なトランザクション・リ
スト）スロットを待機している場合に発生する可能性があります。これは、セッション
がそのブロック内の行をロックしても、1 つ以上の他のセッションの行が同じブロック
でロックされ、そのブロック内に空き ITL スロットがない場合に発生します。通常は、
Oracle が別の ITL スロットを動的に追加します。この操作は、ITL を追加するためのブ
ロック内の空き領域が十分にない場合には実行できません。空き領域が十分にある場合、
セッションはモード 4 で TX エンキューを持つスロットを待機します。このタイプの TX
エンキュー待機は、enq: TX - allocate ITL entry に対応します。
解決方法は、表の INITRANS または MAXTRANS を変更する（ALTER 文を使用するか、
それより高い値で表を再作成する）ことによって使用可能な ITL の個数を増やすことで
す。
■
モード 4 の TX の待機は、セッションが UNIQUE 索引内の潜在的な重複のためにセッショ
ンが待機している場合にも発生します。2 つのセッションが同じキー値を挿入しようと
する場合、第 2 のセッションは ORA-0001 が発生したかどうかを確認するまで、待機す
る必要があります。このタイプのエンキュー待機は、待機イベント enq: TX - row
lock contention に対応します。
解決方法は、ロックをすでに保持している最初のセッションに COMMIT または
ROLLBACK を実行させることです。
10-34　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
■
■
■
モード 4 の TX の待機は、共有ビットマップ・インデックス・フラグメントのためにセッ
ションが待機している場合にも可能です。ビットマップ索引は、キー値と ROWID の範
囲を索引付けします。ビットマップ索引内の各エントリは、実際の表中の多数の行をカ
バーできます。2 つのセッションが同じビットマップ・インデックス・フラグメントで
カバーされる行を更新する場合、第 2 のセッションは、モード 4 で TX ロックを待機し
て、第 1 のトランザクションの COMMIT または ROLLBACK を待機します。このタイプ
の TX エンキュー待機は、待機イベント enq: TX - row lock contention に対応しま
す。
モード 4 の TX の待機は、PREPARED トランザクションを待機している場合にも発生する
可能性があります。
モード 4 の TX の待機は、索引に 1 行を挿入するトランザクションが、他のトランザク
ションによる索引ブロック分割の終了を待つ必要がある場合にも発生します。このタイ
プの TX エンキュー待機は、待機イベント enq: TX - index contention に対応しま
す。
関連項目 : 参照整合性およびデータの明示的ロックの詳細は、『Oracle
Database アプリケーション開発者ガイド - 基礎編』を参照してください。
free buffer waits
この待機イベントは、サーバー・プロセスが空きバッファを検索できず、使用済バッファを
書き出すことによって空きバッファを作成するためにデータベース・ライターを転送したこ
とを示します。使用済バッファは、内容が変更されたバッファです。使用済バッファは、
DBWR がブロックをディスクに書き込み終えると、再利用するために解放されます。
原因
DBWR は、次の状況では使用済バッファの書込みを継続できない場合があります。
■
I/O システムが低速である。
■
I/O システムが待機しているラッチなどのリソースがある。
■
■
バッファ・キャッシュが小さすぎるため、DBWR はサーバー・プロセスのバッファのク
リーニングに大部分の時間を費やす。
バッファ・キャッシュが大きすぎるため、DBWR プロセスは要求を満たすだけのキャッ
シュ内のバッファを十分に解放できない。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-35
待機イベント統計
処置
このイベントが頻繁に発生する場合は、DBWR に対するセッション待機を調べて、DBWR
を遅らせる原因があるかどうかを確認してください。
書込み セッションが書込みを待機している場合は、書込みを遅らせている原因を解明し、
修正してください。次の点をチェックします。
■
■
V$FILESTAT を調べて、書込みの大半が発生する場所を確認してください。
I/O システムのホスト・オペレーティング・システム統計を調べてください。書込み時
間は許容できるものですか ?
I/O が低速である場合は、次のようにしてください。
■
■
さらに高速な I/O 手段を使用して書込み時間を高速化することを検討してください。
多数のスピンドル（ディスク）とコントローラの間に I/O アクティビティを拡散してく
ださい。I/O のバランス化については、第 8 章「I/O 構成および設計」を参照してくだ
さい。
キャッシュが小さすぎる場合 キャッシュが小さすぎるために DBWR が非常にアクティブで
ある可能性があります。バッファ・キャッシュ・ヒット率が低いかどうかを確認して、これ
が考えられる原因であるかどうかを調べます。また、V$DB_CACHE_ADVICE ビューを使用
して、それより大きいキャッシュ・サイズが有利かどうかを判断します。7-8 ページの
「バッファ・キャッシュのサイズ設定」を参照してください。
キャッシュが 1 つの DBWR に対して大きすぎる場合 キャッシュ・サイズが適切であり、I/O
がすでに均等に分散されている場合は、非同期 I/O を使用するか、複数のデータベース・ラ
イターを使用して、DBWR の動作を修正できます。
複数のデータベース・ライター（DBWR）
複数のデータベース・ライター（
）・プロセスまたは I/O スレーブ
の検討
複数のデータベース・ライター・プロセスを構成したり、I/O スレーブを使用するのは、ト
ランザクション・レートが高い場合や、バッファ・キャッシュ・サイズが大きすぎて単一の
DBWn プロセスが負荷に耐えられない場合に役立ちます。
DB_WRITER_PROCESSES DB_WRITER_PROCESSES 初期化パラメータを使用すると、複数の
データベース・ライター・プロセス（DBW0 から DBW9 までと、DBWa から DBWj）を構
成できます。複数の DBWR プロセスを構成すると、書き込まれるバッファの識別に必要な
作業が分散され、また、これらのプロセス間に I/O 負荷もが分散されます。複数のデータ
ベース・ライター・プロセスは、複数の CPU を持つシステム（CPU 8 つにつき最低 1 つの
データベース・ライター）や、複数のプロセッサ・グループを持つシステム（最低でプロセ
ス・グループと同数のデータベース・ライター）にお薦めします。
CPU の数またはプロセッサ・グループの数に基づいて、Oracle は、適切な DB_WRITER_
PROCESSES のデフォルト設定を選択するか、ユーザー定義の設定を調整します。
10-36　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
DBWR_IO_SLAVES 複数の DBWR プロセスを使用することが実用的ではない場合、Oracle に
は複数のスレーブ・プロセス間に I/O 負荷を分散できる機能があります。DBWR プロセス
は、ブロックを書き出すためにバッファ・キャッシュ LRU リストをスキャンする唯一のプ
ロセスです。ただし、これらのブロックの I/O は I/O スレーブで実行されます。I/O ス
レーブの個数は、DBWR_IO_SLAVES パラメータで決定されます。
DBWR_IO_SLAVES は、
（CPU が 1 つの場合など）複数の DB_WRITER_PROCESSES を使用
できない場合を想定しています。I/O スレーブは、非同期 I/O が使用できないときにも役立
ちます。書き込まれるキャッシュ内のブロックの識別を継続するために DBWR を解放する
ことによって、複数の I/O スレーブが非ブロッキング要求をシミュレートするからです。一
般的に、非同期 I/O がある場合、オペレーティング・システム・レベルの非同期 I/O をお
薦めします。
DBWR の I/O スレーブは、初回の I/O リクエストが実行されるときに、データベースが開
いた直後に割り当てられます。DBWR は、I/O の実行とは別に、DBWR 関連のすべての作
業の実行を継続します。I/O スレーブは単に、DBWR のために I/O を実行します。バッチ
の書込みは I/O スレーブ間でパラレル化されます。
注意 : DBWR_IO_SLAVES を実装するには、余分な共有メモリーを I/O
バッファと要求キューに割り当てる必要があります。複数の DBWR プロ
セスを I/O スレーブと併用することはできません。I/O スレーブを構成す
ると、1 つの DBWR プロセスのみ起動するように設定されます。
複数の DBWR プロセスと I/O スレーブの選択 複数の DBWR プロセスを構成すると、単一の
DBWR プロセスが、必要なワークロードに耐えられないときのパフォーマンスに有益です。
ただし、複数の DBWR プロセスを構成する前に、非同期 I/O が使用でき、システム上に構
成されるかどうかを確認します。システムが非同期 I/O をサポートしても現在使用されてい
ない場合は、複数の DBWR プロセスを構成すると問題が軽減されるかどうかを確認するた
めに非同期 I/O を使用可能にします。システムが非同期 I/O をサポートしない場合、また
は非同期 I/O がすでに構成され、DBWR ボトルネックが依然として存在する場合は、複数
の DBWR プロセスを構成します。
注意 : プラットフォーム上で非同期 I/O を使用できない場合は、DISK_
ASYNCH_IO 初期化パラメータを FALSE に設定して非同期 I/O を無効に
できます。
複数の DBWR を使用すると、バッファの収集と書込みがパラレル化されます。そのため、
複数の DBWn プロセスは同じ数の I/O スレーブを使用する 1 つの DBWR プロセスよりもス
ループットを向上します。このため、複数の DBWR プロセスを優先して、I/O スレーブは
使用されなくなりました。I/O スレーブは、複数の DBWR プロセスを構成できない場合の
み使用してください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-37
待機イベント統計
ラッチ・イベント
ラッチは、メモリー構造を保護するために Oracle で使用される下位レベルの内部ロックで
す。ラッチ解放イベントは、サーバー・プロセスがラッチを取得しようとしたときに更新さ
れ、ラッチは最初の試行で使用できなくなります。
通常は大きな競合を生成する一般的なラッチ用に、専用のラッチ関連待機イベントがありま
す。これらのイベントの場合は、latch: library cache または latch: cache buffers
chains のように、ラッチ名が待機イベント名に含まれます。このため、ラッチに関連する
ほとんどの競合の原因が特定のタイプのラッチであるかどうかをすばやく確認できます。他
のすべてのラッチの待機は、汎用の latch free 待機イベントにグループ化されています。
関連項目 : ラッチおよび内部ロックの詳細は、『Oracle Database 概要』
を参照してください。
処置
このイベントは、ラッチ待機がシステム上の待機時間全体の重要な部分である場合か、また
は問題が発生している個々のユーザーに対してのみかを考慮してください。
■
■
関連するリソースのリソース使用量を調べます。たとえば、ライブラリ・キャッシュ・
ラッチの競合が大きい場合は、ハードとソフトの解析率を調べます。
ラッチ競合が発生しているセッションの SQL 文を調べて、共通性があるかどうかを確認
してください。
次の V$SESSION_WAIT パラメータ列をチェックします。
■
P1 － ラッチのアドレス
■
P2 － ラッチ番号
■
P3 － すでにスリープしたプロセスの回数
例 : 現在待機されているラッチの検索
SELECT EVENT, SUM(P3) SLEEPS, SUM(SECONDS_IN_WAIT) SECONDS_IN_WAIT
FROM V$SESSION_WAIT
WHERE EVENT LIKE 'latch%'
GROUP BY EVENT;
前述の問合せには、インスタンスまたは長期的なインスタンスのチューニングよりも、セッ
ションのチューニングまたは短期的なインスタンスのチューニングに関して多くの情報が示
されるという問題があります。
次の問合せは長期的なインスタンス・チューニングの詳細情報を提供し、ラッチの待機が
データベース全体の時間に占める割合が大きいかどうかを示します。
10-38　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
SELECT EVENT, TIME_WAITED_MICRO,
ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME
FROM V$SYSTEM_EVENT,
(SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S
WHERE EVENT LIKE 'latch%'
ORDER BY PCT_DB_TIME ASC;
ラッチ待機固有でない、より汎用的な問合せは次のようになります。
SELECT EVENT, WAIT_CLASS,
TIME_WAITED_MICRO,ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME
FROM V$SYSTEM_EVENT E, V$EVENT_NAME N,
(SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S
WHERE E.EVENT_ID = N.EVENT_ID
AND N.WAIT_CLASS NOT IN ('Idle', 'System I/O')
ORDER BY PCT_DB_TIME ASC;
表 10-2 ラッチ解放イベント
ラッチ
SGA 領域
考えられる原因
検索対象
共有プール、
ライブラリ・
キャッシュ
共有プール
文の再利用不足
次の項目が高いセッション（V$SESSTAT
内）
バインド変数を使用しない文
アプリケーション・カーソル・キャッシュの
サイズが不十分
各実行後に明示的にクローズされたカーソル
■
CPU 解析時間
■
所要解析時間
■
頻繁なログオン / ログオフ
基礎的なオブジェクト構造の変更（たとえ
ば、切捨て）
小さすぎる共有プール
■
解析カウント（ハード）/ 実行カウント
の比率
解析カウント（合計）/ 実行カウントの
比率
次のカーソル（V$SQLAREA/V$SQL 内）
■
■
PARSE_CALLS / EXECUTIONS の高い
比率
EXECUTIONS = 1 WHERE 句のリテラル
のみ異なる（すなわち、バインド変数
を使用しない）
■
高い RELOADS
■
高い INVALIDATIONS
■
大きい（> 1MB）SHARABLE_MEM
パフォーマンス・ビューを使用したインスタンスのチューニング
10-39
待機イベント統計
表 10-2 ラッチ解放イベント（続き）
ラッチ
SGA 領域
考えられる原因
キャッシュ・
バッファ LRU
連鎖
バッファ・
キャッシュ
LRU リスト
過剰なバッファ・キャッシュ・スループッ
論理 I/O または物理 I/O が非常に多く、選
ト。たとえば、正しくない索引に繰り返しア 択性のない索引が使用される文
クセスする非効率的な SQL（大きい索引レン
ジ・スキャン）、または多くの全表スキャン
があります。
検索対象
実行中のワークロードに耐えられない
DBWR。これにより、フォアグラウンド・プ
ロセスが空きバッファを検索するためにラッ
チを保持する時間が長くなります。
小さすぎるキャッシュ
キャッシュ・
バッファ連鎖
バッファ・
キャッシュ
ホット・ブロックと呼ばれる 1 つ（または少 順序番号ジェネレータを使用せずに番号を生
成するための、表の行を更新する順序番号生
数）のブロックへのアクセスの繰返し
成コード
非常に多くのプロセスが、きわめて類似した
述語を使用して選択性のない同一の索引をス
キャンすることから発生する、索引リーフ・
ブロックの競合
ホット・ブロックが属するセグメントの識別
行キャッシュ・
オブジェクト
共有プールとライブラリ・キャッシュ・ラッチの競合
共有プールまたはライブラリ・キャッシュ・ラッチの競合の主な原因は解析です。不要な解
析および不要な解析の様々なタイプの識別に使用できる手法は多数あります。
非共有 SQL この方法では、リテラルがバインド変数と置換された場合に共有できる類似し
た SQL 文を識別します。その概念は次のいずれかです。
■
実行を 1 つのみ持つ SQL 文を手動で検査して、SQL 文が類似しているかどうかを確認し
ます。
SELECT
FROM
WHERE
ORDER
■
SQL_TEXT
V$SQLAREA
EXECUTIONS < 4
BY SQL_TEXT;
類似した文である可能性がある文をグループ化することによって、このプロセスを自動
化します。これを行うには、同じものである可能性の高い SQL 文のバイト数を予測し、
そのバイト数によって SQL 文をグループ化します。たとえば、次の例では、最初の 60
バイトまでが同一で、その後が異なる文をグループ化します。
10-40　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
SELECT SUBSTR(SQL_TEXT,1, 60), COUNT(*)
FROM V$SQLAREA
WHERE EXECUTIONS < 4
GROUP BY SUBSTR(SQL_TEXT, 1, 60)
HAVING COUNT(*) > 1;
■
同じ実行計画を持つ個別の SQL 文をレポートします。次の問合せでは、同じ実行計画を
4 回以上共有する個別の SQL 文が選択されます。この種の SQL 文では、バインド変数
ではなくリテラルが使用されている可能性があります。
SELECT SQL_TEXT FROM V$SQL WHERE PLAN_HASH_VALUE IN
(SELECT PLAN_HASH_VALUE
FROM V$SQL
GROUP BY PLAN_HASH_VALUE HAVING COUNT(*) > 4)
ORDER BY PLAN_HASH_VALUE;
再解析された共有可能な SQL V$SQLAREA ビューをチェックします。次の問合せを入力して
ください。
SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS
FROM V$SQLAREA
ORDER BY PARSE_CALLS;
PARSE_CALLS の値が指定の文の EXECUTIONS 値に近い場合は、その文の再解析を継続でき
ます。解析コールが多い文をチューニングします。
セッション別 不要な解析コールが発生しているセッションを識別して、不要なコールを識
別します。特定のバッチ・プログラムやある種のアプリケーションがほとんどの再解析を
行っている場合があります。これを行うには、次の問合せを実行します。
SELECT
FROM
WHERE
AND
pa.SID, pa.VALUE "Hard Parses", ex.VALUE "Execute Count"
V$SESSTAT pa, V$SESSTAT ex
pa.SID = ex.SID
pa.STATISTIC#=(SELECT STATISTIC#
FROM V$STATNAME WHERE NAME = 'parse count (hard)')
AND ex.STATISTIC#=(SELECT STATISTIC#
FROM V$STATNAME WHERE NAME = 'execute count')
AND pa.VALUE > 0;
結果として、すべてのセッションおよびリストとセッションで実行された解析の量が得られ
ます。セッション識別子（SID）ごとに、V$SESSION で、再解析の原因となっているプログ
ラムの名前を検索します。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-41
待機イベント統計
注意 : この問合せではインスタンス起動後のすべての解析コールがカウ
ントされるため、解析率の高いセッションを検索することをお薦めしま
す。たとえば、50 日間の接続が高い解析値を示すとしても、2 番目の 10
分間の接続の方がより速い速度で解析される場合があります。
出力は、次のようなものです。
SID
-----7
8
6
11
Hard Parses
----------1
3
26
84
Execute Count
------------20
12690
325
1619
キャッシュ・バッファ LRU 連鎖 cache buffers lru chain ラッチは、キャッシュ内の
バッファのリストを保護します。リストからバッファの追加、移動または削除を行う場合、
ラッチを取得する必要があります。
対称型マルチプロセッサ（SMP）システムでは、Oracle によって、LRU ラッチの数がシス
テムの CPU 数の 2 分の 1 に等しい値になるように自動的に設定されます。非 SMP システム
では、LRU ラッチは 1 つあれば十分です。
LRU ラッチの競合は、多数の CPU を備えた SMP マシンでのパフォーマンスを低下させる
ことがあります。LRU ラッチの競合は、V$LATCH、V$SESSION_EVENT および
V$SYSTEM_EVENT に問い合せることによって検出できます。競合を回避するには、アプリ
ケーションのチューニング、DSS ジョブのバッファ・キャッシュのバイパスまたはアプリ
ケーションの再設計を検討してください。
キャッシュ・バッファ連鎖 cache buffers chains のラッチは、バッファ・キャッシュで
バッファ・リストを保護する場合に使用します。これらのラッチは、バッファの検索、追
加、およびバッファ・キャッシュからバッファを削除する場合に使用します。このラッチの
競合は、競合度の高い（ホットな）ブロックが存在することを意味します。
頻繁にアクセスされるバッファ連鎖を識別し、競合するブロックを識別するには、
V$LATCH_CHILDREN ビューを使用して cache buffers chains のラッチのラッチ統計を
調べます。他の子ラッチと比較して、多くの GETS、MISSES および SLEEPS を持つ特定の
cache buffers chains の子ラッチがある場合、これは子ラッチで競合します。
このラッチには、ADDR 列で識別されるメモリー・アドレスがあります。このラッチで保護
されているブロックを識別するには、X$BH 表と結合された ADDR 列の値を使用します。た
とえば、頻繁に競合されたラッチのアドレス（V$LATCH_CHILDREN.ADDR）を指定すると、
ファイル番号とブロック番号の問合せが行われます。
10-42　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
SELECT OBJ data_object_id, FILE#, DBABLK,CLASS, STATE, TCH
FROM X$BH
WHERE HLADDR = 'address of latch'
ORDER BY TCH;
X$BH.TCH は、バッファのタッチ・カウントです。X$BH.TCH の値が高い場合は、ホット・
ブロックであることを示します。
各ラッチで保護されるブロックは多数あります。これらのバッファのうちの 1 つは、ホッ
ト・ブロックであると考えられます。TCH 値の高いブロックは、潜在的なホット・ブロック
です。この問合せを複数回実行し、出力に一貫して表示されるブロックを識別します。ホッ
ト・ブロックを識別した後は、ファイル番号とブロック番号を使用して DBA_EXTENTS の問
合せを行い、セグメントを識別します。
ホット・ブロックの識別後に、次の問合せを使用してそのホット・ブロックが属するセグメ
ントを識別できます。
SELECT OBJECT_NAME, SUBOBJECT_NAME
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = &obj;
この問合せで &obj は、X$BH への前述の問合せにおける OBJ 列の値です。
行キャッシュ・オブジェクト row cache objects ラッチは、データ・ディクショナリを保
護します。
log file parallel write
このイベントには、ログ・バッファから REDO ログ・ファイルへの REDO レコードの書込
みが含まれます。
library cache pin
このイベントでは、ライブラリ・キャッシュの同時実行性を管理します。オブジェクトが確
保されると、ヒープがメモリーへロードされます。クライアントがオブジェクトを修正また
は調査する場合、クライアントはロック後に PIN を取得する必要があります。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-43
待機イベント統計
library cache lock
このイベントは、ライブラリ・キャッシュのクライアント間の同時実行性を制御します。オ
ブジェクト処理のロックが取得され、次のいずれかが可能になります。
■
■
1 つのクライアントが、同一オブジェクトに対する他のクライアントからのアクセスを
防止
クライアントは、別のクライアントにオブジェクトの変更を許可しない依存関係を長期
間維持
また、このロックはライブラリ・キャッシュにオブジェクトを配置するためにも取得されま
す。
log buffer space
このイベントは、サーバー・プロセスがログ・バッファ内の空き領域を待機しているときに
発生します。これは、LGWR が REDO を書き出すよりも、すべての REDO が生成されるほ
うが速いためです。
処置
REDO ログ・バッファ・サイズを修正します。ログ・バッファのサイズがすでに適切なもの
である場合、オンライン REDO ログが存在するディスクが I/O 競合を受けないようにしま
す。log buffer space 待機イベントは、REDO ログが存在するディスク上のディスク I/O
競合を示しているか、小さすぎるログ・バッファを示している可能性があります。REDO ロ
グを含むディスクの I/O プロファイルをチェックして、I/O システムがボトルネックである
かどうかを調べます。I/O システムが問題ではない場合、REDO ログ・バッファが小さすぎ
る可能性があります。このイベントが問題にならなくなるまで、REDO ログ・バッファのサ
イズを大きくします。
10-44　Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
log file switch
一般に発生する待機イベントは、次の 2 つです。
■
Log file switch (archiving needed)
■
Log file switch (checkpoint incomplete)
いずれのイベントでも、LGWR は次のオンライン REDO ログに切り替えることはできず、
すべてのコミット要求はこのイベントを待機します。
処置
log file switch（archiving needed）イベントの場合、アーカイバがタイムリにログ
をアーカイブできない理由を調べます。次の理由が考えられます。
■
アーカイブ先に空き領域が不足している。
■
アーカイバが REDO ログを十分高速に読み込めない（LGWR との競合）
。
■
■
アーカイバが十分高速に書込みを行えない（アーカイブ先での競合、または ARCH プロ
セスの数が不足している）
。その他の可能性（ディスクが低速であったり、アーカイブ
先がいっぱいなど）が除外された場合は、ARCn プロセス数の増加を検討してくださ
い。デフォルトは 2 です。
必須でリモートに転送されるアーカイブ・ログがある場合は、ネットワーク遅延によっ
てこのプロセスが遅くなっていないか、またはエラーによって書込みが完了していない
かをチェックしてください。
ボトルネックの性質により、I/O を再分散したり、アーカイブ先に領域を追加して問題を軽
減することが必要な場合があります。log file switch（checkpoint incomplete）イ
ベントの場合、次を実行してください。
■
■
過負荷または低速の I/O システムであるために DBWR が低速であるかどうかをチェック
してください。DBWR 書込み時間および I/O システムをチェックし、必要に応じて
I/O を分散します。第 8 章「I/O 構成および設計」を参照してください。
REDO ログが少なすぎないか、または小さすぎないかをチェックしてください。REDO
ログが少なすぎるか小さすぎる、あるいはその両方にあてはまる（たとえば、2 × 100k
個のログ）ために、DBWR がチェックポイントを完了する前に、すべてのログをサイク
ルする十分な REDO が生成される場合は、REDO ログのサイズまたは個数、あるいは
その両方を増やします。4-5 ページの「REDO ログ・ファイルのサイズ指定」を参照し
てください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-45
待機イベント統計
log file sync
ユーザー・セッションがコミットする（またはロールバックする）場合、LGWR でセッショ
ンの REDO 情報を REDO ログ・ファイルにフラッシュする必要があります。COMMIT また
は ROLLBACK を実行するサーバー・プロセスは、REDO ログへの書込みが完了するまで、
このイベントで待機します。
処置
このイベントの待機がシステム上での長時間の待機か、応答時間の問題が発生しているユー
ザーまたはシステム上のユーザーによる長時間の待機を構成している場合は、平均待機時間
を調べます。
平均待機時間は短いが、待機数が多い場合、アプリケーションは COMMIT をバッチ処理する
のではなく、すべての INSERT 後にコミットできます。アプリケーションは、行ごとではな
く 50 行後にコミットして待機を減らすことができます。
平均待機時間が多い場合は、LGWR に対するセッション待機を調べ、何を実行および待機す
るために多くの時間を費やしているかを調べます。待機が低速の I/O によるものである場合
は、次のことを試行してください。
■
■
■
■
■
REDO ログを含むディスク上の他の I/O アクティビティを削減するか、専用ディスクを
使用します。
異なるディスク上に交互の REDO ログを設定して、LGWR に対するアーカイバの影響を
できるだけ少なくします。
REDO ログをさらに高速なディスクまたはさらに高速な I/O サブシステム（たとえば、
RAID 5 から RAID 1 への切替え）に移動します。
RAW デバイス（またはディスク・ベンダーが提供しているシミュレートされた RAW デ
バイス）を使用して書込みを高速化することを検討してください。
アプリケーションのタイプにより異なりますが、1 行ごとではなく、N 行ごとにコミッ
トして、COMMIT をバッチ処理することで、ログ・ファイルの同期が少なくて済みま
す。
rdbms ipc reply
このイベントは、バックグラウンド・プロセスのうちの 1 つから応答を待機する場合に使用
します。
10-46　Oracle Database パフォーマンス・チューニング・ガイド
アイドル待機イベント
アイドル待機イベント
これらのイベントは Idle 待機クラスに属し、作業がないためにサーバー・プロセスが待機中
であることを示します。これは通常、ボトルネックが存在する場合にボトルネックがデータ
ベース・リソースに対するものではないことを意味します。チューニングの際、アイドル・
イベントの大部分を無視することが必要なのは、アイドル・イベントがパフォーマンス・ボ
トルネックの性質を示さないためです。アイドル・イベントの中には、ボトルネックでない
ものを示す際に役立つものがあります。このタイプのイベントの例として、最も一般的に発
生するアイドル待機イベントである SQL Net message from client があります。表
10-3 に、このアイドル・イベントと他のアイドル・イベント（およびそれらのカテゴリ）の
リストを示します。
表 10-3 アイドル待機イベント
待機名
ユーザー・
バックグラウンド・ プロセス・
プロセス・
アイドル・
アイドル・イベント イベント
Oracle Real
パラレル問合せ 共有サーバー・ Application
アイドル・
アイドル・
Clusters アイドル・
イベント
イベント
イベント
dispatcher timer
.
.
.
×
.
pipe get
.
×
.
.
.
pmon timer
×
.
.
.
.
PX Idle Wait
.
.
×
.
.
PX Deq Credit: need
buffer
.
.
×
.
.
rdbms ipc message
×
.
.
.
.
smon timer
×
.
.
.
.
SQL*Net message from
client
.
×
.
.
.
virtual circuit
status
.
.
.
×
.
関連項目 : 各アイドル待機イベントの説明は、『Oracle Database リファ
レンス』を参照してください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-47
アイドル待機イベント
10-48　Oracle Database パフォーマンス・チューニング・ガイド
11
ネットワークのチューニング
この章では、チューニングに影響を与える様々な接続モデルについて説明し、ネットワーク
上の問題点を紹介します。
この章には次の項があります。
■
接続モデルについて
■
ネットワークの問題の検出
■
ネットワークの問題の解決
ネットワークのチューニング 11-1
接続モデルについて
接続モデルについて
問題の原因を判別する際に使用するテクニックは構成によって異なります。共有サーバー構
成または専用サーバー構成を持つことができます。
■
■
共有サーバー構成を持っている場合、LSNRCTL サービスは dispatchers をリストしま
す。
専用サーバー構成を持っている場合、LSNRCTL サービスは dedicated servers をリ
ストします。
接続記述子にパラメータ（SERVER = DEDICATED）を入れると、共有サーバー用に構成した
データベースと専用サーバーを接続できます。
共有サーバー構成
この項では、共有サーバー構成の設定について説明します。
ディスパッチャの登録
LSNRCTL 制御ユーティリティの services 文はこのリストに登録されているすべてのディ
スパッチャを表示します。このリストには、ディスパッチャ・プロセス ID が含まれていま
す。アラート・ログをチェックして、ディスパッチャが正常に起動されていることを確認で
きます。
注意 : PMON はディスパッチャをリスナーに登録するには 1 分ほどかか
ります。
LSNRCTL> services
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=helios)(PORT=1521)))
Services Summary...
Service "sales.us.acme.com" has 1 instance(s).
Instance "sales", status READY, has 3 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
"D000" established:0 refused:0 current:0 max:10000 state:ready
DISPATCHER <machine: helios, pid: 1689>
(ADDRESS=(PROTOCOL=tcp)(HOST=helios)(PORT=52414))
"D001" established:0 refused:0 current:0 max:10000 state:ready
DISPATCHER <machine: helios, pid: 1691>
(ADDRESS=(PROTOCOL=tcp)(HOST=helios)(PORT=52415))
The command completed successfully.
関連項目 : 出力モード設定の詳細は、『Oracle Net Services 管理者ガイ
ド』を参照してください。
11-2　Oracle Database パフォーマンス・チューニング・ガイド
接続モデルについて
共有サーバーの初期化パラメータの構成
次のリストに、共有サーバーの初期化パラメータの構成方法を示します。
■
DISPATCHERS 行が正しく設定されていることを確認します。たとえば、次のようにし
ます。
DISPATCHERS = "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=hostname)(PORT=1492)(queuesize=32)))
(DISPATCHERS = 1)
(LISTENER = alias)
(SERVICE = servicename)
(SESSIONS = 1000)
(CONNECTIONS = 1000)
(MULTIPLEX = ON)
(POOL = ON)
(TICK = 5)"
次の属性のうち、1 つの属性のみが必要です。
■
PROTOCOL
■
ADDRESS
■
DESCRIPTION
ADDRESS と DESCRIPTION は、PROTOCOL で追加ネットワーク属性の指定をサポート
します。前述の例で、DISPATCHERS 行全体を（PROTOCOL=TCP）にできます。属性の
DISPATCHERS、LISTENER、SERVICE、SESSIONS、CONNECTIONS、MULTIPLEX、
POOL および TICKS はすべてオプションです。
■
オプションの MAX_DISPATCHERS 行が正しく設定されていることを確認します。たとえ
ば、次のようにします。
MAX_DISPATCHERS = 4
この行は起動する合計ディスパッチャ数を反映している必要があります。
■
オプションの MAX_SHARED_SERVERS 行が正しく設定されていることを確認します。た
とえば、次のようにします。
MAX_SHARED_SERVERS = 5
この行は、システムのピーク負荷を基準に、PMON が作成可能な合計共有サーバーの
上限を設定します。これは、すべての要求がサービスを受けられる程度に大きな値に設
定しますが、この値に達するとシステムがスワップするほど大きな値にはしないでくだ
さい。このパラメータの目的はサーバーのスワップを防止することです。次のスクリプ
ネットワークのチューニング 11-3
接続モデルについて
トを実行し、どの最高水位標が実行されているサーバー数に適しているかを調べて、
MAX_SHARED_SERVERS をその値以上に設定します。
SELECT maximum_connections "MAX CONN", servers_started "STARTED", servers_
terminated "TERMINATED", servers_highwater "HIGHWATER" FROM V$SHARED_SERVER_
MONITOR;
■
オプションの SHARED_SERVERS 行が正しく設定されていることを確認します。たとえ
ば、次のようにします。
SHARED_SERVERS = 5
これは、データベースの起動時に起動された共有サーバーの合計数です。PMON が保
持しようとした共有サーバーの合計数も表しています。これは、データベースがアク
ティブなときに使用されることが予想される共有サーバーの合計数になります。MAX_
SHARED_SERVERS は、ピーク負荷を処理するためのものです。
接続のチェック
LSNRCTL 制御ユーティリティの services コマンドを使用して、過剰な接続拒否がないか
調べます。これが接続の問題になっていないか、リスナーのログ・ファイルを調べます。た
とえば、次のようにします。
LSNRCTL> services
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=helios)(PORT=1521)))
Services Summary...
Service "sales.us.acme.com" has 1 instance(s).
Instance "sales", status READY, has 2 handler(s) for this service...
Handler(s):
"DEDICATED" established:11 refused:0 state:ready
LOCAL SERVER
"D000" established:565 refused:4 current:155 max:10000 state:ready
DISPATCHER <machine: helios, pid: 5673>
(ADDRESS=(PROTOCOL=tcp)(HOST=helios)(PORT=38411))
The command completed successfully.
通常の条件では、拒否された数はゼロになります。リスナーをシャットダウンし、再起動し
て統計を消去します。リスナーの再起動後にも拒否回数が増加している場合は、その接続が
拒否されています。拒否回数がゼロのままであれば、現在トラブルシューティングしている
問題は、接続拒否とは関係ありません。
11-4　Oracle Database パフォーマンス・チューニング・ガイド
接続モデルについて
1 秒当たりの接続速度のチェック
接続拒否は様々な理由で発生します。リスナー・ログを調べ、接続速度を確認してくださ
い。リスナー・ログ・アナライザ・スクリプトを実行してチェックします。
リスナーはキュー・ベースのプロセスです。低レベル・プロトコル・スタックからの接続要
求を受け取ります。これには、オペレーティング・システムの最大値に構成可能な一定の
キュー・スタックがあります。これは 1 つの接続しか一度に処理できないので、このプロセ
スが 1 秒当たりで処理可能な接続数には限界があります。
接続要求が到着する速度がこの限界値を超えると、要求はキュー処理されます。キュー・ス
タックにも限界がありますが、これは設定できます。より多くのリスナー・プロセスがある
場合は、各プロセスに対して行われる要求数は少なくなり、迅速に処理されます。
リスナー・キューの増加は、listener.ora ファイルで行われます。listener.ora ファイ
ルには、別々の名前によって多くのリスナーを含めることができます。リストされている中
の 1 つのみに問題があると想定します。そうでない場合は、この方法がすべての適用可能な
リスナーに適用されます。リスナー・キューを増加するには、(queuesize = number) を
listener.ora ファイルに追加します。たとえば、次のようにします。
listener =
(address =
(protocol = tcp)
(host = sales-pc)
(port = 1521)
(queuesize = 20)
)
関連項目 : 『Oracle Net Services 管理者ガイド』
リスナーを停止し、再起動してこの新しいパラメータを初期化します。現在、共有サーバー
構成を実行していない場合は、実行することを検討してください。リスナーにとっては、専
用サーバー構成より共有サーバー構成でクライアント要求を処理するほうが、処理が速くな
ります。
注意 : 共有サーバーのディスパッチャは、接続要求も受信するので、
キュー・サイズをチューニングすることにより得られる利点もあります。
最大キュー・サイズは特定オペレーティング・システムの最大サイズに
よって決まります。
ネットワークのチューニング 11-5
ネットワークの問題の検出
ネットワークの問題の検出
この項では、ローカル・エリア・ネットワーク（LAN）とワイド・エリア・ネットワーク
（WAN）のトラブルシューティングの方法を説明します。
動的パフォーマンス・ビューを使用したネットワークのパフォーマンスの
向上
ネットワークには、処理をある程度遅延させるオーバーヘッドが伴います。パフォーマンス
を最適化するには、ネットワーク・スループットを高速にし、ネットワーク上に送信する必
要のあるメッセージ数の削減を試してみてください。ネットワークによって加えられる遅延
の測定は困難な場合があります。
ネットワーク遅延を測定するには、次の 3 つの動的パフォーマンス・ビューが役立ちます。
■
V$SESSION_EVENT
■
V$SESSION_WAIT
■
V$SESSTAT
V$SESSION_EVENT では、Oracle がメッセージを待機する時間間隔を AVERAGE_WAIT 列が
示します。この統計を判断基準として使用して、ネットワークの効率を評価できます。
V$SESSION_WAIT には、アクティブなセッションが待機しているイベントをリストする
EVENT 列が含まれます。sqlnet message from client 待機イベントは、共有プロセスま
たはフォアグラウンド・プロセスがクライアントからのメッセージを待機していることを示
します。この待機イベントが発生した場合、メッセージがユーザーによって送信されたかど
うか、または Oracle によって受信されたかどうかをチェックできます。
V$SESSION_WAIT を参照することによってセッションが待機している対象を確認し、ハン
グアップが調査できます。クライアントがメッセージを送信済の場合は、Oracle がそれに応
答中か、まだ待機中であるかを判断できます。
V$SESSTAT では、クライアントから受信したバイト数、クライアントに送信されたバイト
数およびクライアントが実行したコール数を確認できます。
11-6　Oracle Database パフォーマンス・チューニング・ガイド
ネットワークの問題の検出
待機時間および帯域幅
パフォーマンスに関わるネットワークでの最も重要な側面は、待機時間と帯域幅です。
■
■
待機時間という用語は、時間の遅延を意味します。たとえば、デバイスがネットワーク
へのアクセスを要求した時間と送信許可を受信した時間までのギャップなどです。
帯域幅とは、ネットワーク・メディアあるいはプロトコルのスループット容量です。
ネットワーク信号のバリエーションによりネットワークの劣化が発生する場合がありま
す。劣化の原因には、ケーブルが長すぎたり、ケーブルの種類が間違っていることなど
があります。エレベータや蛍光灯などの外部からのノイズ発生源も問題の原因となりま
す。
共有ネットワーク・トポロジ
ローカル・エリア・ネットワーク・トポロジ
■
イーサネット
■
高速イーサネット
■
1 ギガビット・イーサネット
■
トークン・リング
■
FDDI
■
ATM
ワイド・エリア・ネットワーク・トポロジ
■
DSL
■
ISDN
■
フレーム・リレー
■
T-1、T-3、E-1、E-3
■
ATM
■
SONAT
ネットワークのチューニング 11-7
ネットワークの問題の検出
表 11-1 は、各種トポロジの最も共通した速度を示します。
表 11-1 帯域幅レーティング
トポロジまたはキャリア
帯域幅
イーサネット
10 メガビット / 秒
高速イーサネット
100 メガビット / 秒
1 ギガビット・イーサネット
1 ギガビット / 秒
トークン・リング
16 メガビット / 秒
FDDI
100 メガビット / 秒
ATM
155 メガビット / 秒（OC3）、622 メガビット / 秒（OC12）
T-1（米国のみ）
1.544 メガビット / 秒
T-3（米国のみ）
44.736 メガビット / 秒
E-1（米国以外）
2.048 メガビット / 秒
E-3（米国以外）
34.368 メガビット / 秒
フレーム・リレー
最高でキャリア速度までが可能なコミット情報速度、ただし通常
はこの速度にはしません。
DSL
これは、最高でキャリア速度まで可能です。
ISDN
これは、最高でキャリア速度まで可能です。これは通常、低速モ
デムで使用されます。
ダイアル・アップ・モデム
56 キロビット / 秒。迅速なスループットのため、通常はデータ
の圧縮が伴います。
11-8　Oracle Database パフォーマンス・チューニング・ガイド
ネットワークの問題の解決
ネットワークの問題の解決
この項では、パフォーマンスを改善する手法とネットワークの問題を解決する手法をいくつ
か説明します。
■
ネットワークのボトルネックの検出
■
ネットワークのボトルネックの分析
■
配列インタフェースの使用方法
■
セッション・データ・ユニットのバッファ・サイズの調整
■
TCP.NODELAY の使用方法
■
Connection Manager の使用
関連項目 : 『Oracle Net Services 管理者ガイド』
ネットワークのボトルネックの検出
ネットワークの問題を解決する際の最初の手順は、トポロジ全体を理解することです。キー
ワードに関する情報を可能なかぎり収集します。このような情報は通常、ネットワーク図と
して表示されます。図には、ローカル・エリア・ネットワークとワイド・エリア・ネット
ワークで使用されているネットワーク・トポロジのタイプが含まれています。各種ネット
ワーク・セグメントのアドレスも含まれています。
この情報を検討してください。明確なネットワーク・ボトルネックとして次のものがありま
す。
■
■
ダイアルアップ・モデム（通常のモデムあるいは ISDN）を使用して時間が重要なデー
タにアクセスしている場合。
T-1 上でフレーム・リレー・リンクが実行されているが、9.6 キロビット程度の CIR であ
り、1 秒当たり最高で 9.6 キロビットの送信信頼性であるため、帯域幅の残りを使用す
ると、データが消失する可能性がある場合。
■
高速ネットワーク・チャネルからのデータが低速ネットワークを経由している場合。
■
ネットワーク・ホップが多すぎる場合。ルータ 1 台が 1 ホップになります。
■
1 つのウェブ・サイトに対して 10 メガビットのネットワークになっている場合。
パフォーマンスの低下の原因となる問題は数多くあります。次のチェックリストに従ってく
ださい。
■
Network Sniffer のトレースを取得します。
■
次の点をチェックします。
■
ネットワーク、クライアントまたはサーバーで帯域幅が超過しているかどうか。
■
イーサネットの衝突。
ネットワークのチューニング 11-9
ネットワークの問題の解決
■
■
トークン・リングまたは FDDI リング・ビーコン。
■
ラント・フレームが多数あるか。
■
WAN リンクの安定性。
フレーム・リレーの帯域幅使用率チャートを取得し、CIR が超過していないかチェック
します。
■
サービス品質あるいはパケット優先設定が実行されているか。
■
ファイアウォールが途中にあるか。
何も問題がなかった場合は、クライアントからデータ・サーバーへのネットワーク・ルート
を探してください。ネットワークでの所要時間を知っておくと、トランザクションに必要な
時間を推測できます。クライアント / サーバー間の通信には多数の小さなパケットが必要で
す。ネットワークでの待機時間が長いと、要求を送出して応答を受信するまでの間隔が長く
なり、トランザクション処理が遅くなります。
クライアントからサーバーへのルート追跡（traceroute または同等のコマンド）を使用し
て、パス内の各デバイスのアドレス情報を取得します。
たとえば、次のようにします。
traceroute usmail05
Tracing route to usmail05.us.oracle.com [144.25.88.200]over a maximum of 30 hops:
1
<10 ms
<10 ms
10 ms whq1davis-rtr-749-f1-0-a.us.oracle.com [144.25.216.1]
2
<10 ms
<10 ms
<10 ms whq4op3-rtr-723-f0-0.us.oracle.com [144.25.252.23]
3
220 ms
210 ms
231 ms usmail05.us.oracle.com [144.25.88.200]
Trace complete.
各デバイスを順に ping してタイミングをとります。大きなパケットを使用して最も遅い時
間を調べます。ルータがパケットの分解と組立に時間を費やすことのないよう、必ず「don't
fragment bit」を設定してください。パケット・サイズが 1472 であることに注意してくださ
い。これは、イーサネット用です。イーサネット・パケットのサイズは 1536 オクテット
（実際には 8 ビット・バイト）です。ICPM パケット（これは ping 本来の用途）には 64 オ
クテットのヘッダーがあります。低速になっていると思われる場合はこの領域を確認しま
す。
たとえば、次のようにします。
ping -l 1472 -n 1 -f 144.25.216.1
Pinging 144.25.216.1 with 1472 bytes of data:
Reply from 144.25.216.1: bytes=1472 time<10ms TTL=255
ping -l 1472 -n 1 -f 144.25.252.23
Pinging 144.25.252.23 with 1472 bytes of data:
Reply from 144.25.252.23: bytes=1472 time=10ms TTL=254
ping -l 1472 -n 1 -f 144.25.88.200
11-10　Oracle Database パフォーマンス・チューニング・ガイド
ネットワークの問題の解決
Pinging 144.25.88.200 with 1472 bytes of data:
Reply from 144.25.88.200: bytes=1472 time=271ms TTL=253
前述の例では、追跡ルートを評価しています。ワークステーションから 144.25.216.1 に、
144.25.216.1 から 144.25.252.23 に、144.25.252.23 から 144.25.88.200 に ping を実行するのが
理想的です。これにより、移動した各セグメントの待機時間が正確に示されます。
ネットワークのボトルネックの分析
この項は、ネットワーク・ボトルネックの問題を特定する際に役立ちます。
問題が Oracle Net またはネットワークのいずれにあるかの判定
Oracle Net トレース機能は、エラーが Oracle 固有のものであるか、あるいはオペレーティ
ング・システムが Transparent Network Substrate（Oracle TNS レイヤー）に渡す条件によ
るものかを明確にします。
解決しようとしている問題を抱えていることが疑わしい Oracle サーバー、リスナーおよび
クライアントで Oracle Net トレース機能を有効にします。
サーバーでトレース機能を有効にするには、このサーバーの sqlnet.ora ファイルを探し、
次の行を作成します。
TRACE_TIMESTAMP_SERVER = ON
TRACE_LEVEL_SERVER = 16
TRACE_UNIQUE_SERVER = ON
クライアントでトレース機能を有効にするには、このクライアントの sqlnet.ora ファイル
を探し、ファイルに次の行を作成します。
TRACE_TIMESTAMP_CLIENT = ON
TRACE_LEVEL_CLIENT = 16
TRACE_UNIQUE_CLIENT = ON
リスナーでトレース機能を有効にするには、listener.ora ファイルを探し、ファイルに次
の行を作成します。
TRACE_TIMESTAMP_listener_name = ON
TRACE_LEVEL_listener_name = 16
注意 : TRACE_TIMESTAMP_x パラメータはオプションですが、デバッグ
を向上させるために組み込む必要があります。
クライアントとサーバーでトレースを生成するように、問題を再現します。ここで、生成さ
れたトレースを分析します。
ネットワークのチューニング
11-11
ネットワークの問題の解決
関連項目 :
■
■
Oracle Net トレース機能を有効にする詳細な手順は、
『Oracle Net
Services 管理者ガイド』を参照してください。
トレース・ファイルに示される Oracle Net エラーの定義については、
『Oracle Database エラー・メッセージ』を参照してください。
問題はネットワークにあり、Oracle Net ではない場合、次の事項を調べる必要があります。
■
問題はローカル・ネットワークの 1 つのロケーションでのみ発生しているかどうか。
■
問題は WAN の 1 つの領域でのみ発生しているかどうか。
たとえば、データ・センターの存在するビル内では、システムは正常ですが、数マイル離れ
たビル内では低速になっていることがあります。
Oracle のエラー・コードすべてが、Oracle 固有のトラブルを表しているわけではありませ
ん。ORA-3113 は最もよく発生するエラーですが、基盤となっているネットワークに問題が
あることを示します。
注意 : サーバー上でトレースを有効にすると、大量のトレース・ファイ
ルを生成します。これを防ぐため、自身をトレースする個別の環境をセッ
トアップします。この構成は、専用接続に有効です。
まず、サーバーのオペレーティング・システムに Oracle のソフトウェア
所有者としてログインします。一時ディレクトリを作成し、これから作成
される構成ファイルとトレース・ファイルを保管します。sqlnet.ora、
listener.ora および tnsnames.ora をそのディレクトリにコピーしま
す。
sqlnet.ora ファイルを編集し、トレース機能を有効にします。次の行を
sqlnet.ora ファイルに追加します。
TRACE_DIRECTORY_SERVER = temporary_directory_just_created
次に listener.ora ファイルを修正して、リスナー・ポート（TCP、その
他のプロトコルの場合は類似のテクニックを使用）を未使用ポートに変更
します。このテストで使用する接続文字列用にクライアントの
tnsnames.ora ファイルに同様の修正を行う必要があります。
TNS_ADMIN 環境をテンポラリ・ディレクトリをポイントするように設定
します。リスナーを起動します。
これで、新しいリスナーへのすべての接続がこのディレクトリに Server
traces を送信します。問題を再現します。
11-12　Oracle Database パフォーマンス・チューニング・ガイド
ネットワークの問題の解決
Oracle エラー・メッセージを取得しながら、トレース・ファイルを調べエラーを探します。
トラブルシューティング・バグの場合は、Oracle Net トレース分析が問題を完全に探し出す
までに一定の時間がかかります。ただし、高レベルの簡易トレース分析は簡単です。
問題がクライアント上またはサーバー上（Oracle
Net 上）のいずれにあ
問題がクライアント上またはサーバー上（
るかの判定
問題が Oracle Net にある場合、Oracle Net トレースを使用して問題が存在する場所を示しま
す。トレース・ファイルにエラーがある場合は、エラーはクライアントのトレースにのみ現
れるか、サーバーのトレースにのみ現れるかあるいは両方に現れるかを調べます。
クライアント・トレースのみのエラー 問題はクライアントにあります。ただし、
ORA-3113 エラーまたは ORA-3114 エラーを取得している場合は、問題はサーバーにあり
ます。
サーバー・トレースあるいはリスナー・トレースのみのエラー 問題はサーバーにあります。
ただし、ORA-3113 エラーまたは ORA-3114 エラーを取得している場合は、問題はクライ
アントにあります。
すべてのエラー : クライアント、サーバーおよびリスナーのトレース ORA-3113 エラーまた
は ORA-3114 エラーを取得している場合は、問題はネットワークにあります。まず、サー
バーのトラブルシューティングを行います。サーバーが正常であれば、クライアントに障害
があります。
サーバーが共有サーバー用に構成されているかどうかのチェック
共有サーバー・アーキテクチャのトラブルシューティングは、さらに複雑である可能性があ
ります。初期化パラメータ・ファイルに共有サーバーのパラメータが設定されているか確認
します。また、共有サーバー・プロセスが存在していないかオペレーティング・システムを
調べます。
ora_d000 や ora_d001 などの名前を探してディスパッチャをチェックします。たとえば、
次のようにします。
ps -ef | grep ora_d
ora_s000 や ora_s001 などの名前を探して共有サーバーをチェックします。たとえば、
次のようにします。
ps -ef | grep ora_s
ネットワークのチューニング
11-13
ネットワークの問題の解決
関連項目 :
■
■
共有サーバーのチューニングの詳細は、11-2 ページの「共有サーバー
構成」を参照してください。
共有サーバーの概念とパラメータの詳細は、
『Oracle Database 概要』
および『Oracle Net Services 管理者ガイド』を参照してください。
配列インタフェースの使用方法
配列インタフェースを使用してネットワーク・コールを削減します。一度に 1 行をフェッチ
するよりも、ネットワークの 1 往復で 10 行をフェッチする方が効率的です。
関連項目 : 配列インタフェースの詳細は、『Oracle Call Interface プログ
ラマーズ・ガイド』を参照してください。
セッション・データ・ユニットのバッファ・サイズの調整
ネットワーク上にデータを送信する前に、Oracle Net はデータをセッション・データ・ユ
ニット（SDU）にバッファリングします。SQL Net は、バッファがいっぱいになったときま
たはアプリケーションがデータを読み込もうとしたときに、バッファに格納されているデー
タを送信します。大量のデータを取り出すときまたはパケット・サイズが一貫して同じとき
は、デフォルトの SDU サイズを調整するとデータの取出しを高速化できることがあります。
最適な SDU サイズは、標準転送サイズによって決まります。検出ツールを使用してフレー
ム・サイズを調べるか、トレースを最大レベルに設定して送受信されたパケット数をチェッ
クし、それらが断片化されているかどうかを確認します。システムをチューニングして、断
片化の量を制限してください。
Oracle Net Configuration Assistant を使用して、クライアントとサーバーの両方でデフォル
ト SDU サイズを変更します。SDU サイズは、一般にクライアントとサーバーの両方で同じ
です。
関連項目 : 『Oracle Net Services 管理者ガイド』
TCP.NODELAY の使用方法
セッションが確立すると、Oracle Net はデータをパッケージ化し、パケットを使用してサー
バーとクライアント間でデータを送信します。デフォルトでは、さらに頻繁にネットワーク
にパケットをフラッシュさせる TCP.NODELAY パラメータが有効になります。Oracle Net は
多くのネットワーク・プロトコルをサポートしていますが、最も拡張性が高いのは TCP で
す。
11-14　Oracle Database パフォーマンス・チューニング・ガイド
ネットワークの問題の解決
Connection Manager の使用
Oracle Net では、Connection Manager を使用して多重化によりシステム・リソースを確保
できます。多重化とは、転送先サーバーへの単一のトランスポート接続を経由して、複数の
クライアント・セッションを送り込むことです。この方法を使用すると、1 つのプロセスが
処理できるセッションの数を増やすことができます。これが適用されるのは、共有サーバー
構成のみです。また、Connection Manager を使用して、専用サーバーへのクライアントの
アクセスを制御できます。また、Connection Manager では、異なるネットワーク・プロト
コルを持つサーバーとクライアントが通信できる、複数プロトコルのサポートが提供されま
す。
関連項目 : Connection Manager の詳細は、『Oracle Net Services 管理者
ガイド』を参照してください。
ネットワークのチューニング
11-15
ネットワークの問題の解決
11-16　Oracle Database パフォーマンス・チューニング・ガイド
第 IV 部
SQL 文の最適化
第 IV 部では、最適なパフォーマンスを得るための SQL 文の理解と管理に関する情報を示
し、Oracle の SQL 関連パフォーマンス・ツールについて説明します。
第 IV 部には次の章が含まれます。
■
第 12 章「SQL チューニングの概要」
■
第 13 章「自動 SQL チューニング」
■
第 14 章「問合せオプティマイザ」
■
第 15 章「オプティマイザ統計の管理」
■
第 16 章「索引およびクラスタの使用方法」
■
第 17 章「オプティマイザ・ヒント」
■
第 18 章「プラン・スタビリティの使用方法」
■
第 19 章「EXPLAIN PLAN の使用方法」
■
第 20 章「アプリケーション・トレース・ツールの使用方法」
12
SQL チューニングの概要
この章では、チューニングの目的、多くのリソースを消費する SQL 文の識別方法および収
集する内容の説明と、チューニングの提案を示します。
この章には次の項があります。
■
SQL チューニングの概要
■
チューニングの目的
■
高負荷 SQL の識別
■
自動 SQL チューニング機能
■
効率的な SQL 文の開発
関連項目 :
■
■
SQL の概要は、
『Oracle Database 概要』を参照してください。
データベースの監視とチューニングについては、
『Oracle Database 2
日でデータベース管理者』を参照してください。
SQL チューニングの概要
12-1
SQL チューニングの概要
SQL チューニングの概要
SQL 文のチューニングは、データベース・システムのパフォーマンス・チューニングの重要
な側面です。SQL チューニングには、次の 3 つの基本手順を実行します。
■
■
■
システムで使用可能な過去の SQL 実行履歴を検討し、アプリケーションのワークロード
およびシステム・リソースの大部分に関係している高負荷または上位 SQL 文を識別し
ます。
これらの文について問合せオプティマイザにより生成される実行計画が適切に実行され
るかどうかを確認します。
修正アクションを実装し、パフォーマンスの低い SQL 文について適切な実行計画を生成
します。
システム・パフォーマンスが十分なレベルに達するか、他にチューニングできる文がなくな
るまで、この 3 つの手順を繰り返します。
チューニングの目的
システムをチューニングする目的は、システムのエンド・ユーザーへの応答時間を短縮した
り、同じ作業の処理に使用されるリソースを削減することです。これには、次の方法があり
ます。
■
ワークロードの削減
■
ワークロードの均衡化
■
ワークロードのパラレル化
ワークロードの削減
一般に、SQL チューニングには、同じワークロードをより効率的に処理する方法を見つけ出
すことが含まれます。機能性を変えることなく文の実行計画を変更し、リソース使用量を削
減することは可能です。
リソース使用量を削減する方法の 2 つの例を、次に示します。
1.
一般に実行される問合せで、アクセスするデータの表中での割合が少ない場合、効率的
な問合せの実行方法として、索引の使用があります。索引を作成すれば、使用するリ
ソースの量を削減できます。
2.
ユーザーが、特定のソート順序で戻される 10,000 行の最初の 20 行を見る場合でかつ、
索引で問合せ（およびソート順序）を満たすことができる場合、最初の 20 行を見るた
めに、10,000 行にアクセスしてソートする必要はありません。
12-2　Oracle Database パフォーマンス・チューニング・ガイド
高負荷 SQL の識別
ワークロードの均衡化
システムは、実ユーザーがシステムに接続している昼間に使用量が最大に達し、夜間には低
下する傾向があります。重要でないレポートやバッチ・ジョブを夜間に実行するようにスケ
ジューリングし、昼間の同時実行性が削減されれば、昼間の、より重要なプログラムのため
にリソースが解放されます。
ワークロードのパラレル化
大量のデータにアクセスする問合せ（代表的なものは、データ・ウェアハウス問合せ）は、
多くの場合、パラレル化できます。これは特に、同時実行性が低いデータ・ウェアハウスで
応答時間を短縮する場合に有効です。ただし、同時実行性が高い傾向のある OLTP 環境の場
合は、プログラム全体のリソース使用量を増加させることになり、他のユーザーに影響を与
える可能性があります。
高負荷 SQL の識別
この項では、高負荷 SQL 文について、識別およびデータ収集を行う手順を説明します。高負
荷の SQL とは、Oracle データベースのパフォーマンスに影響を与える、パフォーマンスの
低いリソース集中型の SQL 文です。高負荷 SQL 文は、次の手段で識別できます。
■
Automatic Database Diagnostic Monitor
■
自動ワークロード・リポジトリ
■
V$SQL ビュー
■
カスタム・ワークロード
■
SQL トレース
多くのリソースを消費する SQL の識別
リソース集中型の SQL を識別する最初のステップは、検討する問題の分類です。
■
単一（または少数）のプログラムに固有の問題であるか。
■
アプリケーション全体にわたる一般的な問題であるか。
特定のプログラムのチューニング
特定のプログラム（GUI または 3GL）をチューニングする場合、検討する SQL の識別は、
プログラム内で実行された SQL を見るだけの簡単な作業です。Oracle Enterprise Manager
に用意されているツールを使用して、リソースを多く使用する SQL 文の識別、EXPLAIN
PLAN の生成および SQL パフォーマンスの評価ができます。
SQL チューニングの概要
12-3
高負荷 SQL の識別
関連項目 :
■
■
SQL アプリケーションの監視とチューニングに使用可能なツールの詳
細は、
『Oracle Enterprise Manager 概要』を参照してください。
自動 SQL チューニング機能については、第 13 章「自動 SQL チューニ
ング」を参照してください。
SQL を識別できない（たとえば、SQL が動的に生成される）場合は、SQL_TRACE を使用し
て、実行された SQL を含むトレース・ファイルを生成し、次に TKPROF を使用して出力
ファイルを生成します。
TKPROF 出力ファイル内の SQL 文は、実行経過時間（exeela）などの各種パラメータで順
序付けできるため、通常は、SQL 文を経過時間で順序付けする（経過時間が最も長い SQL
文をファイルの一番上に置く）ことで識別に利用されます。これにより、ファイル内に SQL
文が多数ある場合に、パフォーマンスの低い SQL を識別するジョブの実行が容易になりま
す。
関連項目 :
第 20 章「アプリケーション・トレース・ツールの使用方法」
アプリケーションのチューニング / 負荷の軽減
アプリケーション全体のパフォーマンスが十分に最適化されていない場合や、データベー
ス・サーバーの CPU または I/O 全体の負荷を減らそうとする場合は、次の手順で、多くの
リソースを消費する SQL を識別します。
1.
検討する時間帯を判別します。通常は、アプリケーションの処理のピーク時間です。
2.
その期間の開始時と終了時にオペレーティング・システム統計および Oracle 統計を収
集します。収集する最小限の Oracle 統計は、ファイル I/O（V$FILESTAT）、システム
統計（V$SYSSTAT）および SQL 統計（V$SQLAREA または V$SQL、V$SQLTEXT、
V$SQL_PLAN および V$SQL_PLAN_STATISTICS）です。
関連項目 : Oracle ツールを使用して Oracle インスタンス・パフォーマン
ス・データを収集する方法の詳細は、第 6 章「自動パフォーマンス診断」
を参照してください。
3.
ステップ 2 で収集したデータを使用して、多くのリソースを使用する SQL 文を識別し
ます。候補の SQL 文を識別するには、V$SQLAREA を問い合せる方法が適しています。
V$SQLAREA には、共有プール内のすべての SQL 文に関するリソース使用率の情報が含
まれています。V$SQLAREA 内のデータを、リソース使用率で順序付けしてください。
共通リソースの主なものは、次のとおりです。
■
バッファ取得（V$SQLAREA.BUFFER_GETS。CPU 使用率の高い文の問合せ。
）
■
ディスク読取り（V$SQLAREA.DISK_READS。I/O 使用率の高い文の問合せ。
）
■
ソート（V$SQLAREA.SORTS。ソートの多い文の問合せ。
）
12-4　Oracle Database パフォーマンス・チューニング・ガイド
高負荷 SQL の識別
負荷の最も大きい SQL 文を識別する方法の 1 つは、その期間内に SQL 文で使用されたリ
ソースを、同じ期間内に使用されたそのリソースの総量と比較することです。BUFFER_
GETS の場合、各 SQL 文の BUFFER_GETS の回数を、期間中のバッファ取得の総数で除算し
ます。システム内のバッファ取得の総数は V$SYSSTAT 表の session logical reads の統計情
報からわかります。
同様に、V$SQL_AREA.DISK_READS を V$SYSSTAT 統計の physical reads の値で除算する
と、システムによって実行されるディスク読取りの総数のうち、文によって実行されるディ
スク読取りの割合を計算できます。自動ワークロード・リポジトリ・レポートの SQL セク
ションにはこのデータが含まれているため、割合を手動で計算する必要はありません。
関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リ
ファレンス』を参照してください。
候補の SQL 文を識別した後、文を調べるために必要な情報を収集し、チューニングします。
識別した SQL に関するデータの収集
CPU が問題となっている場合は、一定期間内に最も多くの BUFFER_GETS を実行した上位
の SQL 文を調べます。その他の場合は、最も多くの DISK_READS を実行した SQL 文から始
めます。
チューニング中に収集する情報
チューニング・プロセスではまず、基礎となる表と索引の構造を判別します。収集する情報
は、次のとおりです。
1.
V$SQLTEXT からの完全な SQL テキスト
2.
SQL 文で参照される表の構造（通常は SQL*Plus の表を記述）
3.
すべての索引（列、列の順序付け）の定義と、各索引が一意かどうか
4.
セグメントのオプティマイザ統計（表ごとの行数、索引列の選択性など）
、およびセグ
メントが最後に分析された日付
5.
SQL 文で参照されるビューの定義
6.
ステップ 5 で検出された、ビュー定義で参照されている表について、ステップ 2、3 お
よび 4 を繰り返します。
7.
SQL 文（EXPLAIN PLAN、V$SQL_PLAN または TKPROF 出力のいずれかからのもの）の
オプティマイザ計画の安定性
8.
その SQL 文の以前のオプティマイザ計画の安定性
SQL チューニングの概要
12-5
自動 SQL チューニング機能
注意 : アプリケーション内の主要な SQL 文すべてについて、実行計画を
生成し、見直すことが重要です。これにより、SQL 文が効率よく実行され
たときのオプティマイザの実行計画と、そうでないときの計画とを比較で
きます。データ量の変化などの情報とあわせて比較を行うと、パフォーマ
ンスの低下の原因を正確に識別できます。
自動 SQL チューニング機能
手動 SQL チューニング・プロセスはアプリケーション開発者に多数の作業が課されるため、
SQL チューニング・プロセスは自動 SQL チューニング管理機能により自動化されています。
これらの機能は、OLTP タイプとデータ・ウェアハウス・タイプのアプリケーションで同様
に機能するように設計されています。第 13 章「自動 SQL チューニング」を参照してくださ
い。
ADDM
Automatic Database Diagnostic Monitor（ADDM）では、高負荷 SQL 文など、Oracle デー
タベースにおいて考えられるパフォーマンス上の問題について、AWR によって収集された
情報が分析されます。6-3 ページの「Automatic Database Diagnostic Monitor」を参照して
ください。
SQL Tuning Advisor
SQL Tuning Advisor では、SQL 文を変更しないで SQL 文を素早く効率的に最適化すること
が可能です。13-6 ページの「SQL Tuning Advisor」を参照してください。
SQL Tuning Set
複数の SQL 文が ADDM または SQL Tuning Advisor への入力として使用される場合、SQL
Tuning Set（STS）が構成され、格納されます。STS には、SQL 文のセットと、関連する実
行コンテキストおよび基本実行統計が含まれます。13-11 ページの「SQL Tuning Set」を参
照してください。
SQL Access Advisor
Oracle では、SQL Tuning Advisor の他に、SQL Access Advisor が用意されています。これ
は、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログについてアド
バイスを提供するチューニング・ツールです。SQL Access Advisor では、指定のワークロー
ドに関するマテリアライズド・ビュー、マテリアライズド・ビュー・ログおよび索引の適切
なセットが推奨されるため、パフォーマンスの目標を達成するのに役立ちます。一般に、マ
テリアライズド・ビューおよび索引の数と、これらに割り当てられている領域が増えるにつ
れて、問合せのパフォーマンスが向上します。SQL Access Advisor では、領域使用量と問合
せパフォーマンスの兼合いが考慮され、新規および既存のマテリアライズド・ビューおよび
索引の最もコスト効率の高い構成が推奨されます。
12-6　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
Oracle Enterprise Manager Database Control から SQL Access Advisor にアクセスする手順
は、次のとおりです。
■
■
「Database」
」ページの最下部で、
「Related Links」
」の下の「
「Advisor Central」
」リンクを
クリックします。
「Advisor Central」
」ページで「
「SQLAccess Advisor」
」リンクをクリックし、ワークロー
ドのソースを分析できます。
関連項目 : SQL Access Advisor の詳細は、
『Oracle データ・ウェアハウ
ス・ガイド』を参照してください。
効率的な SQL 文の開発
この項では、SQL 文の効率を高める方法を説明します。
■
オプティマイザ統計の確認
■
実行計画の検討
■
SQL 文の再構成
■
索引の再構成
■
トリガーおよび制約の変更または無効化
■
データの再構成
■
実行計画の長期的な保持
■
データへのアクセスを最小限に削減
注意 : この項で説明するガイドラインは、頻繁に実行される本番 SQL に
関するものです。この項でお薦めしていない技法の大半は、パフォーマン
スが重要でない非定型文または頻繁に実行されないアプリケーションでは
使用してもかまいません。
SQL チューニングの概要
12-7
効率的な SQL 文の開発
オプティマイザ統計の確認
問合せオプティマイザでは、最適な実行計画の判別時に、表と索引について収集された統計
を使用します。これらの統計が収集されなかった場合、または、統計がデータベース内に格
納されているデータをすでに反映しなくなっている場合、オプティマイザには最適な計画を
生成するための十分な情報がありません。
チェックする内容
■
■
データベース内のいくつかの表に関する統計が必要な場合は、すべての表に関する統計
を収集するのが望ましい方法です。このことは、結合を実行する SQL 文がアプリケー
ションに含まれている場合に特に言えます。
データ・ディクショナリ内のオプティマイザ統計が表と索引内のデータを反映しなく
なっている場合は、新しい統計を収集します。ディクショナリ統計が失効しているかど
うかをチェックする方法の 1 つは、表の実際のカーディナリティ（行数）と、DBA_
TABLES.NUM_ROWS の値を比較することです。また、述語列に大きなデータの偏りがあ
る場合は、ヒストグラムを使用することを検討してください。
実行計画の検討
OLTP 環境で SQL 文をチューニング（または作成）する場合、最も選択性の高いフィルタを
持つ表から駆動することを目標とします。つまり、次のステップに渡される行を少なくする
ということです。次のステップが結合である場合は、少数の行しか結合されないということ
になります。アクセス・パスが最適かどうかを確認してください。
オプティマイザの実行計画を調べる場合は、次の内容を確認します。
■
■
■
■
駆動表が最適なフィルタを持つ計画であること。
各ステップの結合順序は、最少数の行が次のステップに戻されるようにします（つま
り、可能であれば、結合の順序は最適な未使用フィルタを選んで進むようにする必要が
あります）
。
結合方法が、それによって戻される行数からみた場合に、適切なものであること。たと
えば、索引でのネステッド・ループ結合は、多数の行が戻される場合には最適ではあり
ません。
ビューが効果的に使用されていること。SELECT 構文のリストを見て、ビューへのアク
セスが必要であるかどうかを確認してください。
■
意図しないデカルト積（小さい表の場合も含む）があるかどうか。
■
各表が効率的にアクセスされていること。
SQL 文の述語と、表の行数を評価します。大量の行を持つ表の全表スキャンなど、
WHERE 句に述語を持つ疑わしいアクティビティを探します。そのような選択的な述語
に索引が使用されない理由を判別します。
12-8　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
全表スキャンが非効率的というわけではありません。小さい表で全表スキャンを行う場
合や、戻される行数に対してよりよい結合方法（たとえば、hash_join）を活用するため
に、全表スキャンを行うほうが効率がよい場合があります。
これらの条件のうち最適でないものがある場合は、SQL 文の再構成や、表で使用できる索引
について考慮します。
SQL 文の再構成
非効率的な SQL 文は、修正するよりも書き直す方が簡単なことがよくあります。元の文の
意図を理解していれば、要件を満たす新しい文を迅速かつ容易に作成できます。
AND と = を使用した条件の組立て
SQL の効率性を高めるには、可能なかぎり等価結合を使用します。変換されない列値に対し
て等価結合を実行する文は、最も容易にチューニングできます。
WHERE 句での変換列の回避
変換されない列値を使用します。たとえば、次の例のように使用します。
WHERE a.order_no = b.order_no
次の例は使用しません。
WHERE TO_NUMBER (SUBSTR(a.order_no, INSTR(b.order_no, '.') - 1))
= TO_NUMBER (SUBSTR(a.order_no, INSTR(b.order_no, '.') - 1))
述語句または WHERE 句では、SQL ファンクションを使用しないでください。列を引数とし
て持つ関数など、列を使用する式は、使用できる定義済ファンクション索引がないかぎり、
その列の索引を使用できる可能性をオプティマイザが無視する原因となります（一意索引も
例外ではありません）
。
型が混在する式は避け、暗黙的な型変換に注意してください。VARCHAR2 列 charcol の索
引を使用するときに、WHERE 句が次のようであるとします。
AND charcol = numexpr
numexpr は数値型の式（たとえば、1、USERENV（'SESSIONID'）
、numcol、numcol+0、
...）であり、Oracle はこの式を次のように変換します。
AND TO_NUMBER(charcol) = numexpr
次に示すタイプの複合式は使用しないようにしてください。
■
col1 = NVL (:b1,col1)
■
NVL (col1,-999) = ….
■
TO_DATE()、TO_NUMBER() など
SQL チューニングの概要
12-9
効率的な SQL 文の開発
ここに示した式によって、オプティマイザは有効なカーディナリティまたは選択性の見積り
を割り当てることができなくなります。この結果、全体の計画および結合方法に悪い影響を
与えます。
NVL() のかわりに述語を追加します。
たとえば、次のようにします。
SELECT employee_num, full_name Name, employee_id
FROM mtl_employees_current_view
WHERE (employee_num = NVL (:b1,employee_num)) AND (organization_id=:1)
ORDER BY employee_num;
これは次のようにします。
SELECT employee_num, full_name Name, employee_id
FROM mtl_employees_current_view
WHERE (employee_num = :b1) AND (organization_id=:1)
ORDER BY employee_num;
フィルタまたは述語結合で SQL ファンクションを使用する必要がある場合、索引を持つ列
に対しては使用しないでください。そのかわり、次の文に示すように、述語の反対側に SQL
ファンクションを使用してください。
TO_CHAR(numcol) = varcol
次の例は使用しません。
varcol = TO_CHAR(numcol)
関連項目 : ファンクション索引の詳細は、第 16 章「索引およびクラスタ
の使用方法」を参照してください。
特定のタスクに対する専用の SQL 文の作成
SQL は、手続き型言語ではありません。1 つの SQL を使用して様々なことを実行すると、
通常は各タスクに最適でない結果が生じます。SQL を使用して様々なタスクを実行する場合
は、1 つの文にパラメータを指定して異なるタスクを実行するのではなく、様々な文を作成
してください。
12-10　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
注意 : Oracle Forms と Oracle Reports は、PL/SQL（トリガーまたはプ
ログラム・ユニット）を使用してアプリケーション・ロジックをコード化
するための強力な開発ツールです。Forms または Reports で複雑なロジッ
クを処理することによって、SQL 文の複雑さを減らすことができます。ま
た、規模の大きな単一の複雑な SQL 文のかわりに、少数の SQL 文を実行
するサーバー側の PL/SQL パッケージを起動することもできます。この
パッケージはサーバー側のユニットであるため、クライアントとデータ
ベースの間のラウンドトリップやネットワークの通信量の問題は発生しま
せん。
通常、異なるタスクには個別の SQL 文を作成することが適していますが、使用する SQL 文
を 1 つにする必要がある場合は、UNION ALL 演算子を使用することによって、非常に複雑な
文を多少簡略化できます。
最適化（実行計画の決定）は、どの値で問合せが置換されるかをデータベースが認識する前
に行われます。したがって、実行計画はそれらの値が何であるかに依存しません。たとえ
ば、次のようにします。
SELECT info
FROM tables
WHERE ...
AND somecolumn BETWEEN DECODE(:loval, 'ALL', somecolumn, :loval)
AND DECODE(:hival, 'ALL', somecolumn, :hival);
この例では、データベースは somecolumn 列に対して索引を使用できません。この列を含
む式が、BETWEEN の両辺で同じ列を使用するためです。
このことは、選択性の高い、索引作成可能な他の条件が別にあって、それを使用して駆動表
にアクセスできる場合には問題になりません。ただし、これにあてはまらない場合もよくあ
ります。この例のような条件で索引を使用することは多くありますが、:loval などの値を、
あらかじめ知っておく必要があります。この情報があれば、索引を使用できない ALL のケー
スを除外できます。
:loval と :hival に実際の値が指定されている場合には必ず索引を使用する場合（:loval
と :hival の間が狭く、多くの場合等しいことが期待できる場合）は、この例を論理的に等
しい、次の形式にリライトできます。
SELECT /* change this half of UNION ALL if other half changes */ info
FROM tables
WHERE ...
AND somecolumn BETWEEN :loval AND :hival
AND (:hival != 'ALL' AND :loval != 'ALL')
UNION ALL
SELECT /* Change this half of UNION ALL if other half changes. */ info
FROM tables
SQL チューニングの概要
12-11
効率的な SQL 文の開発
WHERE ...
AND (:hival = 'ALL' OR :loval = 'ALL');
この新しい問合せで EXPLAIN PLAN を実行した場合、望ましい実行計画と望ましくない実
行計画の両方が得られるように思われます。しかし、データベースが UNION ALL の前半と
後半のどちらを実行するかを決めるために最初に評価する条件は、:hival と :loval が
ALL であるかどうかの複合条件です。データベースは、問合せの前半と後半のどちらかの実
行計画から実際に行を取得する前に、この条件を評価します。
UNION ALL 問合せの一方に関して条件が false であれば、その部分はそれ以上評価されませ
ん。与えられている値に関して最適な実行計画の部分のみが実際に実行されます。:hival
と :loval に関する最終条件はどちらか一方のみが true であることが保証されているので、
実際に行を戻すのは UNION ALL の半分のみです。
（UNION ALL 内の ALL は、この排他性に
より論理的に有効です。これにより、問合せの両半分の結果から重複行を除外するためにコ
ストの高いソートを実行することなく、計画を実行できます。
）
副問合せに対する EXISTS と IN の使用
ある環境では、EXISTS より IN を使用したほうが適していることがあります。一般に、選
択的述語が副問合せにある場合は、IN を使用します。選択的述語が親問合せの中にある場
合は、EXISTS を使用します。
注意 : この説明は、親 SQL または副問合せへのアクセス・パスが選択性
の高い索引付きの列を経由するような OLTP 環境で最も当てはまります。
DSS 環境では、親 SQL または副問合せの選択性が低い場合があり、結合
列には索引がない可能性もあります。DSS 環境では、EXISTS の場合にセ
ミ結合を使用することを考慮してください。
関連項目 : 『Oracle データ・ウェアハウス・ガイド』
副問合せに IN 句を使用した場合に、副問合せで指定される選択性の利点を活用するために、
Oracle が副問合せをリライトすることがあります。これは、最も選択性の高いフィルタが副
問合せにある場合、結合列に索引がある場合に、最も有効です。これに対し、EXISTS は、
最も選択性の高いフィルタが親問合せにある場合に有効です。その場合、EXISTS 基準に照
らして行をフィルタにかける前に、親問合せの選択的述語を適用できるからです。
注意 : 使用したリソース（V$SQL または V$SQLAREA からの BUFFER_
GETS、DISK_READS または CPU_TIME）の実際の数で、文のオプティマ
イザ・コストを検証する必要があります。データの偏り（ヒストグラムを
使用しない）などの状況は、オプティマイザの操作コストの見積りにマイ
ナスの影響を与える可能性があります。
12-12　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
「例 1: IN の使用 : 副問合せ内の選択的フィルタ」および「例 2: EXISTS の使用 : 親の中の選
択的述語」に、IN および EXISTS の利点を実証する 2 つの例を示します。いずれの例でも、
次の特性を持つ同じスキーマを使用します。
■
employees.employee_id フィールドに一意索引があります。
■
orders.customer_id フィールドに索引があります。
■
employees.department_id フィールドに索引があります。
■
employees 表には 27,000 行あります。
■
orders 表には 10,000 行あります。
■
OE および HR スキーマに、これらのセグメントがあり、ともに COMPUTE で分析されてい
ます。
例 1: IN の使用 : 副問合せ内の選択的フィルタ この例は、IN を使用するように問合せをリラ
イトすると、パフォーマンスがどのように向上するかを示しています。この問合せでは、顧
客 144 のオーダーを発注したすべての社員を識別します。
EXISTS を使用する SQL 文
SELECT /* EXISTS example */
e.employee_id, e.first_name, e.last_name, e.salary
FROM employees e
WHERE EXISTS (SELECT 1 FROM orders o
/* Note 1 */
WHERE e.employee_id = o.sales_rep_id
/* Note 2 */
AND o.customer_id = 144);
/* Note 3 */
注意 :
■
Note 1: EXISTS を含む行です。
■
Note 2: 副問合せを相関副問合せにする行です。
■
Note 3: 相関副問合せに選択性の高い述語 customer_id = number が
含まれている行です。
SQL チューニングの概要
12-13
効率的な SQL 文の開発
次の計画出力は、前述の文の実行計画（V$SQL_PLAN からのもの）です。この計画では、
employees 表の全表スキャンを必要とし、そのため、多数の行が戻されます。次に、戻さ
れた各行が orders 表で（索引を経由して）フィルタにかけられます。
ID OPERATION
---- -------------------0 SELECT STATEMENT
1 FILTER
2
TABLE ACCESS
3
TABLE ACCESS
4
INDEX
OPTIONS
OBJECT_NAME
OPT
COST
--------------- ---------------------- --- ---------CHO
FULL
BY INDEX ROWID
RANGE SCAN
EMPLOYEES
ORDERS
ORD_CUSTOMER_IX
ANA
ANA
ANA
155
3
1
IN を使用して文をリライトすると、使用されるリソースが大幅に減少します。
IN を使用する SQL 文
SELECT /* IN example */
e.employee_id, e.first_name, e.last_name, e.salary
FROM employees e
WHERE e.employee_id IN (SELECT o.sales_rep_id
/* Note 4 */
FROM orders o
WHERE o.customer_id = 144); /* Note 3 */
注意 :
■
■
Note 3: 相関副問合せに選択性の高い述語 customer_id = number が
含まれている行です。
Note 4: IN が使用されている行です。副問合せは、相関ではなくなっ
ています。これは、IN 句が副問合せ内の結合を置換するためです。
次の計画出力は、前述の文の実行計画（V$SQL_PLAN からのもの）です。オプティマイザは
副問合せをビューにリライトし、次にそれが一意索引で employees 表に結合されます。こ
の結果、計画は大幅に改善されます。ビュー（すなわち、副問合せ）に選択的述語があるた
め、わずかな employee_id のみが戻されるためです。次に、このわずかな employee_id
で、一意索引から employees 表にアクセスします。
ID OPERATION
---- -------------------0 SELECT STATEMENT
1 NESTED LOOPS
2
VIEW
3
SORT
4
TABLE ACCESS
5
TABLE ACCESS
6
INDEX
OPTIONS
OBJECT_NAME
OPT
COST
--------------- ---------------------- --- ---------CHO
5
3
UNIQUE
3
FULL
ORDERS
ANA
1
BY INDEX ROWID EMPLOYEES
ANA
1
UNIQUE SCAN
EMP_EMP_ID_PK
ANA
12-14　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
例 2: EXISTS の使用 : 親の中の選択的述語 この例は、EXISTS を使用するように問合せをリ
ライトすると、パフォーマンスがどのように向上するかを示しています。この問合せでは、
オーダーを発注した、部門 80 の全営業社員を識別します。
IN を使用する SQL 文
SELECT /* IN example */
e.employee_id, e.first_name, e.last_name, e.department_id,
FROM employees e
WHERE e.department_id = 80
/*
AND e.job_id
= 'SA_REP'
/*
AND e.employee_id IN (SELECT o.sales_rep_id FROM orders o); /*
e.salary
Note 5 */
Note 6 */
Note 4 */
注意 :
■
■
Note 4: IN が使用されている行です。副問合せは、相関ではなくなっ
ています。これは、IN 句が副問合せ内の結合を置換するためです。
Note 5 および 6: 親 SQL 内に選択的述語があります。
次の計画出力は、前述の文の実行計画（V$SQL_PLAN からのもの）です。SQL 文は、
orders 表でビューを使用するようにオプティマイザでリライトされています。この文で
は、orders 表に存在するすべての一意の employee_id を戻すためにデータのソートが必
要です。述語がないため、多数の employee_ids が戻されます。この多数の employee_
id からなる大きなリストが、一意索引を使用して employees 表へのアクセスに使用され
ることになります。
ID OPERATION
---- -------------------0 SELECT STATEMENT
1 NESTED LOOPS
2
VIEW
3
SORT
4
TABLE ACCESS
5
TABLE ACCESS
6
INDEX
OPTIONS
OBJECT_NAME
OPT
COST
--------------- ---------------------- --- ---------CHO
125
116
UNIQUE
116
FULL
ORDERS
ANA
40
BY INDEX ROWID EMPLOYEES
ANA
1
UNIQUE SCAN
EMP_EMP_ID_PK
ANA
SQL チューニングの概要
12-15
効率的な SQL 文の開発
EXISTS を使用する SQL 文
SELECT /* EXISTS example */
e.employee_id, e.first_name, e.last_name, e.salary
FROM employees e
WHERE e.department_id = 80
/* Note 5
AND e.job_id
= 'SA_REP'
/* Note 6
AND EXISTS (SELECT 1
/* Note 1
FROM orders o
WHERE e.employee_id = o.sales_rep_id); /* Note
*/
*/
*/
2 */
注意 :
■
Note 1: EXISTS を含む行です。
■
Note 2: 副問合せを相関副問合せにする行です。
■
Note 5 および 6: 親 SQL 内に選択的述語があります。
次の計画出力は、前述の文の実行計画（V$SQL_PLAN からのもの）です。計画のコストは、
EXISTS を使用するように SQL 文をリライトすることで削減されます。この計画は、より効
率的です。これは、2 つの索引を使用して親問合せ内の述語を満たすため、戻される
employee_id がきわめて少ないためです。次に、この employee_id を使用して、索引か
ら orders 表にアクセスします。
ID OPERATION
---- -------------------0 SELECT STATEMENT
1 FILTER
2
TABLE ACCESS
3
AND-EQUAL
4
INDEX
5
INDEX
6
INDEX
OPTIONS
OBJECT_NAME
OPT
COST
--------------- ---------------------- --- ---------CHO
BY INDEX ROWID
EMPLOYEES
ANA
98
RANGE SCAN
RANGE SCAN
RANGE SCAN
EMP_JOB_IX
EMP_DEPARTMENT_IX
ORD_SALES_REP_IX
ANA
ANA
ANA
8
注意 : より効果的なアプローチは、department_id および job_id の
連結索引を作成することです。これによって 2 つの索引にアクセスする必
要がなくなり、使用されるリソースが削減されます。
12-16　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
ヒントによるアクセス・パスおよび結合順序の制御
オプティマイザのアプローチと目標の設定および問合せオプティマイザの代表的な統計の収
集によって、オプティマイザの選択を変えることができます。特定のアプリケーション・
データに関して、オプティマイザよりも多くの情報を持つアプリケーション設計者であれ
ば、より効率よく SQL 文を実行する方法を選択できる場合があります。SQL 文のヒントを
使用すれば、文を実行する方法を指定できます。
/*+FULL */ などのヒントは、アクセス・パスを制御します。たとえば、次のようにします。
SELECT /*+ FULL(e) */ e.last_name
FROM employees e
WHERE e.job_id = 'CLERK';
関連項目 : 第 14 章「問合せオプティマイザ」および 第 17 章「オプティ
マイザ・ヒント」
結合順序は、パフォーマンスに大きな影響を与えることがあります。SQL のチューニングの
主な目的は、結果に影響しない不要な行にアクセスする作業を回避することです。このこと
から次の 3 つの一般ルールが導かれます。
■
■
■
索引を介して必要な行を取得するほうが効率的な場合には、全表スキャンを避けてくだ
さい。
100 行をフェッチする別の索引を使用できる場合には、駆動表から 10,000 行をフェッチ
する索引を使用するようなことは避けてください。
結合順序の後ろへ行くほど結合する行が少なくなるように結合順序を選択してくださ
い。
次の例は、結合順序を効果的にチューニングする方法を示しています。
SELECT info
FROM taba a, tabb b, tabc c
WHERE a.acol BETWEEN 100 AND 200
AND b.bcol BETWEEN 10000 AND 20000
AND c.ccol BETWEEN 10000 AND 20000
AND a.key1 = b.key1
AND a.key2 = c.key2;
SQL チューニングの概要
12-17
効率的な SQL 文の開発
1.
駆動表と駆動索引（存在する場合）を選択します。
前述の例における最初の 3 つの条件は、それぞれ 1 つの表にのみ適用されるフィルタ条
件です。最後の 2 つの条件は結合条件です。
フィルタ条件は、駆動表と駆動索引の選択を左右します。一般に、表内の排除される部
分の比率が最も高くなるフィルタ条件を含む表は駆動表です。この例では、100 ～ 200
の範囲は acol の範囲に比べて狭く、10000 ～ 20000 の範囲は相対的に大きいため、
taba は駆動表であり、他はすべて同じです。
ネステッド・ループ結合の場合、結合はすべて結合索引を介して行う必要があります。
この結合索引は、主キーまたは外部キーに付けられているもので、その表を結合ツリー
内のそれより前にある表に結びつけるために使用します。駆動表を除いて、非結合条件
にこの結合索引を使用することはほとんどありません。そのため、taba を駆動表とし
て選択した後は、b.key1 と c.key2 の索引を使用して tabb と tabc を駆動します。
2.
未使用の最適なフィルタを最初に駆動する最適な結合順序を選択します。
最適な未使用フィルタを持つ表に先に結合することでその後の結合の作業は、削減でき
ます。したがって、
「bcol BETWEEN ...」が「ccol between ...」よりも限定的な（行を
より高い比率で排除する）場合は、tabb が tabc よりも前に結合されると、最後の結
合はより簡単に（より少ない行で）実行できます。
3.
ORDERED または STAR ヒントを使用して、結合順序を強制的に設定できます。
関連項目 :
17-30 ページ「結合順序のヒント」
ビューを管理するときの注意
ビューの結合、ビューへの外部結合、および既存ビューの新規目的への再利用に対しては、
注意が必要です。
複合ビューを結合するときの注意 複合ビューへの結合、特に、ある複合ビューから別の複
合ビューへの結合はお薦めできません。そのような結合を行うと、多くの場合、ビュー全体
がインスタンス化され、ビュー・データに対して問合せが行われる結果になります。
たとえば、次の文は従業員および部門をリストするビューを作成します。
CREATE OR REPLACE VIEW emp_dept
AS
SELECT d.department_id, d.department_name, d.location_id,
e.employee_id, e.last_name, e.first_name, e.salary, e.job_id
FROM departments d
,employees e
WHERE e.department_id (+) = d.department_id;
12-18　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
次の問合せは指定した状態の従業員を検索します。
SELECT v.last_name, v.first_name, l.state_province
FROM locations l, emp_dept v
WHERE l.state_province = 'California'
AND
v.location_id = l.location_id (+);
次の計画表出力では、emp_dept ビューがインスタンス化されます。
-------------------------------------------------------------------------------| Operation
| Name
| Rows | Bytes| Cost | Pstart| Pstop |
-------------------------------------------------------------------------------| SELECT STATEMENT
|
|
|
|
|
|
|
| FILTER
|
|
|
|
|
|
|
|
NESTED LOOPS OUTER
|
|
|
|
|
|
|
|
VIEW
|EMP_DEPT |
|
|
|
|
|
|
NESTED LOOPS OUTER
|
|
|
|
|
|
|
|
TABLE ACCESS FULL
|DEPARTMEN |
|
|
|
|
|
|
TABLE ACCESS BY INDEX|EMPLOYEES |
|
|
|
|
|
|
INDEX RANGE SCAN
|EMP_DEPAR |
|
|
|
|
|
|
TABLE ACCESS BY INDEX R|LOCATIONS |
|
|
|
|
|
|
INDEX UNIQUE SCAN
|LOC_ID_PK |
|
|
|
|
|
--------------------------------------------------------------------------------
ビューの再利用禁止 ある用途のために作成したビューを他の用途に使用することは、不適
切な場合があるため注意してください。ビューから問合せを行うと、データを戻すために、
そのビューに関連するすべての表がアクセスされます。ビューを再利用する前に、ビュー内
のすべての表にアクセスしてデータを戻す必要があるかどうかを判別してください。その必
要がない場合は、ビューを使用しないでください。かわりに、実表を使用するか、必要に応
じて新しいビューを定義してください。その目的は、必要なデータを戻すために参照する表
およびビューの数を最小限にすることにあります。
次の例を見てください。
SELECT department_name
FROM emp_dept
WHERE department_id = 10;
ビュー全体ではまず、employees および departments 表の結合によりインスタンス化さ
れ、次にデータが集計されます。ただし、department_name と department_id は、
departments 表から直接取得できます。emp_dept ビューを問い合せてこの情報を取得す
ることは非効率的です。
SQL チューニングの概要
12-19
効率的な SQL 文の開発
副問合せのネストを解除するときの注意 副問合せのネストの解除によって、副問合せ本体
が解除され、その副問合せが含まれている文の本体にマージされます。これにより、オプ
ティマイザは、アクセス・パスと結合を評価するときに、副問合せと本体の両方をいっしょ
に考慮させてしまいます。
関連項目 : 副問合せのネスト解除における危険性については、
『Oracle
データ・ウェアハウス・ガイド』を参照してください。
ビューへの外部結合を実行するときの注意 複数表のビューに対する外部結合の場合、等価
述語が定義されていれば、問合せオプティマイザ（リリース 8.1.6 以上）は外部結合列から
駆動できます。
ビュー内での外部結合は、外部結合のパフォーマンスに与える影響が読めないため、問題が
発生しやすくなります。
中間結果の格納
中間の表、すなわちステージング表がリレーショナル・データベース・システムで比較的よ
く利用されるのは、それらの表に中間結果を一時的に格納するためです。これは、多くのア
プリケーションで役に立つものですが、作成するにはさらにリソースが必要になります。し
たがって、これらの表による利益が、作成のコストに見合うものかどうかを常に考慮してく
ださい。ステージング表は、その情報が何回も再利用されない場合は、作成しないようにし
てください。
他の考慮事項
■
■
■
ステージング表に中間結果を格納することで、アプリケーション・パフォーマンスを向
上できる場合があります。一般に、中間結果が、引き続きその後の複数の問合せで使用
可能であれば、その結果をステージング表に格納する価値があります。中間結果の再利
用により、複雑な文を使用して何度もデータを取り出すことをしないで済む利益は、中
間結果をマテリアライズするコストを上回ります。
長く複雑な問合せは、理解し、最適化することが困難です。ステージング表を使用する
ことで、複雑な SQL 文をいくつかの小さい文に分解でき、このとき、各ステップの結
果を格納します。
マテリアライズド・ビューを使用することを検討してください。マテリアライズド・
ビューは、ファクト表やディメンション表からの集計データや結合データを格納する、
あらかじめ計算済の表です。
関連項目 : マテリアライズド・ビューの使用方法に関する詳細は、
『Oracle データ・ウェアハウス・ガイド』を参照してください。
12-20　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
索引の再構成
多くの場合は、索引を再構成すると、パフォーマンスが向上します。これには、次の内容が
含まれます。
■
非選択的な索引を削除して、DML の速度を上げます。
■
パフォーマンス重視のアクセス・パスの索引を作成します。
■
既存の連結索引で列を並び換えることを考慮します。
■
索引に列を追加して、選択性を向上します。
索引を万能策として使用しないでください。アプリケーションの開発者は、索引を多く作成
すればパフォーマンスが改善されると考えることがあります。1 人のプログラマが適切に索
引を作成すれば、アプリケーションのパフォーマンスは十分に改善される可能性がありま
す。ただし、50 名のプログラマが別々に索引を作成すると、アプリケーションのパフォーマ
ンス改善は望めません。
トリガーおよび制約の変更または無効化
トリガーを使用すると、システムのリソースが消費されます。使用するトリガーが多すぎる
と、パフォーマンスに悪影響が及ぶので、トリガーを変更または使用禁止にする必要がある
場合があります。
データの再構成
索引と文を再構成した後で、データの再構成について検討できます。
■
■
■
導出された値を用意しておきます。応答時間重視のコードでは、GROUP BY の使用を回
避します。
データ設計を検討します。変更によりパフォーマンスの向上が見込める場合は、システ
ムの設計を変更します。
必要に応じて、パーティション化を考慮します。
実行計画の長期的な保持
格納されている統計または SQL 実行計画を使用すると、SQL 文の既存の実行計画を長期的
に保持できます。表のオプティマイザの統計を格納すると、その表を参照するすべての SQL
文にその統計が適用されます。実行計画を格納すると（すなわち、プラン・スタビリティ）
、
単一の SQL 文の計画が保持されます。統計およびストアド・プランの両方が SQL 文に対し
て使用可能な場合は、オプティマイザはストアド・プランのほうを使用します。
関連項目 :
■
第 15 章「オプティマイザ統計の管理」
■
第 18 章「プラン・スタビリティの使用方法」
SQL チューニングの概要
12-21
効率的な SQL 文の開発
データへのアクセスを最小限に削減
アプリケーションから各行へのアクセスを、可能なかぎり 1 回のみにします。そうすること
で、ネットワークの通信量が削減され、データベースの負荷が軽減されます。次を実行する
ことを考慮してください。
■
CASE 文による複数のスキャンの結合
■
RETURNING 句を持つ DML の使用
■
1 つの文での必要なすべてのデータの変更
CASE 文による複数のスキャンの結合
多くの場合、様々な表セットで異なった集計を行う必要があります。通常、この計算は、表
に複数のスキャンを行って処理されますが、1 回の単一のスキャンですべての集計を計算す
ると簡単です。n-1 回のスキャンを排除することで、パフォーマンスを大幅に向上できます。
複数のスキャンを 1 つのスキャンに結合するには、各スキャンの WHERE 条件の内容を CASE
文の中に移動します。CASE 文は、集計対象のデータをフィルタにかけます。各集計では、
データを取り出す別の列があっても構いません。
次の例では、収入が毎月 2000 より少ない社員、2000 ～ 4000 の社員、4000 を超える社員の
数を問い合せています。これは、次の 3 つの問合せで行うことができます。
SELECT COUNT (*)
FROM employees
WHERE salary < 2000;
SELECT COUNT (*)
FROM employees
WHERE salary BETWEEN 2000 AND 4000;
SELECT COUNT (*)
FROM employees
WHERE salary>4000;
しかし、1 つの文で問合せ全体を実行するほうが効率的です。各数値は 1 つの列として計算
されます。count ファンクションは、CASE 文によるフィルタを使用して、条件が一致する
行のみを数えます。たとえば、次のようにします。
SELECT COUNT (CASE WHEN
THEN
COUNT (CASE WHEN
THEN
COUNT (CASE WHEN
THEN
FROM employees;
salary
1 ELSE
salary
1 ELSE
salary
1 ELSE
< 2000
null END) count1,
BETWEEN 2001 AND 4000
null END) count2,
> 4000
null END) count3
12-22　Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
これは、きわめて単純な例です。範囲が重なっていたり、集計の関数が異なっていることも
あります。
RETURNING 句を持つ DML の使用
適時、INSERT、UPDATE または DELETE...RETURNING を使用して、1 回のコールでデータ
を選択および変更します。この技法は、データベースのコール回数を減らすことでパフォー
マンスを改善します。
関連項目 : INSERT、UPDATE および DELETE の各文の構文については、
『Oracle Database SQL リファレンス』を参照してください。
1 つの文での必要なすべてのデータの変更
可能であれば、配列処理を使用します。つまり、バインド変数の値の配列が繰返し実行のた
めに Oracle に渡されます。これは、あるセットの複数行が同じ操作の対象である場合のく
り返し処理に適しています。
たとえば、次のようにします。
BEGIN
FOR pos_rec IN (SELECT *
FROM order_positions
WHERE order_id = :id) LOOP
DELETE FROM order_positions
WHERE order_id = pos_rec.order_id AND
order_position = pos_rec.order_position;
END LOOP;
DELETE FROM orders
WHERE order_id = :id;
END;
別の方法として、orders に対するカスケード制約を定義できます。前述の例では、1 つの
SELECT に対して n 個の DELETE が実行されます。orders 表に対する DELETE 要求とし
て、DELETE FROM orders WHERE order_id = :id に対して DELETE を発行すると、デー
タベースは、1 回の DELETE 文で複数の行を自動的に削除します。
関連項目 : 分散問合せをチューニングする方法の詳細は、『Oracle
Database 管理者ガイド』または『Oracle Database Heterogeneous
Connectivity 管理者ガイド』を参照してください。
SQL チューニングの概要
12-23
効率的な SQL 文の開発
12-24　Oracle Database パフォーマンス・チューニング・ガイド
13
自動 SQL チューニング
この章では、Oracle の自動 SQL チューニング機能について説明します。
この章には次の項があります。
■
自動 SQL チューニングの概要
■
SQL Tuning Advisor
■
API による SQL プロファイルの管理
■
SQL Tuning Set
■
SQL チューニング情報ビュー
関連項目 : SQL 文の監視およびチューニングの詳細は、『Oracle
Database 2 日でデータベース管理者』を参照してください。
自動 SQL チューニング 13-1
自動 SQL チューニングの概要
自動 SQL チューニングの概要
自動 SQL チューニングは問合せオプティマイザの新機能であり、SQL チューニング・プロ
セス全体を自動化します。新しく拡張された問合せオプティマイザを使用して SQL 文を
チューニングすると、複雑で反復的、また時間のかかる作業である手動 SQL チューニング
が自動プロセスに置き換えられます。自動 SQL チューニング機能は、SQL Tuning Advisor
でユーザーに公開されます。
問合せオプティマイザのモード
拡張された問合せオプティマイザには、標準およびチューニングという 2 つのモードがあり
ます。
標準モード
標準モードのオプティマイザでは、SQL がコンパイルされて実行計画が生成されます。この
モードで生成される実行計画は、大多数の SQL 文に対して妥当なものです。標準モードで
は、オプティマイザは通常はミリ秒単位の厳密な時間的制約に従って動作し、その期間内に
適切な実行計画を検出する必要があります。
チューニング・モード
チューニング・モードのオプティマイザでは、追加の分析が実行され、標準モードで生成さ
れた実行計画をさらに改善できるかどうかがチェックされます。問合せオプティマイザの出
力には、実行計画ではなく、きわめて優れた計画を生成するための一連のアクション、その
理論的根拠および予測されるメリットが示されます。チューニング・モードでコールされる
オプティマイザを、自動チューニング・オプティマイザと呼びます。自動チューニング・オ
プティマイザにより実行されるチューニングを、自動 SQL チューニングと呼びます。
チューニング・モードのオプティマイザでは、1 つの文のチューニングに数分かかることが
あります。問合せをハード解析するたびに、自動チューニング・オプティマイザを起動する
ための時間およびリソースの両方が集中的に使用されます。自動チューニング・オプティマ
イザは、システム全体に通常とは異なる影響を与える複雑で高負荷な SQL 文に使用される
ことを意図した機能です。自動 SQL チューニングの適切な候補となる高負荷の SQL 文は、
Automatic Database Diagnostic Monitor（ADDM）によりプロアクティブに識別されます。
第 6 章「自動パフォーマンス診断」を参照してください。
13-2　Oracle Database パフォーマンス・チューニング・ガイド
自動 SQL チューニングの概要
チューニング分析のタイプ
自動 SQL チューニングには、次の 4 タイプのチューニング分析が含まれます。
■
統計分析
■
SQL プロファイリング
■
アクセス・パス分析
■
SQL 構造分析
統計分析
問合せオプティマイザは、オブジェクト統計に依存して実行計画を生成します。これらの統
計が失効または欠落している場合、オプティマイザに必要な情報がなく、不適切な実行計画
が生成される可能性があります。自動チューニング・オプティマイザは、問合せオブジェク
トごとに統計の欠落や失効がないかどうかをチェックし、次の 2 つのタイプの出力を生成し
ます。
■
統計が失効または欠落しているオブジェクトに関して関連統計を収集するための推奨
事項
オプティマイザ統計は自動的に収集されリフレッシュされるため、この問題が発生する
のは自動オプティマイザ統計収集がオフになっていた場合のみです。15-3 ページの「自
動統計収集」を参照してください。
■
統計が欠落しているオブジェクトに関する統計形式の補足情報と、統計が失効している
オブジェクトに関する統計調整ファクタ
この補足情報は、SQL プロファイルと呼ばれるオブジェクトに格納されます。
SQL プロファイリング
問合せオプティマイザでは、情報の欠落が原因で文の属性に関して不正確な見積りが生成さ
れ、そのために不適切な実行計画が生成される場合があります。従来は、オプティマイザが
適切に決定できるようにアプリケーション・コードに手動でヒントを追加することで、この
問題を解決してきました。パッケージ化されたアプリケーションの場合は、アプリケーショ
ン・コードを変更できず、不具合のログをアプリケーション・ベンダーに提供して修正され
るまで待つ必要があります。
自動 SQL チューニングは、この問題に SQL プロファイリング機能で対処します。自動
チューニング・オプティマイザでは、SQL プロファイルと呼ばれる SQL 文のプロファイル
が作成されます。このプロファイルは、その文に固有の補助統計で構成されます。標準モー
ドの問合せオプティマイザではカーディナリティ、選択性およびコストを見積りますが、こ
れらの値が大幅にずれているために不適切な実行計画が生成されることがあります。SQL プ
ロファイルは、サンプリングおよび部分実行テクニックを使用して追加情報を収集し、これ
らの見積りを検証し、必要に応じて調整することで、この問題に対処します。
自動 SQL チューニング 13-3
自動 SQL チューニングの概要
SQL プロファイリング中に、自動チューニング・オプティマイザは SQL 文の実行履歴情報
も使用して、その SQL 文の OPTIMIZER_MODE 初期化パラメータの設定を ALL_ROWS から
FIRST_ROWS に変更するなど、オプティマイザのパラメータを適切に設定します。
このタイプの分析の出力は、SQL プロファイルを受け入れるための推奨事項です。受け入れ
た SQL プロファイルは、データ・ディクショナリに永続的に格納されます。SQL プロファ
イルは特定の問合せに固有であることに注意してください。SQL プロファイルを受け入れる
と、標準モードのオプティマイザでは、実行計画の生成時に SQL プロファイル内の情報と
通常のデータベース統計が併用されます。追加情報が使用可能になることで、アプリケー
ション・コードを変更しなくても、対応する SQL 文に関して適切にチューニングされた計
画を生成できます。
SQL プロファイルの有効範囲は、CATEGORY プロファイル属性で制御できます。この属性に
より、どのユーザー・セッションでプロファイルを適用できるかが決まります。SQL プロ
ファイルの CATEGORY 属性は、DBA_SQL_PROFILES ビューの CATEGORY 列で確認できま
す。デフォルトでは、すべてのプロファイルは DEFAULT カテゴリに作成されます。つまり、
SQLTUNE_CATEGORY 初期化パラメータが DEFAULT に設定されているユーザー・セッショ
ンはすべて、そのプロファイルを使用できます。
SQL プロファイルのカテゴリを変更すると、プロファイル作成の影響を受けるセッションを
決定できます。たとえば、SQL プロファイルのカテゴリを DEV に設定すると、そのプロファ
イルを使用できるのは SQLTUNE_CATEGORY 初期化パラメータが DEV に設定されている
ユーザー・セッションのみとなります。他のすべてのセッションには SQL プロファイルへの
アクセス権がなく、SQL 文の実行計画は SQL プロファイルの影響を受けません。このテク
ニックを使用すると、SQL プロファイルを他のユーザー・セッションで使用可能にする前
に、限定的な環境でテストできます。
関連項目 : SQLTUNE_CATEGORY 初期化パラメータの詳細は、『Oracle
Database リファレンス』を参照してください。
ストアド・アウトラインとは異なり、SQL プロファイルでは SQL 文の実行計画が凍結され
ないことに注意する必要があります。表が拡張されたり索引が作成または削除されるたびに、
同じ SQL プロファイルを使用して実行計画を変更できます。対応する文のデータ配分やアク
セス・パスに変更があっても、SQL プロファイルに格納された情報は引き続き関連付けられ
ています。ただし、長期的には、その内容が陳腐化することがあり、再生成が必要になりま
す。そのためには、同じ文に対して自動 SQL チューニングを再実行し、SQL プロファイル
を再生成します。
SQL プロファイルは、次のタイプの文に適用されます。
■
SELECT 文
■
UPDATE 文
■
INSERT 文（SELECT 句の場合のみ）
■
DELETE 文
13-4　Oracle Database パフォーマンス・チューニング・ガイド
自動 SQL チューニングの概要
■
CREATE TABLE 文（AS SELECT 句の場合のみ）
■
MERGE 文（更新または挿入操作）
SQL プロファイルの管理用に、完全なファンクション・セットが用意されています。13-10
ページの「API による SQL プロファイルの管理」を参照してください。
アクセス・パス分析
索引を使用すると、大規模な表の全表スキャンを実行する必要性が減少し、SQL 文のパ
フォーマンスを大幅に改善できます。効率的な索引付けは、一般的なチューニング・テク
ニックです。自動チューニング・オプティマイザも、新規索引で問合せのパフォーマンスを
大幅に改善できるかどうかを探索します。この種の索引が識別されると、その作成が推奨さ
れます。
自動チューニング・オプティマイザでは、索引に関する推奨事項が SQL 全体のワークロー
ドにどのように影響するかは分析されないため、典型的な SQL ワークロードを持つ SQL 文
に対して SQL Access Advisor ユーティリティを実行することも推奨されます。SQL Access
Advisor は、索引作成が SQL 全体のワークロードに与える影響を調べてから、推奨事項を作
成します。12-6 ページの「SQL Access Advisor」を参照してください。
SQL 構造分析
自動チューニング・オプティマイザでは、パフォーマンスを低下させる可能性のある SQL
文の構造に関して一般的な問題が識別されます。たとえば、文の構文、セマンティクスまた
は設計上の問題があります。このような問題ごとに、自動チューニング・オプティマイザは
SQL 文の再構成について関連する提案を行います。提案される代替策は、元の文と類似して
いますが同じではありません。
たとえば、オプティマイザから、UNION 演算子を UNION ALL で置き換えたり、NOT IN を
NOT EXISTS で置き換えるように提案される場合があります。その場合、アプリケーション
開発者はアドバイスが状況に適用可能かどうかを判断できます。たとえば、スキーマ設計上、
重複の発生が不可能な場合は、UNION 演算子よりも UNION ALL 演算子のほうが効率的です。
このように変更するには、データ・プロパティを十分に理解し、実装前に慎重に考慮する必
要があります。
自動 SQL チューニング 13-5
SQL Tuning Advisor
SQL Tuning Advisor
自動 SQL チューニング機能は、SQL Tuning Advisor というサーバー・ユーティリティを介
して公開されます。SQL Tuning Advisor は、入力として 1 つ以上の SQL 文を取り、自動
チューニング・オプティマイザを起動して文に対する SQL チューニングを実行します。SQL
Tuning Advisor の出力はアドバイスまたは推奨事項の形式で、各推奨事項の理論的根拠と予
測されるメリットが含まれます。推奨事項は、オブジェクト統計の収集、新規索引の作成、
SQL 文の再構成または SQL プロファイルの作成に関するものです。ユーザーは、推奨事項
を受け入れるかどうかを選択して SQL 文のチューニングを完了できます。
SQL Tuning Advisor の入力には、1 つ以上の SQL 文を使用できます。複数の文をチューニン
グする場合は、最初に SQL Tuning Set（STS）を作成する必要があります。STS は、SQL 文
とその実行コンテキストを格納するデータベース・オブジェクトです。STS は、コマンドラ
イン API を使用して手動で作成する方法と、Oracle Enterprise Manager を使用して自動的
に作成する方法があります。13-11 ページの「SQL Tuning Set」を参照してください。
入力ソース
SQL Tuning Advisor の入力は、複数のソースから取り込むことができます。次のような入力
ソースがあります。
■
Automatic Database Diagnostic Monitor
主入力ソースは、Automatic Database Diagnostic Monitor（ADDM）です。デフォルト
で、ADDM は 1 時間ごとにプロアクティブに実行され、過去 1 時間に自動ワークロー
ド・リポジトリ（AWR）により収集された主要統計が分析され、高負荷の SQL 文など、
パフォーマンスの問題が識別されます。高負荷の SQL 文が識別されると、その SQL に
対して SQL Tuning Advisor を実行するように推奨されます。6-3 ページの「Automatic
Database Diagnostic Monitor」を参照してください。
■
高負荷の SQL 文
2 番目に重要な入力ソースは、自動ワークロード・リポジトリ（AWR）に収集される高
負荷の SQL 文です。AWR は、CPU 使用率や待機時間など、関連統計でランク付けされ
た高負荷の SQL 文を含むシステム・アクティビティについて、通常のスナップショッ
トを作成します。AWR を表示して問題となっている高負荷 SQL を識別し、それに対し
て SQL Tuning Advisor を実行できます。デフォルトで、AWR には過去 7 日間のデータ
が保持されます。つまり、この機能を使用して AWR の保存期間内に実行された高負荷
SQL を検索し、チューニングできます。5-10 ページの「自動ワークロード・リポジト
リ」を参照してください。
■
カーソル・キャッシュ
3 番目の入力ソースはカーソル・キャッシュです。このソースは、まだ AWR に収集さ
れていない最新の SQL 文のチューニングに使用されます。カーソル・キャッシュと
AWR には、現在の時刻から AWR の許容保存期間（デフォルトは 7 日以上）の範囲内
でさかのぼって、高負荷の SQL 文を識別してチューニングする機能が用意されていま
す。
13-6　Oracle Database パフォーマンス・チューニング・ガイド
SQL Tuning Advisor
■
SQL Tuning Set
その他に可能な SQL Tuning Advisor の入力ソースは、ユーザー定義の SQL 文セットで
す。この SQL 文セットには、パフォーマンスを個別に測定することや、パフォーマンス
が予測より低下している SQL 文を識別することを目的として、まだ配置されていない
SQL 文を含めることができます。SQL 文セットを入力として使用する場合は、最初に
SQL Tuning Set（STS）を構成して格納する必要があります。13-11 ページの「SQL
Tuning Set」を参照してください。
チューニング・オプション
SQL Tuning Advisor には、チューニング・タスクの有効範囲と期間を管理するためのオプ
ションが用意されています。チューニング・タスクの有効範囲は、制限付きまたは包括的と
して設定できます。
■
■
制限付きオプションを選択すると、SQL Tuning Advisor では、統計チェック、アクセ
ス・パス分析および SQL 構造分析に基づいて推奨事項が生成されます。SQL プロファ
イルの推奨事項は生成されません。
包括的オプションを選択すると、SQL Tuning Advisor では、制限付きの有効範囲で実行
されるすべての分析と SQL プロファイリングが実行されます。このオプションを選択し
た場合は、チューニング・タスクの時間制限も指定できます。デフォルトでは 30 分で
す。
アドバイザ出力
SQL 文を分析した後、SQL Tuning Advisor により、実行計画の最適化に関するアドバイス、
提案された最適化の理論的根拠、見積もられるパフォーマンスの向上およびアドバイスを実
装するコマンドが提供されます。SQL 文を最適化するには、推奨事項を受け入れるかどうか
を選択するだけです。
Oracle Enterprise Manager を使用した SQL Tuning Advisor へのアクセス
SQL Tuning Advisor への主インタフェースは、Oracle Enterprise Manager Database Control
です。Oracle Enterprise Manager Database Control から SQL Tuning Advisor にアクセスす
る手順は、次のとおりです。
■
■
「Database」
」ページの最下部で、
「Related Links」
」の下の「
「Advisor Central」
」リンクを
クリックします。
「Advisor Central」
」ページで「
「SQL Tuning Advisor」
」リンクをクリックし、SQL 文を分
析してチューニングできます。
関連項目 : Oracle Enterprise Manager で使用可能な監視および診断ツー
ルの詳細は、
『Oracle Enterprise Manager 概要』およびオンライン・ヘル
プを参照してください。
自動 SQL チューニング 13-7
SQL Tuning Advisor
SQL Tuning Advisor API の使用方法
SQL Tuning Advisor への主インタフェースは Oracle Enterprise Manager Database Control
ですが、このアドバイザは DBMS_SQLTUNE パッケージのプロシージャを使用して管理でき
ます。この API を使用するには、DBA ロールおよび ADVISOR 権限がユーザーに付与されて
いる必要があります。
DBMS_SQLTUNE パッケージを使用した SQL Tuning Advisor の実行は、次のように 2 段階の
プロセスです。
1.
SQL チューニング・タスクの作成
2.
SQL チューニング・タスクの実行
関連項目 : DBMS_SQLTUNE パッケージの詳細は、『PL/SQL パッケージ・
プロシージャおよびタイプ・リファレンス』を参照してください。
SQL チューニング・タスクの作成
チューニング・タスクは、1 つの SQL 文、複数の文を含む SQL Tuning Set、カーソル・
キャッシュから SQL 識別子で選択した SQL 文または自動ワークロード・リポジトリから
SQL 識別子で選択した SQL 文のテキストから作成できます。
たとえば、SQL Tuning Advisor を使用して指定の SQL 文テキストを最適化するには、
CLOB 引数として渡す SQL 文を指定してチューニング・タスクを作成する必要があります。
次の PL/SQL コードでは、ユーザー HR に ADVISOR 権限が付与されており、ファンクショ
ンは HR スキーマの employees 表に対してユーザー HR として実行されます。
DECLARE
my_task_name VARCHAR2(30);
my_sqltext
CLOB;
BEGIN
my_sqltext := 'SELECT /*+ ORDERED */ * '
'FROM employees e, locations l, departments d '
'WHERE e.department_id = d.department_id AND '
'l.location_id = d.location_id AND '
'e.employee_id < :bnd';
||
||
||
||
my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
sql_text
=> my_sqltext,
bind_list
=> sql_binds(anydata.ConvertNumber(100)),
user_name
=> 'HR',
scope
=> 'COMPREHENSIVE',
time_limit => 60,
task_name
=> 'my_sql_tuning_task',
description => 'Task to tune a query on a specified employee');
END;
/
13-8　Oracle Database パフォーマンス・チューニング・ガイド
SQL Tuning Advisor
この例で、100 は SQL_BINDS 型のファンクション引数として渡された :bnd バインド変数
の値、HR は CREATE_TUNING_TASK ファンクションで SQL 文の分析に使用されるユーザー
です。有効範囲はアドバイザで SQL プロファイル分析も実行されることを意味する
COMPREHENSIVE に設定されており、60 はファンクションを実行できる最大秒数です。この
他に、タスク名および説明の値が提供されています。
CREATE_TUNING_TASK ファンクションでは、指定したタスク名が戻されるか、一意のタス
ク名が生成されます。他の API を使用している場合にこのタスクを指定するには、このタス
ク名を使用できます。特定の所有者に関連付けられているタスク名を表示するには、次の文
を実行します。
SELECT task_name FROM DBA_ADVISOR_LOG WHERE owner = 'HR';
チューニング・タスクの実行
チューニング・タスクを作成した後、タスクを実行し、チューニング・プロセスを開始する
必要があります。たとえば、次のようにします。
BEGIN
DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'my_sql_tuning_task' );
END;
/
DBA_ADVISOR_LOG ビューの情報を検討してタスクの状態をチェックするか、V$SESSION_
LONGOPS ビューでタスク実行の進捗をチェックできます。たとえば、次のようにします。
SELECT status FROM DBA_ADVISOR_LOG WHERE task_name = 'my_sql_tuning_task';
チューニング・タスクの結果の表示
タスクの実行後に、REPORT_TUNING_TASK ファンクションを使用して結果レポートを表示
します。たとえば、次のようにします。
SET LONG 1000
SET LONGCHUNKSIZE 1000
SET LINESIZE 100
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'my_sql_tuning_task')
FROM DUAL;
このレポートには、自動 SQL チューニングのすべての検出結果および推奨事項が含まれま
す。提案される推奨事項ごとに、その実装に必要な SQL コマンド、理論的根拠およびメリッ
トが提供されます。
チューニング・タスクおよび結果の追加情報は、DBA ビューに表示されます。13-15 ページ
の「SQL チューニング情報ビュー」を参照してください。
自動 SQL チューニング 13-9
API による SQL プロファイルの管理
チューニング・タスクに対するその他の操作
次の API を使用して、SQL チューニング・タスクを管理できます。
■
INTERRUPT_TUNING_TASK（実行中にタスクに割り込み、中間結果を取得して通常終
了）
■
CANCEL_TUNING_TASK（実行中にタスクを取り消し、タスクからすべての結果を削除）
■
RESET_TUNING_TASK（実行中にタスクをリセットし、タスクからすべての結果を削除
し、タスクを初期の状態に戻す）
■
DROP_TUNING_TASK（タスクを削除し、タスクに関連付けられたすべての結果を削除）
API による SQL プロファイルの管理
通常、SQL プロファイルは、自動 SQL チューニング・プロセスの一部として Oracle
Enterprise Manager で処理されますが、DBMS_SQLTUNE パッケージを介して管理できます。
SQL プロファイル API を使用するには、CREATE ANY SQL_PROFILE、DROP ANY SQL_
PROFILE および ALTER ANY SQL_PROFILE の各システム権限が必要です。
関連項目 : DBMS_SQLTUNE パッケージの詳細は、『PL/SQL パッケージ・
プロシージャおよびタイプ・リファレンス』を参照してください。
SQL プロファイルの受入れ
DBMS_SQLTUNE.ACCEPT_SQL_PROFILE プロシージャを使用して、SQL Tuning Advisor に
より推奨された SQL プロファイルを受け入れることができます。これにより、SQL プロ
ファイルが作成され、データベースに格納されます。たとえば、次のようにします。
DECLARE
my_sqlprofile_name VARCHAR2(30);
BEGIN
my_sqlprofile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE (
task_name => 'my_sql_tuning_task',
name
=> 'my_sql_profile');
END;
my_sql_tuning_task は、SQL チューニング・タスクの名前です。
SQL プロファイルの情報は、DBA_SQL_PROFILES ビューで表示できます。
13-10　Oracle Database パフォーマンス・チューニング・ガイド
SQL Tuning Set
SQL プロファイルの変更
ALTER_SQL_PROFILE プロシージャにより、既存の SQL プロファイルの STATUS、NAME、
DESCRIPTION および CATEGORY の各属性を変更できます。たとえば、次のようにします。
BEGIN
DBMS_SQLTUNE.ALTER_SQL_PROFILE(
name
=> 'my_sql_profile',
attribute_name => 'STATUS',
value
=> 'DISABLED');
END;
/
この例で my_sql_profile は、変更する SQL プロファイルの名前です。ステータス属性が
DISABLED に変更されているのは、SQL コンパイル時に SQL プロファイルが使用されない
ことを意味します。
SQL プロファイルの削除
DROP_SQL_PROFILE プロシージャにより SQL プロファイルを削除できます。たとえば、次
のようにします。
BEGIN
DBMS_SQLTUNE.DROP_SQL_PROFILE(name => 'my_sql_profile');
END;
/
この例では、my_sql_profile は、削除する SQL プロファイルの名前です。名前が存在し
ない場合に発生したエラーを無視するかどうかも指定できます。この例の場合、デフォルト
値の FALSE が確定されます。
SQL Tuning Set
SQL Tuning Set（STS）は、1 つ以上の SQL 文とその実行統計および実行コンテキストを含
むデータベース・オブジェクトであり、ユーザーによる優先順位ランキングを含む場合もあ
ります。SQL 文は、自動ワークロード・リポジトリ、カーソル・キャッシュまたはユーザー
提供のカスタム SQL など、様々な SQL ソースから SQL Tuning Set にロードできます。STS
に含まれるのは、次のとおりです。
■
■
■
SQL 文のセット
関連する実行コンテキスト（ユーザー・スキーマ、アプリケーション・モジュール名お
よびアクション、バインド値のリストおよびカーソル・コンパイル環境など）
関連する基本実行統計（経過時間、CPU タイム、バッファ取得、ディスク読取り、処理
された行数、カーソル・フェッチ、実行数、実行完了数、オプティマイザ・コストおよ
びコマンドのタイプなど）
自動 SQL チューニング
13-11
SQL Tuning Set
SQL 文は、アプリケーション・モジュール名とアクション、または任意の実行統計を使用し
てフィルタできます。また、実行統計の任意の組合せに基づいて SQL 文をランク付けするこ
ともできます。
SQL Tuning Set を SQL Tuning Advisor への入力として使用すると、ユーザーが指定した他
の入力パラメータに基づいて SQL 文の自動チューニングが実行されます。通常、SQL
Tuning Set は、自動 SQL チューニング・プロセスの一部として Oracle Enterprise Manager
で処理されますが、DBMS_SQLTUNE パッケージのプロシージャを使用して管理できます。
Oracle Enterprise Manager を使用した SQL Tuning Set へのアクセス
Oracle Enterprise Manager Database Control を介して SQL Tuning Set を管理する手順は、
次のとおりです。
■
「Database」
」ページの最下部で、
「Related Links」
」の下の「
「Advisor Central」
」リンクを
クリックします。
■
■
■
「Advisor Central」
」ページで「
「SQL Tuning Advisor」
」リンクをクリックします。
「SQL Tuning Advisor Links」
」ページで「
「SQL Tuning Sets」
」リンクをクリックし
ます。
「Administration」
」ページで、
「Workload」
」の下の「
「SQL Tuning Sets」
」リンクを選択し
ます。
関連項目 : Oracle Enterprise Manager で使用可能な監視および診断ツー
ルの詳細は、
『Oracle Enterprise Manager 概要』およびオンライン・ヘル
プを参照してください。
SQL Tuning Set の管理
SQL Tuning Set API では、SQL Tuning Set を管理し、システム上で実行する SQL 文に関す
るパフォーマンス情報を決定できます。一般に、STS 操作は次の順序で使用します。
■
新規 STS の作成
■
STS のロード
■
STS を選択して内容を確認
■
必要に応じて STS を更新
■
入力に STS を使用してチューニング・タスクを作成
■
完了時に STS を削除
API を使用するには、ADMINISTER ANY SQL TUNING SET システム権限が必要です。
関連項目 : DBMS_SQLTUNE パッケージの詳細は、『PL/SQL パッケージ・
プロシージャおよびタイプ・リファレンス』を参照してください。
13-12　Oracle Database パフォーマンス・チューニング・ガイド
SQL Tuning Set
SQL Tuning Set の作成
CREATE_SQLSET プロシージャは、データベースに空の STS オブジェクトを作成するために
使用されます。たとえば、次のプロシージャでは、特定の期間中に I/O 集中型の SQL 文を
チューニングするために使用できる STS オブジェクトが作成されます。
BEGIN
DBMS_SQLTUNE.CREATE_SQLSET(
sqlset_name => 'my_sql_tuning_set',
description => 'I/O intensive workload');
END;
/
my_sql_tuning_set はデータベース内の STS の名前であり、'I/O intensive
workload' は STS に割り当てられた説明です。
SQL Tuning Set のロード
LOAD_SQLSET プロシージャでは、選択した SQL 文が STS に移入されます。STS に移入する
ための標準ソースは、Workload Repository、他の STS またはカーソル・キャッシュです。
Workload Repository および STS のどちらの場合も、事前定義済のテーブル・ファンクショ
ンを使用して、新規 STS に移入する列をソースから選択できます。
次の例では、プロシージャ・コールを使用して、AWR ベースライン peak baseline から
my_sql_tuning_set がロードされます。10 回以上実行されていて、ベースライン期間中
のバッファ取得に対するディスク読取りの比率が 50% を超えている SQL 文のみが含まれる
ように、データがフィルタされています。上位 30 の SQL 文のみが選択され、バッファ取得
に対するディスク読取りの比率で順序付けされます。最初の REF カーソルがオープンされ、
指定のベースラインから選択します。次に、文とその統計がベースラインから STS にロード
されます。
DECLARE
baseline_cursor DBMS_SQLTUNE.SQLSET_CURSOR;
BEGIN
OPEN baseline_cursor FOR
SELECT VALUE(p)
FROM TABLE (DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY(
'peak baseline',
'executions >= 10 AND disk_reads/buffer_gets >= 0.5',
NULL,
'disk_reads/buffer_gets',
NULL, NULL, NULL,
30)) p;
DBMS_SQLTUNE.LOAD_SQLSET(
sqlset_name
=> 'my_sql_tuning_set',
populate_cursor => baseline_cursor);
END;
/
自動 SQL チューニング
13-13
SQL Tuning Set
SQL Tuning Set の内容の表示
SELECT_SQLSET テーブル・ファンクションでは、STS の内容が読み取られます。STS が作
成および移入された後、SELECT_SQLSET プロシージャを使用して、STS 内の SQL を参照
できます。
次の例では、STS 内でバッファ取得に対するディスク読取りの比率が 75% 以上の SQL 文が
表示されます。
SELECT * FROM TABLE(DBMS_SQLTUNE.SELECT_SQLSET(
'my_sql_tuning_set',
'(disk_reads/buffer_gets) >= 0.75'));
作成されてロードされた SQL Tuning Set のその他の詳細も、DBA_SQLSET、DBA_SQLSET_
STATEMENTS および DBA_SQLSET_BINDS などの DBA ビューを使用して表示できます。
SQL Tuning Set の変更
SQL 文は、検索条件に基づいて SQL Tuning Set から更新および削除できます。次の例では、
実行回数が 49 回以下の SQL 文が DELETE_SQLSET プロシージャにより my_sql_tuning_
set から削除されます。
BEGIN
DBMS_SQLTUNE.DELETE_SQLSET(
sqlset_name => 'my_sql_tuning_set',
basic_filter => 'executions < 50');
END;
/
SQL Tuning Set の削除
DROP_SQLSET プロシージャは、不要になった STS を削除するために使用されます。たとえ
ば、次のようにします。
BEGIN
DBMS_SQLTUNE.DROP_SQLSET( sqlset_name => 'my_sql_tuning_set' );
END;
/
SQL Tuning Set に対するその他の操作
次の API を使用して STS を管理できます。
■
STS の属性を更新
UPDATE_SQLSET プロシージャでは、STS 名および SQL 識別子により識別された既存
の STS の属性値が更新されます。
13-14　Oracle Database パフォーマンス・チューニング・ガイド
SQL チューニング情報ビュー
■
SQL 情報を取得して STS を作成
SELECT_WORKLOAD_REPOSITORY 関数では、スナップショットまたはベースラインか
ら STS が戻されるため、STS の作成が可能になります。
■
STS への参照の追加および削除
ADD_SQLSET_REFERENCE 関数では、既存の STS への新規参照が追加され、クライア
ントが使用中であることが示されます。この関数では、追加された参照の識別子が戻さ
れます。REMOVE_SQLSET_REFERENCE プロシージャは、STS を非アクティブにし、ク
ライアントにより使用されなくなったことを示すために使用されます。
SQL チューニング情報ビュー
この項では、SQL 文のチューニング用に収集された情報を確認するために表示できるビュー
について説明します。これらのビューにアクセスするには、DBA 権限が必要です。
■
■
■
■
■
アドバイザ情報ビュー（DBA_ADVISOR_TASKS、DBA_ADVISOR_FINDINGS、DBA_
ADVISOR_RECOMMENDATIONS および DBA_ADVISOR_RATIONALE ビューなど）。
SQL チューニング情報ビュー（DBA_SQLTUNE_STATISTICS、DBA_SQLTUNE_BINDS
および DBA_SQLTUNE_PLANS ビューなど）。
SQL Tuning Set ビュー（DBA_SQLSET、DBA_SQLSET_BINDS、DBA_SQLSET_
STATEMENTS および DBA_SQLSET_REFERENCES ビューなど）。
SQL プロファイル情報は DBA_SQL_PROFILES ビューに表示されます。
SQL チューニングの関連情報を含む動的ビュー（V$SQL、V$SQLAREA および V$SQL_
BINDS ビューなど）。
関連項目 : 静的データ・ディクショナリ・ビューおよび動的ビューの詳
細は、
『Oracle Database リファレンス』を参照してください。
自動 SQL チューニング
13-15
SQL チューニング情報ビュー
13-16　Oracle Database パフォーマンス・チューニング・ガイド
14
問合せオプティマイザ
この章では、SQL 処理、最適化方式および SQL 文を実行する特定の計画をオプティマイザ
が選択する方法を説明します。
この章には次の項があります。
■
オプティマイザ操作
■
オプティマイザの目標の選択
■
問合せオプティマイザ機能の有効化および制御
■
問合せオプティマイザについて
■
問合せオプティマイザのアクセス・パスについて
■
結合について
問合せオプティマイザ
14-1
オプティマイザ操作
オプティマイザ操作
SQL 文は、全表スキャン、索引スキャン、ネステッド・ループおよびハッシュ結合などにお
いて、様々な方法で実行されます。問合せオプティマイザは、問合せで指定した参照オブ
ジェクトおよび条件に関連した多くの要素を考慮して SQL 文を最も効率よく実行する方法
を判断します。この判断は、SQL 文の処理で重要なステップであり、実行時間が大きく変化
します。
注意 : オプティマイザは、Oracle のあるバージョンとその次のバージョ
ンで同じ決定を行うとは限りません。最新バージョンのオプティマイザ
は、より高度な情報を使用できるので、異なる決定を行います。
オプティマイザからは、最適な実行方法を説明する計画が出力されます。Oracle サーバーに
は、問合せオプティマイザが用意されています。
Oracle によって処理される SQL 文について、オプティマイザは表 14-1 にリストした操作を
実行します。
表 14-1 オプティマイザ操作
操作
説明
式と条件の評価
オプティマイザは、まず、定数が含まれている式と条件を可能なかぎり完全に評価し
ます。
文の変換
たとえば、相関副問合せやビューなどに関連する複合文について、オプティマイザは
元の文を同等の結合文に変換する場合があります。
オプティマイザの目標の選択
オプティマイザでは、最適化の目標が判別されます。14-3 ページの「オプティマイザ
の目標の選択」を参照してください。
アクセス・パスの選択
文がアクセスするそれぞれの表について、オプティマイザは、表データを取得するた
めに 1 つ以上の使用可能なアクセス・パスを選択します。14-18 ページの「問合せオ
プティマイザのアクセス・パスについて」を参照してください。
結合順序の選択
2 つ以上の表を結合する結合文について、オプティマイザは、最初に結合する表のペ
アを選択し、その後、その結果に結合する表を順次選択していきます。14-30 ページ
の「問合せオプティマイザによる結合の実行計画の選択方法」を参照してください。
オプティマイザの目標の設定および問合せオプティマイザの代表的な統計の収集によって、
オプティマイザの選択を変えることができます。オプティマイザの目標はスループットまた
は応答時間です。14-3 ページの「オプティマイザの目標の選択」および 14-6 ページの「デー
タ・ディクショナリ内の問合せオプティマイザ統計」を参照してください。
特定のアプリケーション・データに関して、オプティマイザよりも多くの情報を持つアプリ
ケーション設計者であれば、より効率よく SQL 文を実行する方法を選択できる場合があり
14-2　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザの目標の選択
ます。アプリケーション設計者は、SQL 文のヒントを使用して文を実行する方法を指定でき
ます。
関連項目 :
■
■
■
■
■
SQL 処理およびオプティマイザの概要は、
『Oracle Database 概要』を
参照してください。
拡張可能オプティマイザの詳細は、
『Oracle Data Cartridge 開発者ガ
イド』を参照してください。
最適化の目標の詳細は、14-3 ページの「オプティマイザの目標の選
択」を参照してください。
統計を収集および使用する方法の詳細は、第 15 章「オプティマイザ統
計の管理」を参照してください。
SQL 文のヒントを使用する方法の詳細は、第 17 章「オプティマイザ・
ヒント」を参照してください。
オプティマイザの目標の選択
デフォルトでは、問合せオプティマイザの目標は最高のスループットです。つまり、CBO
は文からアクセスされたすべての行を処理するのに必要な最小リソースを選択します。また
最短応答時間を目標とした文の最適化も可能です。つまり、CBO は SQL 文からアクセスさ
れた最初の行を処理するのに必要な最小リソースを使用します。
アプリケーションのニーズに基づいて、オプティマイザの目標を選択してください。
■
■
Oracle Reports アプリケーションのように、バッチで実行されるアプリケーションの場
合は、最高のスループットを目標に最適化してください。アプリケーションを起動する
ユーザーの関心は、アプリケーションを完了するために必要な時間のみに向けられてい
るため、通常、バッチ・アプリケーションではスループットの重要度が高くなります。
アプリケーションの実行中にユーザーが個々の文の結果を調べることはないため、応答
時間はそれほど重要ではありません。
Oracle Forms アプリケーションや SQL*Plus の問合せのような対話形式のアプリケー
ションの場合は、最短の応答時間を目標に最適化してください。対話形式では、ユー
ザーは、文がアクセスする最初の行を参照するために待機しています。このため、対話
形式のアプリケーションでは応答時間が重要となります。
SQL 文に対する最適化のアプローチと目標を選択する場合のオプティマイザの動作は、次の
要因の影響を受けます。
■
OPTIMIZER_MODE 初期化パラメータ
■
問合せオプティマイザの目標変更に対するオプティマイザ SQL のヒント
■
データ・ディクショナリ内の問合せオプティマイザ統計
問合せオプティマイザ
14-3
オプティマイザの目標の選択
OPTIMIZER_MODE 初期化パラメータ
OPTIMIZER_MODE 初期化パラメータで、インスタンスに最適化アプローチを選択するため
のデフォルト動作を設定します。指定可能な値およびその説明を表 14-2 に示します。
表 14-2 OPTIMIZER_MODE パラメータ値
値
説明
ALL_ROWS
オプティマイザは、セッション内の SQL 文に対して、統計の存在の有無にかかわりなくコスト
ベースのアプローチを使用し、最高のスループット（最小のリソースを使用して文全体を完成さ
せること）を目標として最適化します。これはデフォルト値です。
FIRST_ROWS_n
オプティマイザは統計の有無とは関係なく、コストベースのアプローチを使用し、最短応答時間
で最初の n 行を戻すように最適化します。n は 1、10、100 または 1000 です。
FIRST_ROWS
オプティマイザは、コストと経験則を組み合せて、最初の数行の高速配信のための最適な計画を
見つけます。
注意 : 問合せオプティマイザは、経験則を使用すると、経験則を適用しない場合に比べてコストが
はるかに大きい計画を生成する場合があります。FIRST_ROWS は、下位互換性とプラン・スタビ
リティのためのものです。かわりに FIRST_ROWS_n を使用してください。
CHOOSE
このパラメータ値はサポートされなくなりました。
RULE
このパラメータ値はサポートされなくなりました。
初期化ファイル内のパラメータ値の変更、または ALTER SESSION SET OPTIMIZER_MODE
文によって、セッション内のすべての SQL 文の問合せオプティマイザの目標を変更できま
す。たとえば、次のようにします。
■
初期化パラメータ・ファイル内の次の文は、インスタンスのすべてのセッションの問合
せオプティマイザの目標を最短の応答時間に変更します。
OPTIMIZER_MODE = FIRST_ROWS_1
■
次の SQL 文は、現行セッションの問合せオプティマイザの目標を最短の応答時間に変更
します。
ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1;
オプティマイザがコストベースのアプローチを SQL 文に使用するときに、文がアクセスす
る一部の表に統計が存在しない場合、オプティマイザはそれらの表に割り当てられている
データ・ブロック数などの内部情報を使用して表に対する別の統計を見積ります。
14-4　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザの目標の選択
問合せオプティマイザの目標変更に対するオプティマイザ SQL のヒント
各 SQL 文に対する問合せオプティマイザの目標を指定する場合は、表 14-3 のヒントのいず
れかを使用します。各 SQL 文にあるこれらのヒントは、いずれも、その SQL 文の
OPTIMIZER_MODE 初期化パラメータを上書きできます。
表 14-3 問合せオプティマイザの目標変更に対するヒント
ヒント
説明
FIRST_ROWS(n)
このヒントは、個々の SQL 文を最適化して最初の n 行を最短応答
時間で戻すように、Oracle に指示します。ここでは、n は正の整
数です。このヒントでは、SQL 文に対して、統計の存在の有無に
かかわりなくコストベースのアプローチが使用されます。
ALL_ROWS
このヒントでは、最高のスループットを目標として SQL 文を最適
化するために、コストベースのアプローチが明示的に選択されま
す。
CPU_COSTING
このヒントは、SQL 文に関する CPU コスト計算をオンにします。
これはオプティマイザのデフォルトのコスト計算モデルです。オ
プティマイザでは、I/O 操作の数とタイプ、および指定された問
合せの実行時にデータベースが実行する CPU サイクルの数を見積
り、システム統計を使用して CPU サイクル数および I/O 数を見
積り済の問合せ実行時間に変換します。
NO_CPU_COSTING
このヒントは、SQL 文に関する CPU コスト計算をオフにします。
オプティマイザでは、単一ブロック読込みのすべてを測定し、
CPU コストを無視する I/O コスト計算モデルが使用されます。
CHOOSE
このヒントはサポートされなくなりました。
RULE
このヒントはサポートされなくなりました。
関連項目 : ヒントを使用する方法の詳細は、第 17 章「オプティマイザ・
ヒント」を参照してください。
問合せオプティマイザ
14-5
問合せオプティマイザ機能の有効化および制御
データ・ディクショナリ内の問合せオプティマイザ統計
問合せオプティマイザで使用される統計は、データ・ディクショナリに格納されます。
DBMS_STATS パッケージを使用して、これらのスキーマ・オブジェクト内の物理的な記憶域
の特性とデータ配分に関する正確な統計または見積り統計を収集できます。
問合せオプティマイザの有効性を維持するには、データを代表する統計が必要です。偏った
データという、値の重複数のバリエーションが多いデータが存在する表列については、ヒス
トグラムを収集する必要があります。
その結果の統計によって、データの一意性と配分についての情報が問合せオプティマイザに
提供されます。この情報を使用することにより、問合せオプティマイザは計画コストを精密
に計算します。その結果、問合せオプティマイザは最小のコストを基に最良の実行計画を選
択できるようになります。
問合せオプティマイザを使用するときに統計が使用不可である場合、OPTMIZER_DYNAMIC_
SAMPLING 初期化パラメータの設定によって、オプティマイザで動的サンプリングが実行さ
れます。この場合、最高のパフォーマンスを得るために解析時間が遅くなる可能性があるた
め、オプティマイザに代表的なオプティマイザ統計が必要となります。
関連項目 :
■
第 15 章「オプティマイザ統計の管理」
■
15-15 ページ「動的サンプリングを使用した統計の見積り」
問合せオプティマイザ機能の有効化および制御
この項には、オプティマイザに固有の初期化パラメータが含まれています。次の項は、
Oracle のアプリケーションをチューニングするときに特に役に立ちます。
関連項目 : 初期化パラメータの詳細は、
『Oracle Database リファレンス』
を参照してください。
問合せオプティマイザ機能の有効化
OPTIMIZER_FEATURES_ENABLE 初期化パラメータを設定して、オプティマイザの機能を有
効化できます。
OPTIMIZER_FEATURES_ENABLE パラメータ
OPTIMIZER_FEATURES_ENABLE パラメータは、問合せオプティマイザのアンブレラ・パラ
メータの役割を果たします。リリースにより異なりますが、このパラメータを使用して一連
のオプティマイザ関連機能を有効にできます。このパラメータは、8.0.4、8.1.7 および 9.2.0
などのリリース番号に対応する有効な文字列値のリストのうちの 1 つを受け入れます。たと
えば、次の設定は、Oracle10g リリース 1（10.1）の問合せ計画の生成時のオプティマイザ機
能を使用可能にします。
14-6　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザ機能の有効化および制御
OPTIMIZER_FEATURES_ENABLE=10.0.0;
OPTIMIZER_FEATURES_ENABLE パラメータは、Oracle サーバーをアップグレード可能に
すること、さらにアップグレード後も問合せオプティマイザの以前の動作を保持できること
を主な目標として導入されました。たとえば、リリース 8.1.5 からリリース 8.1.6 に Oracle
サーバーをアップグレードすると、OPTIMIZER_FEATURES_ENABLE パラメータのデフォル
トの値は 8.1.5 から 8.1.6 に変わります。このアップグレードのために、問合せオプティマイ
ザでは、8.1.5 ではなく 8.1.6 に基づいた最適化機能が有効にされます。
プラン・スタビリティまたは下位互換性の理由から、問合せ計画が新規リリースのオプティ
マイザ機能によって変更されないようにする場合もあります。そのような場合は、
OPTIMIZER_FEATURES_ENABLE パラメータを以前のバージョンに設定します。たとえば、
問合せオプティマイザの動作をリリース 8.1.5 に保持するには、次のようにパラメータを設
定します。
OPTIMIZER_FEATURES_ENABLE=8.1.5;
この文により、8.1.5 より後のリリースで追加されたすべての新規オプティマイザ機能が無効
になります。
注意 : リリースをアップグレードし、使用可能な新機能を有効にする場
合は、OPTIMIZER_FEATURES_ENABLE 初期化パラメータを明示的に設定
する必要はありません。
以前のリリースに OPTIMIZER_FEATURES_ENABLE パラメータを明示的に設定することは
お薦めしません。実行計画または問合せパフォーマンスの問題点は、必要に応じて解決する
ことをお薦めします。
関連項目 : OPTIMIZER_FEATURES_ENABLE パラメータに設定する各リ
リースの値と、それにより有効になるオプティマイザ機能の詳細は、
『Oracle Database リファレンス』を参照してください。
問合せオプティマイザ
14-7
問合せオプティマイザ機能の有効化および制御
問合せオプティマイザの動作の制御
この項には、問合せオプティマイザの動作の管理に使用できる初期化パラメータの一部がリ
ストされています。SQL 実行のパフォーマンスを向上するために、これらのパラメータを使
用して様々なオプティマイザ機能を有効にすることができます。
CURSOR_SHARING
このパラメータは、SQL 文のリテラル値をバインド変数に変換します。値を変換するとカー
ソル共有が改善され、SQL 文の実行計画は影響を受けます。オプティマイザは、実際のリテ
ラル値でなくバインド変数の有無に基づいて実行計画を生成します。
DB_FILE_MULTIBLOCK_READ_COUNT
このパラメータは、全表スキャンまたは高速全索引スキャン時に単一 I/O で読み取られるブ
ロックの個数を指定します。オプティマイザは、DB_FILE_MULTIBLOCK_READ_COUNT の
値を使用して、全表スキャンと高速全索引スキャンのコストを計算します。値が大きいほど
全表スキャンのコストは低くなり、オプティマイザは索引スキャンより全表スキャンを選択
します。
OPTIMIZER_INDEX_CACHING
このパラメータは、ネステッド・ループとともに索引プローブのコスト計算の管理に使用し
ます。OPTIMIZER_INDEX_CACHING の 0 から 100 の範囲は、ネステッド・ループおよび
IN リスト・イテレータの索引キャッシュに関するオプティマイザの仮定を変更するバッ
ファ・キャッシュ内の索引ブロックのキャッシュ率を管理します。この値が 100 となってい
る場合、索引ブロックの 100% がバッファ・キャッシュに見つかる可能性が推測されます。
オプティマイザはそれに応じて索引プローブあるいはネステッド・ループのコストを調整し
ます。実行計画は索引のキャッシュに応じて変更される可能性があります。このパラメータ
を使用するときは注意してください。
OPTIMIZER_INDEX_COST_ADJ
このパラメータを使用して、索引プローブのコストを調整できます。値の範囲は 1 から
10000 です。デフォルト値は 100 ですが、これは索引が標準のコスト計算モデルに基づい
てアクセス・パスとして評価されることを意味します。値 10 は、索引アクセス・パスのコ
ストが標準コストの 1/10 であることを意味します。
OPTIMIZER_MODE
この初期化パラメータは、インスタンスの起動時のオプティマイザのモードを設定します。
可能値は、RULE、CHOOSE、ALL_ROWS、FIRST_ROWS_n および FIRST_ROWS です。これ
らのパラメータ値の詳細は、14-4 ページの「OPTIMIZER_MODE 初期化パラメータ」を参
照してください。
14-8　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
PGA_AGGREGATE_TARGET
このパラメータは、ソートおよびハッシュ結合に割り当てられるメモリーの量を自動的に制
御します。ソートまたはハッシュ結合に大量のメモリーが割り当てられると、これらの操作
のオプティマイザ・コストが減少します。7-49 ページの「PGA メモリー管理」を参照して
ください。
STAR_TRANSFORMATION_ENABLED
このパラメータを true に設定すると、問合せオプティマイザはスター・クエリーのための
スター型変換のコストを計算できます。スター型変換により、様々なファクト表の列でビッ
トマップ索引が結合されます。
関連項目 : 各パラメータの詳細は、
『Oracle Database リファレンス』を
参照してください。
問合せオプティマイザについて
問合せオプティマイザは、SQL 文がアクセスするスキーマ・オブジェクト（表または索引）
について、使用可能なアクセス・パスを検討し、統計に基づいた情報要素を考慮することに
よって最も効果的な実行計画を判断します。また、問合せオプティマイザは文のコメントに
配置された、最適化の提案であるヒントも考慮します。
関連項目 : ヒントの詳細は、第 17 章「オプティマイザ・ヒント」を参照
してください。
問合せオプティマイザは次のステップを実行します。
1.
使用可能なアクセス・パスおよびヒントに基づき、SQL 文の可能な計画のセットを生成
します。
2.
文がアクセスする表、索引およびパーティションのデータ配分および記憶特性に関する
データ・ディクショナリ内の統計に基づき、計画のそれぞれのコストを見積ります。
コストとして見積られる値は、特定の計画での文の実行に必要と予測されるリソース使
コスト
用量に比例しています。オプティマイザは、I/O、CPU、メモリーなどのコンピュー
タ・リソースの見積りに基づいて、アクセス・パスや結合順序のコストを計算します。
コストの大きいシリアル計画の実行には、コストの小さい計画の実行よりも多くの時間
が必要です。ただし、パラレル計画を使用する場合は、リソース使用量は経過時間に直
接関係しません。
3.
計画のコストを比較して、コストが最も小さいものを選択します。
問合せオプティマイザ
14-9
問合せオプティマイザについて
問合せオプティマイザの構成要素
問合せオプティマイザ操作には、次のものがあります。
■
問合せの変換
■
見積り
■
計画の生成
問合せオプティマイザの構成要素を図 14-1 に示します。
図 14-1 問合せオプティマイザの構成要素
14-10　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
問合せの変換
問合せトランスフォーマへの入力は、一連の問合せブロックによって表される解析済問合せ
です。問合せブロックは、互いにネストされているかまたは相互関係を持っています。問合
せの形式によって、問合せブロックの相互関係が判断されます。問合せトランスフォーマの
主な目的は、問合せの形式を変える必要があるかどうかを判断して、より適切な問合せ計画
を生成できるようにすることです。問合せトランスフォーマでは、次のように様々な問合せ
変換手法を採用しています。
■
ビューのマージ
■
述語のプッシュ
■
副問合せのネスト解除
■
マテリアライズド・ビューを使用したクエリー・リライト
これらの変換は任意に組み合せて指定の問合せに適用できます。
ビューのマージ 問合せで参照されるビューは、パーサーによって個別の問合せブロックに
拡張されます。問合せブロックは、基本的にはビュー定義を表しますが、このため必然的に
ビューの結果も表すことになります。オプティマイザには、ビューの問合せブロックの 1 つ
を分離して分析し、ビュー・サブプランを生成するというオプションがあります。オプティ
マイザは、問合せ計画全体の生成にビュー・サブプランを使用することで、残りの問合せを
処理します。この手法は、そのビューが問合せの残りの部分とは別に最適化されるため、通
常は最適な問合せ計画とはなりません。
問合せトランスフォーマは、ビューが含まれている問合せブロックにビューの問合せブロッ
クをマージして、潜在的に最適とは言えない計画を除去します。ほとんどのタイプのビュー
がマージされます。ビューをマージするときには、ビューを表す問合せブロックが包含的な
問合せブロックにマージされます。ビューの問合せブロックは除去されているので、サブプ
ランを生成する必要はありません。
述語のプッシュ マージされていないビューについては、問合せトランスフォーマにより、
関連する述語を、ビューを包含する問合せブロックからビューの問合せブロックに組み込む
ことができます。この手法は、プッシュされた述語を索引へのアクセスやフィルタに使用で
きるので、マージされていないビューのサブプランが改善されます。
副問合せのネスト解除 通常、副問合せを含む問合せのパフォーマンスは、副問合せのネス
トを解除して結合に変換することにで改善できます。大半の副問合せは、問合せトランス
フォーマでネスト解除されます。ネスト解除されない副問合せの場合は、個別のサブプラン
が生成されます。問合せ計画全体の実行速度を上げるため、サブプランは効果的な順序で並
べられます。
マテリアライズド・ビューを使用したクエリー・リライト マテリアライズド・ビューは、
結果がマテリアライズされて表に格納された問合せと類似しています。マテリアライズド・
ビューに関連付けられた問合せと互換性のあるユーザー問合せが検出されると、ユーザー問
合せはマテリアライズド・ビューにリライトできます。この手法は、ほとんどの問合せ結果
問合せオプティマイザ
14-11
問合せオプティマイザについて
があらかじめ計算されているため、ユーザー問合せの実行状態を改善します。問合せトラン
スフォーマは、ユーザー問合せと互換性のあるマテリアライズド・ビューを検索し、1 つ以
上のマテリアライズド・ビューを選択してユーザー問合せをリライトします。問合せをリラ
イトするためのマテリアライズド・ビューの使用はコストベースです。したがって、マテリ
アライズド・ビューを使用せずに生成された計画のコストが、マテリアライズド・ビューを
使用して生成された計画のコストより低い場合、問合せはリライトされません。
ユーザー定義のバインド変数の照合
問合せオプティマイザは、カーソルの最初の起動時にユーザー定義バインド変数の値を照合
します。この機能により、WHERE 句の条件の選択性と、バインド変数のかわりにリテラルが
使用されたかどうかが判断されます。カーソルのその後の起動時は照合が行われず、また、
その後の起動で異なるバインド値を使用しても、カーソルは標準カーソル共有基準に基づい
て共有されます。
バインド変数が文に使用されている場合、カーソルを共有するために異なる起動が同じ実行
計画を使用するものとみなします。カーソルの異なる起動で様々な実行計画が使用される場
合、バインド変数が SQL 文で適切に使用されていない可能性があります。バインド照合は、
すべてのクライアントではなく特定のクライアント・セットに対して機能します。
関連項目 : クエリー・リライトの詳細は、『Oracle データ・ウェアハウ
ス・ガイド』を参照してください。
見積り
エスティメータは、異なるタイプのメジャーを 3 通り生成します。
■
選択性
■
カーディナリティ
■
コスト
これらのメジャーは相互に関連性があり、あるメジャーは別のメジャーから派生します。エ
スティメータの最終目標は、指定された計画のコスト全体を算出することです。統計が使用
可能な場合、エスティメータは統計を使用してメジャーを計算します。統計によって、メ
ジャーの正確さの度合いは改良されます。
選択性 最初のメジャーは行セットの一部の行を表す選択性です。行セットとは、実表、
ビュー、結合結果または GROUP BY 演算子の結果です。選択性は、last_name = 'Smith' な
どの問合せ述語、または last_name = 'Smith' AND job_type = 'Clerk' などの述語の組合
せに拘束されています。述語はフィルタとして機能します。このフィルタは、行セットから
特定数の行を選別します。したがって、述語の選択性が述語テストに合格する行セットの行
数を示しています。選択性の値範囲は、0.0 から 1.0 です。選択性が 0.0 の場合、行セットか
ら行は選択されず、選択性が 1.0 の場合はすべての行が選択されます。
使用可能な統計が存在しない場合、オプティマイザは、OPTIMIZER_DYNAMIC_SAMPLING
初期化パラメータの値に応じて動的サンプリングまたは内部デフォルト値を使用します。使
14-12　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
用される内部デフォルトは、述語のタイプによって異なります。たとえば、等価述語
（last_name = 'Smith'）の内部デフォルトは範囲述語（last_name > 'Smith'）の内部デ
フォルトより低くなっています。エスティメータがこの仮定を行うのは、等価述語が範囲述
語より少ない行数の行を戻すことが予測されるためです。15-15 ページの「動的サンプリン
グを使用した統計の見積り」を参照してください。
統計が使用可能な場合、エスティメータは統計を使用して選択性を推測します。たとえば、
等価述語（last_name = 'Smith'）の選択性は、last_name の個別値である数値 n の逆数
に設定されます。これは、問合せが n の内から 1 つの個別値をすべて含む行を選択するため
です。last_name 列でヒストグラムが使用可能な場合、エスティメータは個別値のかわり
にヒストグラムを使用します。ヒストグラムには列内の異なる値の分散が示されているの
で、より適切な選択性の見積りが行われます。偏ったデータ（値の重複数のバリエーション
が多いデータ）が含まれている列のヒストグラムが存在すると、問合せオプティマイザが適
切な選択性の見積りを生成するのに役立ちます。
カーディナリティ カーディナリティは、行セット内の行数を表します。ここでの行セット
とは、実表、ビュー、結合結果または GROUP BY 演算子の結果です。
コスト コストは、作業単位または使用されるリソースを表します。問合せオプティマイザは
ディスク I/O、CPU 使用量、メモリー使用量を作業単位として使用します。しかし、問合せ
オプティマイザによって使用されるコストは、操作の実行で使用した CPU とメモリーの量
の見積り数になります。すなわち、操作には表をスキャンすること、索引を使用して表から
行にアクセスすること、2 つの表を結合すること、または行セットをソートすることなどが
あります。問合せ計画のコストは、問合せが実行されてその結果が生成されるときに発生す
ると予測される作業単位の数です。
アクセス・パス
アクセス パスは、実表からデータを得るときに実行される作業単位数です。アクセス・パ
パス
スには、表スキャン、高速全索引スキャンまたは索引スキャンがなどがあります。表スキャ
ンまたは高速全索引スキャンの実行中には、単独の I/O 操作で複数のブロックがディスクか
ら読み込まれます。したがって、表スキャンまたは高速全索引スキャンのコストは、スキャ
ンされるブロック数およびマルチブロック READ カウントに左右されます。索引スキャンの
コストは、B ツリーにおけるレベル、つまりスキャンされる索引リーフ・ブロック数、索引
キーの ROWID を使用してフェッチされる行数に左右されます。ROWID を使用して行を
フェッチするコストは、索引クラスタ化係数に依存します。14-21 ページの「ブロックの
I/O（行ではなく）の想定」を参照してください。
結合コストは、結合されている
2 つの行セットの個別のアクセス・コストの組合せと、結合
結合コスト
操作のコストを表します。
関連項目 :
ださい。
結合の詳細は、14-29 ページの「結合について」を参照してく
問合せオプティマイザ
14-13
問合せオプティマイザについて
計画の生成
プラン・ジェネレータの主な機能は、指定の問合せに対して使用できる可能性のある別の計
画を割り出し、コストの最も低いものを取り出すことです。異なる方法でデータをアクセス
および処理し、かつ結果が同じになる、様々なアクセス・パス、結合方法および結合順序の
組合せが存在するので、多数の異なる計画が使用できます。
結合順序は、異なる結合項目（表など）がアクセスされて結合される順序です。たとえば、
table1、table2 および table3 の結合順序では、表 table1 が最初にアクセスされます。
次に、table2 がアクセスされ、そのデータが table1 のデータに結合されて table1 と
table2 の結合が生成されます。最後に table3 がアクセスされ、そのデータが table1 と
table2 の結合結果に結合されます。
問合せのための計画は、まず最初にネストされた副問合せおよびマージされていないビュー
のそれぞれにサブプランを生成することによって構築されます。ネストされた副問合せ、ま
たはマージされていないビューは、それぞれ、個別の問合せブロックによって表されます。
問合せブロックは、それぞれ、下位から上位へ順番に最適化されます。つまり、最も内側の
問合せブロックが最初に最適化され、サブプランが生成されます。そして、問合せ全体を表
す一番外側の問合せブロックは、最後に最適化されます。
プラン・ジェネレータは、別のアクセス・パス、結合方法および結合順序を試行することに
よって、問合せブロックに対する様々な計画を探索します。問合せブロックに使用できる可
能性のある計画の数は、FROM 句にある結合項目の数に比例します。この数は、結合項目の
数によって指数関数的に上昇します。
プラン・ジェネレータは内部カットオフを使用して計画数を削減し、最もコストの低い計画
を検索しようとします。カットオフの基準は、現行の最適な計画のコストです。現行の最適
コストが大きい場合、プラン・ジェネレータはコストがより低く、より適切な計画（つま
り、さらに別の計画）を探索します。現行の最適コストが低い場合は、これ以上のコストの
改善を追及しても大きな効果は得られないため、プラン・ジェネレータは検索を速やかに終
了します。
最適な状態に最も近いコストで計画を生成する初期結合順序で、プラン・ジェネレータが始
動する場合は、カットオフが有効に機能します。適切な初期結合順序の検索は困難です。
14-14　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
実行計画の読み方と理解
SQL 文を実行するために、Oracle は、多数のステップを実行する必要があります。実行され
る各ステップでは、データベースからのデータ行の物理的な取出し、またはユーザーが発行
する文に返すデータ行の準備のどちらかが実行されます。文を実行するために Oracle が使
用するステップの組合せのことを実行計画
実行計画と呼びます。実行計画には、文がアクセスする各
実行計画
表へのアクセス・パス
アクセス・パスと、適切な結合方法
結合方法に基づく表の順序（結合順序
結合順序）が含まれていま
アクセス・パス
結合方法
結合順序
す。
関連項目 :
■
14-18 ページ「問合せオプティマイザのアクセス・パスについて」
■
第 19 章「EXPLAIN PLAN の使用方法」
EXPLAIN PLAN の概要
EXPLAIN PLAN 文を使用することにより、オプティマイザが SQL 文に対して選択した実行
計画を確認できます。文が発行されると、オプティマイザが実行計画を選択した後で、計画
を説明するデータがデータベース表に挿入されます。単純に、EXPLAIN PLAN 文を発行し、
出力表を問い合せます。
EXPLAIN PLAN 文の使用方法の基本は次のとおりです。
■
■
■
■
SQL スクリプト UTLXPLAN.SQL を使用し、使用しているスキーマ内に PLAN_TABLE と
いうサンプル出力表を作成してください。19-5 ページの「PLAN_TABLE 出力表」を参
照してください。
SQL 文の前に EXPLAIN PLAN FOR 句を挿入します。19-6 ページの「EXPLAIN PLAN
の実行」を参照してください。
EXPLAIN PLAN 文を発行した後、Oracle から提供されるスクリプトまたはパッケージ
のいずれかを使用して最新の計画表出力を表示します。19-7 ページの「PLAN_TABLE
出力の表示」を参照してください。
EXPLAIN PLAN の出力実行順序は、最も右端にインデントされている行から始まりま
す。次のステップは、その行の親です。2 つの行が等しくインデントされている場合、
通常、最上位の行が最初に実行されます。
注意 :
■
■
この章では、EXPLAIN PLAN 出力表は utlxpls.sql スクリプトで表
示されました。
この章の EXPLAIN PLAN 出力のステップは、システムによって異なる
場合があります。データベース構成によって、オプティマイザは異な
る実行計画を選択する場合があります。
問合せオプティマイザ
14-15
問合せオプティマイザについて
例 14-1 では EXPLAIN PLAN を使用して、ID が 103 より小さい従業員の、employee_id、
job_title、salary および department_name を選択する SQL 文について説明していま
す。
例 14-1 EXPLAIN PLAN の使用方法
EXPLAIN PLAN FOR
SELECT e.employee_id, j.job_title, e.salary, d.department_name
FROM employees e, jobs j, departments d
WHERE e.employee_id < 103
AND e.job_id = j.job_id
AND e.department_id = d.department_id;
例 14-2 の結果の出力表では、例にある SQL 文を実行するためにオプティマイザで選択され
た実行計画が示されています。
例 14-2 EXPLAIN PLAN 出力
----------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
3 |
189 |
10 (10)|
|
1 | NESTED LOOPS
|
|
3 |
189 |
10 (10)|
|
2 |
NESTED LOOPS
|
|
3 |
141 |
7 (15)|
|* 3 |
TABLE ACCESS FULL
| EMPLOYEES
|
3 |
60 |
4 (25)|
|
4 |
TABLE ACCESS BY INDEX ROWID| JOBS
|
19 |
513 |
2 (50)|
|* 5 |
INDEX UNIQUE SCAN
| JOB_ID_PK
|
1 |
|
|
|
6 |
TABLE ACCESS BY INDEX ROWID | DEPARTMENTS |
27 |
432 |
2 (50)|
|* 7 |
INDEX UNIQUE SCAN
| DEPT_ID_PK
|
1 |
|
|
----------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------3 - filter("E"."EMPLOYEE_ID"<103)
5 - access("E"."JOB_ID"="J"."JOB_ID")
7 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
14-16　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
実行計画のステップ
出力表内の各行は、実行計画内の 1 つのステップに対応しています。アスタリスクの付いた
ステップ ID は、Predicate Information セクションにリストされています。
関連項目 :
第 19 章「EXPLAIN PLAN の使用方法」
実行計画の各ステップで、行のセットが戻されます。この行のセットは、次のステップで使
用されます。最後のステップでは、SQL 文を発行しているユーザーまたはアプリケーション
に対し、行のセットが戻されます。各ステップで戻される行のセットを、行セットと呼びま
す。
ステップ ID の番号は、EXPLAIN PLAN 文で返された実行計画の順序 ID に対応しています。
実行計画の各ステップでは、データベースから行を取り出すか、1 つ以上の行ソースから行
を入力として受け入れます。
■
例 14-2 の次のステップでは、データベース内のオブジェクトからデータが物理的に取り
出されます。
■
■
■
■
■
■
ステップ 3 では employees 表にあるすべての行を読み込みます。
ステップ 5 では、JOB_ID_PK 索引の各 job_id を参照して、jobs 表内の対応する
行の ROWID を検索します。
ステップ 4 では、jobs 表からステップ 5 で戻された ROWID を持つ行を取得しま
す。
ステップ 7 では、DEPT_ID_PK 索引の各 department_id を参照して、
departments 表内の対応する行の ROWID を検索します。
ステップ 6 では、
departments 表からステップ 7 で戻された ROWID を持つ行を取
得します。
例 14-2 の次のステップでは、直前の行ソースから戻された行を処理します。
■
■
ステップ 2 では、ステップ 3 およびステップ 4 から戻される行ソースを受け入れ、ス
テップ 3 からの各行をステップ 4 の対応する行に結合し、その結果の行をステップ
2 に戻す、ネステッド・ループ操作を、jobs 表および employees 表の job_id
で実行します。
ステップ 1 では、ステップ 2 およびステップ 6 から戻される行ソースを受け入れ、ス
テップ 2 からの各行をステップ 6 の対応する行に結合し、その結果の行をステップ
1 に戻すネステッド・ループ操作を実行します。
関連項目 :
■
■
アクセス・パスの詳細は、14-18 ページの「問合せオプティマイザの
アクセス・パスについて」を参照してください。
Oracle が行ソースを結合する方法の詳細は、14-29 ページの「結合に
ついて」を参照してください。
問合せオプティマイザ
14-17
問合せオプティマイザのアクセス・パスについて
問合せオプティマイザのアクセス・パスについて
アクセス・パスは、データベースからデータを取り出す経路です。一般に、表の行の小さい
サブセットを取得する文には索引アクセス・パスを指定する必要がありますが、表の大きい
部分にアクセスするときは全体スキャンのほうが効率がよくなります。オンライン・トラン
ザクション処理（OLTP）アプリケーションは、選択性が高く実行の短い SQL 文から構成さ
れており、多くの場合は索引アクセス・パスを使用するという特徴があります。それに対し
て、意思決定支援システムはパーティション表を使用し、関連するパーティションの全体ス
キャンを実行する傾向があります。
この項では、表内の任意の行の検索および取出しに使用できるデータ・アクセス・パスにつ
いて説明します。
■
全表スキャン
■
ROWID スキャン
■
索引スキャン
■
クラスタ・アクセス
■
ハッシュ・アクセス
■
サンプル表スキャン
■
問合せオプティマイザによるアクセス・パスの選択方法
全表スキャン
このタイプのスキャンでは、表にあるすべての行の読取り、選択基準を満たしていない行の
フィルタが実行されます。全表スキャンで、最高水位標以下の、表中のすべてのブロックが
スキャンされます。最高水位標は、使用済領域の量、またはデータを受け取るようにフォー
マットされている領域を示します。各行が文の WHERE 句を満たすかどうかを判断するため
に、各行が検査されます。
全表スキャンを行うと、ブロックが順に読み取られます。ブロックは隣接しているため、単
一ブロックより大きい I/O コールを使用してプロセスを高速化できます。リード・コールの
サイズの範囲は、1 ブロックから初期化パラメータ DB_FILE_MULTIBLOCK_READ_COUNT
で示されるブロック数までです。マルチブロック READ を使用すると、全表スキャンを効率
よく実行できます。各ブロックは 1 回のみ読み取られます。
14-16 ページの例 14-2「EXPLAIN PLAN 出力」には、employees 表の全表スキャン例が含
まれています。
大量データにアクセスする場合に全表スキャンのほうが高速になる理由
表の中の大部分のブロックにアクセスする場合は、索引レンジ・スキャンより全表スキャン
のほうがコストが低くなります。これは、全表スキャンのほうが大きい I/O コールを使用し
ており、少数の大きい I/O コールのほうが、多数の小さい I/O コールよりもコストが低い
ためです。
14-18　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
オプティマイザが全表スキャンを使用する場合
オプティマイザは、次のいずれかの場合に全表スキャンを使用します。
索引の欠落 問合せで既存の索引を使用できない場合、全表スキャンを使用します。たとえ
ば、索引付きの列で使用される関数が問合せ内にある場合、オプティマイザは索引を使用で
きず、かわりに全表スキャンを使用します。
大小文字を区別しない検索に索引を使用する必要がある場合は、大小文字混合データを検索
列に許可しないか、検索列に UPPER(last_name) のようなファンクション索引を作成しま
す。16-10 ページの「パフォーマンスを考慮したファンクション索引の使用方法」を参照し
てください。
大量のデータ 問合せが表のブロックの大部分にアクセスするとオプティマイザが判断した
場合、索引が使用できる場合でも全表スキャンが使用される可能性があります。
小さい表 1 回の I/O コールで読み取れる DB_FILE_MULTIBLOCK_READ_COUNT より少ない
ブロックが表の最高水位標以内に格納されている場合には、表のどの部分にアクセスされる
かや、索引があるかどうかに関係なく、全表スキャンを行うほうが索引レンジ・スキャンよ
りもコストが低くなる可能性があります。
高い並列度 表の並列度が高いと、レンジ・スキャンよりも全表スキャンの方向にオプティ
マイザを偏らせます。表の並列度を判断するには、ALL_TABLES 内の DEGREE 列を調べま
す。
全表スキャンのヒント
全表スキャンを強制実行する場合は、ヒント FULL(table alias) を使用します。FULL ヒ
ントの詳細は、17-15 ページの「FULL」を参照してください。
パラレル問合せの実行
全表スキャンが必要である場合は、表のスキャンに複数のパラレル実行サーバーを使用し
て、応答時間を向上できます。パラレル問合せは、リソース使用の可能性があるために、一
般的には同時実行性の低いデータ・ウェアハウス環境で使用されます。
関連項目 : 『Oracle データ・ウェアハウス・ガイド』
問合せオプティマイザ
14-19
問合せオプティマイザのアクセス・パスについて
ROWID スキャン
行の ROWID には、行が含まれているデータファイルおよびデータ・ブロックと該当するブ
ロック内の位置を指定します。行の ROWID の特定による、行の位置特定は、単一行を取得
する最も高速な方法です。これは、取得する行のデータベース内での正確な位置が指定され
るためです。
ROWID を使用して表にアクセスする場合、まず、Oracle は選択された行の ROWID を、文
の WHERE 句、または 1 つ以上の表の索引の索引スキャンを使用して取得します。次に、
Oracle は ROWID に従って、それぞれの選択された行を表から探します。
14-16 ページの例 14-2「EXPLAIN PLAN 出力」では、索引スキャンが jobs 表および
departments 表で実行されます。取り出された ROWID は、行データを戻す場合に使用し
ます。
オプティマイザが ROWID を使用する場合
通常、これは索引から ROWID を取得した後の第 2 のステップです。索引内に存在しない文
の中の列には、表アクセスが必要になる場合があります。
ROWID によるアクセスでは、すべての索引スキャンに従う必要はありません。文に必要な
列がすべて索引に含まれていると、ROWID による表アクセスは行われない場合があります。
注意 : ROWID は、データが格納されている場所を表す Oracle の内部表
現です。ROWID はバージョン間で変更される場合があります。位置に基
づいたデータのアクセスは、お薦めしません。行の移行や連鎖によって、
行が移動するためです。また、エクスポートやインポートの後も同様で
す。外部キーは主キーに基づいている必要があります。ROWID の詳細は、
『Oracle Database アプリケーション開発者ガイド - 基礎編』を参照してく
ださい。
14-20　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
索引スキャン
この方法では、文で指定された索引付きの列の値を使用して索引が検索され、行が取得され
ます。索引スキャンでは、索引の 1 つ以上の列値に基づいて索引からデータが取得されま
す。索引スキャンを実行するために、Oracle は文によってアクセスされた列に対応する索引
を検索します。文が索引付けされた列にしかアクセスしない場合、Oracle は索引付けされた
列値を表からではなく、索引から直接読み込みます。
索引には、索引の値の他に、その値を持っている行の ROWID も含まれています。したがっ
て、索引付けされた列の他に別の列にも文がアクセスする場合、Oracle は、ROWID または
クラスタ・スキャンによる表アクセスのどちらかを使用して、表内の行を検索できます。
索引スキャンには次のタイプがあります。
■
ブロックの I/O（行ではなく）の想定
■
索引一意スキャン
■
索引レンジ・スキャン
■
索引レンジ・スキャン降順
■
索引スキップ・スキャン
■
全体スキャン
■
高速全索引スキャン
■
索引結合
■
ビットマップ索引
ブロックの I/O（行ではなく）の想定
（行ではなく）の想定
Oracle は、ブロック単位で I/O を実行します。したがって、全表スキャンを使用するかど
うかのオプティマイザの決定は、行でなくアクセスされるブロックのパーセンテージに影響
されます。これを索引クラスタ化係数といいます。ブロックに単一行が含まれている場合、
アクセスされる行とアクセスされるブロックは同じです。
ただし、大半の表には各ブロック内に複数の行があります。したがって、目的の行が、少な
いブロック内にまとまってクラスタ化されていたり、大量のブロックにわたって拡散されて
いることがあります。
クラスタ化係数は索引のプロパティですが、実際には、表のデータ・ブロック内の類似した
索引付き列の値の拡散度合いに関連します。低いクラスタ化係数は、個々の行が表の少数の
ブロック内に集中されることを示します。逆に、高いクラスタ化係数は、個々の行が表の複
数のブロックによりランダムに分散されることを示します。したがって、高いクラスタ化係
数の場合はレンジ・スキャンを使用して ROWID で行をフェッチするので、よりコストがか
かります。データを戻すために表の中のさらに多くのブロックにアクセスする必要があるた
めです。例 14-3 では、クラスタ化係数がコストにどのような影響を与えるかが示されていま
す。
問合せオプティマイザ
14-21
問合せオプティマイザのアクセス・パスについて
例 14-3 クラスタ化係数がコストに与える影響
次の状況を想定します。
■
9 つの行を持つ表があります。
■
表の col1 に一意でない索引があります。
■
c1 列は現在、値 A、B および C を格納しています。
■
表には、Oracle ブロックが 3 つしかありません。
ケース 1: 次の図のように配置されている場合、行に対して索引クラスタ化係数は低くなりま
す。
Block 1
------A A A
Block 2
------B B B
Block 3
-------C C C
これは、c1 に対して同じ索引付きの列の値を持つ行が、表の中の同じ物理ブロック内にあ
るためです。レンジ・スキャンを使用して、値 A を持つすべての行を戻す際のコストが低い
のは、表の中のブロックを 1 つのみ読み取れば済むためです。
ケース 2: 同じ行が、索引値が表ブロック間に分散する（並べるのではなく）ように再配置さ
れると、索引クラスタ化係数が高くなります。
Block 1
------A B C
Block 2
------A B C
Block 3
-------A B C
これは、表の中の 3 つのブロックを、col1 内に値 A を持つすべての行を取得するために、
すべて読み取る必要があるためです。
索引一意スキャン
このスキャンは 1 つの ROWID しか戻しません。文が単一行にしかアクセスしないことが保
証されている UNIQUE 制約または PRIMARY KEY 制約が存在する場合、Oracle は一意スキャ
ンを実行します。
14-16 ページの例 14-2「EXPLAIN PLAN 出力」では、それぞれ job_id_pk 索引と dept_
id_pk 索引を使用して、jobs 表および departments 表で索引スキャンが実行されます。
オプティマイザが索引一意スキャンを使用する場合 このアクセス・パスは、一意（B ツ
リー）索引または主キー制約の結果作成された索引の、すべての列が等価条件で指定される
場合に使用します。
関連項目 : 索引構造の詳細と B ツリーの検索方法の詳細は、
『Oracle
Database 概要』を参照してください。
14-22　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
索引一意スキャンのヒント 一般に、一意スキャンを行うためのヒントを使用する必要はあ
りません。ただし、表がデータベース・リンクにまたがっていて、ローカル表からアクセス
される場合や、表が小さく、オプティマイザが全表スキャンを選択する場合があります。
ヒント INDEX(alias index_name) は使用する索引を指定しますが、アクセス・パス（レ
ンジ・スキャンや一意スキャン）は指定しません。INDEX ヒントの詳細は、17-16 ページの
「INDEX」を参照してください。
索引レンジ・スキャン
索引レンジ・スキャンは、選択性の高いデータにアクセスする共通の操作です。このスキャ
ンは、境界（両側で境界付き）スキャンまたは非有界（片側または両側で）スキャンとする
ことができます。データは、索引列の昇順に戻されます。同じ値を持つ複数の行は、
ROWID で昇順にソートされます。
データを一定順序でソートする必要がある場合は、ORDER BY 句を使用し、索引には依存し
ません。索引を使用して ORDER BY 句を満たせる場合、オプティマイザはこのオプションを
使用し、ソートを回避します。
例 14-4 では順序がレガシー・システムからインポートされており、レガシー・システム内で
の参照で順序の問合せを行います。この参照が order_date であると仮定します。
例 14-4 索引レンジ・スキャン
SELECT order_status, order_id
FROM orders
WHERE order_date = :b1;
--------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
20 |
3 (34)|
|
1 | TABLE ACCESS BY INDEX ROWID| ORDERS
|
1 |
20 |
3 (34)|
|* 2 |
INDEX RANGE SCAN
| ORD_ORDER_DATE_IX |
1 |
|
2 (50)|
--------------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------2 - access("ORDERS"."ORDER_DATE"=:Z)
これは選択性の高い問合せである必要があり、問合せでは列の索引を使用して目的の行を取
得します。戻されたデータは、order_date の ROWID により昇順でソートされます。索引
列 order_date は、ここで選択された行と同じなので、データは ROWID でソートされま
す。
問合せオプティマイザ
14-23
問合せオプティマイザのアクセス・パスについて
オプティマイザが索引レンジ・スキャンを使用する場合 オプティマイザは、次のように条
件で指定された索引の 1 つ以上の先頭列を検出したとき、レンジ・スキャンを使用します。
■
col1 = :b1
■
col1 < :b1
■
col1 > :b1
■
索引内の先頭列に対する前述の条件の AND 組合せ
■
col1 like 'ASD%' によるワイルド・カード検索は、先頭で行わないでください。こ
れを先頭に置くと、条件 col1 like '%ASD' を使用した検索がレンジ・スキャンにな
りません。
レンジ・スキャンでは、一意索引または非一意索引を使用できます。レンジ・スキャンで
は、索引列が ORDER BY/GROUP BY 句を構成しているときにソートを回避します。
索引レンジ・スキャンのヒント オプティマイザが他の索引を選択したり、全表スキャンを
使用する場合は、ヒントが必要になる場合があります。ヒント INDEX(table_alias
index_name) では、使用する索引を指定します。INDEX ヒントの詳細は、17-16 ページの
「INDEX」を参照してください。
索引レンジ・スキャン降順
索引レンジ・スキャン降順は、データが降順で戻されること以外、索引レンジ・スキャンと
同じです。デフォルトでは、索引は昇順に格納されます。通常、このスキャンが使用される
のは、最初に最新のデータを戻すためにデータを降順に並べる場合や、指定された値より小
さい値を探す場合です。
オプティマイザが索引レンジ・スキャン降順を使用する場合 オプティマイザは、索引で降
順句による順序付けを満たせる場合に、索引レンジ・スキャン降順を使用します。
索引レンジ・スキャン降順のヒント ヒント INDEX_DESC(table_alias index_name)
は、このアクセス・パスに使用します。INDEX_DESC ヒントの詳細は、17-20 ページの
「INDEX_DESC」を参照してください。
索引スキップ・スキャン
索引スキップ・スキャンにより、接頭辞の付いていない列による索引スキャンが改善されま
す。多くの場合、索引ブロックをスキャンするほうが、表データ・ブロックをスキャンする
より高速です。
スキップ・スキャンにより、コンポジット索引をさらに小さい副索引に論理的に分割できま
す。スキップ・スキャンでは、コンポジット索引の初期列が問合せで指定されていません。
つまり、その列がスキップされます。
14-24　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
論理副索引の個数は、初期列内の個別値の数で決まります。スキップ・スキャンは、コンポ
ジット索引の先頭列に個別値がほとんどなく、索引の非先頭キーに値が多数ある場合に便利
です。
例 14-5 索引スキップ・スキャン
たとえば、コンポジット索引（sex、employee_id）を持つ表 employees（sex、
employee_id、address）を想定します。このコンポジット索引を分割すると、結果は 2
つの論理副索引 M および F になります。
この例で、次の索引データがあるとします。
('F',98)
('F',100)
('F',102)
('F',104)
('M',101)
('M',103)
('M',105)
索引は、論理的に次の 2 つの副索引に分割されます。
■
値 F を持つキーがある第 1 の副索引。
■
値 M を持つキーがある第 2 の副索引。
図 14-2 索引スキップ・スキャン
列 sex が、次の問合せでスキップされます。
SELECT *
FROM employees
WHERE employee_id = 101;
索引の完全なスキャンは行われませんが、まず値 F を持つ副索引が検索され、次に値 M を持
つ副索引が検索されます。
問合せオプティマイザ
14-25
問合せオプティマイザのアクセス・パスについて
全体スキャン
全体スキャンを使用できるのは、述語が索引内の列の 1 つを参照している場合です。述語が
索引のドライバである必要はありません。述語がなく、次の条件が 2 つとも満たされる場合
も、全体スキャンを使用できます。
■
問合せで参照される表の列すべてが索引に含まれている。
■
少なくとも索引列の 1 つが NOT NULL。
全体スキャンを使用してソート操作を解消できるのは、データが索引キーで並べられるため
です。全体スキャンではブロックが単独で読み込まれます。
高速全索引スキャン
高速全索引スキャンは、問合せに必要なすべての列が索引に含まれ、索引キー内の 1 つ以上
の列に NOT NULL 制約が存在する場合に、全表スキャンの代用として使用されます。高速全
スキャンは、表にアクセスすることなく索引そのものに存在するデータにアクセスします。
このスキャンでソート操作を解消できないのは、データが索引キーで並べられないためで
す。高速全スキャンでは、全索引スキャンとは異なりマルチブロック READ を使用して索引
全体が読み込まれ、パラレル実行も可能です。
高速全スキャンは、初期化パラメータ OPTIMIZER_FEATURES_ENABLE または INDEX_FFS
ヒントを使用して指定できます。高速全索引スキャンはビットマップ索引に対しては実行で
きません。
高速全スキャンは、表スキャンと同様にマルチブロック I/O を使用してパラレル化できるた
め、通常の全索引スキャンより高速です。
高速全索引スキャンのヒント 高速全索引スキャンには、特別な索引ヒント INDEX_FFS が
あります。この形式と引数は、通常の INDEX ヒントと同じです。INDEX_FFS ヒントの詳細
は、17-20 ページの「INDEX_FFS」を参照してください。
索引結合
索引結合は、問合せで参照される表の列すべてが含まれている複数の索引のハッシュ結合で
す。索引結合が使用された場合は、関連するすべての列値が索引から取り出されるので、表
アクセスは必要ありません。索引結合は、ソート操作の絞込みには使用できません。
索引結合のヒント 索引結合は、INDEX_JOIN ヒントを使用して指定できます。INDEX_
JOIN ヒントの詳細は、17-19 ページの「INDEX_JOIN」を参照してください。
14-26　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
ビットマップ索引
ビットマップ結合は、キー値用のビットマップおよび各ビット位置を ROWID に変換する
マッピング機能を使用します。ビットマップは、AND 条件と OR 条件の変換にブール演算を
使用して、WHERE 句内の複数の条件に対応する索引を効果的にマージできます。
注意 : ビットマップ索引とビットマップ結合索引が使用可能なのは、
Oracle Enterprise Edition をご購入されている場合のみです。
関連項目 : ビットマップ索引の詳細は、『Oracle データ・ウェアハウス・
ガイド』を参照してください。
クラスタ・アクセス
クラスタ・スキャンは、索引クラスタに格納された表から、クラスタ・キー値の等しい行す
べてを取得するときに使用されます。索引クラスタ内においては、同一のクラスタ・キー値
を持つすべての行が同じデータ・ブロックに格納されています。クラスタ・スキャンを実行
するために、Oracle は、クラスタ索引をスキャンすることによって、選択されている行の
ROWID を最初に取得します。次に、Oracle はその行を ROWID に従って探します。
ハッシュ・アクセス
ハッシュ・スキャンは、ハッシュ値に基づいて行をハッシュ・クラスタに配置するために使
用します。ハッシュ・クラスタ内においては、同一のハッシュ値を持つすべての行が同じ
データ・ブロックに格納されています。ハッシュ・スキャンを実行するために、Oracle は、
文によって指定されたクラスタ・キー値にハッシュ関数を適用することによって、最初に
ハッシュ値を取得します。次に、Oracle はそのハッシュ値を持つ行が含まれているデータ・
ブロックを操作します。
サンプル表スキャン
サンプル表スキャンでは、単純な表、または結合およびビューを含む文などの複合 SELECT
文からデータのランダムなサンプルが取り出されます。このアクセス・パスは、文の FROM
句に SAMPLE 句または SAMPLE BLOCK 句が含まれているときに使用されます。SAMPLE 句を
持つ行単位でサンプリングするときにサンプル表スキャンを実行するには、表の中の指定さ
れたパーセントの行を読み取ります。SAMPLE BLOCK 句を持つブロック単位でサンプリング
するときにサンプル表スキャンを実行するには、表のブロックの中の指定されたパーセント
のブロックを読み取ります。
例 14-6 は、サンプル表スキャンを使用して、ブロックによるサンプリングを行って
employees 表の 1% にアクセスします。
問合せオプティマイザ
14-27
問合せオプティマイザのアクセス・パスについて
例 14-6 サンプル表スキャン
SELECT *
FROM employees SAMPLE BLOCK (1);
この文の EXPLAIN PLAN 出力は、次のような形式になります。
------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
68 |
3 (34)|
|
1 | TABLE ACCESS SAMPLE | EMPLOYEES
|
1 |
68 |
3 (34)|
-------------------------------------------------------------------------
問合せオプティマイザによるアクセス・パスの選択方法
問合せオプティマイザは、次の要因に従ってアクセス・パスを選択します。
■
文で使用可能なアクセス・パス
■
各アクセス・パスまたはパスの組合せを使用して文を実行するための見積りコスト
アクセス・パスを選択する場合、オプティマイザは、文の WHERE 句、および FROM 句の条
件を調べて、使用可能なアクセス・パスを最初に判断します。次に、オプティマイザは、使
用可能なアクセス・パスを使用して可能な実行計画のセットを生成し、文にアクセス可能な
索引、列および表の統計を使用して各見積りコストを生成します。そして最後に、オプティ
マイザは見積りコストが最も少ない実行計画を選択します。
アクセス・パスを選択する場合、問合せオプティマイザは次の影響を受けます。
■
オプティマイザ・ヒント
オプティマイザが選択した使用可能なアクセス・パスは、ヒントを使用して上書きでき
ますが、文の FROM 句に SAMPLE または SAMPLE BLOCK が含まれているときには上書き
できません。
関連項目 : SQL 文のヒントの詳細は、第 17 章「オプティマイザ・ヒン
ト」を参照してください。
■
古い統計
たとえば、表が作成された後に解析されなかった場合およびブロックが DB_FILE_
MULTIBLOCK_READ_COUNT 最高水位標より少ない場合は、オプティマイザはその表は
小さいと判断し、全表スキャンが使用されます。ALL_TABLES 表内の LAST_ANALYZED
列および BLOCKS 列を見て、統計を調べてください。
14-28　Oracle Database パフォーマンス・チューニング・ガイド
結合について
結合について
結合は、複数の表からデータを取り出す文です。結合は FROM 句の中の複数の表で特性化さ
れ、各表の関係は WHERE 句の中に結合条件を設定することで定義されます。結合では、片
方の行セットが内部と呼ばれ、もう一方が外部と呼ばれます。
この項では、次の内容を説明します。
■
問合せオプティマイザによる結合文の実行方法
■
問合せオプティマイザによる結合の実行計画の選択方法
■
結合方法
■
ネステッド・ループ結合
■
ハッシュ結合
■
ソート / マージ結合
■
デカルト結合
■
外部結合
関連項目 : 結合の詳細は、『Oracle Database SQL リファレンス』を参照
してください。
問合せオプティマイザによる結合文の実行方法
結合文に実行計画を選択するために、オプティマイザは、相互に関連する次の決定を行う必
要があります。
■
アクセス・パス
単純な文では、オプティマイザは、結合文の各表からデータを取り出すアクセス・パス
を選択する必要があります。
■
結合方法
行ソースの各ペアを結合するには、結合操作を Oracle が実行する必要があります。結
合方法には、ネステッド・ループ結合、ソート / マージ結合、デカルト結合およびハッ
シュ結合があります。
■
結合順序
3 つ以上の表を結合する文を実行する場合、Oracle は 2 つの表を結合し、その結果作成
された行ソースを次の表に結合します。このプロセスは、すべての表がその結果に結合
されるまで続行されます。
関連項目 :
て」
14-18 ページ「問合せオプティマイザのアクセス・パスについ
問合せオプティマイザ
14-29
結合について
問合せオプティマイザによる結合の実行計画の選択方法
実行計画を選択するとき、問合せオプティマイザでは次の点が考慮されます。
■
■
オプティマイザは、2 つ以上の表を結合した結果を、最大 1 つの行を含む行ソースに限
定するかどうかを最初に判断します。オプティマイザは、このような状況を表の
UNIQUE 制約および PRIMARY KEY 制約に基づいて認識します。このような状況が存在
する場合、オプティマイザはこれらの表を結合順序の最初に並べます。その後で、残り
の表の結合を最適化します。
外部結合条件を持つ結合文では、外部結合演算子のある表の結合順序は、条件内のその
他の表の後にしてください。オプティマイザは、この規則に違反する結合順序を考慮し
ません。同様に、副問合せがアンチ結合またはセミ結合に変換されたときは、その副問
合せからの表は、それらが接続または相互に関連付けされた外部問合せブロック内の表
の後に置きます。ただし、ある環境では、ハッシュ・アンチ結合およびセミ結合はこの
順序条件を上書きできます。
問合せオプティマイザでは、適用可能な結合順序、結合方法および使用可能なアクセス・パ
スに従ってオプティマイザが実行計画のセットを生成します。次に、オプティマイザは各計
画のコストを見積り、コストが最も小さいものを選択します。オプティマイザは、次の方法
でコストを見積ります。
■
■
■
ネステッド・ループ操作のコストは、外部表で選択されている各行およびその行に対す
る内部表の一致行をメモリーに読み込むコストが基準になっています。オプティマイザ
は、データ・ディクショナリ内の統計を使用してこれらのコストを見積ります。
ソート / マージ結合のコストは、主に、すべてのソースをメモリーに読み込んでソート
するコストを基準にしています。
ハッシュ結合のコストは、主に、結合への入力側の 1 つ上にハッシュ表を作成するコス
トと、それを調べるために結合のもう一方からの行を使用するコストに基づきます。
オプティマイザは、各操作のコストを判断するときにはその他の要因についても考慮しま
す。たとえば、次のようにします。
■
■
ソート領域のサイズが小さいと、小さいソート領域内でのソートに CPU 時間と I/O が
より多く消費されるため、ソート / マージ結合のコストが大きくなる傾向があります。
SQL 作業領域のサイズ設定については、7-49 ページの「PGA メモリー管理」を参照し
てください。
マルチブロック READ カウントが大きいと、ネステッド・ループ結合に関してソート /
マージ結合のコストが少なくなる傾向があります。多数の連続したブロックが単独の
I/O でディスクから読み込まれる場合は、全表スキャンよりもパフォーマンスを改善す
るために、ネステッド・ループ結合の内部表についての索引が少なくなる傾向がありま
す。マルチブロック READ カウントは、初期化パラメータ DB_FILE_MULTIBLOCK_
READ_COUNT によって指定されます。
14-30　Oracle Database パフォーマンス・チューニング・ガイド
結合について
問合せオプティマイザでは、ORDERED ヒントを使用して結合順序に関するオプティマイザ
の選択を上書きできます。ORDERED ヒントによって、外部結合に関するこの規則に違反す
る結合順序が指定された場合、オプティマイザはこのヒントを無視して順序を選択します。
結合方法に関するオプティマイザの選択も、ヒントを使用して上書きできます。
関連項目 : オプティマイザ・ヒントの詳細は、第 17 章「オプティマイ
ザ・ヒント」を参照してください。
ネステッド・ループ結合
ネステッド・ループ結合は、データの小さいサブセットを結合する場合や、結合条件が第 2
の表にアクセスする効率的な方法である場合に有効です。
内部表が外部表から（外部表によって）駆動されることを確認することが重要です。内部表
のアクセス・パスが外部表とは独立している場合は、外部ループを繰り返すたびに同じ行が
取得されます。これは、パフォーマンスをかなり低下させてしまいます。そのような場合
は、2 つの独立した行ソースを結合するハッシュ結合のほうがパフォーマンスが優れていま
す。
関連項目 :
14-35 ページ「デカルト結合」
ネステッド・ループ結合には、次のステップがあります。
1.
オプティマイザで駆動表が決定され、これが外部表に指定されます。
2.
その他の表は、内部表に指定します。
3.
外部表にあるすべての行について、内部表にあるすべての行がアクセスされます。外部
ループは外部表にあるすべての行に対するものであり、内部ループは内部表の中にある
すべての行に対するものです。次のように、外部ループは実行計画の内部ループの前に
表示されます。
NESTED LOOPS
outer_loop
inner_loop
ネステッド・ループ結合
この項では、14-16 ページの例 14-1 の問合せにおけるネステッド・ループの 1 つの外部ルー
プおよび内部ループを説明します。
...
|
|*
|
|*
...
2
3
4
5
|
|
|
|
NESTED LOOPS
|
TABLE ACCESS FULL
| EMPLOYEES
TABLE ACCESS BY INDEX ROWID| JOBS
INDEX UNIQUE SCAN
| JOB_ID_PK
|
|
|
|
3
3
19
1
|
|
|
|
141 |
60 |
513 |
|
7
4
2
(15)|
(25)|
(50)|
|
問合せオプティマイザ
14-31
結合について
この例では、外部ループが employees 表のすべての行を取得します。外部ループによって
取得された各従業員に対して、内部ループが jobs 表内の関連行を取得します。
外部ループ 14-16 ページの例 14-2 の実行計画では、外部ループおよびそれと等価の文は次
のとおりです。
3 |
TABLE ACCESS FULL
| EMPLOYEES
SELECT e.employee_id, e.salary
FROM employees e
WHERE e.employee_id < 103
内部ループ 次のように、14-16 ページの例 14-2 の実行計画は、外部ループから取得された
すべての行について繰り返される内部ループであることを示します。
4 |
5 |
TABLE ACCESS BY INDEX ROWID| JOBS
INDEX UNIQUE SCAN
| JOB_ID_PK
SELECT j.job_title
FROM jobs j
WHERE e.job_id = j.job_id
オプティマイザがネステッド・ループ結合を使用する場合
オプティマイザは、2 つの表の間で適切な駆動条件で少数の行を結合する場合に、ネステッ
ド・ループ結合を使用します。外部ループから内部ループに起動するので、実行計画の中の
表の順序が重要になります。
外部ループは駆動行ソースです。このループは、結合条件を駆動するための一連の行を生成
します。行ソースは、索引スキャンまたは全表スキャンでアクセスされる表とすることがで
きます。また、他の操作からでも行を生成できます。たとえば、ネステッド・ループ結合か
らの出力は別のネステッド・ループ結合の行ソースとして使用できます。
内部ループは外部ループから戻された行ごとに、索引スキャンによって反復されます。内部
ループのアクセス・パスが外部ループに依存していない場合は、デカルト積で終了すること
が可能で、外部ループの反復ごとに、内部ループは同じ行セットを生成します。したがっ
て、2 つの独立した行ソースをまとめて結合する場合は、他の結合方法を使用することをお
薦めします。
ネステッド・ループ結合のヒント
オプティマイザが他の結合方法を選択する場合は、USE_NL(table1 table2) ヒントを使用
します。table1 と table2 は、結合される表の別名です。
データが十分に小さい SQL 例の場合は、オプティマイザは全表スキャンを優先してハッ
シュ結合を使用します。14-33 ページの例 14-7「ハッシュ結合」は、その SQL の例です。た
だし、USE_NL ヒントを追加して結合方法をネステッド・ループに変更できます。USE_NL
ヒントの詳細は、17-32 ページの「USE_NL」を参照してください。
14-32　Oracle Database パフォーマンス・チューニング・ガイド
結合について
ネステッド・ループのネスト
ネステッド・ループの外部ループ自体もネステッド・ループにできます。2 つ以上の外部
ループをまとめてネストし、必要な数の表に結合できます。次に示すように、各ループは
データ・アクセス方法です。
SELECT STATEMENT
NESTED LOOP 3
NESTED LOOP 2
NESTED LOOP 1
OUTER LOOP 1.1
INNER LOOP 1.2
INNER LOOP 2.2
INNER LOOP 3.2
-
(OUTER LOOP 3.1)
(OUTER LOOP 2.1)
#1
#2
#3
#4
ハッシュ結合
ハッシュ結合は、大きなデータ・セットを結合する場合に使用します。オプティマイザは、
2 つの表またはデータ・ソースの小さいほうを使用して、メモリー内の結合キーにハッシュ
表を作成します。次に、大きいほうの表をスキャンし、ハッシュ表を調べて結合された行を
見つけます。
この方法は、小さいほうの表が使用可能なメモリー内に収まる場合に最適です。これによ
り、コストが 2 つの表のデータに対する 1 回のリード・パスに制限されます。
オプティマイザがハッシュ結合を使用する場合
オプティマイザは、2 つの表が等価結合で結合され、次の条件のいずれかが真である場合に、
ハッシュ結合で 2 つの表を結合します。
■
大量のデータを結合する必要がある。
■
小規模表の大きな部分を結合する必要がある。
例 14-7 では、表 orders がハッシュ表の作成に使用されます。また、後でスキャンされる
order_items は、これより大きな表です。
例 14-7 ハッシュ結合
SELECT o.customer_id, l.unit_price * l.quantity
FROM orders o ,order_items l
WHERE l.order_id = o.order_id;
-------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
665 | 13300 |
8 (25)|
|* 1 | HASH JOIN
|
|
665 | 13300 |
8 (25)|
|
2 |
TABLE ACCESS FULL | ORDERS
|
105 |
840 |
4 (25)|
問合せオプティマイザ
14-33
結合について
|
3 |
TABLE ACCESS FULL | ORDER_ITEMS |
665 | 7980 |
4 (25)|
-------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------1 - access("L"."ORDER_ID"="O"."ORDER_ID")
ハッシュ結合のヒント
2 つの表をまとめて結合するときに、ハッシュ結合を適用するようにオプティマイザにアド
バイスするには、USE_HASH ヒントを使用します。SQL 作業領域のサイズ設定については、
7-49 ページの「PGA メモリー管理」を参照してください。USE_HASH ヒントの詳細は、
17-34 ページの「USE_HASH」を参照してください。
ソート / マージ結合
ソート / マージ結合を使用して、2 つの独立したソースからの行を結合できます。ハッシュ
結合は、一般に、ソート / マージ結合よりパフォーマンスが優れています。次の条件が 2 つ
とも存在する場合は、ハッシュ結合よりソート / マージ結合のほうがパフォーマンスの点で
優れています。
■
行ソースはソート済。
■
ソート操作を終了する必要なし。
ソート / マージ結合に、より低速のアクセス方法（全表スキャンとは対照的な索引スキャ
ン）の選択が含まれている場合、ソート / マージを使用する利点が失われる可能性がありま
す。
ソート / マージ結合は、2 つの表の間の結合条件が <、<=、> または >= などの等価条件で
はない（ただし、非等価ではない）場合に有効です。ソート / マージ結合は、大きいデー
タ・セットの場合にネステッド・ループ結合よりパフォーマンスが優れています。等価条件
がないかぎり、ハッシュ結合を使用できません。
マージ結合には、駆動表の概念はありません。結合には、2 つのステップが含まれています。
1.
ソート結合操作 : 両方の入力が、結合キーでソートされる。
2.
マージ結合処理 : ソートされたリストがマージされる。
入力がすでに結合列でソートされている場合、その行ソースに対してソート結合操作は行わ
れません。
14-34　Oracle Database パフォーマンス・チューニング・ガイド
結合について
オプティマイザがソート / マージ結合を使用する場合
オプティマイザは、次の条件が真である場合に、ハッシュ結合よりソート / マージ結合を選
択して大量のデータを結合します。
■
■
2 つの表の間の結合条件が、等価結合ではない。
ソートが他の操作ですでに要求されているため、オプティマイザは、ハッシュ結合より
ソート / マージを使用するほうがコストが低いと判断した。
ソート / マージ結合のヒント
ソート / マージ結合を使用するようオプティマイザに指示するには、USE_MERGE ヒントを
適用します。また、アクセス・パスを設定するためのヒントを与える必要がある場合があり
ます。
USE_MERGE ヒントでオプティマイザを上書きした方がよい場合があります。たとえば、オ
プティマイザは表に対する全体スキャンを選択して問合せ内でのソート操作を回避できま
す。ただし、大きい表は全表スキャンによる高速アクセスの場合とは異なり、索引および単
一ブロック読込みでアクセスされるため、コストがかかります。
USE_MERGE ヒントの詳細は、17-33 ページの「USE_MERGE」を参照してください。
デカルト結合
他の表への結合条件を文中に持たない表が 1 つ以上ある場合に、デカルト結合が使用されま
す。オプティマイザは、データ・ソースにあるすべての行を、2 つのセットのデカルト積を
作成しながら、別のデータ・ソースにあるすべての行と結合します。
オプティマイザがデカルト結合を使用する場合
オプティマイザは、結合条件のない 2 つの表を結合する指示を受けると、デカルト結合を実
行します。場合によっては、2 つの表の間に共通のフィルタ条件が存在して、オプティマイ
ザが可能な結合条件として採用する可能性があります。また、オプティマイザが、同じ大き
い表に結合されている非常に小さい 2 つの表のデカルト積を生成するように決定する場合も
あります。
デカルト結合のヒント
ORDERED ヒントを適用すると、オプティマイザはデカルト結合を使用します。結合表を指
定する前に表を指定すると、オプティマイザはデカルト結合を行います。ORDERED ヒントの
詳細は、17-31 ページの「ORDERED」を参照してください。
問合せオプティマイザ
14-35
結合について
外部結合
外部結合は単純結合の結果を拡張したものです。外部結合は、結合条件に一致するすべての
行および結合条件が他の表のどの行とも一致しない、表の一部またはすべての行を戻しま
す。
ネステッド・ループ外部結合
この操作は、外部結合が 2 つの表の間で使用されるときに使用します。外部結合は、内部
（オプション）表に対応する行がない場合でも外部（保たれている）表の行を戻します。
正規の外部結合で、オプティマイザはコストに基づいて表（駆動する側と駆動される側）の
順序を選択します。ただし、ネステッド・ループ外部結合では、表の順序は結合条件で決定
されます。行が保たれる外部表は、内部表に駆動する場合に使用します。
オプティマイザは、ネステッド・ループ結合を使用し、次の状況で外部結合を処理します。
■
外部表から内部表まで起動できる。
■
データ量が少なく、ネステッド・ループ方法が効果的と判断できる。
ネステッド・ループの外部結合例の場合は、USE_NL ヒントを例 14-8 に追加してネステッ
ド・ループを使用するようにできます。たとえば、次のようにします。
SELECT /*+ USE_NL(c o) */ cust_last_name, sum(nvl2(o.customer_id,0,1)) "Count"
ハッシュ結合外部結合
データ量が十分大きく、ハッシュ結合方法が有効と判断される場合や、外部表から内部表を
駆動できない場合、オプティマイザは外部結合の処理にハッシュ結合を使用します。
表の順序はコストにより決定されます。外部表は、保存された行も含めて、ハッシュ表を作
成する場合に使用されるか、またはハッシュ表を調べるときに使用される場合があります。
例 14-8 では、一般的なハッシュ結合外部結合の問合せが示されています。この例では、与信
限度が 1000 を超えるすべての顧客が問い合されます。外部結合は、オーダーを持たない顧
客を見逃さないようにするために必要です。
例 14-8 ハッシュ結合外部結合
SELECT
FROM
WHERE
AND
GROUP
cust_last_name, sum(nvl2(o.customer_id,0,1)) "Count"
customers c, orders o
c.credit_limit > 1000
c.customer_id = o.customer_id(+)
BY cust_last_name;
------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
168 | 3192 |
11 (28)|
14-36　Oracle Database パフォーマンス・チューニング・ガイド
結合について
|
1 | SORT GROUP BY
|
|
168 | 3192 |
11 (28)|
|* 2 |
HASH JOIN OUTER
|
|
260 | 4940 |
10 (20)|
|* 3 |
TABLE ACCESS FULL | CUSTOMERS
|
260 | 3900 |
6 (17)|
|* 4 |
TABLE ACCESS FULL | ORDERS
|
105 |
420 |
4 (25)|
------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------2 - access("C"."CUSTOMER_ID"="O"."CUSTOMER_ID"(+))
3 - filter("C"."CREDIT_LIMIT">1000)
4 - filter("O"."CUSTOMER_ID"(+)>0)
この問合せは、様々な条件に一致する顧客を検索します。内部表に対応する行が見つからな
いと、外部結合は外部（保たれている）表の行とともに内部表の列に対して NULL を戻しま
す。この操作で、orders 行も持たない customers 行がすべて検索されます。
この場合、外部結合条件は次のとおりです。
customers.customer_id = orders.customer_id(+)
この条件の構成要素を次に示します。
■
外部表は customers です。
■
内部表は orders です。
■
この結合は、orders 内に対応する行を持たない行を含む customers 行を保存します。
行を戻すには、NOT EXISTS 副問合せを使用できます。ただし、ここでは表の全行の問合せ
を行っているため、ハッシュ結合のほうがパフォーマンスがよくなります（NOT EXISTS 副
問合せがネストされていない場合を除く）
。
例 14-9 では、外部結合はマルチ表ビューに対して行われます。オプティマイザは通常の結合
のようにビューを操作したり、述語をプッシュできないので、ビューの行セット全体を作成
します。
例 14-9 マルチ表ビューへの外部結合
SELECT
FROM
WHERE
AND
GROUP
c.cust_last_name, sum(revenue)
customers c, v_orders o
c.credit_limit > 2000
o.customer_id(+) = c.customer_id
BY c.cust_last_name;
---------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
---------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
144 | 4608 |
16 (32)|
|
1 | SORT GROUP BY
|
|
144 | 4608 |
16 (32)|
問合せオプティマイザ
14-37
結合について
|* 2 |
HASH JOIN OUTER
|
|
663 | 21216 |
15 (27)|
|* 3 |
TABLE ACCESS FULL
| CUSTOMERS
|
195 | 2925 |
6 (17)|
|
4 |
VIEW
| V_ORDERS
|
665 | 11305 |
|
|
5 |
SORT GROUP BY
|
|
665 | 15960 |
9 (34)|
|* 6 |
HASH JOIN
|
|
665 | 15960 |
8 (25)|
|* 7 |
TABLE ACCESS FULL| ORDERS
|
105 |
840 |
4 (25)|
|
8 |
TABLE ACCESS FULL| ORDER_ITEMS |
665 | 10640 |
4 (25)|
---------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------2 - access("O"."CUSTOMER_ID"(+)="C"."CUSTOMER_ID")
3 - filter("C"."CREDIT_LIMIT">2000)
6 - access("O"."ORDER_ID"="L"."ORDER_ID")
7 - filter("O"."CUSTOMER_ID">0)
ビュー定義は、次のようになります。
CREATE OR REPLACE view v_orders AS
SELECT l.product_id, SUM(l.quantity*unit_price) revenue,
o.order_id, o.customer_id
FROM orders o, order_items l
WHERE o.order_id = l.order_id
GROUP BY l.product_id, o.order_id, o.customer_id;
ソート / マージ外部結合
外部結合で、外部（保たれている）表から内部（オプション）表への駆動ができない場合、
外部結合ではハッシュ結合またはネステッド・ループ結合が使用できません。その場合、外
部結合では結合操作を実行するためにソート / マージ外部結合を使用します。
オプティマイザは、次の場合に外部結合にソート / マージを使用します。
■
■
ネステッド・ループ結合の効率が悪い場合。データ量により、ネステッド・ループ結合
は効率が悪い場合があります。
ソートが他の操作ですでに要求されているため、ハッシュ結合よりソート / マージを使
用するほうがコストが低いと判断した場合。
完全外部結合
完全外部結合は、左と右の外部結合の組合せのように動作します。内部結合では、内部結合
の結果で戻されなかった両方の表からの行は保たれており、NULL で拡張されます。つま
り、完全外部結合を使用すると、表をまとめて結合できますが、結合される表内に対応する
行を持たない行も示すことができます。
例 14-10 の問合せでは、全部門と、その各部門に属する全社員を取得しますが、これには次
の内容も含まれます。
14-38　Oracle Database パフォーマンス・チューニング・ガイド
結合について
■
部門に属さない全社員
■
社員のいない全部門
例 14-10 完全外部結合
SELECT
FROM
FULL
ON
ORDER
d.department_id, e.employee_id
employees e
OUTER JOIN departments d
e.department_id = d.department_id
BY d.department_id;
文からは、次の出力が作成されます。
DEPARTMENT_ID EMPLOYEE_ID
------------- ----------10
200
20
201
20
202
30
114
30
115
30
116
...
270
280
178
207
125 rows selected.
問合せオプティマイザ
14-39
結合について
14-40　Oracle Database パフォーマンス・チューニング・ガイド
15
オプティマイザ統計の管理
この章では、問合せオプティマイザにとって統計が重要である理由、および DBMS_STATS
パッケージを使用したオプティマイザ統計の収集方法と使用方法を説明します。
この章には次の項があります。
■
統計について
■
自動統計収集
■
手動統計収集
■
システム統計
■
統計の管理
■
統計の参照
オプティマイザ統計の管理
15-1
統計について
統計について
オプティマイザ統計は、データベースとそのオブジェクトに関する詳細情報を記述するデー
タの集合です。これらの統計は、問合せオプティマイザで各 SQL 文に最適の実行計画を選択
するために使用されます。オプティマイザ統計には次のものがあります。
■
■
■
■
表統計
–
行数
–
ブロック数
–
行の平均長さ
列統計情報
–
列内の個別値（NDV）数
–
列内の NULL 数
–
データ配分（ヒストグラム）
索引統計
–
リーフ・ブロック数
–
レベル
–
クラスタ化係数
システム統計
–
I/O パフォーマンスと使用率
–
CPU パフォーマンスと使用率
注意 : この項で説明する統計は、問合せを最適化する目的で作成されて
データ・ディクショナリに格納されるオプティマイザ統計です。この種の
統計を V$ ビューで参照可能なパフォーマンス統計と混同しないでくださ
い。
オプティマイザ統計はデータ・ディクショナリに格納されます。また、データ・ディクショ
ナリ・ビューを使用して表示できます。15-18 ページの「統計の参照」を参照してください。
データベース内のオブジェクトは常に変化するため、これらのデータベース・オブジェクト
が正確に記述されるように統計を定期的に更新する必要があります。統計は Oracle により自
動的にメンテナンスされます。また、DBMS_STATS パッケージを使用するとオプティマイザ
統計を手動でメンテナンスできます。自動プロセスと手動プロセスについては、15-3 ページ
の「自動統計収集」または 15-6 ページの「手動統計収集」を参照してください。
15-2　Oracle Database パフォーマンス・チューニング・ガイド
自動統計収集
DBMS_STATS パッケージにも、統計を管理するためのプロシージャが用意されています。統
計のコピーを保存してリストアできます。あるシステムから統計をエクスポートし、別のシ
ステムにインポートできます。たとえば、本番システムからテスト・システムに統計をエク
スポートできます。また、統計が変更されないようにロックすることも可能です。ロック方
法については、15-14 ページの「表統計またはスキーマ統計のロック」を参照してください。
自動統計収集
推奨の統計収集方法は、Oracle で統計の自動収集を可能にすることです。Oracle では、すべ
てのデータベース・オブジェクトの統計が自動的に収集され、定期的にスケジュールされた
メンテナンス・ジョブで統計がメンテナンスされます。自動化された統計収集により、問合
せオプティマイザの管理に関連する多数の手動タスクが不要になり、統計の欠落または失効
が原因で不適切な実行計画が生成される可能性が大幅に低下します。
GATHER_STATS_JOB
オプティマイザ統計は、GATHER_STATS_JOB ジョブで自動的に収集されます。このジョブ
では、データベース内で次の統計を持つすべてのオブジェクトの統計が収集されます。
■
統計の欠落
■
統計の失効
このジョブはデータベースの作成時に自動的に作成され、スケジューラにより管理されま
す。このスケジューラでは、メンテナンス・ウィンドウがオープンすると、このジョブが実
行されます。デフォルトでは、メンテナンス・ウィンドウは、毎晩午後 10 時～午前 6 時ま
で、また週末は 1 日中オープンしています。GATHER_STATS_JOB は、メンテナンス・ウィ
ンドウに割り当てられた時間を超えた場合にも、完了するまで続行されます。メンテナン
ス・ウィンドウのデフォルト動作は変更できます。
関連項目 : スケジューラおよびメンテナンス・ウィンドウ・タスクの詳
細は、
『Oracle Database 管理者ガイド』を参照してください。
GATHER_STATS_JOB ジョブでは、DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC
プロシージャがコールされ、オプティマイザ統計が収集されます。GATHER_DATABASE_
STATS_JOB_PROC プロシージャによりデータベース・オブジェクトの統計が収集されるの
は、オブジェクトの統計が以前に収集されていない場合、または基礎となるオブジェクトが
大幅に（行の 10% 以上が）変更されたために既存の統計が失効している場合です。DBMS_
STATS.GATHER_DATABASE_STATS_JOB_PROC は内部プロシージャですが、その動作は
GATHER AUTO オプションを使用する DBMS_STATS.GATHER_DATABASE_STATS プロシー
ジャとほとんど同じです。主な違いは、DBMS_STATS.GATHER_DATABASE_STATS_JOB_
PROC プロシージャでは、統計を必要とするデータベース・オブジェクトに優先順位が設定
されるため、更新済の統計を最も必要とするオブジェクトが最初に処理されることです。こ
れにより、メンテナンス・ウィンドウがクローズする前に、最も必要性の高い統計が確実に
収集されます。
オプティマイザ統計の管理
15-3
自動統計収集
自動統計収集を使用可能にする方法
自動統計収集は、データベースの作成時または以前のリリースからのアップグレード時にデ
フォルトで使用可能になります。DBA_SCHEDULER_JOBS ビューを表示すると、ジョブの存
在を確認できます。
SELECT * FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME = 'GATHER_STATS_JOB';
自動統計収集を使用禁止にする場合に最も直接的なアプローチは、次のように GATHER_
STATS_JOB を使用禁止にすることです。
BEGIN
DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
END;
/
自動統計収集は、15-9 ページの「失効している統計の判別」で説明するように変更監視機能
に依存します。この機能が無効になっている場合、自動統計収集ジョブでは失効している統
計を検出できません。この機能は、STATISTICS_LEVEL パラメータが TYPICAL または ALL
に設定されている場合に有効になります。デフォルト値は TYPICAL です。
統計収集時の考慮事項
この項では、次の内容を説明します。
■
手動統計を使用する場合
■
前のバージョンの統計のリストア
■
統計のロック
手動統計を使用する場合
普通の速度で変更されるほとんどのデータベース・オブジェクトの場合は、自動統計収集で
十分です。ただし、自動統計収集では不十分な場合があります。自動統計収集は夜間のバッ
チ・ウィンドウで実行されるため、日中に大幅に変更された表の統計が失効している可能性
があります。通常、この種のオブジェクトには次の 2 つのタイプがあります。
■
■
日中に削除または切り捨てられて再作成された揮発性の表
オブジェクトの合計サイズの 10% 以上を追加する大規模バルク・ロードのターゲットで
あるオブジェクト
揮発性の高い表の場合は、次の 2 つのアプローチがあります。
■
これらの表の統計を NULL に設定できます。Oracle では、統計のない表が検出される
と、問合せ最適化の一部として必要な統計が動的に収集されます。この動的サンプリン
グ機能は OPTIMIZER_DYNAMIC_SAMPLING パラメータにより制御されます。このパラ
メータは 2 以上の値に設定する必要があります。デフォルト値は 2 です。統計は、削除
してからロックすることで NULL に設定できます。
15-4　Oracle Database パフォーマンス・チューニング・ガイド
自動統計収集
BEGIN
DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS');
DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');
END;
/
設定できるサンプリング・レベルの詳細は、15-16 ページの「動的サンプリング・レベ
ル」を参照してください。
■
この種の表の統計は、表の典型的な状態を表す値に設定できます。表に代表的な行数が
含まれているときに、その表の統計を収集し、統計をロックする必要があります。
この方法は GATHER_STATS_JOB よりも効率的です。これは、夜間のバッチ・ウィンド
ウで表に関して生成された統計が、日中のワークロードに関して最も適切な統計である
とはかぎらないためです。
バルク・ロード対象の表の場合は、統計収集プロシージャをロード・プロセスの直後に、可
能であればバルク・ロードを実行するのと同じスクリプトまたはジョブの一部として、実行
する必要があります。
外部表の場合、GATHER_SCHEMA_STATS、GATHER_DATABASE_STATS および自動統計収集
処理中には統計は収集されません。ただし、GATHER_TABLE_STATS を使用すると外部表の
統計を個別に収集できます。外部表のサンプリングはサポートされていないため、
ESTIMATE_PERCENT オプションは明示的に NULL に設定する必要があります。外部表の
データ操作は許可されないため、対応するファイルに変更があったときに外部表を分析すれ
ば十分です。
STATISTICS_LEVEL を BASIC に設定して監視機能を無効にすると、自動統計収集では失効
している統計を検出できません。この場合は、統計を手動で収集する必要があります。自動
監視機能の詳細は、15-9 ページの「失効している統計の判別」を参照してください。
システム統計も、手動で収集する必要があります。この種の統計は自動的には収集されませ
ん。詳細は、15-10 ページの「システム統計」を参照してください。
動的パフォーマンス表など、固定オブジェクトの統計は、GATHER_FIXED_OBJECTS_
STATS プロシージャを使用して手動で収集する必要があります。固定オブジェクトには現行
のデータベース・アクティビティが記録されます。データベースに典型的なアクティビティ
があるときに統計を収集する必要があります。
前のバージョンの統計のリストア
ディクショナリ内で統計が変更されるたびに、後でリストアできるように前のバージョンの
統計が自動的に保存されます。統計をリストアするには、DBMS_STATS パッケージの
RESTORE プロシージャを使用します。詳細は、15-12 ページの「前のバージョンの統計のリ
ストア」を参照してください。
オプティマイザ統計の管理
15-5
手動統計収集
統計のロック
15-4 ページの「手動統計を使用する場合」で説明したように、揮発性の高い表など、表また
はスキーマに関して DBMS_STATS_JOB プロセスによる新規統計の収集を防止する必要があ
る場合があります。このような場合は、DBMS_STATS パッケージに表またはスキーマの統計
をロックするためのプロシージャが用意されています。詳細は、15-14 ページの「表統計ま
たはスキーマ統計のロック」を参照してください。
手動統計収集
自動統計収集を使用しないように選択した場合は、システム・スキーマを含め、すべてのス
キーマ内で統計を手動で収集する必要があります。データベース内のデータが定期的に変化
する場合は、統計がデータベース・オブジェクトの特性を正確に表すように、統計も定期的
に収集する必要があります。
DBMS_STATS プロシージャによる統計の収集
統計は DBMS_STATS パッケージを使用して収集されます。この PL/SQL パッケージは、統
計の変更、表示、エクスポート、インポートおよび削除にも使用されます。
注意 : オプティマイザ統計の収集に、ANALYZE 文で COMPUTE 句および
ESTIMATE 句を使用しないでください。これらの句は下位互換性のために
のみサポートされており、将来のリリースでは削除される可能性がありま
す。DBMS_STATS パッケージを使用するほうが、より広範囲で正確な統計
セットが効率的に収集されます。
オプティマイザ統計の収集に関係しない次のような用途には、引き続き
ANALYZE 文を使用できます。
■
VALIDATE または LIST CHAINED ROWS 句を使用する場合
■
空きリスト・ブロックの情報を収集する場合
DBMS_STATS パッケージでは、表と索引の統計、および表の列とパーティションの個別の統
計を収集できます。クラスタ統計は収集できません。ただし、DBMS_STATS を使用して、全
クラスタのかわりに個別の表の統計を収集できます。
表、列または索引の統計を生成するとき、分析したオブジェクトの統計がすでにデータ・
ディクショナリ内に収録されている場合、Oracle は既存の統計を更新します。古い統計は保
存され、後で必要に応じてリストアできます。15-12 ページの「前のバージョンの統計のリ
ストア」を参照してください。
15-6　Oracle Database パフォーマンス・チューニング・ガイド
手動統計収集
システム・スキーマの統計を収集する場合は、DBMS_STATS.GATHER_DICTIONARY_
STATS プロシージャを使用できます。このプロシージャでは、SYS や SYSTEM を含むすべて
のシステム・スキーマと、CTXSYS や DRSYS などの他のオプション・スキーマの統計が収
集されます。
データベース・オブジェクトの統計が更新されると、そのオブジェクトにアクセスする現在
解析済の SQL 文が無効にされます。文が次に実行されるときに、文が再解析され、オプティ
マイザは新しい統計に基づいて新しい実行計画を自動的に選択します。リモート・データ
ベース上で新しい統計を持つオブジェクトにアクセスする分散型の文は、無効にされませ
ん。新しい統計は、次回に SQL 文が解析されると有効になります。
表 15-1 は、DBMS_STATS パッケージにおけるデータベース・オブジェクトの統計収集のた
めのプロシージャです。
表 15-1 DBMS_STATS パッケージの統計収集プロシージャ
プロシージャ
収集対象
GATHER_INDEX_STATS
索引統計
GATHER_TABLE_STATS
表、列および索引の統計
GATHER_SCHEMA_STATS
スキーマ内のすべてのオブジェクトの統計
GATHER_DICTIONARY_STATS
すべてのディクショナリ・オブジェクトの
統計
GATHER_DATABASE_STATS
データベース内のすべてのオブジェクトの
統計
関連項目 : すべての DBMS_STATS プロシージャの構文と例については、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参
照してください。
前述のプロシージャを統計収集に使用する場合は、次のようにいくつか重要な考慮事項があ
ります。
■
サンプリングを使用した統計収集
■
パラレル統計収集
■
パーティション・オブジェクトの統計
■
列統計情報とヒストグラム
■
失効している統計の判別
■
ユーザー定義統計
オプティマイザ統計の管理
15-7
手動統計収集
サンプリングを使用した統計収集
統計収集操作では、サンプリングを使用して統計を予測できます。サンプリングは、統計収
集の重要なテクニックです。サンプリングを使用せずに統計を収集するには、全表スキャン
と表全体のソートが必要です。サンプリングを使用すると、統計収集に必要なリソースが最
小限に抑えられます。
サンプリングは、DBMS_STATS プロシージャの ESTIMATE_PERCENT 引数を使用して指定し
ます。サンプリング率は任意の値に設定できますが、必要な統計を正確に収集しながらパ
フォーマンスを最大限まで高めるために、DBMS_STATS 収集プロシージャの ESTIMATE_
PERCENT パラメータを DBMS_STATS.AUTO_SAMPLE_SIZE に設定することをお薦めします。
AUTO_SAMPLE_SIZE を使用すると、Oracle ではオブジェクトの統計優先順位に基づいて適
切な統計に必要な最適のサンプル・サイズが決定されます。統計のタイプごとに要件が異な
るため、実際に取得されるサンプルのサイズは、表、列または索引間で異なる場合がありま
す。たとえば、自動サンプリングで OE スキーマ内のすべての表に関する表統計および列統
計情報を収集するには、次のように使用できます。
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS('OE',DBMS_STATS.AUTO_SAMPLE_SIZE);
ESTIMATE_PERCENT パラメータを手動で指定すると、指定されたパーセントで生成された
サンプルの大きさが十分でない場合に、DBMS_STATS 収集プロシージャによりサンプリン
グ・パーセントが自動的に増やされます。これによって、見積り値の変動が少なくなり、安
定性が保証されます。
パラレル統計収集
統計の収集操作は、シリアルまたはパラレルのどちらでも実行できます。並列度は、DBMS_
STATS 収集プロシージャの DEGREE 引数で指定できます。パラレル統計収集はサンプリング
と併用できます。DEGREE パラメータを DBMS_STATS.AUTO_DEGREE に設定することをお薦
めします。このように設定すると、Oracle はオブジェクトのサイズとパラレル関連の init.ora
パラメータの設定に基づいて適切な並列度を選択できます。
クラスタ索引、ドメイン索引およびビットマップ結合索引など、特定のタイプの索引統計
は、パラレルでは収集されないことに注意してください。
パーティション・オブジェクトの統計
パーティション表および索引に対して、DBMS_STATS は、各パーティションの個別の統計を
収集できます。また、全表または全索引のグローバル統計も収集できます。コンポジット・
パーティションについても同様に、DBMS_STATS はサブパーティション、パーティション、
全表および全索引の個別の統計を収集できます。収集するパーティション統計のタイプは、
DBMS_STATS 収集プロシージャの GRANULARITY 引数で指定します。
最適化された SQL 文によっては、オプティマイザがパーティション（サブパーティション）
統計またはグローバル統計の使用を選択する場合があります。どちらのタイプの統計もほと
んどのアプリケーションにとって重要であり、GRANULARITY パラメータを AUTO に設定し
て両方のタイプのパーティション統計を収集することをお薦めします。
15-8　Oracle Database パフォーマンス・チューニング・ガイド
手動統計収集
列統計情報とヒストグラム
表の統計を収集する場合、DBMS_STATS では表内の列のデータ配分情報が収集されます。
データ配分に関して最も基本的な情報は、列の最大値と最小値です。ただし、列のデータに
偏りがある場合、このレベルの統計ではオプティマイザのニーズが十分に満たされない場合
があります。データ配分に偏りがある場合は、指定した列のデータ配分を記述するヒストグ
ラムも列統計の一部として作成できます。ヒストグラムの詳細は、15-19 ページの「ヒストグ
ラムの表示」を参照してください。
ヒストグラムは、DBMS_STATS 収集プロシージャの METHOD_OPT 引数を使用して指定しま
す。METHOD_OPT は FOR ALL COLUMNS SIZE AUTO に設定することをお薦めします。この設
定では、どの列にヒストグラムが必要であるかということと各ヒストグラムのバケット数
（サイズ）が、Oracle により自動的に判別されます。また、これらの情報は手動でも指定で
きます。
失効している統計の判別
データベースは時間の経過につれて変更されるため、その統計を定期的に収集する必要があ
ります。特定のデータベース・オブジェクトに新規データベース統計が必要かどうかを判別
するために、Oracle には表監視機能が用意されています。この監視機能は、STATISTICS_
LEVEL が TYPICAL または ALL に設定されている場合にデフォルトで有効になります。監視
では、最新の統計収集以降の、表に対する INSERT、UPDATE および DELETE の概数と、そ
の表が切り捨てられているかどうかを追跡します。表の変更情報は、USER_TAB_
MODIFICATIONS ビューで表示できます。データ変更後は、このビューに情報が伝播するま
でに数分の遅延が発生することがあります。メモリーに保存されている未処理の監視情報を
即時に反映させるには、DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO プロシー
ジャを使用します。
OPTIONS パラメータを GATHER STALE または GATHER AUTO に設定すると、GATHER_
DATABASE_STATS または GATHER_SCHEMA_STATS プロシージャは、統計が失効している
表に関して新規の統計を収集します。監視される表の変更が 10% を超えた場合、これらの
統計は失効したものとみなされ、再度収集されます。
ユーザー定義統計
ユーザー定義のオプティマイザ統計を作成して、ユーザー定義の索引およびファンクション
をサポートできます。統計タイプを列またはドメイン索引に対応付ける場合、データベー
ス・オブジェクトの統計が収集されるたびに、Oracle では統計タイプの統計コレクション・
メソッドがコールされます。
Oracle により式が表すのと同等の列統計情報を収集できるように、ファンクション索引の作
成後に表の新規列統計を収集する必要があります。そのためには、METHOD_OPT 引数を FOR
ALL HIDDEN COLUMNS に設定して統計収集プロシージャをコールします。
関連項目 : ユーザー定義統計の実装の詳細は、『Oracle Data Cartridge 開
発者ガイド』を参照してください。
オプティマイザ統計の管理
15-9
システム統計
統計を収集する時期
統計を手動で収集する場合は、その収集方法を決定するのみでなく、新規統計の収集時期と
頻度も決定する必要があります。
表の増分変更が行われるアプリケーションの場合は、新規の統計を週または月に 1 回収集す
るのみでよい場合があります。このような環境で最も簡単な統計収集方法は、スクリプトま
たはジョブ・スケジューリング・ツールを使用して、GATHER_SCHEMA_STATS および
GATHER_DATABASE_STATS プロシージャを定期的に実行することです。収集の頻度によっ
て、統計収集プロセスで起こるオーバーヘッドの処理に対し、オプティマイザの正確な統計
を出すタスクのバランスをとります。
バルク・ロードを使用する場合など、バッチ操作で逐次変更される表の場合は、その表の統
計をバッチ操作の一部として収集する必要があります。ロード操作の完了直後に DBMS_
STATS プロシージャをコールしてください。
パーティション表の場合、通常は 1 つのパーティションのみが変更されます。このような場
合は、表全体の統計を収集するのではなく、変更があったパーティションの統計のみを収集
できます。ただし、パーティション表のグローバル統計の収集も必要な場合があります。
関連項目 : DBMS_STATS パッケージの GATHER_SCHEMA_STATS および
GATHER_DATABASE_STATS プロシージャの詳細は、『PL/SQL パッケー
ジ・プロシージャおよびタイプ・リファレンス』を参照してください。
システム統計
システム統計は、問合せオプティマイザに対してシステムのハードウェア特性（I/O と CPU
のパフォーマンスおよび使用率など）を記述します。実行計画の選択時に、オプティマイザ
で各問合せに必要な I/O および CPU リソースが見積もられます。システム統計を使用する
と、問合せオプティマイザは I/O および CPU コストをより正確に見積もることができ、問
合せオプティマイザはより適切な実行計画を選択できます。
システム統計を収集する場合は、指定期間内のシステム・アクティビティが分析されます。
統計は、DBMS_STATS.GATHER_SYSTEM_STATS プロシージャを使用して収集されます。シ
ステム統計を収集することをお薦めします。
注意 : ディクショナリ・システム統計を更新するには、DBA 権限が必要
です。
表 15-2 に、DBMS_STATS パッケージにより収集されたオプティマイザのシステム統計と、
特定のシステム統計の収集または手動設定のオプションを示します。
15-10　Oracle Database パフォーマンス・チューニング・ガイド
システム統計
表 15-2 DBMS_STAT パッケージ内のオプティマイザのシステム統計
パラメータ名
説明
初期化
統計の収集または設定のオプション
cpuspeed
CPU 速度は、1 秒当たりの CPU 平 システム起動時
均サイクル数です。
gathering_mode = NOWORKLOAD、
INTERVAL または START|STOP に設定する
か、または統計を手動で設定します。
ioseektim
I/O シーク時間は、シーク時間、
待機時間および OS オーバーヘッ
ド時間を合計したものです。
システム起動時
gathering_mode = NOWORKLOAD に設定す
るか、または統計を手動で設定します。
iotfrspeed
I/O 転送速度は、1 回の読込み要求 システム起動時
で Oracle データベースがデータを
読み取ることができる速度です。
gathering_mode = NOWORKLOAD に設定す
るか、または統計を手動で設定します。
maxthr
最大 I/O スループットは、I/O サ
ブシステムが発揮できる最大ス
ループットです。
なし
gathering_mode = NOWORKLOAD、
INTERVAL または START|STOP に設定する
か、または統計を手動で設定します。
slavethr
スレーブ I/O スループットは、パ
ラレル・スレーブの平均 I/O ス
ループットです。
なし
gathering_mode = INTERVAL または
START|STOP に設定するか、または統計を手
動で設定します。
sreadtim
単一ブロック読込み時間は、単一
ブロックをランダムに読み込む平
均時間です。
なし
gathering_mode = INTERVAL または
START|STOP に設定するか、または統計を手
動で設定します。
mreadtim
マルチブロック読込みは、マルチ
ブロックを順に読み込む平均時間
です。
なし
gathering_mode = INTERVAL または
START|STOP に設定するか、または統計を手
動で設定します。
mbrc
マルチブロック・カウントは、平
均マルチブロック順次読込みカウ
ントです。
なし
gathering_mode = INTERVAL または
START|STOP に設定するか、または統計を手
動で設定します。
表、索引、列の統計とは異なり、システム統計の更新時には、すでに解析されている SQL
文は無効にされません。新しい SQL 文はすべて、新しい統計を使用して解析されます。
関連項目 : システム統計を実装するための DBMS_STATS パッケージのプ
ロシージャの詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・
リファレンス』を参照してください。
オプティマイザ統計の管理
15-11
統計の管理
統計の管理
この項では、次の内容を説明します。
■
前のバージョンの統計のリストア
■
統計のエクスポートとインポート
■
統計のリストアとインポートまたはエクスポートの相違点
■
表統計またはスキーマ統計のロック
■
統計の設定
■
統計の欠落の処理
前のバージョンの統計のリストア
ディクショナリ内で統計が変更されるたびに、後でリストアできるように前のバージョンの
統計が自動的に保存されます。統計をリストアするには、DBMS_STATS パッケージの
RESTORE プロシージャを使用します。これらのプロシージャは、引数としてタイムスタンプ
を使用し、そのタイムスタンプでの統計をリストアします。これは、新規に収集された統計
では不適切な実行計画が作成され、管理者が前の統計セットに戻す必要がある場合に役立ち
ます。
統計の変更時刻を表示するディクショナリ・ビューがあります。これらのビューは、統計の
リストアに使用するタイムスタンプを判断する場合に役立ちます。
■
■
カタログ・ビュー DBA_OPTSTAT_OPERATIONS には、DBMS_STATS を使用してスキー
マ・レベルとデータベース・レベルで実行された統計操作の履歴が含まれます。
*_TAB_STATS_HISTORY ビュー（ALL、DBA または USER）には、表統計の変更履歴が
含まれます。
古い統計は、統計履歴の保存設定とシステムの最終分析時刻に基づいて、定期的かつ自動的
に消去されます。保存期間は、DBMS_STATS の ALTER_STATS_HISTORY_RETENTION プロ
シージャを使用して構成可能です。デフォルト値は 31 日で、オプティマイザ統計を過去 31
日の任意の時点までリストアできることを意味します。
自動消去は、STATISTICS_LEVEL パラメータが TYPICAL または ALL に設定されている場
合に有効になります。自動消去が無効になっている場合は、PURGE_STATS プロシージャを
使用して古いバージョンの統計を手動で消去する必要があります。
統計のリストアおよび消去に関連する他の DBMS_STATS プロシージャは、次のとおりです。
■
■
PURGE_STATS: このプロシージャを使用すると、タイムスタンプを超える古いバージョ
ンを手動で消去できます。
GET_STATS_HISTORY_RENTENTION: このファンクションを使用すると、現行の統計履
歴の保存値を取得できます。
15-12　Oracle Database パフォーマンス・チューニング・ガイド
統計の管理
■
GET_STATS_HISTORY_AVAILABILTY: このファンクションを使用すると、統計履歴が
使用可能な最も古いタイムスタンプを取得できます。最も古いタイムスタンプより前の
タイムスタンプには、統計をリストアできません。
前のバージョンの統計をリストアする場合は、次の制限が適用されます。
■
■
RESTORE プロシージャでは、ユーザー定義統計はリストアできません。
統計の収集に ANALYZE コマンドが使用された場合、古いバージョンの統計は格納され
ません。
統計のエクスポートとインポート
統計をデータ・ディクショナリからエクスポートして、ユーザー所有の表にインポートでき
ます。これにより、同じスキーマについて複数バージョンの統計を作成できます。また、
データベース間で統計のコピーもできます。この操作により、統計を本番データベースから
小規模なテスト・データベースにコピーできます。
注意 : 統計のエクスポートとインポートは、データベースの EXP および
IMP ユーティリティとは異なる概念です。DBMS_STATS エクスポートおよ
びインポート・パッケージでは、IMP および EXP ダンプ・ファイルが使
用されます。
統計をエクスポートする前に、その統計を保持する表を作成する必要があります。この統計
表を作成するには、DBMS_STATS.CREATE_STAT_TABLE プロシージャを使用します。この
表の作成後に、DBMS_STATS.EXPORT_*_STATS プロシージャを使用して、データ・ディク
ショナリから統計表に統計をエクスポートできます。その後、DBMS_STATS.IMPORT_*_
STATS プロシージャを使用して統計をインポートします。
オプティマイザでは、ユーザー所有の表に格納されている統計が使用されないことに注意し
てください。オプティマイザで使用されるのは、データ・ディクショナリに格納されている
統計のみです。ユーザー所有の表内の統計をオプティマイザで使用するには、統計インポー
ト・プロシージャを使用して、その統計をデータ・ディクショナリにインポートする必要が
あります。
統計をデータベース間で移動するには、最初のデータベース上の統計をエクスポートしてか
ら、EXP および IMP ユーティリティまたは他のメカニズムを使用して統計表を第 2 のデー
タベースにコピーし、最後に統計を第 2 のデータベースにインポートする必要があります。
注意 : EXP および IMP ユーティリティは、データベースから表とともに
オプティマイザ統計をエクスポートおよびインポートします。ただし、表
にシステム生成名を持つ列が含まれている場合、統計はデータとともにエ
クスポートされません。
オプティマイザ統計の管理
15-13
統計の管理
統計のリストアとインポートまたはエクスポートの相違点
統計リストア機能は、ある面では統計のインポートおよびエクスポート機能に類似していま
す。通常、次の場合にはリストア機能を使用する必要があります。
■
■
統計の古いバージョンをリカバリする場合。たとえば、オプティマイザの動作を前の日
付までリストアする場合などです。
データベースで統計履歴の保存および消去を管理する場合。
次の場合には、EXPORT/IMPORT_*_STATS プロシージャを使用する必要があります。
■
■
■
複数の統計セットを試験的に使用して値を増減させる場合。
データベース間で統計を移動する場合。たとえば、本番システムからテスト・システム
に統計を移動する場合などです。
既知の統計セットを統計のリストアに必要な保存日数よりも長期的に保持する場合。
表統計またはスキーマ統計のロック
表またはスキーマの統計をロックできます。統計がロックされると、その統計はロックが解
除されるまで変更できなくなります。これらのロック・プロシージャは、統計が変化しない
ことを保証する必要のある静的環境に役立ちます。
DBMS_STATS パッケージには、統計をロックするための 2 つのプロシージャと、統計のロッ
クを解除するための 2 つのプロシージャが用意されています。
■
LOCK_SCHEMA_STATS
■
LOCK_TABLE_STATS
■
UNLOCK_SCHEMA_STATS
■
UNLOCK_TABLE_STATS
統計の設定
SET_*_STATISTICS プロシージャを使用して、表、列、索引およびシステムの統計を設定
できます。統計が不正確であったり一貫性がないとパフォーマンスが低下するため、この方
法での統計の設定はお薦めしません。
15-14　Oracle Database パフォーマンス・チューニング・ガイド
統計の管理
動的サンプリングを使用した統計の見積り
動的サンプリングの目的は、述語の選択性および表と索引に関する統計のより正確な見積り
を判断して、サーバーのパフォーマンスを改善することです。表と索引に関する統計には、
表ブロック・カウント、適用可能な索引ブロック・カウント、表のカーディナリティおよび
関連する結合列の統計が含まれます。正確に見積ると、より適切な実行計画がオプティマイ
ザで作成できます。
動的サンプリングを使用すると、次の作業が可能になります。
■
収集された統計が使用できない、あるいは見積りで重大なエラーを引き起こす可能性が
ある場合に、単一表の述語の選択性を見積ります。
■
表、および統計のない関連索引に対する統計を見積ります。
■
表、および統計が古すぎるために信頼できない関連索引に対する統計を見積ります。
この動的サンプリング機能は、OPTIMIZER_DYNAMIC_SAMPLING パラメータにより制御さ
れます。動的サンプリングにより必要な統計を自動的に収集するには、このパラメータを 2
以上の値に設定する必要があります。デフォルト値は 2 です。設定できるサンプリング・レ
ベルの詳細は、15-16 ページの「動的サンプリング・レベル」を参照してください。
動的サンプリングの動作
重要なパフォーマンス属性は、コンパイル時に決定されます。Oracle では、問合せで動的サ
ンプリングを使用する利点があるかどうか、コンパイル時に判別されます。利点がある場
合、再帰的 SQL 文が発行されて表のブロックの小さなランダム・サンプルがスキャンされ、
関連する単一表の述語を適用することで述語の選択性の見積りが行われます。サンプルした
カーディナリティが、表のカーディナリティの見積りに使用される場合もあります。関連す
る列統計情報と索引統計情報も収集されます。
OPTIMIZER_DYNAMIC_SAMPLING 初期化パラメータの値によって、動的サンプリングの問
合せで読み取られるブロック数が決定します。
関連項目 : この初期化パラメータの詳細は、『Oracle Database リファレ
ンス』を参照してください。
動的サンプリング使用のタイミング
通常、迅速に（数秒以内で）完了する問合せに対しては、動的サンプリングのコストが発生
するのは望ましくありません。しかし、次のいずれかの条件が当てはまる場合は、動的サン
プリングが有効です。
■
動的サンプリングを使用すると、より優れた計画になる場合。
■
サンプリングにかかる時間が、問合せの実行時間全体のごく一部である場合。
■
問合せが何度も実行される場合。
オプティマイザ統計の管理
15-15
統計の管理
動的サンプリングは、単一表の述語によるサブセットに適用したり、動的サンプリングが行
われていない述語の通常の選択性の見積りと組み合せることができます。
動的サンプリングを使用したパフォーマンスの改善方法
動的サンプリングは、OPTIMIZER_DYNAMIC_SAMPLING パラメータを使用して制御します。
このパラメータの値は、0 ～ 10 に設定できます。デフォルトは 2 です。
■
■
値が 0 の場合、動的サンプリングが行われません。
パラメータの値が大きくなるにつれて、サンプリングされる表（分析された表、あるい
は分析されていない表）のタイプについても、サンプリングで使用される I/O の量に関
しても、動的サンプリングがより積極的に適用されるようになります。
動的サンプリングは、サンプリング対象の表内で行が挿入、削除または更新されていない場
合、同じものが繰り返し使用されます。OPTIMIZER_FEATURES_ENABLE パラメータが 9.2.0
より前のリリースに設定されている場合、動的サンプリングはオフになります。
動的サンプリング・レベル
サンプリング・レベルは、使用された動的サンプリング・レベルがカーソル・ヒントまたは
OPTIMIZER_DYNAMIC_SAMPLING 初期化パラメータからの場合、次のようになります。
■
■
■
■
■
■
レベル 0: 動的サンプリングは使用しないでください。
レベル 1: 次の条件を満たす場合、すべての分析されていない表をサンプリングします。
（1）分析されていない表が問合せに少なくとも 1 つある場合。
（2）この分析されていな
い表が、別の表と結合、または副問合せかマージ不可能ビューにある場合。
（3）この分
析されていない表に索引がない場合。
（4）この分析されていない表に、この表の動的サ
ンプリングに使用されるブロックの数よりも多いブロックがある場合。サンプリングさ
れたブロック数は、動的サンプリングのブロックのデフォルト数です（32）
。
レベル 2: 動的サンプリングをすべての分析されていない表に適用します。サンプリング
されたブロック数は、動的サンプリングのブロックのデフォルト数の 2 倍です。
レベル 3: レベル 2 の基準を満たすすべての表と、標準の選択性の見積りで動的サンプリ
ングの可能性がある述語の推論が使用されるすべての表に、動的サンプリングを適用し
ます。サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数
です。分析されていない表の場合、サンプリングされたブロック数は、動的サンプリン
グのブロックのデフォルト数の 2 倍です。
レベル 4: 動的サンプリングをレベル 3 の基準を満たすすべての表、および 2 つ以上の列
を参照する単一表の述語を持つすべての表に適用します。サンプリングされたブロック
数は、動的サンプリングのブロックのデフォルト数です。分析されていない表の場合、
サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数の 2 倍
です。
レベル 5、6、7、8 および 9: それぞれ動的サンプリング・ブロックのデフォルトの数の
2、4、8、32 または 128 倍を使用して、動的サンプリングを直前レベルの基準を満たす
すべての表に適用します。
15-16　Oracle Database パフォーマンス・チューニング・ガイド
統計の管理
■
レベル 10: 表内のすべてのブロックを使用して、動的サンプリングをレベル 9 の基準を
満たすすべての表に適用します。
使用された動的サンプリング・レベルが表ヒントからである場合、サンプリング・レベルは
次のようになります。
■
■
■
■
レベル 0: 動的サンプリングは使用しないでください。
レベル 1: サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト
数です (32)。
レベル 2、3、4、5、6、7、8 および 9: サンプリングされたブロック数は、それぞれ動的
サンプリング・ブロックのデフォルト数の 2、4、8、16、32、64、128 または 256 倍で
す。
レベル 10: 表内のすべてのブロックを読み込みます。
関連項目 : DYNAMIC_SAMPLING ヒントを使用してサンプリング・レベ
ルを設定する方法については、17-46 ページの「DYNAMIC_SAMPLING」
を参照してください。
統計の欠落の処理
Oracle では、統計が欠落している表が検出されると、オプティマイザに必要な統計が動的に
収集されます。ただし、ある種の表の場合、動的サンプリングは実行されません。これには、
リモート表と外部表が含まれます。これらの場合および動的サンプリングが無効になってい
る場合、オプティマイザは統計にデフォルト値を使用します。表 15-3 および表 15-4 を参照
してください。
表 15-3 統計が欠落しているときの表のデフォルト値
表統計
オプティマイザによって使用されるデフォルト値
カーディナリティ
ブロック数×（ブロック・サイズ－キャッシュ層）÷行の平
均の長さ
行の平均長さ
100 バイト
ブロック数
100、またはエクステント・マップに基づく実際の値
リモート・カーディナリティ
2000 行
リモートの行の平均長さ
100 バイト
オプティマイザ統計の管理
15-17
統計の参照
表 15-4 統計が欠落しているときの索引のデフォルト値
索引統計
オプティマイザによって使用されるデフォルト値
レベル
1
リーフ・ブロック
25
リーフ・ブロック / キー
1
データ・ブロック / キー
1
個別キー
100
クラスタ化係数
800
統計の参照
この項では、次の内容を説明します。
■
表、索引および列の統計
■
ヒストグラムの表示
表、索引および列の統計
表、索引および列の統計は、データ・ディクショナリに格納されます。データ・ディクショ
ナリ内の統計を表示するには、適切なデータ・ディクショナリ・ビューを問い合せます
（USER、ALL または DBA）。次の DBA_* ビューがあります。
■
DBA_TABLES
■
DBA_OBJECT_TABLES
■
DBA_TAB_STATISTICS
■
DBA_TAB_COL_STATISTICS
■
DBA_TAB_HISTOGRAMS
■
DBA_INDEXES
■
DBA_IND_STATISTICS
■
DBA_CLUSTERS
■
DBA_TAB_PARTITIONS
■
DBA_TAB_SUBPARTITIONS
■
DBA_IND_PARTITIONS
■
DBA_IND_SUBPARTITIONS
15-18　Oracle Database パフォーマンス・チューニング・ガイド
統計の参照
■
DBA_PART_COL_STATISTICS
■
DBA_PART_HISTOGRAMS
■
DBA_SUBPART_COL_STATISTICS
■
DBA_SUBPART_HISTOGRAMS
関連項目 : これらのビューの統計の詳細は、『Oracle Database リファレ
ンス』を参照してください。
ヒストグラムの表示
列統計情報はヒストグラムとして格納できます。これらのヒストグラムは、列データの配分
の正確な見積りを提供します。ヒストグラムによって、データが偏っている場合の選択性の
見積りの精度が改善され、均一でないデータ配分が存在する最適な実行計画が得られます。
Oracle では、列統計情報に高さ調整済ヒストグラムと頻度ヒストグラムという 2 つのタイプ
が使用されます。ヒストグラムのタイプは、*TAB_COL_STATISTICS ビュー（USER および
DBA）の HISTOGRAM 列に格納されます。この列の値は、HEIGHT BALANCED、FREQUENCY
または NONE です。
高さ調整済ヒストグラム
高さ調整済ヒストグラムでは、列値が帯域に分割され、各帯域にほぼ同数の行が存在するよ
うになっています。したがって、ヒストグラムによって提示される有用な情報が存在するの
は、値範囲の終点が位置するところです。
値が 1 ～ 100 の間に存在し、ヒストグラムが 10 バケットである列 C について検討します。
C のデータ配分が均一な場合のヒストグラムは、図 15-1 のようになります。数字は終点の値
です。
図 15-1 データ配分が均一の高さ調整済ヒストグラム
各バケット内の行数は、表内の全行数の 10 分の 1 です。均一に分布しているこの例では、
4/10 の行の値が、60 ～ 100 の間にあります。
データ配分が均一でない場合のヒストグラムの例を図 15-2 に示します。
図 15-2 データ配分が非均一の高さ調整済ヒストグラム
オプティマイザ統計の管理
15-19
統計の参照
この場合、ほとんどの行で、この列の値が 5 になっています。60 ～ 100 の間の値を持ってい
る行は、行全体の 1/10 のみです。
高さ調整済ヒストグラムは、例 15-1 に示すように *TAB_HISTOGRAMS 表を使用して表示で
きます。
例 15-1 高さ調整済ヒストグラム統計の表示
BEGIN
DBMS_STATS.GATHER_table_STATS (OWNNAME => 'OE', TABNAME => 'INVENTORIES',
METHOD_OPT => 'FOR COLUMNS SIZE 10 quantity_on_hand');
END;
/
SELECT column_name, num_distinct, num_buckets, histogram
FROM USER_TAB_COL_STATISTICS
WHERE table_name = 'INVENTORIES' AND column_name = 'QUANTITY_ON_HAND';
COLUMN_NAME
NUM_DISTINCT NUM_BUCKETS HISTOGRAM
------------------------------ ------------ ----------- --------------QUANTITY_ON_HAND
237
10 HEIGHT BALANCED
SELECT endpoint_number, endpoint_value
FROM USER_HISTOGRAMS
WHERE table_name = 'INVENTORIES' and column_name = 'QUANTITY_ON_HAND'
ORDER BY endpoint_number;
ENDPOINT_NUMBER ENDPOINT_VALUE
--------------- -------------0
0
1
27
2
42
3
57
4
74
5
98
6
123
7
149
8
175
9
202
10
353
問合せ出力では、ヒストグラム内で 1 行が 1 つのバケットに対応します。
15-20　Oracle Database パフォーマンス・チューニング・ガイド
統計の参照
頻度ヒストグラム
頻度ヒストグラムでは、列の値がそれぞれヒストグラムの 1 つのバケットに対応します。各
バケットには、その単一値の発生数が含まれます。個別値の個数が、指定されたヒストグラ
ム・バケットの個数以下であれば、高さ調整済ヒストグラムのかわりに頻度ヒストグラムが
自動的に作成されます。頻度ヒストグラムは、例 15-2 に示すように *TAB_HISTOGRAMS 表
を使用して表示できます。
例 15-2 頻度ヒストグラム統計の表示
BEGIN
DBMS_STATS.GATHER_table_STATS (OWNNAME => 'OE', TABNAME => 'INVENTORIES',
METHOD_OPT => 'FOR COLUMNS SIZE 20 warehouse_id');
END;
/
SELECT column_name, num_distinct, num_buckets, histogram
FROM USER_TAB_COL_STATISTICS
WHERE table_name = 'INVENTORIES' AND column_name = 'WAREHOUSE_ID';
COLUMN_NAME
NUM_DISTINCT NUM_BUCKETS HISTOGRAM
------------------------------ ------------ ----------- --------------WAREHOUSE_ID
9
9 FREQUENCY
SELECT endpoint_number, endpoint_value
FROM USER_HISTOGRAMS
WHERE table_name = 'INVENTORIES' and column_name = 'WAREHOUSE_ID'
ORDER BY endpoint_number;
ENDPOINT_NUMBER ENDPOINT_VALUE
--------------- -------------36
1
213
2
261
3
370
4
484
5
692
6
798
7
984
8
1112
9
オプティマイザ統計の管理
15-21
統計の参照
15-22　Oracle Database パフォーマンス・チューニング・ガイド
16
索引およびクラスタの使用方法
この章では、索引およびクラスタを使用してパフォーマンスを強化できる、または低下させ
るデータ・アクセス方法の概要を説明します。
この章には次の項があります。
■
索引パフォーマンスについて
■
パフォーマンスを考慮したファンクション索引の使用方法
■
パフォーマンスを考慮したパーティション索引の使用方法
■
パフォーマンスを考慮した索引構成表の使用方法
■
パフォーマンスを考慮したビットマップ索引の使用方法
■
パフォーマンスを考慮したビットマップ結合索引の使用方法
■
パフォーマンスを考慮したドメイン索引の使用方法
■
パフォーマンスを考慮したクラスタの使用方法
■
パフォーマンスを考慮したハッシュ・クラスタの使用方法
索引およびクラスタの使用方法
16-1
索引パフォーマンスについて
索引パフォーマンスについて
この項では、次の項目について説明します。
■
論理構造のチューニング
■
SQL Access Advisor を使用した索引のチューニング
■
索引を付ける列と式の選択
■
コンポジット索引の選択
■
索引を使用する文の記述
■
索引を使用しない文の記述
■
索引の再作成
■
一意でない索引による一意性の規定
■
ENABLE NOVALIDATE 制約の使用方法
論理構造のチューニング
問合せの最適化は、問合せ実行におけるあまり有効ではない索引の使用を避けるために役立
ちますが、SQL エンジンは、表に対して定義されている索引が使用されているかどうかにか
かわらず、継続的にすべての索引をメンテナンスします。書込み集中型アプリケーションで
は、索引のメンテナンスに CPU と I/O リソースが大量に必要となる場合があります。した
がって、必要がなければ索引を作成しないでください。
最適なパフォーマンスを保つために、アプリケーションで使用していない索引を削除してく
ださい。使用されていない索引は、ALTER INDEX MONITORING USAGE 機能を典型的な負荷
を一定期間かけた後に使用することで検出できます。この監視機能は、索引が使用されたか
どうかを記録します。使用されていない索引が検出された場合は、削除してください。サン
プリングした負荷以外の負荷で使用されている索引を削除しないように、典型的な負荷を監
視していることを確認してください。
また、アプリケーション内では、文の実行計画の調査ですぐには明らかにならない索引の使
用方法もあります。その例が、共有ロックが子表上に取り出されないようにする親表上の外
部キー索引です。
関連項目 :
■
■
ALTER INDEX MONITORING USAGE 文の詳細は、『Oracle Database
SQL リファレンス』を参照してください。
外部キーの詳細は、
『Oracle Database アプリケーション開発者ガイド
- 基礎編』を参照してください。
16-2　Oracle Database パフォーマンス・チューニング・ガイド
索引パフォーマンスについて
また、新しい索引を作成して SQL 文をチューニングするかどうかを決める場合、オプティ
マイザがアプリケーションの実行時にこれらの索引を使用するかどうかを判断するために、
EXPLAIN PLAN 文を使用することもできます。新しい索引を作成して現在解析中の文を
チューニングする場合は、Oracle はその文を無効にします。
その文が次に解析されるとき、オプティマイザは、新しい索引を使用する可能性のある新し
い実行計画を自動的に選択します。新しい索引をリモート・データベース上に作成して分散
型の文をチューニングする場合は、その文が次に解析されるとき、オプティマイザがこれら
の索引について検討します。
索引を作成してある文をチューニングした場合、他の文の実行計画に対するオプティマイザ
の選択に影響を及ぼす場合があるので注意してください。たとえば、ある文によって使用さ
れる索引を作成した場合、オプティマイザは、アプリケーションの他の文に対しても、その
索引の使用を選択する場合があります。このため、最初にチューニング対象と判断した文を
チューニングした後、アプリケーションのパフォーマンスおよび実行計画を再検査し、SQL
トレース機能を利用します。
SQL Access Advisor を使用した索引のチューニング
SQL Access Advisor は、どの索引が必要であるかを手動で判別する作業に対する代替機能で
す。このアドバイザを Oracle Enterprise Manager の「
「Advisor Central」
」から起動するか、
DBMS_ADVISOR パッケージ API を介して実行すると、索引セットを推奨します。SQL
Access Advisor はワークロードの使用を推奨するか、または指定のスキーマに関する仮定的
なワークロードを生成します。SQL キャッシュの現在の内容、ユーザー定義の SQL 文セッ
トまたは SQL Tuning Set など、様々なワークロード・ソースが使用可能です。SQL Access
Advisor により指定のワークロードに関して推奨事項のセットを生成され、その中から実装
する索引を選択できます。実装スクリプトが用意されており、手動で実行するか、または
Oracle Enterprise Manager を介して自動的に実行できます。
関連項目 : SQL Access Advisor の詳細は、『Oracle データ・ウェアハウ
ス・ガイド』を参照してください。
索引を付ける列と式の選択
キーは、索引を付ける列または式です。次のガイドラインに従って、索引を付けるキーを選
択します。
■
■
■
WHERE 句で頻繁に使用されるキーに索引を付けることを検討します。
SQL 文で表を結合するために頻繁に使用されるキーに索引を付けることを検討します。
結合の最適化に関する詳細は、16-15 ページの「パフォーマンスを考慮したハッシュ・
クラスタの使用方法」を参照してください。
高度な選択性の索引キーを選択します。索引の選択性は、索引を付けるキーについて同
じ値を持つ行の表内での割合です。同じ値を持つ行がほとんどない場合、索引の選択性
は最適です。
索引およびクラスタの使用方法
16-3
索引パフォーマンスについて
注意 : Oracle では、整合性制約を使用して定義されるすべての一意キー
および主キーのキーと式に、暗黙に索引を作成するか、既存の索引を使用
します。
選択性の低い列への索引付けは、データ配分が偏っているために、1 つまたは 2 つの値
がその他の値よりはるかに使用頻度が低い場合に便利です。
■
■
■
■
■
個別値をほとんど持たないキーまたは式には標準の B ツリー索引は使用しません。通常
そのようなキーや式は選択性が劣っているので、頻繁に選択されるキー値がその他の
キー値に比べて少ない場合を除くと、パフォーマンスは最適化されません。このような
場合には、ビットマップ索引を使用すると効果的です。ただし、同時実行性の高い
OLTP アプリケーションのように、索引が頻繁に変更される場合には向きません。
頻繁に修正される列には索引を付けません。索引付きの列を修正する UPDATE 文および
索引付きの表を修正する INSERT 文と DELETE 文では、索引がない場合よりも、処理に
長い時間が必要となります。このような SQL 文は、表のデータのみでなく、索引の
データも修正する必要があります。また、取消しと再実行も追加的に生成されます。
関数や演算子を含む WHERE 句のみに指定されるキーには索引を付けません。索引付きの
キーに MIN や MAX 以外の関数や演算子を使用する WHERE 句は、ファンクション索引を
除く索引を使用するアクセス・パスを選択しません。
同時実行の数多くの INSERT 文および UPDATE 文、DELETE 文が親表と子表をアクセス
する場合、参照整合性制約の外部キーに索引を付けることを検討します。このような索
引を使用すると、子表を共有ロックせずに親表で UPDATE および DELETE を実行できま
す。
索引を付けるキーを選択するとき、問合せのパフォーマンス向上が、INSERT、
UPDATE、DELETE のパフォーマンス損失および索引を格納するために必要となる領域
の使用に見合う価値があるかどうか検討してください。SQL 文の処理時間を索引の有無
によって実際に比較することをお薦めします。SQL トレース機能で処理時間を測定でき
ます。
関連項目 : ロックへの外部キーの影響の詳細は、
『Oracle Database アプ
リケーション開発者ガイド - 基礎編』を参照してください。
16-4　Oracle Database パフォーマンス・チューニング・ガイド
索引パフォーマンスについて
コンポジット索引の選択
コンポジット索引には複数のキー列が含まれています。コンポジット索引には、次のような
単一列索引を上回る利点があります。
■
選択性の向上
場合によっては、それぞれの選択性が劣る複数の列や式を組み合せてコンポジット索引
にすると、より高い選択性を得ることができます。
■
I/O の削減
問合せによって選択される列がすべてコンポジット索引に含まれている場合、Oracle
は、表にアクセスすることなく、索引からこれらの値を戻すことができます。
SQL 文にコンポジット索引の先頭部分を利用する条件が含まれていれば、その文はコンポ
ジット索引に関係するアクセス・パスを使用します。
注意 : このことは、索引スキップ・スキャンには現在、該当しなくなっ
ています。14-24 ページの「索引スキップ・スキャン」を参照してくださ
い。
索引の先頭部分とは、その索引を作成した CREATE INDEX 文で列リストの先頭から連続的
に指定された 1 つ以上の列の組合せのことです。次の CREATE INDEX 文を例とします。
CREATE INDEX comp_ind
ON table1(x, y, z);
■
x、xy、xyz の各列の組合せは、索引の先頭部分です。
■
yz、y、z の各列の組合せは索引の先頭部分ではありません。
コンポジット索引のキーの選択
コンポジット索引を構成するキーを選択するために、次のガイドラインに従ってください。
■
■
WHERE 句の条件で、頻繁に AND 演算子で結合して使用されるキー・セットに対して、コ
ンポジット索引を作成することを検討します。特に結合したときの選択性が個々のキー
の選択性よりも優れている場合、コンポジット索引を作成してください。
複数の問合せが 1 つ以上のキー値に基づいて同じキー・セットを選択する場合、これら
のキーのすべてを含むコンポジット索引を作成することを検討します。
もちろん、索引を作成するときの、一般的なパフォーマンスの利点およびトレードオフに関
する前述のガイドラインを検討してください。
索引およびクラスタの使用方法
16-5
索引パフォーマンスについて
コンポジット索引のキーの順序付け
コンポジット索引内でのキーの順序を指定するために次のガイドラインに従ってください。
■
■
■
WHERE 句で使用されるキーが先頭部分を構成するように、索引を作成してください。
一部のキーが WHERE 句で使用される頻度が高い場合には、頻繁に選択されるキーが先頭
部分を構成するように索引を作成し、これらのキーのみを使用する文が索引を使用でき
るようにしてください。
すべてのキーが WHERE 句で使用される頻度が同程度で、そのキーの 1 つでデータが物理
的に順序付けられている場合には、そのキーをコンポジット索引の先頭にしてくださ
い。
索引を使用する文の記述
索引を作成しても、単に索引が存在するのみでは、オプティマイザはその索引を使用するア
クセス・パスを選択できません。オプティマイザは、SQL 文にアクセス・パスを使用可能に
する構造が含まれている場合にかぎり、そのようなアクセス・パスを選択できます。索引ア
クセス・パスを使用するというオプションを問合せオプティマイザで可能にするには、文が
索引アクセス・パスを使用可能にする構文になっていることを確認してください。
索引を使用しない文の記述
場合によっては、既存の索引を使用するアクセス・パスを SQL 文で使用しないことも可能
です。索引の選択性があまり優れておらず、全表スキャンの方が効率的であることがわかっ
ている場合がそうです。そのような索引アクセス・パスを使用可能にする条件が文に含まれ
ている場合は、次に示す方法の 1 つを使用して、オプティマイザに全表スキャンを使用する
ように強制できます。
■
■
■
NO_INDEX ヒントを使用して特定索引の使用を禁止にし、問合せオプティマイザに最大
限の柔軟性を持たせることができます。
FULL ヒントを使用して、オプティマイザに索引スキャンのかわりに全表スキャンを選
択するように強制します。
INDEX ヒントまたは INDEX_COMBINE ヒントを使用して、オプティマイザに、ある索引
（またはリストされている索引セット）を別の索引（または索引セット）のかわりに使
用するように強制します。
関連項目 : NO_INDEX、FULL、INDEX、INDEX_COMBINE および AND_
EQUAL の各ヒントに関する詳細は、第 17 章「オプティマイザ・ヒント」
を参照してください。
パラレル実行は、索引を効果的に利用します。このオプションはパラレル索引レンジ・ス
キャンは実行しませんが、ネステッド・ループ結合を実行するためにパラレル索引参照を実
行します。索引の選択性が高い（各索引エントリの行数が少ない）場合は、パラレル表ス
キャンよりも順次索引参照を使用することをお薦めします。
16-6　Oracle Database パフォーマンス・チューニング・ガイド
索引パフォーマンスについて
索引の再作成
索引を縮小し分断化された領域を最小化するため、または索引の記憶特性を変更するために
索引を再作成する場合があります。既存の索引のサブセットとなる新しい索引を作成すると
き、または既存の索引を新しい記憶特性で再構築するとき、Oracle は、実表ではなく既存の
索引を使用して索引作成のパフォーマンスを向上させる場合があります。
注意 : 索引の作成または再作成の後で DBMS_STATS をコールしないよう
に、CREATE または REBUILD に、COMPUTE STATISTICS 文を含めてくだ
さい。
ただし、既存の索引よりも実表を使用した方が効果的な場合もあります。多くの DML が実
行された表の索引を考えてみてください。DML のために索引のサイズが大きくなり、各ブ
ロックが 50% 以下しか満たされなくなる場合があります。索引が表のほとんどの列を参照
している場合、索引が表よりも大きくなりかねません。その場合は、索引よりも実表を使用
した方が、索引の再作成が速くできます。
ALTER INDEX ... REBUILD 文は、既存の索引を再編成または縮小するため、または既存の索
引の記憶特性を変更するために使用します。REBUILD 文は、新しい索引の基礎として既存
の索引を使用します。STORAGE（エクステントの割当て用）、TABLESPACE（索引を新しい
表領域に移動する）および INITRANS（エントリの最初の数を変更する）などのすべての索
引記憶用の文がサポートされています。
ALTER INDEX ...REBUILD は、高速全スキャン機能を使用するので、通常は索引を削除して
再作成するよりも高速です。この文は、マルチブロック I/O を使用して索引ブロックをすべ
て読み込んでから、ブランチ・ブロックを廃棄します。さらに、このアプローチには、再作
成の実行中の問合せには、旧索引を利用できるという利点があります。
関連項目 : CREATE INDEX 文と ALTER INDEX 文の詳細および索引の再
作成の制限の詳細は、
『Oracle Database SQL リファレンス』を参照してく
ださい。
索引の縮小
COALESCE オプションを持つ ALTER INDEX 文を使用して索引のリーフ・ブロックを結合で
きます。このオプションでは、索引のリーフ・レベルを結合して空きブロックにし、再利用
できます。また、索引をオンラインで再作成することもできます。
関連項目 : この文の構文の詳細は、『Oracle Database SQL リファレンス』
および『Oracle Database 管理者ガイド』を参照してください。
索引およびクラスタの使用方法
16-7
索引パフォーマンスについて
一意でない索引による一意性の規定
UNIQUE 制約、または PRIMARY KEY 制約の一意性の側面に関して、一意性を規定するため
に、表の既存の一意でない索引を使用できます。このアプローチの利点は、制約が使用禁止
にされているときでも索引が使用可能であり、妥当であるということです。したがって、使
用禁止にされている UNIQUE 制約または PRIMARY KEY 制約を使用可能にするために、その
制約に対応付けられている UNIQUE 索引を再作成する必要はありません。これにより、大
規模表で操作を使用可能にする際に時間を大幅に節約できます。
さらに、一意でない索引を使用して一意性を規定すると、索引の重複を排除できます。主
キー列がすでにコンポジット索引の同一キーとして組み込まれている場合、その列に対する
一意索引は不要です。Oracle では、制約を使用可能または規定するときに、既存の索引を使
用できます。索引を複製しないので、領域を大幅に節約できます。ただし、既存の索引が
パーティション化されている場合は、索引のパーティション・キーも UNIQUE キーのサブ
セットである必要があります。サブセットでなければ、Oracle はさらに一意索引を追加作成
し、制約を規定します。
ENABLE NOVALIDATE 制約の使用方法
ENABLE NOVALIDATE 制約は、新しいデータの ENABLE VALIDATE 制約と同じように動
作します。制約を ENABLE NOVALIDATE 状態にすることは、表に入力された新規データ
が制約に準拠する必要があることを意味します。既存のデータはチェックされません。制約
を ENABLE NOVALIDATE 状態にすることにより、表をロックしないで制約を使用可能に
できます。
制約を使用禁止から使用可能に変更する場合、表をロックする必要があります。使用可能化
操作の間に表の操作が制約に準拠していることを保証する機能がないため、新たに DML、
問合せまたは DDL を実行できません。ENABLE NOVALIDATE 状態では、制約に違反する
操作は表に対して実行されません。
表のパラレル一貫読込み問合せによって ENABLE NOVALIDATE 制約を検査済にすること
で、制約に違反するデータがあるかどうかを判断できます。ロックは実行されず、使用可能
化操作は表に対する読込み機能または書込み機能をブロックしません。さらに、ENABLE
NOVALIDATE 制約はパラレルで検査済にすることができます。複数の制約を同時に検査済
にし、パラレル問合せを使用して各制約の妥当性チェックを実行できます。
制約と索引を持つ表を作成するアプローチは次のとおりです。
1.
制約を持つ表を作成します。NOT NULL 制約には名前を付けなくても構いませんが、検
査済使用可能で作成してください。その他の制約（CHECK、UNIQUE、PRIMARY KEY お
よび FOREIGN KEY）にはすべて名前を付け、使用禁止で作成します。
注意 :
デフォルトでは、制約は ENABLED 状態で作成されます。
16-8　Oracle Database パフォーマンス・チューニング・ガイド
索引パフォーマンスについて
2.
旧データを表にロードします。
3.
制約に必要な索引を含め、すべての索引を作成します。
4.
未検査の制約をすべて使用可能にします。これは、外部キーの前に主キーに対して行っ
てください。
5.
ユーザーがデータを問合せおよび変更できるようにします。
6.
制約ごとに個別の ALTER TABLE 文を使用して、すべての制約を検査します。これは、
外部キーの前に主キーに対して行ってください。次に例を示します。
CREATE TABLE t (a NUMBER CONSTRAINT apk PRIMARY KEY DISABLE,
b NUMBER NOT NULL);
CREATE TABLE x (c NUMBER CONSTRAINT afk REFERENCES t DISABLE);
ここで、インポートまたは高速ローダーを使用してデータを表 t にロードします。
CREATE UNIQUE INDEX tai ON t (a);
CREATE INDEX tci ON x (c);
ALTER TABLE t MODIFY CONSTRAINT apk ENABLE NOVALIDATE;
ALTER TABLE x MODIFY CONSTRAINT afk ENABLE NOVALIDATE;
この時点で、ユーザーは、表 t で INSERT、UPDATE、DELETE および SELECT を実行
できます。
ALTER TABLE t ENABLE CONSTRAINT apk;
ALTER TABLE x ENABLE CONSTRAINT afk;
これで、制約は ENABLE VALIDATE になりました。
関連項目 :
ださい。
整合性制約の詳細は、『Oracle Database 概要』を参照してく
索引およびクラスタの使用方法
16-9
パフォーマンスを考慮したファンクション索引の使用方法
パフォーマンスを考慮したファンクション索引の使用方法
ファンクション索引には、関数（たとえば、UPPER 関数）で変換される列、または式（たと
えば、col1 + col2）に含まれている列が含まれています。ファンクション索引により、索
引で計算集中型の式を保存できます。
変換された列または式でファンクション索引を定義すると、その関数または式を WHERE 句
または ORDER BY 句で使用するとき、その索引を使用してデータを戻すことができます。こ
れにより、Oracle は、SELECT 文および DELETE 文を処理する際に式の値の計算をバイパス
できます。したがって、ファンクション索引は、頻繁に実行される SQL 文の WHERE 句また
は ORDER BY 句の中に変換列（または式の中の列）が含まれているときに有益です。
Oracle では、降順の索引は、ファンクション索引として処理されます。DESC のマークのあ
る列は、降順でソートされます。
たとえば、UPPER（column_name）キーワードまたは LOWER（column_name）キーワー
ドで定義されたファンクション索引を使用すると、大小文字を区別しない検索ができます。
次の文で索引を作成します。
CREATE INDEX uppercase_idx ON employees (UPPER(last_name));
これを使用すると、次のような問合せの処理が容易になります。
SELECT * FROM employees
WHERE UPPER(last_name) = 'MARKSON';
関連項目 :
■
■
ファンクション索引の使用の詳細は、
『Oracle Database アプリケー
ション開発者ガイド - 基礎編』および『Oracle Database 管理者ガイ
ド』を参照してください。
CREATE INDEX 文の詳細は、
『Oracle Database SQL リファレンス』を
参照してください。
16-10　Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスを考慮したパーティション索引の使用方法
パフォーマンスを考慮したパーティション索引の使用方法
パーティション表と同様に、パーティション索引を使用すると、管理可能性、可用性、パ
フォーマンスおよび拡張性が向上します。パーティション索引は、個別にパーティション化
するか（グローバル索引）
、または表のパーティション・メソッドに自動的にリンクできま
す（ローカル索引）
。
Oracle では、レンジ・パーティション化およびハッシュ・パーティション化されたグローバ
ル索引をどちらもサポートしています。レンジ・パーティション化されたグローバル索引で
は、各索引パーティションに、パーティション・バウンドで定義された値が含まれます。
ハッシュ・パーティション化されたグローバル索引では、各パーティションに、Oracle の
ハッシュ関数により決定された値が含まれます。
マルチユーザーの OLTP 環境で、索引内の少数のリーフ・ブロックに競合が多い場合、ハッ
シュ・メソッドにより索引のパフォーマンスが向上します。OLTP アプリケーションによっ
ては、索引の右端にのみ索引が挿入される場合があります。これは、単調に増える列につい
て索引が定義されている場合に行われます。このような場合、索引ページ、バッファ、更新
のラッチ、および追加索引メンテナンス・アクティビティの競合により、索引の右端がホッ
トスポットとなり、パフォーマンスが低下します。
ハッシュ・パーティション化されたグローバル索引では、索引エントリはパーティション・
キーおよびパーティション数に基づいて異なるパーティションにハッシュされます。これに
より、定義済のパーティション数全体に競合が拡散され、スループットが向上します。ハッ
シュ・パーティション化されたグローバル索引を使用すると、バッファ・ラッチの競合が複
数のパーティションにわたって拡散されるため、大規模 PDML として大きなファクト表に
実行される TPC-H リフレッシュ関数には有効です。
ハッシュ・パーティション化では、索引エントリは Oracle で生成されたハッシュ値に基づ
いて特定の索引パーティションにマップされます。ハッシュ・パーティション化されたグ
ローバル索引を作成するための構文は、ハッシュ・パーティション表と非常によく似ていま
す。索引パーティション・キーについての等価述語および IN 述語を伴う問合せでは、グ
ローバル・ハッシュ・パーティション索引を効率的に使用して問合せにすばやく回答できま
す。
関連項目 : グローバル索引表の詳細は、『Oracle Database 概要』および
『Oracle Database 管理者ガイド』を参照してください。
索引およびクラスタの使用方法
16-11
パフォーマンスを考慮した索引構成表の使用方法
パフォーマンスを考慮した索引構成表の使用方法
索引構成表は、表のデータが、対応付けられた索引に保持されるという点で普通の表とは異
なります。新しい行の追加、行の更新、行の削除など、表データを変更すると、索引のみが
更新されます。データ行は索引に格納されるため、索引構成表では完全一致、範囲検索また
はその両方を含む問合せの表データに対するさらに高速なキー・ベースのアクセスが可能に
なります。
グローバル・ハッシュ・パーティション索引は索引構成表でサポートされており、マルチ
ユーザーの OLTP 環境でパフォーマンスが向上します。
関連項目 : 索引構成表の詳細は、『Oracle Database 概要』および
『Oracle Database 管理者ガイド』を参照してください。
パフォーマンスを考慮したビットマップ索引の使用方法
ビットマップ索引は、次のすべての特性を持つ問合せのパフォーマンスを大幅に向上できま
す。
■
■
■
■
カーディナリティが低いか中位である列に関する述語が WHERE 句に複数含まれていま
す。
カーディナリティが低いか中位である列に関する個々の述語が大量の行を選択していま
す。
カーディナリティが低いか中位である列の一部または全部に対して、問合せで使用され
るビットマップ索引が作成されています。
問合せの表に多数の行が含まれています。
複数のビットマップ索引を使用して、単独の表に対する条件を評価できます。このため、
ビットマップ索引は、長い WHERE 句を含む複合非定型問合せにとって非常に有効です。
ビットマップ索引は、集合問合せでもスター・スキーマでの結合の最適化でも最適なパ
フォーマンスを提供します。
関連項目 : ビットマップ索引の詳細は、『Oracle Database 概要』および
『Oracle データ・ウェアハウス・ガイド』を参照してください。
16-12　Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスを考慮したドメイン索引の使用方法
パフォーマンスを考慮したビットマップ結合索引の使用方法
単一表のビットマップ索引に加えて、ビットマップ結合索引を作成できます。このビット
マップ結合索引は、複数の表を結合するためのビットマップ索引です。ビットマップ結合索
引は、事前の制限事項の実行により結合される必要のあるデータ量を削減するためにスペー
スを節約するよい方法です。ビットマップ結合索引は、表の列の値ごとに、別の表の対応す
る行の ROWID を格納します。データ・ウェアハウス環境では、結合条件は、ディメンショ
ン表の主キー列、およびファクト表の外部キー列との間の等価内部結合です。
ビットマップ結合索引は、マテリアライズド結合ビューより格納の効率がはるかによく、事
前に結合をマテリアライズする方法の代替手段です。これは、マテリアライズド結合ビュー
がファクト表の ROWID を圧縮しないためです。
関連項目 : ビットマップ結合索引の例および制限については、『Oracle
データ・ウェアハウス・ガイド』を参照してください。
パフォーマンスを考慮したドメイン索引の使用方法
ドメイン索引は、ユーザー定義の索引タイプで指定された索引作成論理で作成されます。索
引タイプを使用すると、特定の演算子の述部に合うデータに効率よくアクセスできます。通
常、ユーザー定義の索引タイプは、Spatial オプションと同様 Oracle のオプションの一部で
す。たとえば、SpatialIndextype を使用すると、ある条件ボックスにオーバーラップす
る Spatial データを効率よく取り出せます。
ドメイン索引の作成と保守で指定できるパラメータは、カートリッジによって異なります。
同様に、ドメイン索引のパフォーマンスと記憶域の特性は、カートリッジ固有のマニュアル
を参照してください。
次の情報は、適切なカートリッジ・マニュアルを参照してください。
■
索引付けできるデータ型
■
使用できる索引タイプ
■
索引タイプで使用できる演算子
■
ドメイン索引を作成およびメンテナンスする方法
■
問合せで演算子を効率よく使用する方法
■
パフォーマンス特性の内容
注意 :
索引の型は CREATE INDEXTYPE 文でも作成できます。
関連項目 : SpatialIndextype の詳細は、『Oracle Spatial ユーザーズ・
ガイドおよびリファレンス』を参照してください。
索引およびクラスタの使用方法
16-13
パフォーマンスを考慮したクラスタの使用方法
パフォーマンスを考慮したクラスタの使用方法
クラスタとは、物理的にまとめて格納される 1 つ以上の表のグループです。それらの表は、
共通の列を共有しており、通常、一緒に使用されるため、まとめて格納されます。関連する
行が物理的にまとめて格納されているため、ディスク・アクセス時間が短縮されます。
クラスタを作成するには、CREATE CLUSTER コマンドを使用します。
関連項目 :
さい。
クラスタの詳細は、『Oracle Database 概要』を参照してくだ
表をクラスタ化するかどうかを判断するために、次のガイドラインに従ってください。
■
■
■
■
■
■
■
アプリケーションが結合処理で頻繁にアクセスする表をクラスタ化します。
アプリケーションが表の結合を頻繁には行わない場合、または共通の列の値を頻繁に修
正する場合、それらの表はクラスタ化しません。表をクラスタ化した場合、Oracle は修
正された行を別のブロックへ移行して、クラスタをメンテナンスする必要もあります。
このため、非クラスタ化表の値を修正する場合よりも、行のクラスタ・キー値を修正す
る場合の処理時間は長くなる可能性があります。
アプリケーションが複数の表の 1 つについてのみ頻繁に全表スキャンを行う場合、それ
らの表はクラスタ化しません。クラスタ化表の全表スキャンに要する処理時間は、非ク
ラスタ化表の全表スキャンよりも長くなる可能性があります。複数の表があわせて格納
されているため、Oracle が読み込む必要のあるブロックは多くなります。
マスター・レコードを選択してからディテール・レコードを選択することがよくある場
合、マスター / ディテール表をクラスタ化します。ディテール・レコードはマスター・
レコードと同じデータ・ブロックに格納されるため、選択時にそれらがメモリー内に存
在している可能性が高くなり、Oracle による I/O 処理が少なくなる場合があります。
同じマスターについて多くのディテール・レコードを選択することがよくある場合、
ディテール表のみをクラスタに格納します。このようにすれば、同じマスターについて
多くの詳細レコードを選択する問合せのパフォーマンスが改善され、マスター表に対す
る全表スキャンのパフォーマンスも低下させずに済みます。別の方法として、索引構成
表を使用する方法があります。
同じクラスタ・キー値を持つすべての表からのデータが、1 つまたは 2 つの Oracle ブ
ロックを超える場合、それらの表はクラスタ化しません。クラスタ化表の行をアクセス
する場合、Oracle はその値を持つ行を含んでいるブロックをすべて読み込みます。これ
らの行が複数のブロックを使用している場合、単一行をアクセスすることによって、非
クラスタ化表で同じ行をアクセスする場合よりも多くの読込み処理が必要になる場合が
あります。
各クラスタ・キー値の行数が大きく異なっている場合は表をクラスタ化しないてくださ
い。クラスタ化した場合、カーディナリティの低いキー値の場合には領域が無駄にな
り、カーディナリティの高いキー値の場合には衝突が発生します。衝突が発生するとパ
フォーマンスが下がります。
16-14　Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスを考慮したハッシュ・クラスタの使用方法
アプリケーションのニーズに応じて、クラスタの長所と短所を検討してください。たとえ
ば、結合文のパフォーマンス向上が、クラスタ・キー値を修正する文のパフォーマンス低下
を上回る場合もあります。表をクラスタ化した場合と別々に格納した場合について実験し
て、処理時間を比較してください。
関連項目 : クラスタの詳細は、
『Oracle Database 管理者ガイド』を参照
してください。
パフォーマンスを考慮したハッシュ・クラスタの使用方法
ハッシュ・クラスタは、ハッシュ関数をそれぞれの行のクラスタ・キー値に適用することに
よって、表データをグループ分けします。同じクラスタ・キー値を持つすべての行が、ディ
スク上にまとめて格納されます。アプリケーションのニーズに応じて、ハッシュ・クラスタ
の長所と短所を検討してください。特定の表をハッシュ・クラスタに格納する場合と、索引
付きで単独に格納する場合を実験して、処理時間を比較してください。
ハッシュ・クラスタを使用する場合を判断するために、次のガイドラインに従ってくださ
い。
■
■
■
■
■
同じ列または列の組合せを使用する等価条件が WHERE 句に含まれる場合、WHERE 句を
持つ SQL 文により頻繁にアクセスされる表を格納するために、ハッシュ・クラスタが
使用されます。この列または列の組合せをクラスタ・キーとして指定します。
将来挿入する行およびすぐに挿入する行を含めて、特定のクラスタ・キー値を持つすべ
ての行を保持するために必要な領域を判断できる場合、ハッシュ・クラスタに表を格納
します。
ハッシュ関数の各値に対応する行が特定の列において昇順でソートされる場合、ソート
されたクラスタ・データを操作することで応答時間を改善できるのであれば、ソートさ
れたハッシュ・クラスタを使用します。
アプリケーションが全表スキャンを実行する場合が多く、表が拡大することを見越して
ハッシュ・クラスタに大きな領域を割り当てる必要がある場合は、その表をハッシュ・
クラスタに格納しません。そのような全表スキャンでは、いくつかのブロックにはほと
んど行が含まれていなくても、ハッシュ・クラスタに割り当てられているブロックをす
べて読み込む必要があります。表を単独で格納することによって、全表スキャンにより
読み込まれるブロック数が減少します。
アプリケーションがクラスタ・キー値を頻繁に修正する場合、ハッシュ・クラスタに表
は格納しません。表をクラスタ化した場合、Oracle は修正された行を別のブロックへ移
行して、クラスタをメンテナンスする必要もあります。このため、非クラスタ化表の値
を修正する場合よりも、行のクラスタ・キー値を修正する場合の処理時間は長くなる可
能性があります。
前述の考慮事項に基づいてハッシングが適切であるかぎり、他の表と頻繁に結合されるかど
うかにかかわらず、単一の表をハッシュ・クラスタに格納することは有益です。
索引およびクラスタの使用方法
16-15
パフォーマンスを考慮したハッシュ・クラスタの使用方法
関連項目 :
■
■
ハッシュ・クラスタの管理の詳細は、
『Oracle Database 管理者ガイド』
を参照してください。
CREATE CLUSTER 文の詳細は、
『Oracle Database SQL リファレンス』
を参照してください。
16-16　Oracle Database パフォーマンス・チューニング・ガイド
17
オプティマイザ・ヒント
オプティマイザ・ヒントを SQL 文で使用して実行計画を変更できます。ヒントを使用して
様々なアプローチを強制する方法を説明します。
この章には次の項があります。
■
オプティマイザ・ヒントの理解
■
オプティマイザ・ヒントの使用方法
オプティマイザ・ヒント
17-1
オプティマイザ・ヒントの理解
オプティマイザ・ヒントの理解
ヒントを使用することにより、通常オプティマイザによって行われる意思決定を行うことが
できます。アプリケーション設計者が、オプティマイザの認知しない、データに関する情報
を把握している場合があります。ヒントは、特定の基準に基づいて特定の問合せ実行計画を
選択するオプティマイザを割り当てる機構を提供します。
たとえば、ある問合せに対しては、特定の索引を選択する方がよい場合もあります。この情
報に基づいて、アプリケーション設計者がオプティマイザよりも効率的に実行計画を選択で
きます。その場合は、ヒントを使用して、オプティマイザが最適な実行計画を使用するよう
に強制できます。
ヒントの型および使用方法の詳細は、17-12 ページの「オプティマイザ・ヒントの使用方法」
を参照してください。ヒントは次のカテゴリにグループ分けされます。
■
最適化アプローチと目標のヒント
■
アクセス・パスに関するヒント
■
問合せの変換に関するヒント
■
結合順序のヒント
■
結合操作のヒント
■
パラレル実行のヒント
■
その他のヒント
注意 : ヒントを使用すると、管理、チェックおよび制御する必要のある
コードが増えます。
関連項目 :
■
■
SQL 文の分析およびチューニングの詳細は、第 6 章「自動パフォーマ
ンス診断」を参照してください。
Oracle Enterprise Manager 機能を使用した監視とチューニングの詳細
は、
『Oracle Enterprise Manager 概要』を参照してください。
17-2　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの理解
ヒントの型
ヒントは、次の一般的な種別に分類されます。
■
単一表
単一表ヒントは、1 つの表またはビュー上で指定されます。単一表ヒントの例として、
INDEX および USE_NL があります。
■
複数表
複数表ヒントは単一表ヒントに似ていますが、ヒントで 1 つ以上の表またはビューを指
定できる点が異なります。複数表ヒントの例には、LEADING があります。USE_NL
(table1 table2) は、複数表ヒントとはみなされないため注意してください。これ
は、実際には USE_NL(table1) および USE_NL(table2) のショートカットであるた
めです。
■
問合せブロック
問合せブロック・ヒントでは、単一の問合せブロックが処理されます。問合せブロッ
ク・ヒントの例として、STAR_TRANSFORMATION および UNNEST があります。
■
文
文ヒントは SQL 文全体に適用されます。文ヒントの例には、ALL_ROWS があります。
ヒントの指定方法
ヒントは、それらが含まれる SQL 文ブロックの最適化のみに適用されます。文ブロックは、
次のいずれかの文または文の一部です。
■
単純な SELECT 文、UPDATE 文または DELETE 文
■
複合文の親文または副問合せ
■
複合問合せの一部
たとえば、UNION 演算子で結合した 2 つの問合せから構成されている複合問合せには、各構
成要素の問合せに対して 1 つずつ、合計 2 つのブロックがあります。このため、この最初の
構成要素の問合せにおけるヒントはその最適化のみに適用され、2 番目の構成要素の問合せ
の最適化には適用されません。
次の各項では、ヒントの使用方法をさらに詳しく説明します。
■
ヒントの構文
■
ヒント全セットの指定方法
■
ヒントにおける問合せブロックの指定方法
■
グローバル表のヒントの指定方法
■
複合索引ヒントの指定方法
オプティマイザ・ヒント
17-3
オプティマイザ・ヒントの理解
ヒントの構文
オプティマイザへヒントを送るには、SQL 文内でそのヒントをコメントとして囲みます。
関連項目 : コメントの詳細は、
『Oracle Database SQL リファレンス』を
参照してください。
文中のブロックは、SELECT、UPDATE、MERGE または DELETE キーワードの後に、ヒント
を含むコメントを 1 つのみ持つことができます。
例外 : APPEND ヒントは常に INSERT キーワードの後に付けられ、
PARALLEL ヒントは INSERT キーワードの後に付けられます。
次の構文では、Oracle が文ブロックでサポートするコメントの 2 つのスタイルに含まれるヒ
ントの構文が示されています。
{DELETE|INSERT|MERGE|SELECT|UPDATE} /*+ hint [text] [hint[text]]... */
または
{DELETE|INSERT|MERGE|SELECT|UPDATE} --+ hint [text] [hint[text]]...
各項目は次のとおりです。
■
■
■
■
DELETE、INSERT、SELECT、MERGE および UPDATE は、文ブロックを開始するキー
ワードです。ヒントを含むコメントは、これらのキーワードの直後にかぎり指定できま
す。
+ により、Oracle はコメントをヒントのリストとして解釈します。プラス記号は、コメ
ント区切り記号の直後に続ける必要があります（空白は許されません）
。
hint は、この項で説明するヒントの 1 つです。コメントに複数のヒントが含まれる場
合、各ヒントはその他のヒントと最低 1 つの空白で区切られる必要があります。
text は、ヒントとともに指定できる、ヒント以外のコメントのテキストです。
--+ ヒント・フォーマットでは、ヒントは 1 行のみに指定する必要があります。
次のように、ヒントの指定が間違っている場合、Oracle はそれらを無視し、エラーを戻しま
せん。たとえば、次のようにします。
■
■
■
ヒントを含んでいるコメントが DELETE、INSERT、SELECT、MERGE または UPDATE
キーワードに続いていない場合、Oracle はそのヒントを無視します。
Oracle は構文エラーを含むヒントを無視しますが、同じコメント内に正しく指定されて
いる他のヒントは考慮します。
Oracle は矛盾するヒントの組合せを無視しますが、同じコメント内の他のヒントは考慮
します。
17-4　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの理解
■
Forms バージョン 3 のトリガー、Oracle Forms 4.5、Oracle Reports 2.5 など、PL/SQL
バージョン 1 を使用する環境では、Oracle はすべての SQL 文でヒントを無視します。
これらのヒントをサーバーに渡すことはできますが、サーバーは渡されたヒントを無視
します。
関連項目 :
■
■
各ヒントの構文については、17-12 ページの「オプティマイザ・ヒン
トの使用方法」を参照してください。
索引の型に固有の条件については、17-16 ページの「INDEX」および
以降の項を参照してください。
ヒント全セットの指定方法
ヒントを使用するとき、ある状況では、最適な実行計画を確認するためにヒントの全セット
の指定が必要な場合があります。たとえば、多数の表が結合された非常に複雑な問合せが存
在するときに、指定の表に対して INDEX ヒントのみを指定すると、オプティマイザは、使
用される残りのアクセス・パスとともに、対応する結合方法も判断する必要があります。し
たがって、INDEX ヒントを指定しても、オプティマイザによってそのヒントが使用されると
はかぎりません。これは、オプティマイザの選択した結合方法およびアクセス・パスによっ
ては、要求された索引を使用できないとオプティマイザが判断するためです。
例 17-1 では、ORDERED ヒントにより、使用する正確な結合順序が、別の表で使用される結
合方法とともに指定されています。
例 17-1 ヒント全セットの指定方法
SELECT /*+ LEADING(e2 e1) USE_NL(e1) INDEX(e1 emp_emp_id_pk)
USE_MERGE(j) FULL(j) */
e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal
FROM employees e1, employees e2, job_history j
WHERE e1.employee_id = e2.manager_id
AND e1.employee_id = j.employee_id
AND e1.hire_date = j.start_date
GROUP BY e1.first_name, e1.last_name, j.job_id
ORDER BY total_sal;
ヒントにおける問合せブロックの指定方法
問合せ内の問合せブロックを識別するには、ヒントにオプションの問合せブロック名を使用
して、ヒントの適用先となる問合せブロックを指定します。問合せブロック引数の構文の
フォームは @queryblock です。queryblock は、問合せ内の問合せブロックを指定する識
別子です。queryblock 識別子は、システム生成またはユーザー指定のいずれかとなりま
す。
■
システム生成識別子を取得するには、問合せに EXPLAIN PLAN を使用します。変換前の
問合せブロック名を決定するには、NO_QUERY_TRANSFORMATION ヒントを使用して、
オプティマイザ・ヒント
17-5
オプティマイザ・ヒントの理解
問合せに EXPLAIN PLAN を実行します。17-23 ページの「NO_QUERY_
TRANSFORMATION」を参照してください。
■
ユーザー指定の名前は、QB_NAME ヒントにより設定できます。17-44 ページの「QB_
NAME」を参照してください。
例 17-2 では、ビュー上の SELECT 文内の問合せブロックを指定するため、問合せブロック
名が NO_UNNEST ヒントとともに使用されています。
例 17-2 ヒントにおける問合せブロックの使用方法
CREATE OR REPLACE VIEW v AS
SELECT e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal
FROM employees e1,
( SELECT *
FROM employees e3) e2, job_history j
WHERE e1.employee_id = e2.manager_id
AND e1.employee_id = j.employee_id
AND e1.hire_date = j.start_date
AND e1.salary = ( SELECT max(e2.salary)
FROM employees e2
WHERE e2.department_id = e1.department_id )
GROUP BY e1.first_name, e1.last_name, j.job_id
ORDER BY total_sal;
問合せに EXPLAIN PLAN を実行し、PLAN TABLE 出力を表示した後、システム生成の問合
せブロック識別子を決定できます。たとえば、問合せブロック名は次の PLAN TABLE 出力
に表示されます。
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, NULL, 'SERIAL'));
...
Query Block Name / Object Alias (identified by operation id):
------------------------------------------------------------...
10 - SEL$4
/ E2@SEL$4
問合せブロック名が決定された後は、これを次の SQL 文に使用できます。
SELECT /*+ NO_UNNEST( @SEL$4 ) */
*
FROM v;
17-6　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの理解
グローバル表のヒントの指定方法
表を指定するヒントは、一般に、ヒントが呼び出される場所である DELETE、SELECT また
は UPDATE 問合せブロック内の表を参照します。文によって参照されるビュー内の表は参照
しません。ビュー内に表示される表のヒントを指定する場合は、ビューに埋め込まれている
ヒントではなくグローバル・ヒントを使用することをお薦めします。この章で説明する表ヒ
ントは、表の名前とともにビューの名前が含まれる拡張 tablespec 構文を使用して、グ
ローバル・ヒントに変換できます。
また、tablespec 構文の前にオプションの問合せブロック名を使用できます。17-5 ページ
の「ヒントにおける問合せブロックの指定方法」を参照してください。
表を指定するヒントには、次の構文を使用します。
図 17-1 Tablespec 構文
tablespec::=
各項目は次のとおりです。
■
view は、ビュー名を指定します。
■
table は、表の名前または別名を指定します。
ビューのパスが指定されている場合、ヒントは左から右へ解決されます。この場合、1 つ目
のビューは FROM 句に含まれる必要があり、それ以降の各ビューは、前のビューの FROM 句
で指定されている必要があります。
たとえば、例 17-3 では、部門内で給与が最高である各従業員について、従業員の姓名、従業
員の最初のジョブおよび従業員の全ダイレクト・レポートの合計給与を戻すためのビュー v
が作成されます。データを問合せる場合、ビュー e2 の表 e3 に索引 emp_job_ix を使用す
ることを強制できます。
例 17-3 グローバル・ヒントの使用例
CREATE OR REPLACE VIEW v AS
SELECT
e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal
FROM employees e1,
( SELECT *
FROM employees e3) e2, job_history j
WHERE e1.employee_id = e2.manager_id
AND e1.employee_id = j.employee_id
AND e1.hire_date = j.start_date
AND e1.salary = ( SELECT
オプティマイザ・ヒント
17-7
オプティマイザ・ヒントの理解
max(e2.salary)
FROM employees e2
WHERE e2.department_id = e1.department_id)
GROUP BY e1.first_name, e1.last_name, j.job_id
ORDER BY total_sal;
グローバル・ヒント構造を使用することで、ビュー e2 の本体に索引ヒントを指定して、
ビュー v の変更を防ぐことができます。表 e3 に索引 emp_job_ix を使用するよう強制する
には、次のいずれかの文を使用します。
SELECT /*+ INDEX(v.e2.e3 emp_job_ix) */
FROM v;
*
SELECT /*+ INDEX(@SEL$2 e2.e3 emp_job_ix) */ *
FROM v;
SELECT /*+ INDEX(@SEL$3 e3 emp_job_ix) */ *
FROM v;
グローバル・ヒント構文は、例 17-4 に示すように、マージ不可能なビューにも適用されま
す。
例 17-4 NO_MERGE を含むグローバル・ヒントの使用方法
CREATE OR REPLACE VIEW v1 AS
SELECT *
FROM employees
WHERE employee_id < 150;
CREATE OR REPLACE VIEW v2 AS
SELECT v1.employee_id employee_id, departments.department_id department_id
FROM v1, departments
WHERE v1.department_id = departments.department_id;
SELECT /*+ NO_MERGE(v2) INDEX(v2.v1.employees emp_emp_id_pk)
FULL(v2.departments) */ *
FROM v2
WHERE department_id = 30;
このヒントは、v2 をマージ不可能にし、従業員および部門表のアクセス・パス・ヒントを
指定します。これらのヒントは、マージされていないビュー v2 にプッシュされます。
関連項目 :
17-10 ページ「ビューでのヒントの使用方法」
17-8　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの理解
複合索引ヒントの指定方法
索引を指定するヒントには、次のように、単純な索引名またはカッコで括られた列のリスト
のいずれかを使用できます。
図 17-2 Indexspec 構文
indexspec::=
各項目は次のとおりです。
■
table は表の名前を指定します。
■
column は、指定された表内の列名を指定します。
■
–
オプションで列の前に表修飾子を付けることができるため、ヒントにより、索引列
が索引付きの表とは別の表にあるビットマップ結合索引を指定できます。表修飾子
がある場合、問合せに含まれる別名ではなく、実表である必要があります。
–
索引指定の各列は、式ではなく、指定された表のベース列である必要があります。
索引指定で指定された列がファンクション索引の接頭辞を形成している場合を除
き、列指定を使用してファンクション索引をヒントで指定することはできません。
index は、索引名を指定します。
ヒントは次のように解決されます。
■
■
索引名が指定されている場合、その索引のみが考慮されます。
列リストが指定されており、列の数と順序が指定の列と一致する索引が存在する場合、
その索引のみが考慮されます。このような索引が存在しない場合、指定された列が接頭
辞として指定順序どおりに含まれる、表に対する索引が考慮されます。いずれの場合
も、一致するすべての索引に対してユーザーが個別に同じヒントを指定した場合と同じ
動作になります。
たとえば、例 17-3 では、job_history 表に、employee_id 列に対する単一列索引と、
employee_id および start_date 列に対する連結索引があります。これらのいずれかの索
引を使用するには、次のように問合せにヒントを指定します。
SELECT /*+ INDEX(v.j jhist_employee_ix (employee_id start_date)) */ * FROM v;
オプティマイザ・ヒント
17-9
オプティマイザ・ヒントの理解
ビューでのヒントの使用方法
ビュー（または副問合せ）内、またはビューに対してのヒントの使用は、お薦めしません。
これは、1 つのコンテキストに定義したビューを他のコンテキストでも使用できるためです。
また、このようなヒントによって予想外の実行計画が発生する可能性があります。特に、
ビュー内のヒントまたはビューに対するヒントは、そのビューがトップレベルの問合せに
マージ可能かどうかによって処理方法が異なります。
表のヒントをビューまたは副問合せ内で指定する場合は、グローバル・ヒント構文の使用を
お薦めします。17-7 ページの「グローバル表のヒントの指定方法」を参照してください。
それでも、ビューでヒントを使用する場合は、この後の項で状況ごとの動作についての説明
を参照してください。
■
ヒントおよび複合ビュー
■
ヒントとマージ可能ビュー
■
ヒントとマージ不可能ビュー
ヒントおよび複合ビュー
デフォルトでは、複合ビューでヒントは使用できません。たとえば、複合ビューに対して選
択する問合せでヒントを指定しても、そのヒントは機能しません。これは、ビュー内にヒン
トがプッシュされないためです。
注意 :
ビューが単一表の場合、ヒントは伝播されません。
ヒントがベース・ビュー内に存在しないかぎり、ビューに対する問合せからヒントが機能す
ることはありません。
ヒントとマージ可能ビュー
この項では、マージ可能なビューでのヒントの動作について説明します。
ビューでの最適化アプローチと目標のヒント
最適化アプローチと目標のヒントは、トップレベルの問合せまたはビューの内側に指定でき
ます。
■
■
そのようなヒントがトップレベルの問合せにある場合は、ビューの内側にあるヒントと
は関係なくそのヒントが使用されます。
トップレベルのオプティマイザ・モード・ヒントがない場合は、参照されているビュー
のすべてのモード・ヒントに一貫性があるかぎり、それらのモード・ヒントが使用され
ます。
17-10　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの理解
■
参照されているビューの 2 つ以上のモード・ヒントが矛盾する場合は、そのビューのす
べてのモード・ヒントが廃棄されて、セッション・モードが使用されます（デフォルト
かユーザー指定かには関係しません）
。
ビューに対するアクセス・パスとヒント結合
参照されるビューに対するアクセス・パスとヒント結合は、そのビューが単一の表を含んで
いないかぎり（または単一の表を持つその他のヒント・ビューを参照していないかぎり）無
視されます。そのような単一表ビューでは、ビューに対するアクセス・パスやヒント結合
は、そのビューの中の表に対して適用されます。
ビューの内側のアクセス・パスとヒント結合
アクセス・パスとヒント結合は、ビュー定義に含めることができます。
■
■
ビューがインライン・ビューである場合（つまり、ビューが SELECT 文の FROM 句にあ
る場合）
、そのビューの内側のすべてのアクセス・パスとヒント結合は、そのビューが
トップレベルの問合せにマージされるときに保存されます。
インライン・ビューでないビューでは、そのビューの中のアクセス・パスとヒント結合
が保存されるのは、参照問合せが他の表やビューを参照していない場合（つまり、
SELECT 文の FROM 句にそのビューしか含まれていない場合）のみです。
ビューに対するパラレル実行ヒント
ビューに対する PARALLEL、NO_PARALLEL、PARALLEL_INDEX および NO_PARALLEL_
INDEX ヒントは、参照されるビュー内のすべての表に繰り返し適用されます。トップレベル
の問合せのパラレル実行ヒントは、参照されるビューの内側のそのようなヒントを上書きし
ます。
ビューの内側のパラレル実行ヒント
ビューの内側の PARALLEL、NO_PARALLEL、PARALLEL_INDEX および NO_PARALLEL_
INDEX ヒントは、ビューがトップレベルの問合せにマージされるときに保存されます。トッ
プレベルの問合せにあるビューのパラレル実行ヒントは、参照されるビューの内側のそのよ
うなヒントを上書きします。
ヒントとマージ不可能ビュー
マージ不可能なビューでは、ビューの内側の最適化アプローチと目標のヒントは無視されま
す。つまり、トップレベルの問合せにより最適化モードが決定されます。
マージ不可能なビューはトップレベルの問合せとは別に最適化されるので、そのビューの内
側のアクセス・パスとヒント結合は保存されます。同じ理由から、トップレベルの問合せ内
のビューに対するアクセス・パスも無視されます。
ただし、トップレベルの問合せ内のビューに対するヒント結合は保存されます。この場合、
マージ不可能なビューは表と同様であるためです。
オプティマイザ・ヒント
17-11
オプティマイザ・ヒントの使用方法
オプティマイザ・ヒントの使用方法
この項では、オプティマイザ・ヒントの使用方法を説明します。オプティマイザ・ヒント
は、次のように分類できます。
■
最適化アプローチと目標のヒント
■
アクセス・パスに関するヒント
■
問合せの変換に関するヒント
■
結合順序のヒント
■
結合操作のヒント
■
パラレル実行のヒント
■
その他のヒント
最適化アプローチと目標のヒント
この項で説明しているヒントでは、最適化アプローチと目標のいずれかを選択できます。
■
ALL_ROWS
■
FIRST_ROWS(n)
■
RULE
最適化アプローチと目標を指定するヒントが SQL 文に含まれている場合、オプティマイザ
は、統計の有無、OPTIMIZER_MODE 初期化パラメータの値および ALTER SESSION 文の
OPTIMIZER_MODE パラメータにかかわらず、指定されたアプローチを使用します。
注意 : オプティマイザの目標は直接実行される問合せにのみ適用されま
す。ヒントを使用して、PL/SQL の内部から実行される SQL 文のための
アクセス・パスを指定してください。ALTER SESSION...SET OPTIMIZER_
MODE 文は、PL/SQL の内部から実行される SQL には作用しません。
SQL 文に ALL_ROWS ヒントまたは FIRST_ROWS(n) ヒントを指定した場合、データ・ディク
ショナリ内に、文がアクセスする表に関する統計情報が作成されていないと、オプティマイ
ザは、デフォルトの統計値（そのような表に割り当てられている記憶域など）を使用して、
欠けている統計を見積ってから、実行計画を選択します。これらの見積りは DBMS_STATS
パッケージによって生成された見積りほど正確ではありません。したがって、統計の収集に
は DBMS_STATS パッケージを使用します。
ALL_ROWS ヒントまたは FIRST_ROWS(n) ヒントとともに、アクセス・パスまたは結合操作
のヒントを指定した場合、オプティマイザはヒントによって指定されたアクセス・パスと結
合操作を優先します。
17-12　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
マージ可能なビューでのヒントの動作については、17-10 ページの「ビューでの最適化アプ
ローチと目標のヒント」を参照してください。
ALL_ROWS
ALL_ROWS ヒントは、最高のスループットを目標として（つまり合計のリソース使用率を最
小限にして）文ブロックを最適化するために、問合せ最適化のアプローチを選択します。
all_rows_hint::=
たとえば、オプティマイザは、次の文を最適化するために、最高のスループットを目標とし
た問合せ最適化のアプローチを使用します。
SELECT /*+ ALL_ROWS */ employee_id, last_name, salary, job_id
FROM employees
WHERE employee_id = 7566;
FIRST_ROWS(n)
FIRST_ROWS(n) ヒントは Oracle に対して、最初の n 行を最も効率的に戻す計画を選択し、
応答が高速化するように SQL 文を個別に最適化することを指示します。
first_rows_hint::=
integer は、戻す行数を指定します。
たとえば、オプティマイザは、次の文を最適化するために、最短応答時間を目標とした問合
せ最適化のアプローチを使用します。
SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name, salary, job_id
FROM employees
WHERE department_id = 20;
この例では、各部門に多数の社員がいます。ユーザーは、部門 20 の最初の 10 人の社員を可
能なかぎり素早く表示するとします。
オプティマイザは、DELETE 文ブロックと UPDATE 文ブロック、および次の構文のいずれか
が含まれている SELECT 文ブロックでこのヒントを無視します。
■
集合演算子（UNION、INTERSECT、MINUS、UNION ALL）
■
GROUP BY 句
■
FOR UPDATE 句
■
集計関数
オプティマイザ・ヒント
17-13
オプティマイザ・ヒントの使用方法
■
DISTINCT 演算子
■
順序付けする列に索引がない場合の ORDER BY 句
Oracle は最初の行を戻す前に、文によってアクセスされた行をすべて取り出す必要があるた
め、これらの文は最短の応答時間を目標に最適化できません。これらの文にこのヒントを指
定した場合、オプティマイザは問合せ最適化のアプローチを使用して、最高のスループット
を目標に最適化します。
注意 : FIRST_ROWS ヒントは、最初の 1 行を戻す計画を最適化するため
のものであり、下位互換性とプラン・スタビリティのために保持されてい
ます。
RULE
RULE ヒントは、問合せオプティマイザを使用禁止にします。このヒントはサポート外であ
り、使用しないでください。
rule_hint::=
アクセス・パスに関するヒント
この項では、表のアクセス・パスを指示するいくつかのヒントについて説明します。
■
FULL
■
CLUSTER
■
HASH
■
INDEX
■
NO_INDEX
■
INDEX_ASC
■
INDEX_COMBINE
■
INDEX_JOIN
■
INDEX_DESC
■
INDEX_FFS
■
NO_INDEX_FFS
■
INDEX_SS
17-14　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
■
INDEX_SS_ASC
■
INDEX_SS_DESC
■
NO_INDEX_SS
これらのヒントの 1 つを指定すると、指定されたアクセス・パスが索引やクラスタの存在お
よび SQL 文の構文構造体に基づいて使用できる場合のみ、オプティマイザはそのアクセス・
パスを選択します。ヒントを使用できないアクセス・パスを指定すると、オプティマイザは
その指定を無視します。
アクセスする表は、文に指定する場合と同じように正確に指定してください。文が表の別名
を使用している場合、表の名前ではなく、表の別名をヒントで使用する必要があります。ス
キーマ名が文中にある場合は、ヒント内の表名にそのスキーマ名を入れないでください。
マージ可能なビューでのヒントの動作については、17-11 ページの「ビューに対するアクセ
ス・パスとヒント結合」および 17-11 ページの「ビューの内側のアクセス・パスとヒント結
合」を参照してください。
注意 : アクセス・パスのヒントの場合、SELECT 文の FROM 句で SAMPLE
オプションを指定すると、Oracle はヒントを無視します。
関連項目 : SAMPLE オプションの詳細は、
『Oracle Database SQL リファ
レンス』を参照してください。
FULL
FULL ヒントは、指定された表に対して全表スキャンを選択します。
full_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ FULL(e) */ employee_id, last_name
FROM employees e
WHERE last_name LIKE :b1;
Oracle は、WHERE 句の条件によって使用可能になる last_name 列に索引が付けられている
場合でも、employees 表で全表スキャンを実行して、この文を実行します。
オプティマイザ・ヒント
17-15
オプティマイザ・ヒントの使用方法
注意 : employees 表には別名 e が存在するため、ヒントでは、名前では
なく別名で表を参照する必要があります。また、スキーマ名が FROM 句に
指定されていても、ヒントにその名前を指定しないでください。
CLUSTER
CLUSTER ヒントは、指定された表にアクセスするためにクラスタ・スキャンを選択します。
これはクラスタ化オブジェクトにのみ適用されます。
cluster_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
HASH
HASH ヒントは、指定された表をアクセスするためにハッシュ・スキャンを選択します。こ
れは、クラスタに格納されている表にのみ適用されます。
hash_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
INDEX
INDEX ヒントは、指定された表に対して索引スキャンを選択します。INDEX ヒントはドメ
イン索引、B ツリー索引およびビットマップ結合索引に使用できます。ただし、INDEX_
COMBINE の方が INDEX よりも用途の広いヒントであるため、複数索引の結合には INDEX_
COMBINE の使用をお薦めします。
index_hint::=
17-16　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。indexspec 構文の詳細は、17-9 ページの「複合索引ヒント
の指定方法」を参照してください。
このヒントでは、次のように 1 つ以上の索引を指定できます。
■
■
■
ヒントが使用可能な索引を 1 つ指定している場合、オプティマイザはその索引に対して
スキャンを行います。オプティマイザは、全表スキャンや、表の別の索引に対するス
キャンを検討しません。
ヒントが使用可能な索引のリストを指定している場合、オプティマイザはリスト内の各
索引についてスキャン・コストを検討し、コストの最も低い索引に対してスキャンを行
います。また、このリストから複数の索引をスキャンし、その結果をマージするアクセ
ス・パスのコストが最も低い場合、オプティマイザはそのアクセス・パスを選択しま
す。ただし、オプティマイザは、全表スキャンや、ヒントでリストされていない索引に
対するスキャンについては検討しません。
ヒントが索引を指定していない場合、オプティマイザは表に対して使用可能な各索引の
スキャンのコストを検討し、コストの最も低い索引に対してスキャンを行います。ま
た、複数の索引をスキャンし、その結果をマージするアクセス・パスのコストが最も低
い場合、オプティマイザはそのアクセス・パスを選択します。オプティマイザは、全表
スキャンについては検討しません。
たとえば、次のようにします。
SELECT /*+ INDEX (employees emp_department_ix)*/
employee_id, department_id
FROM employees
WHERE department_id > 50;
NO_INDEX
NO_INDEX ヒントは、指定された表の索引を明示的に禁止します。
no_index_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能しますが、次の変更点があ
ります。
オプティマイザ・ヒント
17-17
オプティマイザ・ヒントの使用方法
■
■
■
使用可能な索引がヒントによって 1 つ指定されている場合、オプティマイザはその索引
に対してスキャンを検討しません。指定されていないその他の索引はひきつづき検討さ
れます。
使用可能な索引のリストがヒントによって指定されている場合、オプティマイザはその
索引のどれに対してもスキャンを検討しません。リストで指定されていないその他の索
引は検討されます。
索引がヒントによって指定されていない場合、オプティマイザは表のどの索引に対して
もスキャンを検討しません。この動作は、NO_INDEX ヒントで使用可能な表の索引すべ
てのリストを指定した場合と同じです。
NO_INDEX ヒントは、ファンクション索引、B ツリー索引、ビットマップ索引、クラスタ索
引またはドメイン索引に適用されます。NO_INDEX ヒントと索引ヒント（INDEX、INDEX_
ASC、INDEX_DESC、INDEX_COMBINE または INDEX_FFS）の両方で同じ索引が指定され
ると、NO_INDEX ヒントおよび索引ヒントは両方とも指定された索引で無視され、オプティ
マイザがその索引を検討します。
たとえば、次のようにします。
SELECT /*+ NO_INDEX(employees emp_empid) */ employee_id
FROM employees
WHERE employee_id > 200;
INDEX_ASC
INDEX_ASC ヒントは、指定された表に対して索引スキャンを選択します。文が索引レン
ジ・スキャンを使用する場合、Oracle は索引付きの値について昇順に索引エントリをスキャ
ンします。
index_asc_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
レンジ・スキャンのデフォルト動作は、索引付けされた値の昇順に索引エントリをスキャン
する作業のため、このヒントでは、INDEX ヒント以外に何も指定されません。INDEX_ASC
ヒントを使用して昇順のレンジ・スキャンを明示的に指定する場合は、デフォルト動作を変
更してください。
17-18　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
INDEX_COMBINE
INDEX_COMBINE ヒントは、表のビットマップ・アクセス・パスを明示的に選択します。
INDEX_COMBINE ヒントに引数として索引が与えられていない場合、オプティマイザは、最
良のコストが見積もられている索引のブール値の組合せを表に対して使用します。引数とし
て特定の索引が与えられた場合、オプティマイザは、指定された索引のブール値の組合せの
使用を試みます。
index_combine_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
たとえば、次のようにします。
SELECT /*+ INDEX_COMBINE(e emp_manager_ix emp_department_ix) */ *
FROM employees e
WHERE manager_id = 108
OR department_id = 110;
INDEX_JOIN
INDEX_JOIN ヒントは、オプティマイザが索引結合をアクセス・パスとして使用することを
明示的に指示します。このヒントを効果的にするには、問合せの解決に必要な列をすべて含
んだ、少数の索引が必要です。
index_join_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
たとえば、次の問合せでは索引結合を使用して、employees 表に索引が作成されている
manager_id および department_id 列にアクセスします。
SELECT /*+ INDEX_JOIN(e emp_manager_ix emp_department_ix) */ department_id
FROM employees e
WHERE manager_id < 110
AND department_id < 50;
オプティマイザ・ヒント
17-19
オプティマイザ・ヒントの使用方法
INDEX_DESC
INDEX_DESC ヒントは、指定された表に対して索引スキャンを選択します。文に索引レン
ジ・スキャンが使用される場合、Oracle は索引エントリを索引付きの値について降順にス
キャンします。パーティション索引では、各パーティション内で結果が降順に表示されま
す。
index_desc_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
たとえば、次のようにします。
SELECT /*+ INDEX_DESC(e emp_name_ix) */ *
FROM employees e;
INDEX_FFS
INDEX_FFS ヒントによって、全表スキャンではなく高速全索引スキャンが実行されます。
index_ffs_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
たとえば、次のようにします。
SELECT /*+ INDEX_FFS(e emp_name_ix) */ first_name
FROM employees e;
関連項目 :
14-26 ページ「全体スキャン」
NO_INDEX_FFS
NO_INDEX_FFS ヒントによって、オプティマイザは指定された表における指定された索引
の高速全索引スキャンを除外します。
no_index_ffs_hint::=
17-20　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
たとえば、次のようにします。
SELECT /*+ NO_INDEX_FFS(items item_order_ix) */ order_id
FROM order_items items;
INDEX_SS
INDEX_SS ヒントは、指定された表に対して索引スキップ・スキャンを選択します。文が索
引レンジ・スキャンを使用する場合、Oracle は索引付きの値について昇順に索引エントリを
スキャンします。パーティション索引では、各パーティション内で結果が昇順に表示されま
す。
index_ss_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
たとえば、次のようにします。
SELECT /*+ INDEX_SS(e emp_name_ix) */ last_name
FROM employees e
WHERE first_name = 'Steven';
INDEX_SS_ASC
INDEX_SS_ASC ヒントは、指定された表に対して索引スキップ・スキャンを選択します。
文が索引レンジ・スキャンを使用する場合、Oracle は索引付きの値について昇順に索引エン
トリをスキャンします。パーティション索引では、各パーティション内で結果が昇順に表示
されます。
index_ss_asc_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
レンジ・スキャンのデフォルト動作は、索引付けされた値の昇順に索引エントリをスキャン
する作業なので、このヒントでは、INDEX_SS ヒント以外に何も指定されません。INDEX_
SS_ASC ヒントを使用して昇順のレンジ・スキャンを明示的に指定する場合は、デフォルト
動作を変更してください。
オプティマイザ・ヒント
17-21
オプティマイザ・ヒントの使用方法
INDEX_SS_DESC
INDEX_SS_DESC ヒントは、指定された表に対して索引スキップ・スキャンを選択します。
文に索引レンジ・スキャンが使用される場合、Oracle は索引エントリを索引付きの値につい
て降順にスキャンします。パーティション索引では、各パーティション内で結果が降順に表
示されます。
index_ss_desc_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
たとえば、次のようにします。
SELECT /*+ INDEX_SS_DESC(e emp_name_ix) */ last_name
FROM employees e
WHERE first_name = 'Steven';
NO_INDEX_SS
NO_INDEX_SS ヒントによって、オプティマイザは指定された表における指定された索引の
スキップ・スキャンを除外します。
no_index_ss_desc_hint::=
各パラメータは、17-16 ページの INDEX ヒントと同じ目的で機能します。
問合せの変換に関するヒント
この項で説明する各ヒントは、SQL 問合せ変換を示唆するものです。
■
NO_QUERY_TRANSFORMATION
■
USE_CONCAT
■
NO_EXPAND
■
REWRITE
■
NO_REWRITE
■
MERGE
■
NO_MERGE
17-22　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
■
STAR_TRANSFORMATION
■
NO_STAR_TRANSFORMATION
■
FACT
■
NO_FACT
■
UNNEST
■
NO_UNNEST
NO_QUERY_TRANSFORMATION
NO_QUERY_TRANSFORMATION ヒントによって、オプティマイザは OR 拡張、ビューのマー
ジ、副問合せのネスト解除、スター型変換およびマテリアライズド・ビューによるリライト
を含む、すべての問合せ変換などをスキップします。
no_query_transformation::=
たとえば、次のようにします。
SELECT /*+ NO_QUERY_TRANSFORMATION */ employee_id, last_name
FROM (SELECT *
FROM employees e) v
WHERE v.last_name = 'Smith';
USE_CONCAT
USE_CONCAT ヒントを使用すると、問合せの WHERE 句の OR 条件の組合せが、UNION ALL
集合演算子を使用する複合問合せに強制的に変換されます。通常、この変換は、連結を使用
する問合せのコストが、使用しない場合のコストよりも低い場合にかぎり実行します。
USE_CONCAT ヒントは、コストの考慮事項を上書きします。
use_concat_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
たとえば、次のようにします。
SELECT /*+ USE_CONCAT */ *
FROM employees e
WHERE manager_id = 108
OR department_id = 110;
オプティマイザ・ヒント
17-23
オプティマイザ・ヒントの使用方法
NO_EXPAND
NO_EXPAND ヒントは、オプティマイザが OR 条件または WHERE 句の IN リストを持ってい
る問合せの OR 拡張を検討するのを防ぎます。通常、オプティマイザは OR 拡張の使用を検
討し、使用しない場合よりもコストが低いと判断した場合にこのメソッドを使用します。
no_expand_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
たとえば、次のようにします。
SELECT /*+ NO_EXPAND */ *
FROM employees e, departments d
WHERE e.manager_id = 108
OR d.department_id = 110;
REWRITE
REWRITE ヒントでは、可能な場合には、オプティマイザがコストを考慮せずに、問合せを
強制的にマテリアライズド・ビューに書き換えます。REWRITE ヒントは、ビュー・リスト
とともに、またはビュー・リストなしで使用します。REWRITE ヒントをビュー・リストと
ともに使用する場合、リストに適切なマテリアライズド・ビューが存在すると、Oracle はコ
ストとは関係なくそのビューを使用します。
リスト外のビューは検討されません。ビュー・リストを指定しない場合は、Oracle によって
適切なマテリアライズド・ビューが検索され、最終計画のコストとは関係なくそのビューが
使用されます。
rewrite_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
17-24　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
関連項目 :
■
■
マテリアライズド・ビューの詳細は、『Oracle Database 概要』および
『Oracle Database アドバンスト・レプリケーション』を参照してくだ
さい。
マテリアライズド・ビューでの REWRITE の使用方法の詳細は、
『Oracle データ・ウェアハウス・ガイド』を参照してください。
NO_REWRITE
NO_REWRITE ヒントは、パラメータ QUERY_REWRITE_ENABLED の設定を上書きして、問合
せブロックに対する問合せのリライトを無効にします。
注意 : NO_REWRITE ヒントで、ファンクション索引の使用を使用禁止に
します。
no_rewrite_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
たとえば、次のようにします。
SELECT /*+ NO_REWRITE */ sum(s.amount_sold) AS dollars
FROM sales s, times t
WHERE s.time_id = t.time_id
GROUP BY t.calendar_month_desc;
注意 : NOREWRITE ヒントは使用されなくなりました。NO_REWRITE ヒ
ントを使用してください。
オプティマイザ・ヒント
17-25
オプティマイザ・ヒントの使用方法
MERGE
MERGE ヒントは、問合せにビューをマージできます。
ビューの問合せブロックが GROUP BY 句または DISTINCT 演算子を SELECT リストに持って
いる場合は、複合ビューのマージが使用可能になっているときのみ、オプティマイザが
ビューをアクセス文にマージできます。また、複合マージは、副問合せに相互関係がない場
合に、アクセス文に IN 副問合せをマージするのにも使用できます。
merge_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ MERGE(v) */ e1.last_name, e1.salary, v.avg_salary
FROM employees e1,
(SELECT department_id, avg(salary) avg_salary
FROM employees e2
GROUP BY department_id) v
WHERE e1.department_id = v.department_id AND e1.salary > v.avg_salary;
引数を指定せずに MERGE ヒントを使用するときは、ビュー問合せブロック内に挿入してく
ださい。ビュー名を引数として指定して MERGE を使用するときは、周囲の問合せに挿入して
ください。
NO_MERGE
NO_MERGE ヒントを使用すると、Oracle はマージ可能なビューをマージしません。
no_merge_hint::=
17-26　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
このヒントを使用すると、ビューのアクセス方法に、ユーザーがより多くの影響を与えるこ
とができます。
たとえば、次のようにします。
SELECT /*+NO_MERGE(seattle_dept)*/ e1.last_name, seattle_dept.department_name
FROM employees e1,
(SELECT location_id, department_id, department_name
FROM departments
WHERE location_id = 1700) seattle_dept
WHERE e1.department_id = seattle_dept.department_id;
これにより、seattle_dept はマージされなくなります。
引数を指定せずに NO_MERGE ヒントを使用するときは、ビュー問合せブロック内に挿入して
ください。ビュー名を引数として指定して NO_MERGE を使用するときは、周囲の問合せに挿
入してください。
STAR_TRANSFORMATION
STAR_TRANSFORMATION ヒントにより、オプティマイザは、変換（TRANSFORMATION）
が使用されている最適な計画を使用します。このヒントを使用しない場合、オプティマイザ
は、変換された問合せのための最適な計画のかわりに、変換なしで生成された最適な計画を
使用するという問合せ最適化の決定を行うことがあります。
ヒントが与えられている場合でも、変換が行われる保証はありません。オプティマイザは、
合理的と思われる場合にのみ副問合せを生成します。副問合せが生成されない場合は、変換
された問合せが存在しないので、変換されていない問合せの中で最適な計画がヒントとは無
関係に使用されます。
star_transformation_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
オプティマイザ・ヒント
17-27
オプティマイザ・ヒントの使用方法
たとえば、次のようにします。
SELECT /*+ STAR_TRANSFORMATION */ *
FROM sales s, times t, products p, channels c
WHERE s.time_id = t.time_id
AND s.prod_id = p.product_id
AND s.channel_id = c.channel_id
AND p.product_status = 'obsolete';
関連項目 :
■
■
スター型変換の詳細は、
『Oracle Database 概要』を参照してください。
STAR_TRANSFORMATION_ENABLED 初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照してください。
NO_STAR_TRANSFORMATION
NO_STAR_TRANSFORMATION ヒントによって、オプティマイザはスター・クエリー変換を
実行しなくなります。
no_star_transformation_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
FACT
FACT ヒントをスター型変換のコンテキストで使用すると、ヒントで指定された表が、変換
においてファクト表とみなされます。
fact_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
17-28　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
NO_FACT
NO_FACT ヒントをスター型変換のコンテキストで使用すると、ヒントで指定された表は、
変換においてファクト表とみなされません。
no_fact_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
UNNEST
UNNEST ヒントは、副問合せのネスト解除を指定します。副問合せのネストの解除によって、
副問合せ本体のネストが解除され、その副問合せが含まれている問合せブロックの本体に
マージされます。これにより、オプティマイザは、アクセス・パスと結合を評価するとき
に、副問合せと本文の両方をいっしょに考慮できるようになります。
UNNEST ヒントが使用された場合、Oracle では、まず最初に文が妥当かどうかが検証されま
す。文が妥当でないと、副問合せのネストの解除は処理できません。次に、文は、副問合せ
のネストを解除して問合せを最適化することが最も効率がよいかどうかをチェックされま
す。
UNNEST ヒントは、副問合せブロックの妥当性のみを調査するよう Oracle に通知します。副
問合せブロックが妥当な場合は、経験則やコストをチェックしなくても、副問合せのネスト
解除が使用可能になります。
関連項目 :
■
■
ネストされた副問合せのネスト解除および副問合せブロックを妥当に
する条件の詳細は、
『Oracle Database SQL リファレンス』を参照して
ください。
14-11 ページ「副問合せのネスト解除」
unnest_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
オプティマイザ・ヒント
17-29
オプティマイザ・ヒントの使用方法
NO_UNNEST
NO_UNNEST ヒントは、特定の副問合せブロックのネスト解除をオフに切り替えます。
no_unnest_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
結合順序のヒント
この項で説明するヒントは、結合順序を指示します。
■
LEADING
■
ORDERED
LEADING ヒントのほうが用途が広く、ORDERED ヒントより望ましい方法です。
LEADING
LEADING ヒントによって、実行計画の接頭辞として使用される表のセットが指定されます。
このヒントは、ORDERED ヒントよりも広い用途を持っています。
結合グラフにおける依存性のため、指定された表を最初に指定順序で結合できない場合、
LEADING ヒントは無視されます。競合する 2 つ以上の LEADING ヒントを指定した場合は、
指定したヒントはすべて無視されます。ORDERED ヒントが指定されている場合は、
LEADING ヒントがすべて上書きされます。
leading_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ LEADING(e j) */ *
FROM employees e, departments d, job_history j
WHERE e.department_id = d.department_id
AND e.hire_date = j.start_date;
17-30　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
ORDERED
ORDERED ヒントによって、Oracle は FROM 句に指定された順序で表を結合します。
結合を行う SQL 文に ORDERED ヒントを指定しない場合は、表を結合する順序をオプティマ
イザが選択します。オプティマイザにはわからないような、各表から選択される行数に関す
る情報を把握している場合、ORDERED ヒントを使用して結合順序を指定できます。そのよ
うな情報を把握している場合は、オプティマイザよりも適切に内部表と外部表を選択できま
す。
ordered_hint::=
次の問合せは ORDERED ヒントの使用例です。
SELECT /*+ORDERED */ o.order_id, c.customer_id, l.unit_price * l.quantity
FROM customers c, order_items l, orders o
WHERE c.cust_last_name = :b1
AND o.customer_id = c.customer_id
AND o.order_id = l.order_id;
結合操作のヒント
この項では、表の結合処理を指示するヒントについて説明します。
■
USE_NL
■
NO_USE_NL
■
USE_NL_WITH_INDEX
■
USE_MERGE
■
NO_USE_MERGE
■
USE_HASH
■
NO_USE_HASH
USE_NL ヒントと USE_MERGE ヒントは、結合順序のヒントとともに使用することをお薦め
します。17-30 ページの「結合順序のヒント」を参照してください。Oracle では、参照表が
結合の内部表になった場合にこれらのヒントを使用し、参照表が外部表の場合にはこれらの
ヒントを無視します。
マージ可能なビューでのヒントの動作については、17-11 ページの「ビューに対するアクセ
ス・パスとヒント結合」および 17-11 ページの「ビューの内側のアクセス・パスとヒント結
合」を参照してください。
オプティマイザ・ヒント
17-31
オプティマイザ・ヒントの使用方法
USE_NL
USE_NL ヒントによって、Oracle は、別の行ソースに指定された各表を、指定の表が内部表
として使用されているネステッド・ループ結合に結合します。
use_nl_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
ネステッド・ループがヒントによって強制的に使用される次の例の場合は、orders に対し
ては全表スキャンによってアクセスされ、フィルタ条件 l.order_id = h.order_id がす
べての行に適用されます。フィルタ条件を満たすどの行についても、order_items は索引
order_id からアクセスされます。
SELECT /*+ USE_NL(l h) */ h.customer_id, l.unit_price * l.quantity
FROM orders h ,order_items l
WHERE l.order_id = h.order_id;
問合せに INDEX ヒントを追加すると、さらに大きいシステムで使用されるものに類似した
実行計画になり、orders での全表スキャンが実行されるのを回避できます（今回は特に有
効ではない場合も）
。
NO_USE_NL
NO_USE_NL ヒントによって、オプティマイザは、別の行ソースに指定された各表を結合す
るための、指定の表が内部表として使用されているネステッド・ループ結合を除外します。
このヒントが使用されている場合、指定された表に対してハッシュ結合およびソート / マー
ジ結合のみが考慮されます。ただし、ネステッド・ループを使用しないと表を結合できない
場合があります。そのような場合、オプティマイザではこれらの表のヒントが無視されます。
no_use_nl_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
17-32　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
SELECT /*+ NO_USE_NL(l h) */ *
FROM orders h, order_items l
WHERE l.order_id = h.order_id
AND l.order_id > 3500;
USE_NL_WITH_INDEX
USE_NL_WITH_INDEX ヒントによって、オプティマイザは、別の行ソースに指定された表
を、指定の表が内部表として使用されているネステッド・ループ結合に結合しますが、次の
条件を満たす場合に限られます。索引が指定されていない場合、オプティマイザは、少なく
とも 1 つの述語結合が含まれる索引を索引キーとして使用できる必要があります。索引が指
定されている場合、オプティマイザは、少なくとも 1 つの述語結合が含まれる索引を索引
キーとして使用できる必要があります。
use_nl_with_index_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。indexspec 構文の詳細は、17-9 ページの「複合索引ヒント
の指定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ USE_NL_WITH_INDEX(l item_product_ix) */ *
FROM orders h, order_items l
WHERE l.order_id = h.order_id
AND l.order_id > 3500;
USE_MERGE
USE_MERGE ヒントにより、Oracle はソート / マージ結合を使用して、それぞれの指定され
た表を別の行ソースと結合します。
use_merge_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
オプティマイザ・ヒント
17-33
オプティマイザ・ヒントの使用方法
SELECT /*+ USE_MERGE(employees departments) */ *
FROM employees, departments
WHERE employees.department_id = departments.department_id;
NO_USE_MERGE
NO_USE_MERGE ヒントによって、オプティマイザは、別の行ソースに指定された各表を結
合するための、指定の表が内部表として使用されているソート / マージ結合を除外します。
no_use_merge_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ NO_USE_MERGE(e d) */ *
FROM employees e, departments d
WHERE e.department_id = d.department_id
ORDER BY d.department_id;
USE_HASH
USE_HASH ヒントにより、Oracle はハッシュ結合を使用して、それぞれの指定された表と別
の行ソースを結合します。
use_hash_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ USE_HASH(l h) */ *
FROM orders h, order_items l
WHERE l.order_id = h.order_id
AND l.order_id > 3500;
17-34　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
NO_USE_HASH
NO_USE_HASH ヒントによって、オプティマイザは、別の行ソースに指定された各表を結合
するための、指定の表が内部表として使用されているハッシュ結合を除外します。
no_use_hash_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ NO_USE_HASH(e d) */ *
FROM employees e, departments d
WHERE e.department_id = d.department_id;
パラレル実行のヒント
この項では、パラレル実行を行ったときに、文がどのようにパラレル化されるか、またはパ
ラレル化されないかを指示するヒントについて説明します。
■
PARALLEL
■
NO_PARALLEL
■
PQ_DISTRIBUTE
■
PARALLEL_INDEX
■
NO_PARALLEL_INDEX
マージ可能なビューでのヒントの動作については、17-11 ページの「ビューに対するパラレ
ル実行ヒント」および 17-11 ページの「ビューの内側のパラレル実行ヒント」を参照してく
ださい。
関連項目 : パラレル実行の詳細は、『Oracle データ・ウェアハウス・ガイ
ド』を参照してください。
PARALLEL
PARALLEL ヒントを使用して、パラレル操作に使用できる同時サーバーの数を自由に指定し
ます。このヒントは、文の SELECT 部分、INSERT 部分、UPDATE 部分および DELETE 部分
と、表スキャン部分に適用されます。
オプティマイザ・ヒント
17-35
オプティマイザ・ヒントの使用方法
注意 : 使用できるサーバーの数は、同時にソート操作またはグルーピン
グ操作が実行されると、PARALLEL ヒント内の値の 2 倍になります。
パラレル制限のいずれかに違反すると、ヒントは無視されます。
parallel_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
整数値では、指定の表の並列度を指定します。DEFAULT を指定するか、または値を指定し
ないと、問合せコーディネータが初期化パラメータの設定を調べ、デフォルトの並列度を判
別します。次の例では、PARALLEL ヒントによって、employees 表定義に指定されている
並列度が上書きされます。
SELECT /*+ FULL(hr_emp) PARALLEL(hr_emp, 5) */ last_name
FROM employees hr_emp;
その次の例では、PARALLEL ヒントによって、employees 表定義に指定されている並列度
が上書きされ、オプティマイザは、初期化パラメータに指定されているデフォルトの並列度
を使用するように命令されます。
SELECT /*+ FULL(hr_emp) PARALLEL(hr_emp, DEFAULT) */ last_name
FROM employees hr_emp;
NO_PARALLEL
NO_PARALLEL ヒントは表句の PARALLEL 指定を上書きします。
no_parallel_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
次の例に、NO_PARALLEL ヒントを示します。
17-36　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
SELECT /*+ NO_PARALLEL(hr_emp) */ last_name
FROM employees hr_emp;
注意 : NOPARALLEL ヒントは使用されなくなりました。NO_PARALLEL
ヒントを使用してください。
PQ_DISTRIBUTE
PQ_DISTRIBUTE ヒントで、パラレル結合操作のパフォーマンスが向上します。これを行う
には、結合した表の列を生成側とコンシューマの問合せサーバー間で配布する方法を指定し
ます。このヒントを使用すると、オプティマイザが通常行う決定は上書きされます。
オプティマイザによって選択された配布を識別するには、EXPLAIN PLAN 文を使用します。
両方の表がシリアルの場合、オプティマイザは配布ヒントを無視します。
pq_distribute_hint::=
各項目は次のとおりです。
■
outer_distribution は、外部表の配布です。
■
inner_distribution は、内部表の配布です。
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
関連項目 : Oracle が結合操作をパラレル化する方法の詳細は、『Oracle
Database 概要』を参照してください。
表の配布には次の 6 つの組合せがあります。表 17-1 で説明するように、結合表の配布方式の
組合せはサブセットのみが妥当です。
表 17-1 配布ヒントの組合せ
配布
説明
ハッシュ対ハッシュ
結合キーでハッシュ関数を使用して、各表の行をコンシューマ問合せ
サーバーにマップします。マッピングが完了すると、各問合せサー
バーは結果パーティションのペア間で結合を実行します。このヒント
は、表のサイズが同じくらいで、結合操作がハッシュ結合またはソー
ト / マージ結合で実装されている場合にお薦めします。
オプティマイザ・ヒント
17-37
オプティマイザ・ヒントの使用方法
表 17-1 配布ヒントの組合せ（続き）
配布
説明
ブロードキャスト対なし
外部表のすべての行が各問合せサーバーにブロードキャストされます。
内部表の行はランダムにパーティション化されます。このヒントは、
外部表が内部表に比べて非常に小さい場合にお薦めします。一般規則
として、ブロードキャスト対なしのヒントは、内部表のサイズ×問合
せサーバー数が、外部表のサイズよりも大きい場合に使用します。
なし対ブロードキャスト
内部表のすべての行が各コンシューマ問合せサーバーにブロードキャ
ストされます。外部表の行はランダムにパーティション化されます。
このヒントは、内部表が外部表に比べて非常に小さい場合にお薦めし
ます。一般的に、なし対ブロードキャストのヒントは、内部表のサイ
ズ×問合せサーバー数が、外部表のサイズよりも小さい場合に使用し
ます。
パーティション対なし
内部表のパーティション化を使用して、外部表の行をマップします。
内部表は、結合キーでパーティション化する必要があります。このヒ
ントは、外部表のパーティションの数が問合せサーバーの数と等しい
か、その倍数に近い場合にお薦めします。たとえば、パーティション
が 14 で問合せサーバーが 15 の場合などです。
注意 : 内部表がパーティション化されていない場合やパーティション
化キーで等価結合されていない場合、オプティマイザはこのヒントを
無視します。
なし対パーティション
外部表のパーティション化を使用して、内部表の行をマップします。
外部表は、結合キーでパーティション化する必要があります。このヒ
ントは、外部表のパーティションの数が問合せサーバーの数と等しい
か、その倍数に近い場合にお薦めします。たとえば、パーティション
が 14 で問合せサーバーが 15 の場合などです。
注意 : 外部表がパーティション化されていない場合やパーティション
化キーで等価結合されていない場合、オプティマイザはこのヒントを
無視します。
なし対なし
各問合せサーバーは、各表から 1 つずつ、一致するパーティションの
ペア間で結合操作を実行します。どちらの表も、結合キーで同一レベ
ル・パーティション化する必要があります。
例 : r と s の 2 つの表がハッシュ結合を使用して結合された場合は、ハッシュ配布を使用す
るヒントが次の問合せに組み込まれます。
SELECT /*+ORDERED PQ_DISTRIBUTE(s HASH, HASH) USE_HASH (s)*/ column_list
FROM r,s
WHERE r.c=s.c;
外部表 r をブロードキャストするには、問合せを次のようにします。
SELECT /*+ORDERED PQ_DISTRIBUTE(s BROADCAST, NONE) USE_HASH (s) */ column_list
FROM r,s
WHERE r.c=s.c;
17-38　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
PARALLEL_INDEX
PARALLEL_INDEX ヒントは、パーティション索引の索引レンジ・スキャンをパラレル化す
るために使用できる同時サーバーの数を指定します。
parallel_index_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。indexspec 構文の詳細は、17-9 ページの「複合索引ヒント
の指定方法」を参照してください。
整数値では、指定の索引の並列度を指定します。DEFAULT を指定するか、または値を指定
しないと、問合せコーディネータが初期化パラメータの設定を調べ、デフォルトの並列度を
判別します。
たとえば、次のようにします。
SELECT /*+ PARALLEL_INDEX(table1, index1, 3) */
この例では、3 つのパラレル実行プロセスが使用されます。
NO_PARALLEL_INDEX
NO_PARALLEL_INDEX ヒントは、索引の PARALLEL 属性の設定を上書きしてパラレル索引
スキャン操作を回避します。
no_parallel_index_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。indexspec 構文の詳細は、17-9 ページの「複合索引ヒント
の指定方法」を参照してください。
オプティマイザ・ヒント
17-39
オプティマイザ・ヒントの使用方法
注意 : NOPARALLEL_INDEX ヒントは使用されなくなりました。NO_
PARALLEL_INDEX ヒントを使用してください。
その他のヒント
この項ではその他のいくつかのヒントを説明します。
■
APPEND
■
NOAPPEND
■
CACHE
■
NOCACHE
■
PUSH_PRED
■
NO_PUSH_PRED
■
PUSH_SUBQ
■
NO_PUSH_SUBQ
■
QB_NAME
■
CURSOR_SHARING_EXACT
■
DRIVING_SITE
■
DYNAMIC_SAMPLING
■
SPREAD_MIN_ANALYSIS
APPEND
APPEND ヒントを使用すると、データベースがシリアル・モードで動作している場合にダイ
レクト・パス INSERT が使用可能になります。Enterprise Edition を使用していない場合、
データベースはシリアル・モードです。シリアル・モードでは従来の INSERT がデフォルト
であり、パラレル・モードではダイレクト・パス INSERT がデフォルトです。
ダイレクト・パス INSERT では、表に現在割り当てられている既存の領域を使用せず、表の
終わりにデータが付加されます。その結果、ダイレクト・パス INSERT は従来の INSERT よ
りかなり高速になる可能性があります。
append_hint::=
関連項目 : ダイレクト・パス・インサートの詳細は、『Oracle Database
管理者ガイド』を参照してください。
17-40　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
NOAPPEND
NOAPPEND ヒントを使用すると、INSERT 文の実行中にパラレル・モードを無効にして、従
来の INSERT を使用可能にできます。（従来の INSERT はシリアル・モードがデフォルトで
あり、ダイレクト・パス INSERT はパラレル・モードがデフォルトです。）
noappend_hint::=
CACHE
CACHE ヒントでは、全表スキャンが実行され、取得されたブロックが、バッファ・キャッ
シュ内で LRU リストの、最後に使用されたものの位置に配置されるように指定します。こ
のオプションは、小さい参照表の場合に役立ちます。
cache_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
次の例では、CACHE ヒントによって、表のデフォルトのキャッシュ仕様が上書きされます。
SELECT /*+ FULL (hr_emp) CACHE(hr_emp) */ last_name
FROM employees hr_emp;
NOCACHE
NOCACHE ヒントでは、全表スキャンが実行され、取得されたブロックが、バッファ・
キャッシュ内で LRU リストの、最初に使用されたものの位置に配置されるように指定しま
す。これは、バッファ・キャッシュ内のブロックの通常の動作です。
nocache_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
オプティマイザ・ヒント
17-41
オプティマイザ・ヒントの使用方法
SELECT /*+ FULL(hr_emp) NOCACHE(hr_emp) */ last_name
FROM employees hr_emp;
注意 : CACHE ヒントおよび NOCACHE ヒントは、V$SYSSTAT ビューに示
されているように、システム統計 table scans(long tables) および
table scans(short tables) に影響を与えます。
小規模表の自動キャッシュ 小規模表は、表 17-2 の基準に従って自動的にキャッシュされま
す。
表 17-2 表のキャッシュ基準
表サイズ
サイズ基準
キャッシュ
小規模
ブロックの数が 20 より少な
い、またはキャッシュされて
いるブロックの合計の 2% の
うち、大きいもの
STATISTICS_LEVEL が TYPICAL またはそれ以
上に設定されている場合、Oracle では、表ス
キャン履歴に応じて、表をキャッシュするかど
うかが判別されます。今後の表スキャンで
キャッシュされるブロックが見つかる可能性が
ある場合にのみ、表がキャッシュされます。
STATISTICS_LEVEL が BASIC に設定されてい
る場合、表はキャッシュされません。
中規模
小規模表よりも大きいが、
キャッシュされているブロッ
クの合計が 10% より少ない
Oracle では、表スキャンの基礎およびワーク
ロード履歴に表をキャッシュするかどうかが判
別されます。今後の表スキャンでキャッシュさ
れるブロックが見つかる可能性がある場合にの
み、表がキャッシュされます。
大規模
キャッシュされているブロッ
クの合計が 10% より大きい
キャッシュされません
小規模表の自動キャッシュは、CACHE 属性で作成または変更された表に対しては使用禁止で
す。
PUSH_PRED
PUSH_PRED ヒントを使用すると、述語結合が強制的にビューへプッシュされます。
push_pred_hint::=
17-42　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ NO_MERGE(v) PUSH_PRED(v) */ *
FROM employees e,
(SELECT manager_id
FROM employees
) v
WHERE e.manager_id = v.manager_id(+)
AND e.employee_id = 100;
引数を指定せずに PUSH_PRED ヒントを使用するときは、ビュー問合せブロック内に挿入し
てください。ビュー名を引数として指定して PUSH_PRED を使用するときは、周囲の問合せ
に挿入してください。
NO_PUSH_PRED
NO_PUSH_PRED ヒントを使用すると、述語結合がビューへプッシュされません。
no_push_pred_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ NO_MERGE(v) NO_PUSH_PRED(v) */ *
FROM employees e,
(SELECT manager_id
FROM employees
) v
WHERE e.manager_id = v.manager_id(+)
AND e.employee_id = 100;
引数を指定せずに NO_PUSH_PRED ヒントを使用するときは、ビュー問合せブロック内に挿
入してください。ビュー名を引数として指定して NO_PUSH_PRED を使用するときは、周囲
の問合せに挿入してください。
オプティマイザ・ヒント
17-43
オプティマイザ・ヒントの使用方法
PUSH_SUBQ
PUSH_SUBQ ヒントを使用すると、マージされていない副問合せは、実行計画の最初に使用
可能なステップで評価されます。一般に、マージされていない副問合せは、実行計画の最後
のステップとして実行されます。副問合せのコストが相対的に低く、副問合せが行数を大幅
に減少させる場合には、パフォーマンスが向上し、副問合せの評価が速くなります。
このヒントは、副問合せがリモート表に適用されている場合、またはマージ結合を使用して
結合されたリモート表に適用されている場合は、効果がありません。
push_subq_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
NO_PUSH_SUBQ
NO_PUSH_SUBQ ヒントを使用すると、マージされていない副問合せは、実行計画の最後の
ステップとして評価されます。副問合せのコストが相対的に高く、副問合せにより行数が大
幅に減少されない場合には、パフォーマンスが向上し、副問合せを最後に評価します。
no_push_subq_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
QB_NAME
問合せブロックの名前を定義するには、QB_NAME ヒントを使用します。この名前を別の問
合せブロックで使用し、名前が付けられた問合せブロックに含まれる表をヒントで指定でき
ます。
qb_name::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。
2 つ以上の問合せブロックの名前が同じである場合、または同じ問合せブロックが異なる名
前で 2 度ヒント指定されている場合、これらを参照している名前およびヒントはすべて無視
17-44　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
されます。このヒントを使用して名前が付けられていない問合せブロックには、システム生
成の一意の名前が付けられます。これらの名前は PLAN TABLE に表示でき、問合せブロッ
クまたは問合せブロックのヒント内で表のヒント指定にも使用できます。
たとえば、次のようにします。
SELECT /*+ QB_NAME(qb) FULL(@qb e) */ employee_id, last_name
FROM employees e
WHERE last_name = 'Smith';
CURSOR_SHARING_EXACT
安全であれば、Oracle で SQL 文のリテラルをバインド変数に置き換えられます。この処理
は、CURSOR_SHARING 起動パラメータで制御されます。CURSOR_SHARING_EXACT ヒント
を使用すると、この処理がオフに切り替えられます。つまり、リテラルをバインド変数に置
き換える処理をしなくても SQL 文が実行されます。
cursor_sharing_exact_hint::=
DRIVING_SITE
DRIVING_SITE ヒントを使用すると、Oracle が選択したサイトとは別のサイトで表に問合
せを実行できます。
driving_site_hint::=
queryblock 構文の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を
参照してください。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指
定方法」を参照してください。
たとえば、次のようにします。
SELECT /*+ DRIVING_SITE(departments) */ *
FROM employees, departments@rsite
WHERE employees.department_id = departments.department_id;
この問合せがヒントなしで実行されると、departments の行はローカル・サイトに送ら
れ、結合はそこで実行されます。ヒントを使用して実行されると、employees の行はリ
モート・サイトに送られます。そこで、問合せが実行されて結果がローカル・サイトに戻さ
れます。
このヒントは、分散問合せの最適化を使用する場合に役立ちます。
オプティマイザ・ヒント
17-45
オプティマイザ・ヒントの使用方法
DYNAMIC_SAMPLING
DYNAMIC_SAMPLING ヒントを使用して、より正確な述語の選択性および表と索引に関する
統計を判別することにより、動的サンプリングを制御してサーバーのパフォーマンスを改善
できます。DYNAMIC_SAMPLING の値は 0 から 10 までの値に設定できます。レベルが高く
なるにつれ、コンパイラで動的サンプリングに対してさらに多くの作業が行われ、より広く
適用されます。サンプリングでは、表を指定しない場合、カーソル・レベルがデフォルトと
なります。
dynamic_sampling_hint::=
integer は、0 から 10 の値で、サンプリングの度合いを示しています。queryblock 構文
の詳細は、17-5 ページの「ヒントにおける問合せブロックの指定方法」を参照してくださ
い。tablespec 構文の詳細は、17-7 ページの「グローバル表のヒントの指定方法」を参照
してください。
カーディナリティ統計が存在する場合、それが使用されます。存在しない場合、DYNAMIC_
SAMPLING ヒントはカーディナリティ統計を見積もるための動的サンプリングを使用可能に
します。
特定の表に動的サンプリングを適用するには、次のヒントのフォームを使用します。
SELECT /*+ dynamic_sampling(employees 1) */ *
FROM employees
WHERE ..,
表ヒントがある場合、表が分析済で表に述語がない場合を除いて、動的サンプリングが使用
されます。たとえば、employees が分析された場合、次の問合せでは、動的サンプリング
が発生しません。
SELECT /*+ dynamic_sampling(e 1) */ count(*)
FROM employees e;
カーディナリティ統計が存在する場合、それが使用されます。述語がある場合、動的サンプ
リングが表ヒントを使用して行われ、カーディナリティは見積もられません。
関連項目 : 動的サンプリングと設定できるサンプリング・レベルの詳細
は、15-15 ページの「動的サンプリングを使用した統計の見積り」を参照
してください。
17-46　Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの使用方法
SPREAD_MIN_ANALYSIS
このヒントによって、ルールのコンパイル時間の最適化の一部（主にスプレッドシート上の
詳細な依存性グラフ分析）が省略されます。スプレッドシートのアクセス構造を選択的に移
入するためのフィルタの作成および制限されたルールのプルーニングなど、一部の最適化は
引き続き使用されます。
ルール数がかなり多い（数百以上など）場合、スプレッドシート分析が非常に長くなる場合
があるため、このヒントを使用するとコンパイル時間が短縮されます。
spread_min_analysis_hint::=
オプティマイザ・ヒント
17-47
オプティマイザ・ヒントの使用方法
17-48　Oracle Database パフォーマンス・チューニング・ガイド
18
プラン・スタビリティの使用方法
この章では、プラン・スタビリティを使用してパフォーマンス特性を保持する方法を説明し
ます。プラン・スタビリティは、新規の Oracle リリースへアップグレードする際に、ルール
ベース・オプティマイザから問合せオプティマイザへ移行するときにも役立ちます。
この章には次の項があります。
■
実行計画を保持するためのプラン・スタビリティの使用
■
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用
プラン・スタビリティの使用方法
18-1
実行計画を保持するためのプラン・スタビリティの使用
実行計画を保持するためのプラン・スタビリティの使用
プラン・スタビリティを使用すると、データベース環境を変更してもアプリケーションのパ
フォーマンス特性に影響が及ぶのを防ぐことができます。このような変更には、オプティマ
イザ統計の変更、オプティマイザ・モード設定の変更および SORT_AREA_SIZE や BITMAP_
MERGE_AREA_SIZE などのメモリー構造のサイズに影響するパラメータの変更があります。
プラン・スタビリティは、アプリケーションでパフォーマンスが変化してしまうリスクを冒
すことができない場合に特に役立ちます。
プラン・スタビリティは、実行計画をストアド・アウトラインに保持します。アウトライン
は、SQL 文に関連付けられたオプティマイザ・ヒントのセットとして実装されます。文に対
してアウトラインを使用できる場合、Oracle ではストアド・ヒントが自動的に考慮され、こ
れらのヒントに従って実行計画の生成が試行されます。
Oracle では、1 つまたはすべての SQL 文についてパブリックまたはプライベート・ストア
ド・アウトラインを作成できます。ストアド・アウトラインを使用可能にすると、オプティ
マイザはアウトラインから同じ実行計画を生成します。アウトラインをグループ化してカテ
ゴリに分け、Oracle が使用するカテゴリを制御することによって、アウトラインの管理と配
置を単純化できます。
Oracle がストアド・アウトラインに保持する計画は、システム構成または統計の変更にかか
わらず一貫しています。また、ストアド・アウトラインを使用すると、以降の Oracle リ
リースでオプティマイザが変更されても、生成した実行計画の安定性は保たれます。
注意 : 市場を通じて多量に販売するアプリケーションを開発する場合は、
ストアド・アウトラインを使用すると、すべての顧客が確実に同じ実行計
画にアクセスするようにできます。
プラン・スタビリティでのヒントの使用
Oracle ではヒントを使用してストアド・プランを記録するため、プラン・スタビリティが実
行計画を制御する度合いは、Oracle のヒント・メカニズムが実行計画を制御する度合いに
よって決定します。
SQL テキストは、そのストアド・アウトラインと 1 対 1 で対応しています。異なるリテラル
を述語に指定すると、異なるアウトラインが適用されます。これを避けるには、アプリケー
ションのリテラルをバインド変数に置き換えてください。
関連項目 : リテラルをシステム生成のバインド変数に置き換えて、SQL
を共有するように類似文を設定できます。これは、CREATE OUTLINE 文で
なく CREATE_STORED_OUTLINES パラメータを使用してアウトラインが
生成されている場合のプラン・スタビリティにかぎり有効です。また、ア
ウトラインは CURSOR_SHARING パラメータを SIMILAR に設定して作成
してあり、アウトラインを使用するときにも、このパラメータを
SIMILAR に設定する必要があります。詳細は、第 7 章「メモリーの構成
と使用方法」を参照してください。
18-2　Oracle Database パフォーマンス・チューニング・ガイド
実行計画を保持するためのプラン・スタビリティの使用
プラン・スタビリティは、パフォーマンスに問題がない場合、実行計画の保持に依存しま
す。しかし、多くの環境では、日付やオーダー番号などのデータ・タイプの属性はすぐに変
わる可能性があります。そのような場合に実行計画を永続的に使用すると、データ特性の変
更につれて、パフォーマンスが低下していく結果となります。
つまり、動的な環境では、計画の保持に依存するという技法は、問合せの最適化の目的に反
することになります。問合せの最適化では、データの状態を正確に反映した統計に基づいて
実行計画の生成が試みられます。したがって、プラン・スタビリティを制御する必要性と、
データ特性の変更への適合性を持つオプティマイザの利点とのバランスを考慮する必要があ
ります。
アウトラインでのヒントの使用方法
アウトラインは主に、特定の SQL 文の実行計画生成に対するオプティマイザの結果に相当
するヒントのセットからなります。Oracle によってアウトラインが作成されると、プラン・
スタビリティは実行計画の生成に使用したのと同じデータを使用して最適化の結果を調べま
す。つまり、Oracle は実行計画そのものではなく実行計画への入力を使用して、アウトライ
ンを生成します。
注意 : Oracle は、SYS 表領域に USER_OUTLINES ビューと USER_
OUTLINE_HINTS ビューを、それぞれ OL$ 表と OL$HINTS 表のデータに
基づいて作成します。OL$、OL$HINTS および OL$NODES 表の直接操作は
禁止されています。
SQL 文にヒントを組み込むことはできますが、その結果が Oracle による
アウトラインの使用方法に影響することはありません。Oracle は、ヒント
を使用して修正された SQL 文を、アウトラインに格納されている元の
SQL 文とは異なるものとして認識します。
アウトラインの格納
アウトライン・データは、OL$、OL$HINTS および OL$NODES の各表に格納します。アウト
ラインは、削除しなければ無期限に保持されます。
実行計画がキャッシュ内に存在しているかどうかの識別には、SQL テキストのみでなくアウ
トラインのカテゴリ名が使用されます。アウトラインが実行計画のキャッシュに及ぼす影響
はこの点に限定されています。これにより、別のカテゴリの下でコンパイルした SQL 文を
実行するときに、Oracle が、それとは別のあるカテゴリの下でコンパイルした実行計画を使
用することはありません。
プラン・スタビリティの使用方法
18-3
実行計画を保持するためのプラン・スタビリティの使用
プラン・スタビリティを使用可能にする方法
アウトラインを適切に機能させるためには、接尾辞 _ENABLED で終わるパラメータをはじめ
とするいくつかのパラメータ設定が、実行環境全体で一貫したものになっている必要があり
ます。該当するパラメータは次のとおりです。
■
QUERY_REWRITE_ENABLED
■
STAR_TRANSFORMATION_ENABLED
■
OPTIMIZER_FEATURES_ENABLE
提供されるパッケージを使用したストアド・アウトラインの管理
DBMS_OUTLN および DBMS_OUTLN_EDIT パッケージによって、ストアド・アウトラインと
そのアウトライン・カテゴリの管理に使用するプロシージャが提供されます。
ユーザーは DBMS_OUTLN を実行するために EXECUTE_CATALOG_ROLE ロールを必要としま
すが、パブリックには DBMS_OUTLN_EDIT に対する実行権限があります。DBMS_OUTLN_
EDIT パッケージは、実行者権限のパッケージです。
便利な DBMS_OUTLN および DBMS_OUTLN_EDIT プロシージャのいくつかを次に示します。
■
CLEAR_USED: 指定されたアウトラインを消去します。
■
DROP_BY_CAT: 指定されたカテゴリに属するアウトラインを削除します。
■
■
■
UPDATE_BY_CAT: 指定されたカテゴリのアウトラインのカテゴリを新規の指定カテゴリ
に変更します。
EXACT_TEXT_SIGNATURES: テキストが完全一致するスキームに従って、アウトライ
ン・シグネチャを計算します。
GENERATE_SIGNATURE: 指定された SQL テキストのシグネチャを生成します。
関連項目 :
■
■
DBMS_OUTLN パッケージ・プロシージャの使用方法の詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』
を参照してください。
DBMS_OUTLN_EDIT パッケージ・プロシージャの使用方法の詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』
を参照してください。
18-4　Oracle Database パフォーマンス・チューニング・ガイド
実行計画を保持するためのプラン・スタビリティの使用
アウトラインの作成
すべての SQL 文に対して自動的にアウトラインを作成することも、特定の SQL 文に対して
自分でアウトラインを作成することもできます。そのどちらの場合においても、アウトライ
ンの入力はオプティマイザから導出されます。
初期化パラメータ CREATE_STORED_OUTLINES を TRUE に設定すると、ストアド・アウト
ラインは Oracle によって自動的に作成されます。パラメータを有効にすると、Oracle はコ
ンパイルされた SQL 文すべてにアウトラインを作成します。CREATE OUTLINE 文を使用し
て、特定の文に対するストアド・アウトラインを作成することもできます。
プライベート・アウトラインを作成または編集する場合、アウトライン・データは SYSTEM
スキーマのグローバル一時表に書き込まれます。これらの表は、OL$、OL$HINTS および
OL$NODES の各シノニムによりアクセスできます。
注意 : アウトラインを作成するスキーマに CREATE ANY OUTLINE 権限が
あることを必ず確認してください。この権限が存在しない場合は、
CREATE_STORED_OUTLINE 初期化パラメータをオンにしても、アプリ
ケーションの実行後にデータベース内でアウトラインを見つけることはで
きません。
また、CREATE_STORED_OUTLINES 初期化パラメータが有効で、実行中
のアプリケーションに多数のリテラル SQL 文がある場合、デフォルトの
システム表領域がすべて使用される可能性があります。その場合は、
DBMS_OUTLN.DROP_UNUSED プロシージャを使用して、これらのリテラル
SQL のアウトラインを削除します。
関連項目 :
■
■
■
■
CREATE OUTLINE 文の詳細は、
『Oracle Database SQL リファレンス』
を参照してください。
DBMS_OUTLN および DBMS_OUTLN_EDIT の各パッケージの詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』
を参照してください。
ルールベース・オプティマイザから問合せオプティマイザに移行する
方法の詳細は、18-12 ページの「RBO から問合せオプティマイザへの
移行」を参照してください。
使用しやすいグラフィカル・インタフェースでストアド・アウトライ
ンの作成、編集、削除および管理を行う Outline Management および
Outline Editor の各ツールについては、『Oracle Enterprise Manager 概
要』を参照してください。
プラン・スタビリティの使用方法
18-5
実行計画を保持するためのプラン・スタビリティの使用
ストアド・アウトラインにカテゴリ名を使用する方法
管理タスクを単純にするために、アウトラインをカテゴリに分類できます。CREATE
OUTLINE 文を使用すると、カテゴリを指定できます。指定されていなければ、DEFAULT カ
テゴリが選択されます。同様に、CREATE_STORED_OUTLINES 初期化パラメータでカテゴ
リの名前を指定できますが、このパラメータに true を指定すると DEFAULT カテゴリ内に
アウトラインを作成できます。
CREATE_STORED_OUTLINES 初期化パラメータを使用してカテゴリ名を指定すると、その
後で作成されるアウトラインはすべて Oracle によってそのカテゴリに割り当てられます。
この割当ては、そのカテゴリ名がリセットされるまで変更されません。アウトラインの生成
を中断するには、このパラメータを false に設定します。
CREATE_STORED_OUTLINES を true に設定するか、またはカテゴリ名を使用しない
CREATE OUTLINE 文を使用した場合は、Oracle はアウトラインを DEFAULT のカテゴリ名に
割り当てます。
ストアド・アウトラインの使用および編集
ストアド・アウトラインの使用をアクティブにした場合、Oracle は常に問合せオプティマイ
ザを使用します。これは、アウトラインがヒントに依存し、そのヒントのほとんどが効率性
のために問合せオプティマイザを必要とするからです。
Oracle が SQL 文をコンパイルする際にストアド・アウトラインを使用するには、システム・
パラメータ USE_STORED_OUTLINES を true またはカテゴリ名に設定します。USE_
STORED_OUTLINES を true に設定すると、Oracle はアウトラインを default カテゴリで
使用します。USE_STORED_OUTLINES パラメータを使用してカテゴリを指定すると、USE_
STORED_OUTLINES パラメータを別のカテゴリ名に再設定するか、USE_STORED_
OUTLINES を false に設定してアウトラインの使用を中断するまで、Oracle はそのカテゴ
リでアウトラインを使用します。カテゴリ名を指定しているときにそのカテゴリ内に SQL
文と一致するアウトラインが見つからない場合、Oracle は default カテゴリ内のアウトラ
インを検索します。
カテゴリ内のすべてのアウトラインではなく特定のアウトラインを使用する場合、ALTER
OUTLINE 文を使用して特定のアウトラインを使用可能にします。特定のアウトラインを除
くカテゴリ内のアウトラインを使用する場合、ALTER OUTLINE 文を使用して、使用されて
いるカテゴリ内の特定のアウトラインを使用禁止にします。ALTER OUTLINE 文により、ス
トアド・アウトラインの名前の変更、別のカテゴリへの再割当てまたは再生成も可能です。
関連項目 : ALTER OUTLINE 文の詳細は、『Oracle Database SQL リファ
レンス』を参照してください。
指定されたアウトラインは、アウトラインを持つ SQL 文のコンパイルのみを制御します。
USE_STORED_OUTLINES を false に設定すると、Oracle はアウトラインを使用しません。
USE_STORED_OUTLINES を false に設定し、CREATE_STORED_OUTLINES を true に設
定した場合、Oracle はアウトラインを作成しますが、使用はしません。
18-6　Oracle Database パフォーマンス・チューニング・ガイド
実行計画を保持するためのプラン・スタビリティの使用
USE_PRIVATE_OUTLINES パラメータを使用すると、プライベート・アウトラインの使用を
制御できます。プライベート・アウトラインは、現行のセッション内のみで見られるアウト
ラインで、そのデータは現行の解析スキーマ内に常駐します。このアウトラインに対して
行った変更はシステム上の他のセッションからは見られず、文のコンパイルへの適用は、現
行セッションで USE_PRIVATE_OUTLINES パラメータを指定することによってのみ行えま
す。編集内容をパブリック領域に保存するように明示的に選択した場合のみ、他のユーザー
にも編集内容が表示されます。
オプティマイザは通常、問合せに最適な計画を選択しますが、ユーザーが実行環境に関して
理解している事柄と、オプティマイザが従う経験則的方法とが整合しない場合があります。
アウトラインを直接編集することで、アプリケーションを変更しなくても SQL 問合せを
チューニングできます。
USE_PRIVATE_OUTLINES パラメータを有効にし、アウトラインを使用する SQL 文を発行
すると、オプティマイザは、USE_STORED_OUTLINES を有効にした場合に使用されるパブ
リック領域ではなく、セッションのプライベート領域からアウトラインを取り出します。
セッションのプライベート領域にアウトラインが存在しない場合、オプティマイザは、文の
コンパイルにアウトラインを使用しません。
CREATE OUTLINE 文はすべて、CREATE ANY OUTLINE 権限が必要です。FROM 句を指定する
場合は、SELECT 権限も必要です。この権限は、アウトラインを使用する文に関連する SQL
テキストとヒント・テキストを表示する権限を持つユーザーのみに与える必要があります。
このロールは、CREATE OUTLINE FROM コマンドに必要です。コマンドの発行者がアウトラ
インの所有者でもある場合は、このロールは不要です。
編集セッションを開始するときには、USE_PRIVATE_OUTLINES を、編集するアウトライン
が属するカテゴリに設定する必要があります。編集を終了するときには、このパラメータを
false に設定して、USE_STORED_OUTLINES パラメータに従って、アウトラインを参照す
るように元に戻しておく必要があります。
注意 : USE_STORED_OUTLINES および USE_PRIVATE_OUTLINES パラ
メータは、システムまたはセッション固有です。これらは初期化パラメー
タではありません。これらのパラメータの詳細は、『Oracle Database SQL
リファレンス』を参照してください。
Oracle Enterprise Manager の Outline Editor を使用して、アウトラインを更新することもで
きます。
関連項目 : Oracle Enterprise Manager GUI ツールの詳細は、
『Oracle
Enterprise Manager 概要』を参照してください。
プラン・スタビリティの使用方法
18-7
実行計画を保持するためのプラン・スタビリティの使用
アウトラインの編集例
アウトライン ol1 を編集すると仮定します。手順は次のとおりです。
1.
アウトラインを使用する文を実行できるスキーマに接続し、CREATE ANY OUTLINE およ
び SELECT 権限が与えられているかどうかを確認します。
2.
次のコードを使用して、編集するアウトラインのクローンをプライベート領域に作成し
ます。
CREATE PRIVATE OUTLINE p_ol1 FROM ol1;
3.
Enterprise Manager の Outline Editor でアウトラインを編集するか、ローカルの
OL$HINTS 表に問い合せて、適切なヒント行に対して DML を実行する方法で手動でア
ウトラインを編集します。結合順序を変更する場合、適切な LEADING ヒントを変更し
ます。17-30 ページの「LEADING」を参照してください。
4.
アウトラインを手動で編集する場合は、次のいわゆる認証文でストアド・アウトライン
定義を再同期化します。
CREATE PRIVATE OUTLINE p_ol1 FROM PRIVATE p_ol1;
これは、DBMS_OUTLN_EDIT.REFRESH_PRIVATE_OUTLINE または ALTER SYSTEM
FLUSH SHARED_POOL を使用して行うこともできます。
5.
編集内容をテストします。USE_PRIVATE_OUTLINES=TRUE と設定し、アウトライン文
を発行するか、文で EXPLAIN PLAN を実行します。
6.
パブリックで使用するためにこれらの編集内容を保持する場合は、次の文で編集内容を
公開します。
CREATE OR REPLACE OUTLINE ol1 FROM PRIVATE p_ol1;
7.
次のように設定してプライベート・アウトラインとしての使用を無効にします。
USE_PRIVATE_OUTLINES=FALSE
関連項目 :
■
■
■
CREATE_STORED_OUTLINES 初期化パラメータを使用する場合の構文
については、
『Oracle Database リファレンス』を参照してください。
USE_STORED_OUTLINES および USE_PRIVATE_OUTLINES パラメー
タを使用する場合の SQL 構文については、『Oracle Database SQL リ
ファレンス』を参照してください。
DBMS_OUTLN および DBMS_OUTLN_EDIT の各パッケージの詳細は、
『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』
を参照してください。
18-8　Oracle Database パフォーマンス・チューニング・ガイド
実行計画を保持するためのプラン・スタビリティの使用
アウトラインが使用されているかどうかを知る方法
アウトラインが V$SQL で使用されているかどうかをテストできます。SQL 文で OUTLINE_
CATEGORY 列の問合せを行います。アウトラインが適用されている場合は、そのアウトライ
ンが属しているカテゴリが列に挿入されます。適用されていない場合は、NULL になります。
OUTLINE_SID 列は、この特定のカーソルがパブリック・アウトラインを使用しているか
（値は 0）
、プライベート・アウトラインを使用しているか（そのアウトラインを使用してい
るセッションの SID）を知らせます。
たとえば、次のようにします。
SELECT OUTLINE_CATEGORY, OUTLINE_SID
FROM V$SQL
WHERE SQL_TEXT LIKE 'SELECT COUNT(*) FROM emp%';
アウトライン・データの照会
次のビューから、データ・ディクショナリに格納されているアウトラインおよびそれに関連
するヒント・データの情報にアクセスできます。
■
USER_OUTLINES
■
USER_OUTLINE_HINTS
■
ALL_OUTLINES
■
ALL_OUTLINE_HINTS
■
DBA_OUTLINES
■
DBA_OUTLINE_HINTS
アウトライン・カテゴリが mycat である USER_OUTLINES ビューからアウトライン情報を
取得するには、次の構文を使用します。
SELECT NAME, SQL_TEXT
FROM USER_OUTLINES
WHERE CATEGORY='mycat';
その結果、カテゴリ mycat 内の全アウトラインの名前とテキストが表示されます。
アウトライン name1 に対して生成されたすべてのヒントを表示するには、次の構文を使用
します。
SELECT HINT
FROM USER_OUTLINE_HINTS
WHERE NAME='name1';
プラン・スタビリティの使用方法
18-9
実行計画を保持するためのプラン・スタビリティの使用
互換性、形式およびアウトラインが使用可能かどうかについて、_OUTLINES ビューのフラ
グを確認できます。たとえば、アウトラインが使用可能かどうかを判断するには、USER_
OUTLINES ビューの ENABLED フィールドを確認します。
SELECT NAME, CATEGORY, ENABLED FROM USER_OUTLINES;
関連項目 : アウトラインに関連するビューの詳細は、『Oracle Database
リファレンス』を参照してください。
アウトライン表の移動
Oracle は、USER_OUTLINES ビューと USER_OUTLINE_HINTS ビューを、それぞれ OL$ 表
と OL$HINTS 表のデータに基づいて作成します。OUTLN と呼ばれるスキーマを使用して、
SYSTEM 表領域にこれらの表と OL$NODES 表も作成します。アウトラインが SYSTEM 表領域
の領域を過剰に使用している場合は、アウトラインを移動できます。そのためには、次の手
順を使用して別の表領域を作成し、そこにアウトライン表を移動します。
1.
CREATE_STORED_OUTLINES パラメータがオンであり、かつ、実行中のアプリケー
ションに多数のリテラル SQL 文がある場合、デフォルトのシステム表領域すべてが使
用される可能性があります。その場合は、DBMS_OUTLN.DROP_UNUSED プロシージャを
使用して、これらのリテラル SQL アウトラインを削除します。
2.
Oracle Export Utility を使用して、OL$、OL$HINTS および OL$NODES の各表をエクス
ポートします。
EXP OUTLN/outln_password
FILE = exp_file TABLES = 'OL$' 'OL$HINTS' 'OL$NODES'
3.
SQL*Plus を起動し、データベースに接続します。
CONNECT OUTLN/outln_password;
4.
以前の OL$ 表、OL$HINTS 表および OL$NODES 表を削除します。
DROP TABLE OL$;
DROP TABLE OL$HINTS;
DROP TABLE OL$NODES;
5.
表に新しい表領域を作成します。
CONNECT SYSTEM/system_password;
CREATE TABLESPACE outln_ts
DATAFILE 'tspace.dat' SIZE 2M
DEFAULT STORAGE (INITIAL 10K NEXT 20K MINEXTENTS 1 MAXEXTENTS 999
PCTINCREASE 10)
ONLINE;
18-10　Oracle Database パフォーマンス・チューニング・ガイド
実行計画を保持するためのプラン・スタビリティの使用
6.
次の文を入力して、デフォルトの表領域を変更します。
ALTER USER OUTLN DEFAULT TABLESPACE outln_ts;
7.
OUTLN_TS 表領域に強制的にインポートするには、OUTLN ユーザーについて、SYSTEM
表領域の割当て制限を 0KB に設定します。また、UNLIMITED TABLESPACE 権限、お
よび RESOURCE ロールなどの、無制限の表領域権限または割当て制限を持つすべての
ロールを取り消す必要があります。OUTLN 表領域の割当て制限を設定します。
8.
OL$ 表、OL$HINTS 表および OL$NODES 表をインポートします。
IMP OUTLN/outln_password
FILE = exp_file TABLES = (OL$, OL$HINTS, OL$NODES)
インポート・プロセスが完了すると、OUTLN という名前のスキーマに OL$ 表、OL$HINTS
表および OL$NODES 表が再作成され、OUTLN_TS という新しい表領域に配置されます。
このプロセスが完了した後、前のステップで削除された権限およびロールを追加すること
で、OUTLN ユーザーの表領域割当て制限を適切に調整できます。
関連項目 :
■
■
Export および Import のユーティリティの使用方法は、『Oracle
Database ユーティリティ』を参照してください。Import Utility の説
明の箇所にある表領域の再編成に関する項に注意してください。
DBMS_OUTLN パッケージの使用方法の詳細は、
『PL/SQL パッケージ・
プロシージャおよびタイプ・リファレンス』を参照してください。
プラン・スタビリティの使用方法
18-11
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用
問合せオプティマイザのアップグレードによるプラン・スタビ
リティの使用
この項では、問合せオプティマイザの機能を利用してパフォーマンスを大幅に改善する手順
を説明します。プラン・スタビリティは、システムが目標としている、パフォーマンスのよ
い実行計画を保ちながら、一方で、残りの SQL 文に対する問合せオプティマイザの新機能
の利点も利用する手段を提供します。
元の実行計画の正確な再現が保証されない SQL 文および機能のクラスもありますが、プラ
ン・スタビリティは移行プロセスにおける非常に便利な要素です。移行前に、アプリケー
ションの SQL 文のすべてまたは大部分が取得されるまで、実行計画のアウトライン取得を
オンにする必要があります。移行後に、特定の SQL 文でパフォーマンスの問題がある場合
は、以前の動作を元に戻す方法として、この文に対するストアド・アウトラインの使用をオ
ンにできます。ストアド・アウトラインの使用は、変化するデータ・プロパティに計画が適
応できないため、移行関連のパフォーマンスの問題を解決する最善の方法ではない場合があ
りますが、こうした問題への対処に使用できる数あるテクニックの 1 つです。
この項で説明する項目は次のとおりです。
■
RBO から問合せオプティマイザへの移行
■
問合せオプティマイザを使用している場合の新規 Oracle リリースへの移行
RBO から問合せオプティマイザへの移行
ルールベース・オプティマイザを使用して開発したアプリケーションの場合、パフォーマン
スを最適化するために SQL 文の手動チューニングに多大な作業量を投入している場合があ
ります。プラン・スタビリティを使用すると、ルールベースの最適化から問合せの最適化へ
アップグレードする際にアプリケーションの動作を保持することによって、すでにパフォー
マンス・チューニングに投入した作業を生かすことができます。
問合せの最適化に切り替える前にアプリケーションのアウトラインを作成すると、ルール
ベース・オプティマイザで生成した計画を使用しながら、切替え後に新しく作成されたアプ
リケーションで生成した文で問合せの計画を使用できます。アプリケーションのアウトライ
ンを作成および使用するには、次のプロセスを実行します。
注意 :
い。
1.
この手順をよく読んで、内容を十分理解してから実行してくださ
アウトラインを作成するスキーマに CREATE ANY OUTLINE 権限があることを確認しま
す。たとえば、SYS からは次のようになります。
GRANT CREATE ANY OUTLINE TO user-name
18-12　Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用
2.
次のような構文を実行してアウトライン・カテゴリを指定します。ここでは、例として
RBOCAT アウトライン・カテゴリを指定します。
ALTER SESSION SET CREATE_STORED_OUTLINES = rbocat;
3.
重要な SQL 文すべてにストアド・アウトラインを獲得できるよう十分に時間をとって
アプリケーションを実行します。
4.
アウトライン生成を中断します。
ALTER SESSION SET CREATE_STORED_OUTLINES = FALSE;
5.
DBMS_STATS パッケージを使用して統計を収集します。
6.
パラメータ OPTIMIZER_MODE を CHOOSE に変更します。
7.
次の構文を入力して、Oracle がカテゴリ RBOCAT のアウトラインを使用するようにしま
す。
ALTER SESSION SET USE_STORED_OUTLINES = rbocat;
8.
アプリケーションを実行します。
プラン・スタビリティの制約上の理由から、このアプリケーションの SQL 文のアクセ
ス・パスは変更しないようにしてください。
注意 : 手順 2 で問合せが実行されなかった場合は、問合せの最適化に切
り替えた後も、以前の問合せの動作が獲得される可能性があります。その
場合は、オプティマイザ・モードを RULE に変更し、問合せのアウトライ
ンを作成してから、オプティマイザ・モードを再び CHOOSE に戻します。
問合せオプティマイザを使用している場合の新規 Oracle リリースへの移行
問合せの最適化を使用していて、新しい Oracle リリースにアップグレードする場合は、オ
プティマイザの変更に伴って変更された実行計画がいくつかの SQL 文に存在する可能性が
常にあります。このような変更によりパフォーマンスが向上しますが、アプリケーションに
よっては、パフォーマンスがすでに十分であるため、動作の変更は不要なリスクと考える場
合もあります。このようなアプリケーションに対しては、次の手順により、アップグレード
前にアウトラインを作成します。
注意 :
い。
この手順をよく読んで、内容を十分理解してから実行してくださ
プラン・スタビリティの使用方法
18-13
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用
1.
次の構文を入力して、アウトラインを作成できるようにします。
ALTER SESSION SET CREATE_STORED_OUTLINES = ALL_QUERIES;
2.
重要な SQL 文すべてにストアド・アウトラインを獲得できるよう十分に時間をとって
アプリケーションを実行します。
3.
次の構文を入力して、アウトラインの生成を中断します。
ALTER SESSION SET CREATE_STORED_OUTLINES = FALSE;
4.
新しいバージョンの RDBMS に本番システムをアップグレードします。
5.
アプリケーションを実行します。
アップグレード後は、ストアド・アウトラインを使用可能にすることもできますし、あるい
は、アップグレード後にパフォーマンスの低下を示す文があれば格納されていたアウトライ
ンをバックアップとして使用することもできます。
バックアップとして使用する場合は、次のようにして、問題のある文にストアド・アウトラ
インを使用できます。
1.
問題のある SQL 文それぞれについて、関連するストアド・アウトラインの CATEGORY
を次のようなカテゴリ名に変更します。
ALTER OUTLINE outline_name CHANGE CATEGORY TO problemcat;
2.
次の構文を入力して、Oracle がカテゴリ problemcat のアウトラインを使用するよう
にします。
ALTER SESSION SET USE_STORED_OUTLINES = problemcat;
テスト・システムでのアップグレード
本番システムとは別に、テスト・システムを用意すれば、アップグレードとあわせてオプ
ティマイザの動作を試すのに役立ちます。インポートとエクスポートを使用して、本番シス
テムからテスト・システムへ統計を移行できます。それにより、テスト・システムの表を
データで満たす必要が少なくなります。
アウトラインはカテゴリごとにシステム間で移動できます。たとえば、problemcat カテゴ
リにアウトラインを作成した後、問合せベースのエクスポート・オプションを使用してカテ
ゴリごとにエクスポートします。これは、ソース・データベース内のアウトラインをすべて
エクスポートするのでなく、選択したアウトラインのみをあるデータベースから別のデータ
ベースにエクスポートするうえで、便利で効率的な方法です。これを行うには、次の文を発
行します。
EXP OUTLN/outln_password FILE=exp-file TABLES= 'OL$' 'OL$HINTS' 'OL$NODES'
QUERY='WHERE CATEGORY="problemcat"'
18-14　Oracle Database パフォーマンス・チューニング・ガイド
19
EXPLAIN PLAN の使用方法
この章では、実行計画について紹介し、SQL 文 EXPLAIN PLAN を解説し、その出力の解釈
方法を説明します。さらに、アプリケーションのパフォーマンス特性を制御するアウトライ
ンを管理するプロシージャを示します。
この章には次の項があります。
■
EXPLAIN PLAN について
■
PLAN_TABLE 出力表
■
EXPLAIN PLAN の実行
■
PLAN_TABLE 出力の表示
■
EXPLAIN PLAN 出力の読み方
■
EXPLAIN PLAN によるパラレル実行の表示
■
EXPLAIN PLAN によるビットマップ索引の表示
■
EXPLAIN PLAN によるパーティション・オブジェクトの表示
■
PLAN_TABLE 列
関連項目 :
■
■
EXPLAIN PLAN 文の構文については、
『Oracle Database SQL リファレ
ンス』を参照してください。
第 14 章「問合せオプティマイザ」
EXPLAIN PLAN の使用方法
19-1
EXPLAIN PLAN について
EXPLAIN PLAN について
EXPLAIN PLAN 文は、SELECT、UPDATE、INSERT および DELETE 文について Oracle オプ
ティマイザが選択した実行計画を表示します。文の実行計画とは、Oracle がその文を実行す
るために行う一連の処理です。
行ソース・ツリーは、実行計画の中核です。行ソース・ツリーは次の情報を示します。
■
文によって参照される表の順序
■
文で言及される各表へのアクセス方法
■
文の結合操作の影響を受ける表の結合方法
■
フィルタ、ソート、集計などのデータ操作
PLAN TABLE には、行ソース・ツリーの他、次の情報が含まれています。
■
最適化。各操作のコストとカーディナリティについて。
■
パーティション化。アクセスされたパーティションのセットなど。
■
パラレル実行。結合入力の配分方法など。
EXPLAIN PLAN の結果により、オプティマイザが特定の実行計画（たとえば、ネステッド・
ループ結合）を選択するかどうかを判断できます。また、オプティマイザの決定（たとえ
ば、オプティマイザがハッシュ結合でなくネステッド・ループ結合を選択した理由）につい
て理解し、問合せのパフォーマンスを知るために役立ちます。
注意 : Oracle Performance Manager チャートと Oracle SQL Analyze は、
EXPLAIN PLAN を自動的に作成して表示できます。EXPLAIN PLAN の使
用方法の詳細は、
『Oracle Enterprise Manager 概要』を参照してください。
19-2　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN について
実行計画の変化理由
問合せオプティマイザを使用すると、実行計画は基礎となるオプティマイザ入力が変化する
たびに変化します。EXPLAIN PLAN の出力は、SQL 文の説明段階での実行方法を示します。
この方法は、実行環境と EXPLAIN PLAN 環境との違いにより、SQL 文の実際の実行計画と
は異なる場合があります。
実行計画は、次の理由により異なります。
■
スキーマの相違
■
コストの相違
スキーマの相違
■
■
■
実行と EXPLAIN PLAN が、異なるデータベース上で起こる場合。
文を EXPLAIN するユーザーが、文を実行するユーザーとは異なる場合。2 人のユー
ザーが同じデータベース内の異なるオブジェクトを指していれば、異なる実行計画が発
生します。
2 つの操作間でスキーマが変更された場合（多くは索引の変更）。
コストの相違
スキーマが同じであっても、コストが異なる場合にオプティマイザは異なる実行計画を選択
する可能性があります。コストに影響を与えるいくつかの要因には次のものがあります。
■
データ量と統計
■
バインド変数の型と値
■
初期化パラメータ（グローバル設定またはセッション・レベルでの設定）
排除行数の最少化
EXPLAIN PLAN を調べることにより、次の場合の排除行数を確認できます。
■
全表スキャン
■
選択性のないレンジ・スキャン
■
遅延した述語フィルタ
■
誤った結合順序
■
遅延したフィルタ処理
たとえば、次の EXPLAIN PLAN では、最後のステップは非常に選択性のないレンジ・ス
キャンです。このレンジ・スキャンは 76563 回実行され、11432983 行にアクセスし、アクセ
スした行の 99 パーセントを排除して 76563 行を保持します。11432983 行にアクセスした結
果、必要な行が 76563 行のみであると判別された理由について考えます。
EXPLAIN PLAN の使用方法
19-3
EXPLAIN PLAN について
例 19-1 EXPLAIN PLAN 内の排除行数の確認
Rows
-------12
2
76563
76575
19
76570
76570
76563
11432983
Execution Plan
---------------------------------------------------SORT AGGREGATE
SORT GROUP BY
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS FULL CN_PAYRUNS_ALL
TABLE ACCESS BY INDEX ROWID CN_POSTING_DETAILS_ALL
INDEX RANGE SCAN (object id 178321)
TABLE ACCESS BY INDEX ROWID CN_PAYMENT_WORKSHEETS_ALL
INDEX RANGE SCAN (object id 186024)
実行計画以外の考慮事項
実行計画の操作だけでは、よく調整された文とうまく機能しない文を区別できません。たと
えば、文による索引の使用が EXPLAIN PLAN 出力で示されたとしても、その文が効率的に
機能するとはかぎりません。索引は、非常に非効率的である場合もあります。この場合、次
のことを調べる必要があります。
■
使用される索引の列
■
その索引の選択性（アクセスされる表の一部）
したがって、EXPLAIN PLAN でアクセス計画を判断し、後からテストによってそれが最適な
計画であることを確認するのが最もよい方法です。計画を評価する際は、文の正確なリソー
ス使用量を調べてください。
V$SQL_PLAN ビューの使用
EXPLAIN PLAN コマンドを実行して計画を表示するのみではなく、V$SQL_PLAN ビューを使
用して SQL 文の実行計画を表示できます。
文の実行後に、V$SQL_PLAN ビューを問い合せて計画を表示できます。V$SQL_PLAN には、
カーソル・キャッシュに格納されている各文の実行計画が含まれます。その定義は、PLAN_
TABLE に類似しています。19-23 ページの「PLAN_TABLE 列」を参照してください。
EXPLAIN PLAN とは異なり、V$SQL_PLAN には、特定の文の実行に使用されたコンパイル環
境を使用する必要がないというメリットがあります。EXPLAIN PLAN の場合は、文の実行時
に同じ計画を取得するために同一環境をセットアップする必要があります。
V$SQL_PLAN_STATISTICS ビューは、出力行数や経過時間など、計画に含まれる操作ごと
に実際の実行統計を提供します。出力行数を除き、すべての統計は累積されます。たとえば、
結合操作の統計には、2 つの入力の統計も含まれます。V$SQL_PLAN_STATISTICS の統計
は、STATISTICS_LEVEL 初期化パラメータを ALL に設定してコンパイルされたカーソルに
使用できます。
19-4　Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 出力表
V$SQL_PLAN_STATISTICS_ALL ビューを使用すると、行数と経過時間に関してオプティマ
イザにより提供される見積りを並べて表示できます。このビューでは、各カーソルの
V$SQL_PLAN および V$SQL_PLAN_STATISTICS 情報が結合されます。
関連項目 :
■
■
V$SQL_PLAN ビューの詳細は、
『Oracle Database リファレンス』を参
照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
EXPLAIN PLAN の制限事項
EXPLAIN PLAN は、日付バインド変数の暗黙的な型変換を実行する文をサポートしません。
一般にバインド変数では、EXPLAIN PLAN が実際の実行計画を表していない場合がありま
す。
TKPROF は、SQL 文のテキストからバインド変数の型を判断することはできません。型は
CHARACTER であると想定され、これ以外の場合はエラー・メッセージが表示されます。こ
の制限事項は、SQL 文に適切な型変換を入れることで対処できます。
関連項目 :
第 20 章「アプリケーション・トレース・ツールの使用方法」
PLAN_TABLE 出力表
すべてのユーザーの EXPLAIN PLAN 文の出力を保持するため、PLAN_TABLE がグローバル
一時表として自動的に作成されます。PLAN_TABLE は、EXPLAIN PLAN 文が実行計画につい
て記述している行を挿入するデフォルトのサンプル出力表です。表内の列の詳細は、19-23
ページの「PLAN_TABLE 列」を参照してください。
PLAN_TABLE 表は各ユーザーに対し自動的に設定されますが、SQL スクリプト
utlxplan.sql を使用して、スキーマにローカルの PLAN_TABLE を手動で作成できます。
このスクリプトの正確な名前と位置は、使用するオペレーティング・システムによって異な
ります。このスクリプトは UNIX 上では $ORACLE_HOME/rdbms/admin ディレクトリにあ
ります。
たとえば、SQL*Plus セッションで例 19-2 のコマンドを実行し、HR スキーマに PLAN_
TABLE を作成します。
例 19-2 PLAN_TABLE の作成
CONNECT HR/your_password
@$ORACLE_HOME/rdbms/admin/utlxplan.sql
Table created.
EXPLAIN PLAN の使用方法
19-5
EXPLAIN PLAN の実行
データベースのバージョンを更新した場合は、列が変更される可能性があるため、ローカル
の PLAN_TABLE 表を削除して再作成することをお薦めします。表を指定する場合は、スク
リプトの実行が失敗したり、TKPROF が失敗する場合があります。
別の名前の出力表が必要な場合は、最初に utlxplan.sql スクリプトを使用して手動で
PLAN_TABLE を作成してから、RENAME SQL 文で表の名前を変更します。たとえば、次のよ
うにします。
RENAME PLAN_TABLE TO my_plan_table;
EXPLAIN PLAN の実行
SQL 文を EXPLAIN する場合は、文の直前に EXPLAIN PLAN FOR 句を使用します。たとえ
ば、次のようにします。
EXPLAIN PLAN FOR
SELECT last_name FROM employees;
計画を EXPLAIN したものが PLAN_TABLE 表に挿入されます。PLAN_TABLE から実行計画
を選択できるようになります。19-7 ページの「PLAN_TABLE 出力の表示」を参照してくだ
さい。
EXPLAIN PLAN での文の指定
複数の文があるときは、文の識別子を指定し、その識別子で特定の実行計画を識別できま
す。SET STATEMENT ID を使用する前に、その文と同じ識別子を持つ既存の行を削除してく
ださい。
例 19-3 の場合は、st1 が文の識別子として指定されています。
例 19-3 STATEMENT ID 句での EXPLAIN PLAN の使用方法
EXPLAIN PLAN
SET STATEMENT_ID = 'st1' FOR
SELECT last_name FROM employees;
EXPLAIN PLAN での別の表の指定
INTO 句を指定して、別の表を指定できます。
例 19-4 INTO 句での EXPLAIN PLAN の使用方法
EXPLAIN PLAN
INTO my_plan_table
FOR
SELECT last_name FROM employees;
19-6　Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 出力の表示
INTO 句を使用する場合は、文の識別子を指定できます。
EXPLAIN PLAN
SET STATEMENT_ID = 'st1'
INTO my_plan_table
FOR
SELECT last_name FROM employees;
関連項目 : EXPLAIN PLAN 構文の詳細は、『Oracle Database SQL リファ
レンス』を参照してください。
PLAN_TABLE 出力の表示
計画を EXPLAIN した後、Oracle から提供される次の SQL スクリプトまたは PL/SQL パッ
ケージを使用して最新の PLAN TABLE 出力を表示します。
■
UTLXPLS.SQL
このスクリプトは、シリアル処理のための PLAN TABLE 出力を表示します。14-16 ペー
ジの例 14-2「EXPLAIN PLAN 出力」は、UTLXPLS.SQL スクリプトを使用した場合の
PLAN TABLE 出力の例です。
■
UTLXPLP.SQL
このスクリプトは、パラレル実行列を含む PLAN TABLE 出力を表示します。
■
DBMS_XPLAN.DISPLAY プロシージャ
このプロシージャは、PLAN TABLE 出力を表示するオプションを受け入れます。指定
できるのは次のとおりです。
■
PLAN_TABLE とは別の表を使用している場合の PLAN TABLE 名
■
EXPLAIN PLAN に文の識別子を設定した場合の文の識別子
■
詳細レベルを決定するフォーマット・オプション : BASIC、SERIAL および
TYPICAL、ALL
DBMS_XPLAN を使用して PLAN_TABLE 出力を表示するいくつかの例を次に示します。
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY('MY_PLAN_TABLE', 'st1','TYPICAL'));
関連項目 : DBMS_XPLAN パッケージの詳細は、
『PL/SQL パッケージ・プ
ロシージャおよびタイプ・リファレンス』を参照してください。
EXPLAIN PLAN の使用方法
19-7
PLAN_TABLE 出力の表示
PLAN_TABLE 出力のカスタマイズ
文の識別子を指定した場合は、PLAN_TABLE を問い合せるための独自のスクリプトを書くこ
とができます。たとえば、次のようにします。
■
■
■
START WITH ID = 0 および STATEMENT_ID を指定します。
CONNECT BY 句を使用して親から子へツリーを移動します。結合キーは、STATEMENT_
ID = PRIOR STATEMENT_ID と PARENT_ID = PRIOR ID です。
疑似列 LEVEL（CONNECT BY に関連付けられている）を使用して子をインデントしま
す。
SELECT cardinality "Rows",
lpad(' ',level-1)||operation||' '||options||' '||object_name "Plan"
FROM PLAN_TABLE
CONNECT BY prior id = parent_id
AND prior statement_id = statement_id
START WITH id = 0
AND statement_id = 'st1'
ORDER BY id;
Rows Plan
------- ---------------------------------------SELECT STATEMENT
TABLE ACCESS FULL EMPLOYEES
Rows 列の NULL は、オプティマイザが表に統計を持っていないことを示します。表を
ANALYZE すると、次の内容が表示されます。
Rows Plan
------- ---------------------------------------16957 SELECT STATEMENT
16957 TABLE ACCESS FULL EMPLOYEES
COST も選択できます。これは、実行計画を比較する場合や、オプティマイザが複数の
中からある実行計画を選択した理由を理解する場合に便利です。
注意 :
ん。
これらの単純な例は、再帰的 SQL の場合には有効ではありませ
19-8　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN 出力の読み方
EXPLAIN PLAN 出力の読み方
この項では、EXPLAIN PLAN の例を使用して実行計画を説明します。例 19-5 の文は、実行
計画の表示に使用されます。
例 19-5 EXPLAIN PLAN を表示する文
SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, 'statement_id','BASIC'));
この文の出力例を、例 19-6 および例 19-7 に示します。
例 19-6 文 ID ex_plan1 の EXPLAIN PLAN
EXPLAIN PLAN
SET statement_id = 'ex_plan1' FOR
SELECT phone_number FROM employees
WHERE phone_number LIKE '650%';
--------------------------------------| Id | Operation
| Name
|
--------------------------------------|
0 | SELECT STATEMENT |
|
|
1 | TABLE ACCESS FULL| EMPLOYEES |
---------------------------------------
この計画は、SELECT 文の実行を示します。表 employees は、全表スキャンでアクセスさ
れます。
■
■
表 employees のすべての行がアクセスされ、各行が WHERE 句の条件に基づいて評価さ
れます。
SELECT 文により、WHERE 句の条件に一致する行が戻されます。
例 19-7 文 ID ex_plan2 の EXPLAIN PLAN
EXPLAIN PLAN
SET statement_id = 'ex_plan2' FOR
SELECT last_name FROM employees
WHERE last_name LIKE 'Pe%';
SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, 'ex_plan2','BASIC'));
EXPLAIN PLAN の使用方法
19-9
EXPLAIN PLAN によるパラレル実行の表示
---------------------------------------| Id | Operation
| Name
|
---------------------------------------|
0 | SELECT STATEMENT |
|
|
1 | INDEX RANGE SCAN| EMP_NAME_IX |
----------------------------------------
この計画は、SELECT 文の実行を示します。
■
■
索引 EMP_NAME_IX は、レンジ・スキャン操作で WHERE 句の条件を評価するために使用
されます。
SELECT 文により、WHERE 句の条件を満たす行が戻されます。
EXPLAIN PLAN によるパラレル実行の表示
パラレル問合せのチューニングは、パラレルでない問合せのチューニングの場合と同様に駆
動表を選択することにより、開始されます。ただし、選択を管理するルールは異なります。
パラレルでない問合せの場合は、通常、制限条件が適用された後に最も少ない行が生成され
る駆動表が最適です。少数の行は、一意でない索引を使用して大きな表に結合されます。た
とえば、CUSTOMER、ACCOUNT および TRANSACTION で構成された表階層の場合について考
えます。
図 19-1 表階層
ここでは CUSTOMER が最も小さな表、TRANSACTION が最も大きな表です。通常の OLTP 問
合せでは、特定の顧客のアカウントに関する取引情報が取得できます。問合せは CUSTOMER
表から駆動されます。この場合の目標は、論理 I/O を最少化することです。それにより、通
常、物理 I/O や CPU タイムを含むその他の重要なリソースも最少化されます。
パラレル問合せの場合は、通常、最も大きな表が駆動表として選択されます。これは、最も
大きな表でパラレル問合せが有効に利用できるためです。この問合せにパラレル問合せを使
用するのは効率的ではありません。各表から最終的にアクセスされる行がごくわずかである
ためです。ここで、たとえば前月に特定のタイプの取引を持つすべての顧客を識別する必要
が生じた場合を考えます。顧客表には制限条件がないため、問合せは TRANSACTION 表から
行うほうが効率的です。TRANSACTION 表から取り出した行は ACCOUNT 表に結合され、最
終的には CUSTOMER 表に結合されます。この場合、ACCOUNT および CUSTOMER 表で使用さ
19-10　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパラレル実行の表示
れる索引は、通常、最初の問合せで使用される一意でない索引ではなく、選択性の高い主
キーまたは一意の索引になります。TRANSACTION 表は大きく、列に選択性がないため、
TRANSACTION 表から行われるパラレル問合せを使用したほうが有効です。
パラレル操作には次のものがあります。
■
PARALLEL_TO_PARALLEL
■
PARALLEL_TO_SERIAL
PARALLEL_TO_SERIAL 操作は、パラレル操作からの行が問合せコーディネータによっ
て使用される場合、常に発生するステップです。この問合せでは発生しない他の種類の
操作には、SERIAL 操作があります。これらの操作が発生するとボトルネックになる可
能性があります。パフォーマンスを向上させるために、これらの操作をパラレル操作に
することを考慮します。
■
PARALLEL_FROM_SERIAL
■
PARALLEL_TO_PARALLEL
通常は、各操作のワークロードがほぼ同じであるかぎり、PARALLEL_TO_PARALLEL 操
作によって最適なパフォーマンスが得られます。
■
PARALLEL_COMBINED_WITH_CHILD
■
PARALLEL_COMBINED_WITH_PARENT
ステップが親ステップと同時に実行される場合、PARALLEL_COMBINED_WITH_
PARENT 操作が発生します。
パラレル・ステップによって多数の行が生成されると、問合せコーディネータ（QC）がそ
れらの行を生成後すぐに処理できない場合があります。このような状況を改善する方法はあ
りません。
関連項目 : 19-23 ページの表 19-1「PLAN_TABLE 列」の OTHER_TAG 列
を参照してください。
EXPLAIN PLAN によるパラレル問合せの表示
パラレル問合せに EXPLAIN PLAN を使用する場合、1 つのパラレル計画がコンパイルされ、
実行されます。この計画は、問合せコーディネータ（QC）計画のパラレル・サポートに固
有の行ソースを割り当てることで、シリアル計画から導出されます。2 つのスレーブ・セッ
ト PQ モデルで要求される、表キューの行ソース（PX Send および PX Receive）
、グラ
ニュル・イテレータおよびバッファ・ソートは、パラレル計画に直接挿入されます。この計
画は、パラレルで実行された場合はすべてのスレーブで、またシリアルで実行された場合は
すべての QC で、まったく同じ計画となります。
例 19-8 は、パラレル問合せの EXPLAIN PLAN を説明するための単純な問合せです。
EXPLAIN PLAN の使用方法
19-11
EXPLAIN PLAN によるパラレル実行の表示
例 19-8 パラレル問合せの EXPLAIN PLAN
CREATE TABLE emp2 AS SELECT * FROM employees;
ALTER TABLE emp2 PARALLEL 2;
EXPLAIN PLAN FOR
SELECT SUM(salary) FROM emp2 GROUP BY department_id;
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
-------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost |
TQ |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
41 | 1066 |
4 |
|
|
|
|
1 | PX COORDINATOR
|
|
|
|
|
|
|
|
|
2 |
PX SEND QC (RANDOM)
| :TQ10001 |
41 | 1066 |
4 | Q1,01 | P->S | QC (RAND) |
|
3 |
SORT GROUP BY
|
|
41 | 1066 |
4 | Q1,01 | PCWP |
|
|
4 |
PX RECEIVE
|
|
41 | 1066 |
4 | Q1,01 | PCWP |
|
|
5 |
PX SEND HASH
| :TQ10000 |
41 | 1066 |
4 | Q1,00 | P->P | HASH
|
|
6 |
SORT GROUP BY
|
|
41 | 1066 |
4 | Q1,00 | PCWP |
|
|
7 |
PX BLOCK ITERATOR |
|
41 | 1066 |
1 | Q1,00 | PCWC |
|
|
8 |
TABLE ACCESS FULL| EMP2
|
41 | 1066 |
1 | Q1,00 | PCWP |
|
--------------------------------------------------------------------------------------------------
第 1 のスレーブ・セットにより EMP2 表がパラレルにスキャンされる間に、第 2 のスレー
ブ・セットにより GROUP BY が集計されます。PX BLOCK ITERATOR 行ソースは、スキャン
のワークロードがパラレル・スキャン・スレーブ間で分割されるように、EMP2 表が複数の
ピースに分割されることを表します。PX SEND および PX RECEIVE 行ソースは、2 つのス
レーブ・セットをパラレル・スキャンからの行フローとして接続するパイプが、HASH 表
キューを介して再びパーティション化されてから、上位スレーブ・セットにより読み取られ
て集計されることを表します。PX SEND QC 行ソースは、QC（問合せコーディネータ）にラ
ンダム（RAND）な順序で送られる集計値を表します。PX COORDINATOR 行ソースは、計画
ツリーで下に表示されるパラレル計画を制御しスケジュールする QC（問合せコーディネー
タ）を表します。
19-12　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるビットマップ索引の表示
EXPLAIN PLAN によるビットマップ索引の表示
ビットマップ索引を使用する索引行ソースは、索引のタイプを示すワード BITMAP とともに
EXPLAIN PLAN 出力に表示されます。例 19-9 の問合せおよび計画の次の例を検討します。
例 19-9 ビットマップ検索による EXPLAIN PLAN
EXPLAIN PLAN FOR
SELECT * FROM t
WHERE c1 = 2
AND c2 <> 6
OR c3 BETWEEN 10 AND 20;
SELECT STATEMENT
TABLE ACCESS T BY INDEX ROWID
BITMAP CONVERSION TO ROWID
BITMAP OR
BITMAP MINUS
BITMAP MINUS
BITMAP INDEX C1_IND SINGLE VALUE
BITMAP INDEX C2_IND SINGLE VALUE
BITMAP INDEX C2_IND SINGLE VALUE
BITMAP MERGE
BITMAP INDEX C3_IND RANGE SCAN
この例では、述語 c1=2 によってビットマップが生成され、そこから減算が行われます。こ
のビットマップから、c2 = 6 に対応するビットマップ内のビットが減算されます。同様に、
c2 IS NULL に対応するビットマップ内のビットが減算され、この計画の中に 2 つの MINUS
行ソースがある理由がわかります。NULL 減算は、NOT NULL 制約が列に付いていないかぎ
り、意味上の正確さを保つために必要です。TO ROWIDS オプションは、表アクセスに必要な
ROWID を生成するのに使用されます。
注意 : ビットマップ結合索引を使用した問合せは、ビットマップ結合索
引のアクセス・パスを指示します。ビットマップ結合索引の操作は、ビッ
トマップ索引と同じです。
EXPLAIN PLAN の使用方法
19-13
EXPLAIN PLAN によるパーティション・オブジェクトの表示
EXPLAIN PLAN によるパーティション・オブジェクトの表示
EXPLAIN PLAN を使用すると、特定の問合せでのパーティション・オブジェクトに Oracle
がアクセスする方法を参照できます。
プルーニング後にアクセスされたパーティションは、PARTITION START 列と PARTITION
STOP 列に表示されます。レンジ・パーティションの行ソース名は、PARTITION RANGE で
す。ハッシュ・パーティションの場合、行ソース名は PARTITION HASH です。
結合されるいずれかの表の PLAN TABLE の DISTRIBUTION 列に PARTITION（KEY）が存
在する場合、結合はパーシャル・パーティション・ワイズ結合を使用して実装されます。
パーシャル・パーティション・ワイズ結合が可能なのは、結合される表のいずれかが結合列
でパーティション化されており、かつ、表がパラレル化されている場合です。
EXPLAIN PLAN 出力の結合行ソースの前にパーティション行ソースがある場合、結合はフ
ル・パーティション・ワイズ結合を使用して実装されます。フル・パーティション・ワイズ
結合が可能なのは、両方の結合表がそれぞれの結合列でパーティション化されている場合の
みです。次に、いくつかの種類のパーティションに対する実行計画の例を示します。
EXPLAIN PLAN によるレンジ・パーティション化およびハッシュ・パーティ
ション化の表示の例
hire_date で範囲ごとにパーティション化されている次の emp_range 表を参考に、プ
ルーニングの表示方法を例示します。Oracle サンプル・スキーマの表 employees および
departments が存在することを想定しています。
CREATE TABLE emp_range
PARTITION BY RANGE(hire_date)
(
PARTITION emp_p1 VALUES LESS THAN
PARTITION emp_p2 VALUES LESS THAN
PARTITION emp_p3 VALUES LESS THAN
PARTITION emp_p4 VALUES LESS THAN
PARTITION emp_p5 VALUES LESS THAN
)
AS SELECT * FROM employees;
(TO_DATE('1-JAN-1992','DD-MON-YYYY')),
(TO_DATE('1-JAN-1994','DD-MON-YYYY')),
(TO_DATE('1-JAN-1996','DD-MON-YYYY')),
(TO_DATE('1-JAN-1998','DD-MON-YYYY')),
(TO_DATE('1-JAN-2001','DD-MON-YYYY'))
最初の例では、次の文を検討します。
EXPLAIN PLAN FOR
SELECT * FROM emp_range;
次のようなものが表示されます。
19-14　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパーティション・オブジェクトの表示
--------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
--------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
105 | 13965 |
2 |
|
|
|
1 | PARTITION RANGE ALL|
|
105 | 13965 |
2 |
1 |
5 |
|
2 |
TABLE ACCESS FULL | EMP_RANGE |
105 | 13965 |
2 |
1 |
5 |
---------------------------------------------------------------------------------
パーティション行ソースは、表アクセス行ソースの上に作成されます。これが、アクセスさ
れるパーティションのセットについて繰り返されます。この例では、述語がプルーニングに
使用されていないので、パーティション・イテレータはすべてのパーティション（ALL）を
対象とします。PLAN_TABLE の PARTITION_START 列と PARTITION_STOP 列は、1 ～ 5 ま
でのすべてのパーティションへのアクセスを示します。
次の例では、次の文を検討します。
EXPLAIN PLAN FOR
SELECT * FROM emp_range
WHERE hire_date >= TO_DATE('1-JAN-1996','DD-MON-YYYY');
-------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
-------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
3 |
399 |
2 |
|
|
|
1 | PARTITION RANGE ITERATOR|
|
3 |
399 |
2 |
4 |
5 |
|* 2 |
TABLE ACCESS FULL
| EMP_RANGE |
3 |
399 |
2 |
4 |
5 |
--------------------------------------------------------------------------------------
前の例では、パーティション行ソースがパーティション 4 ～ 5 までを反復します。これは、
hire_date についての述語を使用してその他のパーティションをプルーニングするためで
す。
最後に、次の文を検討します。
EXPLAIN PLAN FOR
SELECT * FROM emp_range
WHERE hire_date < TO_DATE('1-JAN-1992','DD-MON-YYYY');
-----------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
-----------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
133 |
2 |
|
|
|
1 | PARTITION RANGE SINGLE|
|
1 |
133 |
2 |
1 |
1 |
|* 2 |
TABLE ACCESS FULL
| EMP_RANGE |
1 |
133 |
2 |
1 |
1 |
------------------------------------------------------------------------------------
この例では、パーティション 1 のみがアクセスされ、それがコンパイル時に認識されます。
したがって、パーティション行ソースは必要ありません。
EXPLAIN PLAN の使用方法
19-15
EXPLAIN PLAN によるパーティション・オブジェクトの表示
ハッシュ・パーティション化の計画
パーティション行ソース名が PARTITION RANGE ではなく PARTITION HASH であることを
除き、Oracle はハッシュ・パーティション・オブジェクトに対して同じ情報を表示します。
また、ハッシュ・パーティション化では、プルーニングが可能なのは等価述語か IN リスト
述語を使用している場合のみです。
コンポジット・パーティション・オブジェクトでのプルーニング情報の例
Oracle がコンポジット・パーティション・オブジェクトのプルーニング情報を表示する方法
を例示するために、hiredate でレンジ・パーティション化され、deptno でハッシュ・サ
ブパーティション化された表 emp_comp を検討します。
CREATE TABLE emp_comp PARTITION BY RANGE(hire_date)
SUBPARTITION BY HASH(department_id) SUBPARTITIONS 3
(
PARTITION emp_p1 VALUES LESS THAN (TO_DATE('1-JAN-1992','DD-MON-YYYY')),
PARTITION emp_p2 VALUES LESS THAN (TO_DATE('1-JAN-1994','DD-MON-YYYY')),
PARTITION emp_p3 VALUES LESS THAN (TO_DATE('1-JAN-1996','DD-MON-YYYY')),
PARTITION emp_p4 VALUES LESS THAN (TO_DATE('1-JAN-1998','DD-MON-YYYY')),
PARTITION emp_p5 VALUES LESS THAN (TO_DATE('1-JAN-2001','DD-MON-YYYY'))
)
AS SELECT * FROM employees;
最初の例では、次の文を検討します。
EXPLAIN PLAN FOR
SELECT * FROM emp_comp;
-------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
-------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
| 10120 | 1314K|
78 |
|
|
|
1 | PARTITION RANGE ALL|
| 10120 | 1314K|
78 |
1 |
5 |
|
2 |
PARTITION HASH ALL|
| 10120 | 1314K|
78 |
1 |
3 |
|
3 |
TABLE ACCESS FULL| EMP_COMP | 10120 | 1314K|
78 |
1 |
15 |
--------------------------------------------------------------------------------
この例では、Oracle がコンポジット・パーティション・オブジェクトの全パーティションの
全サブパーティションにアクセスする場合の計画を示します。そのために、2 つのパーティ
ション行ソースが使用されています。1 つはパーティションを反復するレンジ・パーティ
ション行ソースで、もう 1 つはアクセスされる各パーティションのサブパーティションを反
復するハッシュ・パーティション行ソースです。
次の例では、プルーニングが実行されていないので、レンジ・パーティション行ソースは
パーティション 1 から 5 までを反復します。各パーティション内では、ハッシュ・パーティ
ション行ソースは現在のパーティションのサブパーティション 1 から 3 までを反復します。
その結果、表アクセス行ソースがサブパーティション 1 ～ 15 にアクセスします。つまり、
19-16　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパーティション・オブジェクトの表示
コンポジット・オブジェクトのすべてのサブパーティションにアクセスすることになりま
す。
EXPLAIN PLAN FOR
SELECT * FROM emp_comp
WHERE hire_date = TO_DATE('15-FEB-1998', 'DD-MON-YYYY');
----------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
----------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
20 | 2660 |
17 |
|
|
|
1 | PARTITION RANGE SINGLE|
|
20 | 2660 |
17 |
5 |
5 |
|
2 |
PARTITION HASH ALL
|
|
20 | 2660 |
17 |
1 |
3 |
|* 3 |
TABLE ACCESS FULL
| EMP_COMP |
20 | 2660 |
17 |
13 |
15 |
-----------------------------------------------------------------------------------
この例では、最後のパーティション 5 のみがアクセスされます。このパーティションはコン
パイル時に認識されるので、計画内で表示する必要はありません。ハッシュ・パーティショ
ン行ソースは、そのパーティション内のすべてのサブパーティションのアクセスを表示しま
す。つまりサブパーティション 1 ～ 3 が表示されることになりますが、これは emp_comp 表
のサブパーティション 13 ～ 15 までと変換されます。
次に、次の文を検討します。
EXPLAIN PLAN FOR
SELECT * FROM emp_comp WHERE department_id = 20;
----------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
----------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
101 | 13433 |
78 |
|
|
|
1 | PARTITION RANGE ALL
|
|
101 | 13433 |
78 |
1 |
5 |
|
2 |
PARTITION HASH SINGLE|
|
101 | 13433 |
78 |
3 |
3 |
|* 3 |
TABLE ACCESS FULL
| EMP_COMP |
101 | 13433 |
78 |
|
|
-----------------------------------------------------------------------------------
この例では、述語 deptno = 20 によって各パーティション内のハッシュ・ディメンションで
プルーニングが使用可能なので、Oracle は単一のサブパーティションにアクセスするだけで
済みます。そのサブパーティションの番号はコンパイル時に認識されるので、ハッシュ・
パーティション行ソースは必要ありません。
最後に、次の文を検討します。
EXPLAIN PLAN の使用方法
19-17
EXPLAIN PLAN によるパーティション・オブジェクトの表示
VARIABLE dno NUMBER;
EXPLAIN PLAN FOR
SELECT * FROM emp_comp WHERE department_id = :dno;
----------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
----------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
101 | 13433 |
78 |
|
|
|
1 | PARTITION RANGE ALL
|
|
101 | 13433 |
78 |
1 |
5 |
|
2 |
PARTITION HASH SINGLE|
|
101 | 13433 |
78 |
KEY |
KEY |
|* 3 |
TABLE ACCESS FULL
| EMP_COMP |
101 | 13433 |
78 |
|
|
-----------------------------------------------------------------------------------
最後の 2 つの例は、deptno = 20 が department_id = :dno に置き換えられたこと以外は
同じです。この最後の場合、サブパーティションの番号はコンパイル時には不明であり、
ハッシュ・パーティション行ソースが割り当てられます。Oracle が各パーティション内でア
クセスするサブパーティションは 1 つのみなので、その行ソースのオプションは SINGLE で
す。PARTITION_START および PARTITION_STOP は KEY に設定されます。これは、Oracle
がサブパーティションの番号を実行時に判別することを意味します。
パーシャル・パーティション・ワイズ結合の例
次の例では、emp_range_did がパーティション化列 department_id で結合され、パラレ
ル化されます。dept2 表がパーティション化されていないことにより、パーシャル・パー
ティション・ワイズ結合が使用可能になります。Oracle は結合前に dept2 表を動的にパー
ティション化します。
例 19-10 レンジ・パーティション化を使用したパーシャル・パーティション・ワイズ結合
CREATE TABLE dept2 AS SELECT * FROM departments;
ALTER TABLE dept2 PARALLEL 2;
CREATE TABLE emp_range_did PARTITION BY RANGE(department_id)
(PARTITION emp_p1 VALUES LESS THAN (150),
PARTITION emp_p5 VALUES LESS THAN (MAXVALUE) )
AS SELECT * FROM employees;
ALTER TABLE emp_range_did PARALLEL 2;
EXPLAIN PLAN FOR
SELECT /*+ PQ_DISTRIBUTE(d NONE PARTITION) ORDERED */ e.last_name,
d.department_name
FROM emp_range_did e , dept2 d
WHERE e.department_id = d.department_id ;
19-18　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパーティション・オブジェクトの表示
------------------------------------------------------------------------------------------------------------| Id| Operation
|Name
|Rows | Bytes |Cost|Pstart|Pstop|
TQ |IN-OUT|PQ Distrib |
------------------------------------------------------------------------------------------------------------| 0| SELECT STATEMENT
|
| 284 | 16188 | 6 |
|
|
|
|
| 1| PX COORDINATOR
|
|
|
|
|
|
|
|
|
|
| 2|
PX SEND QC (RANDOM)
|:TQ10001
| 284 | 16188 | 6 |
|
| Q1,01 | P->S | QC (RAND) |
|* 3|
HASH JOIN
|
| 284 | 16188 | 6 |
|
| Q1,01 | PCWP |
|
| 4|
PX PARTITION RANGE ALL
|
| 284 | 7668 | 2 |
1 |
2 | Q1,01 | PCWC |
|
| 5|
TABLE ACCESS FULL
|EMP_RANGE_DID| 284 | 7668 | 2 |
1 |
2 | Q1,01 | PCWP |
|
| 6|
BUFFER SORT
|
|
|
|
|
|
| Q1,01 | PCWC |
|
| 7|
PX RECEIVE
|
| 21 |
630 | 2 |
|
| Q1,01 | PCWP |
|
| 8|
PX SEND PARTITION (KEY)|:TQ10000
| 21 |
630 | 2 |
|
|
| S->P |PART (KEY) |
| 9|
TABLE ACCESS FULL
|DEPT2
| 21 |
630 | 2 |
|
|
|
|
|
------------------------------------------------------------------------------------------------------------
この実行計画は、dept2 表がシリアルにスキャンされ、emp_range_did の同じパーティ
ション化列値（department_id）を持つすべての行が、パーティション・キーを示す
PART (KEY)、表キューを介して、パーシャル・パーティション・ワイズ結合を実行する同じ
スレーブに送られることを示します。
次の例では、emp_comp がパーティション化列で結合され、パラレル化されます。dept2 表
がパーティション化されていないことにより、パーシャル・パーティション・ワイズ結合が
使用可能になります。Oracle は結合前に dept2 表を動的にパーティション化します。
例 19-11 コンポジット・パーティション化を使用したパーシャル・パーティション・ワイズ結合
ALTER TABLE emp_comp PARALLEL 2;
EXPLAIN PLAN FOR
SELECT /*+ PQ_DISTRIBUTE(d NONE PARTITION) ORDERED */ e.last_name,
d.department_name
FROM emp_comp e, dept2 d
WHERE e.department_id = d.department_id;
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
------------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost |Pstart|Pstop|
TQ |IN-OUT| PQ Distrib|
------------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
| 445 | 17800 |
5 |
|
|
|
|
|
| 1 | PX COORDINATOR
|
|
|
|
|
|
|
|
|
|
| 2 |
PX SEND QC (RANDOM)
|:TQ10001 | 445 | 17800 |
5 |
|
| Q1,01 | P->S | QC (RAND) |
|* 3 |
HASH JOIN
|
| 445 | 17800 |
5 |
|
| Q1,01 | PCWP |
|
| 4 |
PX PARTITION RANGE ALL |
| 107 | 1070 |
3 |
1 |
5 | Q1,01 | PCWC |
|
| 5 |
PX PARTITION HASH ALL |
| 107 | 1070 |
3 |
1 |
3 | Q1,01 | PCWC |
|
| 6 |
TABLE ACCESS FULL
|EMP_COMP | 107 | 1070 |
3 |
1 | 15 | Q1,01 | PCWP |
|
| 7 |
PX RECEIVE
|
|
21 |
630 |
1 |
|
| Q1,01 | PCWP |
|
| 8 |
PX SEND PARTITION (KEY)|:TQ10000 |
21 |
630 |
1 |
|
| Q1,00 | P->P |PART (KEY) |
| 9 |
PX BLOCK ITERATOR
|
|
21 |
630 |
1 |
|
| Q1,00 | PCWC |
|
| 10 |
TABLE ACCESS FULL
|DEPT2
|
21 |
630 |
1 |
|
| Q1,00 | PCWP |
|
-------------------------------------------------------------------------------------------------------------
EXPLAIN PLAN の使用方法
19-19
EXPLAIN PLAN によるパーティション・オブジェクトの表示
この計画は、オプティマイザが 2 つの列の一方からパーシャル・パーティション・ワイズ結
合を選択することを示します。PX SEND のノード・タイプは PARTITION(KEY) で、PQ
Distrib 列にはパーティション・キーを示すテキスト PART (KEY) が含まれています。これは、
EMP_COMP のスキャンと結合を実行するパラレル・スレーブに送られる結合列
department_id に基づいて、dept2 表が再びパーティション化されることを意味します。
例 19-10 および例 19-11 では、問合せオプティマイザがこの問合せのコストに基づいて異な
る計画を選択する可能性があるため、パーシャル・パーティション・ワイズ結合を明示的に
強制するために、PQ_DISTRIBUTE ヒントが使用されていることに注意してください。
フル・パーティション・ワイズ結合の例
次の例では、emp_comp と dept_hash がハッシュ・パーティション化列で結合されます。
これにより、フル・パーティション・ワイズ結合が使用可能になります。PARTITION HASH
行ソースが、PLAN TABLE 出力の結合行ソースの上に表示されます。
PX PARTITION HASH 行ソースは計画表出力で結合行ソースの上に表示されますが、PX
PARTITION RANGE 行ソースは emp_comp のスキャンにまたがって表示されます。各パラレ
ル・スレーブは、emp_comp のハッシュ・パーティション全体と dept_hash のパーティ
ション全体の結合を実行します。
例 19-12 フル・パーティション・ワイズ結合
CREATE TABLE dept_hash
PARTITION BY HASH(department_id)
PARTITIONS 3
PARALLEL 2
AS SELECT * FROM departments;
EXPLAIN PLAN FOR SELECT /*+ PQ_DISTRIBUTE(e NONE NONE) ORDERED */ e.last_name,
d.department_name
FROM emp_comp e, dept_hash d
WHERE e.department_id = d.department_id;
------------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows |Bytes |Cost |Pstart|Pstop |
TQ |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
| 106 | 2544 |
8 |
|
|
|
|
|
| 1 | PX COORDINATOR
|
|
|
|
|
|
|
|
|
|
| 2 |
PX SEND QC (RANDOM)
| :TQ10000 | 106 | 2544 |
8 |
|
| Q1,00 | P->S | QC (RAND) |
| 3 |
PX PARTITION HASH ALL
|
| 106 | 2544 |
8 |
1 |
3 | Q1,00 | PCWC |
|
|* 4 |
HASH JOIN
|
| 106 | 2544 |
8 |
|
| Q1,00 | PCWP |
|
| 5 |
PX PARTITION RANGE ALL|
| 107 | 1070 |
3 |
1 |
5 | Q1,00 | PCWC |
|
| 6 |
TABLE ACCESS FULL
| EMP_COMP | 107 | 1070 |
3 |
1 |
15 | Q1,00 | PCWP |
|
| 7 |
TABLE ACCESS FULL
| DEPT_HASH |
27 | 378 |
4 |
1 |
3 | Q1,00 | PCWP |
|
-------------------------------------------------------------------------------------------------------------
19-20　Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパーティション・オブジェクトの表示
INLIST ITERATOR および EXPLAIN PLAN の例
INLIST ITERATOR 操作は、索引が IN リスト述語を実装する場合に、EXPLAIN PLAN 出力
に表示されます。たとえば、次のようにします。
SELECT * FROM emp WHERE empno IN (7876, 7900, 7902);
EXPLAIN PLAN 出力は次のようになります。
OPERATION
---------------SELECT STATEMENT
INLIST ITERATOR
TABLE ACCESS
INDEX
OPTIONS
---------------
OBJECT_NAME
--------------
BY ROWID
RANGE SCAN
EMP
EMP_EMPNO
INLIST ITERATOR 操作は、IN リスト述語内の各値に対して、計画内の次の操作を反復し
ます。パーティション表およびパーティション索引には 3 種類の IN リスト列が使用可能で
すが、これについては次の項で説明します。
IN リスト列が索引列である場合
IN リスト列 empno が索引列で、パーティション列ではない場合、計画は次のようになりま
す（IN リスト演算子は表操作の前に表示されますが、パーティションの操作よりは後に表
示されます）
。
OPERATION
---------------SELECT STATEMENT
PARTITION RANGE
INLIST ITERATOR
TABLE ACCESS
INDEX
OPTIONS
------------
OBJECT_NAME PARTITION_START PARTITION_STOP
----------- --------------- --------------
ALL
KEY(INLIST)
KEY(INLIST)
BY LOCAL INDEX ROWID EMP
RANGE SCAN
EMP_EMPNO
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
PARTITION_START 列と PARTITION_STOP 列に KEY（INLIST）指定があるため、索引の
開始 / 終了キーに対して IN リスト述語が表示されます。
IN リスト列が索引でありパーティション列である場合
empno が索引付けされている列で、それがパーティション列でもある場合、計画にはパー
ティション操作の前に INLIST ITERATOR 操作が含まれています。
OPERATION
---------------SELECT STATEMENT
INLIST ITERATOR
PARTITION RANGE
TABLE ACCESS
INDEX
OPTIONS
------------
OBJECT_NAME PARTITION_START PARTITION_STOP
----------- --------------- --------------
ITERATOR
BY LOCAL INDEX ROWID EMP
RANGE SCAN
EMP_EMPNO
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
EXPLAIN PLAN の使用方法
19-21
EXPLAIN PLAN によるパーティション・オブジェクトの表示
IN リスト列がパーティション列である場合
empno がパーティション列で、索引が存在しない場合は、INLIST ITERATOR 操作は割り当
てられません。
OPERATION
---------------SELECT STATEMENT
PARTITION RANGE
TABLE ACCESS
OPTIONS
------------
OBJECT_NAME
-----------
PARTITION_START
---------------
PARTITION_STOP
--------------
INLIST
FULL
EMP
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
KEY(INLIST)
emp_empno がビットマップ索引である場合、計画は次のとおりです。
OPERATION
---------------SELECT STATEMENT
INLIST ITERATOR
TABLE ACCESS
BITMAP CONVERSION
BITMAP INDEX
OPTIONS
---------------
OBJECT_NAME
--------------
BY INDEX ROWID
TO ROWIDS
SINGLE VALUE
EMP
EMP_EMPNO
ドメイン索引および EXPLAIN PLAN の例
また、EXPLAIN PLAN を使用して、ドメイン索引に対するユーザー定義の CPU および I/O
コストを導出できます。EXPLAIN PLAN は、これらの統計を PLAN_TABLE の OTHER 列に表
示します。
たとえば、resume 列にドメイン索引 emp_resume を持つユーザー定義演算子 CONTAINS
が表 emp に存在し、emp_resume の索引タイプが演算子 CONTAINS をサポートしている場
合に、次の問合せをします。
SELECT * FROM emp WHERE CONTAINS(resume, 'Oracle') = 1
その結果、次のような計画が表示されます。
OPERATION
----------------SELECT STATEMENT
TABLE ACCESS
DOMAIN INDEX
OPTIONS
-----------
OBJECT_NAME
------------
OTHER
----------------
BY ROWID
EMP
EMP_RESUME
CPU: 300, I/O: 4
19-22　Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 列
PLAN_TABLE 列
EXPLAIN PLAN 文に使用される PLAN_TABLE には、表 19-1 にリストした列があります。
表 19-1 PLAN_TABLE 列
列
型
説明
STATEMENT_ID
VARCHAR2(30)
EXPLAIN PLAN 文で指定した、オプションの STATEMENT_ID パラ
メータの値です。
PLAN_ID
NUMBER
データベース内の計画の一意の識別子です。
TIMESTAMP
DATE
EXPLAIN PLAN 文が生成された日時です。
REMARKS
VARCHAR2(80)
実行計画の各ステップに関連付けるコメント（最大 80 バイト）で
す。この列は、問合せにアウトラインが使用されたか SQL プロファ
イルが使用されたかを示すために使用されます。
PLAN_TABLE の行に関するコメントを追加または変更する必要があ
る場合は、UPDATE 文を使用して PLAN_TABLE の行を修正してくだ
さい。
OPERATION
VARCHAR2(30)
このステップで実行された内部操作の名前です。文に対して生成さ
れた最初の行の列には、次の値の 1 つが含まれます。
■
DELETE STATEMENT
■
INSERT STATEMENT
■
SELECT STATEMENT
■
UPDATE STATEMENT
この列の値の詳細は、表 19-3 を参照してください。
OPTIONS
VARCHAR2(225)
OPERATION 列に記述されている処理に関するバリエーションです。
この列の値の詳細は、表 19-3 を参照してください。
OBJECT_NODE
VARCHAR2(128)
オブジェクト（表名またはビュー名）を参照するために使用された
データベース・リンクの名前です。パラレル実行を指定したローカ
ル問合せの場合は、各処理による出力の使用順序がこの列に記述さ
れます。
OBJECT_OWNER
VARCHAR2(30)
表または索引を含むスキーマを所有しているユーザーの名前です。
OBJECT_NAME
VARCHAR2(30)
表または索引の名前です。
OBJECT_ALIAS
VARCHAR2(65)
SQL 文に含まれる表またはビューの一意の別名です。索引の場合
は、基礎となる表のオブジェクトの別名です。
EXPLAIN PLAN の使用方法
19-23
PLAN_TABLE 列
表 19-1 PLAN_TABLE 列（続き）
列
型
説明
OBJECT_INSTANCE
NUMERIC
元の文に指定されているオブジェクトの位置に対応する順番を示す
数値です。この数値は元の文テキストに関して、左から右へ、外側
から内側へ付番されています。ビューを展開した場合、この数値は
予測できません。
OBJECT_TYPE
VARCHAR2(30)
たとえば、索引に対する NON-UNIQUE のような、オブジェクトに関
して説明を与える修飾子です。
OPTIMIZER
VARCHAR2(255)
オプティマイザの現行モードです。
SEARCH_COLUMNS
NUMBERIC
現在は使用されていません。
ID
NUMERIC
実行計画の各ステップに割り当てられた番号です。
PARENT_ID
NUMERIC
ID のステップの出力について処理を行う次の実行ステップの ID で
す。
DEPTH
NUMERIC
計画により表される行ソース・ツリー内の操作の深さです。この値
を使用して、PLAN TABLE レポートの行をインデントできます。
POSITION
NUMERIC
最初の出力行の場合、この列はオプティマイザが見積った、文を実
行するためのコストを示します。その他の行の場合は、同じ親の他
の子に対応する相対位置を示します。
COST
NUMERIC
オプティマイザの問合せアプローチによって見積もられた操作コス
トです。表アクセス操作のためのコストは判断されません。この列
の値には、特定の単位はなく、単に実行計画のコストを比較するた
めに使用される重み値を示します。この列の値は、CPU_COST 列と
IO_COST 列の関数です。
CARDINALITY
NUMERIC
この操作によってアクセスされる行数の問合せ最適化アプローチに
よる見積りです。
BYTES
NUMERIC
この操作によってアクセスされるバイト数の問合せ最適化アプロー
チによる見積りです。
19-24　Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 列
表 19-1 PLAN_TABLE 列（続き）
列
型
説明
OTHER_TAG
VARCHAR2(255)
OTHER 列の内容を記述します。値は次のとおりです。
■
■
■
■
■
■
■
PARTITION_START
VARCHAR2(255)
SERIAL( ): シリアル実行。現在のところ、この場合は SQL は
OTHER 列にロードされません。
SERIAL_FROM_REMOTE (S -> R): リモート・サイトでシリア
ル実行されます。
PARALLEL_FROM_SERIAL (S -> P): シリアル実行。ステップ
の出力は、パーティション化されるか、パラレル実行サーバー
にブロードキャストされます。
PARALLEL_TO_SERIAL (P -> S): パラレル実行。ステップの出
力は、シリアル「問合せコーディネータ」
（QC）プロセスに戻
されます。
PARALLEL_TO_PARALLEL (P -> P): パラレル実行。ステップ
の出力は、パラレル実行サーバーの 2 番目のセットに再パー
ティション化されます。
PARALLEL_COMBINED_WITH_PARENT (PWP): パラレル実
行。ステップの出力は、同じパラレル処理の次のステップに送
られます。親へのプロセス間通信はありません。
PARALLEL_COMBINED_WITH_CHILD (PWC): パラレル実
行。ステップの入力は、同じパラレル処理の前のステップから
受け取ります。子からのプロセス間通信はありません。
アクセスされるパーティション範囲の開始パーティションです。こ
れは、次のいずれかの値をとります。
n は、開始パーティションが SQL コンパイラで識別され、そのパー
ティション番号が n で示されることを意味します。
KEY は、開始パーティションが実行時にパーティション・キー値か
ら識別されることを意味します。
ROW REMOVE_LOCATION は、開始パーティション（終了パーティ
ションと同じになります）が実行時に、取得される各レコードの位
置から計算されることを意味します。レコードの位置は、ユーザー
またはグローバル索引によって獲得されます。
INVALID は、アクセスしたパーティションの範囲が空であること
を意味します。
EXPLAIN PLAN の使用方法
19-25
PLAN_TABLE 列
表 19-1 PLAN_TABLE 列（続き）
列
型
説明
PARTITION_STOP
VARCHAR2(255)
アクセスされるパーティション範囲の終了パーティションです。こ
れは、次のいずれかの値をとります。
n は、終了パーティションが SQL コンパイラで識別され、そのパー
ティション番号が n で示されることを意味します。
KEY は、終了パーティションが実行時にパーティション・キー値か
ら識別されることを意味します。
ROW REMOVE_LOCATION は、終了パーティション（開始パーティ
ションと同じになります）が実行時に、取得される各レコードの位
置から計算されることを意味します。レコードの位置は、ユーザー
またはグローバル索引によって獲得されます。
INVALID は、アクセスしたパーティションの範囲が空であること
を意味します。
PARTITION_ID
NUMERIC
PARTITION_START と PARTITION_STOP 列の値の対を計算したス
テップです。
OTHER
LONG
ユーザーにとって有効な実行ステップに関するその他の情報です。
OTHER_TAG 列を参照してください。
DISTRIBUTION
VARCHAR2(30)
プロデューサ問合せサーバーからコンシューマ問合せサーバーへ行
を分配する方法です。
この列に使用可能な値の詳細は、表 19-2 を参照してください。コン
シューマ問合せサーバーおよびプロデューサ問合せサーバーの詳細
は、
『Oracle データ・ウェアハウス・ガイド』を参照してください。
CPU_COST
NUMERIC
問合せオプティマイザのアプローチによって見積もられた操作の
CPU コストです。この列の値は、操作に必要なマシン・サイクル数
に比例します。ルールベース・アプローチを使用する文では、この
列は NULL になります。
IO_COST
NUMERIC
問合せオプティマイザのアプローチによって見積もられた操作の
I/O コストです。この列の値は、操作で読み込まれるデータ・ブ
ロックの数に比例します。ルールベース・アプローチを使用する文
では、この列は NULL になります。
TEMP_SPACE
NUMERIC
問合せオプティマイザのアプローチで見積もられた、操作で使用さ
れる一時領域をバイト単位で表したものです。ルールベース・アプ
ローチを使用する文の場合、または一時領域を使用しない操作の場
合、この列は NULL です。
ACCESS_PREDICATES
VARCHAR2(4000)
アクセス構造の行を特定する場合に使用する述語です。たとえば、
索引レンジ・スキャンの開始や停止の述語などがあります。
FILTER_PREDICATES
VARCHAR2(4000)
フィルタにかけた後で行を生成する場合に使用する述語です。
19-26　Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 列
表 19-1 PLAN_TABLE 列（続き）
列
型
説明
PROJECTION
VARCHAR2(4000)
操作によって生成される式です。
TIME
NUMBER(20,2)
問合せの最適化によって見積もられた操作の秒単位の経過時間で
す。ルールベース・アプローチを使用する文では、この列は NULL
になります。
QBLOCK_NAME
VARCHAR2(30)
問合せブロックの名前です。システム生成または QB_NAME ヒント
によるユーザー定義のいずれかとなります。
表 19-2 で、DISTRIBUTION 列に使用される値を説明します。
表 19-2 PLAN_TABLE の DISTRIBUTION 列の値
DISTRIBUTION テキスト
説明
PARTITION (ROWID)
UPDATE または DELETE を実行する行の ROWID を使用し、表または索引のパーティ
ション化に基づいて行を問合せサーバーにマップします。
PARTITION (KEY)
列のセットを使用し、表または索引のパーティション化に基づいて行を問合せサーバー
にマップします。パーシャル・パーティション・ワイズ結合、PARALLEL INSERT、
パーティション表の CREATE TABLE AS SELECT および CREATE PARTITIONED GLOBAL
INDEX に使用します。
HASH
結合キーについて、ハッシュ関数を使用して、行を問合せサーバーにマップします。
PARALLEL JOIN または PARALLEL GROUP BY に使用します。
RANGE
ソート・キーの範囲を使用して、行を問合せサーバーにマップします。文に ORDER BY
句がある場合に使用します。
ROUND-ROBIN
行を問合せサーバーにランダムにマップします。
BROADCAST
表全体の行を各問合せサーバーにブロードキャストします。ある表がその他の表に比べ
て非常に小さい場合、パラレル結合に使用します。
QC (ORDER)
問合せコーディネータ（QC）が、最初の問合せサーバーから最後の問合せサーバーまで
順番に入力データを受け取ります。文に ORDER BY 句がある場合に使用します。
QC (RANDOM)
問合せコーディネータ（QC）が、入力データをランダムに受け取ります。文に ORDER
BY 句がない場合に使用します。
表 19-3 に、EXPLAIN PLAN 文によって生成される OPERATION と OPTIONS の各組合せおよ
びその実行計画におけるそれぞれの意味を示します。
EXPLAIN PLAN の使用方法
19-27
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値
操作
オプション
説明
AND-EQUAL
.
複数の ROWID のセットを受け取り、重複をなくして、そのセットの
共通部分を戻す処理。この処理は単一列索引のアクセス・パスに対し
て使用されます。
BITMAP
CONVERSION
TO ROWIDS は、ビットマップ表現を、表にアクセスするために使用で
きる実際の ROWID に変換します。
FROM ROWIDS は、ROWID をビットマップ表現に変換します。
COUNT は、実際の値を必要としない場合に ROWID の数を戻します。
BITMAP
INDEX
SINGLE VALUE は、索引内の単一のキー値のビットマップを参照しま
す。
RANGE SCAN は、ある範囲のキー値のビットマップを取り出します。
FULL SCAN は、開始キーまたは終了キーがない場合にビットマップ索
引の全体スキャンを実行します。
BITMAP
MERGE
レンジ・スキャンの結果の複数のビットマップを 1 つのビットマップ
にマージします。
BITMAP
MINUS
片方のビットマップのビットを、もう一方のビットマップから減算し
ます。行ソースは否定述語に対して使用されます。減算が発生する可
能性があるビットマップを作成する非否定述語がある場合にのみ使用
できます。19-13 ページの「EXPLAIN PLAN によるビットマップ索引
の表示」で例を示します。
BITMAP
OR
2 つのビットマップのビット単位の OR を計算します。
BITMAP
AND
2 つのビットマップのビット単位の AND を計算します。
BITMAP
KEY ITERATION
表の行ソースから各行を取り出し、ビットマップ索引から対応する
ビットマップを検索します。その後、このビットマップのセットは、
次の BITMAP MERGE 操作で 1 つのビットマップにマージされます。
CONNECT BY
.
CONNECT BY 句を含んでいる問合せについて階層順に行を取り出しま
す。
CONCATENATION
.
複数の行のセットを受け取り、そのセットの UNION-ALL を戻す処
理。
COUNT
.
表から選択された行の数をカウントする処理。
COUNT
STOPKEY
戻される行数を WHERE 句の ROWNUM 式によって制限するカウント処
理。
DOMAIN INDEX
.
ドメイン索引からの 1 つ以上の ROWID の取出し。オプション列には、
ユーザー定義ドメイン・インデックス・コスト関数から与えられた情
報が含まれています。
19-28　Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
FILTER
.
行のセットを受け取り、そのいくつかを取り除き、残りを戻す処理。
FIRST ROW
.
問合せで選択される最初の行のみの取出し。
FOR UPDATE
.
FOR UPDATE 句が含まれている問合せによって選択される行を取り出
し、ロックする処理。
HASH JOIN
.
2 つのセットの行を結合し、結果を戻す操作。この結合方法は、データ
のラージ・データ・セット（DSS やバッチなど）の結合に役立ちます。
この結合条件は、第 2 の表にアクセスする場合に有効です。
（これらは結合操作
です。）
問合せオプティマイザは、2 つの表またはデータ・ソースの小さいほう
を使用して、メモリー内に結合キーについてのハッシュ表を作成しま
す。次に、大きいほうの表をスキャンし、ハッシュ表を調べて結合さ
れた行を見つけます。
HASH JOIN
ANTI
ハッシュ（左側）アンチ結合。
HASH JOIN
SEMI
ハッシュ（左側）セミ結合。
HASH JOIN
RIGHT ANTI
ハッシュ右側アンチ結合。
HASH JOIN
RIGHT SEMI
ハッシュ右側セミ結合。
HASH JOIN
OUTER
ハッシュ（左側）外部結合。
HASH JOIN
RIGHT OUTER
ハッシュ（右側）外部結合。
INDEX
UNIQUE SCAN
索引からの単一の ROWID の取出し。
INDEX
RANGE SCAN
索引からの 1 つ以上の ROWID の取出し。索引値は昇順でスキャンさ
れます。
INDEX
RANGE SCAN
DESCENDING
索引からの 1 つ以上の ROWID の取出し。索引値は降順でスキャンさ
れます。
INDEX
FULL SCAN
スタート・キーおよびストップ・キーがない場合の、索引からのすべ
ての ROWID の取得。索引値は昇順でスキャンされます。
INDEX
FULL SCAN
DESCENDING
スタート・キーおよびストップ・キーがない場合の、索引からのすべ
ての ROWID の取得。索引値は降順でスキャンされます。
INDEX
FAST FULL SCAN
マルチブロック READ を使用した全 ROWID（および列の値）の取得。
ソート順は定義できません。索引付けされた列に対してのみ、全表ス
キャンと比較されます。コストベース・オプティマイザでのみ使用可
能です。
（これらはアクセス
方法です。）
EXPLAIN PLAN の使用方法
19-29
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
INDEX
SKIP SCAN
索引内の先頭列を使用しない、連結索引からの ROWID の取得。
Oracle9i で導入されています。コストベース・オプティマイザでのみ
使用可能です。
INLIST ITERATOR
.
IN リスト述語内の各値に対して、計画内の次の操作を反復します。
INTERSECTION
.
2 つの行のセットを受け取り、重複をなくして、そのセットの共通部分
を戻す処理。
MERGE JOIN
.
2 つの行のセットを受け取り、それぞれを特定の値でソートし、一方の
セットの各行を他方の行と突き合せて結合し、その結果を戻す処理。
MERGE JOIN
OUTER
外部結合文を実行するマージ結合処理。
MERGE JOIN
ANTI
マージ・アンチ結合。
MERGE JOIN
SEMI
マージ・セミ結合。
MERGE JOIN
CARTESIAN
文中に他の表への結合条件を持たない 1 つ以上の表について発生する
操作です。結合とともに発生する可能性がありますが、計画内では
CARTESIAN とフラグが付かないことがあります。
CONNECT BY
.
CONNECT BY 句を含んでいる問合せに対する、階層順での行の取出し。
MINUS
.
2 つの行のセットを受け取り、最初のセットにあって 2 番目のセットに
ない行を戻して、重複をなくす処理。
NESTED LOOPS
.
外側のセットと内側のセット、2 つの行のセットを受け取る処理。
Oracle は、外側のセットの各行を内側のセットの各行と比較し、条件
を満たす行を戻します。この結合方法は、小さいサブセットのデータ
を結合する場合（OLTP）に役立ちます。この結合条件は、第 2 の表に
アクセスする場合に有効です。
NESTED LOOPS
OUTER
外部結合文を実行するネステッド・ループ操作。
PARTITION
.
PARTITION_START 列および PARTITION_STOP 列によって指定され
た範囲の各パーティションに対して、計画内の次の操作を反復します。
PARTITION は、単一のパーティション・オブジェクト（表または索
引）や同じ数でパーティション化されたオブジェクトのセット（パー
ティション表やそのローカル索引）に適用できるパーティションの区
間を示します。パーティションの区間は、PARTITION の
PARTITION_START および PARTITION_STOP の値で指定されます。
PARTITION_START および PARTITION_STOP の有効な値は、表 19-1
を参照してください。
PARTITION
SINGLE
1 つのパーティションへのアクセス。
PARTITION
ITERATOR
多数のパーティション（サブセット）へのアクセス。
（これらは結合操作
です。）
（これらは結合操作
です。）
19-30　Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
PARTITION
ALL
すべてのパーティションへのアクセス。
PARTITION
INLIST
IN リスト述語を基準にしたイテレータ。
PARTITION
INVALID
アクセスするよう設定されているパーティションが空であることを示
します。
PX ITERATOR
BLOCK、CHUNK
パラレル・スレーブ・セット間でのブロックまたはチャンク範囲への
オブジェクトの分割を実装します。
PX COORDINATOR
.
パラレル問合せスレーブを使用して下位のパラレル計画を制御、スケ
ジュールおよび実行する問合せコーディネータを実装します。また、パ
ラレルに実行され、常に下位に PX SEND QC 操作を持つ計画部分の終
わりとして、シリアライズ・ポイントを表します。
PX PARTITION
.
セマンティクスは通常の PARTITION 操作と同じですが、パラレル計
画に表示されます。
PX RECEIVE
.
PX SEND ノード上で実行される送信側 / プロデューサ（QC またはス
レーブ）からパーティション化されたデータを読み取る、コンシュー
マ / 受信側スレーブ・ノードを示します。以前は、この情報は
DISTRIBUTION 列に表示されていました。19-27 ページの表 19-2 を参
照してください。
PX SEND
QC (RANDOM)、
HASH、RANGE
REMOTE
.
リモート・データベースからのデータの取出し。
SEQUENCE
.
順序値のアクセスを伴う処理。
SORT
AGGREGATE
選択した行のグループにグループ関数を適用した結果として取得され
る単一行の取出し。
SORT
UNIQUE
行のセットをソートし、重複をなくす処理。
SORT
GROUP BY
GROUP BY 句を持つ問合せで、行のセットを複数のグループにソートす
る処理。
SORT
JOIN
マージ結合の前に、一連の行をソートする操作。
SORT
ORDER BY
ORDER BY 句を持つ問合せに対して行のセットをソートする処理。
TABLE ACCESS
FULL
表のすべての行の取出し。
スレーブの 2 つのパラレル・セットの間における配分方法を実装しま
す。2 つのスレーブ・セット間の境界と、送信側 / プロデューサ側
（QC またはスレーブ）でのデータのパーティション化方法を示します。
以前は、この情報は DISTRIBUTION 列に表示されていました。19-27
ページの表 19-2 を参照してください。
（これらはアクセス
方法です。）
EXPLAIN PLAN の使用方法
19-31
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
TABLE ACCESS
SAMPLE
表のサンプル採取された行の取出し。
TABLE ACCESS
CLUSTER
索引クラスタのキーの値に基づいた、表からの行の取出し。
TABLE ACCESS
HASH
ハッシュ・クラスタのキーの値に基づいた、表からの行の取出し。
TABLE ACCESS
BY ROWID RANGE
ROWID 範囲に基づいた表からの行の取出し。
TABLE ACCESS
SAMPLE BY ROWID
RANGE
ROWID 範囲に基づいた表からのサンプル行の取出し。
TABLE ACCESS
BY USER ROWID
ユーザー指定の ROWID を使用して表の行が指定される場合。
TABLE ACCESS
BY INDEX ROWID
表がパーティション化されておらず、索引を使用して行が指定される
場合。
TABLE ACCESS
BY GLOBAL INDEX
ROWID
表がパーティション化されており、グローバル索引のみを使用して行
が指定される場合。
TABLE ACCESS
BY LOCAL INDEX
ROWID
表がパーティション化されており、1 つ以上のローカル索引と場合に
よってはいくつかのグローバル索引を使用して、行が指定される場合。
パーティション区間 :
パーティション区間は次のようにして計算されている可能性がありま
す。
前の PARTITION ステップによって決定される場合。この場合、
PARTITION_START 列の値と PARTITION_STOP 列の値は
PARTITION ステップ内の値をレプリケートし、PARTITION_ID には
PARTITION ステップの ID が組み込まれます。PARTITION_START お
よび PARTITION_STOP に使用できる値は、NUMBER(n)、KEY、
INVALID です。
TABLE ACCESS または INDEX ステップ自体で決定される場合。この場
合、PARTITION_ID にはそのステップの ID が組み込まれます。
PARTITION_START および PARTITION_STOP に使用できる値は、
NUMBER(n)、KEY、ROW REMOVE_LOCATION（TABLE ACCESS のみ）
および INVALID です。
UNION
.
2 つの行のセットを受け取り、重複をなくして、そのセットの連結結果
を戻す処理。
VIEW
.
ビューの問合せを実行し、結果の行を別の処理に戻す処理。
関連項目 : PLAN_TABLE の詳細は、
『Oracle Database リファレンス』を
参照してください。
19-32　Oracle Database パフォーマンス・チューニング・ガイド
20
アプリケーション・トレース・ツールの
使用方法
Oracle では、Oracle データベースで実行されるアプリケーションの監視および分析に役立つ
トレース・ツールをいくつか提供しています。
End to End Application Tracing では、高負荷の SQL 文などの過剰なワークロードのソース
を、クライアント識別子、サービス、モジュールまたはアクションによって識別できます。
これによって、問題が特定のユーザー、サービスまたはアプリケーション・コンポーネント
に特定されます。
Oracle では、特定の基準に基づいてトレース情報を統合する trcsess コマンドライン・
ユーティリティを提供します。
SQL トレース機能および TKPROF は、Oracle サーバーのもとで実行されるアプリケーショ
ンの監視に役立つ 2 つの基本的なパフォーマンス診断ツールです。
この章には次の項があります。
■
End to End Application Tracing
■
trcsess ユーティリティの使用方法
■
SQL トレースと TKPROF について
■
SQL トレース機能と TKPROF の使用方法
■
TKPROF の解釈における誤りの回避
■
TKPROF の出力例
関連項目 : 自動トレースを使用した SQL*Plus 文のトレースおよびチュー
ニングの詳細は、
『SQL*Plus ユーザーズ・ガイドおよびリファレンス』を
参照してください。
アプリケーション・トレース・ツールの使用方法
20-1
End to End Application Tracing
End to End Application Tracing
End to End Application Tracing を使用すると、複数層環境におけるパフォーマンス問題の診
断プロセスが簡素化されます。複数層環境では、エンド・クライアントからの要求は中間層
により様々なデータベース・セッションにルーティングされるため、異なるデータベース・
セッション間でクライアントを追跡しにくくなっています。End to End Application Tracing
では、クライアント識別子により、すべての層を通してデータベース・サーバーまで、特定
のエンドクライアントが一意にトレースされます。
この機能では、高負荷の SQL 文などの過剰なワークロードのソースを識別でき、担当する
特定のユーザーに連絡をとることができます。また、問題のあるユーザーから連絡を受け、
データベース・レベルでのユーザーのセッションの動作を識別できます。
さらに、End to End Application Tracing では、あるサービスの特定のモジュールおよびアク
ションを追跡することで、アプリケーション・ワークロードの管理が簡素化されます。
End to End Application Tracing によりワークロードの問題を識別できるのは、次のとおりで
す。
■
■
■
■
クライアント識別子 : HR.HR などのログオン ID に基づいてエンド・ユーザーを指定しま
す。
サービス : 共通の属性、サービス・レベルのしきい値および優先順位を使用してアプリ
ケーション・グループを指定するか、または会計アプリケーションの場合は ACCTG な
どのように単一アプリケーションを指定します。
モジュール : 売掛勘定または総勘定元帳など、アプリケーションの機能ブロックを指定
します。
アクション : INSERT または UPDATE 操作など、モジュール内のアクションを指定しま
す。
トレース情報がファイルに書き込まれた後、この情報を trcsess ユーティリティによって
統合し、TKPROF などの分析ユーティリティによって診断できます。
単一インスタンスの Oracle データベースでサービスを作成するには、DBMS_SERVICE パッ
ケージの CREATE_SERVICE プロシージャを使用するか、または SERVICE_NAMES 初期化パ
ラメータを設定できます。
モジュール名およびアクション名は、アプリケーション開発者が設定します。たとえば、
PL/SQL プログラムでこれらの値を設定するには、DBMS_APPICATION_INFO パッケージの
SET_MODULE および SET_ACTION プロシージャを使用します。
20-2　Oracle Database パフォーマンス・チューニング・ガイド
End to End Application Tracing
関連項目 :
■
■
■
■
サービスの詳細は、
『Oracle Database 概要』を参照してください。
OCI アプリケーションにおける必要なパラメータの設定の詳細は、
『Oracle Call Interface プログラマーズ・ガイド』を参照してください。
DBMS_MONITOR、DBMS_SERVICE および DBMS_APPICATION_INFO
の各パッケージの詳細は、
『PL/SQL パッケージ・プロシージャおよ
びタイプ・リファレンス』を参照してください。
V$ ビューおよび初期化パラメータの詳細は、
『Oracle Database リファ
レンス』を参照してください。
Oracle Enterprise Manager を使用した End to End Application Tracing へのアク
セス
End to End Application Tracing への主インタフェースは、Oracle Enterprise Manager
Database Control です。Oracle Enterprise Manager Database Control を介して End to End
Application Tracing を管理する手順は、次のとおりです。
■
■
■
「Performance」
」ページで、「Additional Monitoring Links」
」の下の「
「Top Consumers」
」
リンクを選択します。
「Top Services」
」、
「Top Modules」
」
、「Top Actions」
」、
「Top Clients」
」または「
「Top
Sessions」
」リンクをクリックし、上位コンシューマを表示します。
個々の「
「Top Consumers」
」ページで、特定のコンシューマの統計収集およびトレースを
使用可能または使用禁止にできます。
関連項目 : Oracle Enterprise Manager で使用可能なトレース・ツールの
詳細は、
『Oracle Enterprise Manager 概要』および Oracle Enterprise
Manager オンライン・ヘルプを参照してください。
API およびビューを使用した End to End Application Tracing の管理
End to End Application Tracing の主インタフェースは Oracle Enterprise Manager Database
Control ですが、この機能は DBMS_MONITOR パッケージの API で管理できます。
エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化
PL/SQL を使用して適切な統計を収集するには、DBMS_MONITOR パッケージのプロシー
ジャを使用して、クライアント識別子、サービス、モジュールまたはアクションに対する統
計収集を使用可能にする必要があります。
次の基準による統計収集が可能です。
アプリケーション・トレース・ツールの使用方法
20-3
End to End Application Tracing
■
クライアント識別子
■
サービス名
■
サービス名、モジュール名およびアクション名の組合せ
デフォルト・レベルは、セッション・レベルの統計収集です。統計収集はデータベース全体
を対象にしており、インスタンスの再起動後も引き続き行われます。
クライアント識別子に対する統計収集 プロシージャ CLIENT_ID_STAT_ENABLE では、特
定のクライアント識別子に対する統計収集が使用可能になります。たとえば、特定のクライ
アント識別子に対する統計収集を使用可能にするには、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_ENABLE(client_id => 'OE.OE');
この例では、OE.OE は、統計を収集する対象のクライアント識別子です。V$SESSION の
CLIENT_IDENTIFIER 列でクライアント識別子を表示できます。
プロシージャ CLIENT_ID_STAT_DISABLE では、特定のクライアント識別子に対する統計
収集が使用禁止になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_DISABLE(client_id => 'OE.OE');
サービス、モジュールおよびアクションに対する統計収集 プロシージャ SERV_MOD_ACT_
STAT_ENABLE では、サービス、モジュールおよびアクションの組合せに対する統計収集が
使用可能になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'ACCTG',
module_name => 'PAYROLL');
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'ACCTG',
module_name => 'GLEDGER', action_name => 'INSERT ITEM');
前のコマンドが両方とも実行された場合、統計は次のように収集されます。
■
ACCTG サービスに関する統計（各サービス名の累積がデフォルトであるため）
■
PAYROLL モジュール内のすべてのアクションに関する統計
■
GLEDGER モジュール内の INSERT ITEM アクションに関する統計
プロシージャ SERV_MOD_ACT_STAT_DISABLE では、サービス、モジュールおよびアク
ションの組合せに対する統計収集が使用禁止になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_DISABLE(service_name => 'ACCTG',
module_name => 'GLEDGER', action_name => 'INSERT ITEM');
20-4　Oracle Database パフォーマンス・チューニング・ガイド
End to End Application Tracing
End to End Application Tracing の収集した統計の表示
収集された統計は、様々な動的ビューで表示できます。
■
■
■
■
■
現在使用可能な統計の累積グローバル統計は、DBA_ENABLED_AGGREGATIONS ビュー
で表示できます。
指定されたクライアント識別子の累積統計は、V$CLIENT_STATS ビューで表示できま
す。
指定されたサービスの累積統計は、V$SERVICE_STATS ビューで表示できます。
指定されたサービス、モジュールおよびアクションの組合せの累積統計は、V$SERV_
MOD_ACT_STATS ビューで表示できます。
データベース・コールの経過時間および CPU 使用率の累積統計は、V$SVCMETRIC
ビューで表示できます。
エンド・トゥ・エンド・トレースにおける有効化および無効化
クライアント識別子、サービス、モジュールまたはアクションのトレースを使用可能にする
には、DBMS_MONITOR パッケージの適切なプロシージャを実行する必要があります。次の
基準により、特定の診断およびワークロード管理のトレースを使用可能にできます。
■
特定のクライアントの識別子
■
サービス名、モジュール名およびアクション名の組合せ
■
セッション
指定した基準により、特定のトレース情報がトレース・ファイルのセットに収集され、1 つ
の出力トレース・ファイルに結合されます。
クライアント識別子のトレース CLIENT_ID_TRACE_ENABLE プロシージャでは、データ
ベースにおける特定のクライアント識別子のトレースが全体的に使用可能になります。たと
えば、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE(client_id => 'OE.OE',
waits => TRUE, binds => FALSE);
この例では、OE.OE は、SQL トレースを使用可能にするクライアント識別子です。TRUE 引
数は、待機情報がトレースに含められることを指定します。FALSE 引数は、バインド情報が
トレースに含められないことを指定します。
CLIENT_ID_TRACE_DISABLE プロシージャでは、データベースにおける特定のクライアン
ト識別子のトレースが全体的に使用禁止になります。前の例でトレースを使用禁止にするに
は、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE(client_id => 'OE.OE');
アプリケーション・トレース・ツールの使用方法
20-5
End to End Application Tracing
サービス、モジュールおよびアクションのトレース SERV_MOD_ACT_TRACE_ENABLE プロ
シージャでは、データベースにおける、サービス名、モジュールおよびアクションの指定の
組合せの SQL トレースが全体的に使用可能になります。ただし、このプロシージャでイン
スタンス名が指定されている場合を除きます。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(service_name => 'ACCTG',
waits => TRUE, binds => FALSE, instance_name => 'inst1');
この例では、サービス ACCTG が指定されています。モジュールまたはアクション名は指定
されていません。TRUE 引数は、待機情報がトレースに含められることを指定します。
FALSE 引数は、バインド情報がトレースに含められないことを指定します。inst1 インス
タンスが指定されているため、このインスタンスのトレースのみが使用可能になります。
サービスおよびモジュールの指定の組合せについてすべてのアクションのトレースを使用可
能にするには、次のようにします。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(service_name => 'ACCTG',
module_name => 'PAYROLL', waits => TRUE, binds => FALSE,
instance_name => 'inst1');
SERV_MOD_ACT_TRACE_DISABLE プロシージャでは、サービス名、モジュールおよびアク
ション名の指定の組合せについて、使用可能なすべてのインスタンスにおけるトレースが全
体的に使用禁止になります。たとえば、次の文では、この項の最初の例のトレースが使用禁
止になります。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(service_name => 'ACCTG',
instance_name => 'inst1');
この例では、この項の 2 つ目の例のトレースが使用禁止になります。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(service_name => 'ACCTG',
module_name => 'PAYROLL', instance_name => 'inst1');
セッションのトレース SESSION_TRACE_ENABLE プロシージャでは、ローカル・インスタ
ンスにおける、特定のデータベース・セッション識別子（SID）のトレースが使用可能にな
ります。
特定のセッション ID およびシリアル番号のトレースを使用可能にするには、トレースする
セッションの値を決定します。
SELECT SID, SERIAL#, USERNAME FROM V$SESSION;
SID
SERIAL# USERNAME
---------- ---------- -----------------------------27
60 OE
...
20-6　Oracle Database パフォーマンス・チューニング・ガイド
trcsess ユーティリティの使用方法
特定のセッションのトレースを使用可能にするには、適切な値を使用します。
EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => 27, serial_num => 60,
waits => TRUE, binds => FALSE);
TRUE 引数は、待機情報がトレースに含められることを指定します。FALSE 引数は、バイン
ド情報がトレースに含められないことを指定します。
SESSION_TRACE_DISABLE プロシージャでは、特定のデータベース・セッション識別子
（SID）およびシリアル番号のトレースが使用禁止になります。たとえば、次のようにしま
す。
EXECUTE DBMS_MONITOR.SESSION_TRACE_DISABLE(session_id => 27, serial_num => 60);
エンド・トゥ・エンド・トレースにおける使用可能なトレースの表示
未処理のトレースはすべて、Oracle Enterprise Manager レポートで、または DBA_
ENABLED_TRACES ビューで表示できます。DBA_ENABLED_TRACES ビューでは、トレー
ス・タイプを含め、トレースを使用可能にした方法に関する詳細を判断できます。トレー
ス・タイプは、クライアント識別子、セッション、サービスまたはサービス、モジュールお
よびアクションの組合せについてトレースが使用可能かどうかを指定します。
trcsess ユーティリティの使用方法
trcsess ユーティリティでは、次の複数の基準に基づいて、選択されたトレース・ファイ
ルからのトレース出力が統合されます。
■
セッション ID
■
クライアント ID
■
サービス名
■
アクション名
■
モジュール名
trcsess によりトレース情報が 1 つの出力ファイルにマージされた後、出力ファイルを
TKPROF によって処理できます。
trcsess は、パフォーマンスまたはデバッグを向上させるため、特定のセッションのト
レースを統合する際に便利です。特定のセッションのトレースは、専用サーバー・モデルで
は、1 つの専用プロセスが存続期間中ずっと 1 つのセッションに対応するため、通常は問題
になりません。このセッションのトレース情報はすべて、このセッションに対応する専用
サーバーに属するトレース・ファイルで参照できます。ただし、共有サーバー構成では、
ユーザー・セッションが様々なプロセスで対応される場合があります。ユーザー・セッショ
ンに関連するトレースは、様々なプロセスに属する各種トレース・ファイル間で分散されま
す。そのため、セッションの存続期間におけるすべての状況を把握しにくくなります。
アプリケーション・トレース・ツールの使用方法
20-7
trcsess ユーティリティの使用方法
trcsess の構文
trcsess ユーティリティの構文は、次のとおりです。
trcsess
[output=output_file_name]
[session=session_id]
[clientid=client_id]
[service=service_name]
[action=action_name]
[module=module_name]
[trace_files]
各項目の意味は次のとおりです。
■
■
output は、出力の生成場所となるファイルを指定します。このオプションが指定され
ていない場合、出力に標準出力が使用されます。
session は、指定されたセッションのトレース情報を統合します。セッション識別子
は、セッション索引とセッション・シリアル番号の組合せ（21.2371 など）です。こ
れらの値は V$SESSION ビューで見つけることができます。
■
clientid は、特定のクライアント ID のトレース情報を統合します。
■
service は、特定のサービス名のトレース情報を統合します。
■
action は、特定のアクション名のトレース情報を統合します。
■
module は、特定のモジュール名のトレース情報を統合します。
■
trace_files は、スペースで区切られたすべてのトレース・ファイル名のリストであ
り、ここで trcsess はトレース情報を検索する必要があります。ワイルド・カード文
字 * を使用して、トレース・ファイル名を指定できます。トレース・ファイルが指定さ
れていない場合、現在のディレクトリのすべてのファイルが trcsess への入力データ
とみなされます。
session、clientid、service、action または module オプションのいずれかを指定す
る必要があります。session、clientid、service、action または module オプション
が複数指定されている場合、指定されたすべての基準を満たすトレース・ファイルが出力
ファイルに統合されます。
20-8　Oracle Database パフォーマンス・チューニング・ガイド
trcsess ユーティリティの使用方法
trcsess の出力例
この trcsess の出力例は、特定のセッションにおけるトレースの統合を示しています。こ
の例では、セッション索引およびシリアル番号は 21.2371 となります。
trcsess は様々なオプションで起動できます。次の場合、現在のディレクトリのすべての
ファイルが入力データとみなされます。
trcsess session=21.2371
この場合、複数のトレース・ファイルが指定されています。
trcsess session=21.2371 main_12359.trc main_12995.trc
出力例は次のようになります。
[PROCESS ID = 12359]
*** 2002-04-02 09:48:28.376
PARSING IN CURSOR #1 len=17 dep=0 uid=27 oct=3 lid=27 tim=868373970961 hv=887450622
ad='22683fb4'
select * from cat
END OF STMT
PARSE #1:c=0,e=339,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=868373970944
EXEC #1:c=0,e=221,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=868373971411
FETCH #1:c=0,e=791,p=0,cr=7,cu=0,mis=0,r=1,dep=0,og=4,tim=868373972435
FETCH #1:c=0,e=1486,p=0,cr=20,cu=0,mis=0,r=6,dep=0,og=4,tim=868373986238
*** 2002-04-02 10:03:58.058
XCTEND rlbk=0, rd_only=1
STAT #1 id=1 cnt=7 pid=0 pos=1 obj=0 op='FILTER '
STAT #1 id=2 cnt=7 pid=1 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ$ '
STAT #1 id=3 cnt=7 pid=2 pos=1 obj=37 op='INDEX RANGE SCAN I_OBJ2 '
STAT #1 id=4 cnt=0 pid=1 pos=2 obj=4 op='TABLE ACCESS CLUSTER TAB$J2 '
STAT #1 id=5 cnt=6 pid=4 pos=1 obj=3 op='INDEX UNIQUE SCAN I_OBJ# '
[PROCESS ID=12995]
*** 2002-04-02 10:04:32.738
Archiving is disabled
Archiving is disabled
アプリケーション・トレース・ツールの使用方法
20-9
SQL トレースと TKPROF について
SQL トレースと TKPROF について
SQL トレース機能および TKPROF を使用すると、アプリケーションが実行する SQL 文の効
率を正確に評価できます。最善の結果を得るには、EXPLAIN PLAN を単体ではなくこれらの
ツールとともに使用してください。
SQL トレース機能について
SQL トレース機能は、個々の SQL 文に関するパフォーマンス情報を提供します。SQL ト
レース機能は、文単位に次の統計を生成します。
■
解析、実行、フェッチのカウント
■
CPU 時間と経過時間
■
物理読込みと論理読込み
■
処理された行数
■
ライブラリ・キャッシュでのミス
■
それぞれの解析が行われるユーザー名
■
各コミットおよびロールバック
■
各 SQL 文の待機イベント・データおよび各トレース・ファイルの要約
また、SQL 文のカーソルがクローズされている場合は、SQL トレースにより次の内容を含
む行ソース情報が提供されます。
■
■
各 SQL 文の実際の実行計画を示す行操作
行数、一貫性のある読込みの数、物理読込み数、物理書込み数および行の各操作の経過
時間
セッションまたはインスタンスに対して、SQL トレース機能を使用可能にできます。SQL
トレース機能が使用可能にされると、ユーザー・セッションまたはインスタンスで実行され
るすべての SQL 文のパフォーマンス統計がトレース・ファイルに格納されます。
Oracle では、セッションまたはクライアント ID などの特定の基準に基づいて複数のトレー
ス・ファイルからトレース情報を統合する、trcsess コマンドライン・ユーティリティが
提供されています。20-7 ページの「trcsess ユーティリティの使用方法」を参照してくださ
い。
パフォーマンスに問題のあるアプリケーションに対して SQL トレース機能を実行する際の
オーバーヘッドは、アプリケーションの非効率性から発生するオーバーヘッドと比較すると
通常わずかです。
20-10　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレースと TKPROF について
注意 : SQL トレースは、特定のセッションにおける統計収集に対しての
み使用可能にするようにしてください。この機能を本番環境全体で使用可
能にする必要がある場合は、次を行うことによりパフォーマンスの影響を
最小限にとどめます。
■
最低 25% の CPU のアイドル状態を維持すること
■
USER_DUMP_DEST 位置に対する適切なディスク領域の維持
■
十分なディスクでのディスク領域のストライプ化
TKPROF について
TKPROF プログラムを実行すると、トレース・ファイルの内容をフォーマットし判読可能な
ファイルとして出力できます。TKPROF は次のことも実行します。
■
統計をデータベースに格納する SQL スクリプトを作成します。
■
SQL 文の実行計画を判断します。
注意 : SQL 文のカーソルがクローズされていない場合、TKPROF 出力に
は、SQL 文の実際の実行計画は自動的に含められません。この場合は、
TKPROF で EXPLAIN オプションを使用して、実行計画を生成できます。
TKPROF は、実行した各文を、消費したリソースおよびコールした回数、処理した行数とと
もにレポートします。この情報を使用すると、リソースを最も多く使用している文を簡単に
検出できます。経験、または参考にできる基準をもとに、使用されたリソースが実行された
作業に対して妥当であるかどうかを評価できます。
アプリケーション・トレース・ツールの使用方法
20-11
SQL トレース機能と TKPROF の使用方法
SQL トレース機能と TKPROF の使用方法
SQL トレース機能および TKPROF を使用するには、次の手順に従います。
1.
トレース・ファイル管理用の初期化パラメータを設定します。
20-12 ページの「手順 1: トレース・ファイル管理用の初期化パラメータの設定」を参照
してください。
2.
対象とするセッションに対して SQL トレース機能を使用可能にして、アプリケーショ
ンを実行します。手順 2 では、アプリケーションによって発行された SQL 文に関する
統計を含むトレース・ファイルが作成されます。
20-15 ページの「手順 2: SQL トレース機能を使用可能にする方法」を参照してくださ
い。
3.
手順 2 で作成されるトレース・ファイルを判読可能な出力ファイルに変換するために、
TKPROF を実行します。手順 3 ではオプションとして、データベースに統計を格納する
のに使用できる SQL スクリプトを作成できます。
20-16 ページの「手順 3: TKPROF によるトレース・ファイルのフォーマット」を参照し
てください。
4.
手順 3 で作成した出力ファイルを解釈します。
20-21 ページの「手順 4: TKPROF 出力の解釈」を参照してください。
5.
任意で、手順 3 で作成した SQL スクリプトを実行してデータベースに統計を格納しま
す。
20-27 ページの「手順 5: SQL トレース機能統計の格納」を参照してください。
次の項では、これらの各手順について詳しく説明します。
手順 1: トレース・ファイル管理用の初期化パラメータの設定
セッションに対して SQL トレース機能が使用可能になると、Oracle はトレース・ファイル
を生成します。このファイルには、そのセッションのトレースされた SQL 文に関する統計
が記録されています。インスタンスに対して SQL トレース機能が使用可能になると、Oracle
はプロセスごとに個別のトレース・ファイルを作成します。SQL トレース機能を有効にする
前に、次のことを行ってください。
1.
TIMED_STATISTICS、MAX_DUMP_FILE_SIZE および USER_DUMP_DEST の初期化パ
ラメータ設定をチェックします。表 20-1 を参照してください。
20-12　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
表 20-1 SQL トレース機能を有効にする前にチェックする初期化パラメータ
パラメータ
説明
TIMED_STATISTICS
これにより、SQL トレース機能による CPU 時間や経過時間などの
時間統計の収集、および動的パフォーマンス表の中の様々な統計の
収集が使用可能または使用禁止にできます。デフォルト値は false
であり、時間計測は使用禁止になっています。true にすることに
よって時間計測が使用可能になります。時間計測を使用可能にする
と、下位レベル操作に対する時間計測呼出しが余分に発生します。
これは動的パラメータです。これはセッション・パラメータでもあ
ります。
MAX_DUMP_FILE_SIZE
SQL トレース機能がインスタンス・レベルで使用可能にされている
ときは、サーバーに対するすべてのコールはオペレーティング・シ
ステムのファイル形式でテキスト行を生成します。これらのファイ
ルの最大サイズ（オペレーティング・システム・ブロック単位）
は、初期化パラメータによって制限されます。デフォルト値は 500
です。トレース出力が切り捨てられている場合、別のトレース・
ファイルを生成する前にこのパラメータの値を大きくしてくださ
い。これは動的パラメータです。これはセッション・パラメータで
もあります。
USER_DUMP_DEST
このパラメータで、オペレーティング・システムの規則に従って、
トレース・ファイルの出力先をフルパスで指定する必要がありま
す。デフォルト値は、使用するオペレーティング・システムのシス
テム・ダンプのデフォルトの出力先です。この値は、ALTER
SYSTEM SET USER_DUMP_DEST= newdir を使用して変更できま
す。これは動的パラメータです。これはセッション・パラメータで
もあります。
関連項目 :
■
■
■
■
STATISTICS_LEVEL、DB_CACHE_ADVICE、TIMED_STATISTICS ま
たは TIMED_OS_STATISTICS 初期化パラメータを設定する場合の考
慮事項は、5-7 ページの「統計の解釈」を参照してください。
STATISTICS_LEVEL の設定の詳細は、10-7 ページの「統計収集のレ
ベルの設定」を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
動的パフォーマンス・ビュー V$STATISTICS_LEVEL の詳細は、
『Oracle Database リファレンス』を参照してください。
アプリケーション・トレース・ツールの使用方法
20-13
SQL トレース機能と TKPROF の使用方法
2.
結果のトレース・ファイルを認識する方法を考えます。
トレース・ファイルを名前で区別できるようにしてください。Oracle は、USER_DUMP_
DEST で指定されたユーザー・ダンプ出力先にこれらを書き込みます。ただし、この
ディレクトリは通常、生成された名前を持つ何百ものファイルですぐに一杯になりま
す。このため、トレース・ファイルを生成元のセッションやプロセスに対応づけること
は困難な場合があります。SELECT 'program_name' FROM DUAL のような文をプログ
ラムに組み込むことによって、トレース・ファイルにタグを付けることができます。こ
れによって、各ファイルの生成元のプロセスを追跡できます。
TRACEFILE_IDENTIFIER 初期化パラメータを設定し、トレース・ファイル名の一部と
なるカスタム識別子も指定できます。たとえば、次の文によって、後続のトレース・
ファイル名に my_trace_id を追加し、識別しやすくできます。
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'my_trace_id';
関連項目 : TRACEFILE_IDENTIFIER 初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照してください。
3.
オペレーティング・システムがファイルの複数のバージョンを保持している場合、SQL
トレース機能が生成するトレース・ファイルの数に対して、バージョンの制限が十分高
いことを確認してください。
4.
生成されたトレース・ファイルの所有者は、データベース管理者以外のオペレーティン
グ・システム・ユーザーの場合があります。データベース管理者が TKPROF を実行して
これらのファイルをフォーマットする場合は、このユーザーが前もって、管理者がト
レース・ファイルを利用できる状態にしておく必要があります。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-7 ページの「統計収集のレ
ベルの設定」を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
20-14　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
手順 2: SQL トレース機能を使用可能にする方法
セッションに対して SQL トレース機能を使用可能にするには、次のいずれかを使用します。
■
DBMS_SESSION.SET_SQL_TRACE プロシージャ
■
ALTER SESSION SET SQL_TRACE = TRUE;
注意 : SQL トレース機能を実行するとシステムのオーバーヘッドが増加
するので、この機能は SQL 文をチューニングするときにのみ使用可能に
し、チューニングが終了してから使用禁止にしてください。
ALTER SESSION 文を挿入するには、アプリケーションを修正する必要が
あります。たとえば、Oracle Forms で ALTER SESSION 文を発行するに
は、-s オプションを指定して Oracle Forms を起動するか、または
statistics オプションを指定して Oracle Forms（Design）を起動して
ください。
SQL トレース機能を使用禁止にするには、次のように入力します。
ALTER SESSION SET SQL_TRACE = FALSE;
アプリケーションが Oracle との接続を切断すると、そのセッションの SQL トレース機能は
自動的に使用禁止になります。
初期化ファイルの SQL_TRACE 初期化パラメータの値を TRUE に設定すると、インスタンス
に対して SQL トレース機能が使用可能になります。
SQL_TRACE = TRUE
更新済初期化パラメータ・ファイルを使用してインスタンスを再起動すると、インスタンス
に対して SQL トレースが使用可能になり、すべてのセッションに関する統計が収集されま
す。インスタンスに対して SQL トレース機能を使用可能にした場合は、SQL_TRACE パラ
メータの値を FALSE に設定すると使用禁止にできます。
注意 : SQL_TRACE を TRUE に設定すると、サーバーのパフォーマンス
に重大な影響を与えることがあります。詳細は、
『Oracle Database リファ
レンス』を参照してください。
アプリケーション・トレース・ツールの使用方法
20-15
SQL トレース機能と TKPROF の使用方法
手順 3: TKPROF によるトレース・ファイルのフォーマット
TKPROF は、SQL トレース機能によって生成されたトレース・ファイルを入力として受け入
れ、フォーマットされた出力ファイルを生成します。TKPROF は、実行計画の生成にも使用
できます。
SQL トレース機能によって多数のトレース・ファイルが生成されると、次を実行できるよう
になります。
■
■
■
各トレース・ファイルごとに TKPROF を実行して、フォーマットした出力ファイルを各
セッションに 1 つずつ作成できます。
トレース・ファイルを連結し、その結果のファイルに対して TKPROF を実行して、イン
スタンス全体のフォーマットした出力ファイルを生成できます。
trcsess コマンドライン・ユーティリティを実行して複数のトレース・ファイルからト
レース情報を統合し、結果に対して TKPROF を実行します。20-7 ページの「trcsess ユー
ティリティの使用方法」を参照してください。
TKPROF は、トレース・ファイルに記録されている COMMIT および ROLLBACK をレポートし
ません。
TKPROF の出力例
TKPROF の出力例は次のようになります。
SELECT * FROM emp, dept
WHERE emp.deptno = dept.deptno;
call
count
---- ------Parse
1
Execute
1
Fetch
1
cpu
------0.16
0.00
0.03
elapsed
disk
query current
--------- -------- -------- ------0.29
3
13
0
0.00
0
0
0
0.26
2
2
4
Misses in library cache during parse: 1
Parsing user id: (8) SCOTT
rows
-----0
0
14
Rows
Execution Plan
------- --------------------------------------------------14 MERGE JOIN
4
SORT JOIN
4
TABLE ACCESS (FULL) OF 'DEPT'
14
SORT JOIN
14
TABLE ACCESS (FULL) OF 'EMP'
20-16　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
この文では、TKPROF 出力に次の情報が含まれています。
■
SQL 文のテキスト
■
表形式で示された SQL トレース統計
■
文の解析と実行におけるライブラリ・キャッシュ・ミスの回数
■
文を最初に解析したユーザー
■
EXPLAIN PLAN によって生成された実行計画
TKPROF は、トレース・ファイルのユーザー・レベル文と再帰的 SQL コールの要約も提供し
ます。
TKPROF の構文
TKPROF は、オペレーティング・システムのプロンプトから実行します。構文は次のとおり
です。
tkprof filename1 filename2 [waits=yes|no] [sort=option] [print=n]
[aggregate=yes|no] [insert=filename3] [sys=yes|no] [table=schema.table]
[explain=user/password] [record=filename4] [width=n]
必要な引数は、入力ファイルと出力ファイルのみです。引数を指定しないで TKPROF を呼び
出すと、オンライン・ヘルプが表示されます。TKPROF を実行するときには表 20-2 の引数を
使用します。
表 20-2 TKPROF 引数
引数
説明
filename1
入力ファイル、つまり SQL トレース機能によって生成された統計を収録しているトレー
ス・ファイルを指定します。このファイルは、単一のセッションに対して生成されたト
レース・ファイル、または複数のセッションの個々のトレース・ファイルを結合して生
成したファイルのどちらでもかまいません。
filename2
TKPROF が、フォーマット済の出力を書き出すファイルを指定します。
WAITS
トレース・ファイル内の待機イベントのサマリーを記録するかどうかを指定します。値
は YES または NO のいずれかです。デフォルトは YES です。
SORTS
トレースした SQL 文のリストを出力ファイルに作成する前に、指定したソート・オプ
ションに基づいて降順にソートします。複数のオプションが指定されている場合、出力
はソート・オプションに指定されている値の合計によって降順にソートされます。この
パラメータを指定しないと、TKPROF はそれぞれの文のリストを使用順に出力ファイル
に作成します。ソート・オプションは次のとおりです。
PRSCNT
解析回数
PRSCPU
解析に費やされた CPU 時間
アプリケーション・トレース・ツールの使用方法
20-17
SQL トレース機能と TKPROF の使用方法
表 20-2 TKPROF 引数（続き）
引数
説明
PRSELA
解析に費やされた経過時間
PRSDSK
解析中のディスクに対する物理読込みの回数
PRSQRY
解析中の一貫モード・ブロック読込みの回数
PRSCU
解析中の現行モード・ブロック読込みの回数
PRSMIS
解析中のライブラリ・キャッシュ・ミスの回数
EXECNT
実行回数
EXECPU
実行に費やされた CPU 時間
EXEELA
実行に費やされた経過時間
EXEDSK
実行中のディスクに対する物理読込みの回数
EXEQRY
実行中の一貫モード・ブロック読込みの回数
EXECU
実行中の現行モード・ブロック読込みの回数
EXEROW
実行中に処理された行数
EXEMIS
実行中のライブラリ・キャッシュ・ミスの回数
FCHCNT
フェッチ回数
FCHCPU
フェッチに費やされた CPU 時間
FCHELA
フェッチに費やされた経過時間
FCHDSK
フェッチ中のディスクに対する物理読込みの回数
FCHQRY
フェッチ中の一貫モード・ブロック読込みの回数
FCHCU
フェッチ中の現行モード・ブロック読込みの回数
FCHROW
フェッチされた行数
USERID
カーソルを解析するユーザーのユーザー ID
PRINT
出力ファイルから最初に整数でソートされた SQL 文のみのリストを作成します。このパ
ラメータを指定しないと、TKPROF はトレースした SQL 文すべてのリストを作成しま
す。このパラメータは、INSERT オプションの SQL スクリプトには影響しません。SQL
スクリプトは、常に、トレースされたすべての SQL 文に対する挿入データを生成しま
す。
AGGREGATE
AGGREGATE = NO を指定すると、TKPROF は同じ SQL テキストに対する複数のユーザー
のデータを集計しません。
20-18　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
表 20-2 TKPROF 引数（続き）
引数
説明
INSERT
トレース・ファイルの統計をデータベースに格納する SQL スクリプトを作成します。
TKPROF は、名前 filename3 を使用してこのスクリプトを作成します。このスクリプ
トは表を作成し、トレースされた各 SQL 文の統計が入っている行をこの表に挿入しま
す。
SYS
ユーザー SYS が発行した SQL 文、つまり再帰的 SQL 文の出力ファイルへのリストを使
用可能または使用禁止にします。デフォルト値は YES で、TKPROF がこれらの SQL 文
のリストを作成します。NO の値が指定されると、TKPROF はこれらの SQL 文のリスト
を作成しません。このパラメータは、INSERT オプションの SQL スクリプトには影響し
ません。SQL スクリプトは、常にトレースされたすべての SQL 文（再帰的 SQL 文を含
む）に関する統計を挿入します。
TABLE
実行計画が出力ファイルに書き込まれる前に、TKPROF が一時的にこれらの実行計画を
格納しておく表のスキーマと名前を指定します。指定された表がすでに存在している場
合、TKPROF はその表の行をすべて削除し、EXPLAIN PLAN 文（より多くの行を表に書
き込む）でその表を使用してからその表の行をすべて削除します。指定した表が存在し
ない場合、TKPROF はこの表を作成して使用し、使用後にこの表を削除します。
指定されたユーザーは、表に対して INSERT、SELECT および DELETE 文を発行できる
必要があります。表がまだ存在しない場合は、この指定のユーザーが前述の文に加えて
CREATE TABLE 文と DROP TABLE 文も発行できる必要があります。これらの文を発行す
るための権限については、
『Oracle Database SQL リファレンス』を参照してください。
このオプションを指定すると、EXPLAIN の値に指定されている同一のユーザーについて
複数のユーザーが同時に TKPROF を実行できます。これらの複数のユーザーが個別に、
TABLE に異なる値を指定しておくことで、一時的な PLAN TABLE の処理時に互いの
データを破壊するような状況が発生することを防ぐことができます。
TABLE パラメータを指定せずに EXPLAIN パラメータを使用すると、TKPROF は
EXPLAIN パラメータで指定されたユーザーのスキーマにある表 PROF$PLAN_TABLE を
使用します。EXPLAIN パラメータを指定せずに TABLE パラメータを使用した場合は、
TKPROF が TABLE パラメータを無視します。
PLAN TABLE が存在しない場合、TKPROF では表 PROF$PLAN_TABLE が作成され、最
後に削除されます。
アプリケーション・トレース・ツールの使用方法
20-19
SQL トレース機能と TKPROF の使用方法
表 20-2 TKPROF 引数（続き）
引数
説明
EXPLAIN
トレース・ファイルの各 SQL 文の実行計画を判断して、これらの実行計画を出力ファイ
ルに書き込みます。TKPROF は、このパラメータに指定されたユーザーとパスワードを
使用して Oracle に接続した後、EXPLAIN PLAN 文を発行して実行計画を判断します。指
定されたユーザーは、CREATE SESSION システム権限を持っている必要があります。
EXPLAIN オプションが使用されている場合は、TKPROF が大きなトレース・ファイルを
処理するのに要する時間が長くなります。
RECORD
トレース・ファイル内の非再帰的 SQL 文をすべて収録した SQL スクリプトを、指定し
た filename4 で作成します。トレース・ファイルのユーザー・イベントを再実行する
場合に、このオプションを指定できます。
WIDTH
EXPLAIN PLAN など、一部の TKPROF 出力の出力行幅を制御する整数です。このパラ
メータは、TKPROF 出力の後処理に役立ちます。
TKPROF 文の例
この項では、TKPROF の 2 つの使用例を簡単に説明します。TKPROF 出力例の詳細は、20-33
ページの「TKPROF の出力例」を参照してください。
TKPROF の例 1 SORT パラメータと PRINT パラメータの組合せを使用して大規模なトレー
ス・ファイルを処理する場合は、リソースを最も多く使用する文のみを含む TKPROF 出力
ファイルを生成できます。たとえば、次の文は、トレース・ファイルに格納されている、ほ
とんどの物理 I/O を生成した 10 個の文を印刷します。
TKPROF ora53269.trc ora53269.prf SORT = (PRSDSK, EXEDSK, FCHDSK) PRINT = 10
TKPROF の例 2 この例では、TKPROF を実行して、dlsun12_jane_fg_sqlplus_007.trc
というトレース・ファイルを取り込み、outputa.prf という名前のフォーマット済の出力
ファイルに書き込みます。
TKPROF dlsun12_jane_fg_sqlplus_007.trc OUTPUTA.PRF
EXPLAIN=scott/tiger TABLE=scott.temp_plan_table_a INSERT=STOREA.SQL SYS=NO
SORT=(EXECPU,FCHCPU)
この例は、スクリーン上で複数行にわたって表示される可能性があるので、使用しているオ
ペレーティング・システムによっては継続文字を使用する必要があります。
この例で使用されている他のパラメータに注意してください。
■
EXPLAIN の値によって、TKPROF がユーザー scott として接続され、トレースされた
各 SQL 文の実行計画を生成するために EXPLAIN PLAN 文が使用されます。これを使用
してアクセス・パスおよび行ソース行数を取得できます。
20-20　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
注意 : SQL 文のカーソルがクローズされていない場合、TKPROF 出力に
は、SQL 文の実際の実行計画は自動的に含められません。この場合は、
TKPROF で EXPLAIN オプションを使用して、実行計画を生成できます。
■
■
■
■
TABLE の値によって、TKPROF がスキーマ scott の表 temp_plan_table_a を一時的
な PLAN TABLE として使用します。
INSERT の値によって、TKPROF がトレースされたすべての SQL 文に関する統計をデー
タベース内に格納する SQL スクリプト、STOREA.SQL を生成します。
SYS パラメータに値 NO が指定されていることにより、TKPROF は出力ファイルに再帰的
SQL 文のリストを作成しません。そのため、一時表操作などの内部 Oracle 文は無視さ
れます。
SORT の値によって、TKPROF は SQL 文を出力ファイルに書き込む前に、SQL 文の実行
にかかった CPU 時間と行のフェッチにかかった CPU 時間の合計値の順に SQL 文を
ソートします。効率を最大にするためには、SORT パラメータを常に使用してください。
手順 4: TKPROF 出力の解釈
この項では、TKPROF 出力を解釈するためのヒントを示します。
■
TKPROF の表形式の統計
■
行ソースの操作
■
待機イベント情報
■
統計の精度の解釈
■
再帰的コールについて
■
TKPROF のライブラリ・キャッシュ・ミス
■
SQL トレースでの文の切捨て
■
TKPROF での SQL 文を発行するユーザーの識別
■
TKPROF の実行計画
■
チューニングする文の決定
TKPROF は非常に有用な分析を提供しますが、効率の最も正確なメジャーは、対象アプリ
ケーションの実際のパフォーマンスです。TKPROF 出力の最後の部分は、トレース実行期間
中にプロセスがデータベース・エンジンで実行した作業のサマリーです。
アプリケーション・トレース・ツールの使用方法
20-21
SQL トレース機能と TKPROF の使用方法
TKPROF の表形式の統計
TKPROF は、SQL トレース機能によって戻される SQL 文の統計のリストを行と列に作成し
ます。各行は、SQL 文を処理する 3 つのステップの 1 つに対応します。統計は、次に示す
CALL 列の値によって識別されます。表 20-3 を参照してください。
表 20-3 CALL 列の値
CALL の値
意味
PARSE
適切なセキュリティ認可のチェック、および表、列、その他の参照オ
ブジェクトの存在のチェックを行って SQL 文を実行計画に変換しま
す。
EXECUTE
Oracle によって行われる実際の文の実行です。INSERT 文、UPDATE
文および DELETE 文では、データの変更が行われます。SELECT 文で
は、選択された行が識別されます。
FETCH
問合せを満たす行を取得します。フェッチは、SELECT 文についての
み実行されます。
SQL トレース機能の出力におけるその他の列は、すべての文の解析、実行、フェッチについ
ての統計です。query と current の合計が、アクセスされたバッファの総数となります。
これは論理 I/O（LIO）とも呼ばれます。表 20-4 を参照してください。
表 20-4 解析、実行およびフェッチの SQL トレース統計
SQL トレース統計
意味
COUNT
文が解析、実行またはフェッチされた回数です。
CPU
文に対するすべての解析コール、実行コールまたはフェッチ・コール
にかかった CPU 時間の合計（単位は秒）です。TIMED_STATISTICS
がオンになっていない場合、この値は 0（ゼロ）になります。
ELAPSED
文に対するすべての解析コール、実行コールまたはフェッチ・コール
にかかった経過時間の合計（単位は秒）です。TIMED_STATISTICS
がオンになっていない場合、この値は 0（ゼロ）になります。
DISK
すべての解析コール、実行コールまたはフェッチ・コールに対して、
ディスク上のデータファイルから物理的に読み込んだデータ・ブロッ
クの総数です。
QUERY
すべての解析コール、実行コールまたはフェッチ・コールに対して、
一貫モードで取り出されたバッファの総数です。通常バッファは問合
せに対して一貫モードで取り出されます。
CURRENT
現行モードで取り出されたバッファの総数です。INSERT、UPDATE、
DELETE などの文では、バッファは現行モードで取り出されます。
20-22　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
処理された行に関する統計は、ROWS 列に表示されます。表 20-5 を参照してください。
表 20-5 ROWS 列の SQL トレース統計
SQL トレース統計
意味
ROWS
SQL 文によって処理された行の総数です。この値には、SQL 文の副問
合せによって処理された行は含まれません。
SELECT 文の場合、戻された行数はフェッチ・ステップに表示されます。UPDATE 文、
DELETE 文および INSERT 文の場合、処理された行数は実行ステップに表示されます。
注意 : 行ソースの件数は、カーソルがクローズされたときに表示されま
す。SQL*Plus では、ユーザー・カーソルは 1 つしかないため、文が実行
されるたびに直前のカーソルがクローズされます。これにより、行ソース
の件数が表示されます。PL/SQL には、独自のカーソル処理方法があり、
親カーソルがクローズされても子カーソルはクローズされません。終了
（または再接続）によって、件数が表示されます。
行ソースの操作
行ソースの操作では、行に対して実行される各操作で処理される行数と、物理読込みおよび
書込みなど、行ソースの追加情報が提供されます。出力例は次のようになります。
Rows
------0
28144
51427
647529
Row Source Operation
--------------------------------------------------DELETE (cr=43141 r=266947 w=25854 time=60235565 us)
HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us)
TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us)
INDEX FAST FULL SCAN STATS$SQL_SUMMARY_PK
(cr=39592 r=39325 w=0 time=10522877 us) (object id 7409)
この例の TKPROF 出力では、行ソースの操作の列で次の点に注意してください。
■
cr は、行ソースにより実行される読取り一貫性を指定します。
■
r は、行ソースにより実行される物理読込みを指定します。
■
w は、行ソースにより実行される物理書込みを指定します。
■
time は、時間をマイクロ秒単位で指定します。
アプリケーション・トレース・ツールの使用方法
20-23
SQL トレース機能と TKPROF の使用方法
待機イベント情報
待機イベント情報が存在する場合、TKPROF 出力には次のような項が含まれます。
Elapsed times include waiting on following events:
Event waited on
Times
---------------------------------------Waited
db file sequential read
8084
direct path write
834
direct path write temp
834
db file parallel read
8
db file scattered read
4180
direct path read
7082
direct path read temp
7082
rdbms ipc reply
20
SQL*Net message to client
1
SQL*Net message from client
1
Max. Wait
---------0.12
0.00
0.00
1.53
0.07
0.00
0.00
0.00
0.00
0.00
Total Waited
-----------5.34
0.00
0.05
5.51
1.45
0.05
0.44
0.01
0.00
0.00
さらに、ファイルの最後でトレース・ファイル全体について待機イベントが要約されます。
待機イベント情報がそのセッションのトレース・ファイルに確実に書き込まれるようにする
には、次の SQL 文を実行します。
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';
統計の精度の解釈
タイミング統計の分解能は 100 分の 1 秒なので、100 分の 1 秒以下のカーソル操作は正確に
計測できません。統計を解読するときには、このことを覚えておいてください。非常に高速
に実行する単純な問合せの結果を解読するときには特に注意してください。
再帰的コールについて
ユーザーが発行した SQL 文を実行するために、Oracle は内部的に追加の文を実行する必要
があります。このような文を再帰的コールまたは再帰的 SQL 文と呼びます。たとえば、十
分な領域のない表に行を挿入しようとすると、Oracle は再帰的コールを実行して動的に領域
を割り当てます。データ・ディクショナリの情報がデータ・ディクショナリ・キャッシュに
ないため、ディスクから取り出す必要がある場合にも、再帰的コールが生成されます。
SQL トレース機能が使用可能になっているときに、再帰的コールが発生すると、TKPROF は
再帰的コールの原因となった文に加えて再帰的 SQL 文の統計を表示します。SYS コマンド
ライン・パラメータを NO に設定して、出力ファイルへの Oracle 内部再帰的コール（たとえ
ば、領域管理）のリスト表示を抑止できます。再帰的 SQL 文の統計は、再帰的コールを発
生させた SQL 文のリストでなく、再帰的 SQL 文のリストに表示されます。したがって、
SQL 文の処理に必要なリソースの合計を計算するときは、その文自体の統計に加えて、その
文を原因とする再帰的コールの統計も合わせて考慮する必要があります。
20-24　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
注意 : 再帰的 SQL 統計は、SQL レベルの操作には組み込まれません。た
だし、再帰的 SQL 統計は、トリガーなど SQL レベルより下の操作には組
み込まれます。詳細は、20-33 ページの「トリガー・トラップの回避」を
参照してください。
TKPROF のライブラリ・キャッシュ・ミス
TKPROF は、各 SQL 文の解析ステップと実行ステップの結果として生じるライブラリ・
キャッシュ・ミス回数のリストも作成します。これらの統計は、表形式の統計に続く別の行
に表示されます。文でライブラリ・キャッシュ・ミスが発生しなかった場合、TKPROF はそ
の統計のリストを作成しません。20-16 ページの「TKPROF の出力例」における解析ステッ
プでは、ライブラリ・キャッシュ・ミスが 1 回発生し、実行ステップではライブラリ・
キャッシュ・ミスは発生しませんでした。
SQL トレースでの文の切捨て
次の SQL 文は、SQL トレース・ファイルでは 25 文字に切り捨てられます。
SET ROLE
GRANT
ALTER USER
ALTER ROLE
CREATE USER
CREATE ROLE
TKPROF での SQL 文を発行するユーザーの識別
TKPROF は、各 SQL 文を発行したユーザーのユーザー ID を出力します。SQL トレース入力
ファイルが複数のユーザーからの統計を収録し、文が複数のユーザーによって発行された場
合、TKPROF は文を解析した最後のユーザーの ID を出力します。すべてのデータベース・
ユーザーのユーザー ID は、列 ALL_USERS.USER_ID のデータ・ディクショナリに表示され
ます。
TKPROF の実行計画
TKPROF のコマンドラインに EXPLAIN パラメータを指定すると、TKPROF は EXPLAIN
PLAN 文を使用して、トレースされた SQL 文ごとに実行計画を生成します。TKPROF は実行
計画の各ステップによって処理された行数も表示します。
アプリケーション・トレース・ツールの使用方法
20-25
SQL トレース機能と TKPROF の使用方法
注意 : インスタンスの始動直後に生成されたトレース・ファイルは、ス
タートアップ・プロセスのアクティビティを反映するデータを含みます。
特に、これらは、システム・グローバル領域（SGA）のキャッシュがいっ
ぱいになったときの不均衡な量の I/O アクティビティを反映します。
チューニングを行うときには、このようなトレース・ファイルは無視して
ください。
関連項目 : 実行計画の解釈に関する詳細は、第 19 章「EXPLAIN PLAN
の使用方法」を参照してください。
チューニングする文の決定
CPU リソースまたはディスク・リソースを最も消費する SQL 文を検出する必要があります。
TIMED_STATISTICS パラメータがオンになっている場合は、CPU の高いアクティビティを
CPU 列で見つけられます。TIMED_STATISTICS がオンになっていない場合は、QUERY 列と
CURRENT 列をチェックします。
関連項目 : リソースを消費する文の検索例は、20-20 ページの「TKPROF
文の例」を参照してください。
ロックの問題と効率の悪い PL/SQL ループを除いて、問題の文を発見するためには CPU 時
間と経過時間のどちらも必要ありません。重要なのは、問合せモード（すなわち、読取り一
貫性の対象）と現行モード（読取り一貫性の非対象）の両方でアクセスするブロックの数で
す。セグメント・ヘッダーと更新されるブロックは現行モードで獲得されますが、すべての
問合せ処理と副問合せ処理は問合せモードでデータを要求します。これらのメジャーは、イ
ンスタンス統計 CONSISTENT GETS および DB BLOCK GETS とまったく同じです。高ディス
ク・アクティビティはディスク列で見つけられます。
次のリストには、ある SQL 文の TKPROF 出力が出力ファイルに表示されるときと同じ状態
で示されています。
SELECT *
FROM emp, dept
WHERE emp.deptno = dept.deptno;
call
count
cpu
elapsed
disk
query current
rows
---- ------- ------- --------- -------- -------- ------- -----Parse
11
0.08
0.18
0
0
0
0
Execute
11
0.23
0.66
0
3
6
0
Fetch
35
6.70
6.83
100
12326
2
824
-----------------------------------------------------------------total
57
7.01
7.67
100
12329
8
826
Misses in library cache during parse: 0
20-26　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
7.01 CPU 秒で、824 行を取り出せる場合は、これ以上このトレース出力を検索する必要はあ
りません。事実上、チューニング作業での TKPROF レポートの主な用途は、詳細なチューニ
ング段階のプロセスを排除することです。
1 つの文に対して 11 の解析コールが存在していたため、10 の不要な解析コールが作成され、
その配列フェッチ操作が実行されたことも確認できます。これは、フェッチで取り出された
行よりも多くの行がフェッチされていることからわかります。CPU 時間と経過時間の大きな
ギャップは、物理 I/O（PIO）の存在を示します。
手順 5: SQL トレース機能統計の格納
SQL トレース機能によって生成されたアプリケーションに関する統計の履歴を保持し、別の
時点でこれらの統計を比較することがあります。TKPROF は、表を作成して、統計の行をそ
の表に挿入する SQL スクリプトを生成します。このスクリプトには、次の内容が記述され
ています。
■
TKPROF_TABLE という出力表を作成する CREATE TABLE 文
■
トレースした各 SQL 文ごとに統計行を 1 行ずつ TKPROF_TABLE に追加する INSERT 文
TKPROF の実行後にこのスクリプトを実行すると、統計をデータベースに格納できます。
TKPROF による出力 SQL スクリプトの生成
TKPROF を実行する場合は、INSERT パラメータを使用して、生成される SQL スクリプトの
名前を指定します。このパラメータを指定しないと、TKPROF はスクリプトを生成しませ
ん。
TKPROF による出力 SQL スクリプトの編集
TKPROF によって SQL スクリプトが作成された後、SQL スクリプトを実行する前にスクリ
プトを編集できます。以前収集した統計の出力表をすでに作成しており、新しい統計をこの
表に追加する場合は、スクリプトから CREATE TABLE 文を削除します。これにより、スク
リプトが新しい行を既存の表に挿入します。
異なるデータベースの統計を別々の表に格納するために複数の出力表を作成している場合
は、CREATE TABLE 文と INSERT 文を編集して、出力表の名前を変更してください。
出力表の問合せ
次の CREATE TABLE 文は TKPROF_TABLE を作成します。
CREATE TABLE TKPROF_TABLE (
DATE_OF_INSERT
DATE,
CURSOR_NUM
NUMBER,
DEPTH
NUMBER,
USER_ID
NUMBER,
PARSE_CNT
NUMBER,
アプリケーション・トレース・ツールの使用方法
20-27
SQL トレース機能と TKPROF の使用方法
PARSE_CPU
PARSE_ELAP
PARSE_DISK
PARSE_QUERY
PARSE_CURRENT
PARSE_MISS
EXE_COUNT
EXE_CPU
EXE_ELAP
EXE_DISK
EXE_QUERY
EXE_CURRENT
EXE_MISS
EXE_ROWS
FETCH_COUNT
FETCH_CPU
FETCH_ELAP
FETCH_DISK
FETCH_QUERY
FETCH_CURRENT
FETCH_ROWS
CLOCK_TICKS
SQL_STATEMENT
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
NUMBER,
LONG);
出力表のほとんどの列は、フォーマットされた出力ファイルに記録されている統計と直接対
応しています。たとえば、PARSE_CNT 列の値は出力ファイルの解析ステップに関するカウ
ント統計に対応しています。
表 20-6 の列は、統計が入っている行を識別する際に役立ちます。
表 20-6 統計の行を識別する TKPROF_TABLE 列
列
説明
SQL_STATEMENT
SQL トレース機能が収集した統計行の対象となる SQL 文です。この列
のデータ型は LONG なので式または WHERE 句条件ではこの列を使用で
きません。
DATE_OF_INSERT
行が表に挿入された日時です。この値は、SQL トレース機能によって統
計が収集された時刻と完全には一致しません。
DEPTH
SQL 文が発行された再帰レベルを示します。たとえば、値 0 はユー
ザーがその文を発行したことを示します。値 1 は、Oracle が値 0 の文
（ユーザー発行の文）を処理するための再帰的コールとして、その文を
生成したことを示します。値 n は、Oracle がその文を値 n-1 の文を処理
する再帰的コールとして生成したことを示します。
20-28　Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
表 20-6 統計の行を識別する TKPROF_TABLE 列（続き）
列
説明
USER_ID
この文を発行するユーザーを識別します。この値はフォーマットした
出力ファイルにも出力されます。
CURSOR_NUM
この列の値は、各 SQL 文が割り当てられているカーソルを追跡して記
録するために Oracle が使用します。
文の実行計画は出力表に格納されません。次の問合せは、出力表からの統計を返します。こ
れらの統計は、20-16 ページの「TKPROF の出力例」で示したフォーマットされた出力に対
応します。
SELECT * FROM TKPROF_TABLE;
Oracle によって次のような結果が返されます。
DATE_OF_INSERT CURSOR_NUM DEPTH USER_ID PARSE_CNT PARSE_CPU PARSE_ELAP
-------------- ---------- ----- ------- --------- --------- ---------21-DEC-1998
1
0
8
1
16
22
PARSE_DISK PARSE_QUERY PARSE_CURRENT PARSE_MISS EXE_COUNT EXE_CPU
---------- ----------- ------------- ---------- --------- ------3
11
0
1
1
0
EXE_ELAP EXE_DISK EXE_QUERY EXE_CURRENT EXE_MISS EXE_ROWS FETCH_COUNT
-------- -------- --------- ----------- -------- -------- ----------0
0
0
0
0
0
1
FETCH_CPU FETCH_ELAP FETCH_DISK FETCH_QUERY FETCH_CURRENT FETCH_ROWS
--------- ---------- ---------- ----------- ------------- ---------2
20
2
2
4
10
SQL_STATEMENT
--------------------------------------------------------------------SELECT * FROM EMP, DEPT WHERE EMP.DEPTNO = DEPT.DEPTNO
アプリケーション・トレース・ツールの使用方法
20-29
TKPROF の解釈における誤りの回避
TKPROF の解釈における誤りの回避
この項では、TKPROF の解釈における細かなポイントをいくつか説明します。
■
引数トラップの回避
■
読取り一貫性トラップの回避
■
スキーマ・トラップの回避
■
タイム・トラップの回避
■
トリガー・トラップの回避
引数トラップの回避
実行時にバインドされる値を認識していない場合は、引数トラップに陥る可能性がありま
す。EXPLAIN PLAN は、SQL 文からバインド変数の型を判別できないので、型は常に
varchar であると想定されます。バインド変数が実際には番号または日付である場合、
TKPROF が暗黙的データ変換を行い、その結果、効率の悪い計画が実行される可能性があり
ます。これを回避するには、異なるデータ型を使用して問合せを試みます。
この問題を回避するには、各自で変換を行ってください。
関連項目 : TKPROF およびバインド変数の詳細は、19-5 ページの
「EXPLAIN PLAN の制限事項」を参照してください。
読取り一貫性トラップの回避
次の例は、読取り一貫性トラップを示しています。コミットされていないトランザクション
が NAME 列に一連の更新を行ったことを知らないと、多くのブロックがアクセスされる理由
を判断することは非常に困難です。
通常、このようなケースは再現可能ではありません。そのプロセスが再度実行された場合
に、別のトランザクションが同じようにそのプロセスに影響を及ぼすことはあまりありませ
ん。
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call
---Parse
Execute
Fetch
count
----1
1
1
cpu
--0.10
0.00
0.11
elapsed
------0.18
0.00
0.21
disk
---0
0
2
Misses in library cache during parse: 1
Parsing user id: 01 (USER1)
20-30　Oracle Database パフォーマンス・チューニング・ガイド
query current
----- ------0
0
0
0
101
0
rows
---0
0
1
TKPROF の解釈における誤りの回避
Rows
---0
1
2
Execution Plan
--------- ---SELECT STATEMENT
TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON_UNIQUE)
スキーマ・トラップの回避
この例は極端な場合を示しているので、スキーマ・トラップは容易に検出できます。最初
は、明らかに単純に索引付けされた問合せが多くのデータベース・ブロックを検索する必要
がある理由、または現行モードでブロックにアクセスすることが必要な理由を理解すること
は困難です。
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call
-------Parse
Execute
Fetch
count
------1
1
1
cpu
-------0.06
0.02
0.23
elapsed
--------0.10
0.02
0.30
disk query current rows
------- ------ ------- ---0
0
0
0
0
0
0
0
31
31
3
1
Misses in library cache during parse: 0
Parsing user id: 02 (USER2)
Rows
------0
2340
0
Execution Plan
--------------------------------------------------SELECT STATEMENT
TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)
2 つの統計は、問合せが全表スキャンを使用して実行された可能性があることを示していま
す。これらの統計は、現行モードでのブロック・アクセスと、実行計画の Table Access 行
ソースに由来する行数です。これは、トレース・ファイルが生成された後、TKPROF が実行
される前に、必要な索引が構築されたことを示しています。
新規トレース・ファイルを生成すると次のデータが与えられます。
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call
count
cpu
----- ------ -----Parse
1
0.01
Execute
1
0.00
Fetch
1
0.00
elapsed disk query current
-------- ----- ------ ------0.02
0
0
0
0.00
0
0
0
0.00
0
2
0
rows
----0
0
1
アプリケーション・トレース・ツールの使用方法
20-31
TKPROF の解釈における誤りの回避
Misses in library cache during parse: 0
Parsing user id: 02 (USER2)
Rows
------0
1
2
Execution Plan
--------------------------------------------------SELECT STATEMENT
TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)
この正しいバージョンで注目する機能の 1 つは、解析コールには 10 ミリ秒の CPU 時間と
20 ミリ秒の経過時間を要する一方で、問合せとフェッチの実行にはまったく時間がかかって
いないことです。これらの例外的事態が発生するのは、10 ミリ秒というクロック刻みがデー
タの実行およびフェッチに要する時間と比べて非常に長いためです。このような場合、文を
多く実行して統計的に有効な数値を得ることが重要になります。
タイム・トラップの回避
次の例で示すように、特定の問合せに長時間かかる理由がわからないことがあります。
UPDATE cq_names SET ATTRIBUTES = lower(ATTRIBUTES)
WHERE ATTRIBUTES = :att
call
count
-------- ------Parse
1
Execute
1
Fetch
0
cpu
-------0.06
0.62
0.00
elapsed
disk
query current
--------- -------- -------- ------0.24
0
0
0
19.62
22
526
12
0.00
0
0
0
rows
---------0
7
0
Misses in library cache during parse: 1
Parsing user id: 02 (USER2)
Rows
Execution Plan
------- --------------------------------------------------0 UPDATE STATEMENT
2519 TABLE ACCESS (FULL) OF 'CQ_NAMES'
ここでも、別のトランザクションによる妨害というのが答えです。この場合は、別のトラン
ザクションが更新を発行する前後の数秒間、表 cq_names で共有ロックが保持されていま
す。妨害の影響が発生していることを診断できるようになるにはかなりの経験が必要です。
妨害によって発生する遅延が短時間である（または前の例のようにブロック・アクセスにお
ける増加がわずかである）場合は、比較用のデータが必要です。一方、妨害がわずかなオー
バーヘッドの原因にしかならず、本質的に文の効率がよい場合は、統計を分析の対象にする
必要はありません。
20-32　Oracle Database パフォーマンス・チューニング・ガイド
TKPROF の出力例
トリガー・トラップの回避
ある文についてレポートされたリソースには、文が処理されていた間に発行されたすべての
SQL 用のリソースが含まれます。したがって、これらには、トリガーで使用されるリソース
と、領域割当てで使用されるリソースなど他の再帰的 SQL で使用されるリソースが含まれ
ます。リソースが実際に低い再帰レベルで使用されている場合は、DML 文をチューニング
することは避けてください。
DML 文が予想よりはるかに多くのリソースを消費していると思われる場合は、トリガーと
制約についての SQL 文に関連する表をチェックして、トリガーと制約がリソースの使用量
を大幅に増やしていないか、調べてください。
TKPROF の出力例
この項では、TKPROF 出力の例を示します。簡潔化のために各部分を編集してあります。
TKPROF ヘッダーのサンプル
TKPROF: Release 10.1.0.0.0 - Beta on Mon Feb 10 14:43:00 2003
(c) Copyright 2001 Oracle Corporation.
All rights reserved.
Trace file: main_ora_27621.trc
Sort options: default
********************************************************************************
count
= number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk
= number of physical reads of buffers from disk
query
= number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows
= number of rows processed by the fetch or execute call
********************************************************************************
TKPROF 本体のサンプル
call
count
------- -----Parse
1
Execute
1
Fetch
0
------- -----total
2
cpu
elapsed
disk
query
current
-------- ---------- ---------- ---------- ---------0.01
0.00
0
0
0
0.00
0.00
0
0
0
0.00
0.00
0
0
0
-------- ---------- ---------- ---------- ---------0.01
0.00
0
0
0
rows
---------0
0
0
---------0
Misses in library cache during parse: 1
アプリケーション・トレース・ツールの使用方法
20-33
TKPROF の出力例
Optimizer mode: FIRST_ROWS
Parsing user id: 44
Elapsed times include waiting on following events:
Event waited on
Times
Max. Wait Total Waited
---------------------------------------Waited ---------- -----------SQL*Net message to client
1
0.00
0.00
SQL*Net message from client
1
28.59
28.59
********************************************************************************
select condition
from
cdef$ where rowid=:1
call
count
------- -----Parse
1
Execute
1
Fetch
1
------- -----total
3
cpu
elapsed
disk
query
current
-------- ---------- ---------- ---------- ---------0.00
0.00
0
0
0
0.00
0.00
0
0
0
0.00
0.00
0
2
0
-------- ---------- ---------- ---------- ---------0.00
0.00
0
2
0
rows
---------0
0
1
---------1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS
(recursive depth: 1)
Rows
------1
Row Source Operation
--------------------------------------------------TABLE ACCESS BY USER ROWID OBJ#(31) (cr=1 r=0 w=0 time=151 us)
********************************************************************************
SELECT last_name, job_id, salary
FROM employees
WHERE salary =
(SELECT max(salary) FROM employees)
call
count
------- -----Parse
1
Execute
1
Fetch
2
------- -----total
4
cpu
elapsed
disk
query
current
-------- ---------- ---------- ---------- ---------0.02
0.01
0
0
0
0.00
0.00
0
0
0
0.00
0.00
0
15
0
-------- ---------- ---------- ---------- ---------0.02
0.01
0
15
0
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
20-34　Oracle Database パフォーマンス・チューニング・ガイド
rows
---------0
0
1
---------1
TKPROF の出力例
Parsing user id: 44
Rows
------1
1
107
Row Source Operation
--------------------------------------------------TABLE ACCESS FULL EMPLOYEES (cr=15 r=0 w=0 time=1743 us)
SORT AGGREGATE (cr=7 r=0 w=0 time=777 us)
TABLE ACCESS FULL EMPLOYEES (cr=7 r=0 w=0 time=655 us)
Elapsed times include waiting on following events:
Event waited on
Times
Max. Wait Total Waited
---------------------------------------Waited ---------- -----------SQL*Net message to client
2
0.00
0.00
SQL*Net message from client
2
9.62
9.62
********************************************************************************
********************************************************************************
delete
from stats$sqltext st
where (hash_value, text_subset) not in
(select --+ hash_aj
hash_value, text_subset
from stats$sql_summary ss
where (
(
snap_id
< :lo_snap
or snap_id
> :hi_snap
)
and dbid
= :dbid
and instance_number = :inst_num
)
or (
dbid
!= :dbid
or instance_number != :inst_num)
)
call
count
------- -----Parse
1
Execute
1
Fetch
0
------- -----total
2
cpu
elapsed
disk
query
current rows
-------- ---------- ---------- ---------- ---------- ---------0.00
0.00
0
0
0
0
29.60
60.68
266984
43776
131172
28144
0.00
0.00
0
0
0
0
-------- ---------- ---------- ---------- ---------- ---------29.60
60.68
266984
43776
131172
28144
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 22
アプリケーション・トレース・ツールの使用方法
20-35
TKPROF の出力例
Rows
------0
28144
51427
647529
Row Source Operation
--------------------------------------------------DELETE (cr=43141 r=266947 w=25854 time=60235565 us)
HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us)
TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us)
INDEX FAST FULL SCAN STATS$SQL_SUMMARY_PK
(cr=39592 r=39325 w=0 time=10522877 us) (object id 7409)
Elapsed times include waiting on following events:
Event waited on
Times
Max. Wait Total Waited
---------------------------------------Waited ---------- -----------db file sequential read
8084
0.12
5.34
direct path write
834
0.00
0.00
direct path write temp
834
0.00
0.05
db file parallel read
8
1.53
5.51
db file scattered read
4180
0.07
1.45
direct path read
7082
0.00
0.05
direct path read temp
7082
0.00
0.44
rdbms ipc reply
20
0.00
0.01
SQL*Net message to client
1
0.00
0.00
SQL*Net message from client
1
0.00
0.00
********************************************************************************
TKPROF サマリーのサンプル
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call
count
------- -----Parse
4
Execute
5
Fetch
2
------- -----total
11
cpu
elapsed
disk
query
current
-------- ---------- ---------- ---------- ---------0.04
0.01
0
0
0
0.00
0.04
0
0
0
0.00
0.00
0
15
0
-------- ---------- ---------- ---------- ---------0.04
0.06
0
15
0
Misses in library cache during parse: 4
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on
Times
---------------------------------------Waited
SQL*Net message to client
6
SQL*Net message from client
5
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
20-36　Oracle Database パフォーマンス・チューニング・ガイド
Max. Wait
---------0.00
77.77
rows
---------0
0
1
---------1
Total Waited
-----------0.00
128.88
TKPROF の出力例
call
count
------- -----Parse
1
Execute
1
Fetch
1
------- -----total
3
cpu
elapsed
disk
query
current
-------- ---------- ---------- ---------- ---------0.00
0.00
0
0
0
0.00
0.00
0
0
0
0.00
0.00
0
2
0
-------- ---------- ---------- ---------- ---------0.00
0.00
0
2
0
rows
---------0
0
1
---------1
Misses in library cache during parse: 1
5 user SQL statements in session.
1 internal SQL statements in session.
6 SQL statements in session.
********************************************************************************
Trace file: main_ora_27621.trc
Trace file compatibility: 9.00.01
Sort options: default
1 session in tracefile.
5 user SQL statements in trace file.
1 internal SQL statements in trace file.
6 SQL statements in trace file.
6 unique SQL statements in trace file.
76 lines in trace file.
128 elapsed seconds in trace file.
アプリケーション・トレース・ツールの使用方法
20-37
TKPROF の出力例
20-38　Oracle Database パフォーマンス・チューニング・ガイド
用語集
EXPLAIN PLAN
DML 文に対してオプティマイザが選択した実行計画を検証できる SQL 文。EXPLAIN PLAN
を実行すると、オプティマイザは実行計画を選択し、計画を説明するデータをデータベース
表に格納します。
LIO
論理 I/O（Logical I/O）
。バッファ・キャッシュから読むことができる場合とできない場合
のあるブロック読込み。
MTBF
平均障害間隔時間（Mean Time Between Failures）
。一般的なデータベース統計で、I/O の
チューニングに重要です。
PGA
プログラム・グローバル領域（Program Global Area）
。サーバー・プロセスのデータと制御
情報が含まれる非共有のメモリー領域。サーバー・プロセスの開始時に作成されます。
PIO
物理 I/O（Physical I/O）
。ブロックがバッファ・キャッシュに存在しなかったか、I/O が
バッファ・キャッシュをバイパスする直接 I/O であるため、バッファ・キャッシュから読む
ことのできなかったブロック読取り。
RAID
Redundant Arrays of Inexpensive Disks。RAID 構成では、ストライプ化（手動によるデー
タの分散化）とともに、高いデータの信頼性を実現します。パフォーマンスとコストに基づ
いて様々な RAID 構成（レベル）が選択され、その I/O 特性に応じて、適応がふさわしいア
プリケーションは異なります。
用語集 -1
RBO
ルールベース・オプティマイザ（Rule-based optimizer）
。使用可能なアクセス・パスとその
アクセス・パスのランクに基づいて、SQL 文の実行計画を選択します。複数の方法がある場
合は、RBO ではランクの低い操作が使用されます。
注意 :
この機能はサポートされなくなりました。
SGA
システム・グローバル領域（System Global Area）
。高速なアクセスのためにデータを格納す
るメイン・メモリー内のメモリー領域。Oracle では、共有 SQL および PL/SQL プロシー
ジャ用の SGA メモリーの割当てに共有プールが使用されます。
SQL Tuning Set（
（STS）
）
1 つ以上の SQL 文、実行統計および実行コンテキストを含むデータベース・オブジェクト。
SQL*Loader
入力ファイルを読み込み、解析します。大量のデータをロードする最も効率的な方法です。
SQL コンパイラ（SQL
Compiler）
）
コンパイラ（
SQL 文を共有カーソルにコンパイルします。SQL コンパイラは、パーサー、オプティマイ
ザおよび行ソース・ジェネレータで構成されます。
SQL トレース（SQL
Trace）
）
トレース（
基本的なパフォーマンス診断ツール。Oracle サーバーで実行されるアプリケーションのモニ
ターとチューニングに役立ちます。SQL トレースを使用すると、アプリケーションで実行さ
れる SQL 文の効率性を評価し、各文の統計を生成できます。このツールで生成されるト
レース・ファイルは、TKPROF の入力として使用されます。
SQL プロファイル（SQL
Profile）
）
プロファイル（
問合せオプティマイザが SQL 文に対して最適の実行計画を作成できるようにする情報の収
集。
SQL 文（同一）
（SQL
statements （identical）
）
）
（
テキストが同じ SQL 文は、すべての点で同一です。
SQL 文（類似）
（SQL
statements（
（similar）
）
）
（
類似する SQL 文は、リテラル値を変更するという点のみ異なります。リテラル値がバイン
ド変数に置換された場合、SQL 文はテキストの点で同一になります。
用語集 -2
Statspack
パフォーマンス・データの収集、自動化、格納および表示ができる SQL、PL/SQL および
SQL*Plus スクリプトのセット。この機能は自動ワークロード・リポジトリ（Automatic
Workload Repository）に置き換えられました。
TKPROF
診断ツール。Oracle サーバーで実行されるアプリケーションのモニターとチューニングに役
立ちます。TKPROF は主に、SQL トレースの出力ファイルを処理して読取り可能な出力ファ
イルに変換し、トレース・ファイルに関してユーザー・レベルの文と再帰的 SQL コールの
サマリーを提供します。また、SQL 文の効率性の評価、実行計画の生成、データベースに統
計を格納する SQL スクリプトの作成が実行できます。
UGA
ユーザー・グローバル領域（User Global Area）。ユーザー・セッションに使用されるラー
ジ・プール内のメモリー領域。
インスタンス・リカバリ（instance
recovery）
）
インスタンス・リカバリ（
クラッシュまたはシステム障害後に、コミットされていない Oracle データ・ブロックに
REDO ログ・レコードを自動的に適用すること。
エスティメータ（estimator）
）
エスティメータ（
統計を使用して、選択性、カーディナリティおよび実行計画のコストを評価します。エス
ティメータの主な目標は、実行計画のコスト全体を算出することです。
エンキュー（enqueue）
）
エンキュー（
これはロックの別の用語です。
オプティマイザ（optimizer）
）
オプティマイザ（
SQL 文の式を評価し、より処理速度の速い等価の式に変換することによって、SQL 文を最
も効率的に実行する方法を判断します。オプティマイザは実行計画セットを示し、SQL 文に
対して最適な計画を選択します。問合せオプティマイザ（Query Optimizer）を参照してく
ださい。
解析（parse）
）
解析（
ハード解析は、SQL 文が実行され、かつ SQL 文が共有プール内にないか、共有プール内に
あっても共有できないときに行われます。SQL 文は、2 つの SQL 文のメタデータが異なる
場合に共有されません。これは、ある SQL 文が既存の SQL 文とテキストでは同一ですが、
2 つの文で参照される表が物理的に異なる表に変換される場合、またはオプティマイザ環境
が異なる場合に発生する可能性があります。
ソフト解析は、セッションが SQL 文を実行しようとし、かつ文がすでに共有プール内にあ
り、かつ文を使用できる（すなわち、共有できる）ときに行われます。共有される文の場
用語集 -3
合、既存の SQL 文に関連するすべてのデータ（オプティマイザ実行計画などのメタデータ
も含む）が発行対象の現行の文に同じように適用できる必要があります。
解析コール（parse
call）
）
解析コール（
SQL 文実行の準備のために Oracle に行われるコール。このコールには、SQL 文の構文
チェック、SQL 文の最適化、SQL 文の実行可能形式の作成（または指定）が含まれていま
す。
外部結合（outer
join）
）
外部結合（
結合する表のどれか 1 つの 1 つ以上の列で外部結合演算子（+）を使用する結合条件。
Oracle は、この結合条件に一致する行をすべて戻します。また、外部結合演算子がついてお
らず外部結合演算子を持つ表に対応する行が存在しない表からは、すべての行を戻します。
キャッシュ（cache）
）
キャッシュ（
バッファ・キャッシュとも呼ばれています。すべてのバッファおよびバッファ・プール。
キャッシュ・リカバリ（cache
recovery）
）
キャッシュ・リカバリ（
REDO ログ・ファイルのすべてのコミット済およびコミットされていない変更内容を、対象
のデータ・ブロックに適用するインスタンス・リカバリの部分。インスタンス・リカバリの
ロールフォワード・フェーズとも呼ばれています。
競合（contention）
）
競合（
あるプロセスが別のプロセスで使用されているリソースを待機する必要のある場合。
行ソース・ジェネレータ（row
source generator）
）
行ソース・ジェネレータ（
オプティマイザから最適な計画を受け取り、SQL 文の実行計画を出力します。行ソースは、
1 組の行を反復方式で処理し、行セットを生成する反復制御構造です。
結合（join）
）
結合（
複数の表からデータを選択する問合せ。結合の特徴は、FROM 句内に複数の表が並んでいる
点です。Oracle は、WHERE 句に指定された条件を使用して、それぞれの表の行を比較し、
その結果作成された行を戻します。この条件は結合条件と呼ばれます。通常、結合されたす
べての表の列はこの条件によって比較されます。
作業領域（work
area）
）
作業領域（
メモリーのプライベート割当てであり、ソート、ハッシュ結合およびオンメモリー中心のそ
の他の操作に使用されます。ソート演算子は、作業領域（ソート領域）を使用して一連の行
のメモリー内ソートを実行します。同様に、ハッシュ結合演算子は作業領域（ハッシュ領
域）を使用して、ハッシュ表を左側から入力して作成します。
自動トレース（Autotrace）
）
自動トレース（
SQL オプティマイザが使用した実行パス、および文の実行統計に関するレポートを生成しま
す。レポートは、DML 文のパフォーマンスの監視およびチューニングに役立ちます。
用語集 -4
自動ワークロード・リポジトリ（Automatic
Workload Repository）
）
自動ワークロード・リポジトリ（
問題の検出および自己チューニングを目的として、パフォーマンス統計を収集、処理および
保守します。
述語（predicate）
）
述語（
SQL 内の WHERE 条件。
ストライプ化（striping）
）
ストライプ化（
ディスク間でのデータのブロックの並列処理化。適切なストライプ化は I/O を減らし、パ
フォーマンスを向上します。
■
■
ストライプ深度は、ストライプのサイズで、ストライプ単位とも呼ばれます。
ストライプ幅は、ストライプ深度とストライプ・セットを構成するドライブ数の積で
す。
セグメント（segment）
）
セグメント（
セグメントは、表、索引、クラスタなど、特定の種類のデータベース・オブジェクトのため
に割り当てられているエクステントの集合です。
待機イベント（wait
events）
）
待機イベント（
処理を継続する際にあるイベントが完了するまで待機する必要があったことを示すために、
サーバー・プロセス / スレッドによって増やされる統計。待機イベントは、事後パフォーマ
ンス・チューニングの実行時に最初に検証する事項の 1 つです。
待機イベント（アイドル）
（wait
events（
（idle）
（
））
これらのイベントは、作業がないためにサーバー・プロセスが待機していることを示しま
す。アイドル・イベントをチューニングのときに無視することが必要なのは、アイドル・イ
ベントがパフォーマンスのボトルネックの性質を示さないからです。
単純な問合せ（simple
query）
）
単純な問合せ（
1 つの表のみを参照し、GROUP BY 関数の参照は行わない SELECT 文。
単純な文（simple
statement）
）
単純な文（
単一表のみに関連する INSERT 文、UPDATE 文、DELETE 文または SELECT 文。
直接 I/O（
（direct I/O）
）
バッファ・キャッシュをバイパスする I/O。用語集 -1 ページの「PIO」を参照してくださ
い。
用語集 -5
ディクショナリ・キャッシュ（dictionary
cache）
）
ディクショナリ・キャッシュ（
データベース、その構造およびそのユーザーに関する参照情報を含むデータベース表と
ビューを集めたもの。Oracle は、SQL 文の解析時にデータ・ディクショナリに頻繁にアクセ
スします。ディクショナリ・データを保持するために、メモリー内に 2 つの特別な場所があ
ります。1 つはデータ・ディクショナリ・キャッシュと呼ばれ、データをバッファ（デー
タ・ブロック全体を保持する）のかわりに行として保持するために行キャッシュとも呼ばれ
ます。もう 1 つの領域はライブラリ・キャッシュです。すべての Oracle ユーザー・プロセ
スは、データ・ディクショナリ情報にアクセスするためにこれらの 2 つのキャッシュを共有
しています。
デカルト積（Cartesian
product）
）
デカルト積（
結合条件を使用しない結合はデカルト積（クロス積）に帰結します。デカルト積は、各表か
ら 1 つずつ選んだ行の作成可能なすべての組合せです。つまり、2 つの表の結合において、1
つの表の各行がもう一方の表のすべての行とそれぞれ組み合せられます。3 つ以上の表のデ
カルト積は、1 つの表の各行と残りの表のデカルト積のすべての行をそれぞれ組み合せた結
果です。その他のすべての種類の結合は、デカルト積から、効率的に結合条件を満たさない
行を絞り込んで作成されたデカルト積のサブセットです。
問合せオプティマイザ（Query
Optimizer）
）
問合せオプティマイザ（
SQL 文の潜在的な実行計画セットの生成、各計画のコストの見積り、計画を生成するプラ
ン・ジェネレータのコールを実行し、コストを比較して最も低コストの計画を選択します。
この方法は、SQL 文でアクセスされる表の少なくとも 1 つに関する統計がデータ・ディク
ショナリに含まれている場合に使用されます。問合せオプティマイザは、問合せトランス
フォーマ、エスティメータおよびプラン・ジェネレータで構成されます。
問合せトランスフォーマ（query
transformer）
）
問合せトランスフォーマ（
ユーザー問合せをリライトして、より効率的な問合せ計画を生成するかどうかを判断し、
ビューをマージして副問合せのネスト解除を実行します。
等価結合（equijoin）
）
等価結合（
等価演算子が含まれている結合条件。
動的パフォーマンス・ビュー（dynamic
performance views）
）
動的パフォーマンス・ビュー（
データベース管理者が動的パフォーマンス表（現在のデータベース・アクティビティを記録
する仮想表）に作成するビュー。データベース管理者が変更または削除できないため、固定
ビューと呼ばれます。
トランザクション・リカバリ（transaction
recovery）
）
トランザクション・リカバリ（
Oracle がコミットされない変更を元に戻すためにロールバック・セグメントを適用するイン
スタンス・リカバリの部分。インスタンス・リカバリのロールバック・フェーズとも呼ばれ
ています。
用語集 -6
パーサー（parser）
）
パーサー（
SQL 文の構文分析とセマンティック分析を実行し、
（問合せで参照される）ビューを個別の
問合せブロックに展開します。
バインド変数（bind
variable）
）
バインド変数（
SQL 文の中の変数。SQL 文を正常に実行するには、バインド変数を有効な値または値のア
ドレスに置換する必要があります。
バッファ（buffer）
）
バッファ（
ディスクから読み取られて、現在使用されているデータまたは最近使用されたデータを、
バッファ・マネージャがキャッシュする主メモリーのアドレス。時間の経過につれて、バッ
ファが保持するブロックは変わります。新しいブロックが必要なときは、バッファ・マネー
ジャは古いブロックを破棄して、新しいブロックで置換します。
バッファ・プール（buffer
pool）
）
バッファ・プール（
バッファの集まり。
非等価結合（nonequijoin）
）
非等価結合（
等価演算子以外の演算子が含まれている結合条件。
非同期 I/O（
（asynchronous I/O）
）
独立 I/O。転送に対する時間的な要件がなく、転送が終了する前に他のプロセスを開始でき
ます。
複合問合せ（compound
query）
）
複合問合せ（
2 つ以上の単純な文または複合文を組み合せるために集合演算子（UNION、UNION ALL、
INTERSECT または MINUS）を使用する問合せ。複合問合せ内の単純な文または複合文それ
ぞれは、コンポーネント・クエリーと呼ばれます。
プラン・ジェネレータ（plan
generator）
）
プラン・ジェネレータ（
問合せオプティマイザが最も低コストの計画を選択できるように、与えられた問合せに対し
て考えられる様々な計画を試行します。異なるアクセス・パス、結合方法および結合順序を
試みることによって、問合せブロックに対する様々な計画を調査します。
ブロック（block）
）
ブロック（
主メモリーとディスク間でのデータ転送の単位。メモリー・アドレス空間の 1 セクションに
ある多数のブロックが 1 つのセグメントを形成します。
分散型の文（distributed
statement）
）
分散型の文（
分散データベースの 2 つ以上の個別ノード / インスタンスのデータにアクセスする文。リ
モート文は、分散データベースの 1 つのリモート・ノードのデータにアクセスします。
用語集 -7
ページング（paging）
）
ページング（
プログラムの作業メモリーのうちの使用頻度の低い部分を主メモリーから二次記憶媒体（通
常はディスク）に移動することによって使用可能なメモリー領域を増やすための手法。転送
単位はページと呼ばれます。
ボトルネック（bottleneck）
）
ボトルネック（
一般にはシステムの帯域幅がデータの処理される速度で中継されてくる量をサポートできな
いときのデータ伝送の遅延。ただし、システム内にボトルネックを生成する可能性のある要
因は多数あります。
ミラー化（mirroring）
）
ミラー化（
同じ内容のデータのコピーを 1 つ以上のディスクで保持すること。一般的にミラー化は、オ
ペレーティング・システム・レベルで二重化されたハードディスクにおいて実現します。し
たがって、いずれかのディスクが使用不可能になっても、中断せずにもう一方のディスクが
要求の処理を継続できます。
ライブラリ・キャッシュ（library
cache）
）
ライブラリ・キャッシュ（
共有されている SQL 領域と PL/SQL 領域を保持するメモリー構造。ライブラリ・キャッ
シュは共有プールの 3 つの部分のうちの 1 つです。
ラッチ（latch）
）
ラッチ（
システム・グローバル領域で共有されているデータ構造を保護するための簡素な下位レベル
のシリアライズ・メカニズム。
リテラル（literal）
）
リテラル（
コンパイル時に書き込まれ、実行時に読取り専用の定数の値。リテラルは高速にアクセスで
き、また、修正が不要なときに使用します。
用語集 -8
索引
A
Active Session History，5-4
addmrpt.sql
Automatic Database Diagnostic Monitor，6-8
ALL_OUTLINE_HINTS ビュー
ストアド・アウトライン・ヒント，18-9
ALL_OUTLINES ビュー
ストアド・アウトライン，18-9
ALL_ROWS オプティマイザ・モード・パラメータ，
14-4
ALL_ROWS ヒント，14-5，17-13
ALTER INDEX 文，16-7
ALTER SESSION 文
SET SESSION_CACHED_CURSORS 句，7-41
例，20-15
ANALYZE 文，15-6
APPEND ヒント，17-40
Automatic Database Diagnostic Monitor，xxiv，1-6，
6-2，12-6
addmrpt.sql レポート，6-8
API を使用した実行，6-9
DB time，6-3
DBIO_EXPECTED，6-6
DBMS_ADVISOR パッケージ，6-9
Oracle Enterprise Manager を使用したアクセス，
6-7
STATISTICS_LEVEL パラメータ，6-6
概要，6-3
結果，6-4
検出結果，6-4
考慮される問題のタイプ，6-3
推奨事項のアクションと理論的根拠，6-5
推奨事項のタイプ，6-4
設定，6-6
分析結果の例，6-5
レポートの例，6-5
awrrpt.sql
自動ワークロード・リポジトリ・レポート，5-16
B
buffer busy waits イベント，10-16，10-24
処置，10-25
BYTES 列
PLAN_TABLE 表，19-24
B ツリー索引，2-15
C
CACHE ヒント，17-41
CARDINALITY 列
PLAN_TABLE 表，19-24
CHOOSE オプティマイザ・モード・パラメータ，14-4
CHOOSE ヒント，14-5
CLUSTER ヒント，17-16
COMPATIBLE 初期化パラメータ，4-3
Connection Manager，11-15
consistent gets from cache 統計，7-12
CONTROL_FILES 初期化パラメータ，4-2
COST 列
PLAN_TABLE 表，19-24
CPU，2-8
使用率，9-11
統計，5-6
CPU_COSTING ヒント，14-5
CPU 統計，10-5
CREATE INDEX 文
PARALLEL 句，4-9
索引 -1
CREATE OUTLINE 文，18-5
CREATE_STORED_OUTLINES 初期化パラメータ，
18-5，18-6
CREATE_STORED_OUTLINES パラメータ，18-5
CURSOR_NUM 列
TKPROF_TABLE 表，20-29
CURSOR_SHARING_EXACT ヒント，17-45
CURSOR_SHARING 初期化パラメータ，7-26，7-45，
14-8
CURSOR_SPACE_FOR_TIME 初期化パラメータ
設定，7-40
D
Database Resource Manager，9-5，9-9，10-5
DATE_OF_INSERT 列
TKPROF_TABLE 表，20-28
db block gets from cache 統計，7-12
db file scattered read 待機イベント，10-16，10-26
処置，10-26，10-29
db file sequential read 待機イベント，10-16，10-26，
10-28
処置，10-29
DB time
測定値，6-3
統計，5-4
DB_BLOCK_SIZE 初期化パラメータ，4-3，8-4
DB_CACHE_ADVICE パラメータ，7-14
DB_CACHE_SIZE 初期化パラメータ，7-15
DB_DOMAIN 初期化パラメータ，4-2
DB_FILE_MULTIBLOCK_READ_COUNT 初期化パラ
メータ，8-3，8-4，8-5，10-26，14-8，14-18
コストベースの最適化，14-30
DB_KEEP_CACHE_SIZE
初期化パラメータ，7-19
DB_NAME 初期化パラメータ，4-2
DB_nK_CACHE_SIZE 初期化パラメータ，7-14
DB_RECYCLE_CACHE_SIZE
初期化パラメータ，7-20
DB_WRITER_PROCESSES 初期化パラメータ，10-36
DBA_HIST_WR_CONTROL ビュー
自動ワークロード・リポジトリ設定，5-14
DBA_HIST ビュー，5-15
DBA_OBJECTS ビュー，7-18
DBA_OUTLINE_HINTS ビュー
ストアド・アウトライン・ヒント，18-9
索引 -2
DBA_OUTLINES ビュー
ストアド・アウトライン，18-9
DBIO_EXPECTED パラメータ，6-6
DBMS_ADVISOR パッケージ
ADDM 用の設定，6-6
Automatic Database Diagnostic Monitor，6-8，6-9
DBIO_EXPECTED の設定，6-6
DBMS_MONITOR パッケージ
End to End Application Tracing，20-3
DBMS_OUTLN_EDIT パッケージ
アウトラインを管理するプロシージャ，18-4
DBMS_OUTLN パッケージ
アウトラインを管理するプロシージャ，18-4
DBMS_SHARED_POOL パッケージ
共有プールの管理，7-44
DBMS_SQLTUNE パッケージ
SQL Tuning Advisor，13-8
SQL Tuning Set，13-12
SQL プロファイル，13-10
DBMS_STATS パッケージ，15-7
収集プロシージャのサンプル・サイズの手動決定，
15-8
問合せオプティマイザ統計の管理，14-6，15-3
DBMS_WORKLOAD_REPOSITORY パッケージ
自動ワークロード・リポジトリの管理，5-13
DBMS_XPLAN パッケージ
PLAN TABLE 出力の表示，19-7
DEPTH 列
TKPROF_TABLE 表，20-28
direct path
read イベント，10-30
read イベントの原因，10-30
read イベントの処置，10-30
write イベント，10-31
write イベントの原因，10-32
write イベントの処置，10-32
DISPATCHERS 初期化パラメータ，11-3
DISTRIBUTION 列
PLAN_TABLE 表，19-26
DRIVING_SITE ヒント，17-45
DYNAMIC_SAMPLING ヒント，17-46
E
G
End to End Application Tracing，20-1，20-2
DBMS_APPLICATION_INFO パッケージ，20-2
DBMS_MONITOR パッケージ，20-3
Oracle Enterprise Manager を使用したアクセス，
20-3
アクション名とモジュール名，2-21，20-2
サービスの作成，20-2
enqueue 待機イベント，10-17，10-32
処置，10-33
統計，10-11
EXPLAIN PLAN 文
PLAN_TABLE 表，19-5
TKPROF プログラムでの起動，20-20
アクセス・パス，14-28
基本ステップ，14-15
出力ステップの実行順序，14-15
出力の表示，14-15
出力の例，20-26
出力表示用スクリプト，14-15
制限事項，19-5
ドメイン索引，19-22
パーシャル・パーティション・ワイズ結合，19-18
パーティション・オブジェクト，19-14
フル・パーティション・ワイズ結合，19-20
Export Utility
システム生成の列名の統計，15-13
EXTENT MANAGEMENT LOCAL
一時表領域の作成，4-6
GATHER_ INDEX_STATS プロシージャ
DBMS_STATS パッケージ，15-7
GATHER_DATABASE_STATS_JOB_PROC プロシー
ジャ
オプティマイザ統計を自動的に収集，15-3
メンテナンス・ウィンドウでの GATHER_STATS_
JOB，15-3
GATHER_DATABASE_STATS プロシージャ
DBMS_STATS パッケージ，15-7
GATHER_DICTIONARY_STATS プロシージャ
DBMS_STATS パッケージ，15-7
GATHER_SCHEMA_STATS プロシージャ
DBMS_STATS パッケージ，15-7
GATHER_STATS_JOB
オプティマイザ統計を自動的に収集，15-3
GATHER_TABLE_STATS プロシージャ
DBMS_STATS パッケージ，15-7
GETMISSES 列
V$ROWCACHE 表，7-36
GETS 列
V$ROWCACHE ビュー，7-36
GV$BUFFER_POOL_STATISTICS ビュー，7-17
F
FACT ヒント，17-28
FILESYSTEMIO_OPTIONS 初期化パラメータ，9-3
FIRST_ROWS(n) ヒント，14-5，17-13
FIRST_ROWS_n
オプティマイザ・モード・パラメータ，14-4
FIRST_ROWS オプティマイザ・モード・パラメータ，
14-4
free buffer waits イベント，10-16，10-35
FULL ヒント，16-6，17-15
H
HASH ヒント，17-16
HOLD_CURSOR 句，7-28
HW エンキュー
競合，10-34
I
ID 列
PLAN_TABLE 表，19-24
Import Utility
統計のコピー，15-13
INDEX_ASC ヒント，17-18
INDEX_COMBINE ヒント，16-6，17-19
INDEX_DESC ヒント，17-20
INDEX_FFS ヒント，14-26
INDEX_JOIN ヒント，14-26
INDEX_SS_ASC ヒント，17-21
INDEX_SS_DESC ヒント，17-22
INDEX_SS ヒント，17-21
索引 -3
indexspec
ヒント構文，17-9
INDEX ヒント，16-6，17-16
INLIST，19-21
INLIST ITERATOR 操作，19-21
INSERT 文
追加，17-40
I/O
I/O 待機を発生させるオブジェクト，10-28
SQL 文，10-28
過剰な I/O 待機，10-27
監視，10-5
競合，5-3，10-6，10-8，10-27，10-44
低減，16-5
IOT（索引構成表）
，2-15
K
KEEP キャッシュ，7-16
KEEP バッファ・プール，7-19
L
LARGE_POOL_SIZE 初期化パラメータ，7-37
latch free 待機イベント，10-17
処置，10-38
LEADING ヒント，17-30
log buffer
space 待機イベント，10-17，10-44
log file
parallel write 待機イベント，10-43
switch 待機イベント，10-45
sync 待機イベント，10-17，10-46
LOG_BUFFER 初期化パラメータ，7-48
設定，7-49
LRU
除去方針，7-15
ラッチの競合，10-42
M
MAX_DISPATCHERS 初期化パラメータ，4-12
MAX_DUMP_FILE_SIZE 初期化パラメータ
SQL トレース，20-13
MAXOPENCURSORS 句，7-28
MERGE ヒント，17-26
索引 -4
N
NAMESPACE 列
V$LIBRARYCACHE ビュー，7-30
NO_CPU_COSTING ヒント，14-5
NO_EXPAND ヒント，17-24
NO_FACT ヒント，17-29
NO_INDEX_FFS ヒント，17-20
NO_INDEX_SS ヒント，17-22
NO_INDEX ヒント，16-6，17-17
NO_MERGE ヒント，17-26
NO_PARALLEL_INDEX，17-39
NO_PARALLEL ヒント，17-36
NO_PUSH_PRED ヒント，17-43
NO_PUSH_SUBQ ヒント，17-44
NO_QUERY_TRANSFORMATION ヒント，17-23
NO_REWRITE ヒント，17-25
NO_UNNEST ヒント，17-30
NO_USE_HASH ヒント，17-35
NO_USE_MERGE ヒント，17-34
NO_USE_NL ヒント，17-32
NOAPPEND ヒント，17-41
NOCACHE ヒント，17-41
NOPARALLEL_INDEX ヒント，17-39
NOPARALLEL ヒント，17-36
NOREWRITE ヒント，17-25
NOT IN 副問合せ，14-30
O
OBJECT_INSTANCE 列
PLAN_TABLE 表，19-24
OBJECT_NAME 列
PLAN_TABLE 表，19-23
OBJECT_NODE 列
PLAN_TABLE 表，19-23
OBJECT_OWNER 列
PLAN_TABLE 表，19-23
OBJECT_TYPE 列
PLAN_TABLE 表，19-24
OLAP_PAGE_POOL_SIZE 初期化パラメータ，7-66
OPEN_CURSORS 初期化パラメータ，4-2
各セッションのカーソル数の増加，7-35
OPERATION 列
PLAN_TABLE 表，19-23，19-27
OPTIMIZER_DYNAMIC_SAMPLING 初期化パラ
メータ，xxv，15-15，15-16
OPTIMIZER_FEATURES_ENABLE 初期化パラメータ，
14-6，14-26
OPTIMIZER_INDEX_CACHING 初期化パラメータ，
14-8
OPTIMIZER_INDEX_COST_ADJ 初期化パラメータ，
14-8
OPTIMIZER_MODE 初期化パラメータ，14-4，14-8，
17-12
ヒントの影響，14-5
OPTIMIZER 列
PLAN_TABLE，19-24
OPTIONS 列
PLAN_TABLE 表，19-23
OPTMIZER_DYNAMIC_SAMPLING 初期化パラ
メータ，14-6
Oracle CPU 統計，10-5
Oracle Enterprise Manager
Outline Editor，18-7
「Performance」ページ，1-7
SQL Access Advisor へのアクセス，12-7
SQL Tuning Advisor へのアクセス，13-7
SQL Tuning Set へのアクセス，13-12
アドバイザ，1-7
アドバイザへのアクセス，1-7
Oracle Forms，20-15
解析とプライベート SQL 領域の制御，7-29
Oracle Managed Files，8-10
チューニング，8-10
Oracle Net Configuration Assistant，11-14
Oracle Trace
Oracle リリースからの削除，xxvii
廃止，xxvii
Oracle のパフォーマンス改善方法，3-2
手順，3-3
ORDERED ヒント，14-31，17-31
OTHER_TAG 列
PLAN_TABLE 表，19-25
OTHER 列
PLAN_TABLE 表，19-26
Outline Editor，18-7
P
PARALLEL 句
CREATE INDEX 文，4-9
PARALLEL ヒント，17-35
PARENT_ID 列
PLAN_TABLE 表，19-24
PARTITION_ID 列
PLAN_TABLE 表，19-26
PARTITION_START 列
PLAN_TABLE 表，19-25
PARTITION_STOP 列
PLAN_TABLE 表，19-26
PCTFREE パラメータ，4-7，10-20
PCTUSED パラメータ，10-20
PGA_AGGREGATE_TARGET 初期化パラメータ，4-3，
4-9，7-51，9-4，14-9
physical reads from cache 統計，7-12
PLAN_TABLE 表
BYTES 列，19-24
CARDINALITY 列，19-24
COST 列，19-24
DISTRIBUTION 列，19-26
ID 列，19-24
OBJECT_INSTANCE 列，19-24
OBJECT_NAME 列，19-23
OBJECT_NODE 列，19-23
OBJECT_OWNER 列，19-23
OBJECT_TYPE 列，19-24
OPERATION 列，19-23
OPTIMIZER 列，19-24
OPTIONS 列，19-23
OTHER_TAG 列，19-25
OTHER 列，19-26
PARENT_ID 列，19-24
PARTITION_ID 列，19-26
PARTITION_START 列，19-25
PARTITION_STOP 列，19-26
POSITION 列，19-24
REMARKS 列，19-23
SEARCH_COLUMNS 列，19-24
STATEMENT_ID 列，19-23
TIMESTAMP 列，19-23
作成，19-5
表示，19-7
索引 -5
POSITION 列
PLAN_TABLE 表，19-24
PQ_DISTRIBUTE ヒント，17-37
PRIMARY KEY 制約，16-8
PRIVATE_SGA 変数，7-39
PROCESSES 初期化パラメータ，4-3
PUSH_PRED ヒント，17-42
PUSH_SUBQ ヒント，17-44
Q
QB_NAME ヒント，17-44
R
rdbms ipc reply 待機イベント，10-46
read 待機イベント
direct path，10-30
scattered，10-26
REBUILD 句，16-7
RECYCLE キャッシュ，7-16
REDO BUFFER ALLOCATION RETRIES 統計，7-49
REDO ログ，4-5
サイズ設定，4-5
ディスク上の配置，8-7
バッファ・サイズ，10-44
ミラー化，8-9
領域要求，10-18
REDO ログのサイズ設定，4-5
RELEASE_CURSOR 句，7-28
REMARKS 列
PLAN_TABLE 表，19-23
REWRITE ヒント，17-24
ROWID
表アクセス，14-20
RULE オプティマイザ・モード・パラメータ，14-4
RULE ヒント，17-14
S
SAMPLE BLOCK 句，14-27
アクセス・パスおよびヒントによる上書き不可，
14-28
SAMPLE 句，14-27
アクセス・パスおよびヒントによる上書き不可，
14-28
sar UNIX コマンド，9-11
索引 -6
SEARCH_COLUMNS 列
PLAN_TABLE 表，19-24
SELECT 文
SAMPLE 句，14-27
SAMPLE 句およびアクセス・パス，14-28
sequential read 待機イベント
処置，10-29
SESSION_CACHED_CURSORS 初期化パラメータ，
7-41
SESSIONS 初期化パラメータ，4-3
SGA_TARGET 初期化パラメータ，4-3
自動共有メモリー管理，7-3
自動メモリー管理，7-3
SGA サイズ，7-48
SHARED_POOL_RESERVED_SIZE 初期化パラメータ，
7-43
SHARED_POOL_SIZE 初期化パラメータ，7-36，7-43
共有プールのチューニング，7-40
ライブラリ・キャッシュの割当て，7-35
SHOW SGA 文，7-7
SPREAD_MIN_ANALYSIS ヒント，17-47
SQL Access Advisor，1-7，12-6，12-7
Oracle Enterprise Manager を使用したアクセス，
12-7
SQL Tuning Advisor，xxiv，1-6，12-6
API を使用した管理，13-8
Oracle Enterprise Manager を使用したアクセス，
13-7
概要，13-6
チューニング・オプション，13-7
入力ソース，13-6
SQL Tuning Set
API による管理，13-11，13-12
Oracle Enterprise Manager を使用したアクセス，
13-12
説明，12-6，13-6
SQL*Net
message from client アイドル・イベント，10-22
message from dblink 待機イベント，10-23
more data to client 待機イベント，10-24
SQL_STATEMENT 列
TKPROF_TABLE，20-28
SQL_TRACE
初期化パラメータ，20-15
SQLTUNE_CATEGORY 初期化パラメータ
SQL プロファイルのカテゴリの判別，13-4
SQL トレース機能，20-10，20-16
実行手順，20-12
出力，20-22
出力の例，20-26
トレース・ファイル，20-14
文の切捨て，20-25
SQL プロファイル
API による管理，13-10
説明，13-3
SQL 文
I/O を待機，10-28
索引データの修正，16-4
索引不使用，16-6
索引を使用，16-6
実行計画，14-15
STAR_TRANSFORMATION_ENABLED 初期化パラ
メータ，14-9，17-28
STAR_TRANSFORMATION ヒント，17-27
STATEMENT_ID 列
PLAN_TABLE 表，19-23
STATISTICS_LEVEL 初期化パラメータ，5-8，10-7
Automatic Database Diagnostic Monitor の有効化，
6-6
自動ワークロード・リポジトリ，5-11
統計収集用の設定，1-6
STREAMS_POOL_SIZE 初期化パラメータ，4-4，7-4
ST エンキュー
競合，10-33
T
tablespec
ヒント構文，17-7
TCP.NODELAY パラメータ，11-14
TIMED_STATISTICS 初期化パラメータ
SQL トレース，20-13
TIMESTAMP 列
PLAN_TABLE 表，19-23
TKPROF_TABLE，20-28
問合せ，20-27
TKPROF プログラム，20-11，20-16
EXPLAIN PLAN 文の使用，20-20
行ソースの操作，20-23
構文，20-17
出力 SQL スクリプトの生成，20-27
出力 SQL スクリプトの編集，20-27
出力の例，20-26
待機イベント情報，20-24
TM エンキュー
競合，10-34
TRACEFILE_IDENTIFIER 初期化パラメータ
トレース・ファイルの識別，20-14
trcsess ユーティリティ，xxiv，20-7
TX エンキュー
競合，10-34
U
UNDO TABLESPACE 句，4-4
UNDO_MANAGEMENT 初期化パラメータ，4-3，4-4
UNDO_TABLESPACE 初期化パラメータ，4-3
UNDO 管理
自動モード，4-4
UNIX システム・パフォーマンス，9-6
UNNEST ヒント，17-29
USE_CONCAT ヒント，17-23
USE_HASH ヒント，17-34
USE_MERGE ヒント，17-33
USE_NL_WITH_INDEX ヒント，17-33
USE_NL ヒント，17-32
USE_STORED_OUTLINES パラメータ，18-6
USER_DUMP_DEST 初期化パラメータ，20-13
SQL トレース，20-13
USER_ID 列
TKPROF_TABLE，20-29
USER_OUTLINE_HINTS ビュー
ストアド・アウトライン・ヒント，18-9
USER_OUTLINES ビュー
ストアド・アウトライン，18-9
UTLCHN1.SQL スクリプト，10-19
UTLXPLP.SQL スクリプト
EXPLAIN PLAN の表示用，14-15
PLAN TABLE 出力の表示，19-7
UTLXPLS.SQL スクリプト
EXPLAIN PLAN の表示に使用，14-15
EXPLAIN PLAN の表示用，14-15
PLAN TABLE 出力の表示，19-7
V
V$ACTIVE_SESSION_HISTORY ビュー，5-4，10-8
V$BH ビュー，7-18
V$BUFFER_POOL_STATISTICS ビュー，7-17
索引 -7
V$DB_CACHE_ADVICE ビュー，7-8，7-11，7-13，
7-14，7-15，7-17
V$EVENT_HISTOGRAM ビュー，10-9
V$FILE_HISTOGRAM ビュー，10-9
V$JAVA_LIBRARY_CACHE_MEMORY ビュー，7-33
V$JAVA_POOL_ADVICE ビュー，7-33
V$LIBRARY_CACHE_MEMORY ビュー，7-33
V$LIBRARYCACHE ビュー
NAMESPACE 列，7-30
V$OSSTAT ビュー，5-6
V$QUEUE ビュー，4-13
V$ROWCACHE ビュー
GETMISSES 列，7-36
GETS 列，7-36
パフォーマンス統計，7-34
V$RSRC_CONSUMER_GROUP ビュー，10-5
V$SESS_TIME_MODEL ビュー，5-3，10-9
V$SESSION_EVENT ビュー，10-9，10-21
ネットワーク情報，11-6
V$SESSION_WAIT_CLASS ビュー，10-9
V$SESSION_WAIT_HISTORY ビュー，10-9
V$SESSION_WAIT ビュー，10-9，10-21
ネットワーク情報，11-6
V$SESSION ビュー，10-9，10-10，10-21
V$SESSTAT ビュー，10-5
使用，7-38
ネットワーク情報，11-6
V$SHARED_POOL_ADVICE ビュー，7-33
V$SHARED_POOL_RESERVED ビュー，7-43
V$SQL_PLAN_STATISTICS_ALL ビュー
実行計画情報の表示に使用，19-5
V$SQL_PLAN_STATISTICS ビュー
実行計画の統計表示に使用，19-4
V$SQL_PLAN ビュー
実行計画の表示に使用，19-4
V$SYS_TIME_MODEL ビュー，5-3，10-9
V$SYSSTAT ビュー
REDO バッファ割当て，7-49
使用，7-11
V$SYSTEM_EVENT ビュー，10-9，10-21
V$SYSTEM_WAIT_CLASS ビュー，10-9
V$TEMP_HISTOGRAM ビュー，10-10
V$UNDOSTAT ビュー，4-4
V$WAITSTAT ビュー，10-10
vmstat UNIX コマンド，9-11
索引 -8
W
Windows のパフォーマンス，9-6
あ
アイドル待機イベント，10-47
SQL*Net message from client，10-22
アウトライン
CREATE OUTLINE 文，18-5
格納要件，18-3
作成と使用，18-5
実行計画とプラン・スタビリティ，18-2
使用，18-6
説明，18-2
データの照会，18-9
問合せオプティマイザへの移行，18-12
表の移動，18-10
ヒント，18-3
空きリスト，10-25
アクセス・パス
クラスタ・スキャン，14-27
索引スキャン，14-21
実行計画，14-15
定義，14-17
ハッシュ・スキャン，14-27
アップグレード
コストベース・オプティマイザへ，18-13
アドバイザ
Oracle Enterprise Manager を使用したアクセス，
1-7
アプリケーション
開発の傾向，2-21
実装，2-19
設計の原則，2-13
配置，2-26
アプリケーションの配置，2-26
アンチ結合，14-30
い
移行行，10-19
一意性，16-8
一意制約，16-8
一時表領域，4-5
作成，4-6
一貫性
読取り，10-18
一貫モード
TKPROF，20-22
インスタンスの構成
初期化ファイル，4-2
パフォーマンスの考慮事項，4-2
インターネットの拡張性，2-4
え
エラー・メッセージ・マニュアル，xix
お
応答時間，2-12
オプティマイザの目標，14-3
コストベースのアプローチ，14-4
最適化，14-3，17-13
オブジェクト指向，2-21
オプティマイザ
RBO からの移行，18-12
アップグレード，18-13
応答時間，14-3
概要，1-5，14-2
コスト計算，14-9
スループット，14-3
設定モードのパラメータ，14-4
操作，14-2
問合せ，1-5
統計，15-2
プラン・スタビリティ，18-2
モード，13-2
目標，14-3
オプティマイザ・モード・パラメータ
ALL_ROWS，14-4
CHOOSE，14-4
FIRST_ROWS，14-4
FIRST_ROWS_n，14-4
RULE，14-4
オペレーティング・システム
ディスク I/O の監視，10-5
データ・キャッシュ，9-2
統計，5-5
か
カーソル
アクセス，7-28
共有，7-28
開始列
パーティション化と EXPLAIN PLAN 文，19-15
解析
Oracle Forms，7-29
Oracle プリコンパイラ，7-28
ソフト，2-17
ハード，2-17
不要コールの低減，7-28
概念的なモデル化，3-5
開発環境，2-19
外部結合，12-18，14-36
拡張構文
グローバル・ヒント，17-7
ヒントにおける表の指定，17-7
拡張性，2-3
インターネット，2-4
妨げる要因，2-6
線状，2-6
仮想メモリー統計，5-6
型変換，12-9
監視
診断，1-6，12-6
完全外部結合，14-38
き
規定された制約，16-8
逆キー索引，2-15
キャッシュ表
小規模表の自動キャッシュ，17-42
行
位置特定に使用される ROWID，14-20
行ソース，14-17
行キャッシュ・オブジェクト，10-43
競合
共有プール，10-40
待機イベント，10-38
チューニング，10-1
メモリー，7-2，10-1
ライブラリ・キャッシュ・ラッチ，10-40
行ソース，14-17
索引 -9
共有 SQL 領域
メモリー割当て，7-35
共有サーバー
競合の低減，4-10
チューニング，4-10
パフォーマンス問題，4-10
メモリーのチューニング，7-37
共有プール競合，10-40
緊急事態
パフォーマンス，3-9
く
クライアント / サーバー・アプリケーション，9-12
クラス
待機イベント，5-3，10-8
クラスタ，16-14
スキャン，14-27
ソートされたハッシュ・クラスタ，16-15
ハッシュおよびスキャン，14-27
グローバル・ヒント，17-7
け
結合
アンチ結合，14-30
外部，14-36
完全外部，14-38
結合順序および実行計画，14-15
索引結合，14-26
実行計画，14-29
順序，12-17，12-18
セミ結合，14-30
ソート / マージ，14-34
ソート / マージおよびコストベースの最適化，
14-30
デカルト，14-35
ネステッド・ループ，14-31
ネステッド・ループおよびコストベースの最適化，
14-30
パーティション・ワイズ
パーシャルの例，19-18
フル，19-20
フルの例，19-20
ハッシュ，14-33
パラレル、PQ_DISTRIBUTE ヒント，17-37
索引 -10
現行モード
TKPROF，20-22
こ
コスト
オプティマイザ計算，14-9
コストベースの最適化，14-9
アップグレード，18-13
プラン・スタビリティのプロシージャ，18-12
コンテキスト・スイッチ，9-12
コンポーネント
ソフトウェア，2-8
ハードウェア，2-7
コンポジット・パーティション化
例，19-16
さ
サービス時間，2-12
再帰的コール，20-24
最高水位標，14-18
最大セッション・メモリー統計，7-38
最適化
アプローチの選択，14-4
コスト計算，14-9
コストベース，14-9
コストベースおよびアクセス・パスの選択，14-28
実行される操作，14-2
手動，14-5
説明，1-5，14-2
動的サンプリング，14-6
ヒント，14-5，14-26
索引
B ツリー，2-15
I/O の削減，2-16
値の修正，16-4
一意性の規定，16-8
一意でない，16-8
逆キー，2-15
結合，14-26
コスト，2-16
コンポジット，16-5
再作成，16-7
索引結合，14-26
削除，16-2
作成，4-9
順序，2-16
使用，16-6
シリアライズ，2-16
スキャン，14-21
設計，2-14
選択性，2-16，16-3
選択性の向上，16-5
ディスク上の配置，8-6
低選択性，16-6
統計の収集，15-12
ドメイン，16-13
パーティション，2-15
ビットマップ，2-15，16-12
ヒントでの指定，17-9
ファンクション索引，2-15，16-10
不使用，16-6
列の順序，2-16
列の選択，16-3
列の追加，2-15
索引構成表，2-15
サンプル表スキャン，14-27
ヒントによる上書き不可，14-28
し
時間モデル統計，5-3
式
型が混在，12-9
システム・アーキテクチャ，2-7
構成，2-10
ソフトウェア・コンポーネント，2-8
データおよびトランザクション，2-10
ビジネス・ロジックの実装，2-9
ユーザー・インタフェースの管理，2-9
ユーザー要求およびリソース割当て，2-9
ハードウェア・コンポーネント，2-7
CPU，2-8
I/O サブシステム，2-8
ネットワーク，2-8
メモリー，2-8
システム・グローバル領域のチューニング，7-6
実行計画
TKPROF，20-17，20-20
utlxpls.sql スクリプトによる表示，14-15
概要，14-15
結合，14-29
プラン・スタビリティ，18-2
プラン・スタビリティでの保存，18-2
例，20-17
自動 SQL チューニング，1-6，12-6
概要，13-2
機能，13-1
分析，13-3
自動 UNDO 管理，4-4
モード，4-4
自動共有メモリー管理，7-3
自動セグメント領域管理，4-6，8-12，10-25
自動チューニング・オプティマイザ，13-2
自動ワークロード・リポジトリ，xxiv，1-6
API による管理，5-13
DBA_HIST_WR_CONTROL ビューで設定，5-14
DBMS_WORKLOAD_REPOSITORY パッケージ，
5-13
Oracle Enterprise Manager を使用したアクセス，
5-12
概要，5-10
自動スナップショット収集をオフに設定，5-11
収集される統計，5-10
データの収集，5-2
データへのアクセスに使用するビュー，5-15
デフォルト設定，5-11
保存期間，5-11
保存期間に関する推奨事項，5-11
領域使用量，5-11
領域使用量に影響する要因，5-10
領域使用量の最小化，5-11
レポート，5-16
レポートの例外的なパーセンテージ，5-16
終了列
パーティション化と EXPLAIN PLAN 文，19-15
順序
結合，12-17
使用可能にされた制約，16-8
使用禁止にされた制約，16-8
照合
バインド変数，14-12
初期化パラメータ
CONTROL_FILES，4-2
DB_BLOCK_SIZE，4-3
DB_DOMAIN，4-2
DB_FILE_MULTIBLOCK_READ_COUNT，14-30
DB_NAME，4-2
OPEN_CURSORS，4-2
索引 -11
OPTIMIZER_DYNAMIC_SAMPLING，xxv，
15-15，15-16
OPTIMIZER_FEATURES_ENABLE，14-26
OPTIMIZER_MODE，14-4，17-12
PGA_AGGREGATE_TARGET，4-9
PROCESSES，4-3
SESSION_CACHED_CURSORS，7-41
SESSIONS，4-3
SQL_TRACE，20-15
STREAMS_POOL_SIZE，4-4
USER_DUMP_DEST，20-13
新機能，xxiii
診断モニター，1-6，6-2，12-6
概要，6-2
す
スキャン
索引，14-21
索引結合，14-26
サンプル表，14-27
サンプル表およびヒントは上書き不可，14-28
タイプ・ビットマップの索引，14-27
スター型変換，17-27
ストアド・アウトライン
格納要件，18-3
作成と使用，18-5
実行計画とプラン・スタビリティ，18-2
使用，18-6
データの照会，18-9
表の移動，18-10
ヒント，18-3
ストライプ化
手動，8-6
スナップショット
保存済セット，5-11
スラッシング，9-12
スループット
オプティマイザの目標，14-3
コストベースのアプローチ，14-4
最適化，14-3，17-13
スワッピング，9-11，9-12
低減，7-6
索引 -12
せ
制約，16-8
セグメント・レベル統計，10-11
設計
検証，2-24
テスト，2-24
デバッグ，2-24
設計の検証，2-24
設計の原則，2-13
設計のテスト，2-24
設計のデバッグ，2-24
セッション・データ・ユニット（SDU），11-14
セッション・メモリー統計，7-38
セミ結合，14-30
線状の拡張性，2-6
選択性
索引，16-6
索引内の列の順序付け，2-16
索引の向上，16-5
索引の作成，16-3
全表スキャン，10-31
そ
ソート / マージ結合，14-34
コストベースの最適化，14-30
ソート領域
チューニング，7-50
測定値，5-2
ソフトウェア
コンポーネント，2-8
ソフト解析，2-17
た
待機イベント，5-3
buffer busy waits，10-24
direct path，10-31
enqueue，10-32
free buffer waits，10-35
log buffer space，10-44
log file parallel write，10-43
log file switch，10-45
log file sync，10-46
rdbms ipc reply，10-46
アイドル待機イベント，10-47
競合待機イベント，10-38
クラス，5-3，10-8
ネットワーク通信待機イベント，10-22
ライブラリ・キャッシュ・ラッチ，10-38
ラッチ，10-38
リソース待機イベント，10-28
ダイレクト・パス INSERT，17-40
ち
チューニング
SQL Tuning Advisor，13-6
共有サーバー，4-10
システム・グローバル領域（SGA）
，7-6
ソート，7-50
プロアクティブな監視，1-4
ボトルネックの解消，1-4
メモリー割当て，7-7
ラッチ，1-4，10-40
リソースの競合，10-1
論理構造，16-2
つ
ツール
パフォーマンス・チューニング，1-6
て
低減
共有サーバーとの競合，4-13
ディスパッチャとの競合，4-12
データ・ディクショナリ・キャッシュ・ミス，7-36
不要解析コール，7-28
ページングとスワッピング，7-6
ディスク
オペレーティング・システムファイル・アクティビ
ティの監視，10-5
統計，5-6
データ
キャッシュ（cache），9-2
検索，2-12
収集，5-2
問合せ，2-12
トランザクション，2-10
モデル化，2-14
データ・ディクショナリ，7-36
最適化で使用されるビュー，15-18
統計，15-18
データベース
サイズ，2-13
診断と監視，6-2
統計，5-3
バッファ，7-15，7-36
データベース監視，1-6，12-6
診断，6-2
デカルト結合，14-35
デフォルト・キャッシュ，7-16
と
問合せ
索引不使用，16-6
索引を使用，16-6
データ，2-12
問合せオプティマイザ，1-5
「オプティマイザ」を参照
等価結合，12-9
統計
consistent gets from cache，7-12
db block gets from cache，7-12
DBMS_STATS パッケージでの収集，15-7
DBMS_STATS プロシージャによる収集，15-6
GATHER_STATS_JOB，15-3
physical reads from cache，7-12
STATISTICS_LEVEL 初期化パラメータ，1-6
エクスポートとインポート，15-13
オプティマイザ，15-2
オプティマイザ使用，14-9
オプティマイザ・モード，14-4
オペレーティング・システム，5-5
CPU 統計，5-6
仮想メモリー統計，5-6
ディスク統計，5-6
ネットワーク統計，5-7
外部表に関する収集，15-5
共有サーバー・プロセス，4-13
欠落，15-17
最大セッション・メモリー，7-38
サンプリングを使用した収集，15-8
時間モデル，5-3
システム，15-10
失効，15-9
索引 -13
失効したものを収集，15-9
自動収集，15-3
自動収集を使用可能にする方法，15-4
収集，5-2
収集する時期，15-10
手動による収集，15-6
セグメント・レベル，10-11
セッション・メモリー，7-38
データベース，5-3
問合せ最適化のための生成，15-3
ヒストグラム，15-19
ビューに表示，15-18
ベースライン，5-2
前のバージョンのリストア，15-12
前のバージョンのリストアに関する制限事項，
15-13
ユーザー定義，15-9
ロック，15-14
動的サンプリング
パフォーマンスの向上，15-16
プロセス，15-15
目的，15-15
用途，15-15
レベル設定，15-16，15-17
ドメイン索引
EXPLAIN PLAN，19-22
使用，16-13
トランザクションおよびデータ，2-10
トリクル・ロールアウトの方法，2-26
トレース
trcsess との統合，20-7
ファイルの識別，20-14
ね
ネステッド・ループ結合，14-31
コストベースの最適化，14-30
ネットワーク
セッション・データ・ユニット，11-14
速度，2-12
チューニング，11-1
統計，5-7
ハードウェア・コンポーネント，2-8
配列インタフェース，11-14
パフォーマンス上の問題の検出，11-6
問題の解決，11-9
索引 -14
ネットワーク通信待機イベント，10-22
db file scattered read 待機イベント，10-26
db file sequential read 待機イベント，10-26，10-28
SQL*Net message from dblink，10-23
SQL*Net more data to client，10-24
は
パーティション・オブジェクト
EXPLAIN PLAN 文，19-14
パーティション化
開始列と終了列，19-15
ハッシュ，19-14
複合の例，19-16
分散値，19-27
例，19-14
レンジ，19-14
パーティション索引，2-15
パーティション・ワイズ結合
パーシャル、EXPLAIN PLAN 出力，19-18
フル，19-20
フル、EXPLAIN PLAN 出力，19-20
ハードウェア
コンポーネント，2-7
コンポーネントのサイズ指定，2-6
コンポーネントの制限，2-7
ハード解析，2-17
配布
ヒント，17-37
配列インタフェース，11-14
バインド変数，7-24
照合，14-12
ハッシュ
分散値，19-27
ハッシュ・クラスタ
スキャン，14-27
ソート，16-15
ハッシュ結合，14-33
コストベースの最適化，14-30
索引結合，14-26
ハッシュ・パーティション，19-14
例，19-14
ハッシング，16-15
バッファ・キャッシュ
競合，10-26，10-28，10-40
バッファ数の低減，7-15，7-36
ヒット率，7-12
バッファ・プール
KEEP，7-19
KEEP キャッシュ，7-16
RECYCLE キャッシュ，7-16
デフォルト・キャッシュ，7-16
ヒット率，7-17
複数，7-15
パフォーマンス
UNIX ベース・システム，9-6
Windows，9-6
Windows でのメモリーの監視，9-11
改善方法，3-2
改善方法の手順，3-3
緊急事態，3-9
実行計画の表示，14-15
診断およびチューニング用のツール，1-6
メインフレーム，9-7
パフォーマンスの緊急の問題に対処する方法，3-9
パラレル結合
PQ_DISTRIBUTE ヒント，17-37
パラレル実行
ヒント，17-35
ひ
ビジネス・ロジック，2-9，2-19
ビジネス・ロジックの実装，2-9
ヒストグラム
高さ調整済，15-19
表示，15-19
頻度，15-21
ビッグ・バン・ロールアウトの方法，2-26
ビットマップ索引，2-15
INLIST ITERATOR，19-22
結合，16-13
用途，16-12
ビュー，2-17
DBA_HIST，5-15
統計，15-18
表
記憶領域オプションの設定，4-7
作成，4-7
設計，2-14
全表スキャン，10-31
ディスク上の配置，8-6
表領域，4-5
一時，4-5，4-6
作成，4-5
作成、一時，4-6
ヒント
ALL_ROWS，17-13
APPEND，17-40
CACHE，17-41
CLUSTER，17-16
CURSOR_SHARING_EXACT，17-45
DRIVING_SITE，17-45
DYNAMIC_SAMPLING，17-46
FACT，17-28
FIRST_ROWS(n)，17-13
FULL，16-6，17-15
HASH，17-16
INDEX，17-16
INDEX_ASC，17-18
INDEX_COMBINE，17-19
INDEX_DESC，17-20
INDEX_FFS，14-26
INDEX_JOIN，14-26
INDEX_SS，17-21
INDEX_SS_ASC，17-21
INDEX_SS_DESC，17-22
indexspec 構文，17-9
LEADING，17-30
MERGE，17-26
NO_EXPAND，17-24
NO_FACT，17-29
NO_INDEX，16-6，17-17
NO_INDEX_FFS，17-20
NO_INDEX_SS，17-22
NO_MERGE，17-26
NO_PARALLEL，17-36
NO_PARALLEL_INDEX，17-39
NO_PUSH_PRED，17-43
NO_PUSH_SUBQ，17-44
NO_QUERY_TRANSFORMATION，17-23
NO_REWRITE，17-25
NO_UNNEST，17-30
NO_USE_HASH，17-35
NO_USE_MERGE，17-34
NO_USE_NL，17-32
NOAPPEND，17-41
NOCACHE，17-41
NOPARALLEL，17-36
索引 -15
NOPARALLEL_INDEX，17-39
NOREWRITE，17-25
ORDERED，17-31
ORDERED ヒント，14-31
PARALLEL，17-35
PQ_DISTRIBUTE，17-37
PUSH_PRED，17-42
PUSH_SUBQ，17-44
QB_NAME，17-44
REWRITE，17-24
RULE，17-14
SPREAD_MIN_ANALYSIS，17-47
STAR_TRANSFORMATION，17-27
tablespec 構文，17-7
UNNEST，17-29
USE_CONCAT，17-23
USE_HASH，17-34
USE_MERGE，17-33
USE_NL，17-32
USE_NL_WITH_INDEX，17-33
アウトラインでの使用，18-3
アクセス・パス，12-17，17-14，17-22
位置構文，17-5
上書き OPTIMIZER_MODE，14-5
オプティマイザ，17-2
オプティマイザの選択を上書き，14-28
拡張構文の使用，17-7
グローバル，17-7
グローバルとローカルの比較，17-7
結合操作，17-31
構文，17-4
最適化のアプローチと目標，17-12
索引の指定，17-9
サンプル・アクセス・パスは上書き不可，14-28
使用方法，17-2
問合せブロックの指定，17-5
パラレル問合せオプション，17-35
並列度，17-35
ふ
ファンクション索引，2-15，16-10
複合索引，16-5
複数バッファ・プール，7-15
副問合せ
NOT IN，14-30
ネスト解除，12-20
索引 -16
プラン・スタビリティ，18-2
コストベース・オプティマイザのプロシージャ，
18-12
実行計画の保存，18-2
制限事項，18-2
ヒントの使用，18-2
プリコンパイラ
解析とプライベート SQL 領域の制御，7-28
フル・パーティション・ワイズ結合，19-20
プロアクティブな監視，1-4
ブロードキャスト
分散値，19-27
プログラミング言語，2-19
プログラム・グローバル領域（PGA）
direct path read，10-30
direct path write，10-31
共有サーバー，7-38
プロセス
スケジューリング，9-12
プロセスのスイッチング，9-12
ブロック・クリーンアウト，10-18
ブロック・サイズ
最適な，8-11
選択，8-11
分散読取り待機イベント，10-26
処置，10-26
へ
ページ表，9-11
ページング，9-12
低減，7-6
ベースライン，1-3
パフォーマンス，5-2
保存済スナップショット・セット，5-11
変換されない列値，12-9
ほ
保存済スナップショット，5-11
ボトルネック
解消，1-4
修正，3-2
特定，3-2
メモリー，7-2
リソース，10-23
み
ら
ミラー化
REDO ログ，8-9
ライブラリ・キャッシュ
PIN，10-43
メモリー割当て，7-35
ラッチ待機イベント，10-38
ラッチの競合，10-40
ロック，10-44
ラウンドロビン
分散値，19-27
ラッチ
チューニング，1-4，10-40
ラッチ待機イベント，10-38
ラッチの競合
共有プール・ラッチ，10-13
ライブラリ・キャッシュ・ラッチ，10-13
め
メモリー
ハードウェア・コンポーネント，2-8
メモリー・アドバイザ
Oracle Enterprise Manager を使用したアクセス，
7-2
メモリー割当て
共有 SQL 領域，7-35
重要性，7-2
チューニング，7-7
ライブラリ・キャッシュ，7-35
も
モデル化
概念的，3-5
データ，2-14
ワークロード，2-24
ゆ
ユーザー
位置，2-12
インタフェース，2-19
応答時間，2-12
数，2-11
対話方式，2-11
ネットワーク速度，2-12
要求，2-19
ユーザー・インタフェースの管理，2-9
ユーザー・グローバル領域（UGA）
V$SESSTAT，7-38
共有サーバー，4-10，7-37
ユーザー定義のバインド変数，14-12
ユーザー要求，2-9
よ
読取り一貫性，10-18
り
リソース
待機イベント，10-28
ボトルネック，10-23
割当て，2-9，2-19
れ
例
ALTER SESSION 文，20-15
EXPLAIN PLAN 出力，20-26
SQL トレース機能の出力，20-26
列
索引付け，16-3
列の順序
索引，2-16
連鎖行，10-19
レンジ
パーティション，19-14
パーティションの例，19-14
分散値，19-27
ろ
ロールアウトの方法
トリクル・アプローチ，2-26
ビッグ・バン・アプローチ，2-26
ログ・バッファ
チューニング，7-48
索引 -17
ログ・ライター・プロセス
チューニング，8-8
ロックおよびロック・ホルダー
検索，10-33
わ
ワークロード
テスト，2-24
見積り，2-23
推定，2-23
ベンチマーク，2-23
モデル化，2-24
ワークロードの推定，2-23
ワークロードのベンチマーク，2-23
ワークロードの見積り，2-23
推定，2-23
ベンチマーク，2-23
割当て
メモリー，7-2
索引 -18