パフォーマンス・チューニング・ガイド , 10g リリース 2（10.2）

Oracle® Database
パフォーマンス・チューニング・ガイド
10g リリース 2（10.2）
部品番号 : B19207-02
2008 年 5 月
Oracle Database パフォーマンス・チューニング・ガイド , 10g リリース 2（10.2）
部品番号 : B19207-02
原本名 : Oracle Database Performance Tuning Guide, 10g Release 2 (10.2)
原本部品番号 : B14211-03
原本著者 : Immanuel Chan
原本協力者 : Aditya Agrawal, James Barlow, Vladimir Barriere, Ruth Baylis, Eric Belden, Pete Belknap,
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, Prabhaker Gongloor, Connie Dialeris Green, Russell 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, Paul Lane, Sue K. Lee,
Herve Lejeune, Yunrui Li, Juan Loaiza, Diana Lorentz, George Lumpkin, Joe McDonald, Bill McKenna,
Mughees Minhas, Valarie Moore, Sujatha Muthulingam, Gary Ngai, Michael Orlowski, Kant C. Patel,
Richard Powell, Mark Ramacher, Shankar Raman, Yair Sarig, Uri Shaft, Vinay Srihari, Sankar Subramanian,
Margaret Susairaj, Hal Takahara, Misha Tyulenev, Mark Van de Wiel, Venkateshwaran Venkataramani, Nitin
Vengurlekar, Stephen Vivian, Simon Watt, Andrew Witkowski, Graham Wood, Khaled Yagoub, Mohamed
Zait
Copyright © 2000, 2008, Oracle. 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 USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
このプログラムは、核、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションへの用途
を目的としておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを安全に使
用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用
者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、オラクル社およ
びその関連会社は一切責任を負いかねます。
Oracle、JD Edwards、PeopleSoft、Siebel は米国 Oracle Corporation およびその子会社、関連会社の登録商
標です。その他の名称は、他社の商標の可能性があります。
このプログラムは、第三者の Web サイトへリンクし、第三者のコンテンツ、製品、サービスへアクセスす
ることがあります。オラクル社およびその関連会社は第三者の Web サイトで提供されるコンテンツについ
ては、一切の責任を負いかねます。当該コンテンツの利用は、お客様の責任になります。第三者の製品また
はサービスを購入する場合は、第三者と直接の取引となります。オラクル社およびその関連会社は、第三者
の製品およびサービスの品質、契約の履行（製品またはサービスの提供、保証義務を含む）に関しては責任
を負いかねます。また、第三者との取引により損失や損害が発生いたしましても、オラクル社およびその関
連会社は一切の責任を負いかねます。
目次
はじめに ..............................................................................................................................................................................
xxi
対象読者 ....................................................................................................................................................................... xxii
ドキュメントのアクセシビリティについて ........................................................................................................... xxii
関連ドキュメント ....................................................................................................................................................... xxiii
表記規則 ....................................................................................................................................................................... xxiii
サポートおよびサービス .......................................................................................................................................... xxiv
Oracle のパフォーマンスの新機能
................................................................................................................ xxv
第 I 部 パフォーマンス・チューニング
1
パフォーマンス・チューニングの概要
パフォーマンス・チューニングの概要 .................................................................................................................... 1-2
パフォーマンス計画 ............................................................................................................................................ 1-2
インスタンスのチューニング ............................................................................................................................ 1-2
パフォーマンスの原理 ................................................................................................................................
ベースライン ................................................................................................................................................
症状および問題点 ........................................................................................................................................
チューニングの時期 ....................................................................................................................................
プロアクティブな監視 ........................................................................................................................
ボトルネックの解消 ............................................................................................................................
SQL チューニング ...............................................................................................................................................
1-2
1-2
1-3
1-3
1-3
1-4
1-4
問合せオプティマイザおよび実行計画 .................................................................................................... 1-4
パフォーマンス・チューニング機能およびツールの概要 .................................................................................... 1-5
自動パフォーマンス・チューニング機能 ........................................................................................................ 1-5
その他の Oracle ツール ...................................................................................................................................... 1-6
V$ パフォーマンス・ビュー ...................................................................................................................... 1-6
i
第 II 部 パフォーマンス計画
2
パフォーマンスを考慮した設計と開発
オラクル社の新しい方法論 ........................................................................................................................................
投資の選択肢について ................................................................................................................................................
拡張性について ............................................................................................................................................................
拡張性とは ............................................................................................................................................................
2-2
2-2
2-3
2-3
システムの拡張性 ................................................................................................................................................ 2-4
拡張性を妨げる要因 ............................................................................................................................................ 2-5
システム・アーキテクチャ ........................................................................................................................................ 2-6
ハードウェア・コンポーネントとソフトウェア・コンポーネント ............................................................ 2-6
ハードウェア・コンポーネント ................................................................................................................
CPU ........................................................................................................................................................
メモリー ................................................................................................................................................
I/O サブシステム ................................................................................................................................
ネットワーク ........................................................................................................................................
ソフトウェア・コンポーネント ................................................................................................................
ユーザー・インタフェースの管理 ....................................................................................................
ビジネス・ロジックの実装 ................................................................................................................
ユーザー要求とリソース割当ての管理 ............................................................................................
データおよびトランザクションの管理 ............................................................................................
要件に合った正しいシステム・アーキテクチャの構成 ................................................................................
2-6
2-6
2-6
2-6
2-6
2-6
2-7
2-7
2-7
2-7
2-8
アプリケーション設計の原則 ................................................................................................................................. 2-10
アプリケーション設計の簡潔さ ...................................................................................................................... 2-10
データのモデル化 .............................................................................................................................................. 2-10
表および索引の設計 .......................................................................................................................................... 2-11
索引への列の追加または索引構成表の使用 ..........................................................................................
異なる索引タイプの使用 ..........................................................................................................................
B ツリー索引 .......................................................................................................................................
ビットマップ索引 ..............................................................................................................................
ファンクション索引 ..........................................................................................................................
パーティション索引 ..........................................................................................................................
逆キー索引 ..........................................................................................................................................
索引のコストの算出 ..................................................................................................................................
索引内のシリアライズ ..............................................................................................................................
索引内の列の順序付け ..............................................................................................................................
ビューの使用 ......................................................................................................................................................
2-11
2-11
2-11
2-11
2-12
2-12
2-12
2-12
2-12
2-12
2-13
SQL の実行効率 ................................................................................................................................................. 2-13
アプリケーションの実装 .................................................................................................................................. 2-14
アプリケーション開発の傾向 .......................................................................................................................... 2-16
ワークロードのテスト、モデル化および実装 ...................................................................................................... 2-17
データのサイズ設定 .......................................................................................................................................... 2-17
ワークロードの見積り ...................................................................................................................................... 2-17
類似システムからの推定 .......................................................................................................................... 2-17
ベンチマーク .............................................................................................................................................. 2-18
アプリケーションのモデル化 .......................................................................................................................... 2-18
設計のテスト、デバッグおよび検証 .............................................................................................................. 2-18
ii
新規アプリケーションの配置 .................................................................................................................................. 2-20
ロールアウトの方法 .......................................................................................................................................... 2-20
パフォーマンス・チェックリスト .................................................................................................................. 2-20
3
パフォーマンス改善方法
Oracle のパフォーマンス改善方法 ........................................................................................................................... 3-2
Oracle のパフォーマンス改善方法の手順 ....................................................................................................... 3-3
パフォーマンスを概念的にモデル化する際の意思決定プロセスの例 ........................................................ 3-4
Oracle システムにおける誤りの上位 10 項目 ................................................................................................. 3-5
パフォーマンスの緊急の問題に対処する方法 ........................................................................................................ 3-7
パフォーマンスの緊急の問題に対処する方法の手順 .................................................................................... 3-7
第 III 部 インスタンスのパフォーマンスの最適化
4
パフォーマンスを考慮したデータベースの構成
初期インスタンス構成のパフォーマンスの考慮事項 ............................................................................................ 4-2
初期化パラメータ ................................................................................................................................................ 4-2
UNDO 領域の構成 .............................................................................................................................................. 4-3
REDO ログ・ファイルのサイズ指定 ............................................................................................................... 4-4
追加表領域の作成 ................................................................................................................................................ 4-4
永続的な表領域の作成 : 自動セグメント領域管理 .................................................................................
一時表領域の作成 ........................................................................................................................................
適切なパフォーマンスを得る表の作成とメンテナンス ........................................................................................
表圧縮 ....................................................................................................................................................................
4-5
4-5
4-6
4-6
圧縮係数の見積り ........................................................................................................................................ 4-6
チューニングによる圧縮率向上 ................................................................................................................ 4-6
未使用領域の解放 ................................................................................................................................................ 4-7
データの索引付け ................................................................................................................................................ 4-7
ソート用データのメモリーの指定 ............................................................................................................ 4-7
共有サーバーのパフォーマンスの考慮事項 ............................................................................................................ 4-8
ディスパッチャ固有のビューを使用する競合の識別 .................................................................................... 4-8
ディスパッチャ・プロセスの競合の低減 ................................................................................................ 4-9
共有サーバー・プロセスの競合の識別 .......................................................................................................... 4-10
5
自動パフォーマンス統計
データ収集の概要 ........................................................................................................................................................ 5-2
データベース統計 ................................................................................................................................................ 5-3
待機イベント ................................................................................................................................................
時間モデル統計 ............................................................................................................................................
Active Session History（ASH）.................................................................................................................
システム統計とセッション統計 ................................................................................................................
オペレーティング・システム統計 ....................................................................................................................
5-3
5-3
5-4
5-4
5-5
CPU 統計 ......................................................................................................................................................
仮想メモリー統計 ........................................................................................................................................
ディスク統計 ................................................................................................................................................
ネットワーク統計 ........................................................................................................................................
オペレーティング・システムのデータ収集ツール ................................................................................
5-5
5-5
5-6
5-6
5-6
iii
統計の解釈 ............................................................................................................................................................ 5-6
自動ワークロード・リポジトリの概要 .................................................................................................................... 5-8
スナップショット ................................................................................................................................................ 5-8
ベースライン ........................................................................................................................................................ 5-9
領域使用量 ............................................................................................................................................................ 5-9
自動ワークロード・リポジトリの管理 .................................................................................................................. 5-10
スナップショットの管理 .................................................................................................................................. 5-10
スナップショットの作成 ..........................................................................................................................
スナップショットの削除 ..........................................................................................................................
スナップショット設定の変更 ..................................................................................................................
ベースラインの管理 ..........................................................................................................................................
5-10
5-11
5-11
5-12
ベースラインの作成 .................................................................................................................................. 5-12
ベースラインの削除 .................................................................................................................................. 5-12
自動ワークロード・リポジトリ・データの転送 .......................................................................................... 5-13
AWR データの抽出 ................................................................................................................................... 5-13
AWR データのロード ............................................................................................................................... 5-14
自動ワークロード・リポジトリ・ビューの使用 .......................................................................................... 5-15
自動ワークロード・リポジトリ・レポートの生成 ...................................................................................... 5-16
awrrpt.sql レポートの実行 .......................................................................................................................
awrrpti.sql レポートの実行 ......................................................................................................................
awrsqrpt.sql レポートの実行 ...................................................................................................................
awrsqrpi.sql レポートの実行 ...................................................................................................................
awrddrpt.sql レポートの実行 ..................................................................................................................
awrddrpi.sql レポートの実行 ..................................................................................................................
Active Session History レポートの生成 .........................................................................................................
5-16
5-17
5-17
5-18
5-18
5-19
5-20
ashrpt.sql レポートの実行 ........................................................................................................................ 5-20
ashrpti.sql レポートの実行 ...................................................................................................................... 5-21
6
自動パフォーマンス診断
Automatic Database Diagnostic Monitor の概要 ................................................................................................. 6-2
Automatic Database Diagnostic Monitor .............................................................................................................. 6-3
ADDM の分析結果 .............................................................................................................................................. 6-4
ADDM の例 .......................................................................................................................................................... 6-4
ADDM の設定 ...................................................................................................................................................... 6-5
ADDM を使用したデータベース・パフォーマンスの問題の診断 .............................................................. 6-6
addmrpt.sql を使用した ADDM の実行 .................................................................................................. 6-6
DBMS_ADVISOR API を使用した ADDM の実行 ................................................................................ 6-7
ADDM 情報を表示するビュー .......................................................................................................................... 6-9
7
メモリーの構成と使用方法
メモリー割当ての問題について ................................................................................................................................ 7-2
Oracle メモリー・キャッシュ ........................................................................................................................... 7-2
自動共有メモリー管理 ........................................................................................................................................ 7-2
キャッシュ・サイズの動的な変更 .................................................................................................................... 7-3
動的サイズ変更操作に関する情報の表示 ................................................................................................ 7-4
アプリケーションの考慮事項 ............................................................................................................................ 7-4
iv
オペレーティング・システムのメモリー使用量 ............................................................................................ 7-5
ページングの削減 ........................................................................................................................................
主メモリーへの SGA の格納 .....................................................................................................................
個々のユーザーへの十分なメモリーの割当て ........................................................................................
構成の繰返し ........................................................................................................................................................
7-5
7-5
7-5
7-6
バッファ・キャッシュの構成と使用方法 ................................................................................................................ 7-6
バッファ・キャッシュの効果的な使用 ............................................................................................................ 7-6
バッファ・キャッシュのサイズ設定 ................................................................................................................ 7-6
バッファ・キャッシュ・アドバイザの統計 ............................................................................................
V$DB_CACHE_ADVICE の使用 ..............................................................................................................
バッファ・キャッシュ・ヒット率の計算 ................................................................................................
バッファ・キャッシュ・アドバイザ統計の解釈および使用方法 ................................................................
7-6
7-6
7-8
7-9
バッファ・キャッシュに割り当てられたメモリーの増加 .................................................................. 7-10
バッファ・キャッシュに割り当てられたメモリーの削減 .................................................................. 7-10
複数バッファ・プールについて ...................................................................................................................... 7-11
大きいセグメントへのランダム・アクセス ..........................................................................................
Oracle Real Application Cluster のインスタンス ................................................................................
複数バッファ・プールの使用方法 ..........................................................................................................
V$DB_CACHE_ADVICE 内のバッファ・プール・データ ........................................................................
7-11
7-11
7-12
7-12
バッファ・プール・ヒット率 .......................................................................................................................... 7-12
プール内に多くのバッファを持つセグメントの判断 .................................................................................. 7-13
KEEP プール ....................................................................................................................................................... 7-14
RECYCLE プール .............................................................................................................................................. 7-15
共有プールとラージ・プールの構成および使用方法 .......................................................................................... 7-15
共有プールの概念 .............................................................................................................................................. 7-16
ディクショナリ・キャッシュの概念 ......................................................................................................
ライブラリ・キャッシュの概念 ..............................................................................................................
SQL 共有基準 .............................................................................................................................................
共有プールの効果的な使用方法 ......................................................................................................................
7-16
7-16
7-17
7-18
共有カーソル ..............................................................................................................................................
単一のユーザーのログインおよび修飾表の参照 ..................................................................................
PL/SQL の使用方法 ..................................................................................................................................
DDL の実行の回避 ....................................................................................................................................
キャッシュ順序番号 ..................................................................................................................................
カーソルのアクセスおよび管理 ..............................................................................................................
OCI による解析コールの低減 .........................................................................................................
Oracle プリコンパイラによる解析コールの低減 .........................................................................
SQLJ による解析コールの低減 ........................................................................................................
JDBC による解析コールの低減 .......................................................................................................
Oracle Forms による解析コールの低減 .........................................................................................
共有プールのサイズ設定 ..................................................................................................................................
7-18
7-19
7-19
7-19
7-20
7-20
7-20
7-20
7-21
7-21
7-21
7-21
共有プール : ライブラリ・キャッシュの統計 .......................................................................................
V$LIBRARYCACHE .................................................................................................................................
共有プールのアドバイザ統計 ..................................................................................................................
V$SHARED_POOL_ADVICE .........................................................................................................
V$LIBRARY_CACHE_MEMORY ..................................................................................................
V$JAVA_POOL_ADVICE および V$JAVA_LIBRARY_CACHE_MEMORY ..........................
共有プール : ディクショナリ・キャッシュの統計 ...............................................................................
7-21
7-22
7-23
7-23
7-23
7-23
7-24
v
共有プール統計の解釈 ...................................................................................................................................... 7-25
メモリー割当ての増加 ..............................................................................................................................
ライブラリ・キャッシュへの追加のメモリー割当て ..................................................................
データ・ディクショナリ・キャッシュへの追加のメモリーの割当て ......................................
メモリー割当ての減少 ..............................................................................................................................
ラージ・プールの使用 ......................................................................................................................................
7-25
7-25
7-25
7-26
7-26
共有サーバー・アーキテクチャでのラージ・プールと共有プールのチューニング ......................
共有サーバーの UGA 記憶域のための効果的な設定の判別 .......................................................
V$SESSTAT ビューでのシステム統計のチェック .......................................................................
PRIVATE_SGA の設定による各ユーザー・セッションのメモリー使用量の制限 .................
3 層の接続でのメモリー使用の低減 ...............................................................................................
CURSOR_SPACE_FOR_TIME の使用 ............................................................................................................
7-26
7-27
7-27
7-28
7-28
7-29
セッション・カーソルのキャッシュ .............................................................................................................. 7-29
予約プールの構成 .............................................................................................................................................. 7-30
SHARED_POOL_RESERVED_SIZE の使用 ..........................................................................................
SHARED_POOL_RESERVED_SIZE が小さすぎる場合 ......................................................................
SHARED_POOL_RESERVED_SIZE が大きすぎる場合 ......................................................................
SHARED_POOL_SIZE が小さすぎる場合 .............................................................................................
除去防止のためのラージ・オブジェクトの保存 ..........................................................................................
7-30
7-31
7-31
7-31
7-31
既存のアプリケーション用の CURSOR_SHARING .................................................................................... 7-32
類似 SQL 文 ................................................................................................................................................
CURSOR_SHARING .................................................................................................................................
CURSOR_SHARING を使用する場合 ....................................................................................................
接続の維持 ..........................................................................................................................................................
7-32
7-32
7-33
7-33
REDO ログ・バッファの構成および使用 ............................................................................................................. 7-34
ログ・バッファのサイズ設定 .......................................................................................................................... 7-35
ログ・バッファの統計 ...................................................................................................................................... 7-35
PGA メモリー管理 .................................................................................................................................................... 7-35
自動 PGA メモリーの構成 ............................................................................................................................... 7-37
PGA_AGGREGATE_TARGET の初期設定 ...........................................................................................
自動 PGA メモリー管理のパフォーマンスの監視 ...............................................................................
V$PGASTAT ......................................................................................................................................
V$PROCESS .......................................................................................................................................
V$PROCESS_MEMORY ...................................................................................................................
V$SQL_WORKAREA_HISTOGRAM ............................................................................................
V$SQL_WORKAREA_ACTIVE ......................................................................................................
V$SQL_WORKAREA .......................................................................................................................
PGA_AGGREGATE_TARGET のチューニング ...................................................................................
V$PGA_TARGET_ADVICE .............................................................................................................
PGA_AGGREGATE_TARGET のチューニング方法 ...................................................................
V$PGA_TARGET_ADVICE_HISTOGRAM ..................................................................................
V$SYSSTAT および V$SESSTAT .............................................................................................................
OLAP_PAGE_POOL_SIZE の構成 .................................................................................................................
vi
7-37
7-38
7-38
7-40
7-40
7-40
7-42
7-42
7-44
7-44
7-46
7-47
7-48
7-48
8
I/O 構成および設計
I/O の理解 ..................................................................................................................................................................... 8-2
I/O の基本構成 ............................................................................................................................................................. 8-2
オペレーティング・システムまたはハードウェアのストライプ化を使用したファイルのレイアウト ... 8-2
要求された I/O サイズ ...............................................................................................................................
I/O リクエストの同時実行性 ....................................................................................................................
物理ストライプ境界とブロック・サイズ境界との位置合せ ................................................................
提案されたシステムの管理可能性 ............................................................................................................
手動による I/O の分散 .......................................................................................................................................
8-3
8-3
8-4
8-4
8-5
ファイルを分割する場合 .................................................................................................................................... 8-5
表、索引および TEMP 表領域 ...................................................................................................................
REDO ログ・ファイル ...............................................................................................................................
アーカイブ REDO ログ ..............................................................................................................................
3 つの構成サンプル .............................................................................................................................................
8-6
8-6
8-6
8-7
すべてのディスクにまたがったすべての内容のストライプ化 ............................................................
異なるディスクへのアーカイブ・ログの移動 ........................................................................................
個別のディスクへの REDO ログの移動 ..................................................................................................
Oracle Managed Files .........................................................................................................................................
8-7
8-7
8-8
8-8
Oracle Managed Files のチューニング .................................................................................................... 8-8
データ・ブロック・サイズの選択 .................................................................................................................... 8-9
読込み ............................................................................................................................................................ 8-9
書込み ............................................................................................................................................................ 8-9
ブロック・サイズの長所と短所 .............................................................................................................. 8-10
9
オペレーティング・システム・リソース
オペレーティング・システムのパフォーマンスの問題の理解 ............................................................................ 9-2
オペレーティング・システムのキャッシュの使用 ........................................................................................ 9-2
非同期 I/O .................................................................................................................................................... 9-3
FILESYSTEMIO_OPTIONS 初期化パラメータ ...................................................................................... 9-3
メモリー使用量 .................................................................................................................................................... 9-3
バッファ・キャッシュの制限 .................................................................................................................... 9-3
メモリー使用量に影響を与えるパラメータ ............................................................................................ 9-3
オペレーティング・システムのリソース・マネージャの使用 .................................................................... 9-4
オペレーティング・システムの問題の解決 ............................................................................................................ 9-5
UNIX ベースのシステムのパフォーマンスに関するヒント ........................................................................ 9-5
Windows システムのパフォーマンスに関するヒント ................................................................................. 9-5
HP OpenVMS システムのパフォーマンスに関するヒント ......................................................................... 9-5
CPU について .............................................................................................................................................................. 9-6
システムの CPU 使用率の調査 ................................................................................................................................. 9-8
メモリー管理のチェック .................................................................................................................................... 9-9
ページングとスワッピング ........................................................................................................................ 9-9
大きすぎるページ表 .................................................................................................................................... 9-9
I/O 管理のチェック ............................................................................................................................................ 9-9
ネットワーク管理のチェック ............................................................................................................................ 9-9
プロセス管理のチェック .................................................................................................................................... 9-9
スケジューリングとスイッチング ............................................................................................................ 9-9
コンテキストのスイッチング .................................................................................................................... 9-9
ポスト・ウェイト・ドライバ ............................................................................................................ 9-9
vii
メモリーマップ済システム・タイマー .......................................................................................... 9-10
1 回のコールで複数の非同期 I/O を発行するリスト I/O インタフェース ............................. 9-10
オペレーティング・システムの新規プロセスの開始 .......................................................................... 9-10
10
パフォーマンス・ビューを使用したインスタンスのチューニング
インスタンスのチューニング手順 .......................................................................................................................... 10-2
問題の定義 .......................................................................................................................................................... 10-2
ホスト・システムの検査 .................................................................................................................................. 10-3
CPU の使用率 .............................................................................................................................................
Oracle 以外のプロセス .....................................................................................................................
Oracle プロセス .................................................................................................................................
Oracle CPU 統計 ................................................................................................................................
CPU 統計の解釈 .................................................................................................................................
I/O の問題の検出 ......................................................................................................................................
ネットワーク ..............................................................................................................................................
Oracle 統計の調査 .............................................................................................................................................
10-3
10-3
10-3
10-4
10-4
10-4
10-5
10-5
統計収集のレベルの設定 ..........................................................................................................................
V$STATISTICS_LEVEL ....................................................................................................................
待機イベント ..............................................................................................................................................
待機イベント統計を含む動的パフォーマンス・ビュー ......................................................................
システム統計 ..............................................................................................................................................
V$ACTIVE_SESSION_HISTORY ....................................................................................................
V$SYSSTAT ........................................................................................................................................
V$FILESTAT .......................................................................................................................................
V$ROLLSTAT ....................................................................................................................................
V$ENQUEUE_STAT .........................................................................................................................
V$LATCH ...........................................................................................................................................
セグメント・レベルの統計 ......................................................................................................................
変更の実装および測定 ......................................................................................................................................
10-5
10-6
10-6
10-6
10-7
10-8
10-8
10-8
10-8
10-8
10-8
10-8
10-9
Oracle 統計の解釈 ..................................................................................................................................................... 10-9
負荷の検査 .......................................................................................................................................................... 10-9
負荷の変更 .................................................................................................................................................. 10-9
高いアクティビティ率 ............................................................................................................................ 10-10
待機イベント統計を使用したボトルネックへのドリルダウン ................................................................ 10-10
待機イベントおよび潜在的な原因の表 ........................................................................................................ 10-12
追加された統計情報 ........................................................................................................................................ 10-13
viii
REDO ログ領域要求統計 ........................................................................................................................
読取り一貫性 ............................................................................................................................................
継続行による表フェッチ ........................................................................................................................
解析関連の統計 ........................................................................................................................................
待機イベント統計 ....................................................................................................................................................
SQL*Net イベント ...........................................................................................................................................
10-13
10-13
10-14
10-14
10-15
10-16
SQL*Net message from client ................................................................................................................
ネットワーク・ボトルネック ........................................................................................................
クライアント・プロセス上のリソース・ボトルネック ............................................................
SQL*Net message from dblink ..............................................................................................................
SQL*Net more data to client ..................................................................................................................
10-16
10-16
10-17
10-17
10-17
buffer busy waits ............................................................................................................................................. 10-18
原因 ............................................................................................................................................................
処置 ............................................................................................................................................................
セグメント・ヘッダー ....................................................................................................................
データ・ブロック ............................................................................................................................
UNDO ヘッダー ..............................................................................................................................
undo block ........................................................................................................................................
db file scattered read .......................................................................................................................................
10-18
10-18
10-18
10-19
10-19
10-19
10-19
処置 ............................................................................................................................................................
過剰な I/O の管理 ...................................................................................................................................
不十分な I/O 分散 ...................................................................................................................................
I/O を待機しているセッションで実行された SQL 文の検索 ..........................................................
I/O を必要とするオブジェクトの検索 ................................................................................................
db file sequential read ....................................................................................................................................
10-19
10-19
10-20
10-20
10-20
10-21
処置 ............................................................................................................................................................ 10-21
direct path read および direct path read temp ........................................................................................... 10-22
原因 ............................................................................................................................................................
処置 ............................................................................................................................................................
ディスクでのソート ........................................................................................................................
全表スキャン ....................................................................................................................................
ハッシュ領域サイズ ........................................................................................................................
direct path write および direct path write temp .........................................................................................
10-22
10-22
10-22
10-22
10-22
10-23
原因 ............................................................................................................................................................ 10-23
処置 ............................................................................................................................................................ 10-23
enqueue（enq:）待機 ..................................................................................................................................... 10-23
ロックおよびロック・ホルダーの検索 ................................................................................................
処置 ............................................................................................................................................................
ST エンキュー ..................................................................................................................................
HW エンキュー ...............................................................................................................................
TM エンキュー ................................................................................................................................
TX エンキュー ..................................................................................................................................
events in wait class other ...............................................................................................................................
free buffer waits ...............................................................................................................................................
10-24
10-24
10-24
10-24
10-24
10-25
10-25
10-26
原因 ............................................................................................................................................................
処置 ............................................................................................................................................................
書込み ................................................................................................................................................
キャッシュが小さすぎる場合 ........................................................................................................
キャッシュが 1 つの DBWR に対して大きすぎる場合 .............................................................
複数のデータベース・ライター（DBWR）
・プロセスまたは I/O スレーブの検討 ....................
DB_WRITER_PROCESSES ............................................................................................................
DBWR_IO_SLAVES ........................................................................................................................
複数の DBWR プロセスと I/O スレーブの選択 .........................................................................
ラッチ・イベント ............................................................................................................................................
10-26
10-26
10-26
10-26
10-26
10-26
10-26
10-27
10-27
10-28
処置 ............................................................................................................................................................
例 : 現在待機されているラッチの検索 .................................................................................................
共有プールとライブラリ・キャッシュ・ラッチの競合 ....................................................................
非共有 SQL .......................................................................................................................................
再解析された共有可能な SQL .......................................................................................................
セッション別 ....................................................................................................................................
キャッシュ・バッファ LRU 連鎖 .................................................................................................
10-28
10-28
10-29
10-29
10-30
10-30
10-31
ix
キャッシュ・バッファ連鎖 ............................................................................................................
行キャッシュ・オブジェクト ........................................................................................................
log file parallel write .......................................................................................................................................
library cache pin ..............................................................................................................................................
library cache lock .............................................................................................................................................
log buffer space ................................................................................................................................................
log file switch ...................................................................................................................................................
10-31
10-31
10-31
10-32
10-32
10-32
10-32
処置 ............................................................................................................................................................ 10-32
log file sync ....................................................................................................................................................... 10-33
rdbms ipc reply ................................................................................................................................................ 10-33
アイドル待機イベント ............................................................................................................................................ 10-34
第 IV 部　SQL
文の最適化
部　11
SQL チューニングの概要
SQL チューニングの概要 ......................................................................................................................................... 11-2
チューニングの目的 .................................................................................................................................................. 11-2
ワークロードの削減 .......................................................................................................................................... 11-2
ワークロードの均衡化 ...................................................................................................................................... 11-2
ワークロードのパラレル化 .............................................................................................................................. 11-2
高負荷 SQL の識別 .................................................................................................................................................... 11-3
多くのリソースを消費する SQL の識別 ........................................................................................................ 11-3
特定のプログラムのチューニング .......................................................................................................... 11-3
アプリケーションのチューニング / 負荷の軽減 .................................................................................. 11-3
識別した SQL に関するデータの収集 ............................................................................................................ 11-4
チューニング中に収集する情報 ..............................................................................................................
自動 SQL チューニング機能 ....................................................................................................................................
効率的な SQL 文の開発 ............................................................................................................................................
オプティマイザ統計の確認 ..............................................................................................................................
11-4
11-5
11-6
11-6
実行計画の検討 .................................................................................................................................................. 11-6
SQL 文の再構成 ................................................................................................................................................. 11-7
AND と = を使用した条件の組立て ....................................................................................................... 11-7
WHERE 句での変換列の回避 .................................................................................................................. 11-7
特定のタスクに対する専用の SQL 文の作成 ........................................................................................ 11-8
副問合せに対する EXISTS と IN の使用 ................................................................................................ 11-9
例 1: IN の使用 : 副問合せ内の選択的フィルタ .......................................................................... 11-10
例 2: EXISTS の使用 : 親の中の選択的述語 .................................................................................. 11-11
ヒントによるアクセス・パスおよび結合順序の制御 ................................................................................ 11-12
ビューを管理するときの注意 ................................................................................................................
複合ビューを結合するときの注意 ................................................................................................
ビューの再利用禁止 ........................................................................................................................
副問合せのネストを解除するときの注意 ....................................................................................
ビューへの外部結合を実行するときの注意 ................................................................................
中間結果の格納 ........................................................................................................................................
索引の再構成 ....................................................................................................................................................
11-13
11-13
11-14
11-14
11-14
11-15
11-15
トリガーおよび制約の変更または無効化 .................................................................................................... 11-15
データの再構成 ................................................................................................................................................ 11-15
実行計画の長期的な保持 ................................................................................................................................ 11-16
x
データへのアクセスを最小限に削減 ............................................................................................................ 11-16
CASE 文による複数のスキャンの結合 ................................................................................................ 11-16
RETURNING 句を持つ DML の使用 ................................................................................................... 11-17
1 つの文での必要なすべてのデータの変更 ......................................................................................... 11-17
12
自動 SQL チューニング
自動 SQL チューニングの概要 ............................................................................................................................... 12-2
問合せオプティマイザのモード ...................................................................................................................... 12-2
標準モード .................................................................................................................................................. 12-2
チューニング・モード .............................................................................................................................. 12-2
チューニング分析のタイプ .............................................................................................................................. 12-3
統計分析 ......................................................................................................................................................
SQL プロファイリング .............................................................................................................................
アクセス・パス分析 ..................................................................................................................................
SQL 構造分析 .............................................................................................................................................
SQL チューニング・アドバイザ ............................................................................................................................
入力ソース ..........................................................................................................................................................
12-3
12-3
12-4
12-4
12-5
12-5
チューニング・オプション .............................................................................................................................. 12-6
アドバイザ出力 .................................................................................................................................................. 12-6
SQL チューニング・アドバイザ API の使用方法 ........................................................................................ 12-6
SQL チューニング・タスクの作成 .........................................................................................................
SQL チューニング・タスクの実行 .........................................................................................................
SQL チューニング・タスクのステータスのチェック .........................................................................
SQL チューニング・アドバイザの進捗のチェック .............................................................................
SQL チューニング・タスクの結果の表示 .............................................................................................
SQL チューニング・タスクに関するその他の操作 .............................................................................
SQL チューニング・セット ....................................................................................................................................
SQL チューニング・セットの作成 ...............................................................................................................
12-7
12-8
12-8
12-8
12-9
12-9
12-9
12-11
SQL チューニング・セットのロード ........................................................................................................... 12-11
SQL チューニング・セットの内容の表示 ................................................................................................... 12-11
SQL チューニング・セットの変更 ............................................................................................................... 12-12
SQL チューニング・セットの転送 ............................................................................................................... 12-12
SQL チューニング・セットの削除 ............................................................................................................... 12-13
SQL チューニング・セットに対するその他の操作 ................................................................................... 12-13
SQL プロファイル ................................................................................................................................................... 12-13
SQL プロファイルの受入れ ........................................................................................................................... 12-14
SQL プロファイルの変更 ............................................................................................................................... 12-14
SQL プロファイルの削除 ............................................................................................................................... 12-15
SQL チューニング情報ビュー .............................................................................................................................. 12-15
13
問合せオプティマイザ
オプティマイザ操作 .................................................................................................................................................. 13-2
オプティマイザの目標の選択 .................................................................................................................................. 13-3
OPTIMIZER_MODE 初期化パラメータ ........................................................................................................ 13-4
問合せオプティマイザの目標変更に対するオプティマイザ SQL のヒント ............................................ 13-4
データ・ディクショナリ内の問合せオプティマイザ統計 .......................................................................... 13-5
xi
問合せオプティマイザ機能の有効化および制御 .................................................................................................. 13-5
問合せオプティマイザ機能の有効化 .............................................................................................................. 13-5
問合せオプティマイザの動作の制御 .............................................................................................................. 13-6
問合せオプティマイザについて .............................................................................................................................. 13-7
問合せオプティマイザの構成要素 .................................................................................................................. 13-8
問合せの変換 .............................................................................................................................................. 13-8
ビューのマージ .................................................................................................................................. 13-8
述語のプッシュ .................................................................................................................................. 13-9
副問合せのネスト解除 ...................................................................................................................... 13-9
マテリアライズド・ビューを使用したクエリー・リライト ...................................................... 13-9
ユーザー定義のバインド変数の照合 ...................................................................................................... 13-9
見積り .......................................................................................................................................................... 13-9
選択性 ................................................................................................................................................ 13-10
カーディナリティ ............................................................................................................................ 13-10
コスト ................................................................................................................................................ 13-10
計画の生成 ................................................................................................................................................ 13-11
実行計画の読み方と理解 ................................................................................................................................ 13-11
EXPLAIN PLAN の概要 .........................................................................................................................
実行計画のステップ ................................................................................................................................
問合せオプティマイザのアクセス・パスについて ............................................................................................
全表スキャン ....................................................................................................................................................
13-11
13-13
13-14
13-14
大量データにアクセスする場合に全表スキャンの方が高速になる理由 ........................................
オプティマイザが全表スキャンを使用する場合 ................................................................................
索引の欠落 ........................................................................................................................................
大量のデータ ....................................................................................................................................
小さい表 ............................................................................................................................................
高い並列度 ........................................................................................................................................
全表スキャンのヒント ............................................................................................................................
パラレル問合せの実行 ............................................................................................................................
ROWID スキャン .............................................................................................................................................
13-14
13-14
13-14
13-15
13-15
13-15
13-15
13-15
13-16
オプティマイザが ROWID を使用する場合 ........................................................................................ 13-16
索引スキャン .................................................................................................................................................... 13-16
ブロックの I/O（行ではなく）の想定 ................................................................................................
索引一意スキャン ....................................................................................................................................
オプティマイザが索引一意スキャンを使用する場合 ................................................................
索引一意スキャンのヒント ............................................................................................................
索引レンジ・スキャン ............................................................................................................................
オプティマイザが索引レンジ・スキャンを使用する場合 ........................................................
索引レンジ・スキャンのヒント ....................................................................................................
索引レンジ・スキャン降順 ....................................................................................................................
オプティマイザが索引レンジ・スキャン降順を使用する場合 ................................................
索引レンジ・スキャン降順のヒント ............................................................................................
索引スキップ・スキャン ........................................................................................................................
全体スキャン ............................................................................................................................................
高速全索引スキャン ................................................................................................................................
高速全索引スキャンのヒント ........................................................................................................
索引結合 ....................................................................................................................................................
索引結合のヒント ............................................................................................................................
ビットマップ索引 ....................................................................................................................................
xii
13-17
13-17
13-17
13-18
13-18
13-18
13-18
13-19
13-19
13-19
13-19
13-20
13-20
13-20
13-20
13-20
13-20
クラスタ・アクセス ........................................................................................................................................ 13-21
ハッシュ・アクセス ........................................................................................................................................ 13-21
サンプル表スキャン ........................................................................................................................................ 13-21
問合せオプティマイザによるアクセス・パスの選択方法 ........................................................................ 13-21
結合について ............................................................................................................................................................ 13-22
問合せオプティマイザによる結合文の実行方法 ........................................................................................ 13-22
問合せオプティマイザによる結合の実行計画の選択方法 ........................................................................ 13-23
ネステッド・ループ結合 ................................................................................................................................ 13-24
ネステッド・ループ結合 ........................................................................................................................
外部ループ ........................................................................................................................................
内部ループ ........................................................................................................................................
オプティマイザがネステッド・ループ結合を使用する場合 ............................................................
ネステッド・ループ結合のヒント ........................................................................................................
ネステッド・ループのネスト ................................................................................................................
ハッシュ結合 ....................................................................................................................................................
13-24
13-24
13-24
13-25
13-25
13-25
13-25
オプティマイザがハッシュ結合を使用する場合 ................................................................................ 13-25
ハッシュ結合のヒント ............................................................................................................................ 13-26
ソート / マージ結合 ....................................................................................................................................... 13-26
オプティマイザがソート / マージ結合を使用する場合 ................................................................... 13-26
ソート / マージ結合のヒント ............................................................................................................... 13-27
デカルト結合 .................................................................................................................................................... 13-27
オプティマイザがデカルト結合を使用する場合 ................................................................................ 13-27
デカルト結合のヒント ............................................................................................................................ 13-27
外部結合 ............................................................................................................................................................ 13-27
ネステッド・ループ外部結合 ................................................................................................................
ハッシュ結合外部結合 ............................................................................................................................
ソート / マージ外部結合 .......................................................................................................................
完全外部結合 ............................................................................................................................................
14
13-27
13-28
13-29
13-29
オプティマイザ統計の管理
統計について .............................................................................................................................................................. 14-2
自動統計収集 .............................................................................................................................................................. 14-3
GATHER_STATS_JOB ...................................................................................................................................... 14-3
自動統計収集を使用可能にする方法 .............................................................................................................. 14-3
統計収集時の考慮事項 ...................................................................................................................................... 14-4
手動統計を使用する場合 ..........................................................................................................................
前のバージョンの統計のリストア ..........................................................................................................
統計のロック ..............................................................................................................................................
手動統計収集 ..............................................................................................................................................................
DBMS_STATS プロシージャによる統計の収集 ...........................................................................................
14-4
14-5
14-5
14-5
14-5
サンプリングを使用した統計収集 ..........................................................................................................
パラレル統計収集 ......................................................................................................................................
パーティション・オブジェクトの統計 ..................................................................................................
列統計情報とヒストグラム ......................................................................................................................
失効している統計の判別 ..........................................................................................................................
ユーザー定義統計 ......................................................................................................................................
統計を収集する時期 ..........................................................................................................................................
14-6
14-6
14-7
14-7
14-7
14-7
14-8
xiii
システム統計 .............................................................................................................................................................. 14-8
作業負荷統計 ...................................................................................................................................................... 14-9
作業負荷統計の収集 ................................................................................................................................ 14-10
マルチブロック読込みカウント ............................................................................................................ 14-10
非作業負荷統計 ................................................................................................................................................ 14-10
非作業負荷統計の収集 ............................................................................................................................ 14-11
統計の管理 ................................................................................................................................................................ 14-11
前のバージョンの統計のリストア ................................................................................................................ 14-11
統計のエクスポートとインポート ................................................................................................................ 14-12
統計のリストアとインポートまたはエクスポートの相違点 .................................................................... 14-13
表統計またはスキーマ統計のロック ............................................................................................................ 14-13
統計の設定 ........................................................................................................................................................ 14-13
動的サンプリングを使用した統計の見積り ................................................................................................ 14-13
動的サンプリングの動作 ........................................................................................................................
動的サンプリング使用のタイミング ....................................................................................................
動的サンプリングを使用したパフォーマンスの改善方法 ................................................................
動的サンプリング・レベル ....................................................................................................................
統計の欠落の処理 ............................................................................................................................................
14-14
14-14
14-14
14-14
14-15
統計の参照 ................................................................................................................................................................ 14-16
表、索引および列の統計 ................................................................................................................................ 14-16
ヒストグラムの表示 ........................................................................................................................................ 14-16
高さ調整済ヒストグラム ........................................................................................................................ 14-16
頻度ヒストグラム .................................................................................................................................... 14-18
15
索引およびクラスタの使用方法
索引パフォーマンスについて .................................................................................................................................. 15-2
論理構造のチューニング .................................................................................................................................. 15-2
SQL アクセス・アドバイザを使用した索引のチューニング ..................................................................... 15-3
索引を付ける列と式の選択 .............................................................................................................................. 15-3
コンポジット索引の選択 .................................................................................................................................. 15-4
コンポジット索引のキーの選択 .............................................................................................................. 15-4
コンポジット索引のキーの順序付け ...................................................................................................... 15-4
索引を使用する文の記述 .................................................................................................................................. 15-5
索引を使用しない文の記述 .............................................................................................................................. 15-5
索引の再作成 ...................................................................................................................................................... 15-5
索引の縮小 .......................................................................................................................................................... 15-6
一意でない索引による一意性の規定 .............................................................................................................. 15-6
ENABLE NOVALIDATE 制約の使用方法 .................................................................................................... 15-6
パフォーマンスを考慮したファンクション索引の使用方法 .............................................................................. 15-7
パフォーマンスを考慮したパーティション索引の使用方法 .............................................................................. 15-8
パフォーマンスを考慮した索引構成表の使用方法 .............................................................................................. 15-8
パフォーマンスを考慮したビットマップ索引の使用方法 .................................................................................. 15-9
パフォーマンスを考慮したビットマップ結合索引の使用方法 .......................................................................... 15-9
パフォーマンスを考慮したドメイン索引の使用方法 .......................................................................................... 15-9
パフォーマンスを考慮したクラスタの使用方法 ................................................................................................ 15-10
パフォーマンスを考慮したハッシュ・クラスタの使用方法 ............................................................................ 15-11
xiv
16
オプティマイザ・ヒントの使用方法
オプティマイザ・ヒントの理解 .............................................................................................................................. 16-2
ヒントの型 .......................................................................................................................................................... 16-2
カテゴリ別のヒント .......................................................................................................................................... 16-2
最適化アプローチと目標のヒント ..........................................................................................................
アクセス・パスに関するヒント ..............................................................................................................
問合せの変換に関するヒント ..................................................................................................................
結合順序のヒント ......................................................................................................................................
結合操作のヒント ......................................................................................................................................
パラレル実行のヒント ..............................................................................................................................
その他のヒント ..........................................................................................................................................
ヒントの指定方法 ......................................................................................................................................................
ヒント全セットの指定方法 ..............................................................................................................................
16-3
16-3
16-4
16-4
16-4
16-5
16-5
16-6
16-6
ヒントにおける問合せブロックの指定方法 .................................................................................................. 16-7
グローバル表のヒントの指定方法 .................................................................................................................. 16-8
複合索引ヒントの指定方法 .............................................................................................................................. 16-9
ビューでのヒントの使用方法 ................................................................................................................................ 16-10
ヒントおよび複合ビュー ................................................................................................................................ 16-10
ヒントとマージ可能ビュー ............................................................................................................................ 16-10
ヒントとマージ不可能ビュー ........................................................................................................................ 16-11
17
SQL アクセス・アドバイザ
DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要 ............................................................ 17-2
SQL アクセス・アドバイザの使用方法の概要 ............................................................................................. 17-3
SQL アクセス・アドバイザ・リポジトリ ............................................................................................. 17-5
SQL アクセス・アドバイザの使用方法 ................................................................................................................ 17-6
SQL アクセス・アドバイザの使用手順 ......................................................................................................... 17-6
SQL アクセス・アドバイザの使用に必要な権限 ......................................................................................... 17-7
タスクとテンプレートの設定 .......................................................................................................................... 17-7
タスクの作成 ..............................................................................................................................................
テンプレートの使用方法 ..........................................................................................................................
テンプレートの作成 ..................................................................................................................................
ワークロードの管理 ..........................................................................................................................................
17-7
17-8
17-8
17-9
ワークロード・オブジェクト ..................................................................................................................
ワークロードの使用 ..................................................................................................................................
タスクとワークロードのリンク ............................................................................................................
ワークロードの内容の定義 ....................................................................................................................
SQL チューニング・セット ...........................................................................................................
ユーザー定義のワークロードのロード ........................................................................................
SQL キャッシュのワークロードのロード ...................................................................................
仮想ワークロードの使用方法 ........................................................................................................
Oracle Database 9i サマリー・アドバイザのワークロードの使用方法 ..................................
SQL アクセス・アドバイザのワークロードのパラメータ .......................................................
ワークロードへの SQL 文の追加 ..........................................................................................................
ワークロードの SQL 文の削除 ..............................................................................................................
ワークロードの SQL 文の変更 ..............................................................................................................
17-9
17-9
17-10
17-10
17-11
17-11
17-12
17-13
17-14
17-14
17-15
17-15
17-16
xv
ワークロードのメンテナンス ................................................................................................................
ワークロード属性の設定 ................................................................................................................
ワークロードのリセット ................................................................................................................
ワークロードとタスク間のリンクの削除 ....................................................................................
ワークロードの削除 ................................................................................................................................
推奨事項の処理 ................................................................................................................................................
17-16
17-16
17-17
17-17
17-17
17-17
推奨オプション ........................................................................................................................................
評価モード ................................................................................................................................................
推奨事項の生成 ........................................................................................................................................
EXECUTE_TASK プロシージャ ....................................................................................................
推奨事項の表示 ........................................................................................................................................
SQL ワークロードのジャーナル ...........................................................................................................
推奨プロセスの停止 ................................................................................................................................
タスクへの割込み ............................................................................................................................
タスクの取消 ....................................................................................................................................
推奨事項のマーキング ............................................................................................................................
推奨事項の変更 ........................................................................................................................................
SQL スクリプトの生成 ...........................................................................................................................
推奨事項が必要なくなった場合 ............................................................................................................
クイック・チューニングの実行 ....................................................................................................................
17-18
17-19
17-19
17-19
17-19
17-23
17-23
17-23
17-24
17-24
17-24
17-25
17-26
17-27
タスクの管理 .................................................................................................................................................... 17-27
タスク属性の更新 ....................................................................................................................................
タスクの削除 ............................................................................................................................................
DAYS_TO_EXPIRE パラメータの設定 ................................................................................................
SQL アクセス・アドバイザの定数の使用方法 ...........................................................................................
17-27
17-28
17-28
17-28
SQL アクセス・アドバイザの使用例 ........................................................................................................... 17-29
18
ユーザー定義のワークロードの推奨事項 ............................................................................................
タスク・テンプレートを使用した推奨事項の生成 ............................................................................
SQL キャッシュからのワークロードのフィルタリング ...................................................................
索引およびマテリアライズド・ビューの現在の使用状況の評価 ....................................................
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング ................
DBMS_ADVISOR.TUNE_MVIEW プロシージャ ......................................................................................
17-29
17-31
17-32
17-33
17-34
17-35
TUNE_MVIEW の構文と操作 ...............................................................................................................
TUNE_MVIEW の出力結果へのアクセス ...........................................................................................
USER_TUNE_MVIEW ビューおよび DBA_TUNE_MVIEW ビュー ......................................
DBMS_ADVISOR 関数およびプロシージャによるスクリプトの生成 ...................................
最適化されたサブマテリアライズド・ビューによる高速リフレッシュの有効化 ........................
17-35
17-36
17-36
17-36
17-41
プラン・スタビリティの使用方法
実行計画を保持するためのプラン・スタビリティの使用 .................................................................................. 18-2
プラン・スタビリティでのヒントの使用 ...................................................................................................... 18-2
アウトラインでのヒントの使用方法 ...................................................................................................... 18-3
アウトラインの格納 .......................................................................................................................................... 18-3
プラン・スタビリティを使用可能にする方法 .............................................................................................. 18-3
提供されるパッケージを使用したストアド・アウトラインの管理 .......................................................... 18-3
アウトラインの作成 .......................................................................................................................................... 18-4
ストアド・アウトラインにカテゴリ名を使用する方法 ...................................................................... 18-5
ストアド・アウトラインの使用 ...................................................................................................................... 18-5
xvi
アウトライン・データの照会 .......................................................................................................................... 18-6
アウトライン表の移動 ...................................................................................................................................... 18-7
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用 .............................................. 18-8
RBO から問合せオプティマイザへの移行 .................................................................................................... 18-8
問合せオプティマイザを使用している場合の新規 Oracle リリースへの移行 ........................................ 18-9
テスト・システムでのアップグレード ................................................................................................ 18-10
19
EXPLAIN PLAN の使用方法
EXPLAIN PLAN について ...................................................................................................................................... 19-2
実行計画の変化理由 .......................................................................................................................................... 19-2
スキーマの相違 .......................................................................................................................................... 19-2
コストの相違 .............................................................................................................................................. 19-2
排除行数の最少化 .............................................................................................................................................. 19-3
実行計画以外の考慮事項 .................................................................................................................................. 19-3
V$SQL_PLAN ビューの使用 ................................................................................................................... 19-3
EXPLAIN PLAN の制限事項 ........................................................................................................................... 19-4
PLAN_TABLE 出力表 .............................................................................................................................................. 19-4
EXPLAIN PLAN の実行 .......................................................................................................................................... 19-5
EXPLAIN PLAN での文の指定 ....................................................................................................................... 19-5
EXPLAIN PLAN での別の表の指定 ............................................................................................................... 19-5
PLAN_TABLE 出力の表示 ...................................................................................................................................... 19-6
PLAN_TABLE 出力のカスタマイズ ............................................................................................................... 19-6
EXPLAIN PLAN 出力の読み方 .............................................................................................................................. 19-7
EXPLAIN PLAN によるパラレル実行の表示 ...................................................................................................... 19-8
EXPLAIN PLAN によるパラレル問合せの表示 ........................................................................................... 19-9
EXPLAIN PLAN によるビットマップ索引の表示 ............................................................................................ 19-10
EXPLAIN PLAN によるパーティション・オブジェクトの表示 .................................................................... 19-10
EXPLAIN PLAN によるレンジ・パーティション化およびハッシュ・パーティション化の
表示の例 ............................................................................................................................................................ 19-11
ハッシュ・パーティション化の計画 .................................................................................................... 19-12
コンポジット・パーティション・オブジェクトでのプルーニング情報の例 ........................................ 19-12
パーシャル・パーティション・ワイズ結合の例 ........................................................................................ 19-14
フル・パーティション・ワイズ結合の例 .................................................................................................... 19-16
INLIST ITERATOR および EXPLAIN PLAN の例 .................................................................................... 19-16
IN リスト列が索引列である場合 ..........................................................................................................
IN リスト列が索引でありパーティション列である場合 ..................................................................
IN リスト列がパーティション列である場合 ......................................................................................
ドメイン索引および EXPLAIN PLAN の例 ................................................................................................
19-17
19-17
19-17
19-18
PLAN_TABLE 列 .................................................................................................................................................... 19-18
20
アプリケーション・トレース・ツールの使用方法
End to End Application Tracing ............................................................................................................................ 20-2
エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化 .......................................... 20-3
クライアント識別子に対する統計収集 .................................................................................................. 20-3
サービス、モジュールおよびアクションに対する統計収集 .............................................................. 20-3
End to End Application Tracing の収集した統計の表示 ............................................................................ 20-4
xvii
エンド・トゥ・エンド・トレースにおける有効化および無効化 .............................................................. 20-4
クライアント識別子のトレース ..............................................................................................................
サービス、モジュールおよびアクションのトレース ..........................................................................
セッションのトレース ..............................................................................................................................
インスタンス全体またはデータベース全体のトレース ......................................................................
エンド・トゥ・エンド・トレースにおける使用可能なトレースの表示 ..................................................
20-4
20-5
20-5
20-6
20-6
trcsess ユーティリティの使用方法 ......................................................................................................................... 20-7
trcsess の構文 ..................................................................................................................................................... 20-7
trcsess の出力例 ................................................................................................................................................. 20-8
SQL トレースと TKPROF について ...................................................................................................................... 20-8
SQL トレース機能について ............................................................................................................................. 20-8
TKPROF について ............................................................................................................................................. 20-9
SQL トレース機能と TKPROF の使用方法 ........................................................................................................ 20-10
手順 1: トレース・ファイル管理用の初期化パラメータの設定 ............................................................... 20-10
手順 2: SQL トレース機能を使用可能にする方法 ...................................................................................... 20-12
手順 3: TKPROF によるトレース・ファイルのフォーマット .................................................................. 20-13
TKPROF の出力例 ...................................................................................................................................
TKPROF の構文 .......................................................................................................................................
TKPROF 文の例 .......................................................................................................................................
TKPROF の例 1 ................................................................................................................................
TKPROF の例 2 ................................................................................................................................
手順 4: TKPROF 出力の解釈 ..........................................................................................................................
20-13
20-14
20-16
20-16
20-16
20-17
TKPROF の表形式の統計 .......................................................................................................................
行ソースの操作 ........................................................................................................................................
待機イベント情報 ....................................................................................................................................
統計の精度の解釈 ....................................................................................................................................
再帰的コールについて ............................................................................................................................
TKPROF のライブラリ・キャッシュ・ミス .......................................................................................
SQL トレースでの文の切捨て ...............................................................................................................
TKPROF での SQL 文を発行するユーザーの識別 ..............................................................................
TKPROF の実行計画 ...............................................................................................................................
チューニングする文の決定 ....................................................................................................................
手順 5: SQL トレース機能統計の格納 ..........................................................................................................
20-17
20-18
20-19
20-19
20-19
20-19
20-20
20-20
20-20
20-20
20-21
TKPROF による出力 SQL スクリプトの生成 ......................................................................................
TKPROF による出力 SQL スクリプトの編集 ......................................................................................
出力表の問合せ ........................................................................................................................................
TKPROF の解釈における誤りの回避 ..................................................................................................................
引数トラップの回避 ........................................................................................................................................
20-21
20-21
20-22
20-23
20-23
読取り一貫性トラップの回避 ........................................................................................................................ 20-24
スキーマ・トラップの回避 ............................................................................................................................ 20-24
タイム・トラップの回避 ................................................................................................................................ 20-25
トリガー・トラップの回避 ............................................................................................................................ 20-26
TKPROF の出力例 .................................................................................................................................................. 20-26
TKPROF ヘッダーのサンプル ....................................................................................................................... 20-26
TKPROF 本体のサンプル ............................................................................................................................... 20-26
TKPROF サマリーのサンプル ....................................................................................................................... 20-28
xviii
第 V 部　Real
Application Testing
部　データベース・リプレイ
21
データベース・リプレイの概要 .............................................................................................................................. 21-2
ワークロードの取得 .......................................................................................................................................... 21-3
ワークロードの前処理 ...................................................................................................................................... 21-3
ワークロードのリプレイ .................................................................................................................................. 21-3
分析およびレポート作成 .................................................................................................................................. 21-4
データベース・ワークロードの取得 ...................................................................................................................... 21-4
ワークロードの取得の有効化と無効化 .......................................................................................................... 21-4
データベース・ワークロードの取得の前提条件 .......................................................................................... 21-5
ワークロードの取得オプション ...................................................................................................................... 21-6
データベースの再起動 ..............................................................................................................................
ワークロード・フィルタの定義 ..............................................................................................................
取得ディレクトリの設定 ..........................................................................................................................
ワークロードの取得の制限 ..............................................................................................................................
21-6
21-7
21-7
21-7
Enterprise Manager を使用したデータベース・ワークロードの取得 ..................................................... 21-8
Enterprise Manager を使用したワークロードの取得の監視 ................................................................... 21-10
アクティブなワークロードの取得の監視 ............................................................................................
アクティブなワークロードの取得の停止 ............................................................................................
完了したワークロードの取得の管理 ....................................................................................................
API を使用したデータベース・ワークロードの取得 ................................................................................
21-10
21-11
21-12
21-13
ワークロード・フィルタの追加と削除 ................................................................................................
ワークロードの取得の開始 ....................................................................................................................
ワークロードの取得の停止 ....................................................................................................................
ワークロードの取得に関する AWR データのエクスポート ............................................................
ビューを使用したワークロードの取得の監視 ............................................................................................
21-13
21-14
21-14
21-15
21-15
ワークロードの取得の分析 .................................................................................................................................... 21-15
Enterprise Manager を使用したワークロードの取得レポートの生成 ................................................... 21-15
API を使用したワークロードの取得レポートの生成 ................................................................................ 21-16
ワークロードの取得レポートの使用 ............................................................................................................ 21-17
SQL パフォーマンス・アナライザ
22
SQL パフォーマンス・アナライザの概要 ............................................................................................................ 22-2
SQL ワークロードの取得 ........................................................................................................................................ 22-3
用語集
索引
xix
xx
はじめに
この章には、次の項目が含まれます。
■
対象読者
■
ドキュメントのアクセシビリティについて
■
関連ドキュメント
■
表記規則
■
サポートおよびサービス
xxi
対象読者
『Oracle Database パフォーマンス・チューニング・ガイド』は、Oracle Database の運用、メン
テナンスおよびパフォーマンスの担当者を対象としています。このマニュアルでは、パフォー
マンス・ツールを使用して、SQL を適切に作成およびチューニングし、インスタンスのパ
フォーマンスを最適化して、Oracle データベースのパフォーマンスを向上させる方法を詳しく
説明します。また、優れたパフォーマンスを実現するための初期データベースの作成方法を説
明するとともに、パフォーマンス関連の参照情報を示します。データベース管理者、アプリ
ケーション設計者およびプログラマに役立つガイドです。
Oracle Enterprise Manager を使用して Oracle Database のパフォーマンスをチューニングする
方法の詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照して
ください。
ドキュメントのアクセシビリティについて
オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメ
ントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、
ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML 形式
のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマーク
アップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべて
のお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術
的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle
Accessibility Program の Web サイト http://www.oracle.com/accessibility/ を参照し
てください。
ドキュメント内のサンプル・コードのアクセシビリティについて
スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合がありま
す。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかし JAWS は括弧だ
けの行を読まない場合があります。
外部 Web サイトのドキュメントのアクセシビリティについて
このドキュメントにはオラクル社およびその関連会社が所有または管理しない Web サイトへの
リンクが含まれている場合があります。オラクル社およびその関連会社は、それらの Web サイ
トのアクセシビリティに関しての評価や言及は行っておりません。
Oracle サポート・サービスへの TTY アクセス
アメリカ国内では、Oracle サポート・サービスへ 24 時間年中無休でテキスト電話（TTY）アク
セスが提供されています。TTY サポートについては、(800)446-2398 にお電話ください。アメリ
カ国外からの場合は、+1-407-458-2479 にお電話ください。
xxii
関連ドキュメント
このマニュアルを読む前に、
『Oracle Database 概要』、
『Oracle Database 2 日でデータベース管
理者』
、『Oracle Database アドバンスト・アプリケーション開発者ガイド』および『Oracle
Database 管理者ガイド』をお読みください。
Oracle Enterprise Manager を使用して Oracle Database のパフォーマンスをチューニングする
方法の詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照して
ください。
データ・ウェアハウス環境をチューニングする方法の詳細は、
『Oracle Database データ・ウェ
アハウス・ガイド』を参照してください。
このマニュアルに記載されている例の多くは、Oracle Database のインストール時に基本インス
トール・オプションを選択した場合、デフォルトでインストールされるサンプル・スキーマを
使用しています。これらのスキーマがどのように作成されているか、およびその使用方法につ
いては、
『Oracle Database サンプル・スキーマ』を参照してください。
Oracle エラー・メッセージの詳細は、『Oracle Database エラー・メッセージ』を参照してくだ
さい。Oracle Database エラー・メッセージのマニュアルは、HTML 版のみご利用いただけま
す。Oracle マニュアル CD のエラー・メッセージ・マニュアルにアクセスする場合、範囲ごと
にエラー・メッセージを参照できます。範囲を検索した後、ブラウザの検索機能を使用して
メッセージを検索します。インターネットに接続している場合は、Oracle オンライン・マニュ
アルのエラー・メッセージ検索機能を使用して、特定のエラー・メッセージを検索できます。
表記規則
このマニュアルでは、次の表記規則を使用しています。
規則
意味
太字
太字は、アクションに関連するグラフィカル・ユーザー・インタフェース
要素、または本文や用語集で定義されている用語を示します。
イタリック
イタリックは、特定の値を指定するプレースホルダ変数を示します。
固定幅フォント
固定幅フォントは、段落内のコマンド、URL、サンプル・コード、画面上
に表示されるテキストまたはユーザーが入力するテキストを示します。
xxiii
サポートおよびサービス
次の各項に、各サービスに接続するための URL を記載します。
Oracle サポート・サービス
オラクル製品サポートの購入方法、および Oracle サポート・サービスへの連絡方法の詳細は、
次の URL を参照してください。
http://www.oracle.co.jp/support/
製品マニュアル
製品のマニュアルは、次の URL にあります。
http://otn.oracle.co.jp/document/
研修およびトレーニング
研修に関する情報とスケジュールは、次の URL で入手できます。
http://www.oracle.co.jp/education/
その他の情報
オラクル製品やサービスに関するその他の情報については、次の URL から参照してください。
http://www.oracle.co.jp
http://otn.oracle.co.jp
注意 : ドキュメント内に記載されている URL や参照ドキュメントには、
Oracle Corporation が提供する英語の情報も含まれています。日本語版の情
報については、前述の URL を参照してください。
xxiv
Oracle のパフォーマンスの新機能
この項では、Oracle Database 10g リリース 2（10.2）のパフォーマンスに関連した新機能につ
いて説明するとともに、追加情報の掲載場所も記載しています。この項で説明する機能と拡張
機能は、データベースのパフォーマンスを最適化することを目標としています。
Oracle Database 10g リリース 2（10.2）のすべての新機能のサマリーは、『Oracle Database 新機
能ガイド』を参照してください。Oracle Enterprise Manager を使用して Oracle Database のパ
フォーマンスをチューニングする方法の詳細は、
『Oracle Database 2 日でパフォーマンス・
チューニング・ガイド』を参照してください。
Oracle Database 10g リリース 2（10.2）におけるパフォーマンスに関連した新機能および機能
更新は次のとおりです。
■
Active Session History レポート
Active Session History（ASH）レポートには、指定された期間の、ブロッカ ID および待
機中 ID とその関連トランザクション識別子、ならびに SQL の識別に使用された ASH 情報
が含まれています。5-20 ページの「Active Session History レポートの生成」を参照してく
ださい。
■
自動 PGA メモリー管理
新しいビューが追加され、各 Oracle プロセスの PGA メモリー使用量を動的に監視します。
V$PROCESS_MEMORY ビューの詳細は、7-38 ページの「自動 PGA メモリー管理のパフォー
マンスの監視」を参照してください。
■
自動共有メモリー管理
自動共有メモリー管理により、自己チューニング・アルゴリズムを介したシステム・グ
ローバル領域（SGA）メモリー関連パラメータの構成作業が簡素化されます。自動共有メ
モリー管理は拡張され、ストリーム・プールは自動 SGA 管理の一部として自動的にチュー
ニングされます。7-2 ページの「自動共有メモリー管理」を参照してください。
■
マルチブロック読込みカウントの自動チューニング
DB_FILE_MULTIBLOCK_READ_COUNT 初期化パラメータは、このパラメータが明示的に設
定されていない場合は、デフォルト値を使用して自動的にチューニングされるようになり
ました。DB_FILE_MULTIBLOCK_READ_COUNT パラメータの詳細は、13-6 ページの「問
合せオプティマイザの動作の制御」を参照してください。
■
自動ワークロード・リポジトリ・レポート
自動ワークロード・リポジトリ（AWR）レポートには、スナップショット ID の有効範囲
の統計が表示されます。2 つの新しいレポート awrsqrpt.sql および awrsqrpi.sql が
追加され、特定の SQL 文の統計が表示されます。5-16 ページの「自動ワークロード・リポ
ジトリ・レポートの生成」を参照してください。
xxv
■
構成可能な自動ワークロード・リポジトリ SQL 収集
自動ワークロード・リポジトリ（AWR）は、問題の検出および自己チューニングを目的と
して、システムに最大の負荷を与える SQL 文を含めたパフォーマンス統計を収集、処理お
よび保守します。この機能は拡張され、各 SQL 基準（経過時間、CPU 時間、解析コール、
共有可能メモリー、バージョン・カウント）に対してフラッシュする上位 SQL の数を構成
できるようになりました。5-8 ページの「自動ワークロード・リポジトリの概要」を参照し
てください。
■
データベース・リプレイ
本番システム上でデータベース・ワークロードを取得し、それをテスト・システム上でリ
プレイして、データベース更新などのシステム変更で望ましい結果が得られることを確認
できます。詳細は、第 21 章「データベース・リプレイ」を参照してください。
注意 : 現在、このリリースでサポートされているのは、ワークロードの取得
のみです。Oracle Database 11g リリース 1（11.1）以降のリリースでは、取得
されたワークロードを前処理してリプレイできます。
■
拡張された End to End Application Tracing
End to End Application Tracing は、高負荷 SQL 文などの過剰なワークロードのソースを
識別します。この機能は拡張され、セッション、インスタンス全体、または全データベー
ス・レベルでの SQL トレースが可能になりました。20-2 ページの「End to End
Application Tracing」を参照してください。
■
システム統計の向上
V$SYSSTAT ビューには、すべての Oracle プロセスで実行される物理 I/O の合計数を取得
するための行が追加されました。10-9 ページの「負荷の検査」を参照してください。さら
に、新しいイベントが追加され、
「その他」待機クラスのイベントで統計を保守するための
メモリー使用量を削減できるようになりました。10-25 ページの「events in wait class
other」を参照してください。
■
SQL アクセス・アドバイザ
SQL アクセス・アドバイザおよび関連する DBMS_ADVISOR パッケージでは、機能ベース
の索引が推奨され、推奨プロセスは割込みできるようになりました。また、Oracle
Enterprise Manager の複数の機能も改善されました。第 17 章「SQL アクセス・アドバイ
ザ」を参照してください。
■
SQL パフォーマンス・アナライザ
SQL パフォーマンス・アナライザを使用すると、テスト・システム上で SQL ワークロード
を使用してシステム変更をテストし、これらの変更が SQL パフォーマンスに及ぼす影響を
予測できます。詳細は、第 22 章「SQL パフォーマンス・アナライザ」を参照してくださ
い。
注意 : 現在、このリリースでサポートされているのは、SQL ワークロード
の取得のみです。Oracle Database 11g リリース 1（11.1）以降のリリースで
は、取得した SQL ワークロードを実行し、そのパフォーマンスを測定して比
較できます。
■
SQL プロファイル
また、DBMS_SQLTUNE パッケージは、リテラルのテキスト値をバインド変数に正規化する
ことで、SQL プロファイルを共有し、リテラル値でのみ異なるテキストを持つ SQL を許可
する機能も提供します。12-14 ページの「SQL プロファイルの受入れ」を参照してくださ
い。
xxvi
■
SQL チューニング・アドバイザ
新しい V$ADVISOR_PROGRESS ビューを使用して、SQL チューニング・アドバイザの実行
の進捗を監視できるようになりました。12-8 ページの「SQL チューニング・アドバイザの
進捗のチェック」を参照してください。
■
SQL チューニング・セット
DBMS_SQLTUNE パッケージ・プロシージャを使用して、SQL チューニング・セットを他の
システムにエクスポートしたり、他のシステムからインポートできます。12-12 ページの
「SQL チューニング・セットの転送」を参照してください。
■
V$SQLSTATS ビュー
新しいビュー V$SQLSTATS は、SQL カーソルのパフォーマンス統計を戻します。
V$SQLSTATS には、V$SQL および V$SQLAREA に表示される列のサブセットが含まれま
す。ただし、V$SQLSTATS ビューは、より高速でスケーラブルであり、データ保存期間が
より長いという点で V$SQL および V$SQLAREA とは異なります。SQL カーソルの統計を
フェッチする場合、V$SQL のかわりに V$SQLSTATS を使用することをお薦めします。
関連項目 : V$SQLSTATS の詳細は、
『Oracle Database リファレンス』を
参照してください。
xxvii
xxviii
第I部
パフォーマンス・チューニング
第 I 部では、パフォーマンス・チューニングの概要を説明します。
第 I 部には次の章が含まれます。
■
第 1 章「パフォーマンス・チューニングの概要」
1
パフォーマンス・チューニングの概要
この章では、パフォーマンス・チューニングの概要を説明します。この章には、次の項があり
ます。
■
パフォーマンス・チューニングの概要
■
パフォーマンス・チューニング機能およびツールの概要
パフォーマンス・チューニングの概要
1-1
パフォーマンス・チューニングの概要
パフォーマンス・チューニングの概要
このガイドは、Oracle Database システムのパフォーマンス・チューニングに関する情報を提供
します。この項には次の項目があります。
■
パフォーマンス計画
■
インスタンスのチューニング
■
SQL チューニング
パフォーマンス計画
このガイドのインスタンスまたは SQL のチューニングの項に進む前に、必ず第 II 部「パフォー
マンス計画」に目を通しておいてください。オラクル社では、長年にわたる設計およびパ
フォーマンス経験に基づき、パフォーマンスに関する方法論を設計しました。この項では、シ
ステム・パフォーマンスを大幅に向上させる明瞭で簡単なアクティビティについて説明します。
次の項目について説明しています。
■
投資の選択肢について
■
拡張性について
■
システム・アーキテクチャ
■
アプリケーション設計の原則
■
ワークロードのテスト、モデル化および実装
■
新規アプリケーションの配置
インスタンスのチューニング
このガイドの第 III 部「インスタンスのパフォーマンスの最適化」では、Oracle データベース・
インスタンスのチューニングおよび最適化に関連する要因について説明します。
インスタンスのチューニングを検討している場合、パフォーマンス上の問題を引き起こす可能
性のあるボトルネックを回避するため、データベース・システムの初期設計には注意する必要
があります。さらに、次の点も考慮する必要があります。
■
データベース構造体へのメモリーの割当て
■
データベースの様々な部分の I/O 要件の判断
■
データベースのパフォーマンスを最適化するためのオペレーティング・システムのチュー
ニング
データベース・インスタンスをインストールおよび構成した後、パフォーマンス関連の問題を
チェックするために動作しているデータベースを監視する必要があります。
パフォーマンスの原理
パフォーマンス・チューニングでは、システムの初期構成に対して異なる（ただし関連性があ
る）方法を必要とします。システムの構成では、初期システムの構成が機能的なものになるよ
うに整理された手順に従ってリソースを割り当てます。
チューニングを開始するには、最も影響のあるボトルネックを識別し、適切な変更を行ってそ
のボトルネックの影響を低減するかまたは排除します。チューニングは通常、システムが本番
開始以前か、または稼働状態になった後で事後的に行われます。
ベースライン
最も効率的なチューニングの方法は、パフォーマンスの問題が生じた場合に比較に使用できる
パフォーマンス・ベースラインを確立することです。データベース管理者（DBA）の多くは、
自分のシステムを熟知し、ピークの使用期間を簡単に識別できます。たとえば、ピーク期間は
10.00am ～ 12.00pm である場合、また 1.30pm ～ 3.00pm である場合もあります。これには、深
夜の 12.00am から 6.00am までのバッチ・ウィンドウが含まれることがあります。
1-2
Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンス・チューニングの概要
サイトでこのようなピーク時間帯を識別し、このような高負荷の時間帯のパフォーマンス・
データを収集するモニタリング・ツールをインストールすることが重要です。アプリケーショ
ンが QA サイクル中の初期のトライアル段階にある時点から、データ収集を構成することが最
適です。それ以外の場合は、システムが最初に稼働したときに、このデータ収集を構成する必
要があります。
収集されたベースライン・データには、次の内容が含まれていることが理想的です。
■
アプリケーション統計（トランザクション・ボリューム、応答時間）
■
データベース統計
■
オペレーティング・システム統計
■
ディスク I/O 統計
■
ネットワーク統計
自動ワークロード・リポジトリでは、ベースラインは将来比較するために保持されるスナップ
ショットの範囲により識別されます。5-8 ページの「自動ワークロード・リポジトリの概要」を
参照してください。
症状および問題点
パフォーマンス・チューニングの一般的な誤りは、ある問題の症状を現実の問題自体であると
思い違いをすることです。多くのパフォーマンス統計はこの症状を示すこと、およびこの症状
を識別することが修正を実施するために十分なデータではないことを認識することが重要です。
たとえば、次のような場合があります。
■
低速な物理 I/O
一般に、この原因はディスクの構成が適切ではないことにあります。しかし、チューニン
グが適切ではない SQL から発行された、これらのディスク上の大量の不要な物理 I/O が原
因になっている可能性もあります。
■
ラッチの競合
インスタンスを再構成して、ラッチの競合をチューニングできることはほとんどありませ
ん。むしろ、ラッチの競合は通常、アプリケーションの変更により解決されます。
■
過剰な CPU 使用率
過剰な CPU 使用率は通常、システム上にアイドル状態の CPU がほとんどないことを意味
します。この原因として、システムのサイズ設定が不適切であること、SQL 文がチューニ
ングされていないこと、またはアプリケーション・プログラムが不十分である可能性があ
ります。
チューニングの時期
チューニングには次の 2 種類があります。
■
プロアクティブな監視
■
ボトルネックの解消
プロアクティブな監視 プロアクティブな監視は通常、定期的にスケジュールされた間隔で行わ
れます。この場合、システム動作とリソースの使用量が変化したかどうかを識別するために多
数のパフォーマンス統計が調べられます。プロアクティブな監視は、プロアクティブなチュー
ニングとも考えられます。
通常は、進行中の重大な問題が監視により明らかにならないかぎり、監視によりシステムの構
成が変化することはありません。状況によっては、経験豊富なパフォーマンス・エンジニアが
統計のみで潜在的な問題点を識別できますが、通常はパフォーマンスの低下を伴います。
明らかなパフォーマンスの低下がないときに、事前のアクションとしてシステムを試行したり
微調整することは危険なアクティビティであり、不必要にパフォーマンスを低下させる可能性
があります。システムを微調整することは事後チューニングと考えられ、事後チューニングの
手順に従う必要があります。
パフォーマンス・チューニングの概要
1-3
パフォーマンス・チューニングの概要
監視は通常、より大規模な容量計画の調査の一環です。容量計画ではリソース使用状況を調べ
て、さらにアプリケーションが使用されている方法の変化、およびアプリケーションがデータ
ベース・リソースとホスト・リソースを使用している方法の変化を調べます。
ボトルネックの解消 チューニングは通常、パフォーマンスの問題の修正を意味します。ただ
し、チューニングは、分析、設計、コーディング、本番およびメンテナンスの各段階を通じて、
アプリケーションのライフサイクルの一部である必要があります。多くの場合、チューニング
段階はシステムが本番に入るまで残されます。このとき、チューニングは事後対応処理になり
ます。この場合、最も重要なボトルネックが識別され、修正されます。
チューニングの目的は通常、リソース使用量を減らしたり、操作を完了する経過時間を減らす
ことにあります。いずれの場合も、目標は特定のリソースの有効利用を向上することにありま
す。一般に、パフォーマンスの問題は特定のリソースの過剰使用によって発生します。そのリ
ソースは、システム内のボトルネックとなります。ボトルネックと潜在的な修正を識別するに
は、様々な多くの段階があります。それらについては次の項で説明します。
競合の様々な形態は症状であり、次のいずれかを変更することで修正できることに注意してく
ださい。
■
アプリケーションまたはアプリケーションの使用方法の変更
■
Oracle の変更
■
ホスト・ハードウェア構成の変更
多くの場合、ボトルネックを解決する最も効果的な方法は、アプリケーションを変更すること
です。
SQL チューニング
このガイドの第 IV 部「SQL 文の最適化」では、SQL 文のチューニングおよび最適化のプロセ
スについて説明します。
多くのクライアント / サーバー・アプリケーションのプログラマが SQL をメッセージ言語とみ
なすのは、問合せが発行され、データが戻されるためです。しかし、クライアント・ツールで
は非効率的な SQL 文が生成される場合がよくあります。したがって、データベース SQL 処理
エンジンについて理解することは、最適な SQL を作成するために必要です。このことは特に、
大量トランザクション処理システムについて言えます。
一般に、OLTP アプリケーションから発行される SQL 文では、一度にわずかな行しか実行され
ません。必要な行を索引で正確に指示できれば、最短のパスを経由してこれらの行に効率よく
アクセスする正確な計画を作成できます。意思決定支援システム（DSS）環境では、表の行の
ほとんどにアクセスする場合が多いため、選択性は重要視されません。そのような状況では、
全表スキャンが一般的であり、索引は使用しません。このマニュアルは、主として、OLTP タ
イプのアプリケーションを中心に説明しています。DSS 環境、および DSS と OLTP の混合環境
の詳細は、
『Oracle Database データ・ウェアハウス・ガイド』を参照してください。
問合せオプティマイザおよび実行計画
SQL 文が Oracle データベースで実行される場合、Oracle 問合せオプティマイザでは、問合せ
で指定した参照オブジェクトおよび条件に関連した多くの要素が考慮され、最も効率のよい実
行計画が判断されます。この判断は、SQL 文の処理で重要なステップであり、実行時間が大き
く変化します。
評価プロセスでは、問合せオプティマイザにより、システム上に収集された統計が確認され、
最適なデータ・アクセス・パスおよびその他の考慮事項が判断されます。問合せオプティマイ
ザの実行計画を、SQL 文に挿入されたヒントで上書きできます。
1-4
Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンス・チューニング機能およびツールの概要
パフォーマンス・チューニング機能およびツールの概要
効果的なデータの収集と解析は、パフォーマンスの問題を識別して修正するために不可欠です。
Oracle では、パフォーマンス・エンジニアがデータベースのパフォーマンスに関する情報を収
集できるようにする多数のツールを提供しています。Oracle では、データ収集の他に、パ
フォーマンスの監視、問題の診断およびアプリケーションのチューニングのためのツールも提
供しています。
Oracle の収集および監視機能は大部分が自動的なもので、Oracle バックグラウンド・プロセス
により管理されます。自動統計収集機能と自動パフォーマンス機能を使用可能にするには、
STATISTICS_LEVEL 初期化パラメータを TYPICAL または ALL に設定する必要があります。
収集ツールおよびチューニング・ツールからの出力の管理および表示には、Oracle Enterprise
Manager、または API とビューを使用します。使いやすさと様々な自動化された監視および診
断ツールの利点から、Oracle Enterprise Manager Database Control をお薦めします。
関連項目 :
■
■
■
■
Oracle Enterprise Manager を使用して Oracle Database を管理する方
法の詳細は、
『Oracle Database 2 日でデータベース管理者』を参照し
てください。
Oracle Enterprise Manager を使用して Oracle Database のパフォーマ
ンスをチューニングする方法の詳細は、
『Oracle Database 2 日でパ
フォーマンス・チューニング・ガイド』を参照してください。
DBMS_ADVISOR、DBMS_SQLTUNE および DBMS_WORKLOAD_
REPOSITORY パッケージの詳細は、
『Oracle Database PL/SQL パッ
ケージ・プロシージャおよびタイプ・リファレンス』を参照してくだ
さい。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
自動パフォーマンス・チューニング機能
Oracle には、次の自動パフォーマンス・チューニング機能があります。
■
■
■
■
■
■
■
自動ワークロード・リポジトリ（AWR）では、問題の検出および自己チューニングを目的
として、パフォーマンス統計が収集、処理および保守されます。5-8 ページの「自動ワーク
ロード・リポジトリの概要」を参照してください。
Automatic Database Diagnostic Monitor（ADDM）では、Oracle データベースにおいて考
えられるパフォーマンス上の問題について、AWR によって収集された情報が分析されま
す。6-3 ページの「Automatic Database Diagnostic Monitor」を参照してください。
SQL チューニング・アドバイザでは、SQL 文を変更しないで SQL 文を素早く効率的に最適
化することが可能です。12-5 ページの「SQL チューニング・アドバイザ」を参照してくだ
さい。
SQL アクセス・アドバイザでは、マテリアライズド・ビュー、索引およびマテリアライズ
ド・ビュー・ログについてアドバイスが提供されます。SQL アクセス・アドバイザの詳細
は、11-5 ページの「自動 SQL チューニング機能」および 17-2 ページの「DBMS_
ADVISOR パッケージの SQL アクセス・アドバイザの概要」を参照してください。
End to End Application Tracing では、特定のユーザー、サービスまたはアプリケーショ
ン・コンポーネントに関して、システム上の過剰なワークロードが識別されます。20-2
ページの「End to End Application Tracing」を参照してください。
障害となっている問題が検出されると、サーバー生成アラートにより自動的に通知が提供
されます。サーバー生成アラートを使用したデータベース操作の監視の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
Oracle Enterprise Manager からその他のアドバイザを起動できます。たとえば、メモ
リー・アドバイザは、インスタンスのメモリーを最適化します。通常、メモリー・アドバ
イザが使用されるのは、データベースの自動メモリー管理が設定されていない場合です。
その他のアドバイザは、平均リカバリ時間（MTTR）の最適化、セグメントの縮小および
パフォーマンス・チューニングの概要
1-5
パフォーマンス・チューニング機能およびツールの概要
UNDO 表領域の設定に使用されます。Oracle Enterprise Manager で使用可能なアドバイザ
の使用方法の詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』
を参照してください。
■
Oracle Enterprise Manager の「データベース・パフォーマンス」ページには、リアルタイ
ム監視および診断に関するホスト、インスタンス・サービス名およびスループット情報が
表示されます。このページは、選択した間隔で自動的に、または手動でリフレッシュする
ように設定できます。「データベース・パフォーマンス」ページの詳細は、『Oracle
Database 2 日でパフォーマンス・チューニング・ガイド』を参照してください。
その他の Oracle ツール
この項では、パフォーマンスの問題の判断に使用できるその他の Oracle ツールについて説明し
ます。
V$ パフォーマンス・ビュー
V$ ビューは、すべての Oracle パフォーマンス・チューニング・ツールで使用されるパフォー
マンス情報ソースです。V$ ビューは、インスタンスの起動時に初期化されたメモリー構造に基
づいています。メモリー構造および構造を表すビューは、インスタンスが存続する間、Oracle
により自動的にメンテナンスされます。V$ パフォーマンス・ビューを使用して問題を診断し
チューニングする方法は、第 10 章「パフォーマンス・ビューを使用したインスタンスのチュー
ニング」を参照してください。
関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リ
ファレンス』を参照してください。
注意 : パフォーマンス・データの収集には自動ワークロード・リポジト
リを使用することをお薦めします。これらのツールは、パフォーマンスの
分析に必要なすべてのデータを収集するように設計されています。
1-6
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-1 ワークロード成長曲線
アプリケーションは非常に短期間での開発が要求され、テストや評価の時間も限定されていま
す。しかし、一般的に、不適切な設計は、将来、システムの再構築や再実装を招くことになり
ます。アーキテクチャや実装に制限があることがわかっているアプリケーションをインター
ネット上に配置し、ワークロードが需要予測を超えている場合は、将来、確実に障害が発生し
ます。ビジネスの観点からは、低いパフォーマンスは顧客を失うことにつながります。Web
ユーザーの場合、7 秒以内に応答がないと、ユーザーの興味は二度と喚起できません。
多くの場合、新規の実装に移行するためにシステムを停止する間のコストも含めて、システム
を再設計するコストは、最初からシステムを適切に構築する場合のコストを上回ります。ここ
での教訓は単純明快です。開発の当初から拡張性に留意して設計と実装を行うということです。
2-4
Oracle Database パフォーマンス・チューニング・ガイド
拡張性について
拡張性を妨げる要因
アプリケーションを作成するとき、設計者とアーキテクトは、可能なかぎり完全な拡張性に近
づけることを目指す必要があります。この完全な拡張性は線状の拡張性と呼ばれ、システムの
スループットが CPU の数に比例するものです。
線状の拡張性にすることは、設計者の制御の及ばない部分があるため、実際には不可能です。
しかし、アプリケーションの設計や実装に可能なかぎりスケーラブルにしておくと、現在も、
将来においても、ハードウェア・コンポーネントの拡張や CPU テクノロジの発展とともにパ
フォーマンス目標を達成できます。
線状の拡張性を妨げる要因としては次のものが考えられます。
■
不適切なアプリケーションの設計、実装および構成
アプリケーションは、拡張性に最も大きく影響します。たとえば、次のような影響があり
ます。
■
■
■
スキーマ設計が不適切であると、SQL にコストがかかり、拡張性を持ちません。
トランザクション設計が不適切であると、ロックおよびシリアライズの問題が発生し
ます。
接続管理が不適切であると、応答時間が長くなり、システムの信頼性が低下します。
問題となるのは、設計のみではありません。アプリケーションの物理的な実装が弱点にな
る場合があります。たとえば、次のような場合があります。
■
システムが誤った I/O 方針のまま本番環境で使用される場合。
■
テスト時に生成された実行計画とは異なる実行計画が本番環境で使用される場合。
■
■
■
実行時のメモリーの解放を十分に考慮せずに大量のメモリー割当てを行う、メモリー
集中型アプリケーションによって、過剰な量のメモリーが使用される場合。
非効率的なメモリー使用やメモリー・リークによって、動作中の仮想メモリー・サブ
システムに高いストレスがかかる場合。このようなストレスは、パフォーマンスや可
用性に影響を与えます。
ハードウェア・コンポーネントの誤ったサイズ指定
ハードウェア価格の低下に伴い、どのハードウェア・コンポーネントについても容量計画
が不適切で問題になるということは少なくなっています。ただし、容量が大きすぎると、
システムでワークロードが増大したときに、拡張性の問題が隠されてしまう場合がありま
す。
■
ソフトウェア・コンポーネントの制限
すべてのソフトウェア・コンポーネントに、拡張性およびリソース使用上の制限がありま
す。このことは、アプリケーション・サーバー、データベース・サーバーおよびオペレー
ティング・システムでも同様です。アプリケーションの設計では、ソフトウェアの処理能
力を超えた要求をしないでください。
■
ハードウェア・コンポーネントの制限
ハードウェアは、完全にはスケーラブルになりません。ほとんどのマルチプロセッサ・シ
ステムでは、限られた数の CPU では線状の拡張性に近いものを実現できますが、ある数を
超えると、CPU の追加でパフォーマンスが全体的には向上しても、数に比例しなくなりま
す。さらに続けて追加していくと、ある時点からパフォーマンスは向上しなくなり、むし
ろ低下する場合もあります。この動作は、ワークロードとオペレーティング・システムの
設定に深く関連しています。
注意 : 前述の要因は、スケーラブルでないシステムのチューニングにお
いてオラクル社のサーバー・パフォーマンス・グループが得た経験を基に
したものです。
パフォーマンスを考慮した設計と開発
2-5
システム・アーキテクチャ
システム・アーキテクチャ
システムのアーキテクチャには、主要な部分が 2 つあります。
■
ハードウェア・コンポーネントとソフトウェア・コンポーネント
■
要件に合った正しいシステム・アーキテクチャの構成
ハードウェア・コンポーネントとソフトウェア・コンポーネント
この項では、ハードウェア・コンポーネントとソフトウェア・コンポーネントについて説明し
ます。
ハードウェア・コンポーネント
今日の設計者とアーキテクトは、多層環境の各層でハードウェアのサイズ指定と容量計画を行
う必要があります。バランスの取れた設計を実現するのは、アーキテクトの責任です。これは、
橋の設計に似ています。橋の設計者は、橋に関する様々なペイロードや構造上の要件をすべて
考慮する必要があります。橋の強度は、最も弱いコンポーネントの強度にしかなりません。こ
のため、橋は、すべてのコンポーネントがその設計上の限界に同時に達するように、バランス
よく設計されています。
ハードウェアには、主に次のコンポーネントが含まれます。
■
CPU
■
メモリー
■
I/O サブシステム
■
ネットワーク
CPU CPU は 1 つ以上使用されており、その処理能力は、携帯端末に見られるような単純な
CPU のものから高性能サーバーの CPU のものまで様々です。他のハードウェア・コンポーネ
ントのサイズは、通常、システム上の CPU の倍数になります。第 9 章「オペレーティング・シ
ステム・リソース」を参照してください。
メモリー データベース・サーバーとアプリケーション・サーバーには、データをキャッシュし
たり、長時間のディスク・アクセスを避けるために、十分な量のメモリーが必要です。第 7 章
「メモリーの構成と使用方法」を参照してください。
I/O サブシステム I/O サブシステムは、クライアント PC のハード・ディスクから高性能なディ
スク・アレイまで様々あります。ディスク・アレイは、毎秒数千回の I/O を実行できるうえ、
複数の I/O パスおよびホット・プラグ可能なミラー化ディスクという冗長性から、可用性も得
られます。第 8 章「I/O 構成および設計」を参照してください。
ネットワーク システム内のコンピュータは、すべて、モデム回線から高速社内 LAN に到るま
でのネットワークに接続しています。ネットワーク仕様に関する主な考慮点は、帯域幅（通信
量）と待機時間（速度）です。
ソフトウェア・コンポーネント
コンピュータに共通のハードウェア・コンポーネントがあるように、アプリケーションにも共
通の機能コンポーネントがあります。ソフトウェアの開発を機能コンポーネントごとに分割す
ることで、アプリケーションの設計やアーキテクチャがより理解しやすくなります。システム
のコンポーネントの中には、アプリケーションの実装の高速化や、共通コンポーネントの再作
成の防止のために購入された既成のソフトウェアによって実行されるものもあります。
ソフトウェア・コンポーネントとハードウェア・コンポーネントの違いは、ハードウェア・コ
ンポーネントが 1 つのタスクしか実行しないのに対して、ソフトウェアはその 1 つ 1 つが様々
なソフトウェア・コンポーネントの役割を実行できるということです。たとえば、ディスク・
ドライブはデータの格納と取出ししか行いませんが、クライアント・プログラムはユーザー・
インタフェースを管理し、ビジネス・ロジックを実行できます。
2-6
Oracle Database パフォーマンス・チューニング・ガイド
システム・アーキテクチャ
ほとんどのアプリケーションに、次に関するコンポーネントが含まれています。
■
ユーザー・インタフェースの管理
■
ビジネス・ロジックの実装
■
ユーザー要求とリソース割当ての管理
■
データおよびトランザクションの管理
ユーザー・インタフェースの管理 これは、アプリケーション・ユーザーの目に触れることが最
も多いコンポーネントです。これには、次のものがあります。
■
ユーザーが使用するスクリーンの描画
■
ユーザー・データの収集とビジネス・ロジックへのデータの転送
■
データ入力の検証
■
アプリケーションのレベル間または状態間のナビゲーション
ビジネス・ロジックの実装 これに関するコンポーネントは、アプリケーション機能の中心とな
るコア・ビジネス・ルールを実装します。このコンポーネントでのエラーは、修復に相当なコ
ストを要する場合があります。このコンポーネントは、宣言型アプローチとプロシージャ型ア
プローチの組合せで実装されます。宣言アクティビティの例としては、一意キーと外部キーの
定義があります。また、プロシージャ・ベースのロジックの例としては、値引計画の実装があ
ります。
このコンポーネントの一般的な機能は、次のとおりです。
■
リレーショナル表構造へのデータ・モデルの移行
■
リレーショナル表構造での制約の定義
■
ビジネス・ルールを実装するプロシージャ型ロジックのコーディング
ユーザー要求とリソース割当ての管理 このコンポーネントは、すべてのソフトウェアに実装さ
れます。ただし、アプリケーション設計の影響を受ける要求やリソースがある一方で、影響を
受けない要求やリソースもあります。
マルチ・ユーザー・アプリケーションでは、ユーザー要求によるリソース割当てのほとんどは、
データベース・サーバーまたはオペレーティング・システムで処理されます。ただし、ユー
ザー数や使用パターンが不明または急増している大規模アプリケーションの場合、システム・
アーキテクトはどのソフトウェア・コンポーネントも過負荷や不安定にならないように事前に
対処する必要があります。
このコンポーネントの一般的な機能は、次のとおりです。
■
データベースとの接続管理
■
効率的な SQL の実行（カーソルと SQL の共有）
■
クライアント状態情報の管理
■
ハードウェア・リソース間でのユーザー要求のロード・バランシング
■
ハードウェアおよびソフトウェア・コンポーネントに対する操作目標の設定
■
タスクの非同期実行のための永続キューイング
データおよびトランザクションの管理 このコンポーネントは、主にデータベース・サーバーと
オペレーティング・システムが管理します。
このコンポーネントの一般的な機能は、次のとおりです。
■
ロックとトランザクション・セマンティクスを使用した、データへの同時アクセス
■
索引およびメモリー・キャッシュを使用した、データへの最適化アクセス
■
ハードウェア障害時のデータ変更の記録
■
データに対して定義されているルールの適用
パフォーマンスを考慮した設計と開発
2-7
システム・アーキテクチャ
要件に合った正しいシステム・アーキテクチャの構成
初期のシステム・アーキテクチャを構成する作業は、反復的な処理です。アーキテクトは、予
算やスケジュールの制約内でシステム要件を満たす必要があります。対話型ユーザーがデータ
ベースの内容に基づいてビジネスの取引や意思決定を行うシステムの場合、ユーザー要件が主
体のアーキテクチャになります。システム上に対話型ユーザーがほとんどいない場合は、プロ
セス主体のアーキテクチャになります。
対話型ユーザー・アプリケーションの例を、次に示します。
■
経理アプリケーションや会計帳簿アプリケーション
■
注文入力システム
■
電子メール・サーバー
■
Web ベースの小売販売アプリケーション
■
取引システム
プロセス主体のアプリケーションの例を、次に示します。
■
公共料金支払システム
■
不正検出システム
■
ダイレクト・メール
多くの点で、プロセス主体のアプリケーションの方が、ユーザー・インタフェース要素がない
のでマルチ・ユーザー・アプリケーションよりも設計が容易です。しかし、目的がプロセス指
向であるため、大量のデータや様々な成功要因の扱いに慣れていないアーキテクチトは混乱す
ることがあります。プロセス主体のアプリケーションでは、ユーザー・ベースのアプリケー
ションとデータ・ウェアハウス・アプリケーションの両方で使用されるスキルを利用します。
したがって、このマニュアルでは、対話型ユーザー向けの新しいシステム・アーキテクチャに
ついて、重点的に説明します。
注意 : システム・アーキテクチャの生成は、決定論的なプロセスではあ
りません。ビジネス要件、テクノロジの選択肢、既存のインフラストラク
チャやシステム、さらに予算や人員などの実際の物理リソースなどを慎重
に考慮する必要があります。
次の質問は、システム・アーキテクチャに関する完全なガイドではありませんが、アーキテク
チャについて考える場合の参考になります。これらの質問では、アーキテクチャ、実装しやす
さ、さらにシステムの全体的なパフォーマンスと可用性に対して、ビジネス要件がどのように
影響を及ぼすかを示しています。たとえば、次のような影響があります。
■
システムでサポートするユーザーは何人ですか ?
ほとんどのアプリケーションは、次のいずれかのカテゴリに該当します。
–
ごく少数のユーザーが使用率の低いシステムまたは専用システムを使用する場合
このタイプのアプリケーションでは、通常、ユーザーは 1 人です。この場合のアプリ
ケーション設計の重点は、応答時間を短くし、しかもアプリケーションの管理を最小
限に抑えることで、シングル・ユーザーの生産性をできるだけ高くすることにありま
す。このようなアプリケーションのユーザーは、相互に介入することはほとんどなく、
リソースの競合も最小限に抑えられます。
–
中規模から大規模の数の社内ユーザーが共有アプリケーションを使用する場合
このタイプのアプリケーションでは、ユーザー数は、社内でシステムを実際に使用し
てビジネスを行う従業員の数に限定されます。したがって、ユーザー数は予測可能で
す。ただし、信頼性のあるサービスを提供することが、ビジネスにとっては必須です。
ユーザーは共有リソースを使用するため、アプリケーション設計では、大量のシステ
ム・ロード下での応答時間、各セッションで使用されるリソースの増大および将来の
拡張のための余地に重点を置きます。
2-8
Oracle Database パフォーマンス・チューニング・ガイド
システム・アーキテクチャ
–
無数のユーザーがインターネット上に存在する場合
このタイプのアプリケーションでは、すべてのシステム・コンポーネントがそれぞれ
の限界を超えないように設計する必要があります。1 つでも限界を超えるとボトル
ネックが発生し、システムが停止したり不安定になることがあります。このようなア
プリケーションでは、複合的なロード・バランシング、ステートレスなアプリケー
ション・サーバーおよび効率的なデータベース接続管理が必要です。さらに、統計情
報とガバナーを使用して、システムの過負荷が原因でユーザー要求が満たされない場
合にユーザーがフィードバックを受け取るようにする必要があります。
■
ユーザーとの対話方式は何ですか ?
ユーザー・インタフェースの選択肢は、単純な Web ブラウザからカスタム・クライアン
ト・プログラムまで様々です。
■
ユーザーはどこに位置しますか ?
ユーザー間の距離は、ネットワーク待機時間に対処するためのアプリケーションの設計方
法に影響します。また、ユーザーの位置は、1 日の中でピークの時間帯、つまりバッチ機
能やシステム・メンテナンス機能を実行できない時間帯の決定にも影響を与えます。
■
ネットワーク速度はどの程度ですか ?
ネットワーク速度は、データ量に影響を与え、アプリケーション・サーバーやデータベー
ス・サーバーとのユーザー・インタフェースの対話特性にも影響を与えます。対話主体の
ユーザー・インタフェースでは、キー・ストロークごとまたはフィールド・レベルの妥当
性チェックごとにバックエンド・サーバーと通信します。対話が少ないインタフェースは、
画面ごとに送受信を行うモデルで機能します。通信速度が遅いネットワークでは、対話主
体のユーザー・インタフェースを使用しても高速のデータ入力速度は実現できません。
■
ユーザーがアクセスするデータ量はどれくらいで、そのデータの中で読取り専用データが
占める割合はどの程度ですか ?
オンラインでの問合せのデータ量は、表や索引の設計からプレゼンテーション層にいたる
設計のあらゆる局面に影響を与えます。データベースのサイズによってユーザーの応答時
間が影響されないように設計する必要があります。アプリケーションが主として読取り専
用の場合は、アプリケーション・サーバーのローカル・キャッシュへのレプリケーション
とデータ配分が有効な選択肢になります。また、これにより、主要トランザクション・
サーバーでのワークロードが削減されます。
■
ユーザー応答時間の要件は何ですか ?
ユーザー・タイプに関する考慮が重要です。ユーザーが経営者で、瞬時に意思決定を行う
ために正確な情報を必要とする場合は、ユーザー応答時間の妥協は許されません。データ
入力操作を行うユーザーなど、他のタイプのユーザーの場合は、それほど高いパフォーマ
ンスは必要としません。
■
ユーザーは 1 日 24 時間のサービスを期待していますか ?
取引が 1 日 24 時間行われている今日のインターネット・アプリケーションの場合、24 時
間連続稼働は必須です。ただし、1 つのタイム・ゾーンでのみ稼働する企業システムの場
合は、終業後にシステムを停止できます。終業後のシステム停止時間を利用して、バッチ
処理やシステム管理を実行できます。このような場合は、連続稼働システムでない方が経
済的です。
■
変更はすべてリアルタイムで行う必要がありますか ?
ユーザーの応答時間内にトランザクションを実行する必要があるか、またはキューに入れ
て非同期で実行できるかを判断することが重要です。
次の質問は二次的な質問です。これらは設計にも影響を及ぼしますが、予算や実装しやすさの
面に、より大きく影響します。たとえば、次のような影響があります。
■
データベースの規模はどの程度ですか ?
データベースの規模は、データベース・ホスト・システムのサイズ決定に影響します。大
規模データベースを持つシステムでは、ワークロードから判断されるシステムよりも大型
のシステムを用意することが必要になる場合があります。これは、大規模データベースに
パフォーマンスを考慮した設計と開発
2-9
アプリケーション設計の原則
伴う管理オーバーヘッドが、主としてデータベース・サイズに比例するためです。表およ
び索引が大きくなると、許容できる時間内に表を再編成したり索引を作成する必要がある
ため、必要な CPU の数もそれに比例して増加します。
■
ビジネス・トランザクションで必要とされるスループットはどの程度ですか ?
■
可用性に関する要件は何ですか ?
■
このアプリケーションを作成して管理するためのスキルはありますか ?
■
予算上の制約からどのような妥協が求められますか ?
アプリケーション設計の原則
この項では、アプリケーション作成時に必要な次の設計上の決定事項を説明します。
■
アプリケーション設計の簡潔さ
■
データのモデル化
■
表および索引の設計
■
ビューの使用
■
SQL の実行効率
■
アプリケーションの実装
■
アプリケーション開発の傾向
アプリケーション設計の簡潔さ
アプリケーションは、設計と開発を伴う他の製品となんら変わりはありません。通常、適切に
設計された構造、システムおよびツールには信頼性があり、使用方法やメンテナンスが容易で、
概念的にも簡潔です。ごく一般的に表現すると、設計が適切に見えるものは、実際に適切に設
計されているといえます。アプリケーションの作成では、この原則を常に覚えておいてくださ
い。
設計に関しては、次の点を考慮してください。
■
■
■
■
■
表の設計が複雑で、誰も完全に理解できない場合、その表の設計は不適切であるといえま
す。
SQL 文が非常に長く、どのオプティマイザでもリアルタイムに効率よく最適化できない場
合、その SQL 文、基になるトランザクションまたは表の設計が不適切であるといえます。
表に索引があり、同じ列が繰り返し参照される場合は、索引の設計が不適切であるといえ
ます。
問合せを送信したときに、オンライン・ユーザーにとって必要な迅速な応答能力がなかっ
た場合は、ユーザー・インタフェースまたはトランザクションの設計が不適切であるとい
えます。
ソフトウェアの多くの層で、データベース・コールがアプリケーション・ロジックから離
れて抽象化される場合は、ソフトウェアの開発方法が不適切であるといえます。
データのモデル化
データのモデル化は、リレーショナル・アプリケーションの適切な設計に不可欠です。デー
タ・モデルは、実際のビジネスに即した表現である必要があります。正しいデータ・モデルに
ついては、様々な議論の余地があります。重要なことは、最も頻繁に行われるビジネス・トラ
ンザクションの影響を受けるエンティティをモデル化の主な対象にすることです。モデル化
フェーズでは、あまり重要でないデータ要素のモデル化に時間を取られることがあり、開発の
準備期間が延長される結果になります。モデル化ツールを使用すると、スキーマ定義をすばや
く生成できます。また、短期間でプロトタイプを作成する必要がある場合に便利です。
2-10
Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
表および索引の設計
表の設計は、主に、主要トランザクションの柔軟性とパフォーマンスの間でバランスを取る作
業です。データベースの柔軟性を保持しながら予想外のワークロードに対処できるようにする
には、表の設計をデータ・モデルとほぼ同じようにする必要があり、最低でも第 3 正規形に正
規化しておく必要があります。ただし、ユーザーが必要とする特定のトランザクションでは、
パフォーマンス向上のために選択的な非正規化が求められることがあります。
この技法の例としては、事前に結合された表の格納、導出列の追加および集計値があります。
Oracle には、クラスタ化機能とマテリアライズド・ビュー機能により、集計データと事前結合
データの格納に関するオプションが多数用意されています。これらの機能によって、より簡潔
な表の設計を最初から採用できます。
ここでも、最適のパフォーマンスを実現できるように、ビジネス上重要な表に重点的にリソー
スを使用する必要があります。重要でない表の場合は、アプリケーション開発を迅速に進める
ためにも、設計に簡略な方法を採用できます。ただし、プロトタイプおよびテストの結果、重
要でない表でパフォーマンスの問題が発生する場合は、ただちに設計を修正する必要がありま
す。
索引の設計も、アプリケーション設計者が生成した SQL に基づく、主として反復的なプロセス
です。ただし、主キー制約を適用する索引や個人名など既知のアクセス・パターンに対する索
引を作成することから開始することも可能です。アプリケーションの開発が進み、実際のデー
タ量でテストを実行すると、特定の問合せのパフォーマンスを改善する必要が生じますが、こ
れには適切な索引の作成が解決策になることがあります。新たに索引を作成するときに索引の
設計に関して考慮する点を、次に示します。
■
索引への列の追加または索引構成表の使用
■
異なる索引タイプの使用
■
索引のコストの算出
■
索引内のシリアライズ
■
索引内の列の順序付け
索引への列の追加または索引構成表の使用
問合せをスピードアップする簡単な方法の 1 つは、実行計画から表アクセスを排除して論理
I/O の数を減らすことです。これは、問合せによって参照されるすべての列を索引に追加する
ことで実現できます。これらの列は、選択リスト列、および結合またはソートに必要な列です。
この方法は、時間がかかる I/O を削減して、オンライン・アプリケーションの応答時間を短縮
する場合に特に役立ちます。これは、適切なサイズのデータを使用してアプリケーションを初
めてテストするときに最も効果を発揮します。
この技法を最も積極的に使用しているのが、索引構成表（IOT）の作成です。ただし、IOT の
リーフ・サイズの増加が I/O 削減効果を妨げないように注意する必要があります。
異なる索引タイプの使用
選択できる索引のタイプはいくつかあり、それぞれ特定の状況に応じた利点があります。各タ
イプの索引に関連したパフォーマンスの考慮点を、次のリストに示します。
B ツリー索引 標準的な索引タイプです。主キー索引および選択的な索引に最も適しています。
B ツリー索引を連結索引として使用すると、索引列順にソートされたデータを取り出すことが
できます。
ビットマップ索引 この索引は、カーディナリティが低いデータに適しています。この索引は、
圧縮技法によって最小限の I/O で多数の ROWID を生成できます。選択列以外の列に対する
ビットマップ索引を組み合せることによって、最小限の I/O と多数の ROWID で AND 演算と
OR 演算を効率よく実行できます。ビットマップ索引は、索引内で問合せを満たすことができる
ため、COUNT() を使用した問合せで特に効果的です。
パフォーマンスを考慮した設計と開発
2-11
アプリケーション設計の原則
ファンクション索引 この索引では、ベース・データ上の関数から導出された値に対する B ツ
リー経由でアクセスできます。ファンクション索引では NULL の使用に制限があり、問合せオ
プティマイザを使用可能にしておく必要があります。
ファンクション索引は、複合列への問合せで導出される結果を生成する場合や、データベース
へのデータの格納方法における制限を克服する場合に、特に役立ちます。その例として、
（販売
価格 - 値引）×数量から算出された特定の値を超える注文の明細項目（表内の列）の問合せが
あります。別の例としては、UPPER 関数をデータに適用した、大 / 小文字を区別しない検索が
あります。
パーティション索引 グローバル索引のパーティション化によって、パーティション・プルーニ
ングが索引アクセス内で発生し、I/O を削減できます。レンジ・パーティション化またはリス
ト・パーティション化を適切に定義すると、正しい索引パーティションが高速で索引スキャン
されるため、問合せ時間を大幅に短縮できます。
逆キー索引 この索引は、挿入アプリケーションでの索引のホット・スポットを除去するように
設計されています。この索引は、挿入パフォーマンスに優れていますが、索引レンジ・スキャ
ンには使用できません。
索引のコストの算出
索引構造の作成とメンテナンスにはコストがかかり、ディスク領域、CPU および I/O 容量など
のリソースを消費します。設計者は、索引のメンテナンスにかかるコストより、索引の使用に
よる利点が上回るように設計する必要があります。
索引のメンテナンスにかかるコストを見積る簡単な目安があります。それは、索引キーに対し
て INSERT、DELETE または UPDATE を実行することでメンテナンスされる索引では、索引ご
とに、表に対する実際の DML 操作で使用されるリソースの 3 倍のリソースが必要になる、と
いうものです。つまり、3 つの索引がある表に INSERT 操作を行うと、索引がない表に
INSERT 操作を行う場合に比べて、10 倍近く処理が遅くなるということです。DML の場合、
特に INSERT 主体のアプリケーションでは、問合せと INSERT 操作のパフォーマンスとの間の
バランスを取る必要があるため、索引の設計は十分に検討する必要があります。
関連項目 : 索引の使用を監視する方法の詳細は、『Oracle Database 管理
者ガイド』を参照してください。
索引内のシリアライズ
順序またはタイムスタンプを使用して索引付きキー値を生成すると、データベースのホット・
スポット問題が生じ、応答時間やスループットに影響を与える場合があります。これは、通常、
キーが単調に増加することによるもので、結果として索引は適度に増加します。この問題を回
避するには、索引の全範囲にわたって挿入するキーを生成します。これによって、スケーラブ
ルで領域を効率よく使用するバランスの取れた索引になります。これには、逆キー索引を使用
するか、接頭辞および順序値にサイクル順序を使用します。
索引内の列の順序付け
設計者は、索引作成の規則を柔軟に定義する必要があります。状況に応じて、次のいずれかの
方法で索引内のキーに順序を付けます。
■
■
2-12
選択頻度の高い列から順序を付けます。これによって、必要な ROWID に最小限の I/O で
最も速くアクセスできるため、通常はこの方法を使用します。この方法は、主として主
キーや選択頻度の高いレンジ・スキャンに使用します。
列に順序を付け、データをクラスタ化またはソートして I/O を削減します。大規模なレン
ジ・スキャンでは、通常、選択頻度の低い順に列に順序を付けるか、取り出す順にデータ
をソートすると、I/O を削減できます。第 15 章「索引およびクラスタの使用方法」を参照
してください。
Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
ビューの使用
ビューを使用すると、アプリケーションの設計がスピードアップされ簡潔になります。簡単な
ビュー定義により、データの取出し、表示、収集および格納処理を優先するプログラマが、複
雑なデータ・モデルから解放されます。
ただし、ビューは、クリーンなプログラミング・インタフェースを提供する一方で、最適とは
いえないリソース集中型の問合せの原因になる場合があります。ビューの最も不適切な使用例
は、ビューが他の複数のビューを参照し、その複数のビューが問合せ内で結合されている場合
です。多くの場合、開発者はビューを使用せずに表から直接問合せを満たすことができます。
ビューが持つ本来の特性により、通常は、オプティマイザによる最適な実行計画の生成が困難
になります。
SQL の実行効率
システム開発の設計およびアーキテクチャ・フェーズでは、アプリケーション開発者が SQL の
実行効率を理解していることが重要です。これには、開発環境が次の特性をサポートしている
必要があります。
■
適切なデータベース接続管理
データベースへの接続は、コストが高くスケーラブルでない操作です。このため、データ
ベースへの同時接続数はできるだけ少なくする必要があります。アプリケーションの初期
化時にユーザーが 1 人接続しているという単純なシステムが理想的です。しかし、Web
ベース・アプリケーションや多層アプリケーションでは、複数のアプリケーション・サー
バーが使用されてユーザーへのデータベース接続が多重化しているため、接続数を少なく
するのは困難です。このようなタイプのアプリケーションでは、データベース接続をプー
ルし、ユーザー要求ごとに接続が再確立されないように設計する必要があります。
■
適切なカーソルの使用と管理
ユーザー接続のメンテナンスも、システムでの解析アクティビティの最小化にとっては同
じように重要です。解析とは、SQL 文を解釈し、その SQL 文の実行計画を作成する処理で
す。この処理には、構文検査、セキュリティ検査、実行計画の生成、共有プールへの共有
構造のロードなど、多くのフェーズがあります。解析操作には、次の 2 種類があります。
■
■
ハード解析 : SQL 文が初めて送信され、共有プール内に一致するものがない場合です。
ハード解析は、解析に関連するすべての操作を実行するため、最もリソース集中型で
あり、スケーラブルではありません。
ソフト解析 : SQL 文が初めて送信され、共有プール内に一致するものがある場合です。
別のユーザーが以前に実行した結果が一致することがあります。SQL 文は共有される
ため、パフォーマンスが向上します。ただし、ソフト解析では、システム・リソース
を消費する構文検査やセキュリティ検査が必要であり、理想的とはいえません。
解析はできるだけ最小限にする必要があるため、アプリケーション開発者は、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;
パフォーマンスを考慮した設計と開発
2-13
アプリケーション設計の原則
次の例は、単純な 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 文の最適化の詳細は、第 11 章「SQL チュー
ニングの概要」を参照してください。
アプリケーションの実装
開発環境およびプログラミング言語の選択は、開発チームのスキルと、アプリケーションの指
定時に決定したアーキテクチャにより決定します。ただし、簡単なパフォーマンス管理規則が
いくつかあり、これに従うと、スケーラブルで高パフォーマンスのアプリケーションの実現に
つながります。
1.
ソフトウェア・コンポーネントに適した開発環境を選択し、その環境によってパフォーマ
ンスに関する設計が制限されないようにしてください。設計が制限される場合は、選択し
た言語または環境が不適切であるといえます。
■
ユーザー・インタフェース
プログラミング・モデルには、HTML 生成からウィンドウ・システムの直接コールま
で様々なモデルがあります。開発方法では、ユーザー・インタフェース・コードの応
答時間に重点を置く必要があります。HTML または Java をネットワークで送信する場
合は、ネットワーク通信量や対話を最小限に抑えるようにしてください。
■
ビジネス・ロジック
Java や PL/SQL などのインタープリタ型言語は、ビジネス・ロジックのエンコードに
は理想的です。これらの言語は完全に移植可能であるため、ロジックのアップグレー
ドが比較的簡単にできます。どちらの言語も構文が豊富で、読みやすく解析しやすい
コードを作成できます。ビジネス・ロジックで複雑な数学関数が必要な場合は、コン
パイラ型バイナリ言語が必要になる場合があります。ビジネス・ロジック・コードは、
クライアント・システム、アプリケーション・サーバーおよびデータベース・サー
バーに配置できます。ただし、アプリケーション・サーバーに配置するのが最も一般
的です。
■
ユーザー要求とリソース割当て
これがプログラミング言語によって影響を受けることはほとんどありませんが、デー
タベース接続やカーソル管理を隠すツールや第 4 世代言語では、非効率的なメカニズ
ムが使用されることがあります。このようなツールや環境を評価するときは、データ
ベース接続モデルおよびカーソルやバインド変数の使用方法をチェックしてください。
■
データ管理とトランザクション
これに関しては、プログラミング言語による影響はほとんどありません。
2-14
2.
ソフトウェア・コンポーネントを実装するときは、その機能を実装するようにし、他のコ
ンポーネントに関連付けられている機能は実装しないでください。他のコンポーネントの
機能を実装すると、設計や実装が最適でなくなります。これはすべてのコンポーネントに
当てはまります。
3.
機能のギャップをそのまま放置したり、検討中のソフトウェア・コンポーネントを設計、
実装またはテストで使用しないでください。多くの場合、ギャップは、アプリケーション
を展開するか、実際のボリュームでテストするまで検出されません。このギャップは、通
常、アーキテクチャまたは当初のシステム仕様が不適切であることを示します。データ・
アーカイブ / パージ・モジュールは、初期のシステム設計、作成および実装時には最も無
視されやすいモジュールです。
Oracle Database パフォーマンス・チューニング・ガイド
アプリケーション設計の原則
4.
プロシージャ型ロジックを実装するときは、C、Java または PL/SQL などの手続き型言語
で実装するようにします。データ・アクセス（問合せ）またはデータ変更（DML）を実装
するときは、SQL を使用します。これは、プロシージャ型コードとデータ・アクセス（非
プロシージャ型 SQL）コードが混在しているビジネス・ロジック・モジュール特有の規則
です。SQL アクセスにプロシージャ型ロジックを使用することも考えられますが、これは
リソースを多く消費する SQL になる傾向があります。DECODE ケース文を含む SQL 文は、
多くの場合、最適化が必要です。大量の OR 述語または集合演算子（UNION や MINUS な
ど）を含む文も同様です。
5.
頻繁にアクセスし、変更がほとんどなく、繰り返し取り出すのにコストがかかるデータは、
キャッシュします。ただし、キャッシュ・メカニズムは使いやすくして、元の方法でデー
タにアクセスするよりもコストが実際に低くなるようにしてください。これは、頻繁に使
用するデータ値はリモート・データ・ストアまたはコストがかかるデータ・ストアから繰
り返し取り出すよりも、キャッシュするかローカルに格納する必要があるすべてのモ
ジュールにあてはまります。
ローカルにキャッシュするデータの一般的な候補例をいくつか示します。
■
本日の日付。SELECT SYSDATE FROM DUAL が、データベースにかかるワークロードの
60% 以上を占めることもあります。
■
現行ユーザー名。
■
税率、値引率、位置情報など、繰り返し使用するアプリケーション変数および定数。
■
■
ローカルでのデータ・キャッシュは、さらに、アプリケーション・サーバー中間層へ
のローカル・データ・キャッシュの作成へ発展させることができます。これにより、
中央のデータベース・サーバーの負荷が減ります。ただし、ローカル・キャッシュを
作成するときは、パフォーマンス上の利点がなくなるほどキャッシュが複雑にならな
いように注意してください。
ローカル順序の生成
キャッシュを使用する場合は、設計上の意味を考慮してください。たとえば、ユーザーが
午前 0 時に接続して日付がキャッシュされた場合、ユーザーの日付値は無効になります。
6.
コンポーネント間のインタフェースを最適化し、すべてのコンポーネントが最もスケーラ
ブルな構成で使用されるようにします。この規則に説明はほとんど不要で、すべてのモ
ジュールとインタフェースに当てはまります。
7.
外部キー参照を使用します。アプリケーションから参照整合性を適用するのはコストがか
かります。外部キー参照は、子の列値を親から選択してその存在を確認することで、メン
テナンスできます。Oracle が提供する外部キー制約（SQL は使用していません）は、高速
で、しかも簡単に宣言でき、ネットワークの通信は発生しません。
8.
End to End Application Tracing で使用するアクション名およびモジュール名の設定を検討
してください。設定すると、ワークロードの問題を柔軟にトレースできます。20-2 ページ
の「End to End Application Tracing」を参照してください。
パフォーマンスを考慮した設計と開発
2-15
アプリケーション設計の原則
アプリケーション開発の傾向
今日のアプリケーション開発には、2 つの大きな特徴があります。1 つは、コンパイラ型の C
または C++ アプリケーションにかわって Java の使用が増えていること、もう 1 つは、スキー
マ設計に影響を与えるオブジェクト指向手法の使用が増えていることです。
Java はコードの移植性に優れ、高い可用性をプログラマに提供します。ただし、Java にはパ
フォーマンスに影響することが多数あります。Java はインタプリタ型言語であるため、C 言語
などのコンパイラ型言語に比べてロジックの実行速度が遅くなります。その結果、クライアン
ト・システムでのリソース使用率が増大します。このため、強力な CPU をクライアント・シス
テムや中間層システムに設置する必要があり、プログラマは効率的なコードを作成するように
さらに注意を払う必要があります。
Java はオブジェクト指向言語であるため、データ・アクセスはビジネス・ロジックを実行しな
いクラスに分離されやすくなります。この結果、プログラマは、使用するデータ・アクセス・
メソッドの効率を認識せずにそのメソッドを呼び出す可能性があります。これにより、データ
ベース・アクセスが最小限になり、データベースへのインタフェースには最も簡潔で単純なイ
ンタフェースが使用される傾向があります。
このタイプのソフトウェア設計では、常にすべての WHERE 述語が問合せに効率的に組み込まれ
るとは限らず、行のフィルタ処理は Java プログラムで実行されます。これはかなり非効率的で
す。さらに、DML 操作、特に INSERT 操作では単一の INSERT が実行され、配列インタ
フェースは使用できません。これが、プロシージャ・コールによりさらに非効率的になること
があります。データベースとのデータのやりとりでは、実際のデータベース・コールよりも多
くのリソースが使用されます。
一般に、最善の総合的トランザクション設計を実現するには、データ・アクセス・コールをビ
ジネス・ロジックの次に配置するのが最適です。
プログラミング・レベルでのオブジェクト指向の採用は、Oracle サーバー内にオブジェクト指
向データベースを作成することに発展しています。これは、オブジェクト構造を BLOB 内に格
納し、データベースを索引付きカード・ファイルとしてのみ効率的に使用するというケースか
ら、Oracle オブジェクト・リレーショナル機能を使用するというケースまで、様々な形で現れ
ています。
オブジェクト指向アプローチをスキーマ設計に採用する場合は、リレーショナル格納モデルの
柔軟性が失われないように注意してください。多くの場合、スキーマ設計でのオブジェクト指
向アプローチにより、データ構造にかなりの非正規化が生じ、相当なメンテナンスが必要にな
り、オブジェクトに関連付けられた REF ポインタも必要になります。このような設計は、多く
の場合、リレーショナル格納方式に置き換わる前の階層データベースやネットワーク・データ
ベースの設計に戻ることを意味します。
要約すると、データベースにデータを長期間格納し、同一スキーマに対する非定型問合せまた
はアプリケーション開発をある程度予期している場合は、リレーショナル格納方式によって最
善のパフォーマンスと柔軟性が得られることがわかります。
2-16
Oracle Database パフォーマンス・チューニング・ガイド
ワークロードのテスト、モデル化および実装
ワークロードのテスト、モデル化および実装
この項では、ワークロードの見積り、モデル化、実装およびテストについて説明します。この
項では、次の項目について説明します。
■
データのサイズ設定
■
ワークロードの見積り
■
アプリケーションのモデル化
■
設計のテスト、デバッグおよび検証
データのサイズ設定
不適切なサンプル・セットを使用すると、可変長データを扱うときにサイズの見積りを誤るこ
とがあります。データ量の増加に伴い、キーの長さも大幅に長くなり、列サイズの見積りに変
更が生じます。
システムは、本番稼働が始まると、データベース規模の拡大、特に索引の増加は予想が困難に
なります。表は時間とともに増大し、索引は、キーの生成、挿入パターンおよび行の削除とい
うアプリケーションの個々の動作によって変化します。最悪のケースは、昇順キーを使用して
行を挿入してから、一部の行を残してほとんどの行を表の左側から削除した場合です。これに
よって、ギャップと無駄な領域が残ります。索引をこのように使用している場合は、オンライ
ンの索引再作成機能の使用方法を理解してください。
DBA は、オブジェクトごとに領域割当てを監視し、増大して制御できなくなる可能性のあるオ
ブジェクトを探します。アプリケーションを十分に理解することで、急速にまたは予測を超え
て増大する可能性のあるオブジェクトを発見できます。これは、あらゆるシステムのパフォー
マンス計画と可用性計画の両方で重要なことです。本番データベースを実装するときは、対話
型ユーザーがアプリケーションを使用しているときに領域管理が最小限になるように設計する
必要があります。これは、データ・セグメント、一時セグメントおよびロールバック・セグメ
ントのすべてに当てはまります。
ワークロードの見積り
容量計画やテスト用のワークロードの見積りは、黒魔術にもたとえられます。見積りに関連す
る変数の数を考えると、正確な見積りがほとんど不可能であることが容易に理解できます。そ
れでも、設計者は、システムと CPU の数、メモリーおよびディスク・ドライブの数を指定し、
最終的にはアプリケーションを展開する必要があります。サイズ設定に使用する技法はいくつ
かあり、それぞれに利点があります。サイズを設定するときは、次の 2 つの方法を使用して意
思決定プロセスを検証し、サポート用ドキュメントを準備することをお薦めします。
■
類似システムからの推定
■
ベンチマーク
類似システムからの推定
これは完全に経験に基づくアプローチで、特性が類似しており、パフォーマンスが把握されて
いる既存のシステムを基礎システムとして使用します。このシステムの仕様を、サイズ設定の
担当者が既知の相違点に応じて変更します。このアプローチでは、既存のシステムと関連する
部分は参考になりますが、相違点のある部分を扱うときにはほとんど参考になりません。
このアプローチは、巨大なビル、船舶、橋梁、石油掘削装置などの大規模エンジニアリング分
野のほとんどすべてで、エンジニアリング・プロジェクトのコストを見積るときに使用されて
います。参照システムがサイズの点で計画しているシステムと大きな差がある場合は、コン
ポーネントのいくつかが設計上限を超えてしまう可能性があります。
パフォーマンスを考慮した設計と開発
2-17
ワークロードのテスト、モデル化および実装
ベンチマーク
ベンチマーク・プロセスは、リソースと時間をかなり消費し、必ずしも正確な結果が得られる
とはかぎりません。開発初期またはプロトタイプの段階でアプリケーションをシミュレーショ
ンすると、実際の本番システムの場合とは異なるものを計測する危険性があります。予想外か
もしれませんが、オラクル社では長年にわたりデータベース開発組織とともに顧客アプリケー
ションのベンチマークを行っていますが、ベンチマーク・アプリケーションと実際の本番シス
テムとの間に信頼に値する相関関係はまだ認められていません。これは、開発プロセスでアプ
リケーションの非効率な点がいくつか組み込まれてしまうことが主な原因です。
しかし、ベンチマークは、許容可能なレベルの精度でシステムのサイズを設定するためには有
効に利用されています。特に、ベンチマークは、システムの負荷が最大になったときの実際の
I/O 要求数の判断やリカバリ処理のテストに効果があります。
ベンチマークでは、その性質上、システムの全コンポーネントに対してそれぞれの上限までス
トレスがかけられます。すべてのコンポーネントにストレスがかけられていくに従って、ベン
チマーク中にアプリケーションの設計および実装のエラーがすべて明らかになります。また、
ベンチマークでは、データベース、オペレーティング・システムおよびハードウェア・コン
ポーネントもテストされます。ほとんどのベンチマークが急いで実行されるため、システム・
コンポーネントが失敗すると障害や問題が発生すると考えてください。ベンチマークは実施者
にストレスがかかる作業であり、ベンチマークから最大限の結果を得るには豊富な経験が必要
です。
アプリケーションのモデル化
アプリケーションのモデル化は、複雑な数学的モデル化から、封筒の裏を使用するような典型
的な単純計算まで多岐にわたります。どちらの方法にもメリットがあり、一方は高い精度を目
標とし、もう一方は大まかな見積りを作成します。デメリットは、どちらも実装エラーや効率
の悪さが考慮されないことです。
見積りやサイズ設定のプロセスは、正確性に欠ける技法です。しかし、このプロセスを精査す
ることで、ある程度知的な見積りを行うことができます。見積りプロセス全体としては、不適
切な SQL、索引の設計またはカーソル管理によるアプリケーションの非効率は考慮されていま
せん。サイズ設定担当者は、アプリケーションの非効率性に対応する余裕を組み入れる必要が
あります。パフォーマンス・エンジニアは、非効率性を検出し、現実に近い見積りを作成する
必要があります。アプリケーションの非効率性を検出するプロセスの詳細は、
「Oracle のパ
フォーマンス改善方法」を参照してください。
設計のテスト、デバッグおよび検証
テスト・プロセスは、主に機能テストと安定性テストで構成されます。このプロセスの途中で、
パフォーマンス・テストが実施されます。
アプリケーションのパフォーマンス・テストを実行するときの簡単な規則を説明したリストを
次に示します。適切に文書化されていると、この情報は、アプリケーション稼働後の本番アプ
リケーションと容量計画プロセスにとって重要な情報になります。
■
■
Automatic Database Diagnostic Monitor（ADDM）と SQL チューニング・アドバイザを使
用した設計の検証
現実的なデータ量とデータ配分によるテスト
すべてのテストは、データが完全に含まれている表を使用して行う必要があります。テス
ト用データベースには、データ量や表のカーディナリティという点で本番システムと同様
のデータを入れておく必要があります。本番と同様の索引をすべて作成し、スキーマ統計
を正しく入力します。
■
正しいオプティマイザ・モードの使用
すべてのテストは、本番で使用するオプティマイザ・モードで実行する必要があります。
オラクル社では、問合せオプティマイザを重点的に研究開発してきました。したがって、
問合せオプティマイザの使用をお薦めします。
2-18
Oracle Database パフォーマンス・チューニング・ガイド
ワークロードのテスト、モデル化および実装
■
シングル・ユーザーのパフォーマンスのテスト
アイドル状態または使用率が低いシステムでのシングル・ユーザーのパフォーマンスが許
容範囲にあるかテストします。シングル・ユーザーのパフォーマンスが理想的な条件下で
許容範囲に達しない場合、リソースを共有するマルチ・ユーザーの状況で許容できるパ
フォーマンスになることはあり得ません。
■
全 SQL 文の計画の取得と文書化
各 SQL 文の実行計画を取得します。一部の SQL メトリックは、文を最低 1 回実行して取
得する必要があります。このプロセスを使用して、オプティマイザが最適の実行計画を取
得することと、SQL 文の相対コストが CPU 時間と物理 I/O 数の観点から把握されている
ことを検証します。このプロセスは、将来的に最も多くのチューニングやパフォーマンス
作業が必要になる、使用量の多いトランザクションを識別するのに役立ちます。プラン・
スタビリティの詳細は、第 18 章「プラン・スタビリティの使用方法」を参照してくださ
い。
■
マルチ・ユーザーのテスト
ユーザーのワークロードやプロファイルがまだ完全に定量化されていない可能性があるた
め、このプロセスを正確に実行するのは困難です。しかし、DML 文を実行するトランザク
ションをテストして、ロックの競合やシリアライズの問題がないことは確認する必要があ
ります。
■
正しいハードウェア構成でのテスト
できるだけ本番システムに近い構成でテストすることが重要です。これは、ネットワーク
待機時間、I/O サブシステム帯域幅およびプロセッサのタイプと速度についてテストする
場合に特に重要です。このテストを正確に行わないと、潜在的なパフォーマンスの問題を
正しく分析できません。
■
安定した状態でのパフォーマンスの測定
ベンチマークを行うときは、安定した状態でパフォーマンスを測定することが重要です。
各ベンチマークの実行には開始フェーズが必要です。このフェーズでは、ユーザーがアプ
リケーションに接続し、アプリケーションでの作業を徐々に開始します。このプロセスに
よって、安定した状態になる前に、頻繁にキャッシュされるデータをキャッシュに初期化
し、解析などの 1 回実行するのみの操作を完了しておくことができます。同様に、ベンチ
マークの実行後には終了フェーズが必要です。このフェーズでは、リソースをシステムか
ら解放し、ユーザーは作業を終了して接続を切断します。
パフォーマンスを考慮した設計と開発
2-19
新規アプリケーションの配置
新規アプリケーションの配置
この項では、アプリケーションの配置に関して設計で必要な次の決定事項について説明します。
■
ロールアウトの方法
■
パフォーマンス・チェックリスト
ロールアウトの方法
新しいアプリケーションをロールアウトするときは、次の 2 つの方法が一般的です。
■
■
ビッグ・バン・アプローチ : 全ユーザーが一度に新しいシステムに移行します。
トリクル・アプローチ : ユーザーは既存のシステムから新しいシステムに徐々に移行しま
す。
いずれの方式にもメリットとデメリットがあります。ビッグ・バン・アプローチでは、必要な
規模でアプリケーションを十分にテストしておく必要がありますが、旧システムは完全に使用
されなくなるため、旧システムからのデータの変換と旧システムとの同期が最小限で済みます。
トリクル・アプローチでは、ワークロードの増加に伴い拡張性の問題をデバッグできますが、
移行中に旧システムとの間でデータを相互に移行する必要性が発生することがあります。
いずれの方法も、それぞれ移行実施中にシステムの停止につながるリスクがあるため、どちら
かを推奨することは困難です。トリクル・アプローチでは、実際のユーザーが新しいアプリ
ケーションに移行するにつれてユーザー・プロファイルを作成できるので、システムを再構成
しても、その影響を受けるのは移行済ユーザーのみです。この方式は、初期の段階で移行した
ユーザーの作業に影響を与えますが、サポート・サービスの負荷は限定されます。これは、ス
ケジュール外の停止が発生しても、影響を受けるユーザーの割合が小さいことを意味します。
新規アプリケーションのロールアウト方法は、ビジネスごとに判断してください。採用する方
式には、それぞれ固有の長所と短所があります。テストを重ねて、そのテストから得られた知
識が増えるほど、最善のロールアウト方式を判断できるようになります。
パフォーマンス・チェックリスト
ロールアウト・プロセスを支援するため、タスク・リストを作成してください。リスト上のタ
スクを正しく実行すると、本番で良好なパフォーマンスが得られる可能性が高くなり、問題が
発生した場合にもアプリケーションをすばやくデバッグできます。
2-20
1.
本番データベース用の制御ファイルを作成するときは、MAXINSTANCES、
MAXDATAFILES、MAXLOGFILES、MAXLOGMEMBERS および MAXLOGHISTORY をロールア
ウトで予測されるよりも大きい値に設定することで、データベースの成長に対応します。
この結果、ディスク領域の使用量が増えて制御ファイルも大きくなりますが、後でこれら
を緊急に拡張する必要が生じたときに時間を節約できます。
2.
ブロック・サイズをアプリケーションの開発時に使用した値に設定します。本番同様の
データ量でテストが完了し、現在の SQL 実行計画が正しい場合は、スキーマ統計を開発 /
テスト環境から本番データベースにエクスポートします。
3.
最小限の初期化パラメータを設定します。他のパラメータはデフォルトのままにしておく
のが理想的です。チューニングをさらに行う必要がある場合は、システムの負荷が少ない
ときに示されます。初期構成でのパラメータの設定の詳細は、第 4 章「パフォーマンスを
考慮したデータベースの構成」を参照してください。
4.
データベース・オブジェクトの記憶領域オプションを設定して、ブロック競合の管理に備
えます。INSERT/UPDATE/DELETE 操作が頻繁に発生する表と索引を作成するには、自動
セグメント領域管理を使用する必要があります。ロールバック・セグメントの競合を回避
するには、自動 UNDO 管理を使用する必要があります。UNDO セグメントと一時セグメ
ントの詳細は、第 4 章「パフォーマンスを考慮したデータベースの構成」を参照してくだ
さい。
5.
すべての SQL 文が最適であることを検証し、そのリソース使用を把握します。
6.
データベースに接続しているミドルウェアとプログラムの接続管理が効率的であることと、
ログオン / ログオフが繰り返されていないことを確認します。
Oracle Database パフォーマンス・チューニング・ガイド
新規アプリケーションの配置
7.
SQL 文でカーソルが効率的に使用されていることを確認します。各 SQL 文は、1 回解析さ
れた後、繰り返して実行されるものです。これが正しく行われない原因として最も一般的
なものは、バインド変数が正しく使用されていないことか、WHERE 句の述語が文字列リテ
ラルとして送信されていることです。プリコンパイラを使用してアプリケーションを開発
している場合は、アプリケーションをプリコンパイルする前に、MAXOPENCURSORS、
HOLD_CURSOR および RELEASE_CURSOR の各パラメータがデフォルト値から再設定され
ていることを確認します。
8.
すべてのスキーマ・オブジェクトが開発環境から本番データベースに正しく移行されてい
ることを確認します。これには、表、索引、順序、トリガー、パッケージ、プロシージャ、
ファンクション、Java オブジェクト、シノニム、権限付与およびビューが含まれます。テ
スト中に変更を加えた場合は、その変更が本番システムにも加えられていることを確認し
ます。
9.
システムをロールアウトした直後に、データベースとオペレーティング・システムの統計
用ベースライン・セットを設定します。最初の統計データにより、設計およびロールアウ
ト・プロセスで設定した前提事項が検証または訂正されます。
10. 最初のボトルネック（必ず 1 つはあります）の予測を開始し、Oracle のパフォーマンス改
善方法に従ってパフォーマンスを改善します。詳細は、第 3 章「パフォーマンス改善方法」
を参照してください。
パフォーマンスを考慮した設計と開発
2-21
新規アプリケーションの配置
2-22
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 件の取引を処理可能にする。
最終的な満足度は、システム・パフォーマンスに関するユーザーの認識で判断されます。パ
フォーマンス・エンジニアの役割は、パフォーマンスを低下させるボトルネックを取り除くこ
とです。ボトルネックの原因としては、限られた共有リソースの非効率的な使用、またはシリ
アライズの原因となる共有リソースの不適切な使用が考えられます。すべての共有リソースに
は限りがあるため、パフォーマンス・エンジニアの目標は、共有リソースを効率的に活用して、
ビジネス処理件数を最大にすることです。高いレベルでは、データベース・サーバー全体を共
有リソースとみなすことができます。逆に、低いレベルでは、1 台の CPU やディスクを共有リ
ソースとみなすことができます。
Oracle のパフォーマンス改善方法は、パフォーマンス目標を達成するまで、または目標の達成
が不可能と判断されるまで適用できます。このプロセスは非常に反復的なプロセスであり、シ
ステムのパフォーマンスにほとんど影響のない調査も行うことになります。重要なボトルネッ
クを正確かつ適時に特定できるスキルを身に付けるには、時間と経験が必要です。ただし、利
用できるデータや統計を軽視すると、たとえ経験が豊かな技術者でもその経験が裏目に出るこ
とがあります。このような技術者は、根拠のない思い込みと慣習でデータベースをチューニン
グしようとします。これは、データベースのチューニング方法としては非常に危険でコストも
かかり、成功するとは考えられません。
3-2
Oracle Database パフォーマンス・チューニング・ガイド
Oracle のパフォーマンス改善方法
Automatic Database Diagnostic Monitor（ADDM）は、パフォーマンス改善方法の各部を実装
し、統計を分析して、重大なパフォーマンスの問題の自動診断を提供します。ADDM を使用す
ると、システム・パフォーマンスの改善に伴う所要時間を大幅に短縮できます。ADDM の詳細
は、第 6 章「自動パフォーマンス診断」を参照してください。
今日のシステムは多様で複雑であるため、パフォーマンス分析のための絶対的な法則は定義で
きません。本質的に、Oracle のパフォーマンス改善方法は、作業の方法を定義するものであり、
確定した一連の法則を定義するものではありません。ボトルネックの検出における唯一の法則
は、法則がないということです。優れたパフォーマンス・エンジニアは、提供されたデータを
利用し、様々な角度から検討してパフォーマンスの問題を判断します。
Oracle のパフォーマンス改善方法の手順
1.
次に示す初期標準チェックを実行します。
a.
ユーザーから率直なフィードバックを取得します。パフォーマンス・プロジェクトの
適用範囲、最終的なパフォーマンス目標、さらに将来のパフォーマンス目標を決定し
ます。このプロセスは、今後の容量計画にとっての鍵です。
b.
パフォーマンスがよいときと悪いときの両方で、オペレーティング・システム、デー
タベースおよびアプリケーションの統計をフルセットでシステムから取得します。す
べての統計を取得できない場合は、可能な範囲で取得します。使用できる統計がない
のは、犯罪捜査で証拠がないのと同じです。証拠がないと、捜査が困難になり時間も
かかります。
c.
ユーザー・パフォーマンスに関連している全システムのオペレーティング・システム
が健全であることをチェックします。オペレーティング・システムの健全性をチェッ
クすることにより、フルに使用されているハードウェアやオペレーティング・システ
ムのリソースを探します。過剰使用のリソースを症状としてリストし、後で分析しま
す。さらに、すべてのハードウェアでエラーや診断症状がないことをチェックします。
2.
Oracle で最もよく見られる誤りの上位 10 項目をチェックし、問題となる可能性のあるもの
が 1 つでもないか判断します。問題となる可能性がある場合は、症状としてリストし、後
で分析します。これらの項目をリストに含めるのは、問題となる可能性が高いためです。
ADDM では、これらの上位 10 項目のうち 9 項目が自動的に検出されレポートされます。
第 6 章「自動パフォーマンス診断」および 3-5 ページの「Oracle システムにおける誤りの
上位 10 項目」を参照してください。
3.
症状を手がかりにして、システムで発生している状況の概念モデルを作成し、パフォーマ
ンスの問題の原因を把握します。3-4 ページの「パフォーマンスを概念的にモデル化する際
の意思決定プロセスの例」を参照してください。
4.
一連の修正処理とシステムに対して予想される動作を提示し、アプリケーションに対して
最も有効な処理から順に適用します。ADDM により、各推奨事項と予測されるメリットが
生成されます。パフォーマンス改善作業の原則は、変更は一度に 1 つのみとし、変更前後
の差異を測定することです。ただし、システム停止時間に制約があり、この方法を忠実に
実行できないことがあります。一度に複数の変更を適用する場合は、それぞれの変更を切
り離すようにしてください。これにより、それぞれの変更の効果を個別に検証できます。
5.
変更により期待された効果があることを検証し、ユーザーがパフォーマンスの改善を認識
したかどうかを確認します。ユーザーが認識しない場合は、さらにボトルネックを探し、
アプリケーションをより正確に把握できるまで、概念モデルの微調整を続けます。
6.
パフォーマンス目標が達成されるまで、または他の制約によって達成が不可能になるまで、
前述の最後の 3 つの手順を繰り返します。
この方法によって、最大のボトルネックが特定され、パフォーマンスの改善に対する客観的ア
プローチが使用されます。重要なことは、アプリケーションの効率を高め、リソース不足とボ
トルネックを取り除くことにより、パフォーマンスを大幅に改善することです。このプロセス
では、インスタンスのチューニングにより最低限のパフォーマンスの向上（10% 未満）が期待
でき、アプリケーションの効率の悪さを切り離すことで大幅なパフォーマンスの向上（100% 以
上）が期待できます。
パフォーマンス改善方法
3-3
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 および
V$SQLSTATS に CPU 統計が示されます。
関連項目 : V$SQL および V$SQLSTATS の詳細は、
『Oracle Database
リファレンス』を参照してください。
アプリケーションが最適で、SQL が効率的に実行されている場合は、一部の作業をピーク
時以外に再スケジュールするか、大型のシステムの使用を検討してください。
3.
この段階で、CPU リソースが完全には使用されていないのに、システム・パフォーマンス
がまだ不十分ですか ?
不十分な場合は、サーバー内にシリアライズされた、スケーラブルでない動作があります。
サーバーから WAIT_EVENTS 統計を取得し、最大のシリアライズ・ポイントを確認します。
シリアライズ・ポイントがない場合、問題はデータベースの外にある可能性が高く、これ
を重点的に調査する必要があります。WAIT_EVENTS をなくすには、アプリケーション
SQL を修正し、データベース・パラメータをチューニングします。このプロセスは非常に
反復的で、WAIT_EVENTS を系統的にドリルダウンして、シリアライズ・ポイントを取り
除く技術を必要とします。
3-4
Oracle Database パフォーマンス・チューニング・ガイド
Oracle のパフォーマンス改善方法
Oracle システムにおける誤りの上位 10 項目
この項では、Oracle システムで最もよく見受けられる誤りをリストします。Oracle のパフォー
マンス改善方法に従うことで、これらの誤りはすべて回避できます。これらの誤りをシステム
内で見つけた場合は、アプリケーション内でパフォーマンス改善の効果のある箇所を再設計し
ます。Oracle システムの診断とチューニングに役立つ機能については、1-5 ページの「自動パ
フォーマンス・チューニング機能」を参照してください。待機イベント・データにより、パ
フォーマンスに影響を与えるような問題の症状が明らかになりますが、その詳細は、第 10 章
「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。
1.
不適切な接続管理
アプリケーションで、データベースとの対話ごとに接続と切断が行われることがあります。
この問題は、アプリケーション・サーバー内のステートレス・ミドルウェアで多く発生し
ます。この問題がパフォーマンスに与える影響はけた違いに大きく、まったくスケーラブ
ルではありません。
2.
カーソルと共有プールの不適切な使用
カーソルを使用しないと、解析が繰り返し行われることになります。バインド変数を使用
しないと、すべての SQL 文のハード解析が行われます。この問題がパフォーマンスに与え
る影響は甚だしく、まったくスケーラブルではありません。カーソルをオープンするバイ
ンド変数とともにカーソルを使用し、繰り返し実行します。動的 SQL を生成するアプリ
ケーションは疑ってみます。
3.
不適切な SQL
不適切な SQL とは、アプリケーション要件よりも多くのリソースを使用する SQL です。
たとえば、意思決定支援システム（DSS）による問合せが 24 時間以上実行されている場合
や、オンライン・アプリケーションからの問合せに 1 分以上かかる場合などがあります。
大量のシステム・リソースを使用する SQL は、改善の可能性があるかどうかを調査する必
要があります。ADDM により高負荷の SQL が識別され、SQL チューニング・アドバイザ
を使用して改善に関する推奨事項を提供できます。第 6 章「自動パフォーマンス診断」お
よび第 12 章「自動 SQL チューニング」を参照してください。
4.
標準以外の初期化パラメータの使用
このようなパラメータは、不適切なアドバイスや不正確な前提に基づいて実装されている
ことがあります。ほとんどのシステムでは、許容範囲内のパフォーマンスを提供するため
に、基本的なパラメータ・セットのみが使用されます。特に、ラッチに対する
SPIN_COUNT に関連するパラメータとマニュアルに記載されていないオプティマイザ機能
は、多くの問題の原因となり、このためにかなりの調査が必要になることがあります。
また、初期化パラメータ・ファイルに設定したオプティマイザ用パラメータが、実証済の
最適実行計画をオーバーライドしてしまう可能性があります。このため、スキーマ、ス
キーマ情報およびオプティマイザの設定はグループとしてまとめて管理し、一貫したパ
フォーマンスになるようにします。
関連項目 :
■
■
■
初期化パラメータおよびデータベース作成の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照
してください。
初期インスタンス構成でのパラメータと設定の詳細は、4-2 ページの
「初期インスタンス構成のパフォーマンスの考慮事項」を参照してく
ださい。
パフォーマンス改善方法
3-5
Oracle のパフォーマンス改善方法
5.
誤ったデータ I/O の取得
多くのサイトが、使用可能ディスク上にデータベースを適切にレイアウトしていません。
また、ディスクを I/O 帯域幅ではなくディスク領域によって構成し、ディスク数を誤って
指定しているサイトもあります。第 8 章「I/O 構成および設計」を参照してください。
6.
REDO ログの設定の問題
多くのサイトが、数も少なくサイズも小さい REDO ログを使用して運用されています。
REDO ログのサイズが小さいと、システム・チェックポイントがバッファ・キャッシュと
I/O システムに高い負荷をかけ続けることになります。REDO ログの数が少なすぎると、
アーカイブが間に合わないので、データベースはアーカイブ・プロセスが追い付くまで待
機します。パフォーマンスの観点からの REDO ログのサイズ設定の詳細は、第 4 章「パ
フォーマンスを考慮したデータベースの構成」を参照してください。
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-6
Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスの緊急の問題に対処する方法
パフォーマンスの緊急の問題に対処する方法
この項では、パフォーマンスに関する緊急事態に対処する方法について説明します。アプリ
ケーション・パフォーマンスの確立と改善の方法については、すでに詳細に説明しました。し
かし、緊急時には、システム・コンポーネントの変化によって、信頼性の高い予測可能なシス
テムが予測不可能でユーザー要求を満たせないシステムに変化します。
このような場合のパフォーマンス・エンジニアの役割は、何が変化したかをすばやく判断し、
適切な処理を行って、通常のサービスをできるだけ早く再開することです。多くの場合、緊急
の処理が必要であり、パフォーマンス改善方法を厳密に実行することは現実的ではありません。
パフォーマンス・エンジニアは、パフォーマンスの問題にただちに対処した後、十分なデバッ
グ情報を収集して、その問題をより明らかに把握するか、それができない場合は、少なくとも
同じ問題が再発しないようにする必要があります。
緊急のパフォーマンスの問題をデバッグする方法は、このマニュアルの前の章で説明したパ
フォーマンス改善方法と同じです。ただし、急を要するという問題の性質上、様々な段階で簡
便法が使用されます。デバッグ・プロセスの進行中に見つかった事実を詳細にメモし記録して
おくことが、後で行う分析と修正作業の正当化には不可欠です。これは、医師が患者の容態を
克明に記録して、将来の参照資料として役立てるのと同じです。
パフォーマンスの緊急の問題に対処する方法の手順
パフォーマンスの緊急の問題に対処する方法は、次のとおりです。
1.
パフォーマンスの問題を調査し、問題の症状を収集します。このプロセスには、次の作業
が含まれます。
■
■
■
システムのパフォーマンスが低下した状況について、ユーザー・フィードバックを収
集します。問題がスループットか応答時間かを調べます。
「パフォーマンスが正常だった時点から何が変化しましたか ?」という質問をユーザー
にします。この質問に対する回答が、問題の手がかりになることがあります。ただし、
状況が悪化する中で先入観のない回答を得るのは難しいことがあります。問題の前と
後で取得された参照データ（収集済の統計やログ・ファイル）を見つけるようにしま
す。
自動チューニング機能を使用して問題を診断および監視します。Oracle システムの診
断とチューニングに役立つ機能については、1-5 ページの「自動パフォーマンス・
チューニング機能」を参照してください。また、Oracle Enterprise Manager のパ
フォーマンス機能を使用すると、上位の SQL およびセッションを識別できます。
2.
アプリケーション・システムの全コンポーネントのハードウェア使用が健全であることを
チェックします。CPU 使用率が最も高いコンポーネントをチェックし、システムの全コン
ポーネントについて、ディスクとメモリーの使用およびネットワーク・パフォーマンスを
チェックします。このプロセスによって、問題の原因となっている層をすばやく特定でき
ます。問題がアプリケーション内で発生している場合は、分析の重点をアプリケーション
のデバッグへ移します。それ以外の場合は、データベース・サーバーの分析に進みます。
3.
データベース・サーバーが CPU 上で制約を受けているかどうか、待機イベントで待機し続
けているのかを判断します。データベース・サーバーが CPU 上で制約を受けている場合
は、次の点を調べます。
■
■
■
オペレーティング・システム・レベルで大量の CPU を消費しているセッション
（V$SESS_TIME_MODEL でデータベースの CPU 使用率を調べます。）
データベース・レベルで多数のバッファ取得を実行しているセッションまたは文
（V$SESSTAT および V$SQLSTATS を調べます。）
最適ではない SQL の実行の原因となった実行計画の変更（特定が困難な場合もありま
す。
）
■
初期化パラメータの誤設定
■
コード変更または全コンポーネントのアップグレードによるアルゴリズムの問題
パフォーマンス改善方法
3-7
パフォーマンスの緊急の問題に対処する方法
データベース・セッションがイベントを待機している場合は、V$SESSION_WAIT にリスト
されている待機イベントに従って、シリアライズの原因を判断します。V$ACTIVE_
SESSION_HISTORY ビューには、サンプリングされたセッション・アクティビティの履歴
が含まれており、問題が終了してシステムが通常の操作に戻った後も診断に使用できます。
ライブラリ・キャッシュに大量の競合がある場合は、データベースにログオンしたり SQL
を送信するのが不可能なことがあります。このような場合は、履歴データを使用して、そ
のラッチで競合が突然発生した原因を判断します。ほとんどが I/O 待機の場合は、
V$ACTIVE_SESSION_HISTORY を調べて、すべての入出力を実行するセッションで実行中
の SQL を判断します。待機イベントの詳細は、第 10 章「パフォーマンス・ビューを使用
したインスタンスのチューニング」を参照してください。
3-8
4.
緊急時の処理を適用して、システムを安定化します。これには、アプリケーションの一部
をオフラインにする処理や、システムに適用できるワークロードを制限する処理が含まれ
ます。また、システムの再起動や処理中のジョブの停止も含まれることがあります。これ
らの処理は、当然、サービス・レベルに影響を与えることになります。
5.
システムが安定していることを確認します。システムを変更したり制限した場合は、シス
テムが安定したことを確認し、データベースに関する参照統計情報を収集します。次に、
このマニュアルの前の章で説明した厳密なパフォーマンス改善方法に従って、すべての機
能とユーザーをシステムに戻します。このプロセスを完了するには、アプリケーションの
大幅な再設計が必要になることがあります。
Oracle Database パフォーマンス・チューニング・ガイド
第 III 部
インスタンスのパフォーマンスの最適化
第 III 部では、Oracle インスタンスのパフォーマンスを最適化するために、データベース・シス
テムの様々な要素をチューニングする方法について説明します。
第 III 部には次の章が含まれます。
■
第 4 章「パフォーマンスを考慮したデータベースの構成」
■
第 5 章「自動パフォーマンス統計」
■
第 6 章「自動パフォーマンス診断」
■
第 7 章「メモリーの構成と使用方法」
■
第 8 章「I/O 構成および設計」
■
第 9 章「オペレーティング・システム・リソース」
■
第 10 章「パフォーマンス・ビューを使用したインスタンスのチューニング」
4
パフォーマンスを考慮したデータベースの構成
この章では、パフォーマンスを考慮してデータベースを構成するための、オラクル社の方法論
の概要を説明しています。Oracle データベース・インスタンスのパフォーマンスの修正は後で
も可能ですが、データベースの初期構成をニーズにあわせて適切に行うことによって、パ
フォーマンス目標の多くは達成可能です。
この章には次の項があります。
■
初期インスタンス構成のパフォーマンスの考慮事項
■
適切なパフォーマンスを得る表の作成とメンテナンス
■
共有サーバーのパフォーマンスの考慮事項
パフォーマンスを考慮したデータベースの構成
4-1
初期インスタンス構成のパフォーマンスの考慮事項
初期インスタンス構成のパフォーマンスの考慮事項
この項では、パフォーマンスに重要な影響を与えるデータベース・インスタンスの初期構成オ
プションについて説明します。
データベース・コンフィギュレーション・アシスタント（DBCA）を使用してデータベースを
作成する場合、提供されるシード・データベースには必要な基本的初期化パラメータが組み込
まれており、この章で説明するパフォーマンス推奨事項を満たしています。
関連項目 :
■
■
データベース・コンフィギュレーション・アシスタントを使用した
データベース作成の詳細は、
『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 に、パフォーマンスの考慮事項として設定する、最も重要なパラメータを示します。
表 4-2 パフォーマンスに影響を与える重要な初期化パラメータ
4-2
パラメータ
説明
COMPATIBLE
互換性を維持しておく Oracle サーバーのリリースを指定します。
このパラメータを使用すると、新しい機能を自分の環境でテストせ
ずに、ただちに本番システムで新しいリリースで改善された機能を
利用できるようになります。アプリケーションが Oracle の特定の
リリース用に設計されていて、実際にはそれ以降のリリースの
Oracle をインストールする場合は、このパラメータをアプリケー
ション設計時のリリースに設定してください。
Oracle Database パフォーマンス・チューニング・ガイド
初期インスタンス構成のパフォーマンスの考慮事項
表 4-2 パフォーマンスに影響を与える重要な初期化パラメータ（続き）
パラメータ
説明
DB_BLOCK_SIZE
データベース・ファイルに格納され、SGA にキャッシュされる
Oracle データベース・ブロックのサイズを設定します。値の範囲は
オペレーティング・システムにより異なりますが、一般的にトラン
ザクション処理システムの場合は 8192 で、データベース・ウェア
ハウス・システムの場合はさらに大きい値となります。
すべての SGA コンポーネントのサイズ合計を指定します。
SGA_TARGET が指定されている場合、バッファ・キャッシュ
（DB_CACHE_SIZE）、Java プール（JAVA_POOL_SIZE）、ラージ・
プール（LARGE_POOL_SIZE）および共有プール
（SHARED_POOL_SIZE）のメモリー・プールは、自動的にサイズ設
定されます。7-2 ページの「自動共有メモリー管理」を参照してく
ださい。
SGA_TARGET
PGA_AGGREGATE_TARGET インスタンスに添付されたすべてのサーバー・プロセスに利用でき
るターゲット集計 PGA メモリーを指定します。PGA メモリー管理
の詳細は、7-35 ページの「PGA メモリー管理」を参照してくださ
い。
PROCESSES
そのインスタンスで起動できるプロセスの最大数を設定します。こ
のパラメータは、他のパラメータ値の多くがこのパラメータから導
出されるため、設定する最も重要なプライマリ・パラメータとなり
ます。
SESSIONS
これは、デフォルトで PROCESSES の値から設定されます。ただ
し、共有サーバーを使用する場合は、導出された値では不十分であ
る可能性があります。
UNDO_MANAGEMENT
システムで使用する UNDO 領域管理モードを指定します。AUTO
モードの使用をお薦めします。
UNDO_TABLESPACE
インスタンス起動時に使用される UNDO 表領域を指定します。
関連項目 :
■
■
■
第 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 使用量を簡単にチューニン
パフォーマンスを考慮したデータベースの構成
4-3
初期インスタンス構成のパフォーマンスの考慮事項
グすることもできます。V$ROLLSTAT ビューには、UNDO 表領域内の UNDO セグメントの動
作に関する情報が含まれています。
関連項目 :
■
■
■
UNDO 管理アドバイザの詳細は、
『Oracle Database 2 日でデータベー
ス管理者』および Oracle Enterprise Manager オンライン・ヘルプを
参照してください。
自動 UNDO 管理を使用した UNDO 領域の管理の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
動的パフォーマンスの V$ROLLSTAT および V$UNDOSTAT ビューの詳
細は、
『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 ログ・グループ」ページからも、サイズ設定のアドバイ
ログ・グループ」
スを取得できます。
REDO ログ・ファイルに特定のサイズを推奨できない場合もありますが、100MB ～数 GB の範
囲内にある REDO ログ・ファイルが妥当であると考えられます。システムが生成する REDO
の量に従って、オンライン REDO ログ・ファイルをサイズ設定します。およその目安として、
多くても 20 分ごとに 1 回ログを切り替えます。
関連項目 : REDO ログの管理の詳細は、
『Oracle Database 管理者ガイド』
を参照してください。
追加表領域の作成
データベース・コンフィギュレーション・アシスタント（DBCA）を使用してデータベースを
作成する場合、提供されるシード・データベースには必要な表領域すべてが自動的に組み込ま
れます。DBCA を使用しないように選択した場合は、初期データベースの作成後に追加表領域
を作成する必要があります。
すべてのデータベースには、SYSTEM および SYSAUX 表領域に加えて複数の表領域が必要で
す。これらの追加表領域は次のとおりです。
■
■
■
ソートなどに使用される一時表領域
読取り一貫性、リカバリおよびロールバック文に関する情報を格納するための UNDO 表
領域
実際のアプリケーションで使用する 1 つ以上の表領域
ほとんどの場合、アプリケーションにはいくつかの表領域が必要です。多数のデータファイル
を持つ非常に大きな表領域の場合は、複数の ALTER TABLESPACE x ADD DATAFILE Y 文をパラ
レルに実行することもできます。
4-4
Oracle Database パフォーマンス・チューニング・ガイド
初期インスタンス構成のパフォーマンスの考慮事項
表領域の作成時、表領域を構成するデータファイルは特殊な空のブロック・イメージで初期化
されます。テンポラリ・ファイルは初期化されません。
この初期化は、すべてのデータファイルが、その全体に書込みを行えるようにするためですが、
シリアルに行うと、長い処理になる可能性があります。したがって、複数の 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-5
適切なパフォーマンスを得る表の作成とメンテナンス
適切なパフォーマンスを得る表の作成とメンテナンス
アプリケーションをインストールする際、最初のステップで、必要なすべての表および索引を
作成します。表のようなセグメントを作成すると、データのために領域がデータベース内に割
り当てられます。後続のデータベース操作によってデータ容量が増大し、割り当てられた領域
を上回るようになると、Oracle はそのセグメントを拡張します。
表および索引を作成する際には、次の点に注意してください。
■
表領域の自動セグメント領域管理の指定
最高のパフォーマンスが得られるよう、Oracle によって自動的にセグメント領域が管理さ
れます。
■
記憶領域オプションの注意深い設定
アプリケーションでは、表または索引の用途によって記憶領域オプションを慎重に設定す
る必要があります。この設定には、PCTFREE の値の設定が含まれます。自動セグメント領
域管理を使用すると、PCTUSED を指定する必要がありません。
注意 : 空きリストの使用はお薦めしません。自動セグメント領域管理を
使用するには、ローカル管理表領域を作成し、セグメント領域管理の句を
AUTO に設定します。
表圧縮
ヒープ構成表は、どのような種類のアプリケーションにも透過的な圧縮形式で格納できます。
表圧縮は、主に読取り専用の環境向けに設計されたものであり、DML 操作では処理のオーバー
ヘッドの原因となる可能性もあります。ただし、多くの読取り操作で、特にシステムが I/O バ
ウンドである場合は、パフォーマンスが向上します。
データベース・ブロック内の圧縮データは自己完結型です。これは、ブロック内の圧縮されて
いないデータの再現に必要な情報がすべてそのブロック内にあることを意味します。ブロック
は、バッファ・キャッシュ内でも圧縮された状態で保持されます。表圧縮により、ディスク記
憶域のみでなく、メモリー使用量、特にバッファ・キャッシュ要件も削減されます。表へのア
クセスに必要な I/O 操作の量が削減され、バッファ・キャッシュ・ヒットの確立が高まること
で、パフォーマンスの向上が実現します。
圧縮係数の見積り
表圧縮は、個々のブロック内の列値の繰返しを解消することによって機能します。ブロック内
のすべての行と列の重複値は、ブロックの先頭にある、そのブロックのシンボル表と呼ばれる
ものに一度格納されます。こうした値の出現箇所はすべて、シンボル表への簡単な参照で置き
換えられます。繰返しの値が多いブロックほど圧縮率が高くなります。
大規模な表を圧縮する前に、予測される圧縮係数を見積もる必要があります。圧縮係数は、圧
縮されていない形式で情報を格納するために必要なブロック数を、圧縮記憶域に必要なブロッ
ク数で除算した値として定義されます。圧縮される表を代表する少数のデータ・ブロックをサ
ンプリングし、圧縮されていない場合と圧縮された場合の各ブロックの平均レコード数を比較
することで、圧縮係数を見積もることができます。これまでの経験では、およそ 1000 のデー
タ・ブロックを使用することで、きわめて正確な圧縮係数の見積りが可能であることがわかっ
ています。サンプリングのブロック数が多いほど、見積り結果が正確になる点に注意してくだ
さい。
チューニングによる圧縮率向上
Oracle では、多くの場合、特別なチューニングなしで、優れた圧縮係数を達成しています。
データベース管理者またはアプリケーション開発者は、実際に圧縮が行われる際にレコードを
再構成することによって、圧縮係数のチューニングを試行できます。チューニングを行うと、
圧縮係数が若干改善されるケースもあれば大きく改善されるケースもあります。
圧縮係数を高めるには、データベース・ブロック内の値の繰返しの可能性を高くする必要があ
ります。達成できる圧縮係数は、特定の列または列のペアのカーディナリティ（列値の繰返し
4-6
Oracle Database パフォーマンス・チューニング・ガイド
適切なパフォーマンスを得る表の作成とメンテナンス
の可能性を表す）およびこれらの列の行の平均長さによって異なります。Oracle の表圧縮では、
単一列の重複値が圧縮されるだけでなく、可能な場合は、複数列値のペアの使用が試行されま
す。データ配分について熟知していない場合、最適な順序の予測は非常に困難です。
関連項目 : 表圧縮およびパーティションの詳細は、『Oracle Database
データ・ウェアハウス・ガイド』を参照してください。
未使用領域の解放
一般に、時間経過とともにセグメント領域が断片化されたり、更新および削除操作の結果とし
てセグメントに多数の空き領域が生じます。このようにして粗密に移入されたオブジェクトは、
問合せおよび DML 捜査中にパフォーマンスを低下させる可能性があります。
Oracle Database にはセグメント・アドバイザが用意されており、オブジェクト内の領域の断片
化レベルに基づいて、オブジェクトに解放可能な領域があるかどうかのアドバイスを提供しま
す。
関連項目 : セグメント・アドバイザの詳細は、『Oracle Database 管理者
ガイド』および『Oracle Database 2 日でデータベース管理者』を参照して
ください。
オブジェクトに解放可能な領域がある場合は、データベース・セグメントを圧縮して縮小する
か、またはデータベース・セグメントの終わりにある未使用領域を割当て解除できます。
関連項目 :
■
■
未使用領域の解放については、
『Oracle Database 管理者ガイド』を参
照してください。
データベース・セグメントの縮小または未使用領域の割当て解除に使
用する SQL 文の詳細は、『Oracle Database SQL 言語リファレンス』
を参照してください。
データの索引付け
最も効率的な索引の作成方法は、データがロードされた後に索引を作成することです。そうす
ると、領域管理が大幅に簡単になり、行が挿入されるたびに索引がメンテナンスされることも
ありません。これは、SQL*Loader により自動的に行われますが、他の方法で初期データを
ロードする場合は、手動で行う必要があります。また、索引の作成は、CREATE INDEX 文の
PARALLEL 句を使用してパラレルで実行します。ただし、SQL*Loader ではこれを実行できな
いため、データのロード後に索引を手動でパラレルに作成する必要があります。
関連項目 : SQL*Loader の詳細は、
『Oracle Database ユーティリティ』を
参照してください。
ソート用データのメモリーの指定
データを含む表での索引の作成中に、データをソートする必要があります。このソートは、す
べての使用可能なメモリーをソートに使用する場合に最も高速に行われます。
PGA_AGGREGATE_TARGET 初期化パラメータを設定して、SQL 作業領域の自動サイズ指定を使
用可能にすることをお薦めします。
関連項目 :
■
■
PGA メモリー管理の詳細は、7-35 ページの「PGA メモリー管理」を
参照してください。
PGA_AGGREGATE_TARGET 初期化パラメータの詳細は、『Oracle
Database リファレンス』を参照してください。
パフォーマンスを考慮したデータベースの構成
4-7
共有サーバーのパフォーマンスの考慮事項
共有サーバーのパフォーマンスの考慮事項
共有サーバーを使用すると、プロセス数と、システムで消費されるメモリー量が削減されます。
共有サーバーは、多数の OLTP ユーザーが断続的なトランザクションを実行するシステムに有
効です。
また、データベースへの単位時間当たりの接続数が高いシステムでは、一般的に専用サーバー
よりも共有サーバーを使用する方が適しています。共有サーバーでは、接続要求を受けるより
も前に同時接続要求を処理するためのディスパッチャが使用可能な状態になっています。一方、
専用サーバーの場合は、接続固有の専用サーバーが、接続要求ごとに順次初期化されます。
共有サーバー・アーキテクチャを使用すると、特定のデータベース機能のパフォーマンスが改
善することも、または多少低下することもあります。たとえば、パラレル実行がアクティブな
場合、セッションが別の共有サーバーに移行できないことがあります。
クライアントからの要求が処理された後もセッションを移行できない場合があります。これは
すべてのユーザー情報が、UGA に格納されているとは限らないためです。サーバーがクライア
ントからの要求の処理を待機していた場合、UGA に格納されていなかったユーザー状態にはア
クセスできません。これを回避するために、個々の共有サーバーは、しばしばユーザー・セッ
ションにバインドされた状態を続ける必要があります。
関連項目 :
■
■
共有サーバーの管理の詳細は、
『Oracle Database 管理者ガイド』を参
照してください。
共有サーバー用のディスパッチャの構成の詳細は、
『Oracle Database
Net Services 管理者ガイド』を参照してください。
ある種の機能を使用する場合、あるサーバーがセッションに長期間バインドされる可能性があ
るため、追加の共有サーバーを構成する必要が生じる場合があります。
この項では、Oracle のアーキテクチャで使用するプロセスの競合を低減する方法について説明
します。
■
ディスパッチャ固有のビューを使用する競合の識別
■
共有サーバー・プロセスの競合の識別
ディスパッチャ固有のビューを使用する競合の識別
次のビューによってディスパッチャのパフォーマンス統計が提供されます。
■
V$DISPATCHER は、ディスパッチャ・プロセスの一般的な情報を提供します。
■
V$DISPATCHER_RATE は、ディスパッチャ・プロセスの統計を提供します。
V$DISPATCHER_RATE ビューは、いくつかのカテゴリについてディスパッチャ統計の現在、平
均および最大の値を含みます。接頭辞 CUR_ が付いている統計は、現在のサンプルの統計です。
接頭辞 AVG_ が付いている統計は、コレクション期間が開始してからの統計の平均値です。接
頭辞 MAX_ が付いている統計は、統計収集が開始してからのこれらのカテゴリでの最大値です。
ディスパッチャのパフォーマンスを調べるには、V$DISPATCHER_RATE ビューを問い合せて、
最大値と現在の値を比較します。現在のシステム・スループットが適切な応答時間を提供し、
このビューの現在の値が平均値に近くかつ最大値を下回る場合、共有サーバー環境は最適に
チューニングされていると考えられます。
現在の値と平均値が最大値を大きく下回る場合は、ディスパッチャ数の削減を検討してくださ
い。反対に、現在の値と平均値が最大値に近い場合は、ディスパッチャを追加する場合があり
ます。システム使用率が低い期間と高い期間の両方で V$DISPATCHER_RATE 統計を調べてみ
ることを一般規則としてお薦めします。共有サーバーの負荷パターンを識別した後で、それに
従ってパラメータを調整します。
必要であれば、システムのストレス・テストを実行し、定期的に V$DISPATCHER_RATE 統計
をポーリングすることによってワークロードをシミュレートすることもできます。これらの統
4-8
Oracle Database パフォーマンス・チューニング・ガイド
共有サーバーのパフォーマンスの考慮事項
計の正しい解釈方法は、プラットフォームごとに異なります。アプリケーションの種類が変わ
ると、V$DISPATCHER_RATE に記録される統計値も大幅に異なる可能性があります。
関連項目 :
■
■
V$DISPATCHER および V$DISPATCHER_RATE ビューの詳細は、
『Oracle Database リファレンス』を参照してください。
統計を監視する Oracle Tuning Pack アプリケーションの詳細は、
『Oracle Enterprise Manager 概要』を参照してください。
ディスパッチャ・プロセスの競合の低減
競合を低減するには、次の点を考慮してください。
■
ディスパッチャ・プロセスの追加
ディスパッチャ・プロセスの総数は、MAX_DISPATCHERS 初期化パラメータの値で制限さ
れます。ディスパッチャ・プロセスを追加する前に、この値を増やす必要がある場合があ
ります。
■
接続プーリングの使用可能化
システム負荷が増加し、ディスパッチャ・スループットが最大限になった場合は、すぐに
ディスパッチャを追加することが必ずしも適切とはかぎりません。そのかわりに、接続
プーリングによってより多くのユーザーをサポートできるようにディスパッチャを構成す
ることを検討してください。
■
セッション多重化の有効化
多重化は、Connection Manager プロセスで、複数ユーザーから個別のディスパッチャへの
ネットワーク・セッションを確立およびメンテナンスする場合に使用されます。たとえば、
いくつかのユーザー・プロセスが Connection Manager プロセスからの 1 つの接続を経由
して 1 つのディスパッチャに接続できます。ディスパッチャ・プロセスが最大限に使用さ
れるため、セッションの多重化は有効です。多重化は、ディスパッチャ間のデータベー
ス・リンク・セッションを多重化する場合にも役立ちます。
関連項目 :
■
■
■
ディスパッチャ・プロセスの構成の詳細は、
『Oracle Database 管理者
ガイド』を参照してください。
接続プーリングの構成の詳細は、
『Oracle Database Net Services 管理
者ガイド』を参照してください。
DISPATCHERS および MAX_DISPATCHERS パラメータの詳細は、
『Oracle Database リファレンス』を参照してください。
パフォーマンスを考慮したデータベースの構成
4-9
共有サーバーのパフォーマンスの考慮事項
共有サーバー・プロセスの競合の識別
この項では、共有サーバーの競合を識別する方法を説明します。
要求キューにおいて待機時間が一貫して増加する場合、それは共有サーバーの競合を示します。
待機時間のデータを調べるには、動的パフォーマンス・ビュー V$QUEUE を使用します。この
ビューには、共有サーバーの要求キューのアクティビティを示す統計が含まれます。デフォル
トでは、ユーザー SYS および SYSTEM のような、SELECT ANY TABLE システム権限を持ってい
るユーザーのみがこのビューを利用できます。表 4-3 は、要求の待機時間とキュー内の要求の
数を示す列をリストしたものです。
表 4-3 V$QUEUE 内の待機時間と要求列
列
説明
WAIT
キューに存在していた全要求についての待機時間の合計（100 分
の 1 秒単位）
TOTALQ
キューに存在していた要求の総数
アプリケーションの実行時に次の 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
共有サーバーでのリソース競合を検出した場合は、まず、共有プールとラージ・プールを調査
し、これがメモリー競合でないことを確認します。パフォーマンスが改善されない場合は、共
有サーバー・プロセス競合を低減するためにさらにリソースを作成してください。その場合は、
オプションのサーバー・プロセス初期化パラメータを変更します。
■
MAX_DISPATCHERS
■
MAX_SHARED_SERVERS
■
DISPATCHERS
■
SHARED_SERVERS
関連項目 : 共有サーバー・プロセスの初期化パラメータの設定の詳細は、
『Oracle Database 管理者ガイド』を参照してください。
4-10
Oracle Database パフォーマンス・チューニング・ガイド
5
自動パフォーマンス統計
この章では、パフォーマンス統計の収集について説明します。この章には次の項があります。
■
データ収集の概要
■
自動ワークロード・リポジトリの概要
■
自動ワークロード・リポジトリの管理
自動パフォーマンス統計
5-1
データ収集の概要
データ収集の概要
パフォーマンスの問題を効果的に診断するには、統計が使用可能である必要があります。
Oracle では、システム、セッションおよび個々の SQL 文について様々なタイプの累積的な統計
が収集されます。また、セグメントとサービスに関する累積的な統計も追跡されます。このよ
うな有効範囲内でパフォーマンスの問題を分析する場合、通常は、問題となる期間中の統計の
変化（デルタ値）を調べます。特に、期間開始時における統計の累積値と終了時における累積
値の違いを調べます。
統計の累積値は、通常、V$SESSTAT および V$SYSSTAT ビューなどの動的パフォーマンス・
ビューを介して使用できます。動的ビューの累積値は、データベース・インスタンスの停止時
にリセットされることに注意してください。自動ワークロード・リポジトリ（AWR）は、セッ
ション・レベルを除くすべてのレベルでほとんどの統計の累積値とデルタ値を自動的に存続さ
せます。この処理は定期的に繰り返され、その結果は AWR スナップショットと呼ばれます。
スナップショットにより取得されるデルタ値は、期間中の各統計の変化を表します。5-8 ページ
の「自動ワークロード・リポジトリの概要」を参照してください。
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 データとの相関
付けもできます。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』
を参照してください。
この項では、次の項目について説明します。
5-2
■
データベース統計
■
オペレーティング・システム統計
■
統計の解釈
Oracle Database パフォーマンス・チューニング・ガイド
データ収集の概要
データベース統計
データベース統計には、データベースの負荷のタイプ、およびデータベースで使用される内部
リソースと外部リソースに関する情報が提供されます。この項では、重要な次の統計について
説明します。
■
待機イベント
■
時間モデル統計
■
Active Session History（ASH）
■
システム統計とセッション統計
待機イベント
待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示す
ために、サーバー・プロセス / スレッドによって増やされる統計です。待機イベント・データ
は、ラッチの競合、バッファの競合、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 です。この統計はインスタンスのワークロード合計のイ
ンジケータであり、データベース・コールの合計所要時間を表します。この統計は、アイドル
待機イベント（アイドル状態でないユーザー・セッション）で待機していない全セッションの
CPU タイムと待機時間を集計することで計算されます。
DB time は、インスタンスの起動時から累積的に測定されます。DB time はアイドル状態でな
い全ユーザー・セッションの時間の合計として計算されるため、インスタンス起動後の実際の
経過時間を超える場合があります。たとえば、30 分実行されているインスタンスに 4 つのアク
ティブ・ユーザー・セッションがあり、その累積 DB time が約 120 分となる場合があります。
自動パフォーマンス統計
5-3
データ収集の概要
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 識別子
■
オブジェクト数、ファイル数およびブロック数
■
待機イベント識別子およびパラメータ
■
セッション識別子およびセッション・シリアル番号
■
モジュールおよびアクション名
■
セッションのクライアント識別子
■
サービス・ハッシュ識別子
関連項目 : V$ACTIVE_SESSION_HISTORY ビューの詳細は、
『Oracle
Database リファレンス』を参照してください。
指定した期間の Active Session History 情報は、1 つのレポートに収集できます。詳細は、5-20
ページの「Active Session History レポートの生成」を参照してください。
システム統計とセッション統計
V$SYSSTAT および V$SESSTAT ビューを使用すると、システム・レベルとセッション・レベル
で多数の累積的データベース統計を使用できます。
関連項目 : V$SYSSTAT および V$SESSTAT ビューの詳細は、
『Oracle
Database リファレンス』を参照してください。
5-4
Oracle Database パフォーマンス・チューニング・ガイド
データ収集の概要
オペレーティング・システム統計
オペレーティング・システム統計は、オペレーティング・システム自体のパフォーマンスのみ
でなく、システムの主要ハードウェア・コンポーネントの使用率やパフォーマンスも提供しま
す。この情報は、CPU サイクルや物理メモリーなどのリソースがすべて使用される可能性を検
出し、ディスク・ドライブなどの周辺機器のパフォーマンスの低下を検出するために重要です。
オペレーティング・システム統計は、ハードウェアやオペレーティング・システムの稼働状態
のみを示します。システム・パフォーマンスの分析担当者の多くは、ハードウェア・リソース
の不足に対してハードウェアを増設することで対応します。これは、オペレーティング・シス
テム統計に示される一連の症状に対する対処療法です。医師が診断を下すときに患者の体温、
脈拍および身体的痛みを参考にするのと同じように、オペレーティング・システム統計は診断
ツールとみなすのが最適です。ボトルネックを識別するには、パフォーマンス分析の対象と
なっているシステム内の全サーバーのオペレーティング・システム統計を収集します。
オペレーティング・システム統計には次のものが含まれます。
■
CPU 統計
■
仮想メモリー統計
■
ディスク統計
■
ネットワーク統計
オペレーティング・システム統計の収集ツールについては、5-6 ページの「オペレーティング・
システムのデータ収集ツール」を参照してください。
CPU 統計
CPU 使用率は、チューニング・プロセスで最も重要なオペレーティング・システム統計です。
システム全体の CPU 使用率と、マルチプロセッサ環境での各 CPU の使用率を取得します。各
CPU の使用率から、シングル・スレッドおよび拡張性の問題を検出できます。
ほとんどのオペレーティング・システムでは、CPU 使用率を、ユーザー領域またはユーザー・
モードでの経過時間と、カーネル領域またはカーネル・モードでの経過時間でレポートします。
この追加統計情報を使用すると、CPU 上で実際に何が実行されているかをより詳細に分析でき
ます。
Oracle データ・サーバー・システムでは、通常はアプリケーションが 1 つのみ実行され、サー
バーはユーザー領域でデータベース・アクティビティを実行します。データベース要求に対す
るサービスの提供に必要なアクティビティ（スケジューリング、同期、I/O、メモリー管理、
プロセス / スレッドの作成と破棄など）は、カーネル・モードで実行されます。すべての CPU
がフルに活用されているシステムでは、健全な Oracle システムの場合、その 65% から 95% が
ユーザー領域で実行されます。
V$OSSTAT ビューではデータベース内のシステム・レベルの情報が収集され、ハードウェア・
レベルのリソースに問題があるかどうかを容易に判断できます。V$SYSMETRIC_HISTORY
ビューでは、ホスト CPU 使用率測定値の 1 時間の履歴と、1 分ごとの間隔での CPU 使用率の
割合表示が示されます。V$SYS_TIME_MODEL ビューには、Oracle データベースによる CPU 使
用率の統計が表示されます。両方の統計セットを使用すると、Oracle データベースや他のシス
テムのアクティビティが CPU の問題の原因となっているかどうかを判断できます。
仮想メモリー統計
仮想メモリー統計は、主として、システム上でページングまたはスワッピングのアクティビ
ティがほとんど発生していないことを検証するために使用します。ページングまたはスワッピ
ングが発生すると、システム・パフォーマンスは急速かつ予想外に低下します。
個々のプロセスのメモリー統計を使用すると、プログラミングの失敗でプロセス・ヒープから
取得したメモリーを割当て解除できなかったことによるメモリー・リークを検出できます。こ
の統計を使用すると、システムが起動後に安定状態に達した後、メモリー使用量が増加してい
ないことを確認できます。このメモリー使用量増加の問題は、中間層システムの共有サーバー・
アプリケーションで、セッション状態が複数のユーザーの対話にまたがって存続するために、
メモリーの割当てが完全に解除されないという完了時状態情報がある場合は、特に深刻です。
自動パフォーマンス統計
5-5
データ収集の概要
ディスク統計
データベースは一連のディスク上に常駐しているため、データベースのパフォーマンスにとっ
ては I/O サブシステムのパフォーマンスが非常に重要になります。ほとんどのオペレーティン
グ・システムでは、ディスク・パフォーマンスに関する詳細な統計が提供されます。最も重要
なディスク統計は、現在の応答時間とディスク・キューの長さです。この統計は、ディスクが
最適な状態で実行されているか、または過度の使用状態にあるかを示します。
I/O システムの通常のパフォーマンスを測定します。1 ブロックの読取りに関する標準値は、
使用中のハードウェアに応じて 5 ～ 20 ミリ秒です。ハードウェアが通常のパフォーマンス値を
大幅に上回る応答時間を示している場合は、不適切な状態で実行されているか過度の使用状態
にあります。これがボトルネックです。ディスク・キューが 2 つを超えると、そのディスクが
システムのボトルネックになる可能性があります。
ネットワーク統計
ネットワーク統計はディスク統計とほぼ同じように使用でき、ネットワークまたはネットワー
ク・インタフェースが過負荷になっているかどうか、または最適に実行されているかどうかを
判断できます。今日のネットワーク・アプリケーションでは、ネットワーク待機時間が実際の
ユーザー応答時間の大部分を占めることがあります。このため、この統計は重要なデバッグ・
ツールです。
オペレーティング・システムのデータ収集ツール
表 5-1 は、UNIX でのオペレーティング・システム統計収集ツールを示します。Windows の場
合は、パフォーマンス・モニタ・ツールを使用します。
表 5-1 オペレーティング・システム統計収集用の UNIX ツール
コンポーネント UNIX ツール
CPU
sar、vmstat、mpstat、iostat
メモリー
sar、vmstat
ディスク
sar、iostat
ネットワーク
netstat
統計の解釈
最初にパフォーマンス・データを調査するときは、統計を調べることによって潜在的な理論を
構築できます。統計の解釈が正しいかどうかを確認する 1 つの方法は、他のデータとのクロス
チェックを行うことです。これにより、統計またはイベントが実際に対象のものであるかどう
かがわかります。
ここではいくつかの陥りやすい誤りについて説明します。
■
ヒット率
チューニングを行う場合は、問題があるかどうかを容易に判断するために、比率を計算す
ることが一般的です。そのような率には、バッファ・キャッシュ・ヒット率、ソフト解析
率およびラッチ・ヒット率があります。これらの率を、パフォーマンス・ボトルネックが
あるかどうかを厳密に判断する識別子として使用しないでください。むしろ、インジケー
タとして使用してください。ボトルネックがあるかどうかを識別するには、他の関連する
証拠を調べる必要があります。7-8 ページの「バッファ・キャッシュ・ヒット率の計算」を
参照してください。
■
時間統計のある待機イベント
インスタンス・レベルで TIMED_STATISTICS を TRUE に設定すると、Oracle サーバーは
すでに使用できる待機カウントの他にイベントの待機時間を収集します。このデータは、
イベントの合計待機時間をパフォーマンス・データ収集間の総経過時間と比較する場合に
役立ちます。たとえば、待機イベントが 2 時間の期間のうちのわずか 30 秒であれば、この
イベントが待機時間別に順序付けされるときに最高ランクの待機イベントであっても、こ
のイベントを調べて得られるものはほとんどありません。ただし、イベントが 45 分間のう
5-6
Oracle Database パフォーマンス・チューニング・ガイド
データ収集の概要
ちの 30 分であれば、そのイベントは調べる価値があります。5-3 ページの「待機イベント」
を参照してください。
注意 : 初期化パラメータ 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 が正しくない場合、イベントの待機時間は使用できません。した
がって、各イベントを待機した時間数で待機イベントを順序付けることのみ可能です。最
大待機回数を持つイベントが潜在的なボトルネックを示すことがありますが、主要なボト
ルネックとは言えません。これはイベントを長時間待つ場合に発生する可能性があります
が、そのイベントを待つ合計待機時間は短時間です。その逆もなりたちます。待機回数が
少ないイベントは、その待機時間が合計待機時間の大きな割合を占めている場合に問題に
なることがあります。比較のために使用する待機時間がなければ、待機イベントが実際に
重要かどうかの判断は困難です。
■
アイドル待機イベント
Oracle では、いくつかの待機イベントを使用して、Oracle サーバー・プロセスがアイドル
状態であるかどうかを示します。一般に、これらのイベントはパフォーマンスの問題を調
べるときは有効でなく、待機イベントを調べるときは無視する必要があります。10-34 ペー
ジの「アイドル待機イベント」を参照してください。
■
計算済統計
計算済統計（割合、トランザクションごとに正規化された統計、比率など）を解釈する場
合は、計算済統計を実際の統計カウントと相互検査することが重要です。その検査で、導
出レートが実際に重要かどうかが確認されます。通常、小さな統計カウントにより、異常
な比率を除外できます。たとえば、最初の検査で、ソフト解析率 50% は、一般に潜在的な
チューニング領域を示します。ただし、データ収集期間にハード解析が 1 つとソフト解析
が 1 つのみあった場合、この領域が重要な領域でないことを統計カウントが示していても、
ソフト解析率は 50% になります。この場合、統計カウントが低いため、比率は重要ではあ
りません。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-5 ページの「統計収集のレベ
ルの設定」を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
自動パフォーマンス統計
5-7
自動ワークロード・リポジトリの概要
自動ワークロード・リポジトリの概要
自動ワークロード・リポジトリ（AWR）では、問題の検出および自己チューニングを目的とし
て、パフォーマンス統計が収集、処理および保守されます。このデータはメモリーとデータ
ベースの両方に格納されます。収集されたデータは、レポートとビューの両方に表示できます。
AWR により収集され処理される統計は、次のとおりです。
■
■
■
■
■
データベース・セグメントのアクセス統計と使用統計を決定するオブジェクト統計。
アクティビティの時間使用に基づく時間モデル統計。V$SYS_TIME_MODEL および
V$SESS_TIME_MODEL ビューに表示されます。
V$SYSSTAT および V$SESSTAT ビューで収集されるシステム統計とセッション統計の一
部。
システム上で最大負荷を生成している SQL 文。経過時間や CPU タイムなどの基準に基づき
ます。
最新のセッション・アクティビティの履歴を表す Active Session History（ASH）統計。
自動ワークロード・リポジトリを使用可能にするには、STATISTICS_LEVEL 初期化パラメー
タを TYPICAL または ALL に設定する必要があります。この値を BASIC に設定すると、
DBMS_WORKLOAD_REPOSITORY パッケージのプロシージャを使用して AWR を手動で収集でき
ます。ただし、STATISTICS_LEVEL パラメータを BASIC に設定すると、セグメント統計やメ
モリー・アドバイザ情報など、多数のシステム統計のメモリー内収集機能がオフになるため、
手動で収集したスナップショットにはこれらの統計が含まれず、不完全なものになります。
この項では、自動ワークロード・リポジトリに関する次の項目について説明します。
■
スナップショット
■
ベースライン
■
領域使用量
関連項目 : STATISTICS_LEVEL 初期化パラメータの詳細は、『Oracle
Database リファレンス』を参照してください。
スナップショット
スナップショットは、ADDM によりパフォーマンスの比較に使用される、特定の期間の履歴
データのセットです。AWR では、デフォルトで 1 時間ごとにパフォーマンス・データのスナッ
プショットが自動的に生成され、ワークロード・リポジトリに統計が 7 日間保持されます。ス
ナップショットを手動で作成することもできますが、通常は必要ありません。スナップショッ
ト間隔内のデータは、Automatic Database Diagnostic Monitor（ADDM）によって分析されま
す。ADDM の詳細は、6-3 ページの「Automatic Database Diagnostic Monitor」を参照してく
ださい。
AWR は、スナップショット間の違いを比較し、システム負荷への影響に基づいて収集する
SQL 文を判別します。これにより、期間中に収集する必要のある SQL 文の数が減少します。
スナップショットの管理については、5-10 ページの「スナップショットの管理」を参照してく
ださい。
5-8
Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリの概要
ベースライン
ベースラインには、パフォーマンス上の問題が発生したときに、類似する他のワークロード期
間と比較するために保持される、特定期間中のパフォーマンス・データが含まれています。
ベースラインに含まれているスナップショットは、自動 AWR パージ処理から除外され、無期
限に保持されます。
ベースラインの管理については、5-12 ページの「ベースラインの管理」を参照してください。
領域使用量
自動ワークロード・リポジトリによる使用領域は、次のように複数の要因によって決定されま
す。
■
特定の時点におけるシステム内のアクティブ・セッション数
■
スナップショット間隔
スナップショット間隔により、スナップショットの収集頻度が決定されます。スナップ
ショット間隔が短いほど頻度が高くなり、自動ワークロード・リポジトリにより収集され
るデータ量が増大します。
■
履歴データの保存期間
保存期間により、このデータが消去前に保持されている期間が決定されます。保存期間が
長いほど、自動ワークロード・リポジトリによる領域使用量が増大します。
デフォルトでは、スナップショットは 1 時間ごとに収集され、データベースに 7 日間保存され
ます。これらのデフォルト設定では、同時アクティブ・セッション数が平均 10 の標準的なシス
テムの場合、AWR データ用に約 200 ～ 300 MB の領域が必要になる可能性があります。スナッ
プショット間隔と保存期間のデフォルト値は、どちらも変更できます。AWR 設定の変更につい
ては、5-11 ページの「スナップショット設定の変更」を参照してください。
スナップショット間隔を長くして保存期間を短縮すると、自動ワークロード・リポジトリの領
域使用量を減らすことができます。保存期間を短縮する場合は、Oracle の複数の自己管理機能
が AWR データの正常な機能に依存することに注意してください。十分なデータがないと、次
のようなコンポーネントと機能の妥当性および正確さに影響する可能性があります。
■
Automatic Database Diagnostic Monitor
■
SQL チューニング・アドバイザ
■
UNDO アドバイザ
■
セグメント・アドバイザ
可能な場合は、少なくとも 1 つのワークロード・サイクル全体を取得できるように、AWR 保存
期間を十分な長さに設定することをお薦めします。システムのワークロード・サイクルが平日
に OLTP ワークロード、週末にバッチ・ジョブというような週単位になっている場合、デフォ
ルトの AWR 保存期間である 7 日を変更する必要はありません。ただし、月末の帳簿締め処理
時にシステムの月次ピーク負荷が発生する場合は、保存期間を 1 か月に設定する操作が必要に
なることがあります。
例外的な状況では、スナップショット間隔を 0（ゼロ）に設定して、自動スナップショット収
集を完全にオフにできます。この場合、ワークロードおよび統計データの自動収集は停止され、
Oracle の自己管理機能の大部分が動作しなくなります。また、スナップショットも手動で作成
できなくなります。このため、自動スナップショット収集はオフにしないことをお薦めします。
自動パフォーマンス統計
5-9
自動ワークロード・リポジトリの管理
自動ワークロード・リポジトリの管理
この項では、自動ワークロード・リポジトリの管理方法に関する次の項目について説明します。
■
スナップショットの管理
■
ベースラインの管理
■
自動ワークロード・リポジトリ・データの転送
■
自動ワークロード・リポジトリ・ビューの使用
■
自動ワークロード・リポジトリ・レポートの生成
■
Active Session History レポートの生成
自動ワークロード・リポジトリについては、5-8 ページの「自動ワークロード・リポジトリの概
要」を参照してください。
スナップショットの管理
Oracle Database では、デフォルトで 1 時間ごとにスナップショットが自動的に生成され、ワー
クロード・リポジトリに統計が 7 日間保持されます。必要な場合は、
DBMS_WORKLOAD_REPOSITORY プロシージャを使用してスナップショットを手動で作成、削除
および変更できます。これらのプロシージャを起動するには、DBA ロールが付与されている必
要があります。スナップショットの詳細は、5-8 ページの「スナップショット」を参照してくだ
さい。
自動ワークロード・リポジトリ管理用の主インタフェースは Oracle Enterprise Manager です。
スナップショットの管理には、できるかぎり Oracle Enterprise Manager を使用する必要があり
ます。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照して
ください。Oracle Enterprise Manager を使用できない場合は、この項で説明するように、
DBMS_WORKLOAD_REPOSITORY パッケージを使用して AWR スナップショットとベースライン
を管理できます。
この項では、次の項目について説明します。
■
スナップショットの作成
■
スナップショットの削除
■
スナップショット設定の変更
関連項目 : DBMS_WORKLOAD_REPOSITORY パッケージの詳細は、
『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リ
ファレンス』を参照してください。
スナップショットの作成
自動生成されたスナップショットとは異なる時点の統計を収集する場合は、
CREATE_SNAPSHOT プロシージャにより、手動でスナップショットを作成できます。たとえば、
次のようにします。
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
この例では、インスタンスのスナップショットがただちに作成され、フラッシュ・レベルは、
デフォルトのフラッシュ・レベルである TYPICAL に指定されます。このスナップショットは、
DBA_HIST_SNAPSHOT ビューに表示できます。
5-10
Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリの管理
スナップショットの削除
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 の値を指定しない場合は、デフォルト値と
してローカル・データベース識別子が使用されます。
DROP_SNAPSHOT_RANGE プロシージャがコールされると、スナップショット範囲で指定された
期間に属する Active Session History データ（ASH）もパージされます。
スナップショット設定の変更
指定したデータベース ID について、スナップショット生成の間隔、保存および取得済上位
SQL を調整できますが、こうすると Oracle 診断ツールの精度に影響する可能性があるので注意
してください。
INTERVAL の設定は、スナップショットの自動生成の頻度（分単位）に影響します。
RETENTION の設定は、スナップショットがワークロード・リポジトリに格納される時間の長さ
（分単位）に影響します。TOPNSQL の設定は、各 SQL 基準（経過時間、CPU 時間、解析コー
ル、共有可能メモリー、バージョン・カウント）についてフラッシュするための上位 SQL の数
に影響します。この設定の値は、統計またはフラッシュ・レベルによる影響を受けず、AWR
SQL 収集のシステムのデフォルト動作より優先されます。この設定の値を MAXIMUM に設定し
て、カーソル・キャッシュ内の完全な SQL セットを取得できます。ただし、そうする（または
非常に高い値に設定する）ことで、収集して保存するデータがさらに多くなるため、可能な領
域とパフォーマンスが問題になることがあります。この設定を調整するには、
MODIFY_SNAPSHOT_SETTINGS プロシージャを使用します。たとえば、次のようにします。
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
interval => 30, topnsql => 100, dbid => 3310949047);
END;
/
この例では、保存期間は 43,200 分（30 日）
、各スナップショットの間隔は 30 分、各 SQL 基準
についてフラッシュするための上位 SQL 数は 100 と指定されています。NULL が指定された場
合、既存の値が保存されます。オプションのデータベース識別子は 3310949047 です。dbid
の値を指定しない場合は、デフォルト値としてローカル・データベース識別子が使用されます。
DBA_HIST_WR_CONTROL ビューを使用すると、データベース・インスタンスの現在の設定を確
認できます。
自動パフォーマンス統計
5-11
自動ワークロード・リポジトリの管理
ベースラインの管理
この項では、ベースラインの管理方法について説明します。ベースラインの詳細は、5-9 ページ
の「ベースライン」を参照してください。
スナップショット管理用の主インタフェースは Oracle Enterprise Manager です。スナップ
ショットの管理には、できるかぎり Oracle Enterprise Manager を使用する必要があります。詳
細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照してください。
Oracle Enterprise Manager を使用できない場合は、以降の各項で説明するように、
DBMS_WORKLOAD_REPOSITORY パッケージを使用してスナップショットを管理できます。
■
ベースラインの作成
■
ベースラインの削除
ベースラインの作成
この項では、既存範囲のスナップショットを使用してベースラインを作成する方法について説
明します。
ベースラインを作成する手順は、次のとおりです。
1.
DBA_HIST_SNAPSHOT ビューで既存のスナップショットを検討し、使用するスナップ
ショットの範囲を決定します。
2.
CREATE_BASELINE プロシージャを使用し、必要な範囲のスナップショットを使用して
ベースラインを作成します。
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 270,
end_snap_id => 280, baseline_name => 'peak baseline',
dbid => 3310949047, expiration => 30);
END;
/
この例では、270 は開始スナップショットの順序番号であり、280 は終了スナップショッ
トの順序です。ベースライン名は peak baseline です。オプションのデータベース識別
子は 3310949047 です。dbid の値を指定しない場合は、デフォルト値としてローカル・
データベース識別子が使用されます。オプションの expiration パラメータが 30 に設定
されているため、ベースラインは 30 日後に期限切れになって自動的に削除されます。
expiration の値を指定しなければ、ベースラインが期限切れになることはありません。
ベースラインが作成されると、一意のベースライン ID が新規ベースラインに自動的に割り当て
られます。ベースライン ID とデータベース識別子は、DBA_HIST_BASELINE ビューに表示さ
れます。
ベースラインの削除
この項では、既存のベースラインを削除する方法について説明します。ディスク領域を節約す
るために、使用しなくなったベースラインを定期的に削除する必要があります。ベースライン
に関連付けられているスナップショットは、ベースラインを明示的に削除するか、またはベー
スラインが期限切れになるまで、無期限に保持されます。
ベースラインを削除する手順は、次のとおりです。
1.
DBA_HIST_BASELINE ビューで既存のベースラインを検討し、削除するベースラインを決
定します。
2.
DROP_BASELINE プロシージャを使用して、対象のベースラインを削除します。
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'peak baseline',
cascade => FALSE, dbid => 3310949047);
END;
/
5-12
Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリの管理
この例では、ベースライン名は peak baseline です。cascade パラメータは、ベースラ
インのみを削除するように指定する FALSE に設定されています。このパラメータを TRUE
に設定すると、削除操作によって、ベースラインに関連付けられたスナップショットも削
除するように指定したことになります。オプションの dbid パラメータでは、データベース
識別子（この例では 3310949047）を指定します。dbid の値を指定しない場合は、デ
フォルト値としてローカル・データベース識別子が使用されます。
自動ワークロード・リポジトリ・データの転送
Oracle Database では、AWR データをシステム間で転送できます。これは、AWR データの分析
に別のシステムを使用する必要がある場合に役立ちます。AWR データを転送するには、以降の
各項で説明するように、まずソース・システム上のデータベースから AWR スナップショット・
データを抽出し、次にそのデータをターゲット・システム上のデータベースにロードする必要
があります。
■
AWR データの抽出
■
AWR データのロード
AWR データの抽出
awrextr.sql スクリプトにより、一定範囲のスナップショットの AWR データが、データ
ベースからデータ・ポンプ・エクスポート・ファイルに抽出されます。作成後、このダンプ・
ファイルを別のシステムに転送し、そこで抽出データをロードできます。awrextr.sql スクリ
プトを実行するには、データベースに SYS ユーザーとして接続している必要があります。
AWR データを抽出する手順は、次のとおりです。
1.
SQL プロンプトから次のように入力します。
@$ORACLE_HOME/rdbms/admin/awrextr.sql
AWR スキーマ内のデータベースのリストが表示されます。
2.
AWR データの抽出元データベースを指定します。
Enter value for db_id: 1377863381
この例では、データベース識別子 1377863381 を持つデータベースが選択されています。
3.
スナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days: 2
指定した期間範囲の既存のスナップショットのリストが表示されます。この例では、過去 2
日間に取得されたスナップショットが表示されます。
4.
開始スナップショット ID と終了スナップショット ID を指定して、AWR データの抽出対
象となるスナップショットの範囲を定義します。
Enter value for begin_snap: 30
Enter value for end_snap: 40
この例では、スナップショット ID が 30 のスナップショットが開始スナップショットとし
て選択され、スナップショット ID が 40 のスナップショットが終了スナップショットとし
て選択されています。
5.
ディレクトリ・オブジェクトのリストが表示されます。
エクスポート・ダンプ・ファイルの格納先ディレクトリを指すディレクトリ・オブジェク
トを指定します。
Enter value for directory_name: DATA_PUMP_DIR
この例では、ディレクトリ・オブジェクト DATA_PUMP_DIR が選択されています。
自動パフォーマンス統計
5-13
自動ワークロード・リポジトリの管理
6.
エクスポート・ダンプ・ファイル名の接頭辞を指定します（接尾辞 .dmp は自動的に追加
されます）
。
Enter value for file_name: awrdata_30_40
この例では、指定したディレクトリ・オブジェクトに対応するディレクトリに、
awrdata_30_40 というエクスポート・ダンプ・ファイルが作成されます。
Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
C:¥ORACLE¥PRODUCT¥11.1.0.5¥DB_1¥RDBMS¥LOG¥AWRDATA_30_40.DMP
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 08:58:20
抽出する必要のある AWR データの量によっては、AWR 抽出操作が完了するまでに時間が
かかることがあります。ダンプ・ファイルが作成された後、データ・ポンプを使用して
ファイルを別のシステムに転送できます。
関連項目 : データ・ポンプの使用方法は、『Oracle Database ユーティリ
ティ』を参照してください。
AWR データのロード
エクスポート・ダンプ・ファイルをターゲット・システムに転送した後、awrload.sql スク
リプトを使用して、抽出した AWR データをロードできます。awrload.sql スクリプトでは、
最初にステージング・スキーマが作成され、そこでスナップショット・データがデータ・ポン
プ・ファイルからデータベースに転送されます。次に、データがステージング・スキーマから
適切な AWR 表に転送されます。awrload.sql スクリプトを実行するには、データベースに
SYS ユーザーとして接続している必要があります。
AWR データをロードする手順は、次のとおりです。
1.
SQL プロンプトから次のように入力します。
@$ORACLE_HOME/rdbms/admin/awrload.sql
ディレクトリ・オブジェクトのリストが表示されます。
2.
エクスポート・ダンプ・ファイルがあるディレクトリを指すディレクトリ・オブジェクト
を指定します。
Enter value for directory_name: DATA_PUMP_DIR
この例では、ディレクトリ・オブジェクト DATA_PUMP_DIR が選択されています。
3.
エクスポート・ダンプ・ファイル名の接頭辞を指定します（接尾辞 .dmp は自動的に追加
されます）
。
Enter value for file_name: awrdata_30_40
この例では、awrdata_30_40 というエクスポート・ダンプ・ファイルが選択されています。
4.
AWR データのロード先となるステージング・スキーマの名前を指定します。
Enter value for schema_name: AWR_STAGE
この例では、AWR データのロード用に AWR_STAGE というステージング・スキーマが作成
されます。
5.
ステージング・スキーマのデフォルト表領域を指定します。
Enter value for default_tablespace: SYSAUX
この例では、SYSAUX 表領域が選択されています。
6.
ステージング・スキーマの一時表領域を指定します。
Enter value for temporary_tablespace: TEMP
この例では、TEMP 表領域が選択されています。
5-14
Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリの管理
7.
AWR データのロード用に AWR_STAGE というステージング・スキーマが作成されます。
AWR データは AWR_STAGE スキーマにロードされた後、SYS スキーマ内の AWR 表に転送
されます。
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Completed 113 CONSTRAINT objects in 11 seconds
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Completed 1 REF_CONSTRAINT objects in 1 seconds
Job "SYS"."SYS_IMPORT_FULL_03" successfully completed at 09:29:30
... Dropping AWR_STAGE user
End of AWR Load
ロードする必要のある AWR データの量によっては、AWR ロード操作が完了するまでに時
間がかかることがあります。AWR データのロード後、ステージング・スキーマは自動的に
削除されます。
自動ワークロード・リポジトリ・ビューの使用
通常、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 には、システム内のスナップショットの情報が表示されます。
■
DBA_HIST_SQL_PLAN には、SQL 実行計画が表示されます。
■
DBA_HIST_WR_CONTROL には、AWR 制御用の設定が表示されます。
関連項目 : 動的および静的なデータ・ディクショナリ・ビューの詳細は、
『Oracle Database リファレンス』を参照してください。
自動パフォーマンス統計
5-15
自動ワークロード・リポジトリの管理
自動ワークロード・リポジトリ・レポートの生成
AWR レポートは、2 つのスナップショット（または 2 つの時点）間に取得されたデータを示し
ます。AWR レポートは複数のセクションにわかれています。HTML レポートには、セクション
間ですばやくナビゲートできるようにリンクが組み込まれています。レポートの内容には、選
択した範囲のスナップショットに関するシステムのワークロード・プロファイルが含まれます。
AWR レポート生成用の主インタフェースは Oracle Enterprise Manager です。AWR レポートの
生成には、できるかぎり Oracle Enterprise Manager を使用する必要があります。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照してください。Oracle
Enterprise Manager を使用できない場合は、SQL スクリプトを実行して AWR レポートを生成
できます。
■
■
■
■
■
■
awrrpt.sql SQL スクリプトでは、一定範囲のスナップショット ID の統計を表示する、
HTML またはテキストのレポートが生成されます。
awrrpti.sql SQL スクリプトでは、指定されたデータベースおよびインスタンスの一定
範囲のスナップショット ID の統計を表示する、HTML またはテキストのレポートが生成
されます。
awrsqrpt.sql SQL スクリプトでは、一定範囲のスナップショット ID に対する特定の
SQL 文の統計を表示する、HTML またはテキストのレポートが生成されます。SQL 文のパ
フォーマンスを検査またはデバッグする場合にこのレポートを実行します。
awrsqrpi.sql SQL スクリプトでは、指定されたデータベースおよびインスタンスにおけ
る一定範囲のスナップショット ID に対する特定の SQL 文の統計を表示する、HTML また
はテキストのレポートが生成されます。特定のデータベースおよびインスタンスにおける
SQL 文のパフォーマンスを検査またはデバッグする場合にこのレポートを実行します。
awrddrpt.sql SQL スクリプトでは、選択された 2 つの期間の詳細なパフォーマンス属性
および構成設定を比較する、HTML またはテキストのレポートが生成されます。
awrddrpi.sql SQL スクリプトでは、特定のデータベースおよびインスタンスにおける選
択された 2 つの期間の詳細なパフォーマンス属性および構成設定を比較する、HTML また
はテキストのレポートが生成されます。
注意 : これらのスクリプトを実行するには、DBA ロールが付与されてい
る必要があります。
指定した範囲のスナップショットにワークロード・アクティビティのない
データベースに対してレポートを実行すると、一部のレポート統計につい
て 0 より小さいか 100 を超えるパーセンテージが計算される場合がありま
す。この結果は、単にその統計に意味のある値がないことを意味します。
awrrpt.sql レポートの実行
一定範囲のスナップショット ID の HTML またはテキストのレポートを生成するには、SQL プ
ロンプトから awrrpt.sql スクリプトを実行します。
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定する必要があり
ます。
Enter value for report_type: text
スナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days: 2
リストが表示されると、ワークロード・リポジトリ・レポートの開始スナップショット ID と終
了スナップショット ID の入力が要求されます。
Enter value for begin_snap: 150
Enter value for end_snap: 160
5-16
Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリの管理
次に、デフォルトのレポート名を確定するか、またはレポート名を入力します。次の例ではデ
フォルト名が確定されています。
Enter value for report_name:
Using the report name awrrpt_1_150_160
ワークロード・リポジトリ・レポートが生成されます。
awrrpti.sql レポートの実行
スナップショット ID の範囲を入力する前にデータベースおよびインスタンスを指定するには、
SQL プロンプトで awrrpti.sql スクリプトを実行して、HTML またはテキストのレポートを
生成します。
@$ORACLE_HOME/rdbms/admin/awrrpti.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定します。その
後、データベース識別子およびインスタンス番号のリストが表示され、次のようになります。
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 レポートの実行」を参
照してください。
awrsqrpt.sql レポートの実行
特定の SQL 文の HTML またはテキストのレポートを生成するには、SQL プロンプトから
awrsqrpt.sql スクリプトを実行します。
@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定する必要があり
ます。
Enter value for report_type: text
スナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days: 1
リストが表示されると、ワークロード・リポジトリ・レポートの開始スナップショット ID と終
了スナップショット ID の入力が要求されます。
Enter value for begin_snap: 146
Enter value for end_snap: 147
特定の SQL 文の SQL ID を指定して統計を表示します。
Enter value for sql_id: 2b064ybzkwf1y
自動パフォーマンス統計
5-17
自動ワークロード・リポジトリの管理
次に、デフォルトのレポート名を確定するか、またはレポート名を入力します。次の例ではデ
フォルト名が確定されています。
Enter value for report_name:
Using the report name awrsqlrpt_1_146_147.txt
ワークロード・リポジトリ・レポートが生成されます。
awrsqrpi.sql レポートの実行
特定の SQL 文の ID を入力する前にデータベースおよびインスタンスを指定するには、SQL プ
ロンプトで awrsqrpi.sql スクリプトを実行して、HTML またはテキストのレポートを生成
します。
@$ORACLE_HOME/rdbms/admin/awrsqrpi.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定する必要があり
ます。
Enter value for report_type: text
次に、データベース識別子およびインスタンス番号のリストが表示され、次のようになります。
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
Using
Enter
Using
value for dbid: 3309173529
3309173529 for database Id
value for inst_num: 1
1 for instance number
次に、awrsqrpt.sql スクリプトと同様に日数、スナップショット ID、SQL ID およびレポー
ト名の入力が要求され、入力するとテキスト・レポートが生成されます。5-17 ページの
「awrsqrpt.sql レポートの実行」を参照してください。
awrddrpt.sql レポートの実行
2 つの期間の詳細なパフォーマンス属性および構成設定を比較するには、SQL プロンプトで次
のように awrddrpt.sql スクリプトを実行して HTML またはテキストのレポートを生成しま
す。
@$ORACLE_HOME/rdbms/admin/awrddrpt.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定する必要があり
ます。
Enter value for report_type: text
第 1 期間のスナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days: 2
リストが表示されると、第 1 期間の開始スナップショット ID と終了スナップショット ID の入
力が要求されます。
Enter value for begin_snap: 102
Enter value for end_snap: 103
5-18
Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリの管理
次に、第 2 期間のスナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days2: 1
リストが表示されると、第 2 期間の開始スナップショット ID と終了スナップショット ID の入
力が要求されます。
Enter value for begin_snap2: 126
Enter value for end_snap2: 127
次に、デフォルトのレポート名を確定するか、またはレポート名を入力します。次の例ではデ
フォルト名が確定されています。
Enter value for report_name:
Using the report name awrdiff_1_102_1_126.txt
ワークロード・リポジトリ・レポートが生成されます。
awrddrpi.sql レポートの実行
比較する期間を選択する前にデータベースおよびインスタンスを指定するには、SQL プロンプ
トで awrddrpi.sql スクリプトを実行して、HTML またはテキストのレポートを生成します。
@$ORACLE_HOME/rdbms/admin/awrddrpi.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定する必要があり
ます。
Enter value for report_type: text
次に、データベース識別子およびインスタンス番号のリストが表示され、次のようになります。
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id
Inst Num DB Name
Instance
----------- -------- ------------ -----------3309173529
1 MAIN
main
3309173529
1 TINT251
tint251
Host
-----------dlsun1690
stint251
プロンプトに、第 1 期間のデータベース識別子（dbid）およびインスタンス番号
（inst_num）の値を入力します。
Enter
Using
Enter
Using
value for dbid: 3309173529
3309173529 for Database Id for the first pair of snapshots
value for inst_num: 1
1 for Instance Number for the first pair of snapshots
第 1 期間のスナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days: 2
リストが表示されると、第 1 期間の開始スナップショット ID と終了スナップショット ID の入
力が要求されます。
Enter value for begin_snap: 102
Enter value for end_snap: 103
次に、プロンプトに、第 2 期間のデータベース識別子（dbid）およびインスタンス番号
（inst_num）の値を入力します。
Enter
Using
Enter
Using
value for dbid2: 3309173529
3309173529 for Database Id for the second pair of snapshots
value for inst_num2: 1
1 for Instance Number for the second pair of snapshots
自動パフォーマンス統計
5-19
自動ワークロード・リポジトリの管理
第 2 期間のスナップショット ID をリストする対象となる日数を指定します。
Enter value for num_days2: 1
リストが表示されると、第 2 期間の開始スナップショット ID と終了スナップショット ID の入
力が要求されます。
Enter value for begin_snap2: 126
Enter value for end_snap2: 127
次に、デフォルトのレポート名を確定するか、またはレポート名を入力します。次の例ではデ
フォルト名が確定されています。
Enter value for report_name:
Using the report name awrdiff_1_102_1_126.txt
ワークロード・リポジトリ・レポートが生成されます。
Active Session History レポートの生成
Active Session History（ASH）レポートを使用して次の分析を実行します。
■
■
通常数分間で収まる一時的なパフォーマンスの問題
時間、セッション、モジュール、アクションまたは SQL_ID など、様々なディメンション
あるいはその組合せによる有効範囲内または目標となるパフォーマンスの分析
Enterprise Manager を使用するか次の SQL スクリプトを実行して、ASH レポートを表示でき
ます。
■
■
ashrpt.sql SQL スクリプトでは、指定された期間の ASH 情報を表示する、HTML また
はテキストのレポートが生成されます。
ashrpti.sql SQL スクリプトでは、指定されたデータベースおよびインスタンスの指定
された期間の ASH 情報を表示する、HTML またはテキストのレポートが生成されます。
レポートは複数のセクションにわかれています。HTML レポートには、セクション間ですばや
くナビゲートできるようにリンクが組み込まれています。レポートの内容には、指定された期
間の、ブロッカ ID および待機中 ID とその関連トランザクション識別子、および SQL の識別に
使用された ASH 情報が含まれています。ASH の詳細は、5-4 ページの「Active Session History
（ASH）」を参照してください。
ASH レポート生成用の主インタフェースは Oracle Enterprise Manager です。ASH レポートの
生成には、できるかぎり Oracle Enterprise Manager を使用する必要があります。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照してください。Oracle
Enterprise Manager を使用できない場合は、以降の各項で説明するように、SQL スクリプトを
実行して ASH レポートを生成できます。
■
ashrpt.sql レポートの実行
■
ashrpti.sql レポートの実行
ashrpt.sql レポートの実行
ASH 情報のテキスト・レポートを生成するには、SQL プロンプトから ashrpt.sql スクリプ
トを実行します。
@$ORACLE_HOME/rdbms/admin/ashrpt.sql
最初に、HTML 形式とテキスト形式のうち、どちらのレポートが必要かを指定する必要があり
ます。
Enter value for report_type: text
5-20
Oracle Database パフォーマンス・チューニング・ガイド
自動ワークロード・リポジトリの管理
最初にシステム日付より前の開始時刻を分単位で指定して、収集する ASH 情報の時間枠を指定
します。
Enter value for begin_time: -10
次に、開始時刻から ASH 情報を収集するレポートの期間を分単位で入力します。次の例では、
システム日付から開始時刻をマイナスしたデフォルトの期間が確定されています。
Enter value for duration:
この例のレポートでは、現在の時刻の 10 分前から開始され、現在の時刻で終了する ASH 情報
が収集されます。次に、デフォルトのレポート名を確定するか、またはレポート名を入力しま
す。次の例ではデフォルト名が確定されています。
Enter value for report_name:
Using the report name ashrpt_1_0310_0131.txt
セッション履歴レポートが生成されます。
ashrpti.sql レポートの実行
データベースおよびインスタンスを指定してから時間枠を設定して ASH 情報を収集する場合
は、SQL プロンプトから ashrpti.sql レポートを実行してテキスト・レポートを生成しま
す。
@$ORACLE_HOME/rdbms/admin/ashrpti.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
次に、ashrpt.sql スクリプトと同様に、ASH 情報収集の開始時刻と期間の入力が要求され、
入力するとレポートが生成されます。5-20 ページの「ashrpt.sql レポートの実行」を参照して
ください。
自動パフォーマンス統計
5-21
自動ワークロード・リポジトリの管理
5-22
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-8 ページの「自動ワークロード・リポジトリの概要」を参照してください。
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 固有の問題 : グローバル・キャッシュのホット・ブロックとオブジェクトはどうなっ
ているか。相互接続遅延の問題があるかどうか。
アプリケーションによる Oracle の不適切な使用 : 不適切な接続管理、過剰な解析またはア
プリケーション・レベルのロック競合による問題があるかどうか。
データベース構成の問題 : 不適切なログ・ファイル・サイズの設定、アーカイブの問題、過
剰なチェックポイントまたは不適切なパラメータ設定を示す兆候があるかどうか。
■
同時実行性の問題 : バッファ・ビジーの問題があるかどうか。
■
様々な問題領域のホット・オブジェクトおよび上位 SQL。
ADDM では、システムの正常領域も文書化されます。たとえば、システムのパフォーマンスに
ほとんど影響しない待機イベント・クラスが識別され、早期段階でチューニング考慮事項から
削除されます。これにより、システム全体のパフォーマンスに影響しない項目に対する時間お
よび労力の節約になります。
自動パフォーマンス診断
6-3
Automatic Database Diagnostic Monitor
ADDM では、問題の診断に加えて可能な解決策も推奨されます。該当する場合は複数の解決策
が推奨され、データベース管理者はその中から選択できます。ADDM では、推奨事項の生成中
にシステムに対する様々な変更が考慮されます。次のような推奨事項があります。
■
ハードウェア変更 : CPU の追加または I/O サブシステム構成の変更
■
データベース構成 : 初期化パラメータ設定の変更
■
■
■
スキーマ変更 : 表または索引のハッシュ・パーティション化、あるいは自動セグメント領域
管理（ASSM）の使用
アプリケーション変更 : 順序付けのためのキャッシュ・オプションの使用またはバインド変
数の使用
その他のアドバイザの使用 : 高負荷 SQL に対する SQL チューニング・アドバイザの実行、
またはホット・オブジェクトに対するセグメント・アドバイザの実行
ADDM の分析結果
ADDM の分析結果は、一連の検出結果として表示されます。ADDM の分析結果の例は、6-4
ページの例 6-1 を参照してください。ADDM の検出結果は、それぞれ次の 3 つのタイプのいず
れかに属します。
■
問題 : データベース・パフォーマンスの問題の根本的な原因を記述する検出結果
■
症状 : 1 つ以上の問題を検出するための情報を含む検出結果
■
情報 : システムの正常領域のレポートに使用される検出結果
問題の検出結果はそれぞれ、その検出結果のパフォーマンスの問題に起因する影響を DB time
に占める割合の見積りとして数量化したものです。問題の検出結果を推奨事項のリストに関連
付けて、パフォーマンスの問題による影響を軽減できます。各推奨事項にはそれぞれメリット
があります。このメリットは、その推奨事項を実装した場合に節約できる DB time の割合を見
積ったものです。推奨事項のリストには、同じ問題に関する様々な代替解決策が含まれる場合
があります。特定の問題を解決するために推奨事項をすべて適用する必要はありません。
推奨事項は、アクションおよび理論的根拠で構成されます。見積もられたメリットを得るため
には、推奨事項のアクションをすべて適用する必要があります。理論的根拠は、一連のアク
ションの推奨理由を説明し、提案された推奨事項の実装に関する追加情報を提供するために使
用されます。
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 合計に占める割合として表示されることに注意してください。理論的根拠は、
6-4
Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
リテラルを使用していてこのパフォーマンスの問題を引き起こした可能性のある SQL 文を追跡
するための追加情報を提供します。データベース管理者は、問題の原因と思われる SQL 文につ
いて指定の計画ハッシュ値を使用すると、少数のサンプル文をすばやく検査できます。
特定の問題に複数の原因がある場合は、ADDM により複数の問題と症状の検出結果がレポート
されることがあります。この場合、複数の検出結果による影響には、DB time が同じ割合で含
まれる可能性があります。検出結果のパフォーマンスの問題はオーバーラップしている場合が
あるため、レポートされた検出結果の影響を合算すると、DB time の 100% を超える場合があ
ります。たとえば、システムで多数の読取り I/O が実行される場合、ADDM では、I/O アク
ティビティによる DB time の 50% に関係する SQL 文が 1 つの検出結果としてレポートされ、
DB time の 75% に関係する小さいサイズのバッファ・キャッシュが別の検出結果としてレポー
トされる場合があります。
問題の検出結果に複数の推奨事項が関連付けられている場合は、それぞれに問題の代替解決策
が含まれていることがあります。この場合、推奨事項によるメリットの合計は検出結果の影響
よりも大きいことがあります。
該当する場合は、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-5
Automatic Database Diagnostic Monitor
ADDM を使用したデータベース・パフォーマンスの問題の診断
Automatic Database Diagnostic Monitor への主インタフェースは、Oracle Enterprise Manager
です。ADDM の実行には、できるかぎり Oracle Enterprise Manager を使用する必要がありま
す。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照してく
ださい。Oracle Enterprise Manager を使用できない場合は、DBMS_ADDM パッケージを使用して
ADDM を実行できます。ユーザーが DBMS_ADDM API を実行するには、ADVISOR 権限が付与さ
れている必要があります。
次の要件が満たされている場合は、データベース・パフォーマンスの問題を診断するために、
任意の 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 パッケージの詳細は、『Oracle Database
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
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
6-6
Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
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 タスクなど、任意
のアドバイザ・タスクを作成して実行できます。アドバイザ・タスクは、ユーザーによるすべ
てのチューニング作業を管理するワークロード・リポジトリ内の実行可能データ領域です。
DBMS_ADVISOR パッケージの典型的な使用方法では、次の操作が必要です。
■
■
DBMS_ADVISOR.CREATE_TASK を使用して、ADDM など、特定タイプのアドバイザ・タ
スクを作成します。
DBMS_ADVISOR.SET_TASK_PARAMETER を使用して、START_SNAPSHOT および
END_SNAPSHOT パラメータなど、特定タイプのタスクを実行するための必須パラメータを
設定します。ADDM タスクの有効なパラメータには次のものがあります。
–
START_SNAPSHOT（必須）
–
END_SNAPSHOT（必須）
–
DB_ID（オプション。デフォルト設定は現行のデータベース）
–
INSTANCE（オプション。デフォルト設定は現行のインスタンス）
–
DBIO_EXPECTED（オプション。デフォルト設定は 10,000 マイクロ秒）
詳細は、6-5 ページの「ADDM の設定」を参照してください。
■
DBMS_ADVISOR.EXECUTE_TASK を使用してタスクを実行します。
■
DBMS_ADVISOR.GET_TASK_REPORT を使用して結果を表示します。
前述の使用例では、PL/SQL ファンクションを記述して、指定した期間に最も近い時点で作成
されたスナップショットを自動的に識別してから ADDM を実行できます。この PL/SQL ファ
ンクションは、次のようなものです。
例 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
自動パフォーマンス診断
6-7
Automatic Database Diagnostic Monitor
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-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 を十分な大きさの値に設定する必要があるこ
とに注意してください。
6-8
Oracle Database パフォーマンス・チューニング・ガイド
Automatic Database Diagnostic Monitor
ADDM 情報を表示するビュー
一般に、Oracle Enterprise Manager または ADDM レポートを使用して、Automatic Database
Diagnostic Monitor からの出力および情報を表示します。ただし、ADDM 情報は
DBA_ADVISOR ビューを使用して表示できます。このグループのビューには次のようなものが
あります。
■
DBA_ADVISOR_TASKS
このビューでは、タスク ID、タスク名および作成日時など、既存のタスクに関する基本情
報が示されます。
■
DBA_ADVISOR_LOG
このビューには、ステータス、進捗、エラー・メッセージおよび実行時間などの現行タス
クの情報が含まれます。
■
DBA_ADVISOR_RECOMMENDATIONS
このビューには、完了した診断タスクの結果と、実行ごとに識別された問題に対する推奨
事項が表示されます。推奨事項は、RANK 列の順序どおりに参照する必要があります。この
順序は、推奨事項における問題の重要性を伝えているためです。BENEFIT 列には、推奨事
項を実行した場合のシステムに対する利点が示されます。
■
DBA_ADVISOR_FINDINGS
このビューには、診断モニターで発見されたすべての事実と症状が、特定の推奨事項とと
もに表示されます。
関連項目 : 静的なデータ・ディクショナリ・ビューの詳細は、『Oracle
Database リファレンス』を参照してください。
自動パフォーマンス診断
6-9
Automatic Database Diagnostic Monitor
6-10
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-2 ページ「自動共有メモリー管理」
■
7-35 ページ「PGA メモリー管理」
Oracle メモリー・キャッシュ
パフォーマンスに影響を与える主な Oracle メモリー・キャッシュは次のとおりです。
■
共有プール
■
ラージ・プール
■
Java プール
■
バッファ・キャッシュ
■
ストリーム・プール・サイズ
■
ログ・バッファ
■
プロセス・プライベート・メモリー（ソートやハッシュ結合に使用されるメモリーなど）
自動共有メモリー管理
自動共有メモリー管理は、SGA の構成を簡素化する、推奨のメモリー構成です。自動共有メモ
リー管理を使用するには、SGA_TARGET 初期化パラメータをゼロ以外の値に設定し、
STATISTICS_LEVEL 初期化パラメータを TYPICAL または ALL に設定します。SGA_TARGET
パラメータの値は、SGA 専用にするメモリーの容量に設定する必要があります。自動 SGA 管
理では、システム上のワークロードに応じて次のメモリー・プールにメモリーが適切に配分さ
れます。
■
データベース・バッファ・キャッシュ（デフォルト・プール）
■
共有プール
■
ラージ・プール
■
Java プール
■
ストリーム・プール
自動的にチューニングされるこれらのメモリー・プールをゼロ以外の値に設定すると、その値
が自動共有メモリー管理における最小レベルとして使用されます。アプリケーション・コン
ポーネントが最小限のメモリーで正常に機能できる場合は、最小値に設定します。
SGA_TARGET は動的パラメータであり、V$SGA_TARGET_ADVICE ビューを問い合せて ALTER
SYSTEM コマンドを使用して変更できます。SGA_TARGET は、SGA_MAX_SIZE 初期化パラメー
タの値以下に設定できます。SGA_TARGET の値の変更により、自動的にチューニングされたメ
モリー・プールが自動的にサイズ変更されます。
7-2
Oracle Database パフォーマンス・チューニング・ガイド
メモリー割当ての問題について
関連項目 :
■
■
自動 SGA 管理の詳細は、『Oracle Database 概要』を参照してくださ
い。
システム・グローバル領域（SGA）の管理の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
インスタンス起動時に値を 0 に設定して動的に SGA_TARGET を無効にする場合、自動共有メモ
リー管理は無効になり、各メモリー・プールには現在の自動チューニングされたサイズが使用
されます。必要であれば、DB_CACHE_SIZE、SHARED_POOL_SIZE、LARGE_POOL_SIZE、
JAVA_POOL_SIZE および STREAMS_POOL_SIZE の初期化パラメータを使用して、各メモ
リー・プールのサイズを手動で変更できます。7-3 ページの「キャッシュ・サイズの動的な変
更」を参照してください。
次のプールは手動でサイズ設定されるコンポーネントで、自動共有メモリー管理の影響は受け
ません。
■
■
■
ログ・バッファ
その他のバッファ・キャッシュ（KEEP、RECYCLE および他の非デフォルト・ブロック・
サイズなど）
固定 SGA およびその他の内部割当て
これらのメモリー・プールを手動でサイズ設定するには、DB_KEEP_CACHE_SIZE、
DB_RECYCLE_CACHE_SIZE、DB_nK_CACHE_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 に変化します。グラ
ニュル・サイズは、インスタンスの起動時に計算されて固定されます。このサイズは、インス
タンスの存続期間中は変化しません。
メモリーの構成と使用方法
7-3
メモリー割当ての問題について
SGA で現在使用されているグラニュルのサイズは、ビュー V$SGA_DYNAMIC_COMPONENTS に
よって表示できます。それと同じグラニュルのサイズが SGA のすべての動的コンポーネントで
使用されます。
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: 実行済の最新の 800 件の SGA サイズ変更操作に関する情報。これに
は現在進行中の操作は含まれません。
V$SGA_DYNAMIC_COMPONENTS: SGA の動的コンポーネントに関する情報。このビューで
は、起動後のすべての実行済 SGA サイズ変更操作に基づく情報が要約されます。
V$SGA_DYNAMIC_FREE_MEMORY: 今後の動的 SGA サイズ変更操作で使用可能な SGA メモ
リーの量に関する情報。
関連項目 :
■
■
動的 SGA の詳細は、『Oracle Database 概要』を参照してください。
これらのビューの列の詳細は、
『Oracle Database リファレンス』を参
照してください。
アプリケーションの考慮事項
メモリー構成では、アプリケーションの要求に適したキャッシュをサイズ設定することが重要
です。逆に、アプリケーションのキャッシュの使用率をチューニングすると、リソース要件を
大幅に削減できます。Oracle メモリー・キャッシュを効率的に使用すると、これらのキャッ
シュを保護するラッチ、CPU、I/O システムなどの関連リソースに対する負荷も削減できます。
最高のパフォーマンスを得るために、次のことを考慮してください。
■
■
オペレーティング・システムおよびデータベース・リソースを最も効率的に使用するよう
に、キャッシュを最適に設計する必要があります。
Oracle メモリー構造に対するメモリーの割当ては、アプリケーションの要求を最もよく反
映する必要があります。
既存のアプリケーションに対する変更または追加を行う場合は、変更されたアプリケーション
の要求を満たすために Oracle メモリー構造のサイズ変更が必要な場合があります。
7-4
Oracle Database パフォーマンス・チューニング・ガイド
メモリー割当ての問題について
アプリケーションが Java を使用する場合、Java プールのデフォルト構成を変更する必要がある
かどうかを調べる必要があります。Java のメモリー使用量の詳細は、
『Oracle Database Java 開
発者ガイド』を参照してください。
オペレーティング・システムのメモリー使用量
大半のオペレーティング・システムでは、次のことを考慮することが重要です。
ページングの削減
ページングは、新しいページをメモリーにロードできるようにするため、オペレーティング・
システムがメモリー常駐ページをディスクに転送する場合に行われます。多くのオペレーティ
ング・システムは、実メモリーに格納しきれない大量の情報を収容するために、ページングを
行います。大半のオペレーティング・システムでは、ページングはパフォーマンスを低下させ
ます。
オペレーティング・システムのユーティリティを使用して、オペレーティング・システムを調
べ、システム上に多数のページングがあるかどうかを確認します。ページングが多数ある場合
は、システム上の総メモリー量が、メモリーを割り当てたすべてを保持できるほど十分に大き
くない場合があります。システム上の全体のメモリーを増やすか、割り当てたメモリー量を減
らします。
主メモリーへの SGA の格納
SGA の目的は、迅速なアクセスのためにメモリー内にデータを格納することであるため、SGA
は主メモリー内に存在する必要があります。SGA のページがディスクにスワップされると、
データに迅速にアクセスできなくなります。多くのオペレーティング・システムでは、ページ
ングによる損失は、大規模な SGA がもたらす利益をかなり上回ります。
注意 : 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 マ
ニュアルを参照してください。
メモリーの構成と使用方法
7-5
バッファ・キャッシュの構成と使用方法
構成の繰返し
メモリーの割当てを構成する場合は、アプリケーションの要求により異なりますが、Oracle メ
モリー構造に使用可能なメモリーを配分します。Oracle の構造にメモリーを配分すると、
Oracle が動作するために必要な物理 I/O の量に影響を与える可能性があります。最初にメモ
リーを適切に構成すると、I/O システムが効果的に構成されているかどうかも表示されます。
プロセスをひととおり実行した後で、メモリー割当てのステップを繰り返すことが必要となる
可能性もあります。実行を繰り返すことによって、後のステップの変更に基づいて前のステッ
プの調整が可能となります。たとえば、バッファ・キャッシュのサイズを小さくすると、共有
プールなど別のメモリー構造のサイズを大きくできます。
バッファ・キャッシュの構成と使用方法
様々なタイプの操作について、Oracle ではバッファ・キャッシュを使用してディスクから読み
取られたブロックを格納します。ソートやパラレル読込みなどの特定操作の場合には、Oracle
ではバッファ・キャッシュはバイパスされます。バッファ・キャッシュを使用する操作につい
て、この項では次の項目を説明します。
■
バッファ・キャッシュの効果的な使用
■
バッファ・キャッシュのサイズ設定
■
バッファ・キャッシュ・アドバイザ統計の解釈および使用方法
■
複数バッファ・プールについて
バッファ・キャッシュの効果的な使用
バッファ・キャッシュを効果的に使用するには、不要なリソース使用を回避するようにアプリ
ケーションの SQL 文をチューニングする必要があります。これを確認するには、頻繁に実行さ
れる SQL 文と、多数のバッファ取得を実行する SQL 文がチューニングされたかどうかを検証
します。
関連項目 : この確認を行う方法の詳細は、第 11 章「SQL チューニングの
概要」を参照してください。
バッファ・キャッシュのサイズ設定
新規にインスタンスを構成する場合は、バッファ・キャッシュの適切なサイズがわかっていま
せん。通常、データベース管理者はキャッシュ・サイズの最初の見積りを行い、次にインスタ
ンス上で代表的なワークロードを実行し、関連する統計を調べて、キャッシュが構成過小か構
成過大かを調べます。
バッファ・キャッシュ・アドバイザの統計
多数の統計が、バッファ・キャッシュ・アクティビティの調査に使用できます。これらの統計
には次のものがあります。
■
V$DB_CACHE_ADVICE
■
バッファ・キャッシュ・ヒット率
V$DB_CACHE_ADVICE の使用
このビューは、DB_CACHE_ADVICE 初期化パラメータが ON に設定されているときに移入され
ます。このビューは、潜在的なバッファ・キャッシュ・サイズ範囲のシミュレーションによる
ミス率を示します。
このビューには、シミュレートされたキャッシュ・サイズのそれぞれの独自の行と、その
キャッシュ・サイズに対して発生すると予測された物理 I/O アクティビティがあります。
DB_CACHE_ADVICE パラメータは動的であるため、特定のワークロードのアドバイザ・データ
を収集できるように、アドバイザ機能を動的に有効にしたり、無効にできます。
7-6
Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
このアドバイザ機能には、多少のオーバーヘッドが伴います。アドバイザ機能を有効にすると、
追加の記録が必要なため、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 に増や
すことをお薦めします。
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
このビューは、潜在的な各キャッシュ・サイズの物理読込み数を予測する情報を提供して、
キャッシュのサイズ設定を支援します。このデータには物理読込みファクタが含まれています。
これは、バッファ・キャッシュが所定の値にサイズ変更された場合、現行の物理読込み回数が
その分のみ変化すると予測されるファクタです。
メモリーの構成と使用方法
7-7
バッファ・キャッシュの構成と使用方法
注意 : Oracle では、物理読込みは必ずしもディスク読込みを意味しませ
ん。物理読込みは、ファイル・システム・キャッシュからで済む場合があ
ります。
キャッシュ内でのブロックの検出成功とキャッシュのサイズ間の関係は、必ずしも滑らかな分
布を示しません。バッファ・プールをサイズ設定するときは、キャッシュ・ヒット率の向上に
まったく貢献しない（または、ほとんど貢献しない）追加バッファは使用しないでください。
7-8 ページの図 7-1 の例では、キャッシュ・サイズの増分の狭い帯状部分のみが考慮に値するこ
とを示しています。
図 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-1 の統計は、ヒット率の計算に使用されます。
表 7-1 ヒット率を計算するための統計
7-8
統計
説明
consistent gets from
cache
バッファ・キャッシュからのブロックに対して読取り一貫性が要求さ
れた回数。
db block gets from
cache
バッファ・キャッシュからの CURRENT ブロックが要求された回数。
physical reads cache
ディスクからバッファ・キャッシュへ読み込まれたデータ・ブロック
の合計数。
Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
例 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 リファレン
ス』を参照してください。
バッファ・キャッシュ・アドバイザ統計の解釈および使用方法
バッファ・キャッシュ・サイズの増減を考慮する前に、調べるファクタは多数あります。たと
えば、V$DB_CACHE_ADVICE データおよびバッファ・キャッシュ・ヒット率を調べる必要があ
ります。
低いキャッシュ・ヒット率は、キャッシュのサイズを大きくすることがパフォーマンスに有益
であることを意味しません。キャッシュ・ヒット率の高いことが、ワークロードに対して
キャッシュが適切にサイズ設定されていることを示しているとはかぎりません。
バッファ・キャッシュ・ヒット率を解釈する場合は、次の点を考慮する必要があります。
■
■
■
大きな表や索引を繰り返しスキャンすると、キャッシュ・ヒット率を低下させる可能性が
あります。バッファ取得数が多く、頻繁に実行される SQL 文を調べて、実行計画が最適な
ものであるか確認します。可能であれば、1 つのパスですべての処理を実行するか、SQL
文を最適化して、頻繁にアクセスされるデータを繰り返しスキャンしないようにします。
可能であれば、頻繁にアクセスされるデータをクライアント・プログラムまたは中間層に
キャッシュして、同じデータを再問合せしないようにします。
長い全表スキャンでアクセスされた Oracle ブロックは、最低使用頻度（LRU）リストの最
後に配置され、リストの先頭には配置されません。このようにして、これらのブロックは、
索引参照または小規模な表スキャンを実行するときに読み込まれるブロックよりも早く除
去されます。バッファ・キャッシュ・データの解析では、有効な大規模全表スキャン時の
低いヒット率についても考慮する必要があります。
注意 : 小規模表のスキャンは、一定のサイズのしきい値を使用して、表
に対して実行されるスキャンです。小規模表とは、最大でバッファ・
キャッシュの 2% か 20 のいずれかの、大きい方と定義されます。
■
■
OLTP アプリケーションを実行するどの大容量データベースでも、常にほとんどの行は 1 回
ないし 0 回しかアクセスされません。このことを基準に考えると、ブロックを使用後に長
期間メモリーに保存することは、ほとんど意味がありません。
バッファ・キャッシュ・サイズを継続して増やすことはよくある間違いです。全表スキャ
ンや、バッファ・キャッシュを使用しない操作を実行している場合は、このように値を増
やしても何の効果もありません。
メモリーの構成と使用方法
7-9
バッファ・キャッシュの構成と使用方法
バッファ・キャッシュに割り当てられたメモリーの増加
一般規則として、キャッシュ・ヒット率が低く、全表スキャンを実行しないようにアプリケー
ションがチューニングされている場合は、キャッシュのサイズを増やすことを検討してくださ
い。
キャッシュ・サイズを増やすには、まず 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 管理者ガイド』
を参照してください。
バッファ・キャッシュに割り当てられたメモリーの削減
キャッシュ・ヒット率が高い場合、キャッシュが十分大きく、最も頻繁にアクセスされるデー
タも保持できる状態になっています。V$DB_CACHE_ADVICE データをチェックして、キャッ
シュ・サイズを削減すると物理 I/O 数が大幅に増えるかどうかを調べます。物理 I/O への影響
がなければ、別のメモリー構造にメモリーを必要とする場合に、キャッシュ・サイズを削減し
ても、良好なパフォーマンスを維持できます。バッファ・キャッシュを小さくするには、
DB_CACHE_SIZE パラメータの値を変更してキャッシュのサイズを削減します。
7-10
Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
複数バッファ・プールについて
一般に、ほとんどのシステムでは 1 つのデフォルト・バッファ・プールが適切です。ただし、
アプリケーションのバッファ・プールについて詳しい知識を持つユーザーは、複数バッファ・
プールを構成すると有益な場合があります。
非定型アクセス・パターンを持つセグメントの場合、それらのセグメントからのブロックを 2
つの異なるバッファ・プールである KEEP プールと RECYCLE プールに格納します。セグメント
のアクセス・パターンは、常にアクセスされるか（すなわち、ホット）
、またはほとんどアクセ
スされない（たとえば、1 日に 1 回のみバッチ・ジョブでアクセスされる大きなセグメント）
というように、非定型である可能性があります。
複数バッファ・プールによって、これらの違いに対処できます。KEEP バッファ・プールを使用
してバッファ・キャッシュ内の頻繁にアクセスされるセグメントをメンテナンスし、RECYCLE
バッファ・プールを使用してオブジェクトがキャッシュ内の領域を不必要に占有するのを防ぐ
ことができます。オブジェクトがキャッシュに関連付けられると、そのオブジェクトのすべて
のブロックがそのキャッシュに置かれます。特定のバッファ・プールに割り当てられていない
オブジェクトのために、DEFAULT バッファ・プールがメンテナンスされています。デフォル
ト・バッファ・プールのサイズは、DB_CACHE_SIZE です。各バッファ・プールは、同じ LRU
置換方針を使用します（たとえば、KEEP プールがそのプールに割り当てられたすべてのセグメ
ントを格納するほど十分大きくない場合、最も古いブロックがキャッシュから除去されます）
。
オブジェクトを適切なバッファ・プールに割り当てると、次の操作を実行できます。
■
I/O の低減または排除
■
個別のキャッシュに対するオブジェクトの隔離または制限
大きいセグメントへのランダム・アクセス
非常に大きいセグメントに大きい索引レンジ・スキャンまたは非有界索引レンジ・スキャンで
アクセスすると、LRU 除外方法では問題が発生する可能性があります。大規模とは、キャッ
シュのサイズと比較して大きいという意味です。非順次物理読込みのかなりの割合（10% を超
える割合）を 1 つのセグメントが占有する場合、そのセグメントは大規模であると考えられま
す。大規模セグメントに対するランダム読込みは、他のセグメントのデータを含むバッファが
キャッシュから除去される原因となります。大規模セグメントは、キャッシュの大きな割合を
消費しますが、キャッシングによる利益はありません。
非常に頻繁にアクセスされるセグメントは、バッファが頻繁にアクセスされるのでキャッシュ
から除去されないため、大規模セグメントの読込みの影響を受けません。ただし、その問題は、
大規模セグメントの読込みによるバッファの除外を免れるほど頻繁にはアクセスされない
ウォーム・セグメントに影響を与えます。この問題を解決するオプションは、次の 3 つです。
1.
アクセスされたオブジェクトが索引である場合は、索引に選択性があるかどうかを調べま
す。選択性がない場合は、さらに選択性のある索引を使用するように SQL 文をチューニン
グします。
2.
SQL 文をチューニングすると、大きいセグメントを個別の RECYCLE キャッシュに移動で
きるので、その他のセグメントに影響を与えません。RECYCLE キャッシュは DEFAULT
バッファ・プールよりも小さくし、DEFAULT バッファ・プールよりも迅速にバッファを再
利用する必要があります。
3.
大規模セグメントではまったく使用されない別の KEEP キャッシュに小さなウォーム・セ
グメントを移動する方法もあります。KEEP キャッシュをサイズ設定して、キャッシュでの
ミスを最小におさえられます。特定の問合せによってアクセスされるセグメントを KEEP
キャッシュに置き、除去されないようにすることで、その問合せの応答時間をより予測可
能にできます。
Oracle Real Application Cluster のインスタンス
データベース・インスタンスごとに複数バッファ・プールを作成できます。データベースの各
インスタンスについて、必ずしも同じバッファ・プール・セットを定義する必要はありません。
インスタンスごとにバッファ・プールのサイズを変えることも、バッファを定義しないことも
できます。それぞれのアプリケーション要件に従って、各インスタンスをチューニングします。
メモリーの構成と使用方法
7-11
バッファ・キャッシュの構成と使用方法
複数バッファ・プールの使用方法
オブジェクトのデフォルト・バッファ・プールを定義するには、STORAGE 句の BUFFER_POOL
キーワードを使用します。この句は、CREATE TABLE および ALTER TABLE、CLUSTER、およ
び INDEX の各 SQL 文に有効です。バッファ・プールを指定すると、そのオブジェクトに対し
て読み込まれたブロックは、すべてそのプールに配置されます。
バッファ・プールがパーティション表または索引に対して定義されている場合、オブジェクト
の各パーティションは、特定のバッファ・プールで上書きされないかぎり、表または索引定義
からバッファ・プールを継承します。
オブジェクトのバッファ・プールが ALTER 文を使用して変更された場合、変更されたセグメン
トのブロックを現在格納しているすべてのバッファは、ALTER 文を発行する前にあったバッ
ファ・プールに残ります。新たにロードされたブロック、および除去されて再ロードされたブ
ロックは、新しいバッファ・プールに入ります。
関連項目 : STORAGE 句での BUFFER_POOL の指定については、
『Oracle
Database SQL 言語リファレンス』を参照してください。
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-12
Oracle Database パフォーマンス・チューニング・ガイド
バッファ・キャッシュの構成と使用方法
プール内に多くのバッファを持つセグメントの判断
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 列を使用して目的のオブジェクトを識別します。
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;
メモリーの構成と使用方法
7-13
バッファ・キャッシュの構成と使用方法
4.
バッファの総数に対するバッファの比率を計算し、現在 SEGMENT_NAME で使用されて
いるキャッシュの割合を取得します。
% cache used by segment_name = [buffers(Step2)/total buffers(Step3)]
注意 : この手法は、1 つのセグメントに対してのみ有効です。パーティ
ション・オブジェクトについては、パーティションごとに問合せを実行す
る必要があります。
KEEP プール
アプリケーションに頻繁に参照されるセグメントがある場合は、KEEP バッファ・プールと呼ば
れる個別のキャッシュにそれらのセグメントのブロックをキャッシュします。メモリーは、
DB_KEEP_CACHE_SIZE パラメータを必要なサイズに設定することで KEEP バッファ・プール
に割り当てられます。KEEP プールのメモリーは、デフォルト・プールのサブセットではありま
せん。保持できる一般的なセグメントは、頻繁に使用される小さい参照表です。アプリケー
ション開発者と DBA は、どの表が候補かを判断できます。
7-13 ページの「プール内に多くのバッファを持つセグメントの判断」で説明するように、V$BH
を問い合せて、候補表からブロック数をチェックできます。
注意 :
NOCACHE 句は、KEEP キャッシュ内の表に影響を与えません。
KEEP バッファ・プールの目的は、メモリー内にオブジェクトを保存して、I/O 操作を避けるこ
とにあります。したがって、KEEP バッファ・プールのサイズは、バッファ・キャッシュに保持
するオブジェクトによって異なります。KEEP バッファ・プールのおおよそのサイズは、この
プールに割り当てられるすべてのオブジェクトで使用されるブロックを加算することで計算で
きます。セグメントに関する情報を収集する場合、DBA_TABLES.BLOCKS と
DBA_TABLES.EMPTY_BLOCKS を問い合せて使用されるブロック数を判断できます。
ヒット率を計算するには、前述の問合せを使用してシステム・パフォーマンスの 2 つのスナッ
プショットを時間をおいて取ります。物理読込み（physical reads）、ブロック取得
（block gets）および一貫取得（consistent gets）について、古い値から新しい値を引い
て、これらの結果を使用してヒット率を計算します。
100% のバッファ・プール・ヒット率が最適とはかぎりません。KEEP バッファ・プールのサイ
ズを減らしても、十分に高いヒット率が維持されることがよくあります。KEEP バッファ・プー
ルから除去されたブロックは、別のバッファ・プールに割り当ててください。
注意 : オブジェクトのサイズが大きくなった場合に、KEEP バッファ・
プールに入りきらなくなることがあります。この場合、キャッシュからブ
ロックが失われ始めます。
各オブジェクトをメモリー内に保持するとトレードオフが発生します。頻繁にアクセスされる
ブロックをキャッシュに保持することは有効ですが、頻繁に使用しないブロックを保持すると、
よりアクティブな他のブロックのためのスペースが減ることになります。
7-14
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
RECYCLE プール
メモリーに残さないセグメントに属するブロック用の RECYCLE バッファ・プールを構成でき
ます。RECYCLE プールは、ほとんどスキャンされないか頻繁に参照されないセグメントに適し
ています。アプリケーションがラージ・オブジェクトのブロックをランダム方式でアクセスす
る場合は、バッファ・プールに格納されているブロックが除去される前に再利用できる可能性
は（使用可能物理メモリーの量の制約により）ほとんどありません。これはバッファ・プール
のサイズに関係なくあてはまります。したがって、そのオブジェクトのブロックはキャッシュ
しないでください。これらのキャッシュ・バッファは、他のオブジェクトに割り当てることが
できます。
メモリーは、DB_RECYCLE_CACHE_SIZE パラメータを必要なサイズに設定することで
RECYCLE バッファ・プールに割り当てられます。この RECYCLE バッファ・プールのメモリー
は、デフォルト・プールのサブセットではありません。
あまり早くメモリーからブロックを破棄しないでください。バッファ・プールが小さすぎると、
トランザクションまたは SQL 文が実行を完了する前に、ブロックがキャッシュから除外されて
しまう可能性があります。たとえば、アプリケーションが表から値を選択し、その値を使用し
てデータを処理し、レコードを更新する場合があります。SELECT 文の後でブロックがキャッ
シュから削除された場合は、更新を実行するために再度ディスクから読み込む必要があります。
ブロックは、ユーザー・トランザクションの所要時間中は保存される必要があります。
共有プールとラージ・プールの構成および使用方法
異なるタイプのデータをキャッシュするには、共有プールを使用します。キャッシュされた
データには、PL/SQL ブロックおよび SQL 文のテキストおよび実行可能フォーム、ディクショ
ナリ・キャッシュ・データおよびその他のデータが含まれています。
共有プールを適切な大きさにして使用すると、次の 4 つの方法でリソース使用量を低減できま
す。
1.
SQL 文がすでに共有プールに存在する場合は解析オーバーヘッドをなくせます。このため、
ホスト上の CPU リソースとエンド・ユーザーの経過時間が節約されます。
2.
リソース使用のラッチングが大幅に減少して、拡張性がさらに増大します。
3.
すべてのアプリケーションが SQL 文およびディクショナリ・リソースの同一プールを使用
するので、共有プール・メモリーの必要量が低減されます。
4.
共有プールのディクショナリ要素はディスク・アクセスが不要なので、I/O リソースが節
約されます。
この項では、次の項目について説明します。
■
共有プールの概念
■
共有プールの効果的な使用方法
■
共有プールのサイズ設定
■
共有プール統計の解釈
■
ラージ・プールの使用
■
CURSOR_SPACE_FOR_TIME の使用
■
セッション・カーソルのキャッシュ
■
予約プールの構成
■
除去防止のためのラージ・オブジェクトの保存
■
既存のアプリケーション用の CURSOR_SHARING
■
接続の維持
メモリーの構成と使用方法
7-15
共有プールとラージ・プールの構成および使用方法
共有プールの概念
共有プールの主なコンポーネントは、ライブラリ・キャッシュとディクショナリ・キャッシュ
です。ライブラリ・キャッシュは、最近参照された SQL と PL/SQL コードの実行可能な（解析
またはコンパイルされた）形式を格納します。ディクショナリ・キャッシュは、データ・ディ
クショナリから参照されたデータを格納します。ライブラリ・キャッシュやディクショナリ・
キャッシュなどの共有プール内のキャッシュの多くは、必要に応じてサイズを自動的に増減し
ます。共有プールに空き領域がない場合は、新しいエントリを受け入れるために古いエントリ
がこれらのキャッシュから除去されます。
データ・ディクショナリ・キャッシュまたはライブラリ・キャッシュでのキャッシュ・ミスは、
バッファ・キャッシュでのミスよりも影響が大きくなります。このため、頻繁に使用される
データがキャッシュされるように共有プールをサイズ設定する必要があります。
共有サーバー、パラレル問合せ、Recovery Manager など、共有プールで大きいメモリーの割当
てを行う機能は多数あります。ラージ・プールと呼ばれる個別のメモリー領域を構成して、こ
れらの機能で使用される SGA メモリーを区別することをお薦めします。
関連項目 : ラージ・プールの構成の詳細は、7-26 ページの「ラージ・
プールの使用」を参照してください。
共有プールからのメモリーの割当ては、チャンクで行われます。このため、1 つの連続領域を
必要とせずにラージ・オブジェクト（5KB より多い）をキャッシュにロードできるので、フラ
グメント化のために十分な連続メモリーが不足する可能性が減ります。
Java、PL/SQL または SQL の各カーソルが、まれに、5KB より大きい共有プールから割当てを
行う場合があります。このような割当てを最も効率よく行うために、Oracle では、少量の共有
プールを区別しています。このメモリーは、共有プールに十分な領域がない場合に使用します。
共有プールの区別された領域は予約プールと呼ばれます。
関連項目 : 共有プールの予約領域の詳細は、7-30 ページの「予約プール
の構成」を参照してください。
ディクショナリ・キャッシュの概念
データ・ディクショナリ・キャッシュに格納されている情報には、ユーザー名、セグメント情
報、プロファイル・データ、表領域情報および順序番号が含まれています。また、ディクショ
ナリ・キャッシュはスキーマ・オブジェクトを説明する情報すなわちメタデータも格納します。
メタデータが使用されるのは、SQL カーソルの解析時か PL/SQL プログラムのコンパイル時で
す。
ライブラリ・キャッシュの概念
ライブラリ・キャッシュは、SQL カーソル、PL/SQL プログラムおよび Java クラスの実行可能
な形式を保持します。この項では、チューニングを中心に説明します。チューニングはカーソ
ル、PL/SQL プログラムおよび Java クラスに関連するためです。これらをまとめてアプリケー
ション・コードと呼びます。
アプリケーション・コードを実行するとき、既存のコードが以前に実行されており、共有でき
る場合は、そのコードを再利用しようとします。解析された文の表現がライブラリ・キャッ
シュ内に存在し、共有できる場合は、既存のコードを再利用します。これは、ソフト解析また
はライブラリ・キャッシュ・ヒットと呼ばれています。既存のコードを使用できない場合は、
アプリケーション・コードの新しい実行可能バージョンを作成する必要があります。これは、
ハード解析またはライブラリ・キャッシュ・ミスと呼ばれています。SQL 文と PL/SQL 文を共
有できる場合の詳細は、7-17 ページの「SQL 共有基準」を参照してください。
ライブラリ・キャッシュ・ミスは、SQL 文を処理するときの解析ステップまたは実行ステップ
のいずれかで発生します。アプリケーションが SQL 文の解析コールを行うとき、解析された文
の表現がライブラリ・キャッシュにまだ存在しない場合、Oracle はその文を解析し、共有プー
ルに解析されたフォームを格納します。これはハード解析です。可能な場合は、すべての共有
可能な SQL 文が共有プール内にあることを確認して、解析コールのライブラリ・キャッシュ・
ミスを低減できます。
7-16
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
アプリケーションが SQL 文に対して実行コールを作成し、すでに作成された SQL 文の実行可
能な部分が別の文のための場所を作成するためにライブラリ・キャッシュから除去（すなわち、
割当て解除）された場合、Oracle はその文を暗黙に再解析し、新しい共有 SQL 領域を作成し、
実行します。この場合も、ハード解析が発生します。通常は、ライブラリ・キャッシュに割り
当てるメモリーを増やすことによって実行コールのライブラリ・キャッシュ・ミスを低減でき
ます。
ハード解析を実行するには、ソフト解析の実行時より多くのリソースを使用します。ソフト解
析に使用するリソースには、CPU およびライブラリ・キャッシュ・ラッチ取得が含まれます。
ハード解析に必要なリソースには、追加の CPU、ライブラリ・キャッシュ・ラッチ取得および
共有プール・ラッチ取得が含まれます。ハード解析およびソフト解析については、2-13 ページ
の「SQL の実行効率」を参照してください。
SQL 共有基準
Oracle は、発行される SQL 文または PL/SQL ブロックが共有プールに現在存在する別の文と
同じかどうかを自動的に判断します。
比較のために、次のステップが実行されます。
1.
発行された文のテキストは、共有プール内の既存の文と比較されます。
2.
文のテキストがハッシュされます。一致するハッシュ値がない場合、SQL 文は共有プール
内に現在存在せず、ハード解析が実行されます。
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 表がある場合、文はユーザーごとに異なる表を参照する
ので、この文は同一とみなされません。
メモリーの構成と使用方法
7-17
共有プールとラージ・プールの構成および使用方法
5.
SQL 文の中のバインド変数は、名前、データ型および長さで一致している必要があります。
たとえば、次の文で同じ共有 SQL 領域を使用できないのは、バインド変数名が異なるため
です。
SELECT * FROM employees WHERE department_id = :department_id;
SELECT * FROM employees WHERE department_id = :dept_id;
多くの Oracle 製品（Oracle Forms やプリコンパイラなど）は、文をデータベースに渡す前
に SQL を変換します。首尾一貫した SQL 文の集合が生成されるように、文字は大文字に
統一して変換され、空白は圧縮され、バインド変数は改名されます。
6.
セッションの環境は同一である必要があります。たとえば、SQL 文は、同一の最適化目標
を使用して最適化する必要があります。
共有プールの効果的な使用方法
共有プールの重要な目的は、SQL 文と PL/SQL 文の実行可能バージョンをキャッシュすること
です。これにより、ハード解析にリソースを使用することなく、同じ SQL または PL/SQL コー
ドを複数回実行できるので、CPU、メモリーおよびラッチの使用が大幅に減少します。
また、共有プールは、データ・ウェアハウス・アプリケーションで非共有 SQL をサポートでき
ます。これらのアプリケーションでは、同時実行性が低くリソース使用率の高い SQL 文が実行
されます。このような状況では、リテラル値を持つ非共有 SQL を使用することをお薦めしま
す。バインド変数ではなくリテラル値を使用すると、オプティマイザは優れた列選択性の見積
りを行えるので、最適なデータ・アクセス・プランを提供します。
関連項目 : 『Oracle Database データ・ウェアハウス・ガイド』
OLTP システムでは、共有プールと関連リソースを効率的に使用できるようにする方法が多数
あります。次の項目についてアプリケーション開発者と検討し、共有プールが効果的に使用さ
れるようにする方法を決定します。
■
共有カーソル
■
単一のユーザーのログインおよび修飾表の参照
■
PL/SQL の使用方法
■
DDL の実行の回避
■
キャッシュ順序番号
■
カーソルのアクセスおよび管理
同時実行性の高い OLTP システムで共有プールを効率よく使用すると、解析関連アプリケー
ションの拡張性の問題が発生する確率が大幅に低減します。
共有カーソル
同じアプリケーションを実行する複数のユーザーのために共有 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;
7-18
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
注意 : バインド変数を使用するためにコードをリライトすることが実際
的ではない既存のアプリケーションについては、CURSOR_SHARING 初期
化パラメータを使用してハード解析のオーバーヘッドをある程度回避でき
ます。詳細は、7-32 ページの「既存のアプリケーション用の CURSOR_
SHARING」を参照してください。
■
■
■
■
多数のユーザーが動的な非共有の SQL 文を発行するようなアプリケーションを設計しない
ようにしてください。通常、大半のユーザーが必要とするデータの大部分は、事前に設定
されている問合せを使用して満たすことができます。そのような機能が必要な場合は、動
的 SQL を使用します。
アプリケーションのユーザーが最適化アプローチと目標を各セッションに対して変更しな
いことを確認してください。
アプリケーション開発者に対し、次のポリシーを設定します。
–
SQL 文と PL/SQL ブロックに対して、バインド変数のネーミング規則と、スペーシン
グ規定を標準化します。
–
可能な場合、ストアド・プロシージャを使用することを考慮してください。そうすれ
ば、同じストアド・プロシージャを発行している複数のユーザーが、同じ共有
PL/SQL 領域を自動的に使用します。ストアド・プロシージャは解析済フォームに格
納されているため、ストアド・プロシージャを使用すると実行時間の解析が減少しま
す。
同一であっても共有されていない SQL 文について V$SQL_SHARED_CURSOR を問い合せる
ことで、カーソルが共有されない理由を判断できます。この理由には、オプティマイザの
設定とバインド変数の不整合などがあります。
単一のユーザーのログインおよび修飾表の参照
ユーザーが独自のユーザー ID でデータベースにログインするような大きい OLTP システムで
は、パブリック・シノニムを使用するのではなく、明示的にセグメントの所有者を修飾すると
有益です。これにより、ディクショナリ・キャッシュ内のエントリ数が大幅に削減されます。
たとえば、次のような場合があります。
SELECT employee_id FROM hr.employees WHERE department_id = :dept_id;
表名を認定する別の方法として、個々のユーザー ID ではなく単一のユーザー ID でデータベー
スに接続します。ユーザー・レベルの検証は、中間層でローカルに行われます。個別のユー
ザー ID の数を削減した場合も、ディクショナリ・キャッシュ上の負荷は低減します。
PL/SQL の使用方法
ストアド PL/SQL パッケージを使用すると、多数のユーザーが個々にユーザー・サインオンと
パブリック・シノニムを持つシステムにおける、拡張性の問題を克服できます。これは、パッ
ケージがコール元ではなく所有者として実行されるため、ディクショナリ・キャッシュの負荷
がかなり削減されるためです。
注意 : 拡張性の問題を克服するために、定義者権限パッケージの使用を
お薦めします。ディクショナリ・キャッシュの負荷軽減の利点は、実行者
権限パッケージの場合ほど顕著ではありません。
DDL の実行の回避
ピーク時間に使用率の高いセグメントで DDL 操作を実行しないようにします。そのようなセグ
メントで DDL を実行すると、多くの場合、依存 SQL は無効にされるため、以降の実行で再度
解析されることになります。
メモリーの構成と使用方法
7-19
共有プールとラージ・プールの構成および使用方法
キャッシュ順序番号
頻繁に更新される順序番号に十分なキャッシュ領域を割り当てると、ディクショナリ・キャッ
シュ・ロックの回数が大幅に減るため、拡張性が向上します。CREATE SEQUENCE 文または
ALTER SEQUENCE 文の CACHE キーワードを使用して、各順序のキャッシュ済エントリ数を構
成できます。
関連項目 : CREATE SEQUENCE 文および ALTER SEQUENCE 文の詳細は、
『Oracle Database SQL 言語リファレンス』を参照してください。
カーソルのアクセスおよび管理
使用している 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-20
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 はこの点についてワークロード内に該
当する箇所がないかチェックする必要があります。
共有プール : ライブラリ・キャッシュの統計
共有プールをサイズ設定するときの目標は、メモリーを割り当てすぎずに、複数回実行される
SQL 文がライブラリ・キャッシュにキャッシュされるようにすることです。
以前にキャッシュされ、すでに除去された SQL 文の再ロード（すなわち、再解析）の量の統計
は、V$LIBRARYCACHE ビューの RELOADS 列に示されます。効果的に SQL を再利用するアプ
リケーションでは、システムが最適な共有プール・サイズを持ち、RELOADS 統計が 0（ゼロ）
に近い値を示します。
V$LIBRARYCACHE ビューの INVALIDATIONS 列は、ライブラリ・キャッシュのデータが無効
にされ、再解析された回数を示しています。INVALIDATIONS は 0（ゼロ）に近い値である必
要があります。つまり、共有できた可能性のある SQL 文が、ある操作（たとえば、DDL）によ
り無効にされたことを意味します。この統計は、ピーク・ロード中の OLTP システム上では、0
（ゼロ）に近い値となります。
別の重要な統計は、ピーク時の共有プール内の空きメモリー量です。空きメモリー量は、共有
プールの空きメモリーを参照する V$SGASTAT から問い合せることができます。空きメモリー
は、システム上に再ロードを発生させない程度で、できるだけ小さい値である必要があります。
最終的には、ライブラリ・キャッシュの全般的なインジケータは、ライブラリ・キャッシュ・
ヒット率で表されます。この値は、この項で説明されているその他の統計、およびハード解析
率や、共有プールまたはライブラリ・キャッシュのラッチ競合があるかどうかなどのその他の
データとともに考慮する必要があります
これらの統計の詳細は、次の項で説明します。
メモリーの構成と使用方法
7-21
共有プールとラージ・プールの構成および使用方法
V$LIBRARYCACHE
動的パフォーマンス・ビュー V$LIBRARYCACHE を調べることで、ライブラリ・キャッシュの
アクティビティを反映する統計を監視できます。これらの統計は、最新のインスタンス起動以
降のライブラリ・キャッシュのアクティビティを反映しています。
このビューの各行には、ライブラリ・キャッシュ内に保持される項目の 1 つに対応する統計が
収録されます。各行ごとに記述される項目は、NAMESPACE 列の値によって識別されます。次の
NAMESPACE 値を持つ行は、SQL 文と PL/SQL ブロックのライブラリ・キャッシュのアクティ
ビティを反映します。
■
SQL AREA
■
TABLE/PROCEDURE
■
BODY
■
TRIGGER
他の NAMESPACE 値を持つ行は、Oracle が依存関係のメンテナンスのために使用するオブジェ
クト定義に対するライブラリ・キャッシュのアクティビティを反映します。
関連項目 : 動的パフォーマンス・ビュー 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-22
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
戻されたデータを調べると、次のことがわかります。
■
■
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';
The output will be similar to the following:
POOL
NAME
BYTES
----------- -------------------------- ---------shared pool free memory
4928280
共有プール内に使用可能な空きメモリーが常にある場合、プールのサイズを増やしても、効果
はほとんど（または、まったく）ありません。また、共有プールがいっぱいというだけでは、
問題があるとはいえません。これは、適切に構成されたシステムであることを示している場合
があります。
共有プールのアドバイザ統計
ライブラリ・キャッシュに使用可能なメモリー量は、Oracle インスタンスの解析率に大きな影
響を与えます。共有プールのアドバイザ統計から、データベース管理者はライブラリ・キャッ
シュ・メモリーについての情報を得ることができ、共有プールのサイズ変更が共有プール内の
オブジェクトの除去にどのように影響するかを予測できます。
共有プールのアドバイザ統計では、共有プール・メモリーにおけるライブラリ・キャッシュの
使用率が追跡され、異なるサイズの共有プールでライブラリ・キャッシュがどのように動作す
るかが予測されます。2 つの固定ビューにより、ライブラリ・キャッシュのメモリー使用量、
現在の確保量、共有プールの LRU リスト上にある量、さらに共有プールのサイズ変更により損
失または獲得できる時間を判別する情報が提供されます。
共有プールのアドバイザ統計では、次のビューが使用できます。共有プール・アドバイザをオ
ンにすると、これらのビューにはあらゆるデータが表示されます。共有プール・アドバイザを
オフにすると、それらの統計がリセットされます。
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% のうち大きい方の値か
メモリーの構成と使用方法
7-23
共有プールとラージ・プールの構成および使用方法
ら、現在の 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-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
7-24
parameter
sum(gets)
sum(getmisses)
100*sum(gets - getmisses) / sum(gets)
sum(modifications)
V$ROWCACHE
gets > 0
BY parameter;
Oracle Database パフォーマンス・チューニング・ガイド
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
dc_sequences
26973
16
99.9
26,811
dc_synonyms
6617
168
97.5
0
dc_tablespace_quotas
120
7
94.2
51
dc_tablespaces
581248
10
100.0
0
dc_used_extents
51418
20249
60.6
42,811
dc_user_grants
76082
18
100.0
0
dc_usernames
216860
12
100.0
0
dc_users
376895
22
100.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 の値を
増やします。
データ・ディクショナリ・キャッシュへの追加のメモリーの割当て GETS と GETMISSES 列を
監視することによって、キャッシュ・アクティビティを調べてください。ディクショナリ・
キャッシュが頻繁にアクセスされる場合、GETS の合計に対する GETMISSES の割合は、アプリ
ケーションによって異なりますが、10% あるいは 15% より低くしてください。
メモリーの構成と使用方法
7-25
共有プールとラージ・プールの構成および使用方法
次のすべてに当てはまる場合は、キャッシュに利用できるメモリー量を増やすことを考慮して
ください。
■
■
アプリケーションは共有プールを効果的に使用している。7-18 ページの「共有プールの効
果的な使用方法」を参照してください。
システムは安定状態に達し、項目固有のヒット率が低く、ヒット率の低いキャッシュへの
取得数が多い。
初期化パラメータ SHARED_POOL_SIZE の値を増やして、データ・ディクショナリ・キャッ
シュに利用できるメモリーを増やします。
メモリー割当ての減少
RELOADS が 0（ゼロ）に近く、共有プール内の空きメモリーが少ない場合、共有プールは、最
も頻繁にアクセスされるデータを保持できる十分な大きさがあります。
常に共有プールに多数の空きメモリーがある場合、このメモリーを他の場所に割り当てるため
に共有プールのサイズを小さくしても、良好なパフォーマンスを維持できます。
共有プールを小さくするには、SHARED_POOL_SIZE パラメータの値を変更してキャッシュの
サイズを小さくします。
ラージ・プールの使用
共有プールとは異なり、ラージ・プールには LRU リストがありません。Oracle は、ラージ・
プールからオブジェクトを除去しようとしません。
インスタンスが次のいずれかを使用する場合は、ラージ・プールの構成を考慮してください。
■
パラレル問合せ
パラレル問合せでは、共有プール・メモリーを使用してパラレル実行メッセージ・バッ
ファをキャッシュします。
関連項目 : パラレル問合せによるラージ・プールのサイズ設定の詳細は、
『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）メモリー用に割り当てられ
7-26
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
るためです。共有プールのかわりにラージ・プールを使用すると、共有プールの断片化も減少
します。
ラージ・プールに共有サーバー関連の UGA を格納するには、初期化パラメータ
LARGE_POOL_SIZE に値を指定します。どのプール（共有プールまたはラージ・プール）にオ
ブジェクト用のメモリーが存在するかを確認するには、V$SGASTAT で列 POOL をチェックしま
す。ラージ・プールはデフォルトで構成されません。最小値は 300KB です。ラージ・プールを
構成しないと、共有サーバー・ユーザー・セッション・メモリーに共有プールが使用されます。
ラージ・プールの大きさは、同時にアクティブとなるセッションの数を基準に構成します。各
アプリケーションは、必要なセッション情報メモリー量がそれぞれ異なり、ラージ・プールあ
るいは SGA の構成はメモリー要件を反映する必要があります。たとえば、アクティブな各セッ
ションのセッション情報を格納するために共有サーバーが 200 ～ 300KB を必要とすると仮定し
ます。100 個のセッションが同時にアクティブになると予想される場合、30MB のラージ・プー
ルを構成するか、ラージ・プールを構成しない場合は、共有プールを増やしてください。
注意 : 共有サーバー・アーキテクチャを使用する場合、ラージ・プール
を構成した場合でも、Oracle によって各構成セッションに一定量のメモ
リー（約 10KB）が共有プールから割り当てられます。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-27
共有プールとラージ・プールの構成および使用方法
値を検索するには、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 消費量の制限は行わないた
め、このパラメータを使用することはほとんどありません。
関連項目 : PRIVATE_SGA リソース制限の設定の詳細は、
『Oracle
Database SQL 言語リファレンス』の「ALTER RESOURCE COST 文」を参
照してください。
3 層の接続でのメモリー使用の低減 接続ユーザーが非常に多数の場合は、3 層の接続を実装す
ることでメモリー使用を低減できます。これはトランザクション処理（TP）モニター使用の副
産物であり、ロックやコミットされていない DML を複数のコールにわたって保持できないた
め、純粋なトランザクション・モデルでしか実現できません。共有サーバー環境には次の利点
があります。
■
■
■
7-28
TP モニターに比べてアプリケーション設計の制限が大幅に少なくなります。
ユーザーがサーバーのプールを共有できるので、オペレーティング・システム・プロセス
数とコンテキストの切替えが大幅に減ります。
共有サーバー・モードでさらに多くの SGA が使用される場合でも総メモリー使用量が大幅
に減ります。
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
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 文のための領域がない場
合、文は解析されず、共有メモリーがなくなったことを示すエラーが 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 のアルゴリズムで
は、必要に応じてセッション・カーソル・キャッシュ内の項目を除去し、新しい項目のための
空間を作成します。
メモリーの構成と使用方法
7-29
共有プールとラージ・プールの構成および使用方法
また次の文を使用すると、セッション・カーソル・キャッシュを動的に使用可能にすることも
できます。
ALTER SESSION SET SESSION_CACHED_CURSORS = value;
セッション・カーソル・キャッシュがインスタンスに対して十分な大きさであるかどうかを判
断するには、V$SYSSTAT ビュー内のセッション統計（session cursor cache hits）を調べ
ます。この統計では、解析コールによってセッション・カーソル・キャッシュ内でカーソルが
検出された回数を数えます。この統計で、セッションの合計解析コール数が相対的に低い割合
である場合には、SESSION_CACHED_CURSORS を大きい値に設定してください。
予約プールの構成
非常に大きいメモリーの要求は小さいチャンクに分割されますが、システムによっては、メモ
リーの連続チャンク（たとえば、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％に設定し
ます。すでに共有プールのチューニングを済ませている場合、ほとんどのシステムではこの値
で十分です。この値を大きくすると、データベースは共有プールからメモリーを取り出します。
（このため、それより小さい割当てに使用可能な予約されていない共有プールのメモリーの量が
減少します。
）
V$SHARED_POOL_RESERVED ビューの統計を使用すると、これらのパラメータをチューニング
するのに役立ちます。SGA のサイズを大きくするための空きメモリーが豊富にあるシステムで
は、REQUEST_MISSES の値を 0（ゼロ）にすることが目標です。オペレーティング・システ
ム・メモリーに制約があるシステムの場合は、REQUEST_FAILURES をなくすことが目標で、
少なくともこの値が増加しないようにします。
7-30
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
これらの目標値が達成できない場合は、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 を増やします。
除去防止のためのラージ・オブジェクトの保存
エントリが共有プールにロードされた後は、それを移動することはできません。エントリが
ロードされ、除去されると、空きメモリーが断片化されることもあります。
共有プールを管理するには、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 オブジェクトがロードされる場合で、領域を確保するために小さなオブ
ジェクトを共有プールから除去する必要がある場合は、ユーザーの応答時間に影響が現れ
ます。場合によっては、このような大きなオブジェクトをロードするには、メモリーが十
分でないこともあります。
頻繁に実行されるトリガー。頻繁に使用する表のコンパイル済トリガーを共有プール内に
維持できます。
メモリーの構成と使用方法
7-31
共有プールとラージ・プールの構成および使用方法
■
DBMS_SHARED_POOL が順序もサポートする場合。共有プールから順序が除去されると、
順序番号が失われます。DBMS_SHARED_POOL は、共有プール内に順序を保持し、順序番
号の消失を防ぎます。
DBMS_SHARED_POOL パッケージを使用して SQL 領域または PL/SQL 領域を確保するには、次
の手順を実行してください。
1.
メモリー内に確保しておくパッケージまたはカーソルを決定します。
2.
データベースを起動します。
3.
DBMS_SHARED_POOL.KEEP をコールしてオブジェクトを確保します。
この手順により、保存されているオブジェクトがロードされる前にシステムの共有メモ
リーが使用し尽くされないことが保証されます。その結果、オブジェクトをインスタンス
の早い時期に確保することにより、大きなメモリー領域を共有プールの中央に確保するた
めに発生する可能性のある、メモリーの断片化を防ぐことができます。
関連項目 : DBMS_SHARED_POOL プロシージャの使用方法の詳細は、
『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リ
ファレンス』を参照してください。
既存のアプリケーション用の CURSOR_SHARING
解析の第 1 段階の 1 つは、文のテキストを共有プール内の既存の文と比較して、その文を共有
できるかどうかを確認することです。文をテキストとして比較し、なんらかの点で異なる場合
は、文は共有されません。
例外は、CURSOR_SHARING パラメータが SIMILAR または FORCE に設定されている場合です。
このパラメータを使用する場合、まず共有プールがチェックされ、共有プールに同一の文があ
るかどうかが確認されます。同一の文が検出されないと、共有プール内で類似する文が検索さ
れます。類似する文があると、解析チェックが引き続き行われ、カーソルの実行可能フォーム
を使用できるかどうかが検証されます。文がない場合は、文の実行可能フォームを生成するた
めにハード解析が必要になります。
類似 SQL 文
いくつかのリテラル値以外が同一である文は、類似文と呼ばれます。CURSOR_SHARING パラ
メータが SIMILAR または FORCE に設定されると、類似文は解析フェーズでテキスト・チェッ
クを省略します。テキストの類似性では、共有は保証されません。SQL 文の新しいフォームで
は、解析フェーズの残りのステップを実行して、既存の文の実行計画が新しい文にも同じよう
に適用できるかどうかを確認する必要があります。
関連項目 : 実行される各種チェックの詳細は、7-17 ページの「SQL 共有
基準」を参照してください。
CURSOR_SHARING
CURSOR_SHARING を EXACT に設定すると、SQL 文はテキストがまったく同一の場合にのみ
SQL 領域を共有できます。これはデフォルトの動作です。この設定では、類似文は共有できま
せん。テキストとしての完全に同一の文のみ共有できます。
CURSOR_SHARING を SIMILAR または FORCE に設定すると、類似文が SQL を共有できます。
SIMILAR と FORCE の違いは、実行計画を機能低下させることなく SIMILAR が類似する文に
SQL 領域を共有させるという点です。CURSOR_SHARING を FORCE に設定すると、類似文に実
行可能な SQL 領域を共有するように強制します。この方法には、潜在的に実行計画の機能を低
下させる可能性があります。したがって、計画が最適なものではなくなる可能性があっても
カーソル共有率の向上を優先する場合に、FORCE を最後の手段として使用してください。
7-32
Oracle Database パフォーマンス・チューニング・ガイド
共有プールとラージ・プールの構成および使用方法
CURSOR_SHARING を使用する場合
CURSOR_SHARING 初期化パラメータにより一部のパフォーマンス問題を解決できる場合があり
ます。初期化パラメータには、FORCE、SIMILAR および EXACT（デフォルト）の値がありま
す。このパラメータの使用は、多数の類似 SQL 文を持つ既存のアプリケーションにとっては有
益です。
注意 : 複雑な問合せを使用している場合は、DSS 環境で
CURSOR_SHARING を FORCE に設定することはお薦めしません。また、
CURSOR_SHARING が SIMILAR または FORCE に設定されると、スター型
変換はサポートされません。詳細は、13-5 ページの「問合せオプティマイ
ザ機能の有効化」を参照してください。
最適な解決方法は、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）を使用すると、多数の類似文を持ついくつか
のアプリケーション上でのカーソルの共有を大幅に向上できるため、メモリー使用量が削減さ
れ、解析が高速になり、ラッチ競合が減少します。
接続の維持
中間層を持つ大きな OLTP アプリケーションでは、データベース要求ごとに接続と切断を行う
のではなく、接続を維持するようにします。永続的な接続を維持することで、ラッチなどの
CPU リソースとデータベース・リソースが節約されます。
関連項目 : 重要なオペレーティング・システム統計の説明は、5-5 ページ
の「オペレーティング・システム統計」を参照してください。
メモリーの構成と使用方法
7-33
REDO ログ・バッファの構成および使用
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 操作の使用
REDO ログ・バッファのサイズは、初期化パラメータ LOG_BUFFER で決定されます。ログ・
バッファ・サイズは、インスタンス起動後には変更できません。
図 7-2 REDO ログ・バッファ
7-34
Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
ログ・バッファのサイズ設定
大量のデータを挿入、変更または削除するアプリケーションは、通常、デフォルトのログ・
バッファ・サイズを変更する必要があります。ログ・バッファは総 SGA サイズと比較すると小
さく、中規模サイズのログ・バッファは、多数の更新を実行するシステムでのスループットを
大幅に向上させます。
そのようなシステムにおける合理的な最初の見積りはデフォルト値に対するもので、次のとお
りです。
MAX(0.5M, (128K * number of cpus))
大半のシステムでは、ログ・バッファを 1MB より大きくサイズ設定しても、パフォーマンスの
利点が得られません。バッファ・サイズを増やしても、パフォーマンスまたはリカバリ能力に
対してマイナスの影響を及ぼしません。単に追加のメモリーが使用されます。
ログ・バッファの統計
統計 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-35
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-36
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 のチューニング
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）までを使用できます。
メモリーの構成と使用方法
7-37
PGA メモリー管理
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$PROCESS_MEMORY
■
V$SQL_WORKAREA_HISTOGRAM
■
V$SQL_WORKAREA_ACTIVE
■
V$SQL_WORKAREA
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 に表示される主な統計は次のとおりです。
■
■
7-38
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 メモリーが残されている必要があります。
Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
■
■
■
■
global memory bound: AUTO モードで実行された作業領域の最大サイズを示します。こ
の値は、作業領域のワークロードの現在の状態を反映するように継続的に調整されます。
通常は、システム内のアクティブな作業領域の数が増えると、グローバル・メモリー・バ
ウンドが縮小します。一般的には、グローバル・バウンドの値は 1MB を下回らないように
する必要があります。1MB 未満になった場合は、PGA_AGGREGATE_TARGET の値を増やす
必要があります。
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-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 つであったことがこの値に反映
メモリーの構成と使用方法
7-39
PGA メモリー管理
されています。したがって、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
V$PROCESS_MEMORY このビューは、各 Oracle プロセスの名前を付けられたコンポーネント・
カテゴリごとに、動的 PGA のメモリー使用量を表示します。このビューには、各 Oracle プロ
セスに対して 1 行ずつ、6 行まで（次のそれぞれに対して各 1 行）が含まれます。
■
■
■
名前を付けられた各コンポーネント・カテゴリ :
–
Java
–
PL/SQL
–
OLAP
–
SQL
開放可能 : オペレーティング・システムによって、特定のカテゴリにではなくプロセスに割
り当てられたメモリー。
その他 : 名前を付けられたカテゴリの 1 つではなく、1 つのカテゴリに割り当てられたメモ
リー。
列 CATEGORY、ALLOCATED、USED および MAX_ALLOCATED を使用して、6 つのカテゴリそれ
ぞれの Oracle プロセスの PGA メモリー使用量を動的にモニターできます。
関連項目 : V$PROCESS_MEMORY ビューの詳細は、『Oracle Database リ
ファレンス』を参照してください。
V$SQL_WORKAREA_HISTOGRAM このビューには、インスタンス起動後に、最適なメモリー・サ
イズ、ワン・パス・メモリー・サイズおよびマルチ・パス・メモリー・サイズで実行された作
業領域の総数を示します。このビューの統計は、作業領域の最適なメモリー要件によって定義
されるバケットに副分割されます。各バケットは、列 LOW_OPTIMAL_SIZE および
HIGH_OPTIMAL_SIZE の値で指定された最適メモリー要件の範囲によって識別されます。
7-40
Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
例 7-3 および例 7-4 で、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
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);
メモリーの構成と使用方法
7-41
PGA メモリー管理
この問合せの出力例を次に示します。
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-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;
The output of this query might look like the following:
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-42
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;
OPERATION
-----------SELECT STATE
HASH
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%';
メモリーの構成と使用方法
7-43
PGA メモリー管理
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-37 ページの「PGA_AGGREGATE_TARGET の初期設定」を参照してください。
STATISTICS_LEVEL。TYPICAL（デフォルト）または ALL に設定します。このパラメー
タを BASIC に設定すると、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
7-44
CACHE_HIT_PERC
-------------23
24
30
39
58
59
59
ESTD_OVERALLOC_COUNT
-------------------367
30
3
0
0
0
0
Oracle Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
800
900
1000
1500
2000
3000
4000
60
60
61
67
76
83
85
0
0
0
0
0
0
0
この問合せの結果は図 7-3 に示すように図示できます。
図 7-3 V$PGA_TARGET_ADVICE の図示
この曲線は、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 に設定する必要があります。
メモリーの構成と使用方法
7-45
PGA メモリー管理
注意 : 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-23 ページ「共有プールのアドバイザ統計」
■
7-6 ページ「バッファ・キャッシュのサイズ設定」
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 があると仮定しています。
■
■
7-46
この制限 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 Database パフォーマンス・チューニング・ガイド
PGA メモリー管理
さらに、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 の希望値を選択するための追加の述語を使用し、
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-47
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-48
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 またはハードウェア・ス
トライプ化を使用するときの決定事項には、ストライプ深度
ストライプ深度およびストライプ幅
ストライプ幅が含まれます。
ストライプ深度
ストライプ幅
■
ストライプ深度は、ストライプのサイズで、ストライプ単位とも呼ばれます。
■
ストライプ幅は、ストライプ深度とストライプ・セットを構成するドライブ数の積です。
これらの値を適切に選択して、システムが必要なスループットを維持できるようにします。
Oracle データベースにおける適切なストライプ深度は、256KB ～ 1MB です。ストライプ深度
によって、得られるアプリケーションの利点の種類が異なります。最適なストライプ深度およ
びストライプ幅は、次の項目により異なります。
8-2
■
要求された I/O サイズ
■
I/O リクエストの同時実行性
■
物理ストライプ境界とブロック・サイズ境界との位置合せ
■
提案されたシステムの管理可能性
Oracle Database パフォーマンス・チューニング・ガイド
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 を乗算して計算されます（上限値は、オペレー
ティング・システムの制限を受けます）
。この値が明示的に設定さ
れていない（または 0 に設定されている）場合、全表スキャンの
最大 I/O サイズを計算するとき、オプティマイザはこのパラメー
タにデフォルト値の 8 を使用します。
SORT_AREA_SIZE
ソート操作のための I/O サイズおよび同時実行性を決定します。
HASH_AREA_SIZE
ハッシュ操作のための I/O サイズを決定します。
I/O サイズの他に、同時実行性の程度も理想的なストライプ深度を調べる上で役立ちます。ス
トライプ幅およびストライプ深度を選択する場合は、次の点を考慮してください。
■
■
同時実行性の低い（順次）システムでは、単一 I/O が同じディスクに 2 回アクセスしない
ようにします。たとえば、ストライプ幅が 4 つのディスクであり、ストライプ深度が 32KB
であると仮定します。1MB の単一 I/O リクエスト（たとえば、全表スキャンの場合）が
Oracle サーバー・プロセスで発行された場合、ストライプ内の各ディスクは要求された
データを戻すために 8 回 I/O を実行する必要があります。このような状況を回避するため
に、平均 I/O のサイズは、ストライプ深度とストライプ幅の積より小さいサイズにしてく
ださい。そうでない場合は、オペレーティング・システムに対して Oracle が単一 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 を発行する個々のプロセスが多数存
在するためです。粗密なストライプ化は、同時要求が少ないシステムで使用されると、ホッ
ト・スポットが生成される可能性があります。
I/O 構成および設計
8-3
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 ブロック・サイズの少なくと
も 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 は高度になりつつ
あり、ストライプ幅の動的な再構成を可能にするので、システムがオンライン中にディスクを
8-4
Oracle Database パフォーマンス・チューニング・ガイド
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 率がデータベースのパフォーマンスに影響を与える場合にのみ行ってください。
ファイルを分割する場合
オペレーティング・システムのストライプ化または手動 I/O 分散を使用するかどうかに関係な
く、I/O システムまたは I/O レイアウトが要求された I/O 率をサポートできない場合は、I/O
率の高いファイルをそれ以外のファイルから分離する必要があります。このようなファイルは
計画段階かシステムの本稼働後に確認できます。
ファイルを分離する決定は、I/O 率、リカバリ能力の問題、管理可能性の問題によってのみ影
響を受けます（たとえば、LVM がストライプ幅の動的な再構成をサポートしない場合、同一構
成の新しいストライプを作成して n 個のディスクを追加できるように、さらに小さいストライ
プ幅を作成する必要がある場合があります）
。
ファイルを分離する前に、ボトルネックが実際に I/O の問題であるかどうかを検証します。ボ
トルネックの調査から生成されたデータでは、最高の I/O 率を持つファイルを識別します。
関連項目 :
11-3 ページ「高負荷 SQL の識別」
I/O 構成および設計
8-5
I/O の基本構成
表、索引および TEMP 表領域
I/O の多いファイルが表および索引を含む表領域に属するデータファイルである場合は、これ
らのファイルの I/O を SQL のチューニングまたはアプリケーション・コードのいずれかで削減
できるかどうかを識別します。
I/O の多いファイルが TEMP 表領域に属するデータファイルである場合は、このアクティビ
ティを回避するためにディスク・ソートを実行する SQL 文をチューニングするか、あるいは
ソートをチューニングするかを調べます。
不要な I/O を回避するようにアプリケーションをチューニングした後、I/O レイアウトが引き
続き必要なスループットを維持できない場合は、I/O の多いファイルの分離を考慮してくださ
い。
関連項目 :
11-3 ページ「高負荷 SQL の識別」
REDO ログ・ファイル
I/O の多いファイルが REDO ログ・ファイルである場合は、REDO ログ・ファイルをその他の
ファイルから分離することを考慮してください。可能な構成には、次のことが含まれています。
■
■
■
■
すべての REDO ログを、他のファイルのない 1 つのディスクに置きます。可用性も考慮し
ます。すなわち、リカバリ能力の目的で、同じグループのメンバーは異なる物理ディスク
およびコントローラ上にあることが必要です。
他のファイルを格納しない個別のディスク上に各 REDO ログ・グループを置きます。
オペレーティング・システムのストライプ化ツールを使用して、複数のディスクにまた
がって 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-6
Oracle Database パフォーマンス・チューニング・ガイド
I/O の基本構成
図 8-1 ディスク間での REDO メンバーの分散
この例では、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-7
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 デバイスでは使用できません。
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
管理者ガイド』を参照してください。
8-8
Oracle Database パフォーマンス・チューニング・ガイド
I/O の基本構成
データ・ブロック・サイズの選択
8KB のブロック・サイズはほとんどのシステムにとって最適です。ただし、OLTP システムで
はより小さなブロック・サイズを、DSS システムではより大きなブロック・サイズを使用する
ことがあります。この項では、最適なパフォーマンスを得るためにデータベース・ブロック・
サイズを選択するときの考慮事項を説明します。
注意 : 管理性の問題があるため、単一データベース・インスタンスでの
複数のブロック・サイズの使用はお薦めしません。
読込み
データのサイズとは関係なく、目標は必要なデータを取り出すために必要な読込み回数を最小
にすることです。
■
■
■
■
行が小さく、アクセスがきわめてランダムな場合は、小さなブロック・サイズを選択しま
す。
行が小さく、アクセスがきわめて順次である場合は、大きなブロック・サイズを選択しま
す。
行が小さく、アクセスがランダムかつ順次である場合は、大きなブロック・サイズを選択
するのが有効です。
行が大きい（たとえば、ラージ・オブジェクト（LOB）データが含まれている）場合は、
大きなブロック・サイズを選択します。
書込み
同時実行性の高い OLTP システムで、大きなブロック・サイズを使用する場合は、INITRANS、
MAXTRANS および FREELISTS の適切な値について検討します。これらのパラメータは、ブ
ロック内で許可されている更新の同時実行性の程度に影響を与えます。ただし、自動セグメン
ト領域管理を使用する場合は、FREELISTS の値を指定する必要はありません。
選択する必要があるブロック・サイズが不明な場合、多数のトランザクションを処理するシス
テムでは、8KB のデータベース・ブロック・サイズを試行してください。これは優れた妥協案
であり、通常は有効です。8KB を超えるサイズが必要なのは LOB データを処理するシステムの
みです。
関連項目 : 使用しているプラットフォームの最小および最大のブロック・
サイズは、オペレーティング・システム固有の Oracle マニュアルを参照
してください。
I/O 構成および設計
8-9
I/O の基本構成
ブロック・サイズの長所と短所
表 8-3 に、様々なブロック・サイズの長所と短所を示します。
表 8-3 ブロック・サイズの長所と短所
ブロック・サイズ
長所
短所
小さい
行数が少なく大量のランダム・アクセス
に適しています。
メタデータ（すなわち、ブロック・ヘッダー）によ
る比較的大きな領域のオーバーヘッドがあります。
ブロック競合が低減されます。
行が大きい場合にはお薦めできません。1 行がブロッ
クに収まらない場合、1 ブロック当たりの格納行数が
わずかになったり、さらには行の連鎖が発生する可
能性があります。
オーバーヘッドが少ないため、データを
格納する空間が多くなります。
ブロック・サイズが大きい場合に少数の行にランダ
ム・アクセスすると、バッファ・キャッシュ内の領
域が消費されます。たとえば、8KB のブロック・サ
イズと 50 バイトの行サイズでは、ランダム・アクセ
スを行うときにバッファ・キャッシュ内の 7,950 バイ
トが消費されます。
大きい
1 回の I/O でバッファ・キャッシュに多
数の行を読み込めます（行サイズおよび
ブロック・サイズにより異なります）。
順次アクセスまたは非常に大きな行
（LOB データなど）に適しています。
8-10
OLTP 環境で使用される索引ブロックには適しませ
ん。これは、索引リーフ・ブロック上のブロック競
合が増えるためです。
Oracle Database パフォーマンス・チューニング・ガイド
9
オペレーティング・システム・リソース
この章では、Oracle データベース・サーバーのパフォーマンスを最適化するためにオペレー
ティング・システムをチューニングする方法を説明します。
この章には次の項があります。
■
オペレーティング・システムのパフォーマンスの問題の理解
■
オペレーティング・システムの問題の解決
■
CPU について
■
システムの CPU 使用率の調査
関連項目 :
■
■
プラットフォーム固有のチューニング情報は、使用しているプラット
フォーム固有の Oracle のマニュアルを参照してください。また、使
用しているオペレーティング・システム・ベンダーのマニュアルも参
照してください。
オペレーティング・システム統計情報の重要性の詳細は、5-5 ページ
の「オペレーティング・システム統計」を参照してください。
オペレーティング・システム・リソース
9-1
オペレーティング・システムのパフォーマンスの問題の理解
オペレーティング・システムのパフォーマンスの問題の理解
オペレーティング・システムのパフォーマンスの問題は、一般にプロセス管理、メモリー管理
およびスケジューリングに関係します。Oracle インスタンスをチューニングした後で、さらに
パフォーマンスを改善する必要がある場合は、作業方法を検証するか、システム時間の短縮を
試行してください。I/O 帯域幅、CPU 能力およびスワップ・スペースが十分にあることを確認
してください。ただし、オペレーティング・システムをさらにチューニングしても、それがア
プリケーションのパフォーマンスに大きな効果を与えることは期待できません。単にオペレー
ティング・システムをチューニングするよりも、Oracle の構成またはアプリケーションを変更
する方が、結果的にオペレーティング・システムの効率が大きく変わります。
たとえば、アプリケーションで buffer busy waits が非常に頻繁に発生する場合は、システム・
コールの回数が増加します。アプリケーションをチューニングすることで buffer busy waits を
削減すると、システム・コールの数が減少します。
この項では、オペレーティング・システムのパフォーマンスの問題に関する次の項目について
説明します。
■
オペレーティング・システムのキャッシュの使用
■
メモリー使用量
■
オペレーティング・システムのリソース・マネージャの使用
オペレーティング・システムのキャッシュの使用
オペレーティング・システムとデバイス・コントローラが提供するデータ・キャッシュは、
Oracle のキャッシュ管理と直接は衝突しません。ただし、パフォーマンスにほとんど利益にな
らないですし、これらの構造ではリソースが消費されます。このことは、UNIX ファイル・シ
ステムにデータベース・ファイルがある UNIX システムで最も顕著です。デフォルトでは、す
べてのデータベース I/O はファイル・システム・キャッシュ内を通過します。一部の UNIX シ
ステムでは、ファイル・システムへの直接 I/O が使用可能です。これによって、データベー
ス・ファイルは、ファイル・システム・キャッシュをバイパスして UNIX ファイル・システム
内でアクセスできます。これによって CPU リソースを節約でき、ファイル・システム・キャッ
シュを、プログラム・テキストやスプール・ファイルなどのデータベース以外のアクティビ
ティ専用にできます。
この問題は Windows では発生しません。データベースから要求されたファイルは、すべて
ファイル・システム内のキャッシュをバイパスします。
Oracle バッファ・キャッシュのバッファ・ブロックの存在により、オペレーティング・システ
ムのキャッシュは冗長になる場合がありますが、Oracle が Oracle バッファ・キャッシュを使用
しないこともよくあります。このような場合に、UNIX またはオペレーティング・システムの
キャッシュがバイパスされる直接 I/O、またはオペレーティング・システムのキャッシュが使
用されない RAW デバイスを使用すると、オペレーティング・システムのバッファリングを使
用したときより、パフォーマンスが劣化することがあります。これには次のような例がありま
す。
■
一時表領域での読込みまたは書込み
■
NOCACHE LOB に格納されるデータ
■
パラレル問合せスレーブで読み込まれるデータ
オペレーティング・システム・レベルでキャッシュするファイルと、キャッシュしないファイ
ルを混在させる必要がある場合があります。
9-2
Oracle Database パフォーマンス・チューニング・ガイド
オペレーティング・システムのパフォーマンスの問題の理解
非同期 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 を無効にします。
関連項目 : 詳細は、使用しているプラットフォーム固有のマニュアルを
参照してください。
メモリー使用量
メモリー使用量は、バッファ・キャッシュの制限と初期化パラメータの両方の影響を受けます。
バッファ・キャッシュの制限
UNIX バッファ・キャッシュはオペレーティング・システムのメモリー・リソースを消費しま
す。あるバージョンの UNIX では、UNIX バッファ・キャッシュに一定量のメモリーを割り当
てることができますが、現在ではより複雑なメモリー管理メカニズムが使用されるのが普通で
す。通常これらの管理メカニズムでは、I/O をキャッシュするために空きメモリー・ページを
使用できます。そのようなシステムでは、オペレーティング・システムのレポート・ツールは
空きメモリーがないことを示すのが普通で、通常は問題になりません。プロセスがより多くの
メモリーを必要とする場合、通常は I/O データをキャッシュするメモリーが開放されて、その
プロセス・メモリーを割り当てることができます。
メモリー使用量に影響を与えるパラメータ
Oracle セッションから要求されるメモリーは多数の要因に依存します。一般的に、大きな要因
には次のものがあります。
■
オープン・カーソルの数
■
PL/SQL で使用されるメモリー（PL/SQL 表など）
■
SORT_AREA_SIZE 初期化パラメータ
Oracle では、PGA_AGGREGATE_TARGET 初期化パラメータを使用することにより、セッション
のメモリー使用量をより完全に制御できます。
オペレーティング・システム・リソース
9-3
オペレーティング・システムのパフォーマンスの問題の理解
オペレーティング・システムのリソース・マネージャの使用
一部のプラットフォームではオペレーティング・システム・リソース・マネージャが提供され
ます。これらは、CPU のリソース割当てに優先順位を付けることによってピーク負荷使用パ
ターンの影響を少なくするように設計されています。これらは通常、ユーザーがアクセス可能
なリソースと各ユーザーがこれらのリソースのどの程度を消費可能かを統括する、管理方針を
実装します。
オペレーティング・システム・リソース・マネージャは、ドメインや類似のファシリティとは
異なります。ドメインは、1 つのシステム内で 1 つ、あるいは複数のまったく別の環境を提供
します。ディスク、CPU、メモリーおよびその他すべてのリソースがドメイン専用となってお
り、他のドメインからアクセスできません。他の類似のファシリティは、異なる領域、通常個
別の CPU またはメモリー領域へのシステム・リソースの一部として完全に分離されています。
ドメインと同様、個別のリソース領域はその領域に割り当てられた処理専用となっています。
プロセスは境界を超えて移行できません。ドメインとは異なり、その他すべてのリソース（通
常はディスク）は、システムのすべてのパーティションからアクセスできます。
Oracle はドメイン内で実行される他、パーティション化されたメモリー（RAM）リソースの割
当てが動的でなく、固定されている場合は、その他の不完全なパーティション構造体内で実行
されます。
オペレーティング・システム・リソース・マネージャは、リソースのグローバル・プール内、
通常はドメインあるいはシステム全体内でのリソース割当てに優先順位を設定します。プロセ
スはグループに割り当てられ、グループはリソース・プール内の任意の場所にあるリソースに
割り当てられます。
注意 : UNIX オペレーティング・システム・リソース・マネージャのメ
モリー管理および割当てファシリティと Oracle との併用はサポートされ
ません。Oracle インスタンス内でリソース割当て機能を提供する Oracle
Database Resource Manager は、オペレーティング・システムのリソー
ス・マネージャと併用できません。
注意 : オペレーティング・システム・リソース・マネージャで実行され
ている場合、Oracle は各インスタンスが専用オペレーティング・システ
ム・リソース・マネージャ・グループあるいは管理エンティティに割り当
てられている場合にのみサポートされます。また、すべてのインスタンス
のプロセスを実行している専用エンティティは、1 つの優先順位（または
リソース使用）レベルで実行される必要があります。異なる優先順位レベ
ルの個別の Oracle プロセスの管理は、サポートされません。インスタン
スの破壊などの重大な結果が発生します。
関連項目 :
■
■
9-4
オペレーティング・システムのリソース・マネージャ、および Oracle
と Oracle Database Resource Manager と併用して動作するリソース割
当て / 割当て解除機能の全リストについては、システム・ベンダーお
よび Oracle の代理店にお問い合せください。Oracle は特定リリース・
レベルとこれらのシステム機能との互換性を保証しません。
Oracle Database Resource Manager の詳細は、
『Oracle Database 管理
者ガイド』を参照してください。
Oracle Database パフォーマンス・チューニング・ガイド
オペレーティング・システムの問題の解決
オペレーティング・システムの問題の解決
この項では、様々なシステムでのチューニングのヒントを示します。次の項目について説明し
ます。
■
UNIX ベースのシステムのパフォーマンスに関するヒント
■
Windows システムのパフォーマンスに関するヒント
■
HP OpenVMS システムのパフォーマンスに関するヒント
プラットフォーム固有の問題をよく理解し、使用しているオペレーティング・システムが提供
するパフォーマンス・オプションを認識してください。
関連項目 : 使用しているプラットフォーム固有の Oracle マニュアルおよ
び使用しているオペレーティング・システム・ベンダーのマニュアル
UNIX ベースのシステムのパフォーマンスに関するヒント
UNIX システムでは、オペレーティング・システムが費やす時間量（システム・コールの処理
およびプロセス・スケジューリングの実行）とアプリケーションが実行する時間量の妥当な比
率を確立するようにしてください。システム・モードではなく、アプリケーション・モード
（ユーザー・モードとも呼ばれる）での実行に大部分の時間を費やすことを目標としてくださ
い。
各モードで消費される時間の比率は、潜在する問題の徴候にすぎず、次の項目に関係している
可能性があります。
■
ページングまたはスワッピング
■
実行しているオペレーティング・システム・コールが多すぎる状態
■
実行しているプロセスが多すぎる状態
このような条件が存在する場合は、アプリケーションの実行に使用できる時間は少なくなりま
す。オペレーティング・システム側の時間を多く解放するほど、アプリケーションが実行でき
るトランザクションの量が増えます。
Windows システムのパフォーマンスに関するヒント
UNIX ベースのシステムと同様に、Windows システムでは、アプリケーション・モードの時間
とシステム・モードの時間の比率を適切に設定してください。Windows 管理パフォーマンス・
ツールで多数の要因を容易に監視できます。CPU、ネットワーク、I/O およびメモリーはすべ
て、これらの領域でのボトルネックを容易に回避できるように同じグラフ上に表示されます。
HP OpenVMS システムのパフォーマンスに関するヒント
メインフレームのページング・パラメータを検討し、Oracle がパラメータの非常に大きな作業
セットを利用できることを覚えておいてください。
HP OpenVMS 環境での空きメモリーは、どのオペレーティング・システム・プロセスにも実際
にマップされていないメモリーです。ビジーなシステムでは、1 つ以上の現行のアクティブ・
プロセスに属するページを空きメモリーが含むことがよくあります。これがアクセスされると
「ソフト・ページ・フォルト」が発生し、ページにはそのプロセスの作業セットが組み込まれま
す。プロセスが作業セットを拡張できない場合は、プロセスによって現在マップされている
ページの 1 つを空きセットに移動する必要があります。
任意の数のプロセスが、作業セット内に共有メモリーのページを持つことができます。した
がって、作業セットのサイズの合計が使用可能メモリーを著しく超過することがあります。
Oracle サーバーの実行中は、SGA、Oracle カーネル・コードおよび Oracle Forms ランタイム
実行可能ファイルは一般にすべて共有可能であり、アクセスされるページのおよそ 80% または
90% に相当します。
オペレーティング・システム・リソース
9-5
CPU について
CPU について
CPU の問題を扱うには、まずシステムが使用する CPU リソースの量について、適切な見積り
を設定します。次に、十分な CPU リソースが使用可能かどうかを判断し、システムがいつリ
ソースを使用しすぎているかを認識します。最初に、次の 3 つのシステムの状況について
Oracle インスタンスが利用する CPU リソースの量を判断します。
■
システムがアイドル状態（Oracle のアクティビティがほとんど存在しないか、Oracle 以外
のアクティビティが存在する）の場合
■
システムが平均ワークロードの場合
■
システムがピーク・ワークロードの場合
自動ワークロード・リポジトリ、Statspack または UTLBSTAT/UTLESTAT ユーティリティを使
用して、様々なワークロードのスナップショットを取得できます。UNIX の vmstat、sar お
よび iostat や、Windows の管理パフォーマンス監視ツールなどのオペレーティング・システ
ム・ユーティリティは、V$OSSTAT や V$SYSMETRIC_HISTORY ビューとともに、自動ワーク
ロード・リポジトリ、Statspack、UTLBSTAT/UTLESTAT などと同じ間隔で使用し、統計全体の
補完ビューを提供します。
関連項目 :
■
■
5-8 ページ「自動ワークロード・リポジトリの概要」
Oracle ツールの詳細は、第 6 章「自動パフォーマンス診断」を参照し
てください。
システムの 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 トランザクションをサポートする必要があります。需要率が一定の場
合は、この平均ワークロードを満たすようにシステムを構築します。
9-6
Oracle Database パフォーマンス・チューニング・ガイド
CPU について
ただし、使用率のパターンは一定ではないので、この場合、1 分当たり 20 トランザクションと
いうのは単なる最低条件と考えられます。達成する必要があるピークの割合が 1 分当たり 120
トランザクションの場合は、このピーク・ワークロードをサポートできるシステムを構成する
必要があります。
この例で、ワークロードがピークのときに 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-8 ページの「システムの CPU 使用率の調査」を参照してください。
システム・アーキテクチャの変更など、ハードウェア容量を増加する場合。
関連項目 : システム・アーキテクチャの向上の詳細は、2-6 ページの「シ
ステム・アーキテクチャ」を参照してください。
■
CPU のリソース割当てに優先順位を付けることにより、ピーク負荷使用パターンの影響を
少なくする場合。Oracle Database Resource Manager は、データベース・ユーザーとアプ
リケーション間で CPU リソースを割り当て、管理することによって、次の方法でこれを実
行します。
–
各コンシューマ・グループのアクティブ・セッション数の制限
この機能は、各コンシューマ・グループに多数のパラレル問合せがあり、パラレル問
合せの総数を制限する場合に特に重要です。
–
CPU 飽和
CPU が 100% の使用率で稼働している場合に、Oracle Database Resource Manager を
使用して各コンシューマ・グループのセッションに対する CPU の割当てを最小限にで
きます。この機能により、優先順位の低いセッションの CPU 消費を削減できます。
–
リソース集中型の問合せ
Oracle Database Resource Manager は、コールの最大実行時間を制限することで、ま
たは長時間実行問合せを低優先順位の各コンシューマ・グループに移動することで、
リソース集中型の問合せによるダメージを制限できます。
関連項目 : Oracle Database Resource Manager の詳細は、
『Oracle
Database 管理者ガイド』を参照してください。
オペレーティング・システム・リソース
9-7
システムの CPU 使用率の調査
システムの CPU 使用率の調査
使用しているシステムで実行するすべてのプロセスが、使用可能な CPU リソースに影響を与え
ます。このため、Oracle 以外の要因をチューニングするとパフォーマンスが向上することがあ
ります。
V$OSSTAT または V$SYSMETRIC_HISTORY ビューを使用して、オペレーティング・システム
からのシステム使用率統計を監視します。V$OSSTAT および V$SYSMETRIC_HISTORY に含ま
れる有用な統計には、次のものがあります。
■
CPU の数
■
CPU 使用率
■
負荷
■
ページング
■
物理メモリー
関連項目 : V$OSSTAT および V$SYSMETRIC_HISTORY の詳細は、
『Oracle Database リファレンス』を参照してください。
オペレーティング・システムの監視ツールを使用して、システム全体で実行されているプロセ
スを確認します。システムの負荷が非常に高い場合は、この項で後述するメモリー、I/O およ
びプロセス管理の各項目をチェックしてください。
多くの UNIX ベースのシステムにある sar -u などのツールを使用すると、システム全体での
CPU 使用率のレベルを調べることができます。UNIX での CPU 使用率は、ユーザー時間、シ
ステム時間、アイドル時間および I/O の待機時間を示す統計で説明されます。ワークロードが
標準または低いときに、アイドル時間と I/O の待機時間が両方とも 0 に近い（5% 未満である）
場合は、CPU の問題が存在します。
Windows では、管理パフォーマンス・ツールを使用して CPU 使用率を監視します。このユー
ティリティは、プロセッサ時間、ユーザー時間、特権時間（privileged time）、割込み時間およ
び DPC 時間の統計を提供します。
この項では、システムの CPU 使用率のチェックに関する次の項目について説明します。
■
メモリー管理のチェック
■
I/O 管理のチェック
■
ネットワーク管理のチェック
■
プロセス管理のチェック
注意 : この項では、ほとんどの UNIX ベース・システムおよび Windows
システムにおける CPU 使用率のチェック方法を説明します。その他のプ
ラットフォームについては、使用しているオペレーティング・システムの
マニュアルを参照してください。
9-8
Oracle Database パフォーマンス・チューニング・ガイド
システムの CPU 使用率の調査
メモリー管理のチェック
次のメモリー管理項目をチェックします。
ページングとスワッピング
V$OSSTAT ビュー、UNIX の sar、vmstat などのユーティリティ、または Windows の管理パ
フォーマンス・ツールなどを使用して、ページングとスワッピングの原因を調査します。
大きすぎるページ表
UNIX では、処理領域が大きくなりすぎると、ページ表が大きくなりすぎることがあります。
これは Windows システムでは問題になりません。
I/O 管理のチェック
スラッシングは I/O 管理の課題です。システムのスラッシング（メモリー内外のスワッピング
およびページング処理）が発生しないように、ワークロードをメモリーに適合させてください。
オペレーティング・システムは固定サイズのタイム・スライスをユーザーのプロセスに割り当
て、プロセスはそのタイム・スライス中に CPU リソースを使用できます。プロセスが実行可能
かどうか、および必要な構成要素がすべてシステムにあるかどうかを確認するときに、プロセ
スが大半の時間を浪費すると、実際の作業の実行に割り当てられる時間はわずか 50% となるこ
とがあります。
関連項目 :
第 8 章「I/O 構成および設計」
ネットワーク管理のチェック
クライアント / サーバーのラウンドトリップをチェックします。メッセージを処理する際には
オーバーヘッドが発生します。アプリケーションで多数のメッセージを生成し、ネットワーク
を介して送信する必要がある場合、メッセージ送信の待機時間によって CPU のオーバーロード
が発生することがあります。この問題を軽減するには、多数のラウンドトリップを実行せずに、
複数のメッセージをまとめます。たとえば、配列挿入、配列フェッチなどを使用できます。
プロセス管理のチェック
この項で説明するいくつかのプロセス管理の項目をチェックする必要があります。
スケジューリングとスイッチング
オペレーティング・システムはスケジューリングおよびスイッチング処理に大量の時間を消費
することがあります。使用しているプロセスが多すぎる可能性があるので、オペレーティン
グ・システムの使用方法を検証してください。Windows システムでは、Oracle プロセス以外の
大量のプロセスによってサーバーが過負荷にならないようにしてください。
コンテキストのスイッチング
オペレーティング・システム固有の特性によって、システムがコンテキストのスイッチングに
大量の時間を消費することがあります。コンテキストのスイッチングは、特に超大規模 SGA の
場合には不経済です。インスタンス当たりのプロセスが 1 つのみである Windows では、コン
テキストのスイッチングは問題になりません。すべてのスレッドが同じページ表を共有します。
Oracle では、この項で説明する複数のコンテキストのスイッチング機能があります。
ポスト・ウェイト・ドライバ Oracle プロセスは、別の Oracle プロセスをポスト（メッセージ
の送信）でき、さらにポストされるのを待機できる必要があります。
たとえば、フォアグラウンド・プロセスが LGWR をポストして、指定の時点までのブロックを
すべて書き出してコミットを承認するよう、LGWR に通知する必要があります。
このポスト・ウェイト・メカニズムは、UNIX のセマフォを使用して実装するのが普通ですが、
これらのセマフォがリソース集中型である場合があります。したがって、一部のプラット
オペレーティング・システム・リソース
9-9
システムの CPU 使用率の調査
フォームでは、ポスト・ウェイト・ドライバを提供しています。通常は、ポスト・ウェイト・
インタフェースを簡単に実装できるカーネル・デバイス・ドライバが提供されます。
メモリーマップ済システム・タイマー Oracle では、システム時間を問い合せてタイミング情報
を得る必要が生じる場合があります。その場合、オペレーティング・システム・コールが実行
され、比較的コストのかかるコンテキストのスイッチングが発生することがあります。一部の
プラットフォームでは、メモリーマップ済タイマーを実装し、プロセス仮想アドレス空間のア
ドレスに現在のタイミング情報を収集します。このメモリーマップ済タイマーから時間を読み
込む方が、システム・コールのコンテキストのスイッチングのオーバーヘッドよりも経済的で
す。
1 回のコールで複数の非同期 I/O を発行するリスト I/O インタフェース リスト I/O とは、1 回の
システム・コールで複数の非同期 I/O リクエストを発行できる Application Program Interface
です。個別のシステム・コールで複数の I/O リクエストを発行する必要がありません。この機
能の主な利点は、コンテキストのスイッチングの所要回数が減少することです。
オペレーティング・システムの新規プロセスの開始
オペレーティング・システムの新規プロセスを開始する際には高いコストがかかります。プロ
グラマは、単一目的のプロセスを生成し、そのプロセスを終了後に、また新規のプロセスを生
成することがよくあります。この場合、そのつどプロセスの再生成と破壊が行われます。この
方法では、特に大規模な SGA を持つアプリケーションで CPU が集中して使用されます。これ
は、そのたびにページ表を構築する必要があるからです。共有メモリーを確保またはロックす
るときは、すべてのページにアクセスする必要があるため、問題が増大します。
たとえば、1GB の SGA がある場合は、4KB ごとにページ表のエントリがあり、1 つのページ表
のエントリは 8 バイトになります。エントリのサイズの合計は（1G ÷ 4KB）× 8 バイトになり
ます。ページ表がロードされていることを絶えず確認する必要があるので、これは不経済にな
ります。
9-10
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-8 ページの「自動ワークロード・リポジトリの概要」および 6-3
ページの「Automatic Database Diagnostic Monitor」を参照してください。
注意 : サイトに自動ワークロード・リポジトリおよび Automatic
Database Diagnostic Monitor 機能がない場合は、Statspack を使用して
Oracle インスタンス統計を収集できます。
問題の定義
ソリューションの実装を試みる前に、チューニング調査の目的と問題の性質をよく理解してお
くことが不可欠です。これについて理解していないと、事実上、効果的な変更は実装できませ
ん。この段階で収集されたデータを使用して、次に行うこと、および調査する事象を簡単に決
定できます。
次のデータを収集します。
1.
パフォーマンスの目的を識別します。
許容できるパフォーマンスの測定尺度は何ですか ?1 時間、または 1 秒間当たり何件のトラ
ンザクションで、応答時間が必要なパフォーマンス・レベルを満たしますか ?
2.
問題の範囲を識別します。
スローダウンで何が影響を受けますか ? たとえば、インスタンス全体は低速ですか ? それ
は、特定のアプリケーション、プログラム、特定の操作またはシングル・ユーザーですか ?
3.
問題が発生したときの時間帯を識別します。
その問題はピーク時間のみ明白ですか ? パフォーマンスはその日の経過に伴って低下しま
すか ? スローダウンは徐々に（月または週の単位で）発生しましたか、または突然発生し
ましたか ?
10-2
Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
4.
スローダウンを検証します。
これは、問題の範囲の識別に役立ち、問題の修復のために実装された変更により実際に改
善されたかどうかを判断するときの比較結果の測定基準としての役割を果たします。一貫
して再生可能な応答時間またはジョブ実行時間の測定値を検索します。プログラムの動作
が正常だったときよりタイミングがどのくらい悪化していますか ?
5.
変更を識別します。
パフォーマンスが許容可能になった後に変化した内容を識別します。これにより、潜在的
な原因を素早くつきとめることができます。たとえば、オペレーティング・システムのソ
フトウェア、ハードウェア、アプリケーション・ソフトウェアまたは Oracle リリースが
アップグレードされましたか ? さらに多くのデータがシステムにロードされたか、デー
タ・ボリュームまたはユーザー人口が増加しましたか ?
このフェーズの終わりまでに、症状についてよく理解しておく必要があります。症状をプログ
ラムまたはプログラム・セットにローカルなものとして識別できる場合、その問題はインスタ
ンス全体のパフォーマンスの問題とは異なる方法で処理されます。
関連項目 : アプリケーションまたはユーザーに固有なパフォーマンスの
問題の解決については、第 11 章「SQL チューニングの概要」を参照して
ください。
ホスト・システムの検査
データベース・サーバーに対する負荷とデータベース・インスタンスを調べてください。オペ
レーティング・システム、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-3
インスタンスのチューニング手順
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-12 ページの表 10-1「待機イベントおよび潜在的な原因」を参照してください。
I/O の問題の検出
過度にアクティブな I/O システムは、2 より大きいディスク・キューの長さ、すなわち、20 ～
30 ミリ秒を超えるディスク・サービス時間でわかります。I/O システムが過度にアクティブで
ある場合、さらに多くのディスク間に I/O を分散させることで利益を得られる潜在的なホッ
ト・スポットの有無をチェックします。また、これらのリソースを使用して、プログラムのリ
ソース要件を少なくして負荷を減らせるかどうかも識別します。
オペレーティング・システムの監視ツールを使用して、システム全体で実行されているプロセ
スを判別し、すべてのファイルに対するディスク・アクセスを監視してください。データファ
イルと REDO ログ・ファイルを保持しているディスクは、Oracle に関連しないファイルも保持
している可能性があります。データベース・ファイルを含むディスクに対する過度のアクセス
を減らしてください。Oracle 以外のファイルへのアクセスは、V$ ビューを介してではなく、オ
ペレーティング・システムの機能を介してのみ監視できます。
多数の UNIX システム上の sar -d（または iostat）や Windows システム上の管理パフォー
マンス監視ツールなどのユーティリティは、システム全体の I/O 統計を調べます。
関連項目 : プラットフォームで使用可能なツールのオペレーティング・
システムのマニュアル
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 に関連しない待機イベントが明らかになる場合もあります。たとえ
ば、バッファ・キャッシュ内で空きバッファを検出できない場合や、ディスクへのログ書込み
10-4
Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
が完了するまでの待機時間が長い場合も、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 をすべて使用している理由を判断し、次にこの
プロセスをチューニングします。
関連項目 :
■
■
■
■
第 11 章「SQL チューニングの概要」
動的パフォーマンス・ビュー V$SQLAREA の詳細は、
『Oracle
Database リファレンス』を参照してください。
第 8 章「I/O 構成および設計」
散布読取りと順次読取りの違い、およびそれが I/O に与える影響は、
10-19 ページの「db file scattered read」および 10-21 ページの「db
file sequential read」を参照してください。
ネットワーク
オペレーティング・システムのユーティリティを使用して、ネットワーク・ラウンドトリップ
の ping 時間と衝突数を調べます。ネットワークで応答時間の大幅な遅延が発生している場合
は、考えられる原因を調べてください。
ネットワーク負荷を減らすには、大きいデータ転送をピーク時間外へスケジュールするか、リ
モート・ホストに対して要求当たり 1 回ずつ（またはそれ以上）アクセスせずに、要求をバッ
チ処理するようにアプリケーションをコーディングします。
Oracle 統計の調査
問題の診断の一貫性が保たれるようにするには、Oracle 統計を調べてオペレーティング・シス
テムの統計と相互参照してください。ただし、目標が Oracle インスタンスをチューニングする
ことにあれば、修正アクションを実装する前に Oracle 統計を調べて Oracle の観点からリソー
ス・ボトルネックを識別します。10-9 ページの「Oracle 統計の解釈」を参照してください。
チューニング中に使用する一般的な Oracle データ・ソースを次に示します。
統計収集のレベルの設定
Oracle では、初期化パラメータ STATISTICS_LEVEL を提供し、データベース内で主要統計収
集またはアドバイザをすべて制御します。このパラメータでは、データベースに統計収集レベ
ルを設定します。
STATISTICS_LEVEL の設定に応じて、次のように一定のアドバイザ機能または統計が収集さ
れます。
■
■
■
BASIC: アドバイザ機能も統計も収集されません。監視機能および多数の自動機能が使用禁
止になります。重要な Oracle 機能が使用禁止になるため、この設定は使用しないことをお
薦めします。
TYPICAL: これはデフォルト値であり、すべての主要統計が収集され、データベース全体
のパフォーマンスが最高になります。ほとんどの環境では、この設定で十分です。
ALL: TYPICAL 設定を使用して収集されるすべてのアドバイザ機能と統計に加えて、オペ
レーティング・システム時間統計および行ソース実行統計が含まれます。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-5
インスタンスのチューニング手順
関連項目 :
■
■
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
STATISTICS_LEVEL、DB_CACHE_ADVICE、TIMED_STATISTICS ま
たは TIMED_OS_STATISTICS 初期化パラメータを設定する場合の考
慮事項は、5-6 ページの「統計の解釈」を参照してください。
V$STATISTICS_LEVEL このビューには、STATISTICS_LEVEL で制御される統計またはアドバイ
ザ機能のステータスがリストされます。
関連項目 : 動的パフォーマンス・ビュー V$STATISTICS_LEVEL の詳細
は、
『Oracle Database リファレンス』を参照してください。
待機イベント
待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示す
ために、サーバー・プロセスまたはスレッドによって増やされる統計です。待機イベント・
データは、ラッチの競合、バッファの競合、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-5
ページの「統計収集のレベルの設定」を参照してください。
待機イベント統計を含む動的パフォーマンス・ビュー
待機イベント統計について、これらの動的パフォーマンス・ビューを問い合せることができま
す。
■
V$ACTIVE_SESSION_HISTORY
V$ACTIVE_SESSION_HISTORY ビューには、1 秒ごとにサンプリングされたアクティブな
データベース・セッションのアクティビティが表示されます。5-4 ページの「Active
Session History（ASH）
」を参照してください。
■
V$SESS_TIME_MODEL および V$SYS_TIME_MODEL
V$SESS_TIME_MODEL および V$SYS_TIME_MODEL ビューには、データベース・コールの
所要時間合計である DB time など、時間モデル統計が含まれます。
10-6
Oracle Database パフォーマンス・チューニング・ガイド
インスタンスのチューニング手順
■
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 ビューは、待機数に対するインスタンス全体の総時間および待機
イベントの各クラスで消費される時間を示します。
■
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-15 ページの
「待機イベント統計」を参照してください。
システム統計
システム統計は通常、パフォーマンスの問題の原因をさらに示すものを見つけるために、待機
イベント・データとともに使用されます。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-7
インスタンスのチューニング手順
たとえば、最大の待機イベント（待機時間の点で）が 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 統計が含まれています。
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-8
Oracle Database パフォーマンス・チューニング・ガイド
Oracle 統計の解釈
変更の実装および測定
チューニングを実施した後、多くの場合、問題を軽減できると思われる 2 つまたは 3 つの変更
を識別できます。どの変更が最高の利益を提供するかを識別するには、一度に 1 回の変更を実
装することをお薦めします。変更の効果は、問題定義段階でみられたベースライン・データ測
定と対照して測定する必要があります。
一般に、パフォーマンスの問題を持つ大半のサイトでは、一度に重複した変更を実装するので、
どの変更が利益を実現したかを識別できません。これはすぐに問題になることはありませんが、
どの変更が最も効果をあげ、どのような作業を優先する必要があるかを知ることは不可能なの
で、今後同様の問題が発生した場合に大きな障害になります。
個別に変更を実装できない場合は、異なる変更の効果の測定を試みてください。たとえば、変
更された問合せのパフォーマンスを向上するために新しい索引を作成する効果とは別に、
REDO の生成を最適化するために初期化変更を行う効果を測定します。SQL がチューニングさ
れ、オペレーティング・システムのディスク・レイアウトが変更され、初期化パラメータも同
時に変更されている場合は、オペレーティング・システムをアップグレードすることの利益は
測定できません。
パフォーマンス・チューニングは反復的なプロセスです。インスタンス・ワイドのパフォーマ
ンスの問題を解決する万全策が見つかることはほとんどありません。ほとんどの場合、あるボ
トルネックを解決しても別の（ときにはさらに悪い）問題が発生するため、優れたパフォーマ
ンスにはパフォーマンス・チューニング段階を反復する必要があります。
いつチューニングを停止するかを知ることも重要です。パフォーマンスの最も優れた測定は、
統計が理想的な値にどの程度近いかではなく、ユーザーの理解力です。
Oracle 統計の解釈
インスタンスにパフォーマンスの問題があった時を示す統計を収集します。比較のためのベー
スライン・データをすでに収集してある場合は、問題のワークロードを最も代表するベースラ
インからのデータと、現行のデータを比較できます。
2 つのレポートを比較する場合、それらのレポートが、システムを比較できるようなワーク
ロードか確認してください。
関連項目 :
5-2 ページ「データ収集の概要」
負荷の検査
待機イベントは通常、最初に検査するデータです。ただし、ベースライン・レポートがある場
合は、負荷が変化したかどうかをチェックします。ベースラインがあるかどうかにかかわらず、
リソースの使用率が高いかどうかを確認すると便利です。
検査する負荷に関連する統計には、redo size、session logical reads、db block
changes、physical reads、physical read total bytes、physical writes、
physical write total bytes、parse count（total）、parse count（hard）および
user calls が含まれます。このデータは、V$SYSSTAT から問合せが行われます。秒ごとおよ
びトランザクションごとに、このデータを正規化することが最も有効です。また、physical
write total bytes および physical write total bytes の合計を使用して、1 秒当た
りの I/O の総負荷（MB）を調べるのにも便利です。結合した値には、Oracle バックグラウン
ド・プロセスと同様 Recovery Manager バックアップおよびリカバリによって、バッファ・
キャッシュ、REDO ログ、アーカイブ・ログに使用された I/O が含まれます。
自動ワークロード・リポジトリ・レポートの「ロード・プロファイル」の項を参照してくださ
い。データは、トランザクションおよび秒ごとに正規化されています。
負荷の変更
秒ごとの負荷プロファイル統計は、スループットの変化（すなわち、インスタンスの作業実行
量が毎秒ごとに増えているかどうか）を示します。トランザクションごとの統計は、アプリ
ケーション特性の変化をベースライン・レポートからの対応する統計と比較することで識別し
ます。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-9
Oracle 統計の解釈
高いアクティビティ率
アクティビティ率が非常に高いかどうかを識別するには、秒ごとに正規化した統計を調べます。
包括的に高い値を推薦することが難しいのは、しきい値が各サイトで異なり、アプリケーショ
ン特性、CPU の個数と速度、オペレーティング・システム、I/O システムおよび Oracle リ
リースで異なるからです。
次に、いくつかの一般化された例を示します（許容値は各サイトで異なります）
。
■
■
■
秒当たり 100 を超えるハード解析率は、非常に大量なハード解析がシステム上にあること
を示します。高いハード解析率は重大なパフォーマンスの問題を発生させるので、調査す
る必要があります。通常は、高いハード解析率に共有プール上のラッチの競合とライブラ
リ・キャッシュ・ラッチが伴います。
ライブラリ・キャッシュおよび共有プール・ラッチ・イベント（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-13 ページの「追加された統計
情報」を参照してください。
待機イベント・データを使用する最も効率的な方法は、待機時間別にイベントを順序付けする
ことです。この方法は、TIMED_STATISTICS が true に設定されているときのみ可能です。
設定しない場合は、待機イベントを待機数別にランク付けします。これは、一般的に問題を最
もよく表す順序付けではありません。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-5 ページの「統計収集のレ
ベルの設定」を参照してください。
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
など）を除くすべての待機イベントの合計待機時間を追加します。各イベントの待機時間
をすべてのイベントの総待機時間で除算し、5 つの最も重要なイベントの相対的なパーセ
ンテージを計算します。
10-10
Oracle Database パフォーマンス・チューニング・ガイド
Oracle 統計の解釈
関連項目 :
■
■
■
アイドル待機イベントのリストは、10-34 ページの「アイドル待機イ
ベント」を参照してください。
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
3.
トップの待機イベントは、次に調査する場所を識別します。表 10-1 に、一般的な待機イベ
ントを示します。高負荷 SQL を調べることもお薦めします。
4.
待機イベントで指示される関連データを調べて、このデータから得られる他の情報を確認
します。この情報が待機イベント・データとの一貫性を持っているかどうかを判断します。
ほとんどの場合、パフォーマンス・ボトルネックの潜在的な原因に関する理論の展開を開
始するためのデータは十分にあります。
5.
この理論が有効であるかどうかを判断するには、利用可能な他の統計ですでに調べたデー
タの一貫性をクロスチェックします。適切な統計は問題により異なりますが、通常は
V$SYSSTAT やオペレーティング・システム統計などにある、負荷のプロファイル関連の
データが含まれています。他のデータとのクロスチェックを行って、展開中の理論を肯定
または否定します。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-11
Oracle 統計の解釈
待機イベントおよび潜在的な原因の表
表 10-1 に、待機イベントと考えられる原因との関連付けの他、次に検討するのに最も有益と思
われる Oracle データの概要を示します。
表 10-1 待機イベントおよび潜在的な原因
待機イベント
一般的な領域
考えられる原因
検索 / 調査
buffer busy
waits
バッファ・
キャッシュ、
DBWR
バッファ・タイプによって異
なります。たとえば、索引ブ
ロックの待機は、昇順に基づ
く主キーが原因である場合が
あります。
問題が発生している間に V$SESSION を調べ、
競合したブロックのタイプを判別します。
free buffer
waits
バッファ・
キャッシュ、
DBWR、I/O
低速な DBWR（おそらく I/O オペレーティング・システム統計を使用して
書込み時間を調べます。キャッシュが小さす
に起因）
ぎることの証拠があるかどうかについてバッ
小さすぎるキャッシュ
ファ・キャッシュ統計をチェックします。
db file
scattered read
I/O、SQL 文の チューニングが適切ではない
SQL
チューニング
低速な I/O システム
I/O、SQL 文の チューニングが適切ではない
SQL
チューニング
db file
sequential read
低速な I/O システム
enqueue 待機（enq: ロック
で始まる待機）
エンキューのタイプにより異
なる
ライブラリ・キャッ
シュ・ラッチ待機 :
library cache、
library cache pin
および library
cache lock
ラッチの競合
SQL の解析または共有
log buffer space
ログ・バッファ 小さいログ・バッファ
の I/O
低速な I/O システム
log file sync
I/O、コミット
過剰
オンライン・ログを格納する
低速なディスク
バッチされないコミット
V$SQLAREA を調べて、多数のディスク読込
みを実行する SQL 文があるかどうかを確認し
ます。I/O システムと V$FILESTAT をクロス
チェックして、長い読込み時間をチェックし
ます。
V$SQLAREA を調べて、多数のディスク読込
みを実行する SQL 文があるかどうかを確認し
ます。I/O システムと V$FILESTAT をクロス
チェックして、長い読込み時間をチェックし
ます。
V$ENQUEUE_STAT を参照します。
V$SQLAREA を調べて、比較的多数の解析
コールまたは多数の子カーソルを使用する
SQL 文があるかどうかを確認します
（VERSION_COUNT 列）。V$SYSSTAT の解析
統計と毎秒の対応する割合を調べます。
V$SYSSTAT の統計 redo buffer
allocation retries をチェックします。
メモリーの構成の章の、ログ・バッファの構
成の項をチェックしてください。オンライン
REDO ログを格納するディスクをチェックし
て、リソースの競合の有無をチェックしま
す。
オンライン REDO ログを格納するディスクを
チェックして、リソースの競合の有無を
チェックします。V$SYSSTAT から毎秒のト
ランザクション数（コミット数＋ロールバッ
ク数）をチェックします。
また、Oracle Metalink で buffer busy waits（34405.1）および free buffer waits
（62172.1）に関する次の通知も確認する必要があります。
■
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_
id=NOT&p_id=34405.1
■
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_
id=NOT&p_id=62172.1
これらの通知および関連通知にアクセスするには、次の URL で「busy buffer waits」と「free
buffer waits」を検索する方法もあります。
http://metalink.oracle.com
10-12
Oracle Database パフォーマンス・チューニング・ガイド
Oracle 統計の解釈
関連項目 :
■
■
表 10-1 にリストした各イベントの詳細およびクロスチェックするその
他の情報は、10-15 ページの「待機イベント統計」を参照してくださ
い。
動的パフォーマンス・ビューの詳細は、
『Oracle Database リファレン
ス』を参照してください。
追加された統計情報
対応する待機イベントを持たないパフォーマンスの問題を示すことのできる統計は多数ありま
す。
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 管理を使用することをお薦めします。
■
ロールバック・セグメントが十分にない場合、ロールバック・セグメント（ヘッダーまた
はブロック）の競合が発生します。この問題は、次のようにすると明らかになります。
■
■
WAITS 数を V$ROLLSTAT 内の GETS 数と比較する方法。GETS に対する WAITS の比率
は小さい値である必要があります。
V$WAITSTAT を調べて、CLASS 'undo header' のバッファに対して多数の WAITS があ
るかどうかを確認する方法。
解決策は、自動 UNDO 管理を使用することをお薦めします。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-13
Oracle 統計の解釈
継続行による表フェッチ
V$SYSSTAT 内の table fetch continued row 統計数をチェックして、移行行または連鎖行
を検出できます。少数の連鎖行（1% 以下）は、システム・パフォーマンスに影響を与える可能
性はほとんどありません。ただし、連鎖行のパーセンテージが大きいと、パフォーマンスに影
響を与える可能性があります。
ブロック・サイズより大きい行の連鎖は避けられません。そのようなデータについては、ブ
ロック・サイズのより大きい表領域の使用を考慮してください。
ただし、小さい行の場合は、適切な領域パラメータとアプリケーション設計を使用することで
連鎖を回避できます。たとえば、キー値が入力され、かつその他のほとんどの列が NULL であ
る行を、実際のデータで更新しないでください。その行のサイズが大きくなります。その場合
は初めからデータが入力された行を挿入します。
UPDATE 文が行のデータ量を増やし、行がそのデータ・ブロックに収まらなくなった場合、
Oracle は行全体を保持するのに十分な空き領域を持つ別のブロックを見つけようとします。そ
のようなブロックが利用可能であれば、Oracle は新しいブロックへ行全体を移動します。これ
を行の移行と呼びます。行が大きすぎて利用可能なブロックに収まらない場合、Oracle はその
行を複数の断片に分割し、各断片を別々のブロックに格納します。これを行の連鎖と呼びます。
行は挿入時にも連鎖される可能性があります。
移行と連鎖は、特に次の場合のパフォーマンスに影響があります。
■
移行と連鎖の原因となる UPDATE 文のパフォーマンスはよくありません。
■
移行行または連鎖行が追加入出力を実行するため、これらの行を選択する問合せをします。
サンプルの出力表 CHAINED_ROWS の定義が、配布媒体上の使用可能な SQL スクリプトに収録
されています。このスクリプトの一般的な名前は UTLCHN1.SQL ですが、正確な名前と位置は
使用しているプラットフォームによって異なります。出力表は、CHAINED_ROWS 表と同じ列
名、データ型およびサイズである必要があります。
移行行を回避するには、PCTFREE を増やします。ブロック内に使用可能な空き領域を多く残し
ておくと、行の拡張に対処できます。削除割合が高い表と索引を再編成すなわち再作成するこ
ともできます。頻繁に行が削除される表の場合は、データブロックに部分的に空き領域が生じ
ることがあります。行を挿入し後から拡張する場合、行の削除されたブロックにその行が挿入
されることがありますが、拡張の余地はありません。表を再編成すると主な空き領域を完全に
空のブロックにできます。
注意 :
PCTUSED は、PCTFREE の反対の意味ではありません。
関連項目 :
■
■
PCTUSED の詳細は、『Oracle Database 概要』を参照してください。
表の再編成の詳細は、
『Oracle Database 管理者ガイド』を参照してく
ださい。
解析関連の統計
アプリケーションの解析が長くなるほど、競合の可能性が高くなり、システムの待機時間が長
くなります。parse time CPU（CPU 解析時間）が CPU タイムの大半を占める場合、SQL 文
の実行ではなく解析に時間が消費されています。この場合には、アプリケーションはリテラル
SQL を使用しているために SQL を共有できないか、または共有プールの構成が適切でないこと
があります。
関連項目 :
10-14
第 7 章「メモリーの構成と使用方法」
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
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 の大
部分が解析に費やされないことを示します。
待機イベント統計
V$SESSION、V$SESSION_WAIT、V$SESSION_EVENT および V$SYSTEM_EVENT の各ビュー
は、どのようなリソースを待機したかに関する情報を表示し、構成パラメータ
TIMED_STATISTICS が true に設定されている場合は、各リソースを待機した時間に関する
情報も表示されます。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-5 ページの「統計収集のレ
ベルの設定」を参照してください。
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 内に読み込まれたブロック番号およ
パフォーマンス・ビューを使用したインスタンスのチューニング
10-15
待機イベント統計
び P3 内に読み込まれたブロック数を示します（P1 と P2 により待機イベントがどのセグメン
トに対して発生するかを判断できます）
。
この章では、V$SESSION_WAIT の使用例を中心に説明します。ただし、時間間隔のパフォーマ
ンス・データの収集と、パフォーマンスおよび容量分析のためにこのデータを保存することを
お薦めします。この形式のロールアップ・データの問合せは、自動ワークロード・リポジトリ
により V$SYSTEM_EVENT ビューから行います。5-8 ページの「自動ワークロード・リポジトリ
の概要」を参照してください。
最も一般的に発生するイベントについては、この章で、大 / 小文字を区別するアルファベット
順にリストして説明します。調べる対象の他のイベント関連データも含まれています。各イベ
ント名に使用する大 / 小文字区別は、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-16
このイベントに対する多数の待機
データベースとクライアント・プロセスは、時間のほとんどがアイドル状態（ネットワー
ク通信待ち状態）です。
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
ネットワーク・ボトルネックを軽減するには、次のことを試行します。
■
■
■
アプリケーションをチューニングしてラウンドトリップを軽減します。
待機時間を削減するためのオプション（たとえば、VSAT リンクとは反対の地上回線）を探
索します。
通信量の大きいコンポーネントを待機時間の少ないリンクに移動するように、システム構
成を変更します。
クライアント・プロセス上のリソース・ボトルネック クライアント・プロセスがリソースの大
半を使用している場合、データベース内で実行できることはありません。症状には次のものが
あります。
■
待機数は多くなくても、待機時間は長い。
■
クライアント・プロセスは、リソースを多く使用している。
場合によっては、クライアント・プロセスで使用される CPU の量により、待機しているユー
ザーのトラッキングのための待機時間がわかります。この場合のクライアントという用語は、
n 層アーキテクチャにおける、データベース・プロセス（中間層、デスクトップ・クライアン
ト）以外の任意のプロセスを指します。
SQL*Net message from dblink
このイベントは、セッションがリモート・ノードにメッセージを送り、データベース・リンク
からの応答を待機している状態であることを意味します。この時間は、次の理由で増える可能
性があります。
■
ネットワーク・ボトルネック
詳細は、10-16 ページの「SQL*Net message from client」を参照してください。
■
リモート・ノードで SQL を実行するのに要する時間
リモート・ノードで実行されている SQL を確認することが有益です。リモート・データ
ベースにログインし、データベース・リンクで作成されたセッションを検索し、そのセッ
ションで実行される SQL 文を調べます。
■
ラウンドトリップ・メッセージの数
セッションとリモート・ノード間の各メッセージにより、遅延時間が長くなり、処理オー
バーヘッドが増加します。交換されるメッセージの数を減らすには、配列フェッチと配列
挿入を使用します。
SQL*Net more data to client
サーバー・プロセスは、クライアントにさらに多くのデータまたはメッセージを送信します。
クライアントに対する以前の操作も送信されました。
関連項目 : ネットワーク最適化の詳細は、『Oracle Database Net Services
管理者ガイド』を参照してください。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-17
待機イベント統計
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;
処置
必要な処置は、競合対象のクラスと実際のセグメントにより異なります。
セグメント・ヘッダー 競合がセグメント・ヘッダー上にある場合、これは最も起こりうる空き
リストの競合です。
ローカルに管理されている表領域で自動セグメント領域管理を行えば、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 概要』を参照してください。
10-18
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
データ・ブロック 表または索引（セグメント・ヘッダーではない）に対する競合がある場合、
次のようにします。
■
■
昇順インデックスを調べます。これは、多数のプロセスによって同じ点に挿入される索引
です。たとえば、キー値に順序番号ジェネレータを使用する索引をチェックしてください。
自動セグメント領域管理（ASSM）またはグローバル・ハッシュ・パーティション索引を
使用するか、空きリストを増やして複数のプロセスが同じブロック内に挿入されないよう
にすることを検討してください。
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 負荷を示す他の要素として、次のものがあります。
■
低いバッファ・キャッシュ・ヒット率
■
ユーザーへの応答時間を長くしている待機時間のほとんどを発生させている待機イベント
過剰な I/O の管理
過剰な I/O 待機を処理する方法はいくつかあります。有効性の順に示すと、これらの方法は次
のとおりです。
1.
SQL チューニングによる I/O アクティビティの削減。
2.
ワークロードの管理による、I/O を実行する必要性の削減。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-19
待機イベント統計
3.
DBMS_STATS パッケージを使用したシステム統計の収集。これにより、問合せオプティマ
イザでは、全体スキャンを使用する、可能なアクセス・パスのコストを正確に計算できま
す。
4.
自動ストレージ管理の使用。
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 アクティビティを含めてくださ
い。
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;
10-20
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
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-19 ページ
の「db file scattered read」を参照してください。
処置
健全なシステムでは、物理読込み待機がアイドル待機後の最大待機である必要があります。た
だし、パラレル問合せを持つ、全表スキャンに近いスキャンの必要な大きいデータ・ウェアハ
ウス上に、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-21
待機イベント統計
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-35 ページの「PGA メモリー管理」を参照してください。
全表スキャン 高い並列度で表を定義すると、全表スキャンをパラレル・スレーブで検索するよ
うにオプティマイザを偏らせることができます。ダイレクト・パス読取りを使用して読み取る
オブジェクトをチェックします。全表スキャンがワークロードの有効な部分である場合は、
I/O サブシステムが並列度に対して適切に構成されているかどうかを確認します。ディスクの
ストライプ化または自動ストレージ管理（ASM）を使用していない場合は、ディスクのストラ
イプ化を使用することを考慮してください。
ハッシュ領域サイズ ハッシュ結合を呼び出す問合せ計画の場合、過剰な I/O は
HASH_AREA_SIZE が小さすぎることから発生する可能性があります。
WORKAREA_SIZE_POLICY が MANUAL である場合、システムまたは個々のプロセスの
HASH_AREA_SIZE を大きくすることを検討してください。WORKAREA_SIZE_POLICY が AUTO
である場合、PGA_AGGREGATE_TARGET を大きくするかどうかを調べます。
関連項目 :
10-22
■
10-19 ページ「過剰な I/O の管理」
■
7-35 ページ「PGA メモリー管理」
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
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 - 書込みコール内のブロック数
原因
これは次の状況で発生します。
■
ソートが大きすぎ、メモリー内に収まらないため、ディスクに書き込まれる。
■
オブジェクトを作成 / 移入するために、パラレル DML が発行される。
■
ダイレクト・パス・ロード。
処置
大規模なソートについては、10-22 ページの「ディスクでのソート」を参照してください。
パラレル 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-23
待機イベント統計
ロックおよびロック・ホルダーの検索
ロックを保持するセッションを見つけるには、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 文でエクステントを割り当てる方法などです。
HW エンキュー HW エンキューは、セグメントの最高水位標を超える領域の割当てをシリアラ
イズする場合に使用します。
■
■
V$SESSION_WAIT.P2 / V$LOCK.ID1 は表領域番号です。
V$SESSION_WAIT.P3 / V$LOCK.ID2 は、領域が割り当てられるオブジェクトのセグメン
ト・ヘッダーの相対 DBA です。
これがオブジェクトの競合点である場合、エクステントの手動割当てにより問題が解決されま
す。
TM エンキュー TM ロック上の待機の最も一般的な理由は、制約される列が索引付けされない
場合の外部キー制約に関係している傾向があります。この問題を回避するには、外部キー列を
索引付けします。
10-24
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
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
を実行させることです。
■
■
■
モード 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 アドバンスト・アプリケーション開発者ガイド』を参照してくだ
さい。
events in wait class other
このイベントは、
「その他」の待機クラスに属し、通常はシステムで発生しないようにしてくだ
さい。このイベントは、latch free など、
「その他」の待機クラスのその他すべてのイベン
トの集計であり、V$SESSION_EVENT および V$SERVICE_EVENT ビューでのみ使用されま
す。これらのビューでは、
「その他」待機クラスのイベントは、セッションごとにはメンテナン
スされません。かわりに、この 1 つのイベントにロール・アップされ、
「その他」待機クラスの
イベント統計をメンテナンスするためのメモリーを削減します。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-25
待機イベント統計
free buffer waits
この待機イベントは、サーバー・プロセスが空きバッファを検索できず、使用済バッファを書
き出すことによって空きバッファを作成するためにデータベース・ライターを転送したことを
示します。使用済バッファは、内容が変更されたバッファです。使用済バッファは、DBWR が
ブロックをディスクに書き込み終えると、再利用するために解放されます。
原因
DBWR は、次の状況では使用済バッファの書込みを継続できない場合があります。
■
I/O システムが低速である。
■
I/O システムが待機しているラッチなどのリソースがある。
■
■
バッファ・キャッシュが小さすぎるため、DBWR はサーバー・プロセスのバッファのク
リーニングに大部分の時間を費やす。
バッファ・キャッシュが大きすぎるため、DBWR プロセスは要求を満たすだけのキャッ
シュ内のバッファを十分に解放できない。
処置
このイベントが頻繁に発生する場合は、DBWR に対するセッション待機を調べて、DBWR を遅
らせる原因があるかどうかを確認してください。
書込み セッションが書込みを待機している場合は、書込みを遅らせている原因を解明し、修正
してください。次の点をチェックします。
■
■
V$FILESTAT を調べて、書込みの大半が発生する場所を確認してください。
I/O システムのホスト・オペレーティング・システム統計を調べてください。書込み時間
は許容できるものですか ?
I/O が低速である場合は、次のようにしてください。
■
■
さらに高速な I/O 手段を使用して書込み時間を高速化することを検討してください。
多数のスピンドル（ディスク）とコントローラの間に I/O アクティビティを拡散してくだ
さい。I/O のバランス化については、第 8 章「I/O 構成および設計」を参照してください。
キャッシュが小さすぎる場合 キャッシュが小さすぎるために DBWR が非常にアクティブであ
る可能性があります。バッファ・キャッシュ・ヒット率が低いかどうかを確認して、これが考
えられる原因であるかどうかを調べます。また、V$DB_CACHE_ADVICE ビューを使用して、そ
れより大きいキャッシュ・サイズが有利かどうかを判断します。7-6 ページの「バッファ・
キャッシュのサイズ設定」を参照してください。
キャッシュが 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 つのデータベース・
ライター）や、複数のプロセッサ・グループを持つシステム（最低でプロセス・グループと同
数のデータベース・ライター）にお薦めします。
10-26
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
CPU の数またはプロセッサ・グループの数に基づいて、Oracle は、適切な
DB_WRITER_PROCESSES のデフォルト設定を選択するか、ユーザー定義の設定を調整します。
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-27
待機イベント統計
ラッチ・イベント
ラッチは、メモリー構造を保護するために 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;
前述の問合せには、インスタンスまたは長期的なインスタンスのチューニングよりも、セッ
ションのチューニングまたは短期的なインスタンスのチューニングに関して多くの情報が示さ
れるという問題があります。
次の問合せは長期的なインスタンス・チューニングの詳細情報を提供し、ラッチの待機がデー
タベース全体の時間に占める割合が大きいかどうかを示します。
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-28
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
表 10-2 ラッチ解放イベント
ラッチ
SGA 領域
共有プール、
ライブラリ・
キャッシュ
共有プール
考えられる原因
検索対象
文の再利用不足
次の項目が高いセッション（V$SESSTAT 内）
バインド変数を使用しない文
■
CPU 解析時間
■
所要解析時間
アプリケーション・カーソル・キャッシュの
サイズが不十分
各実行後に明示的にクローズされたカーソル
■
解析カウント（ハード）/ 実行カウントの
比率
頻繁なログオン / ログオフ
■
解析カウント（合計）/ 実行カウントの比
率
基礎的なオブジェクト構造の変更（たとえば、
切捨て）
次のカーソル（V$SQLAREA/V$SQLSTATS 内）
小さすぎる共有プール
■
PARSE_CALLS / EXECUTIONS の高い比率
■
キャッシュ・
バッファ LRU
連鎖
バッファ・
キャッシュ
LRU リスト
EXECUTIONS = 1 WHERE 句のリテラルの
み異なる（すなわち、バインド変数を使用
しない）
■
高い RELOADS
■
高い INVALIDATIONS
■
大きい（> 1MB）SHARABLE_MEM
過剰なバッファ・キャッシュ・スループット。 論理 I/O または物理 I/O が非常に多く、選択
たとえば、正しくない索引に繰り返しアクセ
性のない索引が使用される文
スする非効率的な SQL（大きい索引レンジ・
スキャン）
、または多くの全表スキャンがあり
ます。
実行中のワークロードに耐えられない DBWR。
これにより、フォアグラウンド・プロセスが
空きバッファを検索するためにラッチを保持
する時間が長くなります。
小さすぎるキャッシュ
キャッシュ・
バッファ連鎖
バッファ・
キャッシュ
ホット・ブロックと呼ばれる 1 つ（または少
数）のブロックへのアクセスの繰返し
順序番号ジェネレータを使用せずに番号を生成
するための、表の行を更新する順序番号生成
コード
非常に多くのプロセスが、きわめて類似した述
語を使用して選択性のない同一の索引をスキャ
ンすることから発生する、索引リーフ・ブロッ
クの競合
ホット・ブロックが属するセグメントの識別
行キャッシュ・
オブジェクト
共有プールとライブラリ・キャッシュ・ラッチの競合
共有プールまたはライブラリ・キャッシュ・ラッチの競合の主な原因は解析です。不要な解析
および不要な解析の様々なタイプの識別に使用できる手法は多数あります。
非共有 SQL この方法では、リテラルがバインド変数と置換された場合に共有できる類似した
SQL 文を識別します。その概念は次のいずれかです。
■
実行を 1 つのみ持つ SQL 文を手動で検査して、SQL 文が類似しているかどうかを確認しま
す。
SELECT
FROM
WHERE
ORDER
SQL_TEXT
V$SQLSTATS
EXECUTIONS < 4
BY SQL_TEXT;
パフォーマンス・ビューを使用したインスタンスのチューニング
10-29
待機イベント統計
■
類似した文である可能性がある文をグループ化することによって、このプロセスを自動化
します。これを行うには、同じものである可能性の高い SQL 文のバイト数を予測し、その
バイト数によって SQL 文をグループ化します。たとえば、次の例では、最初の 60 バイト
までが同一で、その後が異なる文をグループ化します。
SELECT SUBSTR(SQL_TEXT, 1, 60), COUNT(*)
FROM V$SQLSTATS
WHERE EXECUTIONS < 4
GROUP BY SUBSTR(SQL_TEXT, 1, 60)
HAVING COUNT(*) > 1;
■
同じ実行計画を持つ個別の SQL 文をレポートします。次の問合せでは、同じ実行計画を 4
回以上共有する個別の SQL 文が選択されます。この種の SQL 文では、バインド変数では
なくリテラルが使用されている可能性があります。
SELECT SQL_TEXT FROM V$SQLSTATS WHERE PLAN_HASH_VALUE IN
(SELECT PLAN_HASH_VALUE
FROM V$SQLSTATS
GROUP BY PLAN_HASH_VALUE HAVING COUNT(*) > 4)
ORDER BY PLAN_HASH_VALUE;
再解析された共有可能な SQL V$SQLSTATS ビューをチェックします。次の問合せを入力してく
ださい。
SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS
FROM V$SQLSTATS
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 で、再解析の原因となっているプログラム
の名前を検索します。
注意 : この問合せではインスタンス起動後のすべての解析コールがカウ
ントされるため、解析率の高いセッションを検索することをお薦めしま
す。たとえば、50 日間の接続が高い解析値を示すとしても、2 番目の 10
分間の接続の方がより速い速度で解析される場合があります。
出力は、次のようなものです。
SID
-----7
8
6
11
10-30
Hard Parses
----------1
3
26
84
Execute Count
------------20
12690
325
1619
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
キャッシュ・バッファ 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）を指定すると、ファイル番号
とブロック番号の問合せが作成されます。
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 レコードの書込み
が含まれます。
パフォーマンス・ビューを使用したインスタンスのチューニング
10-31
待機イベント統計
library cache pin
このイベントでは、ライブラリ・キャッシュの同時実行性を管理します。オブジェクトが確保
されると、ヒープがメモリーへロードされます。クライアントがオブジェクトを修正または調
査する場合、クライアントはロック後に PIN を取得する必要があります。
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 ログ・バッファのサイズを大きくし
ます。
log file switch
一般に発生する待機イベントは、次の 2 つです。
■
Log file switch (archiving needed)
■
Log file switch (checkpoint incomplete)
いずれのイベントでも、LGWR は次のオンライン REDO ログに切り替えることはできず、すべ
てのコミット要求はこのイベントを待機します。
処置
log file switch（archiving needed）イベントの場合、アーカイバがタイムリにログを
アーカイブできない理由を調べます。次の理由が考えられます。
■
アーカイブ先に空き領域が不足している。
■
アーカイバが REDO ログを十分高速に読み込めない（LGWR との競合）
。
■
■
10-32
アーカイバが十分高速に書込みを行えない（アーカイブ先での競合、または ARCH プロセ
スの数が不足している）
。その他の可能性（ディスクが低速であったり、アーカイブ先が
いっぱいなど）が除外された場合は、ARCn プロセス数の増加を検討してください。デ
フォルトは 2 です。
必須でリモートに転送されるアーカイブ・ログがある場合は、ネットワーク遅延によって
このプロセスが遅くなっていないか、またはエラーによって書込みが完了していないかを
チェックしてください。
Oracle Database パフォーマンス・チューニング・ガイド
待機イベント統計
ボトルネックの性質により、I/O を再分散したり、アーカイブ先に領域を追加して問題を軽減
することが必要な場合があります。log file switch（checkpoint incomplete）イベント
の場合、次を実行してください。
■
■
過負荷または低速の I/O システムであるために DBWR が低速であるかどうかをチェックし
てください。DBWR 書込み時間および I/O システムをチェックし、必要に応じて I/O を
分散します。第 8 章「I/O 構成および設計」を参照してください。
REDO ログが少なすぎないか、または小さすぎないかをチェックしてください。REDO ロ
グが少なすぎるか小さすぎる、あるいはその両方にあてはまる（たとえば、2 × 100000 個
のログ）ために、DBWR がチェックポイントを完了する前に、すべてのログをサイクルす
る十分な REDO が生成される場合は、REDO ログのサイズまたは個数、あるいはその両方
を増やします。4-4 ページの「REDO ログ・ファイルのサイズ指定」を参照してください。
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-33
アイドル待機イベント
アイドル待機イベント
これらのイベントは 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-34
Oracle Database パフォーマンス・チューニング・ガイド
第 IV 部
SQL 文の最適化
第 IV 部では、最適なパフォーマンスを得るための SQL 文の理解と管理に関する情報を示し、
Oracle の SQL 関連パフォーマンス・ツールについて説明します。
第 IV 部には次の章が含まれます。
■
第 11 章「SQL チューニングの概要」
■
第 12 章「自動 SQL チューニング」
■
第 13 章「問合せオプティマイザ」
■
第 14 章「オプティマイザ統計の管理」
■
第 15 章「索引およびクラスタの使用方法」
■
第 16 章「オプティマイザ・ヒントの使用方法」
■
第 17 章「SQL アクセス・アドバイザ」
■
第 18 章「プラン・スタビリティの使用方法」
■
第 19 章「EXPLAIN PLAN の使用方法」
■
第 20 章「アプリケーション・トレース・ツールの使用方法」
11
SQL チューニングの概要
この章では、チューニングの目的、多くのリソースを消費する SQL 文の識別方法および収集す
る内容の説明と、チューニングの提案を示します。
この章には次の項があります。
■
SQL チューニングの概要
■
チューニングの目的
■
高負荷 SQL の識別
■
自動 SQL チューニング機能
■
効率的な SQL 文の開発
関連項目 :
■
■
SQL の概要は、
『Oracle Database 概要』を参照してください。
データベースの監視とチューニングについては、
『Oracle Database 2
日でデータベース管理者』を参照してください。
SQL チューニングの概要
11-1
SQL チューニングの概要
SQL チューニングの概要
SQL 文のチューニングは、データベース・システムのパフォーマンス・チューニングの重要な
側面です。SQL チューニングには、次の 3 つの基本手順を実行します。
■
■
■
システムで使用可能な過去の SQL 実行履歴を検討し、アプリケーションのワークロードお
よびシステム・リソースの大部分に関係している高負荷または上位 SQL 文を識別します。
これらの文について問合せオプティマイザにより生成される実行計画が適切に実行される
かどうかを確認します。
修正アクションを実装し、パフォーマンスの低い SQL 文について適切な実行計画を生成し
ます。
システム・パフォーマンスが十分なレベルに達するか、他にチューニングできる文がなくなる
まで、この 3 つの手順を繰り返します。
チューニングの目的
システムをチューニングする目的は、システムのエンド・ユーザーへの応答時間を短縮したり、
同じ作業の処理に使用されるリソースを削減することです。これには、次の方法があります。
■
ワークロードの削減
■
ワークロードの均衡化
■
ワークロードのパラレル化
ワークロードの削減
一般に、SQL チューニングには、同じワークロードをより効率的に処理する方法を見つけ出す
ことが含まれます。機能性を変えることなく文の実行計画を変更し、リソース使用量を削減す
ることは可能です。
リソース使用量を削減する方法の 2 つの例を、次に示します。
1.
一般に実行される問合せで、アクセスするデータの表中での割合が少ない場合、効率的な
問合せの実行方法として、索引の使用があります。索引を作成すれば、使用するリソース
の量を削減できます。
2.
ユーザーが、特定のソート順序で戻される 10,000 行の最初の 20 行を見る場合でかつ、索
引で問合せ（およびソート順序）を満たすことができる場合、最初の 20 行を見るために、
10,000 行にアクセスしてソートする必要はありません。
ワークロードの均衡化
システムは、実ユーザーがシステムに接続している昼間に使用量が最大に達し、夜間には低下
する傾向があります。重要でないレポートやバッチ・ジョブを夜間に実行するようにスケ
ジューリングし、昼間の同時実行性が削減されれば、昼間の、より重要なプログラムのために
リソースが解放されます。
ワークロードのパラレル化
大量のデータにアクセスする問合せ（代表的なものは、データ・ウェアハウス問合せ）は、多
くの場合、パラレル化できます。これは特に、同時実行性が低いデータ・ウェアハウスで応答
時間を短縮する場合に有効です。ただし、同時実行性が高い傾向のある OLTP 環境の場合は、
プログラム全体のリソース使用量を増加させることになり、他のユーザーに影響を与える可能
性があります。
11-2
Oracle Database パフォーマンス・チューニング・ガイド
高負荷 SQL の識別
高負荷 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 アプリケーションの監視とチューニングの機能の詳細は、
『Oracle Enterprise Manager 概要』を参照してください。
自動 SQL チューニング機能については、第 12 章「自動 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$SQLSTATS、
V$SQLTEXT、V$SQL_PLAN および V$SQL_PLAN_STATISTICS）です。
関連項目 : Oracle ツールを使用して Oracle インスタンス・パフォーマン
ス・データを収集する方法の詳細は、第 6 章「自動パフォーマンス診断」
を参照してください。
SQL チューニングの概要
11-3
高負荷 SQL の識別
3.
ステップ 2 で収集したデータを使用して、多くのリソースを使用する SQL 文を識別しま
す。候補の SQL 文を識別するには、V$SQLSTATS を問い合せる方法が適しています。
V$SQLSTATS には、共有プール内のすべての SQL 文に関するリソース使用率の情報が含ま
れています。V$SQLSTATS 内のデータを、リソース使用率で順序付けしてください。共通
リソースの主なものは、次のとおりです。
■
バッファ取得（V$SQLSTATS.BUFFER_GETS。CPU 使用率の高い文の問合せ。
）
■
ディスク読取り（V$SQLSTATS.DISK_READS。I/O 使用率の高い文の問合せ。
）
■
ソート（V$SQLSTATS.SORTS。ソートの多い文の問合せ。
）
負荷の最も大きい SQL 文を識別する方法の 1 つは、その期間内に SQL 文で使用されたリソース
を、同じ期間内に使用されたそのリソースの総量と比較することです。BUFFER_GETS の場合、
各 SQL 文の BUFFER_GETS の回数を、期間中のバッファ取得の総数で除算します。システム内
のバッファ取得の総数は V$SYSSTAT 表の session logical reads の統計情報からわかります。
同様に、V$SQL_STATS.DISK_READS を V$SYSSTAT 統計の物理読込みの値で除算すると、シ
ステムによって実行されるディスク読取りの総数のうち、文によって実行されるディスク読取
りの割合を計算できます。自動ワークロード・リポジトリ・レポートの 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 文すべてについて、実行計画を
生成し、見直すことが重要です。これにより、SQL 文が効率よく実行され
たときのオプティマイザの実行計画と、そうでないときの計画とを比較で
きます。データ量の変化などの情報とあわせて比較を行うと、パフォーマ
ンスの低下の原因を正確に識別できます。
11-4
Oracle Database パフォーマンス・チューニング・ガイド
自動 SQL チューニング機能
自動 SQL チューニング機能
手動 SQL チューニング・プロセスはアプリケーション開発者に多数の作業が課されるため、
SQL チューニング・プロセスは自動 SQL チューニング管理機能により自動化されています。こ
れらの機能は、OLTP タイプとデータ・ウェアハウス・タイプのアプリケーションで同様に機
能するように設計されています。第 12 章「自動 SQL チューニング」を参照してください。
ADDM
Automatic Database Diagnostic Monitor（ADDM）では、高負荷 SQL 文など、Oracle データ
ベースにおいて考えられるパフォーマンス上の問題について、AWR によって収集された情報が
分析されます。6-3 ページの「Automatic Database Diagnostic Monitor」を参照してください。
SQL チューニング・アドバイザ
SQL チューニング・アドバイザでは、SQL 文を変更せずに SQL 文を素早く効率的に最適化で
きます。12-5 ページの「SQL チューニング・アドバイザ」を参照してください。
SQL チューニング・セット
複数の SQL 文が ADDM または SQL チューニング・アドバイザへの入力として使用される場
合、SQL チューニング・セット（STS）が構成され、格納されます。STS には、SQL 文のセッ
トと、関連する実行コンテキストおよび基本実行統計が含まれます。12-9 ページの「SQL
チューニング・セット」を参照してください。
SQL アクセス・アドバイザ
Oracle では、SQL チューニング・アドバイザの他に、SQL アクセス・アドバイザが用意されて
います。これは、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログに
ついてアドバイスを提供します。SQL アクセス・アドバイザでは、指定のワークロードに関す
るマテリアライズド・ビュー、マテリアライズド・ビュー・ログおよび索引の適切なセットが
推奨されるため、パフォーマンスの目標を達成するのに役立ちます。一般に、マテリアライズ
ド・ビューおよび索引の数と、これらに割り当てられている領域が増えるにつれて、問合せの
パフォーマンスが向上します。SQL アクセス・アドバイザでは、領域使用量と問合せパフォー
マンスの兼合いが考慮され、新規および既存のマテリアライズド・ビューおよび索引の最もコ
スト効率の高い構成が推奨されます。
Oracle Enterprise Manager Database Control から SQL アクセス・アドバイザにアクセスする手
順は、次のとおりです。
■
■
「データベース」ページの最下部で、
「関連リンク」の下の「セントラル・アドバイザ」
「セントラル・アドバイザ」リ
「データベース」
「関連リンク」
「セントラル・アドバイザ」
ンクをクリックします。
「セントラル・アドバイザ」ページで「
「SQL アクセス・アドバイザ」リンクをクリックし、
「セントラル・アドバイザ」
アクセス・アドバイザ」
ワークロードのソースを分析できます。
17-6 ページの「SQL アクセス・アドバイザの使用方法」を参照してください。
SQL チューニングの概要
11-5
効率的な SQL 文の開発
効率的な SQL 文の開発
この項では、SQL 文の効率を高める方法を説明します。
■
オプティマイザ統計の確認オプティマイザ統計の確認
■
実行計画の検討
■
SQL 文の再構成
■
索引の再構成
■
トリガーおよび制約の変更または無効化
■
データの再構成
■
実行計画の長期的な保持
■
データへのアクセスを最小限に削減
注意 : この項で説明するガイドラインは、頻繁に実行される本番 SQL に
関するものです。この項でお薦めしていない技法の大半は、パフォーマン
スが重要でない非定型文または頻繁に実行されないアプリケーションでは
使用してもかまいません。
オプティマイザ統計の確認
問合せオプティマイザでは、最適な実行計画の判別時に、表と索引について収集された統計を
使用します。これらの統計が収集されなかった場合、または、統計がデータベース内に格納さ
れているデータをすでに反映しなくなっている場合、オプティマイザには最適な計画を生成す
るための十分な情報がありません。
チェックする内容
■
■
データベース内のいくつかの表に関する統計が必要な場合は、すべての表に関する統計を
収集するのが望ましい方法です。このことは、結合を実行する SQL 文がアプリケーション
に含まれている場合に特に言えます。
データ・ディクショナリ内のオプティマイザ統計が表と索引内のデータを反映しなくなっ
ている場合は、新しい統計を収集します。ディクショナリ統計が失効しているかどうかを
チェックする方法の 1 つは、表の実際のカーディナリティ（行数）と、DBA_
TABLES.NUM_ROWS の値を比較することです。また、述語列に大きなデータの偏りがある
場合は、ヒストグラムを使用することを検討してください。
実行計画の検討
OLTP 環境で SQL 文をチューニング（または作成）する場合、最も選択性の高いフィルタを持
つ表から駆動することを目標とします。つまり、次のステップに渡される行を少なくするとい
うことです。次のステップが結合である場合は、少数の行しか結合されないということになり
ます。アクセス・パスが最適かどうかを確認してください。
オプティマイザの実行計画を調べる場合は、次の内容を確認します。
■
■
■
■
■
11-6
駆動表が最適なフィルタを持つ計画であること。
各ステップの結合順序は、最少数の行が次のステップに戻されるようにします（つまり、
可能であれば、結合の順序は最適な未使用フィルタを選んで進むようにする必要がありま
す）
。
結合方法が、それによって戻される行数からみた場合に、適切なものであること。たとえ
ば、索引でのネステッド・ループ結合は、多数の行が戻される場合には最適ではありませ
ん。
ビューが効果的に使用されていること。SELECT 構文のリストを見て、ビューへのアクセ
スが必要であるかどうかを確認してください。
意図しないデカルト積（小さい表の場合も含む）があるかどうか。
Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
■
各表が効率的にアクセスされていること。
SQL 文の述語と、表の行数を評価します。大量の行を持つ表の全表スキャンなど、
WHERE 句に述語を持つ疑わしいアクティビティを探します。そのような選択的な述語に
索引が使用されない理由を判別します。
全表スキャンが非効率的というわけではありません。小さい表で全表スキャンを行う場合
や、戻される行数に対してよりよい結合方法（たとえば、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() など
ここに示した式によって、オプティマイザは有効なカーディナリティまたは選択性の見積りを
割り当てることができなくなります。この結果、全体の計画および結合方法に悪い影響を与え
ます。
NVL() のかわりに述語を追加します。
SQL チューニングの概要
11-7
効率的な SQL 文の開発
たとえば、次のような影響があります。
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)
関連項目 : ファンクション索引の詳細は、第 15 章「索引およびクラスタ
の使用方法」を参照してください。
特定のタスクに対する専用の SQL 文の作成
SQL は、手続き型言語ではありません。1 つの SQL を使用して様々なことを実行すると、通常
は各タスクに最適でない結果が生じます。SQL を使用して様々なタスクを実行する場合は、1
つの文にパラメータを指定して異なるタスクを実行するのではなく、様々な文を作成してくだ
さい。
注意 : 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 の両辺で同じ列を使用するためです。
このことは、選択性の高い、索引作成可能な他の条件が別にあって、それを使用して駆動表に
アクセスできる場合には問題になりません。ただし、これにあてはまらない場合もよくありま
11-8
Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
す。この例のような条件で索引を使用することは多くありますが、: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
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 Database データ・ウェアハウス・ガイド』
副問合せに IN 句を使用した場合に、副問合せで指定される選択性の利点を活用するために、
Oracle が副問合せをリライトすることがあります。これは、最も選択性の高いフィルタが副問
合せにある場合、結合列に索引がある場合に、最も有効です。これに対し、EXISTS は、最も
選択性の高いフィルタが親問合せにある場合に有効です。その場合、EXISTS 基準に照らして
行をフィルタにかける前に、親問合せの選択的述語を適用できるからです。
注意 : 使用したリソース（BUFFER_GETS、DISK_READS、V$SQLSTATS
または V$SQLAREA からの CPU_TIME）の実際の数で、文のオプティマイ
ザ・コストを検証する必要があります。データの偏り（ヒストグラムを使
用しない）などの状況は、オプティマイザの操作コストの見積りにマイナ
スの影響を与える可能性があります。
SQL チューニングの概要
11-9
効率的な 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 が
含まれている行です。
次の計画出力は、前述の文の実行計画（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
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 */
11-10
Oracle Database パフォーマンス・チューニング・ガイド
155
3
1
効率的な SQL 文の開発
注意 :
■
■
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
例 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 チューニングの概要
11-11
効率的な 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 つの索引にアクセスする必
要がなくなり、使用されるリソースが削減されます。
ヒントによるアクセス・パスおよび結合順序の制御
オプティマイザのアプローチと目標の設定および問合せオプティマイザの代表的な統計の収集
によって、オプティマイザの選択を変えることができます。特定のアプリケーション・データ
に関して、オプティマイザよりも多くの情報を持つアプリケーション設計者であれば、より効
率よく SQL 文を実行する方法を選択できる場合があります。SQL 文のヒントを使用すれば、文
を実行する方法をオプティマイザに指示できます。
/*+FULL */ などのヒントは、アクセス・パスを制御します。たとえば、次のようにします。
SELECT /*+ FULL(e) */ e.last_name
FROM employees e
WHERE e.job_id = 'CLERK';
関連項目 : 第 13 章「問合せオプティマイザ」および第 16 章「オプティ
マイザ・ヒントの使用方法」
11-12
Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
結合順序は、パフォーマンスに大きな影響を与えることがあります。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;
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 ヒントを使用して、結合順序を強制的に設定できます。
関連項目 :
16-4 ページ「結合順序のヒント」
ビューを管理するときの注意
ビューの結合、ビューへの外部結合、および既存ビューの新規目的への再利用に対しては、注
意が必要です。
複合ビューを結合するときの注意 複合ビューへの結合、特に、ある複合ビューから別の複合
ビューへの結合はお薦めできません。そのような結合を行うと、多くの場合、ビュー全体がイ
ンスタンス化され、ビュー・データに対して問合せが行われる結果になります。
たとえば、次の文は従業員および部門をリストするビューを作成します。
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;
SQL チューニングの概要
11-13
効率的な 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 ビューを問い合せてこの情報を取得する
ことは非効率的です。
副問合せのネストを解除するときの注意 副問合せのネストの解除によって、副問合せ本体が解
除され、その副問合せが含まれている文の本体にマージされます。これにより、オプティマイ
ザは、アクセス・パスと結合を評価するときに、副問合せと本体の両方をいっしょに考慮させ
てしまいます。
関連項目 : 副問合せのネスト解除における危険性については、『Oracle
Database データ・ウェアハウス・ガイド』を参照してください。
ビューへの外部結合を実行するときの注意 複数表のビューに対する外部結合の場合、等価述語
が定義されていれば、問合せオプティマイザ（リリース 8.1.6 以上）は外部結合列から駆動でき
ます。
ビュー内での外部結合は、外部結合のパフォーマンスに与える影響が読めないため、問題が発
生しやすくなります。
11-14
Oracle Database パフォーマンス・チューニング・ガイド
効率的な SQL 文の開発
中間結果の格納
中間の表、すなわちステージング表がリレーショナル・データベース・システムで比較的よく
利用されるのは、それらの表に中間結果を一時的に格納するためです。これは、多くのアプリ
ケーションで役に立つものですが、作成するにはさらにリソースが必要になります。したがっ
て、これらの表による利益が、作成のコストに見合うものかどうかを常に考慮してください。
ステージング表は、その情報が何回も再利用されない場合は、作成しないようにしてください。
他の考慮事項
■
■
■
ステージング表に中間結果を格納することで、アプリケーション・パフォーマンスを向上
できる場合があります。一般に、中間結果が、引き続きその後の複数の問合せで使用可能
であれば、その結果をステージング表に格納する価値があります。中間結果の再利用によ
り、複雑な文を使用して何度もデータを取り出すことをしないで済む利益は、中間結果を
マテリアライズするコストを上回ります。
長く複雑な問合せは、理解し、最適化することが困難です。ステージング表を使用するこ
とで、複雑な SQL 文をいくつかの小さい文に分解でき、このとき、各ステップの結果を格
納します。
マテリアライズド・ビューを使用することを検討してください。マテリアライズド・
ビューは、ファクト表やディメンション表からの集計データや結合データを格納する、あ
らかじめ計算済の表です。
関連項目 : マテリアライズド・ビューの使用方法に関する詳細は、
『Oracle Database データ・ウェアハウス・ガイド』を参照してください。
索引の再構成
多くの場合は、索引を再構成すると、パフォーマンスが向上します。これには、次の内容が含
まれます。
■
非選択的な索引を削除して、DML の速度を上げます。
■
パフォーマンス重視のアクセス・パスの索引を作成します。
■
既存の連結索引で列を並び換えることを考慮します。
■
索引に列を追加して、選択性を向上します。
索引を万能策として使用しないでください。アプリケーションの開発者は、索引を多く作成す
ればパフォーマンスが改善されると考えることがあります。1 人のプログラマが適切に索引を
作成すれば、アプリケーションのパフォーマンスは十分に改善される可能性があります。ただ
し、50 名のプログラマが別々に索引を作成すると、アプリケーションのパフォーマンス改善は
望めません。
トリガーおよび制約の変更または無効化
トリガーを使用すると、システムのリソースが消費されます。使用するトリガーが多すぎると、
パフォーマンスに悪影響が及ぶので、トリガーを変更または使用禁止にする必要がある場合が
あります。
データの再構成
索引と文を再構成した後で、データの再構成について検討できます。
■
■
■
導出された値を用意しておきます。応答時間重視のコードでは、GROUP BY の使用を回避し
ます。
データ設計を検討します。変更によりパフォーマンスの向上が見込める場合は、システム
の設計を変更します。
必要に応じて、パーティション化を考慮します。
SQL チューニングの概要
11-15
効率的な SQL 文の開発
実行計画の長期的な保持
格納されている統計または SQL 実行計画を使用すると、SQL 文の既存の実行計画を長期的に保
持できます。表のオプティマイザの統計を格納すると、その表を参照するすべての SQL 文にそ
の統計が適用されます。実行計画を格納すると（すなわち、プラン・スタビリティ）
、単一の
SQL 文の計画が保持されます。統計およびストアド・プランの両方が SQL 文に対して使用可能
な場合は、オプティマイザはストアド・プランの方を使用します。
関連項目 :
■
第 14 章「オプティマイザ統計の管理」
■
第 18 章「プラン・スタビリティの使用方法」
データへのアクセスを最小限に削減
アプリケーションから各行へのアクセスを、可能なかぎり 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
これは、きわめて単純な例です。範囲が重なっていたり、集計の関数が異なっていることもあ
ります。
11-16
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 チューニングの概要
11-17
効率的な SQL 文の開発
11-18
Oracle Database パフォーマンス・チューニング・ガイド
12
自動 SQL チューニング
この章では、Oracle の自動 SQL チューニング機能について説明します。
この章には次の項があります。
■
自動 SQL チューニングの概要
■
SQL チューニング・アドバイザ
■
SQL チューニング・セット
■
SQL プロファイル
■
SQL チューニング情報ビュー
関連項目 : SQL 文の監視およびチューニングの詳細は、『Oracle
Database 2 日でデータベース管理者』を参照してください。
自動 SQL チューニング 12-1
自動 SQL チューニングの概要
自動 SQL チューニングの概要
自動 SQL チューニングは問合せオプティマイザの新機能であり、SQL チューニング・プロセス
全体を自動化します。新しく拡張された問合せオプティマイザを使用して SQL 文をチューニン
グすると、複雑で反復的、また時間のかかる作業である手動 SQL チューニングが自動プロセス
に置き換えられます。自動 SQL チューニング機能は、SQL チューニング・アドバイザでユー
ザーに公開されます。
この項では、次の項目について説明します。
■
問合せオプティマイザのモード
■
チューニング分析のタイプ
問合せオプティマイザのモード
拡張された問合せオプティマイザには 2 つのモードがあります。
■
標準モード
■
チューニング・モード
標準モード
標準モードのオプティマイザでは、SQL がコンパイルされて実行計画が生成されます。この
モードで生成される実行計画は、大多数の SQL 文に対して妥当なものです。標準モードでは、
オプティマイザは通常はミリ秒単位の厳密な時間的制約に従って動作し、その期間内に適切な
実行計画を検出する必要があります。
チューニング・モード
チューニング・モードのオプティマイザでは、追加の分析が実行され、標準モードで生成され
た実行計画をさらに改善できるかどうかがチェックされます。問合せオプティマイザの出力に
は、実行計画ではなく、きわめて優れた計画を生成するための一連のアクション、その理論的
根拠および予測されるメリットが示されます。チューニング・モードでコールされるオプティ
マイザを、自動チューニング・オプティマイザと呼びます。自動チューニング・オプティマイ
ザにより実行されるチューニングを、自動 SQL チューニングと呼びます。
チューニング・モードのオプティマイザでは、1 つの文のチューニングに数分かかることがあ
ります。問合せをハード解析するたびに、自動チューニング・オプティマイザを起動するため
の時間およびリソースの両方が集中的に使用されます。自動チューニング・オプティマイザは、
システム全体に通常とは異なる影響を与える複雑で高負荷な SQL 文に使用されることを意図し
た機能です。自動 SQL チューニングの適切な候補となる高負荷の SQL 文は、Automatic
Database Diagnostic Monitor（ADDM）によりプロアクティブに識別されます。第 6 章「自動
パフォーマンス診断」を参照してください。
12-2
Oracle Database パフォーマンス・チューニング・ガイド
自動 SQL チューニングの概要
チューニング分析のタイプ
自動 SQL チューニングには、次の 4 タイプのチューニング分析が含まれます。
■
統計分析
■
SQL プロファイリング
■
アクセス・パス分析
■
SQL 構造分析
統計分析
問合せオプティマイザは、オブジェクト統計に依存して実行計画を生成します。これらの統計
が失効または欠落している場合、オプティマイザに必要な情報がなく、不適切な実行計画が生
成される可能性があります。自動チューニング・オプティマイザは、問合せオブジェクトごと
に統計の欠落や失効がないかどうかをチェックし、次の 2 つのタイプの出力を生成します。
■
統計が失効または欠落しているオブジェクトに関して関連統計を収集するための推奨事項
オプティマイザ統計は自動的に収集されリフレッシュされるため、この問題が発生するの
は自動オプティマイザ統計収集がオフになっていた場合のみです。14-3 ページの「自動統
計収集」を参照してください。
■
統計が欠落しているオブジェクトに関する統計形式の補足情報と、統計が失効しているオ
ブジェクトに関する統計調整ファクタ
この補足情報は、SQL プロファイルと呼ばれるオブジェクトに格納されます。
SQL プロファイリング
問合せオプティマイザでは、情報の欠落が原因で文の属性に関して不正確な見積りが生成され、
そのために不適切な実行計画が生成される場合があります。従来は、オプティマイザが適切に
決定できるようにアプリケーション・コードに手動でヒントを追加することで、この問題を解
決してきました。パッケージ化されたアプリケーションの場合は、アプリケーション・コード
を変更できず、不具合のログをアプリケーション・ベンダーに提供して修正されるまで待つ必
要があります。
自動 SQL チューニングは、この問題に SQL プロファイリング機能で対処します。自動チュー
ニング・オプティマイザでは、SQL プロファイルと呼ばれる SQL 文のプロファイルが作成され
ます。このプロファイルは、その文に固有の補助統計で構成されます。標準モードの問合せオ
プティマイザではカーディナリティ、選択性およびコストを見積りますが、これらの値が大幅
にずれているために不適切な実行計画が生成されることがあります。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 に設定すると、そのプロファイル
自動 SQL チューニング 12-3
自動 SQL チューニングの概要
を使用できるのは SQLTUNE_CATEGORY 初期化パラメータが DEV に設定されているユーザー・
セッションのみとなります。他のすべてのセッションには SQL プロファイルへのアクセス権が
なく、SQL 文の実行計画は SQL プロファイルの影響を受けません。このテクニックを使用する
と、SQL プロファイルを他のユーザー・セッションで使用可能にする前に、限定的な環境でテ
ストできます。
関連項目 : SQLTUNE_CATEGORY 初期化パラメータの詳細は、『Oracle
Database リファレンス』を参照してください。
ストアド・アウトラインとは異なり、SQL プロファイルでは SQL 文の実行計画が凍結されない
ことに注意する必要があります。表が拡張されたり索引が作成または削除されるたびに、同じ
SQL プロファイルを使用して実行計画を変更できます。対応する文のデータ配分やアクセス・
パスに変更があっても、SQL プロファイルに格納された情報は引き続き関連付けられていま
す。ただし、長期的には、その内容が陳腐化することがあり、再生成が必要になります。その
ためには、同じ文に対して自動 SQL チューニングを再実行し、SQL プロファイルを再生成しま
す。
SQL プロファイルは、次のタイプの文に適用されます。
■
SELECT 文
■
UPDATE 文
■
INSERT 文（SELECT 句の場合のみ）
■
DELETE 文
■
CREATE TABLE 文（AS SELECT 句の場合のみ）
■
MERGE 文（更新または挿入操作）
SQL プロファイルの管理用に、完全なファンクション・セットが用意されています。12-13
ページの「SQL プロファイル」を参照してください。
アクセス・パス分析
索引を使用すると、大規模な表の全表スキャンを実行する必要性が減少し、SQL 文のパフォー
マンスを大幅に改善できます。効率的な索引付けは、一般的なチューニング・テクニックです。
自動チューニング・オプティマイザも、新規索引で問合せのパフォーマンスを大幅に改善でき
るかどうかを探索します。この種の索引が識別されると、その作成が推奨されます。
自動チューニング・オプティマイザでは、索引に関する推奨事項が SQL 全体のワークロードに
どのように影響するかは分析されないため、典型的な SQL ワークロードを持つ SQL 文に対し
て SQL アクセス・アドバイザ・ユーティリティを実行することも推奨されます。SQL アクセ
ス・アドバイザは、索引作成が SQL 全体のワークロードに与える影響を調べてから、推奨事項
を作成します。11-5 ページの「自動 SQL チューニング機能」を参照してください。
SQL 構造分析
自動チューニング・オプティマイザでは、パフォーマンスを低下させる可能性のある SQL 文の
構造に関して一般的な問題が識別されます。たとえば、文の構文、セマンティクスまたは設計
上の問題があります。このような問題ごとに、自動チューニング・オプティマイザは SQL 文の
再構成について関連する提案を行います。提案される代替策は、元の文と類似していますが同
じではありません。
たとえば、オプティマイザから、UNION 演算子を UNION ALL で置き換えたり、NOT IN を NOT
EXISTS で置き換えるように提案される場合があります。その場合、アプリケーション開発者
はアドバイスが状況に適用可能かどうかを判断できます。たとえば、スキーマ設計上、重複の
発生が不可能な場合は、UNION 演算子よりも UNION ALL 演算子の方が効率的です。このよう
に変更するには、データ・プロパティを十分に理解し、実装前に慎重に考慮する必要がありま
す。
12-4
Oracle Database パフォーマンス・チューニング・ガイド
SQL チューニング・アドバイザ
SQL チューニング・アドバイザ
自動 SQL チューニング機能は、SQL チューニング・アドバイザというサーバー・ユーティリ
ティを介して公開されます。SQL チューニング・アドバイザは、入力として 1 つ以上の SQL 文
を取り、自動チューニング・オプティマイザを起動して文に対する SQL チューニングを実行し
ます。SQL チューニング・アドバイザの出力はアドバイスまたは推奨事項の形式で、各推奨事
項の理論的根拠と予測されるメリットが含まれます。推奨事項は、オブジェクト統計の収集、
新規索引の作成、SQL 文の再構成または SQL プロファイルの作成に関するものです。ユーザー
は、推奨事項を受け入れるかどうかを選択して SQL 文のチューニングを完了できます。
SQL チューニング・アドバイザの入力には、1 つ以上の SQL 文を使用できます。複数の文を
チューニングする場合は、最初に SQL チューニング・セット（STS）を作成する必要がありま
す。STS は、SQL 文とその実行コンテキストを格納するデータベース・オブジェクトです。
STS は、コマンドライン API を使用して手動で作成する方法と、Oracle Enterprise Manager を
使用して自動的に作成する方法があります。12-9 ページの「SQL チューニング・セット」を参
照してください。
この項では、SQL チューニング・アドバイザに関連した次のトピックについて説明します。
■
入力ソース
■
チューニング・オプション
■
アドバイザ出力
■
SQL チューニング・アドバイザ API の使用方法
入力ソース
SQL チューニング・アドバイザの入力は、複数のソースから取り込むことができます。次のよ
うな入力ソースがあります。
■
Automatic Database Diagnostic Monitor
主入力ソースは、Automatic Database Diagnostic Monitor（ADDM）です。デフォルトで、
ADDM は 1 時間ごとにプロアクティブに実行され、過去 1 時間に自動ワークロード・リポ
ジトリ（AWR）により収集された主要統計が分析され、高負荷の SQL 文など、パフォー
マンスの問題が識別されます。高負荷の SQL 文が識別されると、その SQL に対して SQL
チューニング・アドバイザを実行するように推奨されます。6-3 ページの「Automatic
Database Diagnostic Monitor」を参照してください。
■
高負荷の SQL 文
2 番目に重要な入力ソースは、自動ワークロード・リポジトリ（AWR）に収集される高負
荷の SQL 文です。AWR は、CPU 使用率や待機時間など、関連統計でランク付けされた高
負荷の SQL 文を含むシステム・アクティビティについて、通常のスナップショットを作成
します。AWR を表示して問題となっている高負荷 SQL を識別し、それに対して SQL
チューニング・アドバイザを実行できます。デフォルトで、AWR には過去 7 日間のデータ
が保持されます。つまり、この機能を使用して AWR の保存期間内に実行された高負荷
SQL を検索し、チューニングできます。5-8 ページの「自動ワークロード・リポジトリの
概要」を参照してください。
■
カーソル・キャッシュ
3 番目の入力ソースはカーソル・キャッシュです。このソースは、まだ AWR に収集されて
いない最新の SQL 文のチューニングに使用されます。カーソル・キャッシュと AWR に
は、現在の時刻から AWR の許容保存期間（デフォルトは 7 日以上）の範囲内でさかの
ぼって、高負荷の SQL 文を識別してチューニングする機能が用意されています。
■
SQL チューニング・セット
その他の可能な SQL チューニング・アドバイザの入力ソースは、SQL チューニング・セッ
トです。SQL チューニング・セット（STS）は、SQL 文とその実行コンテキストを格納す
るデータベース・オブジェクトです。STS には、パフォーマンスを個別に測定することや、
パフォーマンスが予測より低下している SQL 文を識別することを目的として、まだ配置さ
れていない SQL 文を含めることができます。SQL 文セットを入力として使用する場合は、
自動 SQL チューニング 12-5
SQL チューニング・アドバイザ
最初に SQL チューニング・セット（STS）を構成して格納する必要があります。12-9 ペー
ジの「SQL チューニング・セット」を参照してください。
チューニング・オプション
SQL チューニング・アドバイザには、チューニング・タスクの有効範囲と期間を管理するため
のオプションが用意されています。チューニング・タスクの有効範囲は、制限付きまたは包括
的として設定できます。
■
■
制限付きオプションを選択すると、SQL チューニング・アドバイザでは、統計チェック、
アクセス・パス分析および SQL 構造分析に基づいて推奨事項が生成されます。SQL プロ
ファイルの推奨事項は生成されません。
包括的オプションを選択すると、SQL チューニング・アドバイザでは、制限付きの有効範
囲で実行されるすべての分析と SQL プロファイリングが実行されます。このオプションを
選択した場合は、チューニング・タスクの時間制限も指定できます。デフォルトでは 30 分
です。
アドバイザ出力
SQL 文を分析した後、SQL チューニング・アドバイザにより、実行計画の最適化に関するアド
バイス、提案された最適化の理論的根拠、見積もられるパフォーマンスの向上およびアドバイ
スを実装するコマンドが提供されます。SQL 文を最適化するには、推奨事項を受け入れるかど
うかを選択するだけです。
SQL チューニング・アドバイザ API の使用方法
SQL チューニング・アドバイザ実行用の推奨インタフェースは、Oracle Enterprise Manager で
す。SQL チューニング・アドバイザの実行には、できるかぎり Oracle Enterprise Manager を使
用する必要があります。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガ
イド』を参照してください。Oracle Enterprise Manager を使用できない場合は、
DBMS_SQLTUNE パッケージのプロシージャを使用して SQL チューニング・アドバイザを実行
できます。この API を使用するには、ユーザーは特定の権限を付与されている必要がありま
す。
関連項目 : DBMS_SQLTUNE パッケージのセキュリティ・モデルの詳細情
報については、
『Oracle Database PL/SQL パッケージ・プロシージャおよ
びタイプ・リファレンス』を参照してください。
DBMS_SQLTUNE パッケージを使用した SQL チューニング・アドバイザの実行には、次のよう
に複数のプロセスがあります。
1.
SQL チューニング・セットの作成（複数の SQL 文をチューニングする場合）
2.
SQL チューニング・タスクの作成
3.
SQL チューニング・タスクの実行
4.
SQL チューニング・タスクの結果の表示
5.
必要に応じた推奨事項の実装
SQL チューニング・タスクは単一の SQL 文に対して作成できます。複数の文をチューニングす
る場合は、最初に SQL チューニング・セット（STS）を作成する必要があります。STS は、
SQL 文とその実行コンテキストを格納するデータベース・オブジェクトです。STS は、コマン
ドライン API を使用して手動で作成する方法と、Oracle Enterprise Manager を使用して自動的
に作成する方法があります。12-9 ページの「SQL チューニング・セット」を参照してくださ
い。
図 12-1 は、DBMS_SQLTUNE パッケージを使用して SQL チューニング・アドバイザを実行する
場合に必要な手順を示しています。
12-6
Oracle Database パフォーマンス・チューニング・ガイド
SQL チューニング・アドバイザ
図 12-1 SQL チューニング・アドバイザ API
この項では、次のトピックについて説明します。
■
SQL チューニング・タスクの作成
■
SQL チューニング・タスクの実行
■
SQL チューニング・タスクのステータスのチェック
■
SQL チューニング・アドバイザの進捗のチェック
■
SQL チューニング・タスクの結果の表示
■
SQL チューニング・タスクに関するその他の操作
関連項目 : DBMS_SQLTUNE パッケージの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照
してください。
SQL チューニング・タスクの作成
チューニング・タスクは、1 つの SQL 文、複数の文を含む SQL チューニング・セット、カーソ
ル・キャッシュから SQL 識別子で選択した SQL 文または自動ワークロード・リポジトリから
SQL 識別子で選択した SQL 文のテキストから作成できます。
たとえば、SQL チューニング・アドバイザを使用して指定の 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 '
||
||
||
||
自動 SQL チューニング 12-7
SQL チューニング・アドバイザ
'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;
/
この例で、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';
SQL チューニング・タスクの実行
チューニング・タスクを作成した後、タスクを実行し、チューニング・プロセスを開始する必
要があります。たとえば、次のようにします。
BEGIN
DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'my_sql_tuning_task' );
END;
/
SQL チューニング・タスクのステータスのチェック
USER_ADVISOR_TASKS ビューの情報を検討してタスクの状態をチェックするか、
V$SESSION_LONGOPS ビューでタスク実行の進捗をチェックできます。たとえば、次のように
します。
SELECT status FROM USER_ADVISOR_TASKS WHERE task_name = 'my_sql_tuning_task';
SQL チューニング・アドバイザの進捗のチェック
V$ADVISOR_PROGRESS ビューで SQL チューニング・アドバイザの実行の進捗状況をチェック
できます。たとえば、次のようにします。
SELECT sofar, totalwork FROM V$ADVISOR_PROGRESS WHERE user_name = 'HR' AND task_name =
'my_sql_tuning_task';
関連項目 : V$ADVISOR_PROGRESS ビューの詳細は、
『Oracle Database
リファレンス』を参照してください。
12-8
Oracle Database パフォーマンス・チューニング・ガイド
SQL チューニング・セット
SQL チューニング・タスクの結果の表示
タスクの実行後に、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 ビューに表示されます。12-15 ページの
「SQL チューニング情報ビュー」を参照してください。
SQL チューニング・タスクに関するその他の操作
次の API を使用して、SQL チューニング・タスクを管理できます。
■
INTERRUPT_TUNING_TASK（実行中にタスクに割り込み、中間結果を取得して通常終了）
■
RESUME_TUNING_TASK（前回割り込まれたタスクを再開）
■
CANCEL_TUNING_TASK（実行中にタスクを取り消し、タスクからすべての結果を削除）
■
RESET_TUNING_TASK（実行中にタスクをリセットし、タスクからすべての結果を削除
し、タスクを初期の状態に戻す）
■
DROP_TUNING_TASK（タスクを削除し、タスクに関連付けられたすべての結果を削除）
SQL チューニング・セット
SQL チューニング・セット（STS）は、1 つ以上の SQL 文とその実行統計および実行コンテキ
ストを含むデータベース・オブジェクトであり、ユーザーによる優先順位ランキングを含む場
合もあります。SQL 文は、自動ワークロード・リポジトリ、カーソル・キャッシュまたはユー
ザー提供のカスタム SQL など、様々な SQL ソースから SQL チューニング・セットにロードで
きます。STS に含まれるのは、次のとおりです。
■
■
■
■
SQL 文のセット
関連する実行コンテキスト（ユーザー・スキーマ、アプリケーション・モジュール名およ
びアクション、バインド値のリストおよびカーソル・コンパイル環境など）
関連する基本実行統計（経過時間、CPU タイム、バッファ取得、ディスク読取り、処理さ
れた行数、カーソル・フェッチ、実行数、実行完了数、オプティマイザ・コストおよびコ
マンドのタイプなど）
各 SQL 文の関連実行計画と行ソース統計（オプション）
SQL 文は、アプリケーション・モジュール名とアクション、または任意の実行統計を使用して
フィルタできます。また、実行統計の任意の組合せに基づいて SQL 文をランク付けすることも
できます。
SQL チューニング・セットを SQL チューニング・アドバイザへの入力として使用すると、ユー
ザーが指定した他の入力パラメータに基づいて SQL 文の自動チューニングが実行されます。
SQL チューニング・セットはデータベース間で転送可能であり、あるシステムから別のシステ
ムへエクスポートできます。これにより、リモート・パフォーマンス診断およびチューニング
のための SQL ワークロードをデータベース間で転送できます。本番システム上にパフォーマン
スの悪い SQL 文がある場合、開発者が直接本番システム上で調査およびチューニングを実行し
ないようにすることをお薦めします。この機能を使用すると、DBA は、開発者が安全に分析お
よびチューニングできるテスト・システムに、原因となっている SQL 文を転送できます。SQL
チューニング・セットを転送するには、DBMS_SQLTUNE パッケージ・プロシージャを使用しま
す。
自動 SQL チューニング 12-9
SQL チューニング・セット
SQL チューニング・セット管理用の推奨インタフェースは、Oracle Enterprise Manager です。
SQL チューニング・セットの管理には、できるかぎり Oracle Enterprise Manager を使用する必
要があります。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を
参照してください。Oracle Enterprise Manager を使用できない場合は、DBMS_SQLTUNE パッ
ケージのプロシージャを使用して SQL チューニング・セットを管理できます。一般に、STS 操
作は次の順序で使用します。
■
新規 STS の作成
■
STS のロード
■
STS を選択して内容を確認
■
必要に応じて STS を更新
■
入力に STS を使用してチューニング・タスクを作成
■
必要に応じて他システムへ STS を転送
■
完了時に STS を削除
この API を使用するには、所有する SQL チューニング・セットを管理する ADMINISTER SQL
TUNING SET システム権限が必要です。または、任意の SQL チューニング・セットを管理する
ADMINISTER ANY SQL TUNING SET システム権限が必要です。
図 12-2 は、SQL チューニング・セット API を使用した場合に必要な手順を示しています。
図 12-2 SQL チューニング・セット API
この項では、次のトピックについて説明します。
■
SQL チューニング・セットの作成
■
SQL チューニング・セットのロード
■
SQL チューニング・セットの内容の表示
■
SQL チューニング・セットの変更
■
SQL チューニング・セットの転送
■
SQL チューニング・セットの削除
■
SQL チューニング・セットに対するその他の操作
関連項目 : DBMS_SQLTUNE パッケージの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照
してください。
12-10
Oracle Database パフォーマンス・チューニング・ガイド
SQL チューニング・セット
SQL チューニング・セットの作成
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 チューニング・セットのロード
LOAD_SQLSET プロシージャでは、選択した SQL 文が STS に移入されます。STS に移入するた
めの標準ソースは、ワークロード・リポジトリ、他の STS またはカーソル・キャッシュです。
ワークロード・リポジトリおよび STS のどちらの場合も、事前定義済のテーブル・ファンク
ションを使用して、新規 STS に移入する列をソースから選択できます。
次の例では、プロシージャ・コールを使用して、AWR ベースライン peak baseline から
my_sql_tuning_set がロードされます。このデータは、経過時間の順に上位 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',
NULL, NULL,
'elapsed_time',
NULL, NULL, NULL,
30)) p;
DBMS_SQLTUNE.LOAD_SQLSET(
sqlset_name
=> 'my_sql_tuning_set',
populate_cursor => baseline_cursor);
END;
/
SQL チューニング・セットの内容の表示
SELECT_SQLSET テーブル・ファンクションでは、STS の内容が読み取られます。STS が作成
および移入された後、異なるフィルタ基準を使用して STS 内の SQL を参照できます。この目的
のため、SELECT_SQLSET プロシージャが提供されます。
次の例では、STS 内でバッファ取得に対するディスク読取りの比率が 75% 以上の SQL 文が表
示されます。
SELECT * FROM TABLE(DBMS_SQLTUNE.SELECT_SQLSET(
'my_sql_tuning_set',
'(disk_reads/buffer_gets) >= 0.75'));
作成されてロードされた SQL チューニング・セットのその他の詳細も、DBA_SQLSET、
DBA_SQLSET_STATEMENTS および DBA_SQLSET_BINDS などの DBA ビューを使用して表示で
きます。
自動 SQL チューニング
12-11
SQL チューニング・セット
SQL チューニング・セットの変更
SQL 文は、検索条件に基づいて SQL チューニング・セットから更新および削除できます。次の
例では、実行回数が 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 チューニング・セットの転送
SQL チューニング・セットは、他のシステムへ転送できます。まず STS をあるシステムからス
テージング表にエクスポートし、次にステージング表から別のシステムに STS をインポートし
ます。
SQL チューニング・セットを転送する手順は次のとおりです。
1.
CREATE_STGTAB_SQLSET プロシージャを使用して、SQL チューニング・セットをエクス
ポートする場所にステージング表を作成します。
次の例は、staging_table という名前のステージング表の作成方法を示しています。
BEGIN
DBMS_SQLTUNE.CREATE_STGTAB_SQLSET( table_name => 'staging_table' );
END;
/
2.
PACK_STGTAB_SQLSET プロシージャを使用して、このステージング表に SQL チューニン
グ・セットをエクスポートします。
次の例は、my_sts という名前の SQL チューニング・セットをステージング表にエクス
ポートする方法を示しています。
BEGIN
DBMS_SQLTUNE.PACK_STGTAB_SQLSET(
sqlset_name => 'my_sts',
staging_table_name => 'staging_table');
END;
/
3.
選択したメカニズム（datapump またはデータベース・リンクなど）を使用して SQL
チューニング・セットがインポートされるシステムに、ステージング表を移動します。
4.
SQL チューニング・セットのインポート対象となるシステムで、
UNPACK_STGTAB_SQLSET プロシージャを使用して、ステージング表から SQL チューニン
グ・セットをインポートします。
次の例は、ステージング表にある SQL チューニング・セットをインポートする方法を示し
ています。
BEGIN
DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET(
sqlset_name => '%',
replace => TRUE,
staging_table_name => 'staging_table');
END;
/
12-12
Oracle Database パフォーマンス・チューニング・ガイド
SQL プロファイル
SQL チューニング・セットの削除
DROP_SQLSET プロシージャは、不要になった STS を削除するために使用されます。たとえば、
次のようにします。
BEGIN
DBMS_SQLTUNE.DROP_SQLSET( sqlset_name => 'my_sql_tuning_set' );
END;
/
SQL チューニング・セットに対するその他の操作
次の API を使用して STS を管理できます。
■
STS 内の SQL 文の属性の更新
UPDATE_SQLSET プロシージャは、STS 名および SQL 識別子で識別される既存の STS 内の
SQL 文の属性（PRIORITY または OTHER など）を更新します。
■
全システム・ワークロードの取得
CAPTURE_CURSOR_CACHE_SQLSET 機能では、特定の間隔でカーソル・キャッシュを繰り
返しポーリングして、全システム・ワークロードを取得できます。この機能では、
SELECT_CURSOR_CACHE および LOAD_SQLSET プロシージャを繰り返し使用するよりも
効果的に、長期間にわたりカーソル・キャッシュを取得できます。この機能は、高負荷
SQL 文のワークロードのみを取得する AWR、またはデータ・ソースに 1 度のみアクセス
する LOAD_SQLSET プロシージャとは対照的に、ワークロード全体を効果的に取得します。
■
STS への参照の追加および削除
ADD_SQLSET_REFERENCE 関数では、既存の STS への新規参照が追加され、クライアント
が使用中であることが示されます。この関数では、追加された参照の識別子が戻されます。
REMOVE_SQLSET_REFERENCE プロシージャは、STS を非アクティブにし、クライアント
により使用されなくなったことを示すために使用されます。
SQL プロファイル
通常、SQL プロファイルは、自動 SQL チューニング・プロセスの一部として Oracle Enterprise
Manager で処理されますが、DBMS_SQLTUNE パッケージを介して管理できます。SQL プロ
ファイル API を使用するには、CREATE ANY SQL_PROFILE、DROP ANY SQL_PROFILE および
ALTER ANY SQL_PROFILE の各システム権限が必要です。
図 12-3 は、SQL プロファイル API を使用した場合に必要な手順を示しています。
図 12-3 SQL プロファイル API
この項では、次のトピックについて説明します。
■
SQL プロファイルの受入れ
■
SQL プロファイルの変更
■
SQL プロファイルの削除
関連項目 : DBMS_SQLTUNE パッケージの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照
してください。
自動 SQL チューニング
12-13
SQL プロファイル
SQL プロファイルの受入れ
SQL チューニング・アドバイザが SQL プロファイルの使用を推奨する場合、推奨された SQL
プロファイルを受け入れる必要があります。SQL チューニング・アドバイザで索引および SQL
プロファイルの使用が推奨されている場合、両方を使用する必要があります。
DBMS_SQLTUNE.ACCEPT_SQL_PROFILE プロシージャを使用して、SQL チューニング・アド
バイザにより推奨された SQL プロファイルを受け入れることができます。これにより、SQL プ
ロファイルが作成され、データベースに格納されます。たとえば、次のようにします。
DECLARE
my_sqlprofile_name
BEGIN
my_sqlprofile_name
task_name
=>
name
=>
force_match =>
END;
VARCHAR2(30);
:= DBMS_SQLTUNE.ACCEPT_SQL_PROFILE (
'my_sql_tuning_task',
'my_sql_profile',)
TRUE);
この例では、my_sql_tuning_task は、SQL チューニング・タスクの名前であり、
my_sql_profile は受け入れる SQL プロファイルの名前です。
通常、受け入れた SQL プロファイルは、ハッシュ関数を使用して生成された特殊な SQL シグ
ネチャを介して SQL 文と関連付けられます。このハッシュ関数は、シグネチャを生成する前
に、SQL 文の大 / 小文字（SQL 文全体を大文字に変更）および空白（余分な空白を削除）を正
規化します。このように、同じ SQL プロファイルは、大 / 小文字の使用と空白のみが異なる、
本質的に同じすべての SQL 文に対して有効です。ただし、force_match を true に設定するこ
とで、SQL プロファイルは、リテラル値をバインド変数に正規化した後で同じテキストを持つ
全 SQL 文に対しても有効です。これは、リテラル値のみが異なるテキストを持つ SQL に SQL
プロファイルの共有を許可するため、バインド変数よりもリテラル値を使用するアプリケー
ションで便利な場合があります。SQL テキストにリテラル値とバインド変数の両方が使用され
ている場合、またはこのパラメータが false（デフォルト値）に設定されている場合、リテラル
値は正規化されません。
SQL プロファイルの情報は、DBA_SQL_PROFILES ビューで表示できます。
SQL プロファイルの変更
既存の SQL プロファイルの STATUS、NAME、DESCRIPTION、CATEGORY および
FORCE_MATCH 属性を、ALTER_SQL_PROFILE プロシージャで変更できます。たとえば、次の
ようにします。
BEGIN
DBMS_SQLTUNE.ALTER_SQL_PROFILE(
name
=> 'my_sql_profile',
attribute_name => 'STATUS',
value
=> 'DISABLED');
END;
/
この例で my_sql_profile は、変更する SQL プロファイルの名前です。ステータス属性が
DISABLED に変更されているのは、SQL コンパイル時に SQL プロファイルが使用されないこ
とを意味します。
12-14
Oracle Database パフォーマンス・チューニング・ガイド
SQL チューニング情報ビュー
SQL プロファイルの削除
DROP_SQL_PROFILE プロシージャにより SQL プロファイルを削除できます。たとえば、次の
ようにします。
BEGIN
DBMS_SQLTUNE.DROP_SQL_PROFILE(name => 'my_sql_profile');
END;
/
この例では、my_sql_profile は、削除する SQL プロファイルの名前です。名前が存在しな
い場合に発生したエラーを無視するかどうかも指定できます。この例の場合、デフォルト値の
FALSE が確定されます。
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 チューニング・セット・ビュー（DBA_SQLSET、DBA_SQLSET_BINDS、
DBA_SQLSET_STATEMENTS および DBA_SQLSET_REFERENCES ビューなど）
。
SQL チューニング・セット内の文に対して取得した実行計画の情報は、
DBA_SQLSET_PLANS ビューおよび USER_SQLSET_PLANS ビューに表示されます。
■
SQL プロファイル情報は DBA_SQL_PROFILES ビューに表示されます。
■
アドバイザの実行進捗情報は、V$ADVISOR_PROGRESS ビューに表示されます。
■
SQL チューニングの関連情報を含む動的ビュー（V$SQL、V$SQLAREA、V$SQLSTATS およ
び V$SQL_BINDS ビューなど）
。
関連項目 : 静的データ・ディクショナリ・ビューおよび動的ビューの詳
細は、
『Oracle Database リファレンス』を参照してください。
自動 SQL チューニング
12-15
SQL チューニング情報ビュー
12-16
Oracle Database パフォーマンス・チューニング・ガイド
13
問合せオプティマイザ
この章では、SQL 処理、最適化方式および SQL 文を実行する特定の計画をオプティマイザが選
択する方法を説明します。
この章には次の項があります。
■
オプティマイザ操作
■
オプティマイザの目標の選択
■
問合せオプティマイザ機能の有効化および制御
■
問合せオプティマイザについて
■
問合せオプティマイザのアクセス・パスについて
■
結合について
問合せオプティマイザ
13-1
オプティマイザ操作
オプティマイザ操作
SQL 文は、全表スキャン、索引スキャン、ネステッド・ループおよびハッシュ結合などにおい
て、様々な方法で実行されます。問合せオプティマイザは、問合せで指定した参照オブジェク
トおよび条件に関連した多くの要素を考慮して SQL 文を最も効率よく実行する方法を判断しま
す。この判断は、SQL 文の処理で重要なステップであり、実行時間が大きく変化します。
注意 : オプティマイザは、Oracle のあるバージョンとその次のバージョ
ンで同じ決定を行うとはかぎりません。最新バージョンのオプティマイザ
は、より高度な情報を使用できるので、異なる決定を行います。
オプティマイザからは、最適な実行方法を説明する計画が出力されます。Oracle サーバーには、
問合せオプティマイザが用意されています。
Oracle によって処理される SQL 文について、オプティマイザは表 13-1 にリストした操作を実
行します。
表 13-1 オプティマイザ操作
操作
説明
式と条件の評価
オプティマイザは、まず、定数が含まれている式と条件を可能なか
ぎり完全に評価します。
文の変換
たとえば、相関副問合せやビューなどに関連する複合文について、
オプティマイザは元の文を同等の結合文に変換する場合がありま
す。
オプティマイザの目標の選択
オプティマイザでは、最適化の目標が判別されます。13-3 ページの
「オプティマイザの目標の選択」を参照してください。
アクセス・パスの選択
文がアクセスするそれぞれの表について、オプティマイザは、表
データを取得するために 1 つ以上の使用可能なアクセス・パスを選
択します。13-14 ページの「問合せオプティマイザのアクセス・パス
について」を参照してください。
結合順序の選択
2 つ以上の表を結合する結合文について、オプティマイザは、最初
に結合する表のペアを選択し、その後、その結果に結合する表を順
次選択していきます。13-23 ページの「問合せオプティマイザによる
結合の実行計画の選択方法」を参照してください。
オプティマイザの目標の設定および問合せオプティマイザの代表的な統計の収集によって、オ
プティマイザの選択を変えることができます。オプティマイザの目標はスループットまたは応
答時間です。13-3 ページの「オプティマイザの目標の選択」および 13-5 ページの「データ・
ディクショナリ内の問合せオプティマイザ統計」を参照してください。
特定のアプリケーション・データに関して、オプティマイザよりも多くの情報を持つアプリ
ケーション設計者であれば、より効率よく SQL 文を実行する方法を選択できる場合がありま
す。アプリケーション・デザイナは SQL 文のヒントを使用して、文の実行方法についてオプ
ティマイザに指示できます。
13-2
Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザの目標の選択
関連項目 :
■
■
■
■
■
SQL 処理およびオプティマイザの概要は、
『Oracle Database 概要』を
参照してください。
拡張可能オプティマイザの詳細は、
『Oracle Database データ・カート
リッジ開発者ガイド』を参照してください。
最適化の目標の詳細は、13-3 ページの「オプティマイザの目標の選
択」を参照してください。
統計を収集および使用する方法の詳細は、第 14 章「オプティマイザ統
計の管理」を参照してください。
SQL 文のヒントを使用する方法の詳細は、第 16 章「オプティマイザ・
ヒントの使用方法」を参照してください。
オプティマイザの目標の選択
デフォルトでは、問合せオプティマイザの目標は最高のスループットです。つまり、CBO は文
からアクセスされたすべての行を処理するのに必要な最小リソースを選択します。また最短応
答時間を目標とした文の最適化も可能です。つまり、CBO は SQL 文からアクセスされた最初
の行を処理するのに必要な最小リソースを使用します。
アプリケーションのニーズに基づいて、オプティマイザの目標を選択してください。
■
■
Oracle Reports アプリケーションのように、バッチで実行されるアプリケーションの場合
は、最高のスループットを目標に最適化してください。アプリケーションを起動するユー
ザーの関心は、アプリケーションを完了するために必要な時間のみに向けられているため、
通常、バッチ・アプリケーションではスループットの重要度が高くなります。アプリケー
ションの実行中にユーザーが個々の文の結果を調べることはないため、応答時間はそれほ
ど重要ではありません。
Oracle Forms アプリケーションや SQL*Plus の問合せのような対話形式のアプリケーション
の場合は、最短の応答時間を目標に最適化してください。対話形式では、ユーザーは、文
がアクセスする最初の行を参照するために待機しています。このため、対話形式のアプリ
ケーションでは応答時間が重要となります。
SQL 文に対する最適化のアプローチと目標を選択する場合のオプティマイザの動作は、次の要
因の影響を受けます。
■
OPTIMIZER_MODE 初期化パラメータ
■
問合せオプティマイザの目標変更に対するオプティマイザ SQL のヒント
■
データ・ディクショナリ内の問合せオプティマイザ統計
問合せオプティマイザ
13-3
オプティマイザの目標の選択
OPTIMIZER_MODE 初期化パラメータ
OPTIMIZER_MODE 初期化パラメータで、インスタンスに最適化アプローチを選択するためのデ
フォルト動作を設定します。指定可能な値およびその説明を表 13-2 に示します。
表 13-2 OPTIMIZER_MODE 初期化パラメータ値
値
説明
ALL_ROWS
オプティマイザは、セッション内の SQL 文に対して、統計の有無
とは関係なくコストベースのアプローチを使用し、最高のスルー
プット（最小のリソースを使用して文全体を完成させること）を目
標として最適化します。これはデフォルト値です。
FIRST_ROWS_n
オプティマイザは統計の有無とは関係なく、コストベースのアプ
ローチを使用し、最短応答時間で最初の n 行を戻すように最適化し
ます。n は 1、10、100 または 1000 です。
FIRST_ROWS
オプティマイザは、コストと経験則を組み合せて、最初の数行の高
速配信のための最適な計画を見つけます。
注意 : 問合せオプティマイザは、経験則を使用すると、経験則を適
用しない場合に比べてコストがはるかに大きい計画を生成する場合
があります。FIRST_ROWS は、下位互換性とプラン・スタビリティ
のためのものです。かわりに FIRST_ROWS_n を使用してください。
初期化ファイル内のパラメータ値の変更、または ALTER SESSION SET OPTIMIZER_MODE 文に
よって、セッション内のすべての SQL 文の問合せオプティマイザの目標を変更できます。たと
えば、次のようにします。
■
初期化パラメータ・ファイル内の次の文は、インスタンスのすべてのセッションの問合せ
オプティマイザの目標を最短の応答時間に設定します。
OPTIMIZER_MODE = FIRST_ROWS_1
■
次の SQL 文は、現行セッションの問合せオプティマイザの目標を最短の応答時間に変更し
ます。
ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1;
オプティマイザがコストベースのアプローチを SQL 文に使用するときに、文がアクセスする一
部の表に統計が存在しない場合、オプティマイザはそれらの表に割り当てられているデータ・
ブロック数などの内部情報を使用して表に対する別の統計を見積ります。
問合せオプティマイザの目標変更に対するオプティマイザ SQL のヒント
各 SQL 文に対する問合せオプティマイザの目標を指定する場合は、表 13-3 のヒントのいずれ
かを使用します。各 SQL 文にあるこれらのヒントは、いずれも、その SQL 文の
OPTIMIZER_MODE 初期化パラメータを上書きできます。
表 13-3 問合せオプティマイザの目標変更に対するヒント
ヒント
説明
FIRST_ROWS(n)
このヒントは、個々の SQL 文を最適化して最初の n 行を最短応答
時間で戻すように、Oracle に指示します。ここでは、n は正の整数
です。このヒントでは、SQL 文に対して、統計の有無に関係なくコ
ストベースのアプローチが使用されます。
ALL_ROWS
このヒントでは、最高のスループットを目標として SQL 文を最適化
するために、コストベースのアプローチが明示的に選択されます。
関連項目 : ヒントを使用する方法の詳細は、第 16 章「オプティマイザ・
ヒントの使用方法」を参照してください。
13-4
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザ機能の有効化および制御
データ・ディクショナリ内の問合せオプティマイザ統計
問合せオプティマイザで使用される統計は、データ・ディクショナリに格納されます。
DBMS_STATS パッケージを使用して、これらのスキーマ・オブジェクト内の物理的な記憶域の
特性とデータ配分に関する正確な統計または見積り統計を収集できます。
問合せオプティマイザの有効性を維持するには、データを代表する統計が必要です。偏った
データという、値の重複数のバリエーションが多いデータが存在する表列については、ヒスト
グラムを収集する必要があります。
その結果の統計によって、データの一意性と配分についての情報が問合せオプティマイザに提
供されます。この情報を使用することにより、問合せオプティマイザは計画コストを精密に計
算します。その結果、問合せオプティマイザは最小のコストを基に最良の実行計画を選択でき
るようになります。
問合せオプティマイザを使用するときに統計が使用不可である場合、
OPTMIZER_DYNAMIC_SAMPLING 初期化パラメータの設定によって、オプティマイザで動的サ
ンプリングが実行されます。この場合、最高のパフォーマンスを得るために解析時間が遅くな
る可能性があるため、オプティマイザに代表的なオプティマイザ統計が必要となります。
関連項目 :
■
■
■
第 14 章「オプティマイザ統計の管理」
ヒストグラムの詳細は、14-16 ページの「ヒストグラムの表示」を参
照してください。
14-13 ページ「動的サンプリングを使用した統計の見積り」
問合せオプティマイザ機能の有効化および制御
この項には、オプティマイザに固有の初期化パラメータが含まれています。次の項は、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）の問合せ計画の生成時のオプティマイザ機能を使用
可能にします。
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 パラメータを以前のバージョンに設定します。たとえば、問
問合せオプティマイザ
13-5
問合せオプティマイザ機能の有効化および制御
合せオプティマイザの動作をリリース 8.1.5 に保持するには、次のようにパラメータを設定しま
す。
OPTIMIZER_FEATURES_ENABLE=8.1.5;
この文により、8.1.5 より後のリリースで追加されたすべての新規オプティマイザ機能が無効に
なります。
注意 : リリースをアップグレードし、使用可能な新機能を有効にする場
合は、OPTIMIZER_FEATURES_ENABLE 初期化パラメータを明示的に設定
する必要はありません。
以前のリリースに OPTIMIZER_FEATURES_ENABLE パラメータを明示的に設定することはお薦
めしません。実行計画または問合せパフォーマンスの問題点は、必要に応じて解決することを
お薦めします。
関連項目 : OPTIMIZER_FEATURES_ENABLE パラメータに設定する各リ
リースの値と、それにより有効になるオプティマイザ機能の詳細は、
『Oracle Database リファレンス』を参照してください。
問合せオプティマイザの動作の制御
この項には、問合せオプティマイザの動作の管理に使用できる初期化パラメータの一部がリス
トされています。SQL 実行のパフォーマンスを向上するために、これらのパラメータを使用し
て様々なオプティマイザ機能を有効にできます。
CURSOR_SHARING
このパラメータは、SQL 文のリテラル値をバインド変数に変換します。値を変換するとカーソ
ル共有が改善され、SQL 文の実行計画は影響を受けます。オプティマイザは、実際のリテラル
値でなくバインド変数の有無に基づいて実行計画を生成します。
DB_FILE_MULTIBLOCK_READ_COUNT
このパラメータは、全表スキャンまたは高速全索引スキャン時に単一 I/O で読み取られるブ
ロックの個数を指定します。オプティマイザは、DB_FILE_MULTIBLOCK_READ_COUNT の値を
使用して、全表スキャンと高速全索引スキャンのコストを計算します。値が大きいほど全表ス
キャンのコストは低くなり、オプティマイザは索引スキャンより全表スキャンを選択します。
このパラメータが明示的に設定されていない（または 0 に設定されている）場合、全表スキャ
ンおよび高速全索引スキャンのコストを算出する際、オプティマイザはデフォルト値の 8 を使
用します。
OPTIMIZER_INDEX_CACHING
このパラメータは、ネステッド・ループとともに索引プローブのコスト計算の管理に使用しま
す。OPTIMIZER_INDEX_CACHING の 0 から 100 の範囲は、ネステッド・ループおよび IN リ
スト・イテレータの索引キャッシュに関するオプティマイザの仮定を変更するバッファ・
キャッシュ内の索引ブロックのキャッシュ率を管理します。この値が 100 となっている場合、
索引ブロックの 100% がバッファ・キャッシュに見つかる可能性が推測されます。オプティマ
イザはそれに応じて索引プローブあるいはネステッド・ループのコストを調整します。実行計
画は索引のキャッシュに応じて変更される可能性があります。このパラメータを使用するとき
は注意してください。
OPTIMIZER_INDEX_COST_ADJ
このパラメータを使用して、索引プローブのコストを調整できます。値の範囲は 1 から 10000
です。デフォルト値は 100 ですが、これは索引が標準のコスト計算モデルに基づいてアクセ
ス・パスとして評価されることを意味します。値 10 は、索引アクセス・パスのコストが標準
コストの 1/10 であることを意味します。
13-6
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
OPTIMIZER_MODE
この初期化パラメータは、インスタンスの起動時のオプティマイザのモードを設定します。可
能な値は、ALL_ROWS、FIRST_ROWS_n および FIRST_ROWS です。これらのパラメータ値の詳
細は、13-4 ページの「OPTIMIZER_MODE 初期化パラメータ」を参照してください。
PGA_AGGREGATE_TARGET
このパラメータは、ソートおよびハッシュ結合に割り当てられるメモリーの量を自動的に制御
します。ソートまたはハッシュ結合に大量のメモリーが割り当てられると、これらの操作のオ
プティマイザ・コストが減少します。7-35 ページの「PGA メモリー管理」を参照してくださ
い。
STAR_TRANSFORMATION_ENABLED
このパラメータを true に設定すると、問合せオプティマイザはスター・クエリーのためのス
ター型変換のコストを計算できます。スター型変換により、様々なファクト表の列でビット
マップ索引が結合されます。
関連項目 : 各パラメータの詳細は、『Oracle Database リファレンス』を
参照してください。
問合せオプティマイザについて
問合せオプティマイザは、SQL 文がアクセスするスキーマ・オブジェクト（表または索引）に
ついて、使用可能なアクセス・パスを検討し、統計に基づいた情報要素を考慮することによっ
て最も効果的な実行計画を判断します。また、問合せオプティマイザは文のコメントに配置さ
れた、最適化の指示であるヒントも考慮します。
関連項目 : ヒントの詳細は、第 16 章「オプティマイザ・ヒントの使用方
法」を参照してください。
問合せオプティマイザは次のステップを実行します。
1.
使用可能なアクセス・パスおよびヒントに基づき、SQL 文の可能な計画のセットを生成し
ます。
2.
文がアクセスする表、索引およびパーティションのデータ配分および記憶特性に関する
データ・ディクショナリ内の統計に基づき、計画のそれぞれのコストを見積ります。
コストとして見積られる値は、特定の計画での文の実行に必要と予測されるリソース使用
コスト
量に比例しています。オプティマイザは、I/O、CPU、メモリーなどのコンピュータ・リ
ソースの見積りに基づいて、アクセス・パスや結合順序のコストを計算します。
コストの大きいシリアル計画の実行には、コストの小さい計画の実行よりも多くの時間が
必要です。ただし、パラレル計画を使用する場合は、リソース使用量は経過時間に直接関
係しません。
3.
計画のコストを比較して、コストが最も小さいものを選択します。
問合せオプティマイザ
13-7
問合せオプティマイザについて
問合せオプティマイザの構成要素
問合せオプティマイザ操作には、次のものがあります。
■
問合せの変換
■
見積り
■
計画の生成
問合せオプティマイザの構成要素を図 13-1 に示します。
図 13-1 問合せオプティマイザの構成要素
問合せの変換
問合せトランスフォーマへの入力は、一連の問合せブロックによって表される解析済問合せで
す。問合せブロックは、互いにネストされているかまたは相互関係を持っています。問合せの
形式によって、問合せブロックの相互関係が判断されます。問合せトランスフォーマの主な目
的は、問合せの形式を変える必要があるかどうかを判断して、より適切な問合せ計画を生成で
きるようにすることです。問合せトランスフォーマでは、次のように様々な問合せ変換手法を
採用しています。
■
ビューのマージ
■
述語のプッシュ
■
副問合せのネスト解除
■
マテリアライズド・ビューを使用したクエリー・リライト
これらの変換は任意に組み合せて指定の問合せに適用できます。
ビューのマージ 問合せで参照されるビューは、パーサーによって個別の問合せブロックに拡張
されます。問合せブロックは、基本的にはビュー定義を表しますが、このため必然的にビュー
の結果も表すことになります。オプティマイザには、ビューの問合せブロックの 1 つを分離し
て分析し、ビュー・サブプランを生成するというオプションがあります。オプティマイザは、
問合せ計画全体の生成にビュー・サブプランを使用することで、残りの問合せを処理します。
この手法は、そのビューが問合せの残りの部分とは別に最適化されるため、通常は最適な問合
せ計画とはなりません。
13-8
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
問合せトランスフォーマは、ビューが含まれている問合せブロックにビューの問合せブロック
をマージして、潜在的に最適とは言えない計画を除去します。ほとんどのタイプのビューが
マージされます。ビューをマージするときには、ビューを表す問合せブロックが包含的な問合
せブロックにマージされます。ビューの問合せブロックは除去されているので、サブプランを
生成する必要はありません。
述語のプッシュ マージされていないビューについては、問合せトランスフォーマにより、関連
する述語を、ビューを包含する問合せブロックからビューの問合せブロックに組み込むことが
できます。この手法は、プッシュされた述語を索引へのアクセスやフィルタに使用できるので、
マージされていないビューのサブプランが改善されます。
副問合せのネスト解除 通常、副問合せを含む問合せのパフォーマンスは、副問合せのネストを
解除して結合に変換することにで改善できます。大半の副問合せは、問合せトランスフォーマ
でネスト解除されます。ネスト解除されない副問合せの場合は、個別のサブプランが生成され
ます。問合せ計画全体の実行速度を上げるため、サブプランは効果的な順序で並べられます。
マテリアライズド・ビューを使用したクエリー・リライト マテリアライズド・ビューは、結果
がマテリアライズされて表に格納された問合せと類似しています。マテリアライズド・ビュー
に関連付けられた問合せと互換性のあるユーザー問合せが検出されると、ユーザー問合せはマ
テリアライズド・ビューにリライトできます。この手法は、ほとんどの問合せ結果があらかじ
め計算されているため、ユーザー問合せの実行状態を改善します。問合せトランスフォーマは、
ユーザー問合せと互換性のあるマテリアライズド・ビューを検索し、1 つ以上のマテリアライ
ズド・ビューを選択してユーザー問合せをリライトします。問合せをリライトするためのマテ
リアライズド・ビューの使用はコストベースです。したがって、マテリアライズド・ビューを
使用せずに生成された計画のコストが、マテリアライズド・ビューを使用して生成された計画
のコストより低い場合、問合せはリライトされません。
ユーザー定義のバインド変数の照合
問合せオプティマイザは、カーソルの最初の起動時にユーザー定義バインド変数の値を照合し
ます。この機能により、WHERE 句の条件の選択性と、バインド変数のかわりにリテラルが使用
されたかどうかが判断されます。カーソルのその後の起動時は照合が行われず、また、その後
の起動で異なるバインド値を使用しても、カーソルは標準カーソル共有基準に基づいて共有さ
れます。
バインド変数が文に使用されている場合、カーソルを共有するために異なる起動が同じ実行計
画を使用するものとみなします。カーソルの異なる起動で様々な実行計画が使用される場合、
バインド変数が SQL 文で適切に使用されていない可能性があります。バインド照合は、すべて
のクライアントではなく特定のクライアント・セットに対して機能します。
関連項目 : クエリー・リライトの詳細は、『Oracle Database データ・
ウェアハウス・ガイド』を参照してください。
見積り
エスティメータは、異なるタイプのメジャーを 3 通り生成します。
■
選択性
■
カーディナリティ
■
コスト
これらのメジャーは相互に関連性があり、あるメジャーは別のメジャーから派生します。エス
ティメータの最終目標は、指定された計画のコスト全体を算出することです。統計が使用可能
な場合、エスティメータは統計を使用してメジャーを計算します。統計によって、メジャーの
正確さの度合いは改良されます。
問合せオプティマイザ
13-9
問合せオプティマイザについて
選択性 最初のメジャーは行セットの一部の行を表す選択性です。行セットとは、実表、
ビュー、結合結果または GROUP BY 演算子の結果です。選択性は、last_name = 'Smith' など
の問合せ述語、または last_name = 'Smith' AND job_type = 'Clerk' などの述語の組合せに
拘束されています。述語はフィルタとして機能します。このフィルタは、行セットから特定数
の行を選別します。したがって、述語の選択性が述語テストに合格する行セットの行数を示し
ています。選択性の値範囲は、0.0 から 1.0 です。選択性が 0.0 の場合、行セットから行は選択
されず、選択性が 1.0 の場合はすべての行が選択されます。
使用可能な統計が存在しない場合、オプティマイザは、OPTIMIZER_DYNAMIC_SAMPLING 初
期化パラメータの値に応じて動的サンプリングまたは内部デフォルト値を使用します。使用さ
れる内部デフォルトは、述語のタイプによって異なります。たとえば、等価述語（last_name
= 'Smith'）の内部デフォルトは範囲述語（last_name > 'Smith'）の内部デフォルトより低く
なっています。エスティメータがこの仮定を行うのは、等価述語が範囲述語より少ない行数の
行を戻すことが予測されるためです。14-13 ページの「動的サンプリングを使用した統計の見積
り」を参照してください。
統計が使用可能な場合、エスティメータは統計を使用して選択性を推測します。たとえば、等
価述語（last_name = 'Smith'）の選択性は、last_name の個別値である数値 n の逆数に設定
されます。これは、問合せが n の内から 1 つの個別値をすべて含む行を選択するためです。
last_name 列でヒストグラムが使用可能な場合、エスティメータは個別値のかわりにヒストグ
ラムを使用します。ヒストグラムには列内の異なる値の分散が示されているので、より適切な
選択性の見積りが行われます。偏ったデータ（値の重複数のバリエーションが多いデータ）が
含まれている列のヒストグラムが存在すると、問合せオプティマイザが適切な選択性の見積り
を生成するのに役立ちます。
関連項目 : ヒストグラムの詳細は、14-16 ページの「ヒストグラムの表示」
を参照してください。
カーディナリティ カーディナリティは、行セット内の行数を表します。ここでの行セットと
は、実表、ビュー、結合結果または GROUP BY 演算子の結果です。
コスト コストは、作業単位または使用されるリソースを表します。問合せオプティマイザは
ディスク I/O、CPU 使用量、メモリー使用量を作業単位として使用します。しかし、問合せオ
プティマイザによって使用されるコストは、操作の実行で使用した CPU とメモリーの量の見積
り数になります。すなわち、操作には表をスキャンすること、索引を使用して表から行にアク
セスすること、2 つの表を結合すること、または行セットをソートすることなどがあります。
問合せ計画のコストは、問合せが実行されてその結果が生成されるときに発生すると予測され
る作業単位の数です。
アクセス・パス
アクセス パスは、実表からデータを得るときに実行される作業単位数です。アクセス・パス
パス
には、表スキャン、高速全索引スキャンまたは索引スキャンがなどがあります。表スキャンま
たは高速全索引スキャンの実行中には、単独の I/O 操作で複数のブロックがディスクから読み
込まれます。したがって、表スキャンまたは高速全索引スキャンのコストは、スキャンされる
ブロック数およびマルチブロック READ カウントに左右されます。索引スキャンのコストは、
B ツリーにおけるレベル、つまりスキャンされる索引リーフ・ブロック数、索引キーの
ROWID を使用してフェッチされる行数に左右されます。ROWID を使用して行をフェッチする
コストは、索引クラスタ化係数に依存します。13-17 ページの「ブロックの I/O（行ではなく）
の想定」を参照してください。
結合コストは、結合されている
2 つの行セットの個別のアクセス・コストの組合せと、結合操
結合コスト
作のコストを表します。
関連項目 :
ださい。
13-10
結合の詳細は、13-22 ページの「結合について」を参照してく
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
計画の生成
プラン・ジェネレータの主な機能は、指定の問合せに対して使用できる可能性のある別の計画
を割り出し、コストの最も低いものを取り出すことです。異なる方法でデータをアクセスおよ
び処理し、かつ結果が同じになる、様々なアクセス・パス、結合方法および結合順序の組合せ
が存在するので、多数の異なる計画が使用できます。
結合順序は、異なる結合項目（表など）がアクセスされて結合される順序です。たとえば、
table1、table2 および table3 の結合順序では、表 table1 が最初にアクセスされます。次
に、table2 がアクセスされ、そのデータが table1 のデータに結合されて table1 と
table2 の結合が生成されます。最後に table3 がアクセスされ、そのデータが table1 と
table2 の結合結果に結合されます。
問合せのための計画は、まず最初にネストされた副問合せおよびマージされていないビューの
それぞれにサブプランを生成することによって構築されます。ネストされた副問合せ、または
マージされていないビューは、それぞれ、個別の問合せブロックによって表されます。問合せ
ブロックは、それぞれ、下位から上位へ順番に最適化されます。つまり、最も内側の問合せブ
ロックが最初に最適化され、サブプランが生成されます。そして、問合せ全体を表す最も外側
の問合せブロックは、最後に最適化されます。
プラン・ジェネレータは、別のアクセス・パス、結合方法および結合順序を試行することに
よって、問合せブロックに対する様々な計画を探索します。問合せブロックに使用できる可能
性のある計画の数は、FROM 句にある結合項目の数に比例します。この数は、結合項目の数に
よって指数関数的に上昇します。
プラン・ジェネレータは内部カットオフを使用して計画数を削減し、最もコストの低い計画を
検索しようとします。カットオフの基準は、現行の最適な計画のコストです。現行の最適コス
トが大きい場合、プラン・ジェネレータはコストがより低く、より適切な計画（つまり、さら
に別の計画）を探索します。現行の最適コストが低い場合は、これ以上のコストの改善を追及
しても大きな効果は得られないため、プラン・ジェネレータは検索を速やかに終了します。
最適な状態に最も近いコストで計画を生成する初期結合順序で、プラン・ジェネレータが始動
する場合は、カットオフが有効に機能します。適切な初期結合順序の検索は困難です。
実行計画の読み方と理解
SQL 文を実行するために、Oracle は、多数のステップを実行する必要があります。実行される
各ステップでは、データベースからのデータ行の物理的な取出し、またはユーザーが発行する
文に返すデータ行の準備のどちらかが実行されます。文を実行するために Oracle が使用するス
テップの組合せのことを実行計画
実行計画と呼びます。実行計画には、文がアクセスする各表へのアク
アク
実行計画
セス・パスと、適切な結合方法
結合方法に基づく表の順序（結合順序
結合順序）が含まれています。
セス・パス
結合方法
結合順序
関連項目 :
■
13-14 ページ「問合せオプティマイザのアクセス・パスについて」
■
第 19 章「EXPLAIN PLAN の使用方法」
EXPLAIN PLAN の概要
EXPLAIN PLAN 文を使用することにより、オプティマイザが SQL 文に対して選択した実行計
画を確認できます。文が発行されると、オプティマイザが実行計画を選択した後で、計画を説
明するデータがデータベース表に挿入されます。単純に、EXPLAIN PLAN 文を発行し、出力
表を問い合せます。
EXPLAIN PLAN 文の使用方法の基本は次のとおりです。
■
■
SQL スクリプト UTLXPLAN.SQL を使用し、使用しているスキーマ内に PLAN_TABLE という
サンプル出力表を作成してください。19-4 ページの「PLAN_TABLE 出力表」を参照して
ください。
SQL 文の前に EXPLAIN PLAN FOR 句を挿入します。19-5 ページの「EXPLAIN PLAN の
実行」を参照してください。
問合せオプティマイザ
13-11
問合せオプティマイザについて
■
■
EXPLAIN PLAN 文を発行した後、Oracle から提供されるスクリプトまたはパッケージの
いずれかを使用して最新の計画表出力を表示します。19-6 ページの「PLAN_TABLE 出力
の表示」を参照してください。
EXPLAIN PLAN の出力実行順序は、最も右端にインデントされている行から始まります。
次のステップは、その行の親です。2 つの行が等しくインデントされている場合、通常、
最上位の行が最初に実行されます。
注意 :
■
■
この章では、EXPLAIN PLAN 出力表は utlxpls.sql スクリプトで表
示されました。
この章の EXPLAIN PLAN 出力のステップは、システムによって異なる
場合があります。データベース構成によって、オプティマイザは異な
る実行計画を選択する場合があります。
例 13-1 では EXPLAIN PLAN を使用して、ID が 103 より小さい従業員の、employee_id、
job_title、salary および department_name を選択する SQL 文について説明しています。
例 13-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;
例 13-2 の結果の出力表では、例にある SQL 文を実行するためにオプティマイザで選択された
実行計画が示されています。
例 13-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")
13-12
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザについて
実行計画のステップ
出力表内の各行は、実行計画内の 1 つのステップに対応しています。アスタリスクの付いたス
テップ ID は、Predicate Information セクションにリストされています。
関連項目 :
第 19 章「EXPLAIN PLAN の使用方法」
実行計画の各ステップで、行のセットが戻されます。この行のセットは、次のステップで使用
されます。最後のステップでは、SQL 文を発行しているユーザーまたはアプリケーションに対
し、行のセットが戻されます。各ステップで戻される行のセットを、行セットと呼びます。
ステップ ID の番号は、EXPLAIN PLAN 文で返された実行計画の順序 ID に対応しています。実
行計画の各ステップでは、データベースから行を取り出すか、1 つ以上の行ソースから行を入
力として受け入れます。
■
例 13-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 を持つ行を取得
します。
例 13-2 の次のステップでは、直前の行ソースから戻された行を処理します。
■
■
ステップ 2 では、ステップ 3 およびステップ 4 から戻される行ソースを受け入れ、ス
テップ 3 からの各行をステップ 4 の対応する行に結合し、その結果の行をステップ 2
に戻す、ネステッド・ループ操作を、jobs 表および employees 表の job_id で実行
します。
ステップ 1 では、ステップ 2 およびステップ 6 から戻される行ソースを受け入れ、ス
テップ 2 からの各行をステップ 6 の対応する行に結合し、その結果の行をステップ 1
に戻すネステッド・ループ操作を実行します。
関連項目 :
■
■
アクセス・パスの詳細は、13-14 ページの「問合せオプティマイザの
アクセス・パスについて」を参照してください。
Oracle が行ソースを結合する方法の詳細は、13-22 ページの「結合に
ついて」を参照してください。
問合せオプティマイザ
13-13
問合せオプティマイザのアクセス・パスについて
問合せオプティマイザのアクセス・パスについて
アクセス・パスは、データベースからデータを取り出す経路です。一般に、表の行の小さいサ
ブセットを取得する文には索引アクセス・パスを指定する必要がありますが、表の大きい部分
にアクセスするときは全体スキャンの方が効率がよくなります。オンライン・トランザクショ
ン処理（OLTP）アプリケーションは、選択性が高く実行の短い SQL 文から構成されており、
多くの場合は索引アクセス・パスを使用するという特徴があります。それに対して、意思決定
支援システムはパーティション表を使用し、関連するパーティションの全体スキャンを実行す
る傾向があります。
この項では、表内の任意の行の検索および取出しに使用できるデータ・アクセス・パスについ
て説明します。
■
全表スキャン
■
ROWID スキャン
■
索引スキャン
■
クラスタ・アクセス
■
ハッシュ・アクセス
■
サンプル表スキャン
■
問合せオプティマイザによるアクセス・パスの選択方法
全表スキャン
このタイプのスキャンでは、表にあるすべての行の読取り、選択基準を満たしていない行の
フィルタが実行されます。全表スキャンで、最高水位標以下の、表中のすべてのブロックがス
キャンされます。最高水位標は、使用済領域の量、またはデータを受け取るようにフォーマッ
トされている領域を示します。各行が文の WHERE 句を満たすかどうかを判断するために、各行
が検査されます。
全表スキャンを行うと、ブロックが順に読み取られます。ブロックは隣接しているため、単一
ブロックより大きい I/O コールを使用してプロセスを高速化できます。リード・コールのサイ
ズの範囲は、1 ブロックから初期化パラメータ DB_FILE_MULTIBLOCK_READ_COUNT で示され
るブロック数までです。マルチブロック READ を使用すると、全表スキャンを効率よく実行で
きます。各ブロックは 1 回のみ読み取られます。
13-12 ページの例 13-2「EXPLAIN PLAN 出力」には、employees 表の全表スキャン例が含ま
れています。
大量データにアクセスする場合に全表スキャンの方が高速になる理由
表の中の大部分のブロックにアクセスする場合は、索引レンジ・スキャンより全表スキャンの
方がコストが低くなります。これは、全表スキャンの方が大きい I/O コールを使用しており、
少数の大きい I/O コールの方が、多数の小さい I/O コールよりもコストが低いためです。
オプティマイザが全表スキャンを使用する場合
オプティマイザは、次のいずれかの場合に全表スキャンを使用します。
索引の欠落 問合せで既存の索引を使用できない場合、全表スキャンを使用します。たとえば、
索引付きの列で使用される関数が問合せ内にある場合、オプティマイザは索引を使用できず、
かわりに全表スキャンを使用します。
大小文字を区別しない検索に索引を使用する必要がある場合は、大小文字混合データを検索列
に許可しないか、検索列に UPPER(last_name) のようなファンクション索引を作成します。
15-7 ページの「パフォーマンスを考慮したファンクション索引の使用方法」を参照してくださ
い。
13-14
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
大量のデータ 問合せが表のブロックの大部分にアクセスするとオプティマイザが判断した場
合、索引が使用できる場合でも全表スキャンが使用される可能性があります。
小さい表 1 回の I/O コールで読み取れる DB_FILE_MULTIBLOCK_READ_COUNT より少ないブ
ロックが表の最高水位標以内に格納されている場合には、表のどの部分にアクセスされるかや、
索引があるかどうかに関係なく、全表スキャンを行う方が索引レンジ・スキャンよりもコスト
が低くなる可能性があります。
高い並列度 表の並列度が高いと、レンジ・スキャンよりも全表スキャンの方向にオプティマイ
ザを偏らせます。表の並列度を判断するには、ALL_TABLES 内の DEGREE 列を調べます。
全表スキャンのヒント
オプティマイザに全表スキャンの使用を指示する場合は、ヒント FULL（table alias）を使
用します。FULL ヒントの詳細は、16-3 ページの「アクセス・パスに関するヒント」を参照して
ください。
取得したブロックがバッファ・キャッシュのどこに置かれるかを示すには、CACHE および
NOCACHE ヒントを使用できます。CACHE ヒントでは、全表スキャンを実行する際、オプティ
マイザに指示して、取得されたブロックがバッファ・キャッシュ内で最後に使用された LRU リ
ストの最後に配置されるようにします。
小規模表は、表 13-4 の基準に従って自動的にキャッシュされます。
表 13-4 表のキャッシュ基準
表サイズ
サイズ基準
キャッシュ
小規模
ブロックの数が 20 より少な
い、またはキャッシュされて
いるブロックの合計の 2% の
うち、大きいもの
STATISTICS_LEVEL が TYPICAL またはそれ以
上に設定されている場合、Oracle では、表ス
キャン履歴に応じて、表をキャッシュするかど
うかが判別されます。今後の表スキャンで
キャッシュされるブロックが見つかる可能性が
ある場合にのみ、表がキャッシュされます。
STATISTICS_LEVEL が BASIC に設定されてい
る場合、表はキャッシュされません。
中規模
小規模表よりも大きいが、
キャッシュされているブロッ
クの合計が 10% より少ない
Oracle では、表スキャンおよびワークロードの
履歴に基づいて表をキャッシュするかどうか判
別します。今後の表スキャンでキャッシュされ
るブロックが見つかる可能性がある場合にのみ、
表がキャッシュされます。
大規模
キャッシュされているブロッ
クの合計が 10% より大きい
キャッシュされません
小規模表の自動キャッシュは、CACHE 属性で作成または変更された表に対しては使用禁止で
す。
パラレル問合せの実行
全表スキャンが必要である場合は、表のスキャンに複数のパラレル実行サーバーを使用して、
応答時間を向上できます。パラレル問合せは、リソース使用の可能性があるために、一般的に
は同時実行性の低いデータ・ウェアハウス環境で使用されます。
関連項目 : 『Oracle Database データ・ウェアハウス・ガイド』
問合せオプティマイザ
13-15
問合せオプティマイザのアクセス・パスについて
ROWID スキャン
行の ROWID には、行が含まれているデータファイルおよびデータ・ブロックと該当するブ
ロック内の位置を指定します。行の ROWID の特定による、行の位置特定は、単一行を取得す
る最も高速な方法です。これは、取得する行のデータベース内での正確な位置が指定されるた
めです。
ROWID を使用して表にアクセスする場合、まず、Oracle は選択された行の ROWID を、文の
WHERE 句、または 1 つ以上の表の索引の索引スキャンを使用して取得します。次に、Oracle は
ROWID に従って、それぞれの選択された行を表から探します。
13-12 ページの例 13-2「EXPLAIN PLAN 出力」では、索引スキャンが jobs 表および
departments 表に対して実行されます。取り出された ROWID は、行データを戻す場合に使
用します。
オプティマイザが ROWID を使用する場合
通常、これは索引から ROWID を取得した後の第 2 のステップです。索引内に存在しない文の
中の列には、表アクセスが必要になる場合があります。
ROWID によるアクセスでは、すべての索引スキャンに従う必要はありません。文に必要な列
がすべて索引に含まれていると、ROWID による表アクセスは行われない場合があります。
注意 : ROWID は、データが格納されている場所を表す Oracle の内部表
現です。ROWID はバージョン間で変更される場合があります。位置に基
づいたデータのアクセスは、お薦めしません。行の移行や連鎖によって、
行が移動するためです。また、エクスポートやインポートの後も同様で
す。外部キーは主キーに基づいている必要があります。ROWID の詳細は、
『Oracle Database アドバンスト・アプリケーション開発者ガイド』を参照
してください。
索引スキャン
この方法では、文で指定された索引付きの列の値を使用して索引が検索され、行が取得されま
す。索引スキャンでは、索引の 1 つ以上の列値に基づいて索引からデータが取得されます。索
引スキャンを実行するために、Oracle は文によってアクセスされた列に対応する索引を検索し
ます。文が索引付けされた列にしかアクセスしない場合、Oracle は索引付けされた列値を表か
らではなく、索引から直接読み込みます。
索引には、索引の値の他に、その値を持っている行の ROWID も含まれています。したがって、
索引付けされた列の他に別の列にも文がアクセスする場合、Oracle は、ROWID またはクラス
タ・スキャンによる表アクセスのどちらかを使用して、表内の行を検索できます。
索引スキャンには次のタイプがあります。
13-16
■
ブロックの I/O（行ではなく）の想定
■
索引一意スキャン
■
索引レンジ・スキャン
■
索引レンジ・スキャン降順
■
索引スキップ・スキャン
■
全体スキャン
■
高速全索引スキャン
■
索引結合
■
ビットマップ索引
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
ブロックの I/O（行ではなく）の想定
（行ではなく）の想定
Oracle は、ブロック単位で I/O を実行します。したがって、全表スキャンを使用するかどうか
のオプティマイザの決定は、行でなくアクセスされるブロックのパーセンテージに影響されま
す。これを索引クラスタ化係数といいます。ブロックに単一行が含まれている場合、アクセス
される行とアクセスされるブロックは同じです。
ただし、大半の表には各ブロック内に複数の行があります。したがって、目的の行が、少ない
ブロック内にまとまってクラスタ化されていたり、大量のブロックにわたって拡散されている
ことがあります。
クラスタ化係数は索引のプロパティですが、実際には、表のデータ・ブロック内の類似した索
引付き列の値の拡散度合いに関連します。低いクラスタ化係数は、個々の行が表の少数のブ
ロック内に集中されることを示します。逆に、高いクラスタ化係数は、個々の行が表の複数の
ブロックによりランダムに分散されることを示します。したがって、高いクラスタ化係数の場
合はレンジ・スキャンを使用して ROWID で行をフェッチするので、よりコストがかかります。
データを戻すために表の中のさらに多くのブロックにアクセスする必要があるためです。例
13-3 では、クラスタ化係数がコストにどのような影響を与えるかが示されています。
例 13-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 は一意スキャンを
実行します。
13-12 ページの例 13-2「EXPLAIN PLAN 出力」では、それぞれ job_id_pk 索引と
dept_id_pk 索引を使用して、jobs 表および departments 表で索引スキャンが実行されま
す。
オプティマイザが索引一意スキャンを使用する場合 このアクセス・パスは、一意（B ツリー）
索引または主キー制約の結果作成された索引の、すべての列が等価条件で指定される場合に使
用します。
関連項目 : 索引構造の詳細と B ツリーの検索方法の詳細は、
『Oracle
Database 概要』を参照してください。
問合せオプティマイザ
13-17
問合せオプティマイザのアクセス・パスについて
索引一意スキャンのヒント 一般に、一意スキャンを行うためのヒントを使用する必要はありま
せん。ただし、表がデータベース・リンクにまたがっていて、ローカル表からアクセスされる
場合や、表が小さく、オプティマイザが全表スキャンを選択する場合があります。
ヒント INDEX(alias index_name) は使用する索引を指定しますが、アクセス・パス（レン
ジ・スキャンや一意スキャン）は指定しません。INDEX ヒントの詳細は、16-3 ページの「アク
セス・パスに関するヒント」を参照してください。
索引レンジ・スキャン
索引レンジ・スキャンは、選択性の高いデータにアクセスする共通の操作です。このスキャン
は、境界（両側で境界付き）スキャンまたは非有界（片側または両側で）スキャンとすること
ができます。データは、索引列の昇順に戻されます。同じ値を持つ複数の行は、ROWID で昇
順にソートされます。
データを一定順序でソートする必要がある場合は、ORDER BY 句を使用し、索引には依存しま
せん。索引を使用して ORDER BY 句を満たせる場合、オプティマイザはこのオプションを使用
し、ソートを回避します。
例 13-4 では順序がレガシー・システムからインポートされており、レガシー・システム内での
参照で順序の問合せを行います。この参照が order_date であると仮定します。
例 13-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 でソートされます。
オプティマイザが索引レンジ・スキャンを使用する場合 オプティマイザは、次のように条件で
指定された索引の 1 つ以上の先頭列を検出したとき、レンジ・スキャンを使用します。
■
col1 = :b1
■
col1 < :b1
■
col1 > :b1
■
索引内の先頭列に対する前述の条件の AND 組合せ
■
col1 like 'ASD%' によるワイルド・カード検索は、先頭で行わないでください。これ
を先頭に置くと、条件 col1 like '%ASD' を使用した検索がレンジ・スキャンになりま
せん。
レンジ・スキャンでは、一意索引または非一意索引を使用できます。レンジ・スキャンでは、
索引列が ORDER BY/GROUP BY 句を構成しているときにソートを回避します。
索引レンジ・スキャンのヒント オプティマイザが他の索引を選択したり、全表スキャンを使用
する場合は、ヒントが必要になる場合があります。ヒント INDEX(table_alias index_name)
では、オプティマイザに指示して特定の索引を使用します。INDEX ヒントの詳細は、16-3 ページ
の「アクセス・パスに関するヒント」を参照してください。
13-18
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
索引レンジ・スキャン降順
索引レンジ・スキャン降順は、データが降順で戻されること以外、索引レンジ・スキャンと同
じです。デフォルトでは、索引は昇順に格納されます。通常、このスキャンが使用されるのは、
最初に最新のデータを戻すためにデータを降順に並べる場合や、指定された値より小さい値を
探す場合です。
オプティマイザが索引レンジ・スキャン降順を使用する場合 オプティマイザは、索引で降順句
による順序付けを満たせる場合に、索引レンジ・スキャン降順を使用します。
索引レンジ・スキャン降順のヒント ヒント INDEX_DESC(table_alias index_name) は、
このアクセス・パスに使用します。INDEX_DESC ヒントの詳細は、16-3 ページの「アクセス・
パスに関するヒント」を参照してください。
索引スキップ・スキャン
索引スキップ・スキャンにより、接頭辞の付いていない列による索引スキャンが改善されます。
多くの場合、索引ブロックをスキャンする方が、表データ・ブロックをスキャンするより高速
です。
スキップ・スキャンにより、コンポジット索引をさらに小さい副索引に論理的に分割できます。
スキップ・スキャンでは、コンポジット索引の初期列が問合せで指定されていません。つまり、
その列がスキップされます。
論理副索引の個数は、初期列内の個別値の数で決まります。スキップ・スキャンは、コンポ
ジット索引の先頭列に個別値がほとんどなく、索引の非先頭キーに値が多数ある場合に便利で
す。
例 13-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 の副索引。
図 13-2 索引スキップ・スキャン
問合せオプティマイザ
13-19
問合せオプティマイザのアクセス・パスについて
列 sex が、次の問合せでスキップされます。
SELECT *
FROM employees
WHERE employee_id = 101;
索引の完全なスキャンは行われませんが、まず値 F を持つ副索引が検索され、次に値 M を持つ
副索引が検索されます。
全体スキャン
全体スキャンを使用できるのは、述語が索引内の列の 1 つを参照している場合です。述語が索
引のドライバである必要はありません。述語がなく、次の条件が 2 つとも満たされる場合も、
全体スキャンを使用できます。
■
問合せで参照される表の列すべてが索引に含まれている。
■
少なくとも索引列の 1 つが NOT NULL。
全体スキャンを使用してソート操作を解消できるのは、データが索引キーで並べられるためで
す。全体スキャンではブロックが単独で読み込まれます。
高速全索引スキャン
高速全索引スキャンは、問合せに必要なすべての列が索引に含まれ、索引キー内の 1 つ以上の
列に NOT NULL 制約が存在する場合に、全表スキャンの代用として使用されます。高速全ス
キャンは、表にアクセスすることなく索引そのものに存在するデータにアクセスします。この
スキャンでソート操作を解消できないのは、データが索引キーで並べられないためです。高速
全スキャンでは、全索引スキャンとは異なりマルチブロック READ を使用して索引全体が読み
込まれ、パラレル実行も可能です。
初期化パラメータ OPTIMIZER_FEATURES_ENABLE または INDEX_FFS ヒントを使用して高速
全索引スキャンを指定できます。高速全索引スキャンはビットマップ索引に対しては実行でき
ません。
高速全スキャンは、表スキャンと同様にマルチブロック I/O を使用してパラレル化できるた
め、通常の全索引スキャンより高速です。
高速全索引スキャンのヒント 高速全索引スキャンには、特別な索引ヒント INDEX_FFS があり
ます。この形式と引数は、通常の INDEX ヒントと同じです。INDEX_FFS ヒントの詳細は、
16-3 ページの「アクセス・パスに関するヒント」を参照してください。
索引結合
索引結合は、問合せで参照される表の列すべてが含まれている複数の索引のハッシュ結合です。
索引結合が使用された場合は、関連するすべての列値が索引から取り出されるので、表アクセ
スは必要ありません。索引結合は、ソート操作の絞込みには使用できません。
索引結合のヒント 索引結合は、INDEX_JOIN ヒントを使用して指定できます。INDEX_JOIN
ヒントの詳細は、16-3 ページの「アクセス・パスに関するヒント」を参照してください。
ビットマップ索引
ビットマップ結合は、キー値用のビットマップおよび各ビット位置を ROWID に変換するマッ
ピング機能を使用します。ビットマップは、AND 条件と OR 条件の変換にブール演算を使用し
て、WHERE 句内の複数の条件に対応する索引を効果的にマージできます。
注意 : ビットマップ索引とビットマップ結合索引が使用可能なのは、
Oracle Enterprise Edition をご購入されている場合のみです。
関連項目 : ビットマップ索引の詳細は、『Oracle Database データ・ウェ
アハウス・ガイド』を参照してください。
13-20
Oracle Database パフォーマンス・チューニング・ガイド
問合せオプティマイザのアクセス・パスについて
クラスタ・アクセス
クラスタ・スキャンは、索引クラスタに格納された表から、クラスタ・キー値の等しい行すべ
てを取得するときに使用されます。索引クラスタ内においては、同一のクラスタ・キー値を持
つすべての行が同じデータ・ブロックに格納されています。クラスタ・スキャンを実行するた
めに、Oracle は、クラスタ索引をスキャンすることによって、選択されている行の ROWID を
最初に取得します。次に、Oracle はその行を ROWID に従って探します。
ハッシュ・アクセス
ハッシュ・スキャンは、ハッシュ値に基づいて行をハッシュ・クラスタに配置するために使用
します。ハッシュ・クラスタ内においては、同一のハッシュ値を持つすべての行が同じデー
タ・ブロックに格納されています。ハッシュ・スキャンを実行するために、Oracle は、文に
よって指定されたクラスタ・キー値にハッシュ関数を適用することによって、最初にハッシュ
値を取得します。次に、Oracle はそのハッシュ値を持つ行が含まれているデータ・ブロックを
操作します。
サンプル表スキャン
サンプル表スキャンでは、単純な表、または結合およびビューを含む文などの複合 SELECT 文
からデータのランダムなサンプルが取り出されます。このアクセス・パスは、文の FROM 句に
SAMPLE 句または SAMPLE BLOCK 句が含まれているときに使用されます。SAMPLE 句を持つ行
単位でサンプリングするときにサンプル表スキャンを実行するには、表の中の指定されたパー
セントの行を読み取ります。SAMPLE BLOCK 句を持つブロック単位でサンプリングするときに
サンプル表スキャンを実行するには、表のブロックの中の指定されたパーセントのブロックを
読み取ります。
例 13-6 は、サンプル表スキャンを使用して、ブロックによるサンプリングを行って
employees 表の 1% にアクセスします。
例 13-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 句の条件を
調べて、使用可能なアクセス・パスを最初に判断します。次に、オプティマイザは、使用可能
なアクセス・パスを使用して可能な実行計画のセットを生成し、文にアクセス可能な索引、列
および表の統計を使用して各見積りコストを生成します。そして最後に、オプティマイザは見
積りコストが最も少ない実行計画を選択します。
問合せオプティマイザ
13-21
結合について
アクセス・パスを選択する場合、問合せオプティマイザは次の影響を受けます。
■
オプティマイザ・ヒント
ヒントを使用し、特定のアクセス・パスを使用するようオプティマイザに指示できますが、
文の FROM 句に SAMPLE または SAMPLE BLOCK が含まれているときは使用できません。
関連項目 : SQL 文のヒントの詳細は、第 16 章「オプティマイザ・ヒント
の使用方法」を参照してください。
■
古い統計
たとえば、表が作成された後に解析されなかった場合およびブロックが
DB_FILE_MULTIBLOCK_READ_COUNT 最高水位標より少ない場合は、オプティマイザはそ
の表は小さいと判断し、全表スキャンが使用されます。ALL_TABLES 表内の
LAST_ANALYZED 列および BLOCKS 列を見て、統計を調べてください。
結合について
結合は、複数の表からデータを取り出す文です。結合は FROM 句の中の複数の表で特性化され、
各表の関係は WHERE 句の中に結合条件を設定することで定義されます。結合では、片方の行
セットが内部と呼ばれ、もう一方が外部と呼ばれます。
この項では、次の内容を説明します。
■
問合せオプティマイザによる結合文の実行方法
■
問合せオプティマイザによる結合の実行計画の選択方法
■
ネステッド・ループ結合
■
ハッシュ結合
■
ソート / マージ結合
■
デカルト結合
■
外部結合
問合せオプティマイザによる結合文の実行方法
結合文に実行計画を選択するために、オプティマイザは、相互に関連する次の決定を行う必要
があります。
■
アクセス・パス
単純な文では、オプティマイザは、結合文の各表からデータを取り出すアクセス・パスを
選択する必要があります。
■
結合方法
行ソースの各ペアを結合するには、結合操作を Oracle が実行する必要があります。結合方
法には、ネステッド・ループ結合、ソート / マージ結合、デカルト結合およびハッシュ結
合があります。
■
結合順序
3 つ以上の表を結合する文を実行する場合、Oracle は 2 つの表を結合し、その結果作成さ
れた行ソースを次の表に結合します。このプロセスは、すべての表がその結果に結合され
るまで続行されます。
関連項目 :
て」
13-22
13-14 ページ「問合せオプティマイザのアクセス・パスについ
Oracle Database パフォーマンス・チューニング・ガイド
結合について
問合せオプティマイザによる結合の実行計画の選択方法
実行計画を選択するとき、問合せオプティマイザでは次の点が考慮されます。
■
■
オプティマイザは、2 つ以上の表を結合した結果を、最大 1 つの行を含む行ソースに限定す
るかどうかを最初に判断します。オプティマイザは、このような状況を表の UNIQUE 制約
および PRIMARY KEY 制約に基づいて認識します。このような状況が存在する場合、オプ
ティマイザはこれらの表を結合順序の最初に並べます。その後で、残りの表の結合を最適
化します。
外部結合条件を持つ結合文では、外部結合演算子のある表の結合順序は、条件内のその他
の表の後にしてください。オプティマイザは、この規則に違反する結合順序を考慮しませ
ん。同様に、副問合せがアンチ結合またはセミ結合に変換されたときは、その副問合せか
らの表は、それらが接続または相互に関連付けされた外部問合せブロック内の表の後に置
きます。ただし、ある環境では、ハッシュ・アンチ結合およびセミ結合はこの順序条件を
上書きできます。
問合せオプティマイザでは、適用可能な結合順序、結合方法および使用可能なアクセス・パス
に従ってオプティマイザが実行計画のセットを生成します。次に、オプティマイザは各計画の
コストを見積り、コストが最も小さいものを選択します。オプティマイザは、次の方法でコス
トを見積ります。
■
■
■
ネステッド・ループ操作のコストは、外部表で選択されている各行およびその行に対する
内部表の一致行をメモリーに読み込むコストが基準になっています。オプティマイザは、
データ・ディクショナリ内の統計を使用してこれらのコストを見積ります。
ソート / マージ結合のコストは、主に、すべてのソースをメモリーに読み込んでソートす
るコストを基準にしています。
ハッシュ結合のコストは、主に、結合への入力側の 1 つ上にハッシュ表を作成するコスト
と、それを調べるために結合のもう一方からの行を使用するコストに基づきます。
オプティマイザは、各操作のコストを判断するときにはその他の要因についても考慮します。
たとえば、次のような場合があります。
■
■
ソート領域のサイズが小さいと、小さいソート領域内でのソートに CPU 時間と I/O がより
多く消費されるため、ソート / マージ結合のコストが大きくなる傾向があります。SQL 作
業領域のサイズ設定については、7-35 ページの「PGA メモリー管理」を参照してくださ
い。
マルチブロック READ カウントが大きいと、ネステッド・ループ結合に関してソート /
マージ結合のコストが少なくなる傾向があります。多数の連続したブロックが単独の I/O
でディスクから読み込まれる場合は、全表スキャンよりもパフォーマンスを改善するため
に、ネステッド・ループ結合の内部表についての索引が少なくなる傾向があります。マル
チブロック READ カウントは、初期化パラメータ DB_FILE_MULTIBLOCK_READ_COUNT
によって指定されます。
問合せオプティマイザでは、ORDERED ヒントを使用して結合順序に関するオプティマイザの選
択を上書きできます。ORDERED ヒントによって、外部結合に関するこの規則に違反する結合順
序が指定された場合、オプティマイザはこのヒントを無視して順序を選択します。結合方法に
関するオプティマイザの選択も、ヒントを使用して上書きできます。
関連項目 : オプティマイザ・ヒントの詳細は、第 16 章「オプティマイ
ザ・ヒントの使用方法」を参照してください。
問合せオプティマイザ
13-23
結合について
ネステッド・ループ結合
ネステッド・ループ結合は、データの小さいサブセットを結合する場合や、結合条件が第 2 の
表にアクセスする効率的な方法である場合に有効です。
内部表が外部表から（外部表によって）駆動されることを確認することが重要です。内部表の
アクセス・パスが外部表とは独立している場合は、外部ループを繰り返すたびに同じ行が取得
されます。これは、パフォーマンスをかなり低下させてしまいます。そのような場合は、2 つ
の独立した行ソースを結合するハッシュ結合の方がパフォーマンスが優れています。
関連項目 :
13-27 ページ「デカルト結合」
ネステッド・ループ結合には、次のステップがあります。
1.
オプティマイザで駆動表が決定され、これが外部表に指定されます。
2.
その他の表は、内部表に指定します。
3.
外部表にあるすべての行について、内部表にあるすべての行がアクセスされます。外部
ループは外部表にあるすべての行に対するものであり、内部ループは内部表の中にあるす
べての行に対するものです。次のように、外部ループは実行計画の内部ループの前に表示
されます。
NESTED LOOPS
outer_loop
inner_loop
ネステッド・ループ結合
この項では、13-12 ページの例 13-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)|
|
この例では、外部ループが employees 表のすべての行を取得します。外部ループによって取
得された各従業員に対して、内部ループが jobs 表内の関連行を取得します。
外部ループ 13-12 ページの例 13-2 の実行計画では、外部ループおよびそれと等価の文は次のと
おりです。
3 |
TABLE ACCESS FULL
| EMPLOYEES
SELECT e.employee_id, e.salary
FROM employees e
WHERE e.employee_id < 103
内部ループ 次のように、13-12 ページの例 13-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
13-24
Oracle Database パフォーマンス・チューニング・ガイド
結合について
オプティマイザがネステッド・ループ結合を使用する場合
オプティマイザは、2 つの表の間で適切な駆動条件で少数の行を結合する場合に、ネステッド・
ループ結合を使用します。外部ループから内部ループに起動するので、実行計画の中の表の順
序が重要になります。
外部ループは駆動行ソースです。このループは、結合条件を駆動するための一連の行を生成し
ます。行ソースは、索引スキャンまたは全表スキャンでアクセスされる表とすることができま
す。また、他の操作からでも行を生成できます。たとえば、ネステッド・ループ結合からの出
力は別のネステッド・ループ結合の行ソースとして使用できます。
内部ループは外部ループから戻された行ごとに、索引スキャンによって反復されます。内部
ループのアクセス・パスが外部ループに依存していない場合は、デカルト積で終了することが
可能で、外部ループの反復ごとに、内部ループは同じ行セットを生成します。したがって、2
つの独立した行ソースをまとめて結合する場合は、他の結合方法を使用することをお薦めしま
す。
ネステッド・ループ結合のヒント
オプティマイザが他の結合方法を選択する場合は、USE_NL(table1 table2) ヒントを使用し
ます。table1 と table2 は、結合される表の別名です。
データが十分に小さい SQL 例の場合は、オプティマイザは全表スキャンを優先してハッシュ結
合を使用します。13-26 ページの例 13-7「ハッシュ結合」は、その SQL の例です。ただし、
USE_NL を追加してオプティマイザに指示し、結合方法をネステッド・ループに変更できます。
USE_NL ヒントの詳細は、16-4 ページの「結合操作のヒント」を参照してください。
ネステッド・ループのネスト
ネステッド・ループの外部ループ自体もネステッド・ループにできます。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 つの表を結合します。
■
大量のデータを結合する必要がある。
■
小規模表の大きな部分を結合する必要がある。
例 13-7 では、表 orders がハッシュ表の作成に使用されます。また、後でスキャンされる
order_items は、これより大きな表です。
問合せオプティマイザ
13-25
結合について
例 13-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)|
|
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-35 ページ
の「PGA メモリー管理」を参照してください。USE_HASH ヒントの詳細は、16-4 ページの「結
合操作のヒント」を参照してください。
ソート / マージ結合
ソート / マージ結合を使用して、2 つの独立したソースからの行を結合できます。ハッシュ結
合は、一般に、ソート / マージ結合よりパフォーマンスが優れています。次の条件が 2 つとも
存在する場合は、ハッシュ結合よりソート / マージ結合の方がパフォーマンスの点で優れてい
ます。
■
行ソースはソート済。
■
ソート操作を終了する必要なし。
ソート / マージ結合に、より低速のアクセス方法（全表スキャンとは対照的な索引スキャン）
の選択が含まれている場合、ソート / マージを使用する利点が失われる可能性があります。
ソート / マージ結合は、2 つの表の間の結合条件が <、<=、> または >= などの等価条件ではな
い（ただし、非等価ではない）場合に有効です。ソート / マージ結合は、大きいデータ・セッ
トの場合にネステッド・ループ結合よりパフォーマンスが優れています。等価条件がないかぎ
り、ハッシュ結合を使用できません。
マージ結合には、駆動表の概念はありません。結合には、2 つのステップが含まれています。
1.
ソート結合操作 : 両方の入力が、結合キーでソートされる。
2.
マージ結合処理 : ソートされたリストがマージされる。
入力がすでに結合列でソートされている場合、その行ソースに対してソート結合操作は行われ
ません。
オプティマイザがソート / マージ結合を使用する場合
オプティマイザは、次の条件が真である場合に、ハッシュ結合よりソート / マージ結合を選択
して大量のデータを結合します。
■
■
13-26
2 つの表の間の結合条件が、等価結合ではない。
ソートが他の操作ですでに要求されているため、オプティマイザは、ハッシュ結合より
ソート / マージを使用する方がコストが低いと判断した。
Oracle Database パフォーマンス・チューニング・ガイド
結合について
ソート / マージ結合のヒント
ソート / マージ結合を使用するようオプティマイザに指示するには、USE_MERGE ヒントを適
用します。また、アクセス・パスを設定するためのヒントを与える必要がある場合があります。
USE_MERGE ヒントでオプティマイザを上書きした方がよい場合があります。たとえば、オプ
ティマイザは表に対する全体スキャンを選択して問合せ内でのソート操作を回避できます。た
だし、大きい表は全表スキャンによる高速アクセスの場合とは異なり、索引および単一ブロッ
ク読込みでアクセスされるため、コストがかかります。
USE_MERGE ヒントの詳細は、16-4 ページの「結合操作のヒント」を参照してください。
デカルト結合
他の表への結合条件を文中に持たない表が 1 つ以上ある場合に、デカルト結合が使用されます。
オプティマイザは、データ・ソースにあるすべての行を、2 つのセットのデカルト積を作成し
ながら、別のデータ・ソースにあるすべての行と結合します。
オプティマイザがデカルト結合を使用する場合
オプティマイザは、結合条件のない 2 つの表を結合する指示を受けると、デカルト結合を実行
します。場合によっては、2 つの表の間に共通のフィルタ条件が存在して、オプティマイザが
可能な結合条件として採用する可能性があります。また、オプティマイザが、同じ大きい表に
結合されている非常に小さい 2 つの表のデカルト積を生成するように決定する場合もあります。
デカルト結合のヒント
ORDERED ヒントを適用すると、オプティマイザに指示してデカルト結合を使用します。結合表
を指定する前に表を指定すると、オプティマイザはデカルト結合を行います。
外部結合
外部結合は単純結合の結果を拡張したものです。外部結合は、結合条件に一致するすべての行
および結合条件が他の表のどの行とも一致しない、表の一部またはすべての行を戻します。
ネステッド・ループ外部結合
この操作は、外部結合が 2 つの表の間で使用されるときに使用します。外部結合は、内部（オ
プション）表に対応する行がない場合でも外部（保たれている）表の行を戻します。
正規の外部結合で、オプティマイザはコストに基づいて表（駆動する側と駆動される側）の順
序を選択します。ただし、ネステッド・ループ外部結合では、表の順序は結合条件で決定され
ます。行が保たれる外部表は、内部表に駆動する場合に使用します。
オプティマイザは、ネステッド・ループ結合を使用し、次の状況で外部結合を処理します。
■
外部表から内部表まで起動できる。
■
データ量が少なく、ネステッド・ループ方法が効果的と判断できる。
ネステッド・ループの外部結合例の場合は、USE_NL ヒントを例 13-8 に追加してオプティマイ
ザに指示し、ネステッド・ループを使用するようにできます。たとえば、次のようにします。
SELECT /*+ USE_NL(c o) */ cust_last_name, sum(nvl2(o.customer_id,0,1)) "Count"
問合せオプティマイザ
13-27
結合について
ハッシュ結合外部結合
データ量が十分大きく、ハッシュ結合方法が有効と判断される場合や、外部表から内部表を駆
動できない場合、オプティマイザは外部結合の処理にハッシュ結合を使用します。
表の順序はコストにより決定されます。外部表は、保存された行も含めて、ハッシュ表を作成
する場合に使用されるか、またはハッシュ表を調べるときに使用される場合があります。
例 13-8 では、一般的なハッシュ結合外部結合の問合せが示されています。この例では、与信限
度が 1000 を超えるすべての顧客が問い合されます。外部結合は、オーダーを持たない顧客を見
逃さないようにするために必要です。
例 13-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 |
6 (17)|
|
1 | HASH GROUP BY
|
|
168 | 3192 |
6 (17)|
|* 2 |
NESTED LOOPS OUTER |
|
260 | 4940 |
5 (0) |
|* 3 |
TABLE ACCESS FULL | CUSTOMERS
|
260 | 3900 |
5 (0) |
|* 4 |
INDEX RANGE SCAN | ORD_CUSTOMER_IX |
105 |
420 |
0 (0) |
----------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------3 - filter("C"."CREDIT_LIMIT">1000)
4 - access("C"."CUSTOMER_ID"="0"."CUSTOMER_ID"(+))
filter("O"."CUSTOMER_ID"(+)>0)
この問合せは、様々な条件に一致する顧客を検索します。内部表に対応する行が見つからない
と、外部結合は外部（保たれている）表の行とともに内部表の列に対して NULL を戻します。
この操作で、orders 行も持たない customers 行がすべて検索されます。
この場合、外部結合条件は次のとおりです。
customers.customer_id = orders.customer_id(+)
この条件の構成要素を次に示します。
■
外部表は customers です。
■
内部表は orders です。
■
この結合は、orders 内に対応する行を持たない行を含む customers 行を保存します。
行を戻すには、NOT EXISTS 副問合せを使用できます。ただし、ここでは表の全行の問合せを
行っているため、ハッシュ結合の方がパフォーマンスがよくなります（NOT EXISTS 副問合せ
がネストされていない場合を除く）
。
例 13-9 では、外部結合はマルチ表ビューに対して行われます。オプティマイザは通常の結合の
ようにビューを操作したり、述語をプッシュできないので、ビューの行セット全体を作成しま
す。
13-28
Oracle Database パフォーマンス・チューニング・ガイド
結合について
例 13-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 | HASH GROUP BY
|
|
144 | 4608 |
16 (32)|
|* 2 |
HASH JOIN OUTER
|
|
663 | 21216 |
15 (27)|
|* 3 |
TABLE ACCESS FULL
| CUSTOMERS
|
195 | 2925 |
6 (17)|
|
4 |
VIEW
| V_ORDERS
|
665 | 11305 |
|
|
5 |
HASH 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 で拡張されます。つまり、完
全外部結合を使用すると、表をまとめて結合できますが、結合される表内に対応する行を持た
ない行も示すことができます。
例 13-10 の問合せでは、全部門と、その各部門に属する全社員を取得しますが、これには次の
内容も含まれます。
■
部門に属さない全社員
■
社員のいない全部門
問合せオプティマイザ
13-29
結合について
例 13-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.
13-30
Oracle Database パフォーマンス・チューニング・ガイド
14
オプティマイザ統計の管理
この章では、問合せオプティマイザにとって統計が重要である理由、および DBMS_STATS パッ
ケージを使用したオプティマイザ統計の収集方法と使用方法を説明します。
この章には次の項があります。
■
統計について
■
自動統計収集
■
手動統計収集
■
システム統計
■
統計の管理
■
統計の参照
オプティマイザ統計の管理
14-1
統計について
統計について
オプティマイザ統計は、データベースとそのオブジェクトに関する詳細情報を記述するデータ
の集合です。これらの統計は、問合せオプティマイザで各 SQL 文に最適の実行計画を選択する
ために使用されます。オプティマイザ統計には次のものがあります。
■
■
■
■
表統計
–
行数
–
ブロック数
–
行の平均長さ
列統計情報
–
列内の個別値（NDV）数
–
列内の NULL 数
–
データ配分（ヒストグラム）
索引統計
–
リーフ・ブロック数
–
レベル
–
クラスタ化係数
システム統計
–
I/O パフォーマンスと使用率
–
CPU パフォーマンスと使用率
注意 : この項で説明する統計は、問合せを最適化する目的で作成されて
データ・ディクショナリに格納されるオプティマイザ統計です。この種の
統計を V$ ビューで参照可能なパフォーマンス統計と混同しないでくださ
い。
オプティマイザ統計はデータ・ディクショナリに格納されます。また、データ・ディクショナ
リ・ビューを使用して表示できます。14-16 ページの「統計の参照」を参照してください。
データベース内のオブジェクトは常に変化するため、これらのデータベース・オブジェクトが
正確に記述されるように統計を定期的に更新する必要があります。統計は Oracle により自動的
にメンテナンスされます。また、DBMS_STATS パッケージを使用するとオプティマイザ統計を
手動でメンテナンスできます。自動プロセスと手動プロセスについては、14-3 ページの「自動
統計収集」または 14-5 ページの「手動統計収集」を参照してください。
DBMS_STATS パッケージにも、統計を管理するためのプロシージャが用意されています。統計
のコピーを保存してリストアできます。あるシステムから統計をエクスポートし、別のシステ
ムにインポートできます。たとえば、本番システムからテスト・システムに統計をエクスポー
トできます。また、統計が変更されないようにロックすることも可能です。ロック方法につい
ては、14-13 ページの「表統計またはスキーマ統計のロック」を参照してください。
14-2
Oracle Database パフォーマンス・チューニング・ガイド
自動統計収集
自動統計収集
推奨の統計収集方法は、Oracle で統計の自動収集を可能にすることです。Oracle では、すべて
のデータベース・オブジェクトの統計が自動的に収集され、定期的にスケジュールされたメン
テナンス・ジョブで統計がメンテナンスされます。自動化された統計収集により、問合せオプ
ティマイザの管理に関連する多数の手動タスクが不要になり、統計の欠落または失効が原因で
不適切な実行計画が生成される可能性が大幅に低下します。
GATHER_STATS_JOB
オプティマイザ統計は、GATHER_STATS_JOB ジョブで自動的に収集されます。このジョブで
は、データベース内で次の統計を持つすべてのオブジェクトの統計が収集されます。
■
統計の欠落
■
統計の失効
このジョブはデータベースの作成時に自動的に作成され、スケジューラにより管理されます。
このスケジューラでは、メンテナンス・ウィンドウがオープンすると、このジョブが実行され
ます。デフォルトでは、メンテナンス・ウィンドウは、毎晩午後 10 時～午前 6 時まで、また週
末は 1 日中オープンしています。
stop_on_window_close 属性は、メンテナンス・ウィンドウがクローズしたとき、
GATHER_STATS_JOB を続けるかどうかを制御します。stop_on_window_close 属性のデ
フォルト設定は、TRUE であり、スケジューラはメンテナンス・ウィンドウがクローズしたとき
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
プロシージャでは、統計を必要とするデータベース・オブジェクトに優先順位が設定されるた
め、更新済の統計を最も必要とするオブジェクトが最初に処理されることです。これにより、
メンテナンス・ウィンドウがクローズする前に、最も必要性の高い統計が確実に収集されます。
自動統計収集を使用可能にする方法
自動統計収集は、データベースの作成時または以前のリリースからのアップグレード時にデ
フォルトで使用可能になります。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;
/
自動統計収集は、14-7 ページの「失効している統計の判別」で説明するように変更監視機能に
依存します。この機能が無効になっている場合、自動統計収集ジョブでは失効している統計を
検出できません。この機能は、STATISTICS_LEVEL パラメータが TYPICAL または ALL に設
定されている場合に有効になります。デフォルト値は TYPICAL です。
オプティマイザ統計の管理
14-3
自動統計収集
統計収集時の考慮事項
この項では、次の内容を説明します。
■
手動統計を使用する場合
■
前のバージョンの統計のリストア
■
統計のロック
手動統計を使用する場合
普通の速度で変更されるほとんどのデータベース・オブジェクトの場合は、自動統計収集で十
分です。ただし、自動統計収集では不十分な場合があります。自動統計収集は夜間のバッチ・
ウィンドウで実行されるため、日中に大幅に変更された表の統計が失効している可能性があり
ます。通常、この種のオブジェクトには次の 2 つのタイプがあります。
■
■
日中に削除または切り捨てられて再作成された揮発性の表
オブジェクトの合計サイズの 10% 以上を追加する大規模バルク・ロードのターゲットであ
るオブジェクト
揮発性の高い表の場合は、次の 2 つのアプローチがあります。
■
これらの表の統計を NULL に設定できます。Oracle では、統計のない表が検出されると、
問合せ最適化の一部として必要な統計が動的に収集されます。この動的サンプリング機能
は OPTIMIZER_DYNAMIC_SAMPLING パラメータにより制御されます。このパラメータは
2 以上の値に設定する必要があります。デフォルト値は 2 です。統計は、削除してから
ロックすることで NULL に設定できます。
BEGIN
DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS');
DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');
END;
/
設定できるサンプリング・レベルの詳細は、14-14 ページの「動的サンプリング・レベル」
を参照してください。
■
この種の表の統計は、表の典型的な状態を表す値に設定できます。表に代表的な行数が含
まれているときに、その表の統計を収集し、統計をロックする必要があります。
この方法は GATHER_STATS_JOB よりも効率的です。これは、夜間のバッチ・ウィンドウ
で表に関して生成された統計が、日中のワークロードに関して最も適切な統計であるとは
かぎらないためです。
バルク・ロード対象の表の場合は、統計収集プロシージャをロード・プロセスの直後に、可能
であればバルク・ロードを実行するのと同じスクリプトまたはジョブの一部として、実行する
必要があります。
外部表の場合、GATHER_SCHEMA_STATS、GATHER_DATABASE_STATS および自動統計収集処
理中には統計は収集されません。ただし、GATHER_TABLE_STATS を使用すると外部表の統計
を個別に収集できます。外部表のサンプリングはサポートされていないため、
ESTIMATE_PERCENT オプションは明示的に NULL に設定する必要があります。外部表のデー
タ操作は許可されないため、対応するファイルに変更があったときに外部表を分析すれば十分
です。
STATISTICS_LEVEL を BASIC に設定して監視機能を無効にすると、自動統計収集では失効し
ている統計を検出できません。この場合は、統計を手動で収集する必要があります。自動監視
機能の詳細は、14-7 ページの「失効している統計の判別」を参照してください。
システム統計も、手動で収集する必要があります。この種の統計は自動的には収集されません。
詳細は、14-8 ページの「システム統計」を参照してください。
動的パフォーマンス表など、固定オブジェクトの統計は、GATHER_FIXED_OBJECTS_STATS
プロシージャを使用して手動で収集する必要があります。固定オブジェクトには現行のデータ
ベース・アクティビティが記録されます。データベースに典型的なアクティビティがあるとき
に統計を収集する必要があります。
14-4
Oracle Database パフォーマンス・チューニング・ガイド
手動統計収集
前のバージョンの統計のリストア
ディクショナリ内で統計が変更されるたびに、後でリストアできるように前のバージョンの統
計が自動的に保存されます。統計をリストアするには、DBMS_STATS パッケージの RESTORE
プロシージャを使用します。詳細は、14-11 ページの「前のバージョンの統計のリストア」を参
照してください。
統計のロック
14-4 ページの「手動統計を使用する場合」で説明したように、揮発性の高い表など、表または
スキーマに関して DBMS_STATS_JOB プロセスによる新規統計の収集を中止する必要がある場
合があります。このような場合は、DBMS_STATS パッケージに表またはスキーマの統計をロッ
クするためのプロシージャが用意されています。詳細は、14-13 ページの「表統計またはスキー
マ統計のロック」を参照してください。
手動統計収集
自動統計収集を使用しないように選択した場合は、システム・スキーマを含め、すべてのス
キーマ内で統計を手動で収集する必要があります。データベース内のデータが定期的に変化す
る場合は、統計がデータベース・オブジェクトの特性を正確に表すように、統計も定期的に収
集する必要があります。
DBMS_STATS プロシージャによる統計の収集
統計は DBMS_STATS パッケージを使用して収集されます。この PL/SQL パッケージは、統計
の変更、表示、エクスポート、インポートおよび削除にも使用されます。
注意 : オプティマイザ統計の収集に、ANALYZE 文で COMPUTE 句および
ESTIMATE 句を使用しないでください。これらの句は下位互換性のために
のみサポートされており、将来のリリースでは削除される可能性がありま
す。DBMS_STATS パッケージを使用する方が、より広範囲で正確な統計
セットが効率的に収集されます。
オプティマイザ統計の収集に関係しない次のような用途には、引き続き
ANALYZE 文を使用できます。
■
VALIDATE または LIST CHAINED ROWS 句を使用する場合
■
空きリスト・ブロックの情報を収集する場合
DBMS_STATS パッケージでは、表と索引の統計、および表の列とパーティションの個別の統計
を収集できます。クラスタ統計は収集できません。ただし、DBMS_STATS を使用して、全クラ
スタのかわりに個別の表の統計を収集できます。
表、列または索引の統計を生成するとき、分析したオブジェクトの統計がすでにデータ・ディ
クショナリ内に収録されている場合、Oracle は既存の統計を更新します。古い統計は保存され、
後で必要に応じてリストアできます。14-11 ページの「前のバージョンの統計のリストア」を参
照してください。
システム・スキーマの統計を収集する場合は、DBMS_STATS.GATHER_DICTIONARY_STATS プ
ロシージャを使用できます。このプロシージャでは、SYS や SYSTEM を含むすべてのシステ
ム・スキーマと、CTXSYS や DRSYS などの他のオプション・スキーマの統計が収集されます。
データベース・オブジェクトの統計が更新されると、そのオブジェクトにアクセスする現在解
析済の SQL 文が無効にされます。文が次に実行されるときに、文が再解析され、オプティマイ
ザは新しい統計に基づいて新しい実行計画を自動的に選択します。リモート・データベース上
で新しい統計を持つオブジェクトにアクセスする分散型の文は、無効にされません。新しい統
計は、次回に SQL 文が解析されると有効になります。
表 14-1 は、DBMS_STATS パッケージにおけるデータベース・オブジェクトの統計収集のための
プロシージャです。
オプティマイザ統計の管理
14-5
手動統計収集
表 14-1 DBMS_STATS パッケージの統計収集プロシージャ
プロシージャ
収集対象
GATHER_INDEX_STATS
索引統計
GATHER_TABLE_STATS
表、列および索引の統計
GATHER_SCHEMA_STATS
スキーマ内のすべてのオブジェクトの統計
GATHER_DICTIONARY_STATS
すべてのディクショナリ・オブジェクトの統計
GATHER_DATABASE_STATS
データベース内のすべてのオブジェクトの統計
関連項目 : すべての DBMS_STATS プロシージャの構文と例については、
『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リ
ファレンス』を参照してください。
前述のプロシージャを統計収集に使用する場合は、次のようにいくつか重要な考慮事項があり
ます。
■
サンプリングを使用した統計収集
■
パラレル統計収集
■
パーティション・オブジェクトの統計
■
列統計情報とヒストグラム
■
失効している統計の判別
■
ユーザー定義統計
サンプリングを使用した統計収集
統計収集操作では、サンプリングを使用して統計を予測できます。サンプリングは、統計収集
の重要なテクニックです。サンプリングを使用せずに統計を収集するには、全表スキャンと表
全体のソートが必要です。サンプリングを使用すると、統計収集に必要なリソースが最小限に
抑えられます。
サンプリングは、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
パラメータの設定に基づいて適切な並列度を選択できます。
クラスタ索引、ドメイン索引およびビットマップ結合索引など、特定のタイプの索引統計は、
パラレルでは収集されないことに注意してください。
14-6
Oracle Database パフォーマンス・チューニング・ガイド
手動統計収集
パーティション・オブジェクトの統計
パーティション表および索引に対して、DBMS_STATS は、各パーティションの個別の統計を収
集できます。また、全表または全索引のグローバル統計も収集できます。コンポジット・パー
ティションについても同様に、DBMS_STATS はサブパーティション、パーティション、全表お
よび全索引の個別の統計を収集できます。収集するパーティション統計のタイプは、
DBMS_STATS 収集プロシージャの GRANULARITY 引数で指定します。
最適化された SQL 文によっては、オプティマイザがパーティション（サブパーティション）統
計またはグローバル統計の使用を選択する場合があります。どちらのタイプの統計もほとんど
のアプリケーションにとって重要であり、GRANULARITY パラメータを AUTO に設定して両方
のタイプのパーティション統計を収集することをお薦めします。
列統計情報とヒストグラム
表の統計を収集する場合、DBMS_STATS では表内の列のデータ配分情報が収集されます。デー
タ配分に関して最も基本的な情報は、列の最大値と最小値です。ただし、列のデータに偏りが
ある場合、このレベルの統計ではオプティマイザのニーズが十分に満たされない場合がありま
す。データ配分に偏りがある場合は、指定した列のデータ配分を記述するヒストグラムも列統
計の一部として作成できます。ヒストグラムの詳細は、14-16 ページの「ヒストグラムの表示」
を参照してください。
ヒストグラムは、DBMS_STATS 収集プロシージャの METHOD_OPT 引数を使用して指定します。
METHOD_OPT は FOR ALL COLUMNS SIZE AUTO に設定することをお薦めします。この設定で
は、どの列にヒストグラムが必要であるかということと各ヒストグラムのバケット数（サイズ）
が、Oracle により自動的に判別されます。また、これらの情報は手動でも指定できます。
注意 : DBMS_STATS を使用中に表からすべての行を削除する必要がある場
合、同じ表を削除して再度作成するかわりに、TRUNCATE を使用します。表
が削除されると、自動ヒストグラム収集機能が使用したワークロード情報と、
RESTORE_*_STATS プロシージャが使用した保存された統計履歴が消失しま
す。このデータなしでは、これらの機能は適切に動作しません。
失効している統計の判別
データベースは時間の経過につれて変更されるため、その統計を定期的に収集する必要があり
ます。特定のデータベース・オブジェクトに新規データベース統計が必要かどうかを判別する
ために、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 Database データ・
カートリッジ開発者ガイド』を参照してください。
オプティマイザ統計の管理
14-7
システム統計
統計を収集する時期
統計を手動で収集する場合は、その収集方法を決定するのみでなく、新規統計の収集時期と頻
度も決定する必要があります。
表の増分変更が行われるアプリケーションの場合は、新規の統計を週または月に 1 回収集する
のみで良い場合があります。このような環境で最も簡単な統計収集方法は、スクリプトまたは
ジョブ・スケジューリング・ツールを使用して、GATHER_SCHEMA_STATS および
GATHER_DATABASE_STATS プロシージャを定期的に実行することです。収集の頻度によって、
統計収集プロセスで起こるオーバーヘッドの処理に対し、オプティマイザの正確な統計を出す
タスクのバランスをとります。
バルク・ロードを使用する場合など、バッチ操作で逐次変更される表の場合は、その表の統計
をバッチ操作の一部として収集する必要があります。ロード操作の完了直後に DBMS_STATS プ
ロシージャをコールしてください。
パーティション表の場合、通常は 1 つのパーティションのみが変更されます。このような場合
は、表全体の統計を収集するのではなく、変更があったパーティションの統計のみを収集でき
ます。ただし、パーティション表のグローバル統計の収集も必要な場合があります。
関連項目 : DBMS_STATS パッケージの GATHER_SCHEMA_STATS および
GATHER_DATABASE_STATS プロシージャの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照
してください。
システム統計
システム統計は、問合せオプティマイザに対してシステムのハードウェア特性（I/O と CPU の
パフォーマンスおよび使用率など）を記述します。実行計画の選択時に、オプティマイザで各
問合せに必要な I/O および CPU リソースが見積もられます。システム統計を使用すると、問
合せオプティマイザは I/O および CPU コストをより正確に見積もることができ、問合せオプ
ティマイザはより適切な実行計画を選択できます。
システム統計を収集するとき、指定された期間のシステム・アクティビティ（作業負荷統計）
が分析されるか、作業負荷（非作業負荷統計）がシミュレートされます。統計は、
DBMS_STATS.GATHER_SYSTEM_STATS プロシージャを使用して収集されます。システム統計
を収集することをお薦めします。
注意 : ディクショナリ・システム統計を更新するには、DBA 権限または
GATHER_SYSTEM_STATISTICS ロールが必要です。
表 14-2 に、DBMS_STATS パッケージにより収集されたオプティマイザのシステム統計と、特定
のシステム統計の収集または手動設定のオプションを示します。
表 14-2 DBMS_STAT パッケージ内のオプティマイザのシステム統計
パラメータ名
説明
cpuspeedNW
ioseektim
iotfrspeed
14-8
初期化
統計の収集または設定のオプション
単位
作業負荷のない場合の CPU 速度を システム起動時
表します。CPU 速度は、1 秒当たり
の CPU 平均サイクル数です。
gathering_mode = NOWORKLOAD に
設定するか、または統計を手動で設定
します。
100 万 / 秒
I/O シーク時間は、シーク時間、待
機時間およびオペレーティング・シ
ステム・オーバーヘッド時間を合計
したものです。
システム起動時
gathering_mode = NOWORKLOAD に
設定するか、または統計を手動で設定
します。
ミリ秒
I/O 転送速度は、1 回の読込み要求
で Oracle データベースがデータを
読み取ることができる速度です。
システム起動時
gathering_mode = NOWORKLOAD に
バイト /
ミリ秒
10（デフォルト）
4096（デフォルト） 設定するか、または統計を手動で設定
します。
Oracle Database パフォーマンス・チューニング・ガイド
システム統計
表 14-2 DBMS_STAT パッケージ内のオプティマイザのシステム統計（続き）
パラメータ名
説明
cpuspeed
初期化
統計の収集または設定のオプション
単位
作業負荷をかけた場合の CPU 速度 なし
を表します。CPU 速度は、1 秒当た
りの CPU 平均サイクル数です。
gathering_mode = NOWORKLOAD、
INTERVAL または START|STOP に設
定するか、または統計を手動で設定し
ます。
100 万 / 秒
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 文はすべて、新しい統計を使用して解析されます。
システム統計の収集方法には 2 つのオプションがあります。
■
作業負荷統計
■
非作業負荷統計
これらのオプションは、物理データベースおよび作業負荷の収集プロセスを容易に使用できる
ようにします。作業負荷システム統計が収集されると、非作業負荷システム統計は無視されま
す。非作業負荷システム統計は、データベースの初回の起動時にデフォルト値に初期化されま
す。
関連項目 : システム統計を実装するための DBMS_STATS パッケージのプ
ロシージャの詳細は、
『Oracle Database PL/SQL パッケージ・プロシー
ジャおよびタイプ・リファレンス』を参照してください。
作業負荷統計
Oracle 9i で導入された作業負荷統計は、シングルおよびマルチブロックの読取り時間、mbrc、
CPU 速度（cpuspeed）
、最大システム・スループットおよび平均スレーブ・スループットを収
集します。sreadtim、mreadtim および mbrc は、作業負荷の開始から終了までの 2 点間の、
物理的な順次およびランダム読取りの数を比較して計算されます。これらの値は、バッファ・
キャッシュが同期読取り要求を完了したときに変更されるカウンタを通して実装されます。こ
のカウンタはバッファ・キャッシュ内にあるため、これらには I/O 遅延のみならず、ラッチの
競合およびタスク・スイッチングに関連する待機も含まれています。このように、作業負荷統
計は、作業負荷ウィンドウでシステムが実行するアクティビティに応じて異なります。ラッチ
競合および I/O スループットの両方でシステムが I/O バウンドの場合、この状態は統計に反映
され、この統計が使用された後で I/O 低減化集中計画が促進されます。さらに、作業負荷統計
収集は、追加のオーバーヘッドを生成しません。
リリース 9.2 では、全表スキャン（FTS）の下限を設定するための最大 I/O スループットおよび
平均スレーブ・スループットが追加されました。
オプティマイザ統計の管理
14-9
システム統計
作業負荷統計の収集
作業負荷統計を収集するには、次のいずれかの手順を実行します。
■
■
作業負荷ウィンドウの開始時に dbms_stats.gather_system_stats('start') プロ
シージャを実行し、作業負荷ウィンドウの終了時に
dbms_stats.gather_system_stats('stop') プロシージャを実行します。
dbms_stats.gather_system_stats('interval', interval=>N) を実行します。
N は、統計収集が自動停止する時間（分）です。
システム統計を削除するには、dbms_stats.delete_system_stats() を実行します。作業
負荷統計が削除され、デフォルトの非作業負荷統計にリセットされます。
マルチブロック読込みカウント
リリース 10.2 では、オプティマイザは全表スキャン（FTS）の実行時に mbrc の値を使用しま
す。db_file_multiblock_read_count の値は、デフォルトでオペレーティング・システム
が許可する最大値に設定されます。ただし、オプティマイザはコスト計算に mbrc=8 を使用し
ます。実際の mbrc は、その中間値になります。いくつかのブロックがバッファ・キャッシュ
に確保されている場合、またはセグメント・サイズが読込みサイズより小さい場合、シリア
ル・マルチブロック読込み要求がバッファ・キャッシュで処理され、2 つ以上の要求に分割さ
れるためです。作業負荷統計の一部として収集された mbrc 値は、このように FTS の見積りに
有用です。
作業負荷統計の収集プロセスでシリアル作業負荷の間に表スキャンが実行されない場合（OLTP
システムでしばしば発生します）
、mbrc および mreadtim が収集されない場合があります。一
方、DSS システムでは FTS が頻繁に実行されますが、パラレル実行によってバッファ・キャッ
シュがバイパスされる可能性があります。このような場合、バッファ・キャッシュを使用して
索引参照が実行されるため、sreadtim が収集されます。mbrc または mreadtim を収集でき
ないか、または収集してもそれらの検証ができない場合で、sreadtim および cpuspeed が収
集済の場合は、sreadtim および cpuspeed のみがコスト計算に使用されます。FTS コスト
は、前のリリースで実装された分析アルゴリズムを使用して計算されます。mbrc および
mreadtim を計算するもう 1 つの方法は、FTS を強制的にシリアル・モードにしてオプティマ
イザでデータを収集できるようにする方法です。
非作業負荷統計
非作業負荷統計は、I/O 転送速度、I/O シーク時間および CPU 速度（cpuspeednw）で構成さ
れています。作業負荷統計と非作業負荷統計の主な違いは、収集方法にあります。
非作業負荷統計は、すべてのデータ・ファイルに対してランダム読取りを発行してデータを収
集しますが、作業負荷統計は、データベース・アクティビティの発生時に更新されるカウンタ
を使用します。isseektim は、ディスク・ヘッドがデータを読み取る位置に移動する時間を表
します。この値は、ディスクの回転速度およびディスクまたは RAID の仕様に応じて 5 ミリ秒
～ 15 ミリ秒の間で変化します。I/O 転送速度は、オペレーティング・システムの 1 つのプロセ
スで I/O サブシステムからのデータの読取りが可能な速度を表します。この値は、毎秒数 MB
から数百 MB まで大きく変化します。Oracle では、I/O 転送速度に比較的低い値のデフォルト
設定を使用しています。
Oracle 10g では、非作業負荷統計および CPU コスト・モデルをデフォルトで使用しています。
非作業負荷統計の値は、最初のインスタンス起動時にデフォルトに初期化されます。
ioseektim = 10ms
iotrfspeed = 4096 bytes/ms
cpuspeednw = gathered value, varies based on system
作業負荷統計が収集されると非作業負荷統計は無視され、かわりに作業負荷統計が使用されま
す。
14-10
Oracle Database パフォーマンス・チューニング・ガイド
統計の管理
非作業負荷統計の収集
非作業負荷統計を収集するには、引数なしで dbms_stats.gather_system_stats() を実
行します。非作業負荷統計の収集プロセスの間、I/O システムにオーバーヘッドが発生します。
この収集プロセスは、I/O のパフォーマンスおよびデータベースのサイズによって数秒から数
分かかることがあります。
この情報は分析され、整合性が検証されます。場合により、非作業負荷統計の値はデフォルト
値のままになることがあります。このような場合は、統計収集プロセスを繰り返すか、
dbms_stats.set_system_stats プロシージャを使用して I/O システムの仕様に応じた値を
手動で設定します。
統計の管理
この項では、次の内容を説明します。
■
前のバージョンの統計のリストア
■
統計のエクスポートとインポート
■
統計のリストアとインポートまたはエクスポートの相違点
■
表統計またはスキーマ統計のロック
■
統計の設定
■
統計の欠落の処理
前のバージョンの統計のリストア
ディクショナリ内で統計が変更されるたびに、後でリストアできるように前のバージョンの統
計が自動的に保存されます。統計をリストアするには、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: このファンクションを使用すると、現行の統計履歴
の保存値を取得できます。
GET_STATS_HISTORY_AVAILABILTY: このファンクションを使用すると、統計履歴が使
用可能な最も古いタイムスタンプを取得できます。最も古いタイムスタンプより前のタイ
ムスタンプには、統計をリストアできません。
オプティマイザ統計の管理
14-11
統計の管理
前のバージョンの統計をリストアする場合は、次の制限が適用されます。
■
■
RESTORE プロシージャでは、ユーザー定義統計はリストアできません。
統計の収集に ANALYZE コマンドが使用された場合、古いバージョンの統計は格納されませ
ん。
注意 : DBMS_STATS を使用中に表からすべての行を削除する必要がある場
合、同じ表を削除して再度作成するかわりに、TRUNCATE を使用します。表
が削除されると、自動ヒストグラム収集機能が使用するワークロード情報と、
RESTORE_*_STATS プロシージャが使用する保存された統計履歴が消失しま
す。このデータなしでは、これらの機能は適切に動作しません。
統計のエクスポートとインポート
統計をデータ・ディクショナリからエクスポートして、ユーザー所有の表にインポートできま
す。これにより、同じスキーマについて複数バージョンの統計を作成できます。また、データ
ベース間で統計のコピーもできます。この操作により、統計を本番データベースから小規模な
テスト・データベースにコピーできます。
注意 : 統計のエクスポートとインポートは、データベースの 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 ユーティリティは、データベースから表とともに
オプティマイザ統計をエクスポートおよびインポートします。ただし、表
にシステム生成名を持つ列が含まれている場合、統計はデータとともにエ
クスポートされません。
14-12
Oracle Database パフォーマンス・チューニング・ガイド
統計の管理
統計のリストアとインポートまたはエクスポートの相違点
統計リストア機能は、ある面では統計のインポートおよびエクスポート機能に類似しています。
通常、次の場合にはリストア機能を使用する必要があります。
■
■
統計の古いバージョンをリカバリする場合。たとえば、オプティマイザの動作を前の日付
までリストアする場合などです。
データベースで統計履歴の保存および消去を管理する場合。
次の場合には、EXPORT/IMPORT_*_STATS プロシージャを使用する必要があります。
■
■
■
複数の統計セットを試験的に使用して値を増減させる場合。
データベース間で統計を移動する場合。たとえば、本番システムからテスト・システムに
統計を移動する場合などです。
既知の統計セットを統計のリストアに必要な保存日数よりも長期的に保持する場合。
表統計またはスキーマ統計のロック
表またはスキーマの統計をロックできます。統計がロックされると、その統計はロックが解除
されるまで変更できなくなります。これらのロック・プロシージャは、統計が変化しないこと
を保証する必要のある静的環境に役立ちます。
DBMS_STATS パッケージには、統計をロックするための 2 つのプロシージャと、統計のロック
を解除するための 2 つのプロシージャが用意されています。
■
LOCK_SCHEMA_STATS
■
LOCK_TABLE_STATS
■
UNLOCK_SCHEMA_STATS
■
UNLOCK_TABLE_STATS
統計の設定
SET_*_STATISTICS プロシージャを使用して、表、列、索引およびシステムの統計を設定で
きます。統計が不正確であったり一貫性がないとパフォーマンスが低下するため、この方法で
の統計の設定はお薦めしません。
動的サンプリングを使用した統計の見積り
動的サンプリングの目的は、述語の選択性および表と索引に関する統計のより正確な見積りを
判断して、サーバーのパフォーマンスを改善することです。表と索引に関する統計には、表ブ
ロック・カウント、適用可能な索引ブロック・カウント、表のカーディナリティおよび関連す
る結合列の統計が含まれます。正確に見積ると、より適切な実行計画がオプティマイザで作成
できます。
動的サンプリングを使用すると、次の作業が可能になります。
■
収集された統計が使用できない、あるいは見積りで重大なエラーを引き起こす可能性があ
る場合に、単一表の述語の選択性を見積ります。
■
表、および統計のない関連索引に対する統計を見積ります。
■
表、および統計が古すぎるために信頼できない関連索引に対する統計を見積ります。
この動的サンプリング機能は、OPTIMIZER_DYNAMIC_SAMPLING パラメータにより制御され
ます。動的サンプリングにより必要な統計を自動的に収集するには、このパラメータを 2 以上
の値に設定する必要があります。デフォルト値は 2 です。設定できるサンプリング・レベルの
詳細は、14-14 ページの「動的サンプリング・レベル」を参照してください。
オプティマイザ統計の管理
14-13
統計の管理
動的サンプリングの動作
重要なパフォーマンス属性は、コンパイル時に決定されます。Oracle では、問合せで動的サン
プリングを使用する利点があるかどうか、コンパイル時に判別されます。利点がある場合、再
帰的 SQL 文が発行されて表のブロックの小さなランダム・サンプルがスキャンされ、関連する
単一表の述語を適用することで述語の選択性の見積りが行われます。サンプルしたカーディナ
リティが、表のカーディナリティの見積りに使用される場合もあります。関連する列統計情報
と索引統計情報も収集されます。
OPTIMIZER_DYNAMIC_SAMPLING 初期化パラメータの値によって、動的サンプリングの問合
せで読み取られるブロック数が決定します。
関連項目 : この初期化パラメータの詳細は、『Oracle Database リファレ
ンス』を参照してください。
動的サンプリング使用のタイミング
通常、迅速に（数秒以内で）完了する問合せに対しては、動的サンプリングのコストが発生す
るのは望ましくありません。しかし、次のいずれかの条件が当てはまる場合は、動的サンプリ
ングが有効です。
■
動的サンプリングを使用すると、より優れた計画になる場合。
■
サンプリングにかかる時間が、問合せの実行時間全体のごく一部である場合。
■
問合せが何度も実行される場合。
動的サンプリングは、単一表の述語によるサブセットに適用したり、動的サンプリングが行わ
れていない述語の通常の選択性の見積りと組み合せることができます。
動的サンプリングを使用したパフォーマンスの改善方法
動的サンプリングは、OPTIMIZER_DYNAMIC_SAMPLING パラメータを使用して制御します。
このパラメータの値は、0 ～ 10 に設定できます。デフォルトは 2 です。
■
■
値が 0 の場合、動的サンプリングが行われません。
パラメータの値が大きくなるにつれて、サンプリングされる表（分析された表、あるいは
分析されていない表）のタイプについても、サンプリングで使用される I/O の量に関して
も、動的サンプリングがより積極的に適用されるようになります。
動的サンプリングは、サンプリング対象の表内で行が挿入、削除または更新されていない場合、
同じものが繰り返し使用されます。OPTIMIZER_FEATURES_ENABLE パラメータが 9.2.0 より
前のリリースに設定されている場合、動的サンプリングはオフになります。
動的サンプリング・レベル
サンプリング・レベルは、使用された動的サンプリング・レベルがカーソル・ヒントまたは
OPTIMIZER_DYNAMIC_SAMPLING 初期化パラメータからの場合、次のようになります。
■
■
■
■
14-14
レベル 0: 動的サンプリングは使用しないでください。
レベル 1: 次の条件を満たす場合、すべての分析されていない表をサンプリングします。
（1）分析されていない表が問合せに少なくとも 1 つある場合。
（2）この分析されていない
表が、別の表と結合、または副問合せかマージ不可能ビューにある場合。
（3）この分析さ
れていない表に索引がない場合。
（4）この分析されていない表に、この表の動的サンプリ
ングに使用されるブロックの数よりも多いブロックがある場合。サンプリングされたブ
ロック数は、動的サンプリングのブロックのデフォルト数です（32）
。
レベル 2: 動的サンプリングをすべての分析されていない表に適用します。サンプリングさ
れたブロック数は、動的サンプリングのブロックのデフォルト数の 2 倍です。
レベル 3: レベル 2 の基準を満たすすべての表と、標準の選択性の見積りで動的サンプリン
グの可能性がある述語の推論が使用されるすべての表に、動的サンプリングを適用します。
サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数です。分
析されていない表の場合、サンプリングされたブロック数は、動的サンプリングのブロッ
クのデフォルト数の 2 倍です。
Oracle Database パフォーマンス・チューニング・ガイド
統計の管理
■
■
■
レベル 4: 動的サンプリングをレベル 3 の基準を満たすすべての表、および 2 つ以上の列を
参照する単一表の述語を持つすべての表に適用します。サンプリングされたブロック数は、
動的サンプリングのブロックのデフォルト数です。分析されていない表の場合、サンプリ
ングされたブロック数は、動的サンプリングのブロックのデフォルト数の 2 倍です。
レベル 5、6、7、8 および 9: それぞれ動的サンプリング・ブロックのデフォルトの数の 2、
4、8、32 または 128 倍を使用して、動的サンプリングを直前レベルの基準を満たすすべて
の表に適用します。
レベル 10: 表内のすべてのブロックを使用して、動的サンプリングをレベル 9 の基準を満た
すすべての表に適用します。
表の動的サンプリング・レベルが DYNAMIC_SAMPLING オプティマイザ・ヒントを使用して
設定されている場合のサンプリング・レベルは、次のとおりです。
■
■
■
■
レベル 0: 動的サンプリングは使用しないでください。
レベル 1: サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数
です (32)。
レベル 2、3、4、5、6、7、8 および 9: サンプリングされたブロック数は、それぞれ動的サ
ンプリング・ブロックのデフォルト数の 2、4、8、16、32、64、128 または 256 倍です。
レベル 10: 表内のすべてのブロックを読み込みます。
関連項目 : DYNAMIC_SAMPLING ヒントを使用してサンプリング・レベ
ルを設定する方法については、
『Oracle Database SQL 言語リファレンス』
を参照してください。
統計の欠落の処理
Oracle では、統計が欠落している表が検出されると、オプティマイザに必要な統計が動的に収
集されます。ただし、ある種の表の場合、動的サンプリングは実行されません。これには、リ
モート表と外部表が含まれます。これらの場合および動的サンプリングが無効になっている場
合、オプティマイザは統計にデフォルト値を使用します。表 14-3 および表 14-4 を参照してくだ
さい。
表 14-3 統計が欠落しているときの表のデフォルト値
表統計
オプティマイザによって使用されるデフォルト値
カーディナリティ
ブロック数×（ブロック・サイズ - キャッシュ層）÷行の平
均の長さ
行の平均長さ
100 バイト
ブロック数
100、またはエクステント・マップに基づく実際の値
リモート・カーディナリティ
2000 行
リモートの行の平均長さ
100 バイト
表 14-4 統計が欠落しているときの索引のデフォルト値
索引統計
オプティマイザによって使用されるデフォルト値
レベル
1
リーフ・ブロック
25
リーフ・ブロック / キー
1
データ・ブロック / キー
1
個別キー
100
クラスタ化係数
800
オプティマイザ統計の管理
14-15
統計の参照
統計の参照
この項では、次の内容を説明します。
■
表、索引および列の統計
■
ヒストグラムの表示
表、索引および列の統計
表、索引および列の統計は、データ・ディクショナリに格納されます。データ・ディクショナ
リ内の統計を表示するには、適切なデータ・ディクショナリ・ビューを問い合せます（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
■
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 の
データ配分が均一な場合のヒストグラムは、図 14-1 のようになります。数字は終点の値です。
14-16
Oracle Database パフォーマンス・チューニング・ガイド
統計の参照
図 14-1 データ配分が均一の高さ調整済ヒストグラム
各バケット内の行数は、表内の全行数の 10 分の 1 です。均一に分布しているこの例では、4/10
の行の値が、60 ～ 100 の間にあります。
データ配分が均一でない場合のヒストグラムの例を図 14-2 に示します。
図 14-2 データ配分が非均一の高さ調整済ヒストグラム
この場合、ほとんどの行で、この列の値が 5 になっています。60 ～ 100 の間の値を持っている
行は、行全体の 1/10 のみです。
高さ調整済ヒストグラムは、例 14-1 に示すように *TAB_HISTOGRAMS 表を使用して表示でき
ます。
例 14-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 つのバケットに対応します。
オプティマイザ統計の管理
14-17
統計の参照
頻度ヒストグラム
頻度ヒストグラムでは、列の値がそれぞれヒストグラムの 1 つのバケットに対応します。各バ
ケットには、その単一値の発生数が含まれます。個別値の個数が、指定されたヒストグラム・
バケットの個数以下であれば、高さ調整済ヒストグラムのかわりに頻度ヒストグラムが自動的
に作成されます。頻度ヒストグラムは、例 14-2 に示すように *TAB_HISTOGRAMS 表を使用し
て表示できます。
例 14-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
14-18
Oracle Database パフォーマンス・チューニング・ガイド
15
索引およびクラスタの使用方法
この章では、索引およびクラスタを使用してパフォーマンスを強化できる、または低下させる
データ・アクセス方法の概要を説明します。
この章には次の項があります。
■
索引パフォーマンスについて
■
パフォーマンスを考慮したファンクション索引の使用方法
■
パフォーマンスを考慮したパーティション索引の使用方法
■
パフォーマンスを考慮した索引構成表の使用方法
■
パフォーマンスを考慮したビットマップ索引の使用方法
■
パフォーマンスを考慮したビットマップ結合索引の使用方法
■
パフォーマンスを考慮したドメイン索引の使用方法
■
パフォーマンスを考慮したクラスタの使用方法
■
パフォーマンスを考慮したハッシュ・クラスタの使用方法
索引およびクラスタの使用方法
15-1
索引パフォーマンスについて
索引パフォーマンスについて
この項では、次の項目について説明します。
■
論理構造のチューニング
■
SQL アクセス・アドバイザを使用した索引のチューニング
■
索引を付ける列と式の選択
■
コンポジット索引の選択
■
索引を使用する文の記述
■
索引を使用しない文の記述
■
索引の再作成
■
一意でない索引による一意性の規定
■
ENABLE NOVALIDATE 制約の使用方法
論理構造のチューニング
問合せの最適化は、問合せ実行におけるあまり有効ではない索引の使用を避けるために役立ち
ますが、SQL エンジンは、表に対して定義されている索引が使用されているかどうかにかかわ
らず、継続的にすべての索引をメンテナンスします。書込み集中型アプリケーションでは、索
引のメンテナンスに CPU と I/O リソースが大量に必要となる場合があります。したがって、
必要がなければ索引を作成しないでください。
最適なパフォーマンスを保つために、アプリケーションで使用していない索引を削除してくだ
さい。使用されていない索引は、ALTER INDEX MONITORING USAGE 機能を典型的な負荷を一
定期間かけた後に使用することで検出できます。この監視機能は、索引が使用されたかどうか
を記録します。使用されていない索引が検出された場合は、削除してください。サンプリング
した負荷以外の負荷で使用されている索引を削除しないように、典型的な負荷を監視している
ことを確認してください。
また、アプリケーション内では、文の実行計画の調査ですぐには明らかにならない索引の使用
方法もあります。その例が、共有ロックが子表上に取り出されないようにする親表上の外部
キー索引です。
関連項目 :
■
■
ALTER INDEX MONITORING USAGE 文の詳細は、『Oracle Database
SQL 言語リファレンス』を参照してください。
外部キーの詳細は、
『Oracle Database アドバンスト・アプリケーショ
ン開発者ガイド』を参照してください。
また、新しい索引を作成して SQL 文をチューニングするかどうかを決める場合、オプティマイ
ザがアプリケーションの実行時にこれらの索引を使用するかどうかを判断するために、
EXPLAIN PLAN 文を使用することもできます。新しい索引を作成して現在解析中の文をチュー
ニングする場合は、Oracle はその文を無効にします。
その文が次に解析されるとき、オプティマイザは、新しい索引を使用する可能性のある新しい
実行計画を自動的に選択します。新しい索引をリモート・データベース上に作成して分散型の
文をチューニングする場合は、その文が次に解析されるとき、オプティマイザがこれらの索引
について検討します。
索引を作成してある文をチューニングした場合、他の文の実行計画に対するオプティマイザの
選択に影響を及ぼす場合があるので注意してください。たとえば、ある文によって使用される
索引を作成した場合、オプティマイザは、アプリケーションの他の文に対しても、その索引の
使用を選択する場合があります。このため、最初にチューニング対象と判断した文をチューニ
ングした後、アプリケーションのパフォーマンスおよび実行計画を再検査し、SQL トレース機
能を利用します。
15-2
Oracle Database パフォーマンス・チューニング・ガイド
索引パフォーマンスについて
SQL アクセス・アドバイザを使用した索引のチューニング
SQL アクセス・アドバイザは、どの索引が必要であるかを手動で判別する作業に対する代替機
能です。このアドバイザを Oracle Enterprise Manager から起動するか、DBMS_ADVISOR パッ
ケージ API を介して実行すると、索引セットを推奨します。SQL アクセス・アドバイザはワー
クロードの使用を推奨するか、または指定のスキーマに関する仮定的なワークロードを生成し
ます。SQL キャッシュの現在の内容、ユーザー定義の SQL 文セットまたは SQL チューニン
グ・セットなど、様々なワークロード・ソースが使用可能です。SQL アクセス・アドバイザに
より指定のワークロードに関して推奨事項のセットを生成され、その中から実装する索引を選
択できます。実装スクリプトが用意されており、手動で実行するか、または Oracle Enterprise
Manager を介して自動的に実行できます。SQL アクセス・アドバイザの詳細は、17-2 ページの
「DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要」を参照してください。
索引を付ける列と式の選択
キーは、索引を付ける列または式です。次のガイドラインに従って、索引を付けるキーを選択
します。
■
■
■
WHERE 句で頻繁に使用されるキーに索引を付けることを検討します。
SQL 文で表を結合するために頻繁に使用されるキーに索引を付けることを検討します。結
合の最適化の詳細は、15-11 ページの「パフォーマンスを考慮したハッシュ・クラスタの使
用方法」を参照してください。
高度な選択性の索引キーを選択します。索引の選択性は、索引を付けるキーについて同じ
値を持つ行の表内での割合です。同じ値を持つ行がほとんどない場合、索引の選択性は最
適です。
注意 : 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 アド
バンスト・アプリケーション開発者ガイド』を参照してください。
索引およびクラスタの使用方法
15-3
索引パフォーマンスについて
コンポジット索引の選択
コンポジット索引には複数のキー列が含まれています。コンポジット索引には、次のような単
一列索引を上回る利点があります。
■
選択性の向上
場合によっては、それぞれの選択性が劣る複数の列や式を組み合せてコンポジット索引に
すると、より高い選択性を得ることができます。
■
I/O の削減
問合せによって選択される列がすべてコンポジット索引に含まれている場合、Oracle は、
表にアクセスすることなく、索引からこれらの値を戻すことができます。
SQL 文にコンポジット索引の先頭部分を利用する条件が含まれていれば、その文はコンポジッ
ト索引に関係するアクセス・パスを使用します。
注意 : このことは、索引スキップ・スキャンには現在、該当しなくなっ
ています。13-19 ページの「索引スキップ・スキャン」を参照してくださ
い。
索引の先頭部分とは、その索引を作成した CREATE INDEX 文で列リストの先頭から連続的に指
定された 1 つ以上の列の組合せのことです。次の CREATE INDEX 文を例とします。
CREATE INDEX comp_ind
ON table1(x, y, z);
■
x、xy、xyz の各列の組合せは、索引の先頭部分です。
■
yz、y、z の各列の組合せは、索引の先頭部分ではありません。
コンポジット索引のキーの選択
コンポジット索引を構成するキーを選択するために、次のガイドラインに従ってください。
■
■
WHERE 句の条件で、頻繁に AND 演算子で結合して使用されるキー・セットに対して、コン
ポジット索引を作成することを検討します。特に結合したときの選択性が個々のキーの選
択性よりも優れている場合、コンポジット索引を作成してください。
複数の問合せが 1 つ以上のキー値に基づいて同じキー・セットを選択する場合、これらの
キーのすべてを含むコンポジット索引を作成することを検討します。
もちろん、索引を作成するときの、一般的なパフォーマンスの利点およびトレードオフに関す
る前述のガイドラインを検討してください。
コンポジット索引のキーの順序付け
コンポジット索引内でのキーの順序を指定するために次のガイドラインに従ってください。
■
■
■
15-4
WHERE 句で使用されるキーが先頭部分を構成するように、索引を作成してください。
一部のキーが WHERE 句で使用される頻度が高い場合には、頻繁に選択されるキーが先頭部
分を構成するように索引を作成し、これらのキーのみを使用する文が索引を使用できるよ
うにしてください。
すべてのキーが WHERE 句で使用される頻度が同程度で、そのキーの 1 つでデータが物理的
に順序付けられている場合には、そのキーをコンポジット索引の先頭にしてください。
Oracle Database パフォーマンス・チューニング・ガイド
索引パフォーマンスについて
索引を使用する文の記述
索引を作成しても、単に索引が存在するのみでは、オプティマイザはその索引を使用するアク
セス・パスを選択できません。オプティマイザは、SQL 文にアクセス・パスを使用可能にする
構造が含まれている場合にかぎり、そのようなアクセス・パスを選択できます。索引アクセ
ス・パスを使用するというオプションを問合せオプティマイザで可能にするには、文が索引ア
クセス・パスを使用可能にする構文になっていることを確認してください。
索引を使用しない文の記述
場合によっては、既存の索引を使用するアクセス・パスを SQL 文で使用しないことも可能で
す。索引の選択性があまり優れておらず、全表スキャンの方が効率的であることがわかってい
る場合がそうです。そのような索引アクセス・パスを使用可能にする条件が文に含まれている
場合は、次に示す方法の 1 つを使用して、オプティマイザに全表スキャンを使用するように強
制できます。
■
■
■
NO_INDEX ヒントを使用して特定索引の使用を禁止にし、問合せオプティマイザに最大限
の柔軟性を持たせることができます。
FULL ヒントを使用し、オプティマイザに対して索引スキャンのかわりに全表スキャンを選
択するように指示します。
INDEX ヒントまたは INDEX_COMBINE ヒントを使用し、オプティマイザに、ある索引（ま
たはリストされている索引セット）を別の索引（または索引セット）のかわりに使用する
ように指示します。
関連項目 : NO_INDEX、FULL、INDEX、INDEX_COMBINE および
AND_EQUAL の各ヒントに関する詳細は、第 16 章「オプティマイザ・ヒン
トの使用方法」を参照してください。
パラレル実行は、索引を効果的に利用します。このオプションはパラレル索引レンジ・スキャ
ンは実行しませんが、ネステッド・ループ結合を実行するためにパラレル索引参照を実行しま
す。索引の選択性が高い（各索引エントリの行数が少ない）場合は、パラレル表スキャンより
も順次索引参照を使用することをお薦めします。
索引の再作成
索引を縮小し分断化された領域を最小化するため、または索引の記憶特性を変更するために索
引を再作成する場合があります。既存の索引のサブセットとなる新しい索引を作成するとき、
または既存の索引を新しい記憶特性で再構築するとき、Oracle は、実表ではなく既存の索引を
使用して索引作成のパフォーマンスを向上させる場合があります。
注意 : 索引の作成または再作成の後で DBMS_STATS をコールしないよう
に、CREATE または REBUILD に、COMPUTE STATISTICS 文を含めてくだ
さい。
ただし、既存の索引よりも実表を使用した方が効果的な場合もあります。多くの DML が実行
された表の索引を考えてみてください。DML のために索引のサイズが大きくなり、各ブロック
が 50% 以下しか満たされなくなる場合があります。索引が表のほとんどの列を参照している場
合、索引が表よりも大きくなりかねません。その場合は、索引よりも実表を使用した方が、索
引の再作成が速くできます。
ALTER INDEX ...REBUILD 文は、既存の索引を再編成または縮小するため、または既存の索引
の記憶特性を変更するために使用します。REBUILD 文は、新しい索引の基礎として既存の索引
を使用します。STORAGE（エクステントの割当て用）、TABLESPACE（索引を新しい表領域に
移動する）および INITRANS（エントリの最初の数を変更する）などのすべての索引記憶用の
文がサポートされています。
ALTER INDEX ...REBUILD は、高速全スキャン機能を使用するので、通常は索引を削除して再
作成するよりも高速です。この文は、マルチブロック I/O を使用して索引ブロックをすべて読
索引およびクラスタの使用方法
15-5
索引パフォーマンスについて
み込んでから、ブランチ・ブロックを廃棄します。さらに、このアプローチには、再作成の実
行中の問合せには、旧索引を利用できるという利点があります。
関連項目 : CREATE INDEX 文と ALTER INDEX 文の詳細および索引の再
作成の制限の詳細は、
『Oracle Database SQL 言語リファレンス』を参照し
てください。
索引の縮小
COALESCE オプションを持つ ALTER INDEX 文を使用して索引のリーフ・ブロックを結合でき
ます。このオプションでは、索引のリーフ・レベルを結合して空きブロックにし、再利用でき
ます。また、索引をオンラインで再作成することもできます。
関連項目 : この文の構文の詳細は、『Oracle Database SQL 言語リファレ
ンス』および『Oracle Database 管理者ガイド』を参照してください。
一意でない索引による一意性の規定
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）にはすべて名前を付け、使用禁止で作成します。
注意 :
2.
15-6
デフォルトでは、制約は ENABLED 状態で作成されます。
旧データを表にロードします。
Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスを考慮したファンクション索引の使用方法
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 概要』を参照してく
パフォーマンスを考慮したファンクション索引の使用方法
ファンクション索引には、関数（たとえば、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 言語リファレン
ス』を参照してください。
索引およびクラスタの使用方法
15-7
パフォーマンスを考慮したパーティション索引の使用方法
パフォーマンスを考慮したパーティション索引の使用方法
パーティション表と同様に、パーティション索引を使用すると、管理可能性、可用性、パ
フォーマンスおよび拡張性が向上します。パーティション索引は、個別にパーティション化す
るか（グローバル索引）
、または表のパーティション・メソッドに自動的にリンクできます
（ローカル索引）。
Oracle では、レンジ・パーティション化およびハッシュ・パーティション化されたグローバル
索引をどちらもサポートしています。レンジ・パーティション化されたグローバル索引では、
各索引パーティションに、パーティション・バウンドで定義された値が含まれます。ハッ
シュ・パーティション化されたグローバル索引では、各パーティションに、Oracle のハッシュ
関数により決定された値が含まれます。
マルチユーザーの OLTP 環境で、索引内の少数のリーフ・ブロックに競合が多い場合、ハッ
シュ・メソッドにより索引のパフォーマンスが向上します。OLTP アプリケーションによって
は、索引の右端にのみ索引が挿入される場合があります。これは、単調に増える列について索
引が定義されている場合に行われます。このような場合、索引ページ、バッファ、更新のラッ
チ、および追加索引メンテナンス・アクティビティの競合により、索引の右端がホット・ス
ポットとなり、パフォーマンスが低下します。
ハッシュ・パーティション化されたグローバル索引では、索引エントリはパーティション・
キーおよびパーティション数に基づいて異なるパーティションにハッシュされます。これによ
り、定義済のパーティション数全体に競合が拡散され、スループットが向上します。ハッ
シュ・パーティション化されたグローバル索引を使用すると、バッファ・ラッチの競合が複数
のパーティションにわたって拡散されるため、大規模 PDML として大きなファクト表に実行さ
れる TPC-H リフレッシュ関数には有効です。
ハッシュ・パーティション化では、索引エントリは Oracle で生成されたハッシュ値に基づいて
特定の索引パーティションにマップされます。ハッシュ・パーティション化されたグローバル
索引を作成するための構文は、ハッシュ・パーティション表と非常によく似ています。索引
パーティション・キーについての等価述語および IN 述語を伴う問合せでは、グローバル・
ハッシュ・パーティション索引を効率的に使用して問合せにすばやく回答できます。
関連項目 : グローバル索引表の詳細は、『Oracle Database 概要』および
『Oracle Database 管理者ガイド』を参照してください。
パフォーマンスを考慮した索引構成表の使用方法
索引構成表は、表のデータが、対応付けられた索引に保持されるという点で普通の表とは異な
ります。新しい行の追加、行の更新、行の削除など、表データを変更すると、索引のみが更新
されます。データ行は索引に格納されるため、索引構成表では完全一致、範囲検索またはその
両方を含む問合せの表データに対するさらに高速なキー・ベースのアクセスが可能になります。
グローバル・ハッシュ・パーティション索引は索引構成表でサポートされており、マルチユー
ザーの OLTP 環境でパフォーマンスが向上します。
関連項目 : 索引構成表の詳細は、『Oracle Database 概要』および
『Oracle Database 管理者ガイド』を参照してください。
15-8
Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスを考慮したドメイン索引の使用方法
パフォーマンスを考慮したビットマップ索引の使用方法
ビットマップ索引は、次のすべての特性を持つ問合せのパフォーマンスを大幅に向上できます。
■
カーディナリティが低いか中位である列に関する述語が WHERE 句に複数含まれています。
■
カーディナリティが低いか中位である列に関する個々の述語が大量の行を選択しています。
■
■
カーディナリティが低いか中位である列の一部または全部に対して、問合せで使用される
ビットマップ索引が作成されています。
問合せの表に多数の行が含まれています。
複数のビットマップ索引を使用して、単独の表に対する条件を評価できます。このため、ビッ
トマップ索引は、長い WHERE 句を含む複合非定型問合せにとって非常に有効です。ビットマッ
プ索引は、集合問合せでもスター・スキーマでの結合の最適化でも最適なパフォーマンスを提
供します。
関連項目 : ビットマップ索引の詳細は、『Oracle Database 概要』および
『Oracle Database データ・ウェアハウス・ガイド』を参照してください。
パフォーマンスを考慮したビットマップ結合索引の使用方法
単一表のビットマップ索引に加えて、ビットマップ結合索引を作成できます。このビットマッ
プ結合索引は、複数の表を結合するためのビットマップ索引です。ビットマップ結合索引は、
事前の制限事項の実行により結合される必要のあるデータ量を削減するためにスペースを節約
するよい方法です。ビットマップ結合索引は、表の列の値ごとに、別の表の対応する行の
ROWID を格納します。データ・ウェアハウス環境では、結合条件は、ディメンション表の主
キー列、およびファクト表の外部キー列との間の等価内部結合です。
ビットマップ結合索引は、マテリアライズド結合ビューより格納の効率がはるかによく、事前
に結合をマテリアライズする方法の代替手段です。これは、マテリアライズド結合ビューが
ファクト表の ROWID を圧縮しないためです。
関連項目 : ビットマップ結合索引の例および制限については、『Oracle
Database データ・ウェアハウス・ガイド』を参照してください。
パフォーマンスを考慮したドメイン索引の使用方法
ドメイン索引は、ユーザー定義の索引タイプで指定された索引作成論理で作成されます。索引
タイプを使用すると、特定の演算子の述部に合うデータに効率よくアクセスできます。通常、
ユーザー定義の索引タイプは、Spatial オプションと同様 Oracle のオプションの一部です。た
とえば、SpatialIndextype を使用すると、ある条件ボックスにオーバーラップする Spatial
データを効率よく取り出せます。
ドメイン索引の作成と保守で指定できるパラメータは、カートリッジによって異なります。同
様に、ドメイン索引のパフォーマンスと記憶域の特性は、カートリッジ固有のマニュアルを参
照してください。
次の情報は、適切なカートリッジ・マニュアルを参照してください。
■
索引付けできるデータ型
■
使用できる索引タイプ
■
索引タイプで使用できる演算子
■
ドメイン索引を作成およびメンテナンスする方法
■
問合せで演算子を効率よく使用する方法
■
パフォーマンス特性の内容
注意 :
索引の型は CREATE INDEXTYPE 文でも作成できます。
索引およびクラスタの使用方法
15-9
パフォーマンスを考慮したクラスタの使用方法
関連項目 : SpatialIndextype の詳細は、『Oracle Spatial 開発者
ガイド』を参照してください。
パフォーマンスを考慮したクラスタの使用方法
クラスタとは、物理的にまとめて格納される 1 つ以上の表のグループです。それらの表は、共
通の列を共有しており、通常、一緒に使用されるため、まとめて格納されます。関連する行が
物理的にまとめて格納されているため、ディスク・アクセス時間が短縮されます。
クラスタを作成するには、CREATE CLUSTER コマンドを使用します。
関連項目 :
さい。
クラスタの詳細は、『Oracle Database 概要』を参照してくだ
表をクラスタ化するかどうかを判断するために、次のガイドラインに従ってください。
■
■
■
■
■
■
■
アプリケーションが結合処理で頻繁にアクセスする表をクラスタ化します。
アプリケーションが表の結合を頻繁には行わない場合、または共通の列の値を頻繁に修正
する場合、それらの表はクラスタ化しません。表をクラスタ化した場合、Oracle は修正さ
れた行を別のブロックへ移行して、クラスタをメンテナンスする必要もあります。このた
め、非クラスタ化表の値を修正する場合よりも、行のクラスタ・キー値を修正する場合の
処理時間は長くなる可能性があります。
アプリケーションが複数の表の 1 つについてのみ頻繁に全表スキャンを行う場合、それら
の表はクラスタ化しません。クラスタ化表の全表スキャンに要する処理時間は、非クラス
タ化表の全表スキャンよりも長くなる可能性があります。複数の表があわせて格納されて
いるため、Oracle が読み込む必要のあるブロックは多くなります。
マスター・レコードを選択してからディテール・レコードを選択することがよくある場合、
マスター / ディテール表をクラスタ化します。ディテール・レコードはマスター・レコー
ドと同じデータ・ブロックに格納されるため、選択時にそれらがメモリー内に存在してい
る可能性が高くなり、Oracle による I/O 処理が少なくなる場合があります。
同じマスターについて多くのディテール・レコードを選択することがよくある場合、ディ
テール表のみをクラスタに格納します。このようにすれば、同じマスターについて多くの
詳細レコードを選択する問合せのパフォーマンスが改善され、マスター表に対する全表ス
キャンのパフォーマンスも低下させずに済みます。別の方法として、索引構成表を使用す
る方法があります。
同じクラスタ・キー値を持つすべての表からのデータが、1 つまたは 2 つの Oracle ブロック
を超える場合、それらの表はクラスタ化しません。クラスタ化表の行をアクセスする場合、
Oracle はその値を持つ行を含んでいるブロックをすべて読み込みます。これらの行が複数
のブロックを使用している場合、単一行をアクセスすることによって、非クラスタ化表で
同じ行をアクセスする場合よりも多くの読込み処理が必要になる場合があります。
各クラスタ・キー値の行数が大きく異なっている場合は表をクラスタ化しないでください。
クラスタ化した場合、カーディナリティの低いキー値の場合には領域が無駄になり、カー
ディナリティの高いキー値の場合には衝突が発生します。衝突が発生するとパフォーマン
スが下がります。
アプリケーションのニーズに応じて、クラスタの長所と短所を検討してください。たとえば、
結合文のパフォーマンス向上が、クラスタ・キー値を修正する文のパフォーマンス低下を上回
る場合もあります。表をクラスタ化した場合と別々に格納した場合について実験して、処理時
間を比較してください。
関連項目 : クラスタの詳細は、『Oracle Database 管理者ガイド』を参照
してください。
15-10
Oracle Database パフォーマンス・チューニング・ガイド
パフォーマンスを考慮したハッシュ・クラスタの使用方法
パフォーマンスを考慮したハッシュ・クラスタの使用方法
ハッシュ・クラスタは、ハッシュ関数をそれぞれの行のクラスタ・キー値に適用することに
よって、表データをグループ分けします。同じクラスタ・キー値を持つすべての行が、ディス
ク上にまとめて格納されます。アプリケーションのニーズに応じて、ハッシュ・クラスタの長
所と短所を検討してください。特定の表をハッシュ・クラスタに格納する場合と、索引付きで
単独に格納する場合を実験して、処理時間を比較してください。
ハッシュ・クラスタを使用する場合を判断するために、次のガイドラインに従ってください。
■
■
■
■
■
同じ列または列の組合せを使用する等価条件が WHERE 句に含まれる場合、WHERE 句を持つ
SQL 文により頻繁にアクセスされる表を格納するために、ハッシュ・クラスタが使用され
ます。この列または列の組合せをクラスタ・キーとして指定します。
将来挿入する行およびすぐに挿入する行を含めて、特定のクラスタ・キー値を持つすべて
の行を保持するために必要な領域を判断できる場合、ハッシュ・クラスタに表を格納しま
す。
ハッシュ関数の各値に対応する行が特定の列において昇順でソートされる場合、ソートさ
れたクラスタ・データを操作することで応答時間を改善できるのであれば、ソートされた
ハッシュ・クラスタを使用します。
アプリケーションが全表スキャンを実行する場合が多く、表が拡大することを見越して
ハッシュ・クラスタに大きな領域を割り当てる必要がある場合は、その表をハッシュ・ク
ラスタに格納しません。そのような全表スキャンでは、いくつかのブロックにはほとんど
行が含まれていなくても、ハッシュ・クラスタに割り当てられているブロックをすべて読
み込む必要があります。表を単独で格納することによって、全表スキャンにより読み込ま
れるブロック数が減少します。
アプリケーションがクラスタ・キー値を頻繁に修正する場合、ハッシュ・クラスタに表は
格納しません。表をクラスタ化した場合、Oracle は修正された行を別のブロックへ移行し
て、クラスタをメンテナンスする必要もあります。このため、非クラスタ化表の値を修正
する場合よりも、行のクラスタ・キー値を修正する場合の処理時間は長くなる可能性があ
ります。
前述の考慮事項に基づいてハッシングが適切であるかぎり、他の表と頻繁に結合されるかどう
かにかかわらず、単一の表をハッシュ・クラスタに格納することは有益です。
関連項目 :
■
■
ハッシュ・クラスタの管理の詳細は、
『Oracle Database 管理者ガイド』
を参照してください。
CREATE CLUSTER 文の詳細は、
『Oracle Database SQL 言語リファレン
ス』を参照してください。
索引およびクラスタの使用方法
15-11
パフォーマンスを考慮したハッシュ・クラスタの使用方法
15-12
Oracle Database パフォーマンス・チューニング・ガイド
16
オプティマイザ・ヒントの使用方法
オプティマイザ・ヒントを SQL 文で使用して実行計画を変更できます。ヒントを使用して、特
定のアプローチの使用をオプティマイザに指示する方法を説明します。
この章には次の項があります。
■
オプティマイザ・ヒントの理解
■
ヒントの指定方法
■
ビューでのヒントの使用方法
オプティマイザ・ヒントの使用方法
16-1
オプティマイザ・ヒントの理解
オプティマイザ・ヒントの理解
ヒントを使用することにより、通常オプティマイザによって行われる意思決定を行うことがで
きます。アプリケーション設計者が、オプティマイザの認知しない、データに関する情報を把
握している場合があります。ヒントは、特定の基準に基づいて特定の問合せ実行計画を選択す
るオプティマイザを指示する機構を備えています。
たとえば、ある問合せに対しては、特定の索引を選択する方がよい場合もあります。この情報
に基づいて、アプリケーション設計者がオプティマイザよりも効率的に実行計画を選択できま
す。その場合は、ヒントを使用して、オプティマイザが最適な実行計画を使用するように指示
できます。
注意 : ヒントを使用すると、管理、チェックおよび制御する必要のあるコー
ドが増えます。
ヒントの型
ヒントは、次の一般的な型に分類されます。
■
単一表
単一表ヒントは、1 つの表またはビュー上で指定します。単一表ヒントの例として、
INDEX および USE_NL があります。
■
複数表
複数表ヒントは単一表ヒントに似ていますが、ヒントで 1 つ以上の表またはビューを指定
できる点が異なります。複数表ヒントの例には、LEADING があります。USE_NL(table1
table2) は、複数表ヒントとはみなされないため注意してください。これは、実際には
USE_NL(table1) および USE_NL(table2) のショートカットであるためです。
■
問合せブロック
問合せブロック・ヒントでは、単一の問合せブロックが処理されます。問合せブロック・
ヒントの例として、STAR_TRANSFORMATION および UNNEST があります。
■
文
文ヒントは SQL 文全体に適用されます。文ヒントの例には、ALL_ROWS があります。
カテゴリ別のヒント
オプティマイザ・ヒントは次のカテゴリにグループ分けされます。
■
最適化アプローチと目標のヒント
■
アクセス・パスに関するヒント
■
問合せの変換に関するヒント
■
結合順序のヒント
■
結合操作のヒント
■
パラレル実行のヒント
■
その他のヒント
このようなカテゴリと各カテゴリ内に含まれるヒントについては、次の各項で説明します。
関連項目 : 構文と各ヒントの詳細は、『Oracle Database SQL 言語リファレ
ンス』を参照してください。
16-2
Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの理解
最適化アプローチと目標のヒント
次のヒントでは、最適化アプローチと目標のいずれかを選択できます。
■
ALL_ROWS
■
FIRST_ROWS(n)
最適化アプローチと目標を指定するヒントが 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) ヒントとともに、アクセス・パスまたは結合操作の
ヒントを指定した場合、オプティマイザはヒントによって指定されたアクセス・パスと結合操
作を優先します。
マージ可能なビューでのヒントの動作については、16-10 ページの「ビューでの最適化アプロー
チと目標のヒント」を参照してください。
アクセス・パスに関するヒント
次の各ヒントでは、オプティマイザが表の特定のアクセス・パスを使用するように指示します。
■
FULL
■
CLUSTER
■
HASH
■
INDEX
■
NO_INDEX
■
INDEX_ASC
■
INDEX_COMBINE
■
INDEX_JOIN
■
INDEX_DESC
■
INDEX_FFS
■
NO_INDEX_FFS
■
INDEX_SS
■
INDEX_SS_ASC
■
INDEX_SS_DESC
■
NO_INDEX_SS
これらのヒントの 1 つを指定すると、指定されたアクセス・パスが索引やクラスタの存在およ
び SQL 文の構文構造体に基づいて使用できる場合のみ、オプティマイザはそのアクセス・パス
を選択します。ヒントを使用できないアクセス・パスを指定すると、オプティマイザはその指
定を無視します。
オプティマイザ・ヒントの使用方法
16-3
オプティマイザ・ヒントの理解
アクセスする表は、文に指定する場合と同じように正確に指定してください。文が表の別名を
使用している場合、表の名前ではなく、表の別名をヒントで使用する必要があります。スキー
マ名が文中にある場合は、ヒント内の表名にそのスキーマ名を入れないでください。
マージ可能なビューでのヒントの動作については、16-10 ページの「ビューに対するアクセス・
パスとヒント結合」および 16-11 ページの「ビューの内側のアクセス・パスとヒント結合」を
参照してください。
注意 : アクセス・パスのヒントの場合、SELECT 文の FROM 句で SAMPLE
オプションを指定すると、Oracle はヒントを無視します。
関連項目 : SAMPLE オプションの詳細は、
『Oracle Database SQL 言語リ
ファレンス』を参照してください。
問合せの変換に関するヒント
次の各ヒントでは、オプティマイザが特定の SQL 問合せ変換を使用するように指示します。
■
NO_QUERY_TRANSFORMATION
■
USE_CONCAT
■
NO_EXPAND
■
REWRITE
■
NO_REWRITE
■
MERGE
■
NO_MERGE
■
STAR_TRANSFORMATION
■
NO_STAR_TRANSFORMATION
■
FACT
■
NO_FACT
■
UNNEST
■
NO_UNNEST
結合順序のヒント
次のヒントは結合順序を指示します。
■
LEADING
■
ORDERED
結合操作のヒント
次の各ヒントでは、オプティマイザが表の特定の結合操作を使用するように指示します。
16-4
■
USE_NL
■
NO_USE_NL
■
USE_NL_WITH_INDEX
■
USE_MERGE
■
NO_USE_MERGE
■
USE_HASH
■
NO_USE_HASH
Oracle Database パフォーマンス・チューニング・ガイド
オプティマイザ・ヒントの理解
USE_NL ヒントと USE_MERGE ヒントは、結合順序のヒントとともに使用することをお薦めし
ます。16-4 ページの「結合順序のヒント」を参照してください。Oracle では、参照表が結合の
内部表になった場合にこれらのヒントを使用し、参照表が外部表の場合にはこれらのヒントを
無視します。
マージ可能なビューでのヒントの動作については、16-10 ページの「ビューに対するアクセス・
パスとヒント結合」および 16-11 ページの「ビューの内側のアクセス・パスとヒント結合」を
参照してください。
パラレル実行のヒント
次のヒントでは、パラレル実行を行ったときに、文がどのようにパラレル化されるか、または
パラレル化されないかについてオプティマイザを指示します。
■
PARALLEL
■
PQ_DISTRIBUTE
■
PARALLEL_INDEX
■
NO_PARALLEL_INDEX
マージ可能なビューでのヒントの動作については、16-11 ページの「ビューに対するパラレル実
行ヒント」および 16-11 ページの「ビューの内側のパラレル実行ヒント」を参照してください。
関連項目 : パラレル実行の詳細は、『Oracle Database データ・ウェアハウ
ス・ガイド』を参照してください。
その他のヒント
この項ではその他のいくつかのヒントを説明します。
■
APPEND
■
NOAPPEND
■
CACHE
■
NOCACHE
■
PUSH_PRED
■
NO_PUSH_PRED
■
PUSH_SUBQ
■
NO_PUSH_SUBQ
■
QB_NAME
■
CURSOR_SHARING_EXACT
■
DRIVING_SITE
■
DYNAMIC_SAMPLING
■
MODEL_MIN_ANALYSIS
オプティマイザ・ヒントの使用方法
16-5
ヒントの指定方法
ヒントの指定方法
ヒントは、それらが含まれる SQL 文ブロックの最適化のみに適用されます。文ブロックは、次
のいずれかの文または文の一部です。
■
単純な SELECT 文、UPDATE 文または DELETE 文
■
複合文の親文または副問合せ
■
複合問合せの一部
たとえば、UNION 演算子で結合した 2 つの問合せから構成されている複合問合せには、各構成
要素の問合せに対して 1 つずつ、合計 2 つのブロックがあります。このため、この最初の構成
要素の問合せにおけるヒントはその最適化のみに適用され、2 番目の構成要素の問合せの最適
化には適用されません。
次の各項では、ヒントの使用方法をさらに詳しく説明します。
■
ヒント全セットの指定方法
■
ヒントにおける問合せブロックの指定方法
■
グローバル表のヒントの指定方法
■
複合索引ヒントの指定方法
ヒント全セットの指定方法
ヒントを使用するとき、ある状況では、最適な実行計画を確認するためにヒントの全セットの
指定が必要な場合があります。たとえば、多数の表が結合された非常に複雑な問合せが存在す
るときに、指定の表に対して INDEX ヒントのみを指定すると、オプティマイザは、使用される
残りのアクセス・パスとともに、対応する結合方法も判断する必要があります。したがって、
INDEX ヒントを指定しても、オプティマイザによってそのヒントが使用されるとはかぎりませ
ん。これは、オプティマイザの選択した結合方法およびアクセス・パスによっては、要求され
た索引を使用できないとオプティマイザが判断するためです。
例 16-1 では、LEADING ヒントにより、使用する正確な結合順序が、別の表で使用される結合
方法とともに指定されています。
例 16-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;
16-6
Oracle Database パフォーマンス・チューニング・ガイド
ヒントの指定方法
ヒントにおける問合せブロックの指定方法
問合せ内の問合せブロックを識別するには、ヒントにオプションの問合せブロック名を使用し
て、ヒントの適用先となる問合せブロックを指定します。問合せブロック引数の構文のフォー
ムは @queryblock です。queryblock は、問合せ内の問合せブロックを指定する識別子で
す。queryblock 識別子は、システム生成またはユーザー指定のいずれかとなります。
■
■
システム生成識別子を取得するには、問合せに EXPLAIN PLAN を使用します。変換前の問
合せブロック名を決定するには、NO_QUERY_TRANSFORMATION ヒントを使用して、問合
せに EXPLAIN PLAN を実行します。
ユーザー指定の名前は、QB_NAME ヒントにより設定できます。
例 16-2 では、ビュー上の SELECT 文内の問合せブロックを指定するため、問合せブロック名が
NO_UNNEST ヒントとともに使用されています。
例 16-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;
オプティマイザ・ヒントの使用方法
16-7
ヒントの指定方法
グローバル表のヒントの指定方法
表を指定するヒントは、一般に、ヒントが呼び出される場所である DELETE、SELECT または
UPDATE 問合せブロック内の表を参照します。文によって参照されるビュー内の表は参照しま
せん。ビュー内に表示される表のヒントを指定する場合は、ビューに埋め込まれているヒント
ではなくグローバル・ヒントを使用することをお薦めします。この章で説明する表ヒントは、
表の名前とともにビューの名前が含まれる拡張 tablespec 構文を使用して、グローバル・ヒ
ントに変換できます。
また、tablespec 構文の前にオプションの問合せブロック名を使用できます。16-7 ページの
「ヒントにおける問合せブロックの指定方法」を参照してください。
表を指定するヒントには、次の構文を使用します。
tablespec::=
view
.
table
各項目は次のとおりです。
■
view は、ビュー名を指定します。
■
table は、表の名前または別名を指定します。
ビューのパスが指定されている場合、ヒントは左から右へ解決されます。この場合、1 つ目の
ビューは FROM 句に含まれる必要があり、それ以降の各ビューは、前のビューの FROM 句で指
定されている必要があります。
たとえば、例 16-3 では、部門内で給与が最高である各従業員について、従業員の姓名、従業員
の最初のジョブおよび従業員の全ダイレクト・レポートの合計給与を戻すためのビュー v が作
成されます。データを問合せる場合、ビュー e2 の表 e3 に索引 emp_job_ix を使用すること
を強制できます。
例 16-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
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;
16-8
Oracle Database パフォーマンス・チューニング・ガイド
ヒントの指定方法
グローバル・ヒント構文は、例 16-4 に示すように、マージ不可能なビューにも適用されます。
例 16-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 にプッシュされます。
関連項目 :
16-10 ページ「ビューでのヒントの使用方法」
複合索引ヒントの指定方法
索引を指定するヒントには、次のように、単純な索引名またはカッコで括られた列のリストの
いずれかを使用できます。
indexspec::=
index
table
.
(
column
)
各項目は次のとおりです。
■
table は、表の名前を指定します。
■
column は、指定された表内の列名を指定します。
■
–
オプションで列の前に表修飾子を付けることができるため、ヒントにより、索引列が
索引付きの表とは別の表にあるビットマップ結合索引を指定できます。表修飾子があ
る場合、問合せに含まれる別名ではなく、実表である必要があります。
–
索引指定の各列は、式ではなく、指定された表のベース列である必要があります。索
引指定で指定された列がファンクション索引の接頭辞を形成している場合を除き、列
指定を使用してファンクション索引をヒントで指定することはできません。
index は、索引名を指定します。
ヒントは次のように解決されます。
■
■
索引名が指定されている場合、その索引のみが考慮されます。
列リストが指定されており、列の数と順序が指定の列と一致する索引が存在する場合、その
索引のみが考慮されます。このような索引が存在しない場合、指定された列が接頭辞として
指定順序どおりに含まれる、表に対する索引が考慮されます。いずれの場合も、一致するす
べての索引に対してユーザーが個別に同じヒントを指定した場合と同じ動作になります。
たとえば、例 16-3 では、job_history 表に、employee_id 列に対する単一列索引と、
employee_id および start_date 列に対する連結索引があります。索引の使用に関してオプ
ティマイザを明確に指示するには、次のように問合せにヒントを指定します。
SELECT /*+ INDEX(v.j jhist_employee_ix (employee_id start_date)) */ * FROM v;
オプティマイザ・ヒントの使用方法
16-9
ビューでのヒントの使用方法
ビューでのヒントの使用方法
ビュー（または副問合せ）内、またはビューに対してのヒントの使用は、お薦めしません。こ
れは、1 つのコンテキストに定義したビューを他のコンテキストでも使用できるためです。ま
た、このようなヒントによって予想外の実行計画が発生する可能性があります。特に、ビュー
内のヒントまたはビューに対するヒントは、そのビューがトップレベルの問合せにマージ可能
かどうかによって処理方法が異なります。
表のヒントをビューまたは副問合せ内で指定する場合は、グローバル・ヒント構文の使用をお
薦めします。16-8 ページの「グローバル表のヒントの指定方法」を参照してください。
それでも、ビューでヒントを使用する場合は、この後の項で状況ごとの動作についての説明を
参照してください。
■
ヒントおよび複合ビュー
■
ヒントとマージ可能ビュー
■
ヒントとマージ不可能ビュー
ヒントおよび複合ビュー
デフォルトでは、複合ビューでヒントは使用できません。たとえば、複合ビューに対して選択
する問合せでヒントを指定しても、そのヒントは機能しません。これは、ビュー内にヒントが
プッシュされないためです。
注意 :
ビューが単一表の場合、ヒントは伝播されません。
ヒントがベース・ビュー内に存在しないかぎり、ビューに対する問合せからヒントが機能する
ことはありません。
ヒントとマージ可能ビュー
この項では、マージ可能なビューでのヒントの動作について説明します。
ビューでの最適化アプローチと目標のヒント
最適化アプローチと目標のヒントは、トップレベルの問合せまたはビューの内側に指定できま
す。
■
■
■
そのようなヒントがトップレベルの問合せにある場合は、ビューの内側にあるヒントとは
関係なくそのヒントが使用されます。
トップレベルのオプティマイザ・モード・ヒントがない場合は、参照されているビューの
すべてのモード・ヒントに一貫性があるかぎり、それらのモード・ヒントが使用されます。
参照されているビューの 2 つ以上のモード・ヒントが矛盾する場合は、そのビューのすべ
てのモード・ヒントが廃棄されて、セッション・モードが使用されます（デフォルトか
ユーザー指定かには関係しません）
。
ビューに対するアクセス・パスとヒント結合
参照されるビューに対するアクセス・パスとヒント結合は、そのビューが単一の表を含んでい
ないかぎり（または単一の表を持つその他のヒント・ビューを参照していないかぎり）無視さ
れます。そのような単一表ビューでは、ビューに対するアクセス・パスやヒント結合は、その
ビューの中の表に対して適用されます。
16-10
Oracle Database パフォーマンス・チューニング・ガイド
ビューでのヒントの使用方法
ビューの内側のアクセス・パスとヒント結合
アクセス・パスとヒント結合は、ビュー定義に含めることができます。
■
■
ビューがインライン・ビューである場合（つまり、ビューが SELECT 文の FROM 句にある場
合）
、そのビューの内側のすべてのアクセス・パスとヒント結合は、そのビューがトップレ
ベルの問合せにマージされるときに保存されます。
インライン・ビューでないビューでは、そのビューの中のアクセス・パスとヒント結合が
保存されるのは、参照問合せが他の表やビューを参照していない場合（つまり、SELECT
文の FROM 句にそのビューしか含まれていない場合）のみです。
ビューに対するパラレル実行ヒント
ビューに対する PARALLEL、NO_PARALLEL、PARALLEL_INDEX および
NO_PARALLEL_INDEX ヒントは、参照されるビュー内のすべての表に繰り返し適用されます。
トップレベルの問合せのパラレル実行ヒントは、参照されるビューの内側のそのようなヒント
を上書きします。
ビューの内側のパラレル実行ヒント
ビューの内側の PARALLEL、NO_PARALLEL、PARALLEL_INDEX および
NO_PARALLEL_INDEX ヒントは、ビューがトップレベルの問合せにマージされるときに保存さ
れます。トップレベルの問合せにあるビューのパラレル実行ヒントは、参照されるビューの内
側のそのようなヒントを上書きします。
ヒントとマージ不可能ビュー
マージ不可能なビューでは、ビューの内側の最適化アプローチと目標のヒントは無視されます。
つまり、トップレベルの問合せにより最適化モードが決定されます。
マージ不可能なビューはトップレベルの問合せとは別に最適化されるので、そのビューの内側
のアクセス・パスとヒント結合は保存されます。同じ理由から、トップレベルの問合せ内の
ビューに対するアクセス・パスも無視されます。
ただし、トップレベルの問合せ内のビューに対するヒント結合は保存されます。この場合、
マージ不可能なビューは表と同様であるためです。
オプティマイザ・ヒントの使用方法
16-11
ビューでのヒントの使用方法
16-12
Oracle Database パフォーマンス・チューニング・ガイド
17
SQL アクセス・アドバイザ
この章では、SQL アクセス・アドバイザの使用方法について説明します。SQL アクセス・アド
バイザは、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログについて
アドバイスを提供するチューニング・ツールです。この章には次の項があります。
■
DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要
■
SQL アクセス・アドバイザの使用方法
■
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
SQL アクセス・アドバイザ
17-1
DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要
DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要
データ集中型の複雑な問合せの実行時に最適なパフォーマンスを実現できるようにデータベー
スをチューニングする際、マテリアライズド・ビューと索引が必要になります。SQL アクセ
ス・アドバイザでは、指定のワークロードに関するマテリアライズド・ビュー、マテリアライ
ズド・ビュー・ログおよび索引の適切なセットが推奨されるため、パフォーマンスの目標を達
成するのに役立ちます。SQL を最適化する際には、これらの構造を理解して使用することが重
要です。これにより、データを取り出す際のパフォーマンスが大幅に向上します。ただし、こ
のような利点を利用するにはそれなりの負担が伴います。これらのオブジェクトの作成やメン
テナンスには時間がかかり、また領域要件も重要になります。
SQL アクセス・アドバイザでは、ビットマップ索引、ファンクション索引および B ツリー索引
が推奨されています。ビットマップ索引を使用すると、多くのタイプの非定型問合せの応答時
間が短縮され、その他の索引付けの方法と比べて記憶域要件が軽減されます。B ツリー索引は、
一意またはほぼ一意のキーに索引を付ける方法で、データ・ウェアハウスで最も一般的に使用
されています。
また、SQL アクセス・アドバイザの別のコンポーネントにより、マテリアライズド・ビューの
最適化も推奨されています。これにより、マテリアライズド・ビューの高速リフレッシュが可
能になり、汎用的なクエリー・リライトを利用できます。
SQL アクセス・アドバイザを実行するには、Oracle Enterprise Manager（
「セントラル・アドバ
イザ」ページからアクセス可能）から SQL アクセス・アドバイザ・ウィザードを使用するか、
DBMS_ADVISOR パッケージを起動します。DBMS_ADVISOR パッケージは、任意の PL/SQL プ
ログラムからコール可能な分析およびアドバイザ用のファンクションおよびプロシージャの集
合です。図 17-1 は、ユーザー定義の表または SQL キャッシュから取得した特定のワークロー
ドについて SQL アクセス・アドバイザがマテリアライズド・ビューを推奨する方法を示しま
す。ワークロードが提供されていない場合、SQL アクセス・アドバイザは仮想ワークロードも
生成および使用できます。
図 17-1 マテリアライズド・ビューと SQL アクセス・アドバイザ
17-2
Oracle Database パフォーマンス・チューニング・ガイド
DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要
SQL アクセス・アドバイザ・ウィザードまたは API を使用して、次の操作を実行できます。
■
収集した情報または仮想ワークロード情報に基づいてマテリアライズド・ビューと索引を
推奨します。
■
ワークロードを管理します。
■
推奨事項をマーク、更新および削除します。
また、SQL アクセス・アドバイザの API を使用して、次の操作を実行できます。
■
単一 SQL 文を使用してクイック・チューニングを実行します。
■
マテリアライズド・ビューを高速でリフレッシュする方法を示します。
■
マテリアライズド・ビューを変更して汎用的なクエリー・リライトを可能にする方法を示
します。
表と索引のカーディナリティ、およびディメンション・レベルのすべての列、JOIN KEY 列お
よびファクト表のキー列の個別カーディナリティに関する構造的な統計を収集すると、SQL ア
クセス・アドバイザの推奨事項は大幅に向上します。これを行うには、DBMS_STATS パッケー
ジを使用して正確な統計または見積り統計を収集します。統計の収集は時間のかかる処理であ
り、極端な統計精度は必要ないため、通常は統計を見積もることをお薦めします。これらの統
計がない場合、その表を参照する問合せはワークロードで無効とマークされるため、これらの
問合せについては推奨事項が生成されなくなります。また、既存のすべての索引とマテリアラ
イズド・ビューを分析しておくこともお薦めします。DBMS_STATS パッケージの詳細は、
『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照し
てください。
SQL アクセス・アドバイザの使用方法の概要
SQL アクセス・アドバイザを使用する最も簡単な方法は、ウィザードを起動する方法です。こ
のウィザードは、Oracle Enterprise Manager の「セントラル・アドバイザ」ページからアクセ
スできます。DBMS_ADVISOR パッケージを介して SQL アクセス・アドバイザを使用する方が
望ましい場合は、この項の説明にある基本的なコンポーネントや、様々なプロシージャをコー
ルする必要があるシーケンスについて参照してください。
この項では、一連の推奨事項を生成するための 4 つの手順について説明します。
■
タスクの作成
■
ワークロードの定義
■
推奨事項の生成
■
推奨事項の表示と実装
手順 1 タスクの作成
推奨を行う前に、タスクを作成する必要があります。推奨プロセスの結果など、推奨プロセス
に関するすべての情報はタスク内に格納されるため、タスクは重要です。Oracle Enterprise
Manager のウィザードまたは DBMS_ADVISOR.QUICK_TUNE プロシージャを使用する場合、タ
スクは自動的に作成されます。これ以外のすべてのケースにおいては、
DBMS_ADVISOR.CREATE_TASK プロシージャを使用してタスクを作成する必要があります。
タスクの処理内容を制御するには、DBMS_ADVISOR.SET_TASK_PARAMETER プロシージャを使
用してタスクのパラメータを定義します。
タスクの作成の詳細は、17-7 ページの「タスクの作成」を参照してください。
SQL アクセス・アドバイザ
17-3
DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要
手順 2 ワークロードの定義
ワークロードは、SQL アクセス・アドバイザの主な入力データであり、1 つ以上の SQL 文と、
各文を完全に説明する様々な統計や属性で構成されています。ワークロードにターゲットのビ
ジネス・アプリケーションのすべての SQL 文が含まれる場合、このワークロードは全ワーク
ロードとみなされます。一方、ワークロードに SQL 文のサブセットが含まれる場合、このワー
クロードは部分ワークロードと呼ばれます。全ワークロードと部分ワークロードの違いは、全
ワークロードの場合、効率的に使用されていない既存のマテリアライズド・ビューや索引を検
出すると、SQL アクセス・アドバイザがこれらを削除するよう推奨する点にあります。
通常、SQL アクセス・アドバイザでは、すべての分析アクティビティの基礎としてワークロー
ドを使用します。ワークロードには様々な種類の文が含まれることがありますが、ワークロー
ドでは、特定の統計、ビジネスの重要性、または統計とビジネスの重要性の組合せに応じてエ
ントリにランクが付けられます。このランクは重要です。このようにランクを付けることによ
り、SQL アクセス・アドバイザはビジネスへの影響が少ない SQL 文よりも最も重要な SQL 文
を先に処理できるようになるためです。
データの集合を有効なワークロードとみなすために、SQL アクセス・アドバイザには特定の属
性が必要になることがあります。一部の項目が欠落していても分析は実行できますが、推奨事
項の品質が大幅に低下する場合があります。たとえば、SQL アクセス・アドバイザでは、SQL
問合せとこの問合せを実行したユーザーがワークロードに含まれている必要があります。その
他すべての属性はオプションです。ただし、ワークロードに I/O および CPU 情報も含まれて
いると、SQL アクセス・アドバイザでは文の現在の効率をより正確に評価できる場合がありま
す。ワークロードは、DBMS_ADVISOR.CREATE_SQLWKLD プロシージャを使用して作成される
別のオブジェクトとして格納され、多くのアドバイザ・タスク間で簡単に共有できます。ワー
クロードは独立しているため、DBMS_ADVISOR.ADD_SQLWKLD_REF プロシージャを使用して
タスクにリンクする必要があります。いったんこのリンクが確立されると、すべてのアドバイ
ザ・タスクからワークロードに対する依存性が削除されるまではワークロードを削除または変
更できなくなります。ワークロード参照が削除されるのは、親アドバイザ・タスクが削除され
る場合か、ユーザーが DBMS_ADVISOR.DELETE_SQLWKLD_REF プロシージャを使用してアド
バイザ・タスクからワークロード参照を手動で削除する場合です。
SQL アクセス・アドバイザはワークロードなしでも使用できますが、最良の結果を得るには、
ユーザー指定の表または SQL チューニング・セットの形式でワークロードを提供するか、SQL
キャッシュからワークロードをインポートする必要があります。ワークロードが提供されない
場合、SQL アクセス・アドバイザは、スキーマに定義されているディメンションに基づいて仮
想ワークロードを生成および使用できます。
ワークロードがリポジトリにロードされるか、推奨事項が生成されると、ワークロードにフィ
ルタを適用し、分析対象を制限できます。これにより、様々なワークロード・シナリオに基づ
いて一連の各種推奨事項を生成できるようになります。
ワークロードの推奨プロセスとカスタマイズは、SQL アクセス・アドバイザ・パラメータに
よって制御されます。これらのパラメータは、必要な推奨事項のタイプや推奨内容のネーミン
グ規則など、推奨プロセスの様々な側面を制御します。ワークロードに関しては、パラメータ
は、ワークロードの存続時間やワークロードに適用するフィルタを制御します。
これらのパラメータを設定するには、SET_TASK_PARAMETER および
SET_SQLWKLD_PARAMETER プロシージャを使用します。パラメータは、タスクまたはワーク
ロード・オブジェクトの存続期間は設定されたままであるという点において永続的です。
SET_TASK_PARAMETER プロシージャを使用してパラメータを設定した場合、
SET_TASK_PARAMETER をもう 1 回コールするまではこのパラメータは変更されません。
ワークロードの詳細は、17-10 ページの「ワークロードの内容の定義」を参照してください。
17-4
Oracle Database パフォーマンス・チューニング・ガイド
DBMS_ADVISOR パッケージの SQL アクセス・アドバイザの概要
手順 3 推奨事項の生成
タスクが存在するときにこのタスクにワークロードをリンクし、適切なパラメータを設定する
と、DBMS_ADVISOR.EXECUTE_TASK プロシージャを使用して推奨事項を生成できます。これ
らの推奨事項は、SQL アクセス・アドバイザ・リポジトリに格納されます。
推奨プロセスにより、多数の推奨事項が生成されます。各推奨事項には、1 つ以上のアクショ
ンが含まれます。たとえば、マテリアライズド・ビューを作成し、これを分析して統計情報を
収集します。
タスクの推奨事項には、単純な提案から、索引、マテリアライズド・ビューおよびマテリアラ
イズド・ビュー・ログなどの一連のデータベース・オブジェクトの実装を必要とする複雑なソ
リューションまで多岐にわたります。アドバイザ・タスクが実行されると、収集されたデータ
とユーザー調整のタスク・パラメータが慎重に分析されます。これにより、SQL アクセス・ア
ドバイザでは、組み込まれているナレッジに基づいて精度を形成しようとします。次に、この
精度は微調整され、ユーザーが表示および実装できるよう構造化された推奨事項の形式で格納
されます。
推奨事項の生成の詳細は、17-19 ページの「推奨事項の生成」を参照してください。
手順 4 推奨事項の表示と実装
SQL アクセス・アドバイザの推奨事項を表示する方法には 2 通りあります。カタログ・ビュー
を使用する方法と、DBMS_ADVISOR.GET_TASK_SCRIPT プロシージャを使用してスクリプト
を生成する方法です。Enterprise Manager では、SQL アクセス・アドバイザ・プロセスが完了
すると推奨事項が表示されます。
推奨事項を表示するためにカタログ・ビューを使用する方法の詳細は、17-19 ページの「推奨事
項の表示」を参照してください。スクリプトの作成方法の詳細は、17-25 ページの「SQL スクリ
プトの生成」を参照してください。
すべての推奨事項を受け入れる必要はなく、推奨事項のスクリプトに含める推奨事項をマーク
できます。
最終手順では、推奨事項を実装し、問合せのパフォーマンスが向上したかどうかを検証します。
SQL アクセス・アドバイザ・リポジトリ
SQL アクセス・アドバイザによって生成されたすべての必要情報は、データベース・ディク
ショナリの一部であるアドバイザ・リポジトリに格納されます。リポジトリを使用する利点は、
次のとおりです。
■
SQL アクセス・アドバイザの完全なワークロードが収集されます。
■
履歴データがサポートされます。
■
サーバーによって管理されます。
SQL アクセス・アドバイザ
17-5
SQL アクセス・アドバイザの使用方法
SQL アクセス・アドバイザの使用方法
この項では、SQL アクセス・アドバイザに関する一般的な情報や、SQL アクセス・アドバイザ
を使用するために必要な手順について説明します。この項には、次の項目があります。
■
SQL アクセス・アドバイザの使用手順
■
SQL アクセス・アドバイザの使用に必要な権限
■
タスクとテンプレートの設定
■
ワークロードの管理
■
推奨事項の処理
■
クイック・チューニングの実行
■
タスクの管理
■
SQL アクセス・アドバイザの定数の使用方法
関連項目 : SQL アクセス・アドバイザを Oracle Enterprise Manager で使用
する方法については、
『Oracle Database 2 日でパフォーマンス・チューニン
グ・ガイド』を参照してください。
SQL アクセス・アドバイザの使用手順
図 17-2 には、SQL アクセス・アドバイザの使用手順と、SQL アクセス・アドバイザのすべて
のパラメータの概要、およびその適切な使用タイミングを示します。
図 17-2 SQL アクセス・アドバイザのフローチャート
17-6
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
SQL アクセス・アドバイザの使用に必要な権限
SQL アクセス・アドバイザを管理または使用するには、ADVISOR 権限が必要です。SQL アク
セス・アドバイザは、ワークロードの処理時に各文を検証し、表と列の参照関係を識別しよう
とします。この文のオリジナル・ユーザーが実行しているものとして各文を処理することに
よって検証されます。このユーザーが特定の表に対する SELECT 権限を持っていない場合、
SQL アクセス・アドバイザは、この表を参照している文をバイパスします。これにより、多く
の文が分析から除外されることがあります。SQL アクセス・アドバイザがワークロード内のす
べての文を除外すると、ワークロードは無効になり、次のメッセージが戻されます。
QSM-00774, there are no SQL statements to process for task TASK_NAME
重要なワークロード問合せが欠落しないようにするには、現在のデータベース・ユーザーが、
マテリアライズド・ビューの分析対象の表に対する SELECT 権限を持つ必要があります。これ
らの表については、ロールを介してこれらの SELECT 権限を取得できません。
タスクとテンプレートの設定
この項では、タスクとテンプレートの設定に関する次の側面について説明します。
■
タスクの作成
■
テンプレートの使用方法
■
テンプレートの作成
タスクの作成
アドバイザ・タスクとは、分析する内容と、この分析結果の提供先を定義するタスクです。
ユーザーは、各タスクが特化した任意の数のタスクを作成できます。これらすべてのタスクは
同じアドバイザ・タスク・モデルに基づいており、同じリポジトリを共有します。
タスクを作成するには、CREATE_TASK プロシージャを使用します。構文は、次のとおりです。
DBMS_ADVISOR.CREATE_TASK
advisor_name
task_id
task_name
task_desc
template
is_template
how_created
(
IN VARCHAR2,
OUT NUMBER,
IN OUT VARCHAR2,
IN VARCHAR2 := NULL,
IN VARCHAR2 := NULL,
IN VARCHAR2 := 'FALSE',
IN VARCHAR2 := NULL);
DBMS_ADVISOR.CREATE_TASK
advisor_name
task_name
task_desc
template
is_template
how_created
(
IN
IN
IN
IN
IN
IN
VARCHAR2,
VARCHAR2,
VARCHAR2 :=
VARCHAR2 :=
VARCHAR2 :=
VARCHAR2 :=
NULL,
NULL,
'FALSE',
NULL);
次に、このプロシージャの使用例を示します。
VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'MYTASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK ('SQL Access Advisor', :task_id, :task_name);
CREATE_TASK および CREATE_SQLWKLD プロシージャとそのパラメータの詳細は、
『Oracle
Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してくださ
い。
SQL アクセス・アドバイザ
17-7
SQL アクセス・アドバイザの使用方法
テンプレートの使用方法
タスクまたはワークロードの理想的な構成が識別されると、将来のタスクとワークロードの基
となるテンプレートとしてこの構成を保存できます。
これにより、将来のタスクを作成する場合の理にかなった開始ポイントまたはテンプレートと
して使用可能なタスクまたはワークロードを、任意の数だけ設定できるようになります。テン
プレートを設定することにより、チューニング分析の実行時間を短縮できます。また、チュー
ニング分析をビジネス処理に合うようにカスタマイズすることもできます。
テンプレートからタスクを作成するには、新しいタスクの作成時に使用するテンプレートを指
定します。このとき、SQL アクセス・アドバイザは、新しく作成されたタスクにテンプレート
からデータおよびパラメータ設定をコピーします。また、既存のタスクをテンプレートとして
設定するには、タスクの作成時にテンプレート属性を使用するか、後で
UPDATE_TASK_ATTRIBUTE プロシージャを使用します。
タスクをテンプレートとして使用するには、新しいタスクの作成時にタスクを使用することを
SQL アクセス・アドバイザに通知します。このとき、SQL アクセス・アドバイザは、新しく作
成されたタスクにテンプレートのデータおよびパラメータ設定をコピーします。また、既存の
タスクをテンプレートとして設定するには、テンプレート属性を設定します。この操作は、コ
マンドラインまたは Enterprise Manager で行います。
新しいワークロード・オブジェクトを作成するためのテンプレートとしてワークロード・オブ
ジェクトを使用することもできます。タスクをテンプレートとして使用する場合と同じガイド
ラインに従うことにより、ワークロード・オブジェクトにも明確な開始ポイントを指定できま
す。タスク・テンプレートの場合と同様、テンプレートのワークロード・オブジェクトを使用
して作成できるのは、同じワークロード・オブジェクトのみです。
テンプレートの作成
テンプレートの作成例は、次のとおりです。
1.
MY_TEMPLATE と呼ばれるテンプレートを作成します。
VARIABLE template_id NUMBER;
VARIABLE template_name VARCHAR2(255);
EXECUTE :template_name := 'MY_TEMPLATE';
EXECUTE DBMS_ADVISOR.CREATE_TASK('SQL Access Advisor',:template_id, :template_name, is_template => 'TRUE');
2.
テンプレートのパラメータを設定します。たとえば、次の例では、推奨される索引とマテ
リアライズド・ビューのネーミング規則とデフォルトの表領域を設定します。
-- set naming conventions for recommended indexes/mvs
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'INDEX_NAME_TEMPLATE', 'SH_IDX$$_<SEQ>');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'MVIEW_NAME_TEMPLATE', 'SH_MV$$_<SEQ>');
-- set default tablespace for recommended indexes/mvs
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'DEF_INDEX_TABLESPACE', 'SH_INDEXES');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'DEF_MVIEW_TABLESPACE', 'SH_MVIEWS');
3.
これで、このテンプレートは、次のようにタスクを作成するときの開始ポイントとして使
用できます。
VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'MYTASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK('SQL Access Advisor', :task_id, :task_name, template=>'MY_TEMPLATE');
17-8
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
次の例では、事前定義済テンプレート SQLACCESS_WAREHOUSE を使用します。詳細は、
表 17-4 を参照してください。
EXECUTE DBMS_ADVISOR.CREATE_TASK('SQL Access Advisor', :task_id, :task_name, template=>'SQLACCESS_WAREHOUSE');
ワークロードの管理
この項では、ワークロードの管理に関する次の側面について説明します。
■
ワークロード・オブジェクト
■
ワークロードの使用
■
タスクとワークロードのリンク
■
ワークロードの内容の定義
■
ワークロードへの SQL 文の追加
■
ワークロードの SQL 文の削除
■
ワークロードの SQL 文の変更
■
ワークロードのメンテナンス
■
ワークロードの削除
ワークロード・オブジェクト
ワークロードは個別のワークロード・オブジェクトとして格納されるため、多くのアドバイ
ザ・タスク間で簡単に共有できます。ワークロード・オブジェクトは、アドバイザ・タスクに
よっていったん参照されると、すべてのアドバイザ・タスクからこのデータに対する依存性が
削除されるまでは削除または変更できなくなります。ワークロード参照が削除されるのは、親
アドバイザ・タスクが削除される場合か、ユーザーがアドバイザ・タスクからワークロード参
照を手動で削除する場合です。
SQL アクセス・アドバイザのパフォーマンスは、使用状況に基づいたワークロードが使用可能
な場合に最も高くなります。SQL アクセス・ワークロード・リポジトリには複数のワークロー
ドを格納できるため、長期間にわたってデータベース・インスタンスの起動から停止までのラ
イフサイクル全体について、実際のデータ・ウェアハウスまたはトランザクション処理環境の
様々な使用状況を参照できます。
実際にワークロードの SQL 文を定義する前に、CREATE_SQLWKLD プロシージャを使用して
ワークロードを作成する必要があります。次に、IMPORT_SQLWKLD プロシージャを使用して
ワークロードをロードします。特定のワークロードを削除するには、DELETE_SQLWKLD プロ
シージャをコールし、このプロシージャに有効なワークロード名を渡します。現在のユーザー
のすべてのワークロードを削除するには、DELETE_SQLWKLD をコールし、定数値
ADVISOR_ALL または % を渡します。
ワークロードの使用
CREATE_SQLWKLD プロシージャは、ワークロードを作成します。このプロシージャは、SQL
文のインポートや更新などのその他のワークロード操作を実行する前に存在している必要があ
ります。ワークロードは名前で識別されるため、操作に関連する一意の名前を定義する必要が
あります。
この構文は、次のとおりです。
DBMS_ADVISOR.CREATE_SQLWKLD
workload_name
description
template
is_template
(
IN
IN
IN
IN
OUT VARCHAR2,
VARCHAR2 := NULL,
VARCHAR2 := NULL.
VARCHAR2 := 'FALSE');
このプロシージャの使用例は、次のとおりです。
SQL アクセス・アドバイザ
17-9
SQL アクセス・アドバイザの使用方法
例 17-1 ワークロードの作成
VARIABLE workload_name VARCHAR2(255);
EXECUTE :workload_name := 'MYWORKLOAD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:workload_name,'This is my first workload');
例 17-2 テンプレートからのワークロードの作成
1.
変数を作成します。
VARIABLE template_id NUMBER;
VARIABLE template_name VARCHAR2(255);
2.
MY_WK_TEMPLATE と呼ばれるテンプレートを作成します。
EXECUTE :template_name := 'MY_WK_TEMPLATE';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:template_name, is_template=>'TRUE');
3.
テンプレートのパラメータを設定します。たとえば、次の例では、sh スキーマ内の表のみ
をチューニングするフィルタを設定します。
-- set USERNAME_LIST filter to SH
EXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER( :template_name, 'USERNAME_LIST', 'SH');
4.
ここで、テンプレートを使用してワークロードを作成します。
VARIABLE workload_name VARCHAR2(255);
EXECUTE :workload_name := 'MYWORKLOAD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD ( :workload_name, 'This is my first workload', 'MY_WK_TEMPLATE');
CREATE_SQLWKLD プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッ
ケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
タスクとワークロードのリンク
推奨プロセスを開始する前に、タスクをワークロードにリンクする必要があります。これを行
うには、ADD_SQKLWKLD_REF プロシージャを使用します。タスクとワークロードはそれぞれ
の名前を使用してリンクされます。このプロシージャは、アドバイザ・タスクとワークロード
間のリンクを確立します。アドバイザ・タスクとワークロード間のリンクがいったん確立され
ると、ワークロードは削除できなくなります。この構文は、次のとおりです。
DBMS_ADVISOR.ADD_SQLWKLD_REF (task_name
workload_name
IN VARCHAR2,
IN VARCHAR2);
次の例では、作成した MYTASK タスクを MYWORKLOAD SQL ワークロードにリンクします。
EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_REF('MYTASK', 'MYWORKLOAD');
ADD_SQLWKLD_REF プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッ
ケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ワークロードの内容の定義
ワークロードの作成後、ワークロードに情報を移入する必要があります。ワークロードは、
データベースに使用されている SQL 文で構成されるのが理想的です（仮想ワークロードである
場合を除きます）
。SQL アクセス・アドバイザは、次のソースからワークロードを取得できま
す。
17-10
■
SQL チューニング・セット
■
ユーザー定義のワークロードのロード
■
SQL キャッシュのワークロードのロード
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
■
仮想ワークロードの使用方法
■
Oracle Database 9i サマリー・アドバイザのワークロードの使用方法
SQL チューニング・セット SQL チューニング・セットは、ワークロード・リポジトリにある
ワークロードです。SQL チューニング・セットを SQL アクセス・アドバイザのワークロードと
して使用するには、IMPORT_WORKLOAD_STS プロシージャを使用してこれをインポートしま
す。このプロシージャの構文は、次のとおりです。
DBMS_ADVISOR.IMPORT_SQLWKLD_STS (workload_name
sts_owner
sts_name
import_mode
priority
saved_rows
failed_rows
IN VARCHAR2,
IN VARCHAR2,
IN VARCHAR2,
IN VARCHAR2 := 'NEW',
IN NUMBER := 2,
OUT NUMBER,
OUT NUMBER);
DBMS_ADVISOR.IMPORT_SQLWKLD_STS (workload_name
sts_name
import_mode
priority
saved_rows
failed_rows
IN VARCHAR2,
IN VARCHAR2,
IN VARCHAR2 := 'NEW',
IN NUMBER := 2,
OUT NUMBER,
OUT NUMBER);
ワークロードが収集され、文にフィルタがかけられた後、SQL アクセス・アドバイザは、ワー
クロード内の DML 文に関する使用状況統計を計算します。
次の例では、MY_STS_WORKLOAD という名前の SQL チューニング・セットからワークロードを
作成します。
VARIABLE sqlsetname VARCHAR2(30);
VARIABLE workload_name VARCHAR2(30);
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
EXECUTE
:sqlsetname := 'MY_STS_WORKLOAD';
EXECUTE
:workload_name := 'MY_WORKLOAD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD (:workload_name);
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_STS (:workload_name , :sqlsetname, 'NEW', 1, :saved_stmts, :failed_stmts);
ユーザー定義のワークロードのロード ユーザー定義のワークロードをロードするには、
IMPORT_SQLWKLD_USER プロシージャを使用します。このプロシージャは、ユーザー構成表か
らアプリケーション・ワークロードを収集するか、アプリケーション・ワークロードをアドバ
イザ・リポジトリに表示して保存します。owner_name と table_name という 2 つのパラ
メータにより、ワークロードの取得元の表が識別されます。
ワークロードが格納されるスキーマ、表の名前、またはユーザー定義表の数には制限がありま
せん。唯一の要件は、ユーザー表の形式が USER_WORKLOAD 表と一致することと（表 17-1 を参
照）
、ユーザーにはワークロード表またはビューに対する SELECT アクセス権があることが必要
です。この構文は、次のとおりです。
DBMS_ADVISOR.IMPORT_SQLWKLD_USER (
workload_name
IN VARCHAR2,
import_mode
IN VARCHAR2 := 'NEW',
owner_name
IN VARCHAR2,
table_name
IN VARCHAR2,
saved_rows
OUT NUMBER,
failed_rows
OUT NUMBER);
SQL アクセス・アドバイザ
17-11
SQL アクセス・アドバイザの使用方法
次の例では、ユーザー表 SH.USER_WORKLOAD を使用して、前に作成した MYWORKLOAD ワーク
ロードをロードします。この表には、SQL 文が移入されており、表 17-1 に指定されている形式
に準拠していることが前提です。
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_USER( 'MYWORKLOAD', 'NEW', 'SH', 'USER_WORKLOAD', :saved_stmts, :failed_stmts);
IMPORT_SQLWKLD_USER プロシージャとそのパラメータの詳細は、『Oracle Database PL/SQL
パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
表 17-1 USER_WORKLOAD 表の形式
列
型
デフォルト
コメント
MODULE
VARCHAR2(64)
空の文字列
アプリケーション・モジュール名です。
ACTION
VARCHAR2(64)
空の文字列
アプリケーションのアクションです。
BUFFER_GETS
NUMBER
0
文のバッファ取得合計です。
CPU_TIME
NUMBER
0
文の合計 CPU 時間（秒単位）です。
ELAPSED_TIME
NUMBER
0
文の合計経過時間（秒単位）です。
DISK_READS
NUMBER
0
文によって使用されたディスク読取り操作の合計回数で
す。
ROWS_PROCESSED
NUMBER
0
SQL 文によって処理された行の総数です。
EXECUTIONS
NUMBER
1
文が実行された合計回数です。
OPTIMIZER_COST
NUMBER
0
オプティマイザが計算した問合せの実行コスト値です。
LAST_EXECUTION_DATE
DATE
SYSDATE
問合せが最後に使用された日付です。デフォルトでは使
用不可です。
PRIORITY
NUMBER
2
次のいずれかの値をとる必要があります。
1- HIGH、2- MEDIUM または 3- LOW
SQL_TEXT
CLOB or LONG or
VARCHAR2
なし
SQL 文です。これは必須列です。
STAT_PERIOD
NUMBER
1
実行統計に対応する時間（秒単位）です。
USERNAME
VARCHAR(30)
現在のユーザー 問合せを実行したユーザーです。これは必須列です。
SQL キャッシュのワークロードのロード SQL キャッシュのワークロードを取得するには、
IMPORT_SQLWKLD_SQLCACHE プロシージャを使用します。このプロシージャがコールされる
と、SQL キャッシュの現在の内容が分析され、ワークロードに格納されます。
IMPORT_SQLWKLD_SQLCACHE プロシージャにより、SQL キャッシュから SQL ワークロードが
ロードされます。この構文は、次のとおりです。
DBMS_ADVISOR.IMPORT_SQLWKLD_SQLCACHE (
workload_name
IN VARCHAR2,
import_mode
IN VARCHAR2,
priority
IN NUMBER := 2,
saved_rows
OUT NUMBER,
failed_rows
OUT NUMBER);
IMPORT_SQLWKLD_SQLCACHE プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
17-12
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
次の例では、前に作成した MYWORKLOAD ワークロードを SQL キャッシュからロードします。
ロードしたワークロード文の優先順位は、2（MEDIUM）です。
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_SQLCACHE ('MYWORKLOAD', 'APPEND', 2, :saved_stmts, :failed_stmts);
SQL アクセス・アドバイザでは、ワークロード情報を SQL キャッシュから取得できます。収集
したデータが、インスタンス・パラメータ cursor_sharing が SIMILAR または FORCE に設
定されたサーバーから取得された場合、リテラル値が組み込まれたユーザー問合せは、システ
ム生成のバインド変数が含まれる文に変換されます。SQL アクセス・アドバイザを使用してマ
テリアライズド・ビューを推奨する場合、サーバーのインスタンス・パラメータ
cursor_sharing を EXACT に設定し、WHERE 句を持つマテリアライズド・ビューが推奨され
るようにする必要があります。
仮想ワークロードの使用方法 多くの場合、アプリケーション・ワークロードはまだ存在してい
ません。このような場合、SQL アクセス・アドバイザは、現在の論理スキーマ設計を調べ、表
間に定義されている関係に基づいて推奨事項を形成できます。このタイプのワークロードは、
仮想ワークロードとも呼ばれます。SQL アクセス・アドバイザは、推奨事項の初期セットを生
成し、アプリケーションをチューニングするための信頼できるベースとなります。
仮想ワークロードを使用する利点は、次のとおりです。
■
必要なのはスキーマと表の関係のみです。
■
なんらかの状況を仮定したシナリオをモデリングする場合に効果があります。
仮想ワークロードを使用する短所は、次のとおりです。
■
ディメンションが定義されている場合のみ機能します。
■
推奨されたアクセス構造に対する DML の影響に関する情報が提供されていません。
■
必ずしも完全ではありません。
仮想ワークロードを正常にインポートするには、ターゲット・スキーマにディメンション情報
が含まれている必要があります。この場合、IMPORT_SQLWKLD_SCHEMA プロシージャを使用
します。この構文は、次のとおりです。
DBMS_ADVISOR.IMPORT_SQLWKLD_SCHEMA (
workload_name
IN VARCHAR2,
import_mode
IN VARCHAR2 := 'NEW',
priority
IN NUMBER := 2,
saved_rows
OUT NUMBER,
failed_rows
OUT NUMBER);
IMPORT_SQLWKLD_SCHEMA プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。この
プロシージャを使用するには、外部プロシージャを構成する必要があります。
次の例では、SCHEMA_WKLD と呼ばれる仮想ワークロードを作成し、VALID_TABLE_LIST を
sh に設定し、IMPORT_SQLWKLD_SCHEMA をコールして仮想ワークロードを生成します。
VARIABLE workload_name VARCHAR2(255);
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
EXECUTE :workload_name := 'SCHEMA_WKLD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:workload_name);
EXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER (:workload_name, VALID_TABLE_LIST, 'SH');
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_SCHEMA ( :workload_name, 'NEW', 2, :saved_stmts, :failed_stmts);
IMPORT_SQLWKLD_SCHEMA を使用する場合、VALID_TABLE_LIST パラメータには、SCO% や
SCOTT.EMP% などのワイルドカードは使用できません。サポートされているワイルドカードの
形式は、特定のスキーマ内のすべての表を指定する SCOTT.% のみです。
SQL アクセス・アドバイザ
17-13
SQL アクセス・アドバイザの使用方法
Oracle Database 9i サマリー・アドバイザのワークロードの使用方法 Oracle Database 9i サマ
リー・アドバイザを使用してワークロードを作成したとします。これらのワークロードを SQL
アクセス・アドバイザにより使用できるようにするには、IMPORT_SQLWLD_SUMADV プロシー
ジャを使用してこれらをインポートします。このプロシージャを使用するには、Oracle
Database 9i のワークロード ID を知っている必要があります。
このプロシージャは、SQL ワークロードをサマリー・アドバイザのワークロードから収集しま
す。このプロシージャは、Oracle Database 9i サマリー・アドバイザのユーザーによる SQL ア
クセス・アドバイザへの移行をサポートすることを目的としています。この構文は、次のとお
りです。
DBMS_ADVISOR.IMPORT_SQLWKLD_SUMADV (
workload_name
IN VARCHAR2,
import_mode
IN VARCHAR2 := 'NEW',
priority
IN NUMBER := 2,
sumadv_id
IN NUMBER,
saved_rows
OUT NUMBER,
failed_rows
OUT NUMBER);
IMPORT_SQLWKLD_SUMADV プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
次の例では、Oracle Database 9i サマリー・アドバイザのワークロードから SQL ワークロード
を作成します。Oracle Database 9i のワークロードの workload_id は、777 です。
1.
変数を作成します。
VARIABLE workload_name VARCHAR2(255);
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
2.
WKLD_9I という名前のワークロードを作成します。
EXECUTE :workload_name := 'WKLD_9I';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:workload_name);
3.
Oracle Database 9i サマリー・アドバイザからワークロードをインポートします。
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_SUMADV ( :workload_name, 'NEW', 2, 777, :saved_stmts, :failed_stmts);
SQL アクセス・アドバイザのワークロードのパラメータ ロード時に SQL ワークロードにフィ
ルタをかけるには、SET_SQLWKLD_PARAMETER を使用して『Oracle Database PL/SQL パッ
ケージ・プロシージャおよびタイプ・リファレンス』に記載されている 1 つ以上のパラメータ
を設定します。
次の例は、SQL ワークロードのパラメータの設定を示しています。ここでは、SQL_LIMIT を
3、ORDER_LIST を OPTIMIZER_COST に設定します。つまり、ワークロードのインポート時に
は、文は OPTIMIZER_COST で順序付けられ、上位 3 つの文が保持されます。
-- Order statements by OPTIMIZER_COST
EXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER ( 'MYWORKLOAD', 'ORDER_LIST', 'OPTIMIZER_COST');
-- Max number of statements 3
EXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER('MYWORKLOAD', 'SQL_LIMIT', 3);
17-14
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
ワークロードへの SQL 文の追加
ワークロードをインポートするもう 1 つの方法は、SQL 文を手動で指定し、
ADD_SQLWKLD_STATEMENT プロシージャを使用してこれらをワークロードに追加する方法で
す。このプロシージャは、指定されたワークロードに SQL 文を追加します。この構文は、次の
とおりです。
DBMS_ADVISOR.ADD_SQLWKLD_STATEMENT (
workload_name
IN VARCHAR2,
module
IN VARCHAR2,
action
IN VARCHAR2,
cpu_time
IN NUMBER := 0,
elapsed_time
IN NUMBER := 0,
disk_reads
IN NUMBER := 0,
buffer_gets
IN NUMBER := 0,
rows_processed
IN NUMBER := 0,
optimizer_cost
IN NUMBER := 0,
executions
IN NUMBER := 1,
priority
IN NUMBER := 2,
last_execution_date IN DATE := 'SYSDATE',
stat_period
IN NUMBER := 0,
username
IN VARCHAR2,
sql_text
IN CLOB);
ADD_SQLWKLD_STATEMENT プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。次の
例では、MYWORKLOAD ワークロードに文を 1 つ追加します。
VARIABLE sql_text VARCHAR2(400);
EXECUTE :sql_text := 'SELECT AVG(amount_sold) FROM sales';
EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_STATEMENT ( 'MYWORKLOAD', 'MONTHLY', 'ROLLUP', priority=>1, executions=>10, username => 'SH', sql_text => :sql_text);
ワークロードの SQL 文の削除
既存の SQL 文を特定のワークロードから削除するには、DELETE_SQLWKLD_STATEMENT プロ
シージャを使用します。このプロシージャでは、sql_id によって指定した文を削除できます。
DBMS_ADVISOR.DELETE_SQLWKLD_STATEMENT (workload_name
sql_id
IN VARCHAR2,
IN NUMBER);
次の例では、sql_id が 10 の文を MYWORKLOAD から削除します。
EXECUTE DBMS_ADVISOR.DELETE_SQLWKLD_STATEMENT('MYWORKLOAD', 10);
ワークロードが現在アクティブなタスクによって参照されている場合、このワークロードは変
更または削除できません。タスクは、初期状態にない場合アクティブであるとみなされます。
タスクを初期状態に設定する方法の詳細は、RESET_TASK プロシージャを参照してください。
DELETE_SQLWKLD_STATEMENT プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
SQL アクセス・アドバイザ
17-15
SQL アクセス・アドバイザの使用方法
ワークロードの SQL 文の変更
ワークロードの SQL 文を変更するには、UPDATE_SQLWKLD_STATEMENT プロシージャを使用
します。このプロシージャは、指定したワークロード内の既存の SQL 文を更新します。
このプロシージャでは、sql_id を指定して SQL 文を更新できます。この構文は、次のとおり
です。
DBMS_ADVISOR.UPDATE_SQLWKLD_STATEMENT (
workload_name
IN VARCHAR2,
sql_id
IN NUMBER,
application
IN VARCHAR2 := NULL,
action
IN VARCHAR2 := NULL,
priority
IN NUMBER := NULL,
username
IN VARCHAR2 := NULL);
DBMS_ADVISOR.UPDATE_SQLWKLD_STATEMENT (
workload_name
IN VARCHAR2,
search
IN VARCHAR2,
updated
OUT NUMBER,
application
IN VARCHAR2 := NULL,
action
IN VARCHAR2 := NULL,
priority
IN NUMBER := NULL,
username
IN VARCHAR2 := NULL);
次の例では、ID が 10 の文の優先順位を 3 に変更します。
EXECUTE DBMS_ADVISOR.UPDATE_SQLWKLD_STATEMENT('MYWORKLOAD', 10, priority=>3);
UPDATE_SQLWKLD_STATEMENT プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ワークロードのメンテナンス
ワークロードまたは実行可能なその他の操作には、次のようなものがあります。
■
ワークロード属性の設定
■
ワークロードのリセット
■
ワークロードとタスク間のリンクの削除
ワークロード属性の設定 UPDATE_SQLWKLD_ATTRIBUTES は、ワークロード・オブジェクト
またはテンプレートの様々な属性を変更します。これには、ワークロードの説明、ワークロー
ドがテンプレートであるか読取り専用であるかなどの属性があります。この構文は、次のとお
りです。
DBMS_ADVISOR.UPDATE_SQLWKLD_ATTRIBUTES
workload_name
IN VARCHAR2,
new_name
IN VARCHAR2 :=
description
IN VARCHAR2 :=
read_only
IN VARCHAR2 :=
is_template
IN VARCHAR2 :=
how_created
IN VARCHAR2 :=
(
NULL,
NULL,
NULL,
NULL,
NULL);
次の例では、MYWORKLOAD ワークロードを読取り専用に変更します。
EXECUTE DBMS_ADVISOR.UPDATE_SQLWKLD_ATTRIBUTES ( 'MYWORKLOAD', read_only=> 'TRUE');
UPDATE_SQLWKLD_ATTRIBUTES プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
17-16
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
ワークロードのリセット RESET_SQLWKLD プロシージャは、ワークロードを初期の開始ポイン
トにリセットします。これには、ワークロード・データに影響を与えずに、すべてのジャーナ
ルおよびログ・メッセージの削除や不安定統計の再計算を実行できる利点があります。このプ
ロシージャは、SQL 文の追加や削除などのワークロード調整の後に実行する必要があります。
次の例では、MYWORKLOAD ワークロードをリセットします。
EXECUTE DBMS_ADVISOR.RESET_SQLWKLD('MYWORKLOAD');
RESET_SQLWKLD プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッ
ケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ワークロードとタスク間のリンクの削除 タスクまたはワークロードがそれぞれワークロードま
たはタスクにリンクされている場合、これらを削除する前に、DELETE_SQLWKLD_REF プロ
シージャを使用して、タスクとワークロード間のリンクを削除する必要があります。次の例で
は、MYTASK タスクと MYWORKLOAD SQL ワークロード間のリンクを削除します。
EXECUTE DBMS_ADVISOR.DELETE_SQLWKLD_REF('MYTASK', 'MYWORKLOAD');
ワークロードの削除
ワークロードが必要なくなった場合、DELETE_SQLWKLD プロシージャを使用してこれらを削除
できます。すべてのワークロードまたは特定の収集を削除できますが、ワークロードがタスク
にリンクされている場合は削除できません。
次のプロシージャは、特定のワークロードの削除例です。ここでは、リポジトリから既存の
ワークロードを削除します。
DBMS_ADVISOR.DELETE_SQLWKLD (workload_name IN VARCHAR2);
EXECUTE DBMS_ADVISOR.DELETE_SQLWKLD('MYWORKLOAD');
DELETE_SQLWKLD プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッ
ケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
推奨事項の処理
この項では、推奨事項の処理に関する次の側面について説明します。
■
推奨オプション
■
評価モード
■
推奨事項の生成
■
推奨事項の表示
■
SQL ワークロードのジャーナル
■
推奨プロセスの停止
■
推奨事項のマーキング
■
推奨事項の変更
■
SQL スクリプトの生成
■
推奨事項が必要なくなった場合
SQL アクセス・アドバイザ
17-17
SQL アクセス・アドバイザの使用方法
推奨オプション
推奨事項を生成する前に、SET_TASK_PARAMETER プロシージャを使用してタスクのパラメー
タを最初に定義する必要があります。パラメータを定義しない場合、デフォルト値が使用され
ます。
タスクのパラメータを設定するには、SET_TASK_PARAMETER プロシージャを使用します。こ
の構文は、次のとおりです。
DBMS_ADVISOR.SET_TASK_PARAMETER (
task_name
IN VARCHAR2,
parameter
IN VARCHAR2,
value
IN [VARCHAR2 | NUMBER]);
タスク・パラメータは多数存在するため、関連するパラメータを識別しやすいように、これら
のカテゴリ分けした表を表 17-2 に示します。
表 17-2 アドバイザのタスク・パラメータのタイプとその使用方法
ワークロードのフィルタ
タスク構成
スキーマ属性
推奨オプション
END_TIME
DAYS_TO_EXPIRE
DEF_INDEX_OWNER
DML_VOLATILITY
INVALID_ACTION_LIST
REPORT_DATE_FORMAT
DEF_INDEX_TABLESPACE
EVALUATION_ONLY
INVALID_MODULE_LIST
JOURNALING
DEF_MVIEW_OWNER
EXECUTION_TYPE
INVALID_SQLTRING_LIMIT
DEF_MVIEW_TABLESPACE
MODE
INVALID_TABLE_LIST
DEF_MVLOG_TABLSPACE
REFRESH_MODE
INVALID_USERNAME_LIST
INDEX_NAME_TEMPLATE
STORAGE_CHANGE
ORDER_LIST
MVIEW_NAME_TEMPLATE
CREATION_COST
SQL_LIMIT
WORKLOAD_SCOPE
START_TIME
TIME_LIMIT
VALID_ACTION_LIST
VALID_MODULE_LIST
VALID_SQLSTRING_LIST
VALID_TABLE_LIST
VALID_USERNAME_LIST
次の例では、MYTASK タスクの記憶域変更を 100MB に設定します。これは、推奨事項の追加領
域が 100MB であることを示します。値 0（ゼロ）は、割り当てられる追加領域がないことを示
します。マイナス値は、指定した量だけアドバイザが現在の領域使用量を削減する必要がある
ことを示しています。
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER('MYTASK','STORAGE_CHANGE', 100000000);
次の例では、SH.SALES および SH.CUSTOMERS 表を構成していないすべての問合せを、フィ
ルタで除外するように VALID_TABLE_LIST パラメータを設定します。
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( 'MYTASK', 'VALID_TABLE_LIST', 'SH.SALES, SH.CUSTOMERS');
SET_TASK_PARAMETER プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL
パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
17-18
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
評価モード
タスクの実行時には、SQL アクセス・アドバイザは、問題解決と評価の 2 つのモードで動作し
ます。デフォルトでは、SQL アクセス・アドバイザは、索引構造、マテリアライズド・ビュー
およびマテリアライズド・ビュー・ログの拡張機能を検索し、アクセス方法の問題を解決しよ
うとします。評価のみを行う場合、SQL アクセス・アドバイザは、指定されたワークロードが
使用するアクセス構造についてのみコメントします。たとえば、問題解決の実行では、新しい
索引の作成やマテリアライズド・ビュー・ログへの新しい列の追加などが推奨されますが、評
価のみのシナリオでは、索引の保持やマテリアライズド・ビューの保持などの推奨事項のみが
生成されます。評価を行う場合、アクセス方法の調整は考慮されません。評価では、既存のア
クセス方法構造の参照や、指定されたワークロードによるこれらの使用方法の参照のみを行い
ます。
推奨事項の生成
推奨事項を生成するには、タスク名とともに EXECUTE_TASK プロシージャを使用します。プ
ロシージャが終了した後、DBA_ADVISOR_LOG 表をチェックし、実際の実行ステータスや、生
成された推奨事項およびアクションの数を確認できます。推奨事項は
{DBA, USER}_ADVISOR_RECOMMENDATIONS でタスク名別に問い合せることができ、これら
推奨事項のアクションは {DBA, USER}_ADVISOR_ACTIONS でタスク別に表示されます。
EXECUTE_TASK プロシージャ このプロシージャでは、特定のタスクに対する SQL アクセス・ア
ドバイザの分析または評価を実行します。タスク実行は同期操作であるため、操作が完了する
か、ユーザー割込みが検出されるまで制御がユーザーに戻されません。タスクの実行が戻され
ると、実際の実行ステータスについて DBA_ADVISOR_LOG 表をチェックできます。
EXECUTE_TASK を実行すると、推奨事項が生成されます。この場合、推奨事項は、マテリアラ
イズド・ビュー・ログやマテリアライズド・ビューの作成などの 1 つ以上のアクションから構
成されます。この構文は、次のとおりです。
DBMS_ADVISOR.EXECUTE_TASK (task_name
IN VARCHAR2);
次に、このプロシージャの使用例を示します。
EXECUTE DBMS_ADVISOR.EXECUTE_TASK('MYTASK');
EXECUTE_TASK プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッケー
ジ・プロシージャおよびタイプ・リファレンス』を参照してください。
推奨事項の表示
SQL アクセス・アドバイザによって生成された各推奨事項は、
(DBA, USER)_ADVISOR_RECOMMENDATIONS などのいくつかのカタログ・ビューを使用して表
示されます。ただし、GET_TASK_SCRIPT プロシージャを使用するか、または Enterprise
Manager で SQL アクセス・アドバイザを使用する方が簡単です。この場合、推奨事項がグラ
フィック表示され、推奨事項が有用となる SQL 文を簡単に参照するためのハイパーリンクが用
意されています。SQL アクセス・アドバイザによって生成された各推奨事項は、推奨事項に
よってできる SQL 文にリンクされています。
次の例は、アドバイザの実行によって生成される推奨事項（rec_id）とそのランクおよび全利
点を示します。ランクとは、推奨事項がサポートする問合せの重要性の尺度です。利点とは、
推奨事項を使用したすべての問合せの実行コスト（オプティマイザのコストの観点から）にお
ける改善結果です。
VARIABLE workload_name VARCHAR2(255);
VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'MYTASK';
EXECUTE :workload_name := 'MYWORKLOAD';
SELECT REC_ID, RANK, BENEFIT
FROM USER_ADVISOR_RECOMMENDATIONS WHERE TASK_NAME = :task_name;
SQL アクセス・アドバイザ
17-19
SQL アクセス・アドバイザの使用方法
REC_ID
RANK
BENEFIT
---------- ---------- ---------1
2
2754
2
3
1222
3
1
5499
4
4
594
推奨事項が役立つ問合せを確認するには、DBA_* および USER_ADVISOR_SQLA_WK_STMTS
ビューを使用します。事前コストと事後コストの数は、それぞれ推奨されたアクセス構造の変
更がある場合とない場合とで見積もられたオプティマイザのコスト（EXPLAIN PLAN を参照）
に関するものです。各問合せの推奨事項を表示するには、次の文を発行します。
SELECT sql_id, rec_id, precost, postcost,
(precost-postcost)*100/precost AS percent_benefit
FROM USER_ADVISOR_SQLA_WK_STMTS
WHERE TASK_NAME = :task_name AND workload_name = :workload_name;
SQL_ID
REC_ID
PRECOST
POSTCOST PERCENT_BENEFIT
---------- ---------- ---------- ---------- --------------121
1
3003
249
91.7082917
122
2
1404
182
87.037037
123
3
5503
4
99.9273124
124
4
730
136
81.369863
各推奨事項は 1 つ以上のアクションから構成されます。推奨事項の利点を得るには、これらの
アクションをまとめて実装する必要があります。SQL アクセス・アドバイザでは、次のタイプ
のアクションを生成します。
■
CREATE|DROP|RETAIN MATERIALIZED VIEW
■
CREATE|ALTER|RETAIN MATERIALIZED VIEW LOG
■
CREATE|DROP|RETAIN INDEX
■
GATHER STATS
CREATE アクションは、新しいアクセス構造に対応します。RETAIN 推奨事項は、既存のアク
セス構造を維持する必要があることを示します。DROP 推奨事項が生成されるのは、
WORKLOAD_SCOPE パラメータが FULL に設定されている場合のみです。GATHER STATS アク
ションは、DBMS_STATS プロシージャへのコールを生成し、新しく生成されたアクセス構造に
関する統計を収集します。複数の推奨事項が同じアクションを参照していることがありますが、
推奨事項のスクリプトの生成時に 1 回のみ各アクションが表示されます。
次の例では、この一連の推奨事項について個別アクションの数を確認できます。
SELECT 'Action Count', COUNT(DISTINCT action_id) cnt
FROM user_advisor_actions WHERE task_name = :task_name;
'ACTIONCOUNT
CNT
------------ ---------Action Count
20
-- see the actions for each recommendations
SELECT rec_id, action_id, SUBSTR(command,1,30) AS command
FROM user_advisor_actions WHERE task_name = :task_name
ORDER BY rec_id, action_id;
REC_ID ACTION_ID COMMAND
---------- ---------- -----------------------------1
5 CREATE MATERIALIZED VIEW LOG
1
6 ALTER MATERIALIZED VIEW LOG
1
7 CREATE MATERIALIZED VIEW LOG
1
8 ALTER MATERIALIZED VIEW LOG
1
9 CREATE MATERIALIZED VIEW LOG
1
10 ALTER MATERIALIZED VIEW LOG
1
11 CREATE MATERIALIZED VIEW
17-20
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
1
1
1
2
2
2
...
12
19
20
5
6
9
GATHER TABLE STATISTICS
CREATE INDEX
GATHER INDEX STATISTICS
CREATE MATERIALIZED VIEW LOG
ALTER MATERIALIZED VIEW LOG
CREATE MATERIALIZED VIEW LOG
各アクションには、アクセス構造のプロパティに関連する複数の属性があります。各アクセス
構造の名前と表領域は、必要に応じて attr1 および attr2 にそれぞれ格納されます。新しい
各アクセス構造が占有する領域は、num_attr1 にあります。その他すべての属性は、アクショ
ンごとに異なります。
表 17-3 では、SQL アクセス・アドバイザのアクション情報を DBA_ADVISOR_ACTIONS 内の該
当する列にマップします。
表 17-3 SQL アクセス・アドバイザのアクション属性
ATTR1
ATTR2
ATTR3
ATTR4
ATTR5
ATTR6
CREATE INDEX
索引名
索引表領域 ターゲット
表
BITMAP または 索引列
未使用
BTREE
リスト / 式
索引の記憶域
のサイズ
（バイト単位）
CREATE
MATERIALIZED
VIEW
MV 名
MV 表領域 REFRESH
COMPLETE
REFRESH
FAST、
REFRESH
FORCE、
NEVER
REFRESH
ENABLE QUERY SQL
REWRITE、
SELECT 文
DISABLE
QUERY
REWRITE
MV の記憶域
のサイズ
（バイト単位）
CREATE
MATERIALIZED
VIEW LOG
ターゲット MVログ
表名
表領域
ROWID
PRIMARY
KEY、
SEQUENCE
OBJECT ID
INCLUDING
NEW
VALUES、
EXCLUDING
NEW VALUES
表列リスト
CREATE
REWRITE
EQUIVALENCE
等価名
チェック
サム値
未使用
未使用
ソース SQL 等価 SQL 文
文
DROP INDEX
索引名
未使用
未使用
未使用
索引列
未使用
索引の記憶域
のサイズ
（バイト単位）
DROP
MATERIALIZED
VIEW
MV 名
未使用
未使用
未使用
未使用
未使用
MV の記憶域
のサイズ
（バイト単位）
DROP
MATERIALIZED
VIEW LOG
ターゲット 未使用
表名
未使用
未使用
未使用
未使用
RETAIN INDEX
索引名
未使用
ターゲット
表
BITMAP または 索引列
BTREE
未使用
索引の記憶域
のサイズ
（バイト単位）
RETAIN
MATERIALIZED
VIEW
MV 名
未使用
REFRESH
COMPLETE
または
REFRESH
FAST
未使用
SQL
SELECT 文
未使用
MV の記憶域
のサイズ
（バイト単位）
RETAIN
MATERIALIZED
VIEW LOG
ターゲット 未使用
表名
未使用
未使用
未使用
未使用
未使用
NUM_ATTR1
パーティション 未使用
副次句
未使用
未使用
未使用
SQL アクセス・アドバイザ
17-21
SQL アクセス・アドバイザの使用方法
次の PL/SQL プロシージャを使用して、推奨事項の属性を出力できます。
CONNECT SH/SH;
CREATE OR REPLACE PROCEDURE show_recm (in_task_name IN VARCHAR2) IS
CURSOR curs IS
SELECT DISTINCT action_id, command, attr1, attr2, attr3, attr4
FROM user_advisor_actions
WHERE task_name = in_task_name
ORDER BY action_id;
v_action
number;
v_command
VARCHAR2(32);
v_attr1
VARCHAR2(4000);
v_attr2
VARCHAR2(4000);
v_attr3
VARCHAR2(4000);
v_attr4
VARCHAR2(4000);
v_attr5
VARCHAR2(4000);
BEGIN
OPEN curs;
DBMS_OUTPUT.PUT_LINE('=========================================');
DBMS_OUTPUT.PUT_LINE('Task_name = ' || in_task_name);
LOOP
FETCH curs INTO
v_action, v_command, v_attr1, v_attr2, v_attr3, v_attr4 ;
EXIT when curs%NOTFOUND;
DBMS_OUTPUT.PUT_LINE('Action ID: ' || v_action);
DBMS_OUTPUT.PUT_LINE('Command : ' || v_command);
DBMS_OUTPUT.PUT_LINE('Attr1 (name)
: ' || SUBSTR(v_attr1,1,30));
DBMS_OUTPUT.PUT_LINE('Attr2 (tablespace): ' || SUBSTR(v_attr2,1,30));
DBMS_OUTPUT.PUT_LINE('Attr3
: ' || SUBSTR(v_attr3,1,30));
DBMS_OUTPUT.PUT_LINE('Attr4
: ' || v_attr4);
DBMS_OUTPUT.PUT_LINE('Attr5
: ' || v_attr5);
DBMS_OUTPUT.PUT_LINE('----------------------------------------');
END LOOP;
CLOSE curs;
DBMS_OUTPUT.PUT_LINE('=========END RECOMMENDATIONS============');
END show_recm;
/
-- see what the actions are using sample procedure
set serveroutput on size 99999
EXECUTE show_recm(:task_name);
A fragment of a sample output from this procedure is as follows:
Task_name = MYTASK
Action ID: 1
Command : CREATE MATERIALIZED VIEW LOG
Attr1 (name)
: "SH"."CUSTOMERS"
Attr2 (tablespace):
Attr3
: ROWID, SEQUENCE
Attr4
: INCLUDING NEW VALUES
Attr5
:
---------------------------------------..
---------------------------------------Action ID: 15
Command : CREATE MATERIALIZED VIEW
Attr1 (name)
: "SH"."SH_MV$$_0004"
Attr2 (tablespace): "SH_MVIEWS"
Attr3
: REFRESH FAST WITH ROWID
Attr4
: ENABLE QUERY REWRITE
Attr5
:
---------------------------------------..
---------------------------------------Action ID: 19
Command : CREATE INDEX
17-22
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
Attr1 (name)
:
Attr2 (tablespace):
Attr3
:
Attr4
:
Attr5
:
"SH"."SH_IDX$$_0013"
"SH_INDEXES"
"SH"."SH_MV$$_0002"
BITMAP
Attr5 および Attr6 の詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよび
タイプ・リファレンス』を参照してください。
SQL ワークロードのジャーナル
分析プロセス（EXECUTE_TASK）の処理時に、SQL アクセス・アドバイザにより、分析に関し
て役に立つ情報がジャーナルに保存されます。ジャーナルを表示するには、
USER_ADVISOR_JOURNAL ビューを使用します。情報の出力量は、JOURNALING タスク・パラ
メータの設定に応じて異なります。
ワークロードのインポート時には、様々な情報メッセージが SQL ワークロードのジャーナルに
記録されます。これらのジャーナルを表示するには、USER_ADVISOR_SQLW_JOURNAL を使用
します。ジャーナルは、文がフィルタによってワークロードから除外された理由を特定すると
きに役に立ちます。たとえば、特定の SQL 文が無効な表や統計が欠落している表を参照してい
る場合や、特定の SQL 文に権限エラーがある場合、この情報がジャーナルに記録されます。情
報の出力量は、JOURNALING パラメータの設定によって制御されます。
ジャーナルへの記録をオフにするには、次の文を発行します。
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER('MYTASK', 'JOURNALING', 0);
ワークロードをインポートする前にジャーナルへの記録をオフにするには、次の文を発行しま
す。
EXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER('MYWORKLOAD', 'JOURNALING', 0);
情報メッセージのみを表示するには、次の文を発行します。
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER('MYTASK', 'JOURNALING', 4);
致命的メッセージのみを表示するには、次の文を発行します。
EXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER('MYWORKLOAD', 'JOURNALING', 1);
ジャーナル内の情報は診断のみを目的としており、将来のリリースでは変更される場合があり
ます。ジャーナル内の情報は、アプリケーション内で使用しないでください。
JOURNALING パラメータのすべての設定の詳細は、
『Oracle Database PL/SQL パッケージ・プ
ロシージャおよびタイプ・リファレンス』を参照してください。
推奨プロセスの停止
SQL アクセス・アドバイザが EXECUTE_TASK プロシージャを使用して推奨を行う時間が長す
ぎる場合、これを停止できます。停止するには、CANCEL_TASK プロシージャをコールし、こ
の推奨プロセスの task_name を渡します。CANCEL_TASK を使用すると、推奨は行われませ
ん。また、推奨プロセスに割り込むには、INTERRUPT_TASK プロシージャを使用します。
タスクへの割込み INTERRUPT_TASK プロシージャを使用すると、アドバイザ操作は通常の終
了に達したものとして終了されます。これにより、ユーザーには、割込みポイントまでに形成
された推奨事項が表示されます。
割り込まれたタスクは再開できません。この構文は、次のとおりです。
DBMS_ADVISOR.INTERRUPT_TASK (task_name IN VARCHAR2);
次に、このプロシージャの使用例を示します。
EXECUTE DBMS_ADVISOR.INTERRUPT_TASK ('MY_TASK');
SQL アクセス・アドバイザ
17-23
SQL アクセス・アドバイザの使用方法
タスクの取消 CANCEL_TASK プロシージャを使用すると、現在実行中の操作が終了します。こ
の場合、アドバイザ操作がコールに応答するのに数秒かかることがあります。すべてのアドバ
イザ・タスクのプロシージャは同期操作であるため、操作を取り消すには、別のデータベー
ス・セッションを使用する必要があります。
取消コマンドは、取り消された操作の開始前の状態にタスクを効率的にリストアします。この
ため、取り消されたタスクまたはデータ・オブジェクトはリストアできません。この構文は、
次のとおりです。
DBMS_ADVISOR.CANCEL_TASK (task_name
IN
VARCHAR2);
次に、このプロシージャの使用例を示します。
EXECUTE DBMS_ADVISOR.CANCEL_TASK('MYTASK');
CANCEL_TASK プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッケー
ジ・プロシージャおよびタイプ・リファレンス』を参照してください。
推奨事項のマーキング
デフォルトでは、SQL アクセス・アドバイザのすべての推奨事項は実装可能な状態にあります
が、MARK_RECOMMENDATION プロシージャを使用すると、選択した推奨事項をスキップまたは
除外できます。MARK_RECOMMENDATION を使用すると、REJECT または IGNORE 設定で推奨事
項に注釈をつけることができます。これにより、プロシージャの実装時に GET_TASK_SCRIPT
によってこの推奨事項はスキップされます。この構文は、次のとおりです。
DBMS_ADVISOR.MARK_RECOMMENDATION (
task_name
IN VARCHAR2
id
IN NUMBER,
action
IN VARCHAR2);
次の例では、ID が 2 の推奨事項を REJECT としてマークします。この推奨事項と任意の依存推
奨事項は、スクリプトに表示されません。
EXECUTE DBMS_ADVISOR.MARK_RECOMMENDATION('MYTASK', 2, 'REJECT');
MARK_RECOMMENDATIONS プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
推奨事項の変更
UPDATE_REC_ATTRIBUTES プロシージャを使用すると、SQL アクセス・アドバイザにより、
分析操作時に索引やマテリアライズド・ビューなどの新しいオブジェクトに名前が付けられ、
所有権が割り当てられます。ただし、必ずしも適切な名前が選択されるとはかぎらないため、
新しいオブジェクトの所有者、名前および表領域の値を手動で設定できます。既存のデータ
ベース・オブジェクトを参照している推奨事項の場合、所有者と名前の値は変更できません。
この構文は、次のとおりです。
DBMS_ADVISOR.UPDATE_REC_ATTRIBUTES (
task_name
IN VARCHAR2
rec_id
IN NUMBER,
action_id
IN NUMBER,
attribute_name
IN VARCHAR2,
value
IN VARCHAR2);
attribute_name パラメータには、次の値を使用できます。
■
OWNER
推奨オブジェクトの所有者名を指定します。
■
NAME
推奨オブジェクトの名前を指定します。
■
TABLESPACE
推奨オブジェクトの表領域を指定します。
17-24
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
次の例では、推奨事項 ID 1、アクション ID 1 の TABLESPACE 属性を SH_MVIEWS に変更しま
す。
EXECUTE DBMS_ADVISOR.UPDATE_REC_ATTRIBUTES('MYTASK', 1, 1, 'TABLESPACE', 'SH_MVIEWS');
UPDATE_REC_ATTRIBUTES プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
SQL スクリプトの生成
推奨事項を表示するためにメタデータを問い合せるもう 1 つの方法は、GET_TASK_SCRIPT プ
ロシージャを使用して推奨事項の SQL 文のスクリプトを作成する方法です。この結果生成され
るスクリプトは実行可能 SQL ファイルで、DROP、CREATE および ALTER 文を含めることがで
きます。新しいオブジェクトの場合、マテリアライズド・ビューの名前、マテリアライズド・
ビュー・ログおよび索引は、ユーザー指定の名前テンプレートを使用して自動的に生成されま
す。生成された SQL スクリプトは、実行する前に見直す必要があります。
ネーミング規則（MVIEW_NAME_TEMPLATE および INDEX_NAME_TEMPLATE）、これらの新し
いオブジェクトの所有者（DEF_INDEX_OWNER および DEF_MVIEW_OWNER）
、表領域
（DEF_MVIEW_TABLESPACE および DEF_INDEX_TABLESPACE）を制御するタスク・パラメー
タは 4 つあります。
次の例は、推奨事項のスクリプトが含まれる CLOB を生成する方法を示します。
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT('MYTASK'), 'ADVISOR_RESULTS', 'advscript.sql');
スクリプトをファイルに保存するには、CREATE_FILE プロシージャにスクリプトの格納先を
示すディレクトリ・パスを指定する必要があります。また、このディレクトリには読取りおよ
び書込み権限を付与する必要があります。次の例は、CLOB アドバイザ・スクリプトをファイル
に保存する方法を示します。
-- create a directory and grant permissions to read/write to it
CONNECT SH/SH;
CREATE DIRECTORY ADVISOR_RESULTS AS '/mydir';
GRANT READ ON DIRECTORY ADVISOR_RESULTS TO PUBLIC;
GRANT WRITE ON DIRECTORY ADVISOR_RESULTS TO PUBLIC;
次の例は、このスクリプトによって生成されたスクリプトのフラグメントです。また、このス
クリプトには、推奨されたアクセス構造に関する統計を収集する PL/SQL コールが含まれ、最
後に推奨事項を IMPLEMENTED としてマークします。
Rem Access Advisor V10.1.0.0.0 - Production
Rem
Rem Username:
SH
Rem Task:
MYTASK
Rem Execution date: 15/04/2005 11:35
Rem
set feedback 1
set linesize 80
set trimspool on
set tab off
set pagesize 60
whenever sqlerror CONTINUE
CREATE MATERIALIZED VIEW LOG ON "SH"."PRODUCTS"
WITH ROWID, SEQUENCE("PROD_ID","PROD_SUBCATEGORY")
INCLUDING NEW VALUES;
ALTER MATERIALIZED VIEW LOG FORCE ON "SH"."PRODUCTS"
ADD ROWID, SEQUENCE("PROD_ID","PROD_SUBCATEGORY")
INCLUDING NEW VALUES;
..
CREATE MATERIALIZED VIEW "SH"."MV$$_00510002"
REFRESH FAST WITH ROWID
SQL アクセス・アドバイザ
17-25
SQL アクセス・アドバイザの使用方法
ENABLE QUERY REWRITE
AS SELECT SH.CUSTOMERS.CUST_STATE_PROVINCE C1, COUNT(*) M1 FROM
SH.CUSTOMERS WHERE (SH.CUSTOMERS.CUST_STATE_PROVINCE = 'CA') GROUP
BY SH.CUSTOMERS.CUST_STATE_PROVINCE;
BEGIN
DBMS_STATS.GATHER_TABLE_STATS('"SH"', '"MV$$_00510002"', NULL,
DBMS_STATS.AUTO_SAMPLE_SIZE);
END;
/
..
CREATE BITMAP INDEX "SH"."MV$$_00510004_IDX$$_00510013"
ON "SH"."MV$$_00510004" ("C4");
whenever sqlerror EXIT SQL.SQLCODE
BEGIN
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',1,'IMPLEMENTED');
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',2,'IMPLEMENTED');
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',3,'IMPLEMENTED');
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',4,'IMPLEMENTED');
END;
/
関連項目 : CREATE DIRECTORY 構文の詳細は『Oracle Database SQL 言
語リファレンス』を、GET_TASK_SCRIPT プロシージャの詳細は『Oracle
Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレン
ス』を参照してください。
推奨事項が必要なくなった場合
RESET_TASK プロシージャは、タスクを初期の開始ポイントにリセットします。これにより、
すべての推奨事項と中間データがタスクから削除されます。実際のタスクのステータスは、
INITIAL に設定されます。この構文は、次のとおりです。
DBMS_ADVISOR.RESET_TASK (task_name
IN VARCHAR2);
次に、このプロシージャの使用例を示します。
EXECUTE DBMS_ADVISOR.RESET_TASK('MYTASK');
RESET_TASK プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッケー
ジ・プロシージャおよびタイプ・リファレンス』を参照してください。
17-26
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
クイック・チューニングの実行
単一の SQL 文のみをチューニングする場合、QUICK_TUNE プロシージャでは、task_name と
SQL 文を入力できます。次に、タスクとワークロードが作成され、このタスクが実行されま
す。QUICK_TUNE を使用しても、結果に違いはありません。結果は EXECUTE_TASK を使用す
る場合とまったく同じです。チューニング対象の SQL 文が 1 つのみである場合、この方法を使
用した方が簡単です。この構文は、次のとおりです。
DBMS_ADVISOR.QUICK_TUNE (
advisor_name
IN VARCHAR2,
task_name
IN VARCHAR2,
attr1
IN CLOB,
attr2
IN VARCHAR2 := NULL,
attr3
IN NUMBER := NULL,
task_or_template
IN VARCHAR2 := NULL);
次の例は、単一の SQL 文をクイック・チューニングする方法を示しています。
VARIABLE task_name VARCHAR2(255);
VARIABLE sql_stmt VARCHAR2(4000);
EXECUTE :sql_stmt := 'SELECT COUNT(*) FROM customers
WHERE cust_state_province=''CA''';
EXECUTE :task_name := 'MY_QUICKTUNE_TASK';
EXECUTE DBMS_ADVISOR.QUICK_TUNE(DBMS_ADVISOR.SQLACCESS_ADVISOR, :task_name, :sql_stmt);
QUICK_TUNE プロシージャとそのパラメータの詳細は、『Oracle Database PL/SQL パッケー
ジ・プロシージャおよびタイプ・リファレンス』を参照してください。
タスクの管理
推奨事項が生成されるたびにタスクが作成され、それらのタスクに対してメンテナンスが実行
されない場合、タスク数は時間の経過とともに増加し、記憶域領域を占めるようになります。
タスクの中には、誤って削除しないように保持する必要のあるタスクがある場合もあります。
このため、タスクに対して実行可能な管理操作がいくつか用意されています。
■
タスク属性の更新
■
タスクの削除
■
DAYS_TO_EXPIRE パラメータの設定
タスク属性の更新
UPDATE_TASK_ATTRIBUTES プロシージャを使用すると、次の操作ができます。
■
タスク名の変更
■
タスクの説明の付加
■
タスクの読取り専用（変更不可）設定
■
他のタスクの定義に使用するタスク・テンプレートの作成
■
タスクやタスク・テンプレートの様々な属性の変更
この構文は、次のとおりです。
DBMS_ADVISOR.UPDATE_TASK_ATTRIBUTES (
task_name
IN VARCHAR2
new_name
IN VARCHAR2 := NULL,
description
IN VARCHAR2 := NULL,
read_only
IN VARCHAR2 := NULL,
is_template
IN VARCHAR2 := NULL,
how_created
IN VARCHAR2 := NULL);
SQL アクセス・アドバイザ
17-27
SQL アクセス・アドバイザの使用方法
次の例では、タスク MYTASK の名前が TUNING1 に更新されます。
EXECUTE DBMS_ADVISOR.UPDATE_TASK_ATTRIBUTES('MYTASK', 'TUNING1');
次の例では、タスク TUNING1 が読取り専用に設定されます。
EXECUTE DBMS_ADVISOR.UPDATE_TASK_ATTRIBUTES('TUNING1', read_only => 'TRUE');
次の例では、タスク MYTASK がテンプレートとして設定されます。
EXECUTE DBMS_ADVISOR.UPDATE_TASK_ATTRIBUTES('TUNING1', is_template=>'TRUE');
UPDATE_TASK_ATTRIBUTES プロシージャとそのパラメータの詳細は、『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
タスクの削除
DELETE_TASK プロシージャでは、アドバイザの既存のタスクがリポジトリから削除されます。
この構文は、次のとおりです。
DBMS_ADVISOR.DELETE_TASK (task_name
IN VARCHAR2);
次に、このプロシージャの使用例を示します。
EXECUTE DBMS_ADVISOR.DELETE_TASK('MYTASK');
DELETE_TASK プロシージャとそのパラメータの詳細は、
『Oracle Database PL/SQL パッケー
ジ・プロシージャおよびタイプ・リファレンス』を参照してください。
DAYS_TO_EXPIRE パラメータの設定
タスクやワークロード・オブジェクトが作成されると、パラメータ DAYS_TO_EXPIRE が 30 に
設定されます。この値は、タスクやオブジェクトがシステムによって自動的に削除されるまで
の日数を示しています。タスクやワークロードを無期限に保持するには、DAYS_TO_EXPIRE パ
ラメータを ADVISOR_UNLIMITED に設定する必要があります。
SQL アクセス・アドバイザの定数の使用方法
SQL アクセス・アドバイザでは、表 17-4 に示されている定数を使用できます。
表 17-4 SQL アクセス・アドバイザの定数
定数
説明
ADVISOR_ALL
すべての可能な値を示すために使用する値。文字列パラメータでは、この値はワイルドカード文字で
ある % と同等です。
ADVISOR_CURRENT
現在の時刻またはアクティブな要素セットを示します。通常、これは時間パラメータで使用します。
ADVISOR_DEFAULT
デフォルト値を示します。通常、タスクまたはワークロード・パラメータの設定時に使用します。
ADVISOR_UNLIMITED
無制限な数値を表す値です。
ADVISOR_UNUSED
未使用のエンティティを表す値。パラメータが ADVISOR_UNUSED に設定されている場合、現在の操
作には影響しません。通常、この値はパラメータを依存操作に対して未使用に設定するために使用し
ます。
SQLACCESS_GENERAL
SQL アクセスの汎用タスク・テンプレートのデフォルト名を指定します。このテンプレートでは、
DML_VOLATILITY タスク・パラメータを TRUE に、また EXECUTION_TYPE を FULL に設定します。
SQLACCESS_OLTP
SQL アクセスの OLTP タスク・テンプレートのデフォルト名を指定します。このテンプレートでは、
DML_VOLATILITY タスク・パラメータを TRUE に、また EXECUTION_TYPE を INDEX ONLY に設定
します。
SQLACCESS_WAREHOUSE
SQL アクセスのウェアハウス・タスク・テンプレートのデフォルト名を指定します。このテンプ
レートでは、DML_VOLATILITY タスク・パラメータを FALSE に、また EXECUTION_TYPE を FULL
に設定します。
SQLACCESS_ADVISOR
SQL アクセス・アドバイザの正式名称を格納します。プロシージャでアドバイザ名が引数として必
要な場合、これを使用できます。
17-28
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
SQL アクセス・アドバイザの使用例
この項では、SQL アクセス・アドバイザの一般的な使用例について説明します。Oracle
Database では、この章の例を含む aadvdemo.sql というスクリプトが提供されています。
ユーザー定義のワークロードの推奨事項
次の例では、ユーザー定義表 SH.USER_WORKLOAD からワークロードがインポートされます。
次に、MYTASK というタスクが作成され、記憶域上限が 100 MB に設定されて、タスクが実行さ
れます。PL/SQL プロシージャによって、推奨事項が印刷されます。最後にスクリプトが生成
されます。これを使用して、推奨事項を実装できます。
手順 1 USER_WORKLOAD 表の準備
次の SQL 文で、USER_WORKLOAD 表がロードされます。
CONNECT SH/SH;
-- aggregation with selection
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT
t.week_ending_day, p.prod_subcategory,
SUM(s.amount_sold) AS dollars, s.channel_id, s.promo_id
FROM sales s, times t, products p WHERE s.time_id = t.time_id
AND s.prod_id = p.prod_id AND s.prod_id > 10 AND s.prod_id < 50
GROUP BY t.week_ending_day, p.prod_subcategory,
s.channel_id, s.promo_id')
/
-- aggregation with selection
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT
t.calendar_month_desc, SUM(s.amount_sold) AS dollars
FROM
sales s , times t
WHERE
s.time_id = t.time_id
AND
s.time_id between TO_DATE(''01-JAN-2000'', ''DD-MON-YYYY'')
AND TO_DATE(''01-JUL-2000'', ''DD-MON-YYYY'')
GROUP BY t.calendar_month_desc')
/
--Load all SQL queries.
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc,
SUM(s.amount_sold) sales_amount
FROM sales s, times t, customers c, channels ch
WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id
AND s.channel_id = ch.channel_id AND c.cust_state_province = ''CA''
AND
ch.channel_desc IN (''Internet'',''Catalog'')
AND
t.calendar_quarter_desc IN (''1999-Q1'',''1999-Q2'')
GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc')
/
-- order by
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT c.country_id, c.cust_city, c.cust_last_name
FROM customers c WHERE c.country_id IN (52790, 52789)
ORDER BY c.country_id, c.cust_city, c.cust_last_name')
/
COMMIT;
CONNECT SH/SH;
set serveroutput on;
SQL アクセス・アドバイザ
17-29
SQL アクセス・アドバイザの使用方法
VARIABLE
VARIABLE
VARIABLE
VARIABLE
VARIABLE
task_id NUMBER;
task_name VARCHAR2(255);
workload_name VARCHAR2(255);
saved_stmts NUMBER;
failed_stmts NUMBER;
手順 2 ワークロード MYWORKLOAD の作成
EXECUTE :workload_name := 'MYWORKLOAD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:workload_name);
手順 3 ユーザー定義表 SH.USER_WORKLOAD からのワークロードのロード
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_USER (:workload_name, 'APPEND', 'SH', 'USER_WORKLOAD', :saved_stmts, :failed_stmts);
PRINT :saved_stmts;
PRINT :failed_stmts;
手順 4 タスク MYTASK の作成
EXECUTE :task_name := 'MYTASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK('SQL Access Advisor', :task_id, :task_name);
手順 5 タスク・パラメータの設定
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER(:task_name, 'STORAGE_CHANGE', 100);
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :task_name, 'EXECUTION_TYPE', 'INDEX_ONLY');
手順 6 ワークロードとタスクの間のリンクの作成
EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_REF(:task_name, :workload_name);
手順 7 タスクの実行
EXECUTE DBMS_ADVISOR.EXECUTE_TASK(:task_name);
手順 8 推奨事項の表示
-- See the number of recommendations and the status of the task.
SELECT rec_id, rank, benefit
FROM user_advisor_recommendations WHERE task_name = :task_name;
詳細は、17-19 ページの「推奨事項の表示」または 17-25 ページの「SQL スクリプトの生成」を
参照してください。
-- See recommendation for each query.
SELECT sql_id, rec_id, precost, postcost,
(precost-postcost)*100/precost AS percent_benefit
FROM user_advisor_sqla_wk_stmts
WHERE task_name = :task_name AND workload_name = :workload_name;
-- See the actions for each recommendations.
SELECT rec_id, action_id, SUBSTR(command,1,30) AS command
FROM user_advisor_actions
WHERE task_name = :task_name
ORDER BY rec_id, action_id;
-- See what the actions are using sample procedure.
SET SERVEROUTPUT ON SIZE 99999
EXECUTE show_recm(:task_name);
手順 9 推奨事項を実装するためのスクリプトの生成
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(:task_name),'ADVISOR_RESULTS', 'Example1_script.sql');
17-30
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
タスク・テンプレートを使用した推奨事項の生成
次の例では、テンプレートを作成し、それを使用してタスクを作成します。次にこのタスクを
使用して、17-29 ページの「ユーザー定義のワークロードの推奨事項」と同様に、ユーザー定義
の表から推奨事項が生成されます。
CONNECT SH/SH;
VARIABLE template_id NUMBER;
VARIABLE template_name VARCHAR2(255);
手順 1 テンプレート MY_TEMPLATE の作成
EXECUTE :template_name := 'MY_TEMPLATE';
EXECUTE DBMS_ADVISOR.CREATE_TASK ( 'SQL Access Advisor',:template_id, :template_name, is_template=>'TRUE');
手順 2 テンプレート・パラメータの設定
推奨される索引およびマテリアライズド・ビューのネーミング規則を設定します。
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'INDEX_NAME_TEMPLATE', 'SH_IDX$$_<SEQ>');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'MVIEW_NAME_TEMPLATE', 'SH_MV$$_<SEQ>');
--Set default owners for recommended indexes/materialized views.
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'DEF_INDEX_OWNER', 'SH');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'DEF_MVIEW_OWNER', 'SH');
--Set default tablespace for recommended indexes/materialized views.
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'DEF_INDEX_TABLESPACE', 'SH_INDEXES');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( :template_name, 'DEF_MVIEW_TABLESPACE', 'SH_MVIEWS');
手順 3 テンプレートを使用したタスクの作成
VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'MYTASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK ( 'SQL Access Advisor', :task_id, :task_name, template => 'MY_TEMPLATE');
--See the parameter settings for task
SELECT parameter_name, parameter_value
FROM user_advisor_parameters
WHERE task_name = :task_name AND (parameter_name LIKE '%MVIEW%'
OR parameter_name LIKE '%INDEX%');
手順 4 ワークロード MYWORKLOAD の作成
VARIABLE workload_name VARCHAR2(255);
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
EXECUTE :workload_name := 'MYWORKLOAD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:workload_name);
手順 5 ユーザー定義表 SH.USER_WORKLOAD からのワークロードのロード
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_USER ( :workload_name, 'APPEND', 'SH', 'USER_WORKLOAD', :saved_stmts,:failed_stmts);
手順 6 ワークロードとタスクの間のリンクの作成
EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_REF(:task_name, :workload_name);
SQL アクセス・アドバイザ
17-31
SQL アクセス・アドバイザの使用方法
手順 7 タスクの実行
EXECUTE DBMS_ADVISOR.EXECUTE_TASK(:task_name);
手順 8 スクリプトの生成
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(:task_name),'ADVISOR_RESULTS', 'Example2_script.sql');
SQL キャッシュからのワークロードのフィルタリング
次の例では、SQL キャッシュからワークロードを収集する方法を示します。まず、一連の SQL
文でキャッシュをロードします。次に、いくつかのフィルタを設定してそれらの文のサブセッ
トのみを選択し、SQL アクセス・アドバイザのワークロードにインポートします。その後、
ワークロードを使用して、推奨事項を生成します。
手順 1 SQL キャッシュのロード
次の文が実行され、SQL キャッシュにロードされます。
CONNECT / AS SYSDBA
--Clear any prior contents of the cache.
ALTER SYSTEM FLUSH SHARED_POOL;
CONNECT SH/SH;
SELECT
t.calendar_month_desc, SUM(s.amount_sold) AS dollars
FROM
sales s, times t WHERE s.time_id = t.time_id
AND s.time_id between TO_DATE('01-JAN-2000', 'DD-MON-YYYY')
AND TO_DATE('01-JUL-2000', 'DD-MON-YYYY')
GROUP BY t.calendar_month_desc;
-- Order by
SELECT c.country_id, c.cust_city, c.cust_last_name
FROM customers c WHERE c.country_id IN ('52790', '52789')
ORDER BY c.country_id, c.cust_city, c.cust_last_name;
-- Queries to illustrate filtering
CONNECT scott/tiger;
SELECT e.ename, d.dname
FROM emp e, dept d WHERE e.deptno = d.deptno;
SELECT COUNT(*) FROM dept;
CONNECT sh/sh
VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
VARIABLE workload_name VARCHAR2(255);
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
手順 2 ワークロード MY_CACHE_WORKLOAD の作成
EXECUTE :workload_name := 'MY_CACHE_WORKLOAD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:workload_name);
手順 3 フィルタの設定
SH 表を含む SQL 文のみのロード
EXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER ( :workload_name, 'USERNAME_LIST', 'SH');
17-32
Oracle Database パフォーマンス・チューニング・ガイド
SQL アクセス・アドバイザの使用方法
手順 4 SQL キャッシュからのワークロードのロード
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_SQLCACHE ( :workload_name, 'APPEND', 2, :saved_stmts, :failed_stmts);
PRINT :saved_stmts;
PRINT :failed_stmts;
--See the workload statements in catalog views
SELECT num_select_stmt, create_date
FROM user_advisor_sqlw_sum
WHERE workload_name = :workload_name;
SELECT sql_id, username, optimizer_cost, SUBSTR(sql_text, 1, 30)
FROM user_advisor_sqlw_stmts
WHERE workload_name = :workload_name
ORDER BY sql_id;
手順 5 ワークロードへの文の追加
EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_STATEMENT (:workload_name, username => 'SH', priority => 1, executions => 10, sql_text => 'select count(*) from customers where cust_state_province=''CA''');
SELECT num_select_stmt, create_date
FROM user_advisor_sqlw_sum
WHERE workload_name = :workload_name;
手順 6 タスク MYTASK の作成
EXECUTE :task_name := 'MYTASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK ('SQL Access Advisor', :task_id, :task_name);
手順 7 ワークロードとタスクの間のリンクの作成
EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_REF(:task_name, :workload_name);
手順 8 タスクの実行
EXECUTE DBMS_ADVISOR.EXECUTE_TASK(:task_name);
手順 9 スクリプトの生成
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(:task_name),'ADVISOR_RESULTS', 'Example3_script.sql');
索引およびマテリアライズド・ビューの現在の使用状況の評価
この例では、SQL アクセス・アドバイザを使用して、既存の索引およびマテリアライズド・
ビューの使用率を評価する方法を示します。17-29 ページの「ユーザー定義のワークロードの推
奨事項」に記載されているように、ワークロードを USER_WORKLOAD 表にロードするとしま
す。
（特定のワークロードによって）現在使用されている索引およびマテリアライズド・ビュー
は、SQL アクセス・アドバイザの推奨事項で RETAIN アクションとして表示されます。
CONNECT SH/SH;
VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
VARIABLE workload_name VARCHAR2(255);
VARIABLE saved_stmts NUMBER;
VARIABLE failed_stmts NUMBER;
手順 1 ワークロード WORKLOAD の作成
EXECUTE :workload_name := 'MYWORKLOAD';
EXECUTE DBMS_ADVISOR.CREATE_SQLWKLD(:workload_name);
SQL アクセス・アドバイザ
17-33
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
手順 2 ユーザー定義表 SH.USER_WORKLOAD からのワークロードのロード
EXECUTE DBMS_ADVISOR.IMPORT_SQLWKLD_USER ( :workload_name, 'APPEND', 'SH','USER_WORKLOAD', :saved_stmts, :failed_stmts);
PRINT :saved_stmts;
PRINT :failed_stmts;
手順 3 タスク MY_EVAL_TASK の作成
EXECUTE :task_name := 'MY_EVAL_TASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK ('SQL Access Advisor', :task_id, :task_name);
手順 4 ワークロードとタスクの間のリンクの作成
EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_REF(:task_name, :workload_name);
手順 5 EVALUATION ONLY タスクを示すタスク・パラメータの設定
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER (:task_name, 'EVALUATION_ONLY', 'TRUE');
手順 6 タスクの実行
EXECUTE DBMS_ADVISOR.EXECUTE_TASK(:task_name);
手順 7 評価結果の表示
--See the number of recommendations and the status of the task.
SELECT rec_id, rank, benefit
FROM user_advisor_recommendations WHERE task_name = :task_name;
--See the actions for each recommendation.
SELECT rec_id, action_id, SUBSTR(command,1,30) AS command, attr1 AS name
FROM user_advisor_actions WHERE task_name = :task_name
ORDER BY rec_id, action_id;
高速リフレッシュとクエリー・リライトのためのマテリアライ
ズド・ビューのチューニング
高速リフレッシュおよびクエリー・リライトのために最適化されたマテリアライズド・ビュー
を作成するには、いくつかの DBMS_MVIEW プロシージャが役立ちます。EXPLAIN_MVIEW プロ
シージャではマテリアライズド・ビューの高速リフレッシュおよび通常のクエリー・リライト
が可能かどうかが、また EXPLAIN_REWRITE プロシージャではクエリー・リライトが行われる
かどうかがわかります。ただし、いずれのプロシージャでも、高速リフレッシュやクエリー・
リライトの実行方法は示されません。
マテリアライズド・ビューをさらに使いやすくするため、TUNE_MVIEW プロシージャでは、
CREATE MATERIALIZED VIEW 文を最適化する方法と、高速リフレッシュや通常のクエリー・
リライトのためのその他の要件（マテリアライズド・ビュー・ログやリライト同値化関係など）
を満たす方法が示されます。TUNE_MVIEW により、CREATE MATERIALIZED VIEW 文の分析と
処理が行われ、2 つの出力結果（マテリアライズド・ビューの実装とマテリアライズド・
ビュー作成操作の取消し）が生成されます。この 2 つの出力結果は、Oracle のビューからアク
セスできる他、SQL アクセス・アドバイザで作成された外部スクリプト・ファイルに保存する
こともできます。これらの外部スクリプト・ファイルを実行すると、マテリアライズド・
ビューを実装できます。
TUNE_MVIEW プロシージャを使用すると、マテリアライズド・ビューの詳しい知識がない場合
でも、アプリケーションでマテリアライズド・ビューを作成できます。このプロシージャに
よって、マテリアライズド・ビューと必要なコンポーネント（マテリアライズド・ビュー・ロ
グなど）は正しく作成されます。
TUNE_MVIEW プロシージャの詳細は、
『Oracle Database PL/SQL パッケージ・プロシージャお
よびタイプ・リファレンス』を参照してください。
17-34
Oracle Database パフォーマンス・チューニング・ガイド
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
DBMS_ADVISOR.TUNE_MVIEW プロシージャ
この項では、次の項目について説明します。
■
TUNE_MVIEW の構文と操作
■
TUNE_MVIEW の出力結果へのアクセス
TUNE_MVIEW の構文と操作
TUNE_MVIEW の構文は次のとおりです。
DBMS_ADVISOR.TUNE_MVIEW (
task_name IN OUT VARCHAR2, mv_create_stmt IN [CLOB | VARCHAR2])
TUNE_MVIEW プロシージャでは、task_name と mv_create_stmt という 2 つの入力パラ
メータが使用されます。task_name はユーザー提供のタスク識別子で、出力結果へのアクセス
に使用されます。mv_create_stmt は、チューニングが行われる完全な CREATE
MATERIALIZED VIEW 文です。入力された CREATE MATERIALIZED VIEW 文に REFRESH FAST
句または ENABLE QUERY REWRITE 句の一方あるいは両方が含まれない場合、TUNE_MVIEW で
は、デフォルトである REFRESH FORCE 句および DISABLE QUERY REWRITE 句を使用して文を
チューニングし、可能な場合は高速リフレッシュ、それ以外の場合は完全リフレッシュが実行
されます。
TUNE_MVIEW プロシージャでは、内部に任意の問合せ定義を持つことができる、様々な
CREATE MATERIALIZED VIEW 文が処理されます。この問合せ定義は、単純な SELECT 文であ
る場合も、集合演算子やインライン・ビューを持つ複雑なクエリーである場合もあります。マ
テリアライズド・ビューの問合せ定義に REFRESH FAST 句が含まれる場合、TUNE_MVIEW に
よってそのクエリーが分析され、高速リフレッシュが可能かどうかが確認されます。すでに高
速リフレッシュが可能な場合、
「マテリアライズド・ビューはすでに最適であり、これ以上
チューニングできません」というメッセージが戻されます。その他の場合、TUNE_MVIEW プロ
シージャによって特定の文に対してチューニング作業が開始されます。
TUNE_MVIEW プロシージャでは、FAST REFRESH が可能なように、必須集計列などの新しい列
の追加やマテリアライズド・ビュー・ログの修正によって、問合せ定義を修正する出力文を生
成できます。複雑な問合せ定義の場合、TUNE_MVIEW プロシージャでは、そのクエリーを分解
して複数の高速リフレッシュ可能なマテリアライズド・ビューを生成するか、または高速リフ
レッシュの要件が最大限に満たされる方法でマテリアライズド・ビューを記述しなおすことが
あります。TUNE_MVIEW プロシージャでは、次の複雑なクエリー構造を持つ問合せ定義がサ
ポートされます。
■
集合演算子（UNION、UNION ALL、MINUS および INTERSECT）
■
COUNT DISTINCT
■
SELECT DISTINCT
■
インライン・ビュー
ENABLE QUERY REWRITE 句を指定した場合、TUNE_MVIEW では、REFRESH FAST と同様のプ
ロセスを使用して文が修正され、最大限の高度なクエリー・リライトが可能となるようにマテ
リアライズド・ビューが再定義されます。
TUNE_MVIEW プロシージャでは、実行可能文として、2 つの出力結果が生成されます。1 つの
出力結果（IMPLEMENTATION）は、マテリアライズド・ビューと高速リフレッシュやクエ
リー・リライトを可能にするために必要なコンポーネント（マテリアライズド・ビュー・ログ
やリライト同値化）を最大限実装するためのものです。もう 1 つの出力結果（UNDO）は、不要
と判断した場合にマテリアライズド・ビューとリライト同値化を削除するためのものです。
SQL アクセス・アドバイザ
17-35
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
IMPLEMENTATION プロセスの出力文には、次のものがあります。
■
■
■
■
CREATE MATERIALIZED VIEW LOG 文 : 高速リフレッシュに必要で、欠落しているマテリア
ライズド・ビュー・ログを作成します。
ALTER MATERIALIZED VIEW LOG FORCE 文 : マテリアライズド・ビュー・ログに関する要
件（高速リフレッシュに必要で、欠落しているフィルタ列やシーケンスなど）を修正しま
す。
1 つ以上の CREATE MATERIALIZED VIEW 文 : 出力文が 1 つの場合、元の問合せ定義が直接
記述し直され、変換されます。単純なクエリー変換では、必須列の追加が行われるのみで
す。たとえば、マテリアライズド結合ビューに ROWID 列が、マテリアライズド集計
ビューに集計列が追加されます。分解を行うと、複数の CREATE MATERIALIZED VIEW 文
が生成され、元の文から変更された新しいトップレベルのマテリアライズド・ビューが 1
つ以上のサブマテリアライズド・ビューを参照する、ネストされたマテリアライズド・
ビュー階層が形成されます。これは、高速リフレッシュやクエリー・リライトを最大限可
能にするためです。多くの場合、サブマテリアライズド・ビューは高速リフレッシュが可
能です。
BUILD_SAFE_REWRITE_EQUIVALENCE 文 : サブマテリアライズド・ビューを使用して、
トップレベルのマテリアライズド・ビューをリライトできるようにします。分解を行う場
合、クエリー・リライトを有効にする必要があります。
分解により、サブマテリアライズド・ビューの共有ができなくなることがあります。つまり、
分解を行うと、TUNE_MVIEW の出力には常に新しいサブマテリアライズド・ビューが含まれ、
既存のマテリアライズド・ビューは参照されません。
UNDO プロセスの出力文には、次のものがあります。
■
■
DROP MATERIALIZED VIEW 文 : IMPLEMENTATION プロセスでのマテリアライズド・
ビュー（サブマテリアライズド・ビューを含む）の作成を取り消します。
DROP_REWRITE_EQUIVALENCE 文 : 必要に応じて、IMPLEMENTATION プロセスで構築さ
れたリライト同値化関係を削除します。
UNDO プロセスには、マテリアライズド・ビュー・ログを削除する文は含まれません。これは、
マテリアライズド・ビュー・ログが様々なマテリアライズド・ビューで共有されており、その
一部はリモートの Oracle インスタンスに存在する可能性があるためです。
TUNE_MVIEW の出力結果へのアクセス
TUNE_MVIEW の出力結果へのアクセス方法は 2 通りあります。
■
■
DBMS_ADVISOR.GET_TASK_SCRIPT 関数と DBMS_ADVISOR.CREATE_FILE プロシージャ
によるスクリプト生成
USER_TUNE_MVIEW ビューまたは DBA_TUNE_MVIEW ビューの使用方法
USER_TUNE_MVIEW ビューおよび DBA_TUNE_MVIEW ビュー TUNE_MVIEW を実行すると、結果は
SQL アクセス・アドバイザのリポジトリ表に出力され、Oracle ビューである
USER_TUNE_MVIEW と DBA_TUNE_MVIEW からアクセスできます。詳細は、
『Oracle Database
リファレンス』を参照してください。
DBMS_ADVISOR 関数およびプロシージャによるスクリプトの生成 推奨事項の実行スクリプトを
生成する最も簡単な方法は、DBMS_ADVISOR.GET_TASK_SCRIPT プロシージャを使用するこ
とです。次に簡単な例を示します。まず、結果を格納するディレクトリを定義する必要があり
ます。
CREATE DIRECTORY TUNE_RESULTS AS '/tmp/script_dir';
GRANT READ, WRITE ON DIRECTORY TUNE_RESULTS TO PUBLIC;
17-36
Oracle Database パフォーマンス・チューニング・ガイド
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
次に、実装スクリプトと UNDO スクリプトを生成し、それぞれ
/tmp/script_dir/mv_create.sql と /tmp/script_dir/mv_undo.sql に格納します。
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(:task_name),'TUNE_RESULTS', 'mv_create.sql');
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(:task_name, 'UNDO'), 'TUNE_RESULTS', 'mv_undo.sql');
TUNE_MVIEW プロシージャの使用例を次にいくつか示します。
例 17-3 高速リフレッシュのための問合せ定義の最適化
この例では、TUNE_MVIEW によって問合せ定義を高速リフレッシュできるように変更する方法
を示します。CREATE MATERIALIZED VIEW 文は、変数 create_mv_ddl で定義されていま
す。これに、FAST REFRESH 句が含まれています。問合せ定義に 1 つのクエリー・ブロックが
あり、その集計列 SUM(s.amount_sold) には高速リフレッシュをサポートするための必須集
計列がありません。TUNE_MVIEW 文を MATERIALIZED VIEW CREATE 文とともに実行すると、
その結果のマテリアライズド・ビューの推奨事項は高速リフレッシュ可能になります。
VARIABLE task_cust_mv VARCHAR2(30);
VARIABLE create_mv_ddl VARCHAR2(4000);
EXECUTE :task_cust_mv := 'cust_mv';
EXECUTE :create_mv_ddl := '
CREATE MATERIALIZED VIEW cust_mv
REFRESH FAST
DISABLE QUERY REWRITE AS
SELECT s.prod_id, s.cust_id, SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id
GROUP BY s.prod_id, s.cust_id';
EXECUTE DBMS_ADVISOR.TUNE_MVIEW(:task_cust_mv, :create_mv_ddl);
cust_mv の元の問合せ定義は、高速リフレッシュを可能にするための集計列の追加によって変
更されています。
TUNE_MVIEW からの出力には、次のように、最適化されたマテリアライズド・ビューの問合せ
定義が含まれます。
CREATE MATERIALIZED VIEW SH.CUST_MV
REFRESH FAST WITH ROWID
DISABLE QUERY REWRITE AS
SELECT SH.SALES.PROD_ID C1, SH.CUSTOMERS.CUST_ID C2,
SUM("SH"."SALES"."AMOUNT_SOLD") M1,
COUNT("SH"."SALES"."AMOUNT_SOLD") M2,
COUNT(*) M3
FROM SH.SALES, SH.CUSTOMERS
WHERE SH.CUSTOMERS.CUST_ID = SH.SALES.CUST_ID
GROUP BY SH.SALES.PROD_ID, SH.CUSTOMERS.CUST_ID;
UNDO の出力は次のとおりです。
DROP MATERIALIZED VIEW SH.CUST_MV;
例 17-4 USER_TUNE_MVIEW ビューからの IMPLEMENTATION の出力へのアクセス
SELECT STATEMENT FROM USER_TUNE_MVIEW
WHERE TASK_NAME= :task_cust_mv AND SCRIPT_TYPE='IMPLEMENTATION';
SQL アクセス・アドバイザ
17-37
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
例 17-5 スクリプト・ファイルへの IMPLEMENTATION の出力の保存
CREATE DIRECTORY TUNE_RESULTS AS '/myscript'
GRANT READ, WRITE ON DIRECTORY TUNE_RESULTS TO PUBLIC;
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(:task_cust_mv), 'TUNE_RESULTS', 'mv_create.sql');
例 17-6 複数のマテリアライズド・ビューの作成によるクエリー・リライトの有効化
この例では、クエリー・リライトでサポートされない集合演算子 UNION を含むマテリアライズ
ド・ビューの問合せ定義を、複数のサブマテリアライズド・ビューに分解し、クエリー・リラ
イトを可能にする方法を示します。入力ディテール表として、sales、customers および
countries を想定し、マテリアライズド・ビュー・ログはないものとします。
まず、TUNE_MVIEW 文を create_mv_ddl 変数で定義されている CREATE MATERIALIZED
VIEW 文とともに実行する必要があります。
EXECUTE :task_cust_mv := 'cust_mv2';
EXECUTE :create_mv_ddl := '
CREATE MATERIALIZED VIEW cust_mv
ENABLE QUERY REWRITE AS
SELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amount
FROM sales s, customers cs, countries cn
WHERE s.cust_id = cs.cust_id AND cs.country_id = cn.country_id
AND cn.country_name IN (''USA'',''Canada'')
GROUP BY s.prod_id, s.cust_id
UNION
SELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (1005,1010,1012)
GROUP BY s.prod_id, s.cust_id';
マテリアライズド・ビューの問合せ定義には、通常のクエリー・リライトをサポートしない
UNION 集合演算子が含まれていますが、これを複数のマテリアライズド・ビューに分解する
と、クエリー・リライトが可能になります。通常のクエリー・リライトをサポートするため、
MATERIALIZED VIEW 問合せ定義が分解されます。
EXECUTE DBMS_ADVISOR.TUNE_MVIEW(:task_cust_mv, :create_mv_ddl);
TUNE_MVIEW からの次の推奨事項は、マテリアライズド・ビュー・ログと複数のマテリアライ
ズド・ビューで構成されています。
CREATE MATERIALIZED VIEW LOG ON "SH"."CUSTOMERS"
WITH ROWID, SEQUENCE("CUST_ID")
INCLUDING NEW VALUES;
ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."CUSTOMERS"
ADD ROWID, SEQUENCE("CUST_ID")
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LOG ON
"SH"."SALES"
WITH ROWID, SEQUENCE("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES;
ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."SALES"
ADD ROWID, SEQUENCE("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LOG ON
"SH"."COUNTRIES"
17-38
Oracle Database パフォーマンス・チューニング・ガイド
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
WITH ROWID, SEQUENCE("COUNTRY_ID","COUNTRY_NAME")
INCLUDING NEW VALUES;
ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."COUNTRIES"
ADD ROWID, SEQUENCE("COUNTRY_ID","COUNTRY_NAME")
INCLUDING NEW VALUES;
ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."CUSTOMERS"
ADD ROWID, SEQUENCE("CUST_ID","COUNTRY_ID")
INCLUDING NEW VALUES;
ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."SALES"
ADD ROWID, SEQUENCE("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW SH.CUST_MV$SUB1
REFRESH FAST WITH ROWID ON COMMIT
ENABLE QUERY REWRITE
AS SELECT SH.SALES.PROD_ID C1, SH.CUSTOMERS.CUST_ID C2,
SUM("SH"."SALES"."AMOUNT_SOLD")
M1, COUNT("SH"."SALES"."AMOUNT_SOLD") M2, COUNT(*) M3 FROM SH.SALES,
SH.CUSTOMERS WHERE SH.CUSTOMERS.CUST_ID = SH.SALES.CUST_ID AND
(SH.SALES.CUST_ID IN (1012, 1010, 1005))
GROUP BY SH.SALES.PROD_ID, SH.CUSTOMERS.CUST_ID;
CREATE MATERIALIZED VIEW SH.CUST_MV$SUB2
REFRESH FAST WITH ROWID ON COMMIT
ENABLE QUERY REWRITE
AS SELECT SH.SALES.PROD_ID C1, SH.CUSTOMERS.CUST_ID C2,
SH.COUNTRIES.COUNTRY_NAME C3, SUM("SH"."SALES"."AMOUNT_SOLD") M1,
COUNT("SH"."SALES".
"AMOUNT_SOLD")
M2, COUNT(*) M3 FROM SH.SALES, SH.CUSTOMERS, SH.COUNTRIES WHERE
SH.CUSTOMERS.CUST_ID
= SH.SALES.CUST_ID AND SH.COUNTRIES.COUNTRY_ID = SH.CUSTOMERS.COUNTRY_ID
AND (SH.COUNTRIES.COUNTRY_NAME IN ('USA', 'Canada')) GROUP BY
SH.SALES.PROD_ID,
SH.CUSTOMERS.CUST_ID, SH.COUNTRIES.COUNTRY_NAME;
CREATE MATERIALIZED VIEW SH.CUST_MV
REFRESH FORCE WITH ROWID
ENABLE QUERY REWRITE
AS (SELECT "CUST_MV$SUB2"."C1" "PROD_ID","CUST_MV$SUB2"."C2"
"CUST_ID",SUM("CUST_MV$SUB2"."M3")
"CNT",SUM("CUST_MV$SUB2"."M1") "SUM_AMOUNT" FROM "SH"."CUST_MV$SUB2"
"CUST_MV$SUB2" GROUP BY "CUST_MV$SUB2"."C1","CUST_MV$SUB2"."C2")UNION
(SELECT "CUST_MV$SUB1"."C1" "PROD_ID","CUST_MV$SUB1"."C2"
"CUST_ID",SUM("CUST_MV$SUB1"."M3")
"CNT",SUM("CUST_MV$SUB1"."M1") "SUM_AMOUNT" FROM "SH"."CUST_MV$SUB1"
"CUST_MV$SUB1" GROUP BY "CUST_MV$SUB1"."C1","CUST_MV$SUB1"."C2");
BEGIN
DBMS_ADVANCED_REWRITE.BUILD_SAFE_REWRITE_EQUIVALENCE ('SH.CUST_MV$RWEQ',
'SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs, countries cn
WHERE s.cust_id = cs.cust_id AND cs.country_id = cn.country_id
AND cn.country_name IN (''USA'',''Canada'')
GROUP BY s.prod_id, s.cust_id
UNION
SQL アクセス・アドバイザ
17-39
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (1005,1010,1012)
GROUP BY s.prod_id, s.cust_id',
'(SELECT "CUST_MV$SUB2"."C3" "PROD_ID","CUST_MV$SUB2"."C2" "CUST_ID",
SUM("CUST_MV$SUB2"."M3") "CNT",
SUM("CUST_MV$SUB2"."M1") "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB2" "CUST_MV$SUB2"
GROUP BY "CUST_MV$SUB2"."C3","CUST_MV$SUB2"."C2")
UNION
(SELECT "CUST_MV$SUB1"."C2" "PROD_ID","CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1")',-1553577441)
END;
/;
DROP の出力は次のとおりです。
DROP MATERIALIZED VIEW SH.CUST_MV$SUB1
DROP MATERIALIZED VIEW SH.CUST_MV$SUB2
DROP MATERIALIZED VIEW SH.CUST_MV
DBMS_ADVANCED_REWRITE.DROP_REWRITE_EQUIVALENCE('SH.CUST_MV$RWEQ')
cust_mv の元の問合せ定義は、cust_mv$SUB1 および cust_mv$SUB2 という 2 つのサブマテ
リアライズド・ビューに分解されました。COUNT(amount_sold) という新しい列が
cust_mv$SUB1 に追加され、マテリアライズド・ビューの高速リフレッシュが可能になりまし
た。
cust_mv の元の問合せ定義は、2 つのサブマテリアライズド・ビューを問い合せるように変更
され、両方のサブマテリアライズド・ビューで高速リフレッシュと通常のクエリー・リライト
が可能です。
必要なマテリアライズド・ビュー・ログが追加され、サブマテリアライズド・ビューの高速リ
フレッシュが可能です。ディテール表ごとに、2 つのマテリアライズド・ビュー・ログ文が生
成されます。1 つは CREATE MATERIALIZED VIEW 文、もう 1 つは ALTER MATERIALIZED
VIEW FORCE 文です。これは、CREATE スクリプトを複数回実行できるようにするためです。
BUILD_SAFE_REWRITE_EQUIVALENCE 文は、古い問合せ定義を、新しいトップレベルのマテ
リアライズド・ビューの問合せ定義に結合します。これによって、クエリー・リライトで新し
いトップレベルのマテリアライズド・ビューを使用して問合せに応答できるようにします。
例 17-7 USER_TUNE_MVIEW ビューからの IMPLEMENTATION の出力へのアクセス
SELECT * FROM USER_TUNE_MVIEW
WHERE TASK_NAME='cust_mv2'
AND SCRIPT_TYPE='IMPLEMENTATION';
例 17-8 スクリプト・ファイルへの IMPLEMENTATION の出力の保存
次の文では、IMPLEMENTATION の出力が、/myscript/mv_create2.sql にあるスクリプ
ト・ファイルに保存されます。
CREATE DIRECTORY TUNE_RESULTS AS '/myscript'
GRANT READ, WRITE ON DIRECTRY TUNE_RESULTS TO PUBLIC;
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT('cust_mv2'),
'TUNE_RESULTS', 'mv_create2.sql');
17-40
Oracle Database パフォーマンス・チューニング・ガイド
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
最適化されたサブマテリアライズド・ビューによる高速リフレッシュの
有効化
この例では、TUNE_MVIEW を使用して、高速リフレッシュを行えるようにマテリアライズド・
ビューを最適化する方法を示します。この例では、集合演算子を持つマテリアライズド・
ビューの問合せ定義が 1 つのサブマテリアライズド・ビューと 1 つのトップレベル・マテリア
ライズド・ビューに変換されます。元の問合せ定義の副問合せの形式は類似しており、条件式
は結合されます。
マテリアライズド・ビュー自体が高速リフレッシュできないよう、マテリアライズド・ビュー
の問合せ定義には UNION 集合演算子が含まれています。ただし、マテリアライズド・ビューの
問合せ定義内の 2 つの副問合せを、1 つの問合せとして結合できます。
例 17-9 高速リフレッシュのためのサブマテリアライズド・ビューの最適化
EXECUTE :task_cust_mv := 'cust_mv3';
EXECUTE :create_mv_ddl := '
CREATE MATERIALIZED VIEW cust_mv
REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE AS
SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id
GROUP BY s.prod_id, s.cust_id UNION
SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
FROM sales s, customers cs WHERE s.cust_id = cs.cust_id AND s.cust_id
GROUP BY s.prod_id, s.cust_id';
SUM(s.amount_sold) sum_amount
IN (2005,1020)
SUM(s.amount_sold) sum_amount
IN (1005,1010,1012)
EXECUTE DBMS_ADVISOR.TUNE_MVIEW(:task_cust_mv, :create_mv_ddl);
TUNE_MVIEW と 2 つの副問合せを結合して最適化されたサブマテリアライズド・ビューで次の
推奨事項が生成され、サブマテリアライズド・ビューは新しいトップレベルのマテリアライズ
ド・ビューによって参照されます。
CREATE MATERIALIZED VIEW LOG ON "SH"."SALES"
WITH ROWID, SEQUENCE ("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES
ALTER MATERIALIZED VIEW LOG FORCE ON "SH"."SALES"
ADD ROWID, SEQUENCE ("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES
CREATE MATERIALIZED VIEW LOG ON "SH"."CUSTOMERS"
WITH ROWID, SEQUENCE ("CUST_ID") INCLUDING NEW VALUES
ALTER MATERIALIZED VIEW LOG FORCE ON "SH"."CUSTOMERS"
ADD ROWID, SEQUENCE ("CUST_ID") INCLUDING NEW VALUES
CREATE MATERIALIZED VIEW SH.CUST_MV$SUB1
REFRESH FAST WITH ROWID
ENABLE QUERY REWRITE AS
SELECT SH.SALES.CUST_ID C1, SH.SALES.PROD_ID C2,
SUM("SH"."SALES"."AMOUNT_SOLD") M1,
COUNT("SH"."SALES"."AMOUNT_SOLD")M2, COUNT(*) M3
FROM SH.CUSTOMERS, SH.SALES
WHERE SH.SALES.CUST_ID = SH.CUSTOMERS.CUST_ID AND
(SH.SALES.CUST_ID IN (2005, 1020, 1012, 1010, 1005))
GROUP BY SH.SALES.CUST_ID, SH.SALES.PROD_ID
CREATE MATERIALIZED VIEW SH.CUST_MV
REFRESH FORCE WITH ROWID ENABLE QUERY REWRITE AS
(SELECT "CUST_MV$SUB1"."C2" "PROD_ID","CUST_MV$SUB1"."C1" "CUST_ID",
SQL アクセス・アドバイザ
17-41
高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=2005 OR "CUST_MV$SUB1"."C1"=1020)
UNION
(SELECT "CUST_MV$SUB1"."C2" "PROD_ID","CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=1012 OR "CUST_MV$SUB1"."C1"=1010 OR
"CUST_MV$SUB1"."C1"=1005)
DBMS_ADVANCED_REWRITE.BUILD_SAFE_REWRITE_EQUIVALENCE ('SH.CUST_MV$RWEQ',
'SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (2005,1020)
GROUP BY s.prod_id, s.cust_id UNION
SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (1005,1010,1012)
GROUP BY s.prod_id, s.cust_id',
'(SELECT "CUST_MV$SUB1"."C2" "PROD_ID",
"CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=2005OR "CUST_MV$SUB1"."C1"=1020)
UNION
(SELECT "CUST_MV$SUB1"."C2" "PROD_ID",
"CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=1012 OR "CUST_MV$SUB1"."C1"=1010 OR
"CUST_MV$SUB1"."C1"=1005)',
1811223110);
cust_mv の元の問合せ定義は、サブマテリアライズド・ビュー CUST_MV$SUB1 の 2 つの副問
合せの条件を結合することで最適化されています。また、必要なマテリアライズド・ビュー・
ログも追加され、サブマテリアライズド・ビューの高速リフレッシュが可能です。
DROP の出力は次のとおりです。
DROP MATERIALIZED VIEW SH.CUST_MV$SUB1
DROP MATERIALIZED VIEW SH.CUST_MV
DBMS_ADVANCED_REWRITE.DROP_REWRITE_EQUIVALENCE('SH.CUST_MV$RWEQ');
次の文では、IMPLEMENTATION の出力が、/myscript/mv_create3.sql にあるスクリプ
ト・ファイルに保存されます。
CREATE DIRECTORY TUNE_RESULTS AS '/myscript'
GRANT READ, WRITE ON DIRECTORY TUNE_RESULTS TO PUBLIC;
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT('cust_mv3'),
'TUNE_RESULTS', 'mv_create3.sql');
17-42
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 が、それとは別のあるカテゴリの下でコンパイルした実行計画を使用すること
はありません。
プラン・スタビリティを使用可能にする方法
アウトラインを適切に機能させるためには、接尾辞 _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 テキストのシグネチャを生成します。
プラン・スタビリティの使用方法
18-3
実行計画を保持するためのプラン・スタビリティの使用
関連項目 :
■
■
DBMS_OUTLN パッケージ・プロシージャの使用方法の詳細は、
『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・
リファレンス』を参照してください。
DBMS_OUTLN_EDIT パッケージ・プロシージャの使用方法の詳細は、
『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・
リファレンス』を参照してください。
アウトラインの作成
すべての 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 のアウトラインを削除します。
関連項目 :
■
■
■
18-4
CREATE OUTLINE 文の詳細は、
『Oracle Database SQL 言語リファレン
ス』を参照してください。
DBMS_OUTLN および DBMS_OUTLN_EDIT の各パッケージの詳細は、
『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・
リファレンス』を参照してください。
ルールベース・オプティマイザから問合せオプティマイザに移行する
方法の詳細は、18-8 ページの「RBO から問合せオプティマイザへの
移行」を参照してください。
Oracle Database パフォーマンス・チューニング・ガイド
実行計画を保持するためのプラン・スタビリティの使用
ストアド・アウトラインにカテゴリ名を使用する方法
管理タスクを単純にするために、アウトラインをカテゴリに分類できます。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 はアウトラインを作成しますが、使用はしません。
USE_PRIVATE_OUTLINES パラメータを使用すると、プライベート・アウトラインの使用を制
御できます。プライベート・アウトラインは、現行のセッション内のみで見られるアウトライ
ンで、そのデータは現行の解析スキーマ内に常駐します。このアウトラインに対して行った変
更はシステム上の他のセッションからは見られず、文のコンパイルへの適用は、現行セッショ
ンで USE_PRIVATE_OUTLINES パラメータを指定することによってのみ行えます。編集内容を
パブリック領域に保存するように明示的に選択した場合のみ、他のユーザーにも編集内容が表
示されます。
オプティマイザは通常、問合せに最適な計画を選択しますが、ユーザーが実行環境に関して理
解している事柄と、オプティマイザが従う経験則的方法とが整合しない場合があります。アウ
トラインを直接編集することで、アプリケーションを変更しなくても SQL 問合せをチューニン
グできます。
USE_PRIVATE_OUTLINES パラメータを有効にし、アウトラインを使用する SQL 文を発行する
と、オプティマイザは、USE_STORED_OUTLINES を有効にした場合に使用されるパブリック領
域ではなく、セッションのプライベート領域からアウトラインを取り出します。セッションの
プラン・スタビリティの使用方法
18-5
実行計画を保持するためのプラン・スタビリティの使用
プライベート領域にアウトラインが存在しない場合、オプティマイザは、文のコンパイルにア
ウトラインを使用しません。
CREATE OUTLINE 文はすべて、CREATE ANY OUTLINE 権限が必要です。FROM 句を指定する場
合は、SELECT 権限も必要です。この権限は、アウトラインを使用する文に関連する SQL テキ
ストとヒント・テキストを表示する権限を持つユーザーのみに与える必要があります。この
ロールは、CREATE OUTLINE FROM コマンドに必要です。コマンドの発行者がアウトラインの
所有者でもある場合は、このロールは不要です。
注意 : USE_STORED_OUTLINES および USE_PRIVATE_OUTLINES パラ
メータは、システムまたはセッション固有です。これらは初期化パラメー
タではありません。これらのパラメータの詳細は、『Oracle Database SQL
言語リファレンス』を参照してください。
アウトラインが 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-6
Oracle Database パフォーマンス・チューニング・ガイド
実行計画を保持するためのプラン・スタビリティの使用
互換性、形式およびアウトラインが使用可能かどうかについて、_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;
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)
プラン・スタビリティの使用方法
18-7
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用
インポート・プロセスが完了すると、OUTLN という名前のスキーマに OL$ 表、OL$HINTS 表お
よび OL$NODES 表が再作成され、OUTLN_TS という新しい表領域に配置されます。
このプロセスが完了した後、前のステップで削除された権限およびロールを追加することで、
OUTLN ユーザーの表領域割当て制限を適切に調整できます。
関連項目 :
■
■
Export および Import のユーティリティの使用方法は、『Oracle
Database ユーティリティ』を参照してください。Import ユーティリ
ティの説明の箇所にある表領域の再編成に関する項に注意してくださ
い。
DBMS_OUTLN パッケージの使用方法の詳細は、
『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を
参照してください。
問合せオプティマイザのアップグレードによるプラン・スタビ
リティの使用
この項では、問合せオプティマイザの機能を利用してパフォーマンスを大幅に改善する手順を
説明します。プラン・スタビリティは、システムが目標としている、パフォーマンスのよい実
行計画を保ちながら、一方で、残りの SQL 文に対する問合せオプティマイザの新機能の利点も
利用する手段を提供します。
元の実行計画の正確な再現が保証されない SQL 文および機能のクラスもありますが、プラン・
スタビリティは移行プロセスにおける非常に便利な要素です。移行前に、アプリケーションの
SQL 文のすべてまたは大部分が取得されるまで、実行計画のアウトライン取得をオンにする必
要があります。移行後に、特定の SQL 文でパフォーマンスの問題がある場合は、以前の動作を
元に戻す方法として、この文に対するストアド・アウトラインの使用をオンにできます。スト
アド・アウトラインの使用は、変化するデータ・プロパティに計画が適応できないため、移行
関連のパフォーマンスの問題を解決する最善の方法ではない場合がありますが、こうした問題
への対処に使用できる数あるテクニックの 1 つです。
この項で説明する項目は次のとおりです。
■
RBO から問合せオプティマイザへの移行
■
問合せオプティマイザを使用している場合の新規 Oracle リリースへの移行
RBO から問合せオプティマイザへの移行
ルールベース・オプティマイザを使用して開発したアプリケーションの場合、パフォーマンス
を最適化するために SQL 文の手動チューニングに多大な作業量を投入している場合がありま
す。プラン・スタビリティを使用すると、ルールベースの最適化から問合せの最適化へアップ
グレードする際にアプリケーションの動作を保持することによって、すでにパフォーマンス・
チューニングに投入した作業を生かすことができます。
問合せの最適化に切り替える前にアプリケーションのアウトラインを作成すると、ルールベー
ス・オプティマイザで生成した計画を使用しながら、切替え後に新しく作成されたアプリケー
ションで生成した文で問合せの計画を使用できます。アプリケーションのアウトラインを作成
および使用するには、次のプロセスを実行します。
注意 :
い。
1.
この手順をよく読んで、内容を十分理解してから実行してくださ
アウトラインを作成するスキーマに CREATE ANY OUTLINE 権限があることを確認します。
たとえば、SYS からは次のようになります。
GRANT CREATE ANY OUTLINE TO user-name
18-8
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 文に存在する可能性が常にあ
ります。このような変更によりパフォーマンスが向上しますが、アプリケーションによっては、
パフォーマンスがすでに十分であるため、動作の変更は不要なリスクと考える場合もあります。
このようなアプリケーションに対しては、次の手順により、アップグレード前にアウトライン
を作成します。
注意 :
い。
1.
この手順をよく読んで、内容を十分理解してから実行してくださ
次の構文を入力して、アウトラインを作成できるようにします。
ALTER SESSION SET CREATE_STORED_OUTLINES = ALL_QUERIES;
2.
重要な SQL 文すべてにストアド・アウトラインを獲得できるよう十分に時間をとってアプ
リケーションを実行します。
3.
次の構文を入力して、アウトラインの生成を中断します。
ALTER SESSION SET CREATE_STORED_OUTLINES = FALSE;
4.
新しいバージョンの RDBMS に本番システムをアップグレードします。
5.
アプリケーションを実行します。
アップグレード後は、ストアド・アウトラインを使用可能にすることもできますし、あるいは、
アップグレード後にパフォーマンスの低下を示す文があれば格納されていたアウトラインを
バックアップとして使用することもできます。
プラン・スタビリティの使用方法
18-9
問合せオプティマイザのアップグレードによるプラン・スタビリティの使用
バックアップとして使用する場合は、次のようにして、問題のある文にストアド・アウトライ
ンを使用できます。
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-10
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 言語リ
ファレンス』を参照してください。
第 13 章「問合せオプティマイザ」
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 概要』を参照してくださ
い。
実行計画の変化理由
問合せオプティマイザを使用すると、実行計画は基礎となるオプティマイザ入力が変化するた
びに変化します。EXPLAIN PLAN の出力は、SQL 文の説明段階での実行方法を示します。この
方法は、実行環境と EXPLAIN PLAN 環境との違いにより、SQL 文の実際の実行計画とは異な
る場合があります。
実行計画は、次の理由により異なります。
■
スキーマの相違
■
コストの相違
スキーマの相違
■
■
■
実行と EXPLAIN PLAN が、異なるデータベース上で起こる場合。
文を EXPLAIN するユーザーが、文を実行するユーザーとは異なる場合。2 人のユーザーが
同じデータベース内の異なるオブジェクトを指していれば、異なる実行計画が発生します。
2 つの操作間でスキーマが変更された場合（多くは索引の変更）。
コストの相違
スキーマが同じであっても、コストが異なる場合にオプティマイザは異なる実行計画を選択す
る可能性があります。コストに影響を与えるいくつかの要因には次のものがあります。
19-2
■
データ量と統計
■
バインド変数の型と値
■
初期化パラメータ（グローバル設定またはセッション・レベルでの設定）
Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN について
排除行数の最少化
EXPLAIN PLAN を調べることにより、次の場合の排除行数を確認できます。
■
全表スキャン
■
選択性のないレンジ・スキャン
■
遅延した述語フィルタ
■
誤った結合順序
■
遅延したフィルタ処理
たとえば、次の EXPLAIN PLAN では、最後のステップは非常に選択性のないレンジ・スキャ
ンです。このレンジ・スキャンは 76563 回実行され、11432983 行にアクセスし、アクセスした
行の 99 パーセントを排除して 76563 行を保持します。11432983 行にアクセスした結果、必要
な行が 76563 行のみであると判別された理由について考えます。
例 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-18 ページの「PLAN_TABLE 列」を参照してください。
EXPLAIN PLAN とは異なり、V$SQL_PLAN には、特定の文の実行に使用されたコンパイル環境
を使用する必要がないというメリットがあります。EXPLAIN PLAN の場合は、文の実行時に同
じ計画を取得するために同一環境をセットアップする必要があります。
V$SQL_PLAN_STATISTICS ビューは、出力行数や経過時間など、計画に含まれる操作ごとに
実際の実行統計を提供します。出力行数を除き、すべての統計は累積されます。たとえば、結
合操作の統計には、2 つの入力の統計も含まれます。V$SQL_PLAN_STATISTICS の統計は、
STATISTICS_LEVEL 初期化パラメータを ALL に設定してコンパイルされたカーソルに使用で
きます。
EXPLAIN PLAN の使用方法
19-3
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-18 ページの
「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.
データベースのバージョンを更新した場合は、列が変更される可能性があるため、ローカルの
PLAN_TABLE 表を削除して再作成することをお薦めします。表を指定する場合は、スクリプト
の実行が失敗したり、TKPROF が失敗する場合があります。
別の名前の出力表が必要な場合は、最初に utlxplan.sql スクリプトを使用して手動で
PLAN_TABLE を作成してから、RENAME SQL 文で表の名前を変更します。たとえば、次のよう
にします。
RENAME PLAN_TABLE TO my_plan_table;
19-4
Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN の実行
EXPLAIN PLAN の実行
SQL 文を EXPLAIN する場合は、文の直前に EXPLAIN PLAN FOR 句を使用します。たとえば、
次のようにします。
EXPLAIN PLAN FOR
SELECT last_name FROM employees;
計画を EXPLAIN したものが PLAN_TABLE 表に挿入されます。PLAN_TABLE から実行計画を選
択できるようになります。19-6 ページの「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;
INTO 句を使用する場合は、文の識別子を指定できます。
EXPLAIN PLAN
SET STATEMENT_ID = 'st1'
INTO my_plan_table
FOR
SELECT last_name FROM employees;
関連項目 : EXPLAIN PLAN 構文の詳細は、『Oracle Database SQL 言語リ
ファレンス』を参照してください。
EXPLAIN PLAN の使用方法
19-5
PLAN_TABLE 出力の表示
PLAN_TABLE 出力の表示
計画を EXPLAIN した後、Oracle から提供される次の SQL スクリプトまたは PL/SQL パッ
ケージを使用して最新の PLAN TABLE 出力を表示します。
■
UTLXPLS.SQL
このスクリプトは、シリアル処理のための PLAN TABLE 出力を表示します。13-12 ページ
の例 13-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 パッケージの詳細は、
『Oracle Database
PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照
してください。
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
19-6
Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN 出力の読み方
Rows 列の NULL は、オプティマイザが表に統計を持っていないことを示します。表を
ANALYZE すると、次の内容が表示されます。
Rows Plan
------- ---------------------------------------16957 SELECT STATEMENT
16957 TABLE ACCESS FULL EMPLOYEES
COST も選択できます。これは、実行計画を比較する場合や、オプティマイザが複数の中か
らある実行計画を選択した理由を理解する場合に便利です。
注意 :
ん。
これらの単純な例は、再帰的 SQL の場合には有効ではありませ
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-7
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 表で使用される索引は、
通常、最初の問合せで使用される一意でない索引ではなく、選択性の高い主キーまたは一意の
索引になります。TRANSACTION 表は大きく、列に選択性がないため、TRANSACTION 表から
行われるパラレル問合せを使用した方が有効です。
パラレル操作には次のものがあります。
■
PARALLEL_TO_PARALLEL
■
PARALLEL_TO_SERIAL
PARALLEL_TO_SERIAL 操作は、パラレル操作からの行が問合せコーディネータによって
使用される場合、常に発生するステップです。この問合せでは発生しない他の種類の操作
には、SERIAL 操作があります。これらの操作が発生するとボトルネックになる可能性が
あります。パフォーマンスを向上させるために、これらの操作をパラレル操作にすること
を考慮します。
■
19-8
PARALLEL_FROM_SERIAL
Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパラレル実行の表示
■
PARALLEL_TO_PARALLEL
通常は、各操作のワークロードがほぼ同じであるかぎり、PARALLEL_TO_PARALLEL 操作
によって最適なパフォーマンスが得られます。
■
PARALLEL_COMBINED_WITH_CHILD
■
PARALLEL_COMBINED_WITH_PARENT
ステップが親ステップと同時に実行される場合、PARALLEL_COMBINED_WITH_PARENT 操
作が発生します。
パラレル・ステップによって多数の行が生成されると、問合せコーディネータ（QC）がそれら
の行を生成後すぐに処理できない場合があります。このような状況を改善する方法はありませ
ん。
関連項目 : 19-18 ページの表 19-1「PLAN_TABLE 列」の OTHER_TAG 列
を参照してください。
EXPLAIN PLAN によるパラレル問合せの表示
パラレル問合せに EXPLAIN PLAN を使用する場合、1 つのパラレル計画がコンパイルされ、実
行されます。この計画は、問合せコーディネータ（QC）計画のパラレル・サポートに固有の行
ソースを割り当てることで、シリアル計画から導出されます。2 つのスレーブ・セット PQ モデ
ルで要求される、表キューの行ソース（PX Send および PX Receive）
、グラニュル・イテレー
タおよびバッファ・ソートは、パラレル計画に直接挿入されます。この計画は、パラレルで実
行された場合はすべてのスレーブで、またシリアルで実行された場合はすべての QC で、まっ
たく同じ計画となります。
例 19-8 は、パラレル問合せの 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 (%CPU) |
TQ |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
107 | 2782 |
3 (34) |
|
|
|
|
1 | PX COORDINATOR
|
|
|
|
|
|
|
|
|
2 |
PX SEND QC (RANDOM)
| :TQ10001 |
107 | 2782 |
3 (34) | Q1,01 | P->S | QC (RAND) |
|
3 |
HASH GROUP BY
|
|
107 | 2782 |
3 (34) | Q1,01 | PCWP |
|
|
4 |
PX RECEIVE
|
|
107 | 2782 |
3 (34) | Q1,01 | PCWP |
|
|
5 |
PX SEND HASH
| :TQ10000 |
107 | 2782 |
3 (34) | Q1,00 | P->P | HASH
|
|
6 |
HASH GROUP BY
|
|
107 | 2782 |
3 (34) | Q1,00 | PCWP |
|
|
7 |
PX BLOCK ITERATOR |
|
107 | 2782 |
2 (0)
| Q1,00 | PCWP |
|
|
8 |
TABLE ACCESS FULL| EMP2
|
107 | 2782 |
2 (0)
| 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（問合せコーディネータ）を表します。
EXPLAIN PLAN の使用方法
19-9
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 によるパーティション・オブジェクトの表示
EXPLAIN PLAN を使用すると、特定の問合せでのパーティション・オブジェクトに Oracle がア
クセスする方法を参照できます。
プルーニング後にアクセスされたパーティションは、PARTITION START 列と PARTITION
STOP 列に表示されます。レンジ・パーティションの行ソース名は、PARTITION RANGE です。
ハッシュ・パーティションの場合、行ソース名は PARTITION HASH です。
結合されるいずれかの表の PLAN TABLE の DISTRIBUTION 列に PARTITION（KEY）が存在
する場合、結合はパーシャル・パーティション・ワイズ結合を使用して実装されます。パー
シャル・パーティション・ワイズ結合が可能なのは、結合される表のいずれかが結合列でパー
ティション化されており、かつ、表がパラレル化されている場合です。
EXPLAIN PLAN 出力の結合行ソースの前にパーティション行ソースがある場合、結合はフル・
パーティション・ワイズ結合を使用して実装されます。フル・パーティション・ワイズ結合が
可能なのは、両方の結合表がそれぞれの結合列でパーティション化されている場合のみです。
次に、いくつかの種類のパーティションに対する実行計画の例を示します。
19-10
Oracle Database パフォーマンス・チューニング・ガイド
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;
次のようなものが表示されます。
--------------------------------------------------------------------------------| 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 の使用方法
19-11
EXPLAIN PLAN によるパーティション・オブジェクトの表示
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 のみがアクセスされ、それがコンパイル時に認識されます。し
たがって、パーティション行ソースは必要ありません。
ハッシュ・パーティション化の計画
パーティション行ソース名が 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 つはアクセスされる各パーティションのサブパーティションを反復するハッ
シュ・パーティション行ソースです。
19-12
Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパーティション・オブジェクトの表示
次の例では、プルーニングが実行されていないので、レンジ・パーティション行ソースはパー
ティション 1 から 5 までを反復します。各パーティション内では、ハッシュ・パーティション
行ソースは現在のパーティションのサブパーティション 1 から 3 までを反復します。その結果、
表アクセス行ソースがサブパーティション 1 ～ 15 にアクセスします。つまり、コンポジット・
オブジェクトのすべてのサブパーティションにアクセスすることになります。
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 は単一のサブパーティションにアクセスするだけで済み
ます。そのサブパーティションの番号はコンパイル時に認識されるので、ハッシュ・パーティ
ション行ソースは必要ありません。
最後に、次の文を検討します。
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 がサブ
パーティションの番号を実行時に判別することを意味します。
EXPLAIN PLAN の使用方法
19-13
EXPLAIN PLAN によるパーティション・オブジェクトの表示
パーシャル・パーティション・ワイズ結合の例
次の例では、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 ;
------------------------------------------------------------------------------------------------------------| 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)、
表キューを介して、パーシャル・パーティション・ワイズ結合を実行する同じスレーブに送ら
れることを示します。
19-14
Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパーティション・オブジェクトの表示
次の例では、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 |
|
-------------------------------------------------------------------------------------------------------------
この計画は、オプティマイザが 2 つの列の一方からパーシャル・パーティション・ワイズ結合
を選択することを示します。PX SEND のノード・タイプは PARTITION(KEY) で、PQ Distrib 列
にはパーティション・キーを示すテキスト PART (KEY) が含まれています。これは、EMP_COMP
のスキャンと結合を実行するパラレル・スレーブに送られる結合列 department_id に基づい
て、dept2 表が再びパーティション化されることを意味します。
例 19-10 および例 19-11 では、問合せオプティマイザがこの問合せのコストに基づいて異なる計
画を選択する可能性があるため、パーシャル・パーティション・ワイズ結合を明示的に強制す
るために、PQ_DISTRIBUTE ヒントが使用されていることに注意してください。
EXPLAIN PLAN の使用方法
19-15
EXPLAIN PLAN によるパーティション・オブジェクトの表示
フル・パーティション・ワイズ結合の例
次の例では、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 |
|
-------------------------------------------------------------------------------------------------------------
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 リスト列が使用可能ですが、
これについては次の項で説明します。
19-16
Oracle Database パフォーマンス・チューニング・ガイド
EXPLAIN PLAN によるパーティション・オブジェクトの表示
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)
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 の使用方法
19-17
PLAN_TABLE 列
ドメイン索引および 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
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 文に含まれる表またはビューの一意の別名です。索引の場合
は、基礎となる表のオブジェクトの別名です。
19-18
Oracle Database パフォーマンス・チューニング・ガイド
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
この操作によってアクセスされるバイト数の問合せ最適化アプロー
チによる見積りです。
OTHER_TAG
VARCHAR2(255)
OTHER 列の内容を記述します。値は次のとおりです。
■
■
■
■
■
■
■
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): パラレル実
行。ステップの入力は、同じパラレル処理の前のステップから
受け取ります。子からのプロセス間通信はありません。
EXPLAIN PLAN の使用方法
19-19
PLAN_TABLE 列
表 19-1 PLAN_TABLE 列（続き）
列
型
説明
PARTITION_START
VARCHAR2(255)
アクセスされるパーティション範囲の開始パーティションです。こ
れは、次のいずれかの値をとります。
n は、開始パーティションが SQL コンパイラで識別され、そのパー
ティション番号が n で示されることを意味します。
KEY は、開始パーティションが実行時にパーティション・キー値か
ら識別されることを意味します。
ROW REMOVE_LOCATION は、開始パーティション（終了パーティ
ションと同じになります）が実行時に、取得される各レコードの位
置から計算されることを意味します。レコードの位置は、ユーザー
またはグローバル索引によって獲得されます。
INVALID は、アクセスしたパーティションの範囲が空であること
を意味します。
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 Database データ・ウェアハウス・ガイド』を参照して
ください。
CPU_COST
NUMERIC
問合せオプティマイザのアプローチによって見積もられた操作の
CPU コストです。この列の値は、操作に必要なシステム・サイクル
数に比例します。ルールベース・アプローチを使用する文では、こ
の列は NULL になります。
IO_COST
NUMERIC
問合せオプティマイザのアプローチによって見積もられた操作の
I/O コストです。この列の値は、操作で読み込まれるデータ・ブ
ロックの数に比例します。ルールベース・アプローチを使用する文
では、この列は NULL になります。
TEMP_SPACE
NUMERIC
問合せオプティマイザのアプローチで見積もられた、操作で使用さ
れる一時領域をバイト単位で表したものです。ルールベース・アプ
ローチを使用する文の場合、または一時領域を使用しない操作の場
合、この列は NULL です。
ACCESS_PREDICATES
VARCHAR2(4000)
アクセス構造の行を特定する場合に使用する述語です。たとえば、
索引レンジ・スキャンの開始や停止の述語などがあります。
FILTER_PREDICATES
VARCHAR2(4000)
フィルタにかけた後で行を生成する場合に使用する述語です。
19-20
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 の各組合せおよび
その実行計画におけるそれぞれの意味を示します。
表 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 は、開始キーまたは終了キーがない場合にビットマップ索
引の全体スキャンを実行します。
EXPLAIN PLAN の使用方法
19-21
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
BITMAP
MERGE
レンジ・スキャンの結果の複数のビットマップを 1 つのビットマップに
マージします。
BITMAP
MINUS
片方のビットマップのビットを、もう一方のビットマップから減算しま
す。行ソースは否定述語に対して使用されます。減算が発生する可能性
があるビットマップを作成する非否定述語がある場合にのみ使用できま
す。19-10 ページの「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 の取出し。オプション列には、
ユーザー定義ドメイン・インデックス・コスト関数から与えられた情報
が含まれています。
FILTER
.
行のセットを受け取り、そのいくつかを取り除き、残りを戻す処理。
FIRST ROW
.
問合せで選択される最初の行のみの取出し。
FOR UPDATE
.
FOR UPDATE 句が含まれている問合せによって選択される行を取り出し、
ロックする処理。
HASH
GROUP BY
GROUP BY 句を持つ問合せで、行のセットを複数のグループにハッシュ
する処理。
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
ハッシュ（右側）外部結合。
19-22
Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
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（および列の値）の取得。
ソート順は定義できません。索引付けされた列に対してのみ、全表ス
キャンと比較されます。コストベース・オプティマイザでのみ使用可能
です。
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 句を含んでいる問合せに対する、階層順での行の取出し。
MAT_VIEW REWITE
ACCESS
FULL
マテリアライズド・ビューのすべての行の取出し。
MAT_VIEW REWITE
ACCESS
SAMPLE
マテリアライズド・ビューのサンプル行の取出し。
MAT_VIEW REWITE
ACCESS
CLUSTER
索引クラスタのキーの値に基づいた、マテリアライズド・ビューからの
行の取出し。
MAT_VIEW REWITE
ACCESS
HASH
ハッシュ・クラスタのキーの値に基づいた、マテリアライズド・ビュー
からの行の取出し。
MAT_VIEW REWITE
ACCESS
BY ROWID RANGE
ROWID 範囲に基づいたマテリアライズド・ビューからの行の取出し。
MAT_VIEW REWITE
ACCESS
SAMPLE BY ROWID
RANGE
ROWID 範囲に基づいたマテリアライズド・ビューからのサンプル行の
取出し。
MAT_VIEW
REWITE ACCESS
BY USER ROWID
ユーザー指定の ROWID を使用してマテリアライズド・ビューの行が指
定される場合。
（これらは結合操作
です。）
（これらはアクセス
方法です。）
EXPLAIN PLAN の使用方法
19-23
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
MAT_VIEW REWITE
ACCESS
BY INDEX ROWID
マテリアライズド・ビューがパーティション化されておらず、索引を使
用して行が指定される場合。
MAT_VIEW REWITE
ACCESS
BY GLOBAL INDEX
ROWID
マテリアライズド・ビューがパーティション化されており、グローバル
索引のみを使用して行が指定される場合。
MAT_VIEW REWITE
ACCESS
BY LOCAL INDEX
ROWID
マテリアライズド・ビューがパーティション化されており、1 つ以上の
ローカル索引と、場合によってはいくつかのグローバル索引を使用して
行が指定される場合。
パーティション区間 :
パーティション区間は次のようにして計算されている可能性があります。
前の PARTITION ステップによって決定される場合。この場合、
PARTITION_START 列の値と PARTITION_STOP 列の値は PARTITION
ステップ内の値をレプリケートし、PARTITION_ID には PARTITION ス
テップの ID が組み込まれます。PARTITION_START および
PARTITION_STOP に使用できる値は、NUMBER(n)、KEY、INVALID で
す。
MAT_VIEW REWRITE ACCESS または INDEX ステップ自体で決定される
場合。この場合、PARTITION_ID にはそのステップの ID が組み込まれ
ます。PARTITION_START および PARTITION_STOP に使用できる値
は、NUMBER(n)、KEY、ROW REMOVE_LOCATION（MAT_VIEW REWRITE
ACCESS のみ）および INVALID です。
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
多数のパーティション（サブセット）へのアクセス。
PARTITION
ALL
すべてのパーティションへのアクセス。
PARTITION
INLIST
IN リスト述語を基準にしたイテレータ。
PARTITION
INVALID
アクセスするよう設定されているパーティションが空であることを示し
ます。
PX ITERATOR
BLOCK、CHUNK
パラレル・スレーブ・セット間でのブロックまたはチャンク範囲へのオ
ブジェクトの分割を実装します。
PX COORDINATOR
.
パラレル問合せスレーブを使用して下位のパラレル計画を制御、スケ
ジュールおよび実行する問合せコーディネータを実装します。また、パ
ラレルに実行され、常に下位に PX SEND QC 操作を持つ計画部分の終わ
りとして、シリアライズ・ポイントを表します。
PX PARTITION
.
セマンティクスは通常の PARTITION 操作と同じですが、パラレル計画
に表示されます。
（これらは結合操作
です。）
19-24
Oracle Database パフォーマンス・チューニング・ガイド
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
PX RECEIVE
.
PX SEND ノード上で実行される送信側 / プロデューサ（QC またはス
レーブ）からパーティション化されたデータを読み取る、コンシューマ
/ 受信側スレーブ・ノードを示します。以前は、この情報は
DISTRIBUTION 列に表示されていました。19-21 ページの表 19-2 を参照
してください。
PX SEND
QC (RANDOM)、
HASH、RANGE
スレーブの 2 つのパラレル・セットの間における配分方法を実装します。
2 つのスレーブ・セット間の境界と、送信側 / プロデューサ側（QC ま
たはスレーブ）でのデータのパーティション化方法を示します。以前は、
この情報は DISTRIBUTION 列に表示されていました。19-21 ページの表
19-2 を参照してください。
REMOTE
.
リモート・データベースからのデータの取出し。
SEQUENCE
.
順序値のアクセスを伴う処理。
SORT
AGGREGATE
選択した行のグループにグループ関数を適用した結果として取得される
単一行の取出し。
SORT
UNIQUE
行のセットをソートし、重複をなくす処理。
SORT
GROUP BY
GROUP BY 句を持つ問合せで、行のセットを複数のグループにソートす
る処理。
SORT
JOIN
マージ結合の前に、一連の行をソートする操作。
SORT
ORDER BY
ORDER BY 句を持つ問合せに対して行のセットをソートする処理。
TABLE ACCESS
FULL
表のすべての行の取出し。
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
表がパーティション化されており、グローバル索引のみを使用して行が
指定される場合。
（これらはアクセス
方法です。）
EXPLAIN PLAN の使用方法
19-25
PLAN_TABLE 列
表 19-3 EXPLAIN PLAN によって生成される OPERATION 値と OPTIONS 値（続き）
操作
オプション
説明
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-26
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 操作など、モジュール内のアクションを指定します。
セッション : 任意のデータベース・セッション識別子（SID）に基づいて、ローカル・イン
スタンスのセッションを指定します。
インスタンス : インスタンス名に基づいて任意のインスタンスを指定します。
トレース情報がファイルに書き込まれた後、この情報を trcsess ユーティリティによって統
合し、TKPROF などの分析ユーティリティによって診断できます。
単一インスタンスの Oracle データベースでサービスを作成するには、DBMS_SERVICE パッ
ケージの CREATE_SERVICE プロシージャを使用するか、または SERVICE_NAMES 初期化パラ
メータを設定できます。
モジュール名およびアクション名は、アプリケーション開発者が設定します。たとえば、
PL/SQL プログラムでこれらの値を設定するには、DBMS_APPICATION_INFO パッケージの
SET_MODULE および SET_ACTION プロシージャを使用します。
End to End Application Tracing への推奨インタフェースは、Oracle Enterprise Manager です。
Enterprise Manager を使用すると、各コンシューマ・タイプの上位コンシューマを表示し、特
定のコンシューマに関する統計収集および SQL トレースを使用可能または使用禁止にできま
す。End to End Application Tracing の管理には、できるかぎり Enterprise Manager を使用する
必要があります。詳細は、
『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』
を参照してください。Oracle Enterprise Manager を使用できない場合は、以降の各項で説明す
るように、DBMS_MONITOR API を使用して、この機能を管理できます。
20-2
■
エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化
■
End to End Application Tracing の収集した統計の表示
■
エンド・トゥ・エンド・トレースにおける有効化および無効化
■
エンド・トゥ・エンド・トレースにおける使用可能なトレースの表示
Oracle Database パフォーマンス・チューニング・ガイド
End to End Application Tracing
関連項目 :
■
■
■
■
サービスの詳細は、
『Oracle Database 概要』を参照してください。
OCI アプリケーションにおける必要なパラメータの設定の詳細は、
『Oracle Call Interface プログラマーズ・ガイド』を参照してください。
DBMS_MONITOR、DBMS_SESSION、DBMS_SERVICE および
DBMS_APPICATION_INFO の各パッケージの詳細は、『Oracle
Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレ
ンス』を参照してください。
V$ ビューおよび初期化パラメータの詳細は、
『Oracle Database リファ
レンス』を参照してください。
エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化
PL/SQL を使用して適切な統計を収集するには、DBMS_MONITOR パッケージのプロシージャを
使用して、クライアント識別子、サービス、モジュールまたはアクションに対する統計収集を
使用可能にする必要があります。
統計は次の基準でも収集できます。
■
クライアント識別子に対する統計収集
■
サービス、モジュールおよびアクションに対する統計収集
デフォルト・レベルは、セッション・レベルの統計収集です。統計収集はデータベース全体を
対象にしており、インスタンスの再起動後も引き続き行われます。
クライアント識別子に対する統計収集
プロシージャ 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 アクションに関する統計
アプリケーション・トレース・ツールの使用方法
20-3
End to End Application Tracing
プロシージャ SERV_MOD_ACT_STAT_DISABLE では、サービス、モジュールおよびアクション
の組合せに対する統計収集が使用禁止になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_DISABLE(service_name => 'ACCTG',
module_name => 'GLEDGER', action_name => 'INSERT ITEM');
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-4
Oracle Database パフォーマンス・チューニング・ガイド
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
...
特定のセッションのトレースを使用可能にするには、適切な値を使用します。
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);
アプリケーション・トレース・ツールの使用方法
20-5
End to End Application Tracing
DBMS_MONITOR パッケージは DBA ロールが付与されているユーザーのみが起動できる一方、
任意のユーザーが DBMS_SESSION パッケージを使用して、所有するセッションの SQL トレー
スを使用可能にできます。SESSION_TRACE_ENABLE プロシージャは、任意のユーザーが起動
でき、所有するセッションに対するセッション・レベルの SQL トレースを使用可能にできま
す。たとえば、次のようにします。
EXECUTE DBMS_SESSION.SESSION_TRACE_ENABLE(waits => TRUE, binds => FALSE);
TRUE 引数は、待機情報がトレースに含められることを指定します。FALSE 引数は、バインド
情報がトレースに含められないことを指定します。
SESSION_TRACE_DISABLE プロシージャは、起動セッションのトレースを使用禁止にします。
たとえば、次のようにします。
EXECUTE DBMS_SESSION.SESSION_TRACE_DISABLE();
インスタンス全体またはデータベース全体のトレース
DATABASE_TRACE_ENABLE プロシージャは、任意のインスタンスまたはデータベース全体の
SQL トレースを使用可能にします。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.DATABASE_TRACE_ENABLE(waits => TRUE, binds => FALSE,
instance_name => 'inst1');
この例では inst1 インスタンスが指定されているため、このインスタンスのトレースが使用可
能になります。TRUE 引数は、待機情報がトレースに含められることを指定します。FALSE 引
数は、バインド情報がトレースに含められないことを指定します。この例は、inst1 インスタ
ンス内の全 SQL を SQL トレースすることになります。
DATABASE_TRACE_ENABLE プロシージャは、他のすべてのセッション・レベルのトレースよ
り優先されますが、クライアント識別子、サービス、モジュールおよびアクションのトレース
を補完します。すべての新規セッションは、DATABASE_TRACE_DISABLE プロシージャがコー
ルされるまで、このプロシージャで指定された待機およびバインド情報を継承します。
instance_name パラメータを指定してこのプロシージャを起動すると、指定されたインスタ
ンスのセッション・レベルの SQL トレースがリセットされます。instance_name パラメータ
を指定せずにこのプロシージャを起動すると、データベース全体のセッション・レベルの SQL
トレースがリセットされます。
DATABASE_TRACE_DISABLE プロシージャは、インスタンス全体またはデータベース全体のト
レースを使用禁止にします。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.DATABASE_TRACE_DISABLE(instance_name => 'inst1');
この例では、すべてのセッション・レベルの SQL トレースは、inst1 インスタンスに対して使
用禁止になります。データベース全体に対してセッション・レベルの SQL トレースを使用禁止
にするには、instance_name パラメータを指定せずに DATABASE_TRACE_DISABLE プロ
シージャを起動します。
EXECUTE DBMS_MONITOR.DATABASE_TRACE_DISABLE();
エンド・トゥ・エンド・トレースにおける使用可能なトレースの表示
未処理のトレースはすべて、Oracle Enterprise Manager レポートで、または
DBA_ENABLED_TRACES ビューで表示できます。DBA_ENABLED_TRACES ビューでは、トレー
ス・タイプを含め、トレースを使用可能にした方法に関する詳細を判断できます。トレース・
タイプは、クライアント識別子、セッション、サービス、データベース、またはサービス、モ
ジュールおよびアクションの組合せについてトレースが使用可能かどうかを指定します。
20-6
Oracle Database パフォーマンス・チューニング・ガイド
trcsess ユーティリティの使用方法
trcsess ユーティリティの使用方法
trcsess ユーティリティでは、次の複数の基準に基づいて、選択されたトレース・ファイルか
らのトレース出力が統合されます。
■
セッション ID
■
クライアント ID
■
サービス名
■
アクション名
■
モジュール名
trcsess によりトレース情報が 1 つの出力ファイルにマージされた後、出力ファイルを
TKPROF によって処理できます。
trcsess は、パフォーマンスまたはデバッグを向上させるため、特定のセッションのトレース
を統合する際に便利です。特定のセッションのトレースは、専用サーバー・モデルでは、1 つ
の専用プロセスが存続期間中ずっと 1 つのセッションに対応するため、通常は問題になりませ
ん。このセッションのトレース情報はすべて、このセッションに対応する専用サーバーに属す
るトレース・ファイルで参照できます。ただし、共有サーバー構成では、ユーザー・セッショ
ンが様々なプロセスで対応される場合があります。ユーザー・セッションに関連するトレース
は、様々なプロセスに属する各種トレース・ファイル間で分散されます。そのため、セッショ
ンの存続期間におけるすべての状況を把握しにくくなります。
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-7
SQL トレースと TKPROF について
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
SQL トレースと TKPROF について
SQL トレース機能および TKPROF を使用すると、アプリケーションが実行する SQL 文の効率
を正確に評価できます。最善の結果を得るには、EXPLAIN PLAN を単体ではなくこれらのツー
ルとともに使用してください。
SQL トレース機能について
SQL トレース機能は、個々の SQL 文に関するパフォーマンス情報を提供します。SQL トレー
ス機能は、文単位に次の統計を生成します。
20-8
■
解析、実行、フェッチのカウント
■
CPU 時間と経過時間
■
物理読込みと論理読込み
■
処理された行数
■
ライブラリ・キャッシュでのミス
■
それぞれの解析が行われるユーザー名
■
各コミットおよびロールバック
■
各 SQL 文の待機イベント・データおよび各トレース・ファイルの要約
Oracle Database パフォーマンス・チューニング・ガイド
SQL トレースと TKPROF について
また、SQL 文のカーソルがクローズされている場合は、SQL トレースにより次の内容を含む行
ソース情報が提供されます。
■
■
各 SQL 文の実際の実行計画を示す行操作
行数、一貫性のある読込みの数、物理読込み数、物理書込み数および行の各操作の経過時
間
1 つのセッションまたはインスタンスに対して SQL トレース機能を使用可能にできますが、か
わりに DBMS_SESSION または DBMS_MONITOR パッケージを使用することをお薦めします。
セッションまたはインスタンスに対して SQL トレース機能を使用可能にすると、ユーザー・
セッションまたはインスタンスで実行されるすべての SQL 文のパフォーマンス統計がトレー
ス・ファイルに格納されます。SQL トレース機能を使用するとパフォーマンスに重大な影響を
与えることがあり、システム・オーバーヘッドの増加、過剰な CPU 使用率およびディスク領域
の不足をもたらす場合があります。
関連項目 : DBMS_SESSION または DBMS_MONITOR パッケージを使用し
てセッションまたはインスタンスに対する SQL トレースを使用可能にす
る方法の詳細は、20-4 ページの「エンド・トゥ・エンド・トレースにおけ
る有効化および無効化」を参照してください。
Oracle では、セッションまたはクライアント ID などの特定の基準に基づいて複数のトレース・
ファイルからトレース情報を統合する、trcsess コマンドライン・ユーティリティが提供され
ています。20-7 ページの「trcsess ユーティリティの使用方法」を参照してください。
TKPROF について
TKPROF プログラムを実行すると、トレース・ファイルの内容をフォーマットし判読可能な
ファイルとして出力できます。TKPROF は次のことも実行します。
■
統計をデータベースに格納する SQL スクリプトを作成します。
■
SQL 文の実行計画を判断します。
注意 : SQL 文のカーソルがクローズされていない場合、TKPROF 出力に
は、SQL 文の実際の実行計画は自動的に含められません。この場合は、
TKPROF で EXPLAIN オプションを使用して、実行計画を生成できます。
TKPROF は、実行した各文を、消費したリソースおよびコールした回数、処理した行数ととも
にレポートします。この情報を使用すると、リソースを最も多く使用している文を簡単に検出
できます。経験、または参考にできる基準をもとに、使用されたリソースが実行された作業に
対して妥当であるかどうかを評価できます。
アプリケーション・トレース・ツールの使用方法
20-9
SQL トレース機能と TKPROF の使用方法
SQL トレース機能と TKPROF の使用方法
SQL トレース機能および TKPROF を使用するには、次の手順に従います。
1.
トレース・ファイル管理用の初期化パラメータを設定します。
20-10 ページの「手順 1: トレース・ファイル管理用の初期化パラメータの設定」を参照し
てください。
2.
対象とするセッションに対して SQL トレース機能を使用可能にして、アプリケーションを
実行します。手順 2 では、アプリケーションによって発行された SQL 文に関する統計を含
むトレース・ファイルが作成されます。
20-12 ページの「手順 2: SQL トレース機能を使用可能にする方法」を参照してください。
3.
手順 2 で作成されるトレース・ファイルを判読可能な出力ファイルに変換するために、
TKPROF を実行します。手順 3 ではオプションとして、データベースに統計を格納するの
に使用できる SQL スクリプトを作成できます。
20-13 ページの「手順 3: TKPROF によるトレース・ファイルのフォーマット」を参照して
ください。
4.
手順 3 で作成した出力ファイルを解釈します。
20-17 ページの「手順 4: TKPROF 出力の解釈」を参照してください。
5.
任意で、手順 3 で作成した SQL スクリプトを実行してデータベースに統計を格納します。
20-21 ページの「手順 5: SQL トレース機能統計の格納」を参照してください。
次の項では、これらの各手順について詳しく説明します。
手順 1: トレース・ファイル管理用の初期化パラメータの設定
セッションに対して SQL トレース機能が使用可能になると、Oracle はトレース・ファイルを生
成します。このファイルには、そのセッションのトレースされた SQL 文に関する統計が記録さ
れています。インスタンスに対して SQL トレース機能が使用可能になると、Oracle はプロセス
ごとに個別のトレース・ファイルを作成します。SQL トレース機能を有効にする前に、次のこ
とを行ってください。
1.
TIMED_STATISTICS、MAX_DUMP_FILE_SIZE および USER_DUMP_DEST の初期化パラ
メータ設定をチェックします。表 20-1 を参照してください。
表 20-1 SQL トレース機能を有効にする前にチェックする初期化パラメータ
20-10
パラメータ
説明
TIMED_STATISTICS
これにより、SQL トレース機能による CPU 時間や経過時間などの
時間統計の収集、および動的パフォーマンス表の中の様々な統計の
収集が使用可能または使用禁止にできます。デフォルト値は false
であり、時間計測は使用禁止になっています。true にすることに
よって時間計測が使用可能になります。時間計測を使用可能にする
と、下位レベル操作に対する時間計測呼出しが余分に発生します。
これは動的パラメータです。これはセッション・パラメータでもあ
ります。
MAX_DUMP_FILE_SIZE
SQL トレース機能がインスタンス・レベルで使用可能にされている
ときは、サーバーに対するすべてのコールはオペレーティング・シ
ステムのファイル形式でテキスト行を生成します。これらのファイ
ルの最大サイズ（オペレーティング・システム・ブロック単位）
は、初期化パラメータによって制限されます。デフォルト値は 500
です。トレース出力が切り捨てられている場合、別のトレース・
ファイルを生成する前にこのパラメータの値を大きくしてくださ
い。これは動的パラメータです。これはセッション・パラメータで
もあります。
Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
表 20-1 SQL トレース機能を有効にする前にチェックする初期化パラメータ（続き）
パラメータ
説明
USER_DUMP_DEST
このパラメータで、オペレーティング・システムの規則に従って、
トレース・ファイルの出力先をフルパスで指定する必要がありま
す。デフォルト値は、使用するオペレーティング・システムのシス
テム・ダンプのデフォルトの出力先です。この値は、ALTER
SYSTEM SET USER_DUMP_DEST= newdir を使用して変更できま
す。これは動的パラメータです。これはセッション・パラメータで
もあります。
関連項目 :
■
■
■
■
1.
STATISTICS_LEVEL、DB_CACHE_ADVICE、TIMED_STATISTICS ま
たは TIMED_OS_STATISTICS 初期化パラメータを設定する場合の考
慮事項は、5-6 ページの「統計の解釈」を参照してください。
STATISTICS_LEVEL の設定の詳細は、10-5 ページの「統計収集のレ
ベルの設定」を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
動的パフォーマンス・ビュー V$STATISTICS_LEVEL の詳細は、
『Oracle Database リファレンス』を参照してください。
結果のトレース・ファイルを認識する方法を考えます。
トレース・ファイルを名前で区別できるようにしてください。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 リファレンス』を参照してください。
2.
オペレーティング・システムがファイルの複数のバージョンを保持している場合、SQL ト
レース機能が生成するトレース・ファイルの数に対して、バージョンの制限が十分高いこ
とを確認してください。
3.
生成されたトレース・ファイルの所有者は、データベース管理者以外のオペレーティン
グ・システム・ユーザーの場合があります。データベース管理者が TKPROF を実行してこ
れらのファイルをフォーマットする場合は、このユーザーが前もって、管理者がトレー
ス・ファイルを利用できる状態にしておく必要があります。
関連項目 :
■
■
STATISTICS_LEVEL の設定の詳細は、10-5 ページの「統計収集のレ
ベルの設定」を参照してください。
STATISTICS_LEVEL 初期化パラメータの詳細は、
『Oracle Database
リファレンス』を参照してください。
アプリケーション・トレース・ツールの使用方法
20-11
SQL トレース機能と TKPROF の使用方法
手順 2: SQL トレース機能を使用可能にする方法
セッションに対して SQL トレース機能を使用可能にするには、次のいずれかを使用します。
■
DBMS_SESSION.SET_SQL_TRACE プロシージャ
■
ALTER SESSION SET SQL_TRACE = TRUE;
注意 : SQL トレース機能を実行するとシステムのオーバーヘッドが増加
するため、この機能は SQL 文をチューニングするときにのみ使用可能に
し、チューニングが終了してから使用禁止にしてください。かわりに
DBMS_SESSION または DBMS_MONITOR パッケージを使用して、セッ
ションまたはインスタンスに対する SQL トレースを使用可能にすること
をお薦めします。これらのパッケージの使用方法の詳細は、20-4 ページの
「エンド・トゥ・エンド・トレースにおける有効化および無効化」を参照
してください。
ALTER SESSION 文を挿入するには、アプリケーションを修正する必要が
あります。たとえば、Oracle Forms で ALTER SESSION 文を発行するに
は、-s オプションを指定して Oracle Forms を起動するか、または
statistics オプションを指定して Oracle Forms（Design）を起動して
ください。Oracle Forms の詳細は、『Oracle Forms Reference』を参照して
ください。
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-12
Oracle Database パフォーマンス・チューニング・ガイド
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
rows
-----0
0
14
Misses in library cache during parse: 1
Parsing user id: (8) SCOTT
Rows
Execution Plan
------- --------------------------------------------------14 MERGE JOIN
4
SORT JOIN
4
TABLE ACCESS (FULL) OF 'DEPT'
14
SORT JOIN
14
TABLE ACCESS (FULL) OF 'EMP'
この文では、TKPROF 出力に次の情報が含まれています。
■
SQL 文のテキスト
■
表形式で示された SQL トレース統計
■
文の解析と実行におけるライブラリ・キャッシュ・ミスの回数
■
文を最初に解析したユーザー
■
EXPLAIN PLAN によって生成された実行計画
TKPROF は、トレース・ファイルのユーザー・レベル文と再帰的 SQL コールの要約も提供しま
す。
アプリケーション・トレース・ツールの使用方法
20-13
SQL トレース機能と TKPROF の使用方法
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 時間
PRSELA
解析に費やされた経過時間
PRSDSK
解析中のディスクに対する物理読込みの回数
PRSQRY
解析中の一貫モード・ブロック読込みの回数
PRSCU
解析中の現行モード・ブロック読込みの回数
PRSMIS
解析中のライブラリ・キャッシュ・ミスの回数
EXECNT
実行回数
EXECPU
実行に費やされた CPU 時間
EXEELA
実行に費やされた経過時間
EXEDSK
実行中のディスクに対する物理読込みの回数
EXEQRY
実行中の一貫モード・ブロック読込みの回数
EXECU
実行中の現行モード・ブロック読込みの回数
EXEROW
実行中に処理された行数
EXEMIS
実行中のライブラリ・キャッシュ・ミスの回数
FCHCNT
フェッチ回数
FCHCPU
フェッチに費やされた CPU 時間
FCHELA
フェッチに費やされた経過時間
FCHDSK
フェッチ中のディスクに対する物理読込みの回数
FCHQRY
フェッチ中の一貫モード・ブロック読込みの回数
FCHCU
フェッチ中の現行モード・ブロック読込みの回数
20-14
Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
表 20-2 TKPROF 引数（続き）
引数
説明
FCHROW
フェッチされた行数
USERID
カーソルを解析するユーザーのユーザー ID
PRINT
出力ファイルから最初に整数でソートされた SQL 文のみのリストを作成します。このパラ
メータを指定しないと、TKPROF はトレースした SQL 文すべてのリストを作成します。こ
のパラメータは、INSERT オプションの SQL スクリプトには影響しません。SQL スクリプ
トは、常に、トレースされたすべての SQL 文に対する挿入データを生成します。
AGGREGATE
AGGREGATE = NO を指定すると、TKPROF は同じ SQL テキストに対する複数のユーザーの
データを集計しません。
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 が作成され、最後に
削除されます。
EXPLAIN
トレース・ファイルの各 SQL 文の実行計画を判断して、これらの実行計画を出力ファイル
に書き込みます。TKPROF は、このパラメータに指定されたユーザーとパスワードを使用し
て Oracle に接続した後、EXPLAIN PLAN 文を発行して実行計画を判断します。指定された
ユーザーは、CREATE SESSION システム権限を持っている必要があります。EXPLAIN オプ
ションが使用されている場合は、TKPROF が大きなトレース・ファイルを処理するのに要す
る時間が長くなります。
RECORD
トレース・ファイル内の非再帰的 SQL 文をすべて収録した SQL スクリプトを、指定した
filename4 で作成します。トレース・ファイルのユーザー・イベントを再実行する場合
に、このオプションを指定できます。
WIDTH
EXPLAIN PLAN など、一部の TKPROF 出力の出力行幅を制御する整数です。このパラ
メータは、TKPROF 出力の後処理に役立ちます。
アプリケーション・トレース・ツールの使用方法
20-15
SQL トレース機能と TKPROF の使用方法
TKPROF 文の例
この項では、TKPROF の 2 つの使用例を簡単に説明します。TKPROF 出力例の詳細は、20-26
ページの「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 文が使用されます。これを使用してア
クセス・パスおよび行ソース行数を取得できます。
注意 : SQL 文のカーソルがクローズされていない場合、TKPROF 出力に
は、SQL 文の実際の実行計画は自動的に含められません。この場合は、
TKPROF で EXPLAIN オプションを使用して、実行計画を生成できます。
■
■
■
■
20-16
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 パラメータを常に使用してください。
Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
手順 4: TKPROF 出力の解釈
この項では、TKPROF 出力を解釈するためのヒントを示します。
■
TKPROF の表形式の統計
■
行ソースの操作
■
待機イベント情報
■
統計の精度の解釈
■
再帰的コールについて
■
TKPROF のライブラリ・キャッシュ・ミス
■
SQL トレースでの文の切捨て
■
TKPROF での SQL 文を発行するユーザーの識別
■
TKPROF の実行計画
■
チューニングする文の決定
TKPROF は非常に有用な分析を提供しますが、効率の最も正確なメジャーは、対象アプリケー
ションの実際のパフォーマンスです。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
すべての解析コール、実行コールまたはフェッチ・コールに対して、ディ
スク上のデータファイルから物理的に読み込んだデータ・ブロックの総数
です。
アプリケーション・トレース・ツールの使用方法
20-17
SQL トレース機能と TKPROF の使用方法
表 20-4 解析、実行およびフェッチの SQL トレース統計（続き）
SQL トレース統計
意味
QUERY
すべての解析コール、実行コールまたはフェッチ・コールに対して、一貫
モードで取り出されたバッファの総数です。通常バッファは問合せに対し
て一貫モードで取り出されます。
CURRENT
現行モードで取り出されたバッファの総数です。INSERT、UPDATE、
DELETE などの文では、バッファは現行モードで取り出されます。
処理された行に関する統計は、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 出力では、行ソースの操作の列で次の点に注意してください。
20-18
■
cr は、行ソースにより実行される読取り一貫性を指定します。
■
r は、行ソースにより実行される物理読込みを指定します。
■
w は、行ソースにより実行される物理書込みを指定します。
■
time は、時間をマイクロ秒単位で指定します。
Oracle Database パフォーマンス・チューニング・ガイド
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 文の処理
に必要なリソースの合計を計算するときは、その文自体の統計に加えて、その文を原因とする
再帰的コールの統計もあわせて考慮する必要があります。
注意 : 再帰的 SQL 統計は、SQL レベルの操作には組み込まれません。た
だし、再帰的 SQL 統計は、トリガーなど SQL レベルより下の操作には組
み込まれます。詳細は、20-26 ページの「トリガー・トラップの回避」を
参照してください。
TKPROF のライブラリ・キャッシュ・ミス
TKPROF は、各 SQL 文の解析ステップと実行ステップの結果として生じるライブラリ・キャッ
シュ・ミス回数のリストも作成します。これらの統計は、表形式の統計に続く別の行に表示さ
れます。文でライブラリ・キャッシュ・ミスが発生しなかった場合、TKPROF はその統計のリ
ストを作成しません。20-13 ページの「TKPROF の出力例」における解析ステップでは、ライブ
ラリ・キャッシュ・ミスが 1 回発生し、実行ステップではライブラリ・キャッシュ・ミスは発
生しませんでした。
アプリケーション・トレース・ツールの使用方法
20-19
SQL トレース機能と TKPROF の使用方法
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 は実行計画の各
ステップによって処理された行数も表示します。
注意 : インスタンスの始動直後に生成されたトレース・ファイルは、ス
タートアップ・プロセスのアクティビティを反映するデータを含みます。
特に、これらは、システム・グローバル領域（SGA）のキャッシュがいっ
ぱいになったときの不均衡な量の I/O アクティビティを反映します。
チューニングを行うときには、このようなトレース・ファイルは無視して
ください。
関連項目 : 実行計画の解釈に関する詳細は、第 19 章「EXPLAIN PLAN
の使用方法」を参照してください。
チューニングする文の決定
CPU リソースまたはディスク・リソースを最も消費する SQL 文を検出する必要があります。
TIMED_STATISTICS パラメータがオンになっている場合は、CPU の高いアクティビティを
CPU 列で見つけられます。TIMED_STATISTICS がオンになっていない場合は、QUERY 列と
CURRENT 列をチェックします。
関連項目 : リソースを消費する文の検索例は、20-16 ページの「TKPROF
文の例」を参照してください。
ロックの問題と効率の悪い PL/SQL ループを除いて、問題の文を発見するためには CPU 時間
と経過時間のどちらも必要ありません。重要なのは、問合せモード（すなわち、読取り一貫性
の対象）と現行モード（読取り一貫性の非対象）の両方でアクセスするブロックの数です。セ
グメント・ヘッダーと更新されるブロックは現行モードで獲得されますが、すべての問合せ処
理と副問合せ処理は問合せモードでデータを要求します。これらのメジャーは、インスタンス
統計 CONSISTENT GETS および DB BLOCK GETS とまったく同じです。高ディスク・アクティ
ビティはディスク列で見つけられます。
20-20
Oracle Database パフォーマンス・チューニング・ガイド
SQL トレース機能と TKPROF の使用方法
次のリストには、ある 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
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 文を編集して、出力表の名前を変更してください。
アプリケーション・トレース・ツールの使用方法
20-21
SQL トレース機能と TKPROF の使用方法
出力表の問合せ
次の CREATE TABLE 文は TKPROF_TABLE を作成します。
CREATE TABLE TKPROF_TABLE (
DATE_OF_INSERT
DATE,
CURSOR_NUM
NUMBER,
DEPTH
NUMBER,
USER_ID
NUMBER,
PARSE_CNT
NUMBER,
PARSE_CPU
NUMBER,
PARSE_ELAP
NUMBER,
PARSE_DISK
NUMBER,
PARSE_QUERY
NUMBER,
PARSE_CURRENT
NUMBER,
PARSE_MISS
NUMBER,
EXE_COUNT
NUMBER,
EXE_CPU
NUMBER,
EXE_ELAP
NUMBER,
EXE_DISK
NUMBER,
EXE_QUERY
NUMBER,
EXE_CURRENT
NUMBER,
EXE_MISS
NUMBER,
EXE_ROWS
NUMBER,
FETCH_COUNT
NUMBER,
FETCH_CPU
NUMBER,
FETCH_ELAP
NUMBER,
FETCH_DISK
NUMBER,
FETCH_QUERY
NUMBER,
FETCH_CURRENT
NUMBER,
FETCH_ROWS
NUMBER,
CLOCK_TICKS
NUMBER,
SQL_STATEMENT
LONG);
出力表のほとんどの列は、フォーマットされた出力ファイルに記録されている統計と直接対応
しています。たとえば、PARSE_CNT 列の値は出力ファイルの解析ステップに関するカウント統
計に対応しています。
表 20-6 の列は、統計が入っている行を識別する際に役立ちます。
表 20-6 統計の行を識別する TKPROF_TABLE 列
列
説明
SQL_STATEMENT
SQL トレース機能が収集した統計行の対象となる SQL 文です。この列
のデータ型は LONG であるため式または WHERE 句条件ではこの列を使
用できません。
DATE_OF_INSERT
行が表に挿入された日時です。この値は、SQL トレース機能によって
統計が収集された時刻と完全には一致しません。
DEPTH
20-22
SQL 文が発行された再帰レベルを示します。たとえば、値 0 はユー
ザーがその文を発行したことを示します。値 1 は、Oracle が値 0 の文
（ユーザー発行の文）を処理するための再帰的コールとして、その文を
生成したことを示します。値 n は、Oracle がその文を値 n-1 の文を処
理する再帰的コールとして生成したことを示します。
USER_ID
この文を発行するユーザーを識別します。この値はフォーマットした
出力ファイルにも出力されます。
CURSOR_NUM
この列の値は、各 SQL 文が割り当てられているカーソルを追跡して記
録するために Oracle が使用します。
Oracle Database パフォーマンス・チューニング・ガイド
TKPROF の解釈における誤りの回避
文の実行計画は出力表に格納されません。次の問合せは、出力表からの統計を返します。これ
らの統計は、20-13 ページの「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
TKPROF の解釈における誤りの回避
この項では、TKPROF の解釈における細かなポイントをいくつか説明します。
■
引数トラップの回避
■
読取り一貫性トラップの回避
■
スキーマ・トラップの回避
■
タイム・トラップの回避
■
トリガー・トラップの回避
引数トラップの回避
実行時にバインドされる値を認識していない場合は、引数トラップに陥る可能性があります。
EXPLAIN PLAN は、SQL 文からバインド変数の型を判別できないので、型は常に varchar で
あると想定されます。バインド変数が実際には番号または日付である場合、TKPROF が暗黙的
データ変換を行い、その結果、効率の悪い計画が実行される可能性があります。これを回避す
るには、異なるデータ型を使用して問合せを試みます。
この問題を回避するには、各自で変換を行ってください。
関連項目 : TKPROF およびバインド変数の詳細は、19-4 ページの
「EXPLAIN PLAN の制限事項」を参照してください。
アプリケーション・トレース・ツールの使用方法
20-23
TKPROF の解釈における誤りの回避
読取り一貫性トラップの回避
次の例は、読取り一貫性トラップを示しています。コミットされていないトランザクションが
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
query current
----- ------0
0
0
0
101
0
rows
---0
0
1
Misses in library cache during parse: 1
Parsing user id: 01 (USER1)
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
20-24
Execution Plan
--------------------------------------------------SELECT STATEMENT
TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)
Oracle Database パフォーマンス・チューニング・ガイド
TKPROF の解釈における誤りの回避
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
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-25
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
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
20-26
Oracle Database パフォーマンス・チューニング・ガイド
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
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
rows
---------0
0
1
---------1
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
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)
アプリケーション・トレース・ツールの使用方法
20-27
TKPROF の出力例
)
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
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-28
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-29
TKPROF の出力例
20-30
Oracle Database パフォーマンス・チューニング・ガイド
第V部
Real Application Testing
第 V 部では、Real Application Testing を実行してデータベース変更の整合性を保持する方法に
ついて説明します。
Oracle Database の現実世界のテストを実行できるように、2 つの Real Application Testing ソ
リューションが用意されており、本番システムに影響するリスクなしで、システム変更が本番
ワークロードに及ぼす影響をテストできます。データベース・リプレイを使用すると、テスト・
システム上で完全な本番ワークロードをリプレイし、システム変更による全体の影響を評価で
きます。SQL パフォーマンス・アナライザを使用すると、SQL ワークロードを使用して、シス
テム変更が SQL パフォーマンスに及ぼす影響を評価できます。
第 V 部には次の章が含まれます。
■
第 21 章「データベース・リプレイ」
■
第 22 章「SQL パフォーマンス・アナライザ」
21
データベース・リプレイ
ハードウェアやソフトウェアのアップグレードなどのシステム変更を行う前に、通常は変更内
容を検証するためにテスト環境で広範囲なテストが実行されます。ただし、テストを実行して
も、テストには実際のワークロードを使用していないため、新規システムの本番運用が開始さ
れると、しばしば予期しない動作が発生します。テスト中に実際のワークロードをシミュレー
トできないことは、システム変更を検証する際の最大の問題点の 1 つです。
データベース・リプレイにより、本番のワークロード環境をテスト・システム上で本質的に再
作成して、システム変更を現実的にテストできます。データベース・リプレイを使用すると、
本番システム上でワークロードを取得し、テスト・システムでオリジナルのワークロードの正
確なタイミング、同時実行性およびトランザクション特性を使用して、取得されたワークロー
ドをリプレイできます。これにより、望ましくない結果、新しい競合ポイントまたは計画の回
帰など、変更による影響を完全に評価できます。広範囲な分析およびレポート機能が用意され
ており、新たに発生したエラーやパフォーマンスの相違など、潜在的な問題を識別する上で役
立ちます。
本番のワークロードを取得することで、シミュレーション・ワークロードまたはスクリプトを
開発する必要がなくなるため、大幅なコストの削減と時間の節約になります。データベース・
リプレイを使用すると、従来はロード・シミュレーション・ツールを使用して数か月かかって
いた複雑なアプリケーションの現実的なテストを数日で完了できます。これにより、迅速に変
更をテストして、従来よりも信頼性が高く低リスクの新規テクノロジを採用できます。
データベース・リプレイでは、外部クライアントのワークロードの取得がデータベース・レベ
ルで実行され、パフォーマンス・オーバーヘッドはわずかです。データベース・リプレイを使
用すると、次のようにすべての重要なシステム変更をテストできます。
■
■
データベースとオペレーティング・システムのアップグレード
構成変更（単一インスタンスから Oracle Real Application Clusters（RAC）環境へのデー
タベースの変換など）
■
記憶域、ネットワークおよび相互接続の変更
■
オペレーティング・システムとハードウェアの移行
この章では、Oracle Database のデータベース・リプレイ機能の使用方法について説明します。
この章には、次の項があります。
■
データベース・リプレイの概要
■
データベース・ワークロードの取得
■
ワークロードの取得の分析
データベース・リプレイ
21-1
データベース・リプレイの概要
データベース・リプレイの概要
データベース・リプレイにより、本番システム上でワークロードを取得し、それをテスト・シ
ステム上でリプレイすることで、テスト・システム上に本番のワークロード環境を本質的に再
作成して、システム変更を現実的にテストできます。
図 21-1 データベース・リプレイのアーキテクチャ
データベース・リプレイを使用するには、図 21-1 に示すように 4 つの主要ステップが必要で
す。
■
ワークロードの取得
■
ワークロードの前処理
■
ワークロードのリプレイ
■
分析およびレポート作成
注意 : 現在、このリリースでサポートされているのは、ワークロードの取得
のみです。Oracle Database 11g リリース 1（11.1）以降のリリースでは、取得
されたワークロードを前処理してリプレイできます。
21-2
Oracle Database パフォーマンス・チューニング・ガイド
データベース・リプレイの概要
ワークロードの取得
データベース・リプレイを使用する最初のステップは、本番のワークロードを取得することで
す。ワークロードを取得するには、外部クライアントから Oracle Database に対して発行された
要求をすべて記録する必要があります。ワークロードの取得が有効化されている場合、Oracle
Database に送られた外部クライアントの要求がすべて追跡され、ファイル・システム上で取得
ファイルと呼ばれるバイナリ・ファイルに格納されます。これらの取得ファイルはプラット
フォームに依存せず、別のシステムに転送できます。ワークロード取得の開始時刻と期間、お
よび取得ファイルの格納場所を指定できます。ワークロードの取得が始まると、すべての外部
データベース・コールが取得ファイルに書き込まれます。取得ファイルには、SQL テキスト、
バインド値およびトランザクション情報など、クライアント要求に関する関連情報がすべて含
まれます。バックグラウンド・アクティビティとデータベース・スケジューラ・ジョブは取得
されません。
本番システム上でワークロードを取得する方法は、21-4 ページの「データベース・ワークロー
ドの取得」を参照してください。
ワークロードの前処理
ワークロードの取得が完了した後、取得ファイル内の情報を前処理する必要があります。前処
理により、ワークロードのリプレイに必要なメタデータがすべて作成されます。この前処理は、
取得された各ワークロードをリプレイする前に 1 度実行する必要があります。前処理後、同じ
バージョンの Oracle Database を実行中のリプレイ・システム上で、取得されたワークロード
を繰り返しリプレイできます。通常は、取得ファイルは前処理のために別のシステムにコピー
する必要があります。ワークロードの前処理は時間のかかるリソース集中型の処理であるため、
このステップはワークロードのリプレイに使用するテスト・システム上で実行することをお薦
めします。
関連項目 : 取得されたワークロードの前処理の詳細は、『Oracle Database パ
フォーマンス・チューニング・ガイド 11g リリース 1（11.1）
』を参照してく
ださい。
ワークロードのリプレイ
前処理が完了した後、取得されたワークロードをテスト・システム上でリプレイできます。
ワークロードのリプレイ・フェーズでは、ワークロードの取得フェーズで記録されたアクショ
ンが、Oracle Database によりテスト・システム上で実行されます。そのために、取得されたす
べての外部クライアント要求が、本番システムと同じタイミング、同時実行性およびトランザ
クション依存性を使用して再作成されます。
データベース・リプレイでは、リプレイ・クライアントと呼ばれるクライアント・プログラム
を使用して、ワークロードの取得中に記録された外部クライアント要求がすべて再作成されま
す。取得されたワークロードによっては、正常にリプレイするために 1 つ以上のリプレイ・ク
ライアントが必要になる場合があります。特定のワークロードに必要なリプレイ・クライアン
トの数を判別できるように、測定ツールが用意されています。DML および SQL 問合せを含め
てワークロード全体がリプレイされるため、リプレイ・システム内のデータは取得システム上
のデータと論理的に類似している必要があります。これにより、データの相違が最小限になり、
信頼性の高いリプレイ分析が可能になります。
関連項目 : 取得されたワークロードのリプレイの詳細は、『Oracle Database
パフォーマンス・チューニング・ガイド 11g リリース 1（11.1）
』を参照して
ください。
データベース・リプレイ
21-3
データベース・ワークロードの取得
分析およびレポート作成
ワークロードがリプレイされた後、ワークロードの取得とリプレイの両方について詳細な分析
を実行できるように、詳細レポートが提供されます。
レポート・サマリーは、リプレイ中に発生したエラーや、DML または SQL 問合せで戻された
行のデータの相違など、ワークロードの取得とリプレイに関する基本情報を提供します。ワー
クロードの取得とワークロードのリプレイとの複数の統計（DB 時間、平均アクティブ・セッ
ションおよびユーザー・コールなど）の比較も提供されます。拡張分析の場合、自動ワーク
ロード・リポジトリ（AWR）レポートを使用して、ワークロードの取得とワークロードのリプ
レイの間でパフォーマンス統計詳細を比較できます。これらのレポートで使用可能な情報は非
常に詳細であり、ワークロードの取得とリプレイの間にはある程度の相違を予想できます。
アプリケーション・レベルの検証では、リプレイ全体の成功を評価するためのスクリプトの開
発を検討する必要があります。たとえば、ワークロードの取得中に 10,000 件のオーダーが処理
される場合、リプレイ中にもそれとほぼ同数のオーダーが処理されることを検証する必要があ
ります。
ワークロードの取得レポートを生成して分析する方法は、21-15 ページの「ワークロードの取得
の分析」を参照してください。
データベース・ワークロードの取得
この項では、本番システム上でデータベース・ワークロードを取得する方法について説明しま
す。データベース・ワークロード取得用の主ツールは、Oracle Enterprise Manager です。なん
らかの理由で Oracle Enterprise Manager を使用できない場合は、API を使用してデータベー
ス・ワークロードを取得できます。
この項では、次の項目について説明します。
■
ワークロードの取得の有効化と無効化
■
データベース・ワークロードの取得の前提条件
■
ワークロードの取得オプション
■
ワークロードの取得の制限
■
Enterprise Manager を使用したデータベース・ワークロードの取得
■
Enterprise Manager を使用したワークロードの取得の監視
■
API を使用したデータベース・ワークロードの取得
■
ビューを使用したワークロードの取得の監視
ワークロードの取得の有効化と無効化
ワークロードを取得する前に、取得を計画しているシステム上でワークロードの取得を有効化
する必要があります。Oracle Database 10g リリース 2（10.2）では、デフォルトでワークロード
の取得は有効化されません。PRE_11G_ENABLE_CAPTURE 初期化パラメータを指定すると、
ワークロードの取得を有効化または無効化できます。
ワークロードの取得を有効化するには、SQL プロンプトから wrrenbl.sql スクリプトを実行
します。
@$ORACLE_HOME/rdbms/admin/wrrenbl.sql
wrrenbl.sql スクリプトにより ALTER SYSTEM SQL 文がコールされ、
PRE_11G_ENABLE_CAPTURE 初期化パラメータが TRUE に設定されます。サーバー・パラメー
タ・ファイル（SPFILE）を使用する場合、PRE_11G_ENABLE_CAPTURE 初期化パラメータは
現在実行中のインスタンスにあわせて変更されて SPFILE に記録されるため、新しい設定は
データベースを再起動するまで存続します。SPFILE を使用しない場合、
PRE_11G_ENABLE_CAPTURE 初期化パラメータは現在実行中のインスタンスについてのみ変更
され、新しい設定はデータベースを再起動すると存続しなくなります。SPFILE を使用せずに設
21-4
Oracle Database パフォーマンス・チューニング・ガイド
データベース・ワークロードの取得
定を永続的にするには、パラメータを初期化パラメータ・ファイル（init.ora）に手動で指定す
る必要があります。
ワークロードの取得を無効化するには、SQL プロンプトから wrrdsbl.sql スクリプトを実行
します。
@$ORACLE_HOME/rdbms/admin/wrrdsbl.sql
wrrdsbl.sql スクリプトにより ALTER SYSTEM SQL 文がコールされ、
PRE_11G_ENABLE_CAPTURE 初期化パラメータが FALSE に設定されます。サーバー・パラ
メータ・ファイル（SPFILE）を使用する場合、PRE_11G_ENABLE_CAPTURE 初期化パラメー
タは現在実行中のインスタンスにあわせて変更されて SPFILE に記録されるため、新しい設定
はデータベースを再起動するまで存続します。SPFILE を使用しない場合、
PRE_11G_ENABLE_CAPTURE 初期化パラメータは現在実行中のインスタンスについてのみ変更
され、新しい設定はデータベースを再起動すると存続しなくなります。SPFILE を使用せずに設
定を永続的にするには、パラメータを初期化パラメータ・ファイル（init.ora）に手動で指定す
る必要があります。
注意 : PRE_11G_ENABLE_CAPTURE 初期化パラメータを使用できるのは、
Oracle Database 10g リリース 2（10.2）のみです。以降のリリースでは、この
パラメータは無効です。データベースのアップグレード後は、このパラメー
タをサーバー・パラメータ・ファイル（SPFILE）または初期化パラメータ・
ファイル（init.ora）から削除する必要があります。削除しないと、データ
ベースを起動できません。
関連項目 : PRE_11G_ENABLE_CAPTURE 初期化パラメータの詳細は、
『Oracle Database リファレンス』を参照してください。
データベース・ワークロードの取得の前提条件
ワークロードの取得を開始する前に、テスト・システム上でデータベースをリストアするため
の計画を作成する必要があります。ワークロードをリプレイする前に、リプレイ・システム上
のアプリケーション・データを、リプレイ開始時の取得システムと同じ状態にする必要があり
ます。そのためには、次の方法のいずれかを使用することを検討してください。
■
Recovery Manager（RMAN）の DUPLICATE コマンド
■
スナップショット・スタンバイ
■
データ・ポンプのインポートとエクスポート
これにより、リプレイ・システム上のデータベースを、ワークロードの取得開始時点でのアプ
リケーションの状態にリストアできます。
関連項目 :
■
■
■
RMAN を使用したデータベースの複製の詳細は、『Oracle Database バッ
クアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
スナップショット・スタンバイ・データベースの管理については、
『Oracle Data Guard 概要および管理』を参照してください。
データ・ポンプの使用方法は、
『Oracle Database ユーティリティ』を参
照してください。
データベース・リプレイ
21-5
データベース・ワークロードの取得
ワークロードの取得オプション
取得が正確で、別の環境でリプレイしたときに役立つように、ワークロードの取得前に適切に
計画しておく必要があります。
データベース・ワークロードを取得する前に、次のオプションを慎重に検討してください。
■
データベースの再起動
■
ワークロード・フィルタの定義
■
取得ディレクトリの設定
データベースの再起動
このステップはオプションですが、実行中のトランザクションや依存トランザクションを取得
開始前に確実に完了またはロールバックできるように、ワークロードの取得前にデータベース
を再起動することをお薦めします。取得開始前にデータベースを再起動しないと、実行中だっ
たトランザクションや、まだコミットされていなかったトランザクションがワークロードに完
全に取得されません。したがって、実行中のトランザクションは正しくリプレイされません。
これは、トランザクションのうちコールが取得された部分のみがリプレイされるためです。そ
の結果、ワークロードをリプレイすると、データに望ましくない相違が発生する可能性があり
ます。未完了トランザクションに依存する以降のトランザクションでも、リプレイ中にエラー
が生成される可能性があります。
データベースを再起動する前に、最小限の中断でワークロード取得期間前に本番データベース
を停止する適切な時期を判断します。たとえば、午前 8 時から始まるワークロードを取得する
必要があるとします。ただし、通常の業務時間中のサービス中断を回避するために、この時刻
にはデータベースを再起動しないようにします。この場合は、中断期間が短くなる時刻にデー
タベースを再起動できるように、ワークロードの取得開始時刻を早めることを検討する必要が
あります。
データベースの再起動後は、ユーザー・セッションが再接続されてワークロードの発行が開始
される前に、ワークロードの取得を開始することが重要です。このようにしないと、これらの
ユーザー・セッションにより実行されるトランザクションは、以降のデータベース・リプレイ
で正常にリプレイされません。これは、トランザクションのうち、ワークロードの取得開始後
にコールが実行された部分のみがリプレイされるためです。この問題を回避するために、
STARTUP_RESTRICTED を使用してデータベースを RESTRICTED モードで再起動することを検
討してください。これにより、SYS ユーザーのみがログインとワークロードの取得開始を許可
されます。デフォルトでは、ワークロードの取得が始まると、RESTRICTED モードのデータ
ベース・インスタンスが自動的に UNRESTRICTED モードに切り替わり、ワークロードの取得
中に通常の操作を継続できるようになります。
関連項目 : 起動時のインスタンスへのアクセスを制限する方法は、『Oracle
Database 管理者ガイド』を参照してください。
1 回に実行できるワークロードの取得は、1 つのみです。Oracle Real Application Clusters
（RAC）の場合、ワークロードの取得はデータベース全体に対して実行されます。ワークロード
の取得開始前にクリーンな状態を有効化するには、すべてのインスタンスを再起動する必要が
あります。そのためには、次の手順を実行できます。
21-6
1.
すべてのインスタンスを停止します。
2.
インスタンスの 1 つを再起動します。
3.
ワークロードの取得を開始します。
4.
残りのインスタンスを再起動します。
Oracle Database パフォーマンス・チューニング・ガイド
データベース・ワークロードの取得
ワークロード・フィルタの定義
デフォルトでは、ワークロードの取得中にすべてのユーザー・セッションが記録されます。
ワークロード・フィルタを使用すると、ワークロードに含めるか除外するユーザー・セッショ
ンを指定できます。包含フィルタを使用すると、ワークロードで取得するユーザー・セッショ
ンを指定できます。これは、データベース・ワークロードのサブセットのみを取得する場合に
役立ちます。除外フィルタを使用すると、ワークロードで取得しないユーザー・セッションを
指定できます。これは、ワークロードで取得する必要のないセッション・タイプを除外する場
合に役立ちます。たとえば、ワークロードのリプレイに使用するシステムで Oracle Enterprise
Manager（EM）を実行中の場合、取得した EM セッションをこのシステム上でリプレイする
と、ワークロードが重複する結果となります。この場合は、除外フィルタを使用して EM セッ
ションを除外できます。ワークロードの取得には、包含フィルタまたは除外フィルタを使用で
きますが、両方を使用することはできません。
取得ディレクトリの設定
取得されたワークロードを格納する場所を決定し、ディレクトリを設定します。ワークロード
の取得を開始する前に、ディレクトリが空で、ワークロードを格納できる十分なディスク領域
があることを確認します。ワークロードの取得中にディレクトリがディスク領域不足になると、
取得が停止します。
Oracle RAC の場合は、共有ファイル・システムの使用を検討してください。または、各インス
タンス上の個別の物理ディレクトリに解決される取得ディレクトリ・パスを設定することもで
きますが、ワークロードの取得を前処理する前に、これらの各ディレクトリに作成された取得
ファイルを 1 つのディレクトリに収集する必要があります。
ワークロードの取得の制限
現行リリースでは、次のタイプのクライアント要求はワークロードで取得されません。
■
SQL*Loader などのユーティリティによる、外部ファイルからのデータのダイレクト・パ
ス・ロード
■
共有サーバー要求（Oracle MTS）
■
Oracle Streams
■
アドバンスト・レプリケーション・ストリーム
■
非 PL/SQL ベースのアドバンスト・キューイング（AQ）
■
フラッシュバック問合せ
■
Oracle Call Interface（OCI）ベースのオブジェクト・ナビゲーション
■
非 SQL ベースのオブジェクト・アクセス
■
■
分散トランザクション（取得された分散トランザクションは、ローカル・トランザクショ
ンとしてリプレイされます。
）
リモートの DESCRIBE および COMMIT 操作
データベース・リプレイ
21-7
データベース・ワークロードの取得
Enterprise Manager を使用したデータベース・ワークロードの取得
この項では、Enterprise Manager を使用してデータベース・ワークロードを取得する方法につ
いて説明します。
Enterprise Manager を使用してデータベース・ワークロードを取得する手順は、次のとおりで
す。
1. 「管理」ページで、
「Real Application Testing」の下にある「データベース・リプレイ」
「データベース・リプレイ」を
「データベース・リプレイ」
クリックします。
「データベース・リプレイ」ページが表示されます。
2. 「タスクに移動」列で、
「ワークロードの取得」タスクに対応するアイコンをクリックしま
す。
「ワークロードの取得 : 環境の計画」ページが表示されます。
3.
先に進む前に、すべての前提条件を満たしていることを確認します。
前提条件については、21-5 ページの「データベース・ワークロードの取得の前提条件」を
参照してください。確認した前提条件ごとに、「確認」列のボックスを選択します。すべて
の前提条件を確認した後、
「次」をクリックします。
「次」
「ワークロードの取得 : オプション」ページが表示されます。
4.
ワークロードの取得オプションを選択します。
■
「データベースの再起動オプション」の下で、ワークロードの取得前にデータベースを
再起動するかどうかを選択します。
ワークロードの取得にクリーンな状態を使用できるように、ワークロードの取得前に
データベースを再起動することをお薦めします。再起動しないと、ワークロードのリ
プレイ時に潜在的な問題が発生する可能性があります。詳細は、21-6 ページの「デー
タベースの再起動」を参照してください。
■
「ワークロード・フィルタ」の下にある「フィルタ・モード」リストで、「除外」を選
「除外」
択して除外フィルタを使用するように選択するか、または「包含」
「包含」を選択して包含
「包含」
フィルタを使用するように選択します。
フィルタを追加するには、
「行の追加」をクリックし、フィルタ名、セッション属性タ
イプおよび属性値を対応するフィールドに入力します。詳細は、21-7 ページの「ワー
クロード・フィルタの定義」を参照してください。
必要なワークロード取得オプションの選択後、「次」をクリックします。
「ワークロードの
「次」
取得 : パラメータ」ページが表示されます。
5.
ワークロードの取得のパラメータを定義します。
■
「ワークロードの取得パラメータ」の下の「取得名」フィールドに、ワークロードの取
得名を入力します。「ディレクトリ・オブジェクト」リストで、取得されたワーク
ロードを格納するディレクトリを選択します。ワークロードの取得が格納されていな
いディレクトリを選択する必要があります。詳細は、21-7 ページの「取得ディレクト
リの設定」を参照してください。
新規ディレクトリ・オブジェクトを作成するには、「ディレクトリ・オブジェクトの作
成」をクリックします。「ディレクトリ・オブジェクトの作成」ページが表示されま
成」
す。「名前」フィールドに、ディレクトリ・オブジェクト名を入力します。「パス」
フィールドに、ディレクトリ・オブジェクトへのパスを入力します。指定したディレ
クトリがファイル・システムに存在するかどうかをテストするには、「テスト・ファイ
ルシステム」をクリックします。
そのディレクトリが存在しない場合は、最初に作成
ルシステム」
する必要があります。
21-8
Oracle Database パフォーマンス・チューニング・ガイド
データベース・ワークロードの取得
■
「データベースの停止パラメータ」の下で、実行するデータベース停止方法のタイプを
選択します。このオプションは、ワークロードの取得前にデータベースを再起動する
場合にのみ表示されます。使用可能なデータベース停止方法のタイプは、次のとおり
です。
–
即時
即時停止の場合、アクティブなトランザクションがすべてロールバックされ、接
続しているユーザーがすべて切断されてから、データベースが停止します。
–
トランザクション
トランザクション停止の場合、最初にアクティブなトランザクションがすべて完
了してから、接続しているユーザーが切断され、データベースが停止します。
–
中断
中断停止の場合、アクティブなトランザクションがすべて中断され、データベー
スが即時に停止します。
■
「データベースの起動パラメータ」の下で、データベースの再起動に現行のデフォル
ト・サーバー・パラメータ・ファイル（SPFILE）を使用するか、特定のパラメータ・
ファイル（PFILE）を使用するかを選択します。PFILE を選択するには、PFILE の完全
修飾名を入力します。このオプションは、ワークロードの取得前にデータベースを再
起動する場合にのみ表示されます。
ワークロードの取得パラメータを定義した後、「次」をクリックします。
「ワークロードの
「次」
取得 : スケジュール」ページが表示されます。
6. 「ジョブ・パラメータ」の下で、ジョブのパラメータを定義します。
■
■
「ジョブ名」フィールドで、ジョブ名を入力するか、またはシステム生成名を受け入れ
ます。
「説明」フィールドに、オプションでジョブの説明を入力します。
7. 「ジョブ・スケジュール」の下で、ワークロードの取得の開始時刻と期間を指定します。
■
■
「開始」の下で、「即時」を選択してジョブを即時に実行するように選択するか、また
「即時」
は「後で」
「後で」を選択し、
「日付」および「時間」フィールドに必要な時刻を指定して後で
「後で」
実行するように選択します。
「取得期間」の下で「期間」
「期間」を選択し、
「時間」および「分」フィールドを使用して必
「期間」
要な期間を指定して、ジョブの実行期間を指定します。取得期間を指定しない場合は、
「指定されていません」を選択します。
取得期間を指定しない場合は、ジョブを手動で
「指定されていません」
停止する必要があります。
8. 「ジョブの資格証明」の下で、ホストとデータベースのログイン資格証明を入力します。
■
■
「ホスト資格証明」の下で、ホスト・システム用のユーザー名とパスワードを入力しま
す。
「データベース資格証明」の下で、ワークロードの取得に使用するデータベース用の
ユーザー名とパスワードを入力します。ユーザーがワークロードを取得するには、DBA
権限が必要です。
「次」をクリックします。
「ワークロードの取得 : 確認」ページが表示されます。
「次」
9.
定義したワークロードの取得に関するジョブ設定を確認します。ジョブを実行するには、
「発行」をクリックします。変更するには、
「戻る」をクリックします。
変更内容を保存せず
「発行」
「戻る」
にワークロードの取得を取り消すには、「取消」をクリックします。
「取消」
データベース・リプレイ
21-9
データベース・ワークロードの取得
10. 定義したジョブ設定に応じて次のいずれかになります。
■
■
■
ジョブを即時に開始するようにスケジュールし、データベースを再起動する場合は、
「確認 : データベースの再起動」ページが表示されます。データベースを再起動するに
は、
「はい」をクリックします。
データベースの再起動中に「情報 : データベースの再
「はい」
起動」ページが表示されます。データベースの再起動後に、ワークロードの取得が自
動的に開始されます。「リフレッシュ」をクリックします。
「ワークロードの取得の表
「リフレッシュ」
示」ページが表示されます。
ジョブが即時に開始するようにスケジュールされていても、データベースを再起動し
ない場合、ワークロードの取得が自動的に開始され、ジョブが正常に作成されたこと
を示す確認メッセージを含んだ「データベース・リプレイ」ページが表示されます。
ジョブが後で開始するようにスケジュールされている場合は、ジョブが正常に作成さ
れたことを示す確認メッセージを含んだ「データベース・リプレイ」ページが表示さ
れます。
ワークロードの取得が開始された後は、21-10 ページの「アクティブなワークロードの取得
の監視」で説明するように、
「ワークロードの取得の表示」ページを使用して取得プロセス
を監視できます。
Enterprise Manager を使用したワークロードの取得の監視
この項では、Enterprise Manager を使用してワークロードの取得を監視する方法について説明
します。ワークロードの取得監視用の主ツールは、Oracle Enterprise Manager です。Enterprise
Manager を使用して次の操作を実行できます。
■
アクティブなワークロードの取得の監視または停止
■
完了したワークロードの取得の表示または削除
なんらかの理由で Oracle Enterprise Manager を使用できない場合は、21-15 ページの「ビュー
を使用したワークロードの取得の監視」で説明するように、ビューを使用してワークロードの
取得を監視できます。
この項では、次の項目について説明します。
■
アクティブなワークロードの取得の監視
■
アクティブなワークロードの取得の停止
■
完了したワークロードの取得の管理
アクティブなワークロードの取得の監視
この項では、Enterprise Manager を使用してアクティブなワークロードの取得を監視する方法
について説明します。
アクティブなワークロードの取得を監視する手順は、次のとおりです。
1. 「管理」ページで、
「Real Application Testing」の下にある「データベース・リプレイ」
「データベース・リプレイ」を
「データベース・リプレイ」
クリックします。
「データベース・リプレイ」ページが表示されます。
2. 「アクティブな取得とリプレイ」の下で、監視するワークロードの取得を選択して「表示」
「表示」
をクリックします。
「ワークロードの取得の表示」ページが表示されます。
3. 「サマリー」の下に、ワークロードの取得に関する情報が表示されます。
21-10
Oracle Database パフォーマンス・チューニング・ガイド
データベース・ワークロードの取得
4.
ワークロード・プロファイルを表示するには、「ワークロード・プロファイル」タブをク
「ワークロード・プロファイル」
リックします。
「平均アクティブ・セッション」の下の「アクティブ・セッション」グラフに、取得された
セッション・アクティビティと取得されていないセッション・アクティビティ（バックグラ
ウンド・アクティビティやフィルタされたセッションなど）の比較がグラフ表示されます。
「比較」の下に、データベース時間、平均アクティブ・セッション、ユーザー・コール、ト
ランザクション、接続およびアプリケーション・エラーなど、ワークロードの取得の各種
統計が表示されます。「合計」列には合計セッション・アクティビティの統計が表示され、
「取得」列には取得されたセッション・アクティビティの統計が表示されます。「合計の割
合」列には、ワークロードで取得中の合計セッション・アクティビティの割合が表示され
ます。
ワークロードの取得レポートを表示するには、「ワークロードの取得レポートの表示」をク
「ワークロードの取得レポートの表示」
リックします。
5.
ワークロードの取得に使用されたワークロード・フィルタを表示するには、「ワークロー
ド・フィルタ」タブをクリックします。
ド・フィルタ」
ワークロードの取得に使用されたワークロード・フィルタの詳細（ワークロード・フィル
タ名、タイプ、セッション属性および値など）が表示されます。
6. 「データベース・リプレイ」ページに戻るには、
「OK」
」をクリックします。
アクティブなワークロードの取得の停止
この項では、Enterprise Manager を使用してアクティブなワークロードの取得を停止する方法
について説明します。
アクティブなワークロードの取得を停止する手順は、次のとおりです。
1. 「管理」ページで、
「Real Application Testing」の下にある「データベース・リプレイ」
「データベース・リプレイ」を
「データベース・リプレイ」
クリックします。
「データベース・リプレイ」ページが表示されます。
2. 「アクティブな取得とリプレイ」の下で、停止するワークロードの取得を選択して「停止」
「停止」
をクリックします。
「確認」ページが表示されます。
3.
ワークロードの取得を停止することを確認するには、「はい」をクリックします。
「はい」
「AWR データのエクスポート」ページが表示されます。
4.
自動ワークロード・リポジトリ（AWR）データをエクスポートするには、
「はい」をク
「はい」
リックします。
AWR データをエクスポートすると、ワークロードの詳細分析を実行できます。このデータ
は、ワークロードの取得またはリプレイのペアに対して「AWR の期間比較レポート」を実
行するように計画している場合も必須です。AWR データをエクスポートしないことを選択
する場合は、
「いいえ」をクリックします。
完了したワークロードの取得からの AWR デー
「いいえ」
タを、
「ワークロードの取得履歴の表示」ページから後でエクスポートすることもできま
す。AWR については、5-8 ページの「自動ワークロード・リポジトリの概要」を参照して
ください。
データベース・リプレイ
21-11
データベース・ワークロードの取得
完了したワークロードの取得の管理
この項では、Enterprise Manager を使用して、完了したワークロードの取得を管理する方法に
ついて説明します。
完了したワークロードの取得を管理する手順は、次のとおりです。
1. 「管理」ページで、
「Real Application Testing」の下にある「データベース・リプレイ」
「データベース・リプレイ」を
「データベース・リプレイ」
クリックします。
「データベース・リプレイ」ページが表示されます。
2. 「ワークロードの取得履歴の表示」をクリックします。
「ワークロードの取得履歴の表示」
「ワークロードの取得履歴の表示」ページが表示されます。
3.
ワークロードの取得を削除するには、ワークロードの取得を選択して「削除」
「削除」をクリック
「削除」
します。
4.
ワークロードの取得に関する AWR データをエクスポートするには、ワークロードの取得
を選択して「
「AWR データのエクスポート」をクリックします。
データのエクスポート」
AWR データをエクスポートすると、ワークロードの詳細分析を実行できます。このデータ
は、ワークロードの取得またはリプレイのペアに対して「AWR の期間比較レポート」を実
行するように計画している場合も必須です。
5.
ワークロードの取得の詳細を表示するには、ワークロードの取得を選択して「表示」
「表示」をク
「表示」
リックします。
「ワークロードの取得の表示」ページが表示されます。
6. 「サマリー」の下に、ワークロードの取得に関する情報が表示されます。
7.
ワークロード・プロファイルを表示するには、「ワークロード・プロファイル」タブをク
「ワークロード・プロファイル」
リックします。
「平均アクティブ・セッション」の下の「アクティブ・セッション」グラフに、取得された
セッション・アクティビティと取得されていないセッション・アクティビティ（バックグ
ラウンド・アクティビティやフィルタされたセッションなど）の比較がグラフ表示されま
す。このグラフが表示されるのは、取得期間中に使用可能な Active Session History（ASH）
データが存在する場合のみです。ASH については、5-4 ページの「Active Session History
（ASH）」を参照してください。
「比較」の下に、データベース時間、平均アクティブ・セッション、ユーザー・コール、ト
ランザクション、接続およびアプリケーション・エラーなど、ワークロードの取得の各種
統計が表示されます。「合計」列には合計セッション・アクティビティの統計が表示され、
「取得」列には取得されたセッション・アクティビティの統計が表示されます。「合計の割
合」列には、ワークロードで取得中の合計セッション・アクティビティの割合が表示され
ます。
ワークロードの取得レポートを表示するには、「ワークロードの取得レポートの表示」をク
「ワークロードの取得レポートの表示」
リックします。
8.
ワークロードの取得に使用されたワークロード・フィルタを表示するには、「ワークロー
ド・フィルタ」タブをクリックします。
ド・フィルタ」
ワークロードの取得に使用されたワークロード・フィルタの詳細（ワークロード・フィル
タ名、タイプ、セッション属性および値など）が表示されます。
9. 「データベース・リプレイ」ページに戻るには、
「OK」
」をクリックします。
21-12
Oracle Database パフォーマンス・チューニング・ガイド
データベース・ワークロードの取得
API を使用したデータベース・ワークロードの取得
この項では、API を使用してデータベース・ワークロードを取得する方法について説明します。
DBMS_WORKLOAD_CAPTURE パッケージを使用してデータベース・ワークロードを取得するに
は、次のステップを実行する必要があります。
■
ワークロード・フィルタの追加と削除
■
ワークロードの取得の開始
■
ワークロードの取得の停止
■
ワークロードの取得に関する AWR データのエクスポート
関連項目 : 『Oracle Database PL/SQL パッケージ・プロシージャおよびタイ
プ・リファレンス』
ワークロード・フィルタの追加と削除
この項では、ワークロード・フィルタを追加および削除する方法について説明します。ワーク
ロード・フィルタの使用方法は、21-7 ページの「ワークロード・フィルタの定義」を参照して
ください。
ワークロードの取得にフィルタを追加するには、ADD_FILTER プロシージャを使用します。
BEGIN
DBMS_WORKLOAD_CAPTURE.ADD_FILTER (
fname => 'user_ichan',
fattribute => 'USER',
fvalue => 'ICHAN');
END;
/
この例では、ADD_FILTER プロシージャにより user_ichan というフィルタが追加されます。こ
のフィルタを使用すると、ユーザー名 ICHAN に属しているセッションをすべて除外できます。
この例の ADD_FILTER プロシージャでは、次のパラメータを使用しています。
■
■
■
必須パラメータ fname では、追加するフィルタの名前を指定します。
必須パラメータ fattribute では、フィルタを適用する属性を指定します。有効な値は、
PROGRAM、MODULE、ACTION、SERVICE、INSTANCE_NUMBER および USER で
す。
必須パラメータ fvalue では、フィルタを適用する、対応する属性の値を指定します。モ
ジュールやアクションなど、一部の属性には % などのワイルドカードを使用できます。
ワークロードの取得からフィルタを削除するには、DELETE_FILTER プロシージャを使用しま
す。
BEGIN
DBMS_WORKLOAD_CAPTURE.DELETE_FILTER (fname => 'user_ichan');
END;
/
この例の DELETE_FILTER プロシージャでは、ワークロードの取得から user_ichan というフィ
ルタが削除されます。DELETE_FILTER プロシージャでは、削除対象のフィルタの名前を指定
する必須パラメータ fname を使用しています。
データベース・リプレイ
21-13
データベース・ワークロードの取得
ワークロードの取得の開始
ワークロードの取得を開始する前に、まず 21-5 ページの「データベース・ワークロードの取得
の前提条件」の説明に従って、データベース・ワークロードを取得するための前提条件を完了
する必要があります。また、21-6 ページの「ワークロードの取得オプション」の説明に従って、
ワークロードの取得オプションも確認する必要があります。
取得されたワークロードのリプレイを開始する前に、ワークロードの始点を適切に定義してお
くことが重要です。これにより、リプレイ・システムをその時点にリストアできるようになり
ます。ワークロードの取得の始点を適切に定義するには、ワークロードの取得の開始時にアク
ティブなユーザー・セッションを残さないことをお薦めします。アクティブなセッションで実
行中のトランザクションがあると、これらのトランザクションは、以降のデータベース・リプ
レイで正常にリプレイされません。これは、トランザクションのうち、ワークロードの取得開
始後にコールが実行された部分のみがリプレイされるためです。この問題を回避するために、
ワークロードの取得を開始する前に、STARTUP_RESTRICTED を使用してデータベースを
RESTRICTED モードで再起動することを検討してください。ワークロードの取得が開始される
と、データベースが自動的に UNRESTRICTED モードに切り替わり、ワークロードの取得中に
通常の操作を継続できます。ワークロードの取得を開始する前のデータベースの再起動の詳細
は、21-6 ページの「データベースの再起動」を参照してください。
ワークロードの取得を開始するには、START_CAPTURE プロシージャを使用します。
BEGIN
DBMS_WORKLOAD_CAPTURE.START_CAPTURE (name => 'dec06_peak',
dir => 'dec06',
duration => 600);
END;
/
この例では、dec06_peak というワークロードが 600 秒間取得され、dec06 というデータベー
ス・ディレクトリ・オブジェクトで定義されたオペレーティング・システムに格納されます。
この例の START_CAPTURE プロシージャでは、次のパラメータを使用しています。
■
■
■
必須パラメータ name では、取得するワークロードの名前を指定します。
必須パラメータ dir では、取得されたワークロードを格納するディレクトリを指すディレ
クトリ・オブジェクトを指定します。
オプション・パラメータ duration では、ワークロードの取得が終了するまでの秒数を指
定します。値を指定しなければ、ワークロードの取得は FINISH_CAPTURE プロシージャが
コールされるまで継続されます。
ワークロードの取得の停止
ワークロードの取得を停止するには、FINISH_CAPTURE プロシージャを使用します。
BEGIN
DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE ();
END;
/
この例の FINISH_CAPTURE プロシージャでは、ワークロードの取得がファイナライズされ、
データベースが通常の状態に戻されます。
21-14
Oracle Database パフォーマンス・チューニング・ガイド
ワークロードの取得の分析
ワークロードの取得に関する AWR データのエクスポート
AWR データをエクスポートすると、ワークロードの詳細分析を実行できます。このデータは、
ワークロードの取得またはリプレイのペアに対して「AWR の期間比較レポート」を実行するよ
うに計画している場合も必須です。
AWR データをエクスポートするには、EXPORT_AWR プロシージャを使用します。
BEGIN
DBMS_WORKLOAD_CAPTURE.EXPORT_AWR (capture_id => 2);
END;
/
この例では、取得 ID が 2 のワークロードの取得に対応する AWR スナップショットがエクス
ポートされます。EXPORT_AWR プロシージャでは、必須パラメータ capture_id を使用して、
AWR スナップショットのエクスポート対象となる取得の ID を指定しています。このプロシー
ジャが動作するのは、対応するワークロードの取得が現行のデータベース内で実行され、元の
取得期間に対応する AWR スナップショットが引き続き使用可能な場合のみです。
ビューを使用したワークロードの取得の監視
この項では、ワークロードの取得を監視するために表示できるビューについて説明します。こ
れらのビューにアクセスするには、DBA 権限が必要です。
■
■
DBA_WORKLOAD_CAPTURES ビューには、現行のデータベース内で取得されたワークロー
ドの取得がすべてリストされます。
DBA_WORKLOAD_FILTERS ビューには、現行のデータベース内で定義済のワークロードの
取得に使用されたワークロード・フィルタがすべてリストされます。
関連項目 : これらのビューについては、『Oracle Database リファレンス』を
参照してください。
ワークロードの取得の分析
この項では、ワークロードの取得レポートを生成して分析する方法について説明します。ワー
クロードの取得レポート生成用の主ツールは、Oracle Enterprise Manager です。なんらかの理
由で Oracle Enterprise Manager を使用できない場合は、API を使用してワークロードの取得レ
ポートを生成できます。
この項では、次の項目について説明します。
■
Enterprise Manager を使用したワークロードの取得レポートの生成
■
API を使用したワークロードの取得レポートの生成
■
ワークロードの取得レポートの使用
Enterprise Manager を使用したワークロードの取得レポートの生成
ワークロードの取得レポートには、取得されたワークロードの統計、取得された上位セッショ
ン・アクティビティに関する情報、および取得プロセス中に使用されたワークロード・フィル
タが含まれています。
Enterprise Manager を使用してワークロードの取得レポートを生成する手順は、次のとおりで
す。
1. 「管理」ページで、
「Real Application Testing」の下にある「データベース・リプレイ」
「データベース・リプレイ」を
「データベース・リプレイ」
クリックします。
「データベース・リプレイ」ページが表示されます。
2. 「ワークロードの取得履歴の表示」をクリックします。
「ワークロードの取得履歴の表示」
「ワークロードの取得履歴の表示」ページが表示されます。
データベース・リプレイ
21-15
ワークロードの取得の分析
3.
ワークロードの取得レポートを実行するワークロードの取得を選択し、「表示」をクリック
「表示」
します。
「ワークロードの取得の表示」ページが表示されます。
4.
ワークロードの取得レポートを表示するには、「ワークロードの取得レポートの表示」をク
「ワークロードの取得レポートの表示」
リックします。
レポートの生成中に「レポート」ウィンドウがオープンします。
5.
生成後、
「ファイルに保存」をクリックしてレポートを保存できます。
「ファイルに保存」
ワークロードの取得レポートの使用方法は、21-17 ページの「ワークロードの取得レポート
の使用」を参照してください。
API を使用したワークロードの取得レポートの生成
ワークロードの取得レポートには、取得されたワークロードの統計、取得された上位セッショ
ン・アクティビティに関する情報、および取得プロセス中に使用されたワークロード・フィル
タが含まれています。
最新のワークロードの取得に関するレポートを生成するには、
DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO プロシージャと
DBMS_WORKLOAD_CAPTURE.REPORT ファンクションを使用します。
DECLARE
cap_id
NUMBER;
cap_rpt
CLOB;
BEGIN
cap_id := DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO(dir => 'dec06');
cap_rpt := DBMS_WORKLOAD_CAPTURE.REPORT(capture_id => cap_id,
format => DBMS_WORKLOAD_CAPTURE.TYPE_TEXT);
END;
/
この例の GET_CAPTURE_INFO プロシージャでは、dec06 ディレクトリに格納されたワーク
ロードの取得に関する情報がすべて取得され、そのワークロードの取得に該当する cap_id が
戻されます。REPORT ファンクションでは、GET_CAPTURE_INFO プロシージャから戻された
cap_id を使用してテキスト・レポートが生成されます。
GET_CAPTURE_INFO プロシージャでは、必須パラメータ dir を使用して、ワークロードの取
得のディレクトリ・オブジェクトの名前を指定しています。
REPORT ファンクションでは、次のパラメータが使用されています。
■
■
必須パラメータ capture_id は、レポートの生成対象となるワークロードの取得を含んだ
ディレクトリに関連しています。このディレクトリには、ワークロードの取得を含んだホ
スト・システム上の有効なディレクトリを指定する必要があります。このパラメータの値
は、GET_CAPTURE_INFO プロシージャから戻された cap_id と一致する必要があります。
必須パラメータ format では、レポート形式を指定します。有効な値は、
DBMS_WORKLOAD_CAPTURE.TYPE_TEXT および
DBMS_WORKLOAD_REPLAY.TYPE_HTML などです。
ワークロードの取得レポートの使用方法は、21-17 ページの「ワークロードの取得レポートの使
用」を参照してください。
関連項目 : DBMS_WORKLOAD_CAPTURE パッケージの詳細は、
『Oracle
Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』
を参照してください。
21-16
Oracle Database パフォーマンス・チューニング・ガイド
ワークロードの取得の分析
ワークロードの取得レポートの使用
ワークロードの取得レポートには、ワークロードの取得の妥当性評価に使用できる各種の情報
が含まれています。このレポートに表示される情報を使用して、取得されたワークロードにつ
いて次のことを判断できます。
■
リプレイする必要のある実際のワークロードを表しているかどうか。
■
除外する必要のあるワークロードが含まれていないかどうか。
■
リプレイできるかどうか。
ワークロードの取得レポートに含まれている情報は、次のカテゴリにわかれています。
■
■
ワークロードの取得の詳細（ワークロードの取得の名前、定義済のフィルタ、日付、時刻
および取得の SCN など）
ワークロードの取得全体の統計（取得された DB 時間合計、取得されたログインおよびトラ
ンザクション数など）と、合計システム・アクティビティに対応する割合
■
取得されたワークロードのプロファイル
■
バージョン制限が原因で取得されなかったワークロードのプロファイル
■
定義済フィルタを使用して除外した、取得されなかったワークロードのプロファイル
■
バックグラウンド・プロセスまたはスケジュール済ジョブで構成される、取得されなかっ
たワークロードのプロファイル
データベース・リプレイ
21-17
ワークロードの取得の分析
21-18
Oracle Database パフォーマンス・チューニング・ガイド
22
SQL パフォーマンス・アナライザ
データベースのアップグレードや新規索引の追加など、SQL 実行計画に影響するシステム変更
は、SQL のパフォーマンスに重大な影響を及ぼす可能性があります。その結果、DBA は変更が
原因で低下した SQL 文の識別と修正に長時間費やすことになります。
SQL パフォーマンス・アナライザは、それぞれの文のパフォーマンスの相違を識別すること
で、変更が SQL ワークロード全体に及ぼす影響の評価プロセスを自動化します。変更がワーク
ロード・パフォーマンスに及ぼす最終的な影響を示すレポートが提供されます。また、低下し
た SQL 文については、チューニング推奨とともに適切な実行計画詳細も提供されます。その結
果、DBA はエンド・ユーザーが影響を受ける前に望ましくない結果を処置し、本番環境に対す
るシステム変更が最終的な改善をもたらすかどうかを検証できます。これにより、大幅に時間
を短縮してコストを削減できます。
SQL パフォーマンス・アナライザを使用すると、あらゆるタイプのシステム変更が SQL パ
フォーマンスに及ぼす影響を分析できます。SQL パフォーマンス・アナライザを使用できる一
般的なシステム変更の例を次に示します。
■
データベースのアップグレード
■
オペレーティング・システム、ハードウェアまたはデータベースの構成変更
■
データベース初期化パラメータの変更
■
スキーマの変更（新規索引やマテリアライズド・ビューの追加など）
■
オプティマイザ統計の収集
■
SQL チューニング・アクション（SQL プロファイルの作成など）の検証
この章には次の項があります。
■
SQL パフォーマンス・アナライザの概要
■
SQL ワークロードの取得
SQL パフォーマンス・アナライザ
22-1
SQL パフォーマンス・アナライザの概要
SQL パフォーマンス・アナライザの概要
図 22-1 に示すように、SQL パフォーマンス・アナライザでは、システム変更が SQL パフォー
マンスに及ぼす影響が 5 つの主要ステップで評価されます。
図 22-1 SQL パフォーマンス・アナライザ・ワークフロー
SQL パフォーマンス・アナライザ・ワークフローのステップは、次のとおりです。
1.
SQL ワークロードの取得
最初に、本番システム上の典型的な SQL ワークロードを表す SQL 文のセットを SQL
チューニング・セット（STS）に取得する必要があります。その後、ワークロードを取得し
たのと同じデータベース、または別のデータベース上で、SQL パフォーマンス・アナライ
ザ分析を実行できます。分析はリソース集中型のため、通常は本番データベース上でワー
クロードを取得し、本番システムに類似したテスト・データベース上で分析を実行します。
これらのアクションの実行方法の詳細は、22-3 ページの「SQL ワークロードの取得」を参
照してください。
2.
変更前のワークロードのパフォーマンス測定
SQL パフォーマンス・アナライザにより、SQL チューニング・セットに取得された SQL
文が実行され、文ごとに実行計画と実行統計が生成されます。データベースへの悪影響を
回避するために、問合せと DML 文の問合せ部分のみが実行されます。SQL パフォーマン
ス・アナライザでは、初期の実行順序と同時実行性が考慮されず、SQL 文が相互に分離さ
れて逐次実行されます。ただし、SQL パフォーマンス・アナライザによる SQL 問合せの実
行順序はカスタマイズできます。たとえば、レスポンス時間に関して最も高コストの SQL
文から開始できます。
3.
変更の実行
測定対象の SQL パフォーマンスに影響するような変更を行います。SQL パフォーマンス・
アナライザでは、多数のタイプのシステム変更による影響を分析できます。たとえば、
データベースのアップグレード、新規索引の作成、初期化パラメータの変更、オプティマ
イザ統計のリフレッシュなどをテストできます。
22-2
Oracle Database パフォーマンス・チューニング・ガイド
SQL ワークロードの取得
4.
変更後のワークロードのパフォーマンス測定
計画に従って変更した後、SQL パフォーマンス・アナライザにより SQL 文が再実行され、
各 SQL 文の実行計画と実行統計が再び生成されます。この実行結果は、SQL パフォーマン
ス・アナライザで以降の比較に使用されるパフォーマンス・データの新規セットを表しま
す。
5.
パフォーマンスの比較
SQL パフォーマンス・アナライザにより、変更前と変更後の SQL 文のパフォーマンスが比
較され、SQL 文の実行計画またはパフォーマンスの変化を識別するレポートが生成されま
す。
低下した SQL 文がパフォーマンス比較により判明した場合は、さらに変更を行って問題を
処置できます。たとえば、SQL チューニング・アドバイザを実行して、低下した SQL を修
正できます。その後、SQL チューニング・セットを実行してパフォーマンスを最初の実行
と比較するプロセスを繰り返すことができます。これらのステップを、分析結果に問題が
なくなるまで繰り返します。
SQL ワークロードの取得
SQL パフォーマンス・アナライザで使用できる SQL ワークロードを取得するには、典型的な
SQL 文セットを取得して SQL チューニング・セットに格納する必要があります。SQL チューニ
ング・セットは、SQL ワークロードの管理に使用するデータベース・オブジェクトです。SQL
チューニング・セットを使用すると、1 つ以上の SQL 文をその実行コンテキストとともに格納
できます。実行コンテキストには、SQL のテキスト、SQL 文をコンパイルできる解析スキー
マ、SQL 文の実行に必要なバインド値、実行計画、SQL 文の実行回数などが含まれます。
SQL チューニング・セットには、カーソル・キャッシュ、自動ワークロード・リポジトリ
（AWR）および既存の SQL チューニング・セットなど、様々なソースから SQL 文をロードで
きます。SQL チューニング・セットの作成、ロードおよび転送の詳細は、12-9 ページの「SQL
チューニング・セット」を参照してください。
注意 : 現在、このリリースでサポートされているのは、SQL ワークロード
の取得のみです。Oracle Database 11g リリース 1（11.1）以降のリリースで
は、取得した SQL ワークロードを実行し、そのパフォーマンスを測定して比
較できます。詳細は、『Oracle Database パフォーマンス・チューニング・ガ
イド 11g リリース 1（11.1）
』を参照してください。
SQL パフォーマンス・アナライザ
22-3
SQL ワークロードの取得
22-4
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 特性に応じて、適応がふさわしいアプリ
ケーションは異なります。
RBO
ルールベース・オプティマイザ（Rule-based optimizer）
。使用可能なアクセス・パスとそのア
クセス・パスのランクに基づいて、SQL 文の実行計画を選択します。複数の方法がある場合
は、RBO ではランクの低い操作が使用されます。
注意 :
この機能はサポートされなくなりました。
SGA
システム・グローバル領域（System Global Area）
。高速なアクセスのためにデータを格納する
メイン・メモリー内のメモリー領域。Oracle では、共有 SQL および PL/SQL プロシージャ用
の SGA メモリーの割当てに共有プールが使用されます。
用語集 -1
SQL*Loader
入力ファイルを読み込み、解析します。大量のデータをロードする最も効率的な方法です。
SQL コンパイラ（SQL Compiler）
）
SQL 文を共有カーソルにコンパイルします。SQL コンパイラは、パーサー、オプティマイザお
よび行ソース・ジェネレータで構成されます。
SQL チューニング・セット（SQL
Tuning Set: STS）
）1 つ以上の SQL 文、実行統計および実行
チューニング・セット（
コンテキストを含むデータベース・オブジェクト。
SQL トレース（SQL Trace）
）
基本的なパフォーマンス診断ツール。Oracle サーバーで実行されるアプリケーションのモニ
ターとチューニングに役立ちます。SQL トレースを使用すると、アプリケーションで実行され
る SQL 文の効率性を評価し、各文の統計を生成できます。このツールで生成されるトレース・
ファイルは、TKPROF の入力として使用されます。
SQL プロファイル（SQL Profile）
）
問合せオプティマイザが SQL 文に対して最適の実行計画を作成できるようにする情報の収集。
SQL 文（同一）
（SQL statements（
（identical）
））
テキストが同じ SQL 文は、すべての点で同一です。
SQL 文（類似）
（SQL statements（
（similar）
））
類似する SQL 文は、リテラル値を変更するという点のみ異なります。リテラル値がバインド変
数に置換された場合、SQL 文はテキストの点で同一になります。
Statspack
パフォーマンス・データの収集、自動化、格納および表示ができる SQL、PL/SQL および
SQL*Plus スクリプトのセット。この機能は自動ワークロード・リポジトリに置き換えられまし
た。
TKPROF
診断ツール。Oracle サーバーで実行されるアプリケーションのモニターとチューニングに役立
ちます。TKPROF は主に、SQL トレースの出力ファイルを処理して読取り可能な出力ファイル
に変換し、トレース・ファイルに関してユーザー・レベルの文と再帰的 SQL コールのサマリー
を提供します。また、SQL 文の効率性の評価、実行計画の生成、データベースに統計を格納す
る SQL スクリプトの作成が実行できます。
UGA
ユーザー・グローバル領域（User Global Area）。ユーザー・セッションに使用されるラージ・
プール内のメモリー領域。
インスタンス・リカバリ（instance recovery）
）
システム障害後に、コミットされていない Oracle データ・ブロックに REDO ログ・レコード
を自動的に適用すること。
エスティメータ（estimator）
）
統計を使用して、選択性、カーディナリティおよび実行計画のコストを評価します。エスティ
メータの主な目標は、実行計画のコスト全体を算出することです。
エンキュー（enqueue）
）
これはロックの別の用語です。
オプティマイザ（optimizer）
）
SQL 文の式を評価し、より処理速度の速い等価の式に変換することによって、SQL 文を最も効
率的に実行する方法を判断します。オプティマイザは実行計画セットを示し、SQL 文に対して
最適な計画を選択します。
「問合せオプティマイザ」を参照してください。
用語集 -2
解析（parse）
）
ハード解析は、SQL 文が実行され、かつ SQL 文が共有プール内にないか、共有プール内にあっ
ても共有できないときに行われます。SQL 文は、2 つの SQL 文のメタデータが異なる場合に共
有されません。これは、ある SQL 文が既存の SQL 文とテキストでは同一ですが、2 つの文で参
照される表が物理的に異なる表に変換される場合、またはオプティマイザ環境が異なる場合に
発生する可能性があります。
ソフト解析は、セッションが SQL 文を実行しようとし、かつ文がすでに共有プール内にあり、
かつ文を使用できる（すなわち、共有できる）ときに行われます。共有される文の場合、既存
の 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 文のパフォーマンスの監視およびチューニングに役立ちます。
自動ワークロード・リポジトリ（Automatic Workload Repository）
）
問題の検出および自己チューニングを目的として、パフォーマンス統計を収集、処理および保
守します。
用語集 -3
述語（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」を参照してください。
ディクショナリ・キャッシュ（dictionary cache）
）
データベース、その構造およびそのユーザーに関する参照情報を含むデータベース表とビュー
を集めたもの。Oracle は、SQL 文の解析時にデータ・ディクショナリに頻繁にアクセスしま
す。ディクショナリ・データを保持するために、メモリー内に 2 つの特別な場所があります。1
つはデータ・ディクショナリ・キャッシュと呼ばれ、データをバッファ（データ・ブロック全
体を保持する）のかわりに行として保持するために行キャッシュとも呼ばれます。もう 1 つの
領域はライブラリ・キャッシュです。すべての Oracle ユーザー・プロセスは、データ・ディク
ショナリ情報にアクセスするためにこれらの 2 つのキャッシュを共有しています。
デカルト積（Cartesian product）
）
結合条件を使用しない結合はデカルト積（クロス積）に帰結します。デカルト積は、各表から
1 つずつ選んだ行の作成可能なすべての組合せです。つまり、2 つの表の結合において、1 つの
表の各行がもう一方の表のすべての行とそれぞれ組み合せられます。3 つ以上の表のデカルト
積は、1 つの表の各行と残りの表のデカルト積のすべての行をそれぞれ組み合せた結果です。
その他のすべての種類の結合は、デカルト積から、効率的に結合条件を満たさない行を絞り込
んで作成されたデカルト積のサブセットです。
問合せオプティマイザ（Query Optimizer）
）
SQL 文の潜在的な実行計画セットの生成、各計画のコストの見積り、計画を生成するプラン・
ジェネレータのコールを実行し、コストを比較して最も低コストの計画を選択します。この方
法は、SQL 文でアクセスされる表の少なくとも 1 つに関する統計がデータ・ディクショナリに
含まれている場合に使用されます。問合せオプティマイザは、問合せトランスフォーマ、エス
ティメータおよびプラン・ジェネレータで構成されます。
用語集 -4
問合せトランスフォーマ（query transformer）
）
ユーザー問合せをリライトして、より効率的な問合せ計画を生成するかどうかを判断し、
ビューをマージして副問合せのネスト解除を実行します。
等価結合（equijoin）
）
等価演算子が含まれている結合条件。
動的パフォーマンス・ビュー（dynamic performance views）
）
データベース管理者が動的パフォーマンス表（現在のデータベース・アクティビティを記録す
る仮想表）に作成するビュー。データベース管理者が変更または削除できないため、固定
ビューと呼ばれます。
トランザクション・リカバリ（transaction recovery）
）
Oracle がコミットされない変更を元に戻すためにロールバック・セグメントを適用するインス
タンス・リカバリの部分。インスタンス・リカバリのロールバック・フェーズとも呼ばれてい
ます。
パーサー（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 つのセグメントを形成します。
用語集 -5
分散型の文（distributed statement）
）
分散データベースの 2 つ以上の個別ノード / インスタンスのデータにアクセスする文。リモー
ト文は、分散データベースの 1 つのリモート・ノードのデータにアクセスします。
ページング（paging）
）
プログラムの作業メモリーのうちの使用頻度の低い部分を主メモリーから二次記憶媒体（通常
はディスク）に移動することによって使用可能なメモリー領域を増やすための手法。転送単位
はページと呼ばれます。
ボトルネック（bottleneck）
）
一般にはシステムの帯域幅がデータの処理される速度で中継されてくる量をサポートできない
ときのデータ伝送の遅延。ただし、システム内にボトルネックを生成する可能性のある要因は
多数あります。
ミラー化（mirroring）
）
同じ内容のデータのコピーを 1 つ以上のディスクで保持すること。一般的にミラー化は、オペ
レーティング・システム・レベルで二重化されたハードディスクにおいて実現します。した
がって、いずれかのディスクが使用不可能になっても、中断せずにもう一方のディスクが要求
の処理を継続できます。
ライブラリ・キャッシュ（library cache）
）
共有されている SQL 領域と PL/SQL 領域を保持するメモリー構造。ライブラリ・キャッシュは
共有プールの 3 つの部分のうちの 1 つです。
ラッチ（latch）
）
システム・グローバル領域で共有されているデータ構造を保護するための簡素な下位レベルの
シリアライズ・メカニズム。
リテラル（literal）
）
コンパイル時に書き込まれ、実行時に読取り専用の定数の値。リテラルは高速にアクセスでき、
また、修正が不要なときに使用します。
用語集 -6
索引
A
C
Active Session History，5-4
addmrpt.sql
Automatic Database Diagnostic Monitor，6-6
ALL_OUTLINE_HINTS ビュー
ストアド・アウトライン・ヒント，18-6
ALL_OUTLINES ビュー
ストアド・アウトライン，18-6
ALL_ROWS ヒント，13-4
ALTER INDEX 文，15-5
ALTER SESSION 文
SET SESSION_CACHED_CURSORS 句，7-30
例，20-12
ANALYZE 文，14-5
Automatic Database Diagnostic Monitor，1-5，6-2，11-5
addmrpt.sql レポート，6-6
API を使用した実行，6-7
DB time，6-3
DBIO_EXPECTED，6-5
DBMS_ADVISOR パッケージ，6-7
STATISTICS_LEVEL パラメータ，6-5
概要，6-3
結果，6-4
検出結果，6-4
考慮される問題のタイプ，6-3
推奨事項のアクションと理論的根拠，6-4
推奨事項のタイプ，6-4
設定，6-5
分析結果の例，6-4
レポートの例，6-4
awrrpt.sql
自動ワークロード・リポジトリ・レポート，5-16，
5-20
CARDINALITY 列
PLAN_TABLE 表，19-19
COMPATIBLE 初期化パラメータ，4-2
consistent gets from cache 統計，7-8
CONTROL_FILES 初期化パラメータ，4-2
COST 列
PLAN_TABLE 表，19-19
CPU，2-6
使用率，9-8
統計，5-5
CPU 統計，10-4
CREATE INDEX 文
PARALLEL 句，4-7
CREATE OUTLINE 文，18-4
CREATE_STORED_OUTLINES 初期化パラメータ，
18-4，18-5
CREATE_STORED_OUTLINES パラメータ，18-4
CURSOR_NUM 列
TKPROF_TABLE 表，20-22
CURSOR_SHARING 初期化パラメータ，7-19，7-33，
13-6
CURSOR_SPACE_FOR_TIME 初期化パラメータ
設定，7-29
B
buffer busy waits イベント，10-12，10-18
処置，10-18
BYTES 列
PLAN_TABLE 表，19-19
B ツリー索引，2-11
D
Database Resource Manager，9-4，9-7，10-4
DATE_OF_INSERT 列
TKPROF_TABLE 表，20-22
db block gets from cache 統計，7-8
db file scattered read 待機イベント，10-12，10-19
処置，10-19，10-21
db file sequential read 待機イベント，10-12，10-19，
10-21
処置，10-21
DB time
測定値，6-3
統計，5-3
DB_BLOCK_SIZE 初期化パラメータ，4-3，8-4
DB_CACHE_ADVICE パラメータ，7-10
DB_CACHE_SIZE 初期化パラメータ，7-10，7-11
DB_DOMAIN 初期化パラメータ，4-2
DB_FILE_MULTIBLOCK_READ_COUNT 初期化パラ
メータ，8-3，8-4，10-19，13-6，13-14
コストベースの最適化，13-23
索引 -1
DB_KEEP_CACHE_SIZE
初期化パラメータ，7-14
DB_NAME 初期化パラメータ，4-2
DB_nK_CACHE_SIZE 初期化パラメータ，7-10
DB_RECYCLE_CACHE_SIZE
初期化パラメータ，7-15
DB_WRITER_PROCESSES 初期化パラメータ，10-26
DBA_HIST_WR_CONTROL ビュー
自動ワークロード・リポジトリ設定，5-11
DBA_HIST ビュー，5-15
DBA_OBJECTS ビュー，7-13
DBA_OUTLINE_HINTS ビュー
ストアド・アウトライン・ヒント，18-6
DBA_OUTLINES ビュー
ストアド・アウトライン，18-6
DBIO_EXPECTED パラメータ，6-5
DBMS_ADDM パッケージ
Automatic Database Diagnostic Monitor，6-6
DBMS_ADVISOR パッケージ，17-2
ADDM 用の設定，6-5
Automatic Database Diagnostic Monitor，6-6，6-7
DBIO_EXPECTED の設定，6-5
DBMS_MONITOR パッケージ
End to End Application Tracing，20-2
DBMS_OUTLN_EDIT パッケージ
アウトラインを管理するプロシージャ，18-3
DBMS_OUTLN パッケージ
アウトラインを管理するプロシージャ，18-3
DBMS_SHARED_POOL パッケージ
共有プールの管理，7-31
DBMS_SQLTUNE パッケージ
SQL チューニング・アドバイザ，12-6，12-10
SQL チューニング・セット，12-10
SQL プロファイル，12-13
DBMS_STATS パッケージ，14-5，17-3
収集プロシージャのサンプル・サイズの手動決定，
14-6
問合せオプティマイザ統計の管理，13-5，14-2
DBMS_WORKLOAD_REPOSITORY パッケージ
自動ワークロード・リポジトリの管理，5-10，5-12
DBMS_XPLAN パッケージ
PLAN TABLE 出力の表示，19-6
DEPTH 列
TKPROF_TABLE 表，20-22
direct path
read イベント，10-22
read イベントの原因，10-22
read イベントの処置，10-22
write イベントの原因，10-23
write イベントの処置，10-23
待機イベント，10-23
DISTRIBUTION 列
PLAN_TABLE 表，19-20
E
End to End Application Tracing，20-1，20-2
DBMS_APPLICATION_INFO パッケージ，20-2
DBMS_MONITOR パッケージ，20-2
アクション名とモジュール名，2-15，20-2
サービスの作成，20-2
索引 -2
enqueue 待機イベント，10-12，10-23
処置，10-24
統計，10-8
EXECUTE_TASK プロシージャ，17-19
EXPLAIN PLAN 文
PLAN_TABLE 表，19-4
TKPROF プログラムでの起動，20-15
アクセス・パス，13-21
基本ステップ，13-11
出力ステップの実行順序，13-12
出力の表示，13-11
出力の例，20-21
出力表示用スクリプト，13-12
制限事項，19-4
ドメイン索引，19-18
パーシャル・パーティション・ワイズ結合，19-14
パーティション・オブジェクト，19-10
フル・パーティション・ワイズ結合，19-16
EXPLAIN_MVIEW プロシージャ，17-34
Export Utility
システム生成の列名の統計，14-12
EXTENT MANAGEMENT LOCAL
一時表領域の作成，4-5
F
FILESYSTEMIO_OPTIONS 初期化パラメータ，9-3
FIRST_ROWS(n) ヒント，13-4
free buffer waits イベント，10-12，10-26
FULL ヒント，15-5
G
GATHER_DATABASE_STATS_JOB_PROC プロシージャ
オプティマイザ統計を自動的に収集，14-3
メンテナンス・ウィンドウでの
GATHER_STATS_JOB，14-3
GATHER_DATABASE_STATS プロシージャ
DBMS_STATS パッケージ，14-6
GATHER_DICTIONARY_STATS プロシージャ
DBMS_STATS パッケージ，14-6
GATHER_INDEX_STATS プロシージャ
DBMS_STATS パッケージ，14-6
GATHER_SCHEMA_STATS プロシージャ
DBMS_STATS パッケージ，14-6
GATHER_STATS_JOB
オプティマイザ統計を自動的に収集，14-3
GATHER_TABLE_STATS プロシージャ
DBMS_STATS パッケージ，14-6
GETMISSES 列
V$ROWCACHE 表，7-25
GETS 列
V$ROWCACHE ビュー，7-25
GV$BUFFER_POOL_STATISTICS ビュー，7-12
H
HOLD_CURSOR 句，7-20
HW エンキュー
競合，10-24
I
ID 列
PLAN_TABLE 表，19-19
Import Utility
統計のコピー，14-12
INDEX_COMBINE ヒント，15-5
INDEX_FFS ヒント，13-20
INDEX_JOIN ヒント，13-20
indexspec
ヒント構文，16-9
INDEX ヒント，15-5
INLIST，19-16
INLIST ITERATOR 操作，19-16
I/O
I/O 待機を発生させるオブジェクト，10-20
SQL 文，10-20
過剰な I/O 待機，10-19
監視，10-4
競合，5-3，10-4，10-6，10-19，10-32
低減，15-4
IOT（索引構成表）
，2-11
K
KEEP キャッシュ，7-11
KEEP バッファ・プール，7-14
L
LARGE_POOL_SIZE 初期化パラメータ，7-27
latch free 待機イベント，10-12
処置，10-28
log file
parallel write 待機イベント，10-31
switch 待機イベント，10-32
sync 待機イベント，10-12，10-33
LOG_BUFFER 初期化パラメータ，7-34
設定，7-35
LRU
除去方針，7-11
ラッチの競合，10-31
M
MAX_DISPATCHERS 初期化パラメータ，4-9
MAX_DUMP_FILE_SIZE 初期化パラメータ
SQL トレース，20-10
MAXOPENCURSORS 句，7-20
N
NAMESPACE 列
V$LIBRARYCACHE ビュー，7-22
NO_INDEX ヒント，15-5
NOT IN 副問合せ，13-23
O
OBJECT_INSTANCE 列
PLAN_TABLE 表，19-19
OBJECT_NAME 列
PLAN_TABLE 表，19-18
OBJECT_NODE 列
PLAN_TABLE 表，19-18
OBJECT_OWNER 列
PLAN_TABLE 表，19-18
OBJECT_TYPE 列
PLAN_TABLE 表，19-19
OLAP_PAGE_POOL_SIZE 初期化パラメータ，7-48
OPEN_CURSORS 初期化パラメータ，4-2
各セッションのカーソル数の増加，7-25
OPERATION 列
PLAN_TABLE 表，19-18，19-21
OPTIMIZER_DYNAMIC_SAMPLING 初期化パラ
メータ，14-14
OPTIMIZER_FEATURES_ENABLE 初期化パラメータ，
13-5，13-20
OPTIMIZER_INDEX_CACHING 初期化パラメータ，
13-6
OPTIMIZER_INDEX_COST_ADJ 初期化パラメータ，
13-6
OPTIMIZER_MODE 初期化パラメータ，13-4，13-7，
16-3
ヒントの影響，13-4
OPTIMIZER 列
PLAN_TABLE，19-19
OPTIONS 列
PLAN_TABLE 表，19-18
OPTMIZER_DYNAMIC_SAMPLING 初期化パラ
メータ，13-5
Oracle CPU 統計，10-4
Oracle Enterprise Manager
SQL アクセス・アドバイザへのアクセス，11-5
アドバイザ，1-6
「パフォーマンス」ページ，1-6
Oracle Forms，20-12
解析とプライベート SQL 領域の制御，7-21
Oracle Managed Files，8-8
チューニング，8-8
Oracle のパフォーマンス改善方法，3-2
手順，3-3
ORDERED ヒント，13-23
OTHER_TAG 列
PLAN_TABLE 表，19-19
OTHER 列
PLAN_TABLE 表，19-20
P
PARALLEL 句
CREATE INDEX 文，4-7
PARENT_ID 列
PLAN_TABLE 表，19-19
PARTITION_ID 列
PLAN_TABLE 表，19-20
PARTITION_START 列
PLAN_TABLE 表，19-20
PARTITION_STOP 列
PLAN_TABLE 表，19-20
PCTFREE パラメータ，4-6，10-14
PCTUSED パラメータ，10-14
PGA_AGGREGATE_TARGET 初期化パラメータ，4-3，
4-7，7-37，9-3，13-7
physical reads from cache 統計，7-8
索引 -3
PLAN_TABLE 表
BYTES 列，19-19
CARDINALITY 列，19-19
COST 列，19-19
DISTRIBUTION 列，19-20
ID 列，19-19
OBJECT_INSTANCE 列，19-19
OBJECT_NAME 列，19-18
OBJECT_NODE 列，19-18
OBJECT_OWNER 列，19-18
OBJECT_TYPE 列，19-19
OPERATION 列，19-18
OPTIMIZER 列，19-19
OPTIONS 列，19-18
OTHER_TAG 列，19-19
OTHER 列，19-20
PARENT_ID 列，19-19
PARTITION_ID 列，19-20
PARTITION_START 列，19-20
PARTITION_STOP 列，19-20
POSITION 列，19-19
REMARKS 列，19-18
SEARCH_COLUMNS 列，19-19
STATEMENT_ID 列，19-18
TIMESTAMP 列，19-18
作成，19-4
表示，19-6
PL/SQL プロシージャ
EXPLAIN_MVIEW，17-34
TUNE_MVIEW，17-34
POSITION 列
PLAN_TABLE 表，19-19
PRIMARY KEY 制約，15-6
PRIVATE_SGA 変数，7-28
PROCESSES 初期化パラメータ，4-3
R
rdbms ipc reply 待機イベント，10-33
read 待機イベント
direct path，10-22
scattered，10-19
REBUILD 句，15-5
RECYCLE キャッシュ，7-11
REDO BUFFER ALLOCATION RETRIES 統計，7-35
REDO ログ，4-4
サイズ設定，4-4
ディスク上の配置，8-6
バッファ・サイズ，10-32
ミラー化，8-7
領域要求，10-13
REDO ログのサイズ設定，4-4
RELEASE_CURSOR 句，7-20
REMARKS 列
PLAN_TABLE 表，19-18
ROWID
表アクセス，13-16
索引 -4
S
SAMPLE BLOCK 句，13-21
アクセス・パスおよびヒント，13-22
SAMPLE 句，13-21
アクセス・パスおよびヒントによる上書き不可，
13-22
sar UNIX コマンド，9-9
SEARCH_COLUMNS 列
PLAN_TABLE 表，19-19
SELECT 文
SAMPLE 句，13-21
sequential read 待機イベント
処置，10-21
SESSION_CACHED_CURSORS 初期化パラメータ，7-29
SESSIONS 初期化パラメータ，4-3
SGA_TARGET 初期化パラメータ，4-3
自動共有メモリー管理，7-2
自動メモリー管理，7-2
SGA サイズ，7-35
SHARED_POOL_RESERVED_SIZE 初期化パラメータ，
7-31
SHARED_POOL_SIZE 初期化パラメータ，7-26，7-31
共有プールのチューニング，7-28
ライブラリ・キャッシュの割当て，7-25
SHOW SGA 文，7-5
SQL*Net
message from client アイドル・イベント，10-16
message from dblink 待機イベント，10-17
more data to client 待機イベント，10-17
SQL_STATEMENT 列
TKPROF_TABLE，20-22
SQL_TRACE
初期化パラメータ，20-12
SQLTUNE_CATEGORY 初期化パラメータ
SQL プロファイルのカテゴリの判別，12-3
SQL アクセス・アドバイザ，1-5，11-5，17-2，17-8
EXECUTE_TASK プロシージャ，17-19
Oracle Enterprise Manager を使用したアクセス，
11-5
クイック・チューニング，17-27
権限，17-7
定数，17-28
使用手順，17-3
推奨事項の実装，17-5
推奨事項の生成，17-5
推奨プロセス，17-23
タスクの作成，17-3
ワークロード・オブジェクト，17-9
ワークロードの定義，17-4
ワークロードのメンテナンス，17-16
SQL アクセス・アドバイザのワークロード
メンテナンス，17-16
SQL チューニング・アドバイザ，1-5，11-5
API を使用した管理，12-6，12-10
概要，12-5
チューニング・オプション，12-6
入力ソース，12-5
SQL チューニング・セット
API による管理，12-9，12-10
説明，11-5，12-5，12-6
SQL トレース機能，20-8，20-13
実行手順，20-10
出力，20-17
出力の例，20-21
トレース・ファイル，20-11
文の切捨て，20-20
SQL パフォーマンス・アナライザ
SQL ワークロードの取得，22-3
SQL プロファイル
API による管理，12-13
説明，12-3
SQL 文
I/O を待機，10-20
索引データの修正，15-3
索引不使用，15-5
索引を使用，15-5
実行計画，13-11
低下の識別，22-1
SQL ワークロード
SQL パフォーマンス・アナライザでの取得，22-2
SQL ワークロードのジャーナル，17-23
STAR_TRANSFORMATION_ENABLED 初期化パラ
メータ，13-7
STATEMENT_ID 列
PLAN_TABLE 表，19-18
STATISTICS_LEVEL 初期化パラメータ，5-7，10-5
Automatic Database Diagnostic Monitor の有効化，
6-5
自動ワークロード・リポジトリ，5-8
統計収集用の設定，1-5
STREAMS_POOL_SIZE 初期化パラメータ，4-3，7-3
ST エンキュー
競合，10-24
T
tablespec
ヒント構文，16-8
TIMED_STATISTICS 初期化パラメータ
SQL トレース，20-10
TIMESTAMP 列
PLAN_TABLE 表，19-18
TKPROF_TABLE，20-22
問合せ，20-22
TKPROF プログラム，20-9，20-13
EXPLAIN PLAN 文の使用，20-15
行ソースの操作，20-18
構文，20-14
出力 SQL スクリプトの生成，20-21
出力 SQL スクリプトの編集，20-21
出力の例，20-21
待機イベント情報，20-19
TM エンキュー
競合，10-24
TRACEFILE_IDENTIFIER 初期化パラメータ
トレース・ファイルの識別，20-11
trcsess ユーティリティ，20-7
TUNE_MVIEW プロシージャ，17-34
TX エンキュー
競合，10-25
U
UNDO TABLESPACE 句，4-3
UNDO_MANAGEMENT 初期化パラメータ，4-3
UNDO_TABLESPACE 初期化パラメータ，4-3
UNDO 管理
自動モード，4-3
UNIX システム・パフォーマンス，9-5
USE_STORED_OUTLINES パラメータ，18-5
USER_DUMP_DEST 初期化パラメータ，20-11
SQL トレース，20-11
USER_ID 列
TKPROF_TABLE，20-22
USER_OUTLINE_HINTS ビュー
ストアド・アウトライン・ヒント，18-6
USER_OUTLINES ビュー
ストアド・アウトライン，18-6
UTLCHN1.SQL スクリプト，10-14
UTLXPLP.SQL スクリプト
EXPLAIN PLAN の表示用，13-12
PLAN TABLE 出力の表示，19-6
UTLXPLS.SQL スクリプト
EXPLAIN PLAN の表示に使用，13-12
EXPLAIN PLAN の表示用，13-12
PLAN TABLE 出力の表示，19-6
V
V$ACTIVE_SESSION_HISTORY ビュー，5-4，10-6
V$ADVISOR_PROGRESS ビュー，12-8，12-15
V$BH ビュー，7-13
V$BUFFER_POOL_STATISTICS ビュー，7-12
V$DB_CACHE_ADVICE ビュー，7-6，7-8，7-9，7-10，
7-12
V$EVENT_HISTOGRAM ビュー，10-7
V$FILE_HISTOGRAM ビュー，10-7
V$JAVA_LIBRARY_CACHE_MEMORY ビュー，7-23
V$JAVA_POOL_ADVICE ビュー，7-23
V$LIBRARY_CACHE_MEMORY ビュー，7-23
V$LIBRARYCACHE ビュー
NAMESPACE 列，7-22
V$OSSTAT ビュー，5-5
V$PGASTAT ビュー，7-38
V$PROCESS_MEMORY ビュー，7-40
V$PROCESS ビュー，7-40
V$QUEUE ビュー，4-10
V$ROWCACHE ビュー
GETMISSES 列，7-25
GETS 列，7-25
パフォーマンス統計，7-24
V$RSRC_CONSUMER_GROUP ビュー，10-4
V$SESS_TIME_MODEL ビュー，5-3，10-6
V$SESSION_EVENT ビュー，10-7，10-15
V$SESSION_WAIT_CLASS ビュー，10-7
V$SESSION_WAIT_HISTORY ビュー，10-7
V$SESSION_WAIT ビュー，10-7，10-15
V$SESSION ビュー，10-7，10-8，10-15
V$SESSTAT ビュー，10-4
使用，7-27
V$SHARED_POOL_ADVICE ビュー，7-23
V$SHARED_POOL_RESERVED ビュー，7-31
V$SQL_PLAN_STATISTICS_ALL ビュー
実行計画情報の表示に使用，19-4
索引 -5
V$SQL_PLAN_STATISTICS ビュー
実行計画の統計表示に使用，19-3
V$SQL_PLAN ビュー
実行計画の表示に使用，19-3
V$SQL_WORKAREA_ACTIVE ビュー，7-42
V$SQL_WORKAREA_HISTOGRAM ビュー，7-40
V$SQL_WORKAREA ビュー，7-42
V$SYS_TIME_MODEL ビュー，5-3，5-5，10-6
V$SYSMETRIC_HISTORY ビュー，5-5
V$SYSSTAT ビュー
REDO バッファ割当て，7-35
使用，7-8
V$SYSTEM_EVENT ビュー，10-7，10-15
V$SYSTEM_WAIT_CLASS ビュー，10-7
V$TEMP_HISTOGRAM ビュー，10-7
V$UNDOSTAT ビュー，4-4
V$WAITSTAT ビュー，10-8
vmstat UNIX コマンド，9-9
W
Windows のパフォーマンス，9-5
あ
アイドル待機イベント，10-34
SQL*Net message from client，10-16
アウトライン
CREATE OUTLINE 文，18-4
格納要件，18-3
作成と使用，18-4
実行計画とプラン・スタビリティ，18-2
使用，18-5
説明，18-2
データの照会，18-6
問合せオプティマイザへの移行，18-8
表の移動，18-7
ヒント，18-3
空きリスト，10-18
アクセス・パス
クラスタ・スキャン，13-21
索引スキャン，13-16
実行計画，13-11
定義，13-13
ハッシュ・スキャン，13-21
アップグレード
コストベース・オプティマイザへ，18-9
アプリケーション
開発の傾向，2-16
実装，2-14
設計の原則，2-10
配置，2-20
アプリケーションの配置，2-20
アンチ結合，13-23
い
移行行，10-14
一意性，15-6
一意制約，15-6
一時表領域，4-4
作成，4-5
索引 -6
一貫性
読取り，10-13
一貫モード
TKPROF，20-18
インスタンスの構成
初期化ファイル，4-2
パフォーマンスの考慮事項，4-2
インターネットの拡張性，2-4
え
エラー・メッセージ・マニュアル，xxiii
お
応答時間，2-9
オプティマイザの目標，13-3
コストベースのアプローチ，13-4
最適化，13-3
オブジェクト指向，2-16
オプティマイザ
RBO からの移行，18-8
アップグレード，18-9
応答時間，13-3
概要，1-4，13-2
コスト計算，13-7
スループット，13-3
設定モードのパラメータ，13-4
操作，13-2
問合せ，1-4
統計，14-2
プラン・スタビリティ，18-2
モード，12-2
目標，13-3
オペレーティング・システム
ディスク I/O の監視，10-4
データ・キャッシュ，9-2
統計，5-5
か
カーソル
アクセス，7-20
共有，7-20
開始列
パーティション化と EXPLAIN PLAN 文，19-11
解析
Oracle Forms，7-21
Oracle プリコンパイラ，7-20
ソフト，2-13
ハード，2-13
不要コールの低減，7-20
概念的なモデル化，3-4
開発環境，2-14
外部結合，11-13，13-27
拡張構文
グローバル・ヒント，16-8
ヒントにおける表の指定，16-8
拡張性，2-3
インターネット，2-4
妨げる要因，2-5
線状，2-5
仮想メモリー統計，5-5
型変換，11-7
監視
診断，1-5，11-5
完全外部結合，13-29
き
規定された制約，15-6
逆キー索引，2-12
行
位置特定に使用される ROWID，13-16
行ソース，13-13
行キャッシュ・オブジェクト，10-31
競合
共有プール，10-29
待機イベント，10-28
チューニング，10-1
メモリー，7-2，10-1
ライブラリ・キャッシュ・ラッチ，10-29
行ソース，13-13
共有 SQL 領域
メモリー割当て，7-25
共有サーバー
競合の低減，4-8
チューニング，4-8
パフォーマンス問題，4-8
メモリーのチューニング，7-27
共有プール競合，10-29
緊急事態
パフォーマンス，3-7
く
クライアント / サーバー・アプリケーション，9-9
クラス
待機イベント，5-3，10-6
クラスタ，15-10
スキャン，13-21
ソートされたハッシュ・クラスタ，15-11
ハッシュおよびスキャン，13-21
グローバル・ヒント，16-8
け
結合
アンチ結合，13-23
外部，13-27
完全外部，13-29
結合順序および実行計画，13-11
索引結合，13-20
実行計画，13-22
順序，11-13
セミ結合，13-23
ソート / マージ，13-26
ソート / マージおよびコストベースの最適化，13-23
デカルト，13-27
ネステッド・ループ，13-24
ネステッド・ループおよびコストベースの最適化，
13-23
パーティション・ワイズ
パーシャルの例，19-14
フル，19-16
フルの例，19-16
ハッシュ，13-25
権限
SQL アクセス・アドバイザ，17-7
現行モード
TKPROF，20-18
こ
コスト
オプティマイザ計算，13-7
コストベースの最適化，13-7
アップグレード，18-9
プラン・スタビリティのプロシージャ，18-8
コンテキスト・スイッチ，9-9
コンポーネント
ソフトウェア，2-6
ハードウェア，2-6
コンポジット・パーティション化
例，19-12
さ
サービス時間，2-9
再帰的コール，20-19
最高水位標，13-14
最大セッション・メモリー統計，7-27
最適化
アプローチの選択，13-4
コスト計算，13-7
コストベース，13-7
コストベースおよびアクセス・パスの選択，13-21
実行される操作，13-2
手動，13-4
説明，1-4，13-2
動的サンプリング，13-5
ヒント，13-4，13-20
索引
B ツリー，2-11
I/O の削減，2-12
値の修正，15-3
一意性の規定，15-6
一意でない，15-6
逆キー，2-12
結合，13-20
コスト，2-12
コンポジット，15-4
再作成，15-5
索引結合，13-20
削除，15-2
作成，4-7
順序，2-12
使用，15-5
シリアライズ，2-12
スキャン，13-16
設計，2-11
索引 -7
選択性，2-12，15-3
選択性の向上，15-4
ディスク上の配置，8-5
低選択性，15-5
統計の収集，14-11
ドメイン，15-9
パーティション，2-12
ビットマップ，2-11，15-9
ヒントでの指定，16-9
ファンクション索引，2-12，15-7
不使用，15-5
列の順序，2-12
列の選択，15-3
列の追加，2-11
索引構成表，2-11
サンプル表スキャン，13-21
ヒントによる上書き不可，13-22
し
時間モデル統計，5-3
式
型が混在，11-7
システム・アーキテクチャ，2-6
構成，2-8
ソフトウェア・コンポーネント，2-6
データおよびトランザクション，2-7
ビジネス・ロジックの実装，2-7
ユーザー・インタフェースの管理，2-7
ユーザー要求およびリソース割当て，2-7
ハードウェア・コンポーネント，2-6
CPU，2-6
I/O サブシステム，2-6
ネットワーク，2-6
メモリー，2-6
システム・グローバル領域のチューニング，7-5
実行計画
TKPROF，20-13，20-15
utlxpls.sql スクリプトによる表示，13-11
概要，13-11
結合，13-22
プラン・スタビリティ，18-2
プラン・スタビリティでの保存，18-2
例，20-13
自動 SQL チューニング，1-5，11-5
概要，12-2
機能，12-1
分析，12-3
自動 UNDO 管理，4-3
モード，4-3
自動共有メモリー管理，7-2
自動セグメント領域管理，4-5，8-9，10-18
自動チューニング・オプティマイザ，12-2
自動ワークロード・リポジトリ，1-5
API による管理，5-10，5-12
DBA_HIST_WR_CONTROL ビューで設定，5-11
DBMS_WORKLOAD_REPOSITORY パッケージ，
5-10，5-12
概要，5-8
自動スナップショット収集をオフに設定，5-9
収集される統計，5-8
データの収集，5-2
データへのアクセスに使用するビュー，5-15
索引 -8
デフォルト設定，5-9
保存期間，5-9
保存期間に関する推奨事項，5-9
領域使用量，5-9
領域使用量に影響する要因，5-9
領域使用量の最小化，5-9
レポート，5-16，5-20
レポートの例外的なパーセンテージ，5-16
終了列
パーティション化と EXPLAIN PLAN 文，19-11
順序
結合，11-13
使用可能にされた制約，15-6
使用禁止にされた制約，15-6
照合
バインド変数，13-9
初期化パラメータ
CONTROL_FILES，4-2
DB_BLOCK_SIZE，4-3
DB_DOMAIN，4-2
DB_FILE_MULTIBLOCK_READ_COUNT，13-23
DB_NAME，4-2
OPEN_CURSORS，4-2
OPTIMIZER_DYNAMIC_SAMPLING，14-14
OPTIMIZER_FEATURES_ENABLE，13-20
OPTIMIZER_MODE，13-4，16-3
PGA_AGGREGATE_TARGET，4-7
PROCESSES，4-3
SESSION_CACHED_CURSORS，7-29
SESSIONS，4-3
SQL_TRACE，20-12
STREAMS_POOL_SIZE，4-3，7-3
USER_DUMP_DEST，20-11
診断モニター，1-5，6-2，11-5
概要，6-2
す
スキャン
索引，13-16
索引結合，13-20
サンプル表，13-21
サンプル表およびヒントは上書き不可，13-22
タイプ・ビットマップの索引，13-20
ストアド・アウトライン
格納要件，18-3
作成と使用，18-4
実行計画とプラン・スタビリティ，18-2
使用，18-5
データの照会，18-6
表の移動，18-7
ヒント，18-3
ストライプ化
手動，8-5
スナップショット
説明，5-8
スラッシング，9-9
スループット
オプティマイザの目標，13-3
最適化，13-3
スワッピング，9-9
低減，7-5
せ
制約，15-6
セグメント・レベル統計，10-8
設計
検証，2-18
テスト，2-18
デバッグ，2-18
設計の検証，2-18
設計の原則，2-10
設計のテスト，2-18
設計のデバッグ，2-18
セッション・メモリー統計，7-27
セミ結合，13-23
線状の拡張性，2-5
選択性
索引，15-5
索引内の列の順序付け，2-12
索引の向上，15-4
索引の作成，15-3
全表スキャン，10-22
そ
ソート / マージ結合，13-26
コストベースの最適化，13-23
ソート領域
チューニング，7-36
測定値，5-2
ソフトウェア
コンポーネント，2-6
ソフト解析，2-13
た
待機イベント，5-3
buffer busy waits，10-18
direct path，10-23
enqueue，10-23
free buffer waits，10-26
log buffer space，10-32
log file parallel write，10-31
log file switch，10-32
log file sync，10-33
rdbms ipc reply，10-33
アイドル待機イベント，10-34
競合待機イベント，10-28
クラス，5-3，10-6
ネットワーク通信待機イベント，10-16
ライブラリ・キャッシュ・ラッチ，10-28
ラッチ，10-28
リソース待機イベント，10-21
ち
チューニング
SQL チューニング・アドバイザ，12-5
共有サーバー，4-8
システム・グローバル領域（SGA）
，7-5
ソート，7-36
プロアクティブな監視，1-3
ボトルネックの解消，1-4
メモリー割当て，7-6
ラッチ，1-3，10-29
リソースの競合，10-1
論理構造，15-2
つ
ツール
パフォーマンス・チューニング，1-5
て
低減
共有サーバーとの競合，4-10
ディスパッチャとの競合，4-9
データ・ディクショナリ・キャッシュ・ミス，7-25
不要解析コール，7-20
ページングとスワッピング，7-5
ディスク
オペレーティング・システムファイル・アクティビ
ティの監視，10-4
統計，5-6
データ
キャッシュ，9-2
検索，2-9
収集，5-2
問合せ，2-9
トランザクション，2-7
モデル化，2-10
データ・ディクショナリ，7-25
最適化で使用されるビュー，14-16
統計，14-16
データベース
サイズ，2-9
診断と監視，6-2
統計，5-3
バッファ，7-10，7-26
データベース監視，1-5，11-5
診断，6-2
デカルト結合，13-27
デフォルト・キャッシュ，7-11
テンプレート
SQL アクセス・アドバイザ，17-8
と
問合せ
索引不使用，15-5
索引を使用，15-5
データ，2-9
問合せオプティマイザ，1-4
「オプティマイザ」を参照
等価結合，11-7
統計
consistent gets from cache，7-8
db block gets from cache，7-8
DBMS_STATS パッケージでの収集，14-5
DBMS_STATS プロシージャによる収集，14-5
GATHER_STATS_JOB，14-3
physical reads from cache，7-8
STATISTICS_LEVEL 初期化パラメータ，1-5
エクスポートとインポート，14-12
オプティマイザ，14-2
オプティマイザ使用，13-7
索引 -9
オプティマイザ・モード，13-4
オペレーティング・システム，5-5
CPU 統計，5-5
仮想メモリー統計，5-5
ディスク統計，5-6
ネットワーク統計，5-6
外部表に関する収集，14-4
共有サーバー・プロセス，4-10
欠落，14-15
最大セッション・メモリー，7-27
サンプリングを使用した収集，14-6
時間モデル，5-3
システム，14-8
失効，14-7
失効したものを収集，14-7
自動収集，14-3
自動収集を使用可能にする方法，14-3
収集，5-2
収集する時期，14-8
手動による収集，14-5
セグメント・レベル，10-8
セッション・メモリー，7-27
データベース，5-3
問合せ最適化のための生成，14-3
ヒストグラム，14-16
ビューに表示，14-16
ベースライン，5-2
前のバージョンのリストア，14-11
前のバージョンのリストアに関する制限事項，14-12
ユーザー定義，14-7
ロック，14-13
動的サンプリング
パフォーマンスの向上，14-14
プロセス，14-14
目的，14-13
用途，14-14
レベル設定，14-14，14-15
ドメイン索引
EXPLAIN PLAN，19-18
使用，15-9
トランザクションおよびデータ，2-7
トリクル・ロールアウトの方法，2-20
トレース
trcsess との統合，20-7
ファイルの識別，20-11
ね
ネステッド・ループ結合，13-24
コストベースの最適化，13-23
ネットワーク
速度，2-9
統計，5-6
ハードウェア・コンポーネント，2-6
ネットワーク通信待機イベント，10-16
db file scattered read 待機イベント，10-19
db file sequential read 待機イベント，10-19，10-21
SQL*Net message from dblink，10-17
SQL*Net more data to client，10-17
索引 -10
は
パーティション・オブジェクト
EXPLAIN PLAN 文，19-10
パーティション化
開始列と終了列，19-11
ハッシュ，19-10
複合の例，19-12
分散値，19-21
例，19-11
レンジ，19-10
パーティション索引，2-12
パーティション・ワイズ結合
パーシャル、EXPLAIN PLAN 出力，19-14
フル，19-16
フル、EXPLAIN PLAN 出力，19-16
ハードウェア
コンポーネント，2-6
コンポーネントのサイズ指定，2-5
コンポーネントの制限，2-5
ハード解析，2-13
バインド変数，7-18
照合，13-9
パッケージ
DBMS_ADVISOR，17-2
DBMS_STATS，17-3
ハッシュ
分散値，19-21
ハッシュ・クラスタ
スキャン，13-21
ソート，15-11
ハッシュ結合，13-25
コストベースの最適化，13-23
索引結合，13-20
ハッシュ・パーティション，19-10
例，19-11
ハッシング，15-11
バッファ・キャッシュ
競合，10-19，10-21，10-29
バッファ数の低減，7-10，7-26
ヒット率，7-9
バッファ・プール
KEEP，7-14
KEEP キャッシュ，7-11
RECYCLE キャッシュ，7-11
デフォルト・キャッシュ，7-11
ヒット率，7-12
複数，7-11
パフォーマンス
UNIX ベース・システム，9-5
Windows，9-5
Windows でのメモリーの監視，9-9
改善方法，3-2
改善方法の手順，3-3
緊急事態，3-7
実行計画の表示，13-11
診断およびチューニング用のツール，1-5
メインフレーム，9-5
パフォーマンスの緊急の問題に対処する方法，3-7
ひ
ビジネス・ロジック，2-7，2-14
ビジネス・ロジックの実装，2-7
ヒストグラム
高さ調整済，14-16
表示，14-16
頻度，14-18
ビッグ・バン・ロールアウトの方法，2-20
ビットマップ索引，2-11
INLIST ITERATOR，19-17
結合，15-9
用途，15-9
ビュー，2-13
DBA_HIST，5-15
統計，14-16
表
記憶領域オプションの設定，4-6
作成，4-6
設計，2-11
全表スキャン，10-22
ディスク上の配置，8-5
表領域，4-4
一時，4-4，4-5
作成，4-4
作成、一時，4-5
ヒント
FULL，15-5
INDEX_FFS，13-20
INDEX_JOIN，13-20
indexspec 構文，16-9
NO_INDEX，15-5
ORDERED ヒント，13-23
tablespec 構文，16-8
アウトラインでの使用，18-3
アクセス・パス，11-12，16-3，16-4
位置構文，16-7
上書き OPTIMIZER_MODE，13-4
オプティマイザ，16-2
オプティマイザの選択を上書き，13-22
拡張構文の使用，16-8
グローバル，16-8
グローバルとローカルの比較，16-8
結合操作，16-4
最適化のアプローチと目標，16-3
索引の指定，16-9
サンプル・アクセス・パスは上書き不可，13-22
使用方法，16-2
問合せブロックの指定，16-7
パラレル問合せオプション，16-5
並列度，16-5
制限事項，18-2
ヒントの使用，18-2
プリコンパイラ
解析とプライベート SQL 領域の制御，7-20
フル・パーティション・ワイズ結合，19-16
プロアクティブな監視，1-3
ブロードキャスト
分散値，19-21
プログラミング言語，2-14
プログラム・グローバル領域（PGA）
direct path read，10-22
direct path write，10-23
共有サーバー，7-27
プロセス
スケジューリング，9-9
プロセスのスイッチング，9-9
ブロック・クリーンアウト，10-13
ブロック・サイズ
最適な，8-9
選択，8-9
分散読取り待機イベント，10-19
処置，10-19
へ
ページ表，9-9
ページング，9-9
低減，7-5
ベースライン，1-2
説明，5-9
パフォーマンス，5-2
変換されない列値，11-7
ほ
ボトルネック
解消，1-4
修正，3-2
特定，3-2
メモリー，7-2
リソース，10-17
ま
マテリアライズド・ビュー
チューニング，17-34
み
ミラー化
REDO ログ，8-7
ふ
め
ファンクション索引，2-12，15-7
複合索引，15-4
複数バッファ・プール，7-11
副問合せ
NOT IN，13-23
ネスト解除，11-14
プラン・スタビリティ，18-2
コストベース・オプティマイザのプロシージャ，18-8
実行計画の保存，18-2
メモリー
ハードウェア・コンポーネント，2-6
メモリー割当て
共有 SQL 領域，7-25
重要性，7-2
チューニング，7-6
ライブラリ・キャッシュ，7-25
索引 -11
も
モデル化
概念的，3-4
データ，2-10
ワークロード，2-18
ゆ
ユーザー
位置，2-9
インタフェース，2-14
応答時間，2-9
数，2-8
対話方式，2-9
ネットワーク速度，2-9
要求，2-14
ユーザー・インタフェースの管理，2-7
ユーザー・グローバル領域（UGA）
V$SESSTAT，7-27
共有サーバー，4-8，7-27
ユーザー定義のバインド変数，13-9
ユーザー要求，2-7
よ
読取り一貫性，10-13
ら
ライブラリ・キャッシュ
PIN，10-32
メモリー割当て，7-25
ラッチ待機イベント，10-28
ラッチの競合，10-29
ロック，10-32
ラウンドロビン
分散値，19-21
ラッチ
チューニング，1-3，10-29
ラッチ待機イベント，10-28
ラッチの競合
共有プール・ラッチ，10-10
ライブラリ・キャッシュ・ラッチ，10-10
り
リソース
待機イベント，10-21
ボトルネック，10-17
割当て，2-7，2-14
れ
例
ALTER SESSION 文，20-12
EXPLAIN PLAN 出力，20-21
SQL トレース機能の出力，20-21
列
索引付け，15-3
列の順序
索引，2-12
連鎖行，10-14
索引 -12
レンジ
パーティション，19-10
パーティションの例，19-11
分散値，19-21
ろ
ロールアウトの方法
トリクル・アプローチ，2-20
ビッグ・バン・アプローチ，2-20
ログ・バッファ
space 待機イベント，10-12，10-32
チューニング，7-35
ログ・ライター・プロセス
チューニング，8-6
ロックおよびロック・ホルダー
検索，10-24
わ
ワークロード
削除，17-10
テスト，2-18
見積り，2-17
推定，2-17
ベンチマーク，2-18
モデル化，2-18
ワークロード・オブジェクト，17-9
ワークロードの推定，2-17
ワークロードのベンチマーク，2-18
ワークロードの見積り，2-17
推定，2-17
ベンチマーク，2-18
割当て
メモリー，7-2