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

パフォーマンスの原理 ................................................................................................................................ 1-2ベースライン ................................................................................................................................................ 1-2

症状および問題点 ........................................................................................................................................ 1-3チューニングの時期 .................................................................................................................................... 1-3

プロアクティブな監視 ........................................................................................................................ 1-3

ボトルネックの解消 ............................................................................................................................ 1-4SQL チューニング ............................................................................................................................................... 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

ハードウェア・コンポーネント ................................................................................................................ 2-6CPU ........................................................................................................................................................ 2-6メモリー ................................................................................................................................................ 2-6

I/O サブシステム ................................................................................................................................ 2-6ネットワーク ........................................................................................................................................ 2-6

ソフトウェア・コンポーネント ................................................................................................................ 2-6

ユーザー・インタフェースの管理 .................................................................................................... 2-7ビジネス・ロジックの実装 ................................................................................................................ 2-7ユーザー要求とリソース割当ての管理 ............................................................................................ 2-7

データおよびトランザクションの管理 ............................................................................................ 2-7要件に合った正しいシステム・アーキテクチャの構成 ................................................................................ 2-8

アプリケーション設計の原則アプリケーション設計の原則アプリケーション設計の原則アプリケーション設計の原則 ................................................................................................................................. 2-10アプリケーション設計の簡潔さ ...................................................................................................................... 2-10

データのモデル化 .............................................................................................................................................. 2-10

表および索引の設計 .......................................................................................................................................... 2-11

索引への列の追加または索引構成表の使用 .......................................................................................... 2-11

異なる索引タイプの使用 .......................................................................................................................... 2-11B ツリー索引 ....................................................................................................................................... 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-2Oracle のパフォーマンス改善方法の手順 ....................................................................................................... 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

待機イベント ................................................................................................................................................ 5-3

時間モデル統計 ............................................................................................................................................ 5-3Active Session History（ASH） ................................................................................................................. 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-13AWR データのロード ............................................................................................................................... 5-14

自動ワークロード・リポジトリ・ビューの使用 .......................................................................................... 5-15

自動ワークロード・リポジトリ・レポートの生成 ...................................................................................... 5-16

awrrpt.sql レポートの実行 ....................................................................................................................... 5-16

awrrpti.sql レポートの実行 ...................................................................................................................... 5-17awrsqrpt.sql レポートの実行 ................................................................................................................... 5-17awrsqrpi.sql レポートの実行 ................................................................................................................... 5-18awrddrpt.sql レポートの実行 .................................................................................................................. 5-18

awrddrpi.sql レポートの実行 .................................................................................................................. 5-19Active Session History レポートの生成 ......................................................................................................... 5-20

ashrpt.sql レポートの実行 ........................................................................................................................ 5-20

ashrpti.sql レポートの実行 ...................................................................................................................... 5-21

6 自動パフォーマンス診断自動パフォーマンス診断自動パフォーマンス診断自動パフォーマンス診断

Automatic Database Diagnostic Monitor の概要の概要の概要の概要 ................................................................................................. 6-2

Automatic Database Diagnostic Monitor .............................................................................................................. 6-3ADDM の分析結果 .............................................................................................................................................. 6-4

ADDM の例 .......................................................................................................................................................... 6-4

ADDM の設定 ...................................................................................................................................................... 6-5

ADDM を使用したデータベース・パフォーマンスの問題の診断 .............................................................. 6-6

addmrpt.sql を使用した ADDM の実行 .................................................................................................. 6-6DBMS_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

ページングの削減 ........................................................................................................................................ 7-5主メモリーへの SGA の格納 ..................................................................................................................... 7-5

個々のユーザーへの十分なメモリーの割当て ........................................................................................ 7-5構成の繰返し ........................................................................................................................................................ 7-6

バッファ・キャッシュの構成と使用方法バッファ・キャッシュの構成と使用方法バッファ・キャッシュの構成と使用方法バッファ・キャッシュの構成と使用方法 ................................................................................................................ 7-6

バッファ・キャッシュの効果的な使用 ............................................................................................................ 7-6

バッファ・キャッシュのサイズ設定 ................................................................................................................ 7-6

バッファ・キャッシュ・アドバイザの統計 ............................................................................................ 7-6

V$DB_CACHE_ADVICE の使用 .............................................................................................................. 7-6バッファ・キャッシュ・ヒット率の計算 ................................................................................................ 7-8

バッファ・キャッシュ・アドバイザ統計の解釈および使用方法 ................................................................ 7-9

バッファ・キャッシュに割り当てられたメモリーの増加 .................................................................. 7-10

バッファ・キャッシュに割り当てられたメモリーの削減 .................................................................. 7-10複数バッファ・プールについて ...................................................................................................................... 7-11

大きいセグメントへのランダム・アクセス .......................................................................................... 7-11

Oracle Real Application Cluster のインスタンス ................................................................................ 7-11複数バッファ・プールの使用方法 .......................................................................................................... 7-12

V$DB_CACHE_ADVICE 内のバッファ・プール・データ ........................................................................ 7-12

バッファ・プール・ヒット率 .......................................................................................................................... 7-12

プール内に多くのバッファを持つセグメントの判断 .................................................................................. 7-13

KEEP プール ....................................................................................................................................................... 7-14

RECYCLE プール .............................................................................................................................................. 7-15

共有プールとラージ・プールの構成および使用方法共有プールとラージ・プールの構成および使用方法共有プールとラージ・プールの構成および使用方法共有プールとラージ・プールの構成および使用方法 .......................................................................................... 7-15共有プールの概念 .............................................................................................................................................. 7-16

ディクショナリ・キャッシュの概念 ...................................................................................................... 7-16

ライブラリ・キャッシュの概念 .............................................................................................................. 7-16SQL 共有基準 ............................................................................................................................................. 7-17

共有プールの効果的な使用方法 ...................................................................................................................... 7-18

共有カーソル .............................................................................................................................................. 7-18単一のユーザーのログインおよび修飾表の参照 .................................................................................. 7-19PL/SQL の使用方法 .................................................................................................................................. 7-19DDL の実行の回避 .................................................................................................................................... 7-19

キャッシュ順序番号 .................................................................................................................................. 7-20カーソルのアクセスおよび管理 .............................................................................................................. 7-20

OCI による解析コールの低減 ......................................................................................................... 7-20

Oracle プリコンパイラによる解析コールの低減 ......................................................................... 7-20SQLJ による解析コールの低減 ........................................................................................................ 7-21JDBC による解析コールの低減 ....................................................................................................... 7-21

Oracle Forms による解析コールの低減 ......................................................................................... 7-21共有プールのサイズ設定 .................................................................................................................................. 7-21

共有プール : ライブラリ・キャッシュの統計 ....................................................................................... 7-21V$LIBRARYCACHE ................................................................................................................................. 7-22

共有プールのアドバイザ統計 .................................................................................................................. 7-23V$SHARED_POOL_ADVICE ......................................................................................................... 7-23V$LIBRARY_CACHE_MEMORY .................................................................................................. 7-23

V$JAVA_POOL_ADVICE および V$JAVA_LIBRARY_CACHE_MEMORY .......................... 7-23共有プール : ディクショナリ・キャッシュの統計 ............................................................................... 7-24

v

共有プール統計の解釈 ...................................................................................................................................... 7-25

メモリー割当ての増加 .............................................................................................................................. 7-25ライブラリ・キャッシュへの追加のメモリー割当て .................................................................. 7-25

データ・ディクショナリ・キャッシュへの追加のメモリーの割当て ...................................... 7-25メモリー割当ての減少 .............................................................................................................................. 7-26

ラージ・プールの使用 ...................................................................................................................................... 7-26

共有サーバー・アーキテクチャでのラージ・プールと共有プールのチューニング ...................... 7-26共有サーバーの UGA 記憶域のための効果的な設定の判別 ....................................................... 7-27V$SESSTAT ビューでのシステム統計のチェック ....................................................................... 7-27

PRIVATE_SGA の設定による各ユーザー・セッションのメモリー使用量の制限 ................. 7-283 層の接続でのメモリー使用の低減 ............................................................................................... 7-28

CURSOR_SPACE_FOR_TIME の使用 ............................................................................................................ 7-29

セッション・カーソルのキャッシュ .............................................................................................................. 7-29

予約プールの構成 .............................................................................................................................................. 7-30

SHARED_POOL_RESERVED_SIZE の使用 .......................................................................................... 7-30SHARED_POOL_RESERVED_SIZE が小さすぎる場合 ...................................................................... 7-31

SHARED_POOL_RESERVED_SIZE が大きすぎる場合 ...................................................................... 7-31SHARED_POOL_SIZE が小さすぎる場合 ............................................................................................. 7-31

除去防止のためのラージ・オブジェクトの保存 .......................................................................................... 7-31

既存のアプリケーション用の CURSOR_SHARING .................................................................................... 7-32

類似 SQL 文 ................................................................................................................................................ 7-32CURSOR_SHARING ................................................................................................................................. 7-32CURSOR_SHARING を使用する場合 .................................................................................................... 7-33

接続の維持 .......................................................................................................................................................... 7-33

REDO ログ・バッファの構成および使用ログ・バッファの構成および使用ログ・バッファの構成および使用ログ・バッファの構成および使用 ............................................................................................................. 7-34ログ・バッファのサイズ設定 .......................................................................................................................... 7-35

ログ・バッファの統計 ...................................................................................................................................... 7-35

PGA メモリー管理メモリー管理メモリー管理メモリー管理 .................................................................................................................................................... 7-35自動 PGA メモリーの構成 ............................................................................................................................... 7-37

PGA_AGGREGATE_TARGET の初期設定 ........................................................................................... 7-37自動 PGA メモリー管理のパフォーマンスの監視 ............................................................................... 7-38

V$PGASTAT ...................................................................................................................................... 7-38V$PROCESS ....................................................................................................................................... 7-40

V$PROCESS_MEMORY ................................................................................................................... 7-40V$SQL_WORKAREA_HISTOGRAM ............................................................................................ 7-40V$SQL_WORKAREA_ACTIVE ...................................................................................................... 7-42

V$SQL_WORKAREA ....................................................................................................................... 7-42PGA_AGGREGATE_TARGET のチューニング ................................................................................... 7-44

V$PGA_TARGET_ADVICE ............................................................................................................. 7-44

PGA_AGGREGATE_TARGET のチューニング方法 ................................................................... 7-46V$PGA_TARGET_ADVICE_HISTOGRAM .................................................................................. 7-47

V$SYSSTAT および V$SESSTAT ............................................................................................................. 7-48OLAP_PAGE_POOL_SIZE の構成 ................................................................................................................. 7-48

vi

8 I/O 構成および設計構成および設計構成および設計構成および設計

I/O の理解の理解の理解の理解 ..................................................................................................................................................................... 8-2

I/O の基本構成の基本構成の基本構成の基本構成 ............................................................................................................................................................. 8-2オペレーティング・システムまたはハードウェアのストライプ化を使用したファイルのレイアウト ... 8-2

要求された I/O サイズ ............................................................................................................................... 8-3

I/O リクエストの同時実行性 .................................................................................................................... 8-3物理ストライプ境界とブロック・サイズ境界との位置合せ ................................................................ 8-4提案されたシステムの管理可能性 ............................................................................................................ 8-4

手動による I/O の分散 ....................................................................................................................................... 8-5

ファイルを分割する場合 .................................................................................................................................... 8-5

表、索引および TEMP 表領域 ................................................................................................................... 8-6REDO ログ・ファイル ............................................................................................................................... 8-6

アーカイブ REDO ログ .............................................................................................................................. 8-63 つの構成サンプル ............................................................................................................................................. 8-7

すべてのディスクにまたがったすべての内容のストライプ化 ............................................................ 8-7

異なるディスクへのアーカイブ・ログの移動 ........................................................................................ 8-7個別のディスクへの REDO ログの移動 .................................................................................................. 8-8

Oracle Managed Files ......................................................................................................................................... 8-8

Oracle Managed Files のチューニング .................................................................................................... 8-8データ・ブロック・サイズの選択 .................................................................................................................... 8-9

読込み ............................................................................................................................................................ 8-9書込み ............................................................................................................................................................ 8-9

ブロック・サイズの長所と短所 .............................................................................................................. 8-10

9 オペレーティング・システム・リソースオペレーティング・システム・リソースオペレーティング・システム・リソースオペレーティング・システム・リソース

オペレーティング・システムのパフォーマンスの問題の理解オペレーティング・システムのパフォーマンスの問題の理解オペレーティング・システムのパフォーマンスの問題の理解オペレーティング・システムのパフォーマンスの問題の理解 ............................................................................ 9-2

オペレーティング・システムのキャッシュの使用 ........................................................................................ 9-2

非同期 I/O .................................................................................................................................................... 9-3FILESYSTEMIO_OPTIONS 初期化パラメータ ...................................................................................... 9-3

メモリー使用量 .................................................................................................................................................... 9-3

バッファ・キャッシュの制限 .................................................................................................................... 9-3メモリー使用量に影響を与えるパラメータ ............................................................................................ 9-3

オペレーティング・システムのリソース・マネージャの使用 .................................................................... 9-4

オペレーティング・システムの問題の解決オペレーティング・システムの問題の解決オペレーティング・システムの問題の解決オペレーティング・システムの問題の解決 ............................................................................................................ 9-5UNIX ベースのシステムのパフォーマンスに関するヒント ........................................................................ 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-101 回のコールで複数の非同期 I/O を発行するリスト I/O インタフェース ............................. 9-10

オペレーティング・システムの新規プロセスの開始 .......................................................................... 9-10

10 パフォーマンス・ビューを使用したインスタンスのチューニングパフォーマンス・ビューを使用したインスタンスのチューニングパフォーマンス・ビューを使用したインスタンスのチューニングパフォーマンス・ビューを使用したインスタンスのチューニング

インスタンスのチューニング手順インスタンスのチューニング手順インスタンスのチューニング手順インスタンスのチューニング手順 .......................................................................................................................... 10-2問題の定義 .......................................................................................................................................................... 10-2

ホスト・システムの検査 .................................................................................................................................. 10-3

CPU の使用率 ............................................................................................................................................. 10-3Oracle 以外のプロセス ..................................................................................................................... 10-3

Oracle プロセス ................................................................................................................................. 10-3Oracle CPU 統計 ................................................................................................................................ 10-4CPU 統計の解釈 ................................................................................................................................. 10-4

I/O の問題の検出 ...................................................................................................................................... 10-4

ネットワーク .............................................................................................................................................. 10-5Oracle 統計の調査 ............................................................................................................................................. 10-5

統計収集のレベルの設定 .......................................................................................................................... 10-5

V$STATISTICS_LEVEL .................................................................................................................... 10-6待機イベント .............................................................................................................................................. 10-6待機イベント統計を含む動的パフォーマンス・ビュー ...................................................................... 10-6

システム統計 .............................................................................................................................................. 10-7V$ACTIVE_SESSION_HISTORY .................................................................................................... 10-8V$SYSSTAT ........................................................................................................................................ 10-8V$FILESTAT ....................................................................................................................................... 10-8

V$ROLLSTAT .................................................................................................................................... 10-8V$ENQUEUE_STAT ......................................................................................................................... 10-8V$LATCH ........................................................................................................................................... 10-8

セグメント・レベルの統計 ...................................................................................................................... 10-8変更の実装および測定 ...................................................................................................................................... 10-9

Oracle 統計の解釈統計の解釈統計の解釈統計の解釈 ..................................................................................................................................................... 10-9負荷の検査 .......................................................................................................................................................... 10-9

負荷の変更 .................................................................................................................................................. 10-9高いアクティビティ率 ............................................................................................................................ 10-10

待機イベント統計を使用したボトルネックへのドリルダウン ................................................................ 10-10

待機イベントおよび潜在的な原因の表 ........................................................................................................ 10-12

追加された統計情報 ........................................................................................................................................ 10-13

REDO ログ領域要求統計 ........................................................................................................................ 10-13

読取り一貫性 ............................................................................................................................................ 10-13継続行による表フェッチ ........................................................................................................................ 10-14解析関連の統計 ........................................................................................................................................ 10-14

待機イベント統計待機イベント統計待機イベント統計待機イベント統計 .................................................................................................................................................... 10-15

SQL*Net イベント ........................................................................................................................................... 10-16

SQL*Net message from client ................................................................................................................ 10-16ネットワーク・ボトルネック ........................................................................................................ 10-16

クライアント・プロセス上のリソース・ボトルネック ............................................................ 10-17SQL*Net message from dblink .............................................................................................................. 10-17SQL*Net more data to client .................................................................................................................. 10-17

viii

buffer busy waits ............................................................................................................................................. 10-18

原因 ............................................................................................................................................................ 10-18処置 ............................................................................................................................................................ 10-18

セグメント・ヘッダー .................................................................................................................... 10-18データ・ブロック ............................................................................................................................ 10-19UNDO ヘッダー .............................................................................................................................. 10-19

undo block ........................................................................................................................................ 10-19db file scattered read ....................................................................................................................................... 10-19

処置 ............................................................................................................................................................ 10-19

過剰な I/O の管理 ................................................................................................................................... 10-19不十分な I/O 分散 ................................................................................................................................... 10-20I/O を待機しているセッションで実行された SQL 文の検索 .......................................................... 10-20I/O を必要とするオブジェクトの検索 ................................................................................................ 10-20

db file sequential read .................................................................................................................................... 10-21

処置 ............................................................................................................................................................ 10-21direct path read および direct path read temp ........................................................................................... 10-22

原因 ............................................................................................................................................................ 10-22処置 ............................................................................................................................................................ 10-22

ディスクでのソート ........................................................................................................................ 10-22

全表スキャン .................................................................................................................................... 10-22ハッシュ領域サイズ ........................................................................................................................ 10-22

direct path write および direct path write temp ......................................................................................... 10-23

原因 ............................................................................................................................................................ 10-23処置 ............................................................................................................................................................ 10-23

enqueue（enq:）待機 ..................................................................................................................................... 10-23

ロックおよびロック・ホルダーの検索 ................................................................................................ 10-24

処置 ............................................................................................................................................................ 10-24ST エンキュー .................................................................................................................................. 10-24HW エンキュー ............................................................................................................................... 10-24

TM エンキュー ................................................................................................................................ 10-24TX エンキュー .................................................................................................................................. 10-25

events in wait class other ............................................................................................................................... 10-25

free buffer waits ............................................................................................................................................... 10-26

原因 ............................................................................................................................................................ 10-26処置 ............................................................................................................................................................ 10-26

書込み ................................................................................................................................................ 10-26

キャッシュが小さすぎる場合 ........................................................................................................ 10-26キャッシュが 1 つの DBWR に対して大きすぎる場合 ............................................................. 10-26

複数のデータベース・ライター（DBWR）・プロセスまたは I/O スレーブの検討 .................... 10-26

DB_WRITER_PROCESSES ............................................................................................................ 10-26DBWR_IO_SLAVES ........................................................................................................................ 10-27複数の DBWR プロセスと I/O スレーブの選択 ......................................................................... 10-27

ラッチ・イベント ............................................................................................................................................ 10-28

処置 ............................................................................................................................................................ 10-28例 : 現在待機されているラッチの検索 ................................................................................................. 10-28共有プールとライブラリ・キャッシュ・ラッチの競合 .................................................................... 10-29

非共有 SQL ....................................................................................................................................... 10-29再解析された共有可能な SQL ....................................................................................................... 10-30セッション別 .................................................................................................................................... 10-30

キャッシュ・バッファ LRU 連鎖 ................................................................................................. 10-31

ix

キャッシュ・バッファ連鎖 ............................................................................................................ 10-31行キャッシュ・オブジェクト ........................................................................................................ 10-31

log file parallel write ....................................................................................................................................... 10-31

library cache pin .............................................................................................................................................. 10-32library cache lock ............................................................................................................................................. 10-32log buffer space ................................................................................................................................................ 10-32

log file switch ................................................................................................................................................... 10-32

処置 ............................................................................................................................................................ 10-32log 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

チューニング中に収集する情報 .............................................................................................................. 11-4自動自動自動自動 SQL チューニング機能チューニング機能チューニング機能チューニング機能 .................................................................................................................................... 11-5効率的な効率的な効率的な効率的な SQL 文の開発文の開発文の開発文の開発 ............................................................................................................................................ 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-16RETURNING 句を持つ DML の使用 ................................................................................................... 11-17

1 つの文での必要なすべてのデータの変更 ......................................................................................... 11-17

12 自動自動自動自動 SQL チューニングチューニングチューニングチューニング

自動自動自動自動 SQL チューニングの概要チューニングの概要チューニングの概要チューニングの概要 ............................................................................................................................... 12-2

問合せオプティマイザのモード ...................................................................................................................... 12-2

標準モード .................................................................................................................................................. 12-2チューニング・モード .............................................................................................................................. 12-2

チューニング分析のタイプ .............................................................................................................................. 12-3

統計分析 ...................................................................................................................................................... 12-3SQL プロファイリング ............................................................................................................................. 12-3アクセス・パス分析 .................................................................................................................................. 12-4

SQL 構造分析 ............................................................................................................................................. 12-4SQL チューニング・アドバイザチューニング・アドバイザチューニング・アドバイザチューニング・アドバイザ ............................................................................................................................ 12-5

入力ソース .......................................................................................................................................................... 12-5

チューニング・オプション .............................................................................................................................. 12-6

アドバイザ出力 .................................................................................................................................................. 12-6

SQL チューニング・アドバイザ API の使用方法 ........................................................................................ 12-6

SQL チューニング・タスクの作成 ......................................................................................................... 12-7SQL チューニング・タスクの実行 ......................................................................................................... 12-8SQL チューニング・タスクのステータスのチェック ......................................................................... 12-8SQL チューニング・アドバイザの進捗のチェック ............................................................................. 12-8

SQL チューニング・タスクの結果の表示 ............................................................................................. 12-9SQL チューニング・タスクに関するその他の操作 ............................................................................. 12-9

SQL チューニング・セットチューニング・セットチューニング・セットチューニング・セット .................................................................................................................................... 12-9

SQL チューニング・セットの作成 ............................................................................................................... 12-11

SQL チューニング・セットのロード ........................................................................................................... 12-11

SQL チューニング・セットの内容の表示 ................................................................................................... 12-11

SQL チューニング・セットの変更 ............................................................................................................... 12-12

SQL チューニング・セットの転送 ............................................................................................................... 12-12

SQL チューニング・セットの削除 ............................................................................................................... 12-13

SQL チューニング・セットに対するその他の操作 ................................................................................... 12-13

SQL プロファイルプロファイルプロファイルプロファイル ................................................................................................................................................... 12-13SQL プロファイルの受入れ ........................................................................................................................... 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

大量データにアクセスする場合に全表スキャンの方が高速になる理由 ........................................ 13-14オプティマイザが全表スキャンを使用する場合 ................................................................................ 13-14

索引の欠落 ........................................................................................................................................ 13-14大量のデータ .................................................................................................................................... 13-15小さい表 ............................................................................................................................................ 13-15

高い並列度 ........................................................................................................................................ 13-15全表スキャンのヒント ............................................................................................................................ 13-15パラレル問合せの実行 ............................................................................................................................ 13-15

ROWID スキャン ............................................................................................................................................. 13-16

オプティマイザが ROWID を使用する場合 ........................................................................................ 13-16索引スキャン .................................................................................................................................................... 13-16

ブロックの I/O（行ではなく）の想定 ................................................................................................ 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

xii

クラスタ・アクセス ........................................................................................................................................ 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

ネステッド・ループ外部結合 ................................................................................................................ 13-27ハッシュ結合外部結合 ............................................................................................................................ 13-28

ソート / マージ外部結合 ....................................................................................................................... 13-29完全外部結合 ............................................................................................................................................ 13-29

14 オプティマイザ統計の管理オプティマイザ統計の管理オプティマイザ統計の管理オプティマイザ統計の管理

統計について統計について統計について統計について .............................................................................................................................................................. 14-2自動統計収集自動統計収集自動統計収集自動統計収集 .............................................................................................................................................................. 14-3

GATHER_STATS_JOB ...................................................................................................................................... 14-3

自動統計収集を使用可能にする方法 .............................................................................................................. 14-3

統計収集時の考慮事項 ...................................................................................................................................... 14-4

手動統計を使用する場合 .......................................................................................................................... 14-4前のバージョンの統計のリストア .......................................................................................................... 14-5

統計のロック .............................................................................................................................................. 14-5手動統計収集手動統計収集手動統計収集手動統計収集 .............................................................................................................................................................. 14-5

DBMS_STATS プロシージャによる統計の収集 ........................................................................................... 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-5SQL アクセス・アドバイザの使用方法アクセス・アドバイザの使用方法アクセス・アドバイザの使用方法アクセス・アドバイザの使用方法 ................................................................................................................ 17-6

SQL アクセス・アドバイザの使用手順 ......................................................................................................... 17-6

SQL アクセス・アドバイザの使用に必要な権限 ......................................................................................... 17-7

タスクとテンプレートの設定 .......................................................................................................................... 17-7

タスクの作成 .............................................................................................................................................. 17-7テンプレートの使用方法 .......................................................................................................................... 17-8テンプレートの作成 .................................................................................................................................. 17-8

ワークロードの管理 .......................................................................................................................................... 17-9

ワークロード・オブジェクト .................................................................................................................. 17-9ワークロードの使用 .................................................................................................................................. 17-9タスクとワークロードのリンク ............................................................................................................ 17-10

ワークロードの内容の定義 .................................................................................................................... 17-10SQL チューニング・セット ........................................................................................................... 17-11ユーザー定義のワークロードのロード ........................................................................................ 17-11

SQL キャッシュのワークロードのロード ................................................................................... 17-12仮想ワークロードの使用方法 ........................................................................................................ 17-13Oracle Database 9i サマリー・アドバイザのワークロードの使用方法 .................................. 17-14SQL アクセス・アドバイザのワークロードのパラメータ ....................................................... 17-14

ワークロードへの SQL 文の追加 .......................................................................................................... 17-15ワークロードの SQL 文の削除 .............................................................................................................. 17-15ワークロードの SQL 文の変更 .............................................................................................................. 17-16

xv

ワークロードのメンテナンス ................................................................................................................ 17-16ワークロード属性の設定 ................................................................................................................ 17-16ワークロードのリセット ................................................................................................................ 17-17

ワークロードとタスク間のリンクの削除 .................................................................................... 17-17ワークロードの削除 ................................................................................................................................ 17-17

推奨事項の処理 ................................................................................................................................................ 17-17

推奨オプション ........................................................................................................................................ 17-18評価モード ................................................................................................................................................ 17-19推奨事項の生成 ........................................................................................................................................ 17-19

EXECUTE_TASK プロシージャ .................................................................................................... 17-19推奨事項の表示 ........................................................................................................................................ 17-19SQL ワークロードのジャーナル ........................................................................................................... 17-23推奨プロセスの停止 ................................................................................................................................ 17-23

タスクへの割込み ............................................................................................................................ 17-23タスクの取消 .................................................................................................................................... 17-24

推奨事項のマーキング ............................................................................................................................ 17-24

推奨事項の変更 ........................................................................................................................................ 17-24SQL スクリプトの生成 ........................................................................................................................... 17-25推奨事項が必要なくなった場合 ............................................................................................................ 17-26

クイック・チューニングの実行 .................................................................................................................... 17-27

タスクの管理 .................................................................................................................................................... 17-27

タスク属性の更新 .................................................................................................................................... 17-27タスクの削除 ............................................................................................................................................ 17-28

DAYS_TO_EXPIRE パラメータの設定 ................................................................................................ 17-28SQL アクセス・アドバイザの定数の使用方法 ........................................................................................... 17-28

SQL アクセス・アドバイザの使用例 ........................................................................................................... 17-29

ユーザー定義のワークロードの推奨事項 ............................................................................................ 17-29タスク・テンプレートを使用した推奨事項の生成 ............................................................................ 17-31SQL キャッシュからのワークロードのフィルタリング ................................................................... 17-32索引およびマテリアライズド・ビューの現在の使用状況の評価 .................................................... 17-33

高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング ................ 17-34DBMS_ADVISOR.TUNE_MVIEW プロシージャ ...................................................................................... 17-35

TUNE_MVIEW の構文と操作 ............................................................................................................... 17-35

TUNE_MVIEW の出力結果へのアクセス ........................................................................................... 17-36USER_TUNE_MVIEW ビューおよび DBA_TUNE_MVIEW ビュー ...................................... 17-36DBMS_ADVISOR 関数およびプロシージャによるスクリプトの生成 ................................... 17-36

適化されたサブマテリアライズド・ビューによる高速リフレッシュの有効化 ........................ 17-41

18 プラン・スタビリティの使用方法プラン・スタビリティの使用方法プラン・スタビリティの使用方法プラン・スタビリティの使用方法

実行計画を保持するためのプラン・スタビリティの使用実行計画を保持するためのプラン・スタビリティの使用実行計画を保持するためのプラン・スタビリティの使用実行計画を保持するためのプラン・スタビリティの使用 .................................................................................. 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-3EXPLAIN PLAN の制限事項 ........................................................................................................................... 19-4

PLAN_TABLE 出力表出力表出力表出力表 .............................................................................................................................................. 19-4

EXPLAIN PLAN の実行の実行の実行の実行 .......................................................................................................................................... 19-5EXPLAIN PLAN での文の指定 ....................................................................................................................... 19-5

EXPLAIN PLAN での別の表の指定 ............................................................................................................... 19-5

PLAN_TABLE 出力の表示出力の表示出力の表示出力の表示 ...................................................................................................................................... 19-6PLAN_TABLE 出力のカスタマイズ ............................................................................................................... 19-6

EXPLAIN PLAN 出力の読み方出力の読み方出力の読み方出力の読み方 .............................................................................................................................. 19-7EXPLAIN PLAN によるパラレル実行の表示によるパラレル実行の表示によるパラレル実行の表示によるパラレル実行の表示 ...................................................................................................... 19-8

EXPLAIN PLAN によるパラレル問合せの表示 ........................................................................................... 19-9

EXPLAIN PLAN によるビットマップ索引の表示によるビットマップ索引の表示によるビットマップ索引の表示によるビットマップ索引の表示 ............................................................................................ 19-10EXPLAIN PLAN によるパーティション・オブジェクトの表示によるパーティション・オブジェクトの表示によるパーティション・オブジェクトの表示によるパーティション・オブジェクトの表示 .................................................................... 19-10

EXPLAIN PLAN によるレンジ・パーティション化およびハッシュ・パーティション化の

表示の例 ............................................................................................................................................................ 19-11

ハッシュ・パーティション化の計画 .................................................................................................... 19-12コンポジット・パーティション・オブジェクトでのプルーニング情報の例 ........................................ 19-12

パーシャル・パーティション・ワイズ結合の例 ........................................................................................ 19-14

フル・パーティション・ワイズ結合の例 .................................................................................................... 19-16

INLIST ITERATOR および EXPLAIN PLAN の例 .................................................................................... 19-16

IN リスト列が索引列である場合 .......................................................................................................... 19-17IN リスト列が索引でありパーティション列である場合 .................................................................. 19-17

IN リスト列がパーティション列である場合 ...................................................................................... 19-17ドメイン索引および EXPLAIN PLAN の例 ................................................................................................ 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-7trcsess の構文 ..................................................................................................................................................... 20-7

trcsess の出力例 ................................................................................................................................................. 20-8

SQL トレースとトレースとトレースとトレースと TKPROF についてについてについてについて ...................................................................................................................... 20-8SQL トレース機能について ............................................................................................................................. 20-8

TKPROF について ............................................................................................................................................. 20-9

SQL トレース機能とトレース機能とトレース機能とトレース機能と TKPROF の使用方法の使用方法の使用方法の使用方法 ........................................................................................................ 20-10

手順 1: トレース・ファイル管理用の初期化パラメータの設定 ............................................................... 20-10

手順 2: SQL トレース機能を使用可能にする方法 ...................................................................................... 20-12

手順 3: TKPROF によるトレース・ファイルのフォーマット .................................................................. 20-13

TKPROF の出力例 ................................................................................................................................... 20-13TKPROF の構文 ....................................................................................................................................... 20-14TKPROF 文の例 ....................................................................................................................................... 20-16

TKPROF の例 1 ................................................................................................................................ 20-16TKPROF の例 2 ................................................................................................................................ 20-16

手順 4: TKPROF 出力の解釈 .......................................................................................................................... 20-17

TKPROF の表形式の統計 ....................................................................................................................... 20-17

行ソースの操作 ........................................................................................................................................ 20-18待機イベント情報 .................................................................................................................................... 20-19統計の精度の解釈 .................................................................................................................................... 20-19

再帰的コールについて ............................................................................................................................ 20-19TKPROF のライブラリ・キャッシュ・ミス ....................................................................................... 20-19SQL トレースでの文の切捨て ............................................................................................................... 20-20

TKPROF での SQL 文を発行するユーザーの識別 .............................................................................. 20-20TKPROF の実行計画 ............................................................................................................................... 20-20チューニングする文の決定 .................................................................................................................... 20-20

手順 5: SQL トレース機能統計の格納 .......................................................................................................... 20-21

TKPROF による出力 SQL スクリプトの生成 ...................................................................................... 20-21TKPROF による出力 SQL スクリプトの編集 ...................................................................................... 20-21出力表の問合せ ........................................................................................................................................ 20-22

TKPROF の解釈における誤りの回避の解釈における誤りの回避の解釈における誤りの回避の解釈における誤りの回避 .................................................................................................................. 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

アクティブなワークロードの取得の監視 ............................................................................................ 21-10アクティブなワークロードの取得の停止 ............................................................................................ 21-11

完了したワークロードの取得の管理 .................................................................................................... 21-12API を使用したデータベース・ワークロードの取得 ................................................................................ 21-13

ワークロード・フィルタの追加と削除 ................................................................................................ 21-13ワークロードの取得の開始 .................................................................................................................... 21-14

ワークロードの取得の停止 .................................................................................................................... 21-14ワークロードの取得に関する AWR データのエクスポート ............................................................ 21-15

ビューを使用したワークロードの取得の監視 ............................................................................................ 21-15

ワークロードの取得の分析ワークロードの取得の分析ワークロードの取得の分析ワークロードの取得の分析 .................................................................................................................................... 21-15Enterprise Manager を使用したワークロードの取得レポートの生成 ................................................... 21-15

API を使用したワークロードの取得レポートの生成 ................................................................................ 21-16

ワークロードの取得レポートの使用 ............................................................................................................ 21-17

22 SQL パフォーマンス・アナライザパフォーマンス・アナライザパフォーマンス・アナライザパフォーマンス・アナライザ

SQL パフォーマンス・アナライザの概要パフォーマンス・アナライザの概要パフォーマンス・アナライザの概要パフォーマンス・アナライザの概要 ............................................................................................................ 22-2SQL ワークロードの取得ワークロードの取得ワークロードの取得ワークロードの取得 ........................................................................................................................................ 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.jphttp://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 章「データベース・リプレイ」を参照してください。

� 拡張された 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 プロファイル

また、DBMS_SQLTUNEパッケージは、リテラルのテキスト値をバインド変数に正規化することで、SQL プロファイルを共有し、リテラル値でのみ異なるテキストを持つ SQL を許可する機能も提供します。12-14 ページの「SQL プロファイルの受入れ」を参照してください。

注意注意注意注意 : 現在、このリリースでサポートされているのは、ワークロードの取得のみです。 Oracle Database 11g リリース 1（11.1）以降のリリースでは、取得されたワークロードを前処理してリプレイできます。

注意注意注意注意 : 現在、このリリースでサポートされているのは、SQL ワークロードの取得のみです。 Oracle Database 11g リリース 1（11.1）以降のリリースでは、取得した 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 には、次の自動パフォーマンス・チューニング機能があります。

� 自動ワークロード・リポジトリ（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）の 適化、セグメントの縮小および

関連項目関連項目関連項目関連項目 :

� 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リファレンス』を参照してください。

パフォーマンス・チューニングの概要 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操作のパフォーマンスとの間のバランスを取る必要があるため、索引の設計は十分に検討する必要があります。

索引内のシリアライズ索引内のシリアライズ索引内のシリアライズ索引内のシリアライズ順序またはタイムスタンプを使用して索引付きキー値を生成すると、データベースのホット・スポット問題が生じ、応答時間やスループットに影響を与える場合があります。これは、通常、キーが単調に増加することによるもので、結果として索引は適度に増加します。この問題を回避するには、索引の全範囲にわたって挿入するキーを生成します。これによって、スケーラブルで領域を効率よく使用するバランスの取れた索引になります。これには、逆キー索引を使用するか、接頭辞および順序値にサイクル順序を使用します。

索引内の列の順序付け索引内の列の順序付け索引内の列の順序付け索引内の列の順序付け設計者は、索引作成の規則を柔軟に定義する必要があります。状況に応じて、次のいずれかの方法で索引内のキーに順序を付けます。

� 選択頻度の高い列から順序を付けます。これによって、必要な ROWID に 小限の I/O でも速くアクセスできるため、通常はこの方法を使用します。この方法は、主として主

キーや選択頻度の高いレンジ・スキャンに使用します。

� 列に順序を付け、データをクラスタ化またはソートして I/O を削減します。大規模なレンジ・スキャンでは、通常、選択頻度の低い順に列に順序を付けるか、取り出す順にデータをソートすると、I/O を削減できます。第 15 章「索引およびクラスタの使用方法」を参照してください。

関連項目関連項目関連項目関連項目 : 索引の使用を監視する方法の詳細は、『Oracle Database 管理者ガイド』を参照してください。

2-12 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 SupportedNo Parsing all statements 270 Soft Parsing all statements 150Hard Parsing all statements 60Re-Connecting for each Transaction 30

このテストは、4 台の CPU を搭載したシステムで実行されました。システム上の CPU の数が増えると、差異も大きくなります。SQL 文の 適化の詳細は、第 11 章「SQL チューニングの概要」を参照してください。

アプリケーションの実装アプリケーションの実装アプリケーションの実装アプリケーションの実装開発環境およびプログラミング言語の選択は、開発チームのスキルと、アプリケーションの指定時に決定したアーキテクチャにより決定します。ただし、簡単なパフォーマンス管理規則がいくつかあり、これに従うと、スケーラブルで高パフォーマンスのアプリケーションの実現につながります。

1. ソフトウェア・コンポーネントに適した開発環境を選択し、その環境によってパフォーマンスに関する設計が制限されないようにしてください。設計が制限される場合は、選択した言語または環境が不適切であるといえます。

� ユーザー・インタフェース

プログラミング・モデルには、HTML 生成からウィンドウ・システムの直接コールまで様々なモデルがあります。開発方法では、ユーザー・インタフェース・コードの応答時間に重点を置く必要があります。HTML または Java をネットワークで送信する場合は、ネットワーク通信量や対話を 小限に抑えるようにしてください。

� ビジネス・ロジック

Java や PL/SQL などのインタープリタ型言語は、ビジネス・ロジックのエンコードには理想的です。これらの言語は完全に移植可能であるため、ロジックのアップグレードが比較的簡単にできます。どちらの言語も構文が豊富で、読みやすく解析しやすいコードを作成できます。ビジネス・ロジックで複雑な数学関数が必要な場合は、コンパイラ型バイナリ言語が必要になる場合があります。 ビジネス・ロジック・コードは、クライアント・システム、アプリケーション・サーバーおよびデータベース・サーバーに配置できます。ただし、アプリケーション・サーバーに配置するのが も一般的です。

� ユーザー要求とリソース割当て

これがプログラミング言語によって影響を受けることはほとんどありませんが、データベース接続やカーソル管理を隠すツールや第 4 世代言語では、非効率的なメカニズムが使用されることがあります。このようなツールや環境を評価するときは、データベース接続モデルおよびカーソルやバインド変数の使用方法をチェックしてください。

� データ管理とトランザクション

これに関しては、プログラミング言語による影響はほとんどありません。

2. ソフトウェア・コンポーネントを実装するときは、その機能を実装するようにし、他のコンポーネントに関連付けられている機能は実装しないでください。他のコンポーネントの機能を実装すると、設計や実装が 適でなくなります。これはすべてのコンポーネントに当てはまります。

3. 機能のギャップをそのまま放置したり、検討中のソフトウェア・コンポーネントを設計、実装またはテストで使用しないでください。多くの場合、ギャップは、アプリケーションを展開するか、実際のボリュームでテストするまで検出されません。このギャップは、通常、アーキテクチャまたは当初のシステム仕様が不適切であることを示します。データ・アーカイブ / パージ・モジュールは、初期のシステム設計、作成および実装時には も無視されやすいモジュールです。

2-14 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 つの方法が一般的です。

� ビッグ・バン・アプローチ : 全ユーザーが一度に新しいシステムに移行します。

� トリクル・アプローチ : ユーザーは既存のシステムから新しいシステムに徐々に移行します。

いずれの方式にもメリットとデメリットがあります。ビッグ・バン・アプローチでは、必要な規模でアプリケーションを十分にテストしておく必要がありますが、旧システムは完全に使用されなくなるため、旧システムからのデータの変換と旧システムとの同期が 小限で済みます。トリクル・アプローチでは、ワークロードの増加に伴い拡張性の問題をデバッグできますが、移行中に旧システムとの間でデータを相互に移行する必要性が発生することがあります。

いずれの方法も、それぞれ移行実施中にシステムの停止につながるリスクがあるため、どちらかを推奨することは困難です。トリクル・アプローチでは、実際のユーザーが新しいアプリケーションに移行するにつれてユーザー・プロファイルを作成できるので、システムを再構成しても、その影響を受けるのは移行済ユーザーのみです。この方式は、初期の段階で移行したユーザーの作業に影響を与えますが、サポート・サービスの負荷は限定されます。これは、スケジュール外の停止が発生しても、影響を受けるユーザーの割合が小さいことを意味します。

新規アプリケーションのロールアウト方法は、ビジネスごとに判断してください。採用する方式には、それぞれ固有の長所と短所があります。テストを重ねて、そのテストから得られた知識が増えるほど、 善のロールアウト方式を判断できるようになります。

パフォーマンス・チェックリストパフォーマンス・チェックリストパフォーマンス・チェックリストパフォーマンス・チェックリストロールアウト・プロセスを支援するため、タスク・リストを作成してください。リスト上のタスクを正しく実行すると、本番で良好なパフォーマンスが得られる可能性が高くなり、問題が発生した場合にもアプリケーションをすばやくデバッグできます。

1. 本番データベース用の制御ファイルを作成するときは、MAXINSTANCES、MAXDATAFILES、MAXLOGFILES、MAXLOGMEMBERSおよび MAXLOGHISTORYをロールアウトで予測されるよりも大きい値に設定することで、データベースの成長に対応します。この結果、ディスク領域の使用量が増えて制御ファイルも大きくなりますが、後でこれらを緊急に拡張する必要が生じたときに時間を節約できます。

2. ブロック・サイズをアプリケーションの開発時に使用した値に設定します。本番同様のデータ量でテストが完了し、現在の SQL 実行計画が正しい場合は、スキーマ統計を開発 /テスト環境から本番データベースにエクスポートします。

3. 小限の初期化パラメータを設定します。他のパラメータはデフォルトのままにしておくのが理想的です。チューニングをさらに行う必要がある場合は、システムの負荷が少ないときに示されます。初期構成でのパラメータの設定の詳細は、第 4 章「パフォーマンスを考慮したデータベースの構成」を参照してください。

4. データベース・オブジェクトの記憶領域オプションを設定して、ブロック競合の管理に備えます。INSERT/UPDATE/DELETE操作が頻繁に発生する表と索引を作成するには、自動セグメント領域管理を使用する必要があります。ロールバック・セグメントの競合を回避するには、自動 UNDO 管理を使用する必要があります。UNDO セグメントと一時セグメントの詳細は、第 4 章「パフォーマンスを考慮したデータベースの構成」を参照してください。

5. すべての SQL 文が 適であることを検証し、そのリソース使用を把握します。

6. データベースに接続しているミドルウェアとプログラムの接続管理が効率的であることと、ログオン / ログオフが繰り返されていないことを確認します。

2-20 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 統計が示されます。

アプリケーションが 適で、SQL が効率的に実行されている場合は、一部の作業をピーク時以外に再スケジュールするか、大型のシステムの使用を検討してください。

3. この段階で、CPU リソースが完全には使用されていないのに、システム・パフォーマンスがまだ不十分ですか ?

不十分な場合は、サーバー内にシリアライズされた、スケーラブルでない動作があります。サーバーから WAIT_EVENTS統計を取得し、 大のシリアライズ・ポイントを確認します。シリアライズ・ポイントがない場合、問題はデータベースの外にある可能性が高く、これを重点的に調査する必要があります。WAIT_EVENTSをなくすには、アプリケーションSQL を修正し、データベース・パラメータをチューニングします。このプロセスは非常に反復的で、WAIT_EVENTSを系統的にドリルダウンして、シリアライズ・ポイントを取り除く技術を必要とします。

関連項目関連項目関連項目関連項目 : V$SQLおよび V$SQLSTATSの詳細は、『Oracle Databaseリファレンス』を参照してください。

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 章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。

4. 緊急時の処理を適用して、システムを安定化します。これには、アプリケーションの一部をオフラインにする処理や、システムに適用できるワークロードを制限する処理が含まれます。また、システムの再起動や処理中のジョブの停止も含まれることがあります。これらの処理は、当然、サービス・レベルに影響を与えることになります。

5. システムが安定していることを確認します。システムを変更したり制限した場合は、システムが安定したことを確認し、データベースに関する参照統計情報を収集します。次に、このマニュアルの前の章で説明した厳密なパフォーマンス改善方法に従って、すべての機能とユーザーをシステムに戻します。このプロセスを完了するには、アプリケーションの大幅な再設計が必要になることがあります。

3-8 Oracle Database パフォーマンス・チューニング・ガイド

第第第第 III 部部部部

インスタンスのパフォーマンスの最適化インスタンスのパフォーマンスの最適化インスタンスのパフォーマンスの最適化インスタンスのパフォーマンスの最適化

第 III 部では、Oracle インスタンスのパフォーマンスを 適化するために、データベース・システムの様々な要素をチューニングする方法について説明します。

第 III 部には次の章が含まれます。

� 第 4 章「パフォーマンスを考慮したデータベースの構成」

� 第 5 章「自動パフォーマンス統計」

� 第 6 章「自動パフォーマンス診断」

� 第 7 章「メモリーの構成と使用方法」

� 第 8 章「I/O 構成および設計」

� 第 9 章「オペレーティング・システム・リソース」

� 第 10 章「パフォーマンス・ビューを使用したインスタンスのチューニング」

パフォーマンスを考慮したデータベースの

4

パフォーマンスを考慮したデータベースの構成パフォーマンスを考慮したデータベースの構成パフォーマンスを考慮したデータベースの構成パフォーマンスを考慮したデータベースの構成

この章では、パフォーマンスを考慮してデータベースを構成するための、オラクル社の方法論の概要を説明しています。Oracle データベース・インスタンスのパフォーマンスの修正は後でも可能ですが、データベースの初期構成をニーズにあわせて適切に行うことによって、パフォーマンス目標の多くは達成可能です。

この章には次の項があります。

� 初期インスタンス構成のパフォーマンスの考慮事項

� 適切なパフォーマンスを得る表の作成とメンテナンス

� 共有サーバーのパフォーマンスの考慮事項

構成 4-1

初期インスタンス構成のパフォーマンスの考慮事項

初期インスタンス構成のパフォーマンスの考慮事項初期インスタンス構成のパフォーマンスの考慮事項初期インスタンス構成のパフォーマンスの考慮事項初期インスタンス構成のパフォーマンスの考慮事項この項では、パフォーマンスに重要な影響を与えるデータベース・インスタンスの初期構成オプションについて説明します。

データベース・コンフィギュレーション・アシスタント（DBCA）を使用してデータベースを作成する場合、提供されるシード・データベースには必要な基本的初期化パラメータが組み込まれており、この章で説明するパフォーマンス推奨事項を満たしています。

初期化パラメータ初期化パラメータ初期化パラメータ初期化パラメータ実行中の Oracle インスタンスは、初期化パラメータ・ファイルで設定される初期化パラメータを使用して構成されます。これらのパラメータは、パフォーマンスへの影響を含め、実行中のインスタンスの動作に影響を与えます。一般的に、関連する設定をほとんど持たない非常に単純な初期化ファイルでは、ほとんどの状況に対応できます。表 4-2 に示すきわめて少数のパラメータを除き、初期化ファイルはパフォーマンス・チューニングを行う 初の場所ではありません。

表 4-1 に、 小初期化ファイルで必要なパラメータを示します。これらのパラメータは必須ですが、パフォーマンスに影響を与えません。

表 4-2 に、パフォーマンスの考慮事項として設定する、 も重要なパラメータを示します。

関連項目関連項目関連項目関連項目 :

� データベース・コンフィギュレーション・アシスタントを使用したデータベース作成の詳細は、『Oracle Database 2 日でデータベース管理者』を参照してください。

� データベース作成プロセスの詳細は、『Oracle Database 管理者ガイド』を参照してください。

表表表表 4-1 パフォーマンスに影響を与えない必要な初期化パラメータパフォーマンスに影響を与えない必要な初期化パラメータパフォーマンスに影響を与えない必要な初期化パラメータパフォーマンスに影響を与えない必要な初期化パラメータ

パラメータパラメータパラメータパラメータ 説明説明説明説明

DB_NAME データベースの名前。これは、環境変数 ORACLE_SIDに一致する

必要があります。

DB_DOMAIN インターネット・ドット表記法による、データベースの場所。

OPEN_CURSORS 1 セッション当たりのカーソル（アクティブな SQL 文）の 大数

に対する制限。設定はアプリケーションにより異なり、推奨値は500 です。

CONTROL_FILES 異なるディスク・ドライブ上に少なくとも 2 つのファイルを含め

るように設定して、制御ファイルの消失による障害を防ぎます。

DB_FILES データベースに割り当てることのできるファイルの 大数に設定します。

関連項目関連項目関連項目関連項目 : 初期化パラメータの管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

表表表表 4-2 パフォーマンスに影響を与える重要な初期化パラメータパフォーマンスに影響を与える重要な初期化パラメータパフォーマンスに影響を与える重要な初期化パラメータパフォーマンスに影響を与える重要な初期化パラメータ

パラメータパラメータパラメータパラメータ 説明説明説明説明

COMPATIBLE 互換性を維持しておく Oracle サーバーのリリースを指定します。

このパラメータを使用すると、新しい機能を自分の環境でテストせずに、ただちに本番システムで新しいリリースで改善された機能を利用できるようになります。アプリケーションが Oracle の特定の

リリース用に設計されていて、実際にはそれ以降のリリースのOracle をインストールする場合は、このパラメータをアプリケー

ション設計時のリリースに設定してください。

4-2 Oracle Database パフォーマンス・チューニング・ガイド

初期インスタンス構成のパフォーマンスの考慮事項

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 使用量を簡単にチューニン

DB_BLOCK_SIZE データベース・ファイルに格納され、SGA にキャッシュされる

Oracle データベース・ブロックのサイズを設定します。値の範囲は

オペレーティング・システムにより異なりますが、一般的にトランザクション処理システムの場合は 8192 で、データベース・ウェア

ハウス・システムの場合はさらに大きい値となります。

SGA_TARGET すべての SGA コンポーネントのサイズ合計を指定します。

SGA_TARGETが指定されている場合、バッファ・キャッシュ

（DB_CACHE_SIZE）、Java プール（JAVA_POOL_SIZE）、ラージ・

プール（LARGE_POOL_SIZE）および共有プール

（SHARED_POOL_SIZE）のメモリー・プールは、自動的にサイズ設

定されます。 7-2 ページの「自動共有メモリー管理」を参照してく

ださい。

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概要および管理』を参照してください。

表表表表 4-2 パフォーマンスに影響を与える重要な初期化パラメータ（続き）パフォーマンスに影響を与える重要な初期化パラメータ（続き）パフォーマンスに影響を与える重要な初期化パラメータ（続き）パフォーマンスに影響を与える重要な初期化パラメータ（続き）

パラメータパラメータパラメータパラメータ 説明説明説明説明

パフォーマンスを考慮したデータベースの構成 4-3

初期インスタンス構成のパフォーマンスの考慮事項

グすることもできます。V$ROLLSTATビューには、UNDO 表領域内の UNDO セグメントの動作に関する情報が含まれています。

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 回ログを切り替えます。

追加表領域の作成追加表領域の作成追加表領域の作成追加表領域の作成データベース・コンフィギュレーション・アシスタント（DBCA）を使用してデータベースを作成する場合、提供されるシード・データベースには必要な表領域すべてが自動的に組み込まれます。DBCA を使用しないように選択した場合は、初期データベースの作成後に追加表領域を作成する必要があります。

すべてのデータベースには、SYSTEM および SYSAUX 表領域に加えて複数の表領域が必要です。これらの追加表領域は次のとおりです。

� ソートなどに使用される一時表領域

� 読取り一貫性、リカバリおよびロールバック文に関する情報を格納するための UNDO 表領域

� 実際のアプリケーションで使用する 1 つ以上の表領域

ほとんどの場合、アプリケーションにはいくつかの表領域が必要です。多数のデータファイルを持つ非常に大きな表領域の場合は、複数の ALTER TABLESPACE x ADD DATAFILE Y文をパラレルに実行することもできます。

関連項目関連項目関連項目関連項目 :

� UNDO 管理アドバイザの詳細は、『Oracle Database 2 日でデータベース管理者』および Oracle Enterprise Manager オンライン・ヘルプを参照してください。

� 自動 UNDO 管理を使用した UNDO 領域の管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� 動的パフォーマンスの V$ROLLSTATおよび V$UNDOSTATビューの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : REDO ログの管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

4-4 Oracle Database パフォーマンス・チューニング・ガイド

初期インスタンス構成のパフォーマンスの考慮事項

表領域の作成時、表領域を構成するデータファイルは特殊な空のブロック・イメージで初期化されます。テンポラリ・ファイルは初期化されません。

この初期化は、すべてのデータファイルが、その全体に書込みを行えるようにするためですが、シリアルに行うと、長い処理になる可能性があります。したがって、複数の CREATE TABLESPACE文を同時に実行して、表領域の作成処理を高速化します。永続的な表の場合、表領域作成時にローカルまたはグローバルのいずれかのエクステント管理を選択するかで、パフォーマンスに大きな影響を与える可能性があります。読取り操作と比べて、普通または大規模な、挿入、変更または削除操作を行う永続的な表領域の場合は、ローカル・エクステント管理を選択する必要があります。

永続的な表領域の作成永続的な表領域の作成永続的な表領域の作成永続的な表領域の作成 : 自動セグメント領域管理自動セグメント領域管理自動セグメント領域管理自動セグメント領域管理永続的な表領域では、自動セグメント領域管理を使用することをお薦めします。これらの表領域（ビットマップ表領域と呼ばれる）は、ビットマップ・セグメント領域管理が行われるローカル管理表領域です。

一時表領域の作成一時表領域の作成一時表領域の作成一時表領域の作成一時表領域を正しく構成すると、ディスク・ソートのパフォーマンスの 適化に役立ちます。一時表領域はディクショナリ管理を行うこともローカル管理を行うこともできます。UNIFORMエクステント・サイズが 1MBの、ローカル管理の一時表領域を使用することをお薦めします。

一時表領域アクティビティを監視して、一時セグメントに割り当てられているエクステントの数をチェックする必要があります。1 つのアプリケーションで一時表が広範囲に使用されている場合は、多くのユーザーが一時表を同時に使用している場合と同様に、エクステント・サイズを 256KB などの小さい値に設定できます。これは、使用のたびに少なくとも 1 つのエクステントが必要になるためです。一時表領域はすべてサイズが均一のローカル管理エクステントで作成されるため、EXTENT MANAGEMENT LOCAL句は一時表領域ではオプションです。SIZEのデフォルトは 1MBです。

関連項目関連項目関連項目関連項目 :

� 空き領域管理の詳細は、『Oracle Database 概要』を参照してください。

� 表領域の自動セグメント領域管理の作成および使用の詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 :

� 一時表領域の管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� 一時表領域の詳細は、『Oracle Database 概要』を参照してください。

� TEMPORARY句を含む CREATE文および ALTER TABLESPACE文の使用の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

パフォーマンスを考慮したデータベースの構成 4-5

適切なパフォーマンスを得る表の作成とメンテナンス

適切なパフォーマンスを得る表の作成とメンテナンス適切なパフォーマンスを得る表の作成とメンテナンス適切なパフォーマンスを得る表の作成とメンテナンス適切なパフォーマンスを得る表の作成とメンテナンスアプリケーションをインストールする際、 初のステップで、必要なすべての表および索引を作成します。表のようなセグメントを作成すると、データのために領域がデータベース内に割り当てられます。後続のデータベース操作によってデータ容量が増大し、割り当てられた領域を上回るようになると、Oracle はそのセグメントを拡張します。

表および索引を作成する際には、次の点に注意してください。

� 表領域の自動セグメント領域管理の指定

高のパフォーマンスが得られるよう、Oracle によって自動的にセグメント領域が管理されます。

� 記憶領域オプションの注意深い設定

アプリケーションでは、表または索引の用途によって記憶領域オプションを慎重に設定する必要があります。この設定には、PCTFREEの値の設定が含まれます。自動セグメント領域管理を使用すると、PCTUSEDを指定する必要がありません。

表圧縮表圧縮表圧縮表圧縮ヒープ構成表は、どのような種類のアプリケーションにも透過的な圧縮形式で格納できます。表圧縮は、主に読取り専用の環境向けに設計されたものであり、DML 操作では処理のオーバーヘッドの原因となる可能性もあります。ただし、多くの読取り操作で、特にシステムが I/O バウンドである場合は、パフォーマンスが向上します。

データベース・ブロック内の圧縮データは自己完結型です。これは、ブロック内の圧縮されていないデータの再現に必要な情報がすべてそのブロック内にあることを意味します。ブロックは、バッファ・キャッシュ内でも圧縮された状態で保持されます。表圧縮により、ディスク記憶域のみでなく、メモリー使用量、特にバッファ・キャッシュ要件も削減されます。表へのアクセスに必要な I/O 操作の量が削減され、バッファ・キャッシュ・ヒットの確立が高まることで、パフォーマンスの向上が実現します。

圧縮係数の見積り圧縮係数の見積り圧縮係数の見積り圧縮係数の見積り表圧縮は、個々のブロック内の列値の繰返しを解消することによって機能します。ブロック内のすべての行と列の重複値は、ブロックの先頭にある、そのブロックのシンボル表と呼ばれるものに一度格納されます。こうした値の出現箇所はすべて、シンボル表への簡単な参照で置き換えられます。繰返しの値が多いブロックほど圧縮率が高くなります。

大規模な表を圧縮する前に、予測される圧縮係数を見積もる必要があります。圧縮係数は、圧縮されていない形式で情報を格納するために必要なブロック数を、圧縮記憶域に必要なブロック数で除算した値として定義されます。圧縮される表を代表する少数のデータ・ブロックをサンプリングし、圧縮されていない場合と圧縮された場合の各ブロックの平均レコード数を比較することで、圧縮係数を見積もることができます。これまでの経験では、およそ 1000 のデータ・ブロックを使用することで、きわめて正確な圧縮係数の見積りが可能であることがわかっています。サンプリングのブロック数が多いほど、見積り結果が正確になる点に注意してください。

チューニングによる圧縮率向上チューニングによる圧縮率向上チューニングによる圧縮率向上チューニングによる圧縮率向上Oracle では、多くの場合、特別なチューニングなしで、優れた圧縮係数を達成しています。データベース管理者またはアプリケーション開発者は、実際に圧縮が行われる際にレコードを再構成することによって、圧縮係数のチューニングを試行できます。チューニングを行うと、圧縮係数が若干改善されるケースもあれば大きく改善されるケースもあります。

圧縮係数を高めるには、データベース・ブロック内の値の繰返しの可能性を高くする必要があります。達成できる圧縮係数は、特定の列または列のペアのカーディナリティ（列値の繰返し

注意注意注意注意 : 空きリストの使用はお薦めしません。自動セグメント領域管理を使用するには、ローカル管理表領域を作成し、セグメント領域管理の句をAUTOに設定します。

4-6 Oracle Database パフォーマンス・チューニング・ガイド

適切なパフォーマンスを得る表の作成とメンテナンス

の可能性を表す）およびこれらの列の行の平均長さによって異なります。Oracle の表圧縮では、単一列の重複値が圧縮されるだけでなく、可能な場合は、複数列値のペアの使用が試行されます。データ配分について熟知していない場合、 適な順序の予測は非常に困難です。

未使用領域の解放未使用領域の解放未使用領域の解放未使用領域の解放一般に、時間経過とともにセグメント領域が断片化されたり、更新および削除操作の結果としてセグメントに多数の空き領域が生じます。このようにして粗密に移入されたオブジェクトは、問合せおよび DML 捜査中にパフォーマンスを低下させる可能性があります。

Oracle Database にはセグメント・アドバイザが用意されており、オブジェクト内の領域の断片化レベルに基づいて、オブジェクトに解放可能な領域があるかどうかのアドバイスを提供します。

オブジェクトに解放可能な領域がある場合は、データベース・セグメントを圧縮して縮小するか、またはデータベース・セグメントの終わりにある未使用領域を割当て解除できます。

データの索引付けデータの索引付けデータの索引付けデータの索引付けも効率的な索引の作成方法は、データがロードされた後に索引を作成することです。そうす

ると、領域管理が大幅に簡単になり、行が挿入されるたびに索引がメンテナンスされることもありません。これは、SQL*Loader により自動的に行われますが、他の方法で初期データをロードする場合は、手動で行う必要があります。また、索引の作成は、CREATE INDEX文のPARALLEL句を使用してパラレルで実行します。ただし、SQL*Loader ではこれを実行できないため、データのロード後に索引を手動でパラレルに作成する必要があります。

ソート用データのメモリーの指定ソート用データのメモリーの指定ソート用データのメモリーの指定ソート用データのメモリーの指定データを含む表での索引の作成中に、データをソートする必要があります。このソートは、すべての使用可能なメモリーをソートに使用する場合に も高速に行われます。PGA_AGGREGATE_TARGET初期化パラメータを設定して、SQL 作業領域の自動サイズ指定を使用可能にすることをお薦めします。

関連項目関連項目関連項目関連項目 : 表圧縮およびパーティションの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : セグメント・アドバイザの詳細は、『Oracle Database 管理者ガイド』および『Oracle Database 2 日でデータベース管理者』を参照してください。

関連項目関連項目関連項目関連項目 :

� 未使用領域の解放については、『Oracle Database 管理者ガイド』を参照してください。

� データベース・セグメントの縮小または未使用領域の割当て解除に使用する SQL 文の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : SQL*Loader の詳細は、『Oracle Database ユーティリティ』を参照してください。

関連項目関連項目関連項目関連項目 :

� PGA メモリー管理の詳細は、7-35 ページの「PGA メモリー管理」を参照してください。

� PGA_AGGREGATE_TARGET初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

パフォーマンスを考慮したデータベースの構成 4-7

共有サーバーのパフォーマンスの考慮事項

共有サーバーのパフォーマンスの考慮事項共有サーバーのパフォーマンスの考慮事項共有サーバーのパフォーマンスの考慮事項共有サーバーのパフォーマンスの考慮事項共有サーバーを使用すると、プロセス数と、システムで消費されるメモリー量が削減されます。共有サーバーは、多数の OLTP ユーザーが断続的なトランザクションを実行するシステムに有効です。

また、データベースへの単位時間当たりの接続数が高いシステムでは、一般的に専用サーバーよりも共有サーバーを使用する方が適しています。共有サーバーでは、接続要求を受けるよりも前に同時接続要求を処理するためのディスパッチャが使用可能な状態になっています。一方、専用サーバーの場合は、接続固有の専用サーバーが、接続要求ごとに順次初期化されます。

共有サーバー・アーキテクチャを使用すると、特定のデータベース機能のパフォーマンスが改善することも、または多少低下することもあります。たとえば、パラレル実行がアクティブな場合、セッションが別の共有サーバーに移行できないことがあります。

クライアントからの要求が処理された後もセッションを移行できない場合があります。これはすべてのユーザー情報が、UGA に格納されているとは限らないためです。サーバーがクライアントからの要求の処理を待機していた場合、UGA に格納されていなかったユーザー状態にはアクセスできません。これを回避するために、個々の共有サーバーは、しばしばユーザー・セッションにバインドされた状態を続ける必要があります。

ある種の機能を使用する場合、あるサーバーがセッションに長期間バインドされる可能性があるため、追加の共有サーバーを構成する必要が生じる場合があります。

この項では、Oracle のアーキテクチャで使用するプロセスの競合を低減する方法について説明します。

� ディスパッチャ固有のビューを使用する競合の識別

� 共有サーバー・プロセスの競合の識別

ディスパッチャ固有のビューを使用する競合の識別ディスパッチャ固有のビューを使用する競合の識別ディスパッチャ固有のビューを使用する競合の識別ディスパッチャ固有のビューを使用する競合の識別次のビューによってディスパッチャのパフォーマンス統計が提供されます。

� V$DISPATCHERは、ディスパッチャ・プロセスの一般的な情報を提供します。

� V$DISPATCHER_RATEは、ディスパッチャ・プロセスの統計を提供します。

V$DISPATCHER_RATEビューは、いくつかのカテゴリについてディスパッチャ統計の現在、平均および 大の値を含みます。接頭辞 CUR_が付いている統計は、現在のサンプルの統計です。接頭辞 AVG_が付いている統計は、コレクション期間が開始してからの統計の平均値です。接頭辞 MAX_が付いている統計は、統計収集が開始してからのこれらのカテゴリでの 大値です。

ディスパッチャのパフォーマンスを調べるには、V$DISPATCHER_RATEビューを問い合せて、大値と現在の値を比較します。現在のシステム・スループットが適切な応答時間を提供し、

このビューの現在の値が平均値に近くかつ 大値を下回る場合、共有サーバー環境は 適にチューニングされていると考えられます。

現在の値と平均値が 大値を大きく下回る場合は、ディスパッチャ数の削減を検討してください。反対に、現在の値と平均値が 大値に近い場合は、ディスパッチャを追加する場合があります。システム使用率が低い期間と高い期間の両方で V$DISPATCHER_RATE統計を調べてみることを一般規則としてお薦めします。共有サーバーの負荷パターンを識別した後で、それに従ってパラメータを調整します。

必要であれば、システムのストレス・テストを実行し、定期的に V$DISPATCHER_RATE統計をポーリングすることによってワークロードをシミュレートすることもできます。これらの統

関連項目関連項目関連項目関連項目 :

� 共有サーバーの管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� 共有サーバー用のディスパッチャの構成の詳細は、『Oracle Database Net Services 管理者ガイド』を参照してください。

4-8 Oracle Database パフォーマンス・チューニング・ガイド

共有サーバーのパフォーマンスの考慮事項

計の正しい解釈方法は、プラットフォームごとに異なります。アプリケーションの種類が変わると、V$DISPATCHER_RATEに記録される統計値も大幅に異なる可能性があります。

ディスパッチャ・プロセスの競合の低減ディスパッチャ・プロセスの競合の低減ディスパッチャ・プロセスの競合の低減ディスパッチャ・プロセスの競合の低減競合を低減するには、次の点を考慮してください。

� ディスパッチャ・プロセスの追加

ディスパッチャ・プロセスの総数は、MAX_DISPATCHERS初期化パラメータの値で制限されます。ディスパッチャ・プロセスを追加する前に、この値を増やす必要がある場合があります。

� 接続プーリングの使用可能化

システム負荷が増加し、ディスパッチャ・スループットが 大限になった場合は、すぐにディスパッチャを追加することが必ずしも適切とはかぎりません。そのかわりに、接続プーリングによってより多くのユーザーをサポートできるようにディスパッチャを構成することを検討してください。

� セッション多重化の有効化

多重化は、Connection Manager プロセスで、複数ユーザーから個別のディスパッチャへのネットワーク・セッションを確立およびメンテナンスする場合に使用されます。たとえば、いくつかのユーザー・プロセスが Connection Manager プロセスからの 1 つの接続を経由して 1 つのディスパッチャに接続できます。ディスパッチャ・プロセスが 大限に使用されるため、セッションの多重化は有効です。多重化は、ディスパッチャ間のデータベース・リンク・セッションを多重化する場合にも役立ちます。

関連項目関連項目関連項目関連項目 :

� V$DISPATCHERおよび V$DISPATCHER_RATEビューの詳細は、『Oracle Database リファレンス』を参照してください。

� 統計を監視する Oracle Tuning Pack アプリケーションの詳細は、『Oracle Enterprise Manager 概要』を参照してください。

関連項目関連項目関連項目関連項目 :

� ディスパッチャ・プロセスの構成の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� 接続プーリングの構成の詳細は、『Oracle Database Net Services 管理者ガイド』を参照してください。

� DISPATCHERSおよび MAX_DISPATCHERSパラメータの詳細は、『Oracle Database リファレンス』を参照してください。

パフォーマンスを考慮したデータベースの構成 4-9

共有サーバーのパフォーマンスの考慮事項

共有サーバー・プロセスの競合の識別共有サーバー・プロセスの競合の識別共有サーバー・プロセスの競合の識別共有サーバー・プロセスの競合の識別この項では、共有サーバーの競合を識別する方法を説明します。

要求キューにおいて待機時間が一貫して増加する場合、それは共有サーバーの競合を示します。待機時間のデータを調べるには、動的パフォーマンス・ビュー V$QUEUEを使用します。このビューには、共有サーバーの要求キューのアクティビティを示す統計が含まれます。デフォルトでは、ユーザー SYSおよび SYSTEMのような、SELECT ANY TABLEシステム権限を持っているユーザーのみがこのビューを利用できます。表 4-3 は、要求の待機時間とキュー内の要求の数を示す列をリストしたものです。

アプリケーションの実行時に次の 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

表表表表 4-3 V$QUEUE 内の待機時間と要求列内の待機時間と要求列内の待機時間と要求列内の待機時間と要求列

列列列列 説明説明説明説明

WAIT キューに存在していた全要求についての待機時間の合計（100 分

の 1 秒単位）

TOTALQ キューに存在していた要求の総数

関連項目関連項目関連項目関連項目 : 共有サーバー・プロセスの初期化パラメータの設定の詳細は、『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 アドバイザおよびレポートでは、統計が時間単位で記述されます。また、V$SESS_TIME_MODELおよび V$SYS_TIME_MODELビューには、時間モデル統計が用意されています。共通の時間という尺度で計測すると、データベース操作に対する影響を数量化して識別できます。

も重要な時間モデル統計は DB timeです。この統計はインスタンスのワークロード合計のインジケータであり、データベース・コールの合計所要時間を表します。この統計は、アイドル待機イベント（アイドル状態でないユーザー・セッション）で待機していない全セッションのCPU タイムと待機時間を集計することで計算されます。

DB timeは、インスタンスの起動時から累積的に測定されます。 DB timeはアイドル状態でない全ユーザー・セッションの時間の合計として計算されるため、インスタンス起動後の実際の経過時間を超える場合があります。たとえば、30 分実行されているインスタンスに 4 つのアクティブ・ユーザー・セッションがあり、その累積 DB timeが約 120 分となる場合があります。

関連項目関連項目関連項目関連項目 : Oracle 待機イベントの詳細は、『Oracle Database リファレンス』を参照してください。

自動パフォーマンス統計 5-3

データ収集の概要

Oracle システムのチューニングは、データベース上でユーザーが実行する一部のアクションについて所要時間を短縮すること、または単に DB timeを短縮することを目的としています。他の時間モデル統計は、ログオン操作、ハード解析およびソフト解析など、特定のアクションへの影響を（時間単位で）数量化した情報を提供します。

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 識別子

� オブジェクト数、ファイル数およびブロック数

� 待機イベント識別子およびパラメータ

� セッション識別子およびセッション・シリアル番号

� モジュールおよびアクション名

� セッションのクライアント識別子

� サービス・ハッシュ識別子

指定した期間の Active Session History 情報は、1 つのレポートに収集できます。詳細は、5-20ページの「Active Session History レポートの生成」を参照してください。

システム統計とセッション統計システム統計とセッション統計システム統計とセッション統計システム統計とセッション統計V$SYSSTATおよび V$SESSTATビューを使用すると、システム・レベルとセッション・レベルで多数の累積的データベース統計を使用できます。

関連項目関連項目関連項目関連項目 : V$SESS_TIME_MODELおよび V$SYS_TIME_MODELビューの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : V$ACTIVE_SESSION_HISTORYビューの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : 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 の場合は、パフォーマンス・モニタ・ツールを使用します。

統計の解釈統計の解釈統計の解釈統計の解釈初にパフォーマンス・データを調査するときは、統計を調べることによって潜在的な理論を

構築できます。統計の解釈が正しいかどうかを確認する 1 つの方法は、他のデータとのクロスチェックを行うことです。これにより、統計またはイベントが実際に対象のものであるかどうかがわかります。

ここではいくつかの陥りやすい誤りについて説明します。

� ヒット率

チューニングを行う場合は、問題があるかどうかを容易に判断するために、比率を計算することが一般的です。そのような率には、バッファ・キャッシュ・ヒット率、ソフト解析率およびラッチ・ヒット率があります。これらの率を、パフォーマンス・ボトルネックがあるかどうかを厳密に判断する識別子として使用しないでください。むしろ、インジケータとして使用してください。ボトルネックがあるかどうかを識別するには、他の関連する証拠を調べる必要があります。7-8 ページの「バッファ・キャッシュ・ヒット率の計算」を参照してください。

� 時間統計のある待機イベント

インスタンス・レベルで TIMED_STATISTICSを TRUE に設定すると、Oracle サーバーはすでに使用できる待機カウントの他にイベントの待機時間を収集します。このデータは、イベントの合計待機時間をパフォーマンス・データ収集間の総経過時間と比較する場合に役立ちます。たとえば、待機イベントが 2 時間の期間のうちのわずか 30 秒であれば、このイベントが待機時間別に順序付けされるときに 高ランクの待機イベントであっても、このイベントを調べて得られるものはほとんどありません。ただし、イベントが 45 分間のう

表表表表 5-1 オペレーティング・システム統計収集用のオペレーティング・システム統計収集用のオペレーティング・システム統計収集用のオペレーティング・システム統計収集用の UNIX ツールツールツールツール

コンポーネントコンポーネントコンポーネントコンポーネント UNIX ツールツールツールツール

CPU sar、vmstat、mpstat、iostat

メモリー sar、vmstat

ディスク sar、iostat

ネットワーク netstat

5-6 Oracle Database パフォーマンス・チューニング・ガイド

データ収集の概要

ちの 30 分であれば、そのイベントは調べる価値があります。5-3 ページの「待機イベント」を参照してください。

� Oracle 統計とその他の要因の比較

統計を調べる場合、統計に価値があるかどうかに影響を与える他の要因を考慮することが重要です。そのような要因には、ユーザー負荷やハードウェア能力があります。 待機時間が 45 分間のスナップショットのうちの 30 分間であったイベントでも、システム上に 2000人のユーザーがいて、ホスト・ハードウェアが 64 ノード・システムであった場合は問題とはみなされないことがあります。

� 時間統計のない待機イベント

TIMED_STATISTICSが正しくない場合、イベントの待機時間は使用できません。したがって、各イベントを待機した時間数で待機イベントを順序付けることのみ可能です。大待機回数を持つイベントが潜在的なボトルネックを示すことがありますが、主要なボトルネックとは言えません。これはイベントを長時間待つ場合に発生する可能性がありますが、そのイベントを待つ合計待機時間は短時間です。その逆もなりたちます。待機回数が少ないイベントは、その待機時間が合計待機時間の大きな割合を占めている場合に問題になることがあります。比較のために使用する待機時間がなければ、待機イベントが実際に重要かどうかの判断は困難です。

� アイドル待機イベント

Oracle では、いくつかの待機イベントを使用して、Oracle サーバー・プロセスがアイドル状態であるかどうかを示します。一般に、これらのイベントはパフォーマンスの問題を調べるときは有効でなく、待機イベントを調べるときは無視する必要があります。10-34 ページの「アイドル待機イベント」を参照してください。

� 計算済統計

計算済統計（割合、トランザクションごとに正規化された統計、比率など）を解釈する場合は、計算済統計を実際の統計カウントと相互検査することが重要です。その検査で、導出レートが実際に重要かどうかが確認されます。通常、小さな統計カウントにより、異常な比率を除外できます。たとえば、 初の検査で、ソフト解析率 50% は、一般に潜在的なチューニング領域を示します。ただし、データ収集期間にハード解析が 1 つとソフト解析が 1 つのみあった場合、この領域が重要な領域でないことを統計カウントが示していても、ソフト解析率は 50% になります。この場合、統計カウントが低いため、比率は重要ではありません。

注意注意注意注意 : 初期化パラメータ 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から導出された値を上書きします。

関連項目関連項目関連項目関連項目 :

� 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に設定すると、セグメント統計やメモリー・アドバイザ情報など、多数のシステム統計のメモリー内収集機能がオフになるため、手動で収集したスナップショットにはこれらの統計が含まれず、不完全なものになります。

この項では、自動ワークロード・リポジトリに関する次の項目について説明します。

� スナップショット

� ベースライン

� 領域使用量

スナップショットスナップショットスナップショットスナップショットスナップショットは、ADDM によりパフォーマンスの比較に使用される、特定の期間の履歴データのセットです。 AWR では、デフォルトで 1 時間ごとにパフォーマンス・データのスナップショットが自動的に生成され、ワークロード・リポジトリに統計が 7 日間保持されます。スナップショットを手動で作成することもできますが、通常は必要ありません。スナップショット間隔内のデータは、Automatic Database Diagnostic Monitor（ADDM）によって分析されます。 ADDM の詳細は、6-3 ページの「Automatic Database Diagnostic Monitor」を参照してください。

AWR は、スナップショット間の違いを比較し、システム負荷への影響に基づいて収集するSQL 文を判別します。これにより、期間中に収集する必要のある SQL 文の数が減少します。

スナップショットの管理については、5-10 ページの「スナップショットの管理」を参照してください。

関連項目関連項目関連項目関連項目 : STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

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 スナップショットとベースラインを管理できます。

この項では、次の項目について説明します。

� スナップショットの作成

� スナップショットの削除

� スナップショット設定の変更

スナップショットの作成スナップショットの作成スナップショットの作成スナップショットの作成自動生成されたスナップショットとは異なる時点の統計を収集する場合は、CREATE_SNAPSHOTプロシージャにより、手動でスナップショットを作成できます。 たとえば、次のようにします。

BEGIN DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();END;/

この例では、インスタンスのスナップショットがただちに作成され、フラッシュ・レベルは、デフォルトのフラッシュ・レベルである TYPICALに指定されます。このスナップショットは、DBA_HIST_SNAPSHOTビューに表示できます。

関連項目関連項目関連項目関連項目 : DBMS_WORKLOAD_REPOSITORYパッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

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: 30Enter 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.DMPJob "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 08:58:20

抽出する必要のある AWR データの量によっては、AWR 抽出操作が完了するまでに時間がかかることがあります。 ダンプ・ファイルが作成された後、データ・ポンプを使用してファイルを別のシステムに転送できます。

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 表領域が選択されています。

関連項目関連項目関連項目関連項目 : データ・ポンプの使用方法は、『Oracle Database ユーティリティ』を参照してください。

5-14 Oracle Database パフォーマンス・チューニング・ガイド

自動ワークロード・リポジトリの管理

7. AWR データのロード用に AWR_STAGEというステージング・スキーマが作成されます。 AWR データは AWR_STAGEスキーマにロードされた後、SYSスキーマ内の AWR 表に転送されます。

Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTCompleted 113 CONSTRAINT objects in 11 secondsProcessing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINTCompleted 1 REF_CONSTRAINT objects in 1 secondsJob "SYS"."SYS_IMPORT_FULL_03" successfully completed at 09:29:30... Dropping AWR_STAGE userEnd 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 またはテキストのレポートが生成されます。

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: 150Enter value for end_snap: 160

注意注意注意注意 : これらのスクリプトを実行するには、DBA ロールが付与されている必要があります。

指定した範囲のスナップショットにワークロード・アクティビティのないデータベースに対してレポートを実行すると、一部のレポート統計について 0 より小さいか 100 を超えるパーセンテージが計算される場合があります。この結果は、単にその統計に意味のある値がないことを意味します。

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 Host----------- -------- ------------ ------------ ------------ 3309173529 1 MAIN main dlsun1690 3309173529 1 TINT251 tint251 stint251

プロンプトに、データベース識別子（dbid）およびインスタンス番号（inst_num）の値を入力します。

Enter value for dbid: 3309173529Using 3309173529 for database IdEnter 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: 146Enter 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 Host----------- -------- ------------ ------------ ------------ 3309173529 1 MAIN main dlsun1690 3309173529 1 TINT251 tint251 stint251

プロンプトに、データベース識別子（dbid）およびインスタンス番号（inst_num）の値を入力します。

Enter value for dbid: 3309173529Using 3309173529 for database IdEnter value for inst_num: 1Using 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: 102Enter 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: 126Enter 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 Host----------- -------- ------------ ------------ ------------ 3309173529 1 MAIN main dlsun1690 3309173529 1 TINT251 tint251 stint251

プロンプトに、第 1 期間のデータベース識別子（dbid）およびインスタンス番号（inst_num）の値を入力します。

Enter value for dbid: 3309173529Using 3309173529 for Database Id for the first pair of snapshotsEnter value for inst_num: 1Using 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: 102Enter value for end_snap: 103

次に、プロンプトに、第 2 期間のデータベース識別子（dbid）およびインスタンス番号（inst_num）の値を入力します。

Enter value for dbid2: 3309173529Using 3309173529 for Database Id for the second pair of snapshotsEnter value for inst_num2: 1Using 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: 126Enter 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 Host----------- -------- ------------ ------------ ------------ 3309173529 1 MAIN main dlsun1690 3309173529 1 TINT251 tint251 stint251

プロンプトに、データベース識別子（dbid）およびインスタンス番号（inst_num）の値を入力します。

Enter value for dbid: 3309173529Using 3309173529 for database idEnter 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 MonitorAutomatic Database Diagnostic Monitor（ADDM）は、全体的なチューニング・ソリューションを提供します。ADDM 分析は、特定のインスタンス上で作成された 1 対の AWR スナップショットで定義される期間に対して実行できます。分析はトップ・ダウン方式で実行され、初に症状が識別されてから、パフォーマンスの問題の根本的な原因に到達するまで詳細化されます。

分析の目標は、DB timeと呼ばれる 1 つのスループット測定値を減少させることです。DB timeは、データベース・サーバーでユーザー要求の処理にかかった累積時間です。これには、アイドル状態でないユーザー・セッションすべての待機時間と CPU タイムが含まれます。DB timeは、V$SESS_TIME_MODELおよび V$SYS_TIME_MODELビューに表示されます。

個々のユーザー応答時間のチューニングは 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 では、システムの正常領域も文書化されます。たとえば、システムのパフォーマンスにほとんど影響しない待機イベント・クラスが識別され、早期段階でチューニング考慮事項から削除されます。これにより、システム全体のパフォーマンスに影響しない項目に対する時間および労力の節約になります。

関連項目関連項目関連項目関連項目 :

� V$SESS_TIME_MODELおよび V$SYS_TIME_MODELビューの詳細は、『Oracle Database リファレンス』を参照してください。

� 時間モデル統計および DB timeについては、5-3 ページの「時間モデル統計」を参照してください。

� サーバー・プロセスについては、『Oracle Database 概要』を参照してください。

自動パフォーマンス診断 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 機能が無効になります。この設定はお薦めしません。

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);

関連項目関連項目関連項目関連項目 : STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

自動パフォーマンス診断 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権限を付与されている任意のユーザーが実行できます。

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... SnapInstance 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: 137Begin Snapshot Id specified: 137

Enter value for end_snap: 141End Snapshot Id specified: 141

関連項目関連項目関連項目関連項目 : DBMS_ADVISORパッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

6-6 Oracle Database パフォーマンス・チューニング・ガイド

Automatic Database Diagnostic Monitor

3. レポート名の指定を求めるプロンプトに対してレポート名を入力するか、デフォルト名を受け入れます。

Enter value for report_name: Using the report name addmrpt_1_137_145.txtRunning 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 VARCHAR2IS begin_snap NUMBER; end_snap NUMBER; tid NUMBER; -- Task ID tname VARCHAR2(30); -- Task Name tdesc VARCHAR2(256); -- Task DescriptionBEGIN -- 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 reportSET PAGESIZE 0 LONG 1000000 LONGCHUNKSIZE 1000;COLUMN get_clob FORMAT a80;-- execute run_addm() with 7pm and 9pm as inputVARIABLE 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 パフォーマンス・チューニング・ガイド

メモリー割当ての問題について

インスタンス起動時に値を 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に使用可能な総量から差し引かれます。

キャッシュ・サイズの動的な変更キャッシュ・サイズの動的な変更キャッシュ・サイズの動的な変更キャッシュ・サイズの動的な変更システムで自動共有メモリー管理が使用されていない場合、共有プール、ラージ・プール、バッファ・キャッシュおよびプロセス・プライベート・メモリーのサイズを動的に再構成することを選択できます。次の各項では、キャッシュ・サイズ設定の詳細について説明します。

� バッファ・キャッシュの構成と使用方法

� 共有プールとラージ・プールの構成および使用方法

� REDO ログ・バッファの構成および使用

DB_CACHE_ADVICE、JAVA_POOL_SIZE、LARGE_POOL_SIZE、LOG_BUFFERおよびSHARED_POOL_SIZEなどの初期化構成パラメータを使用して、これらのメモリー・キャッシュのサイズを構成できます。これらのパラメータの値も、ALTER SYSTEM文で動的に構成できます（起動後に静的に設定されるログ・バッファ・プールおよびプロセス・プライベート・メモリーを除く）。

共有プール、ラージ・プール、Java プールおよびバッファ・キャッシュのメモリーは、グラニュル単位で割り当てられます。SGA サイズが 1GB より小さい場合、グラニュル・サイズは4MB です。SGA サイズが 1GB 以上の場合、グラニュル・サイズは 16MB に変化します。グラニュル・サイズは、インスタンスの起動時に計算されて固定されます。このサイズは、インスタンスの存続期間中は変化しません。

関連項目関連項目関連項目関連項目 :

� 自動 SGA 管理の詳細は、『Oracle Database 概要』を参照してください。

� システム・グローバル領域（SGA）の管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 :

� 初期化パラメータの管理の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� STREAMS_POOL_SIZE初期化パラメータの詳細は、『Oracle Streams概要および管理』を参照してください。

� Java のメモリー使用量の詳細は、『Oracle Database Java 開発者ガイド』を参照してください。

メモリーの構成と使用方法 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 サイズ変更操作に関する情報を提供します。

� 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 メモリーの量に関する情報。

アプリケーションの考慮事項アプリケーションの考慮事項アプリケーションの考慮事項アプリケーションの考慮事項メモリー構成では、アプリケーションの要求に適したキャッシュをサイズ設定することが重要です。逆に、アプリケーションのキャッシュの使用率をチューニングすると、リソース要件を大幅に削減できます。Oracle メモリー・キャッシュを効率的に使用すると、これらのキャッシュを保護するラッチ、CPU、I/O システムなどの関連リソースに対する負荷も削減できます。

高のパフォーマンスを得るために、次のことを考慮してください。

� オペレーティング・システムおよびデータベース・リソースを も効率的に使用するように、キャッシュを 適に設計する必要があります。

� Oracle メモリー構造に対するメモリーの割当ては、アプリケーションの要求を もよく反映する必要があります。

既存のアプリケーションに対する変更または追加を行う場合は、変更されたアプリケーションの要求を満たすために Oracle メモリー構造のサイズ変更が必要な場合があります。

注意注意注意注意 : SGA_MAX_SIZEは、動的にサイズ変更できません。

関連項目関連項目関連項目関連項目 : 動的 SGA の管理の詳細は、オペレーティング・システムのマニュアルを参照してください。

関連項目関連項目関連項目関連項目 :

� 動的 SGA の詳細は、『Oracle Database 概要』を参照してください。

� これらのビューの列の詳細は、『Oracle Database リファレンス』を参照してください。

7-4 Oracle Database パフォーマンス・チューニング・ガイド

メモリー割当ての問題について

アプリケーションが Java を使用する場合、Java プールのデフォルト構成を変更する必要があるかどうかを調べる必要があります。Java のメモリー使用量の詳細は、『Oracle Database Java 開発者ガイド』を参照してください。

オペレーティング・システムのメモリー使用量オペレーティング・システムのメモリー使用量オペレーティング・システムのメモリー使用量オペレーティング・システムのメモリー使用量大半のオペレーティング・システムでは、次のことを考慮することが重要です。

ページングの削減ページングの削減ページングの削減ページングの削減ページングは、新しいページをメモリーにロードできるようにするため、オペレーティング・システムがメモリー常駐ページをディスクに転送する場合に行われます。多くのオペレーティング・システムは、実メモリーに格納しきれない大量の情報を収容するために、ページングを行います。大半のオペレーティング・システムでは、ページングはパフォーマンスを低下させます。

オペレーティング・システムのユーティリティを使用して、オペレーティング・システムを調べ、システム上に多数のページングがあるかどうかを確認します。ページングが多数ある場合は、システム上の総メモリー量が、メモリーを割り当てたすべてを保持できるほど十分に大きくない場合があります。システム上の全体のメモリーを増やすか、割り当てたメモリー量を減らします。

主メモリーへの主メモリーへの主メモリーへの主メモリーへの SGA の格納の格納の格納の格納SGA の目的は、迅速なアクセスのためにメモリー内にデータを格納することであるため、SGAは主メモリー内に存在する必要があります。SGA のページがディスクにスワップされると、データに迅速にアクセスできなくなります。多くのオペレーティング・システムでは、ページングによる損失は、大規模な SGA がもたらす利益をかなり上回ります。

SGA とその各内部構造に割り当てられるメモリー量を確認するには、次の SQL*Plus 文を入力します。

SHOW SGA

この文の出力例を次に示します。

Total System Global Area 840205000 bytesFixed Size 279240 bytesVariable Size 520093696 bytesDatabase Buffers 318767104 bytesRedo Buffers 1064960 bytes

個々のユーザーへの十分なメモリーの割当て個々のユーザーへの十分なメモリーの割当て個々のユーザーへの十分なメモリーの割当て個々のユーザーへの十分なメモリーの割当てSGA をサイズ設定する場合は、個々のサーバー・プロセスとその他のプログラムがシステム上で作動するように十分なメモリーを使用できるようにします。

注意注意注意注意 : LOCK_SGAパラメータを使用すると、SGA が物理メモリーにロックされるため、ページ・アウトを防止できます。

関連項目関連項目関連項目関連項目 : オペレーティング・システムのメモリー使用方法のチューニングの詳細は、オペレーティング・システムのハードウェアとソフトウェアのマニュアル、およびオペレーティング・システム固有の Oracle マニュアルを参照してください。

メモリーの構成と使用方法 7-5

バッファ・キャッシュの構成と使用方法

構成の繰返し構成の繰返し構成の繰返し構成の繰返しメモリーの割当てを構成する場合は、アプリケーションの要求により異なりますが、Oracle メモリー構造に使用可能なメモリーを配分します。Oracle の構造にメモリーを配分すると、Oracle が動作するために必要な物理 I/O の量に影響を与える可能性があります。 初にメモリーを適切に構成すると、I/O システムが効果的に構成されているかどうかも表示されます。

プロセスをひととおり実行した後で、メモリー割当てのステップを繰り返すことが必要となる可能性もあります。実行を繰り返すことによって、後のステップの変更に基づいて前のステップの調整が可能となります。たとえば、バッファ・キャッシュのサイズを小さくすると、共有プールなど別のメモリー構造のサイズを大きくできます。

バッファ・キャッシュの構成と使用方法バッファ・キャッシュの構成と使用方法バッファ・キャッシュの構成と使用方法バッファ・キャッシュの構成と使用方法様々なタイプの操作について、Oracle ではバッファ・キャッシュを使用してディスクから読み取られたブロックを格納します。ソートやパラレル読込みなどの特定操作の場合には、Oracleではバッファ・キャッシュはバイパスされます。バッファ・キャッシュを使用する操作について、この項では次の項目を説明します。

� バッファ・キャッシュの効果的な使用

� バッファ・キャッシュのサイズ設定

� バッファ・キャッシュ・アドバイザ統計の解釈および使用方法

� 複数バッファ・プールについて

バッファ・キャッシュの効果的な使用バッファ・キャッシュの効果的な使用バッファ・キャッシュの効果的な使用バッファ・キャッシュの効果的な使用バッファ・キャッシュを効果的に使用するには、不要なリソース使用を回避するようにアプリケーションの SQL 文をチューニングする必要があります。これを確認するには、頻繁に実行される SQL 文と、多数のバッファ取得を実行する SQL 文がチューニングされたかどうかを検証します。

バッファ・キャッシュのサイズ設定バッファ・キャッシュのサイズ設定バッファ・キャッシュのサイズ設定バッファ・キャッシュのサイズ設定新規にインスタンスを構成する場合は、バッファ・キャッシュの適切なサイズがわかっていません。通常、データベース管理者はキャッシュ・サイズの 初の見積りを行い、次にインスタンス上で代表的なワークロードを実行し、関連する統計を調べて、キャッシュが構成過小か構成過大かを調べます。

バッファ・キャッシュ・アドバイザの統計バッファ・キャッシュ・アドバイザの統計バッファ・キャッシュ・アドバイザの統計バッファ・キャッシュ・アドバイザの統計多数の統計が、バッファ・キャッシュ・アクティビティの調査に使用できます。これらの統計には次のものがあります。

� V$DB_CACHE_ADVICE

� バッファ・キャッシュ・ヒット率

V$DB_CACHE_ADVICE の使用の使用の使用の使用このビューは、DB_CACHE_ADVICE初期化パラメータが ONに設定されているときに移入されます。このビューは、潜在的なバッファ・キャッシュ・サイズ範囲のシミュレーションによるミス率を示します。

このビューには、シミュレートされたキャッシュ・サイズのそれぞれの独自の行と、そのキャッシュ・サイズに対して発生すると予測された物理 I/O アクティビティがあります。DB_CACHE_ADVICEパラメータは動的であるため、特定のワークロードのアドバイザ・データを収集できるように、アドバイザ機能を動的に有効にしたり、無効にできます。

関連項目関連項目関連項目関連項目 : この確認を行う方法の詳細は、第 11 章「SQL チューニングの概要」を参照してください。

7-6 Oracle Database パフォーマンス・チューニング・ガイド

バッファ・キャッシュの構成と使用方法

このアドバイザ機能には、多少のオーバーヘッドが伴います。アドバイザ機能を有効にすると、追加の記録が必要なため、CPU の使用量はわずかに増加します。

Oracle では、DBA ベースのサンプリングを使用して、キャッシュ・アドバイザ統計を収集します。サンプリングを使用すると、ブックキーピングに関連する CPU およびメモリーのオーバーヘッドが大幅に減少します。サンプリングは、開始時のバッファの数が少ないバッファ・プールでは使用しません。

V$DB_CACHE_ADVICEを使用するには、パラメータ DB_CACHE_ADVICEを ONに設定し、インスタンス上で代表的なワークロードを実行するようにします。V$DB_CACHE_ADVICEビューを問い合せる前にワークロードを安定化できるようにします。

次の SQL 文は、様々なキャッシュ・サイズについてデフォルト・バッファ・プールに対するI/O 要件の予測を戻します。

COLUMN size_for_estimate FORMAT 999,999,999,999 heading 'Cache Size (MB)'COLUMN buffers_for_estimate FORMAT 999,999,999 heading 'Buffers'COLUMN estd_physical_read_factor FORMAT 999.90 heading 'Estd Phys|Read Factor'COLUMN estd_physical_reads FORMAT 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 10% of Current Size 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 Current Size 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 200% of Current Size

このビューは、潜在的な各キャッシュ・サイズの物理読込み数を予測する情報を提供して、キャッシュのサイズ設定を支援します。このデータには物理読込みファクタが含まれています。これは、バッファ・キャッシュが所定の値にサイズ変更された場合、現行の物理読込み回数がその分のみ変化すると予測されるファクタです。

メモリーの構成と使用方法 7-7

バッファ・キャッシュの構成と使用方法

キャッシュ内でのブロックの検出成功とキャッシュのサイズ間の関係は、必ずしも滑らかな分布を示しません。バッファ・プールをサイズ設定するときは、キャッシュ・ヒット率の向上にまったく貢献しない（または、ほとんど貢献しない）追加バッファは使用しないでください。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 の統計は、ヒット率の計算に使用されます。

注意注意注意注意 : Oracle では、物理読込みは必ずしもディスク読込みを意味しません。物理読込みは、ファイル・システム・キャッシュからで済む場合があります。

表表表表 7-1 ヒット率を計算するための統計ヒット率を計算するための統計ヒット率を計算するための統計ヒット率を計算するための統計

統計統計統計統計 説明説明説明説明

consistent gets from cache

バッファ・キャッシュからのブロックに対して読取り一貫性が要求された回数。

db block gets from cache

バッファ・キャッシュからの CURRENT ブロックが要求された回数。

physical reads cache ディスクからバッファ・キャッシュへ読み込まれたデータ・ブロックの合計数。

7-8 Oracle Database パフォーマンス・チューニング・ガイド

バッファ・キャッシュの構成と使用方法

例 7-1 は V$SYSSTAT表から直接選択した値を使用して単純化したもので、ある期間の値を選択したものではありません。アプリケーションの実行中のある期間にわたるこれらの統計の差分を計算し、それらの統計を使用してヒット率を判断することが 良の方法です。

例例例例 7-1 バッファ・キャッシュ・ヒット率の計算バッファ・キャッシュ・ヒット率の計算バッファ・キャッシュ・ヒット率の計算バッファ・キャッシュ・ヒット率の計算

SELECT NAME, VALUE FROM V$SYSSTATWHERE 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$DB_CACHE_ADVICEデータおよびバッファ・キャッシュ・ヒット率を調べる必要があります。

低いキャッシュ・ヒット率は、キャッシュのサイズを大きくすることがパフォーマンスに有益であることを意味しません。キャッシュ・ヒット率の高いことが、ワークロードに対してキャッシュが適切にサイズ設定されていることを示しているとはかぎりません。

バッファ・キャッシュ・ヒット率を解釈する場合は、次の点を考慮する必要があります。

� 大きな表や索引を繰り返しスキャンすると、キャッシュ・ヒット率を低下させる可能性があります。バッファ取得数が多く、頻繁に実行される SQL 文を調べて、実行計画が 適なものであるか確認します。可能であれば、1 つのパスですべての処理を実行するか、SQL文を 適化して、頻繁にアクセスされるデータを繰り返しスキャンしないようにします。

� 可能であれば、頻繁にアクセスされるデータをクライアント・プログラムまたは中間層にキャッシュして、同じデータを再問合せしないようにします。

� 長い全表スキャンでアクセスされた Oracle ブロックは、 低使用頻度（LRU）リストの後に配置され、リストの先頭には配置されません。このようにして、これらのブロックは、索引参照または小規模な表スキャンを実行するときに読み込まれるブロックよりも早く除去されます。バッファ・キャッシュ・データの解析では、有効な大規模全表スキャン時の低いヒット率についても考慮する必要があります。

� OLTP アプリケーションを実行するどの大容量データベースでも、常にほとんどの行は 1 回ないし 0 回しかアクセスされません。このことを基準に考えると、ブロックを使用後に長期間メモリーに保存することは、ほとんど意味がありません。

� バッファ・キャッシュ・サイズを継続して増やすことはよくある間違いです。全表スキャンや、バッファ・キャッシュを使用しない操作を実行している場合は、このように値を増やしても何の効果もありません。

関連項目関連項目関連項目関連項目 : ある期間内の統計の収集の詳細は、第 6 章「自動パフォーマンス診断」を参照してください。

関連項目関連項目関連項目関連項目 : V$SYSSTATビューの詳細は、『Oracle Database リファレンス』を参照してください。

注意注意注意注意 : 小規模表のスキャンは、一定のサイズのしきい値を使用して、表に対して実行されるスキャンです。小規模表とは、 大でバッファ・キャッシュの 2% か 20 のいずれかの、大きい方と定義されます。

メモリーの構成と使用方法 7-9

バッファ・キャッシュの構成と使用方法

バッファ・キャッシュに割り当てられたメモリーの増加バッファ・キャッシュに割り当てられたメモリーの増加バッファ・キャッシュに割り当てられたメモリーの増加バッファ・キャッシュに割り当てられたメモリーの増加一般規則として、キャッシュ・ヒット率が低く、全表スキャンを実行しないようにアプリケーションがチューニングされている場合は、キャッシュのサイズを増やすことを検討してください。

キャッシュ・サイズを増やすには、まず DB_CACHE_ADVICE初期化パラメータを ONに設定し、キャッシュ統計を安定させます。V$DB_CACHE_ADVICEビュー内のアドバイザ・データを調べて、実行する物理 I/O の量を大幅に減少させるために必要な次の増分を決定します。ホスト・オペレーティング・システムにページングさせずに必要な余分なメモリーをバッファ・キャッシュに割り当てることができる場合は、このメモリーを割り当てます。バッファ・キャッシュに割り当てられたメモリーの量を増やすには、DB_CACHE_SIZE初期化パラメータの値を増やします。

必要であれば、インスタンスをシャットダウンせずに、バッファ・プールを動的にサイズ変更してこの変更を行います。

DB_CACHE_SIZEパラメータは、データベースの標準ブロック・サイズのデフォルト・キャッシュのサイズを指定します。データベースの標準ブロック・サイズとは異なるブロック・サイズを持つ表領域を作成して使用するには（トランスポータブル表領域をサポートする場合など）、使用するブロック・サイズごとに個別のキャッシュを構成する必要があります。DB_nK_CACHE_SIZEパラメータを使用して、必要な標準以外のブロック・サイズを構成できます（n は 2、4、8、16 または 32 のいずれかで、n は標準ブロック・サイズではありません）。

バッファ・キャッシュに割り当てられたメモリーの削減バッファ・キャッシュに割り当てられたメモリーの削減バッファ・キャッシュに割り当てられたメモリーの削減バッファ・キャッシュに割り当てられたメモリーの削減キャッシュ・ヒット率が高い場合、キャッシュが十分大きく、 も頻繁にアクセスされるデータも保持できる状態になっています。V$DB_CACHE_ADVICEデータをチェックして、キャッシュ・サイズを削減すると物理 I/O 数が大幅に増えるかどうかを調べます。物理 I/O への影響がなければ、別のメモリー構造にメモリーを必要とする場合に、キャッシュ・サイズを削減しても、良好なパフォーマンスを維持できます。バッファ・キャッシュを小さくするには、DB_CACHE_SIZEパラメータの値を変更してキャッシュのサイズを削減します。

注意注意注意注意 : キャッシュを大幅に（20 パーセント以上）サイズ変更すると、古いキャッシュ・アドバイザ値は破棄されて、新しいサイズに設定されます。大幅にサイズ変更しない場合は、古いキャッシュ・アドバイザ値は既存の値を補間することで新しいサイズに調整されます。

注意注意注意注意 : キャッシュ・サイズを選択するプロセスは、キャッシュがデフォルトの標準ブロック・サイズ・キャッシュ、KEEPまたは RECYCLEキャッシュ、標準以外のブロック・サイズ・キャッシュのいずれかにかかわらず同様です。

関連項目関連項目関連項目関連項目 : DB_nK_CACHE_SIZEパラメータの使用方法の詳細は、『Oracle Database リファレンス』および『Oracle Database 管理者ガイド』を参照してください。

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文を発行する前にあったバッファ・プールに残ります。新たにロードされたブロック、および除去されて再ロードされたブロックは、新しいバッファ・プールに入ります。

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;

関連項目関連項目関連項目関連項目 : STORAGE句での BUFFER_POOLの指定については、『Oracle Database SQL 言語リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : V$BUFFER_POOL_STATISTICSビューの詳細は、『Oracle Database リファレンス』 を参照してください。

7-12 Oracle Database パフォーマンス・チューニング・ガイド

バッファ・キャッシュの構成と使用方法

プール内に多くのバッファを持つセグメントの判断プール内に多くのバッファを持つセグメントの判断プール内に多くのバッファを持つセグメントの判断プール内に多くのバッファを持つセグメントの判断V$BHビューは、SGA 内に現在常駐するすべてのブロックのデータ・オブジェクト ID を示します。プール内にバッファを多く持つセグメントを判断するには、この項で説明する 2 つの方法のいずれかを使用します。すべてのセグメントのバッファ・キャッシュ使用パターンを確認する（方法 1）か、特定のセグメントの使用パターンを調べます（方法 2）。

方法方法方法方法 1次の問合せでは、ある時点でバッファ・キャッシュ内に常駐するすべてのセグメントのブロック数をカウントします。バッファ・キャッシュ・サイズによっては、このカウントに多数のソート領域を必要とする可能性があります。

COLUMN OBJECT_NAME FORMAT A40COLUMN 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 1SYS_C002651 1..DS_PERSON 78OM_EXT_HEADER 701OM_SHELL 1,765OM_HEADER 5,826OM_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)]

KEEP プールプールプールプールアプリケーションに頻繁に参照されるセグメントがある場合は、KEEPバッファ・プールと呼ばれる個別のキャッシュにそれらのセグメントのブロックをキャッシュします。メモリーは、DB_KEEP_CACHE_SIZEパラメータを必要なサイズに設定することで KEEPバッファ・プールに割り当てられます。KEEPプールのメモリーは、デフォルト・プールのサブセットではありません。保持できる一般的なセグメントは、頻繁に使用される小さい参照表です。アプリケーション開発者と DBA は、どの表が候補かを判断できます。

7-13 ページの「プール内に多くのバッファを持つセグメントの判断」で説明するように、V$BHを問い合せて、候補表からブロック数をチェックできます。

KEEPバッファ・プールの目的は、メモリー内にオブジェクトを保存して、I/O 操作を避けることにあります。したがって、KEEPバッファ・プールのサイズは、バッファ・キャッシュに保持するオブジェクトによって異なります。KEEPバッファ・プールのおおよそのサイズは、このプールに割り当てられるすべてのオブジェクトで使用されるブロックを加算することで計算できます。セグメントに関する情報を収集する場合、DBA_TABLES.BLOCKSとDBA_TABLES.EMPTY_BLOCKSを問い合せて使用されるブロック数を判断できます。

ヒット率を計算するには、前述の問合せを使用してシステム・パフォーマンスの 2 つのスナップショットを時間をおいて取ります。物理読込み（physical reads）、ブロック取得

（block gets）および一貫取得（consistent gets）について、古い値から新しい値を引いて、これらの結果を使用してヒット率を計算します。

100% のバッファ・プール・ヒット率が 適とはかぎりません。KEEPバッファ・プールのサイズを減らしても、十分に高いヒット率が維持されることがよくあります。KEEPバッファ・プールから除去されたブロックは、別のバッファ・プールに割り当ててください。

各オブジェクトをメモリー内に保持するとトレードオフが発生します。頻繁にアクセスされるブロックをキャッシュに保持することは有効ですが、頻繁に使用しないブロックを保持すると、よりアクティブな他のブロックのためのスペースが減ることになります。

注意注意注意注意 : この手法は、1 つのセグメントに対してのみ有効です。パーティション・オブジェクトについては、パーティションごとに問合せを実行する必要があります。

注意注意注意注意 : NOCACHE句は、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 メモリーを区別することをお薦めします。

共有プールからのメモリーの割当ては、チャンクで行われます。このため、1 つの連続領域を必要とせずにラージ・オブジェクト（5KB より多い）をキャッシュにロードできるので、フラグメント化のために十分な連続メモリーが不足する可能性が減ります。

Java、PL/SQL または SQL の各カーソルが、まれに、5KB より大きい共有プールから割当てを行う場合があります。このような割当てを も効率よく行うために、Oracle では、少量の共有プールを区別しています。このメモリーは、共有プールに十分な領域がない場合に使用します。共有プールの区別された領域は予約プールと呼ばれます。

ディクショナリ・キャッシュの概念ディクショナリ・キャッシュの概念ディクショナリ・キャッシュの概念ディクショナリ・キャッシュの概念データ・ディクショナリ・キャッシュに格納されている情報には、ユーザー名、セグメント情報、プロファイル・データ、表領域情報および順序番号が含まれています。また、ディクショナリ・キャッシュはスキーマ・オブジェクトを説明する情報すなわちメタデータも格納します。メタデータが使用されるのは、SQL カーソルの解析時か PL/SQL プログラムのコンパイル時です。

ライブラリ・キャッシュの概念ライブラリ・キャッシュの概念ライブラリ・キャッシュの概念ライブラリ・キャッシュの概念ライブラリ・キャッシュは、SQL カーソル、PL/SQL プログラムおよび Java クラスの実行可能な形式を保持します。この項では、チューニングを中心に説明します。チューニングはカーソル、PL/SQL プログラムおよび Java クラスに関連するためです。これらをまとめてアプリケーション・コードと呼びます。

アプリケーション・コードを実行するとき、既存のコードが以前に実行されており、共有できる場合は、そのコードを再利用しようとします。解析された文の表現がライブラリ・キャッシュ内に存在し、共有できる場合は、既存のコードを再利用します。これは、ソフト解析またはライブラリ・キャッシュ・ヒットと呼ばれています。既存のコードを使用できない場合は、アプリケーション・コードの新しい実行可能バージョンを作成する必要があります。これは、ハード解析またはライブラリ・キャッシュ・ミスと呼ばれています。SQL 文と PL/SQL 文を共有できる場合の詳細は、7-17 ページの「SQL 共有基準」を参照してください。

ライブラリ・キャッシュ・ミスは、SQL 文を処理するときの解析ステップまたは実行ステップのいずれかで発生します。アプリケーションが SQL 文の解析コールを行うとき、解析された文の表現がライブラリ・キャッシュにまだ存在しない場合、Oracle はその文を解析し、共有プールに解析されたフォームを格納します。これはハード解析です。可能な場合は、すべての共有可能な SQL 文が共有プール内にあることを確認して、解析コールのライブラリ・キャッシュ・ミスを低減できます。

関連項目関連項目関連項目関連項目 : ラージ・プールの構成の詳細は、7-26 ページの「ラージ・プールの使用」を参照してください。

関連項目関連項目関連項目関連項目 : 共有プールの予約領域の詳細は、7-30 ページの「予約プールの構成」を参照してください。

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を使用する場合のコストと効果については、この項の後半で説明します。

4. 発行された文で参照されたオブジェクトは、共有プール内のすべての既存の文の参照済オブジェクトと比較され、両方のオブジェクトが同一であるかどうかが確認されます。

SQL 文や PL/SQL ブロック内でスキーマ・オブジェクトを参照する際には、同じスキーマ内の同じオブジェクトである必要があります。たとえば、2 人のユーザーが次の SQL 文を発行するとします。

SELECT * FROM employees;

各ユーザーに独自の employees表がある場合、文はユーザーごとに異なる表を参照するので、この文は同一とみなされません。

関連項目関連項目関連項目関連項目 : CURSOR_SHARINGパラメータの詳細は、『Oracle Database リファレンス』を参照してください。

メモリーの構成と使用方法 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 を使用することをお薦めします。バインド変数ではなくリテラル値を使用すると、オプティマイザは優れた列選択性の見積りを行えるので、 適なデータ・アクセス・プランを提供します。

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;

関連項目関連項目関連項目関連項目 : 『Oracle Database データ・ウェアハウス・ガイド』

7-18 Oracle Database パフォーマンス・チューニング・ガイド

共有プールとラージ・プールの構成および使用方法

� 多数のユーザーが動的な非共有の 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 は無効にされるため、以降の実行で再度解析されることになります。

注意注意注意注意 : バインド変数を使用するためにコードをリライトすることが実際的ではない既存のアプリケーションについては、CURSOR_SHARING初期化パラメータを使用してハード解析のオーバーヘッドをある程度回避できます。詳細は、7-32 ページの「既存のアプリケーション用の CURSOR_SHARING」を参照してください。

注意注意注意注意 : 拡張性の問題を克服するために、定義者権限パッケージの使用をお薦めします。ディクショナリ・キャッシュの負荷軽減の利点は、実行者権限パッケージの場合ほど顕著ではありません。

メモリーの構成と使用方法 7-19

共有プールとラージ・プールの構成および使用方法

キャッシュ順序番号キャッシュ順序番号キャッシュ順序番号キャッシュ順序番号頻繁に更新される順序番号に十分なキャッシュ領域を割り当てると、ディクショナリ・キャッシュ・ロックの回数が大幅に減るため、拡張性が向上します。CREATE SEQUENCE文またはALTER SEQUENCE文の CACHEキーワードを使用して、各順序のキャッシュ済エントリ数を構成できます。

カーソルのアクセスおよび管理カーソルのアクセスおよび管理カーソルのアクセスおよび管理カーソルのアクセスおよび管理使用している Oracle アプリケーション・ツールにより異なりますが、アプリケーションが解析コールを実行する頻度を制御できます。

アプリケーションが、カーソルをクローズする、または新しい SQL 文に既存のカーソルを再利用する頻度は、セッションで使用されるメモリー量と、時には、そのセッションで実行される解析の量にも影響を与えます。

（異なる SQL 文の）カーソルをクローズまたは再利用するアプリケーションは、カーソルをオープンした状態を保つアプリケーションほどセッション・メモリーを必要としません。逆に、そのようなアプリケーションでは、解析コールをより多く実行し、そのための追加の CPU および Oracle リソースを使用する可能性があります。

頻繁に実行されない SQL 文に関連するカーソルをクローズしたり、他の文に再利用できるのは、その文を再実行（および再解析）する可能性が低いからです。

再実行される SQL 文を含むカーソルがクローズまたは別の文に再利用される場合は、追加の解析コールが必要になります。カーソルがオープンされた状態であれば、解析コールを発行するためのオーバーヘッドを発生させずに、カーソルを再利用できます。

カーソルの管理を行う方法は、アプリケーション開発ツールにより異なります。次の項では、いくつかのツールで使用される方法を紹介します。

OCI による解析コールの低減による解析コールの低減による解析コールの低減による解析コールの低減 Oracle Call Interface（OCI）を使用する場合、再実行するカーソルはクローズおよび再オープンしないでください。そのかわりに、カーソルをオープンしたままにし、実行前にリテラル値をバインド変数に変更してください。

既存の SQL 文が今後再実行される場合は、新しい SQL 文に文ハンドルを再利用しないようにしてください。

Oracle プリコンパイラによる解析コールの低減プリコンパイラによる解析コールの低減プリコンパイラによる解析コールの低減プリコンパイラによる解析コールの低減 Oracle プリコンパイラを使用する場合、プリコンパイラ句を設定して、いつカーソルをクローズするかを制御できます。Oracle モードでは、プリコンパイラ句は次のとおりです。

� HOLD_CURSOR = YES

� RELEASE_CURSOR = NO

� MAXOPENCURSORS = 希望の値

ANSI モードでは、HOLD_CURSORと RELEASE_CURSORの値が切り替えられますが、これはお薦めしません。

プリコンパイラ句は、プリコンパイラ・コマンドライン上またはプリコンパイラ・プログラム内で指定できます。これらの句により、様々な方法で、プログラムの実行中にカーソルを管理できます。

関連項目関連項目関連項目関連項目 : CREATE SEQUENCE文および ALTER SEQUENCE文の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 :

� 各ツールの詳細は、ツール固有のマニュアルを参照してください。

� カーソル共有 SQL の詳細は、『Oracle Database 概要』を参照してください。

関連項目関連項目関連項目関連項目 : これらの句の詳細は、使用している言語のプリコンパイラ・マニュアルを参照してください。

7-20 Oracle Database パフォーマンス・チューニング・ガイド

共有プールとラージ・プールの構成および使用方法

SQLJ による解析コールの低減による解析コールの低減による解析コールの低減による解析コールの低減 文を用意し、バインド変数に新しい値を使用して文を再実行します。カーソルは、セッション中はオープンのままです。

JDBC による解析コールの低減による解析コールの低減による解析コールの低減による解析コールの低減 新しいリテラル値は、再実行のためにカーソルにバインドできるので、カーソルを再実行する場合は、カーソルをクローズしないでください。別の方法として、JDBC は setStmtCacheSize()メソッドを使用して JDBC クライアント内に SQL 文キャッシュを提供しています。このメソッドを使用して、JDBC は JDBC プログラムに対してローカルな SQL 文キャッシュを作成します。

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から問い合せることができます。空きメモリーは、システム上に再ロードを発生させない程度で、できるだけ小さい値である必要があります。

終的には、ライブラリ・キャッシュの全般的なインジケータは、ライブラリ・キャッシュ・ヒット率で表されます。この値は、この項で説明されているその他の統計、およびハード解析率や、共有プールまたはライブラリ・キャッシュのラッチ競合があるかどうかなどのその他のデータとともに考慮する必要があります

これらの統計の詳細は、次の項で説明します。

関連項目関連項目関連項目関連項目 : JDBC SQL 文キャッシュの使用方法の詳細は、『Oracle Database JDBC 開発者ガイドおよびリファレンス』を参照してください。

メモリーの構成と使用方法 7-21

共有プールとラージ・プールの構成および使用方法

V$LIBRARYCACHE動的パフォーマンス・ビュー V$LIBRARYCACHEを調べることで、ライブラリ・キャッシュのアクティビティを反映する統計を監視できます。これらの統計は、 新のインスタンス起動以降のライブラリ・キャッシュのアクティビティを反映しています。

このビューの各行には、ライブラリ・キャッシュ内に保持される項目の 1 つに対応する統計が収録されます。各行ごとに記述される項目は、NAMESPACE列の値によって識別されます。次のNAMESPACE値を持つ行は、SQL 文と PL/SQL ブロックのライブラリ・キャッシュのアクティビティを反映します。

� SQL AREA

� TABLE/PROCEDURE

� BODY

� TRIGGER

他の NAMESPACE値を持つ行は、Oracle が依存関係のメンテナンスのために使用するオブジェクト定義に対するライブラリ・キャッシュのアクティビティを反映します。

各 NAMESPACE を個々に調べるには、次の問合せを使用します。

SELECT NAMESPACE, PINS, PINHITS, RELOADS, INVALIDATIONS FROM V$LIBRARYCACHE ORDER BY NAMESPACE;

この問合せの出力例を次に示します。

NAMESPACE PINS PINHITS RELOADS INVALIDATIONS--------------- ---------- ---------- ---------- -------------BODY 8870 8819 0 0CLUSTER 393 380 0 0INDEX 29 0 0 0OBJECT 0 0 0 0PIPE 55265 55263 0 0SQL AREA 21536413 21520516 11204 2TABLE/PROCEDURE 10775684 10774401 0 0TRIGGER 1852 1844 0 0

ライブラリ・キャッシュ・ヒット率を計算するには、次の計算式を使用します。

Library Cache Hit Ratio = sum(pinhits) / sum(pins)

ライブラリ・キャッシュ・ヒット率の計算式を使用すると、キャッシュ・ヒット率は次のようになります。

SUM(PINHITS)/SUM(PINS)---------------------- .999466248

関連項目関連項目関連項目関連項目 : 動的パフォーマンス・ビュー V$LIBRARYCACHE の詳細は、『Oracle Database リファレンス』を参照してください。

注意注意注意注意 : これらの問合せでは、ある時間間隔で収集された統計ではなく、インスタンス起動時からのデータを戻します。時間間隔の統計の方が、より的確に問題を特定できます。

関連項目関連項目関連項目関連項目 : ある時間間隔の情報を収集する方法の詳細は、第 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 プールの現在のサイズによって異なります。

共有プール共有プール共有プール共有プール : ディクショナリ・キャッシュの統計ディクショナリ・キャッシュの統計ディクショナリ・キャッシュの統計ディクショナリ・キャッシュの統計共有プールがライブラリ・キャッシュに対して適切にサイズ設定されている場合、その設定はディクショナリ・キャッシュ・データに対しても適切であるのが普通です。

データ・ディクショナリ・キャッシュ・ミスは、いくつかの場合に予想されます。インスタンス起動時は、データ・ディクショナリ・キャッシュにデータは含まれていません。したがって、発行された SQL 文からキャッシュ・ミスが発生する可能性があります。キャッシュに読み込まれるデータが増えると、キャッシュ・ミスの可能性は減少します。 終的に、データベースは、も頻繁に使用されるディクショナリ・データがキャッシュ内に存在する安定状態に到達しま

す。この時点で、キャッシュ・ミスはほとんど発生しません。

V$ROWCACHEビューの各行は、データ・ディクショナリ項目について単一のタイプの統計を収録します。これらの統計は、直前のインスタンス起動以降のデータ・ディクショナリ・アクティビティを反映しています。データ・ディクショナリ・キャッシュの使用と有効性を反映する V$ROWCACHEビューの中の列を表 7-2 にリストします。

次の問合せによって、アプリケーションの実行中、ある期間にわたって V$ROWCACHEビューの統計を監視してください。導出された列 PCT_SUCC_GETSは、項目固有のヒット率と考えることができます。

column parameter format a21column pct_succ_gets format 999.9column updates format 999,999,999

SELECT parameter , sum(gets) , sum(getmisses) , 100*sum(gets - getmisses) / sum(gets) pct_succ_gets , sum(modifications) updates FROM V$ROWCACHE WHERE gets > 0 GROUP BY parameter;

関連項目関連項目関連項目関連項目 : 動的パフォーマンス・ビュー V$SHARED_POOL_ADVICE、V$LIBRARY_CACHE_MEMORY、V$JAVA_POOL_ADVICEおよびV$JAVA_LIBRARY_CACHE_MEMORYの詳細は、『Oracle Database リファレンス』を参照してください。

表表表表 7-2 V$ROWCACHE 列列列列

列列列列 説明説明説明説明

PARAMETER 特定のデータ・ディクショナリ項目を識別します。各行で、この列の値は接頭辞 dc_が付いた項目です。たとえば、ファイル記述の統

計を含む行では、この列の値は dc_filesです。

GETS 対応する項目に関する情報への要求の総数を示します。たとえば、ファイル記述の統計を含む行では、この列はファイル記述データへの要求の総数を持ちます。

GETMISSES キャッシュで満たされなかったデータ要求で、I/O を必要とするも

のの個数を示します。

MODIFICATIONS ディクショナリ・キャッシュ内のデータが更新された回数を示します。

7-24 Oracle Database パフォーマンス・チューニング・ガイド

共有プールとラージ・プールの構成および使用方法

この問合せの出力例を次に示します。

PARAMETER SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS UPDATES--------------------- ---------- -------------- ------------- ------------dc_database_links 81 1 98.8 0dc_free_extents 44876 20301 54.8 40,453dc_global_oids 42 9 78.6 0dc_histogram_defs 9419 651 93.1 0dc_object_ids 29854 239 99.2 52dc_objects 33600 590 98.2 53dc_profiles 19001 1 100.0 0dc_rollback_segments 47244 16 100.0 19dc_segments 100467 19042 81.0 40,272dc_sequence_grants 119 16 86.6 0dc_sequences 26973 16 99.9 26,811dc_synonyms 6617 168 97.5 0dc_tablespace_quotas 120 7 94.2 51dc_tablespaces 581248 10 100.0 0dc_used_extents 51418 20249 60.6 42,811dc_user_grants 76082 18 100.0 0dc_usernames 216860 12 100.0 0dc_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 は、ラージ・プールからオブジェクトを除去しようとしません。

インスタンスが次のいずれかを使用する場合は、ラージ・プールの構成を考慮してください。

� パラレル問合せ

パラレル問合せでは、共有プール・メモリーを使用してパラレル実行メッセージ・バッファをキャッシュします。

� Recovery Manager

Recovery Manager は、共有プールを使用してバックアップおよびリストア操作時に I/Oバッファをキャッシュします。I/O サーバー・プロセスと、バックアップおよびリストア操作では、Oracle は数百 KB 単位でバッファを割り当てます。

� 共有サーバー

共有サーバー・アーキテクチャでは、各クライアント・プロセスのセッション・メモリーが共有プールに含まれています。

共有サーバー・アーキテクチャでのラージ・プールと共有プールの共有サーバー・アーキテクチャでのラージ・プールと共有プールの共有サーバー・アーキテクチャでのラージ・プールと共有プールの共有サーバー・アーキテクチャでのラージ・プールと共有プールのチューニングチューニングチューニングチューニングOracle では共有サーバー・セッション・メモリーに共有プールからメモリーを割り当てるため、ライブラリ・キャッシュとディクショナリ・キャッシュに使用可能な共有プール・メモリーの量が減少します。別のプールからこのセッション・メモリーを割り当てると、Oracle は、主に共有 SQL のキャッシングのために共有プールを使用できるので、共有 SQL キャッシュの減少によるパフォーマンス・オーバーヘッドは発生しません。

共有サーバー関連のユーザー・グローバル領域（UGA）の割当てには、共有プールではなくラージ・プールの使用をお薦めします。共有プールは、Oracle によって、共有 SQL や PL/SQLプロシージャなど、他の目的のシステム・グローバル領域（SGA）メモリー用に割り当てられ

関連項目関連項目関連項目関連項目 : パラレル問合せによるラージ・プールのサイズ設定の詳細は、『Oracle Database データ・ウェアハウス・ガイド』 を参照してください。

関連項目関連項目関連項目関連項目 : Recovery Manager を使用する場合のラージ・プールのサイズ設定の詳細は、『Oracle Database Recovery Manager リファレンス』を参照してください。

7-26 Oracle Database パフォーマンス・チューニング・ガイド

共有プールとラージ・プールの構成および使用方法

るためです。共有プールのかわりにラージ・プールを使用すると、共有プールの断片化も減少します。

ラージ・プールに共有サーバー関連の UGA を格納するには、初期化パラメータLARGE_POOL_SIZEに値を指定します。どのプール（共有プールまたはラージ・プール）にオブジェクト用のメモリーが存在するかを確認するには、V$SGASTATで列 POOLをチェックします。ラージ・プールはデフォルトで構成されません。 小値は 300KB です。ラージ・プールを構成しないと、共有サーバー・ユーザー・セッション・メモリーに共有プールが使用されます。

ラージ・プールの大きさは、同時にアクティブとなるセッションの数を基準に構成します。各アプリケーションは、必要なセッション情報メモリー量がそれぞれ異なり、ラージ・プールあるいは SGA の構成はメモリー要件を反映する必要があります。たとえば、アクティブな各セッションのセッション情報を格納するために共有サーバーが 200 ～ 300KB を必要とすると仮定します。100 個のセッションが同時にアクティブになると予想される場合、30MB のラージ・プールを構成するか、ラージ・プールを構成しない場合は、共有プールを増やしてください。

共有サーバーの共有サーバーの共有サーバーの共有サーバーの UGA 記憶域のための効果的な設定の判別記憶域のための効果的な設定の判別記憶域のための効果的な設定の判別記憶域のための効果的な設定の判別 Oracle が使用する UGA の厳密な容量は、各アプリケーションによって異なります。ラージ・プールまたは共有プールの効果的な設定を判別するには、一般的なユーザーでの UGA の使用状況を観察して、その容量をユーザー・セッションの見積り数に乗算します。

共有サーバーの使用により共有メモリーの使用が増加するとしても、合計のメモリー使用量は減少します。これは、プロセス数が減少するので、専用サーバー環境と比較した場合に共有サーバーでは PGA メモリーの使用量が減るためです。

V$SESSTAT ビューでのシステム統計のチェックビューでのシステム統計のチェックビューでのシステム統計のチェックビューでのシステム統計のチェック Oracle では、セッションに使用された全メモリーの統計が収集され、動的パフォーマンス・ビュー V$SESSTATに格納されます。表 7-3 はこれらの統計をリストしたものです。

注意注意注意注意 : 共有サーバー・アーキテクチャを使用する場合、ラージ・プールを構成した場合でも、Oracle によって各構成セッションに一定量のメモリー（約 10KB）が共有プールから割り当てられます。CIRCUITS初期化パラメータは、データベースで許可される同時共有サーバー接続 大数を指定します。

関連項目関連項目関連項目関連項目 :

� ラージ・プールの詳細は、『Oracle Database 概要』を参照してください。

� 初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

注意注意注意注意 : 共有サーバーを使用したソートのパフォーマンスを 高にするには、SORT_AREA_SIZEと SORT_AREA_RETAINED_SIZEを同じ値に設定します。これによって、ソート結果をディスクに書き込むのではなくラージ・プールに留めておきます。

表表表表 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 消費量の制限は行わないため、このパラメータを使用することはほとんどありません。

3 層の接続でのメモリー使用の低減層の接続でのメモリー使用の低減層の接続でのメモリー使用の低減層の接続でのメモリー使用の低減 接続ユーザーが非常に多数の場合は、3 層の接続を実装することでメモリー使用を低減できます。これはトランザクション処理（TP）モニター使用の副産物であり、ロックやコミットされていない DML を複数のコールにわたって保持できないため、純粋なトランザクション・モデルでしか実現できません。共有サーバー環境には次の利点があります。

� TP モニターに比べてアプリケーション設計の制限が大幅に少なくなります。

� ユーザーがサーバーのプールを共有できるので、オペレーティング・システム・プロセス数とコンテキストの切替えが大幅に減ります。

� 共有サーバー・モードでさらに多くの SGA が使用される場合でも総メモリー使用量が大幅に減ります。

関連項目関連項目関連項目関連項目 : PRIVATE_SGAリソース制限の設定の詳細は、『Oracle Database SQL 言語リファレンス』の「ALTER RESOURCE COST文」を参照してください。

7-28 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の値も同じだけ増やします。

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 オブジェクトがロードされる場合で、領域を確保するために小さなオブジェクトを共有プールから除去する必要がある場合は、ユーザーの応答時間に影響が現れます。場合によっては、このような大きなオブジェクトをロードするには、メモリーが十分でないこともあります。

� 頻繁に実行されるトリガー。頻繁に使用する表のコンパイル済トリガーを共有プール内に維持できます。

関連項目関連項目関連項目関連項目 : LARGE_POOL_SIZEパラメータ設定の詳細は、『Oracle Database リファレンス』を参照してください。

メモリーの構成と使用方法 7-31

共有プールとラージ・プールの構成および使用方法

� DBMS_SHARED_POOLが順序もサポートする場合。共有プールから順序が除去されると、順序番号が失われます。DBMS_SHARED_POOLは、共有プール内に順序を保持し、順序番号の消失を防ぎます。

DBMS_SHARED_POOLパッケージを使用して SQL 領域または PL/SQL 領域を確保するには、次の手順を実行してください。

1. メモリー内に確保しておくパッケージまたはカーソルを決定します。

2. データベースを起動します。

3. DBMS_SHARED_POOL.KEEPをコールしてオブジェクトを確保します。

この手順により、保存されているオブジェクトがロードされる前にシステムの共有メモリーが使用し尽くされないことが保証されます。その結果、オブジェクトをインスタンスの早い時期に確保することにより、大きなメモリー領域を共有プールの中央に確保するために発生する可能性のある、メモリーの断片化を防ぐことができます。

既存のアプリケーション用の既存のアプリケーション用の既存のアプリケーション用の既存のアプリケーション用の CURSOR_SHARING解析の第 1 段階の 1 つは、文のテキストを共有プール内の既存の文と比較して、その文を共有できるかどうかを確認することです。文をテキストとして比較し、なんらかの点で異なる場合は、文は共有されません。

例外は、CURSOR_SHARINGパラメータが SIMILARまたは FORCEに設定されている場合です。このパラメータを使用する場合、まず共有プールがチェックされ、共有プールに同一の文があるかどうかが確認されます。同一の文が検出されないと、共有プール内で類似する文が検索されます。類似する文があると、解析チェックが引き続き行われ、カーソルの実行可能フォームを使用できるかどうかが検証されます。文がない場合は、文の実行可能フォームを生成するためにハード解析が必要になります。

類似類似類似類似 SQL 文文文文いくつかのリテラル値以外が同一である文は、類似文と呼ばれます。CURSOR_SHARINGパラメータが SIMILARまたは FORCEに設定されると、類似文は解析フェーズでテキスト・チェックを省略します。テキストの類似性では、共有は保証されません。SQL 文の新しいフォームでは、解析フェーズの残りのステップを実行して、既存の文の実行計画が新しい文にも同じように適用できるかどうかを確認する必要があります。

CURSOR_SHARINGCURSOR_SHARINGを EXACTに設定すると、SQL 文はテキストがまったく同一の場合にのみSQL 領域を共有できます。これはデフォルトの動作です。この設定では、類似文は共有できません。テキストとしての完全に同一の文のみ共有できます。

CURSOR_SHARINGを SIMILARまたは FORCEに設定すると、類似文が SQL を共有できます。SIMILARと FORCEの違いは、実行計画を機能低下させることなく SIMILARが類似する文にSQL 領域を共有させるという点です。CURSOR_SHARINGを FORCEに設定すると、類似文に実行可能な SQL 領域を共有するように強制します。この方法には、潜在的に実行計画の機能を低下させる可能性があります。したがって、計画が 適なものではなくなる可能性があってもカーソル共有率の向上を優先する場合に、FORCEを 後の手段として使用してください。

関連項目関連項目関連項目関連項目 : DBMS_SHARED_POOLプロシージャの使用方法の詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : 実行される各種チェックの詳細は、7-17 ページの「SQL 共有基準」を参照してください。

7-32 Oracle Database パフォーマンス・チューニング・ガイド

共有プールとラージ・プールの構成および使用方法

CURSOR_SHARING を使用する場合を使用する場合を使用する場合を使用する場合CURSOR_SHARING初期化パラメータにより一部のパフォーマンス問題を解決できる場合があります。初期化パラメータには、FORCE、SIMILARおよび EXACT（デフォルト）の値があります。このパラメータの使用は、多数の類似 SQL 文を持つ既存のアプリケーションにとっては有益です。

適な解決方法は、CURSOR_SHARINGパラメータに依存するのではなく、共有可能な SQL を書くことです。これは、CURSOR_SHARINGによってハード解析がなくなる分、使用されるリソース量は大幅に削減されますが、共有プール内で類似文を検索するために、ソフト解析の一部としてある程度の追加作業が必要になるからです。

次の質問の両方に該当する場合は、CURSOR_SHARINGを SIMILARまたは FORCEに設定することを考慮してください。

1. 共有プール内にリテラルの値のみが異なる文がありますか。

2. 応答時間は、ライブラリ・キャッシュ・ミス数が非常に多いために遅くなっていますか。

CURSOR_SHARING = SIMILAR（または FORCE）を使用すると、多数の類似文を持ついくつかのアプリケーション上でのカーソルの共有を大幅に向上できるため、メモリー使用量が削減され、解析が高速になり、ラッチ競合が減少します。

接続の維持接続の維持接続の維持接続の維持中間層を持つ大きな OLTP アプリケーションでは、データベース要求ごとに接続と切断を行うのではなく、接続を維持するようにします。永続的な接続を維持することで、ラッチなどのCPU リソースとデータベース・リソースが節約されます。

注意注意注意注意 : 複雑な問合せを使用している場合は、DSS 環境でCURSOR_SHARINGを FORCEに設定することはお薦めしません。また、CURSOR_SHARINGが SIMILARまたは FORCEに設定されると、スター型変換はサポートされません。 詳細は、13-5 ページの「問合せオプティマイザ機能の有効化」を参照してください。

注意注意注意注意 : CURSOR_SHARINGを SIMILARまたは FORCEに設定すると、（SELECT文に指定した）リテラルを含む選択された式の 大長（DESCRIBEからの戻り値）が増加します。ただし、戻されたデータの実際の長さは変わりません。

注意注意注意注意 : CURSOR_SHARINGを FORCEまたは SIMILARに設定すると、CURSOR_SHARINGが EXACTに設定された状態で生成されたリテラルを持つアウトラインは使用されません。

CURSOR_SHARING=FORCEまたは SIMILARでストアド・アウトラインを使用するには、FORCEまたは SIMILARに設定された CURSOR_SHARINGでアウトラインを生成するか、CREATE_STORED_OUTLINESパラメータでアウトラインを生成する必要があります。

関連項目関連項目関連項目関連項目 : 重要なオペレーティング・システム統計の説明は、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 メモリー領域内に、そのカーソルのための新しいランタイム領域が作成されます。

複雑な問合せ（たとえば、意思決定支援の問合せ）の場合、ランタイム領域の大部分が、次のようなメモリー集約型演算子で割り当てられた作業領域に使用されます。

� ソート・ベース演算子（たとえば、ORDER BY、GROUP BY、ROLLUPおよびウィンドウ機能）

� ハッシュ結合

� ビットマップ・マージ

注意注意注意注意 : ランタイム領域の一部は、共有サーバーを使用するときに SGA 内に配置できます。

メモリーの構成と使用方法 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 の初期設定

� 自動 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）までを使用できます。

関連項目関連項目関連項目関連項目 : PGA_AGGREGATE_TARGET初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

メモリーの構成と使用方法 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 bytesaggregate PGA auto target 21823488 bytesglobal memory bound 2057216 bytestotal PGA inuse 16899072 bytestotal PGA allocated 35014656 bytesmaximum PGA allocated 136795136 bytestotal freeable PGA memory 524288 bytesPGA memory freed back to OS 1713242112 bytestotal PGA used for auto workareas 0 bytesmaximum PGA used for auto workareas 2383872 bytestotal PGA used for manual workareas 0 bytesmaximum PGA used for manual workareas 8470528 bytesover allocation count 291bytes processed 2124600320 bytesextra bytes read/written 39949312 bytescache hit percentage 98.15 percent

V$PGASTATに表示される主な統計は次のとおりです。

� aggregate PGA target parameter: これは初期化パラメータPGA_AGGREGATE_TARGETの現在の値です。デフォルト値は、SGA サイズの 20% です。このパラメータを 0（ゼロ）に設定すると、PGA メモリーの自動管理は無効になります。

� aggregate PGA auto target: 自動モードで実行する作業領域に使用できる PGA メモリーの量を示します。この量は、PGA_AGGREGATE_TARGETパラメータの値と現在の作業領域のワークロードから導出されます。したがって、Oracle で継続的に調整されます。この値が PGA_AGGREGATE_TARGETと比べて小さい場合、多くの PGA メモリーがシステムの他のコンポーネント（たとえば、PL/SQL や Java メモリー）で使用され、ソート作業領域にはメモリーがほとんど残されていません。自動モードで実行される作業領域には十分な PGA メモリーが残されている必要があります。

7-38 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 0oracle@dlsun1690 (PMON) 314540 685860 0 685860oracle@dlsun1690 (MMAN) 313992 685860 0 685860oracle@dlsun1690 (DBW0) 696720 1063112 0 1063112oracle@dlsun1690 (LGWR) 10835108 22967940 0 22967940oracle@dlsun1690 (CKPT) 352716 710376 0 710376oracle@dlsun1690 (SMON) 541508 948004 0 1603364oracle@dlsun1690 (RECO) 323688 685860 0 816932oracle@dlsun1690 (q001) 233508 585128 0 585128oracle@dlsun1690 (QMNC) 314332 685860 0 685860oracle@dlsun1690 (MMON) 885756 1996548 393216 1996548oracle@dlsun1690 (MMNL) 315068 685860 0 685860oracle@dlsun1690 (q000) 330872 716200 65536 716200oracle@dlsun1690 (TNS V1-V3) 635768 928024 0 1255704oracle@dlsun1690 (CJQ0) 533476 1013540 0 1144612oracle@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$SQL_WORKAREA_HISTOGRAM このビューには、インスタンス起動後に、 適なメモリー・サイズ、ワン・パス・メモリー・サイズおよびマルチ・パス・メモリー・サイズで実行された作業領域の総数を示します。このビューの統計は、作業領域の 適なメモリー要件によって定義されるバケットに副分割されます。各バケットは、列 LOW_OPTIMAL_SIZEおよびHIGH_OPTIMAL_SIZEの値で指定された 適メモリー要件の範囲によって識別されます。

関連項目関連項目関連項目関連項目 : V$PROCESS_MEMORYビューの詳細は、『Oracle Database リファレンス』を参照してください。

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 0131072 262144 0 44 0262144 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_percFROM (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 workarea_address, operation_type, policy, estimated_optimal_size FROM V$SQL_WORKAREA ORDER BY estimated_optimal_size ) WHERE ROWNUM <= 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 a10col name format a20SELECT 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 OPTIONS NAME input(MB) LAST_MEM OPTIMAL_ME ONEPASS_ME O/1/M ------------ -------- -------- --------- -------- ---------- ---------- ------SELECT STATE HASH GROUP BY 4582 8 16 16 16/0/0HASH JOIN SEMI 4582 5976 5194 2187 16/0/0TABLE ACCESS FULL ORDERS 51 TABLE ACCESS FUL LINEITEM 1000

アドレスおよびハッシュ値は、問合せでパターンを指定することにより 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の変更時にリセットされます。

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 CACHE_HIT_PERC ESTD_OVERALLOC_COUNT---------- -------------- -------------------- 63 23 367 125 24 30 250 30 3 375 39 0 500 58 0 600 59 0 700 59 0

注意注意注意注意 : シミュレーションに実際の実行のすべての要素を含めることはできません。したがって、導出された統計が、実際のパフォーマンス統計に完全には一致しない場合があります。PGA_AGGREGATE_TARGETを変更した後は、常にシステムを監視して、新しいパフォーマンスが予測どおりであるかどうかを確認してください。

7-44 Oracle Database パフォーマンス・チューニング・ガイド

PGA メモリー管理

800 60 0 900 60 0 1000 61 0 1500 67 0 2000 76 0 3000 83 0 4000 85 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 メモリー管理

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 から取得できない場合は、システムへの物理メモリーの追加を検討します。

PGA_AGGREGATE_TARGET のチューニング方法のチューニング方法のチューニング方法のチューニング方法 PGA_AGGREGATE_TARGETをチューニングする場合は、チューニング・ガイドラインとして次の手順に従います。

1. メモリーが過剰割当てされないよう PGA_AGGREGATE_TARGETを設定します。過剰割当てゾーンに設定しないでください。例 7-8 では、PGA_AGGREGATE_TARGETは 低 375MB に設定する必要があります。

2. 過剰割当てを解消した後、応答時間の要件およびメモリーの制約に基づいて PGA cache hit percentageを極力 大化します。例 7-8 では、PGA に割当て可能なメモリーに制限X があると仮定しています。

� この制限 X が 適値を超過している場合は、PGA_AGGREGATE_TARGETを 適値に設定します。この時点では、PGA_AGGREGATE_TARGETへのメモリー割当ての増加に伴う有益性はごくわずかです。例 7-8 で 10GB を PGA 専用とする場合は、PGA_AGGREGATE_TARGETを 適値である 3GB に設定します。残りの 7GB は SGA 専用となります。

� 制限 X が 適値より小さい場合は、PGA_AGGREGATE_TARGETを X に設定します。例7-8 で 2GB のみを PGA 専用とする場合は、PGA_AGGREGATE_TARGETを 2GB に設定し、cache hit percentage 75% を受け入れます。

注意注意注意注意 : PGA cache hit percentageの理論的な 大値が 100% の場合でも、作業領域の実際の 大サイズには制限があります。したがって、PGA_AGGREGATE_TARGETの値をさらに増やしても、理論的な 大値に達しない場合があります。これが発生するのは、 適メモリー要件が大きく、cache hit percentageの値が低いヒット率（90% など）に下がる可能性のある大規模 DSS システムのみです。

関連項目関連項目関連項目関連項目 :

� 7-23 ページ「共有プールのアドバイザ統計」

� 7-6 ページ「バッファ・キャッシュのサイズ設定」

7-46 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 HIGH_KB ESTD_OPTIMAL_CNT ESTD_ONEPASS_CNT ESTD_MPASS_CNT------ ------- ---------------- ---------------- -------------- 8 16 156107 0 0 16 32 148 0 0 32 64 89 0 0 64 128 13 0 0 128 256 58 0 0 256 512 10 0 0 512 1024 653 0 0 1024 2048 530 0 0 2048 4096 509 0 0 4096 8192 227 0 0 8192 16384 176 0 0 16384 32768 133 16 0 32768 65536 66 103 0 65536 131072 15 47 0131072 262144 0 48 0262144 524288 0 23 0

この出力は、PGA_AGGREGATE_TARGETを 2 のべき乗で増加させると、16MB 未満のすべての作業領域を 適モードで実行できることを示しています。

関連項目関連項目関連項目関連項目 : 『Oracle Database リファレンス』

メモリーの構成と使用方法 7-47

PGA メモリー管理

V$SYSSTAT およびおよびおよびおよび V$SESSTATV$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 95workarea executions - onepass 284 5workarea 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 パフォーマンス・チューニング・ガイド

I/O 構成および

8

I/O 構成および設計構成および設計構成および設計構成および設計

I/O サブシステムは、Oracle データベースに不可欠なコンポーネントです。基本的な 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 です。ストライプ深度によって、得られるアプリケーションの利点の種類が異なります。 適なストライプ深度およびストライプ幅は、次の項目により異なります。

� 要求された I/O サイズ

� I/O リクエストの同時実行性

� 物理ストライプ境界とブロック・サイズ境界との位置合せ

� 提案されたシステムの管理可能性

8-2 Oracle Database パフォーマンス・チューニング・ガイド

I/O の基本構成

要求された要求された要求された要求された I/O サイズサイズサイズサイズ表 8-1 に、I/O サイズの設定で使用できる Oracle およびオペレーティング・システムのパラメータを示します。

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 を発行する個々のプロセスが多数存在するためです。粗密なストライプ化は、同時要求が少ないシステムで使用されると、ホット・スポットが生成される可能性があります。

表表表表 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 構成および設計 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 に、ランダム・アクセスおよび順次読取りでお薦めする小ストライプ深度を示します。

提案されたシステムの管理可能性提案されたシステムの管理可能性提案されたシステムの管理可能性提案されたシステムの管理可能性LVM の場合、 も管理の簡単な構成は、使用可能なすべてのディスク上に単一ストライプ化ボリュームを構成したものです。この場合、ストライプ幅はすべての使用可能なディスクを包含します。すべてのデータベース・ファイルはそのボリューム内に常駐し、効果的に負荷を均等分散します。この単一ボリューム・レイアウトは、ほとんどの状況で適切なパフォーマンスを実現します。

単一ボリューム構成は、RAID 1 などの簡単なリカバリを可能にする RAID 技術と併用する場合のみ有効です。それ以外の場合、単一のディスクを失うことはすべてのファイルを同時に失うことであり、完全なデータベースのリストアおよびリカバリを実行する必要があることを意味します。

パフォーマンスの他に、管理性の問題があります。システムの設計で、ディスクを簡単に追加できるようにして、データベースの拡張を可能にする必要があります。課題は、負荷のバランスを維持しながら拡張を行うことです。

たとえば、初期構成で、64 個の 16GB のディスク上に単一ストライプ化ボリュームを作成する必要があるとします。これはプライマリ・データの 1TB の合計ディスク領域になります。場合によっては、システムが動作した後に、将来のデータベース拡張を可能にするためにさらに80GB（すなわち、5 つのディスク）を追加する必要があります。

この領域をデータベースで使用できるようにするオプションには、5 つの新しいディスクを含む第 2 のボリュームの作成があります。ただし、これらの新しいディスクがその上に配置されたファイルに必要な I/O スループットを保持できない場合、I/O ボトルネックが発生する可能性があります。

もう 1 つのオプションは、元のボリュームのサイズを増やすことです。LVM は高度になりつつあり、ストライプ幅の動的な再構成を可能にするので、システムがオンライン中にディスクを

表表表表 8-2 最小ストライプ深度最小ストライプ深度最小ストライプ深度最小ストライプ深度

ディスク・アクセスディスク・アクセスディスク・アクセスディスク・アクセス 最小ストライプ深度最小ストライプ深度最小ストライプ深度最小ストライプ深度

ランダム読込みおよび書込み 小ストライプ深度は、Oracle ブロック・サイズの 2 倍です。

順次読取り 小ストライプ深度は、Oracle ブロック・サイズを乗算した

DB_FILE_MULTIBLOCK_READ_COUNTの値の 2 倍です。

関連項目関連項目関連項目関連項目 : プラットフォームの固有のマニュアル

8-4 Oracle Database パフォーマンス・チューニング・ガイド

I/O の基本構成

追加できます。このため、本番環境で単一ストライプ化ボリューム上にすべてのファイルを配置できるようになってきました。

LVM がストライプへのディスクの動的な追加をサポートできない場合は、より小さく管理しやすいストライプ幅を選択する必要があります。そのようにすると、新しいディスクを追加する場合、ストライプ幅だけシステムを拡張できます。

前述の例で、8 個のディスクがより管理しやすいストライプ幅といえます。これは、8 個のディスクで 1 秒間に必要な数の I/O を維持できる場合のみ可能です。したがって、追加のディスク領域が必要なときは、別の 8 ディスク・ストライプを追加して、ボリューム間で 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 率を持つファイルを識別します。

注意注意注意注意 : ストライプ幅が小さくなるほど、ボリューム上にファイルを分散する時間の必要性が高くなり、このプロシージャは手動による 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 の多いファイルの分離を考慮してください。

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 メンバーを分散する方法を示しています。

関連項目関連項目関連項目関連項目 : 11-3 ページ「高負荷 SQL の識別」

8-6 Oracle Database パフォーマンス・チューニング・ガイド

I/O の基本構成

図図図図 8-1 ディスク間でのディスク間でのディスク間でのディスク間での REDO メンバーの分散メンバーの分散メンバーの分散メンバーの分散

この例では、LGWR はログ・グループ 1（メンバー 1a と 1b）から切り替えられ、ログ・グループ 2（2a と 2b）に書込みを行います。同時に、アーカイバ・プロセスはグループ 1 から読込みをして、アーカイブ先に書込みを行います。REDO ログ・ファイルがどのようにして競合から分離されているかに注意してください。

REDO ログはシリアルに書き込まれるので、REDO ログ・アクティビティ専用のドライブでは一般にヘッドの移動はわずかです。このため、ログ書込みのスピードが大幅に向上します。

3 つの構成サンプルつの構成サンプルつの構成サンプルつの構成サンプルこの項では、I/O システムを構成する高水準の例を 3 つ示します。これらの例には、ディスク・トポロジやストライプ深度などを定義する計算例が含まれています。

すべてのディスクにまたがったすべての内容のストライプ化すべてのディスクにまたがったすべての内容のストライプ化すべてのディスクにまたがったすべての内容のストライプ化すべてのディスクにまたがったすべての内容のストライプ化I/O 構成の も簡単なアプローチは、すべての使用可能ディスクにまたがってストライプ化された、1 つの大きなボリュームを作成することです。リカバリ能力を考慮して、ボリュームがミラー化されます（RAID 1）。ディスク当たりのストライプ化の単位は、頻繁な I/O 操作のための 大 I/O サイズより大きくする必要があります。そうすると、ほとんどの場合は十分なパフォーマンスが得られます。

異なるディスクへのアーカイブ・ログの移動異なるディスクへのアーカイブ・ログの移動異なるディスクへのアーカイブ・ログの移動異なるディスクへのアーカイブ・ログの移動アーカイブ・ログが他のファイルと同じディスク・セット上でストライプ化されている場合、REDO ログがアーカイブされる際、これらのディスク上の I/O リクエストが影響を受けるおそれがあります。個別のディスクにアーカイブ・ログを移動する場合の利点は次のとおりです。

� 非常に高速なアーカイブを実行できます（順次 I/O を使用）。

� アーカイブ先のディスク上で応答時間が低下しても、その影響を受けるものは他にありません。

アーカイブ・ログ用のディスク数は、アーカイブ・ログ生成頻度およびアーカイブ記憶域の必要量により決定されます。

注意注意注意注意 : REDO ログ・ファイルをミラー化する、すなわち各 REDO ログ・ファイルの複数のコピーを別々のディスク上に保持することで、LGWR が大幅に遅くはなりません。LGWR は、各ディスクに対して並列して書込みを行い、並列書込みの各部が完了するまで待機します。したがって、並列書込みが、 も長い単一のディスク書込みよりも長くなることはありません。

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 のチューニングのチューニングのチューニングのチューニングOracle Managed Files をチューニングする場合はいくつかの点に注意する必要があります。

� Oracle Managed Files ではファイル・システムを使用する必要があるため、DBA はデータのレイアウト方法は管理しません。したがって、ファイル・システムを正しく構成することが重要です。

� Oracle Managed Files システムは、ストライプ化をサポートする LVM 上に構築する必要があります。ロード・バランシングおよびスループットの向上のために、Oracle Managed Files システム内のディスクをストライプ化する必要があります。

� Oracle Managed Files は、動的に拡張可能な論理ボリュームをサポートする LVM 上で使用するときに 高の機能を発揮します。それ以外の場合は、論理ボリュームをできるだけ大きく構成する必要があります。

� Oracle Managed Files は、ファイル・システムに大きな拡張可能なファイルがある場合、高の機能を発揮します。

注意注意注意注意 : Oracle Managed Files は、RAW デバイスでは使用できません。

関連項目関連項目関連項目関連項目 : 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 ブロック当たりの格納行数が

わずかになったり、さらには行の連鎖が発生する可能性があります。

大きい オーバーヘッドが少ないため、データを格納する空間が多くなります。

1 回の I/O でバッファ・キャッシュに多

数の行を読み込めます（行サイズおよびブロック・サイズにより異なります）。

順次アクセスまたは非常に大きな行（LOB データなど）に適しています。

ブロック・サイズが大きい場合に少数の行にランダム・アクセスすると、バッファ・キャッシュ内の領域が消費されます。たとえば、8KB のブロック・サ

イズと 50 バイトの行サイズでは、ランダム・アクセ

スを行うときにバッファ・キャッシュ内の 7,950 バイ

トが消費されます。

OLTP 環境で使用される索引ブロックには適しませ

ん。これは、索引リーフ・ブロック上のブロック競合が増えるためです。

8-10 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 プロセスの管理は、サポートされません。インスタンスの破壊などの重大な結果が発生します。

関連項目関連項目関連項目関連項目 :

� オペレーティング・システムのリソース・マネージャ、および Oracleと Oracle Database Resource Manager と併用して動作するリソース割当て / 割当て解除機能の全リストについては、システム・ベンダーおよび Oracle の代理店にお問い合せください。Oracle は特定リリース・レベルとこれらのシステム機能との互換性を保証しません。

� Oracle Database Resource Manager の詳細は、『Oracle Database 管理者ガイド』を参照してください。

9-4 Oracle Database パフォーマンス・チューニング・ガイド

オペレーティング・システムの問題の解決

オペレーティング・システムの問題の解決オペレーティング・システムの問題の解決オペレーティング・システムの問題の解決オペレーティング・システムの問題の解決この項では、様々なシステムでのチューニングのヒントを示します。次の項目について説明します。

� UNIX ベースのシステムのパフォーマンスに関するヒント

� Windows システムのパフォーマンスに関するヒント

� HP OpenVMS システムのパフォーマンスに関するヒント

プラットフォーム固有の問題をよく理解し、使用しているオペレーティング・システムが提供するパフォーマンス・オプションを認識してください。

UNIX ベースのシステムのパフォーマンスに関するヒントベースのシステムのパフォーマンスに関するヒントベースのシステムのパフォーマンスに関するヒントベースのシステムのパフォーマンスに関するヒントUNIX システムでは、オペレーティング・システムが費やす時間量（システム・コールの処理およびプロセス・スケジューリングの実行）とアプリケーションが実行する時間量の妥当な比率を確立するようにしてください。システム・モードではなく、アプリケーション・モード

（ユーザー・モードとも呼ばれる）での実行に大部分の時間を費やすことを目標としてください。

各モードで消費される時間の比率は、潜在する問題の徴候にすぎず、次の項目に関係している可能性があります。

� ページングまたはスワッピング

� 実行しているオペレーティング・システム・コールが多すぎる状態

� 実行しているプロセスが多すぎる状態

このような条件が存在する場合は、アプリケーションの実行に使用できる時間は少なくなります。オペレーティング・システム側の時間を多く解放するほど、アプリケーションが実行できるトランザクションの量が増えます。

Windows システムのパフォーマンスに関するヒントシステムのパフォーマンスに関するヒントシステムのパフォーマンスに関するヒントシステムのパフォーマンスに関するヒントUNIX ベースのシステムと同様に、Windows システムでは、アプリケーション・モードの時間とシステム・モードの時間の比率を適切に設定してください。Windows 管理パフォーマンス・ツールで多数の要因を容易に監視できます。CPU、ネットワーク、I/O およびメモリーはすべて、これらの領域でのボトルネックを容易に回避できるように同じグラフ上に表示されます。

HP OpenVMS システムのパフォーマンスに関するヒントシステムのパフォーマンスに関するヒントシステムのパフォーマンスに関するヒントシステムのパフォーマンスに関するヒントメインフレームのページング・パラメータを検討し、Oracle がパラメータの非常に大きな作業セットを利用できることを覚えておいてください。

HP OpenVMS 環境での空きメモリーは、どのオペレーティング・システム・プロセスにも実際にマップされていないメモリーです。ビジーなシステムでは、1 つ以上の現行のアクティブ・プロセスに属するページを空きメモリーが含むことがよくあります。これがアクセスされると

「ソフト・ページ・フォルト」が発生し、ページにはそのプロセスの作業セットが組み込まれます。プロセスが作業セットを拡張できない場合は、プロセスによって現在マップされているページの 1 つを空きセットに移動する必要があります。

任意の数のプロセスが、作業セット内に共有メモリーのページを持つことができます。したがって、作業セットのサイズの合計が使用可能メモリーを著しく超過することがあります。Oracle サーバーの実行中は、SGA、Oracle カーネル・コードおよび Oracle Forms ランタイム実行可能ファイルは一般にすべて共有可能であり、アクセスされるページのおよそ 80% または90% に相当します。

関連項目関連項目関連項目関連項目 : 使用しているプラットフォーム固有の Oracle マニュアルおよび使用しているオペレーティング・システム・ベンダーのマニュアル

オペレーティング・システム・リソース 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などと同じ間隔で使用し、統計全体の補完ビューを提供します。

システムの 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 トランザクションをサポートする必要があります。需要率が一定の場合は、この平均ワークロードを満たすようにシステムを構築します。

関連項目関連項目関連項目関連項目 :

� 5-8 ページ「自動ワークロード・リポジトリの概要」

� Oracle ツールの詳細は、第 6 章「自動パフォーマンス診断」を参照してください。

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 使用率の調査」を参照してください。

� システム・アーキテクチャの変更など、ハードウェア容量を増加する場合。

� CPU のリソース割当てに優先順位を付けることにより、ピーク負荷使用パターンの影響を少なくする場合。Oracle Database Resource Manager は、データベース・ユーザーとアプリケーション間で CPU リソースを割り当て、管理することによって、次の方法でこれを実行します。

– 各コンシューマ・グループのアクティブ・セッション数の制限

この機能は、各コンシューマ・グループに多数のパラレル問合せがあり、パラレル問合せの総数を制限する場合に特に重要です。

– CPU 飽和

CPU が 100% の使用率で稼働している場合に、Oracle Database Resource Manager を使用して各コンシューマ・グループのセッションに対する CPU の割当てを 小限にできます。この機能により、優先順位の低いセッションの CPU 消費を削減できます。

– リソース集中型の問合せ

Oracle Database Resource Manager は、コールの 大実行時間を制限することで、または長時間実行問合せを低優先順位の各コンシューマ・グループに移動することで、リソース集中型の問合せによるダメージを制限できます。

関連項目関連項目関連項目関連項目 : システム・アーキテクチャの向上の詳細は、2-6 ページの「システム・アーキテクチャ」を参照してください。

関連項目関連項目関連項目関連項目 : Oracle Database Resource Manager の詳細は、『Oracle Database 管理者ガイド』を参照してください。

オペレーティング・システム・リソース 9-7

システムの CPU 使用率の調査

システムのシステムのシステムのシステムの CPU 使用率の調査使用率の調査使用率の調査使用率の調査使用しているシステムで実行するすべてのプロセスが、使用可能な CPU リソースに影響を与えます。このため、Oracle 以外の要因をチューニングするとパフォーマンスが向上することがあります。

V$OSSTATまたは V$SYSMETRIC_HISTORYビューを使用して、オペレーティング・システムからのシステム使用率統計を監視します。V$OSSTATおよび V$SYSMETRIC_HISTORYに含まれる有用な統計には、次のものがあります。

� CPU の数

� CPU 使用率

� 負荷

� ページング

� 物理メモリー

オペレーティング・システムの監視ツールを使用して、システム全体で実行されているプロセスを確認します。システムの負荷が非常に高い場合は、この項で後述するメモリー、I/O およびプロセス管理の各項目をチェックしてください。

多くの UNIX ベースのシステムにある sar -uなどのツールを使用すると、システム全体でのCPU 使用率のレベルを調べることができます。UNIX での CPU 使用率は、ユーザー時間、システム時間、アイドル時間および I/O の待機時間を示す統計で説明されます。ワークロードが標準または低いときに、アイドル時間と I/O の待機時間が両方とも 0 に近い（5% 未満である）場合は、CPU の問題が存在します。

Windows では、管理パフォーマンス・ツールを使用して CPU 使用率を監視します。このユーティリティは、プロセッサ時間、ユーザー時間、特権時間（privileged time）、割込み時間および DPC 時間の統計を提供します。

この項では、システムの CPU 使用率のチェックに関する次の項目について説明します。

� メモリー管理のチェック

� I/O 管理のチェック

� ネットワーク管理のチェック

� プロセス管理のチェック

関連項目関連項目関連項目関連項目 : V$OSSTATおよび V$SYSMETRIC_HISTORYの詳細は、『Oracle Database リファレンス』を参照してください。

注意注意注意注意 : この項では、ほとんどの UNIX ベース・システムおよび Windowsシステムにおける CPU 使用率のチェック方法を説明します。その他のプラットフォームについては、使用しているオペレーティング・システムのマニュアルを参照してください。

9-8 Oracle Database パフォーマンス・チューニング・ガイド

システムの CPU 使用率の調査

メモリー管理のチェックメモリー管理のチェックメモリー管理のチェックメモリー管理のチェック次のメモリー管理項目をチェックします。

ページングとスワッピングページングとスワッピングページングとスワッピングページングとスワッピングV$OSSTATビュー、UNIX の sar、vmstatなどのユーティリティ、または Windows の管理パフォーマンス・ツールなどを使用して、ページングとスワッピングの原因を調査します。

大きすぎるページ表大きすぎるページ表大きすぎるページ表大きすぎるページ表UNIX では、処理領域が大きくなりすぎると、ページ表が大きくなりすぎることがあります。これは Windows システムでは問題になりません。

I/O 管理のチェック管理のチェック管理のチェック管理のチェックスラッシングは I/O 管理の課題です。 システムのスラッシング（メモリー内外のスワッピングおよびページング処理）が発生しないように、ワークロードをメモリーに適合させてください。オペレーティング・システムは固定サイズのタイム・スライスをユーザーのプロセスに割り当て、プロセスはそのタイム・スライス中に CPU リソースを使用できます。 プロセスが実行可能かどうか、および必要な構成要素がすべてシステムにあるかどうかを確認するときに、プロセスが大半の時間を浪費すると、実際の作業の実行に割り当てられる時間はわずか 50% となることがあります。

ネットワーク管理のチェックネットワーク管理のチェックネットワーク管理のチェックネットワーク管理のチェッククライアント / サーバーのラウンドトリップをチェックします。メッセージを処理する際にはオーバーヘッドが発生します。アプリケーションで多数のメッセージを生成し、ネットワークを介して送信する必要がある場合、メッセージ送信の待機時間によって CPU のオーバーロードが発生することがあります。この問題を軽減するには、多数のラウンドトリップを実行せずに、複数のメッセージをまとめます。たとえば、配列挿入、配列フェッチなどを使用できます。

プロセス管理のチェックプロセス管理のチェックプロセス管理のチェックプロセス管理のチェックこの項で説明するいくつかのプロセス管理の項目をチェックする必要があります。

スケジューリングとスイッチングスケジューリングとスイッチングスケジューリングとスイッチングスケジューリングとスイッチングオペレーティング・システムはスケジューリングおよびスイッチング処理に大量の時間を消費することがあります。使用しているプロセスが多すぎる可能性があるので、オペレーティング・システムの使用方法を検証してください。Windows システムでは、Oracle プロセス以外の大量のプロセスによってサーバーが過負荷にならないようにしてください。

コンテキストのスイッチングコンテキストのスイッチングコンテキストのスイッチングコンテキストのスイッチングオペレーティング・システム固有の特性によって、システムがコンテキストのスイッチングに大量の時間を消費することがあります。コンテキストのスイッチングは、特に超大規模 SGA の場合には不経済です。インスタンス当たりのプロセスが 1 つのみである Windows では、コンテキストのスイッチングは問題になりません。すべてのスレッドが同じページ表を共有します。

Oracle では、この項で説明する複数のコンテキストのスイッチング機能があります。

ポスト・ウェイト・ドライバポスト・ウェイト・ドライバポスト・ウェイト・ドライバポスト・ウェイト・ドライバ Oracle プロセスは、別の Oracle プロセスをポスト（メッセージの送信）でき、さらにポストされるのを待機できる必要があります。

たとえば、フォアグラウンド・プロセスが LGWR をポストして、指定の時点までのブロックをすべて書き出してコミットを承認するよう、LGWR に通知する必要があります。

このポスト・ウェイト・メカニズムは、UNIX のセマフォを使用して実装するのが普通ですが、これらのセマフォがリソース集中型である場合があります。したがって、一部のプラット

関連項目関連項目関連項目関連項目 : 第 8 章「I/O 構成および設計」

オペレーティング・システム・リソース 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 を繰り返します。

この章の後半では、Oracle の動的パフォーマンス・ビューを使用したインスタンスのチューニングについて説明します。ただし、拡張機能リストによる統計の収集、監視およびチューニングには、自動ワークロード・リポジトリおよび Automatic Database Diagnostic Monitor を使用することをお薦めします。5-8 ページの「自動ワークロード・リポジトリの概要」および 6-3ページの「Automatic Database Diagnostic Monitor」を参照してください。

問題の定義問題の定義問題の定義問題の定義ソリューションの実装を試みる前に、チューニング調査の目的と問題の性質をよく理解しておくことが不可欠です。これについて理解していないと、事実上、効果的な変更は実装できません。この段階で収集されたデータを使用して、次に行うこと、および調査する事象を簡単に決定できます。

次のデータを収集します。

1. パフォーマンスの目的を識別します。

許容できるパフォーマンスの測定尺度は何ですか ?1 時間、または 1 秒間当たり何件のトランザクションで、応答時間が必要なパフォーマンス・レベルを満たしますか ?

2. 問題の範囲を識別します。

スローダウンで何が影響を受けますか ? たとえば、インスタンス全体は低速ですか ? それは、特定のアプリケーション、プログラム、特定の操作またはシングル・ユーザーですか ?

3. 問題が発生したときの時間帯を識別します。

その問題はピーク時間のみ明白ですか ? パフォーマンスはその日の経過に伴って低下しますか ? スローダウンは徐々に（月または週の単位で）発生しましたか、または突然発生しましたか ?

関連項目関連項目関連項目関連項目 : このパフォーマンス・メソッドの理論的な説明および共通エラーのリストについては、3-2 ページの「Oracle のパフォーマンス改善方法」を参照してください。

注意注意注意注意 : サイトに自動ワークロード・リポジトリおよび Automatic Database Diagnostic Monitor 機能がない場合は、Statspack を使用してOracle インスタンス統計を収集できます。

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

インスタンスのチューニング手順

4. スローダウンを検証します。

これは、問題の範囲の識別に役立ち、問題の修復のために実装された変更により実際に改善されたかどうかを判断するときの比較結果の測定基準としての役割を果たします。一貫して再生可能な応答時間またはジョブ実行時間の測定値を検索します。プログラムの動作が正常だったときよりタイミングがどのくらい悪化していますか ?

5. 変更を識別します。

パフォーマンスが許容可能になった後に変化した内容を識別します。これにより、潜在的な原因を素早くつきとめることができます。たとえば、オペレーティング・システムのソフトウェア、ハードウェア、アプリケーション・ソフトウェアまたは Oracle リリースがアップグレードされましたか ? さらに多くのデータがシステムにロードされたか、データ・ボリュームまたはユーザー人口が増加しましたか ?

このフェーズの終わりまでに、症状についてよく理解しておく必要があります。症状をプログラムまたはプログラム・セットにローカルなものとして識別できる場合、その問題はインスタンス全体のパフォーマンスの問題とは異なる方法で処理されます。

ホスト・システムの検査ホスト・システムの検査ホスト・システムの検査ホスト・システムの検査データベース・サーバーに対する負荷とデータベース・インスタンスを調べてください。オペレーティング・システム、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 の集中的な使用を回避できます。

関連項目関連項目関連項目関連項目 : アプリケーションまたはユーザーに固有なパフォーマンスの問題の解決については、第 11 章「SQL チューニングの概要」を参照してください。

パフォーマンス・ビューを使用したインスタンスのチューニング 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 をすべて使用している理由を判断し、次にこのプロセスをチューニングします。

ネットワークネットワークネットワークネットワークオペレーティング・システムのユーティリティを使用して、ネットワーク・ラウンドトリップの ping 時間と衝突数を調べます。ネットワークで応答時間の大幅な遅延が発生している場合は、考えられる原因を調べてください。

ネットワーク負荷を減らすには、大きいデータ転送をピーク時間外へスケジュールするか、リモート・ホストに対して要求当たり 1 回ずつ（またはそれ以上）アクセスせずに、要求をバッチ処理するようにアプリケーションをコーディングします。

Oracle 統計の調査統計の調査統計の調査統計の調査問題の診断の一貫性が保たれるようにするには、Oracle 統計を調べてオペレーティング・システムの統計と相互参照してください。ただし、目標が Oracle インスタンスをチューニングすることにあれば、修正アクションを実装する前に Oracle 統計を調べて Oracle の観点からリソース・ボトルネックを識別します。 10-9 ページの「Oracle 統計の解釈」を参照してください。

チューニング中に使用する一般的な Oracle データ・ソースを次に示します。

統計収集のレベルの設定統計収集のレベルの設定統計収集のレベルの設定統計収集のレベルの設定Oracle では、初期化パラメータ STATISTICS_LEVELを提供し、データベース内で主要統計収集またはアドバイザをすべて制御します。このパラメータでは、データベースに統計収集レベルを設定します。

STATISTICS_LEVELの設定に応じて、次のように一定のアドバイザ機能または統計が収集されます。

� BASIC: アドバイザ機能も統計も収集されません。監視機能および多数の自動機能が使用禁止になります。重要な Oracle 機能が使用禁止になるため、この設定は使用しないことをお薦めします。

� TYPICAL: これはデフォルト値であり、すべての主要統計が収集され、データベース全体のパフォーマンスが 高になります。ほとんどの環境では、この設定で十分です。

� ALL: TYPICAL設定を使用して収集されるすべてのアドバイザ機能と統計に加えて、オペレーティング・システム時間統計および行ソース実行統計が含まれます。

関連項目関連項目関連項目関連項目 :

� 第 11 章「SQL チューニングの概要」

� 動的パフォーマンス・ビュー V$SQLAREAの詳細は、『Oracle Database リファレンス』を参照してください。

� 第 8 章「I/O 構成および設計」

� 散布読取りと順次読取りの違い、およびそれが I/O に与える影響は、10-19 ページの「db file scattered read」および 10-21 ページの「db file sequential read」を参照してください。

パフォーマンス・ビューを使用したインスタンスのチューニング 10-5

インスタンスのチューニング手順

V$STATISTICS_LEVEL このビューには、STATISTICS_LEVELで制御される統計またはアドバイザ機能のステータスがリストされます。

待機イベント待機イベント待機イベント待機イベント待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示すために、サーバー・プロセスまたはスレッドによって増やされる統計です。待機イベント・データは、ラッチの競合、バッファの競合、I/O の競合などのパフォーマンスに影響を与えると思われる様々な問題の症状を表します。ただし、これらの問題は実際の原因でなく、問題の症状にすぎないことに注意してください。

待機イベントは、クラス別にグループ化されています。待機イベント・クラスには、Administrative、Application、Cluster、Commit、Concurrency、Configuration、Idle、Network、Other、Scheduler、System I/O および User I/O があります。

サーバー・プロセスは、次の症状に対して待機します。

� リソースが使用可能になるまで（バッファやラッチなど）

� アクションが完了するまで（I/O など）

� 実行する追加作業（クライアントが次に実行する SQL 文を提供するまで待機する場合など）サーバー・プロセスが追加作業の待機中であることを識別するイベントのことをアイドル・イベントと呼びます。

待機イベント統計には、イベントを待機した回数や、イベントが完了するまでの待機時間があります。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など、時間モデル統計が含まれます。

関連項目関連項目関連項目関連項目 :

� STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

� STATISTICS_LEVEL、DB_CACHE_ADVICE、TIMED_STATISTICSまたは TIMED_OS_STATISTICS初期化パラメータを設定する場合の考慮事項は、5-6 ページの「統計の解釈」を参照してください。

関連項目関連項目関連項目関連項目 : 動的パフォーマンス・ビュー V$STATISTICS_LEVELの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : Oracle 待機イベントの詳細は、『Oracle Database リファレンス』を参照してください。

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 ブロック読取り中の待機回数を示すヒストグラムが表示されます。

パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・データを調査します。 大時間がリストされるイベントは、多くの場合、パフォーマンス・ボトルネックを顕著に示しています。たとえば、V$SYSTEM_EVENTを参照することで、多くのbuffer busy waitsが発生していると気づくことがあります。おそらく、多数のプロセスが同じブロックに挿入しようとするときに、各プロセスが他のプロセスの挿入を待機してからでないと挿入できないことが原因です。問題となっているオブジェクトに自動セグメント領域管理またはパーティション化を使用することで解決する可能性があります。V$SESSION_WAIT、V$SESSION_EVENTおよび V$SYSTEM_EVENTの各ビューの差異の説明は、10-15 ページの

「待機イベント統計」を参照してください。

システム統計システム統計システム統計システム統計システム統計は通常、パフォーマンスの問題の原因をさらに示すものを見つけるために、待機イベント・データとともに使用されます。

関連項目関連項目関連項目関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リファレンス』を参照してください。

パフォーマンス・ビューを使用したインスタンスのチューニング 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 これには、各ラッチが要求された回数やラッチを待機した回数など、各ラッチの詳細なラッチ使用統計が含まれています。

セグメント・レベルの統計セグメント・レベルの統計セグメント・レベルの統計セグメント・レベルの統計個別のセグメントに関連するパフォーマンス問題に焦点をあてるのに役立つ、セグメント・レベルの統計を収集できます。セグメント・レベルの統計を収集して表示することは、インスタンスで競合度の高い表あるいは索引を効果的に識別するための優れた方法です。

パフォーマンスの問題を識別するために待機イベントおよびシステム統計を表示した後で、セグメント・レベルの統計を使用して問題の原因となっている特定の表または索引を検索できます。バッファ・ビジー待機が、大半の待機時間の原因になっていることを V$SYSTEM_EVENTが示している例を考えます。buffer busy waits の原因になっているトップ・セグメントをV$SEGMENT_STATISTICSから選択できます。これにより、それらのセグメントの問題の解決に集中できます。

セグメント・レベルの統計は、次の動的ビューを使用して問い合せます。

� V$SEGSTAT_NAME このビューには収集するセグメント統計と、各種統計（たとえばサンプル統計など）のプロパティがリストされます。

� V$SEGSTAT これは非常に効率的で、リアルタイム監視が可能なビューであり、統計値、統計名およびその他の基本情報が表示されます。

� V$SEGMENT_STATISTICS ユーザーが扱いやすい統計値のビューです。V$SEGSTATのすべての列の他、ここにはセグメント所有者や表領域名に関する情報があります。統計の理解は容易になりますが、コストがより高くなります。

関連項目関連項目関連項目関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リファレンス』 を参照してください。

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

Oracle 統計の解釈

変更の実装および測定変更の実装および測定変更の実装および測定変更の実装および測定チューニングを実施した後、多くの場合、問題を軽減できると思われる 2 つまたは 3 つの変更を識別できます。どの変更が 高の利益を提供するかを識別するには、一度に 1 回の変更を実装することをお薦めします。変更の効果は、問題定義段階でみられたベースライン・データ測定と対照して測定する必要があります。

一般に、パフォーマンスの問題を持つ大半のサイトでは、一度に重複した変更を実装するので、どの変更が利益を実現したかを識別できません。これはすぐに問題になることはありませんが、どの変更が も効果をあげ、どのような作業を優先する必要があるかを知ることは不可能なので、今後同様の問題が発生した場合に大きな障害になります。

個別に変更を実装できない場合は、異なる変更の効果の測定を試みてください。たとえば、変更された問合せのパフォーマンスを向上するために新しい索引を作成する効果とは別に、REDO の生成を 適化するために初期化変更を行う効果を測定します。SQL がチューニングされ、オペレーティング・システムのディスク・レイアウトが変更され、初期化パラメータも同時に変更されている場合は、オペレーティング・システムをアップグレードすることの利益は測定できません。

パフォーマンス・チューニングは反復的なプロセスです。インスタンス・ワイドのパフォーマンスの問題を解決する万全策が見つかることはほとんどありません。ほとんどの場合、あるボトルネックを解決しても別の（ときにはさらに悪い）問題が発生するため、優れたパフォーマンスにはパフォーマンス・チューニング段階を反復する必要があります。

いつチューニングを停止するかを知ることも重要です。パフォーマンスの も優れた測定は、統計が理想的な値にどの程度近いかではなく、ユーザーの理解力です。

Oracle 統計の解釈統計の解釈統計の解釈統計の解釈インスタンスにパフォーマンスの問題があった時を示す統計を収集します。比較のためのベースライン・データをすでに収集してある場合は、問題のワークロードを も代表するベースラインからのデータと、現行のデータを比較できます。

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 が含まれます。

自動ワークロード・リポジトリ・レポートの「ロード・プロファイル」の項を参照してください。データは、トランザクションおよび秒ごとに正規化されています。

負荷の変更負荷の変更負荷の変更負荷の変更秒ごとの負荷プロファイル統計は、スループットの変化（すなわち、インスタンスの作業実行量が毎秒ごとに増えているかどうか）を示します。トランザクションごとの統計は、アプリケーション特性の変化をベースライン・レポートからの対応する統計と比較することで識別します。

関連項目関連項目関連項目関連項目 : 5-2 ページ「データ収集の概要」

パフォーマンス・ビューを使用したインスタンスのチューニング 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 待機クラスには、実行する作業がなく、さらに作業が実行されるのを待っている場合にプロセスが待機するイベントすべてがグループ化されます。アイドル状態でないイベントはリソースあるいはアクションが完了するまでの非生産的な待機時間を示します。

待機イベント・データを使用する も効率的な方法は、待機時間別にイベントを順序付けすることです。この方法は、TIMED_STATISTICSが trueに設定されているときのみ可能です。設定しない場合は、待機イベントを待機数別にランク付けします。これは、一般的に問題をもよく表す順序付けではありません。

どこで時間が消費されているかが判明してから、次の手順を実行してください。

1. V$SYSTEM_EVENTのデータ収集を調べます。対象のイベントは、待機時間別にランク付けする必要があります。

待機時間の も大きいパーセンテージを持つ待機イベントを識別します。待機時間のパーセンテージを決定するには、アイドル・イベント（Null event、SQL*Net message from client、SQL*Net message to clientおよび SQL*Net more data to clientなど）を除くすべての待機イベントの合計待機時間を追加します。各イベントの待機時間をすべてのイベントの総待機時間で除算し、5 つの も重要なイベントの相対的なパーセンテージを計算します。

注意注意注意注意 : すべての症状が待機イベントによって証明されるわけではありません。チェックできる統計については、10-13 ページの「追加された統計情報」を参照してください。

関連項目関連項目関連項目関連項目 :

� STATISTICS_LEVELの設定の詳細は、10-5 ページの「統計収集のレベルの設定」を参照してください。

� STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

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

Oracle 統計の解釈

別の方法として、自動ワークロード・リポジトリ・レポートの先頭の「トップ 5 待機イベント」の項を参照してください。この項では、待機イベント（アイドル・イベントを除く）を自動的に順序付けし、相対的なパーセンテージを計算します。

Top 5 Timed Events~~~~~~~~~~~~~~~~~~ % TotalEvent Waits Time (s) Call Time-------------------------------------- ------------ ----------- ---------CPU time 559 88.80log file parallel write 2,181 28 4.42SQL*Net more data from client 516,611 27 4.24db file parallel write 13,383 13 2.04db file sequential read 563 2 .27

状況によっては、同程度のパーセンテージを持つイベントがいくつか存在する場合があります。このため、すべてのイベントが同じタイプのリソース要求（たとえば、すべてがI/O 関連イベント）に関連している場合に、追加の証拠を提供できます。

2. これらのイベントの待機数と平均待機時間を見てください。たとえば、I/O 関連イベントの場合、平均時間が I/O システムが低速であるかどうかを識別するのに役立つ場合もあります。次に、自動ワークロード・リポジトリ・レポートの「Wait Event」の項から引用した、このデータの例を示します。

Avg Total Wait wait WaitsEvent Waits Timeouts Time (s) (ms) /txn--------------------------- --------- --------- ---------- ------ ---------log file parallel write 2,181 0 28 13 41.2SQL*Net more data from clie 516,611 0 27 0 9,747.4db file parallel write 13,383 0 13 1 252.5

3. トップの待機イベントは、次に調査する場所を識別します。表 10-1 に、一般的な待機イベントを示します。高負荷 SQL を調べることもお薦めします。

4. 待機イベントで指示される関連データを調べて、このデータから得られる他の情報を確認します。この情報が待機イベント・データとの一貫性を持っているかどうかを判断します。ほとんどの場合、パフォーマンス・ボトルネックの潜在的な原因に関する理論の展開を開始するためのデータは十分にあります。

5. この理論が有効であるかどうかを判断するには、利用可能な他の統計ですでに調べたデータの一貫性をクロスチェックします。適切な統計は問題により異なりますが、通常はV$SYSSTATやオペレーティング・システム統計などにある、負荷のプロファイル関連のデータが含まれています。他のデータとのクロスチェックを行って、展開中の理論を肯定または否定します。

関連項目関連項目関連項目関連項目 :

� アイドル待機イベントのリストは、10-34 ページの「アイドル待機イベント」を参照してください。

� V$EVENT_NAMEビューの説明は、『Oracle Database リファレンス』を参照してください。

� 待機イベント情報の詳細は、『Oracle Database リファレンス』を参照してください。

パフォーマンス・ビューを使用したインスタンスのチューニング 10-11

Oracle 統計の解釈

待機イベントおよび潜在的な原因の表待機イベントおよび潜在的な原因の表待機イベントおよび潜在的な原因の表待機イベントおよび潜在的な原因の表表 10-1 に、待機イベントと考えられる原因との関連付けの他、次に検討するのに も有益と思われる Oracle データの概要を示します。

また、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-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 システム

V$SQLAREAを調べて、多数のディスク読込

みを実行する SQL 文があるかどうかを確認し

ます。I/O システムと V$FILESTATをクロス

チェックして、長い読込み時間をチェックします。

db file sequential read

I/O、SQL 文の

チューニング

チューニングが適切ではないSQL

低速な I/O システム

V$SQLAREAを調べて、多数のディスク読込

みを実行する SQL 文があるかどうかを確認し

ます。I/O システムと V$FILESTATをクロス

チェックして、長い読込み時間をチェックします。

enqueue待機（enq:で始まる待機）

ロック エンキューのタイプにより異なる

V$ENQUEUE_STATを参照します。

ライブラリ・キャッシュ・ラッチ待機 : library cache、library cache pinおよび library cache lock

ラッチの競合 SQL の解析または共有 V$SQLAREAを調べて、比較的多数の解析

コールまたは多数の子カーソルを使用するSQL 文があるかどうかを確認します

（VERSION_COUNT列）。V$SYSSTATの解析

統計と毎秒の対応する割合を調べます。

log buffer space ログ・バッファの I/O

小さいログ・バッファ

低速な I/O システム

V$SYSSTATの統計 redo buffer allocation retriesをチェックします。

メモリーの構成の章の、ログ・バッファの構成の項をチェックしてください。オンラインREDO ログを格納するディスクをチェックし

て、リソースの競合の有無をチェックします。

log file sync I/O、コミット

過剰

オンライン・ログを格納する低速なディスク

バッチされないコミット

オンライン REDO ログを格納するディスクを

チェックして、リソースの競合の有無をチェックします。V$SYSSTATから毎秒のト

ランザクション数（コミット数＋ロールバック数）をチェックします。

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

Oracle 統計の解釈

追加された統計情報追加された統計情報追加された統計情報追加された統計情報対応する待機イベントを持たないパフォーマンスの問題を示すことのできる統計は多数あります。

REDO ログ領域要求統計ログ領域要求統計ログ領域要求統計ログ領域要求統計V$SYSSTAT統計の redo log space requestsは、サーバー・プロセスが REDO ログ・バッファ内の領域を待機するのではなく、オンライン REDO ログ内の領域を待機する必要があった回数を示します。この統計と待機イベントの大きい値は、LGWR ではなく、チェックポイント、DBWR、アーカイバ・アクティビティをチューニングする必要があることの標識として使用する必要があります。ログ・バッファのサイズを増やしても効果がありません。

読取り一貫性読取り一貫性読取り一貫性読取り一貫性システムは、一貫したビューを維持するために、ブロックの変更内容のロールバックに長時間を費やすことがあります。次の状況を考慮してください。

� 多数の小さいトランザクションがあり、変化が起こっている同じ表のバックグラウンド内でアクティブな長時間実行問合せが動作している場合、表の一貫読取りイメージを取得するために、問合せはこれらの変化を頻繁にロールバックする必要がある場合があります。次の V$SYSSTAT統計を比較して、変化が発生しているかどうかを判断します。

� consistent changes統計は、そのブロック上で読取り一貫性を実行するために、データベース・ブロックがロールバック・エントリを適用した回数を示します。多数の consistent changesを生成するワークロードは、多数のリソースを使用する可能性があります。

� consistent gets統計は、一貫したモードでの論理読込み数をカウントします。

� 大きいロールバック・セグメントがほとんどない場合、システムはトランザクションがどの SCN にコミットされたかを正確に知るために、遅延ブロックのクリーンアウト時に長時間かけてトランザクション表をロールバックする可能性があります。トランザクションのコミット時には、変更されたブロックすべてがコミット SCN で即時に更新されるとはかぎりません。この場合は、ブロックの読取り時または更新時に必要に応じて更新されます。これを遅延ブロック・クリーンアウトと呼びます。

次の V$SYSSTAT統計の比率は、1 に近い値であることが必要です。

ratio = transaction tables consistent reads - undo records applied / transaction tables consistent read rollbacks

解決策は、自動 UNDO 管理を使用することをお薦めします。

� ロールバック・セグメントが十分にない場合、ロールバック・セグメント（ヘッダーまたはブロック）の競合が発生します。この問題は、次のようにすると明らかになります。

� WAITS数を V$ROLLSTAT内の GETS数と比較する方法。GETSに対する WAITSの比率は小さい値である必要があります。

� V$WAITSTATを調べて、CLASS 'undo header' のバッファに対して多数の WAITSがあるかどうかを確認する方法。

解決策は、自動 UNDO 管理を使用することをお薦めします。

関連項目関連項目関連項目関連項目 :

� 表 10-1 にリストした各イベントの詳細およびクロスチェックするその他の情報は、10-15 ページの「待機イベント統計」を参照してください。

� 動的パフォーマンス・ビューの詳細は、『Oracle Database リファレンス』を参照してください。

パフォーマンス・ビューを使用したインスタンスのチューニング 10-13

Oracle 統計の解釈

継続行による表フェッチ継続行による表フェッチ継続行による表フェッチ継続行による表フェッチV$SYSSTAT内の table fetch continued row統計数をチェックして、移行行または連鎖行を検出できます。少数の連鎖行（1% 以下）は、システム・パフォーマンスに影響を与える可能性はほとんどありません。ただし、連鎖行のパーセンテージが大きいと、パフォーマンスに影響を与える可能性があります。

ブロック・サイズより大きい行の連鎖は避けられません。そのようなデータについては、ブロック・サイズのより大きい表領域の使用を考慮してください。

ただし、小さい行の場合は、適切な領域パラメータとアプリケーション設計を使用することで連鎖を回避できます。たとえば、キー値が入力され、かつその他のほとんどの列が NULL である行を、実際のデータで更新しないでください。その行のサイズが大きくなります。その場合は初めからデータが入力された行を挿入します。

UPDATE文が行のデータ量を増やし、行がそのデータ・ブロックに収まらなくなった場合、Oracle は行全体を保持するのに十分な空き領域を持つ別のブロックを見つけようとします。そのようなブロックが利用可能であれば、Oracle は新しいブロックへ行全体を移動します。これを行の移行と呼びます。行が大きすぎて利用可能なブロックに収まらない場合、Oracle はその行を複数の断片に分割し、各断片を別々のブロックに格納します。これを行の連鎖と呼びます。行は挿入時にも連鎖される可能性があります。

移行と連鎖は、特に次の場合のパフォーマンスに影響があります。

� 移行と連鎖の原因となる UPDATE文のパフォーマンスはよくありません。

� 移行行または連鎖行が追加入出力を実行するため、これらの行を選択する問合せをします。

サンプルの出力表 CHAINED_ROWSの定義が、配布媒体上の使用可能な SQL スクリプトに収録されています。このスクリプトの一般的な名前は UTLCHN1.SQLですが、正確な名前と位置は使用しているプラットフォームによって異なります。出力表は、CHAINED_ROWS表と同じ列名、データ型およびサイズである必要があります。

移行行を回避するには、PCTFREEを増やします。ブロック内に使用可能な空き領域を多く残しておくと、行の拡張に対処できます。削除割合が高い表と索引を再編成すなわち再作成することもできます。頻繁に行が削除される表の場合は、データブロックに部分的に空き領域が生じることがあります。行を挿入し後から拡張する場合、行の削除されたブロックにその行が挿入されることがありますが、拡張の余地はありません。表を再編成すると主な空き領域を完全に空のブロックにできます。

解析関連の統計解析関連の統計解析関連の統計解析関連の統計アプリケーションの解析が長くなるほど、競合の可能性が高くなり、システムの待機時間が長くなります。parse time CPU（CPU 解析時間）が CPU タイムの大半を占める場合、SQL 文の実行ではなく解析に時間が消費されています。この場合には、アプリケーションはリテラルSQL を使用しているために SQL を共有できないか、または共有プールの構成が適切でないことがあります。

注意注意注意注意 : PCTUSEDは、PCTFREEの反対の意味ではありません。

関連項目関連項目関連項目関連項目 :

� PCTUSEDの詳細は、『Oracle Database 概要』を参照してください。

� 表の再編成の詳細は、『Oracle Database 管理者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : 第 7 章「メモリーの構成と使用方法」

10-14 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に設定されている場合は、各リソースを待機した時間に関する情報も表示されます。

パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・データを調査します。 大時間がリストされるイベントは、多くの場合、パフォーマンス・ボトルネックを顕著に示しています。

次の各ビューには、同じデータの関連する（ただし、異なる）ビューが含まれています。

� 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内に読み込まれたブロック番号およ

関連項目関連項目関連項目関連項目 :

� STATISTICS_LEVELの設定の詳細は、10-5 ページの「統計収集のレベルの設定」を参照してください。

� V$ビューおよび Oracle 待機イベントの詳細は、『Oracle Database リファレンス』を参照してください。

パフォーマンス・ビューを使用したインスタンスのチューニング 10-15

待機イベント統計

び P3内に読み込まれたブロック数を示します（P1と P2により待機イベントがどのセグメントに対して発生するかを判断できます）。

この章では、V$SESSION_WAITの使用例を中心に説明します。ただし、時間間隔のパフォーマンス・データの収集と、パフォーマンスおよび容量分析のためにこのデータを保存することをお薦めします。この形式のロールアップ・データの問合せは、自動ワークロード・リポジトリにより V$SYSTEM_EVENTビューから行います。5-8 ページの「自動ワークロード・リポジトリの概要」を参照してください。

も一般的に発生するイベントについては、この章で、大 / 小文字を区別するアルファベット順にリストして説明します。調べる対象の他のイベント関連データも含まれています。各イベント名に使用する大 / 小文字区別は、V$SYSTEM_EVENTビューでの表示と同一です。

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これはアイドル・イベントですが、このイベントを診断に使用できるときに何が問題でないかを説明することが重要です。このイベントは、サーバー・プロセスがクライアント・プロセスからの処理を待機していることを示します。ただし、このイベントが、長い応答時間を経験しているユーザーの待機時間の大半を生成している状況がいくつかあります。その原因は、ネットワーク・ボトルネックまたはクライアント・プロセスでのリソース・ボトルネックのいずれかである可能性があります。

ネットワーク・ボトルネックネットワーク・ボトルネックネットワーク・ボトルネックネットワーク・ボトルネック ネットワーク・ボトルネックは、アプリケーションによってサーバーとクライアントとの間で多量の通信が発生し、ネットワークの待機時間（ラウンドトリップの時間）が長い場合に発生する可能性があります。症状には次のものがあります。

� このイベントに対する多数の待機

� データベースとクライアント・プロセスは、時間のほとんどがアイドル状態（ネットワーク通信待ち状態）です。

関連項目関連項目関連項目関連項目 : V$SYSTEM_EVENTビューの詳細は、『Oracle Database リファレンス』を参照してください。

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 SEGMENT_NAME, FREELISTS FROM DBA_SEGMENTS WHERE SEGMENT_NAME = segment name AND 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 ホット・スポットの削減。

初に行うことは、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;

関連項目関連項目関連項目関連項目 : 第 8 章「I/O 構成および設計」

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

待機イベント統計

db file sequential readこのイベントは、ユーザー・プロセスが SGA 内のバッファ・キャッシュにバッファを読み取り、物理 I/O コールが戻るまで待機することを意味します。順次読取りは、単一ブロック読取りです。

単一ブロック I/O は通常、索引を使用した結果です。エクステント境界のため、すなわち、バッファがすでにバッファ・キャッシュ内に存在するために全表スキャン・コールが単一ブロック・コールに切り捨てられることはほとんどありません。これらの待機は、'db file sequential read' としても表示されます。

次の V$SESSION_WAITパラメータ列をチェックします。

� P1 - 絶対ファイル番号

� P2 - 読み込まれるブロック

� P3 - ブロック数（1 とする必要がある）

処置処置処置処置健全なシステムでは、物理読込み待機がアイドル待機後の 大待機である必要があります。ただし、パラレル問合せを持つ、全表スキャンに近いスキャンの必要な大きいデータ・ウェアハウス上に、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

関連項目関連項目関連項目関連項目 : 過剰 I/O の管理、不適切な I/O 分散、さらに I/O を発生させる SQL および I/O が実行されるセグメントの検索の詳細は、10-19 ページの「db file scattered 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-19 ページ「過剰な I/O の管理」

� 7-35 ページ「PGA メモリー管理」

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

待機イベント統計

direct path write およびおよびおよびおよび direct path write tempプロセスがバッファを PGA から直接書き込む（バッファ・キャッシュからバッファを書き込むDBWR とは反対）場合、プロセスは書込みコールが完了するまでこのイベント上で待機します。ダイレクト・パス書込みを実行できる操作には、ソートがディスクに移動するとき、パラレル DML 操作時、ダイレクト・パス INSERT、パラレル作成表の選択時、およびいくつかのLOB 操作があります。

ダイレクト・パス読込みと同様に、I/O サブシステムが非同期書込みをサポートする場合、待機数は発行された書込みコール数と同じではありません。セッションが PGA 内のすべてのバッファを処理し、I/O リクエストが完了するまで作業を継続できない場合、セッションは待機します。

次の 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 Database管理者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : 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を使用するように切り替えます。

� 動的に拡張するセグメントを含む表領域がディクショナリ管理表領域の場合は、ローカル管理表領域を使用するように切り替えます。

� ローカル管理表領域に切り替えることができない場合は、拡張するオブジェクトの次のエクステント・サイズを、一定の領域割当てを回避できる十分な大きさに変更することによって、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 ロック上の待機の も一般的な理由は、制約される列が索引付けされない場合の外部キー制約に関係している傾向があります。この問題を回避するには、外部キー列を索引付けします。

関連項目関連項目関連項目関連項目 : TEMPFILEおよびローカル管理表領域の詳細は、『Oracle Database 概要』を参照してください。

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に対応します。

events in wait class otherこのイベントは、「その他」の待機クラスに属し、通常はシステムで発生しないようにしてください。このイベントは、latch freeなど、「その他」の待機クラスのその他すべてのイベントの集計であり、V$SESSION_EVENT および V$SERVICE_EVENT ビューでのみ使用されます。これらのビューでは、「その他」待機クラスのイベントは、セッションごとにはメンテナンスされません。かわりに、この 1 つのイベントにロール・アップされ、「その他」待機クラスのイベント統計をメンテナンスするためのメモリーを削減します。

関連項目関連項目関連項目関連項目 : 参照整合性およびデータの明示的ロックの詳細は、『Oracle Database アドバンスト・アプリケーション開発者ガイド』を参照してください。

パフォーマンス・ビューを使用したインスタンスのチューニング 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 プロセスとプロセスとプロセスとプロセスと I/O スレーブの選択スレーブの選択スレーブの選択スレーブの選択 複数の DBWR プロセスを構成すると、単一のDBWR プロセスが、必要なワークロードに耐えられないときのパフォーマンスに有益です。ただし、複数の DBWR プロセスを構成する前に、非同期 I/O が使用でき、システム上に構成されるかどうかを確認します。システムが非同期 I/O をサポートしても現在使用されていない場合は、複数の DBWR プロセスを構成すると問題が軽減されるかどうかを確認するために非同期I/O を使用可能にします。システムが非同期 I/O をサポートしない場合、または非同期 I/O がすでに構成され、DBWR ボトルネックが依然として存在する場合は、複数の DBWR プロセスを構成します。

複数の DBWR を使用すると、バッファの収集と書込みがパラレル化されます。そのため、複数の DBWn プロセスは同じ数の I/O スレーブを使用する 1 つの DBWR プロセスよりもスループットを向上します。このため、複数の DBWR プロセスを優先して、I/O スレーブは使用されなくなりました。I/O スレーブは、複数の DBWR プロセスを構成できない場合のみ使用してください。

注意注意注意注意 : DBWR_IO_SLAVESを実装するには、余分な共有メモリーを I/Oバッファと要求キューに割り当てる必要があります。複数の DBWR プロセスを I/O スレーブと併用することはできません。I/O スレーブを構成すると、1 つの DBWR プロセスのみ起動するように設定されます。

注意注意注意注意 : プラットフォーム上で非同期 I/O を使用できない場合は、DISK_ASYNCH_IO初期化パラメータを FALSEに設定して非同期 I/O を無効にできます。

パフォーマンス・ビューを使用したインスタンスのチューニング 10-27

待機イベント統計

ラッチ・イベントラッチ・イベントラッチ・イベントラッチ・イベントラッチは、メモリー構造を保護するために Oracle で使用される下位レベルの内部ロックです。ラッチ解放イベントは、サーバー・プロセスがラッチを取得しようとしたときに更新され、ラッチは 初の試行で使用できなくなります。

通常は大きな競合を生成する一般的なラッチ用に、専用のラッチ関連待機イベントがあります。これらのイベントの場合は、latch: library cacheまたは latch: cache buffers chainsのように、ラッチ名が待機イベント名に含まれます。このため、ラッチに関連するほとんどの競合の原因が特定のタイプのラッチであるかどうかをすばやく確認できます。他のすべてのラッチの待機は、汎用の latch free待機イベントにグループ化されています。

処置処置処置処置このイベントは、ラッチ待機がシステム上の待機時間全体の重要な部分である場合か、または問題が発生している個々のユーザーに対してのみかを考慮してください。

� 関連するリソースのリソース使用量を調べます。たとえば、ライブラリ・キャッシュ・ラッチの競合が大きい場合は、ハードとソフトの解析率を調べます。

� ラッチ競合が発生しているセッションの 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;

関連項目関連項目関連項目関連項目 : ラッチおよび内部ロックの詳細は、『Oracle Database 概要』 を参照してください。

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

待機イベント統計

共有プールとライブラリ・キャッシュ・ラッチの競合共有プールとライブラリ・キャッシュ・ラッチの競合共有プールとライブラリ・キャッシュ・ラッチの競合共有プールとライブラリ・キャッシュ・ラッチの競合共有プールまたはライブラリ・キャッシュ・ラッチの競合の主な原因は解析です。不要な解析および不要な解析の様々なタイプの識別に使用できる手法は多数あります。

非共有非共有非共有非共有 SQL この方法では、リテラルがバインド変数と置換された場合に共有できる類似したSQL 文を識別します。その概念は次のいずれかです。

� 実行を 1 つのみ持つ SQL 文を手動で検査して、SQL 文が類似しているかどうかを確認します。

SELECT SQL_TEXT FROM V$SQLSTATS WHERE EXECUTIONS < 4 ORDER BY SQL_TEXT;

表表表表 10-2 ラッチ解放イベントラッチ解放イベントラッチ解放イベントラッチ解放イベント

ラッチラッチラッチラッチ SGA 領域領域領域領域 考えられる原因考えられる原因考えられる原因考えられる原因 検索対象検索対象検索対象検索対象

共有プール、ライブラリ・キャッシュ

共有プール 文の再利用不足

バインド変数を使用しない文

アプリケーション・カーソル・キャッシュのサイズが不十分

各実行後に明示的にクローズされたカーソル

頻繁なログオン / ログオフ

基礎的なオブジェクト構造の変更（たとえば、切捨て）

小さすぎる共有プール

次の項目が高いセッション（V$SESSTAT内）

� CPU 解析時間

� 所要解析時間

� 解析カウント（ハード）/ 実行カウントの

比率

� 解析カウント（合計）/ 実行カウントの比

率

次のカーソル（V$SQLAREA/V$SQLSTATS内）

� PARSE_CALLS / EXECUTIONSの高い比率

� EXECUTIONS = 1 WHERE句のリテラルの

み異なる（すなわち、バインド変数を使用しない）

� 高い RELOADS

� 高い INVALIDATIONS

� 大きい（> 1MB）SHARABLE_MEM

キャッシュ・バッファ LRU連鎖

バッファ・キャッシュLRU リスト

過剰なバッファ・キャッシュ・スループット。たとえば、正しくない索引に繰り返しアクセスする非効率的な SQL（大きい索引レンジ・

スキャン）、または多くの全表スキャンがあります。

実行中のワークロードに耐えられない DBWR。これにより、フォアグラウンド・プロセスが空きバッファを検索するためにラッチを保持する時間が長くなります。

小さすぎるキャッシュ

論理 I/O または物理 I/O が非常に多く、選択

性のない索引が使用される文

キャッシュ・バッファ連鎖

バッファ・キャッシュ

ホット・ブロックと呼ばれる 1 つ（または少

数）のブロックへのアクセスの繰返し

順序番号ジェネレータを使用せずに番号を生成するための、表の行を更新する順序番号生成コード

非常に多くのプロセスが、きわめて類似した述語を使用して選択性のない同一の索引をスキャンすることから発生する、索引リーフ・ブロックの競合

ホット・ブロックが属するセグメントの識別

行キャッシュ・オブジェクト

パフォーマンス・ビューを使用したインスタンスのチューニング 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$SQLSTATSORDER BY PARSE_CALLS;

PARSE_CALLSの値が指定の文の EXECUTIONS値に近い場合は、その文の再解析を継続できます。解析コールが多い文をチューニングします。

セッション別セッション別セッション別セッション別 不要な解析コールが発生しているセッションを識別して、不要なコールを識別します。特定のバッチ・プログラムやある種のアプリケーションがほとんどの再解析を行っている場合があります。これを行うには、次の問合せを実行します。

SELECT pa.SID, pa.VALUE "Hard Parses", ex.VALUE "Execute Count" FROM V$SESSTAT pa, V$SESSTAT ex WHERE pa.SID = ex.SID AND 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で、再解析の原因となっているプログラムの名前を検索します。

出力は、次のようなものです。

SID Hard Parses Execute Count------ ----------- ------------- 7 1 20 8 3 12690 6 26 325 11 84 1619

注意注意注意注意 : この問合せではインスタンス起動後のすべての解析コールがカウントされるため、解析率の高いセッションを検索することをお薦めします。たとえば、50 日間の接続が高い解析値を示すとしても、2 番目の 10分間の接続の方がより速い速度で解析される場合があります。

10-30 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 との競合）。

� アーカイバが十分高速に書込みを行えない（アーカイブ先での競合、または ARCH プロセスの数が不足している）。その他の可能性（ディスクが低速であったり、アーカイブ先がいっぱいなど）が除外された場合は、ARCn プロセス数の増加を検討してください。デフォルトは 2 です。

� 必須でリモートに転送されるアーカイブ・ログがある場合は、ネットワーク遅延によってこのプロセスが遅くなっていないか、またはエラーによって書込みが完了していないかをチェックしてください。

10-32 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 章「アプリケーション・トレース・ツールの使用方法」

SQL チューニング

11

SQL チューニングの概要チューニングの概要チューニングの概要チューニングの概要

この章では、チューニングの目的、多くのリソースを消費する SQL 文の識別方法および収集する内容の説明と、チューニングの提案を示します。

この章には次の項があります。

� SQL チューニングの概要

� チューニングの目的

� 高負荷 SQL の識別

� 自動 SQL チューニング機能

� 効率的な SQL 文の開発

関連項目関連項目関連項目関連項目 :

� SQL の概要は、『Oracle Database 概要』を参照してください。

� データベースの監視とチューニングについては、『Oracle Database 2日でデータベース管理者』を参照してください。

の概要 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 を識別できない（たとえば、SQL が動的に生成される）場合は、SQL_TRACEを使用して、実行された SQL を含むトレース・ファイルを生成し、次に TKPROFを使用して出力ファイルを生成します。

TKPROF出力ファイル内の SQL 文は、実行経過時間（exeela）などの各種パラメータで順序付けできるため、通常は、SQL 文を経過時間で順序付けする（経過時間が も長い SQL 文をファイルの も上に置く）ことで識別に利用されます。これにより、ファイル内に SQL 文が多数ある場合に、パフォーマンスの低い SQL を識別するジョブの実行が容易になります。

アプリケーションのチューニングアプリケーションのチューニングアプリケーションのチューニングアプリケーションのチューニング / 負荷の軽減負荷の軽減負荷の軽減負荷の軽減アプリケーション全体のパフォーマンスが十分に 適化されていない場合や、データベース・サーバーの 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）です。

関連項目関連項目関連項目関連項目 :

� SQL アプリケーションの監視とチューニングの機能の詳細は、『Oracle Enterprise Manager 概要』 を参照してください。

� 自動 SQL チューニング機能については、第 12 章「自動 SQL チューニング」を参照してください。

関連項目関連項目関連項目関連項目 : 第 20 章「アプリケーション・トレース・ツールの使用方法」

関連項目関連項目関連項目関連項目 : 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 セクションにはこのデータが含まれているため、割合を手動で計算する必要はありません。

候補の 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 文の以前のオプティマイザ計画の安定性

関連項目関連項目関連項目関連項目 : 動的パフォーマンス・ビューの詳細は、『Oracle Database リファレンス』を参照してください。

注意注意注意注意 : アプリケーション内の主要な SQL 文すべてについて、実行計画を生成し、見直すことが重要です。これにより、SQL 文が効率よく実行されたときのオプティマイザの実行計画と、そうでないときの計画とを比較できます。データ量の変化などの情報とあわせて比較を行うと、パフォーマンスの低下の原因を正確に識別できます。

11-4 Oracle Database パフォーマンス・チューニング・ガイド

自動 SQL チューニング機能

自動自動自動自動 SQL チューニング機能チューニング機能チューニング機能チューニング機能手動 SQL チューニング・プロセスはアプリケーション開発者に多数の作業が課されるため、SQL チューニング・プロセスは自動 SQL チューニング管理機能により自動化されています。これらの機能は、OLTP タイプとデータ・ウェアハウス・タイプのアプリケーションで同様に機能するように設計されています。第 12 章「自動 SQL チューニング」を参照してください。

ADDMAutomatic 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 文がアプリケーションに含まれている場合に特に言えます。

� データ・ディクショナリ内のオプティマイザ統計が表と索引内のデータを反映しなくなっている場合は、新しい統計を収集します。ディクショナリ統計が失効しているかどうかをチェックする方法の 1 つは、表の実際のカーディナリティ（行数）と、DBA_TABLES.NUM_ROWSの値を比較することです。また、述語列に大きなデータの偏りがある場合は、ヒストグラムを使用することを検討してください。

実行計画の検討実行計画の検討実行計画の検討実行計画の検討OLTP 環境で SQL 文をチューニング（または作成）する場合、 も選択性の高いフィルタを持つ表から駆動することを目標とします。つまり、次のステップに渡される行を少なくするということです。次のステップが結合である場合は、少数の行しか結合されないということになります。アクセス・パスが 適かどうかを確認してください。

オプティマイザの実行計画を調べる場合は、次の内容を確認します。

� 駆動表が 適なフィルタを持つ計画であること。

� 各ステップの結合順序は、 少数の行が次のステップに戻されるようにします（つまり、可能であれば、結合の順序は 適な未使用フィルタを選んで進むようにする必要があります）。

� 結合方法が、それによって戻される行数からみた場合に、適切なものであること。たとえば、索引でのネステッド・ループ結合は、多数の行が戻される場合には 適ではありません。

� ビューが効果的に使用されていること。SELECT構文のリストを見て、ビューへのアクセスが必要であるかどうかを確認してください。

� 意図しないデカルト積（小さい表の場合も含む）があるかどうか。

注意注意注意注意 : この項で説明するガイドラインは、頻繁に実行される本番 SQL に関するものです。この項でお薦めしていない技法の大半は、パフォーマンスが重要でない非定型文または頻繁に実行されないアプリケーションでは使用してもかまいません。

11-6 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)

特定のタスクに対する専用の特定のタスクに対する専用の特定のタスクに対する専用の特定のタスクに対する専用の SQL 文の作成文の作成文の作成文の作成SQL は、手続き型言語ではありません。1 つの SQL を使用して様々なことを実行すると、通常は各タスクに 適でない結果が生じます。SQL を使用して様々なタスクを実行する場合は、1つの文にパラメータを指定して異なるタスクを実行するのではなく、様々な文を作成してください。

通常、異なるタスクには個別の SQL 文を作成することが適していますが、使用する SQL 文を 1つにする必要がある場合は、UNION ALL演算子を使用することによって、非常に複雑な文を多少簡略化できます。

適化（実行計画の決定）は、どの値で問合せが置換されるかをデータベースが認識する前に行われます。したがって、実行計画はそれらの値が何であるかに依存しません。 たとえば、次のような場合があります。

SELECT info FROM tablesWHERE ... AND somecolumn BETWEEN DECODE(:loval, 'ALL', somecolumn, :loval)AND DECODE(:hival, 'ALL', somecolumn, :hival);

この例では、データベースは somecolumn列に対して索引を使用できません。この列を含む式が、BETWEENの両辺で同じ列を使用するためです。

このことは、選択性の高い、索引作成可能な他の条件が別にあって、それを使用して駆動表にアクセスできる場合には問題になりません。ただし、これにあてはまらない場合もよくありま

関連項目関連項目関連項目関連項目 : ファンクション索引の詳細は、第 15 章「索引およびクラスタの使用方法」を参照してください。

注意注意注意注意 : Oracle Forms と Oracle Reports は、PL/SQL（トリガーまたはプログラム・ユニット）を使用してアプリケーション・ロジックをコード化するための強力な開発ツールです。Forms または Reports で複雑なロジックを処理することによって、SQL 文の複雑さを減らすことができます。また、規模の大きな単一の複雑な SQL 文のかわりに、少数の SQL 文を実行するサーバー側の PL/SQL パッケージを起動することもできます。このパッケージはサーバー側のユニットであるため、クライアントとデータベースの間のラウンドトリップやネットワークの通信量の問題は発生しません。

11-8 Oracle Database パフォーマンス・チューニング・ガイド

効率的な SQL 文の開発

す。この例のような条件で索引を使用することは多くありますが、:lovalなどの値を、あらかじめ知っておく必要があります。この情報があれば、索引を使用できない ALLのケースを除外できます。

:lovalと :hivalに実際の値が指定されている場合には必ず索引を使用する場合（:lovalと:hivalの間が狭く、多くの場合等しいことが期待できる場合）は、この例を論理的に等しい、次の形式にリライトできます。

SELECT /* change this half of UNION ALL if other half changes */ infoFROM tables WHERE ... AND somecolumn BETWEEN :loval AND :hivalAND (:hival != 'ALL' AND :loval != 'ALL') UNION ALL SELECT /* Change this half of UNION ALL if other half changes. */ infoFROM tablesWHERE ... 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を使用します。

副問合せに IN句を使用した場合に、副問合せで指定される選択性の利点を活用するために、Oracle が副問合せをリライトすることがあります。これは、 も選択性の高いフィルタが副問合せにある場合、結合列に索引がある場合に、 も有効です。これに対し、EXISTSは、 も選択性の高いフィルタが親問合せにある場合に有効です。その場合、EXISTS基準に照らして行をフィルタにかける前に、親問合せの選択的述語を適用できるからです。

注意注意注意注意 : この説明は、親 SQL または副問合せへのアクセス・パスが選択性の高い索引付きの列を経由するような OLTP 環境で も当てはまります。DSS 環境では、親 SQL または副問合せの選択性が低い場合があり、結合列には索引がない可能性もあります。DSS 環境では、EXISTSの場合にセミ結合を使用することを考慮してください。

関連項目関連項目関連項目関連項目 : 『Oracle Database データ・ウェアハウス・ガイド』

注意注意注意注意 : 使用したリソース（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 */

次の計画出力は、前述の文の実行計画（V$SQL_PLANからのもの）です。この計画では、employees表の全表スキャンを必要とし、そのため、多数の行が戻されます。次に、戻された各行が orders表で（索引を経由して）フィルタにかけられます。

ID OPERATION OPTIONS OBJECT_NAME OPT COST---- -------------------- --------------- ---------------------- --- ---------- 0 SELECT STATEMENT CHO 1 FILTER 2 TABLE ACCESS FULL EMPLOYEES ANA 155 3 TABLE ACCESS BY INDEX ROWID ORDERS ANA 3 4 INDEX RANGE SCAN ORD_CUSTOMER_IX ANA 1

INを使用して文をリライトすると、使用されるリソースが大幅に減少します。

INを使用する SQL 文

SELECT /* IN example */ e.employee_id, e.first_name, e.last_name, e.salary FROM employees e WHERE e.employee_id IN (SELECT o.sales_rep_id /* Note 4 */ FROM orders o WHERE o.customer_id = 144); /* Note 3 */

注意注意注意注意 :

� Note 1: EXISTSを含む行です。

� Note 2: 副問合せを相関副問合せにする行です。

� Note 3: 相関副問合せに選択性の高い述語 customer_id = numberが含まれている行です。

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

効率的な SQL 文の開発

次の計画出力は、前述の文の実行計画（V$SQL_PLANからのもの）です。オプティマイザは副問合せをビューにリライトし、次にそれが一意索引で employees表に結合されます。この結果、計画は大幅に改善されます。ビュー（すなわち、副問合せ）に選択的述語があるため、わずかな employee_idのみが戻されるためです。次に、このわずかな employee_idで、一意索引から employees表にアクセスします。

ID OPERATION OPTIONS OBJECT_NAME OPT COST---- -------------------- --------------- ---------------------- --- ---------- 0 SELECT STATEMENT CHO 1 NESTED LOOPS 5 2 VIEW 3 3 SORT UNIQUE 3 4 TABLE ACCESS FULL ORDERS ANA 1 5 TABLE ACCESS BY INDEX ROWID EMPLOYEES ANA 1 6 INDEX 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, e.salary FROM employees e WHERE e.department_id = 80 /* Note 5 */ AND e.job_id = 'SA_REP' /* Note 6 */ AND e.employee_id IN (SELECT o.sales_rep_id FROM orders o); /* Note 4 */

次の計画出力は、前述の文の実行計画（V$SQL_PLANからのもの）です。SQL 文は、orders表でビューを使用するようにオプティマイザでリライトされています。この文では、orders表に存在するすべての一意の employee_idを戻すためにデータのソートが必要です。述語がないため、多数の employee_idsが戻されます。この多数の employee_idからなる大きなリストが、一意索引を使用して employees表へのアクセスに使用されることになります。

ID OPERATION OPTIONS OBJECT_NAME OPT COST---- -------------------- --------------- ---------------------- --- ---------- 0 SELECT STATEMENT CHO 1 NESTED LOOPS 125 2 VIEW 116 3 SORT UNIQUE 116 4 TABLE ACCESS FULL ORDERS ANA 40 5 TABLE ACCESS BY INDEX ROWID EMPLOYEES ANA 1 6 INDEX UNIQUE SCAN EMP_EMP_ID_PK ANA

注意注意注意注意 :

� Note 3: 相関副問合せに選択性の高い述語 customer_id = numberが含まれている行です。

� Note 4: INが使用されている行です。副問合せは、相関ではなくなっています。これは、IN句が副問合せ内の結合を置換するためです。

注意注意注意注意 :

� Note 4: INが使用されている行です。副問合せは、相関ではなくなっています。これは、IN句が副問合せ内の結合を置換するためです。

� Note 5 および 6: 親 SQL 内に選択的述語があります。

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 */

次の計画出力は、前述の文の実行計画（V$SQL_PLANからのもの）です。計画のコストは、EXISTSを使用するように SQL 文をリライトすることで削減されます。この計画は、より効率的です。これは、2 つの索引を使用して親問合せ内の述語を満たすため、戻されるemployee_idがきわめて少ないためです。次に、この employee_idを使用して、索引からorders表にアクセスします。

ID OPERATION OPTIONS OBJECT_NAME OPT COST---- -------------------- --------------- ---------------------- --- ---------- 0 SELECT STATEMENT CHO 1 FILTER 2 TABLE ACCESS BY INDEX ROWID EMPLOYEES ANA 98 3 AND-EQUAL 4 INDEX RANGE SCAN EMP_JOB_IX ANA 5 INDEX RANGE SCAN EMP_DEPARTMENT_IX ANA 6 INDEX RANGE SCAN ORD_SALES_REP_IX ANA 8

ヒントによるアクセス・パスおよび結合順序の制御ヒントによるアクセス・パスおよび結合順序の制御ヒントによるアクセス・パスおよび結合順序の制御ヒントによるアクセス・パスおよび結合順序の制御オプティマイザのアプローチと目標の設定および問合せオプティマイザの代表的な統計の収集によって、オプティマイザの選択を変えることができます。特定のアプリケーション・データに関して、オプティマイザよりも多くの情報を持つアプリケーション設計者であれば、より効率よく SQL 文を実行する方法を選択できる場合があります。SQL 文のヒントを使用すれば、文を実行する方法をオプティマイザに指示できます。

/*+FULL */ などのヒントは、アクセス・パスを制御します。 たとえば、次のようにします。

SELECT /*+ FULL(e) */ e.last_name FROM employees e WHERE e.job_id = 'CLERK';

注意注意注意注意 :

� Note 1: EXISTSを含む行です。

� Note 2: 副問合せを相関副問合せにする行です。

� Note 5 および 6: 親 SQL 内に選択的述語があります。

注意注意注意注意 : より効果的なアプローチは、department_idおよび job_idの連結索引を作成することです。これによって 2 つの索引にアクセスする必要がなくなり、使用されるリソースが削減されます。

関連項目関連項目関連項目関連項目 : 第 13 章「問合せオプティマイザ」および第 16 章「オプティマイザ・ヒントの使用方法」

11-12 Oracle Database パフォーマンス・チューニング・ガイド

効率的な SQL 文の開発

結合順序は、パフォーマンスに大きな影響を与えることがあります。SQL のチューニングの主な目的は、結果に影響しない不要な行にアクセスする作業を回避することです。このことから次の 3 つの一般ルールが導かれます。

� 索引を介して必要な行を取得する方が効率的な場合には、全表スキャンを避けてください。

� 100 行をフェッチする別の索引を使用できる場合には、駆動表から 10,000 行をフェッチする索引を使用するようなことは避けてください。

� 結合順序の後ろへ行くほど結合する行が少なくなるように結合順序を選択してください。

次の例は、結合順序を効果的にチューニングする方法を示しています。

SELECT infoFROM taba a, tabb b, tabc cWHERE a.acol BETWEEN 100 AND 200AND b.bcol BETWEEN 10000 AND 20000AND c.ccol BETWEEN 10000 AND 20000AND a.key1 = b.key1AND 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ヒントを使用して、結合順序を強制的に設定できます。

ビューを管理するときの注意ビューを管理するときの注意ビューを管理するときの注意ビューを管理するときの注意ビューの結合、ビューへの外部結合、および既存ビューの新規目的への再利用に対しては、注意が必要です。

複合ビューを結合するときの注意複合ビューを結合するときの注意複合ビューを結合するときの注意複合ビューを結合するときの注意 複合ビューへの結合、特に、ある複合ビューから別の複合ビューへの結合はお薦めできません。そのような結合を行うと、多くの場合、ビュー全体がインスタンス化され、ビュー・データに対して問合せが行われる結果になります。

たとえば、次の文は従業員および部門をリストするビューを作成します。

CREATE OR REPLACE VIEW emp_deptASSELECT d.department_id, d.department_name, d.location_id, e.employee_id, e.last_name, e.first_name, e.salary, e.job_idFROM departments d ,employees eWHERE e.department_id (+) = d.department_id;

関連項目関連項目関連項目関連項目 : 16-4 ページ「結合順序のヒント」

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_deptWHERE department_id = 10;

ビュー全体ではまず、employeesおよび departments表の結合によりインスタンス化され、次にデータが集計されます。ただし、department_nameと department_idは、departments表から直接取得できます。emp_deptビューを問い合せてこの情報を取得することは非効率的です。

副問合せのネストを解除するときの注意副問合せのネストを解除するときの注意副問合せのネストを解除するときの注意副問合せのネストを解除するときの注意 副問合せのネストの解除によって、副問合せ本体が解除され、その副問合せが含まれている文の本体にマージされます。これにより、オプティマイザは、アクセス・パスと結合を評価するときに、副問合せと本体の両方をいっしょに考慮させてしまいます。

ビューへの外部結合を実行するときの注意ビューへの外部結合を実行するときの注意ビューへの外部結合を実行するときの注意ビューへの外部結合を実行するときの注意 複数表のビューに対する外部結合の場合、等価述語が定義されていれば、問合せオプティマイザ（リリース 8.1.6 以上）は外部結合列から駆動できます。

ビュー内での外部結合は、外部結合のパフォーマンスに与える影響が読めないため、問題が発生しやすくなります。

関連項目関連項目関連項目関連項目 : 副問合せのネスト解除における危険性については、『Oracle Database データ・ウェアハウス・ガイド』を参照してください。

11-14 Oracle Database パフォーマンス・チューニング・ガイド

効率的な SQL 文の開発

中間結果の格納中間結果の格納中間結果の格納中間結果の格納中間の表、すなわちステージング表がリレーショナル・データベース・システムで比較的よく利用されるのは、それらの表に中間結果を一時的に格納するためです。これは、多くのアプリケーションで役に立つものですが、作成するにはさらにリソースが必要になります。したがって、これらの表による利益が、作成のコストに見合うものかどうかを常に考慮してください。ステージング表は、その情報が何回も再利用されない場合は、作成しないようにしてください。

他の考慮事項

� ステージング表に中間結果を格納することで、アプリケーション・パフォーマンスを向上できる場合があります。一般に、中間結果が、引き続きその後の複数の問合せで使用可能であれば、その結果をステージング表に格納する価値があります。中間結果の再利用により、複雑な文を使用して何度もデータを取り出すことをしないで済む利益は、中間結果をマテリアライズするコストを上回ります。

� 長く複雑な問合せは、理解し、 適化することが困難です。ステージング表を使用することで、複雑な SQL 文をいくつかの小さい文に分解でき、このとき、各ステップの結果を格納します。

� マテリアライズド・ビューを使用することを検討してください。マテリアライズド・ビューは、ファクト表やディメンション表からの集計データや結合データを格納する、あらかじめ計算済の表です。

索引の再構成索引の再構成索引の再構成索引の再構成多くの場合は、索引を再構成すると、パフォーマンスが向上します。これには、次の内容が含まれます。

� 非選択的な索引を削除して、DML の速度を上げます。

� パフォーマンス重視のアクセス・パスの索引を作成します。

� 既存の連結索引で列を並び換えることを考慮します。

� 索引に列を追加して、選択性を向上します。

索引を万能策として使用しないでください。アプリケーションの開発者は、索引を多く作成すればパフォーマンスが改善されると考えることがあります。1 人のプログラマが適切に索引を作成すれば、アプリケーションのパフォーマンスは十分に改善される可能性があります。ただし、50 名のプログラマが別々に索引を作成すると、アプリケーションのパフォーマンス改善は望めません。

トリガーおよび制約の変更または無効化トリガーおよび制約の変更または無効化トリガーおよび制約の変更または無効化トリガーおよび制約の変更または無効化トリガーを使用すると、システムのリソースが消費されます。使用するトリガーが多すぎると、パフォーマンスに悪影響が及ぶので、トリガーを変更または使用禁止にする必要がある場合があります。

データの再構成データの再構成データの再構成データの再構成索引と文を再構成した後で、データの再構成について検討できます。

� 導出された値を用意しておきます。応答時間重視のコードでは、GROUP BYの使用を回避します。

� データ設計を検討します。変更によりパフォーマンスの向上が見込める場合は、システムの設計を変更します。

� 必要に応じて、パーティション化を考慮します。

関連項目関連項目関連項目関連項目 : マテリアライズド・ビューの使用方法に関する詳細は、『Oracle Database データ・ウェアハウス・ガイド』を参照してください。

SQL チューニングの概要 11-15

効率的な SQL 文の開発

実行計画の長期的な保持実行計画の長期的な保持実行計画の長期的な保持実行計画の長期的な保持格納されている統計または SQL 実行計画を使用すると、SQL 文の既存の実行計画を長期的に保持できます。表のオプティマイザの統計を格納すると、その表を参照するすべての SQL 文にその統計が適用されます。実行計画を格納すると（すなわち、プラン・スタビリティ）、単一のSQL 文の計画が保持されます。統計およびストアド・プランの両方が SQL 文に対して使用可能な場合は、オプティマイザはストアド・プランの方を使用します。

データへのアクセスを最小限に削減データへのアクセスを最小限に削減データへのアクセスを最小限に削減データへのアクセスを最小限に削減アプリケーションから各行へのアクセスを、可能なかぎり 1 回のみにします。そうすることで、ネットワークの通信量が削減され、データベースの負荷が軽減されます。次を実行することを考慮してください。

� CASE 文による複数のスキャンの結合

� RETURNING 句を持つ DML の使用

� 1 つの文での必要なすべてのデータの変更

CASE 文による複数のスキャンの結合文による複数のスキャンの結合文による複数のスキャンの結合文による複数のスキャンの結合多くの場合、様々な表セットで異なった集計を行う必要があります。通常、この計算は、表に複数のスキャンを行って処理されますが、1 回の単一のスキャンですべての集計を計算すると簡単です。n-1 回のスキャンを排除することで、パフォーマンスを大幅に向上できます。

複数のスキャンを 1 つのスキャンに結合するには、各スキャンの WHERE条件の内容を CASE文の中に移動します。CASE文は、集計対象のデータをフィルタにかけます。各集計では、データを取り出す別の列があっても構いません。

次の例では、収入が毎月 2000 より少ない社員、2000 ～ 4000 の社員、4000 を超える社員の数を問い合せています。これは、次の 3 つの問合せで行うことができます。

SELECT COUNT (*) FROM employees WHERE salary < 2000;

SELECT COUNT (*) FROM employees WHERE salary BETWEEN 2000 AND 4000;

SELECT COUNT (*) FROM employees WHERE salary>4000;

しかし、1 つの文で問合せ全体を実行する方が効率的です。各数値は 1 つの列として計算されます。count ファンクションは、CASE文によるフィルタを使用して、条件が一致する行のみを数えます。 たとえば、次のような場合があります。

SELECT COUNT (CASE WHEN salary < 2000 THEN 1 ELSE null END) count1, COUNT (CASE WHEN salary BETWEEN 2001 AND 4000 THEN 1 ELSE null END) count2, COUNT (CASE WHEN salary > 4000 THEN 1 ELSE null END) count3 FROM employees;

これは、きわめて単純な例です。範囲が重なっていたり、集計の関数が異なっていることもあります。

関連項目関連項目関連項目関連項目 :

� 第 14 章「オプティマイザ統計の管理」

� 第 18 章「プラン・スタビリティの使用方法」

11-16 Oracle Database パフォーマンス・チューニング・ガイド

効率的な SQL 文の開発

RETURNING 句を持つ句を持つ句を持つ句を持つ DML の使用の使用の使用の使用適時、INSERT、UPDATEまたは DELETE...RETURNINGを使用して、1 回のコールでデータを選択および変更します。この技法は、データベースのコール回数を減らすことでパフォーマンスを改善します。

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文で複数の行を自動的に削除します。

関連項目関連項目関連項目関連項目 : INSERT、UPDATEおよび DELETEの各文の構文については、『Oracle Database SQL 言語リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : 分散問合せをチューニングする方法の詳細は、『Oracle Database 管理者ガイド』または『Oracle Database Heterogeneous Connectivity 管理者ガイド』を参照してください。

SQL チューニングの概要 11-17

効率的な SQL 文の開発

11-18 Oracle Database パフォーマンス・チューニング・ガイド

自動 SQL チュー

12

自動自動自動自動 SQL チューニングチューニングチューニングチューニング

この章では、Oracle の自動 SQL チューニング機能について説明します。

この章には次の項があります。

� 自動 SQL チューニングの概要

� SQL チューニング・アドバイザ

� SQL チューニング・セット

� SQL プロファイル

� SQL チューニング情報ビュー

関連項目関連項目関連項目関連項目 : SQL 文の監視およびチューニングの詳細は、『Oracle Database 2 日でデータベース管理者』を参照してください。

ニング 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 プロファイルを他のユーザー・セッションで使用可能にする前に、限定的な環境でテストできます。

ストアド・アウトラインとは異なり、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演算子の方が効率的です。このように変更するには、データ・プロパティを十分に理解し、実装前に慎重に考慮する必要があります。

関連項目関連項目関連項目関連項目 : SQLTUNE_CATEGORY初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

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パッケージを使用した 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 チューニング・アドバイザを実行する場合に必要な手順を示しています。

関連項目関連項目関連項目関連項目 : DBMS_SQLTUNEパッケージのセキュリティ・モデルの詳細情報については、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

12-6 Oracle Database パフォーマンス・チューニング・ガイド

SQL チューニング・アドバイザ

図図図図 12-1 SQL チューニング・アドバイザチューニング・アドバイザチューニング・アドバイザチューニング・アドバイザ API

この項では、次のトピックについて説明します。

� SQL チューニング・タスクの作成

� SQL チューニング・タスクの実行

� SQL チューニング・タスクのステータスのチェック

� SQL チューニング・アドバイザの進捗のチェック

� SQL チューニング・タスクの結果の表示

� 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 ' ||

関連項目関連項目関連項目関連項目 : DBMS_SQLTUNEパッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

自動 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 1000SET LONGCHUNKSIZE 1000SET LINESIZE 100SELECT 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 VARCHAR2(30);BEGIN my_sqlprofile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE ( task_name => 'my_sql_tuning_task', name => 'my_sql_profile',) force_match => TRUE);END;

この例では、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 によって処理される SQL 文について、オプティマイザは表 13-1 にリストした操作を実行します。

オプティマイザの目標の設定および問合せオプティマイザの代表的な統計の収集によって、オプティマイザの選択を変えることができます。オプティマイザの目標はスループットまたは応答時間です。13-3 ページの「オプティマイザの目標の選択」および 13-5 ページの「データ・ディクショナリ内の問合せオプティマイザ統計」を参照してください。

特定のアプリケーション・データに関して、オプティマイザよりも多くの情報を持つアプリケーション設計者であれば、より効率よく SQL 文を実行する方法を選択できる場合があります。アプリケーション・デザイナは SQL 文のヒントを使用して、文の実行方法についてオプティマイザに指示できます。

注意注意注意注意 : オプティマイザは、Oracle のあるバージョンとその次のバージョンで同じ決定を行うとはかぎりません。 新バージョンのオプティマイザは、より高度な情報を使用できるので、異なる決定を行います。

表表表表 13-1 オプティマイザ操作オプティマイザ操作オプティマイザ操作オプティマイザ操作

操作操作操作操作 説明説明説明説明

式と条件の評価 オプティマイザは、まず、定数が含まれている式と条件を可能なかぎり完全に評価します。

文の変換 たとえば、相関副問合せやビューなどに関連する複合文について、オプティマイザは元の文を同等の結合文に変換する場合があります。

オプティマイザの目標の選択 オプティマイザでは、 適化の目標が判別されます。 13-3 ページの

「オプティマイザの目標の選択」を参照してください。

アクセス・パスの選択 文がアクセスするそれぞれの表について、オプティマイザは、表データを取得するために 1 つ以上の使用可能なアクセス・パスを選

択します。 13-14 ページの「問合せオプティマイザのアクセス・パス

について」を参照してください。

結合順序の選択 2 つ以上の表を結合する結合文について、オプティマイザは、 初

に結合する表のペアを選択し、その後、その結果に結合する表を順次選択していきます。 13-23 ページの「問合せオプティマイザによる

結合の実行計画の選択方法」を参照してください。

13-2 Oracle Database パフォーマンス・チューニング・ガイド

オプティマイザの目標の選択

オプティマイザの目標の選択オプティマイザの目標の選択オプティマイザの目標の選択オプティマイザの目標の選択デフォルトでは、問合せオプティマイザの目標は 高のスループットです。つまり、CBO は文からアクセスされたすべての行を処理するのに必要な 小リソースを選択します。また 短応答時間を目標とした文の 適化も可能です。つまり、CBO は SQL 文からアクセスされた 初の行を処理するのに必要な 小リソースを使用します。

アプリケーションのニーズに基づいて、オプティマイザの目標を選択してください。

� Oracle Reports アプリケーションのように、バッチで実行されるアプリケーションの場合は、 高のスループットを目標に 適化してください。アプリケーションを起動するユーザーの関心は、アプリケーションを完了するために必要な時間のみに向けられているため、通常、バッチ・アプリケーションではスループットの重要度が高くなります。アプリケーションの実行中にユーザーが個々の文の結果を調べることはないため、応答時間はそれほど重要ではありません。

� Oracle Formsアプリケーションや SQL*Plusの問合せのような対話形式のアプリケーションの場合は、 短の応答時間を目標に 適化してください。対話形式では、ユーザーは、文がアクセスする 初の行を参照するために待機しています。このため、対話形式のアプリケーションでは応答時間が重要となります。

SQL 文に対する 適化のアプローチと目標を選択する場合のオプティマイザの動作は、次の要因の影響を受けます。

� OPTIMIZER_MODE 初期化パラメータ

� 問合せオプティマイザの目標変更に対するオプティマイザ SQL のヒント

� データ・ディクショナリ内の問合せオプティマイザ統計

関連項目関連項目関連項目関連項目 :

� SQL 処理およびオプティマイザの概要は、『Oracle Database 概要』を参照してください。

� 拡張可能オプティマイザの詳細は、『Oracle Database データ・カートリッジ開発者ガイド』を参照してください。

� 適化の目標の詳細は、13-3 ページの「オプティマイザの目標の選択」を参照してください。

� 統計を収集および使用する方法の詳細は、第 14 章「オプティマイザ統計の管理」を参照してください。

� SQL 文のヒントを使用する方法の詳細は、第 16 章「オプティマイザ・ヒントの使用方法」を参照してください。

問合せオプティマイザ 13-3

オプティマイザの目標の選択

OPTIMIZER_MODE 初期化パラメータ初期化パラメータ初期化パラメータ初期化パラメータOPTIMIZER_MODE初期化パラメータで、インスタンスに 適化アプローチを選択するためのデフォルト動作を設定します。指定可能な値およびその説明を表 13-2 に示します。

初期化ファイル内のパラメータ値の変更、または 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-2 OPTIMIZER_MODE 初期化パラメータ値初期化パラメータ値初期化パラメータ値初期化パラメータ値

値値値値 説明説明説明説明

ALL_ROWS オプティマイザは、セッション内の SQL 文に対して、統計の有無

とは関係なくコストベースのアプローチを使用し、 高のスループット（ 小のリソースを使用して文全体を完成させること）を目標として 適化します。これはデフォルト値です。

FIRST_ROWS_n オプティマイザは統計の有無とは関係なく、コストベースのアプローチを使用し、 短応答時間で 初の n 行を戻すように 適化し

ます。n は 1、10、100 または 1000 です。

FIRST_ROWS オプティマイザは、コストと経験則を組み合せて、 初の数行の高速配信のための 適な計画を見つけます。

注意 : 問合せオプティマイザは、経験則を使用すると、経験則を適

用しない場合に比べてコストがはるかに大きい計画を生成する場合があります。FIRST_ROWSは、下位互換性とプラン・スタビリティ

のためのものです。かわりに FIRST_ROWS_nを使用してください。

表表表表 13-3 問合せオプティマイザの目標変更に対するヒント問合せオプティマイザの目標変更に対するヒント問合せオプティマイザの目標変更に対するヒント問合せオプティマイザの目標変更に対するヒント

ヒントヒントヒントヒント 説明説明説明説明

FIRST_ROWS(n) このヒントは、個々の SQL 文を 適化して 初の n 行を 短応答

時間で戻すように、Oracle に指示します。ここでは、n は正の整数

です。このヒントでは、SQL 文に対して、統計の有無に関係なくコ

ストベースのアプローチが使用されます。

ALL_ROWS このヒントでは、 高のスループットを目標として SQL 文を 適化

するために、コストベースのアプローチが明示的に選択されます。

関連項目関連項目関連項目関連項目 : ヒントを使用する方法の詳細は、第 16 章「オプティマイザ・ヒントの使用方法」を参照してください。

13-4 Oracle Database パフォーマンス・チューニング・ガイド

問合せオプティマイザ機能の有効化および制御

データ・ディクショナリ内の問合せオプティマイザ統計データ・ディクショナリ内の問合せオプティマイザ統計データ・ディクショナリ内の問合せオプティマイザ統計データ・ディクショナリ内の問合せオプティマイザ統計問合せオプティマイザで使用される統計は、データ・ディクショナリに格納されます。DBMS_STATSパッケージを使用して、これらのスキーマ・オブジェクト内の物理的な記憶域の特性とデータ配分に関する正確な統計または見積り統計を収集できます。

問合せオプティマイザの有効性を維持するには、データを代表する統計が必要です。偏ったデータという、値の重複数のバリエーションが多いデータが存在する表列については、ヒストグラムを収集する必要があります。

その結果の統計によって、データの一意性と配分についての情報が問合せオプティマイザに提供されます。この情報を使用することにより、問合せオプティマイザは計画コストを精密に計算します。その結果、問合せオプティマイザは 小のコストを基に 良の実行計画を選択できるようになります。

問合せオプティマイザを使用するときに統計が使用不可である場合、OPTMIZER_DYNAMIC_SAMPLING初期化パラメータの設定によって、オプティマイザで動的サンプリングが実行されます。この場合、 高のパフォーマンスを得るために解析時間が遅くなる可能性があるため、オプティマイザに代表的なオプティマイザ統計が必要となります。

問合せオプティマイザ機能の有効化および制御問合せオプティマイザ機能の有効化および制御問合せオプティマイザ機能の有効化および制御問合せオプティマイザ機能の有効化および制御この項には、オプティマイザに固有の初期化パラメータが含まれています。次の項は、Oracleのアプリケーションをチューニングするときに特に役に立ちます。

問合せオプティマイザ機能の有効化問合せオプティマイザ機能の有効化問合せオプティマイザ機能の有効化問合せオプティマイザ機能の有効化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パラメータを以前のバージョンに設定します。たとえば、問

関連項目関連項目関連項目関連項目 :

� 第 14 章「オプティマイザ統計の管理」

� ヒストグラムの詳細は、14-16 ページの「ヒストグラムの表示」を参照してください。

� 14-13 ページ「動的サンプリングを使用した統計の見積り」

関連項目関連項目関連項目関連項目 : 初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

問合せオプティマイザ 13-5

問合せオプティマイザ機能の有効化および制御

合せオプティマイザの動作をリリース 8.1.5 に保持するには、次のようにパラメータを設定します。

OPTIMIZER_FEATURES_ENABLE=8.1.5;

この文により、8.1.5 より後のリリースで追加されたすべての新規オプティマイザ機能が無効になります。

以前のリリースに OPTIMIZER_FEATURES_ENABLEパラメータを明示的に設定することはお薦めしません。実行計画または問合せパフォーマンスの問題点は、必要に応じて解決することをお薦めします。

問合せオプティマイザの動作の制御問合せオプティマイザの動作の制御問合せオプティマイザの動作の制御問合せオプティマイザの動作の制御この項には、問合せオプティマイザの動作の管理に使用できる初期化パラメータの一部がリストされています。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 であることを意味します。

注意注意注意注意 : リリースをアップグレードし、使用可能な新機能を有効にする場合は、OPTIMIZER_FEATURES_ENABLE初期化パラメータを明示的に設定する必要はありません。

関連項目関連項目関連項目関連項目 : OPTIMIZER_FEATURES_ENABLEパラメータに設定する各リリースの値と、それにより有効になるオプティマイザ機能の詳細は、

『Oracle Database リファレンス』を参照してください。

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に設定すると、問合せオプティマイザはスター・クエリーのためのスター型変換のコストを計算できます。スター型変換により、様々なファクト表の列でビットマップ索引が結合されます。

問合せオプティマイザについて問合せオプティマイザについて問合せオプティマイザについて問合せオプティマイザについて問合せオプティマイザは、SQL 文がアクセスするスキーマ・オブジェクト（表または索引）について、使用可能なアクセス・パスを検討し、統計に基づいた情報要素を考慮することによって も効果的な実行計画を判断します。また、問合せオプティマイザは文のコメントに配置された、 適化の指示であるヒントも考慮します。

問合せオプティマイザは次のステップを実行します。

1. 使用可能なアクセス・パスおよびヒントに基づき、SQL 文の可能な計画のセットを生成します。

2. 文がアクセスする表、索引およびパーティションのデータ配分および記憶特性に関するデータ・ディクショナリ内の統計に基づき、計画のそれぞれのコストを見積ります。

コストコストコストコストとして見積られる値は、特定の計画での文の実行に必要と予測されるリソース使用量に比例しています。オプティマイザは、I/O、CPU、メモリーなどのコンピュータ・リソースの見積りに基づいて、アクセス・パスや結合順序のコストを計算します。

コストの大きいシリアル計画の実行には、コストの小さい計画の実行よりも多くの時間が必要です。ただし、パラレル計画を使用する場合は、リソース使用量は経過時間に直接関係しません。

3. 計画のコストを比較して、コストが も小さいものを選択します。

関連項目関連項目関連項目関連項目 : 各パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : ヒントの詳細は、第 16 章「オプティマイザ・ヒントの使用方法」を参照してください。

問合せオプティマイザ 13-7

問合せオプティマイザについて

問合せオプティマイザの構成要素問合せオプティマイザの構成要素問合せオプティマイザの構成要素問合せオプティマイザの構成要素問合せオプティマイザ操作には、次のものがあります。

� 問合せの変換

� 見積り

� 計画の生成

問合せオプティマイザの構成要素を図 13-1 に示します。

図図図図 13-1 問合せオプティマイザの構成要素問合せオプティマイザの構成要素問合せオプティマイザの構成要素問合せオプティマイザの構成要素

問合せの変換問合せの変換問合せの変換問合せの変換問合せトランスフォーマへの入力は、一連の問合せブロックによって表される解析済問合せです。問合せブロックは、互いにネストされているかまたは相互関係を持っています。問合せの形式によって、問合せブロックの相互関係が判断されます。問合せトランスフォーマの主な目的は、問合せの形式を変える必要があるかどうかを判断して、より適切な問合せ計画を生成できるようにすることです。問合せトランスフォーマでは、次のように様々な問合せ変換手法を採用しています。

� ビューのマージ

� 述語のプッシュ

� 副問合せのネスト解除

� マテリアライズド・ビューを使用したクエリー・リライト

これらの変換は任意に組み合せて指定の問合せに適用できます。

ビューのマージビューのマージビューのマージビューのマージ 問合せで参照されるビューは、パーサーによって個別の問合せブロックに拡張されます。問合せブロックは、基本的にはビュー定義を表しますが、このため必然的にビューの結果も表すことになります。オプティマイザには、ビューの問合せブロックの 1 つを分離して分析し、ビュー・サブプランを生成するというオプションがあります。オプティマイザは、問合せ計画全体の生成にビュー・サブプランを使用することで、残りの問合せを処理します。この手法は、そのビューが問合せの残りの部分とは別に 適化されるため、通常は 適な問合せ計画とはなりません。

13-8 Oracle Database パフォーマンス・チューニング・ガイド

問合せオプティマイザについて

問合せトランスフォーマは、ビューが含まれている問合せブロックにビューの問合せブロックをマージして、潜在的に 適とは言えない計画を除去します。ほとんどのタイプのビューがマージされます。ビューをマージするときには、ビューを表す問合せブロックが包含的な問合せブロックにマージされます。ビューの問合せブロックは除去されているので、サブプランを生成する必要はありません。

述語のプッシュ述語のプッシュ述語のプッシュ述語のプッシュ マージされていないビューについては、問合せトランスフォーマにより、関連する述語を、ビューを包含する問合せブロックからビューの問合せブロックに組み込むことができます。この手法は、プッシュされた述語を索引へのアクセスやフィルタに使用できるので、マージされていないビューのサブプランが改善されます。

副問合せのネスト解除副問合せのネスト解除副問合せのネスト解除副問合せのネスト解除 通常、副問合せを含む問合せのパフォーマンスは、副問合せのネストを解除して結合に変換することにで改善できます。大半の副問合せは、問合せトランスフォーマでネスト解除されます。ネスト解除されない副問合せの場合は、個別のサブプランが生成されます。問合せ計画全体の実行速度を上げるため、サブプランは効果的な順序で並べられます。

マテリアライズド・ビューを使用したクエリー・リライトマテリアライズド・ビューを使用したクエリー・リライトマテリアライズド・ビューを使用したクエリー・リライトマテリアライズド・ビューを使用したクエリー・リライト マテリアライズド・ビューは、結果がマテリアライズされて表に格納された問合せと類似しています。マテリアライズド・ビューに関連付けられた問合せと互換性のあるユーザー問合せが検出されると、ユーザー問合せはマテリアライズド・ビューにリライトできます。この手法は、ほとんどの問合せ結果があらかじめ計算されているため、ユーザー問合せの実行状態を改善します。問合せトランスフォーマは、ユーザー問合せと互換性のあるマテリアライズド・ビューを検索し、1 つ以上のマテリアライズド・ビューを選択してユーザー問合せをリライトします。問合せをリライトするためのマテリアライズド・ビューの使用はコストベースです。したがって、マテリアライズド・ビューを使用せずに生成された計画のコストが、マテリアライズド・ビューを使用して生成された計画のコストより低い場合、問合せはリライトされません。

ユーザー定義のバインド変数の照合ユーザー定義のバインド変数の照合ユーザー定義のバインド変数の照合ユーザー定義のバインド変数の照合問合せオプティマイザは、カーソルの 初の起動時にユーザー定義バインド変数の値を照合します。この機能により、WHERE句の条件の選択性と、バインド変数のかわりにリテラルが使用されたかどうかが判断されます。カーソルのその後の起動時は照合が行われず、また、その後の起動で異なるバインド値を使用しても、カーソルは標準カーソル共有基準に基づいて共有されます。

バインド変数が文に使用されている場合、カーソルを共有するために異なる起動が同じ実行計画を使用するものとみなします。カーソルの異なる起動で様々な実行計画が使用される場合、バインド変数が SQL 文で適切に使用されていない可能性があります。バインド照合は、すべてのクライアントではなく特定のクライアント・セットに対して機能します。

見積り見積り見積り見積りエスティメータは、異なるタイプのメジャーを 3 通り生成します。

� 選択性

� カーディナリティ

� コスト

これらのメジャーは相互に関連性があり、あるメジャーは別のメジャーから派生します。エスティメータの 終目標は、指定された計画のコスト全体を算出することです。統計が使用可能な場合、エスティメータは統計を使用してメジャーを計算します。統計によって、メジャーの正確さの度合いは改良されます。

関連項目関連項目関連項目関連項目 : クエリー・リライトの詳細は、『Oracle Database データ・ウェアハウス・ガイド』を参照してください。

問合せオプティマイザ 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列でヒストグラムが使用可能な場合、エスティメータは個別値のかわりにヒストグラムを使用します。ヒストグラムには列内の異なる値の分散が示されているので、より適切な選択性の見積りが行われます。偏ったデータ（値の重複数のバリエーションが多いデータ）が含まれている列のヒストグラムが存在すると、問合せオプティマイザが適切な選択性の見積りを生成するのに役立ちます。

カーディナリティカーディナリティカーディナリティカーディナリティ カーディナリティは、行セット内の行数を表します。ここでの行セットとは、実表、ビュー、結合結果または GROUP BY演算子の結果です。

コストコストコストコスト コストは、作業単位または使用されるリソースを表します。問合せオプティマイザはディスク I/O、CPU 使用量、メモリー使用量を作業単位として使用します。しかし、問合せオプティマイザによって使用されるコストは、操作の実行で使用した CPU とメモリーの量の見積り数になります。すなわち、操作には表をスキャンすること、索引を使用して表から行にアクセスすること、2 つの表を結合すること、または行セットをソートすることなどがあります。問合せ計画のコストは、問合せが実行されてその結果が生成されるときに発生すると予測される作業単位の数です。

アクセスアクセスアクセスアクセス・パスパスパスパスは、実表からデータを得るときに実行される作業単位数です。アクセス・パスには、表スキャン、高速全索引スキャンまたは索引スキャンがなどがあります。表スキャンまたは高速全索引スキャンの実行中には、単独の I/O 操作で複数のブロックがディスクから読み込まれます。したがって、表スキャンまたは高速全索引スキャンのコストは、スキャンされるブロック数およびマルチブロック READ カウントに左右されます。索引スキャンのコストは、B ツリーにおけるレベル、つまりスキャンされる索引リーフ・ブロック数、索引キーのROWID を使用してフェッチされる行数に左右されます。ROWID を使用して行をフェッチするコストは、索引クラスタ化係数に依存します。13-17 ページの「ブロックの I/O（行ではなく）の想定」を参照してください。

結合コスト結合コスト結合コスト結合コストは、結合されている 2 つの行セットの個別のアクセス・コストの組合せと、結合操作のコストを表します。

関連項目関連項目関連項目関連項目 : ヒストグラムの詳細は、14-16 ページの「ヒストグラムの表示」を参照してください。

関連項目関連項目関連項目関連項目 : 結合の詳細は、13-22 ページの「結合について」を参照してください。

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

問合せオプティマイザについて

計画の生成計画の生成計画の生成計画の生成プラン・ジェネレータの主な機能は、指定の問合せに対して使用できる可能性のある別の計画を割り出し、コストの も低いものを取り出すことです。異なる方法でデータをアクセスおよび処理し、かつ結果が同じになる、様々なアクセス・パス、結合方法および結合順序の組合せが存在するので、多数の異なる計画が使用できます。

結合順序は、異なる結合項目（表など）がアクセスされて結合される順序です。たとえば、table1、table2および table3の結合順序では、表 table1が 初にアクセスされます。次に、table2がアクセスされ、そのデータが table1のデータに結合されて table1とtable2の結合が生成されます。 後に table3がアクセスされ、そのデータが table1とtable2の結合結果に結合されます。

問合せのための計画は、まず 初にネストされた副問合せおよびマージされていないビューのそれぞれにサブプランを生成することによって構築されます。ネストされた副問合せ、またはマージされていないビューは、それぞれ、個別の問合せブロックによって表されます。問合せブロックは、それぞれ、下位から上位へ順番に 適化されます。つまり、 も内側の問合せブロックが 初に 適化され、サブプランが生成されます。そして、問合せ全体を表す も外側の問合せブロックは、 後に 適化されます。

プラン・ジェネレータは、別のアクセス・パス、結合方法および結合順序を試行することによって、問合せブロックに対する様々な計画を探索します。問合せブロックに使用できる可能性のある計画の数は、FROM句にある結合項目の数に比例します。この数は、結合項目の数によって指数関数的に上昇します。

プラン・ジェネレータは内部カットオフを使用して計画数を削減し、 もコストの低い計画を検索しようとします。カットオフの基準は、現行の 適な計画のコストです。現行の 適コストが大きい場合、プラン・ジェネレータはコストがより低く、より適切な計画（つまり、さらに別の計画）を探索します。現行の 適コストが低い場合は、これ以上のコストの改善を追及しても大きな効果は得られないため、プラン・ジェネレータは検索を速やかに終了します。

適な状態に も近いコストで計画を生成する初期結合順序で、プラン・ジェネレータが始動する場合は、カットオフが有効に機能します。適切な初期結合順序の検索は困難です。

実行計画の読み方と理解実行計画の読み方と理解実行計画の読み方と理解実行計画の読み方と理解SQL 文を実行するために、Oracle は、多数のステップを実行する必要があります。実行される各ステップでは、データベースからのデータ行の物理的な取出し、またはユーザーが発行する文に返すデータ行の準備のどちらかが実行されます。文を実行するために Oracle が使用するステップの組合せのことを実行計画実行計画実行計画実行計画と呼びます。実行計画には、文がアクセスする各表へのアクアクアクアクセス・パスセス・パスセス・パスセス・パスと、適切な結合方法結合方法結合方法結合方法に基づく表の順序（結合順序結合順序結合順序結合順序）が含まれています。

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-14 ページ「問合せオプティマイザのアクセス・パスについて」

� 第 19 章「EXPLAIN PLAN の使用方法」

問合せオプティマイザ 13-11

問合せオプティマイザについて

� EXPLAIN PLAN 文を発行した後、Oracle から提供されるスクリプトまたはパッケージのいずれかを使用して 新の計画表出力を表示します。19-6 ページの「PLAN_TABLE 出力の表示」を参照してください。

� EXPLAIN PLAN の出力実行順序は、 も右端にインデントされている行から始まります。次のステップは、その行の親です。2 つの行が等しくインデントされている場合、通常、上位の行が 初に実行されます。

例 13-1 では EXPLAIN PLAN を使用して、ID が 103 より小さい従業員の、employee_id、job_title、salaryおよび department_nameを選択する SQL 文について説明しています。

例例例例 13-1 EXPLAIN PLAN の使用方法の使用方法の使用方法の使用方法

EXPLAIN PLAN FORSELECT 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")

注意注意注意注意 :

� この章では、EXPLAIN PLAN出力表は utlxpls.sqlスクリプトで表示されました。

� この章の EXPLAIN PLAN出力のステップは、システムによって異なる場合があります。データベース構成によって、オプティマイザは異なる実行計画を選択する場合があります。

13-12 Oracle Database パフォーマンス・チューニング・ガイド

問合せオプティマイザについて

実行計画のステップ実行計画のステップ実行計画のステップ実行計画のステップ出力表内の各行は、実行計画内の 1 つのステップに対応しています。アスタリスクの付いたステップ ID は、Predicate Information セクションにリストされています。

実行計画の各ステップで、行のセットが戻されます。この行のセットは、次のステップで使用されます。 後のステップでは、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に戻すネステッド・ループ操作を実行します。

関連項目関連項目関連項目関連項目 : 第 19 章「EXPLAIN PLAN の使用方法」

関連項目関連項目関連項目関連項目 :

� アクセス・パスの詳細は、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 の基準に従って自動的にキャッシュされます。

小規模表の自動キャッシュは、CACHE属性で作成または変更された表に対しては使用禁止です。

パラレル問合せの実行パラレル問合せの実行パラレル問合せの実行パラレル問合せの実行全表スキャンが必要である場合は、表のスキャンに複数のパラレル実行サーバーを使用して、応答時間を向上できます。パラレル問合せは、リソース使用の可能性があるために、一般的には同時実行性の低いデータ・ウェアハウス環境で使用されます。

表表表表 13-4 表のキャッシュ基準表のキャッシュ基準表のキャッシュ基準表のキャッシュ基準

表サイズ表サイズ表サイズ表サイズ サイズ基準サイズ基準サイズ基準サイズ基準 キャッシュキャッシュキャッシュキャッシュ

小規模 ブロックの数が 20 より少な

い、またはキャッシュされているブロックの合計の 2% の

うち、大きいもの

STATISTICS_LEVELが TYPICALまたはそれ以

上に設定されている場合、Oracle では、表ス

キャン履歴に応じて、表をキャッシュするかどうかが判別されます。今後の表スキャンでキャッシュされるブロックが見つかる可能性がある場合にのみ、表がキャッシュされます。STATISTICS_LEVELが BASICに設定されてい

る場合、表はキャッシュされません。

中規模 小規模表よりも大きいが、キャッシュされているブロックの合計が 10% より少ない

Oracle では、表スキャンおよびワークロードの

履歴に基づいて表をキャッシュするかどうか判別します。今後の表スキャンでキャッシュされるブロックが見つかる可能性がある場合にのみ、表がキャッシュされます。

大規模 キャッシュされているブロックの合計が 10% より大きい

キャッシュされません

関連項目関連項目関連項目関連項目 : 『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 による表アクセスは行われない場合があります。

索引スキャン索引スキャン索引スキャン索引スキャンこの方法では、文で指定された索引付きの列の値を使用して索引が検索され、行が取得されます。索引スキャンでは、索引の 1 つ以上の列値に基づいて索引からデータが取得されます。索引スキャンを実行するために、Oracle は文によってアクセスされた列に対応する索引を検索します。文が索引付けされた列にしかアクセスしない場合、Oracle は索引付けされた列値を表からではなく、索引から直接読み込みます。

索引には、索引の値の他に、その値を持っている行の ROWID も含まれています。したがって、索引付けされた列の他に別の列にも文がアクセスする場合、Oracle は、ROWID またはクラスタ・スキャンによる表アクセスのどちらかを使用して、表内の行を検索できます。

索引スキャンには次のタイプがあります。

� ブロックの I/O（行ではなく）の想定

� 索引一意スキャン

� 索引レンジ・スキャン

� 索引レンジ・スキャン降順

� 索引スキップ・スキャン

� 全体スキャン

� 高速全索引スキャン

� 索引結合

� ビットマップ索引

注意注意注意注意 : ROWID は、データが格納されている場所を表す Oracle の内部表現です。ROWID はバージョン間で変更される場合があります。位置に基づいたデータのアクセスは、お薦めしません。行の移行や連鎖によって、行が移動するためです。また、エクスポートやインポートの後も同様です。外部キーは主キーに基づいている必要があります。 ROWID の詳細は、

『Oracle Database アドバンスト・アプリケーション開発者ガイド』を参照してください。

13-16 Oracle Database パフォーマンス・チューニング・ガイド

問合せオプティマイザのアクセス・パスについて

ブロックのブロックのブロックのブロックの I/O（行ではなく）の想定（行ではなく）の想定（行ではなく）の想定（行ではなく）の想定Oracle は、ブロック単位で I/O を実行します。したがって、全表スキャンを使用するかどうかのオプティマイザの決定は、行でなくアクセスされるブロックのパーセンテージに影響されます。これを索引クラスタ化係数といいます。ブロックに単一行が含まれている場合、アクセスされる行とアクセスされるブロックは同じです。

ただし、大半の表には各ブロック内に複数の行があります。したがって、目的の行が、少ないブロック内にまとまってクラスタ化されていたり、大量のブロックにわたって拡散されていることがあります。

クラスタ化係数は索引のプロパティですが、実際には、表のデータ・ブロック内の類似した索引付き列の値の拡散度合いに関連します。低いクラスタ化係数は、個々の行が表の少数のブロック内に集中されることを示します。逆に、高いクラスタ化係数は、個々の行が表の複数のブロックによりランダムに分散されることを示します。したがって、高いクラスタ化係数の場合はレンジ・スキャンを使用して ROWID で行をフェッチするので、よりコストがかかります。データを戻すために表の中のさらに多くのブロックにアクセスする必要があるためです。例13-3 では、クラスタ化係数がコストにどのような影響を与えるかが示されています。

例例例例 13-3 クラスタ化係数がコストに与える影響クラスタ化係数がコストに与える影響クラスタ化係数がコストに与える影響クラスタ化係数がコストに与える影響

次の状況を想定します。

� 9 つの行を持つ表があります。

� 表の col1に一意でない索引があります。

� c1列は現在、値 A、Bおよび Cを格納しています。

� 表には、Oracle ブロックが 3 つしかありません。

ケース 1: 次の図のように配置されている場合、行に対して索引クラスタ化係数は低くなります。

Block 1 Block 2 Block 3 ------- ------- -------- A A A B B B C C C

これは、c1に対して同じ索引付きの列の値を持つ行が、表の中の同じ物理ブロック内にあるためです。レンジ・スキャンを使用して、値 Aを持つすべての行を戻す際のコストが低いのは、表の中のブロックを 1 つのみ読み取れば済むためです。

ケース 2: 同じ行が、索引値が表ブロック間に分散する（並べるのではなく）ように再配置されると、索引クラスタ化係数が高くなります。

Block 1 Block 2 Block 3 ------- ------- -------- A B C A B C 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が含まれているときは使用できません。

� 古い統計

たとえば、表が作成された後に解析されなかった場合およびブロックがDB_FILE_MULTIBLOCK_READ_COUNT 高水位標より少ない場合は、オプティマイザはその表は小さいと判断し、全表スキャンが使用されます。ALL_TABLES表内のLAST_ANALYZED列および BLOCKS列を見て、統計を調べてください。

結合について結合について結合について結合について結合は、複数の表からデータを取り出す文です。結合は FROM句の中の複数の表で特性化され、各表の関係は WHERE句の中に結合条件を設定することで定義されます。結合では、片方の行セットが内部と呼ばれ、もう一方が外部と呼ばれます。

この項では、次の内容を説明します。

� 問合せオプティマイザによる結合文の実行方法

� 問合せオプティマイザによる結合の実行計画の選択方法

� ネステッド・ループ結合

� ハッシュ結合

� ソート / マージ結合

� デカルト結合

� 外部結合

問合せオプティマイザによる結合文の実行方法問合せオプティマイザによる結合文の実行方法問合せオプティマイザによる結合文の実行方法問合せオプティマイザによる結合文の実行方法結合文に実行計画を選択するために、オプティマイザは、相互に関連する次の決定を行う必要があります。

� アクセス・パス

単純な文では、オプティマイザは、結合文の各表からデータを取り出すアクセス・パスを選択する必要があります。

� 結合方法

行ソースの各ペアを結合するには、結合操作を Oracle が実行する必要があります。結合方法には、ネステッド・ループ結合、ソート / マージ結合、デカルト結合およびハッシュ結合があります。

� 結合順序

3 つ以上の表を結合する文を実行する場合、Oracle は 2 つの表を結合し、その結果作成された行ソースを次の表に結合します。このプロセスは、すべての表がその結果に結合されるまで続行されます。

関連項目関連項目関連項目関連項目 : SQL 文のヒントの詳細は、第 16 章「オプティマイザ・ヒントの使用方法」を参照してください。

関連項目関連項目関連項目関連項目 : 13-14 ページ「問合せオプティマイザのアクセス・パスについて」

13-22 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 つの独立した行ソースを結合するハッシュ結合の方がパフォーマンスが優れています。

ネステッド・ループ結合には、次のステップがあります。

1. オプティマイザで駆動表が決定され、これが外部表に指定されます。

2. その他の表は、内部表に指定します。

3. 外部表にあるすべての行について、内部表にあるすべての行がアクセスされます。外部ループは外部表にあるすべての行に対するものであり、内部ループは内部表の中にあるすべての行に対するものです。次のように、外部ループは実行計画の内部ループの前に表示されます。

NESTED LOOPS outer_loop inner_loop

ネステッド・ループ結合ネステッド・ループ結合ネステッド・ループ結合ネステッド・ループ結合この項では、13-12 ページの例 13-1 の問合せにおけるネステッド・ループの 1 つの外部ループおよび内部ループを説明します。

...| 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 | | |...

この例では、外部ループが 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 | TABLE ACCESS BY INDEX ROWID| JOBS5 | INDEX UNIQUE SCAN | JOB_ID_PK

SELECT j.job_title FROM jobs j WHERE e.job_id = j.job_id

関連項目関連項目関連項目関連項目 : 13-27 ページ「デカルト結合」

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 (OUTER LOOP 3.1) NESTED LOOP 1 (OUTER LOOP 2.1) OUTER LOOP 1.1 - #1 INNER LOOP 1.2 - #2 INNER LOOP 2.2 - #3 INNER LOOP 3.2 - #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. マージ結合処理 : ソートされたリストがマージされる。

入力がすでに結合列でソートされている場合、その行ソースに対してソート結合操作は行われません。

オプティマイザがソートオプティマイザがソートオプティマイザがソートオプティマイザがソート / マージ結合を使用する場合マージ結合を使用する場合マージ結合を使用する場合マージ結合を使用する場合オプティマイザは、次の条件が真である場合に、ハッシュ結合よりソート / マージ結合を選択して大量のデータを結合します。

� 2 つの表の間の結合条件が、等価結合ではない。

� ソートが他の操作ですでに要求されているため、オプティマイザは、ハッシュ結合よりソート / マージを使用する方がコストが低いと判断した。

13-26 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 cust_last_name, sum(nvl2(o.customer_id,0,1)) "Count" FROM customers c, orders o WHERE c.credit_limit > 1000 AND c.customer_id = o.customer_id(+) GROUP 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 c.cust_last_name, sum(revenue) FROM customers c, v_orders o WHERE c.credit_limit > 2000 AND o.customer_id(+) = c.customer_id GROUP 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 ASSELECT 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 d.department_id, e.employee_id FROM employees e FULL OUTER JOIN departments d ON e.department_id = d.department_id ORDER 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 パフォーマンスと使用率

オプティマイザ統計はデータ・ディクショナリに格納されます。また、データ・ディクショナリ・ビューを使用して表示できます。14-16 ページの「統計の参照」を参照してください。

データベース内のオブジェクトは常に変化するため、これらのデータベース・オブジェクトが正確に記述されるように統計を定期的に更新する必要があります。統計は Oracle により自動的にメンテナンスされます。また、DBMS_STATSパッケージを使用するとオプティマイザ統計を手動でメンテナンスできます。自動プロセスと手動プロセスについては、14-3 ページの「自動統計収集」または 14-5 ページの「手動統計収集」を参照してください。

DBMS_STATSパッケージにも、統計を管理するためのプロシージャが用意されています。統計のコピーを保存してリストアできます。あるシステムから統計をエクスポートし、別のシステムにインポートできます。たとえば、本番システムからテスト・システムに統計をエクスポートできます。また、統計が変更されないようにロックすることも可能です。ロック方法については、14-13 ページの「表統計またはスキーマ統計のロック」を参照してください。

注意注意注意注意 : この項で説明する統計は、問合せを 適化する目的で作成されてデータ・ディクショナリに格納されるオプティマイザ統計です。この種の統計を V$ビューで参照可能なパフォーマンス統計と混同しないでください。

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を終了します。残りのオブジェクトは、その後、次のメンテナンス・ウィンドウで処理されます。

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です。

関連項目関連項目関連項目関連項目 : スケジューラおよびメンテナンス・ウィンドウ・タスクの詳細は、『Oracle Database 管理者ガイド』を参照してください。

オプティマイザ統計の管理 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 パッケージは、統計の変更、表示、エクスポート、インポートおよび削除にも使用されます。

DBMS_STATSパッケージでは、表と索引の統計、および表の列とパーティションの個別の統計を収集できます。クラスタ統計は収集できません。ただし、DBMS_STATSを使用して、全クラスタのかわりに個別の表の統計を収集できます。

表、列または索引の統計を生成するとき、分析したオブジェクトの統計がすでにデータ・ディクショナリ内に収録されている場合、Oracle は既存の統計を更新します。古い統計は保存され、後で必要に応じてリストアできます。14-11 ページの「前のバージョンの統計のリストア」を参照してください。

システム・スキーマの統計を収集する場合は、DBMS_STATS.GATHER_DICTIONARY_STATSプロシージャを使用できます。このプロシージャでは、SYSや SYSTEMを含むすべてのシステム・スキーマと、CTXSYSや DRSYSなどの他のオプション・スキーマの統計が収集されます。

データベース・オブジェクトの統計が更新されると、そのオブジェクトにアクセスする現在解析済の SQL 文が無効にされます。文が次に実行されるときに、文が再解析され、オプティマイザは新しい統計に基づいて新しい実行計画を自動的に選択します。リモート・データベース上で新しい統計を持つオブジェクトにアクセスする分散型の文は、無効にされません。新しい統計は、次回に SQL 文が解析されると有効になります。

表 14-1 は、DBMS_STATSパッケージにおけるデータベース・オブジェクトの統計収集のためのプロシージャです。

注意注意注意注意 : オプティマイザ統計の収集に、ANALYZE文で COMPUTE句およびESTIMATE句を使用しないでください。これらの句は下位互換性のためにのみサポートされており、将来のリリースでは削除される可能性があります。DBMS_STATSパッケージを使用する方が、より広範囲で正確な統計セットが効率的に収集されます。

オプティマイザ統計の収集に関係しない次のような用途には、引き続きANALYZE文を使用できます。

� VALIDATEまたは LIST CHAINED ROWS句を使用する場合

� 空きリスト・ブロックの情報を収集する場合

オプティマイザ統計の管理 14-5

手動統計収集

前述のプロシージャを統計収集に使用する場合は、次のようにいくつか重要な考慮事項があります。

� サンプリングを使用した統計収集

� パラレル統計収集

� パーティション・オブジェクトの統計

� 列統計情報とヒストグラム

� 失効している統計の判別

� ユーザー定義統計

サンプリングを使用した統計収集サンプリングを使用した統計収集サンプリングを使用した統計収集サンプリングを使用した統計収集統計収集操作では、サンプリングを使用して統計を予測できます。サンプリングは、統計収集の重要なテクニックです。サンプリングを使用せずに統計を収集するには、全表スキャンと表全体のソートが必要です。サンプリングを使用すると、統計収集に必要なリソースが 小限に抑えられます。

サンプリングは、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-1 DBMS_STATS パッケージの統計収集プロシージャパッケージの統計収集プロシージャパッケージの統計収集プロシージャパッケージの統計収集プロシージャ

プロシージャプロシージャプロシージャプロシージャ 収集対象収集対象収集対象収集対象

GATHER_INDEX_STATS 索引統計

GATHER_TABLE_STATS 表、列および索引の統計

GATHER_SCHEMA_STATS スキーマ内のすべてのオブジェクトの統計

GATHER_DICTIONARY_STATS すべてのディクショナリ・オブジェクトの統計

GATHER_DATABASE_STATS データベース内のすべてのオブジェクトの統計

関連項目関連項目関連項目関連項目 : すべての DBMS_STATSプロシージャの構文と例については、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

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 により自動的に判別されます。また、これらの情報は手動でも指定できます。

失効している統計の判別失効している統計の判別失効している統計の判別失効している統計の判別データベースは時間の経過につれて変更されるため、その統計を定期的に収集する必要があります。特定のデータベース・オブジェクトに新規データベース統計が必要かどうかを判別するために、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に設定して統計収集プロシージャをコールします。

注意注意注意注意 : DBMS_STATSを使用中に表からすべての行を削除する必要がある場合、同じ表を削除して再度作成するかわりに、TRUNCATEを使用します。 表が削除されると、自動ヒストグラム収集機能が使用したワークロード情報と、RESTORE_*_STATSプロシージャが使用した保存された統計履歴が消失します。このデータなしでは、これらの機能は適切に動作しません。

関連項目関連項目関連項目関連項目 : ユーザー定義統計の実装の詳細は、『Oracle Database データ・カートリッジ開発者ガイド』を参照してください。

オプティマイザ統計の管理 14-7

システム統計

統計を収集する時期統計を収集する時期統計を収集する時期統計を収集する時期統計を手動で収集する場合は、その収集方法を決定するのみでなく、新規統計の収集時期と頻度も決定する必要があります。

表の増分変更が行われるアプリケーションの場合は、新規の統計を週または月に 1 回収集するのみで良い場合があります。このような環境で も簡単な統計収集方法は、スクリプトまたはジョブ・スケジューリング・ツールを使用して、GATHER_SCHEMA_STATSおよびGATHER_DATABASE_STATSプロシージャを定期的に実行することです。収集の頻度によって、統計収集プロセスで起こるオーバーヘッドの処理に対し、オプティマイザの正確な統計を出すタスクのバランスをとります。

バルク・ロードを使用する場合など、バッチ操作で逐次変更される表の場合は、その表の統計をバッチ操作の一部として収集する必要があります。ロード操作の完了直後に DBMS_STATSプロシージャをコールしてください。

パーティション表の場合、通常は 1 つのパーティションのみが変更されます。このような場合は、表全体の統計を収集するのではなく、変更があったパーティションの統計のみを収集できます。ただし、パーティション表のグローバル統計の収集も必要な場合があります。

システム統計システム統計システム統計システム統計システム統計は、問合せオプティマイザに対してシステムのハードウェア特性（I/O と CPU のパフォーマンスおよび使用率など）を記述します。実行計画の選択時に、オプティマイザで各問合せに必要な I/O および CPU リソースが見積もられます。システム統計を使用すると、問合せオプティマイザは I/O および CPU コストをより正確に見積もることができ、問合せオプティマイザはより適切な実行計画を選択できます。

システム統計を収集するとき、指定された期間のシステム・アクティビティ（作業負荷統計）が分析されるか、作業負荷（非作業負荷統計）がシミュレートされます。統計は、DBMS_STATS.GATHER_SYSTEM_STATSプロシージャを使用して収集されます。システム統計を収集することをお薦めします。

表 14-2 に、DBMS_STATSパッケージにより収集されたオプティマイザのシステム統計と、特定のシステム統計の収集または手動設定のオプションを示します。

関連項目関連項目関連項目関連項目 : DBMS_STATSパッケージの GATHER_SCHEMA_STATSおよびGATHER_DATABASE_STATSプロシージャの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

注意注意注意注意 : ディクショナリ・システム統計を更新するには、DBA 権限またはGATHER_SYSTEM_STATISTICSロールが必要です。

表表表表 14-2 DBMS_STAT パッケージ内のオプティマイザのシステム統計パッケージ内のオプティマイザのシステム統計パッケージ内のオプティマイザのシステム統計パッケージ内のオプティマイザのシステム統計

パラメータ名パラメータ名パラメータ名パラメータ名 説明説明説明説明 初期化初期化初期化初期化 統計の収集または設定のオプション統計の収集または設定のオプション統計の収集または設定のオプション統計の収集または設定のオプション 単位単位単位単位

cpuspeedNW 作業負荷のない場合の CPU 速度を

表します。CPU 速度は、1 秒当たり

の CPU 平均サイクル数です。

システム起動時 gathering_mode = NOWORKLOADに

設定するか、または統計を手動で設定します。

100 万 / 秒

ioseektim I/O シーク時間は、シーク時間、待

機時間およびオペレーティング・システム・オーバーヘッド時間を合計したものです。

システム起動時

10（デフォルト）

gathering_mode = NOWORKLOADに

設定するか、または統計を手動で設定します。

ミリ秒

iotfrspeed I/O 転送速度は、1 回の読込み要求

で Oracle データベースがデータを

読み取ることができる速度です。

システム起動時

4096（デフォルト）

gathering_mode = NOWORKLOADに

設定するか、または統計を手動で設定します。

バイト /ミリ秒

14-8 Oracle Database パフォーマンス・チューニング・ガイド

システム統計

表、索引、列の統計とは異なり、システム統計の更新時には、すでに解析されている SQL 文は無効にされません。新しい SQL 文はすべて、新しい統計を使用して解析されます。

システム統計の収集方法には 2 つのオプションがあります。

� 作業負荷統計

� 非作業負荷統計

これらのオプションは、物理データベースおよび作業負荷の収集プロセスを容易に使用できるようにします。作業負荷システム統計が収集されると、非作業負荷システム統計は無視されます。非作業負荷システム統計は、データベースの初回の起動時にデフォルト値に初期化されます。

作業負荷統計作業負荷統計作業負荷統計作業負荷統計Oracle 9i で導入された作業負荷統計は、シングルおよびマルチブロックの読取り時間、mbrc、CPU 速度（cpuspeed）、 大システム・スループットおよび平均スレーブ・スループットを収集します。sreadtim、mreadtimおよび mbrcは、作業負荷の開始から終了までの 2 点間の、物理的な順次およびランダム読取りの数を比較して計算されます。これらの値は、バッファ・キャッシュが同期読取り要求を完了したときに変更されるカウンタを通して実装されます。このカウンタはバッファ・キャッシュ内にあるため、これらには I/O 遅延のみならず、ラッチの競合およびタスク・スイッチングに関連する待機も含まれています。このように、作業負荷統計は、作業負荷ウィンドウでシステムが実行するアクティビティに応じて異なります。ラッチ競合および I/O スループットの両方でシステムが I/O バウンドの場合、この状態は統計に反映され、この統計が使用された後で I/O 低減化集中計画が促進されます。さらに、作業負荷統計収集は、追加のオーバーヘッドを生成しません。

リリース 9.2 では、全表スキャン（FTS）の下限を設定するための 大 I/O スループットおよび平均スレーブ・スループットが追加されました。

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に設定するか、また

は統計を手動で設定します。

ブロック

関連項目関連項目関連項目関連項目 : システム統計を実装するための DBMS_STATSパッケージのプロシージャの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

表表表表 14-2 DBMS_STAT パッケージ内のオプティマイザのシステム統計（続き）パッケージ内のオプティマイザのシステム統計（続き）パッケージ内のオプティマイザのシステム統計（続き）パッケージ内のオプティマイザのシステム統計（続き）

パラメータ名パラメータ名パラメータ名パラメータ名 説明説明説明説明 初期化初期化初期化初期化 統計の収集または設定のオプション統計の収集または設定のオプション統計の収集または設定のオプション統計の収集または設定のオプション 単位単位単位単位

オプティマイザ統計の管理 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 = 10msiotrfspeed = 4096 bytes/mscpuspeednw = 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.CREATE_STAT_TABLEプロシージャを使用します。この表の作成後に、DBMS_STATS.EXPORT_*_STATSプロシージャを使用して、データ・ディクショナリから統計表に統計をエクスポートできます。その後、DBMS_STATS.IMPORT_*_STATSプロシージャを使用して統計をインポートします。

オプティマイザでは、ユーザー所有の表に格納されている統計が使用されないことに注意してください。オプティマイザで使用されるのは、データ・ディクショナリに格納されている統計のみです。ユーザー所有の表内の統計をオプティマイザで使用するには、統計インポート・プロシージャを使用して、その統計をデータ・ディクショナリにインポートする必要があります。

統計をデータベース間で移動するには、 初のデータベース上の統計をエクスポートしてから、EXP および IMP ユーティリティまたは他のメカニズムを使用して統計表を第 2 のデータベースにコピーし、 後に統計を第 2 のデータベースにインポートする必要があります。

注意注意注意注意 : DBMS_STATSを使用中に表からすべての行を削除する必要がある場合、同じ表を削除して再度作成するかわりに、TRUNCATEを使用します。 表が削除されると、自動ヒストグラム収集機能が使用するワークロード情報と、RESTORE_*_STATSプロシージャが使用する保存された統計履歴が消失します。このデータなしでは、これらの機能は適切に動作しません。

注意注意注意注意 : 統計のエクスポートとインポートは、データベースの EXP およびIMP ユーティリティとは異なる概念です。DBMS_STATSエクスポートおよびインポート・パッケージでは、IMP および EXP ダンプ・ファイルが使用されます。

注意注意注意注意 : 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初期化パラメータの値によって、動的サンプリングの問合せで読み取られるブロック数が決定します。

動的サンプリング使用のタイミング動的サンプリング使用のタイミング動的サンプリング使用のタイミング動的サンプリング使用のタイミング通常、迅速に（数秒以内で）完了する問合せに対しては、動的サンプリングのコストが発生するのは望ましくありません。しかし、次のいずれかの条件が当てはまる場合は、動的サンプリングが有効です。

� 動的サンプリングを使用すると、より優れた計画になる場合。

� サンプリングにかかる時間が、問合せの実行時間全体のごく一部である場合。

� 問合せが何度も実行される場合。

動的サンプリングは、単一表の述語によるサブセットに適用したり、動的サンプリングが行われていない述語の通常の選択性の見積りと組み合せることができます。

動的サンプリングを使用したパフォーマンスの改善方法動的サンプリングを使用したパフォーマンスの改善方法動的サンプリングを使用したパフォーマンスの改善方法動的サンプリングを使用したパフォーマンスの改善方法動的サンプリングは、OPTIMIZER_DYNAMIC_SAMPLINGパラメータを使用して制御します。このパラメータの値は、0～ 10に設定できます。デフォルトは 2です。

� 値が 0の場合、動的サンプリングが行われません。

� パラメータの値が大きくなるにつれて、サンプリングされる表（分析された表、あるいは分析されていない表）のタイプについても、サンプリングで使用される I/O の量に関しても、動的サンプリングがより積極的に適用されるようになります。

動的サンプリングは、サンプリング対象の表内で行が挿入、削除または更新されていない場合、同じものが繰り返し使用されます。OPTIMIZER_FEATURES_ENABLEパラメータが 9.2.0 より前のリリースに設定されている場合、動的サンプリングはオフになります。

動的サンプリング・レベル動的サンプリング・レベル動的サンプリング・レベル動的サンプリング・レベルサンプリング・レベルは、使用された動的サンプリング・レベルがカーソル・ヒントまたはOPTIMIZER_DYNAMIC_SAMPLING初期化パラメータからの場合、次のようになります。

� レベル 0: 動的サンプリングは使用しないでください。

� レベル 1: 次の条件を満たす場合、すべての分析されていない表をサンプリングします。（1）分析されていない表が問合せに少なくとも 1 つある場合。（2）この分析されていない表が、別の表と結合、または副問合せかマージ不可能ビューにある場合。（3）この分析されていない表に索引がない場合。（4）この分析されていない表に、この表の動的サンプリングに使用されるブロックの数よりも多いブロックがある場合。サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数です（32）。

� レベル 2: 動的サンプリングをすべての分析されていない表に適用します。サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数の 2 倍です。

� レベル 3: レベル 2 の基準を満たすすべての表と、標準の選択性の見積りで動的サンプリングの可能性がある述語の推論が使用されるすべての表に、動的サンプリングを適用します。サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数です。分析されていない表の場合、サンプリングされたブロック数は、動的サンプリングのブロックのデフォルト数の 2 倍です。

関連項目関連項目関連項目関連項目 : この初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

14-14 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: 表内のすべてのブロックを読み込みます。

統計の欠落の処理統計の欠落の処理統計の欠落の処理統計の欠落の処理Oracle では、統計が欠落している表が検出されると、オプティマイザに必要な統計が動的に収集されます。ただし、ある種の表の場合、動的サンプリングは実行されません。これには、リモート表と外部表が含まれます。これらの場合および動的サンプリングが無効になっている場合、オプティマイザは統計にデフォルト値を使用します。表 14-3 および表 14-4 を参照してください。

関連項目関連項目関連項目関連項目 : DYNAMIC_SAMPLINGヒントを使用してサンプリング・レベルを設定する方法については、『Oracle Database SQL 言語リファレンス』を参照してください。

表表表表 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 では、列統計情報に高さ調整済ヒストグラムと頻度ヒストグラムという 2 つのタイプが使用されます。ヒストグラムのタイプは、*TAB_COL_STATISTICSビュー（USERおよびDBA）の HISTOGRAM列に格納されます。この列の値は、HEIGHT BALANCED、FREQUENCYまたは NONEです。

高さ調整済ヒストグラム高さ調整済ヒストグラム高さ調整済ヒストグラム高さ調整済ヒストグラム高さ調整済ヒストグラムでは、列値が帯域に分割され、各帯域にほぼ同数の行が存在するようになっています。したがって、ヒストグラムによって提示される有用な情報が存在するのは、値範囲の終点が位置するところです。

値が 1 ～ 100 の間に存在し、ヒストグラムが 10 バケットである列 C について検討します。C のデータ配分が均一な場合のヒストグラムは、図 14-1 のようになります。数字は終点の値です。

関連項目関連項目関連項目関連項目 : これらのビューの統計の詳細は、『Oracle Database リファレンス』を参照してください。

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機能を典型的な負荷を一定期間かけた後に使用することで検出できます。この監視機能は、索引が使用されたかどうかを記録します。使用されていない索引が検出された場合は、削除してください。サンプリングした負荷以外の負荷で使用されている索引を削除しないように、典型的な負荷を監視していることを確認してください。

また、アプリケーション内では、文の実行計画の調査ですぐには明らかにならない索引の使用方法もあります。その例が、共有ロックが子表上に取り出されないようにする親表上の外部キー索引です。

また、新しい索引を作成して SQL 文をチューニングするかどうかを決める場合、オプティマイザがアプリケーションの実行時にこれらの索引を使用するかどうかを判断するために、EXPLAIN PLAN文を使用することもできます。新しい索引を作成して現在解析中の文をチューニングする場合は、Oracle はその文を無効にします。

その文が次に解析されるとき、オプティマイザは、新しい索引を使用する可能性のある新しい実行計画を自動的に選択します。新しい索引をリモート・データベース上に作成して分散型の文をチューニングする場合は、その文が次に解析されるとき、オプティマイザがこれらの索引について検討します。

索引を作成してある文をチューニングした場合、他の文の実行計画に対するオプティマイザの選択に影響を及ぼす場合があるので注意してください。たとえば、ある文によって使用される索引を作成した場合、オプティマイザは、アプリケーションの他の文に対しても、その索引の使用を選択する場合があります。このため、 初にチューニング対象と判断した文をチューニングした後、アプリケーションのパフォーマンスおよび実行計画を再検査し、SQL トレース機能を利用します。

関連項目関連項目関連項目関連項目 :

� ALTER INDEX MONITORING USAGE文の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

� 外部キーの詳細は、『Oracle Database アドバンスト・アプリケーション開発者ガイド』を参照してください。

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 ページの「パフォーマンスを考慮したハッシュ・クラスタの使用方法」を参照してください。

� 高度な選択性の索引キーを選択します。索引の選択性は、索引を付けるキーについて同じ値を持つ行の表内での割合です。同じ値を持つ行がほとんどない場合、索引の選択性は適です。

選択性の低い列への索引付けは、データ配分が偏っているために、1 つまたは 2 つの値がその他の値よりはるかに使用頻度が低い場合に便利です。

� 個別値をほとんど持たないキーまたは式には標準の B ツリー索引は使用しません。通常そのようなキーや式は選択性が劣っているので、頻繁に選択されるキー値がその他のキー値に比べて少ない場合を除くと、パフォーマンスは 適化されません。このような場合には、ビットマップ索引を使用すると効果的です。ただし、同時実行性の高い OLTP アプリケーションのように、索引が頻繁に変更される場合には向きません。

� 頻繁に修正される列には索引を付けません。索引付きの列を修正する UPDATE文および索引付きの表を修正する INSERT文と DELETE文では、索引がない場合よりも、処理に長い時間が必要となります。このような SQL 文は、表のデータのみでなく、索引のデータも修正する必要があります。また、取消しと再実行も追加的に生成されます。

� 関数や演算子を含む WHERE句のみに指定されるキーには索引を付けません。索引付きのキーに MINや MAX以外の関数や演算子を使用する WHERE句は、ファンクション索引を除く索引を使用するアクセス・パスを選択しません。

� 同時実行の数多くの INSERT文および UPDATE文、DELETE文が親表と子表をアクセスする場合、参照整合性制約の外部キーに索引を付けることを検討します。このような索引を使用すると、子表を共有ロックせずに親表で UPDATEおよび DELETEを実行できます。

� 索引を付けるキーを選択するとき、問合せのパフォーマンス向上が、INSERT、UPDATE、DELETEのパフォーマンス損失および索引を格納するために必要となる領域の使用に見合う価値があるかどうか検討してください。SQL 文の処理時間を索引の有無によって実際に比較することをお薦めします。SQL トレース機能で処理時間を測定できます。

注意注意注意注意 : Oracle では、整合性制約を使用して定義されるすべての一意キーおよび主キーのキーと式に、暗黙に索引を作成するか、既存の索引を使用します。

関連項目関連項目関連項目関連項目 : ロックへの外部キーの影響の詳細は、『Oracle Database アドバンスト・アプリケーション開発者ガイド』を参照してください。

索引およびクラスタの使用方法 15-3

索引パフォーマンスについて

コンポジット索引の選択コンポジット索引の選択コンポジット索引の選択コンポジット索引の選択コンポジット索引には複数のキー列が含まれています。コンポジット索引には、次のような単一列索引を上回る利点があります。

� 選択性の向上

場合によっては、それぞれの選択性が劣る複数の列や式を組み合せてコンポジット索引にすると、より高い選択性を得ることができます。

� I/O の削減

問合せによって選択される列がすべてコンポジット索引に含まれている場合、Oracle は、表にアクセスすることなく、索引からこれらの値を戻すことができます。

SQL 文にコンポジット索引の先頭部分を利用する条件が含まれていれば、その文はコンポジット索引に関係するアクセス・パスを使用します。

索引の先頭部分とは、その索引を作成した CREATE INDEX文で列リストの先頭から連続的に指定された 1 つ以上の列の組合せのことです。次の CREATE INDEX文を例とします。

CREATE INDEX comp_ind ON table1(x, y, z);

� x、xy、xyzの各列の組合せは、索引の先頭部分です。

� yz、y、zの各列の組合せは、索引の先頭部分ではありません。

コンポジット索引のキーの選択コンポジット索引のキーの選択コンポジット索引のキーの選択コンポジット索引のキーの選択コンポジット索引を構成するキーを選択するために、次のガイドラインに従ってください。

� WHERE句の条件で、頻繁に AND演算子で結合して使用されるキー・セットに対して、コンポジット索引を作成することを検討します。特に結合したときの選択性が個々のキーの選択性よりも優れている場合、コンポジット索引を作成してください。

� 複数の問合せが 1 つ以上のキー値に基づいて同じキー・セットを選択する場合、これらのキーのすべてを含むコンポジット索引を作成することを検討します。

もちろん、索引を作成するときの、一般的なパフォーマンスの利点およびトレードオフに関する前述のガイドラインを検討してください。

コンポジット索引のキーの順序付けコンポジット索引のキーの順序付けコンポジット索引のキーの順序付けコンポジット索引のキーの順序付けコンポジット索引内でのキーの順序を指定するために次のガイドラインに従ってください。

� WHERE句で使用されるキーが先頭部分を構成するように、索引を作成してください。

� 一部のキーが WHERE句で使用される頻度が高い場合には、頻繁に選択されるキーが先頭部分を構成するように索引を作成し、これらのキーのみを使用する文が索引を使用できるようにしてください。

� すべてのキーが WHERE句で使用される頻度が同程度で、そのキーの 1 つでデータが物理的に順序付けられている場合には、そのキーをコンポジット索引の先頭にしてください。

注意注意注意注意 : このことは、索引スキップ・スキャンには現在、該当しなくなっています。 13-19 ページの「索引スキップ・スキャン」を参照してください。

15-4 Oracle Database パフォーマンス・チューニング・ガイド

索引パフォーマンスについて

索引を使用する文の記述索引を使用する文の記述索引を使用する文の記述索引を使用する文の記述索引を作成しても、単に索引が存在するのみでは、オプティマイザはその索引を使用するアクセス・パスを選択できません。オプティマイザは、SQL 文にアクセス・パスを使用可能にする構造が含まれている場合にかぎり、そのようなアクセス・パスを選択できます。索引アクセス・パスを使用するというオプションを問合せオプティマイザで可能にするには、文が索引アクセス・パスを使用可能にする構文になっていることを確認してください。

索引を使用しない文の記述索引を使用しない文の記述索引を使用しない文の記述索引を使用しない文の記述場合によっては、既存の索引を使用するアクセス・パスを SQL 文で使用しないことも可能です。索引の選択性があまり優れておらず、全表スキャンの方が効率的であることがわかっている場合がそうです。そのような索引アクセス・パスを使用可能にする条件が文に含まれている場合は、次に示す方法の 1 つを使用して、オプティマイザに全表スキャンを使用するように強制できます。

� NO_INDEXヒントを使用して特定索引の使用を禁止にし、問合せオプティマイザに 大限の柔軟性を持たせることができます。

� FULLヒントを使用し、オプティマイザに対して索引スキャンのかわりに全表スキャンを選択するように指示します。

� INDEXヒントまたは INDEX_COMBINEヒントを使用し、オプティマイザに、ある索引（またはリストされている索引セット）を別の索引（または索引セット）のかわりに使用するように指示します。

パラレル実行は、索引を効果的に利用します。このオプションはパラレル索引レンジ・スキャンは実行しませんが、ネステッド・ループ結合を実行するためにパラレル索引参照を実行します。索引の選択性が高い（各索引エントリの行数が少ない）場合は、パラレル表スキャンよりも順次索引参照を使用することをお薦めします。

索引の再作成索引の再作成索引の再作成索引の再作成索引を縮小し分断化された領域を 小化するため、または索引の記憶特性を変更するために索引を再作成する場合があります。既存の索引のサブセットとなる新しい索引を作成するとき、または既存の索引を新しい記憶特性で再構築するとき、Oracle は、実表ではなく既存の索引を使用して索引作成のパフォーマンスを向上させる場合があります。

ただし、既存の索引よりも実表を使用した方が効果的な場合もあります。多くの DML が実行された表の索引を考えてみてください。DML のために索引のサイズが大きくなり、各ブロックが 50% 以下しか満たされなくなる場合があります。索引が表のほとんどの列を参照している場合、索引が表よりも大きくなりかねません。その場合は、索引よりも実表を使用した方が、索引の再作成が速くできます。

ALTER INDEX ...REBUILD文は、既存の索引を再編成または縮小するため、または既存の索引の記憶特性を変更するために使用します。REBUILD文は、新しい索引の基礎として既存の索引を使用します。STORAGE（エクステントの割当て用）、TABLESPACE（索引を新しい表領域に移動する）および INITRANS（エントリの 初の数を変更する）などのすべての索引記憶用の文がサポートされています。

ALTER INDEX ...REBUILDは、高速全スキャン機能を使用するので、通常は索引を削除して再作成するよりも高速です。この文は、マルチブロック I/O を使用して索引ブロックをすべて読

関連項目関連項目関連項目関連項目 : NO_INDEX、FULL、INDEX、INDEX_COMBINEおよびAND_EQUALの各ヒントに関する詳細は、第 16 章「オプティマイザ・ヒントの使用方法」を参照してください。

注意注意注意注意 : 索引の作成または再作成の後で DBMS_STATSをコールしないように、CREATEまたは REBUILDに、COMPUTE STATISTICS文を含めてください。

索引およびクラスタの使用方法 15-5

索引パフォーマンスについて

み込んでから、ブランチ・ブロックを廃棄します。さらに、このアプローチには、再作成の実行中の問合せには、旧索引を利用できるという利点があります。

索引の縮小索引の縮小索引の縮小索引の縮小COALESCEオプションを持つ ALTER INDEX文を使用して索引のリーフ・ブロックを結合できます。このオプションでは、索引のリーフ・レベルを結合して空きブロックにし、再利用できます。また、索引をオンラインで再作成することもできます。

一意でない索引による一意性の規定一意でない索引による一意性の規定一意でない索引による一意性の規定一意でない索引による一意性の規定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. 旧データを表にロードします。

関連項目関連項目関連項目関連項目 : CREATE INDEX文と ALTER INDEX文の詳細および索引の再作成の制限の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : この文の構文の詳細は、『Oracle Database SQL 言語リファレンス』および『Oracle Database 管理者ガイド』を参照してください。

注意注意注意注意 : デフォルトでは、制約は ENABLED状態で作成されます。

15-6 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 になりました。

パフォーマンスを考慮したファンクション索引の使用方法パフォーマンスを考慮したファンクション索引の使用方法パフォーマンスを考慮したファンクション索引の使用方法パフォーマンスを考慮したファンクション索引の使用方法ファンクション索引には、関数（たとえば、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 アドバンスト・アプリケーション開発者ガイド』および『Oracle Database 管理者ガイド』を参照してください。

� CREATE INDEX文の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

索引およびクラスタの使用方法 15-7

パフォーマンスを考慮したパーティション索引の使用方法

パフォーマンスを考慮したパーティション索引の使用方法パフォーマンスを考慮したパーティション索引の使用方法パフォーマンスを考慮したパーティション索引の使用方法パフォーマンスを考慮したパーティション索引の使用方法パーティション表と同様に、パーティション索引を使用すると、管理可能性、可用性、パフォーマンスおよび拡張性が向上します。パーティション索引は、個別にパーティション化するか（グローバル索引）、または表のパーティション・メソッドに自動的にリンクできます

（ローカル索引）。

Oracle では、レンジ・パーティション化およびハッシュ・パーティション化されたグローバル索引をどちらもサポートしています。レンジ・パーティション化されたグローバル索引では、各索引パーティションに、パーティション・バウンドで定義された値が含まれます。ハッシュ・パーティション化されたグローバル索引では、各パーティションに、Oracle のハッシュ関数により決定された値が含まれます。

マルチユーザーの OLTP 環境で、索引内の少数のリーフ・ブロックに競合が多い場合、ハッシュ・メソッドにより索引のパフォーマンスが向上します。OLTP アプリケーションによっては、索引の右端にのみ索引が挿入される場合があります。これは、単調に増える列について索引が定義されている場合に行われます。このような場合、索引ページ、バッファ、更新のラッチ、および追加索引メンテナンス・アクティビティの競合により、索引の右端がホット・スポットとなり、パフォーマンスが低下します。

ハッシュ・パーティション化されたグローバル索引では、索引エントリはパーティション・キーおよびパーティション数に基づいて異なるパーティションにハッシュされます。これにより、定義済のパーティション数全体に競合が拡散され、スループットが向上します。ハッシュ・パーティション化されたグローバル索引を使用すると、バッファ・ラッチの競合が複数のパーティションにわたって拡散されるため、大規模 PDML として大きなファクト表に実行される TPC-H リフレッシュ関数には有効です。

ハッシュ・パーティション化では、索引エントリは Oracle で生成されたハッシュ値に基づいて特定の索引パーティションにマップされます。ハッシュ・パーティション化されたグローバル索引を作成するための構文は、ハッシュ・パーティション表と非常によく似ています。索引パーティション・キーについての等価述語および IN述語を伴う問合せでは、グローバル・ハッシュ・パーティション索引を効率的に使用して問合せにすばやく回答できます。

パフォーマンスを考慮した索引構成表の使用方法パフォーマンスを考慮した索引構成表の使用方法パフォーマンスを考慮した索引構成表の使用方法パフォーマンスを考慮した索引構成表の使用方法索引構成表は、表のデータが、対応付けられた索引に保持されるという点で普通の表とは異なります。新しい行の追加、行の更新、行の削除など、表データを変更すると、索引のみが更新されます。データ行は索引に格納されるため、索引構成表では完全一致、範囲検索またはその両方を含む問合せの表データに対するさらに高速なキー・ベースのアクセスが可能になります。

グローバル・ハッシュ・パーティション索引は索引構成表でサポートされており、マルチユーザーの OLTP 環境でパフォーマンスが向上します。

関連項目関連項目関連項目関連項目 : グローバル索引表の詳細は、『Oracle Database 概要』および『Oracle Database 管理者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : 索引構成表の詳細は、『Oracle Database 概要』および『Oracle Database 管理者ガイド』を参照してください。

15-8 Oracle Database パフォーマンス・チューニング・ガイド

パフォーマンスを考慮したドメイン索引の使用方法

パフォーマンスを考慮したビットマップ索引の使用方法パフォーマンスを考慮したビットマップ索引の使用方法パフォーマンスを考慮したビットマップ索引の使用方法パフォーマンスを考慮したビットマップ索引の使用方法ビットマップ索引は、次のすべての特性を持つ問合せのパフォーマンスを大幅に向上できます。

� カーディナリティが低いか中位である列に関する述語が WHERE句に複数含まれています。

� カーディナリティが低いか中位である列に関する個々の述語が大量の行を選択しています。

� カーディナリティが低いか中位である列の一部または全部に対して、問合せで使用されるビットマップ索引が作成されています。

� 問合せの表に多数の行が含まれています。

複数のビットマップ索引を使用して、単独の表に対する条件を評価できます。このため、ビットマップ索引は、長い WHERE句を含む複合非定型問合せにとって非常に有効です。ビットマップ索引は、集合問合せでもスター・スキーマでの結合の 適化でも 適なパフォーマンスを提供します。

パフォーマンスを考慮したビットマップ結合索引の使用方法パフォーマンスを考慮したビットマップ結合索引の使用方法パフォーマンスを考慮したビットマップ結合索引の使用方法パフォーマンスを考慮したビットマップ結合索引の使用方法単一表のビットマップ索引に加えて、ビットマップ結合索引を作成できます。このビットマップ結合索引は、複数の表を結合するためのビットマップ索引です。ビットマップ結合索引は、事前の制限事項の実行により結合される必要のあるデータ量を削減するためにスペースを節約するよい方法です。ビットマップ結合索引は、表の列の値ごとに、別の表の対応する行のROWID を格納します。データ・ウェアハウス環境では、結合条件は、ディメンション表の主キー列、およびファクト表の外部キー列との間の等価内部結合です。

ビットマップ結合索引は、マテリアライズド結合ビューより格納の効率がはるかによく、事前に結合をマテリアライズする方法の代替手段です。これは、マテリアライズド結合ビューがファクト表の ROWID を圧縮しないためです。

パフォーマンスを考慮したドメイン索引の使用方法パフォーマンスを考慮したドメイン索引の使用方法パフォーマンスを考慮したドメイン索引の使用方法パフォーマンスを考慮したドメイン索引の使用方法ドメイン索引は、ユーザー定義の索引タイプで指定された索引作成論理で作成されます。索引タイプを使用すると、特定の演算子の述部に合うデータに効率よくアクセスできます。通常、ユーザー定義の索引タイプは、Spatial オプションと同様 Oracle のオプションの一部です。たとえば、SpatialIndextypeを使用すると、ある条件ボックスにオーバーラップする Spatialデータを効率よく取り出せます。

ドメイン索引の作成と保守で指定できるパラメータは、カートリッジによって異なります。同様に、ドメイン索引のパフォーマンスと記憶域の特性は、カートリッジ固有のマニュアルを参照してください。

次の情報は、適切なカートリッジ・マニュアルを参照してください。

� 索引付けできるデータ型

� 使用できる索引タイプ

� 索引タイプで使用できる演算子

� ドメイン索引を作成およびメンテナンスする方法

� 問合せで演算子を効率よく使用する方法

� パフォーマンス特性の内容

関連項目関連項目関連項目関連項目 : ビットマップ索引の詳細は、『Oracle Database 概要』および『Oracle Database データ・ウェアハウス・ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : ビットマップ結合索引の例および制限については、『Oracle Database データ・ウェアハウス・ガイド』を参照してください。

注意注意注意注意 : 索引の型は CREATE INDEXTYPE文でも作成できます。

索引およびクラスタの使用方法 15-9

パフォーマンスを考慮したクラスタの使用方法

パフォーマンスを考慮したクラスタの使用方法パフォーマンスを考慮したクラスタの使用方法パフォーマンスを考慮したクラスタの使用方法パフォーマンスを考慮したクラスタの使用方法クラスタとは、物理的にまとめて格納される 1 つ以上の表のグループです。それらの表は、共通の列を共有しており、通常、一緒に使用されるため、まとめて格納されます。関連する行が物理的にまとめて格納されているため、ディスク・アクセス時間が短縮されます。

クラスタを作成するには、CREATE CLUSTERコマンドを使用します。

表をクラスタ化するかどうかを判断するために、次のガイドラインに従ってください。

� アプリケーションが結合処理で頻繁にアクセスする表をクラスタ化します。

� アプリケーションが表の結合を頻繁には行わない場合、または共通の列の値を頻繁に修正する場合、それらの表はクラスタ化しません。表をクラスタ化した場合、Oracle は修正された行を別のブロックへ移行して、クラスタをメンテナンスする必要もあります。このため、非クラスタ化表の値を修正する場合よりも、行のクラスタ・キー値を修正する場合の処理時間は長くなる可能性があります。

� アプリケーションが複数の表の 1 つについてのみ頻繁に全表スキャンを行う場合、それらの表はクラスタ化しません。クラスタ化表の全表スキャンに要する処理時間は、非クラスタ化表の全表スキャンよりも長くなる可能性があります。複数の表があわせて格納されているため、Oracle が読み込む必要のあるブロックは多くなります。

� マスター・レコードを選択してからディテール・レコードを選択することがよくある場合、マスター / ディテール表をクラスタ化します。ディテール・レコードはマスター・レコードと同じデータ・ブロックに格納されるため、選択時にそれらがメモリー内に存在している可能性が高くなり、Oracle による I/O 処理が少なくなる場合があります。

� 同じマスターについて多くのディテール・レコードを選択することがよくある場合、ディテール表のみをクラスタに格納します。このようにすれば、同じマスターについて多くの詳細レコードを選択する問合せのパフォーマンスが改善され、マスター表に対する全表スキャンのパフォーマンスも低下させずに済みます。別の方法として、索引構成表を使用する方法があります。

� 同じクラスタ・キー値を持つすべての表からのデータが、1 つまたは 2 つの Oracle ブロックを超える場合、それらの表はクラスタ化しません。クラスタ化表の行をアクセスする場合、Oracle はその値を持つ行を含んでいるブロックをすべて読み込みます。これらの行が複数のブロックを使用している場合、単一行をアクセスすることによって、非クラスタ化表で同じ行をアクセスする場合よりも多くの読込み処理が必要になる場合があります。

� 各クラスタ・キー値の行数が大きく異なっている場合は表をクラスタ化しないでください。クラスタ化した場合、カーディナリティの低いキー値の場合には領域が無駄になり、カーディナリティの高いキー値の場合には衝突が発生します。衝突が発生するとパフォーマンスが下がります。

アプリケーションのニーズに応じて、クラスタの長所と短所を検討してください。たとえば、結合文のパフォーマンス向上が、クラスタ・キー値を修正する文のパフォーマンス低下を上回る場合もあります。表をクラスタ化した場合と別々に格納した場合について実験して、処理時間を比較してください。

関連項目関連項目関連項目関連項目 : SpatialIndextypeの詳細は、『Oracle Spatial開発者ガイド』を参照してください。

関連項目関連項目関連項目関連項目 : クラスタの詳細は、『Oracle Database 概要』を参照してください。

関連項目関連項目関連項目関連項目 : クラスタの詳細は、『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パラメータにかかわらず、指定されたアプローチを使用します。

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 文の構文構造体に基づいて使用できる場合のみ、オプティマイザはそのアクセス・パスを選択します。ヒントを使用できないアクセス・パスを指定すると、オプティマイザはその指定を無視します。

注意注意注意注意 : オプティマイザの目標は直接実行される問合せにのみ適用されます。ヒントを使用して、PL/SQL の内部から実行される SQL 文のためのアクセス・パスを指定してください。ALTER SESSION...SET OPTIMIZER_MODE文は、PL/SQL の内部から実行される SQL には作用しません。

オプティマイザ・ヒントの使用方法 16-3

オプティマイザ・ヒントの理解

アクセスする表は、文に指定する場合と同じように正確に指定してください。文が表の別名を使用している場合、表の名前ではなく、表の別名をヒントで使用する必要があります。スキーマ名が文中にある場合は、ヒント内の表名にそのスキーマ名を入れないでください。

マージ可能なビューでのヒントの動作については、16-10 ページの「ビューに対するアクセス・パスとヒント結合」および 16-11 ページの「ビューの内側のアクセス・パスとヒント結合」を参照してください。

問合せの変換に関するヒント問合せの変換に関するヒント問合せの変換に関するヒント問合せの変換に関するヒント次の各ヒントでは、オプティマイザが特定の 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

結合操作のヒント結合操作のヒント結合操作のヒント結合操作のヒント次の各ヒントでは、オプティマイザが表の特定の結合操作を使用するように指示します。

� USE_NL

� NO_USE_NL

� USE_NL_WITH_INDEX

� USE_MERGE

� NO_USE_MERGE

� USE_HASH

� NO_USE_HASH

注意注意注意注意 : アクセス・パスのヒントの場合、SELECT文の FROM句で SAMPLEオプションを指定すると、Oracle はヒントを無視します。

関連項目関連項目関連項目関連項目 : SAMPLEオプションの詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

16-4 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 ページの「ビューの内側のパラレル実行ヒント」を参照してください。

その他のヒントその他のヒントその他のヒントその他のヒントこの項ではその他のいくつかのヒントを説明します。

� 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

関連項目関連項目関連項目関連項目 : パラレル実行の詳細は、『Oracle Database データ・ウェアハウス・ガイド』を参照してください。

オプティマイザ・ヒントの使用方法 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は、表の名前または別名を指定します。

ビューのパスが指定されている場合、ヒントは左から右へ解決されます。この場合、1 つ目のビューは FROM句に含まれる必要があり、それ以降の各ビューは、前のビューの FROM句で指定されている必要があります。

たとえば、例 16-3 では、部門内で給与が 高である各従業員について、従業員の姓名、従業員の 初のジョブおよび従業員の全ダイレクト・レポートの合計給与を戻すためのビュー vが作成されます。データを問合せる場合、ビュー e2の表 e3に索引 emp_job_ixを使用することを強制できます。

例例例例 16-3 グローバル・ヒントの使用例グローバル・ヒントの使用例グローバル・ヒントの使用例グローバル・ヒントの使用例

CREATE OR REPLACE VIEW v ASSELECT e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_salFROM employees e1, ( SELECT * FROM employees e3) e2, job_history jWHERE 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_idORDER 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;

view .table

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にプッシュされます。

複合索引ヒントの指定方法複合索引ヒントの指定方法複合索引ヒントの指定方法複合索引ヒントの指定方法索引を指定するヒントには、次のように、単純な索引名またはカッコで括られた列のリストのいずれかを使用できます。

indexspec::=

各項目は次のとおりです。

� 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-10 ページ「ビューでのヒントの使用方法」

index

(table .

column )

オプティマイザ・ヒントの使用方法 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 パフォーマンス・チューニング・ガイド

SQL アクセス・アド

17

SQL アクセス・アドバイザアクセス・アドバイザアクセス・アドバイザアクセス・アドバイザ

この章では、SQL アクセス・アドバイザの使用方法について説明します。SQL アクセス・アドバイザは、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログについてアドバイスを提供するチューニング・ツールです。この章には次の項があります。

� DBMS_ADVISOR パッケージの 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 アクセス・アドバイザの使用手順アクセス・アドバイザの使用手順アクセス・アドバイザの使用手順アクセス・アドバイザの使用手順図 17-2 には、SQL アクセス・アドバイザの使用手順と、SQL アクセス・アドバイザのすべてのパラメータの概要、およびその適切な使用タイミングを示します。

図図図図 17-2 SQL アクセス・アドバイザのフローチャートアクセス・アドバイザのフローチャートアクセス・アドバイザのフローチャートアクセス・アドバイザのフローチャート

関連項目関連項目関連項目関連項目 : SQL アクセス・アドバイザを Oracle Enterprise Manager で使用する方法については、『Oracle Database 2 日でパフォーマンス・チューニング・ガイド』を参照してください。

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 IN VARCHAR2, task_id OUT NUMBER, task_name IN OUT VARCHAR2, task_desc IN VARCHAR2 := NULL, template IN VARCHAR2 := NULL, is_template IN VARCHAR2 := 'FALSE', how_created IN VARCHAR2 := NULL);

DBMS_ADVISOR.CREATE_TASK ( advisor_name IN VARCHAR2, task_name IN VARCHAR2, task_desc IN VARCHAR2 := NULL, template IN VARCHAR2 := NULL, is_template IN VARCHAR2 := 'FALSE', how_created IN VARCHAR2 := 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/mvsEXECUTE 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/mvsEXECUTE 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 IN OUT VARCHAR2, description IN VARCHAR2 := NULL, template IN VARCHAR2 := NULL. is_template IN 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 SHEXECUTE 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 IN VARCHAR2, workload_name IN VARCHAR2);

次の例では、作成した MYTASKタスクを MYWORKLOAD SQL ワークロードにリンクします。

EXECUTE DBMS_ADVISOR.ADD_SQLWKLD_REF('MYTASK', 'MYWORKLOAD');

ADD_SQLWKLD_REFプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

ワークロードの内容の定義ワークロードの内容の定義ワークロードの内容の定義ワークロードの内容の定義ワークロードの作成後、ワークロードに情報を移入する必要があります。ワークロードは、データベースに使用されている SQL 文で構成されるのが理想的です（仮想ワークロードである場合を除きます）。SQL アクセス・アドバイザは、次のソースからワークロードを取得できます。

� SQL チューニング・セット

� ユーザー定義のワークロードのロード

� SQL キャッシュのワークロードのロード

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

SQL アクセス・アドバイザの使用方法

� 仮想ワークロードの使用方法

� Oracle Database 9i サマリー・アドバイザのワークロードの使用方法

SQL チューニング・セットチューニング・セットチューニング・セットチューニング・セット SQL チューニング・セットは、ワークロード・リポジトリにあるワークロードです。SQL チューニング・セットを SQL アクセス・アドバイザのワークロードとして使用するには、IMPORT_WORKLOAD_STSプロシージャを使用してこれをインポートします。このプロシージャの構文は、次のとおりです。

DBMS_ADVISOR.IMPORT_SQLWKLD_STS (workload_name IN VARCHAR2, sts_owner IN VARCHAR2, sts_name IN VARCHAR2, import_mode IN VARCHAR2 := 'NEW', priority IN NUMBER := 2, saved_rows OUT NUMBER, failed_rows OUT NUMBER);

DBMS_ADVISOR.IMPORT_SQLWKLD_STS (workload_name IN VARCHAR2, sts_name IN VARCHAR2, import_mode IN VARCHAR2 := 'NEW', priority IN NUMBER := 2, saved_rows OUT NUMBER, failed_rows 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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

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-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) 現在のユーザー 問合せを実行したユーザーです。これは必須列です。

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_COSTEXECUTE DBMS_ADVISOR.SET_SQLWKLD_PARAMETER ( - 'MYWORKLOAD', 'ORDER_LIST', 'OPTIMIZER_COST');-- Max number of statements 3EXECUTE 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 IN VARCHAR2, sql_id 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 := NULL, description IN VARCHAR2 := NULL, read_only IN VARCHAR2 := NULL, is_template IN VARCHAR2 := NULL, how_created IN VARCHAR2 := 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 に示します。

次の例では、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-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

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, BENEFITFROM 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_benefitFROM USER_ADVISOR_SQLA_WK_STMTSWHERE 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) cntFROM user_advisor_actions WHERE task_name = :task_name;

'ACTIONCOUNT CNT ------------ ---------- Action Count 20

-- see the actions for each recommendationsSELECT rec_id, action_id, SUBSTR(command,1,30) AS commandFROM user_advisor_actions WHERE task_name = :task_nameORDER 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 12 GATHER TABLE STATISTICS 1 19 CREATE INDEX 1 20 GATHER INDEX STATISTICS 2 5 CREATE MATERIALIZED VIEW LOG 2 6 ALTER MATERIALIZED VIEW LOG 2 9 CREATE MATERIALIZED VIEW LOG ... 各アクションには、アクセス構造のプロパティに関連する複数の属性があります。各アクセス構造の名前と表領域は、必要に応じて attr1および attr2にそれぞれ格納されます。新しい各アクセス構造が占有する領域は、num_attr1にあります。その他すべての属性は、アクションごとに異なります。

表 17-3 では、SQL アクセス・アドバイザのアクション情報を DBA_ADVISOR_ACTIONS内の該当する列にマップします。

表表表表 17-3 SQL アクセス・アドバイザのアクション属性アクセス・アドバイザのアクション属性アクセス・アドバイザのアクション属性アクセス・アドバイザのアクション属性

ATTR1 ATTR2 ATTR3 ATTR4 ATTR5 ATTR6 NUM_ATTR1

CREATE INDEX 索引名 索引表領域 ターゲット表

BITMAPまたはBTREE

索引列リスト / 式

未使用 索引の記憶域のサイズ

（バイト単位）

CREATE MATERIALIZED VIEW

MV 名 MV 表領域 REFRESH COMPLETE REFRESH FAST、 REFRESH FORCE、NEVER REFRESH

ENABLE QUERY REWRITE、DISABLE QUERY REWRITE

SQL SELECT文

未使用 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

ターゲット表名

未使用 未使用 未使用 未使用 未使用 未使用

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 procedureset serveroutput on size 99999EXECUTE show_recm(:task_name);A fragment of a sample output from this procedure is as follows:Task_name = MYTASKAction ID: 1Command : CREATE MATERIALIZED VIEW LOG Attr1 (name) : "SH"."CUSTOMERS"Attr2 (tablespace):Attr3 : ROWID, SEQUENCEAttr4 : INCLUDING NEW VALUESAttr5 :----------------------------------------..----------------------------------------Action ID: 15Command : CREATE MATERIALIZED VIEWAttr1 (name) : "SH"."SH_MV$$_0004"Attr2 (tablespace): "SH_MVIEWS"Attr3 : REFRESH FAST WITH ROWIDAttr4 : ENABLE QUERY REWRITEAttr5 :----------------------------------------..----------------------------------------Action ID: 19Command : CREATE INDEX

17-22 Oracle Database パフォーマンス・チューニング・ガイド

SQL アクセス・アドバイザの使用方法

Attr1 (name) : "SH"."SH_IDX$$_0013"Attr2 (tablespace): "SH_INDEXES"Attr3 : "SH"."SH_MV$$_0002"Attr4 : BITMAPAttr5 :

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 itCONNECT 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 - ProductionRem Rem Username: SHRem Task: MYTASKRem Execution date: 15/04/2005 11:35Rem set feedback 1set linesize 80set trimspool onset tab offset pagesize 60whenever 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 FROMSH.CUSTOMERS WHERE (SH.CUSTOMERS.CUST_STATE_PROVINCE = 'CA') GROUPBY 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.SQLCODEBEGIN 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;/

推奨事項が必要なくなった場合推奨事項が必要なくなった場合推奨事項が必要なくなった場合推奨事項が必要なくなった場合RESET_TASKプロシージャは、タスクを初期の開始ポイントにリセットします。これにより、すべての推奨事項と中間データがタスクから削除されます。実際のタスクのステータスは、INITIALに設定されます。 この構文は、次のとおりです。

DBMS_ADVISOR.RESET_TASK (task_name IN VARCHAR2);

次に、このプロシージャの使用例を示します。

EXECUTE DBMS_ADVISOR.RESET_TASK('MYTASK');

RESET_TASKプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : CREATE DIRECTORY構文の詳細は『Oracle Database SQL 言語リファレンス』を、GET_TASK_SCRIPTプロシージャの詳細は『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 selectionINSERT 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 selectionINSERT 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_amountFROM sales s, times t, customers c, channels chWHERE s.time_id = t.time_id AND s.cust_id = c.cust_idAND 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 byINSERT INTO user_workload (username, module, action, priority, sql_text)VALUES ('SH', 'Example1', 'Action', 2, 'SELECT c.country_id, c.cust_city, c.cust_last_nameFROM 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 task_id NUMBER;VARIABLE task_name VARCHAR2(255);VARIABLE workload_name VARCHAR2(255);VARIABLE saved_stmts NUMBER;VARIABLE 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, benefitFROM 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_benefitFROM user_advisor_sqla_wk_stmtsWHERE 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 commandFROM user_advisor_actionsWHERE task_name = :task_nameORDER BY rec_id, action_id;

-- See what the actions are using sample procedure.SET SERVEROUTPUT ON SIZE 99999EXECUTE 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 taskSELECT parameter_name, parameter_valueFROM user_advisor_parametersWHERE 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 dollarsFROM sales s, times t WHERE s.time_id = t.time_idAND 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 bySELECT c.country_id, c.cust_city, c.cust_last_nameFROM customers c WHERE c.country_id IN ('52790', '52789')ORDER BY c.country_id, c.cust_city, c.cust_last_name;

-- Queries to illustrate filteringCONNECT scott/tiger;SELECT e.ename, d.dnameFROM emp e, dept d WHERE e.deptno = d.deptno;

SELECT COUNT(*) FROM dept;

CONNECT sh/shVARIABLE 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 viewsSELECT num_select_stmt, create_dateFROM user_advisor_sqlw_sumWHERE workload_name = :workload_name;

SELECT sql_id, username, optimizer_cost, SUBSTR(sql_text, 1, 30)FROM user_advisor_sqlw_stmtsWHERE workload_name = :workload_nameORDER 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_dateFROM user_advisor_sqlw_sumWHERE 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, benefitFROM 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 nameFROM user_advisor_actions WHERE task_name = :task_nameORDER 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_mvREFRESH FASTDISABLE QUERY REWRITE ASSELECT s.prod_id, s.cust_id, SUM(s.amount_sold) sum_amountFROM sales s, customers csWHERE s.cust_id = cs.cust_idGROUP 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_MVREFRESH FAST WITH ROWIDDISABLE QUERY REWRITE ASSELECT 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_MVIEWWHERE 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_mvENABLE QUERY REWRITE ASSELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amountFROM sales s, customers cs, countries cnWHERE s.cust_id = cs.cust_id AND cs.country_id = cn.country_idAND cn.country_name IN (''USA'',''Canada'')GROUP BY s.prod_id, s.cust_idUNIONSELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amountFROM sales s, customers csWHERE 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");

BEGINDBMS_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$SUB1DROP MATERIALIZED VIEW SH.CUST_MV$SUB2DROP MATERIALIZED VIEW SH.CUST_MVDBMS_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_MVIEWWHERE 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_mvREFRESH FAST ON DEMANDENABLE QUERY REWRITE ASSELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amountFROM sales s, customers csWHERE s.cust_id = cs.cust_id AND s.cust_id IN (2005,1020)GROUP BY s.prod_id, s.cust_id UNIONSELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amountFROM 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';

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$SUB1DROP MATERIALIZED VIEW SH.CUST_MVDBMS_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 は実行計画そのものではなく実行計画への入力を使用して、アウトラインを生成します。

アウトラインの格納アウトラインの格納アウトラインの格納アウトラインの格納アウトライン・データは、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 テキストのシグネチャを生成します。

注意注意注意注意 : Oracle は、SYS表領域に USER_OUTLINESビューとUSER_OUTLINE_HINTSビューを、それぞれ OL$表と OL$HINTS表のデータに基づいて作成します。OL$、OL$HINTSおよび OL$NODES表の直接操作は禁止されています。

SQL 文にヒントを組み込むことはできますが、その結果が Oracle によるアウトラインの使用方法に影響することはありません。Oracle は、ヒントを使用して修正された SQL 文を、アウトラインに格納されている元のSQL 文とは異なるものとして認識します。

プラン・スタビリティの使用方法 18-3

実行計画を保持するためのプラン・スタビリティの使用

アウトラインの作成アウトラインの作成アウトラインの作成アウトラインの作成すべての SQL 文に対して自動的にアウトラインを作成することも、特定の SQL 文に対して自分でアウトラインを作成することもできます。そのどちらの場合においても、アウトラインの入力はオプティマイザから導出されます。

初期化パラメータ CREATE_STORED_OUTLINESを TRUEに設定すると、ストアド・アウトラインは Oracle によって自動的に作成されます。パラメータを有効にすると、Oracle はコンパイルされた SQL 文すべてにアウトラインを作成します。CREATE OUTLINE文を使用して、特定の文に対するストアド・アウトラインを作成することもできます。

プライベート・アウトラインを作成または編集する場合、アウトライン・データは SYSTEMスキーマのグローバル一時表に書き込まれます。これらの表は、OL$、OL$HINTSおよびOL$NODESの各シノニムによりアクセスできます。

関連項目関連項目関連項目関連項目 :

� DBMS_OUTLNパッケージ・プロシージャの使用方法の詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� DBMS_OUTLN_EDITパッケージ・プロシージャの使用方法の詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

注意注意注意注意 : アウトラインを作成するスキーマに CREATE ANY OUTLINE権限があることを必ず確認してください。この権限が存在しない場合は、CREATE_STORED_OUTLINE初期化パラメータをオンにしても、アプリケーションの実行後にデータベース内でアウトラインを見つけることはできません。

また、CREATE_STORED_OUTLINES初期化パラメータが有効で、実行中のアプリケーションに多数のリテラル SQL 文がある場合、デフォルトのシステム表領域がすべて使用される可能性があります。その場合は、DBMS_OUTLN.DROP_UNUSEDプロシージャを使用して、これらのリテラルSQL のアウトラインを削除します。

関連項目関連項目関連項目関連項目 :

� CREATE OUTLINE文の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

� DBMS_OUTLNおよび DBMS_OUTLN_EDITの各パッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� ルールベース・オプティマイザから問合せオプティマイザに移行する方法の詳細は、18-8 ページの「RBO から問合せオプティマイザへの移行」を参照してください。

18-4 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文により、ストアド・アウトラインの名前の変更、別のカテゴリへの再割当てまたは再生成も可能です。

指定されたアウトラインは、アウトラインを持つ 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を有効にした場合に使用されるパブリック領域ではなく、セッションのプライベート領域からアウトラインを取り出します。セッションの

関連項目関連項目関連項目関連項目 : ALTER OUTLINE文の詳細は、『Oracle Database SQL 言語リファレンス』を参照してください。

プラン・スタビリティの使用方法 18-5

実行計画を保持するためのプラン・スタビリティの使用

プライベート領域にアウトラインが存在しない場合、オプティマイザは、文のコンパイルにアウトラインを使用しません。

CREATE OUTLINE文はすべて、CREATE ANY OUTLINE権限が必要です。FROM句を指定する場合は、SELECT権限も必要です。この権限は、アウトラインを使用する文に関連する SQL テキストとヒント・テキストを表示する権限を持つユーザーのみに与える必要があります。このロールは、CREATE OUTLINE FROMコマンドに必要です。コマンドの発行者がアウトラインの所有者でもある場合は、このロールは不要です。

アウトラインが 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';

注意注意注意注意 : USE_STORED_OUTLINESおよび USE_PRIVATE_OUTLINESパラメータは、システムまたはセッション固有です。これらは初期化パラメータではありません。 これらのパラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

18-6 Oracle Database パフォーマンス・チューニング・ガイド

実行計画を保持するためのプラン・スタビリティの使用

互換性、形式およびアウトラインが使用可能かどうかについて、_OUTLINESビューのフラグを確認できます。たとえば、アウトラインが使用可能かどうかを判断するには、USER_OUTLINESビューの ENABLEDフィールドを確認します。

SELECT NAME, CATEGORY, ENABLED FROM USER_OUTLINES;

アウトライン表の移動アウトライン表の移動アウトライン表の移動アウトライン表の移動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)

関連項目関連項目関連項目関連項目 : アウトラインに関連するビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

プラン・スタビリティの使用方法 18-7

問合せオプティマイザのアップグレードによるプラン・スタビリティの使用

インポート・プロセスが完了すると、OUTLNという名前のスキーマに OL$表、OL$HINTS表および OL$NODES表が再作成され、OUTLN_TSという新しい表領域に配置されます。

このプロセスが完了した後、前のステップで削除された権限およびロールを追加することで、OUTLNユーザーの表領域割当て制限を適切に調整できます。

問合せオプティマイザのアップグレードによるプラン・スタビ問合せオプティマイザのアップグレードによるプラン・スタビ問合せオプティマイザのアップグレードによるプラン・スタビ問合せオプティマイザのアップグレードによるプラン・スタビリティの使用リティの使用リティの使用リティの使用

この項では、問合せオプティマイザの機能を利用してパフォーマンスを大幅に改善する手順を説明します。プラン・スタビリティは、システムが目標としている、パフォーマンスのよい実行計画を保ちながら、一方で、残りの SQL 文に対する問合せオプティマイザの新機能の利点も利用する手段を提供します。

元の実行計画の正確な再現が保証されない SQL 文および機能のクラスもありますが、プラン・スタビリティは移行プロセスにおける非常に便利な要素です。移行前に、アプリケーションのSQL 文のすべてまたは大部分が取得されるまで、実行計画のアウトライン取得をオンにする必要があります。移行後に、特定の SQL 文でパフォーマンスの問題がある場合は、以前の動作を元に戻す方法として、この文に対するストアド・アウトラインの使用をオンにできます。ストアド・アウトラインの使用は、変化するデータ・プロパティに計画が適応できないため、移行関連のパフォーマンスの問題を解決する 善の方法ではない場合がありますが、こうした問題への対処に使用できる数あるテクニックの 1 つです。

この項で説明する項目は次のとおりです。

� RBO から問合せオプティマイザへの移行

� 問合せオプティマイザを使用している場合の新規 Oracle リリースへの移行

RBO から問合せオプティマイザへの移行から問合せオプティマイザへの移行から問合せオプティマイザへの移行から問合せオプティマイザへの移行ルールベース・オプティマイザを使用して開発したアプリケーションの場合、パフォーマンスを 適化するために SQL 文の手動チューニングに多大な作業量を投入している場合があります。プラン・スタビリティを使用すると、ルールベースの 適化から問合せの 適化へアップグレードする際にアプリケーションの動作を保持することによって、すでにパフォーマンス・チューニングに投入した作業を生かすことができます。

問合せの 適化に切り替える前にアプリケーションのアウトラインを作成すると、ルールベース・オプティマイザで生成した計画を使用しながら、切替え後に新しく作成されたアプリケーションで生成した文で問合せの計画を使用できます。アプリケーションのアウトラインを作成および使用するには、次のプロセスを実行します。

1. アウトラインを作成するスキーマに CREATE ANY OUTLINE権限があることを確認します。たとえば、SYSからは次のようになります。

GRANT CREATE ANY OUTLINE TO user-name

関連項目関連項目関連項目関連項目 :

� Exportおよび Importのユーティリティの使用方法は、『Oracle Database ユーティリティ』を参照してください。Importユーティリティの説明の箇所にある表領域の再編成に関する項に注意してください。

� DBMS_OUTLNパッケージの使用方法の詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

注意注意注意注意 : この手順をよく読んで、内容を十分理解してから実行してください。

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 文のアクセス・パスは変更しないようにしてください。

問合せオプティマイザを使用している場合の新規問合せオプティマイザを使用している場合の新規問合せオプティマイザを使用している場合の新規問合せオプティマイザを使用している場合の新規 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. アプリケーションを実行します。

アップグレード後は、ストアド・アウトラインを使用可能にすることもできますし、あるいは、アップグレード後にパフォーマンスの低下を示す文があれば格納されていたアウトラインをバックアップとして使用することもできます。

注意注意注意注意 : 手順 2 で問合せが実行されなかった場合は、問合せの 適化に切り替えた後も、以前の問合せの動作が獲得される可能性があります。その場合は、オプティマイザ・モードを RULEに変更し、問合せのアウトラインを作成してから、オプティマイザ・モードを再び CHOOSEに戻します。

注意注意注意注意 : この手順をよく読んで、内容を十分理解してから実行してください。

プラン・スタビリティの使用方法 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 パフォーマンス・チューニング・ガイド

EXPLAIN PLAN の使

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 章「問合せオプティマイザ」

用方法 19-1

EXPLAIN PLAN について

EXPLAIN PLAN についてについてについてについてEXPLAIN PLAN文は、SELECT、UPDATE、INSERTおよび DELETE文について Oracle オプティマイザが選択した実行計画を表示します。文の実行計画とは、Oracle がその文を実行するために行う一連の処理です。

行ソース・ツリーは、実行計画の中核です。行ソース・ツリーは次の情報を示します。

� 文によって参照される表の順序

� 文で言及される各表へのアクセス方法

� 文の結合操作の影響を受ける表の結合方法

� フィルタ、ソート、集計などのデータ操作

PLAN TABLE には、行ソース・ツリーの他、次の情報が含まれています。

� 適化。各操作のコストとカーディナリティについて。

� パーティション化。アクセスされたパーティションのセットなど。

� パラレル実行。結合入力の配分方法など。

EXPLAIN PLANの結果により、オプティマイザが特定の実行計画（たとえば、ネステッド・ループ結合）を選択するかどうかを判断できます。また、オプティマイザの決定（たとえば、オプティマイザがハッシュ結合でなくネステッド・ループ結合を選択した理由）について理解し、問合せのパフォーマンスを知るために役立ちます。

実行計画の変化理由実行計画の変化理由実行計画の変化理由実行計画の変化理由問合せオプティマイザを使用すると、実行計画は基礎となるオプティマイザ入力が変化するたびに変化します。EXPLAIN PLANの出力は、SQL 文の説明段階での実行方法を示します。この方法は、実行環境と EXPLAIN PLAN 環境との違いにより、SQL 文の実際の実行計画とは異なる場合があります。

実行計画は、次の理由により異なります。

� スキーマの相違

� コストの相違

スキーマの相違スキーマの相違スキーマの相違スキーマの相違� 実行と EXPLAIN PLAN が、異なるデータベース上で起こる場合。

� 文を EXPLAIN するユーザーが、文を実行するユーザーとは異なる場合。2 人のユーザーが同じデータベース内の異なるオブジェクトを指していれば、異なる実行計画が発生します。

� 2 つの操作間でスキーマが変更された場合（多くは索引の変更）。

コストの相違コストの相違コストの相違コストの相違スキーマが同じであっても、コストが異なる場合にオプティマイザは異なる実行計画を選択する可能性があります。コストに影響を与えるいくつかの要因には次のものがあります。

� データ量と統計

� バインド変数の型と値

� 初期化パラメータ（グローバル設定またはセッション・レベルでの設定）

注意注意注意注意 : Oracle Performance Manager チャートと Oracle SQL Analyze は、EXPLAIN PLAN を自動的に作成して表示できます。EXPLAIN PLAN の使用方法の詳細は、『Oracle Enterprise Manager 概要』を参照してください。

19-2 Oracle Database パフォーマンス・チューニング・ガイド

EXPLAIN PLAN について

排除行数の最少化排除行数の最少化排除行数の最少化排除行数の最少化EXPLAIN PLAN を調べることにより、次の場合の排除行数を確認できます。

� 全表スキャン

� 選択性のないレンジ・スキャン

� 遅延した述語フィルタ

� 誤った結合順序

� 遅延したフィルタ処理

たとえば、次の EXPLAIN PLAN では、 後のステップは非常に選択性のないレンジ・スキャンです。このレンジ・スキャンは 76563 回実行され、11432983 行にアクセスし、アクセスした行の 99 パーセントを排除して 76563 行を保持します。11432983 行にアクセスした結果、必要な行が 76563 行のみであると判別された理由について考えます。

例例例例 19-1 EXPLAIN PLAN 内の排除行数の確認内の排除行数の確認内の排除行数の確認内の排除行数の確認

Rows Execution Plan-------- ---------------------------------------------------- 12 SORT AGGREGATE 2 SORT GROUP BY 76563 NESTED LOOPS 76575 NESTED LOOPS 19 TABLE ACCESS FULL CN_PAYRUNS_ALL 76570 TABLE ACCESS BY INDEX ROWID CN_POSTING_DETAILS_ALL 76570 INDEX RANGE SCAN (object id 178321) 76563 TABLE ACCESS BY INDEX ROWID CN_PAYMENT_WORKSHEETS_ALL11432983 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情報が結合されます。

EXPLAIN PLAN の制限事項の制限事項の制限事項の制限事項EXPLAIN PLANは、日付バインド変数の暗黙的な型変換を実行する文をサポートしません。一般にバインド変数では、EXPLAIN PLANが実際の実行計画を表していない場合があります。

TKPROFは、SQL 文のテキストからバインド変数の型を判断することはできません。型はCHARACTERであると想定され、これ以外の場合はエラー・メッセージが表示されます。この制限事項は、SQL 文に適切な型変換を入れることで対処できます。

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;

関連項目関連項目関連項目関連項目 :

� V$SQL_PLANビューの詳細は、『Oracle Database リファレンス』を参照してください。

� STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : 第 20 章「アプリケーション・トレース・ツールの使用方法」

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' FORSELECT last_name FROM employees;

EXPLAIN PLAN での別の表の指定での別の表の指定での別の表の指定での別の表の指定INTO句を指定して、別の表を指定できます。

例例例例 19-4 INTO 句での句での句での句での EXPLAIN PLAN の使用方法の使用方法の使用方法の使用方法

EXPLAIN PLAN INTO my_plan_table FORSELECT last_name FROM employees;

INTO句を使用する場合は、文の識別子を指定できます。

EXPLAIN PLAN SET STATEMENT_ID = 'st1' INTO my_plan_table FORSELECT 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'));

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_TABLECONNECT 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

関連項目関連項目関連項目関連項目 : DBMS_XPLANパッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

19-6 Oracle Database パフォーマンス・チューニング・ガイド

EXPLAIN PLAN 出力の読み方

Rows列の NULLは、オプティマイザが表に統計を持っていないことを示します。表をANALYZE すると、次の内容が表示されます。

Rows Plan------- ---------------------------------------- 16957 SELECT STATEMENT 16957 TABLE ACCESS FULL EMPLOYEES

COSTも選択できます。これは、実行計画を比較する場合や、オプティマイザが複数の中からある実行計画を選択した理由を理解する場合に便利です。

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' FORSELECT 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' FORSELECT last_name FROM employees WHERE last_name LIKE 'Pe%';

SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, 'ex_plan2','BASIC'));

注意注意注意注意 : これらの単純な例は、再帰的 SQL の場合には有効ではありません。

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操作があります。これらの操作が発生するとボトルネックになる可能性があります。パフォーマンスを向上させるために、これらの操作をパラレル操作にすることを考慮します。

� PARALLEL_FROM_SERIAL

19-8 Oracle Database パフォーマンス・チューニング・ガイド

EXPLAIN PLAN によるパラレル実行の表示

� PARALLEL_TO_PARALLEL

通常は、各操作のワークロードがほぼ同じであるかぎり、PARALLEL_TO_PARALLEL操作によって 適なパフォーマンスが得られます。

� PARALLEL_COMBINED_WITH_CHILD

� PARALLEL_COMBINED_WITH_PARENT

ステップが親ステップと同時に実行される場合、PARALLEL_COMBINED_WITH_PARENT操作が発生します。

パラレル・ステップによって多数の行が生成されると、問合せコーディネータ（QC）がそれらの行を生成後すぐに処理できない場合があります。このような状況を改善する方法はありません。

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（問合せコーディネータ）を表します。

関連項目関連項目関連項目関連項目 : 19-18 ページの表 19-1「PLAN_TABLE 列」の OTHER_TAG列を参照してください。

EXPLAIN PLAN の使用方法 19-9

EXPLAIN PLAN によるビットマップ索引の表示

EXPLAIN PLAN によるビットマップ索引の表示によるビットマップ索引の表示によるビットマップ索引の表示によるビットマップ索引の表示ビットマップ索引を使用する索引行ソースは、索引のタイプを示すワード BITMAPとともにEXPLAIN PLAN出力に表示されます。例 19-9 の問合せおよび計画の次の例を検討します。

例例例例 19-9 ビットマップ検索によるビットマップ検索によるビットマップ検索によるビットマップ検索による EXPLAIN PLAN

EXPLAIN PLAN FORSELECT * FROM tWHERE 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 (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_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 OPTIONS OBJECT_NAME---------------- --------------- -------------- SELECT STATEMENTINLIST ITERATORTABLE ACCESS BY ROWID EMPINDEX RANGE SCAN EMP_EMPNO

INLIST ITERATOR操作は、INリスト述語内の各値に対して、計画内の次の操作を反復します。パーティション表およびパーティション索引には 3 種類の INリスト列が使用可能ですが、これについては次の項で説明します。

19-16 Oracle Database パフォーマンス・チューニング・ガイド

EXPLAIN PLAN によるパーティション・オブジェクトの表示

IN リスト列が索引列である場合リスト列が索引列である場合リスト列が索引列である場合リスト列が索引列である場合INリスト列 empnoが索引列で、パーティション列ではない場合、計画は次のようになります

（INリスト演算子は表操作の前に表示されますが、パーティションの操作よりは後に表示されます）。

OPERATION OPTIONS OBJECT_NAME PARTITION_START PARTITION_STOP---------------- ------------ ----------- --------------- -------------- SELECT STATEMENT PARTITION RANGE ALL KEY(INLIST) KEY(INLIST)INLIST ITERATORTABLE ACCESS BY LOCAL INDEX ROWID EMP KEY(INLIST) KEY(INLIST)INDEX RANGE SCAN EMP_EMPNO KEY(INLIST) KEY(INLIST)

PARTITION_START 列と PARTITION_STOP 列に KEY（INLIST）指定があるため、索引の開始 / 終了キーに対して INリスト述語が表示されます。

IN リスト列が索引でありパーティション列である場合リスト列が索引でありパーティション列である場合リスト列が索引でありパーティション列である場合リスト列が索引でありパーティション列である場合empnoが索引付けされている列で、それがパーティション列でもある場合、計画にはパーティション操作の前に INLIST ITERATOR操作が含まれています。

OPERATION OPTIONS OBJECT_NAME PARTITION_START PARTITION_STOP---------------- ------------ ----------- --------------- --------------SELECT STATEMENTINLIST ITERATORPARTITION RANGE ITERATOR KEY(INLIST) KEY(INLIST)TABLE ACCESS BY LOCAL INDEX ROWID EMP KEY(INLIST) KEY(INLIST)INDEX RANGE SCAN EMP_EMPNO KEY(INLIST) KEY(INLIST)

IN リスト列がパーティション列である場合リスト列がパーティション列である場合リスト列がパーティション列である場合リスト列がパーティション列である場合empnoがパーティション列で、索引が存在しない場合は、INLIST ITERATOR操作は割り当てられません。

OPERATION OPTIONS OBJECT_NAME PARTITION_START PARTITION_STOP---------------- ------------ ----------- --------------- --------------SELECT STATEMENTPARTITION RANGE INLIST KEY(INLIST) KEY(INLIST)TABLE ACCESS FULL EMP KEY(INLIST) KEY(INLIST)

emp_empnoがビットマップ索引である場合、計画は次のとおりです。

OPERATION OPTIONS OBJECT_NAME---------------- --------------- -------------- SELECT STATEMENTINLIST ITERATORTABLE ACCESS BY INDEX ROWID EMPBITMAP CONVERSION TO ROWIDSBITMAP INDEX SINGLE VALUE 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 OPTIONS OBJECT_NAME OTHER ----------------- ----------- ------------ ----------------SELECT STATEMENT TABLE ACCESS BY ROWID EMPDOMAIN INDEX 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 列

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): パラレル実

行。ステップの入力は、同じパラレル処理の前のステップから受け取ります。子からのプロセス間通信はありません。

表表表表 19-1 PLAN_TABLE 列（続き）列（続き）列（続き）列（続き）

列列列列 型型型型 説明説明説明説明

EXPLAIN PLAN の使用方法 19-19

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-1 PLAN_TABLE 列（続き）列（続き）列（続き）列（続き）

列列列列 型型型型 説明説明説明説明

19-20 Oracle Database パフォーマンス・チューニング・ガイド

PLAN_TABLE 列

表 19-2 で、DISTRIBUTION列に使用される値を説明します。

表 19-3 に、EXPLAIN PLAN文によって生成される OPERATIONと OPTIONSの各組合せおよびその実行計画におけるそれぞれの意味を示します。

PROJECTION VARCHAR2(4000) 操作によって生成される式です。

TIME NUMBER(20,2) 問合せの 適化によって見積もられた操作の秒単位の経過時間です。ルールベース・アプローチを使用する文では、この列は NULLになります。

QBLOCK_NAME VARCHAR2(30) 問合せブロックの名前です。システム生成または QB_NAMEヒント

によるユーザー定義のいずれかとなります。

表表表表 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 値値値値

操作操作操作操作 オプションオプションオプションオプション 説明説明説明説明

AND-EQUAL . 複数の ROWID のセットを受け取り、重複をなくして、そのセットの共

通部分を戻す処理。この処理は単一列索引のアクセス・パスに対して使用されます。

BITMAP CONVERSION TO ROWIDSは、ビットマップ表現を、表にアクセスするために使用で

きる実際の ROWID に変換します。

FROM ROWIDSは、ROWID をビットマップ表現に変換します。

COUNTは、実際の値を必要としない場合に ROWID の数を戻します。

BITMAP INDEX SINGLE VALUEは、索引内の単一のキー値のビットマップを参照しま

す。

RANGE SCANは、ある範囲のキー値のビットマップを取り出します。

FULL SCANは、開始キーまたは終了キーがない場合にビットマップ索

引の全体スキャンを実行します。

表表表表 19-1 PLAN_TABLE 列（続き）列（続き）列（続き）列（続き）

列列列列 型型型型 説明説明説明説明

EXPLAIN PLAN の使用方法 19-21

PLAN_TABLE 列

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-3 EXPLAIN PLAN によって生成されるによって生成されるによって生成されるによって生成される OPERATION 値と値と値と値と OPTIONS 値（続き）値（続き）値（続き）値（続き）

操作操作操作操作 オプションオプションオプションオプション 説明説明説明説明

19-22 Oracle Database パフォーマンス・チューニング・ガイド

PLAN_TABLE 列

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 を使用してマテリアライズド・ビューの行が指

定される場合。

表表表表 19-3 EXPLAIN PLAN によって生成されるによって生成されるによって生成されるによって生成される OPERATION 値と値と値と値と OPTIONS 値（続き）値（続き）値（続き）値（続き）

操作操作操作操作 オプションオプションオプションオプション 説明説明説明説明

EXPLAIN PLAN の使用方法 19-23

PLAN_TABLE 列

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-3 EXPLAIN PLAN によって生成されるによって生成されるによって生成されるによって生成される OPERATION 値と値と値と値と OPTIONS 値（続き）値（続き）値（続き）値（続き）

操作操作操作操作 オプションオプションオプションオプション 説明説明説明説明

19-24 Oracle Database パフォーマンス・チューニング・ガイド

PLAN_TABLE 列

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

表がパーティション化されており、グローバル索引のみを使用して行が指定される場合。

表表表表 19-3 EXPLAIN PLAN によって生成されるによって生成されるによって生成されるによって生成される OPERATION 値と値と値と値と OPTIONS 値（続き）値（続き）値（続き）値（続き）

操作操作操作操作 オプションオプションオプションオプション 説明説明説明説明

EXPLAIN PLAN の使用方法 19-25

PLAN_TABLE 列

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-3 EXPLAIN PLAN によって生成されるによって生成されるによって生成されるによって生成される OPERATION 値と値と値と値と OPTIONS 値（続き）値（続き）値（続き）値（続き）

操作操作操作操作 オプションオプションオプションオプション 説明説明説明説明

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 TracingEnd 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 を使用して、この機能を管理できます。

� エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化

� End to End Application Tracing の収集した統計の表示

� エンド・トゥ・エンド・トレースにおける有効化および無効化

� エンド・トゥ・エンド・トレースにおける使用可能なトレースの表示

20-2 Oracle Database パフォーマンス・チューニング・ガイド

End to End Application Tracing

エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化エンド・トゥ・エンド・トレースにおける統計収集の有効化および無効化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アクションに関する統計

関連項目関連項目関連項目関連項目 :

� サービスの詳細は、『Oracle Database 概要』を参照してください。

� OCI アプリケーションにおける必要なパラメータの設定の詳細は、『Oracle Call Interface プログラマーズ・ガイド』を参照してください。

� DBMS_MONITOR、DBMS_SESSION、DBMS_SERVICEおよびDBMS_APPICATION_INFOの各パッケージの詳細は、『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� V$ ビューおよび初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

アプリケーション・トレース・ツールの使用方法 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 トレース機能は、文単位に次の統計を生成します。

� 解析、実行、フェッチのカウント

� CPU 時間と経過時間

� 物理読込みと論理読込み

� 処理された行数

� ライブラリ・キャッシュでのミス

� それぞれの解析が行われるユーザー名

� 各コミットおよびロールバック

� 各 SQL 文の待機イベント・データおよび各トレース・ファイルの要約

20-8 Oracle Database パフォーマンス・チューニング・ガイド

SQL トレースと TKPROF について

また、SQL 文のカーソルがクローズされている場合は、SQL トレースにより次の内容を含む行ソース情報が提供されます。

� 各 SQL 文の実際の実行計画を示す行操作

� 行数、一貫性のある読込みの数、物理読込み数、物理書込み数および行の各操作の経過時間

1 つのセッションまたはインスタンスに対して SQL トレース機能を使用可能にできますが、かわりに DBMS_SESSIONまたは DBMS_MONITORパッケージを使用することをお薦めします。セッションまたはインスタンスに対して SQL トレース機能を使用可能にすると、ユーザー・セッションまたはインスタンスで実行されるすべての SQL 文のパフォーマンス統計がトレース・ファイルに格納されます。SQL トレース機能を使用するとパフォーマンスに重大な影響を与えることがあり、システム・オーバーヘッドの増加、過剰な CPU 使用率およびディスク領域の不足をもたらす場合があります。

Oracle では、セッションまたはクライアント ID などの特定の基準に基づいて複数のトレース・ファイルからトレース情報を統合する、trcsessコマンドライン・ユーティリティが提供されています。20-7 ページの「trcsess ユーティリティの使用方法」を参照してください。

TKPROF についてについてについてについてTKPROFプログラムを実行すると、トレース・ファイルの内容をフォーマットし判読可能なファイルとして出力できます。TKPROFは次のことも実行します。

� 統計をデータベースに格納する SQL スクリプトを作成します。

� SQL 文の実行計画を判断します。

TKPROFは、実行した各文を、消費したリソースおよびコールした回数、処理した行数とともにレポートします。この情報を使用すると、リソースを も多く使用している文を簡単に検出できます。経験、または参考にできる基準をもとに、使用されたリソースが実行された作業に対して妥当であるかどうかを評価できます。

関連項目関連項目関連項目関連項目 : DBMS_SESSIONまたは DBMS_MONITORパッケージを使用してセッションまたはインスタンスに対する SQL トレースを使用可能にする方法の詳細は、20-4 ページの「エンド・トゥ・エンド・トレースにおける有効化および無効化」を参照してください。

注意注意注意注意 : SQL 文のカーソルがクローズされていない場合、TKPROF出力には、SQL 文の実際の実行計画は自動的に含められません。この場合は、TKPROFで EXPLAINオプションを使用して、実行計画を生成できます。

アプリケーション・トレース・ツールの使用方法 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 トレース機能を有効にする前にチェックする初期化パラメータトレース機能を有効にする前にチェックする初期化パラメータトレース機能を有効にする前にチェックする初期化パラメータトレース機能を有効にする前にチェックする初期化パラメータ

パラメータパラメータパラメータパラメータ 説明説明説明説明

TIMED_STATISTICS これにより、SQL トレース機能による CPU 時間や経過時間などの

時間統計の収集、および動的パフォーマンス表の中の様々な統計の収集が使用可能または使用禁止にできます。デフォルト値は falseであり、時間計測は使用禁止になっています。true にすることに

よって時間計測が使用可能になります。時間計測を使用可能にすると、下位レベル操作に対する時間計測呼出しが余分に発生します。これは動的パラメータです。これはセッション・パラメータでもあります。

MAX_DUMP_FILE_SIZE SQL トレース機能がインスタンス・レベルで使用可能にされている

ときは、サーバーに対するすべてのコールはオペレーティング・システムのファイル形式でテキスト行を生成します。これらのファイルの 大サイズ（オペレーティング・システム・ブロック単位）は、初期化パラメータによって制限されます。デフォルト値は 500です。トレース出力が切り捨てられている場合、別のトレース・ファイルを生成する前にこのパラメータの値を大きくしてください。これは動的パラメータです。これはセッション・パラメータでもあります。

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

SQL トレース機能と TKPROF の使用方法

1. 結果のトレース・ファイルを認識する方法を考えます。

トレース・ファイルを名前で区別できるようにしてください。Oracle は、USER_DUMP_DESTで指定されたユーザー・ダンプ出力先にこれらを書き込みます。ただし、このディレクトリは通常、生成された名前を持つ何百ものファイルですぐに一杯になります。このため、トレース・ファイルを生成元のセッションやプロセスに対応づけることは困難な場合があります。SELECT 'program_name' FROM DUALのような文をプログラムに組み込むことによって、トレース・ファイルにタグを付けることができます。これによって、各ファイルの生成元のプロセスを追跡できます。

TRACEFILE_IDENTIFIER初期化パラメータを設定し、トレース・ファイル名の一部となるカスタム識別子も指定できます。たとえば、次の文によって、後続のトレース・ファイル名に my_trace_id を追加し、識別しやすくできます。

ALTER SESSION SET TRACEFILE_IDENTIFIER = 'my_trace_id';

2. オペレーティング・システムがファイルの複数のバージョンを保持している場合、SQL トレース機能が生成するトレース・ファイルの数に対して、バージョンの制限が十分高いことを確認してください。

3. 生成されたトレース・ファイルの所有者は、データベース管理者以外のオペレーティング・システム・ユーザーの場合があります。データベース管理者が TKPROFを実行してこれらのファイルをフォーマットする場合は、このユーザーが前もって、管理者がトレース・ファイルを利用できる状態にしておく必要があります。

USER_DUMP_DEST このパラメータで、オペレーティング・システムの規則に従って、トレース・ファイルの出力先をフルパスで指定する必要があります。デフォルト値は、使用するオペレーティング・システムのシステム・ダンプのデフォルトの出力先です。この値は、ALTER SYSTEM SET USER_DUMP_DEST= newdir を使用して変更できま

す。これは動的パラメータです。これはセッション・パラメータでもあります。

関連項目関連項目関連項目関連項目 :

� 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 リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 : TRACEFILE_IDENTIFIER初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 :

� STATISTICS_LEVELの設定の詳細は、10-5 ページの「統計収集のレベルの設定」を参照してください。

� STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

表表表表 20-1 SQL トレース機能を有効にする前にチェックする初期化パラメータ（続き）トレース機能を有効にする前にチェックする初期化パラメータ（続き）トレース機能を有効にする前にチェックする初期化パラメータ（続き）トレース機能を有効にする前にチェックする初期化パラメータ（続き）

パラメータパラメータパラメータパラメータ 説明説明説明説明

アプリケーション・トレース・ツールの使用方法 20-11

SQL トレース機能と TKPROF の使用方法

手順手順手順手順 2: SQL トレース機能を使用可能にする方法トレース機能を使用可能にする方法トレース機能を使用可能にする方法トレース機能を使用可能にする方法セッションに対して SQL トレース機能を使用可能にするには、次のいずれかを使用します。

� DBMS_SESSION.SET_SQL_TRACEプロシージャ

� ALTER SESSION SET SQL_TRACE = TRUE;

SQL トレース機能を使用禁止にするには、次のように入力します。

ALTER SESSION SET SQL_TRACE = FALSE;

アプリケーションが Oracle との接続を切断すると、そのセッションの SQL トレース機能は自動的に使用禁止になります。

初期化ファイルの SQL_TRACE初期化パラメータの値を TRUEに設定すると、インスタンスに対して SQL トレース機能が使用可能になります。

SQL_TRACE = TRUE

更新済初期化パラメータ・ファイルを使用してインスタンスを再起動すると、インスタンスに対して SQL トレースが使用可能になり、すべてのセッションに関する統計が収集されます。インスタンスに対して SQL トレース機能を使用可能にした場合は、SQL_TRACEパラメータの値を FALSEに設定すると使用禁止にできます。

注意注意注意注意 : 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_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 cpu elapsed disk query current rows---- ------- ------- --------- -------- -------- ------- ------Parse 1 0.16 0.29 3 13 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 1 0.03 0.26 2 2 4 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 JOIN14 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 の使用方法

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-2 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.PRFEXPLAIN=scott/tiger TABLE=scott.temp_plan_table_a INSERT=STOREA.SQL SYS=NOSORT=(EXECPU,FCHCPU)

この例は、スクリーン上で複数行にわたって表示される可能性があるので、使用しているオペレーティング・システムによっては継続文字を使用する必要があります。

この例で使用されている他のパラメータに注意してください。

� EXPLAINの値によって、TKPROFがユーザー scottとして接続され、トレースされた各SQL 文の実行計画を生成するために EXPLAIN PLAN文が使用されます。これを使用してアクセス・パスおよび行ソース行数を取得できます。

� 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パラメータを常に使用してください。

注意注意注意注意 : SQL 文のカーソルがクローズされていない場合、TKPROF 出力には、SQL 文の実際の実行計画は自動的に含められません。この場合は、TKPROFで EXPLAINオプションを使用して、実行計画を生成できます。

20-16 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 を参照してください。

SQL トレース機能の出力におけるその他の列は、すべての文の解析、実行、フェッチについての統計です。queryと currentの合計が、アクセスされたバッファの総数となります。これは論理 I/O（LIO）とも呼ばれます。表 20-4 を参照してください。

表表表表 20-3 CALL 列の値列の値列の値列の値

CALL の値の値の値の値 意味意味意味意味

PARSE 適切なセキュリティ認可のチェック、および表、列、その他の参照オブジェクトの存在のチェックを行って SQL 文を実行計画に変換します。

EXECUTE Oracle によって行われる実際の文の実行です。INSERT文、UPDATE文お

よび DELETE文では、データの変更が行われます。SELECT文では、選択

された行が識別されます。

FETCH 問合せを満たす行を取得します。フェッチは、SELECT文についてのみ実

行されます。

表表表表 20-4 解析、実行およびフェッチの解析、実行およびフェッチの解析、実行およびフェッチの解析、実行およびフェッチの SQL トレース統計トレース統計トレース統計トレース統計

SQL トレース統計トレース統計トレース統計トレース統計 意味意味意味意味

COUNT 文が解析、実行またはフェッチされた回数です。

CPU 文に対するすべての解析コール、実行コールまたはフェッチ・コールにかかった CPU 時間の合計（単位は秒）です。TIMED_STATISTICSがオン

になっていない場合、この値は 0（ゼロ）になります。

ELAPSED 文に対するすべての解析コール、実行コールまたはフェッチ・コールにかかった経過時間の合計（単位は秒）です。TIMED_STATISTICSがオンに

なっていない場合、この値は 0（ゼロ）になります。

DISK すべての解析コール、実行コールまたはフェッチ・コールに対して、ディスク上のデータファイルから物理的に読み込んだデータ・ブロックの総数です。

アプリケーション・トレース・ツールの使用方法 20-17

SQL トレース機能と TKPROF の使用方法

処理された行に関する統計は、ROWS列に表示されます。表 20-5 を参照してください。

SELECT文の場合、戻された行数はフェッチ・ステップに表示されます。UPDATE文、DELETE文および INSERT文の場合、処理された行数は実行ステップに表示されます。

行ソースの操作行ソースの操作行ソースの操作行ソースの操作行ソースの操作では、行に対して実行される各操作で処理される行数と、物理読込みおよび書込みなど、行ソースの追加情報が提供されます。出力例は次のようになります。

Rows Row Source Operation------- --------------------------------------------------- 0 DELETE (cr=43141 r=266947 w=25854 time=60235565 us) 28144 HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us) 51427 TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us) 647529 INDEX FAST FULL SCAN STATS$SQL_SUMMARY_PK (cr=39592 r=39325 w=0 time=10522877 us) (object id 7409)

この例の TKPROF出力では、行ソースの操作の列で次の点に注意してください。

� crは、行ソースにより実行される読取り一貫性を指定します。

� rは、行ソースにより実行される物理読込みを指定します。

� wは、行ソースにより実行される物理書込みを指定します。

� timeは、時間をマイクロ秒単位で指定します。

QUERY すべての解析コール、実行コールまたはフェッチ・コールに対して、一貫モードで取り出されたバッファの総数です。通常バッファは問合せに対して一貫モードで取り出されます。

CURRENT 現行モードで取り出されたバッファの総数です。INSERT、UPDATE、DELETEなどの文では、バッファは現行モードで取り出されます。

表表表表 20-5 ROWS 列の列の列の列の SQL トレース統計トレース統計トレース統計トレース統計

SQL トレース統計トレース統計トレース統計トレース統計 意味意味意味意味

ROWS SQL 文によって処理された行の総数です。この値には、SQL 文の副問合

せによって処理された行は含まれません。

注意注意注意注意 : 行ソースの件数は、カーソルがクローズされたときに表示されます。SQL*Plus では、ユーザー・カーソルは 1 つしかないため、文が実行されるたびに直前のカーソルがクローズされます。これにより、行ソースの件数が表示されます。PL/SQL には、独自のカーソル処理方法があり、親カーソルがクローズされても子カーソルはクローズされません。終了

（または再接続）によって、件数が表示されます。

表表表表 20-4 解析、実行およびフェッチの解析、実行およびフェッチの解析、実行およびフェッチの解析、実行およびフェッチの SQL トレース統計（続き）トレース統計（続き）トレース統計（続き）トレース統計（続き）

SQL トレース統計トレース統計トレース統計トレース統計 意味意味意味意味

20-18 Oracle Database パフォーマンス・チューニング・ガイド

SQL トレース機能と TKPROF の使用方法

待機イベント情報待機イベント情報待機イベント情報待機イベント情報待機イベント情報が存在する場合、TKPROF出力には次のような項が含まれます。

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

さらに、ファイルの 後でトレース・ファイル全体について待機イベントが要約されます。

待機イベント情報がそのセッションのトレース・ファイルに確実に書き込まれるようにするには、次の 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 文の処理に必要なリソースの合計を計算するときは、その文自体の統計に加えて、その文を原因とする再帰的コールの統計もあわせて考慮する必要があります。

TKPROF のライブラリ・キャッシュ・ミスのライブラリ・キャッシュ・ミスのライブラリ・キャッシュ・ミスのライブラリ・キャッシュ・ミスTKPROFは、各 SQL 文の解析ステップと実行ステップの結果として生じるライブラリ・キャッシュ・ミス回数のリストも作成します。これらの統計は、表形式の統計に続く別の行に表示されます。文でライブラリ・キャッシュ・ミスが発生しなかった場合、TKPROFはその統計のリストを作成しません。 20-13 ページの「TKPROF の出力例」における解析ステップでは、ライブラリ・キャッシュ・ミスが 1 回発生し、実行ステップではライブラリ・キャッシュ・ミスは発生しませんでした。

注意注意注意注意 : 再帰的 SQL 統計は、SQL レベルの操作には組み込まれません。ただし、再帰的 SQL 統計は、トリガーなど SQL レベルより下の操作には組み込まれます。詳細は、20-26 ページの「トリガー・トラップの回避」を参照してください。

アプリケーション・トレース・ツールの使用方法 20-19

SQL トレース機能と TKPROF の使用方法

SQL トレースでの文の切捨てトレースでの文の切捨てトレースでの文の切捨てトレースでの文の切捨て次の SQL 文は、SQL トレース・ファイルでは 25 文字に切り捨てられます。

SET ROLEGRANTALTER USERALTER ROLECREATE USERCREATE ROLE

TKPROF でのでのでのでの SQL 文を発行するユーザーの識別文を発行するユーザーの識別文を発行するユーザーの識別文を発行するユーザーの識別TKPROFは、各 SQL 文を発行したユーザーのユーザー ID を出力します。SQL トレース入力ファイルが複数のユーザーからの統計を収録し、文が複数のユーザーによって発行された場合、TKPROFは文を解析した 後のユーザーの ID を出力します。すべてのデータベース・ユーザーのユーザー ID は、列 ALL_USERS.USER_IDのデータ・ディクショナリに表示されます。

TKPROF の実行計画の実行計画の実行計画の実行計画TKPROFのコマンドラインに EXPLAINパラメータを指定すると、TKPROFは EXPLAIN PLAN文を使用して、トレースされた SQL 文ごとに実行計画を生成します。TKPROFは実行計画の各ステップによって処理された行数も表示します。

チューニングする文の決定チューニングする文の決定チューニングする文の決定チューニングする文の決定CPU リソースまたはディスク・リソースを も消費する SQL 文を検出する必要があります。TIMED_STATISTICSパラメータがオンになっている場合は、CPU の高いアクティビティをCPU列で見つけられます。TIMED_STATISTICSがオンになっていない場合は、QUERY列とCURRENT列をチェックします。

ロックの問題と効率の悪い PL/SQL ループを除いて、問題の文を発見するためには CPU 時間と経過時間のどちらも必要ありません。重要なのは、問合せモード（すなわち、読取り一貫性の対象）と現行モード（読取り一貫性の非対象）の両方でアクセスするブロックの数です。セグメント・ヘッダーと更新されるブロックは現行モードで獲得されますが、すべての問合せ処理と副問合せ処理は問合せモードでデータを要求します。これらのメジャーは、インスタンス統計 CONSISTENT GETSおよび DB BLOCK GETSとまったく同じです。高ディスク・アクティビティはディスク列で見つけられます。

注意注意注意注意 : インスタンスの始動直後に生成されたトレース・ファイルは、スタートアップ・プロセスのアクティビティを反映するデータを含みます。特に、これらは、システム・グローバル領域（SGA）のキャッシュがいっぱいになったときの不均衡な量の I/O アクティビティを反映します。チューニングを行うときには、このようなトレース・ファイルは無視してください。

関連項目関連項目関連項目関連項目 : 実行計画の解釈に関する詳細は、第 19 章「EXPLAIN PLANの使用方法」を参照してください。

関連項目関連項目関連項目関連項目 : リソースを消費する文の検索例は、20-16 ページの「TKPROF文の例」を参照してください。

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 0Execute 11 0.23 0.66 0 3 6 0Fetch 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 SQL 文が発行された再帰レベルを示します。たとえば、値 0 はユー

ザーがその文を発行したことを示します。値 1 は、Oracle が値 0 の文

（ユーザー発行の文）を処理するための再帰的コールとして、その文を生成したことを示します。値 n は、Oracle がその文を値 n-1 の文を処

理する再帰的コールとして生成したことを示します。

USER_ID この文を発行するユーザーを識別します。この値はフォーマットした出力ファイルにも出力されます。

CURSOR_NUM この列の値は、各 SQL 文が割り当てられているカーソルを追跡して記

録するために Oracle が使用します。

20-22 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_idFROM cq_names WHERE name = 'FLOOR';

call count cpu elapsed disk query current rows---- ----- --- ------- ---- ----- ------- ----Parse 1 0.10 0.18 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 1 0.11 0.21 2 101 0 1

Misses in library cache during parse: 1Parsing user id: 01 (USER1)

Rows Execution Plan---- --------- ---- 0 SELECT STATEMENT 1 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES' 2 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON_UNIQUE)

スキーマ・トラップの回避スキーマ・トラップの回避スキーマ・トラップの回避スキーマ・トラップの回避この例は極端な場合を示しているので、スキーマ・トラップは容易に検出できます。 初は、明らかに単純に索引付けされた問合せが多くのデータベース・ブロックを検索する必要がある理由、または現行モードでブロックにアクセスすることが必要な理由を理解することは困難です。

SELECT name_idFROM cq_names WHERE name = 'FLOOR';

call count cpu elapsed disk query current rows-------- ------- -------- --------- ------- ------ ------- ----Parse 1 0.06 0.10 0 0 0 0Execute 1 0.02 0.02 0 0 0 0 Fetch 1 0.23 0.30 31 31 3 1

Misses in library cache during parse: 0Parsing user id: 02 (USER2)

Rows Execution Plan------- --------------------------------------------------- 0 SELECT STATEMENT 2340 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES' 0 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)

20-24 Oracle Database パフォーマンス・チューニング・ガイド

TKPROF の解釈における誤りの回避

2 つの統計は、問合せが全表スキャンを使用して実行された可能性があることを示しています。これらの統計は、現行モードでのブロック・アクセスと、実行計画の Table Access 行ソースに由来する行数です。これは、トレース・ファイルが生成された後、TKPROFが実行される前に、必要な索引が構築されたことを示しています。

新規トレース・ファイルを生成すると次のデータが与えられます。

SELECT name_idFROM cq_names WHERE name = 'FLOOR';

call count cpu elapsed disk query current rows----- ------ ------ -------- ----- ------ ------- -----Parse 1 0.01 0.02 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 1 0.00 0.00 0 2 0 1

Misses in library cache during parse: 0Parsing user id: 02 (USER2)

Rows Execution Plan------- --------------------------------------------------- 0 SELECT STATEMENT 1 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES' 2 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 cpu elapsed disk query current rows-------- ------- -------- --------- -------- -------- ------- ----------Parse 1 0.06 0.24 0 0 0 0Execute 1 0.62 19.62 22 526 12 7Fetch 0 0.00 0.00 0 0 0 0

Misses in library cache during parse: 1Parsing 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.trcSort options: default

********************************************************************************count = number of times OCI procedure was executedcpu = cpu time in seconds executing elapsed = elapsed time in seconds executingdisk = number of physical reads of buffers from diskquery = number of buffers gotten for consistent readcurrent = number of buffers gotten in current mode (usually for update)rows = number of rows processed by the fetch or execute call********************************************************************************

TKPROF 本体のサンプル本体のサンプル本体のサンプル本体のサンプルcall count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.01 0.00 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 0 0.00 0.00 0 0 0 0------- ------ -------- ---------- ---------- ---------- ---------- ----------total 2 0.01 0.00 0 0 0 0

Misses in library cache during parse: 1Optimizer mode: FIRST_ROWSParsing 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 cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 1 0.00 0.00 0 2 0 1------- ------ -------- ---------- ---------- ---------- ---------- ----------total 3 0.00 0.00 0 2 0 1

Misses in library cache during parse: 1Optimizer mode: CHOOSEParsing user id: SYS (recursive depth: 1)

Rows Row Source Operation------- --------------------------------------------------- 1 TABLE ACCESS BY USER ROWID OBJ#(31) (cr=1 r=0 w=0 time=151 us)

********************************************************************************

SELECT last_name, job_id, salary FROM employeesWHERE salary = (SELECT max(salary) FROM employees)

call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.02 0.01 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 2 0.00 0.00 0 15 0 1------- ------ -------- ---------- ---------- ---------- ---------- ----------total 4 0.02 0.01 0 15 0 1

Misses in library cache during parse: 1Optimizer mode: FIRST_ROWSParsing user id: 44

Rows Row Source Operation------- --------------------------------------------------- 1 TABLE ACCESS FULL EMPLOYEES (cr=15 r=0 w=0 time=1743 us) 1 SORT AGGREGATE (cr=7 r=0 w=0 time=777 us) 107 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 cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 29.60 60.68 266984 43776 131172 28144Fetch 0 0.00 0.00 0 0 0 0------- ------ -------- ---------- ---------- ---------- ---------- ----------total 2 29.60 60.68 266984 43776 131172 28144

Misses in library cache during parse: 1Misses in library cache during execute: 1Optimizer mode: CHOOSEParsing user id: 22

Rows Row Source Operation------- --------------------------------------------------- 0 DELETE (cr=43141 r=266947 w=25854 time=60235565 us) 28144 HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us) 51427 TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us) 647529 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 cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 4 0.04 0.01 0 0 0 0Execute 5 0.00 0.04 0 0 0 0Fetch 2 0.00 0.00 0 15 0 1------- ------ -------- ---------- ---------- ---------- ---------- ----------total 11 0.04 0.06 0 15 0 1

Misses in library cache during parse: 4Misses in library cache during execute: 1Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 6 0.00 0.00 SQL*Net message from client 5 77.77 128.88

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

20-28 Oracle Database パフォーマンス・チューニング・ガイド

TKPROF の出力例

call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 1 0.00 0.00 0 2 0 1------- ------ -------- ---------- ---------- ---------- ---------- ----------total 3 0.00 0.00 0 2 0 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.trcTrace file compatibility: 9.00.01Sort 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 によりテスト・システム上で実行されます。そのために、取得されたすべての外部クライアント要求が、本番システムと同じタイミング、同時実行性およびトランザクション依存性を使用して再作成されます。

データベース・リプレイでは、リプレイ・クライアントと呼ばれるクライアント・プログラムを使用して、ワークロードの取得中に記録された外部クライアント要求がすべて再作成されます。 取得されたワークロードによっては、正常にリプレイするために 1 つ以上のリプレイ・クライアントが必要になる場合があります。 特定のワークロードに必要なリプレイ・クライアントの数を判別できるように、測定ツールが用意されています。 DML および SQL 問合せを含めてワークロード全体がリプレイされるため、リプレイ・システム内のデータは取得システム上のデータと論理的に類似している必要があります。これにより、データの相違が 小限になり、信頼性の高いリプレイ分析が可能になります。

関連項目関連項目関連項目関連項目 : 取得されたワークロードの前処理の詳細は、『Oracle Database パフォーマンス・チューニング・ガイド 11g リリース 1（11.1）』を参照してください。

関連項目関連項目関連項目関連項目 : 取得されたワークロードのリプレイの詳細は、『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）に手動で指定する必要があります。

データベース・ワークロードの取得の前提条件データベース・ワークロードの取得の前提条件データベース・ワークロードの取得の前提条件データベース・ワークロードの取得の前提条件ワークロードの取得を開始する前に、テスト・システム上でデータベースをリストアするための計画を作成する必要があります。 ワークロードをリプレイする前に、リプレイ・システム上のアプリケーション・データを、リプレイ開始時の取得システムと同じ状態にする必要があります。 そのためには、次の方法のいずれかを使用することを検討してください。

� Recovery Manager（RMAN）の DUPLICATEコマンド

� スナップショット・スタンバイ

� データ・ポンプのインポートとエクスポート

これにより、リプレイ・システム上のデータベースを、ワークロードの取得開始時点でのアプリケーションの状態にリストアできます。

注意注意注意注意 : PRE_11G_ENABLE_CAPTURE初期化パラメータを使用できるのは、Oracle Database 10g リリース 2（10.2）のみです。 以降のリリースでは、このパラメータは無効です。 データベースのアップグレード後は、このパラメータをサーバー・パラメータ・ファイル（SPFILE）または初期化パラメータ・ファイル（init.ora）から削除する必要があります。削除しないと、データベースを起動できません。

関連項目関連項目関連項目関連項目 : PRE_11G_ENABLE_CAPTURE初期化パラメータの詳細は、『Oracle Database リファレンス』を参照してください。

関連項目関連項目関連項目関連項目 :

� RMAN を使用したデータベースの複製の詳細は、『Oracle Database バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

� スナップショット・スタンバイ・データベースの管理については、『Oracle Data Guard 概要および管理』を参照してください。

� データ・ポンプの使用方法は、『Oracle Database ユーティリティ』を参照してください。

データベース・リプレイ 21-5

データベース・ワークロードの取得

ワークロードの取得オプションワークロードの取得オプションワークロードの取得オプションワークロードの取得オプション取得が正確で、別の環境でリプレイしたときに役立つように、ワークロードの取得前に適切に計画しておく必要があります。

データベース・ワークロードを取得する前に、次のオプションを慎重に検討してください。

� データベースの再起動

� ワークロード・フィルタの定義

� 取得ディレクトリの設定

データベースの再起動データベースの再起動データベースの再起動データベースの再起動このステップはオプションですが、実行中のトランザクションや依存トランザクションを取得開始前に確実に完了またはロールバックできるように、ワークロードの取得前にデータベースを再起動することをお薦めします。 取得開始前にデータベースを再起動しないと、実行中だったトランザクションや、まだコミットされていなかったトランザクションがワークロードに完全に取得されません。 したがって、実行中のトランザクションは正しくリプレイされません。これは、トランザクションのうちコールが取得された部分のみがリプレイされるためです。 その結果、ワークロードをリプレイすると、データに望ましくない相違が発生する可能性があります。 未完了トランザクションに依存する以降のトランザクションでも、リプレイ中にエラーが生成される可能性があります。

データベースを再起動する前に、 小限の中断でワークロード取得期間前に本番データベースを停止する適切な時期を判断します。 たとえば、午前 8 時から始まるワークロードを取得する必要があるとします。ただし、通常の業務時間中のサービス中断を回避するために、この時刻にはデータベースを再起動しないようにします。 この場合は、中断期間が短くなる時刻にデータベースを再起動できるように、ワークロードの取得開始時刻を早めることを検討する必要があります。

データベースの再起動後は、ユーザー・セッションが再接続されてワークロードの発行が開始される前に、ワークロードの取得を開始することが重要です。 このようにしないと、これらのユーザー・セッションにより実行されるトランザクションは、以降のデータベース・リプレイで正常にリプレイされません。これは、トランザクションのうち、ワークロードの取得開始後にコールが実行された部分のみがリプレイされるためです。 この問題を回避するために、STARTUP_RESTRICTEDを使用してデータベースを RESTRICTEDモードで再起動することを検討してください。これにより、SYS ユーザーのみがログインとワークロードの取得開始を許可されます。 デフォルトでは、ワークロードの取得が始まると、RESTRICTEDモードのデータベース・インスタンスが自動的に UNRESTRICTEDモードに切り替わり、ワークロードの取得中に通常の操作を継続できるようになります。

1 回に実行できるワークロードの取得は、1 つのみです。 Oracle Real Application Clusters（RAC）の場合、ワークロードの取得はデータベース全体に対して実行されます。 ワークロードの取得開始前にクリーンな状態を有効化するには、すべてのインスタンスを再起動する必要があります。 そのためには、次の手順を実行できます。

1. すべてのインスタンスを停止します。

2. インスタンスの 1 つを再起動します。

3. ワークロードの取得を開始します。

4. 残りのインスタンスを再起動します。

関連項目関連項目関連項目関連項目 : 起動時のインスタンスへのアクセスを制限する方法は、『Oracle Database 管理者ガイド』を参照してください。

21-6 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 データのエクスポート

ワークロード・フィルタの追加と削除ワークロード・フィルタの追加と削除ワークロード・フィルタの追加と削除ワークロード・フィルタの追加と削除この項では、ワークロード・フィルタを追加および削除する方法について説明します。 ワークロード・フィルタの使用方法は、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を使用しています。

関連項目関連項目関連項目関連項目 : 『Oracle Database PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』

データベース・リプレイ 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 Enterprise Manager です。 なんらかの理由で Oracle Enterprise Manager を使用できない場合は、API を使用してワークロードの取得レポートを生成できます。

この項では、次の項目について説明します。

� Enterprise Manager を使用したワークロードの取得レポートの生成

� API を使用したワークロードの取得レポートの生成

� ワークロードの取得レポートの使用

Enterprise Manager を使用したワークロードの取得レポートの生成を使用したワークロードの取得レポートの生成を使用したワークロードの取得レポートの生成を使用したワークロードの取得レポートの生成ワークロードの取得レポートには、取得されたワークロードの統計、取得された上位セッション・アクティビティに関する情報、および取得プロセス中に使用されたワークロード・フィルタが含まれています。

Enterprise Manager を使用してワークロードの取得レポートを生成する手順は、次のとおりです。

1. 「管理」ページで、「Real Application Testing」の下にある「データベース・リプレイ」「データベース・リプレイ」「データベース・リプレイ」「データベース・リプレイ」をクリックします。

「データベース・リプレイ」ページが表示されます。

2. 「ワークロードの取得履歴の表示」「ワークロードの取得履歴の表示」「ワークロードの取得履歴の表示」「ワークロードの取得履歴の表示」をクリックします。

「ワークロードの取得履歴の表示」ページが表示されます。

関連項目関連項目関連項目関連項目 : これらのビューについては、『Oracle Database リファレンス』を参照してください。

データベース・リプレイ 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 パフォーマンス・チューニング・ガイド

SQL パフォーマンス・ア

22

SQL パフォーマンス・アナライザパフォーマンス・アナライザパフォーマンス・アナライザパフォーマンス・アナライザ

データベースのアップグレードや新規索引の追加など、SQL 実行計画に影響するシステム変更は、SQL のパフォーマンスに重大な影響を及ぼす可能性があります。 その結果、DBA は変更が原因で低下した SQL 文の識別と修正に長時間費やすことになります。

SQL パフォーマンス・アナライザは、それぞれの文のパフォーマンスの相違を識別することで、変更が SQL ワークロード全体に及ぼす影響の評価プロセスを自動化します。 変更がワークロード・パフォーマンスに及ぼす 終的な影響を示すレポートが提供されます。 また、低下した SQL 文については、チューニング推奨とともに適切な実行計画詳細も提供されます。 その結果、DBA はエンド・ユーザーが影響を受ける前に望ましくない結果を処置し、本番環境に対するシステム変更が 終的な改善をもたらすかどうかを検証できます。これにより、大幅に時間を短縮してコストを削減できます。

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

索引索引索引索引

AActive Session History，5-4addmrpt.sql

Automatic Database Diagnostic Monitor，6-6ALL_OUTLINE_HINTS ビュー

ストアド・アウトライン・ヒント，18-6ALL_OUTLINES ビュー

ストアド・アウトライン，18-6ALL_ROWS ヒント，13-4ALTER INDEX 文，15-5ALTER SESSION 文

SET SESSION_CACHED_CURSORS 句，7-30例，20-12

ANALYZE 文，14-5Automatic Database Diagnostic Monitor，1-5，6-2，11-5

addmrpt.sql レポート，6-6API を使用した実行，6-7DB time，6-3DBIO_EXPECTED，6-5DBMS_ADVISOR パッケージ，6-7STATISTICS_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

Bbuffer busy waits イベント，10-12，10-18

処置，10-18BYTES 列

PLAN_TABLE 表，19-19B ツリー索引，2-11

CCARDINALITY 列

PLAN_TABLE 表，19-19COMPATIBLE 初期化パラメータ，4-2consistent gets from cache 統計，7-8CONTROL_FILES 初期化パラメータ，4-2COST 列

PLAN_TABLE 表，19-19CPU，2-6

使用率，9-8統計，5-5

CPU 統計，10-4CREATE INDEX 文

PARALLEL 句，4-7CREATE OUTLINE 文，18-4CREATE_STORED_OUTLINES 初期化パラメータ，

18-4，18-5CREATE_STORED_OUTLINES パラメータ，18-4CURSOR_NUM 列

TKPROF_TABLE 表，20-22CURSOR_SHARING 初期化パラメータ，7-19，7-33，

13-6CURSOR_SPACE_FOR_TIME 初期化パラメータ

設定，7-29

DDatabase Resource Manager，9-4，9-7，10-4DATE_OF_INSERT 列

TKPROF_TABLE 表，20-22db block gets from cache 統計，7-8db file scattered read 待機イベント，10-12，10-19

処置，10-19，10-21db file sequential read 待機イベント，10-12，10-19，

10-21処置，10-21

DB time測定値，6-3統計，5-3

DB_BLOCK_SIZE 初期化パラメータ，4-3，8-4DB_CACHE_ADVICE パラメータ，7-10DB_CACHE_SIZE 初期化パラメータ，7-10，7-11DB_DOMAIN 初期化パラメータ，4-2DB_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-2DB_nK_CACHE_SIZE 初期化パラメータ，7-10DB_RECYCLE_CACHE_SIZE

初期化パラメータ，7-15DB_WRITER_PROCESSES 初期化パラメータ，10-26DBA_HIST_WR_CONTROL ビュー

自動ワークロード・リポジトリ設定，5-11DBA_HIST ビュー，5-15DBA_OBJECTS ビュー，7-13DBA_OUTLINE_HINTS ビュー

ストアド・アウトライン・ヒント，18-6DBA_OUTLINES ビュー

ストアド・アウトライン，18-6DBIO_EXPECTED パラメータ，6-5DBMS_ADDM パッケージ

Automatic Database Diagnostic Monitor，6-6DBMS_ADVISOR パッケージ，17-2

ADDM 用の設定，6-5Automatic Database Diagnostic Monitor，6-6，6-7DBIO_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-10SQL チューニング・セット，12-10SQL プロファイル，12-13

DBMS_STATS パッケージ，14-5，17-3収集プロシージャのサンプル・サイズの手動決定，

14-6問合せオプティマイザ統計の管理，13-5，14-2

DBMS_WORKLOAD_REPOSITORY パッケージ

自動ワークロード・リポジトリの管理，5-10，5-12DBMS_XPLAN パッケージ

PLAN TABLE 出力の表示，19-6DEPTH 列

TKPROF_TABLE 表，20-22direct path

read イベント，10-22read イベントの原因，10-22read イベントの処置，10-22write イベントの原因，10-23write イベントの処置，10-23待機イベント，10-23

DISTRIBUTION 列

PLAN_TABLE 表，19-20

EEnd to End Application Tracing，20-1，20-2

DBMS_APPLICATION_INFO パッケージ，20-2DBMS_MONITOR パッケージ，20-2アクション名とモジュール名，2-15，20-2サービスの作成，20-2

enqueue 待機イベント，10-12，10-23処置，10-24統計，10-8

EXECUTE_TASK プロシージャ，17-19EXPLAIN PLAN 文

PLAN_TABLE 表，19-4TKPROF プログラムでの起動，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-34Export Utility

システム生成の列名の統計，14-12EXTENT MANAGEMENT LOCAL

一時表領域の作成，4-5

FFILESYSTEMIO_OPTIONS 初期化パラメータ，9-3FIRST_ROWS(n) ヒント，13-4free buffer waits イベント，10-12，10-26FULL ヒント，15-5

GGATHER_DATABASE_STATS_JOB_PROC プロシージャ

オプティマイザ統計を自動的に収集，14-3メンテナンス・ウィンドウでの

GATHER_STATS_JOB，14-3GATHER_DATABASE_STATS プロシージャ

DBMS_STATS パッケージ，14-6GATHER_DICTIONARY_STATS プロシージャ

DBMS_STATS パッケージ，14-6GATHER_INDEX_STATS プロシージャ

DBMS_STATS パッケージ，14-6GATHER_SCHEMA_STATS プロシージャ

DBMS_STATS パッケージ，14-6GATHER_STATS_JOB

オプティマイザ統計を自動的に収集，14-3GATHER_TABLE_STATS プロシージャ

DBMS_STATS パッケージ，14-6GETMISSES 列

V$ROWCACHE 表，7-25GETS 列

V$ROWCACHE ビュー，7-25GV$BUFFER_POOL_STATISTICS ビュー，7-12

HHOLD_CURSOR 句，7-20HW エンキュー

競合，10-24

索引索引索引索引 -2

IID 列

PLAN_TABLE 表，19-19Import Utility

統計のコピー，14-12INDEX_COMBINE ヒント，15-5INDEX_FFS ヒント，13-20INDEX_JOIN ヒント，13-20indexspec

ヒント構文，16-9INDEX ヒント，15-5INLIST，19-16INLIST ITERATOR 操作，19-16I/O

I/O 待機を発生させるオブジェクト，10-20SQL 文，10-20過剰な I/O 待機，10-19監視，10-4競合，5-3，10-4，10-6，10-19，10-32低減，15-4

IOT（索引構成表），2-11

KKEEP キャッシュ，7-11KEEP バッファ・プール，7-14

LLARGE_POOL_SIZE 初期化パラメータ，7-27latch free 待機イベント，10-12

処置，10-28log file

parallel write 待機イベント，10-31switch 待機イベント，10-32sync 待機イベント，10-12，10-33

LOG_BUFFER 初期化パラメータ，7-34設定，7-35

LRU除去方針，7-11ラッチの競合，10-31

MMAX_DISPATCHERS 初期化パラメータ，4-9MAX_DUMP_FILE_SIZE 初期化パラメータ

SQL トレース，20-10MAXOPENCURSORS 句，7-20

NNAMESPACE 列

V$LIBRARYCACHE ビュー，7-22NO_INDEX ヒント，15-5NOT IN 副問合せ，13-23

OOBJECT_INSTANCE 列

PLAN_TABLE 表，19-19OBJECT_NAME 列

PLAN_TABLE 表，19-18

OBJECT_NODE 列PLAN_TABLE 表，19-18

OBJECT_OWNER 列

PLAN_TABLE 表，19-18OBJECT_TYPE 列

PLAN_TABLE 表，19-19OLAP_PAGE_POOL_SIZE 初期化パラメータ，7-48OPEN_CURSORS 初期化パラメータ，4-2

各セッションのカーソル数の増加，7-25OPERATION 列

PLAN_TABLE 表，19-18，19-21OPTIMIZER_DYNAMIC_SAMPLING 初期化パラ

メータ，14-14OPTIMIZER_FEATURES_ENABLE 初期化パラメータ，

13-5，13-20OPTIMIZER_INDEX_CACHING 初期化パラメータ，

13-6OPTIMIZER_INDEX_COST_ADJ 初期化パラメータ，

13-6OPTIMIZER_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-4Oracle Enterprise Manager

SQL アクセス・アドバイザへのアクセス，11-5アドバイザ，1-6

「パフォーマンス」ページ，1-6Oracle Forms，20-12

解析とプライベート SQL 領域の制御，7-21Oracle Managed Files，8-8

チューニング，8-8Oracle のパフォーマンス改善方法，3-2

手順，3-3ORDERED ヒント，13-23OTHER_TAG 列

PLAN_TABLE 表，19-19OTHER 列

PLAN_TABLE 表，19-20

PPARALLEL 句

CREATE INDEX 文，4-7PARENT_ID 列

PLAN_TABLE 表，19-19PARTITION_ID 列

PLAN_TABLE 表，19-20PARTITION_START 列

PLAN_TABLE 表，19-20PARTITION_STOP 列

PLAN_TABLE 表，19-20PCTFREE パラメータ，4-6，10-14PCTUSED パラメータ，10-14PGA_AGGREGATE_TARGET 初期化パラメータ，4-3，

4-7，7-37，9-3，13-7physical reads from cache 統計，7-8

索引索引索引索引 -3

PLAN_TABLE 表BYTES 列，19-19CARDINALITY 列，19-19COST 列，19-19DISTRIBUTION 列，19-20ID 列，19-19OBJECT_INSTANCE 列，19-19OBJECT_NAME 列，19-18OBJECT_NODE 列，19-18OBJECT_OWNER 列，19-18OBJECT_TYPE 列，19-19OPERATION 列，19-18OPTIMIZER 列，19-19OPTIONS 列，19-18OTHER_TAG 列，19-19OTHER 列，19-20PARENT_ID 列，19-19PARTITION_ID 列，19-20PARTITION_START 列，19-20PARTITION_STOP 列，19-20POSITION 列，19-19REMARKS 列，19-18SEARCH_COLUMNS 列，19-19STATEMENT_ID 列，19-18TIMESTAMP 列，19-18作成，19-4表示，19-6

PL/SQL プロシージャ

EXPLAIN_MVIEW，17-34TUNE_MVIEW，17-34

POSITION 列

PLAN_TABLE 表，19-19PRIMARY KEY 制約，15-6PRIVATE_SGA 変数，7-28PROCESSES 初期化パラメータ，4-3

Rrdbms ipc reply 待機イベント，10-33read 待機イベント

direct path，10-22scattered，10-19

REBUILD 句，15-5RECYCLE キャッシュ，7-11REDO BUFFER ALLOCATION RETRIES 統計，7-35REDO ログ，4-4

サイズ設定，4-4ディスク上の配置，8-6バッファ・サイズ，10-32ミラー化，8-7領域要求，10-13

REDO ログのサイズ設定，4-4RELEASE_CURSOR 句，7-20REMARKS 列

PLAN_TABLE 表，19-18ROWID

表アクセス，13-16

SSAMPLE BLOCK 句，13-21

アクセス・パスおよびヒント，13-22SAMPLE 句，13-21

アクセス・パスおよびヒントによる上書き不可，13-22

sar UNIX コマンド，9-9SEARCH_COLUMNS 列

PLAN_TABLE 表，19-19SELECT 文

SAMPLE 句，13-21sequential read 待機イベント

処置，10-21SESSION_CACHED_CURSORS 初期化パラメータ，7-29SESSIONS 初期化パラメータ，4-3SGA_TARGET 初期化パラメータ，4-3

自動共有メモリー管理，7-2自動メモリー管理，7-2

SGA サイズ，7-35SHARED_POOL_RESERVED_SIZE 初期化パラメータ，

7-31SHARED_POOL_SIZE 初期化パラメータ，7-26，7-31

共有プールのチューニング，7-28ライブラリ・キャッシュの割当て，7-25

SHOW SGA 文，7-5SQL*Net

message from client アイドル・イベント，10-16message from dblink 待機イベント，10-17more data to client 待機イベント，10-17

SQL_STATEMENT 列

TKPROF_TABLE，20-22SQL_TRACE

初期化パラメータ，20-12SQLTUNE_CATEGORY 初期化パラメータ

SQL プロファイルのカテゴリの判別，12-3SQL アクセス・アドバイザ，1-5，11-5，17-2，17-8

EXECUTE_TASK プロシージャ，17-19Oracle 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-16SQL チューニング・アドバイザ，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

索引索引索引索引 -4

SQL トレース機能，20-8，20-13実行手順，20-10出力，20-17出力の例，20-21トレース・ファイル，20-11文の切捨て，20-20

SQL パフォーマンス・アナライザ

SQL ワークロードの取得，22-3SQL プロファイル

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-23STAR_TRANSFORMATION_ENABLED 初期化パラ

メータ，13-7STATEMENT_ID 列

PLAN_TABLE 表，19-18STATISTICS_LEVEL 初期化パラメータ，5-7，10-5

Automatic Database Diagnostic Monitor の有効化，6-5

自動ワークロード・リポジトリ，5-8統計収集用の設定，1-5

STREAMS_POOL_SIZE 初期化パラメータ，4-3，7-3ST エンキュー

競合，10-24

Ttablespec

ヒント構文，16-8TIMED_STATISTICS 初期化パラメータ

SQL トレース，20-10TIMESTAMP 列

PLAN_TABLE 表，19-18TKPROF_TABLE，20-22

問合せ，20-22TKPROF プログラム，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-7TUNE_MVIEW プロシージャ，17-34TX エンキュー

競合，10-25

UUNDO TABLESPACE 句，4-3UNDO_MANAGEMENT 初期化パラメータ，4-3UNDO_TABLESPACE 初期化パラメータ，4-3UNDO 管理

自動モード，4-3UNIX システム・パフォーマンス，9-5USE_STORED_OUTLINES パラメータ，18-5USER_DUMP_DEST 初期化パラメータ，20-11

SQL トレース，20-11USER_ID 列

TKPROF_TABLE，20-22USER_OUTLINE_HINTS ビュー

ストアド・アウトライン・ヒント，18-6USER_OUTLINES ビュー

ストアド・アウトライン，18-6UTLCHN1.SQL スクリプト，10-14UTLXPLP.SQL スクリプト

EXPLAIN PLAN の表示用，13-12PLAN TABLE 出力の表示，19-6

UTLXPLS.SQL スクリプト

EXPLAIN PLAN の表示に使用，13-12EXPLAIN PLAN の表示用，13-12PLAN TABLE 出力の表示，19-6

VV$ACTIVE_SESSION_HISTORY ビュー，5-4，10-6V$ADVISOR_PROGRESS ビュー，12-8，12-15V$BH ビュー，7-13V$BUFFER_POOL_STATISTICS ビュー，7-12V$DB_CACHE_ADVICE ビュー，7-6，7-8，7-9，7-10，

7-12V$EVENT_HISTOGRAM ビュー，10-7V$FILE_HISTOGRAM ビュー，10-7V$JAVA_LIBRARY_CACHE_MEMORY ビュー，7-23V$JAVA_POOL_ADVICE ビュー，7-23V$LIBRARY_CACHE_MEMORY ビュー，7-23V$LIBRARYCACHE ビュー

NAMESPACE 列，7-22V$OSSTAT ビュー，5-5V$PGASTAT ビュー，7-38V$PROCESS_MEMORY ビュー，7-40V$PROCESS ビュー，7-40V$QUEUE ビュー，4-10V$ROWCACHE ビュー

GETMISSES 列，7-25GETS 列，7-25パフォーマンス統計，7-24

V$RSRC_CONSUMER_GROUP ビュー，10-4V$SESS_TIME_MODEL ビュー，5-3，10-6V$SESSION_EVENT ビュー，10-7，10-15V$SESSION_WAIT_CLASS ビュー，10-7V$SESSION_WAIT_HISTORY ビュー，10-7V$SESSION_WAIT ビュー，10-7，10-15V$SESSION ビュー，10-7，10-8，10-15V$SESSTAT ビュー，10-4

使用，7-27V$SHARED_POOL_ADVICE ビュー，7-23V$SHARED_POOL_RESERVED ビュー，7-31V$SQL_PLAN_STATISTICS_ALL ビュー

実行計画情報の表示に使用，19-4

索引索引索引索引 -5

V$SQL_PLAN_STATISTICS ビュー実行計画の統計表示に使用，19-3

V$SQL_PLAN ビュー

実行計画の表示に使用，19-3V$SQL_WORKAREA_ACTIVE ビュー，7-42V$SQL_WORKAREA_HISTOGRAM ビュー，7-40V$SQL_WORKAREA ビュー，7-42V$SYS_TIME_MODEL ビュー，5-3，5-5，10-6V$SYSMETRIC_HISTORY ビュー，5-5V$SYSSTAT ビュー

REDO バッファ割当て，7-35使用，7-8

V$SYSTEM_EVENT ビュー，10-7，10-15V$SYSTEM_WAIT_CLASS ビュー，10-7V$TEMP_HISTOGRAM ビュー，10-7V$UNDOSTAT ビュー，4-4V$WAITSTAT ビュー，10-8vmstat UNIX コマンド，9-9

WWindows のパフォーマンス，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

一貫性読取り，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-21Oracle プリコンパイラ，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

索引索引索引索引 -6

型変換，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-11I/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-6CPU，2-6I/O サブシステム，2-6ネットワーク，2-6メモリー，2-6

システム・グローバル領域のチューニング，7-5実行計画

TKPROF，20-13，20-15utlxpls.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-12DBA_HIST_WR_CONTROL ビューで設定，5-11DBMS_WORKLOAD_REPOSITORY パッケージ，

5-10，5-12概要，5-8自動スナップショット収集をオフに設定，5-9収集される統計，5-8データの収集，5-2データへのアクセスに使用するビュー，5-15

デフォルト設定，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-2DB_BLOCK_SIZE，4-3DB_DOMAIN，4-2DB_FILE_MULTIBLOCK_READ_COUNT，13-23DB_NAME，4-2OPEN_CURSORS，4-2OPTIMIZER_DYNAMIC_SAMPLING，14-14OPTIMIZER_FEATURES_ENABLE，13-20OPTIMIZER_MODE，13-4，16-3PGA_AGGREGATE_TARGET，4-7PROCESSES，4-3SESSION_CACHED_CURSORS，7-29SESSIONS，4-3SQL_TRACE，20-12STREAMS_POOL_SIZE，4-3，7-3USER_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

索引索引索引索引 -8

せせせせ制約，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-18direct path，10-23enqueue，10-23free buffer waits，10-26log buffer space，10-32log file parallel write，10-31log file switch，10-32log file sync，10-33rdbms 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-8db block gets from cache，7-8DBMS_STATS パッケージでの収集，14-5DBMS_STATS プロシージャによる収集，14-5GATHER_STATS_JOB，14-3physical reads from cache，7-8STATISTICS_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-16db file scattered read 待機イベント，10-19db file sequential read 待機イベント，10-19，10-21SQL*Net message from dblink，10-17SQL*Net more data to client，10-17

ははははパーティション・オブジェクト

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-2DBMS_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-14KEEP キャッシュ，7-11RECYCLE キャッシュ，7-11デフォルト・キャッシュ，7-11ヒット率，7-12複数，7-11

パフォーマンスUNIX ベース・システム，9-5Windows，9-5Windows でのメモリーの監視，9-9改善方法，3-2改善方法の手順，3-3緊急事態，3-7実行計画の表示，13-11診断およびチューニング用のツール，1-5メインフレーム，9-5

パフォーマンスの緊急の問題に対処する方法，3-7

索引索引索引索引 -10

ひひひひビジネス・ロジック，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-13DBA_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-5INDEX_FFS，13-20INDEX_JOIN，13-20indexspec 構文，16-9NO_INDEX，15-5ORDERED ヒント，13-23tablespec 構文，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

ふふふふファンクション索引，2-12，15-7複合索引，15-4複数バッファ・プール，7-11副問合せ

NOT IN，13-23ネスト解除，11-14

プラン・スタビリティ，18-2コストベース・オプティマイザのプロシージャ，18-8実行計画の保存，18-2

制限事項，18-2ヒントの使用，18-2

プリコンパイラ

解析とプライベート SQL 領域の制御，7-20フル・パーティション・ワイズ結合，19-16プロアクティブな監視，1-3ブロードキャスト

分散値，19-21プログラミング言語，2-14プログラム・グローバル領域（PGA）

direct path read，10-22direct 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-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-12EXPLAIN PLAN 出力，20-21SQL トレース機能の出力，20-21

列索引付け，15-3

列の順序索引，2-12

連鎖行，10-14

レンジパーティション，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

索引索引索引索引 -12