Oracle® Database

パフォーマンス・チューニング・ガイド

11gリリース2(11.2)

B56312-06(原本部品番号:E41573-04)

2014年6月

Oracle Databaseパフォーマンス・チューニング・ガイド, 11gリリース2(11.2)

B56312-06

Copyright © 2000, 2014, Oracle and/or its affiliates.All rights reserved.

原本著者: Immanuel Chan、Lance Ashdown

原本協力者: Aditya Agrawal、Hermann Baer、Vladimir Barriere、Mehul Bastawala、Eric Belden、Pete Belknap、Supiti Buranawatanachoke、Sunil Chakkappen、Maria Colgan、Benoit Dageville、Dinesh Das、Karl Dias、Kurt Engeleiter、Marcus Fallen、Mike Feng、Leonidas Galanis、Ray Glasstone、Prabhaker Gongloor、Kiran Goyal、Cecilia Grant、Connie Dialeris Green、Shivani Gupta、Karl Haas、Bill Hodak、Andrew Holdsworth、Hakan Jacobsson、Shantanu Joshi、Ameet Kini、Sergey Koltakov、Vivekanada Kolla、Paul Lane、Sue K.Lee、Herve Lejeune、Ilya Listvinsky、Bryn Llewellyn、George Lumpkin、Mughees Minhas、Gary Ngai、Mark Ramacher、Yair Sarig、Uri Shaft、Vishwanath Sreeraman、Vinay Srihari、Randy Urbano、Amir Valiani、Venkateshwaran Venkataramani、Yujun Wang、Graham Wood、Khaled Yagoub、Mohamed Zait、Mohamed Ziauddin

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

『Oracle Databaseパフォーマンス・チューニング・ガイド』の新機能

- Oracle Database 11gリリース2(11.2.0.4)Oracle Databaseパフォーマンスの新機能

- Oracle Database 11gリリース2(11.2.0.2)Oracle Databaseパフォーマンスの新機能

- Oracle Database 11gリリース2(11.2.0.1)Oracle Databaseパフォーマンスの新機能

第I部 パフォーマンス・チューニング

1 パフォーマンス・チューニングの概要

- 1.1 パフォーマンス・チューニングの概要

- 1.1.1 パフォーマンス計画

- 1.1.2 インスタンスのチューニング

- 1.1.2.1 パフォーマンスの原理

- 1.1.2.2 ベースライン

- 1.1.2.3 症状および問題点

- 1.1.2.4 チューニングの時期

- 1.1.3 SQLチューニング

- 1.1.3.1 問合せオプティマイザおよび実行計画

- 1.2 パフォーマンス・チューニング機能およびツールの概要

- 1.2.1 自動パフォーマンス・チューニング機能

- 1.2.2 その他のOracle Databaseツール

- 1.2.2.1 V$パフォーマンス・ビュー

第II部 パフォーマンス計画

2 パフォーマンスを考慮した設計と開発

- 2.1 オラクル社の新しい方法論

- 2.2 投資の選択肢について

- 2.3 スケーラビリティについて

- 2.3.1 スケーラビリティとは

- 2.3.2 システムのスケーラビリティ

- 2.3.3 スケーラビリティを妨げる要因

- 2.4 システム・アーキテクチャ

- 2.4.1 ハードウェア・コンポーネントとソフトウェア・コンポーネント

- 2.4.1.1 ハードウェア・コンポーネント

- 2.4.1.2 ソフトウェア・コンポーネント

- 2.4.2 要件に合った正しいシステム・アーキテクチャの構成

- 2.5 アプリケーション設計の原則

- 2.5.1 アプリケーション設計の簡潔さ

- 2.5.2 データのモデル化

- 2.5.3 表および索引の設計

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

- 2.5.3.2 異なる索引タイプの使用

- 2.5.3.3 索引のコストの算出

- 2.5.3.4 索引内のシリアライズ

- 2.5.3.5 索引内の列の順序付け

- 2.5.4 ビューの使用

- 2.5.5 SQLの実行効率

- 2.5.6 アプリケーションの実装

- 2.5.7 アプリケーション開発の傾向

- 2.6 ワークロードのテスト、モデル化および実装

- 2.6.1 データのサイズ設定

- 2.6.2 ワークロードの見積り

- 2.6.2.1 類似システムからの推定

- 2.6.2.2 ベンチマーク

- 2.6.3 アプリケーションのモデル化

- 2.6.4 設計のテスト、デバッグおよび検証

- 2.7 新規アプリケーションのデプロイ

- 2.7.1 ロールアウトの方法

- 2.7.2 パフォーマンス・チェックリスト

3 パフォーマンス改善方法

- 3.1Oracleのパフォーマンス改善方法

- 3.1.1 Oracleのパフォーマンス改善方法の手順

- 3.1.2 パフォーマンスを概念的にモデル化する際の意思決定プロセスの例

- 3.1.3 Oracleシステムにおける誤りの上位10項目

- 3.2 パフォーマンスの緊急の問題に対処する方法

- 3.2.1 パフォーマンスの緊急の問題に対処する方法の手順

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

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

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

- 4.1.1 初期化パラメータ

- 4.1.2 UNDO領域の構成

- 4.1.3 REDOログ・ファイルのサイズ指定

- 4.1.4追加表領域の作成

- 4.1.4.1 永続的な表領域の作成: 自動セグメント領域管理

- 4.1.4.2 一時表領域の作成

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

- 4.2.1 表圧縮

- 4.2.1.1 圧縮係数の見積り

- 4.2.1.2 チューニングによる圧縮率向上

- 4.2.2 未使用領域の解放

- 4.2.3 データの索引付け

- 4.2.3.1 ソート用データのメモリーの指定

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

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

- 4.3.1.1 ディスパッチャ・プロセスの競合の低減

- 4.3.2 共有サーバーの競合の識別

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

- 5.1 データ収集の概要

- 5.1.1 データベース統計

- 5.1.1.1 待機イベント

- 5.1.1.2 時間モデル統計

- 5.1.1.3 アクティブ・セッション履歴

- 5.1.1.4 システム統計とセッション統計

- 5.1.2 オペレーティング・システム統計

- 5.1.2.1 CPU統計

- 5.1.2.2 仮想メモリー統計

- 5.1.2.3 ディスクI/O統計

- 5.1.2.4 ネットワーク統計

- 5.1.2.5 オペレーティング・システムのデータ収集ツール

- 5.1.3 統計の解釈

- 5.2 自動ワークロード・リポジトリの概要

- 5.2.1 スナップショット

- 5.2.2 ベースライン

- 5.2.2.1 固定ベースライン

- 5.2.2.2 変動ウィンドウ・ベースライン

- 5.2.2.3 ベースライン・テンプレート

- 5.2.3 適応しきい値

- 5.2.4 領域使用量

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

- 5.3.1 スナップショットの管理

- 5.3.1.1 スナップショットの作成

- 5.3.1.2 スナップショットの削除

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

- 5.3.2 ベースラインの管理

- 5.3.2.1 ベースラインの作成

- 5.3.2.2 ベースラインの削除

- 5.3.2.3 ベースラインの名前変更

- 5.3.2.4 ベースライン・メトリックの表示

- 5.3.2.5 デフォルトの変動ウィンドウ・ベースラインのウィンドウ・サイズの変更

- 5.3.3 ベースライン・テンプレートの管理

- 5.3.3.1 単一ベースライン・テンプレートの作成

- 5.3.3.2 繰返しベースライン・テンプレートの作成

- 5.3.3.3 ベースライン・テンプレートの削除

- 5.3.4自動ワークロード・リポジトリ・データの転送

- 5.3.4.1 AWRデータの抽出

- 5.3.4.2 AWRデータのロード

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

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

- 5.3.6.1 AWRレポートの生成

- 5.3.6.2 Oracle RAC AWRレポートの生成

- 5.3.6.3 特定のデータベース・インスタンスのAWRレポートの生成

- 5.3.6.4 特定のデータベース・インスタンスのOracle RAC AWRレポートの生成

- 5.3.6.5 SQL文のAWRレポートの生成

- 5.3.6.6 特定のデータベース・インスタンスのSQL文のAWRレポートの生成

- 5.3.7 自動ワークロード・リポジトリ期間比較レポートの生成

- 5.3.7.1 AWR期間比較レポートの生成

- 5.3.7.2 Oracle RAC AWR期間比較レポートの生成

- 5.3.7.3 特定のデータベース・インスタンスのAWR期間比較レポートの生成

- 5.3.7.4 特定のデータベース・インスタンスのOracle RAC AWR期間比較レポートの生成

- 5.3.8アクティブ・セッション履歴レポートの生成

- 5.3.8.1 ASHレポートの生成

- 5.3.8.2 特定のデータベース・インスタンスのASHレポートの生成

- 5.3.8.3 Oracle RAC ASHレポートの生成

- 5.3.9アクティブ・セッション履歴レポートの使用

- 5.3.9.1 上位イベント(Top Events)

- 5.3.9.2 ロード・プロファイル(Load Profile)

- 5.3.9.3 上位SQL(Top SQL)

- 5.3.9.4 上位PL/SQL(Top PL/SQL)

- 5.3.9.5 上位Java(Top Java)

- 5.3.9.6 上位セッション(Top Sessions)

- 5.3.9.7 上位オブジェクト/ファイル/ラッチ(Top Objects/Files/Latches)

- 5.3.9.8 アクティビティの経過(Activity Over Time)

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

- 6.1 自動データベース診断モニターの概要

- 6.1.1 ADDM分析

- 6.1.2 Oracle Real Application ClustersでのADDMの使用方法

- 6.1.3 ADDMの分析結果

- 6.1.4 ADDMの分析結果の確認: 例

- 6.2 ADDMの設定

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

- 6.3.1データベース・モードでのADDMの実行

- 6.3.2 インスタンス・モードでのADDMの実行

- 6.3.3 部分モードでのADDMの実行

- 6.3.4 ADDMレポートの表示

- 6.4 ADDM情報を表示するビュー

7 メモリーの構成および使用方法

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

- 7.1.1 Oracleメモリー・キャッシュ

- 7.1.2 自動メモリー管理

- 7.1.3 自動共有メモリー管理

- 7.1.4 キャッシュ・サイズの動的な変更

- 7.1.4.1 動的サイズ変更操作に関する情報の表示

- 7.1.5 アプリケーションの考慮事項

- 7.1.6 オペレーティング・システムのメモリー使用量

- 7.1.6.1 ページングの削減

- 7.1.6.2 主メモリーへのSGAの格納

- 7.1.6.3 個々のユーザーへの十分なメモリーの割当て

- 7.1.7 構成の繰返し

- 7.2 バッファ・キャッシュの構成および使用方法

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

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

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

- 7.2.2.2 V$DB_CACHE_ADVICEの使用

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

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

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

- 7.2.3.2 バッファ・キャッシュに割り当てられたメモリーの削減

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

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

- 7.2.4.2 Oracle Real Application Clustersのインスタンス

- 7.2.4.3 複数バッファ・プールの使用方法

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

- 7.2.6 バッファ・プール・ヒット率

- 7.2.7プール内に多くのバッファを持つセグメントの特定

- 7.2.8 KEEPプール

- 7.2.9 RECYCLEプール

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

- 7.3.1 共有プールの概念

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

- 7.3.1.2 ライブラリ・キャッシュの概念

- 7.3.1.3 SQL共有基準

- 7.3.2共有プールの効果的な使用方法

- 7.3.2.1 共有カーソル

- 7.3.2.2 単一のユーザーのログインおよび修飾表の参照

- 7.3.2.3 PL/SQLの使用方法

- 7.3.2.4 DDLの実行の回避

- 7.3.2.5 キャッシュ順序番号

- 7.3.2.6 カーソルのアクセスおよび管理

- 7.3.3 共有プールのサイズ設定

- 7.3.3.1 共有プール: ライブラリ・キャッシュの統計

- 7.3.3.2 V$LIBRARYCACHE

- 7.3.3.3 共有プールのアドバイザ統計

- 7.3.3.4 共有プール: ディクショナリ・キャッシュの統計

- 7.3.4 共有プール統計の解釈

- 7.3.4.1 メモリー割当ての増加

- 7.3.4.2 メモリー割当ての減少

- 7.3.5 ラージ・プールの使用l

- 7.3.5.1 共有サーバー・アーキテクチャでのラージ・プールと共有プールのチューニング

- 7.3.6 CURSOR_SPACE_FOR_TIMEの使用

- 7.3.7 セッション・カーソルのキャッシュ

- 7.3.7.1 セッション・カーソル・キャッシュの機能

- 7.3.7.2 セッション・カーソル・キャッシュの有効化

- 7.3.7.3 セッション・カーソル・キャッシュのチューニング

- 7.3.8 予約プールの構成

- 7.3.8.1 SHARED_POOL_RESERVED_SIZEの使用

- 7.3.8.2 SHARED_POOL_RESERVED_SIZEが小さすぎる場合

- 7.3.8.3 SHARED_POOL_RESERVED_SIZEが大きすぎる場合

- 7.3.8.4 SHARED_POOL_SIZEが小さすぎる場合

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

- 7.3.10 既存アプリケーションのカーソルの共有

- 7.3.10.1 類似した文でSQL領域を共有する方法

- 7.3.10.2 CURSOR_SHARINGを非デフォルト値に設定する場合

- 7.3.11 接続の維持

- 7.4 REDOログ・バッファの構成および使用方法

- 7.4.1 ログ・バッファのサイズ設定

- 7.4.2 ログ・バッファの統計

- 7.5 PGAメモリー管理

- 7.5.1 自動PGAメモリーの構成

- 7.5.1.1 PGA_AGGREGATE_TARGETの初期設定

- 7.5.1.2 自動PGAメモリー管理のパフォーマンスの監視

- 7.5.1.3 PGA_AGGREGATE_TARGETのチューニング

- 7.5.1.4 V$SYSSTATおよびV$SESSTAT

- 7.5.2 OLAP_PAGE_POOL_SIZEの構成

- 7.6 サーバーおよびクライアントの結果キャッシュの管理

- 7.6.1 サーバーの結果キャッシュの管理

- 7.6.1.1 サーバーの結果キャッシュの機能

- 7.6.1.2 サーバーの結果キャッシュの初期化パラメータ

- 7.6.1.3 サーバーの結果キャッシュに使用するメモリーの管理

- 7.6.2 クライアントの結果キャッシュの管理

- 7.6.2.1 クライアントの結果キャッシュの機能

- 7.6.2.2 クライアントの結果キャッシュの初期化パラメータ

- 7.6.3 結果をキャッシュする問合せの指定

- 7.6.3.1 結果キャッシュのモード

- 7.6.3.2 SQLの結果キャッシュ・ヒントの使用

- 7.6.3.3 結果キャッシュの表注釈の使用

- 7.6.4 結果キャッシュの要件

- 7.6.4.1 結果キャッシュの読取り一貫性の要件

- 7.6.4.2 結果キャッシュのその他の要件

- 7.6.4.3 結果キャッシュの問合せパラメータの要件

- 7.6.5 結果キャッシュの情報へのアクセス

8 I/O構成および設計

- 8.1 I/Oについて

- 8.2 I/O構成

- 8.2.1 オペレーティング・システムまたはハードウェアのストライプ化を使用したファイルのレイアウト

- 8.2.1.1 リクエストされたI/Oサイズ

- 8.2.1.2 I/Oリクエストの同時実行性

- 8.2.1.3 物理ストライプ境界とブロック・サイズ境界との位置合せ

- 8.2.1.4 提案されたシステムの管理性

- 8.2.2 手動によるI/Oの分散

- 8.2.3 ファイルを分割する場合

- 8.2.3.1 表、索引およびTEMP表領域

- 8.2.3.2 REDOログ・ファイル

- 8.2.3.3 アーカイブREDOログ

- 8.2.4 3つの構成サンプル

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

- 8.2.4.2 異なるディスクへのアーカイブ・ログの移動

- 8.2.4.3 個別のディスクへのREDOログの移動

- 8.2.5 Oracle Managed Files

- 8.2.6 データ・ブロック・サイズの選択

- 8.2.6.1 読取り

- 8.2.6.2 書込み

- 8.2.6.3 ブロック・サイズの長所と短所

- 8.3 データベース内部のI/O測定

- 8.3.1 I/O測定の前提条件

- 8.3.2 I/O測定の実行

- 8.4 Oracle Orion測定ツールによるI/O測定

- 8.4.1 Oracle Orion測定ツールの概要

- 8.4.1.1 Orionテストのターゲット

- 8.4.1.2 Oracle管理者のためのOrion

- 8.4.2 Orionの開始

- 8.4.3 Orionの入力ファイル

- 8.4.4 Orionのパラメータ

- 8.4.4.1 Orionに必要なパラメータ

- 8.4.4.2 Orionのオプション・パラメータ

- 8.4.4.3 Orionのコマンドライン例

- 8.4.5 Orionの出力ファイル

- 8.4.5.1 Orionの出力ファイル例

- 8.4.6 Orionのトラブルシューティング

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

- 9.1 オペレーティング・システムのパフォーマンスの問題について

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

- 9.1.1.1 非同期I/O

- 9.1.1.2 FILESYSTEMIO_OPTIONS初期化パラメータ

- 9.1.1.3 NFSサーバー環境における非同期I/Oの制限

- 9.1.2 メモリー使用量

- 9.1.2.1 バッファ・キャッシュの制限

- 9.1.2.2 メモリー使用量に影響を与えるパラメータ

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

- 9.2 オペレーティング・システムの問題の解決

- 9.2.1 UNIXベースのシステムのパフォーマンスに関するヒント

- 9.2.2 Windowsシステムのパフォーマンスに関するヒント

- 9.2.3 HP OpenVMSシステムのパフォーマンスに関するヒント

- 9.3 CPUについて

- 9.4 CPUの問題の解決

- 9.4.1 CPU使用率の確認およびチューニング

- 9.4.1.1 メモリー管理のチェック

- 9.4.1.2 I/O管理のチェック

- 9.4.1.3 ネットワーク管理のチェック

- 9.4.1.4 プロセス管理のチェック

- 9.4.2 Oracle Database Resource Managerを使用したCPUリソースの管理

- 9.4.3 インスタンス・ケージングを使用したCPUリソースの管理

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

- 10.1 インスタンスのチューニング手順

- 10.1.1 問題の定義

- 10.1.2 ホスト・システムの検査

- 10.1.2.1 CPUの使用率

- 10.1.2.2 I/Oの問題の識別

- 10.1.2.3 ネットワークの問題の識別

- 10.1.3 Oracle Database統計の調査

- 10.1.3.1 統計収集のレベルの設定

- 10.1.3.2 待機イベント

- 10.1.3.3 待機イベント統計を含む動的パフォーマンス・ビュー

- 10.1.3.4 システム統計

- 10.1.3.5 セグメント・レベルの統計

- 10.1.4 変更の実装および測定

- 10.2 Oracle Database統計の解釈

- 10.2.1 負荷の検査

- 10.2.1.1 負荷の変更

- 10.2.1.2 高いアクティビティ率

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

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

- 10.2.4 追加された統計情報

- 10.2.4.1 REDOログ領域リクエスト統計

- 10.2.4.2 読取り一貫性

- 10.2.4.3 継続行による表フェッチ

- 10.2.4.4 解析関連の統計

- 10.3 待機イベント統計

- 10.3.1 buffer busy waits

- 10.3.1.1 原因

- 10.3.1.2 処置

- 10.3.2 db file scattered read

- 10.3.2.1 処置

- 10.3.2.2 過剰なI/Oの管理

- 10.3.2.3 不十分なI/O分散

- 10.3.2.4 I/Oを待機しているセッションで実行されたSQL文の検索

- 10.3.2.5 I/Oを必要とするオブジェクトの検索

- 10.3.3 db file sequential read

- 10.3.3.1 処置

- 10.3.4 direct path readおよびdirect path read temp

- 10.3.4.1 原因

- 10.3.4.2 処置

- 10.3.5 direct path writeおよびdirect path write temp

- 10.3.5.1 原因

- 10.3.5.2 処置

- 10.3.6 enqueue(enq:)待機

- 10.3.6.1 ロックおよびロック・ホルダーの検索

- 10.3.6.2 処置

- 10.3.7 Other待機クラスのイベント

- 10.3.8 free buffer waits

- 10.3.8.1 原因

- 10.3.8.2 処置

- 10.3.8.3 複数のデータベース・ライター(DBWR)・プロセスまたはI/Oスレーブの検討

- 10.3.9 アイドル待機イベント

- 10.3.10 ラッチ・イベント

- 10.3.10.1 処置

- 10.3.10.2 例: 現在待機されているラッチの検索

- 10.3.10.3 共有プールとライブラリ・キャッシュ・ラッチの競合

- 10.3.11 log file parallel write

- 10.3.12 library cache pin

- 10.3.13 library cache lock

- 10.3.14 log buffer space

- 10.3.15 log file switch

- 10.3.15.1 処置

- 10.3.16 log file sync

- 10.3.17 rdbms ipc reply

- 10.3.18 SQL*Netイベント

- 10.3.18.1 SQL*Net message from client

- 10.3.18.2 SQL*Net message from dblink

- 10.3.18.3 SQL*Net more data to client

- 10.4 リアルタイムSQL監視

- 10.4.1 SQL計画の監視

- 10.4.2 パラレル実行の監視

- 10.4.3 SQL監視レポートの生成

- 10.4.4 SQL監視の有効化と無効化

- 10.5 インスタンス・リカバリのパフォーマンスのチューニング: ファスト・スタート・フォルト・リカバリ

- 10.5.1 インスタンス・リカバリについて

- 10.5.1.1 キャッシュ・リカバリ(ロールフォワード)

- 10.5.1.2 トランザクション・リカバリ(ロールバック)

- 10.5.1.3 チェックポイントとキャッシュ・リカバリ

- 10.5.2 キャッシュ・リカバリ時間の構成: FAST_START_MTTR_TARGET

- 10.5.2.1 FAST_START_MTTR_TARGETの現実的な値

- 10.5.2.2 ランタイム・パフォーマンスを最適化するためのチェックポイント頻度の低減

- 10.5.2.3 V$INSTANCE_RECOVERYによるキャッシュ・リカバリの監視

- 10.5.3 FAST_START_MTTR_TARGETのチューニングとMTTRアドバイザの使用

- 10.5.3.1 FAST_START_MTTR_TARGETの測定

- 10.5.3.2 FAST_START_MTTR_TARGETの現実的な範囲の決定

- 10.5.3.3 MTTRアドバイザによる様々な目標値の評価

- 10.5.3.4 最適なREDOログ・サイズの決定

第IV部 SQL文の最適化

11 問合せオプティマイザ

- 11.1 問合せオプティマイザの概要

- 11.1.1 オプティマイザ操作

- 11.1.2 問合せオプティマイザの構成要素

- 11.1.2.1 問合せ変換

- 11.1.2.2 見積り

- 11.1.2.3 プラン・ジェネレータ

- 11.1.3 バインド変数の照合

- 11.1.3.1 適応カーソル共有

- 11.1.3.2 バインド関連のパフォーマンスデータの表示

- 11.2 オプティマイザ・アクセス・パスの概要

- 11.2.1 全表スキャン

- 11.2.1.1 大量データにアクセスする場合に全表スキャンのほうが高速になる理由

- 11.2.1.2 オプティマイザが全表スキャンを使用する場合

- 11.2.1.3 全表スキャンのヒント

- 11.2.1.4 パラレル問合せの実行

- 11.2.2 ROWIDスキャン

- 11.2.2.1 オプティマイザがROWIDを使用する場合

- 11.2.3 索引スキャン

- 11.2.3.1 ブロックのI/O(行ではなく)の想定

- 11.2.3.2 索引一意スキャン

- 11.2.3.3 索引レンジ・スキャン

- 11.2.3.4 索引レンジ・スキャン降順

- 11.2.3.5 索引スキップ・スキャン

- 11.2.3.6 全体スキャン

- 11.2.3.7 高速全索引スキャン

- 11.2.3.8 索引結合

- 11.2.3.9 ビットマップ索引

- 11.2.4 クラスタ・アクセス

- 11.2.5 ハッシュ・アクセス

- 11.2.6 サンプル表スキャン

- 11.2.7 問合せオプティマイザによるアクセス・パスの選択方法

- 11.3 結合の概要

- 11.3.1 問合せオプティマイザによる結合文の実行方法

- 11.3.2 問合せオプティマイザによる結合の実行計画の選択方法

- 11.3.3 ネステッド・ループ結合

- 11.3.3.1 ネステッド・ループ結合の従来の実装と新規の実装

- 11.3.3.2 オプティマイザがネステッド・ループ結合を使用する場合

- 11.3.3.3 ネステッド・ループ結合のヒント

- 11.3.3.4 ネステッド・ループのネスト

- 11.3.4 ハッシュ結合

- 11.3.4.1 オプティマイザがハッシュ結合を使用する場合

- 11.3.4.2 ハッシュ結合のヒント

- 11.3.5 ソート/マージ結合

- 11.3.5.1 オプティマイザがソート/マージ結合を使用する場合

- 11.3.5.2 ソート/マージ結合のヒント

- 11.3.6 デカルト結合

- 11.3.6.1 オプティマイザがデカルト結合を使用する場合

- 11.3.6.2 デカルト結合のヒント

- 11.3.7 外部結合

- 11.3.7.1 ネステッド・ループ外部結合

- 11.3.7.2 ハッシュ結合外部結合

- 11.3.7.3 ソート/マージ外部結合

- 11.3.7.4 完全外部結合

- 11.4 実行計画の読み方と理解

- 11.4.1 EXPLAIN PLANの概要

- 11.4.2 実行計画のステップ

- 11.5 オプティマイザ動作の制御

- 11.5.1 問合せオプティマイザ機能の有効化

- 11.5.2 オプティマイザの目標の選択

- 11.5.2.1 OPTIMIZER_MODE初期化パラメータの設定

- 11.5.2.2 オプティマイザの目標変更に対するヒントの使用

- 11.5.2.3 データ・ディクショナリ内のオプティマイザ統計

12 EXPLAIN PLANの使用方法

- 12.1 EXPLAIN PLANについて

- 12.1.1 実行計画の変化理由

- 12.1.1.1 スキーマの相違

- 12.1.1.2 コストの相違

- 12.1.2 排除行数の最少化

- 12.1.3 実行計画以外の考慮事項

- 12.1.3.1 V$SQL_PLANビューの使用

- 12.1.4 EXPLAIN PLANの制限事項

- 12.2 PLAN_TABLE出力表

- 12.3 EXPLAIN PLANの実行

- 12.3.1 EXPLAIN PLANでの文の指定

- 12.3.2 EXPLAIN PLANでの別の表の指定

- 12.4 PLAN_TABLE出力の表示

- 12.4.1 PLAN_TABLE出力のカスタマイズ

- 12.5 EXPLAIN PLAN出力の読み方

- 12.6 EXPLAIN PLANによるパラレル実行の表示

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

- 12.7 EXPLAIN PLANによるビットマップ索引の表示

- 12.8 EXPLAIN PLANによる結果キャッシュの表示

- 12.9 EXPLAIN PLANによるパーティション・オブジェクトの表示

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

- 12.9.1.1 ハッシュ・パーティション化の計画

- 12.9.2 コンポジット・パーティション・オブジェクトでのプルーニング情報の例

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

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

- 12.9.5 INLIST ITERATORおよびEXPLAIN PLANの例

- 12.9.5.1 INリスト列が索引列である場合

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

- 12.9.5.3 INリスト列がパーティション列である場合

- 12.9.6 ドメイン索引およびEXPLAIN PLANの例

- 12.10 PLAN_TABLE列

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

- 13.1 オプティマイザ統計の概要

- 13.2 自動オプティマイザ統計収集の管理

- 13.2.1 自動オプティマイザ統計収集の有効化と無効化

- 13.2.2 統計収集時の考慮事項

- 13.2.2.1 手動統計を使用する場合

- 13.2.2.2 前のバージョンの統計のリストア

- 13.2.2.3 統計のロック

- 13.3 手動での統計の収集

- 13.3.1 DBMS_STATSプロシージャによる統計の収集

- 13.3.1.1 サンプリングを使用した統計収集

- 13.3.1.2 パラレル統計収集

- 13.3.1.3 パーティション・オブジェクトの統計

- 13.3.1.4 列統計情報とヒストグラム

- 13.3.1.5 失効している統計の判別

- 13.3.1.6 ユーザー定義統計

- 13.3.2 手動統計収集のプリファレンスの設定

- 13.3.3 統計を収集する時期

- 13.3.4 DBMS_STATSファンクションによる統計の比較

- 13.4 システム統計

- 13.4.1 作業負荷統計

- 13.4.1.1 作業負荷統計の収集

- 13.4.1.2 マルチブロック読取りカウント

- 13.4.2 非作業負荷統計

- 13.4.2.1 非作業負荷統計の収集

- 13.5 統計の管理

- 13.5.1 統計の保留

- 13.5.2 拡張統計の管理

- 13.5.2.1 列グループの統計の管理

- 13.5.2.2 式の統計の管理

- 13.5.3 前のバージョンの統計のリストア

- 13.5.4 統計のエクスポートとインポート

- 13.5.5 統計のリストアとインポートまたはエクスポートの相違点

- 13.5.6 表統計またはスキーマ統計のロック

- 13.5.7 統計の設定

- 13.5.8 統計の欠落の処理

- 13.6 動的統計の制御

- 13.6.1 動的統計の目的

- 13.6.2 動的統計の概念

- 13.6.2.1 動的統計レベル

- 13.6.2.2 オプティマイザで動的統計を使用するタイミング

- 13.6.3 動的統計レベルの手動設定

- 13.6.4 動的統計の無効化

- 13.7 統計の表示

- 13.7.1 表、索引および列の統計

- 13.7.2 ヒストグラムの表示

- 13.7.2.1 高さ調整済ヒストグラム

- 13.7.2.2 頻度ヒストグラム

14 索引およびクラスタの使用方法

- 14.1 索引パフォーマンスについて

- 14.1.1 論理構造のチューニング

- 14.1.2 SQLアクセス・アドバイザを使用した索引のチューニング

- 14.1.3 索引を付ける列と式の選択

- 14.1.4 コンポジット索引の選択

- 14.1.4.1 コンポジット索引のキーの選択

- 14.1.4.2 コンポジット索引のキーの順序付け

- 14.1.5 索引を使用する文の記述

- 14.1.6 索引を使用しない文の記述

- 14.1.7 索引の再作成

- 14.1.8 索引の縮小

- 14.1.9 一意でない索引による一意性の規定

- 14.1.10 ENABLE NOVALIDATE制約の使用方法

- 14.2 パフォーマンスを考慮したファンクション索引の使用方法

- 14.3 パフォーマンスを考慮したパーティション索引の使用方法

- 14.4 パフォーマンスを考慮した索引構成表の使用方法

- 14.5 パフォーマンスを考慮したビットマップ索引の使用方法

- 14.6 パフォーマンスを考慮したビットマップ結合索引の使用方法

- 14.7 パフォーマンスを考慮したドメイン索引の使用方法

- 14.8 パフォーマンスを考慮した表クラスタの使用方法

- 14.9 パフォーマンスを考慮したハッシュ・クラスタの使用方法

15 SQL計画の管理の使用方法

- 15.1 SQL計画ベースラインの概要

- 15.1.1 SQL計画ベースラインの目的

- 15.1.2 SQL計画ベースラインのアーキテクチャ

- 15.2 SQL計画ベースラインの管理

- 15.2.1 SQL計画ベースラインの取得

- 15.2.1.1 計画の自動取得

- 15.2.1.2 既存計画からのベースラインの作成

- 15.2.2 SQL計画ベースラインの選択

- 15.2.3 SQL計画ベースラインの改良

- 15.2.3.1 手動の計画ロードによる計画の改良

- 15.2.3.2DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEによる計画の改良

- 15.3 SQLチューニング・アドバイザでのSQL計画ベースラインの使用

- 15.4 固定SQL計画ベースラインの使用

- 15.5 SQL計画ベースラインの表示

- 15.6 SQL管理ベース

- 15.6.1 ディスク領域の使用量

- 15.6.2 消去方針

- 15.6.3 SQL管理ベースの構成パラメータ

- 15.7 SQL計画ベースラインのインポートとエクスポート

- 15.8 ストアド・アウトラインのSQL計画ベースラインへの移行

- 15.8.1 ストアド・アウトラインの移行の概要

- 15.8.1.1 ストアド・アウトラインの移行の目的

- 15.8.1.2 ストアド・アウトラインの移行方法

- 15.8.1.3 ストアド・アウトラインの移行のためのユーザー・インタフェース

- 15.8.1.4 ストアド・アウトラインの移行の基本ステップ

- 15.8.2 ストアド・アウトラインの移行の準備

- 15.8.3 アウトラインの移行によるSQL計画管理機能の使用

- 15.8.4 アウトラインの移行でのストアド・アウトライン動作の保存

- 15.8.5 ストアド・アウトラインの移行後のフォーローアップ・タスクの実行

16 SQLチューニングの概要

- 16.1 SQLチューニングの概要

- 16.2 チューニングの目的

- 16.2.1 ワークロードの削減

- 16.2.2 ワークロードの均衡化

- 16.2.3 ワークロードのパラレル化

- 16.3 高負荷SQLの識別

- 16.3.1 多くのリソースを消費するSQLの識別

- 16.3.1.1 特定のプログラムのチューニング

- 16.3.1.2 アプリケーションのチューニング/負荷の軽減

- 16.3.2 識別したSQLに関するデータの収集

- 16.3.2.1 チューニング中に収集する情報

- 16.4 自動SQLチューニング機能

- 16.4.1 ADDM

- 16.4.2 SQLチューニング・アドバイザ

- 16.4.3 SQLチューニング・セット

- 16.4.4 SQLアクセス・アドバイザ

- 16.5 効率的なSQL文の開発

- 16.5.1 オプティマイザ統計の確認

- 16.5.2 実行計画の検討

- 16.5.3 SQL文の再構成

- 16.5.3.1 ANDと=を使用した条件の組立て

- 16.5.3.2 WHERE句での変換列の回避

- 16.5.3.3 特定のタスクに対する専用のSQL文の作成

- 16.5.4 ヒントによるアクセス・パスおよび結合順序の制御

- 16.5.4.1 ビューを管理するときの注意

- 16.5.4.2 中間結果の格納

- 16.5.5 索引の再構成

- 16.5.6 トリガーおよび制約の変更または無効化

- 16.5.7 データの再構成

- 16.5.8 実行計画の長期的な保持

- 16.5.9 データへのアクセスを最小限に削減

- 16.5.9.1 CASE式を使用した複数のスキャンの組合せ

- 16.5.9.2 RETURNING句を持つDMLの使用

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

- 16.6 SQLテスト・ケースの作成

- 16.6.1 テスト・ケースの作成

- 16.6.1.1 Enterprise ManagerからのSQLテスト・ケース・ビルダーへのアクセス

- 16.6.1.2 DBMS_SQLDIAGを使用したSQLテスト・ケース・ビルダーへのアクセス

17 自動SQLチューニング

- 17.1 自動チューニング・オプティマイザの概要

- 17.1.1 統計分析

- 17.1.2 SQLプロファイリング

- 17.1.3 アクセス・パス分析

- 17.1.4 SQL構造分析

- 17.1.5 代替計画分析

- 17.2 自動SQLチューニング・アドバイザの管理

- 17.2.1 自動SQLチューニングの動作

- 17.2.2 自動SQLチューニングの有効化と無効化

- 17.2.3 自動SQLチューニングの構成

- 17.2.4 自動SQLチューニング・レポートの表示

- 17.3 SQLチューニング・アドバイザによる事後対応のチューニング

- 17.3.1 入力ソース

- 17.3.2 チューニング・オプション

- 17.3.3 アドバイザ出力

- 17.3.4 SQLチューニング・アドバイザ

- 17.3.4.1 SQLチューニング・タスクの作成

- 17.3.4.2 SQLチューニング・タスクの構成

- 17.3.4.3 SQLチューニング・タスクの実行

- 17.3.4.4 SQLチューニング・タスクのステータスのチェック

- 17.3.4.5 SQLチューニング・アドバイザの進捗のチェック

- 17.3.4.6 SQLチューニング・タスクの結果の表示

- 17.3.4.7 SQLチューニング・タスクに関するその他の操作

- 17.4 SQLチューニング・セットの管理

- 17.4.1 SQLチューニング・セットの作成

- 17.4.2 SQLチューニング・セットのロード

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

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

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

- 17.4.6 SQLチューニング・セットの削除

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

- 17.5 SQLプロファイルの管理

- 17.5.1 SQLプロファイルの概要

- 17.5.1.1 SQLプロファイルの推奨事項

- 17.5.1.2 SQLプロファイルの作成

- 17.5.1.3 SQLプロファイルのAPI

- 17.5.2 SQLプロファイルの受入れ

- 17.5.3 SQLプロファイルの変更

- 17.5.4 SQLプロファイルの削除

- 17.5.5 SQLプロファイルの転送

- 17.6 SQLチューニング・ビュー

18 SQLアクセス・アドバイザ

- 18.1 SQLアクセス・アドバイザの概要

- 18.1.1 SQLアクセス・アドバイザの概要

- 18.1.1.1 SQLアクセス・アドバイザ・リポジトリ

- 18.2 SQLアクセス・アドバイザの使用

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

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

- 18.2.3 タスクとテンプレートの設定

- 18.2.3.1 タスクの作成

- 18.2.3.2 テンプレートの使用方法

- 18.2.3.3 テンプレートの作成

- 18.2.4 SQLアクセス・アドバイザのワークロード

- 18.2.4.1 SQLチューニング・セットのワークロード

- 18.2.4.2 SQLチューニング・セットの使用方法

- 18.2.4.3 タスクとワークロードのリンク

- 18.2.5 推奨事項の処理

- 18.2.5.1 推奨事項とアクション

- 18.2.5.2 推奨オプション

- 18.2.5.3 評価モード

- 18.2.5.4 推奨事項分析中の中間結果の表示

- 18.2.5.5 推奨事項の生成

- 18.2.5.6 推奨事項の表示

- 18.2.5.7 推奨プロセスの停止

- 18.2.5.8 推奨事項のマーキング

- 18.2.5.9 推奨事項の変更

- 18.2.5.10 SQLスクリプトの生成

- 18.2.5.11 スクリプトにパーティション推奨事項が含まれる場合の特別な考慮事項

- 18.2.5.12 推奨事項が必要なくなった場合

- 18.2.6 クイック・チューニングの実行

- 18.2.7 タスクの管理

- 18.2.7.1 タスク属性の更新

- 18.2.7.2 タスクの削除

- 18.2.7.3 DAYS_TO_EXPIREパラメータの設定

- 18.2.8 SQLアクセス・アドバイザの定数の使用方法

- 18.2.9 SQLアクセス・アドバイザの使用例

- 18.2.9.1 ユーザー定義のワークロードの推奨事項

- 18.2.9.2 タスク・テンプレートを使用した推奨事項の生成

- 18.2.9.3 索引およびマテリアライズド・ビューの現在の使用状況の評価

- 18.3 高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング

- 18.3.1 DBMS_ADVISOR.TUNE_MVIEWプロシージャ

- 18.3.1.1 TUNE_MVIEWの構文と操作

- 18.3.1.2 TUNE_MVIEWの出力結果へのアクセス

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

19 オプティマイザ・ヒントの使用方法

- 19.1 オプティマイザ・ヒントの概要

- 19.1.1 ヒントの型

- 19.1.2 カテゴリ別のヒント

- 19.1.2.1 最適化アプローチと目標のヒント

- 19.1.2.2 オプティマイザ機能を有効化するヒント

- 19.1.2.3 アクセス・パスに関するヒント

- 19.1.2.4 結合順序のヒント

- 19.1.2.5 結合操作のヒント

- 19.1.2.6 オンライン・アプリケーション・アップグレードのヒント

- 19.1.2.7 パラレル実行のヒント

- 19.1.2.8 問合せの変換に関するヒント

- 19.1.2.9 その他のヒント

- 19.2 ヒントの指定方法

- 19.2.1 ヒント全セットの指定方法

- 19.2.2 ヒントにおける問合せブロックの指定方法

- 19.2.3 グローバル表のヒントの指定方法

- 19.2.4 複合索引ヒントの指定方法

- 19.3 ビューでのヒントの使用方法

- 19.3.1 ヒントおよび複合ビュー

- 19.3.2 ヒントとマージ可能ビュー

- 19.3.2.1 ビューでの最適化アプローチと目標のヒント

- 19.3.2.2 ビューに対するアクセス・パスと結合のヒント

- 19.3.2.3 ビュー内のアクセス・パスと結合のヒント

- 19.3.3 ヒントとマージ不可能ビュー

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

- 20.1 実行計画を保持するためのプラン・スタビリティの使用方法

- 20.1.1 プラン・スタビリティでのヒントの使用方法

- 20.1.1.1 アウトラインによるヒントの使用方法

- 20.1.2 アウトラインの格納

- 20.1.3 プラン・スタビリティの有効化

- 20.1.4 付属パッケージを使用したストアド・アウトラインの管理

- 20.1.5 アウトラインの作成

- 20.1.5.1 ストアド・アウトラインのカテゴリ名の使用方法

- 20.1.6 ストアド・アウトラインの使用方法

- 20.1.7 アウトライン・データの表示

- 20.1.8 アウトライン表の移動

- 20.2 問合せオプティマイザのアップグレードによるプラン・スタビリティの使用方法

- 20.2.1 RBOから問合せオプティマイザへの移行

- 20.2.2 問合せオプティマイザを使用する新規Oracleリリースへの移行

- 20.2.2.1 テスト・システムでのアップグレード

21 アプリケーション・トレース・ツールの使用方法

- 21.1 エンドツーエンド・アプリケーションのトレース

- 21.1.1 エンドツーエンド・トレースにおける統計収集の有効化および無効化

- 21.1.1.1 クライアント識別子に対する統計収集

- 21.1.1.2 サービス、モジュールおよびアクションに対する統計収集

- 21.1.2 エンドツーエンド・アプリケーションのトレースで収集した統計の表示

- 21.1.3 エンドツーエンド・トレースにおける有効化および無効化

- 21.1.3.1 クライアント識別子のトレース

- 21.1.3.2 サービス、モジュールおよびアクションのトレース

- 21.1.3.3 セッションのトレース

- 21.1.3.4 インスタンス全体またはデータベース全体のトレース

- 21.1.4 エンドツーエンド・トレースにおける使用可能なトレースの表示

- 21.2 trcsessユーティリティの使用方法

- 21.2.1 trcsessの構文

- 21.2.2 trcsessの出力例

- 21.3 SQLトレースとTKPROFについて

- 21.3.1 SQLトレース機能について

- 21.3.2 TKPROFについて

- 21.4 SQLトレース機能とTKPROFの使用方法

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

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

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

- 21.4.3.1 TKPROFの出力例

- 21.4.3.2 TKPROFの構文

- 21.4.3.3 TKPROF文の例

- 21.4.4 手順4: TKPROF出力の解釈

- 21.4.4.1 TKPROFの表形式の統計

- 21.4.4.2 行ソースの操作

- 21.4.4.3 待機イベント情報

- 21.4.4.4 統計の精度の解釈

- 21.4.4.5 再帰的コールについて

- 21.4.4.6 TKPROFのライブラリ・キャッシュ・ミス

- 21.4.4.7 SQLトレースでの文の切捨て

- 21.4.4.8 TKPROFでのSQL文を発行するユーザーの識別

- 21.4.4.9 TKPROFの実行計画

- 21.4.4.10 チューニングする文の決定

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

- 21.4.5.1 TKPROFによる出力SQLスクリプトの生成

- 21.4.5.2 TKPROFによる出力SQLスクリプトの編集

- 21.4.5.3 出力表の問合せ

- 21.5 TKPROFの解釈における誤りの回避

- 21.5.1 引数トラップの回避

- 21.5.2 読取り一貫性トラップの回避

- 21.5.3 スキーマ・トラップの回避

- 21.5.4 タイム・トラップの回避

- 21.6 TKPROFの出力例

- 21.6.1 TKPROFヘッダーのサンプル

- 21.6.2 TKPROF本体のサンプル

- 21.6.3 TKPROFサマリーのサンプル

用語集

索引

はじめに

この章には、次の項目が含まれます。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Databaseパフォーマンス・チューニング・ガイド』は、Oracle Databaseの運用、メンテナンスおよびパフォーマンスを担当するデータベース管理者(DBA)を対象としています。このガイドでは、コマンドライン・インタフェースでOracle Databaseパフォーマンス・ツールを使用して、データベースのパフォーマンスの最適化とSQL文のチューニングを行う方法について説明します。また、データベースの初期の作成でのパフォーマンスのベスト・プラクティスを説明するとともに、パフォーマンス関連の参照情報を示します。

関連項目:
Oracle Enterprise Managerを使用してデータベースのパフォーマンスをチューニングする方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

このマニュアルを読む前に、次のマニュアルの内容を理解しておく必要があります。

- 『Oracle Database概要』

- 『Oracle Database 2日でデータベース管理者』

- 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』

- 『Oracle Database管理者ガイド』

Oracle Enterprise Managerを使用してOracle Databaseのパフォーマンスをチューニングする方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

データ・ウェアハウス環境のチューニング方法は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

このマニュアルに記載されている例の多くは、Oracle Databaseのインストール時に基本インストール・オプションを選択した場合、デフォルトでインストールされるサンプル・スキーマを使用しています。これらのスキーマのインストールおよび使用方法は、『Oracle Databaseサンプル・スキーマ』を参照してください。

Oracle Databaseエラー・メッセージの詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。Oracle Databaseエラー・メッセージのマニュアルは、HTML版のみご利用いただけます。Oracle Database JP Documentation Libraryのエラー・メッセージ・マニュアルにアクセスする場合、範囲ごとにエラー・メッセージを参照できます。範囲を検索した後、ブラウザの検索機能を使用してメッセージを検索します。インターネットに接続している場合は、Oracleオンライン・マニュアルのエラー・メッセージ検索機能を使用して、特定のエラー・メッセージを検索できます。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

『Oracle Databaseパフォーマンス・チューニング・ガイド』の新機能

ここでは、Oracle Database 11gリリース2 (11.2)のパフォーマンス・チューニングに関連した新機能について説明するとともに、追加情報の記載場所も示します。ここで説明する機能と拡張機能は、データベースのパフォーマンスを最適化することを目標としています。

Oracle Database 11gリリース2 (11.2)のすべての新機能の概要は、『Oracle Database新機能ガイド』を参照してください。

Oracle Database 11gリリース2(11.2.0.4)Oracle Databaseパフォーマンスの新機能

パフォーマンス・チューニングの新機能および更新された機能には、次のものがあります。

- 動的統計の拡張
以前のリリースでは、動的統計(以前は動的サンプリングと呼ばれていました)は、問合せ内の1つ以上の表にオプティマイザ統計が存在しない場合にのみ収集されました。Oracle Database 11gリリース2 (11.2.0.4)から、オプティマイザは、すべてのSQL文に対して、動的統計が有用であるかどうか、および使用する動的統計レベルを自動的に決定できるようになりました。たとえば、オプティマイザでは、表スキャン、索引アクセス、結合およびGROUP BY操作の間に動的統計を収集するかどうかを自動的に決定します。この拡張された動作は、OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータに、新しい値である11を設定した場合にのみ有効となります。

「動的統計の制御」を参照してください。

Oracle Database 11gリリース2(11.2.0.2)Oracle Databaseパフォーマンスの新機能

パフォーマンス・チューニングの新機能および更新された機能には、次のものがあります。

- リソース・マネージャのパラレル文のキューニングに関する強化
リソース・マネージャを使用して、パラレル文キューで文の順序を管理できます。たとえば、優先順位の高い文がキューに留まる時間を短くすることができます。また、ディレクティブを使用して、1つのコンシューマ・グループがすべてのパラレル・サーバーを占有するのを防ぎ、パラレル文が開始されるまでの最大待機時間を秒単位で指定できます。

詳細は、「Oracle Database Resource Managerを使用したCPUリソースの管理」および『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- リソース・マネージャのCPU使用制限に関する強化
リソース・マネージャを使用して、コンシューマ・グループのCPU消費量を制限できます。この機能は、優先順位の低いセッションのCPU消費量を制限して、コンシューマ・グループ内のワークロードにより安定したパフォーマンスを提供できるようにします。

詳細は、「Oracle Database Resource Managerを使用したCPUリソースの管理」を参照してください。

- 自動SQLチューニングの新パッケージ
DBMS_AUTO_SQLTUNEパッケージは、自動SQLチューニング・タスクを管理するための新しいインタフェースです。SQLチューニング・アドバイザ・パッケージDBMS_SQLTUNEはADVISOR権限を必要としますが、これとは異なり、DBMS_AUTO_SQLTUNEではDBAロールを必要とします。

詳細は、「自動SQLチユー二音グの構成」を参照してください。

- Oracle Orion I/O測定ツールのマニュアル
Oracle Orionは、Oracleのインストールやデータベースの作成を行わなくてもOracleデータベースのパフォーマンスを予測できるツールです。他のI/O測定ツールとは異なり、Oracle Orionは、Oracleと同じI/Oソフトウェア・スタックを使用してOracleデータベースのI/Oワークロードをシミュレートするように特別に設計されたものです。またOrionは、Oracle Automatic Storage Managementによって実行されるストライプ化の効果もシミュレートすることができます。

詳細は、「Oracle Orion測定ツールによるI/O測定」を参照してください。

Oracle Database 11gリリース2(11.2.0.1)Oracle Databaseパフォーマンスの新機能

パフォーマンス・チューニングの新機能および更新された機能には、次のものがあります。

- 新しい自動ワークロード・リポジトリ(AWR)ビュー
AWRは、DBA_HIST_DB_CACHE_ADVICEおよびDBA_HIST_IOSTAT_DETAILなどの複数の新規履歴ビューをサポートします。

詳細は、「自動ワークロード・リポジトリ・ビューの使用」を参照してください。

- 新しい自動ワークロード・リポジトリ・レポート
Oracle Real Application Clusters(Oracle RAC)に新しいAWRレポートおよびAWR期間比較レポートが追加されました。

詳細は、「自動ワークロード・リポジトリ・レポートの生成」および「自動ワークロード・リポジトリ期間比較レポートの生成」を参照してください。

- クライアントの結果キャッシュのための表注釈のサポート
クライアントの結果キャッシュは表注釈をサポートします。

詳細は、「結果キャッシュの表注釈の使用」を参照してください。

- PL/SQLファンクションのRESULT_CACHE注釈の拡張
Oracle Database 11gリリース1(11.1)では、注釈付きの表を参照する問合せを実行するPL/SQLファンクションにはRELIES_ON句が必要でした。この句は非推奨になり、必要ではなくなりました。

- 文レベルで並列度を指定するヒント
パラレル・ヒントの有効範囲が拡張され、文レベルが含まれます。

詳細は、「パラレル実行のヒント」を参照してください。

- メモリー内パラレル実行
パラレル問合せを使用する場合、SQL文を直接PGAに読み込むのではなく、データベース・バッファ・キャッシュを使用するようにデータベースを構成できます。この構成は、データベース・サーバーのメモリー容量が大きい場合に適しています。また、Oracle Real Applications Cluster(Oracle RAC)データベースはすべてのノードのバッファ・キャッシュのサイズを集計できるため、より大きいオブジェクトやより多くの問合せのキャッシュが可能になります。

詳細は、「バッファ・キャッシュの効果的な使用」を参照してください。

- オンライン・アプリケーション・アップグレードのヒント
オンライン・アプリケーション・アップグレードのヒントは、編集ベースの再定義を使用してオンライン・アプリケーション・アップグレードを行う場合のINSERT操作とUPDATE操作の競合を処理する方法を提示します。詳細は、「オンライン・アプリケーション・アップグレードのヒント」を参照してください。

- SQLチューニング・アドバイザの拡張
このリリースでのSQLチューニング・アドバイザの拡張は次のとおりです。

- SQLチューニング・アドバイザは、SQL文をチューニングする際に、リアルタイムおよび履歴パフォーマンス・データで、文の代替実行計画を検索します。最初の計画以外の計画が存在する場合、SQLチューニング・アドバイザは、代替計画が見つかったことを報告します。「代替計画分析」を参照してください。

- Oracle Database 10g(リリース2)以上で作成された任意のデータベースにSQLチューニング・セットを転送できます。これは、SQLパフォーマンス・アナライザを使用してテスト用データベースで回帰をチューニングする場合に役立ちます。「SQLチューニング・セットの転送」を参照してください。

- SQLチューニング・アドバイザは、自動並列度(自動DOP)機能を使用するプロファイルを受け入れるよう推奨する場合もあります。パラレル問合せプロファイルは、元の計画がシリアルの場合で、パラレル実行により実行時間の長い問合せの経過時間を大幅に削減できる場合にのみ推奨されます。「SQLプロファイルの推奨事項」を参照してください。

- ストアド・アウトラインのSQL計画ベースラインへの移行
Oracle Databaseでは、ストアド・アウトラインからSQL計画ベースラインに安全に移行できます。移行した後、ストアド・アウトラインを使用した場合と同じ計画の安定性を維持し、SQL計画管理フレームワークで提供された拡張機能を使用できます。詳細は、「ストアド・アウトラインのSQL計画ベースラインへの移行」を参照してください。

第I部

パフォーマンス・チューニング

第I部では、パフォーマンス・チューニングの概要を説明します。

この部の構成は、次のとおりです。

- 第1章「パフォーマンス・チューニングの概要」

1 パフォーマンス・チューニングの概要

この章では、パフォーマンス・チューニングの概要を説明します。この章には、次の項があります。

- パフォーマンス・チューニングの概要

- パフォーマンス・チューニング機能およびツールの概要

1.1 パフォーマンス・チューニングの概要

このガイドは、Oracle Databaseのパフォーマンス・チューニングに関する情報を提供します。この項には次の項目があります。

- パフォーマンス計画

- インスタンスのチューニング

- SQLチューニング

関連項目:
Oracle Enterprise Managerを使用してデータベースのパフォーマンスをチューニングする方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

1.1.1 パフォーマンス計画

このガイドの他の部分に進む前に第II部「パフォーマンス計画」のすべての項目をお読みください。オラクル社では、長年にわたる設計およびパフォーマンス経験に基づき、パフォーマンスに関する方法論を設計しました。第II部では、システム・パフォーマンスを大幅に改善できるアクティビティについて説明します。内容は次のとおりです。

- 投資の選択肢について

- スケーラビリティについて

- システム・アーキテクチャ

- アプリケーション設計の原則

- ワークロードのテスト、モデル化および実装

- 新規アプリケーションのデプロイ

1.1.2 インスタンスのチューニング

第III部「インスタンスのパフォーマンスの最適化」では、Oracleデータベース・インスタンスのチューニングおよび最適化に関連のある要素について説明します。

インスタンスのチューニングを検討する場合、データベースの初期の設計で、パフォーマンスの問題の原因となるボトルネックを回避するよう注意します。さらに、次の点も考慮する必要があります。

- データベース構造体へのメモリーの割当て

- データベースの様々な部分のI/O要件の判断

- データベースのパフォーマンスを最適化するためのオペレーティング・システムのチューニング

データベース・インスタンスをインストールおよび構成した後、パフォーマンス関連の問題をチェックするために動作しているデータベースを監視する必要があります。

1.1.2.1 パフォーマンスの原理

パフォーマンス・チューニングでは、システムの初期構成に対して異なる(ただし関連性がある)方法を必要とします。システムの構成では、初期システムの構成が機能的なものになるように整理された手順に従ってリソースを割り当てます。

チューニングを開始するには、最も影響のあるボトルネックを識別し、適切な変更を行ってそのボトルネックの影響を低減するかまたは排除します。チューニングは通常、システムが本番開始前か、または稼働状態になった後で事後的に行われます。

1.1.2.2 ベースライン

チューニングでは、実証されたパフォーマンス・ベースラインを使用して、パフォーマンスの問題が生じたときに比較するのが最も効果的な方法です。データベース管理者(DBA)の多くは、自分のシステムを熟知し、ピークの使用期間を簡単に識別できます。たとえば、ピーク期間は10.00amから12.00pmである場合、また1.30pmから3.00pmである場合もあります。これには、深夜の12.00amから6.00amまでのバッチ・ウィンドウが含まれることがあります。

サイトでこのようなピーク時間帯を識別し、このような高負荷の時間帯のパフォーマンス・データを収集するモニタリング・ツールをインストールすることが重要です。アプリケーションがQAサイクル中の初期のトライアル段階にある時点から、データ収集を構成することが最適です。それ以外の場合は、システムが最初に稼働したときに、このデータ収集を構成する必要があります。

収集されたベースライン・データには、次の内容が含まれていることが理想的です。

- アプリケーション統計(トランザクション・ボリューム、レスポンス時間)

- データベース統計

- オペレーティング・システム統計

- ディスクI/O統計

- ネットワーク統計

自動ワークロード・リポジトリでは、ベースラインは将来比較するために保持されるスナップショットの範囲により識別されます。「自動ワークロード・リポジトリの概要」を参照してください。

1.1.2.3 症状および問題点

パフォーマンス・チューニングの一般的な誤りは、ある問題の症状を現実の問題自体であると思い違いをすることです。多くのパフォーマンス統計はこの症状を示すこと、およびこの症状を識別することが修正を実施するために十分なデータではないことを認識することが重要です。たとえば、次のようにします。

- 低速な物理I/O
一般に、この原因はディスクの構成が適切ではないことにあります。しかし、チューニングが適切ではないSQLから発行された、これらのディスク上の大量の不要な物理I/Oが原因になっている可能性もあります。

- ラッチの競合
インスタンスを再構成して、ラッチの競合をチューニングできることはほとんどありません。むしろ、ラッチの競合は通常、アプリケーションの変更により解決されます。

- 過剰なCPU使用率
過剰なCPU使用率は通常、システム上にアイドル状態のCPUがほとんどないことを意味します。この原因として、システムのサイズ設定が不適切であること、SQL文がチューニングされていないこと、またはアプリケーション・プログラムが不十分である可能性があります。

1.1.2.4 チューニングの時期

チューニングには次の2種類があります。

- プロアクティブな監視

- ボトルネックの解消

1.1.2.4.1 プロアクティブな監視

プロアクティブな監視は通常、定期的にスケジュールされた間隔で行われます。この場合、システム動作とリソースの使用量が変化したかどうかを識別するために複数のパフォーマンス統計が調べられます。プロアクティブな監視は、プロアクティブなチューニングとも考えられます。

通常は、進行中の重大な問題が監視により明らかにならないかぎり、監視によりシステムの構成が変化することはありません。状況によっては、経験豊富なパフォーマンス・エンジニアが統計のみで潜在的な問題点を識別できますが、通常はパフォーマンスの低下を伴います。

明らかなパフォーマンスの低下がないときに、事前のアクションとしてシステムを試行したり微調整することは危険なアクティビティであり、不必要にパフォーマンスを低下させる可能性があります。システムを微調整することは事後チューニングと考えられ、事後チューニングの手順に従う必要があります。

監視は通常、より大規模な容量計画の調査の一環です。容量計画ではリソース使用状況を調べて、さらにアプリケーションが使用されている方法の変化、およびアプリケーションがデータベース・リソースとホスト・リソースを使用している方法の変化を調べます。

1.1.2.4.2 ボトルネックの解消

チューニングは通常、パフォーマンスの問題の修正を意味します。ただし、チューニングは、分析、設計、コーディング、生産およびメンテナンスの各段階を通じて、アプリケーションのライフサイクルの一部である必要があります。多くの場合、チューニング段階は、データベースが稼働段階に入るまで残されます。この時点で、チューニングは事後対応処理になり、最も重要なボトルネックを識別し、修正します。

チューニングの目的は通常、リソース使用量を減らしたり、操作を完了する経過時間を減らすことにあります。いずれの場合も、目標は特定のリソースの有効利用を向上することにあります。一般に、パフォーマンスの問題は特定のリソースの過剰使用によって発生します。リソースの過剰使用は、システムのボトルネックです。ボトルネックと潜在的な修正を識別するには、様々な複数の段階があります。それらについては次の項で説明します。

競合の様々な形態は症状であり、次のいずれかを変更することで修正できることに注意してください。

- アプリケーションまたはアプリケーションの使用方法の変更

- Oracleの変更

- ホスト・ハードウェア構成の変更

多くの場合、ボトルネックを解決する最も効果的な方法は、アプリケーションを変更することです。

1.1.3 SQLチューニング

このガイドの第IV部「SQL文の最適化」では、SQL文のチューニングおよび最適化のプロセスについて説明します。

SQLでは、問合せを発行し、データが戻されるため、多くのアプリケーション・プログラマはSQLをメッセージ言語として認識しています。しかし、クライアント・ツールでは非効率的なSQL文が生成される場合がよくあります。したがって、データベースSQL処理エンジンについて理解することは、最適なSQLを作成するために必要です。このことは特に、大量トランザクション処理システムについて言えます。

一般に、OLTPアプリケーションから発行されるSQL文では、一度にわずかな行しか実行されません。索引が正確に必要な行を示す場合、正確な計画を作成して、可能な最短のパスを使用して効率的に行にアクセスできます。意思決定支援システム(DSS)環境では、表の行のほとんどにアクセスする場合が多いため、選択性は重要視されません。そのような状況では、全表スキャンが一般的であり、索引は使用しません。このマニュアルは、主として、OLTPタイプのアプリケーションを中心に説明しています。DSS環境、およびDSSとOLTPの混合環境の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

1.1.3.1 問合せオプティマイザおよび実行計画

OracleデータベースでSQL文を実行すると、問合せオプティマイザは、問合せに指定されたオブジェクトの参照および条件に関連する様々な要素を考慮した後、最も効率的な実行計画を判断します。この判断は、SQL文の処理で重要なステップであり、実行時間が大きく変化します。

評価プロセスでは、問合せオプティマイザにより、システム上に収集された統計が確認され、最適なデータ・アクセス・パスおよびその他の考慮事項が判断されます。問合せオプティマイザの実行計画を、SQL文に挿入されたヒントで上書きできます。

1.2 パフォーマンス・チューニング機能およびツールの概要

効果的なデータの収集と解析は、パフォーマンスの問題を識別して修正するために不可欠です。Oracle Databaseには、パフォーマンス・エンジニアがデータベースのパフォーマンスに関する情報の収集に使用できる様々なツールがあります。データの収集に加え、パフォーマンスの監視、問題の診断およびアプリケーションのチューニングのためのツールもあります。

Oracle Databaseの収集および監視機能は、大部分が自動で動作し、Oracleバックグラウンド・プロセスによって管理されます。自動統計収集機能と自動パフォーマンス機能を使用可能にするには、STATISTICS_LEVEL初期化パラメータをTYPICALまたはALLに設定する必要があります。収集ツールおよびチューニング・ツールからの出力の管理および表示には、Oracle Enterprise Manager、またはAPIとビューを使用します。使いやすさと様々な自動化された監視および診断ツールの利点から、Oracle Enterprise Manager Database Controlをお薦めします。

関連項目:

- Oracle Enterprise Managerを使用してOracle Databaseを管理する方法は、『Oracle Database 2日でデータベース管理者』を参照してください。

- Oracle Enterprise Managerを使用してデータベースのパフォーマンスをチューニングする方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

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

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

1.2.1 自動パフォーマンス・チューニング機能

Oracle Databaseの自動パフォーマンス・チューニング機能には、次のものがあります。

- 自動ワークロード・リポジトリ(AWR)では、問題の検出および自己チューニングを目的として、パフォーマンス統計が収集、処理および保守されます。「自動ワークロード・リポジトリの概要」を参照してください。

- 自動データベース診断モニター(ADDM)では、Oracleデータベースにおいて考えられるパフォーマンス上の問題について、AWRによって収集された情報が分析されます。「自動データベース診断モニターの概要」を参照してください。

- SQLチューニング・アドバイザでは、SQL文を変更しないでSQL文を素早く効率的に最適化することが可能です。「SQLチューニング・アドバイザによる事後対応のチューニング」を参照してください。

- SQLアクセス・アドバイザでは、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログについてアドバイスが提供されます。SQLアクセス・アドバイザの詳細は、「自動SQLチューニング機能」および「SQLアクセス・アドバイザの概要」を参照してください。

- エンドツーエンド・アプリケーションのトレースでは、特定のユーザー、サービスまたはアプリケーション・コンポーネントに関して、システム上の過剰なワークロードが識別されます。「エンドツーエンド・アプリケーションのトレース」を参照してください。

- 障害となっている問題が検出されると、サーバー生成アラートにより自動的に通知が提供されます。サーバー生成アラートを使用したデータベース操作の監視方法は、『Oracle Database管理者ガイド』を参照してください。

- Oracle Enterprise Managerからその他のアドバイザを起動できます。たとえば、メモリー・アドバイザは、インスタンスのメモリーを最適化します。通常、メモリー・アドバイザが使用されるのは、データベースの自動メモリー管理が設定されていない場合です。その他のアドバイザは、平均リカバリ時間(MTTR)の最適化、セグメントの縮小およびUNDO表領域の設定に使用されます。Oracle Enterprise Managerで使用可能なアドバイザの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

- Oracle Enterprise Managerの「パフォーマンス」ページには、リアルタイム監視および診断に関するホスト、インスタンス・サービス時間およびスループット情報が表示されます。このページは、選択した間隔で自動的に、または手動でリフレッシュするように設定できます。データベースの「パフォーマンス」ページの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

1.2.2 その他のOracle Databaseツール

この項では、パフォーマンス問題の調査に使用できるその他のOracle Databaseツールについて説明します。

1.2.2.1 V$パフォーマンス・ビュー

V$ビューは、すべてのOracle Databaseパフォーマンス・チューニング・ツールで使用されるパフォーマンスの情報ソースです。V$ビューは、インスタンスの起動時に初期化されたメモリー構造に基づいています。メモリー構造およびそれらを表すビューは、インスタンスの存続期間中、Oracle Databaseにより自動的に管理されます。V$パフォーマンス・ビューを使用して問題を診断しチューニングする方法は、第10章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。

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

注意:
パフォーマンス・データの収集には自動ワークロード・リポジトリを使用することをお薦めします。これらのツールは、パフォーマンスの分析に必要なすべてのデータを収集するように設計されています。

第II部

パフォーマンス計画

第II部では、安定したアプリケーションを設計し、統計情報を使用してアプリケーションのパフォーマンスを監視して、Oracle Databaseのパフォーマンスを向上させる方法について説明します。Oracleのパフォーマンス改善方法と、パフォーマンスの緊急の問題に対処する方法についても説明します。

この部の構成は、次のとおりです。

- 第2章「パフォーマンスを考慮した設計と開発」

- 第3章「パフォーマンス改善方法」

2 パフォーマンスを考慮した設計と開発

最適なシステム・パフォーマンスは設計段階で決まり、その効果は使用しているシステムが存続するかぎり持続します。初期の設計段階でパフォーマンス問題を慎重に検討すると、本番環境でのチューニングが容易になります。

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

- オラクル社の新しい方法論

- 投資の選択肢について

- スケーラビリティについて

- システム・アーキテクチャ

- アプリケーション設計の原則

- ワークロードのテスト、モデル化および実装

- 新規アプリケーションのデプロイ

2.1 オラクル社の新しい方法論

コンピュータ・システムの規模が拡大して複雑になり、ビジネス・アプリケーションでのインターネットの役割が重要になるに従い、システムのパフォーマンスはますます重要になっています。オラクル社では、この状況にあわせて、設計およびパフォーマンスに関する長年の経験に基づいてパフォーマンス方法論を作成しました。この方法論は、システム・パフォーマンスを大幅に向上させる、明瞭で簡潔なアクティビティについて説明したものです。

パフォーマンス計画は、その効果によって異なります。業務システムや意思決定支援システムなどのようにシステムの目的が異なると、求められるパフォーマンス・スキルも異なります。このマニュアルでは、データベース設計者、管理者またはパフォーマンス・エンジニアが重点的に考慮する必要がある事柄について説明します。

システムのパフォーマンスは、設計してシステムに組み込むものです。偶然にパフォーマンスがよくなるわけではありません。パフォーマンスの問題は、通常、システム・リソースの競合、またはシステム・リソースを使い切ったことが原因で発生します。システム・リソースを使い切ると、システムを拡張してパフォーマンス・レベルを向上させることができません。ここで説明する新しいパフォーマンス方法論は、データベースの慎重な計画と設計に基づいており、システム・リソースを使い切ったことが原因で停止時間が発生するのを防止します。リソースの競合を除去することによって、ビジネス要件を満たすレベルまでシステムをスケーラブルにすることができます。

2.2 投資の選択肢について

高性能のプロセッサ、メモリーおよびディスク・ドライブが比較的安価に入手できることから、安易なシステム・リソースの追加購入によって、パフォーマンスを改善しようとする傾向があります。多くの場合、新しいCPU、メモリーまたはディスク・ドライブの増設によって、確かにパフォーマンスは一時的には改善されます。しかし、ハードウェア増設によるパフォーマンスの改善は、目の前の問題の短期的解決にすぎません。アプリケーションに対する需要と負荷が増加し続けると、すぐに同じ問題に直面する可能性があります。

状況によっては、ハードウェアを増設してもシステムのパフォーマンスがまったく改善されない場合もあります。システム設計が不適切な場合、追加のハードウェアをいくつ割り当ててもパフォーマンスは改善されません。ハードウェアを追加購入する前に、アプリケーション内にシリアライズやシングル・スレッドがないことを確認してください。長期的には、各ビジネス・トランザクションで使用する物理リソース数の観点からみて、アプリケーションの効率を上げるほうが一般的には効果的です。

2.3 スケーラビリティについて

スケーラブルという用語は、開発環境の様々な状況で使用されます。次の項では、アプリケーション設計者とパフォーマンス・エンジニアを対象にしたスケーラビリティについて説明します。

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

- スケーラビリティとは

- システムのスケーラビリティ

- スケーラビリティを妨げる要因

2.3.1 スケーラビリティとは

スケーラビリティとは、より多くのワークロードを処理するためのシステムの能力で、それと比例してシステム・リソースの使用が増大します。つまり、スケーラブルなシステムでは、ワークロードが2倍になると、使用するシステム・リソースも2倍になります。これは当たり前のようですが、システム内で競合が発生すると、元のワークロードに対し、リソースの使用が2倍よりも多くなる場合があります。

リソースの競合によってスケーラビリティが低くなる例を次に示します。

- ユーザー数の増加に伴い、アプリケーションでかなりの同時実行性管理が要求される場合

- ロック・アクティビティが増加した場合

- データ整合性に関するワークロードが増加した場合

- オペレーティング・システムのワークロードが増加した場合

- データ量の増加に伴い、トランザクションでデータ・アクセスの増加が要求される場合

- SQLと索引の不適切な設計が原因で、同じ戻り行数に対する論理I/O数が増加した場合

- データベース・オブジェクトのメンテナンス時間が長くなったことで、可用性が低下した場合

アプリケーションのワークロードが増加してもこれ以上のスループットの向上は不可能という点までシステム・リソースを使い切った場合、そのアプリケーションは拡張性がありません。このようなアプリケーションでは、スループットが固定化し、レスポンス時間が長くなります。

リソースを使い切った例を次に示します。

- ハードウェアを使い切った場合

- 大量トランザクションでの表スキャンによって、ディスクI/O不足が発生する場合

- 過剰なネットワーク・リクエストによって、ネットワークとスケジューリングにボトルネックが発生する場合

- メモリー割当てによって、ページングとスワッピングが発生する場合

- プロセスやスレッドの過剰な割当てによって、オペレーティング・システムのスラッシングが発生する場合

このことから、アプリケーション設計者は、ユーザー数やデータ量に関係なく同一リソースを使用するように設計し、限界を超える負荷をシステム・リソースに与えないようにする必要があります。

2.3.2 システムのスケーラビリティ

インターネット経由でアクセスできるアプリケーションでは、パフォーマンスや可用性の要件がさらに複雑になります。インターネット専用に設計および作成されたアプリケーションもありますが、一般会計アプリケーションなどの典型的なバック・オフィス・アプリケーションであっても、データの一部またはすべてをオンラインで利用できるようにすることが必要な場合があります。

インターネット時代のアプリケーションの特徴は、次のとおりです。

- 1日24時間、1年365日の可用性

- 同時ユーザー数が予測不可能で正確な把握が困難

- 容量の計画が困難

- あらゆるタイプの問合せが選択可能

- 多層アーキテクチャ

- ステートレスなミドルウェア

- 短い開発期間

- 最小限のテスト時間

図2-1は、需要が増大するときの典型的なワークロード成長曲線を示しています。アプリケーションは、ワークロードの増大に伴い拡張できる必要があります。また、増大する需要をサポートするためにハードウェアが追加されたときにも拡張できる必要があります。設計に失敗すると、ハードウェア・リソースの増設や再設計に関係なく、実装が限界に達する可能性があります。

図2-1 ワークロード成長曲線

アプリケーションは非常に短期間での開発が要求され、テストや評価の時間も限定されています。しかし、一般的に、不適切な設計は、後でシステムの再構築および再実装が必要になることを意味します。アーキテクチャや実装に既知の制限があるアプリケーションをインターネット上にデプロイした場合、ワークロードが需要予測を超過すると、実際に障害が発生する可能性があります。ビジネスの観点からは、低いパフォーマンスは顧客を失うことにつながります。Webユーザーの場合、7秒以内にレスポンスがないと、ユーザーの興味は二度と喚起できません。

多くの場合、新規の実装に移行するためにシステムを停止する間のコストも含めて、システムを再設計するコストは、最初からシステムを適切に構築する場合のコストを上回ります。ここでの教訓は単純明快です。開発の当初からスケーラビリティに留意して設計と実装を行うということです。

2.3.3 スケーラビリティを妨げる要因

アプリケーションを作成するとき、設計者とアーキテクトは、可能なかぎり完全なスケーラビリティに近づけることを目指す必要があります。これは線形のスケーラビリティと呼ばれ、システムのスループットがCPUの数に比例するものです。

線形のスケーラビリティにすることは、設計者の制御の及ばない部分があるため、実際には不可能です。しかし、アプリケーションの設計や実装に可能なかぎりスケーラブルにしておくと、現在も、将来においても、ハードウェア・コンポーネントの拡張やCPUテクノロジの発展とともにパフォーマンス目標を達成できます。

線形のスケーラビリティを妨げる要因としては次のものが考えられます。

- 不適切なアプリケーションの設計、実装および構成
アプリケーションは、スケーラビリティに最も大きく影響します。たとえば、次のようにします。

- スキーマ設計が不適切であると、SQLにコストがかかり、拡張性を持ちません。

- トランザクション設計が不適切であると、ロックおよびシリアライズの問題が発生します。

- 接続管理が不適切であると、レスポンス時間が長くなり、システムの信頼性が低下します。

問題となるのは、設計のみではありません。アプリケーションの物理的な実装が弱点になる場合があります。たとえば、次のようにします。

- システムが誤ったI/O方針のまま本番環境で使用される場合。

- テスト時に生成された実行計画とは異なる実行計画が本番環境で使用される場合。

- 実行時のメモリーの解放を十分に考慮せずに、大量のメモリー割当てを行うメモリー集中型アプリケーションで、メモリーが過剰に使用される可能性がある場合。

- 非効率的なメモリー使用やメモリー・リークによって、動作中の仮想メモリー・サブシステムに高いストレスがかかる場合。このようなストレスは、パフォーマンスや可用性に影響を与えます。

- ハードウェア・コンポーネントの誤ったサイズ指定
ハードウェア価格の低下に伴い、どのハードウェア・コンポーネントについても容量計画が不適切で問題になるということは少なくなっています。ただし、容量が大きすぎると、システムでワークロードが増大したときに、スケーラビリティの問題が隠されてしまう場合があります。

- ソフトウェア・コンポーネントの制限
すべてのソフトウェア・コンポーネントに、スケーラビリティおよびリソース使用上の制限があります。このことは、アプリケーション・サーバー、データベース・サーバーおよびオペレーティング・システムでも同様です。アプリケーションの設計では、ソフトウェアの処理能力を超えた要求をしないでください。

- ハードウェア・コンポーネントの制限
ハードウェアは、完全にはスケーラブルになりません。ほとんどのマルチプロセッサ・コンピュータでは、限られた数のCPUでほぼ線形の拡張性を達成できますが、ある数を超えると、CPUの追加でパフォーマンスが全体的には向上しても、その数に見合った向上はありません。さらに続けて追加していくと、ある時点からパフォーマンスは向上しなくなり、むしろ低下する場合もあります。この動作は、ワークロードとオペレーティング・システムの設定に深く関連しています。

注意:
前述の要因は、スケーラブルでないシステムのチューニングにおいてオラクル社のサーバー・パフォーマンス・グループが得た経験を基にしたものです。

2.4 システム・アーキテクチャ

システムのアーキテクチャには、主要な部分が2つあります。

- ハードウェア・コンポーネントとソフトウェア・コンポーネント

- 要件に合った正しいシステム・アーキテクチャの構成

2.4.1 ハードウェア・コンポーネントとソフトウェア・コンポーネント

この項では、次の内容を説明します。

- ハードウェア・コンポーネント

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

2.4.1.1 ハードウェア・コンポーネント

今日の設計者とアーキテクトは、多層環境の各層でハードウェアのサイズ指定と容量計画を行う必要があります。バランスの取れた設計を実現するのは、アーキテクトの責任です。これは、橋の設計に似ています。橋の設計者は、橋に関する様々なペイロードや構造上の要件をすべて考慮する必要があります。橋の強度は、最も弱いコンポーネントの強度にしかなりません。このため、橋は、すべてのコンポーネントがその設計上の限界に同時に達するように、バランスよく設計されています。

ハードウェアには、主に次のコンポーネントが含まれます。

- CPU

- メモリー

- I/Oサブシステム

- ネットワーク

2.4.1.1.1 CPU

CPUは1つ以上使用されており、その処理能力は、携帯端末に見られるような単純なCPUのものから高性能サーバーのCPUのものまで様々です。他のハードウェア・コンポーネントのサイズは、通常、システム上のCPUの倍数になります。第9章「オペレーティング・システム・リソースの管理」を参照してください。

2.4.1.1.2 メモリー

データベース・サーバーとアプリケーション・サーバーには、データをキャッシュしたり、長時間のディスク・アクセスを避けるために、十分な量のメモリーが必要です。第7章「メモリーの構成および使用方法」を参照してください。

2.4.1.1.3 I/Oサブシステム

I/Oサブシステムは、クライアントPCのハード・ディスクから高性能なディスク・アレイまで様々あります。ディスク・アレイは、毎秒数千回のI/Oを実行できるうえ、複数のI/Oパスおよびホット・プラグ可能なミラー化ディスクという冗長性から、可用性も得られます。第8章「I/O構成および設計」を参照してください。

2.4.1.1.4 ネットワーク

システム内のコンピュータは、すべて、モデム回線から高速社内LANに到るまでのネットワークに接続しています。ネットワーク仕様に関する主な考慮点は、帯域幅(通信量)と待機時間(速度)です。

2.4.1.2 ソフトウェア・コンポーネント

コンピュータに共通のハードウェア・コンポーネントがあるように、アプリケーションにも共通の機能コンポーネントがあります。ソフトウェアの開発を機能コンポーネントごとに分割することで、アプリケーションの設計やアーキテクチャがより理解しやすくなります。システムのコンポーネントの中には、アプリケーションの実装の高速化や、共通コンポーネントの再作成の防止のために購入された既成のソフトウェアによって実行されるものもあります。

ソフトウェア・コンポーネントとハードウェア・コンポーネントの違いは、ハードウェア・コンポーネントが1つのタスクしか実行しないのに対して、ソフトウェアはその1つ1つが様々なソフトウェア・コンポーネントの役割を実行できるということです。たとえば、ディスク・ドライブはデータの格納と取出ししか行いませんが、クライアント・プログラムはユーザー・インタフェースを管理し、ビジネス・ロジックを実行できます。

ほとんどのアプリケーションに、次に関するコンポーネントが含まれています。

- ユーザー・インタフェースの管理

- ビジネス・ロジックの実装

- ユーザー・リクエストとリソース割当ての管理

- データおよびトランザクションの管理

2.4.1.2.1 ユーザー・インタフェースの管理

ユーザー・インタフェースは、アプリケーション・ユーザーの目に触れることが最も多いコンポーネントです。次のような機能があります。

- ユーザーへの画面の表示

- ユーザー・データの収集とビジネス・ロジックへのデータの転送

- データ入力の検証

- アプリケーションのレベル間または状態間のナビゲーション

2.4.1.2.2 ビジネス・ロジックの実装

このコンポーネントは、アプリケーション機能の中心となるコア・ビジネス・ルールを実装します。このコンポーネントでのエラーは、修復に相当なコストを要する場合があります。このコンポーネントは、宣言型アプローチとプロシージャ型アプローチの組合せで実装されます。宣言アクティビティの例としては、一意キーと外部キーの定義があります。また、プロシージャ・ベースのロジックの例としては、値引計画の実装があります。

このコンポーネントの一般的な機能は、次のとおりです。

- リレーショナル表構造へのデータ・モデルの移行

- リレーショナル表構造での制約の定義

- ビジネス・ルールを実装するプロシージャ型ロジックのコーディング

2.4.1.2.3 ユーザー・リクエストとリソース割当ての管理

このコンポーネントは、すべてのソフトウェアに実装されます。ただし、アプリケーション設計の影響を受けるリクエストやリソースがある一方で、影響を受けないリクエストやリソースもあります。

マルチ・ユーザー・アプリケーションでは、ユーザー・リクエストによるリソース割当てのほとんどは、データベース・サーバーまたはオペレーティング・システムで処理されます。ただし、ユーザー数や使用パターンが不明または急増している大規模アプリケーションの場合、システム・アーキテクトはどのソフトウェア・コンポーネントも過負荷や不安定にならないように事前に対処する必要があります。

このコンポーネントの一般的な機能は、次のとおりです。

- データベースとの接続管理

- 効率的なSQLの実行(カーソルとSQLの共有)

- クライアント状態情報の管理

- ハードウェア・リソース間でのユーザー・リクエストのロード・バランシング

- ハードウェアおよびソフトウェア・コンポーネントの操作目標の設定

- タスクの非同期実行のための永続キューイング

2.4.1.2.4 データおよびトランザクションの管理

このコンポーネントは、主にデータベース・サーバーとオペレーティング・システムが管理します。

このコンポーネントの一般的な機能は、次のとおりです。

- ロックとトランザクション・セマンティクスを使用した、データへの同時アクセス

- 索引およびメモリー・キャッシュを使用した、データへの最適化アクセス

- ハードウェア障害時のデータ変更の記録

- データに対して定義されているルールの適用

2.4.2 要件に合った正しいシステム・アーキテクチャの構成

初期のシステム・アーキテクチャを構成する作業は、反復的な処理です。システム・アーキテクトは、予算やスケジュールの制約内でシステム要件を満たす必要があります。対話型ユーザーがデータベースの内容に基づいてビジネスの取引や意思決定を行うシステムの場合、ユーザー要件が主体のアーキテクチャになります。システム上に対話型ユーザーがほとんどいない場合は、プロセス主体のアーキテクチャになります。

対話型ユーザー・アプリケーションの例を、次に示します。

- 経理アプリケーションや会計帳簿アプリケーション

- 注文入力システム

- 電子メール・サーバー

- Webベースの小売販売アプリケーション

- 取引システム

プロセス主体のアプリケーションの例を、次に示します。

- 公共料金支払システム

- 不正検出システム

- ダイレクト・メール

多くの点で、プロセス主体のアプリケーションのほうが、ユーザー・インタフェース要素がないのでマルチ・ユーザー・アプリケーションよりも設計が容易です。しかし、目的がプロセス指向であるため、大量のデータや様々な成功要因の扱いに慣れていないシステム・アーキテクトは混乱することがあります。プロセス主体のアプリケーションでは、ユーザー・ベースのアプリケーションとデータ・ウェアハウス・アプリケーションの両方で使用されるスキルを利用します。したがって、このマニュアルでは、対話型ユーザー向けの新しいシステム・アーキテクチャについて、重点的に説明します。

注意:
システム・アーキテクチャの生成は、決定論的なプロセスではありません。ビジネス要件、テクノロジの選択肢、既存のインフラストラクチャやシステム、さらに予算や人員などの実際の物理リソースなどを慎重に考慮する必要があります。

次の質問事項は、システム・アーキテクチャの完全なガイドではありませんが、システム・アーキテクチャに関する思考力を高めます。これらの質問では、アーキテクチャ、実装しやすさ、さらにシステムの全体的なパフォーマンスと可用性に対して、ビジネス要件がどのように影響を及ぼすかを示しています。たとえば、次のようにします。

- 何人のユーザーをサポートするシステムが必要ですか。
ほとんどのアプリケーションは、次のいずれかのカテゴリに該当します。

- あまり使用されない専用のコンピュータでごく少数のユーザーをサポートする場合
このタイプのアプリケーションでは、通常、ユーザーは1人です。この場合のアプリケーション設計の重点は、レスポンス時間を短くし、しかもアプリケーションの管理を最小限に抑えることで、シングル・ユーザーの生産性をできるだけ高くすることにあります。このようなアプリケーションのユーザーは、相互に介入することはほとんどなく、リソースの競合も最小限に抑えられます。

- 中規模から大規模の数の社内ユーザーが共有アプリケーションを使用する場合
このタイプのアプリケーションでは、ユーザー数は、社内でシステムを実際に使用してビジネスを行う従業員の数に限定されます。したがって、ユーザー数は予測可能です。ただし、信頼性のあるサービスを提供することが、ビジネスにとっては必須です。ユーザーはリソースを共有する必要があるため、アプリケーションを設計する際には、大量のシステム・ロード下でのレスポンス時間、各セッションで使用されるリソースの増加および将来の拡張のための余地に重点を置きます。

- 無数のユーザーがインターネット上に存在する場合
このタイプのアプリケーションでは、すべてのシステム・コンポーネントがそれぞれの限界を超えないように設計する必要があります。ボトルネックが作成されると、システムが停止するか不安定になります。このようなアプリケーションでは、複合的なロード・バランシング、ステートレスなアプリケーション・サーバーおよび効率的なデータベース接続管理が必要です。さらに、システムの過負荷が原因でユーザー・リクエストが満たされない場合にユーザーがフィードバックを得られるように、統計情報およびガバナーを使用します。

- ユーザーとの対話方式は何ですか。
ユーザー・インタフェースの選択肢は、単純なWebブラウザからカスタム・クライアント・プログラムまで様々です。

- ユーザーはどこに位置しますか。
ユーザー間の距離は、ネットワーク待機時間に対処するためのアプリケーションの設計方法に影響します。また、ユーザーの位置は、1日の中でピークの時間帯、つまりバッチ機能やシステム・メンテナンス機能を実行できない時間帯の決定にも影響を与えます。

- ネットワーク速度はどの程度ですか。
ネットワーク速度は、データ量に影響を与え、アプリケーション・サーバーやデータベース・サーバーとのユーザー・インタフェースの対話特性にも影響を与えます。対話主体のユーザー・インタフェースでは、キー・ストロークごとまたはフィールド・レベルの妥当性チェックごとにバックエンド・サーバーと通信します。対話が少ないインタフェースは、画面ごとに送受信を行うモデルで機能します。通信速度が遅いネットワークでは、対話主体のユーザー・インタフェースを使用しても高速のデータ入力速度は実現できません。

- ユーザーがアクセスするデータ量はどれくらいで、そのデータの中で読取り専用データが占める割合はどの程度ですか。
オンラインでの問合せのデータ量は、表や索引の設計からプレゼンテーション層にいたる設計のあらゆる局面に影響を与えます。データベースのサイズによってユーザーのレスポンス時間が影響されないように設計する必要があります。アプリケーションが主として読取り専用の場合は、アプリケーション・サーバーのローカル・キャッシュへのレプリケーションとデータ配分が有効な選択肢になります。また、これにより、主要トランザクション・サーバーでのワークロードが削減されます。

- ユーザー・レスポンス時間の要件は何ですか。
ユーザー・タイプに関する考慮が重要です。ユーザーが経営者で、瞬時に意思決定を行うために正確な情報を必要とする場合は、ユーザー・レスポンス時間の妥協は許されません。データ入力操作を行うユーザーなど、他のタイプのユーザーの場合は、それほど高いパフォーマンスは必要としません。

- ユーザーは1日24時間のサービスを期待していますか。
取引が1日24時間行われている今日のインターネット・アプリケーションの場合、24時間連続稼働は必須です。ただし、1つのタイム・ゾーンでのみ稼働する企業システムの場合は、終業後にシステムを停止できます。この終業後の停止時間を利用して、バッチ処理やシステム管理を実行できます。このような場合は、連続稼働システムでない方が経済的です。

- 変更はすべてリアルタイムで行う必要がありますか。
ユーザーのレスポンス時間内にトランザクションを実行する必要があるか、またはキューに入れて非同期で実行できるかを判断することが重要です。

次の質問は二次的な質問です。これらは設計にも影響を及ぼしますが、予算や実装しやすさの面に、より大きく影響します。たとえば、次のようにします。

- データベースの規模はどの程度ですか。
データベースの規模は、データベース・サーバーのサイズ決定に影響します。大規模データベースを使用するサーバーでは、ワークロードから判断されるサイズよりも大型のコンピュータを用意することが必要になる場合があります。これは、大規模データベースに伴う管理オーバーヘッドが、主としてデータベース・サイズに比例するためです。表および索引が大きくなると、許容できる時間内に表を再編成したり索引を作成する必要があるため、必要なCPUの数もそれに比例して増加します。

- ビジネス・トランザクションで必要とされるスループットはどの程度ですか。

- 可用性に関する要件は何ですか。

- このアプリケーションを作成して管理するためのスキルはありますか。

- 予算上の制約からどのような妥協を求められますか。

2.5 アプリケーション設計の原則

この項では、アプリケーション作成時に必要な次の設計上の決定事項を説明します。

- アプリケーション設計の簡潔さ

- データのモデル化

- 表および索引の設計

- ビューの使用

- SQLの実行効率

- アプリケーションの実装

- アプリケーション開発の傾向

2.5.1 アプリケーション設計の簡潔さ

アプリケーションは、設計と開発を伴う他の製品となんら変わりはありません。通常、適切に設計された構造、コンピュータおよびツールは、信頼性があり、使用方法やメンテナンスが容易で、コンセプトもシンプルです。ごく一般的に表現すると、設計が適切に見えるものは、実際に適切に設計されているといえます。アプリケーションの作成では、この原則を常に覚えておいてください。

次の設計の問題を考慮してください。

- 表の設計が複雑で、誰も完全に理解できない場合、その表の設計は不適切であるといえます。

- SQL文が非常に長く、どのオプティマイザでもリアルタイムに効率よく最適化できない場合、そのSQL文、基になるトランザクションまたは表の設計が不適切であるといえます。

- 表に索引があり、同じ列が繰り返し参照される場合は、索引の設計が不適切であるといえます。

- 問合せを送信したときに、オンライン・ユーザーにとって必要な迅速なレスポンス能力がなかった場合は、ユーザー・インタフェースまたはトランザクションの設計が不適切であるといえます。

- ソフトウェアの多くの層で、データベース・コールがアプリケーション・ロジックから離れて抽象化される場合は、ソフトウェアの開発方法が不適切であるといえます。

2.5.2 データのモデル化

データのモデル化は、リレーショナル・アプリケーションの適切な設計に重要です。モデル化によって、ビジネス・プラクティスを迅速に表現する必要があります。正しいデータ・モデルに関して様々な議論が展開される場合があります。重要なことは、最も頻繁に行われるビジネス・トランザクションの影響を受けるエンティティをモデル化の主な対象にすることです。モデル化フェーズでは、あまり重要でないデータ要素のモデル化に時間を取られることがあり、開発の準備期間が延長される結果になります。モデル化ツールを使用すると、スキーマ定義をすばやく生成できます。また、短期間でプロトタイプを作成する必要がある場合に便利です。

2.5.3 表および索引の設計

表の設計は、主に、主要トランザクションの柔軟性とパフォーマンスの間でバランスを取る作業です。データベースの柔軟性を保持しながら予想外のワークロードに対処できるようにするには、表の設計をデータ・モデルとほぼ同じようにする必要があり、最低でも第3正規形に正規化しておく必要があります。ただし、ユーザーが必要とする特定のトランザクションでは、パフォーマンス向上のために選択的な非正規化が求められることがあります。

この技法の例としては、事前に結合された表の格納、導出列の追加および集計値があります。Oracle Databaseでは、クラスタ化機能およびマテリアライズド・ビュー機能によって、集計データおよび事前結合データに関する多数のストレージ・オプションが提供されています。これらの機能によって、より簡潔な表の設計を最初から採用できます。

ここでも、最適のパフォーマンスを実現できるように、ビジネス上重要な表に重点的にリソースを使用する必要があります。重要でない表の場合は、アプリケーション開発を迅速に進めるためにも、設計に簡略な方法を採用できます。ただし、プロトタイプおよびテストの結果、重要でない表でパフォーマンスの問題が発生する場合は、ただちに設計を修正する必要があります。

索引の設計も、アプリケーション設計者が生成したSQLに基づく、主として反復的なプロセスです。ただし、主キー制約を適用する索引や個人名など既知のアクセス・パターンに対する索引を作成することから開始することも可能です。アプリケーションの開発が進み、実際のデータ量でテストを実行するときは、適切な索引を作成して特定の問合せのパフォーマンスを改善する必要があります。新しい索引を作成する際には、索引の設計に関する次の事項を検討してください。

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

- 異なる索引タイプの使用

- 索引のコストの算出

- 索引内のシリアライズ

- 索引内の列の順序付け

2.5.3.1 索引への列の追加または索引構成表の使用

問合せをスピードアップする簡単な方法の1つは、実行計画から表アクセスを排除して論理I/Oの数を減らすことです。これは、問合せによって参照されるすべての列を索引に追加することで実現できます。これらの列は、選択リスト列、および結合またはソートに必要な列です。この方法は、時間がかかるI/Oを削減して、オンライン・アプリケーションのレスポンス時間を短縮する場合に特に役立ちます。これは、適切なサイズのデータを使用してアプリケーションを初めてテストするときに最も効果を発揮します。

この技法を最も積極的に使用しているのが、索引構成表(IOT)の作成です。ただし、IOTのリーフ・サイズの増加がI/O削減効果を妨げないように注意する必要があります。

2.5.3.2 異なる索引タイプの使用

選択できる索引のタイプはいくつかあり、それぞれ特定の状況に応じた利点があります。各タイプの索引に関連したパフォーマンスの考慮点を、次のリストに示します。

2.5.3.2.1 Bツリー索引

標準的な索引タイプです。主キー索引および選択的な索引に最も適しています。連結索引として使用すると、索引列順にソートされたデータを取得するのにBツリー索引を使用できます。

2.5.3.2.2 ビットマップ索引

この索引は、カーディナリティが低いデータに適しています。この索引は、圧縮技法によって最小限のI/Oで多数のROWIDを生成できます。選択列以外の列に対するビットマップ索引を組み合せることによって、最小限のI/Oと多数のROWIDでAND演算とOR演算を効率よく実行できます。ビットマップ索引は、索引内で問合せを満たすことができるため、COUNT()を使用した問合せで特に効果的です。

2.5.3.2.3 ファンクション索引

この索引では、ベース・データ上のファンクションから導出された値に対するBツリー経由でアクセスできます。ファンクション索引ではNULLの使用に制限があり、問合せオプティマイザを使用可能にしておく必要があります。

ファンクション索引は、複合列への問合せで導出される結果を生成する場合や、データベースへのデータの格納方法における制限を克服する場合に、特に役立ちます。その例として、(販売価格 - 値引)×数量から算出された特定の値を超える注文の明細項目(表内の列)の問合せがあります。別の例としては、UPPERファンクションをデータに適用した、大/小文字を区別しない検索があります。

2.5.3.2.4 パーティション索引

グローバル索引のパーティション化によって、パーティション・プルーニングが索引アクセス内で発生し、I/Oを削減できます。レンジ・パーティション化またはリスト・パーティション化を適切に定義すると、正しい索引パーティションが高速で索引スキャンされるため、問合せ時間を大幅に短縮できます。

2.5.3.2.5 逆キー索引

この索引は、挿入アプリケーションでの索引のホット・スポットを除去するように設計されています。この索引は挿入パフォーマンスに優れていますが、索引レンジ・スキャンに使用できないという制限があります。

2.5.3.3 索引のコストの算出

索引構造の作成とメンテナンスにはコストがかかり、ディスク領域、CPUおよびI/O容量などのリソースを消費します。設計者は、索引のメンテナンスにかかるコストより、索引の使用による利点が上回るように設計する必要があります。

索引のメンテナンスにかかるコストを見積る簡単な目安があります。それは、索引キーに対してINSERT、DELETEまたはUPDATEを実行することでメンテナンスされる索引では、索引ごとに、表に対する実際のDML操作で使用されるリソースの3倍のリソースが必要になる、というものです。したがって、3つの索引を持つ表へのINSERTは、索引のない表へのINSERTよりも約10倍遅くなります。DMLの場合、特にINSERT操作が多いアプリケーションでは、問合せとINSERT操作のパフォーマンスとの間のバランスを取る必要があるため、索引の設計は十分に検討する必要があります。

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

2.5.3.4 索引内のシリアライズ

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

2.5.3.5 索引内の列の順序付け

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

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

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

2.5.4 ビューの使用

ビューを使用すると、アプリケーションの設計がスピードアップされ簡潔になります。簡単なビュー定義により、データの取出し、表示、収集および格納処理を優先するプログラマが、複雑なデータ・モデルから解放されます。

ただし、ビューは、クリーンなプログラミング・インタフェースを提供する一方で、最適とはいえないリソース集中型の問合せの原因になる場合があります。ビューの最も不適切な使用例は、ビューが他の複数のビューを参照し、その複数のビューが問合せ内で結合されている場合です。多くの場合、開発者はビューを使用せずに表から直接問合せを満たすことができます。ビューが持つ本来の特性により、通常は、オプティマイザによる最適な実行計画の生成が困難になります。

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

次の例は、単純なOLTPアプリケーションでのテスト結果です。

Test                         #Users Supported
No Parsing all statements           270
Soft Parsing all statements         150
Hard Parsing all statements          60
Re-Connecting for each Transaction   30

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

2.5.6 アプリケーションの実装

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

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

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

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

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

- データ管理とトランザクション
これに関しては、プログラミング言語による影響はほとんどありません。

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

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

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. エンドツーエンド・アプリケーションのトレースで使用するアクション名およびモジュール名の設定を検討してください。設定すると、ワークロードの問題を柔軟にトレースできます。「エンドツーエンド・アプリケーションのトレース」を参照してください。

2.5.7 アプリケーション開発の傾向

今日のアプリケーション開発には、2つの大きな特徴があります。1つは、コンパイラ型のCまたはC++アプリケーションにかわってJavaの使用が増えていること、もう1つは、スキーマ設計に影響を与えるオブジェクト指向手法の使用が増えていることです。

Javaはコードの移植性に優れ、高い可用性をプログラマに提供します。ただし、Javaにはパフォーマンスに影響することがいくつかあります。Javaはインタプリタ型言語であるため、C言語などのコンパイラ型言語に比べてロジックの実行速度が遅くなります。その結果、クライアント・コンピュータでのリソース使用量が増加します。このため、強力なCPUをクライアント・コンピュータや中間層コンピュータに設置する必要があり、プログラマは効率的なコードを作成するようにさらに注意を払う必要があります。

Javaはオブジェクト指向言語であるため、ビジネス・ロジックを実行しないクラスへのデータ・アクセスの分離を奨励します。この結果、プログラマは、使用するデータ・アクセス・メソッドの効率を認識せずにそのメソッドを呼び出す可能性があります。このため、データベース・アクセスが最小限になり、データベースへのインタフェースには最も簡潔で単純なインタフェースが使用される可能性があります。

このタイプのソフトウェア設計では、常にすべてのWHERE述語が問合せに効率的に組み込まれるとは限らず、行のフィルタ処理はJavaプログラムで実行されます。これはかなり非効率的です。さらに、DML操作、特にINSERT操作では単一のINSERTが実行され、配列インタフェースは使用できません。これが、プロシージャ・コールによりさらに非効率的になることがあります。データベースとのデータのやり取りでは、実際のデータベース・コールよりも多くのリソースが使用されます。

一般に、最善の総合的トランザクション設計を実現するには、データ・アクセス・コールをビジネス・ロジックの次に配置するのが最適です。

プログラミング・レベルでのオブジェクト指向の採用は、Oracleサーバー内にオブジェクト指向データベースを作成することに発展しています。これは、オブジェクト構造のBLOBへの格納および効果的な索引付きカード・ファイルとしてのデータベースの使用から、Oracle Databaseオブジェクト・リレーショナル機能の使用まで、様々な形で現れています。

オブジェクト指向アプローチをスキーマ設計に採用する場合は、リレーショナル・ストレージ・モデルの柔軟性が失われないようにします。多くの場合、スキーマ設計でのオブジェクト指向アプローチにより、データ構造にかなりの非正規化が生じ、相当なメンテナンスが必要になり、オブジェクトに関連付けられたREFポインタも必要になります。このような設計は、多くの場合、リレーショナル格納方式に置き換わる前の階層データベースやネットワーク・データベースの設計に戻ることを意味します。

要約すると、データベースにデータを長期間格納する場合、また同一スキーマに対する非定型問合せまたはアプリケーション開発をある程度予期している場合は、リレーショナル格納方式が最善のパフォーマンスと柔軟性をもたらす可能性があります。

2.6 ワークロードのテスト、モデル化および実装

この項では、ワークロードの見積り、モデル化、実装およびテストについて説明します。この項では、次の項目について説明します。

- データのサイズ設定

- ワークロードの見積り

- アプリケーションのモデル化

- 設計のテスト、デバッグおよび検証

2.6.1 データのサイズ設定

不適切なサンプル・セットを使用すると、可変長データを扱うときにサイズの見積りを誤ることがあります。データ量の増加に伴い、キーの長さも大幅に長くなり、列サイズの見積りに変更が生じます。

システムは、本番稼働が始まると、データベース規模の拡大、特に索引の増加は予想が困難になります。表は時間とともに増大し、索引は、キーの生成、挿入パターンおよび行の削除というアプリケーションの個々の動作によって変化します。最悪のケースは、昇順キーを使用して行を挿入してから、一部の行を残してほとんどの行を表の左側から削除した場合です。これによって、ギャップと無駄な領域が残ります。索引をこのように使用している場合は、オンラインの索引再作成機能の使用方法を理解している必要があります。

DBAは、オブジェクトごとに領域割当てを監視し、増大して制御できなくなる可能性のあるオブジェクトを探します。アプリケーションを十分に理解することで、急速にまたは予測を超えて増大する可能性のあるオブジェクトを発見できます。これは、あらゆるシステムのパフォーマンス計画と可用性計画の両方で重要なことです。本番データベースを実装するときは、対話型ユーザーがアプリケーションを使用しているときに領域管理が最小限になるように設計する必要があります。これは、データ・セグメント、一時セグメントおよびロールバック・セグメントのすべてに当てはまります。

2.6.2 ワークロードの見積り

含まれる変数の数を考えると、容量計画およびテストのためのワークロードの見積りは非常に困難です。しかし、設計者は、CPU、メモリーおよびディスク・ドライブを搭載したコンピュータを指定して、最終的にはアプリケーションを展開する必要があります。サイズ設定に使用する技法はいくつかあり、それぞれに利点があります。サイズを設定するときは、次の2つの方法を使用して意思決定プロセスを検証し、サポート用ドキュメントを準備することをお薦めします。

- 類似システムからの推定

- ベンチマーク

2.6.2.1 類似システムからの推定

これは完全に経験に基づくアプローチで、特性が類似しており、パフォーマンスが把握されている既存のシステムを基礎システムとして使用します。このシステムの仕様を、サイズ設定の担当者が既知の相違点に応じて変更します。このアプローチでは、既存のシステムと関連する部分は参考になりますが、相違点のある部分を扱うときにはほとんど参考になりません。

このアプローチは、巨大なビル、船舶、橋梁、石油掘削装置などの大規模エンジニアリング分野のほとんどすべてで、エンジニアリング・プロジェクトのコストを見積るときに使用されています。参照システムがサイズの点で計画しているシステムと大きな差がある場合は、一部のコンポーネントが設計上限を超えてしまう可能性があります。

2.6.2.2 ベンチマーク

ベンチマーク・プロセスは、リソースと時間をかなり消費し、必ずしも正確な結果が得られるとはかぎりません。開発初期またはプロトタイプの段階でアプリケーションをシミュレーションすると、実際の本番システムの場合とは異なるものを計測する危険性があります。予想外かもしれませんが、オラクル社では長年にわたりデータベース開発組織とともに顧客アプリケーションのベンチマークを行っていますが、ベンチマーク・アプリケーションと実際の本番システムとの間に信頼に値する相関関係はまだ認められていません。これは、開発プロセスでアプリケーションの非効率な点がいくつか組み込まれてしまうことが主な原因です。

しかし、ベンチマークは、許容可能なレベルの精度でシステムのサイズを設定するためには有効に利用されています。特に、ベンチマークは、システムの負荷が最大になったときの実際のI/O要求数の判断やリカバリ処理のテストに効果があります。

ベンチマークでは、その性質上、システムの全コンポーネントに対してそれぞれの上限までストレスがかけられます。すべてのコンポーネントにストレスがかけられるため、ベンチマーク中にアプリケーションの設計および実装のエラーがすべて明らかになります。また、ベンチマークでは、データベース、オペレーティング・システムおよびハードウェア・コンポーネントもテストされます。ほとんどのベンチマークが急いで実行されるため、システム・コンポーネントが失敗すると障害や問題が発生すると考えてください。ベンチマークは実施者にストレスがかかる作業であり、ベンチマークから最大限の結果を得るには豊富な経験が必要です。

2.6.3 アプリケーションのモデル化

アプリケーションのモデル化は、複雑な数学的モデル化から、封筒の裏を使用するような典型的な単純計算まで多岐にわたります。どちらの方法にもメリットがあり、一方は高い精度を目標とし、もう一方は大まかな見積りを作成します。デメリットは、どちらも実装エラーや効率の悪さが考慮されないことです。

見積りやサイズ設定のプロセスは、正確性に欠ける技法です。しかし、このプロセスを精査することで、ある程度知的な見積りを行うことができます。見積りプロセス全体としては、不適切なSQL、索引の設計またはカーソル管理によるアプリケーションの非効率は考慮されていません。サイズ設定担当者は、アプリケーションの非効率性に対応する余裕を組み入れる必要があります。パフォーマンス・エンジニアは、非効率性を検出し、見積りを現実的なものにします。アプリケーションの非効率性を検出する方法は、Oracleのパフォーマンス改善方法で説明しています。

2.6.4 設計のテスト、デバッグおよび検証

テスト・プロセスは、主に機能テストと安定性テストで構成されます。このプロセスの途中で、パフォーマンス・テストが実施されます。

アプリケーションのパフォーマンス・テストを実行するときの簡単な規則を説明したリストを次に示します。適切に文書化した場合、このリストは、アプリケーション稼働後の本番アプリケーションと容量計画プロセスにとって重要な情報を提供します。

- 自動データベース診断モニター(ADDM)とSQLチューニング・アドバイザを使用した設計の検証

- 現実的なデータ量とデータ配分によるテスト
すべてのテストは、データが完全に含まれている表を使用して行う必要があります。テスト用データベースには、データ量や表のカーディナリティという点で本番システムと同様のデータを入れておく必要があります。本番と同様の索引をすべて作成し、スキーマ統計を正しく入力します。

- 正しいオプティマイザ・モードの使用
すべてのテストは、本番で使用するオプティマイザ・モードで実行する必要があります。Oracle Databaseのすべての研究開発の取組みは、問合せオプティマイザに重点が置かれています。したがって、問合せオプティマイザの使用をお薦めします。

- シングル・ユーザーのパフォーマンスのテスト
アイドル状態または使用率の低いデータベースで、シングル・ユーザーのパフォーマンスが許容範囲にあるかテストします。シングル・ユーザーのパフォーマンスが理想的な条件下で許容範囲に達しない場合、実際の条件下で複数のユーザーが許容可能なパフォーマンスを得ることはできません。

- 全SQL文の計画の取得と文書化
各SQL文の実行計画を取得します。このプロセスを使用して、オプティマイザの実行計画が最適かどうか、およびSQL文の相対コストがCPU時間と物理I/O数の観点から把握されているかどうかを検証します。このプロセスは、将来において多くのチューニングおよびパフォーマンスの必要な頻繁に使用されるトランザクションを識別するのに役立ちます。

- マルチ・ユーザーのテスト
ユーザーのワークロードやプロファイルがまだ完全に定量化されていない可能性があるため、このプロセスを正確に実行するのは困難です。しかし、DML文を実行するトランザクションをテストして、ロックの競合やシリアライズの問題がないことは確認する必要があります。

- 正しいハードウェア構成でのテスト
できるだけ本番システムに近い構成でテストを行います。実際的なシステムの使用は、ネットワーク待機時間、I/Oサブシステム帯域幅およびプロセッサのタイプと速度についてテストする場合に特に重要です。このアプローチを使用しなかった場合、潜在的なパフォーマンスの問題を正しく分析できません。

- 安定した状態でのパフォーマンスの測定
ベンチマークを行うときは、安定した状態でパフォーマンスを測定することが重要です。各ベンチマークの実行には開始フェーズが必要です。このフェーズでは、ユーザーがアプリケーションに接続し、アプリケーションでの作業を徐々に開始します。このプロセスによって、安定した状態になる前に、頻繁にキャッシュされるデータをキャッシュに初期化し、解析などの1回のみ実行する操作を完了しておくことができます。同様に、ベンチマークの実行後には終了フェーズが必要です。このフェーズでは、リソースをシステムから解放し、ユーザーは作業を終了して接続を切断します。

2.7 新規アプリケーションのデプロイ

この項では、アプリケーションのデプロイに関して設計で必要な次の決定事項について説明します。

- ロールアウトの方法

- パフォーマンス・チェックリスト

2.7.1 ロールアウトの方法

新しいアプリケーションをロールアウトするときは、次の2つの方法が一般的です。

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

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

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

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

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

2.7.2 パフォーマンス・チェックリスト

本番での最適なパフォーマンスの可能性を高め、アプリケーションの迅速なデバッグを可能にするタスクのリストを作成すると、ロールアウトの際に役立ちます。次のことを行います。

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

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

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

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

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

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

7. SQL文でカーソルが効率的に使用されていることを確認します。データベースでは、各SQL文を1回解析したら、それを複数回実行します。これが正しく行われない原因として最も一般的なものは、バインド変数が正しく使用されていないことか、WHERE句の述語が文字列リテラルとして送信されていることです。プリコンパイラを使用してアプリケーションを開発する場合は、アプリケーションをプリコンパイルする前に、MAXOPENCURSORS、HOLD_CURSORおよびRELEASE_CURSORの各パラメータのデフォルト値からの再設定が必要です。

8. すべてのスキーマ・オブジェクトが開発環境から本番データベースに正しく移行されていることを確認します。これには、表、索引、順序、トリガー、パッケージ、プロシージャ、ファンクション、Javaオブジェクト、シノニム、権限付与およびビューが含まれます。テスト中に変更を加えた場合は、その変更が本番システムにも加えられていることを確認します。

9. システムをロールアウトした直後に、データベースとオペレーティング・システムの統計用ベースライン・セットを設定します。最初の統計データにより、設計およびロールアウト・プロセスで設定した前提事項が検証または訂正されます。

10. 最初のボトルネックの予測を開始し(不可避のボトルネック)、Oracleのパフォーマンス改善方法に従ってパフォーマンスを改善します。詳細は、第3章「パフォーマンス改善方法」を参照してください。

3 パフォーマンス改善方法

この章では、Oracle Databaseのパフォーマンス改善方法について説明します。この章の内容は次のとおりです。

- Oracleのパフォーマンス改善方法

- パフォーマンスの緊急の問題に対処する方法

3.1Oracleのパフォーマンス改善方法

Oracleのパフォーマンス方法論は、Oracleデータベースのパフォーマンス問題の識別に役立ちます。これには、ボトルネックの識別とその修正が含まれます。システムの変更は、ボトルネックの存在を確認した後にのみ行うことをお薦めします。

パフォーマンスの改善は、本質的に反復的なプロセスです。このため、最初のボトルネックを取り除いても、別のボトルネックが明らかになる可能性があり、パフォーマンスがすぐには改善されないことがあります。また、シリアライズ・ポイントが効率の悪い共有メカニズムに移動したことによって、パフォーマンスが低下する場合もあります。経験を重ね、ボトルネックの除去方法に厳密に従うことにより、アプリケーションをデバッグしてスケーラブルにすることができます。

パフォーマンスの問題は、通常、スループットの不足または許容範囲を超えたユーザー/ジョブ・レスポンス時間(あるいはその両方)が原因で発生します。問題は、アプリケーション・モジュール間でローカルに発生する場合も、システム全体にわたる場合もあります。

データベース統計やオペレーティング・システム統計を調べる前に、システムで最も重要なコンポーネントからのフィードバックを取得することが重要です。つまり、システムのユーザーと、アプリケーション・コストを最終的に負担する人々からのフィードバックです。ユーザーからの典型的なフィードバックには、次のような報告が含まれます。

- オンライン・パフォーマンスがあまりに低いため、部下が業務を遂行できない。

- 請求作業にかかる時間が長すぎる。

- Webトラフィックが多くなると、レスポンス時間が許容できないほど遅くなり、このままでは顧客を失ってしまう。

- 現在、1日に5000件の取引を行っているが、システムが限界を超えている。来月は全ユーザーにロールアウトする予定で、取引数は4倍になる見込みである。

このような率直なフィードバックがあると、パフォーマンスの改善作業を成功させる重要な要因を容易に設定できます。パフォーマンスの目標およびパフォーマンス・エンジニアにとっての最終基準を決定することで、パフォーマンス・プロセスの管理がすべてのレベルで簡潔になり円滑に運びます。このような重要な成功要因は、システム統計ではなく現実的なビジネス目標の観点から定義した方が効果的です。

前述した典型的なユーザー・フィードバックに対する実際のビジネス目標を、次にいくつか示します。

- 請求作業は、3時間で1,000,000件を処理する必要がある。

- Webサイトのピーク時に、1回のページ・リフレッシュのレスポンス時間は5秒以内である必要がある。

- システムでは、8時間で25,000件の取引を処理可能にする。

最終的な満足度は、システム・パフォーマンスに関するユーザーの認識で判断されます。パフォーマンス・エンジニアの役割は、パフォーマンスを低下させるボトルネックを取り除くことです。ボトルネックの原因としては、限られた共有リソースの非効率的な使用、またはシリアライズの原因となる共有リソースの不適切な使用が考えられます。すべての共有リソースにはかぎりがあるため、パフォーマンス・エンジニアの目標は、共有リソースを効率的に活用して、ビジネス処理件数を最大にすることです。高いレベルでは、データベース・サーバー全体を共有リソースとみなすことができます。逆に、低いレベルでは、1台のCPUやディスクを共有リソースとみなすことができます。

Oracleのパフォーマンス改善方法は、パフォーマンス目標を達成するまで、または目標の達成が不可能と判断されるまで適用できます。これは非常に反復的なプロセスです。必然的に、データベースのパフォーマンスにほとんど影響のない調査も発生します。重大なボトルネックを正確かつ迅速に特定するスキルを開発するには、時間と経験が必要です。ただし、利用できるデータや統計を軽視すると、たとえ経験が豊かな技術者でもその経験が裏目に出ることがあります。このような技術者は、根拠のない思い込みと慣習でデータベースをチューニングしようとします。これは、データベースのチューニング方法としては非常に危険でコストもかかり、成功するとは考えられません。

自動データベース診断モニター(ADDM)は、パフォーマンス改善方法の各部を実装し、統計を分析して、重大なパフォーマンスの問題の自動診断を提供します。ADDMを使用すると、システム・パフォーマンスの改善に伴う所要時間を大幅に短縮できます。ADDMの詳細は、第6章「自動パフォーマンス診断」を参照してください。

システムは多様かつ複雑であるため、パフォーマンス分析における絶対的な規則は不可能です。本質的に、Oracleのパフォーマンス改善方法は、作業の方法を定義するものであり、確定した一連の法則を定義するものではありません。ボトルネックの検出における唯一の法則は、法則がないということです。優れたパフォーマンス・エンジニアは、提供されたデータを利用し、様々な角度から検討してパフォーマンスの問題を判断します。

3.1.1 Oracleのパフォーマンス改善方法の手順

1. 次に示す初期標準チェックを実行します。

1. ユーザーから率直なフィードバックを取得します。パフォーマンス・プロジェクトの適用範囲、最終的なパフォーマンス目標、今後のパフォーマンス目標を決定します。このプロセスは、今後の容量計画にとっての鍵です。

2. パフォーマンスがよいときと悪いときの両方で、オペレーティング・システム、データベースおよびアプリケーションの統計をフルセットでシステムから取得します。すべての統計を取得できない場合は、可能な範囲で取得します。使用できる統計がないのは、犯罪捜査で証拠がないのと同じです。証拠がないと、捜査が困難になり時間もかかります。

3. ユーザー・パフォーマンスに関係のあるすべてのコンピュータのオペレーティング・システムが健全であることをチェックします。オペレーティング・システムの健全性をチェックすることにより、フルに使用されているハードウェアやオペレーティング・システムのリソースを探します。過剰使用のリソースを症状としてリストし、後で分析します。さらに、すべてのハードウェアでエラーや診断症状がないことをチェックします。

2. Oracle Databaseで最もよく見られる誤りの上位10項目をチェックし、それらが問題であるかどうかを判断します。問題となる可能性がある場合は、症状としてリストし、後で分析します。これらの項目をリストに含めるのは、問題となる可能性が高いためです。ADDMでは、これらの上位10項目のうち9項目が自動的に検出されレポートされます。第6章「自動パフォーマンス診断」および「Oracleシステムにおける誤りの上位10項目」を参照してください。

3. 症状を手がかりにして、システムで発生している状況の概念モデルを作成し、パフォーマンスの問題の原因を把握します。「パフォーマンスを概念的にモデル化する際の意思決定プロセスの例」を参照してください。

4. 一連の修正処理とシステムに対して予想される動作を提示し、アプリケーションに対して最も有効な処理から順に適用します。ADDMにより、各推奨事項と予測されるメリットが生成されます。パフォーマンス改善作業の原則は、変更は一度に1つのみとし、変更前後の差異を測定することです。ただし、システム停止時間に制約があり、この方法を忠実に実行できないことがあります。一度に複数の変更を適用する場合は、それぞれの変更を切り離して、それぞれの変更の効果を個別に検証できるようにします。

5. 変更により期待された効果があることを検証し、ユーザーがパフォーマンスの改善を認識したかどうかを確認します。ユーザーが認識しない場合は、さらにボトルネックを探し、アプリケーションをより正確に把握できるまで、概念モデルの微調整を続けます。

6. パフォーマンス目標が達成されるまで、または他の制約によって達成が不可能になるまで、前述の最後の3つの手順を繰り返します。

この方法によって、最大のボトルネックが特定され、パフォーマンスの改善に対する客観的アプローチが使用されます。重要なことは、アプリケーションの効率を高め、リソース不足とボトルネックを取り除くことにより、パフォーマンスを大幅に改善することです。このプロセスでは、インスタンスのチューニングにより最低限のパフォーマンスの向上(10%未満)が期待でき、アプリケーションの効率の悪さを切り離すことで大幅なパフォーマンスの向上(100%以上)が期待できます。

3.1.2 パフォーマンスを概念的にモデル化する際の意思決定プロセスの例

概念的なモデル化は、ほとんど決定論的なプロセスです。しかし、パフォーマンス・チューニングの経験を積むと、実際に規則が存在しないことの良さに気がつきます。統計を解析して最適な意思決定を行うには、柔軟で機敏なアプローチが必要になります。

迅速かつ簡単なパフォーマンス・チューニングへのアプローチには、ADDMを使用します。ADDMを使用すると、Oracleシステムが自動的に監視され、パフォーマンスの問題が発生した場合は解決のための推奨事項が提供されます。たとえば、データベース管理者がユーザーからシステム・パフォーマンスが低下したという苦情を受け取ったとします。データベース管理者は、ただ最新のADDMレポートを調べ、問題を解決するにはどの推奨事項を実装すればよいかを確認します。Oracleデータベースの監視と診断に役立つ機能の詳細は、第6章「自動パフォーマンス診断」を参照してください。

次の手順は、パフォーマンス・エンジニアが自動診断機能を使用せずにボトルネックを調べる方法を示しています。これらの手順は、あくまでも手動プロセスのガイドラインです。パフォーマンス・エンジニアは、経験を積みながら、それを関連する手順に追加していきます。この分析では、オペレーティング・システム統計とデータベース統計が収集されていることが前提です。

1. 負荷がまったくないか少ないコンピュータで、シングル・ユーザーに対するレスポンス時間またはバッチ実行時間は許容できる範囲ですか。
許容範囲外の場合は、アプリケーションのコードまたは設計が最適でないと考えられます。また、これは、システム・リソースを共有するマルチ・ユーザーの状況では、まったく受け入れられません。このような場合は、アプリケーションの内部統計を取得し、SQLトレースとSQL計画の情報を取得します。開発者とともに、データ、索引およびトランザクションのSQL設計に関する問題を調査し、バッチ処理およびバックグラウンド処理の遅延の可能性について調査します。

2. CPUがすべて使用されていますか。
カーネル使用率が40%を超えた場合は、ネットワーク転送、ページング、スワッピングまたはプロセス・スラッシングについてオペレーティング・システムを調べます。引き続き、ユーザー領域でのCPU使用率をチェックし、CPUを消費するデータベース以外のジョブ(バックアップ、ファイル変換、印刷キューなど)がシステム上で発生して、共有CPUリソース量を制限していないかどうかを確認します。データベースがCPUのほとんどを使用していることを確認した後、CPU使用率が上位のSQLを調べます。これらの文が、今後の分析の基礎になります。SQLおよびSQLを送信するトランザクションが、最適に実行されているかどうかをチェックします。Oracle Databaseでは、V$SQLおよびV$SQLSTATSにCPU統計が示されます。

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

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

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

3.1.3 Oracleシステムにおける誤りの上位10項目

この項では、Oracleデータベースで最もよく見受けられる誤りをリストします。Oracleのパフォーマンス改善方法に従うことで、これらの誤りはすべて回避できます。これらの誤りをシステム内で見つけた場合は、アプリケーション内でパフォーマンス改善の効果のある箇所を再設計します。Oracleデータベースの診断とチューニングに役立つ機能の詳細は、「自動パフォーマンス・チューニング機能」を参照してください。待機イベント・データにより、パフォーマンスに影響を与えるような問題の症状が明らかになりますが、その詳細は、第10章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。

1. 不適切な接続管理
アプリケーションで、データベースとの対話ごとに接続と切断が行われることがあります。この問題は、アプリケーション・サーバー内のステートレス・ミドルウェアで多く発生します。この問題がパフォーマンスに与える影響の大きさは2桁以上違い、まったくスケーラブルではありません。

2. カーソルと共有プールの不適切な使用
カーソルを使用しないと、解析が繰り返し行われることになります。バインド変数を使用しないと、すべてのSQL文のハード解析が行われます。この問題がパフォーマンスに与える影響は甚だしく、まったくスケーラブルではありません。カーソルをオープンするバインド変数とともにカーソルを使用し、繰り返し実行します。動的SQLを生成するアプリケーションは疑ってみます。

3. 不適切なSQL
不適切なSQLとは、アプリケーション要件よりも多くのリソースを使用するSQLです。たとえば、意思決定支援システム(DSS)による問合せが24時間以上実行されている場合や、オンライン・アプリケーションからの問合せに1分以上かかる場合などがあります。大量のシステム・リソースを消費するSQLを検査し、改善の可能性を調査します。ADDMは、高負荷のSQLを識別します。SQLチューニング・アドバイザにより、改善のための推奨事項が提供される可能性があります。第6章「自動パフォーマンス診断」および第17章「自動SQLチューニング」を参照してください。

4. 標準でない初期化パラメータの使用
このようなパラメータは、不適切なアドバイスや不正確な前提に基づいて実装されていることがあります。ほとんどのデータベースでは、基本パラメータ・セットのみを使用して、許容できるパフォーマンスを提供します。特に、ラッチに対するSPIN_COUNTに関連するパラメータとマニュアルに記載されていないオプティマイザ機能は、多くの問題の原因となり、このためにかなりの調査が必要になることがあります。

また、初期化パラメータ・ファイルに設定したオプティマイザ用パラメータが、実証済の最適実行計画をオーバーライドしてしまう可能性があります。このため、スキーマ、スキーマ情報およびオプティマイザの設定は、グループとして管理して一貫性のあるパフォーマンスを維持します。

関連項目:

- 初期化パラメータおよびデータベース作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

- 初期インスタンス構成でのパラメータと設定の詳細は、「初期インスタンス構成のパフォーマンスの考慮事項」を参照してください。

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.2 パフォーマンスの緊急の問題に対処する方法

この項では、パフォーマンスに関する緊急事態に対処する方法について説明します。アプリケーションのパフォーマンスを確立および改善する方法論がすでに存在すると推定されます。しかし、緊急時には、システム・コンポーネントの変化によって、信頼性の高い予測可能なシステムが予測不可能でユーザー・リクエストを満たせないシステムに変化します。

このような場合、パフォーマンス・エンジニアは、何が変化したかをすばやく判断し、適切な処理を行って、通常のサービスをできるだけ早く再開する必要があります。多くの場合、緊急の処理が必要であり、パフォーマンス改善方法を厳密に実行することは現実的ではありません。

パフォーマンス・エンジニアは、パフォーマンスの問題にただちに対処した後、十分なデバッグ情報を収集して、その問題をより明らかに把握するか、それができない場合は、少なくとも同じ問題が再発しないようにする必要があります。

緊急のパフォーマンスの問題をデバッグする方法は、このマニュアルの前の章で説明したパフォーマンス改善方法と同じです。ただし、急を要するという問題の性質上、様々な段階で簡便法が使用されます。デバッグ・プロセスの進行中に見つかった事実を詳細にメモし記録しておくことが、後で行う分析と修正作業の正当化には不可欠です。これは、医師が患者の容態を克明に記録して、将来の参照資料として役立てるのと同じです。

3.2.1 パフォーマンスの緊急の問題に対処する方法の手順

パフォーマンスの緊急の問題に対処する方法は、次のとおりです。

1. パフォーマンスの問題を調査し、問題の症状を収集します。このプロセスには、次の作業が含まれます。

- システムのパフォーマンスが低下した状況について、ユーザー・フィードバックを収集します。問題がスループットかレスポンス時間かを調べます。

- 「パフォーマンスが正常だった時点から何が変化しましたか」という質問をユーザーにします。この質問に対する答が、問題の手がかりになることがあります。ただし、状況が悪化する中で先入観のない答を得るのは難しいことがあります。問題の前と後で取得された参照データ(収集済の統計やログ・ファイル)を見つけるようにします。

- 自動チューニング機能を使用して問題を診断および監視します。Oracleシステムの診断とチューニングに役立つ機能の詳細は、「自動パフォーマンス・チューニング機能」を参照してください。また、Oracle Enterprise Managerのパフォーマンス機能を使用すると、上位のSQLおよびセッションを識別できます。

2. アプリケーション・システムの全コンポーネントのハードウェア使用が健全であることをチェックします。CPU使用率が最も高いコンポーネントをチェックし、システムの全コンポーネントについて、ディスクとメモリーの使用およびネットワーク・パフォーマンスをチェックします。このプロセスによって、問題の原因となっている層をすばやく特定できます。問題がアプリケーション内で発生している場合は、分析の重点をアプリケーションのデバッグへ移します。それ以外の場合は、データベース・サーバーの分析に進みます。

3. データベース・サーバーがCPU上で制約を受けているかどうか、待機イベントで待機し続けているのかを判断します。データベース・サーバーがCPU上で制約を受けている場合は、次の点を調べます。

- オペレーティング・システム・レベルで大量のCPUおよびデータベースを消費しているセッション(V$SESS_TIME_MODELでデータベースのCPU使用率を調べます。)

- データベース・レベルで多数のバッファ読取りを実行しているセッションまたは文(V$SESSTATおよびV$SQLSTATSを調べます。)

- 最適ではないSQLの実行の原因となった実行計画の変更(特定が困難な場合もあります。)

- 初期化パラメータの誤設定

- コードの変更または全コンポーネントのアップグレードによるアルゴリズムの問題

データベース・セッションがイベントを待機している場合は、V$SESSION_WAITにリストされている待機イベントに従って、シリアライズの原因を判断します。V$ACTIVE_SESSION_HISTORYビューには、サンプリングされたセッション・アクティビティの履歴が含まれており、問題が終了してシステムが通常の操作に戻った後も診断に使用できます。ライブラリ・キャッシュに大量の競合がある場合は、データベースにログオンしたりSQLを送信するのが不可能なことがあります。このような場合は、履歴データを使用して、そのラッチで競合が突然発生した原因を判断します。ほとんどがI/O待機の場合は、V$ACTIVE_SESSION_HISTORYを調べて、すべての入出力を実行するセッションで実行中のSQLを判断します。待機イベントの詳細は、第10章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。

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

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

第III部

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

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

この部の構成は、次のとおりです。

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

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

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

- 第7章「メモリーの構成および使用方法」

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

- 第9章「オペレーティング・システム・リソースの管理」

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

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

この章では、パフォーマンスを考慮してデータベースを構成するための、オラクル社の方法論の概要を説明しています。パフォーマンスの修正はOracle Databaseに対して継続的に実行できますが、データベースの初期構成を適切に行うことにより、多大な利益を得ることができます。

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

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

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

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

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

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

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

関連項目:

- Database Configuration Assistantを使用したデータベースの作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- SQL文を使用したデータベースの作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

4.1.1 初期化パラメータ

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

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

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

パラメータ

説明

DB_NAME

データベースの名前。これは、環境変数ORACLE_SIDに一致する必要があります。

DB_DOMAIN

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

OPEN_CURSORS

1セッション当たりのカーソル(アクティブなSQL文)の最大数に対する制限。設定はアプリケーションにより異なり、推奨値は500です。

CONTROL_FILES

異なるディスク・ドライブ上に少なくとも2つのファイルを含めるように設定して、制御ファイルの消失による障害を防ぎます。

DB_FILES

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

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

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

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

パラメータ

説明

COMPATIBLE

互換性を維持しておくOracleデータベースのリリースを指定します。このパラメータを使用すると、新しい機能を自分の環境でテストせずに、ただちに本番システムで新しいリリースで改善された機能を利用できるようになります。アプリケーションがOracle Databaseの特定のリリース用に設計されていて、実際にはそれより後のリリースをインストールする場合は、このパラメータをアプリケーション設計時のリリースに設定してください。

DB_BLOCK_SIZE

データベース・ファイルに格納され、SGAにキャッシュされるOracleデータベース・ブロックのサイズを設定します。値の範囲はオペレーティング・システムにより異なりますが、一般的にトランザクション処理システムの場合は8192で、データベース・ウェアハウス・システムの場合はさらに大きい値となります。

SGA_TARGET

すべてのSGAコンポーネントのサイズ合計を指定します。SGA_TARGETが指定されている場合、バッファ・キャッシュ(DB_CACHE_SIZE)、Javaプール(JAVA_POOL_SIZE)、ラージ・プール(LARGE_POOL_SIZE)および共有プール(SHARED_POOL_SIZE)のメモリー・プールは、自動的にサイズ設定されます。「自動共有メモリー管理」を参照してください。

PGA_AGGREGATE_TARGET

インスタンスに添付されたすべてのサーバー・プロセスに利用できるターゲット集計PGAメモリーを指定します。「PGAメモリー管理」を参照してください。

PROCESSES

そのインスタンスで起動できるプロセスの最大数を設定します。このパラメータは、他のパラメータ値の多くがこのパラメータから導出されるため、設定する最も重要なプライマリ・パラメータとなります。

SESSIONS

これは、デフォルトでPROCESSESの値から設定されます。ただし、共有サーバーを使用する場合は、導出された値では不十分である可能性があります。

UNDO_MANAGEMENT

データベースで使用するUNDO領域管理モードを指定します。デフォルトはAUTOです。指定しない場合、AUTOが使用されます。

UNDO_TABLESPACE

インスタンス起動時に使用されるUNDO表領域を指定します。

関連項目:

- 第7章「メモリーの構成および使用方法」

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

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

4.1.2 UNDO領域の構成

データベースは、読取り一貫性、リカバリおよびロールバック文で使用するデータを格納するために、UNDO領域を使用します。このデータは1つ以上のUNDO表領域に格納されます。Database Configuration Assistant(DBCA)を使用してデータベースを作成すると、UNDO表領域が自動的に作成されます。UNDO表領域を手動で作成するには、CREATE DATABASE文にUNDO TABLESPACE句を追加します。

UNDOデータを自動的に管理するため、Oracle Databaseでは、UNDOセグメントを透過的に作成および管理する自動UNDO管理を使用します。自動UNDO管理を有効にするには、UNDO_MANAGEMENT初期化パラメータをAUTO(デフォルト設定)に設定します。指定しない場合、UNDO_MANAGEMENT初期化パラメータでは、AUTO設定が使用されます。自動UNDO管理の使用をお薦めするのは、データベース管理が大幅に簡素化され、UNDO(ロールバック)セグメントを手動でチューニングする必要がないためです。ロールバック・セグメントを使用する手動UNDO管理は、下位互換性のためにサポートされています。

V$UNDOSTATビューには、UNDO領域を監視およびチューニングするための統計が含まれています。このビューを使用して、現行のワークロードに必要なUNDO領域の大きさをより的確に見積ることができます。この情報を使用して、UNDO使用量を簡単にチューニングすることもできます。V$ROLLSTATビューには、UNDO表領域内のUNDOセグメントの動作に関する情報が含まれています。

関連項目:

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

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

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

4.1.3 REDOログ・ファイルのサイズ指定

REDOログ・ファイルのサイズはパフォーマンスに影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下します。

REDOログ・ファイルのサイズはLGWRのパフォーマンスに影響を与えませんが、DBWRおよびチェックポイントの動作に影響を与える可能性があります。チェックポイントの頻度には、ログ・ファイルのサイズやFAST_START_MTTR_TARGET初期化パラメータの設定など、複数の要因が影響します。インスタンスのリカバリ時間を制限するためにFAST_START_MTTR_TARGETパラメータが設定されている場合、Oracle Databaseは自動的にチェックポイントを必要に応じて頻繁に試みます。この場合は、ログ・ファイルが小さすぎることによるチェックポイントの追加発生を防ぐために、ログ・ファイルを十分なサイズに設定する必要があります。最適なサイズは、V$INSTANCE_RECOVERYビューからOPTIMAL_LOGFILE_SIZE列を問い合せることで取得できます。また、Oracle Enterprise Managerの「REDOログ・グループ」ページからも、サイズ設定のアドバイスを取得できます。

REDOログ・ファイルに特定のサイズを推奨できない場合もありますが、100MBから数GBの範囲内にあるREDOログ・ファイルが妥当であると考えられます。システムが生成するREDOの量に従って、オンラインREDOログ・ファイルをサイズ設定します。およその目安として、多くても20分ごとに1回ログ・ファイルを切り替えます。

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

4.1.4 追加表領域の作成

Database Configuration Assistant(DBCA)を使用してデータベースを作成する場合、シード・データベースには必要な表領域すべてが自動的に組み込まれます。DBCAを使用しないように選択した場合は、データベースの作成後に追加表領域を作成する必要があります。

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

- ソートなどの操作に使用される一時表領域

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

- アプリケーションで使用する少なくとも1つの表領域(ほとんどの場合、アプリケーションには複数の表領域が必要です)

多数のデータファイルを含む非常に大きな表領域では、複数のALTER TABLESPACE . . .ADD DATAFILE文をパラレルで実行できます。表領域の作成時、表領域を構成するデータファイルは特殊な空のブロック・イメージで初期化されます。一時ファイルは初期化されません。

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

4.1.4.1 永続的な表領域の作成 - 自動セグメント領域管理

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

関連項目:

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

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

4.1.4.2 一時表領域の作成

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

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

関連項目:

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

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

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

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

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

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

- 表領域の自動セグメント領域管理の指定
この方法では、最高のパフォーマンスが得られるよう、Oracle Databaseで自動的にセグメント領域が管理されます。

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

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

4.2.1 表圧縮

ヒープ構成表は、どのような種類のアプリケーションにも透過的な圧縮形式で格納できます。データベース・ブロック内の圧縮データは自己完結型です。つまり、ブロック内の未圧縮データの再作成に必要なすべての情報がそのブロック内にあります。バッファ・キャッシュでも、ブロックは圧縮されています。表圧縮により、ディスク記憶域のみでなく、メモリー使用量、特にバッファ・キャッシュ要件も削減されます。表へのアクセスに必要なI/O操作の量が削減され、バッファ・キャッシュ・ヒットの確率が高まることで、パフォーマンスの向上が実現します。

Oracle Databaseの拡張圧縮オプションを使用すると、データ・ウェアハウスおよびOLTPアプリケーションを含め、どのタイプのアプリケーションもワークロードのパフォーマンスが向上し、データベースに必要なディスク領域を削減します。拡張圧縮機能は、構造化データ、非構造化データ、バックアップ・データおよびネットワーク・データを含め、すべてのタイプのデータに使用できます。

4.2.1.1 圧縮係数の見積り

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

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

4.2.1.2 チューニングによる圧縮率向上

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

圧縮係数を高めるには、データ・ブロック内の値の繰返しの可能性を高くする必要があります。達成できる圧縮係数は、特定の列または列のペアのカーディナリティ(列値の繰返しの可能性を表す)およびこれらの列の行の平均長さによって異なります。表圧縮では、単一列の重複値が圧縮されるだけでなく、可能な場合は、複数列値のペアの使用が試行されます。データ配分について熟知していない場合、最適な順序の予測は非常に困難です。

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

4.2.2 未使用領域の解放

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

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

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

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

関連項目:

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

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

4.2.3 データの索引付け

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

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

4.2.3.1 ソート用データのメモリーの指定

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

関連項目:

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

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

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

共有サーバーを使用すると、プロセス数と、データベース・ホストでのメモリー使用量が削減されます。共有サーバーは、多数のOLTPユーザーが断続的なトランザクションを実行するデータベースに有効です。

また、データベースへの単位時間当たりの接続数が高いシステムでは、一般的に専用サーバーよりも共有サーバーを使用する方が適しています。共有サーバーでは、接続リクエストを受信する際に、ディスパッチャを使用して同時接続リクエストを処理できます。しかし、専用サーバーの場合は、接続固有の専用サーバーが、接続リクエストごとに順次初期化されます。

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

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

関連項目:

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

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

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

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

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

- 共有サーバーの競合の識別

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

次のビューによってディスパッチャのパフォーマンス統計が提供されます。

- V$DISPATCHER: ディスパッチャ・プロセスの一般的な情報

- V$DISPATCHER_RATE: ディスパッチャ・プロセスの統計情報

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

ディスパッチャのパフォーマンスを調べるには、V$DISPATCHER_RATEビューを問い合せて、最大値と現在の値を比較します。現在のシステム・スループットが適切なレスポンス時間を提供し、このビューの現在の値が平均値に近くかつ最大値を下回る場合、共有サーバー環境は最適にチューニングされていると考えられます。

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

必要に応じて、システムのストレス・テストを実行し、定期的にV$DISPATCHER_RATE統計をポーリングすることによってワークロードをシミュレートすることもできます。これらの統計の正しい解釈方法は、プラットフォームごとに異なります。アプリケーションの種類が変わると、V$DISPATCHER_RATEに記録される統計値も大幅に異なる可能性があります。

関連項目:

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

4.3.1.1 ディスパッチャ・プロセスの競合の低減

競合を低減するには、次の点を考慮してください。

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

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

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

関連項目:

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

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

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

4.3.2 共有サーバーの競合の識別

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

表4-3 V$QUEUE内の待機時間およびリクエストの列

列

説明

WAIT

キューに存在していた全リクエストについての待機時間の合計(100分の1秒単位)

TOTALQ

キューに存在していたリクエストの総数

アプリケーションの実行時に次のSQL文を発行して、この統計を数回監視してください。

SELECT DECODE(TOTALQ, 0, 'No Requests',
WAIT/TOTALQ || ' HUNDREDTHS OF SECONDS') "AVERAGE WAIT TIME PER REQUESTS"
FROM V$QUEUE
WHERE TYPE = 'COMMON';

この問合せは、次のような計算結果を戻します。

AVERAGE WAIT TIME PER REQUEST
-----------------------------
.090909 HUNDREDTHS OF SECONDS

この結果から、リクエストは処理される前にキューにおいて平均0.09待機したことがわかります(単位は100分の1秒)。

また、次の問合せを発行することによって、現在実行中の共有サーバーの数が判断できます。

SELECT COUNT(*) "Shared Server Processes"
FROM V$SHARED_SERVER
WHERE STATUS != 'QUIT';

この問合せの結果を次に示します。

Shared Server Processes
-----------------------
10

共有サーバーでのリソース競合を検出した場合は、まず、共有プールとラージ・プールを調査し、これがメモリー競合でないことを確認します。パフォーマンスが改善されない場合は、共有サーバー・プロセス競合を低減するためにさらにリソースを作成してください。その場合は、オプションのサーバー・プロセス初期化パラメータを変更します。

- MAX_DISPATCHERS

- MAX_SHARED_SERVERS

- DISPATCHERS

- SHARED_SERVERS

関連項目:
共有サーバー・プロセスの初期化パラメータの設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

この章では、パフォーマンス統計の収集について説明します。この章には次の項があります。

- データ収集の概要

- 自動ワークロード・リポジトリの概要

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

5.1 データ収集の概要

パフォーマンスの問題を効果的に診断するには、統計が使用可能である必要があります。Oracle Databaseは、システム、セッションおよび個々のSQL文について様々なタイプの累積的な統計を生成します。また、Oracle Databaseは、セグメントおよびサービスに関する累積的な統計も追跡します。通常、これらの範囲でのパフォーマンスの問題を分析する場合は、問題となる期間における統計の変化(デルタ値)を調べます。特に、期間開始時における統計の累積値と終了時における累積値の違いを調べます。

統計の累積値は、通常、V$SESSTATおよびV$SYSSTATビューなどの動的パフォーマンス・ビューを介して使用できます。動的ビューの累積値は、データベース・インスタンスの停止時にリセットされることに注意してください。自動ワークロード・リポジトリ(AWR)は、セッション・レベルを除くすべてのレベルでほとんどの統計の累積値とデルタ値を自動的に存続させます。この処理は定期的に繰り返され、その結果はAWRスナップショットと呼ばれます。スナップショットにより取得されるデルタ値は、期間中の各統計の変化を表します。「自動ワークロード・リポジトリの概要」を参照してください。

メトリックは、Oracle Databaseで収集されるもう1つのタイプの統計です。メトリックは、なんらかの累積統計における変化の割合として定義されます。この割合は、時間、トランザクション、データベース・コールなど、様々な単位で測定できます。たとえば、1秒当たりのデータベース・コールの数はメトリックです。メトリック値は、一部のV$ビューに表示されます。ビューに表示される値は、きわめて短い時間間隔(通常は60秒)での平均値です。最新のメトリック値の履歴は、V$ビューを介して使用でき、データの一部はAWRスナップショットでも存続されます。

Oracleで収集される第3のタイプの統計データは、サンプル・データです。アクティブ・セッション履歴(ASH)サンプラは、サンプリングを実行します。ASHは、すべてのアクティブ・セッションの現在の状態をサンプリングします。このデータはメモリーに収集され、V$ビューでデータにアクセスできます。AWRスナップショット処理によって、このデータは永続記憶域にも書き込まれます。「アクティブ・セッション履歴」を参照してください。

パフォーマンスの問題に関する強力な診断手段は、統計的ベースラインを使用することです。統計的ベースラインは、通常はシステムがピーク負荷で正常に動作している期間中に取得された統計的割合の集合です。パフォーマンスの低下期間中に取得された統計をベースラインと比較すると、大幅に値が大きくなっていて問題の原因だと思われる特定の統計を検出しやすくなります。

AWRは、AWRスナップショットのペアまたは範囲をベースラインとして指定して保存できるようにすることで、ベースライン・データの取得をサポートします。ベースラインとして選択する期間は慎重に考慮してください。ベースラインはシステムのピーク負荷を適切に表している必要があります。将来、これらのベースラインをパフォーマンスが低い期間中に取得されたスナップショットと比較できます。

Oracle Enterprise Managerは、動的パフォーマンス・ビューにリアルタイム・データとAWR履歴表からの履歴データを表示するための推奨ツールです。また、Enterprise Managerを使用してオペレーティング・システムとネットワークの統計データを取得し、AWRデータとの相関付けもできます。詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

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

- データベース統計

- オペレーティング・システム統計

- 統計の解釈

5.1.1 データベース統計

データベース統計は、データベースの負荷のタイプ、およびデータベースで使用される内部リソースと外部リソースに関する情報を提供します。この項では、重要な次の統計について説明します。

5.1.1.1 待機イベント

待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示すために、サーバー・プロセスまたはスレッドによって増やされる統計です。待機イベント・データは、ラッチの競合、バッファの競合、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: ディスクからのブロック読取りの待機。

インスタンスの待機イベント統計には、バックグラウンド・プロセスとフォアグラウンド・プロセスの両方の統計が含まれます。通常は、フォアグラウンド・アクティビティのチューニング作業が中心となるため、インスタンス・アクティビティ全体は、チューニングに役立つように、関連するV$ビュー内でフォアグラウンドとバックグラウンドの統計に分類されます。

V$SYSTEM_EVENTビューには、インスタンスのフォアグラウンド・アクティビティの待機イベント統計と、インスタンスの待機イベント統計が表示されます。V$SYSTEM_WAIT_CLASSビューには、待機クラスへの集計後に、これらのフォアグラウンドおよびインスタンスの待機イベント統計が表示されます。V$SESSION_EVENTおよびV$SESSION_WAIT_CLASSには、セッション・レベルでの待機イベント統計と待機クラス統計が表示されます。

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

5.1.1.2 時間モデル統計

Oracleデータベースをチューニングする場合は、コンポーネントごとに固有の統計セットがあります。システム全体を調べるには、共通の比較尺度が必要です。このため、Oracle Databaseのほとんどのアドバイザおよびレポートでは、統計が時間単位で記述されます。また、V$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューには、時間モデル統計が用意されています。共通の時間という尺度で計測すると、データベース操作に対する影響を数量化して識別できます。

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

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

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

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

5.1.1.3 アクティブ・セッション履歴

V$ACTIVE_SESSION_HISTORYビューには、インスタンス内でサンプリングされたセッション・アクティビティが表示されます。アクティブ・セッションは毎秒サンプリングされ、SGAの循環バッファに格納されます。データベースに接続中で、Idle待機クラスに属さないイベントを待機中のセッションは、アクティブ・セッションとみなされます。これには、サンプリング時にCPUにあったセッションが含まれます。

各セッションのサンプルは一連の行で、V$ACTIVE_SESSION_HISTORYビューは、サンプルごとに各アクティブ・セッションについて1行を、最後のセッション・サンプルの行から順番に戻します。アクティブ・セッションのサンプルはSGAの循環バッファに格納されるため、システム・アクティビティが多いほど、循環バッファにセッション・アクティビティを格納できる秒数は短くなります。つまり、セッション・サンプルがV$ビューに表示される期間、またはV$ビューに表示されるセッション・アクティビティの秒数は、データベース・アクティビティに全面的に依存します。

V$ACTIVE_SESSION_HISTORYの内容も、AWRスナップショットの一部としてディスクにフラッシュされます。大規模なシステム・アクティビティ中は、このV$ビューの内容が極端に大きくなる可能性があるため、ディスクにはセッション・サンプルの一部のみが書き込まれます。

アクティブ・セッションのみを取得することで、システム上で許可されるセッション数ではなく、実行される作業に直接関連するサイズで管理可能なデータ・セットが表示されます。ASHを使用すると、V$ACTIVE_SESSION_HISTORYビューの現行データとDBA_HIST_ACTIVE_SESS_HISTORYビューの履歴データの両方を検査して詳細な分析を実行でき、通常、ワークロードを再現してパフォーマンス・トレース情報を追加収集する必要がありません。ASHには、取得されたSQL文ごとの実行計画情報も含まれます。この情報を使用することで、SQLの経過時間に多くの影響を与えているSQL実行部分を特定できます。ASHに表示されるデータは、次のように、取得する各種ディメンションでロール・アップできます。

- SQL文のSQL識別子

- SQL文の実行に使用されるSQL計画のSQL計画識別子およびハッシュ値

- SQL実行計画情報

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

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

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

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

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

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

- コンシューマ・グループ識別子

指定した期間のASH情報をレポートに収集できます。詳細は、「アクティブ・セッション履歴レポートの生成」を参照してください。

アクティブ・セッション履歴は、Active Data Guardフィジカル・スタンバイ・インスタンスおよびOracle Automatic Storage Management(Oracle ASM)インスタンスでも使用できます。これらのインスタンスでは、現在のセッションのアクティビティが収集されてV$ACTIVE_SESSION_HISTORYビューに表示されますが、ディスクへの書込みは行われません。

関連項目:

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

- Active Data Guardフィジカル・スタンバイ環境でのASHの使用方法の詳細は、『Oracle Database高可用性概要』 を参照してください。

5.1.1.4 システム統計とセッション統計

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

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

5.1.2 オペレーティング・システム統計

オペレーティング・システム統計は、オペレーティング・システム自体のパフォーマンスと、システムの主要ハードウェア・コンポーネントの使用率やパフォーマンスも提供します。この情報は、CPUサイクルや物理メモリーなどのリソースがすべて使用される可能性を検出し、ディスク・ドライブなどの周辺機器のパフォーマンスの低下を検出するために重要です。

オペレーティング・システム統計は、ハードウェアやオペレーティング・システムの稼働状態を示します。システム・アナリストの多くは、ハードウェア・リソースの不足に対してハードウェアを増設することで対応します。これは、オペレーティング・システム統計に示される一連の症状に対する対処療法です。医師が診断を下すときに患者の体温、脈拍および痛みを参考にするのと同じように、オペレーティング・システム統計は診断ツールとみなすのが最適です。ボトルネックの識別を容易にするために、パフォーマンス分析の対象となっているシステム内のすべてのサーバーについてオペレーティング・システム統計を収集します。

オペレーティング・システム統計には次のものが含まれます。

- CPU統計

- 仮想メモリー統計

- ディスクI/O統計

- ネットワーク統計

関連項目:
オペレーティング・システム統計の収集ツールの詳細は、「オペレーティング・システムのデータ収集ツール」を参照してください。

5.1.2.1 CPU統計

CPU使用率は、チューニング・プロセスで最も重要なオペレーティング・システム統計です。システム全体のCPU使用率と、マルチプロセッサ環境での各CPUの使用率を取得します。各CPUの使用率から、シングル・スレッドおよびスケーラビリティの問題を検出できます。

ほとんどのオペレーティング・システムでは、CPU使用率を、ユーザー領域またはユーザー・モードでの経過時間と、カーネル領域またはカーネル・モードでの経過時間でレポートします。この追加統計情報を使用すると、CPU上で実際に何が実行されているかをより詳細に分析できます。

Oracle Databaseを実行しているシステムで、通常はアプリケーションを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.1.2.2 仮想メモリー統計

仮想メモリー統計は、主として、システム上でページングまたはスワッピングのアクティビティがほとんど発生していないことを検証するために使用します。ページングまたはスワッピングが発生すると、システム・パフォーマンスは急速かつ予想外に低下します。

個々のプロセスのメモリー統計を使用すると、プログラミングの失敗でプロセス・ヒープから取得したメモリーを割当て解除できなかったことによるメモリー・リークを検出できます。これらの統計は、システムが起動後に安定状態に達した後、メモリー使用量が増加していないことを確認するために必要です。これは特に、複数のユーザー操作間でセッション状態が保持され、割当て解除が完全でない完了時状態情報のある中間層コンピュータの共有サーバー・アプリケーションにおいて重大な問題です。

5.1.2.3 ディスクI/O統計

データベースは一連のディスク上に常駐しているため、データベースのパフォーマンスにとってはI/Oサブシステムのパフォーマンスが非常に重要になります。ほとんどのオペレーティング・システムでは、ディスク・パフォーマンスに関する詳細な統計が提供されます。最も重要なディスク統計は、現在のレスポンス時間とディスク・キューの長さです。この統計は、ディスクが最適な状態で実行されているか、または過度の使用状態にあるかを示します。

I/Oシステムの通常のパフォーマンスを測定します。1ブロックの読取りに関する標準値は、使用しているハードウェアに応じて5から20ミリ秒です。ハードウェアが通常のパフォーマンス値を大幅に上回るレスポンス時間を示している場合は、不適切な状態で実行されているか過度の使用状態にあります。これがボトルネックです。ディスク・キューが2つを超えたら、そのディスクがシステムのボトルネックである可能性があります。

Oracle Databaseでは、発行したI/Oコールの一貫したI/O統計セットも保持されます。これらの統計は、次のディメンションにおいて、単一および複数のブロック読取り/書込み操作に対して取得されます。

- コンシューマ・グループ
Oracle Database Resource Managerが有効な場合、V$IOSTAT_CONSUMER_GROUPビューには現在有効なリソース・プランに含まれるすべてのコンシューマ・グループのI/O統計が取得されます。データベースは累積的な統計を1時間ごとにサンプリングし、履歴統計としてAWRに格納します。

- データベース・ファイル
現在アクセスされているか、または過去にアクセスされたデータベース・ファイルのI/O統計は、V$IOSTAT_FILEビューに取得されます。

- データベース機能
データベース機能(LGWRやDBWRなど)のI/O統計は、V$IOSTAT_FUNCTIONビューに取得されます。

関連項目:
Oracle Databaseのビューを使用してI/O問題を識別する方法の詳細は、「V$ビューを使用したI/Oの問題の識別」を参照してください。

5.1.2.4 ネットワーク統計

ネットワーク統計は、ディスク統計の場合とほぼ同様に、ネットワークまたはネットワーク・インタフェースが過負荷になっているかどうか、または最適に実行されているかどうかを判断する際に使用できます。今日のネットワーク・アプリケーションでは、ネットワーク待機時間が実際のユーザー・レスポンス時間の大部分を占めることがあります。このため、この統計は重要なデバッグ・ツールです。

Oracle Databaseでは、V$IOSTAT_NETWORKビューに一連のネットワークI/O統計が保持されます。

関連項目:
V$IOSTAT_NETWORKビューを使用してネットワークの問題を識別する方法の詳細は、「ネットワークの問題の識別」を参照してください。

5.1.2.5 オペレーティング・システムのデータ収集ツール

表5-1は、UNIXでのオペレーティング・システム統計収集ツールを示します。Windowsの場合は、パフォーマンス・モニター・ツールを使用します。

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

コンポーネント

UNIXツール

CPU

sar、vmstat、mpstat、iostat

メモリー

sar、vmstat

ディスク

sar、iostat

ネットワーク

netstat

5.1.3 統計の解釈

最初にパフォーマンス・データを調査するときは、統計を調べることによって潜在的な理論を構築できます。統計の解釈が正しいかどうかを確認する1つの方法は、他のデータとのクロスチェックを行うことです。これにより、統計またはイベントが実際に対象のものであるかどうかがわかります。また、フォアグラウンド・アクティビティはチューニング可能であるため、バックグラウンド・アクティビティの統計を分析する前に、フォアグラウンド・アクティビティの統計を先に分析することをお薦めします。

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

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

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

注意:
初期化パラメータSTATISTICS_LEVELがTYPICALまたはALLに設定されている場合、データベースの時間統計は自動的に収集されます。STATISTICS_LEVELをBASICに設定した場合、時間統計の収集を有効にするには、TIMED_STATISTICSをTRUEに設定する必要があります。STATISTICS_LEVELをBASICに設定すると、多くの自動機能が無効になることに注意してください。この設定はお薦めしません。
DB_CACHE_ADVICE、TIMED_STATISTICSまたはTIMED_OS_STATISTICSを、初期化パラメータ・ファイルか、ALTER_SYSTEMまたはALTER SESSIONを使用して明示的に設定した場合、その値はSTATISTICS_LEVELから導出された値を上書きします。

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

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

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

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

関連項目:

- STATISTICS_LEVELの設定の詳細は、「統計収集のレベルの設定」を参照してください。

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

5.2 自動ワークロード・リポジトリの概要

自動ワークロード・リポジトリ(AWR)では、問題の検出および自己チューニングを目的として、パフォーマンス統計が収集、処理および保守されます。このデータはメモリーとデータベースの両方に格納されます。収集されたデータは、レポートとビューの両方に表示できます。

AWRにより収集され処理される統計は、次のとおりです。

- データベース・セグメントのアクセス統計と使用統計を決定するオブジェクト統計。

- アクティビティの時間使用に基づく時間モデル統計。V$SYS_TIME_MODELおよびV$SESS_TIME_MODELビューに表示されます。

- V$SYSSTATおよびV$SESSTATビューで収集されるシステム統計とセッション統計の一部。

- システム上で最大負荷を生成しているSQL文。経過時間やCPUタイムなどの基準に基づきます。

- 最新のセッション・アクティビティの履歴を表すASH統計。

AWRを使用したデータベース統計の収集はデフォルトで有効になっており、STATISTICS_LEVEL初期化パラメータにより制御されます。AWRによる統計の収集を有効にするには、STATISTICS_LEVELパラメータをTYPICALまたはALLに設定する必要があります。デフォルトの設定はTYPICALです。STATISTICS_LEVELをBASICに設定すると、AWRを含め多くのOracle Database機能が無効になります。この設定はお薦めしません。STATISTICS_LEVELをBASICに設定しても、DBMS_WORKLOAD_REPOSITORYパッケージを使用すればAWR統計を手動で取得できます。ただし、セグメント統計やメモリー・アドバイザ情報など、多くのシステム統計のメモリー内収集が無効になるため、これらのスナップショットで取得された統計は不完全になる可能性があります。STATISTICS_LEVELの詳細は、Oracle Databaseリファレンスを参照してください。

5.2.1 スナップショット

スナップショットは、ADDMによりパフォーマンスの比較に使用される、特定の期間の履歴データのセットです。デフォルトでは、1時間ごとにパフォーマンス・データのスナップショットが自動的に生成され、その統計はワークロード・リポジトリに8日間保存されます。スナップショットを手動で作成することもできますが、通常は必要ありません。スナップショット間隔内のデータは、自動データベース診断モニター(ADDM)によって分析されます。ADDMの詳細は、「自動データベース診断モニターの概要」を参照してください。

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

スナップショットの管理の詳細は、「スナップショットの管理」を参照してください。

5.2.2 ベースライン

ベースラインには、パフォーマンス上の問題が発生したときに、類似する他のワークロード期間と比較するために保持されている特定の期間のパフォーマンス・データが含まれます。ベースラインに含まれるスナップショットは、自動AWR消去プロセスの対象からは除外され、無期限に保存されます。

Oracle Databaseで使用可能なベースラインには、次の複数のタイプがあります。

- 固定ベースライン

- 変動ウィンドウ・ベースライン

- ベースライン・テンプレート

5.2.2.1 固定ベースライン

固定ベースラインは、過去の指定時における、固定した連続的な期間に対応します。ベースラインは最適なレベルでのシステム動作を表す必要があるため、固定ベースラインを作成する前に、ベースラインとして選択する期間を慎重に検討してください。将来的に、このベースラインを、パフォーマンスの低下期間中に取得された別のベースラインまたはスナップショットと比較して、時間経過に沿ってパフォーマンスの低下を分析できます。

関連項目:
固定ベースラインの管理の詳細は、「ベースラインの管理」を参照してください。

5.2.2.2 変動ウィンドウ・ベースライン

変動ウィンドウ・ベースラインは、AWR保存期間内に存在するすべてのAWRデータに対応します。これは、AWRの全保存期間におけるAWRデータを使用してメトリックしきい値を計算できるため、適応しきい値を使用する際に役立ちます。

Oracle Databaseでは、システム定義による変動ウィンドウ・ベースラインが自動的に維持されます。システム定義による変動ウィンドウ・ベースラインのデフォルトのウィンドウ・サイズは、現在のAWR保存期間であり、デフォルトでは8日です。適応しきい値を使用する予定の場合は、しきい値を正確に計算するため、より長い変動ウィンドウ(30日など)を使用することを検討してください。変動ウィンドウ・ベースラインのサイズを変更するには、変動ウィンドウの日数を、AWR保存期間の日数以下の値に変更します。したがって、変動ウィンドウのサイズを拡張するには、先にAWR保存期間を適切に拡張しておく必要があります。

関連項目:
変動ウィンドウ・ベースラインのサイズ変更の詳細は、「デフォルトの変動ウィンドウ・ベースラインのウィンドウ・サイズの変更」を参照してください。

5.2.2.3 ベースライン・テンプレート

ベースライン・テンプレートを使用すると、将来の連続的な期間におけるベースラインを作成できます。ベースライン・テンプレートには、単一と繰返しという2つのタイプがあります。

単一ベースライン・テンプレートでは、将来の単一の連続的な期間におけるベースラインを作成できます。このテクニックは、将来に取得する期間が前もってわかっている場合に便利です。たとえば、次の週末にスケジュールされているシステム・テストの最中にAWRデータを取得することが可能です。この場合、単一ベースライン・テンプレートを作成することで、テストが実行されたときに自動的にその期間を取得できます。

繰返しベースライン・テンプレートでは、時間スケジュールの繰返しに基づいてベースラインを作成および削除できます。このテンプレートは、Oracle Databaseにより継続して連続的な期間を自動的に取得する場合に便利です。たとえば、1か月間にわたり毎週月曜日の朝にAWRデータを取得することが可能です。この場合、繰返しベースライン・テンプレートを作成することで、毎週月曜日という繰返しスケジュールに基づいてベースラインを自動的に作成し、1か月といった指定の期限の経過後に古いベースラインを自動的に削除できます。

関連項目:
ベースライン・テンプレートの管理の詳細は、「ベースライン・テンプレートの管理」を参照してください。

5.2.3 適応しきい値

適応しきい値を使用すると、管理オーバーヘッドを最小限に抑えながら、パフォーマンスの問題を監視および検出できます。適応しきい値は、変動ウィンドウ・ベースラインで取得されるメトリック値から導出された統計を使用して、システム・メトリックの警告しきい値とクリティカル・アラートしきい値を自動的に設定できます。これらのしきい値の統計は週に1回再計算され、時間の経過とともに変化するシステムのパフォーマンスに応じて新しいしきい値になります。適応しきい値はしきい値を週に1回再計算する以外に、定期的なワークロードのパターンに基づいて1日または週の異なる時間帯の様々なしきい値を計算します。

たとえば、多くのデータベースでは、日中のオンライン・トランザクション処理(OLTP)と夜間のバッチ処理をサポートしています。トランザクションごとのレスポンス時間のパフォーマンス・メトリックは、日中のOLTPパフォーマンスの低下の検出に役立ちます。ただし、有用なOLTPのしきい値は、長時間実行トランザクションが一般的なバッチ・ワークロードに対しては、ほとんどの場合低すぎます。そのため、OLTPに適切なしきい値では、バッチ処理時に不適切なパフォーマンス・アラートが頻繁にトリガーされることがあります。適応しきい値は、このようなワークロードのパターンを検出し、日中や夜間用の様々なしきい値を自動的に設定できます。

注意:
Oracle Database 11gリリース2(11.2)では、Oracle Databaseによってデータベースの適切な時間のグループ化が自動的に決定されます。ただし、Oracle Database 11gリリース2(11.2)より前のリリースでは、時間のグループ化はデータベース管理者によって手動で指定されます。

適応しきい値には、次の2種類があります。

- 最大パーセント: しきい値は、変動ウィンドウ・ベースライン内のデータに関して観察された最大値の割合の倍数として計算されます。

- 重大レベル: しきい値は、変動ウィンドウ・ベースライン内のデータに基づくしきい値を超える値が観察されることがどの程度異常かを表す統計の百分位数に設定されます。次のいずれかの百分位数を指定します。

- High (.95): この値を超えるのは100回のうち5回のみと予測されます。

- Very High (.99): この値を超えるのは100回のうち1回のみと予測されます。

- Severe (.999): この値を超えるのは1,000回のうち1回のみと予測されます。

- Extreme (.9999): この値を超えるのは10,000回のうち1回のみと予測されます。

注意:
Severe (.999)またはExtreme (.9999)を指定した場合、Oracle Databaseでは内部計算を実行してしきい値を設定します。ベースラインのデータを使用してこれらのレベルのしきい値を設定できず、重大レベルのしきい値が設定されない場合があります。
予測どおりにアラートを受信せず、重大レベルのしきい値Severe (.999)またはExtreme (.9999)を指定した場合、このしきい値をVery High (.99)やHigh (.95)などの低い値に設定できます。また、重大レベルのしきい値のかわりに、最大パーセントのしきい値を設定することもできます。しきい値を変更して、受信するアラートが多すぎることがわかった場合は、アラートの発生回数を増やすことができます。

最大パーセントのしきい値は、システムをピーク・ワークロードに対応するようサイジングし、現在のワークロード・ボリュームが以前の高い値に近づいているか、その値を超えているときにアラートを生成する必要がある場合に特に役立ちます。未知だが明確な制限値を持つメトリックは、このような設定の適切な候補になります。たとえば、1秒当たりの生成REDOのメトリックは、通常、最大パーセントのしきい値に対する適切な候補になります。

重大レベルのしきい値は、システムが正常に機能しているときに統計的に安定した動作を示すメトリックでは非常に役立ちますが、パフォーマンスが低下している場合は大きく変化する可能性があります。たとえば、トランザクションごとのレスポンス時間のメトリックは、適切に調整されたOLTPシステムの場合は安定していますが、パフォーマンスの問題が発生する場合は広い範囲で変動する可能性があります。重大レベルのしきい値は、異常なメトリックの値と異常なシステムのパフォーマンスの両方が発生する場合にアラートを生成することを意図しています。

注意:
ベースライン・メトリックを管理するための主インタフェースは、Oracle Enterprise Managerです。ベースライン・メトリックの適応しきい値を作成するには、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の説明に従ってOracle Enterprise Managerを使用します。

関連項目:
「変動ウィンドウ・ベースライン」

5.2.4 領域使用量

AWRによって使用される領域は、次のように複数の要因によって決まります。

- 特定の時点におけるシステム内のアクティブ・セッション数

- スナップショット間隔
スナップショット間隔により、スナップショットの収集頻度が決定されます。スナップショット間隔が短いほど頻度が高くなり、AWRにより収集されるデータ量が増大します。

- 履歴データの保存期間
保存期間により、このデータが消去前に保持されている期間が決定されます。保存期間が長いほど、AWRによって使用される領域が増加します。

デフォルトでは、スナップショットは1時間に1回取得され、データベースに8日間保存されます。これらのデフォルト設定では、同時アクティブ・セッション数が平均10の標準的なシステムの場合、AWRデータ用に約200から300MBの領域が必要になる可能性があります。スナップショット間隔と保存期間のデフォルト値は、どちらも変更できます。AWR設定の変更の詳細は、「スナップショット設定の変更」を参照してください。

スナップショット間隔を長くして保存期間を短縮すると、AWRの領域使用量を減らすことができます。保存期間を短縮する場合は、Oracle Databaseの複数の自己管理機能が正常に機能するためにAWRデータに依存することに注意してください。十分なデータがないと、次のようなコンポーネントと機能の妥当性および正確さに影響する可能性があります。

- 自動データベース診断モニター

- SQLチューニング・アドバイザ

- UNDOアドバイザ

- セグメント・アドバイザ

可能な場合は、少なくとも1つのワークロード・サイクル全体で収集できるように、AWR保存期間を十分な長さに設定することをお薦めします。システムのワークロード・サイクルが平日にOLTPワークロード、週末にバッチ・ジョブというような週単位になっている場合、デフォルトのAWR保存期間である8日を変更する必要はありません。ただし、月末の帳簿締め処理時にシステムの月次ピーク負荷が発生する場合は、保存期間を1か月に設定する操作が必要になることがあります。

例外的な状況では、スナップショット間隔を0(ゼロ)に設定して、自動スナップショット収集を無効にすることができます。この場合、ワークロードおよび統計データの自動収集は停止され、Oracle Databaseの自己管理機能の大部分が動作しなくなります。また、スナップショットを手動で作成することもできません。このため、自動スナップショット収集を無効にしないことをお薦めします。

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

この項では、AWRの管理方法について説明します。この項には、次の項目があります。

- スナップショットの管理

- ベースラインの管理

- ベースライン・テンプレートの管理

- 自動ワークロード・リポジトリ・データの転送

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

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

- 自動ワークロード・リポジトリ期間比較レポートの生成

- アクティブ・セッション履歴レポートの生成

- アクティブ・セッション履歴レポートの使用

関連項目:
AWRの説明は、「自動ワークロード・リポジトリの概要」を参照してください。

5.3.1 スナップショットの管理

デフォルトでは、1時間ごとにスナップショットが生成され、その統計はワークロード・リポジトリに8日間保存されます。必要に応じて、DBMS_WORKLOAD_REPOSITORYプロシージャを使用してスナップショットを手動で作成、削除および変更できます。これらのプロシージャを起動するには、DBAロールが付与されている必要があります。

スナップショットを管理するための主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、スナップショットは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで管理する必要があります。Oracle Enterprise Managerが使用できない場合、スナップショットは、次の項の手順に従ってDBMS_WORKLOAD_REPOSITORYパッケージで管理します。

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

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

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

関連項目:

- スナップショットの詳細は、「スナップショット」を参照してください。

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

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

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

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/

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

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

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プロシージャがコールされると、スナップショット範囲で指定された期間に属するアクティブ・セッション履歴(ASH)データも消去されます。

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

指定されたデータベースIDのスナップショット生成に関して、その間隔、保存および取得済上位SQLを調整できますが、この調整によって、Oracle Database診断ツールの精度に影響を与える可能性があります。

INTERVAL設定は、データベースがスナップショットを自動的に生成する頻度に影響します。RETENTION設定は、データベースがスナップショットをワークロード・リポジトリに保存する期間に影響します。TOPNSQL設定は、SQL基準(経過時間、CPU時間、解析コール、共有可能メモリー、バージョン・カウント)ごとにフラッシュする上位SQLの数に影響します。この設定の値は、統計レベルまたはフラッシュ・レベルによる影響を受けず、AWR SQL収集のシステム・デフォルト動作より優先されます。この設定値をMAXIMUMに設定して、共有SQL領域内の完全な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.3.2 ベースラインの管理

この項では、ベースラインの管理方法について説明します。ベースラインを管理するための主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、ベースラインは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで管理する必要があります。Oracle Enterprise Managerが使用できない場合、ベースラインは、次の項の手順に従ってDBMS_WORKLOAD_REPOSITORYパッケージで管理します。

- ベースラインの作成

- ベースラインの削除

- ベースラインの名前変更

- ベースライン・メトリックの表示

- デフォルトの変動ウィンドウ・ベースラインのウィンドウ・サイズの変更

関連項目:

- ベースラインの詳細は、「ベースライン」を参照してください。

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

5.3.2.1 ベースラインの作成

この項では、スナップショットの既存範囲を使用してベースラインを作成する方法について説明します。

ベースラインを作成するには、次の手順を実行します。

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ビューに表示されます。

5.3.2.2 ベースラインの削除

この項では、既存のベースラインの削除方法について説明します。すでに使用されていないベースラインは、ディスク領域を節約するために定期的に削除できます。ベースラインに関連付けられたスナップショットは、ベースラインが明示的に削除されるか、ベースラインが期限切れになるまで無期限に保持されます。

ベースラインを削除するには、次の手順を実行します。

1. DBA_HIST_BASELINEビューで既存のベースラインを確認し、削除するベースラインを決定します。

2. DROP_BASELINEプロシージャを使用して、次のように目的のベースラインを削除します。

BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'peak baseline',
cascade => FALSE, dbid => 3310949047);
END;
/

この例では、ベースライン名はpeak baselineです。cascadeパラメータはFALSEに設定されているため、ベースラインのみが削除されます。このパラメータをTRUEに設定すると、この削除操作により、ベースラインに関連付けられたスナップショットも削除されます。オプションのdbidパラメータでは、データベース識別子を指定します(この例では3310949047)。dbidの値を指定しない場合は、ローカル・データベース識別子がデフォルト値として使用されます。

5.3.2.3 ベースラインの名前変更

この項では、ベースラインの名前を変更する方法について説明します。

ベースラインの名前を変更するには、次の手順を実行します。

1. DBA_HIST_BASELINEビューで既存のベースラインを確認し、名前を変更するベースラインを決定します。

2. RENAME_BASELINEプロシージャを使用して、次のように目的のベースラインの名前を変更します。

BEGIN
DBMS_WORKLOAD_REPOSITORY.RENAME_BASELINE (
old_baseline_name => 'peak baseline',
new_baseline_name => 'peak mondays',
dbid => 3310949047);
END;
/

この例では、ベースラインの名前がpeak baseline(old_baseline_nameパラメータによる指定)からpeak mondays(new_baseline_nameパラメータによる指定)に変更されます。オプションのdbidパラメータでは、データベース識別子を指定します(この例では3310949047)。dbidの値を指定しない場合、デフォルト値はローカルDBIDです。

5.3.2.4 ベースライン・メトリックの表示

この項では、ベースラインで取得される期間中のメトリックしきい値設定を表示する方法について説明します。適応しきい値とともに使用する場合、ベースラインには、データベースでメトリックしきい値を計算する際に使用できるAWRデータが含まれます。SELECT_BASELINE_METRICSファンクションにより、ベースライン期間におけるメトリック値のサマリー統計を表示できます。

ベースラインのメトリック情報を表示するには、次の手順を実行します。

1. DBA_HIST_BASELINEビューで既存のベースラインを確認し、メトリック情報を表示するベースラインを決定します。

2. SELECT_BASELINE_METRICSファンクションを使用して、次のように目的のベースラインのメトリック情報を表示します。

BEGIN
DBMS_WORKLOAD_REPOSITORY.SELECT_BASELINE_METRICS (
baseline_name => 'peak baseline',
dbid => 3310949047,
instance_num => '1');
END;
/

この例では、ベースライン名はpeak baselineです。オプションのdbidパラメータでは、データベース識別子を指定します(この例では3310949047)。dbidの値を指定しない場合は、ローカル・データベース識別子がデフォルト値として使用されます。オプションのinstance_numパラメータでは、インスタンス番号を指定します(この例では1)。instance_numの値を指定しない場合は、ローカル・インスタンスがデフォルト値として使用されます。

5.3.2.5 デフォルトの変動ウィンドウ・ベースラインのウィンドウ・サイズの変更

この項では、デフォルトの変動ウィンドウ・ベースラインのウィンドウ・サイズを変更する方法について説明します。デフォルトの変動ウィンドウ・ベースラインの詳細は、「変動ウィンドウ・ベースライン」を参照してください。

デフォルトの変動ウィンドウ・ベースラインのサイズを変更するには、次のようにMODIFY_BASELINE_WINDOW_SIZEプロシージャを使用します。

BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE_WINDOW_SIZE (
window_size => 30,
dbid => 3310949047);
END;
/

window_sizeパラメータでは、デフォルトの変動ウィンドウ・サイズの新規ウィンドウ・サイズ(日数)を指定します。この例では、window_sizeパラメータは30に設定されています。ウィンドウ・サイズは、AWR保存設定の値以下の値に設定する必要があります。現在のAWR保存期間を超えるウィンドウ・サイズを設定するには、「スナップショット設定の変更」の手順に従ってあらかじめretentionパラメータの値を増やしておく必要があります。

この例では、オプションのdbidパラメータでデータベース識別子を3310949047に指定しています。dbidの値を指定しない場合は、ローカル・データベース識別子がデフォルト値として使用されます。

5.3.3 ベースライン・テンプレートの管理

この項では、ベースライン・テンプレートの管理方法について説明します。ベースライン・テンプレートを使用すると、ベースラインを自動的に作成して将来の指定した期間を取得できます。ベースライン・テンプレートの詳細は、「ベースライン・テンプレート」を参照してください。

ベースライン・テンプレートを管理するための主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、ベースライン・テンプレートは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで管理する必要があります。Oracle Enterprise Managerが使用できない場合、ベースライン・テンプレートは、次の項の手順に従ってDBMS_WORKLOAD_REPOSITORYパッケージで管理します。

- 単一ベースライン・テンプレートの作成

- 繰返しベースライン・テンプレートの作成

- ベースライン・テンプレートの削除

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

5.3.3.1 単一ベースライン・テンプレートの作成

この項では、単一ベースライン・テンプレートの作成方法について説明します。単一ベースライン・テンプレートを使用して、将来の単一の固定期間におけるベースラインを作成できます。たとえば、単一ベースライン・テンプレートを作成し、2009年4月2日の午後5:00から午後8:00までに取得されるベースラインを生成できます。

単一ベースライン・テンプレートを作成するには、次のようにCREATE_BASELINE_TEMPLATEプロシージャを使用します。

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
start_time => '2009-04-02 17:00:00 PST',
end_time => '2009-04-02 20:00:00 PST',
baseline_name => 'baseline_090402',
template_name => 'template_090402', expiration => 30,
dbid => 3310949047);
END;
/

start_timeパラメータでは、作成するベースラインの開始時間を指定します。end_timeパラメータでは、作成するベースラインの終了時間を指定します。baseline_nameパラメータでは、作成するベースラインの名前を指定します。template_nameパラメータでは、ベースライン・テンプレートの名前を指定します。オプションのexpirationパラメータでは、ベースラインの有効期限(日数)を指定します。指定しない場合、ベースラインは無期限になります。オプションのdbidパラメータでは、データベース識別子を指定します。指定しない場合は、ローカル・データベース識別子がデフォルト値として使用されます。

この例では、3310949047というデータベースIDを持つデータベース上に、2009年4月2日の午後5:00から午後8:00までの期間におけるベースラインbaseline_090402を生成するtemplate_090402というベースライン・テンプレートが作成されます。このベースラインは、30日後に期限切れとなります。

5.3.3.2 繰返しベースライン・テンプレートの作成

この項では、繰返しベースライン・テンプレートの作成方法について説明します。繰返しベースライン・テンプレートは、将来の一定期間において特定の時間間隔で繰り返されるベースラインを自動的に作成する際に使用します。たとえば、繰返しベースライン・テンプレートを作成し、2009年の毎週月曜日の午後5:00から午後8:00までに繰り返されるベースラインを生成できます。

繰返しベースライン・テンプレートを作成するには、次のようにCREATE_BASELINE_TEMPLATEプロシージャを使用します。

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
day_of_week => 'monday', hour_in_day => 17,
duration => 3, expiration => 30,
start_time => '2009-04-02 17:00:00 PST',
end_time => '2009-12-31 20:00:00 PST',
baseline_name_prefix => 'baseline_2009_mondays_',
template_name => 'template_2009_mondays',
dbid => 3310949047);
END;
/

day_of_weekパラメータでは、ベースラインを繰り返す曜日を指定します。hour_in_dayパラメータでは、ベースラインを開始する日中の時間を指定します。durationパラメータでは、ベースラインを継続させる期間(時間数)を指定します。expirationパラメータでは、作成する各ベースラインの保存日数を指定します。NULLに設定すると、ベースラインは無期限になります。start_timeパラメータでは、作成するベースラインの開始時間を指定します。end_timeパラメータでは、作成するベースラインの終了時間を指定します。baseline_name_prefixパラメータでは、ベースラインの作成時にデータ情報に追加するベースライン接頭辞の名前を指定します。template_nameパラメータでは、ベースライン・テンプレートの名前を指定します。オプションのdbidパラメータでは、データベース識別子を指定します。指定しない場合は、ローカル・データベース識別子がデフォルト値として使用されます。

この例では、3310949047というデータベースIDを持つデータベース上に、2009年4月2日の午後5:00から2009年12月31日の午後8:00までの期間において毎週月曜日の午後5:00から午後8:00までベースラインを生成するtemplate_2009_mondaysというベースライン・テンプレートが作成されます。各ベースラインは、baseline_2009_mondays_という接頭辞付きの名前で作成され、30日後に期限切れとなります。

5.3.3.3 ベースライン・テンプレートの削除

この項では、既存のベースライン・テンプレートの削除方法について説明します。すでに使用されていないベースライン・テンプレートは、ディスク領域を節約するために定期的に削除できます。

ベースライン・テンプレートを削除するには、次の手順を実行します。

1. DBA_HIST_BASELINE_TEMPLATEビューで既存のベースラインを確認し、削除するベースライン・テンプレートを決定します。

2. DROP_BASELINE_TEMPLATEプロシージャを使用して、次のように目的のベースライン・テンプレートを削除します。

BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE_TEMPLATE (
template_name => 'template_2009_mondays',
dbid => 3310949047);
END;
/

template_nameパラメータでは、削除するベースライン・テンプレートの名前を指定します。この例では、削除するベースライン・テンプレートの名前はtemplate_2009_mondaysです。オプションのdbidパラメータでは、データベース識別子を指定します(この例では3310949047)。dbidの値を指定しない場合は、ローカル・データベース識別子がデフォルト値として使用されます。

5.3.4 自動ワークロード・リポジトリ・データの転送

Oracle Databaseでは、システム間でAWRデータを転送できます。この機能は、別のシステムを使用してAWRデータを分析する場合に役立ちます。AWRデータを転送するには、次の項の手順に従って、最初にソース・システムのデータベースからAWRスナップショット・データを抽出し、次にそのデータをターゲット・システムのデータベースにロードする必要があります。

- AWRデータの抽出

- AWRデータのロード

5.3.4.1 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を指定して、AWRデータを抽出するスナップショットの範囲を定義します。

Enter value for begin_snap: 30
Enter value for end_snap: 40

この例では、スナップショットIDが30のスナップショットが最初のスナップショットとして選択され、スナップショットIDが40のスナップショットが最後のスナップショットとして選択されます。

5. ディレクトリ・オブジェクトのリストが表示されます。
エクスポート・ダンプ・ファイルが保存されているディレクトリを示すディレクトリ・オブジェクトを指定します。

Enter value for directory_name: DATA_PUMP_DIR

この例では、ディレクトリ・オブジェクトDATA_PUMP_DIRが選択されます。

6. エクスポート・ダンプ・ファイルの名前の接頭辞を指定します(.dmpという接尾辞が自動的に追加されます)。

Enter value for file_name: awrdata_30_40

この例では、awrdata_30_40というエクスポート・ダンプ・ファイルが、指定したディレクトリ・オブジェクトに対応するディレクトリに作成されます。

Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
C:\ORACLE\PRODUCT\11.1.0.5\DB_1\RDBMS\LOG\AWRDATA_30_40.DMP
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 08:58:20

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

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

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

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

Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Completed 113 CONSTRAINT objects in 11 seconds
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Completed 1 REF_CONSTRAINT objects in 1 seconds
Job "SYS"."SYS_IMPORT_FULL_03" successfully completed at 09:29:30
... Dropping AWR_STAGE user
End of AWR Load

抽出する必要のあるAWRデータの分量によっては、AWR抽出操作の完了までにしばらく時間がかかる場合があります。AWRデータのロード後、ステージング・スキーマは自動的に削除されます。

5.3.5 自動ワークロード・リポジトリ・ビューの使用

通常、AWRデータはOracle Enterprise ManagerまたはAWRレポートで表示します。ただし、次のビューで統計を表示できます。

- V$ACTIVE_SESSION_HISTORY
このビューには、1秒ごとにサンプリングされたアクティブなデータベース・セッションのアクティビティが表示されます。「アクティブ・セッション履歴」を参照してください。

- V$メトリック・ビューでは、システムのパフォーマンスを追跡するためのメトリック・データが示されます。
メトリック・ビューは、イベント、イベント・クラス、システム、セッション、サービス、ファイルおよび表領域のメトリックなど、様々なグループに編成されています。これらのグループは、V$METRICGROUPビューで識別されます。

- DBA_HISTビュー
DBA_HISTビューには、データベースに格納されている履歴データが表示されます。このグループのビューには次のようなものがあります。

- DBA_HIST_ACTIVE_SESS_HISTORYには、最新のシステム・アクティビティに関するメモリー内アクティブ・セッション履歴の内容の履歴が表示されます。

- DBA_HIST_BASELINEには、システム上に収集されたベースラインに関する情報(各ベースラインの時間範囲やベースライン・タイプなど)が表示されます。

- DBA_HIST_BASELINE_DETAILSには、特定のベースラインに関する詳細情報が表示されます。

- DBA_HIST_BASELINE_TEMPLATEには、ベースラインを生成するためにシステムによって使用されるベースライン・テンプレートに関する情報が表示されます。

- DBA_HIST_DATABASE_INSTANCEには、データベース環境に関する情報が表示されます。

- DBA_HIST_DB_CACHE_ADVICEには、各行に対応するキャッシュ・サイズの物理読取りの数の履歴予測が表示されます。

- DBA_HIST_DISPATCHERには、スナップショット時の各ディスパッチャ・プロセスの履歴情報が表示されます。

- DBA_HIST_DYN_REMASTER_STATSには、動的リマスタリング・プロセスに関する統計情報が表示されます。

- DBA_HIST_IOSTAT_DETAILには、ファイル・タイプと機能別に集計された履歴I/O統計が表示されます。

- DBA_HIST_SHARED_SERVER_SUMMARYには、共有サーバー・アクティビティ、一般的なキュー、およびディスパッチャ・キューの履歴情報が表示されます。

- DBA_HIST_SNAPSHOTには、システム内のスナップショットの情報が表示されます。

- DBA_HIST_SQL_PLANには、SQL実行計画が表示されます。

- DBA_HIST_WR_CONTROLには、AWR制御用の設定が表示されます。

関連項目:
動的および静的なデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

5.3.6 自動ワークロード・リポジトリ・レポートの生成

AWRレポートは、2つのスナップショット(または2つの時点)の間に取得されたデータを示します。AWRレポートは複数のセクションに分かれています。HTMLレポートには、セクション間ですばやくナビゲートできるようにリンクが組み込まれています。レポートの内容には、選択した範囲のスナップショットに関するシステムのワークロード・プロファイルが含まれます。

AWRレポートを生成するための主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、AWRレポートは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで生成する必要があります。Oracle Enterprise Managerが使用できない場合、AWRレポートは、次の項の手順に従ってSQLスクリプトを実行することで生成します。

- AWRレポートの生成

- Oracle RAC AWRレポートの生成

- 特定のデータベース・インスタンスのAWRレポートの生成

- 特定のデータベース・インスタンスのOracle RAC AWRレポートの生成

- SQL文のAWRレポートの生成

- 特定のデータベース・インスタンスのSQL文のAWRレポートの生成

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

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

5.3.6.1 AWRレポートの生成

awrrpt.sql SQLスクリプトでは、一定範囲のスナップショットIDの統計を表示する、HTMLまたはテキストのレポートが生成されます。

AWRレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: text

この例では、テキスト形式のレポートが選択されます。

3. スナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最近2日間に取得されたスナップショットが表示されます。

4. ワークロード・リポジトリ・レポートの最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 150
Enter value for end_snap: 160

この例では、スナップショットIDが150のスナップショットが最初のスナップショットとして選択され、スナップショットIDが160のスナップショットが最後のスナップショットとして選択されます。

5. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrrpt_1_150_160

この例では、デフォルト名が使用され、awrrpt_1_150_160というAWRレポートが生成されます。

5.3.6.2 Oracle RAC AWRレポートの生成

awrgrpt.sql SQLスクリプトでは、現在のデータベース識別子およびOracle Real Application Clusters(Oracle RAC)環境のすべての使用可能なデータベース・インスタンスを使用して、一定範囲のスナップショットIDの統計を表示する、HTMLまたはテキストのレポートが生成されます。

注意:
HTMLのレポートは、テキストのレポートよりも読みやすいため、Oracle RAC環境では、テキストではなく、常にHTMLレポートの生成を試みてください。

Oracle RAC環境でAWRレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrgrpt.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

3. スナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最終日に取得されたスナップショットが表示されます。

4. ワークロード・リポジトリ・レポートの最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 150
Enter value for end_snap: 160

この例では、スナップショットIDが150のスナップショットが最初のスナップショットとして選択され、スナップショットIDが160のスナップショットが最後のスナップショットとして選択されます。

5. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrrpt_rac_150_160.html

この例では、デフォルト名が使用され、awrrpt_rac_150_160.htmlというAWRレポートが生成されます。

5.3.6.3 特定のデータベース・インスタンスのAWRレポートの生成

awrrpti.sql SQLスクリプトでは、特定のデータベースおよびインスタンスを使用して、一定範囲のスナップショットIDの統計を表示する、HTMLまたはテキストのレポートが生成されます。このスクリプトでは、AWRレポートの生成に使用されるデータベース識別子およびインスタンスを指定できます。

特定のデータベース・インスタンスのAWRレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrrpti.sql

2. レポートの形式として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         examp1690
3309173529        1 TINT251      tint251      samp251

3. 次のようにデータベース識別子(dbid)およびインスタンス番号(inst_num)の値を入力します。

Enter value for dbid: 3309173529
Using 3309173529 for database Id
Enter value for inst_num: 1

4. スナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最近2日間に取得されたスナップショットが表示されます。

5. ワークロード・リポジトリ・レポートの最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 150
Enter value for end_snap: 160

この例では、スナップショットIDが150のスナップショットが最初のスナップショットとして選択され、スナップショットIDが160のスナップショットが最後のスナップショットとして選択されます。

6. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrrpt_1_150_160

この例では、デフォルト名が使用され、3309173529というデータベースIDを持つデータベース・インスタンスでawrrpt_1_150_160というAWRレポートが生成されます。

5.3.6.4 特定のデータベース・インスタンスのOracle RAC AWRレポートの生成

awrgrpti.sql SQLスクリプトでは、Oracle RAC環境で実行されている特定のデータベースおよびインスタンスを使用して、一定範囲のスナップショットIDの統計を表示する、HTMLまたはテキストのレポートが生成されます。このスクリプトでは、AWRレポートの生成に使用されるデータベース識別子およびデータベース・インスタンスのカンマ区切りのリストを指定できます。

注意:
HTMLのレポートは、テキストのレポートよりも読みやすいため、Oracle RAC環境では、テキストではなく、常にHTMLレポートの生成を試みてください。

Oracle RAC環境の特定のデータベース・インスタンスのAWRレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrgrpti.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

使用可能なデータベース識別子およびインスタンス番号のリストが表示されます。

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id    Inst Num DB Name      Instance     Host
----------- -------- ------------ ------------ ------------
3309173529        1 MAIN         main         examp1690
3309173529        1 TINT251      tint251      samp251
3309173529        2 TINT251      tint252      samp252

3. データベース識別子(dbid)の値を入力します。

Enter value for dbid: 3309173529
Using 3309173529 for database Id

4. レポートに含めるOracle RACインスタンスのインスタンス番号(instance_numbers_or_all)の値を入力します。

Enter value for instance_numbers_or_all: 1,2

5. スナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最近2日間に取得されたスナップショットが表示されます。

6. ワークロード・リポジトリ・レポートの最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 150
Enter value for end_snap: 160

この例では、スナップショットIDが150のスナップショットが最初のスナップショットとして選択され、スナップショットIDが160のスナップショットが最後のスナップショットとして選択されます。

7. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrrpt_rac_150_160.html

この例では、デフォルト名が使用され、3309173529というデータベースIDを持つデータベース・インスタンスでawrrpt_rac_150_160.htmlというAWRレポートが生成されます。

5.3.6.5 SQL文のAWRレポートの生成

awrsqrpt.sql SQLスクリプトでは、一定範囲のスナップショットIDに対する特定のSQL文の統計を表示する、HTMLまたはテキストのレポートが生成されます。SQL文のパフォーマンスを検査またはデバッグする場合にこのレポートを実行します。

特定のSQL文のAWRレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

3. スナップショットIDをリストする日数を指定します。

Enter value for num_days: 1

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、前日に取得されたスナップショットが表示されます。

4. ワークロード・リポジトリ・レポートの最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 146
Enter value for end_snap: 147

この例では、スナップショットIDが146のスナップショットが最初のスナップショットとして選択され、スナップショットIDが147のスナップショットが最後のスナップショットとして選択されます。

5. 特定のSQL文のSQL IDを指定して統計を表示します。

Enter value for sql_id: 2b064ybzkwf1y

この例では、2b064ybzkwf1yというSQL IDを持つSQL文が選択されます。

6. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrrpt_1_146_147.html

この例では、デフォルト名が使用され、awrrpt_1_146_147というAWRレポートが生成されます。

5.3.6.6 特定のデータベース・インスタンスのSQL文のAWRレポートの生成

awrsqrpi.sql SQLスクリプトでは、特定のデータベースおよびインスタンスを使用して、スナップショットIDの範囲について特定のSQL文の統計を表示する、HTMLまたはテキストのレポートが生成されます。このスクリプトでは、AWRレポートの生成対象となるデータベース識別子およびインスタンスを指定できます。このレポートは、特定のデータベースおよびインスタンスにおけるSQL文のパフォーマンスを調査またはデバッグする場合に実行します。

指定したデータベース・インスタンスで特定のSQL文のAWRレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrsqrpi.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

使用可能なデータベース識別子およびインスタンス番号のリストが表示されます。

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id    Inst Num DB Name      Instance     Host
----------- -------- ------------ ------------ ------------
3309173529        1 MAIN         main         examp1690
3309173529        1 TINT251      tint251      samp251

3. 次のようにデータベース識別子(dbid)およびインスタンス番号(inst_num)の値を入力します。

Enter value for dbid: 3309173529
Using 3309173529 for database Id
Enter value for inst_num: 1
Using 1 for instance number

4. スナップショットIDをリストする日数を指定します。

Enter value for num_days: 1

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、前日に取得されたスナップショットが表示されます。

5. ワークロード・リポジトリ・レポートの最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 146
Enter value for end_snap: 147

この例では、スナップショットIDが146のスナップショットが最初のスナップショットとして選択され、スナップショットIDが147のスナップショットが最後のスナップショットとして選択されます。

6. 特定のSQL文のSQL IDを指定して統計を表示します。

Enter value for sql_id: 2b064ybzkwf1y

この例では、2b064ybzkwf1yというSQL IDを持つSQL文が選択されます。

7. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrrpt_1_146_147.html

この例では、デフォルト名が使用され、3309173529というデータベースIDを持つデータベース・インスタンスでawrrpt_1_146_147というAWRレポートが生成されます。

5.3.7 自動ワークロード・リポジトリ期間比較レポートの生成

AWRレポートが2つのスナップショット(または2つの時点)間のAWRデータを示すのに対し、AWR期間比較レポートには2つの期間(または4つのスナップショットと同じ2つのAWRレポート)の相違点が示されます。AWR期間比較レポートを使用すると、2つの期間の間で異なる詳細なパフォーマンス属性と構成設定を明らかにできます。

たとえば、アプリケーションのワークロードが毎日午後10:00から午前0:00の間は安定していることがわかっており、ある木曜日の午後10:00から午後11:00のパフォーマンスが低い場合、木曜日の午後10:00から午後11:00と水曜日の午後10:00から午後11:00のAWR期間比較レポートを生成すると、これらの期間で相違のある構成設定、ワークロード・プロファイルおよび統計が特定されます。相違点に基づいて、パフォーマンス低下の原因を簡単に診断できます。AWR期間比較レポート用に選択する2つの期間は、時間の長さが異なってもかまいません。レポートでは、各期間中にデータベースで費やされた時間によって統計を正規化し、2つの期間の間の最大相違でソートされた統計データを提示するためです。

AWR期間比較レポートは複数のセクションに分かれています。HTMLレポートには、セクション間ですばやくナビゲートできるようにリンクが組み込まれています。レポートの内容には、選択した範囲のスナップショットに関するシステムのワークロード・プロファイルが含まれます。

AWR期間比較レポートを生成するための主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、AWR期間比較レポートは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで生成する必要があります。Oracle Enterprise Managerが使用可能でない場合は、次の項の手順に従ってSQLスクリプトを実行して、AWR期間比較レポートを生成できます。

- AWR期間比較レポートの生成

- Oracle RAC AWR期間比較レポートの生成

- 特定のデータベース・インスタンスのAWR期間比較レポートの生成

- 特定のデータベース・インスタンスのOracle RAC AWR期間比較レポートの生成

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

5.3.7.1 AWR期間比較レポートの生成

awrddrpt.sql SQLスクリプトでは、選択された2つの期間の詳細なパフォーマンス属性および構成設定を比較する、HTMLまたはテキストのレポートが生成されます。

AWR期間比較レポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrddrpt.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

3. 第1期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最近2日間に取得されたスナップショットが表示されます。

4. 第1期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 102
Enter value for end_snap: 103

この例では、第1期間において、スナップショットIDが102のスナップショットが最初のスナップショットとして選択され、スナップショットIDが103のスナップショットが最後のスナップショットとして選択されます。

5. 第2期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days2: 1

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、前日に取得されたスナップショットが表示されます。

6. 第2期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap2: 126
Enter value for end_snap2: 127

この例では、第2期間において、スナップショットIDが126のスナップショットが最初のスナップショットとして選択され、スナップショットIDが127のスナップショットが最後のスナップショットとして選択されます。

7. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrdiff_1_102_1_126.txt

この例では、デフォルト名が使用され、awrdiff_1_102_126というAWRレポートが生成されます。

5.3.7.2 Oracle RAC AWR期間比較レポートの生成

awrgdrpt.sql SQLスクリプトでは、現在のデータベース識別子およびOracle RAC環境のすべての使用可能なデータベース・インスタンスを使用して、選択された2つの期間の詳細なパフォーマンス属性および構成設定を比較する、HTMLまたはテキストのレポートが生成されます。

注意:
HTMLのレポートは、テキストのレポートよりも読みやすいため、Oracle RAC環境では、テキストではなく、常にHTMLレポートの生成を試みてください。

Oracle RAC環境でAWR期間比較レポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrgdrpt.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

3. 第1期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最近2日間に取得されたスナップショットが表示されます。

4. 第1期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 102
Enter value for end_snap: 103

この例では、第1期間において、スナップショットIDが102のスナップショットが最初のスナップショットとして選択され、スナップショットIDが103のスナップショットが最後のスナップショットとして選択されます。

5. 第2期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days2: 1

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、前日に取得されたスナップショットが表示されます。

6. 第2期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap2: 126
Enter value for end_snap2: 127

この例では、第2期間において、スナップショットIDが126のスナップショットが最初のスナップショットとして選択され、スナップショットIDが127のスナップショットが最後のスナップショットとして選択されます。

7. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrracdiff_1st_1_2nd_1.html

この例では、デフォルト名が使用され、awrrac_1st_1_2nd_1.htmlというAWRレポートが生成されます。

5.3.7.3 特定のデータベース・インスタンスのAWR期間比較レポートの生成

awrddrpi.sql SQLスクリプトでは、特定のデータベースおよびインスタンスにおける選択された2つの期間の詳細なパフォーマンス属性および構成設定を比較する、HTMLまたはテキストのレポートが生成されます。このスクリプトでは、AWR期間比較レポートの生成に使用されるデータベース識別子およびインスタンスを指定できます。

指定したデータベース・インスタンスでAWR期間比較レポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrddrpi.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: text

この例では、テキスト形式のレポートが選択されます。

3. 使用可能なデータベース識別子およびインスタンス番号のリストが表示されます。

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id    Inst Num DB Name      Instance     Host
----------- -------- ------------ ------------ ------------
3309173529        1 MAIN         main         examp1690
3309173529        1 TINT251      tint251      samp251

次のように、第1期間に対するデータベース識別子(dbid)およびインスタンス番号(inst_num)の値を入力します。

Enter value for dbid: 3309173529
Using 3309173529 for Database Id for the first pair of snapshots
Enter value for inst_num: 1
Using 1 for Instance Number for the first pair of snapshots

4. 第1期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最近2日間に取得されたスナップショットが表示されます。

5. 第1期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 102
Enter value for end_snap: 103

この例では、第1期間において、スナップショットIDが102のスナップショットが最初のスナップショットとして選択され、スナップショットIDが103のスナップショットが最後のスナップショットとして選択されます。

6. 次のように、第2期間に対するデータベース識別子(dbid)およびインスタンス番号(inst_num)の値を入力します。

Enter value for dbid2: 3309173529
Using 3309173529 for Database Id for the second pair of snapshots
Enter value for inst_num2: 1
Using 1 for Instance Number for the second pair of snapshots

7. 第2期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days2: 1

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、前日に取得されたスナップショットが表示されます。

8. 第2期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap2: 126
Enter value for end_snap2: 127

この例では、第2期間において、スナップショットIDが126のスナップショットが最初のスナップショットとして選択され、スナップショットIDが127のスナップショットが最後のスナップショットとして選択されます。

9. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrdiff_1_102_1_126.txt

この例では、デフォルト名が使用され、3309173529というデータベースIDを持つデータベース・インスタンスでawrdiff_1_102_126というAWRレポートが生成されます。

5.3.7.4 特定のデータベース・インスタンスのOracle RAC AWR期間比較レポートの生成

awrgdrpi.sql SQLスクリプトでは、Oracle RAC環境の特定のデータベースおよびインスタンスを使用して、選択された2つの期間の詳細なパフォーマンス属性および構成設定を比較する、HTMLまたはテキストのレポートが生成されます。このスクリプトでは、AWR期間比較レポートの生成に使用されるデータベース識別子およびデータベース・インスタンスのカンマ区切りのリストを指定できます。

注意:
HTMLのレポートは、テキストのレポートよりも読みやすいため、Oracle RAC環境では、テキストではなく、常にHTMLレポートの生成を試みてください。

Oracle RAC環境の特定のデータベース・インスタンスのAWR期間比較レポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/awrgdrpi.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

3. 使用可能なデータベース識別子およびインスタンス番号のリストが表示されます。

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id    Inst Num DB Name      Instance     Host
----------- -------- ------------ ------------ ------------
3309173529        1 MAIN         main         examp1690
3309173529        1 TINT251      tint251      samp251
3309173529        2 TINT251      tint252      samp252
3309173529        3 TINT251      tint253      samp253
3309173529        4 TINT251      tint254      samp254

次のように、第1期間のデータベース識別子(dbid)およびインスタンス番号(instance_numbers_or_all)の値を入力します。

Enter value for dbid: 3309173529
Using 3309173529 for Database Id for the first pair of snapshots
Enter value for inst_num: 1,2
Using instances 1 for the first pair of snapshots

4. 第1期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days: 2

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、最近2日間に取得されたスナップショットが表示されます。

5. 第1期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap: 102
Enter value for end_snap: 103

この例では、第1期間において、スナップショットIDが102のスナップショットが最初のスナップショットとして選択され、スナップショットIDが103のスナップショットが最後のスナップショットとして選択されます。

6. 使用可能なデータベース識別子およびインスタンス番号のリストが表示されます。

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id    Inst Num DB Name      Instance     Host
----------- -------- ------------ ------------ ------------
3309173529        1 MAIN         main         examp1690
3309173529        1 TINT251      tint251      samp251
3309173529        2 TINT251      tint252      samp252
3309173529        3 TINT251      tint253      samp253
3309173529        4 TINT251      tint254      samp254
INSTNUM1
-----------------------------------------------------
1,2

次のように、第2期間のデータベース識別子(dbid2)およびインスタンス番号(instance_numbers_or_all2)の値を入力します。

Enter value for dbid2: 3309173529
Using 3309173529 for Database Id for the second pair of snapshots
Enter value for instance_numbers_or_all2: 3,4

7. 第2期間のスナップショットIDをリストする日数を指定します。

Enter value for num_days2: 1

指定した時間範囲に対応する既存のスナップショットのリストが表示されます。この例では、前日に取得されたスナップショットが表示されます。

8. 第2期間の最初と最後のスナップショットIDを指定します。

Enter value for begin_snap2: 126
Enter value for end_snap2: 127

この例では、第2期間において、スナップショットIDが126のスナップショットが最初のスナップショットとして選択され、スナップショットIDが127のスナップショットが最後のスナップショットとして選択されます。

9. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name awrracdiff_1st_1_2nd_1.html

この例では、デフォルト名が使用され、awrrac_1st_1_2nd_1.htmlというAWRレポートが生成されます。

5.3.8 アクティブ・セッション履歴レポートの生成

アクティブ・セッション履歴(ASH)レポートを使用して次の分析を実行します。

- 通常数分間で収まる一時的なパフォーマンスの問題

- 時間、セッション、モジュール、アクションまたはSQL_IDなど、様々なディメンションあるいはその組合せによる有効範囲内または目標となるパフォーマンスの分析

一時的なパフォーマンスの問題は、短期的なものであり、自動データベース診断モニター(ADDM)による分析には表れません。ADDMでは、DB時間への影響の観点から、分析期間中に最も重要なパフォーマンス上の問題をレポートしようと試みます。特定の問題の継続期間がごく短い場合、その重大度は、分析期間にわたり平均化されるか、他のパフォーマンス問題によって最小化されることがあります。したがって、その問題はADDMでは検出されない可能性があります。パフォーマンス問題がADDMで取得されるかどうかは、AWRのスナップショット間隔と問題の継続期間の比較によって決まります。

スナップショット間で相当な時間続くパフォーマンスの問題の場合、ADDMにより取得されます。たとえば、スナップショット間隔が1時間に設定されている場合、30分間続くパフォーマンスの問題は一時的なパフォーマンスの問題としては考慮されません。これはこの期間がスナップショット間隔で相当な時間を占め、ADDMにより取得される可能性が高いためです。

しかし、継続期間が2分間のみのパフォーマンス問題は、その期間がスナップショット間隔と比べてわずかであるため、一時的なパフォーマンス問題となり、通常はADDMによって検出されません。たとえば、午後10:00から午後10:10の間にシステムの処理が低下したという連絡がユーザーからあったにもかかわらず、午後10:00から午後11:00の時間間隔におけるADDM分析にパフォーマンス上の問題が見られない場合、ユーザーにより報告された10分というごく短い期間に一時的なパフォーマンス問題が発生した可能性があります。

ASHレポートは複数のセクションに分かれています。HTMLレポートには、セクション間ですばやくナビゲートできるようにリンクが組み込まれています。レポートの内容には、指定された期間の、ブロッカIDおよび待機中IDとその関連トランザクション識別子、およびSQLの識別に使用されたASH情報が含まれています。ASHの詳細は、「アクティブ・セッション履歴」を参照してください。

ASHレポートを生成するための主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、ASHレポートは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで生成する必要があります。Oracle Enterprise Managerが使用可能でない場合は、次の項の手順に従ってSQLスクリプトを実行して、ASHレポートを生成できます。

- ASHレポートの生成

- 特定のデータベース・インスタンスのASHレポートの生成

- Oracle RAC ASHレポートの生成

5.3.8.1 ASHレポートの生成

ashrpt.sql SQLスクリプトでは、指定された期間のASH情報を表示する、HTMLまたはテキストのレポートが生成されます。

ASHレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/ashrpt.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: text

この例では、テキスト形式のレポートが選択されます。

3. システム日付より前の開始時間を分単位で指定します。

Enter value for begin_time: -10

この例では、現在の時刻より10分前が選択されます。

4. 開始時間からASH情報を収集するレポートの期間を分単位で入力します。

Enter value for duration:

この例では、システム日付から開始時間をマイナスしたデフォルトの期間が使用されます。

5. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name ashrpt_1_0310_0131.txt

この例では、デフォルト名が使用され、ashrpt_1_0310_0131というASHレポートが生成されます。このレポートでは、現在の時刻の10分前から開始され、現在の時刻で終了するASH情報が収集されます。

5.3.8.2 特定のデータベース・インスタンスのASHレポートの生成

ashrpti.sql SQLスクリプトでは、指定されたデータベースおよびインスタンスの指定された期間のASH情報を表示する、HTMLまたはテキストのレポートが生成されます。このスクリプトでは、ASH情報を収集する時間枠を設定する前に、データベースおよびインスタンスを指定できます。

指定したデータベース・インスタンスでASHレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/ashrpti.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

3. 使用可能なデータベースIDおよびインスタンス番号のリストが表示されます。

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id    Inst Num DB Name      Instance     Host
----------- -------- ------------ ------------ ------------
3309173529        1 MAIN         main         examp1690
3309173529        1 TINT251      tint251      samp251

次のようにデータベース識別子(dbid)およびインスタンス番号(inst_num)の値を入力します。

Enter value for dbid: 3309173529
Using 3309173529 for database id
Enter value for inst_num: 1

4. この手順は、Active Data Guardフィジカル・スタンバイ・インスタンスのASHレポートを生成する場合にのみ該当します。そうでない場合は、この手順をスキップできます。
フィジカル・スタンバイ・インスタンスのASHレポートを生成するには、スタンバイ・データベースを読取り専用でオープンする必要があります。ディスク上のASHデータはプライマリ・データベースでのアクティビティを表し、メモリー内のASHデータはスタンバイ・データベースでのアクティビティを表します。

レポートの生成に、プライマリ・データベースまたはスタンバイ・データベースのどちらのサンプリング・データを使用するかを指定します。

You are running ASH report on a Standby database.
To generate the report over data sampled on the Primary database, enter 'P'.
Defaults to 'S' - data sampled in the Standby database.
Enter value for stdbyflag:
Using Primary (P) or Standby (S): S

この例では、デフォルト値のスタンバイ(S)が選択されています。

5. システム日付より前の開始時間を分単位で指定します。

Enter value for begin_time: -10

この例では、現在の時刻より10分前が選択されます。

6. 開始時間からASH情報を収集するレポートの期間を分単位で入力します。

Enter value for duration:

この例では、システム日付から開始時間をマイナスしたデフォルトの期間が使用されます。

7. レポートの「アクティビティの経過(Activity Over Time)」セクションで使用する時間帯(秒数)を指定します。

Enter value for slot_width:

この例では、デフォルト値を使用します。「アクティビティの経過(Activity Over Time)」セクションおよび時間帯の指定方法の詳細は、「アクティビティの経過(Activity Over Time)」を参照してください。

8. その後のプロンプトの説明に従って、次のレポート・ターゲットの値を入力します。

- target_session_id

- target_sql_id

- target_wait_class

- target_service_hash

- target_module_name

- target_action_name

- target_client_id

- target_plsql_entry

9. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name ashrpt_1_0310_0131.txt

この例では、デフォルト名が使用され、ashrpt_1_0310_0131というASHレポートが生成されます。このレポートでは、3309173529というデータベースIDを持つデータベース・インスタンスにおいて、現在の時刻の10分前から開始され、現在の時刻で終了するASH情報が収集されます。

5.3.8.3 Oracle RAC ASHレポートの生成

ashrpti.sql SQLスクリプトは、Oracle RAC環境の指定されたデータベースおよびインスタンスにおける指定された期間のASH情報を表示する、HTMLまたはテキストのレポートを生成します。ディスクに書き込まれるASHデータのみがレポートの生成に使用されます。このレポートでは、DBA_HIST_ACTIVE_SESS_HISTORY表にある最後の10分間でのASHサンプルのみが使用されます。

Oracle RAC環境でASHレポートを生成するには、次の手順を実行します。

1. SQLプロンプトで、次のように入力します。

@$ORACLE_HOME/rdbms/admin/ashrpti.sql

2. レポートの形式としてHTMLまたはテキストのいずれかを指定します。

Enter value for report_type: html

この例では、HTML形式のレポートが選択されます。

3. 使用可能なデータベースIDおよびインスタンス番号のリストが表示されます。

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id    Inst Num DB Name      Instance     Host
----------- -------- ------------ ------------ ------------
3309173529        1 MAIN         main         examp1690
3309173529        1 TINT251      tint251      samp251
3309173529        2 TINT251      tint252      samp252
3309173529        3 TINT251      tint253      samp253
3309173529        4 TINT251      tint254      samp254

次のようにデータベース識別子(dbid)およびインスタンス番号(inst_num)の値を入力します。

Enter value for dbid: 3309173529
Using database id: 3309173529
Enter instance numbers. Enter 'ALL' for all instances in an Oracle
RAC cluster or explicitly specify list of instances (e.g., 1,2,3).
Defaults to current instance.
Enter value for inst_num: ALL
Using instance number(s): ALL

4. システム日付より前の開始時間を分単位で指定します。

Enter value for begin_time: -1:10

この例では、現在の時刻より1時間10分前が選択されます。

5. 開始時間からASH情報を収集するレポートの期間を分単位で入力します。

Enter value for duration: 10

この例では、期間は10分間に設定されます。

6. レポートの「アクティビティの経過(Activity Over Time)」セクションで使用する時間帯(秒数)を指定します。

Enter value for slot_width:

この例では、デフォルト値を使用します。「アクティビティの経過(Activity Over Time)」セクションおよび時間帯の指定方法の詳細は、「アクティビティの経過(Activity Over Time)」を参照してください。

7. その後のプロンプトの説明に従って、次のレポート・ターゲットの値を入力します。

- target_session_id

- target_sql_id

- target_wait_class

- target_service_hash

- target_module_name

- target_action_name

- target_client_id

- target_plsql_entry

8. レポート名を入力するか、デフォルトのレポート名を受け入れます。

Enter value for report_name:
Using the report name ashrpt_rac_0310_0131.txt

この例では、デフォルト名が使用され、ashrpt_rac_0310_0131というASHレポートが生成されます。このレポートでは、3309173529というデータベースIDを持つデータベースに所属するすべてのインスタンスにおいて、現在の時刻の1時間10分前から開始され、現在の時刻の1時間前に終了するASH情報が収集されます。

5.3.9 アクティブ・セッション履歴レポートの使用

ASHレポートを生成したら、その内容を確認して一時的なパフォーマンス問題を特定できます。

ASHレポートの内容は、次のセクションに分けられます。

- 上位イベント(Top Events)

- ロード・プロファイル(Load Profile)

- 上位SQL(Top SQL)

- 上位PL/SQL(Top PL/SQL)

- 上位Java(Top Java)

- 上位セッション(Top Sessions)

- 上位オブジェクト/ファイル/ラッチ(Top Objects/Files/Latches)

- アクティビティの経過(Activity Over Time)

関連項目:
Oracle Real Application Clusters(Oracle RAC)に固有のASHレポートのセクションの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

5.3.9.1 上位イベント(Top Events)

「上位イベント(Top Events)」セクションは、ユーザー、バックグラウンドおよび優先順位で分類されたサンプル・セッション・アクティビティの上位待機イベントを示します。このセクションの情報を使用して、一時的なパフォーマンス問題の原因となっている可能性のある待機イベントを特定します。

「上位イベント(Top Events)」セクションには、次のサブセクションが含まれます。

- 上位ユーザー・イベント(Top User Events)
このサブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるユーザー・プロセスの上位待機イベントを示します。

- 上位バックグラウンド・イベント(Top Background Events)
このサブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるバックグランドの上位待機イベントを示します。

- 上位イベントP1/P2/P3(Top Event P1/P2/P3)
このサブセクションは、サンプル・セッション・アクティビティで最高の割合を占める上位待機イベントの待機イベント・パラメータ値を、合計待機時間の割合(%イベント(% Event))の順に示します。各待機イベントにおいて、「P1値、P2値、P3値(P1 Value, P2 Value, P3 Value)」列の値は、「パラメータ1(Parameter 1)」、「パラメータ2(Parameter 2)」、「パラメータ3(Parameter 3)」の各列に表示される待機イベント・パラメータに対応します。

5.3.9.2 ロード・プロファイル(Load Profile)

「ロード・プロファイル(Load Profile)」セクションは、サンプル・セッション・アクティビティで分析された負荷を示します。このセクションの情報を使用して、一時的なパフォーマンス問題の原因となっている可能性のあるサービス、クライアントまたはSQLコマンド・タイプを特定します。

「ロード・プロファイル(Load Profile)」セクションには、次のサブセクションが含まれます。

- 上位サービス/モジュール(Top Service/Modules)
このサブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるサービスおよびモジュールを示します。

- 上位クライアントID(Top Client IDs)
このサブセクションは、データベース・セッションのアプリケーション固有の識別子であるクライアントIDに基づいて、サンプル・セッション・アクティビティで最高の割合を占めるクライアントを示します。

- 上位SQLコマンド・タイプ(Top SQL Command Types)
このサブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるSQLコマンド・タイプ(SELET、UPDATEなど)を示します。

- 上位実行フェーズ(Top Phases of Execution)
このサブセクションは、サンプル・セッション・アクティビティで最高の割合を占める実行フェーズ(SQL、PL/SQL、Javaのコンパイルや実行など)を示します。

5.3.9.3 上位SQL(Top SQL)

「上位SQL(Top SQL)」セクションは、サンプル・セッション・アクティビティの上位SQL文を示します。この情報を使用して、一時的なパフォーマンス問題の原因となっている可能性のある高負荷のSQL文を特定します。

「上位SQL(Top SQL)」セクションには、次のサブセクションが含まれます。

- 上位SQLと上位イベント(Top SQL with Top Events)

- 上位SQLと上位行ソース(Top SQL with Top Row Sources)

- リテラルを使用する上位SQL(Top SQL Using Literals)

- 上位解析モジュール/アクション(Top Parsing Module/Action)

- SQLテキストの完全なリスト(Complete List of SQL Text)

5.3.9.3.1 上位SQLと上位イベント(Top SQL with Top Events)

「上位SQLと上位イベント(Top SQL with Top Events)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるSQL文と、それらのSQL文に対して発生した上位待機イベントを示します。「実行のサンプル数(Sampled # of Executions)」列は、特定のSQL文の個別実行がサンプリングされた数を示します。

5.3.9.3.2 上位SQLと上位行ソース(Top SQL with Top Row Sources)

「上位SQLと上位行ソース(Top SQL with Top Row Sources)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるSQL文と、それらの詳細な実行計画情報を示します。この情報を使用することで、SQLの経過時間に多くの影響を与えているSQL実行部分を特定できます。

5.3.9.3.3 リテラルを使用する上位SQL(Top SQL Using Literals)

「リテラルを使用する上位SQL(Top SQL Using Literals)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるリテラルを使用するSQL文を示します。このレポートにリストされた文を確認して、リテラルをバインド変数に置換できるかどうかを決定する必要があります。

5.3.9.3.4 上位解析モジュール/アクション(Top Parsing Module/Action)

「上位解析モジュール/アクション(Top Parsing Module/Action)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるSQL文解析時のモジュールおよびアクションを示します。

5.3.9.3.5 SQLテキストの完全なリスト(Complete List of SQL Text)

「SQLテキストの完全なリスト(Complete List of SQL Text)」サブセクションは、このセクションに含まれる上位SQL文のテキスト全体を示します。

5.3.9.4 上位PL/SQL(Top PL/SQL)

「上位PL/SQL(Top PL/SQL)」セクションは、サンプル・セッション・アクティビティで最高の割合を占めるPL/SQLプロシージャを示します。「PL/SQLエントリ・サブプログラム(PL/SQL Entry Subprogram)」列は、PL/SQLに対するアプリケーションの最上位レベルのエントリ・ポイントを示します。「PL/SQL現行サブプログラム(PL/SQL Current Subprogram)」列は、サンプリング時点で実行されていたPL/SQLサブプログラムを示します。この列の値がSQLの場合、「%現行(% Current)」列に、このサブプログラムのSQL実行にかかった時間の割合が示されます。

5.3.9.5 上位Java(Top Java)

「上位Java(Top Java)」セクションは、サンプル・セッション・アクティビティの上位Javaプログラムを示します。

5.3.9.6 上位セッション(Top Sessions)

「上位セッション(Top Sessions)」セクションは、特定の待機イベントを待機していたセッションを示します。この情報を使用して、一時的なパフォーマンス問題の原因となっている可能性のある、サンプル・セッション・アクティビティで最高の割合を占めるセッションを特定します。

「上位セッション(Top Sessions)」セクションには、次のサブセクションが含まれます。

- 上位セッション(Top Sessions)

- 上位のブロック・セッション(Top Blocking Sessions)

- PQを実行している上位セッション(Top Sessions Running PQs)

5.3.9.6.1 上位セッション(Top Sessions)

「上位セッション(Top Sessions)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占める特定の待機イベントを待機していたセッションを示します。

5.3.9.6.2 上位のブロック・セッション(Top Blocking Sessions)

「上位のブロック・セッション(Top Blocking Sessions)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるブロック・セッションを示します。

5.3.9.6.3 PQを実行している上位セッション(Top Sessions Running PQs)

「PQを実行している上位セッション(Top Sessions Running PQs)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占める、特定の待機イベントを待機していたパラレル問合せ(PQ)を実行中のセッションを示します。

5.3.9.7 上位オブジェクト/ファイル/ラッチ(Top Objects/Files/Latches)

「上位オブジェクト/ファイル/ラッチ(Top Objects/Files/Latches)」セクションは、最もよく使用されるデータベース・リソースに関する追加情報を示し、次のサブセクションを含みます。

- 上位DBオブジェクト(Top DB Objects)

- 上位DBファイル(Top DB Files)

- 上位ラッチ(Top Latches)

5.3.9.7.1 上位DBオブジェクト(Top DB Objects)

「上位DBオブジェクト(Top DB Objects)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるデータベース・オブジェクト(表や索引など)を示します。

5.3.9.7.2 上位DBファイル(Top DB Files)

「上位DBファイル(Top DB Files)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるデータベース・ファイルを示します。

5.3.9.7.3 上位ラッチ(Top Latches)

「上位ラッチ(Top Latches)」サブセクションは、サンプル・セッション・アクティビティで最高の割合を占めるラッチを示します。

ラッチは、システム・グローバル領域(SGA)で共有されているデータ構造を保護するための簡素な下位レベルのシリアライズ・メカニズムです。たとえば、ラッチにより、データベースに現在アクセスしているユーザーのリストと、バッファ・キャッシュのブロックを記述するデータ構造が保護されます。サーバーまたはバックグラウンド・プロセスは、これらの構造の操作または調査時に、ごく短時間ラッチを取得します。ラッチの実装は、特に、プロセスがラッチを待機するかどうかとその待機時間に関して、オペレーティング・システムに依存します。

5.3.9.8 アクティビティの経過(Activity Over Time)

「アクティビティの経過(Activity Over Time)」セクションは、ASHレポートの中で最も有益な情報の含まれるセクションの1つです。このセクションは、分析期間中のアクティビティおよびワークロード・プロファイルに関する詳細な情報を含むため、期間が長い場合に特に役立ちます。「アクティビティの経過(Activity Over Time)」セクションは、10個の時間帯に分けられます。各時間帯のサイズは、分析期間の継続時間に基づいて変化します。通常、最初と最後の時間帯は、余り部分になります。その内側の時間帯は、すべて同じサイズで、相互に比較できます。たとえば、分析期間が10分間続くと、すべての時間帯がそれぞれ1分となります。ただし、分析期間が9分30秒続くと、両端の時間帯はそれぞれ15秒となり、内側の時間帯はそれぞれ1分となります。

表5-2に示すとおり、各時間帯にはその特定の時間帯に関する情報が含まれます。

表5-2 アクティビティの経過(Activity Over Time)

列

説明

時間帯(期間)(Slot Time (Duration))

時間帯の継続時間

時間帯の数(Slot Count)

時間帯のサンプル・セッションの数

イベント(Event)

時間帯の上位3つの待機イベント

イベント数(Event Count)

待機イベントを待機しているASHサンプルの数

%イベント(% Event)

分析期間全体で待機イベントを待機しているASHサンプルの割合

内側の時間帯を比較する場合、「イベント数(Event Count)」列と「時間帯の数(Slot Count)」列のスパイクを識別して、スキュー解析を実行します。「イベント数(Event Count)」列のスパイクは、特定のイベントを待機しているサンプル・セッションの数の増大を示します。「時間帯の数(Slot Count)」列のスパイクは、アクティブ・セッションの増大(ASHデータはアクティブ・セッションからのみサンプリングされるため)と、データベース・ワークロードの相対的な増大を示します。一般的に、アクティブ・セッション・サンプルの数と、待機イベントに関連するセッションの数が増大している場合、その時間帯が一時的なパフォーマンス問題の原因である可能性があります。

ユーザー定義の時間帯サイズでASHレポートを生成するには、「特定のデータベース・インスタンスのASHレポートの生成」の手順に従ってashrpti.sqlスクリプトを実行します。

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

この章では、Oracle Databaseの自動パフォーマンス診断およびチューニング機能について説明します。

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

- 自動データベース診断モニターの概要

- ADDMの設定

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

- ADDM情報を表示するビュー

関連項目:
Oracle Enterprise Managerを使用して自動データベース診断モニターでデータベースを診断およびチューニングする方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

6.1 自動データベース診断モニターの概要

システムに問題が発生した場合、システムに変更を加える前に問題を正確かつ適時に診断することが重要です。通常、データベース管理者(DBA)は単に症状を調べ、問題を修復するために即時にシステムの変更を開始します。ただし、実際の問題を初期段階で正確に診断すると、その解決に成功する可能性が大幅に向上します。

Oracle Databaseの場合、問題の正確な診断に必要な統計データは自動ワークロード・リポジトリ(AWR)に保存されます。自動データベース診断モニター(ADDM)の機能は、次のとおりです。

- AWRデータの定期的な分析

- パフォーマンス問題の根本的な原因の診断

- 問題を修正するための推奨事項の提供

- システムの正常領域の特定

AWRはパフォーマンスに関する履歴データのリポジトリであるため、ADDMでは、イベントの後にパフォーマンスの問題を分析でき、時間とリソースをかけて問題を再現する必要がありません。AWRの詳細は、「自動ワークロード・リポジトリの概要」を参照してください。

多くの場合、データベース管理者はパフォーマンスの問題に関して通知を受け取った時点で、まずADDM出力を調べる必要があります。ADDMには次の利点があります。

- デフォルトで1時間ごとの自動パフォーマンス診断レポート

- 数十人のチューニング専門家に基づく問題の診断

- 問題の影響と推奨事項による利点の時間ベースの数量化

- 症状ではなく根本的な原因の特定

- 問題の根本的な原因の処理に関する推奨事項

- システムのうち正常な領域の特定

- 診断処理中のシステムに対する最小限のオーバーヘッド

チューニングは反復的なプロセスであり、ある問題を修復したことが原因でシステムの他の部分へのシフトにボトルネックが発生する可能性があることを認識することが重要です。ADDM分析による利点があるとしても、システム・パフォーマンスが許容レベルに達するまでには複数のチューニング・サイクルを必要とする場合があります。ADDMによる利点は本番システムに適用されるのみでなく、開発およびテスト・システムでもパフォーマンスの問題を早期に警告できます。

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

- ADDM分析

- Oracle Real Application ClustersでのADDMの使用方法

- ADDMの分析結果

- ADDMの分析結果の確認: 例

6.1.1 ADDM分析

ADDM分析は、AWRスナップショットのペアと、同じデータベースのインスタンスのセットに対して実行できます。AWRスナップショットのペアにより分析の期間が定義され、インスタンスのセットにより分析のターゲットが定義されます。

Oracle Real Application Clusters(Oracle RAC)を使用している場合、ADDMには次の3つの分析モードがあります。

- データベース
データベース・モードでは、ADDMによりデータベースのすべてのインスタンスが分析されます。

- インスタンス
インスタンス・モードでは、ADDMによりデータベースの特定のインスタンスが分析されます。

- 部分
部分モードでは、ADDMによりすべてのデータベース・インスタンスのサブセットが分析されます。

Oracle RACを使用しない場合は、データベース・インスタンスが1つのみとなり、ADDMはインスタンス・モードでのみ動作します。

ADDM分析はAWRスナップショットが作成されるたびに実行され、結果がデータベースに保存されます。ADDMにより分析される期間は、最新の2つのスナップショットにより定義されます(デフォルトでは最後の1時間)。ADDMでは、インスタンス・モードで指定されたインスタンスが常に分析されます。Oracle RAC以外の環境または単一インスタンス環境の場合、インスタンス・モードで実行される分析は、データベース全体の分析と同じになります。Oracle RACを使用している場合、「Oracle Real Application ClustersでのADDMの使用方法」に記載されているとおり、ADDMではデータベース・モードでデータベース全体が分析されます。ADDMによる分析の完了後、Oracle Enterprise Managerを使用するか、SQL*Plusセッションでレポートを表示することで結果を確認できます。

ADDM分析は、トップダウン方式で実行され、最初に症状を識別し、次にパフォーマンスの問題の根本的な原因に到達するまで精査します。分析の目標は、DB timeと呼ばれる1つのスループット・メトリックを減少させることです。DB timeは、データベースでユーザー・リクエストの処理に費やされた累積時間です。これには、アイドル状態でないすべてのユーザー・セッションの待機時間とCPU時間が含まれます。DB timeは、V$SESS_TIME_MODELビューおよびV$SYS_TIME_MODELビューに表示されます。

関連項目:

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

- 時間モデル統計およびDB timeの詳細は、「時間モデル統計」を参照してください。

- サーバー・プロセスの詳細は、『Oracle Database概要』を参照してください。

DB timeの短縮により、データベースで同じリソースを使用してサポートできるユーザー・リクエストの数が増加し、スループットが改善されます。ADDMによりレポートされる問題は、それに関係するDB timeの量でソートされます。DB timeの大部分に関係しないシステム領域は、正常領域としてレポートされます。

ADDMでは、次のようなタイプの問題が考慮されます。

- CPUのボトルネック - システムCPUがOracle Databaseまたは他のアプリケーションによりバインドされているかどうか。

- 過小なメモリー構造 - SGA、PGA、バッファ・キャッシュなど、Oracle Databaseメモリー構造が十分なサイズに設定されているかどうか。

- I/O能力の問題 - I/Oサブシステムが予想どおりに動作しているかどうか。

- 高負荷のSQL文 - システム・リソースを過剰に使用しているSQL文があるかどうか。

- 高負荷のPL/SQL実行およびコンパイルと、高負荷のJavaの使用。

- Oracle RAC固有の問題 - グローバル・キャッシュのホット・ブロックおよびオブジェクトの問題、相互接続遅延の問題があるかどうか。

- アプリケーションによるOracle Databaseの不適切な使用 - 不適切な接続管理、過剰な解析またはアプリケーション・レベルのロック競合による問題があるかどうか。

- データベース構成の問題 - 不適切なログ・ファイル・サイズの設定、アーカイブの問題、過剰なチェックポイントまたは不適切なパラメータ設定を示す兆候があるかどうか。

- 同時実行性の問題 - バッファ・ビジーの問題があるかどうか。

- 様々な問題領域のホット・オブジェクトおよび上位SQL。

注意:
これは、ADDMの分析で考慮されるすべての問題タイプの包括的なリストではありません。

ADDMでは、システムの正常領域もドキュメント化されます。たとえば、システムのパフォーマンスにほとんど影響しない待機イベント・クラスが識別され、早期段階でチューニング考慮事項から削除されます。これにより、システム全体のパフォーマンスに影響しない項目に費やされる時間および労力が節約されます。

6.1.2 Oracle Real Application ClustersでのADDMの使用方法

Oracle RACを使用する場合は、データベース分析モードでADDMを実行して、すべてのデータベース・インスタンスのスループット・パフォーマンスを分析できます。データベース・モードでは、ADDMは、DB時間をすべてのデータベース・インスタンスのデータベース時間の合計とみなします。データベース分析モードを使用すると、データベース全体にとって重要なすべての検出結果が単一のレポートに表示されます(各インスタンスの個別レポートは表示されません)。

データベース・モードのレポートには、データベース・リソース(I/Oやインターコネクトなど)に関する検出結果が含まれます。レポートには、データベース全体にとって重要な場合は、様々なインスタンスからの検出結果も集計されます。たとえば、単一のインスタンスに対するCPU負荷が高く、データベース全体に影響する場合、データベース・モード分析に、問題の原因である特定のインスタンスを示す検出結果が表示されます。

関連項目:
Oracle RACでADDMを使用する方法の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

6.1.3 ADDMの分析結果

ADDMでは、問題の診断に加えて可能な解決策も推奨されます。ADDMの分析結果は、一連の検出結果として表示されます。ADDMの分析結果の例は、例6-1を参照してください。ADDMの検出結果は、それぞれ次のタイプのいずれかに属します。

- 問題の検出結果では、データベース・パフォーマンスの問題の根本的な原因が記述されます。

- 症状の検出結果には、1つ以上の問題の検出につながる情報が含まれます。

- 情報の検出結果は、データベースのパフォーマンスの理解に役立つが、パフォーマンスの問題には関連しない情報(データベースの正常領域や、自動データベース・メンテナンスのアクティビティなど)をレポートする際に使用されます。

- 警告の検出結果には、ADDM分析の完全性や正確性に影響する可能性のある問題に関する情報(AWRの欠落データなど)が含まれます。

問題の検出結果はそれぞれ、影響によって数量化されます。この影響は、その検出結果のパフォーマンスの問題に起因するDB timeの割合を見積ったものです。問題の検出結果を推奨事項のリストに関連付けて、パフォーマンスの問題による影響を軽減できます。推奨事項のタイプは、次のとおりです。

- ハードウェア変更: CPUの追加またはI/Oサブシステム構成の変更

- データベース構成: 初期化パラメータ設定の変更

- スキーマ変更: 表または索引のハッシュ・パーティション化、あるいは自動セグメント領域管理(ASSM)の使用

- アプリケーション変更: 順序のキャッシュ・オプションの使用またはバインド変数の使用

- その他のアドバイザの使用: 高負荷SQLに対するSQLチューニング・アドバイザの実行、またはホット・オブジェクトに対するセグメント・アドバイザの実行

推奨事項のリストには、同じ問題に関する様々な代替解決策が含まれる場合があります。特定の問題を解決するために推奨事項をすべて適用する必要はありません。推奨事項にはそれぞれメリットがあります。このメリットは、その推奨事項を実装した場合に節約できるDB timeの割合を見積ったものです。推奨は、アクションおよび論理で構成されます。見積られたメリットを得るためには、推奨事項のアクションをすべて適用する必要があります。理論的根拠は、一連のアクションの推奨理由を説明し、提案された推奨事項の実装に関する追加情報を提供するために使用されます。

6.1.4 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.

例6-1では、検出結果は特定の根本的な原因を示しています。SQL文のリテラルの使用は、分析期間中のDB time合計の約31%に影響があると見積られています。

この検出結果には、アクション1つおよび理論的根拠1つで構成される推奨事項が関連付けられています。アクションでは検出された問題の解決策が指定され、その最大メリットは分析期間中のDB timeの31%以内と見積られます。メリットは、検出結果の影響の割合ではなく、DB time合計の割合として表示されることに注意してください。理論的根拠は、リテラルを使用していてこのパフォーマンスの問題を引き起こした可能性のあるSQL文を追跡するための追加情報を提供します。データベース管理者は、問題の原因と思われるSQL文について指定の計画ハッシュ値を使用すると、少数のサンプル文をすばやく検査できます。

特定の問題に複数の原因がある場合は、ADDMにより複数の問題と症状の検出結果がレポートされることがあります。この場合、複数の検出結果による影響には、DB timeが同じ割合で含まれる可能性があります。検出結果のパフォーマンスの問題はオーバーラップしている場合があるため、検出結果の影響を合算すると、DB timeの100%を超える場合があります。たとえば、システムで多数の読取りが実行される場合、ADDMでは、I/OアクティビティによるDB timeの50%に関係するSQL文が1つの検出結果としてレポートされ、DB timeの75%に関係するサイズ不足のバッファ・キャッシュが別の検出結果としてレポートされる場合があります。

問題の検出結果に複数の推奨事項が関連付けられている場合は、それぞれに問題の代替解決策が含まれていることがあります。この場合、推奨事項によるメリットの合計は検出結果の影響よりも大きいことがあります。

該当する場合は、ADDMアクションで複数の解決策が推奨され、管理者はその中から選択できます。この例では、最も有効な解決策はバインド変数を使用することです。ただし、通常、アプリケーションを変更することは困難です。CURSOR_SHARING初期化パラメータの値を変更する方が実装が容易で、大幅な改善が可能です。

6.2 ADDMの設定

自動データベース診断モニターはデフォルトで使用可能になり、CONTROL_MANAGEMENT_PACK_ACCESSおよびSTATISTICS_LEVEL初期化パラメータにより制御されます。

自動データベース診断モニターを使用可能にするには、CONTROL_MANAGEMENT_PACK_ACCESSパラメータをDIAGNOSTICまたはDIAGNOSTIC+TUNINGに設定する必要があります。デフォルト設定はDIAGNOSTIC+TUNINGです。CONTROL_MANAGEMENT_PACK_ACCESSをNONEに設定すると、ADDMが無効になります。

自動データベース診断モニターを使用可能にするには、STATISTICS_LEVELパラメータをTYPICALまたはALLに設定する必要があります。デフォルトの設定はTYPICALです。STATISTICS_LEVELをBASICに設定すると、ADDMを含む多くのOracle Databaseの機能が無効化されるため、この方法はお薦めしません。

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

I/OパフォーマンスのADDM分析は、単一の引数DBIO_EXPECTEDによって異なり、I/Oサブシステムの予測されるパフォーマンスを示しています。DBIO_EXPECTEDの値は、1つのデータベース・ブロックの読取りにかかる平均時間(マイクロ秒単位)です。Oracle Databaseではデフォルト値の10ミリ秒が使用されます。この値は、ほとんどの最新のハード・ドライブに適しています。非常に古いハードウェアや超高速のRAMディスクなど、ハードウェアが大きく異なっている場合は、他の値を使用することを検討してください。

DBIO_EXPECTEDパラメータの適切な設定を判断する手順は、次のとおりです。

1. ハードウェアについて、1データベース・ブロックを読み取るための平均所要時間を測定します。この測定の対象はランダムI/Oであり、標準ハード・ドライブを使用している場合はシーク時間が含まれることに注意してください。ハード・ドライブの標準値は5000から20000マイクロ秒です。

2. 後続のすべてのADDM実行について値を1度設定します。たとえば、測定値が8000マイクロ秒の場合は、次のコマンドをSYSユーザーとして実行する必要があります。

EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
'ADDM', 'DBIO_EXPECTED', 8000);

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

データベース・パフォーマンスの問題を診断するには、AWRスナップショットが取得されるたびに自動的に作成されるADDMの分析結果を最初に確認する必要があります。異なる分析が必要な場合(分析期間の延長、異なるDBIO_EXPECTED設定の使用、分析モードの変更など)、この項の手順に従って手動でADDMを実行できます。

ADDMでは、2つのAWRスナップショットが消去されずにAWRに保存されているかぎり、その(同じデータベース上の)2つのスナップショットを分析できます。ADDMで分析できるのは、開始スナップショットの前に開始され、終了スナップショットまで実行が継続していたインスタンスのみです。また、ADDMでは、AWRスナップショットの生成時に重大なエラーが発生したインスタンスは分析できません。このような場合、ADDMでは、重大な問題の発生していないインスタンスの最大のサブセットが分析されます。

診断モニターの主インタフェースは、Oracle Enterprise Managerです。可能なかぎり、ADDMは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従ってOracle Enterprise Managerで実行する必要があります。Oracle Enterprise Managerが使用できない場合、DBMS_ADDMパッケージを使用してADDMを実行します。DBMS_ADDM APIを実行するには、ユーザーはADVISOR権限を付与されている必要があります。

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

- データベース・モードでのADDMの実行

- インスタンス・モードでのADDMの実行

- 部分モードでのADDMの実行

- ADDMレポートの表示

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

6.3.1 データベース・モードでのADDMの実行

Oracle RAC構成の場合、データベース・モードでADDMを実行して、データベースのすべてのインスタンスを分析できます。単一インスタンス構成の場合も、データベース・モードでADDMを実行できますが、この場合、ADDMは単にインスタンス・モードと同じように動作します。

データベース・モードでADDMを実行するには、DBMS_ADDM.ANALYZE_DBプロシージャを次のように使用します。

BEGIN
DBMS_ADDM.ANALYZE_DB (
task_name           IN OUT VARCHAR2,
begin_snapshot      IN     NUMBER,
end_snapshot        IN     NUMBER,
db_id               IN     NUMBER := NULL);
END;
/

task_nameパラメータでは、作成する分析タスクの名前を指定します。begin_snapshotパラメータでは、分析期間の開始スナップショットのスナップショット番号を指定します。end_snapshotパラメータでは、分析期間の終了スナップショットのスナップショット番号を指定します。db_idパラメータでは、分析するデータベースのデータベース識別子を指定します。指定しない場合、このパラメータは、現在接続しているデータベースのデータベース識別子にデフォルト設定されます。

次の例では、データベース分析モードでADDMタスクを作成して実行し、スナップショット137および145で定義される期間のデータベース全体のパフォーマンスを診断します。

VAR tname VARCHAR2(30);
BEGIN
:tname := 'ADDM for 7PM to 9PM';
DBMS_ADDM.ANALYZE_DB(:tname, 137, 145);
END;
/

6.3.2 インスタンス・モードでのADDMの実行

データベースの特定のインスタンスを分析するには、インスタンス・モードでADDMを実行します。インスタンス・モードでADDMを実行するには、DBMS_ADDM.ANALYZE_INSTプロシージャを次のように使用します。

BEGIN
DBMS_ADDM.ANALYZE_INST (
task_name           IN OUT VARCHAR2,
begin_snapshot      IN     NUMBER,
end_snapshot        IN     NUMBER,
instance_number     IN     NUMBER := NULL,
db_id               IN     NUMBER := NULL);
END;
/

task_nameパラメータでは、作成する分析タスクの名前を指定します。begin_snapshotパラメータでは、分析期間の開始スナップショットのスナップショット番号を指定します。end_snapshotパラメータでは、分析期間の終了スナップショットのスナップショット番号を指定します。instance_numberパラメータでは、分析するインスタンスのインスタンス番号を指定します。指定しない場合、このパラメータは、現在接続しているインスタンスのインスタンス番号にデフォルト設定されます。db_idパラメータでは、分析するデータベースのデータベース識別子を指定します。指定しない場合、このパラメータは、現在接続しているデータベースのデータベース識別子にデフォルト設定されます。

次の例では、インスタンス分析モードでADDMタスクを作成して実行し、スナップショット137および145で定義される期間のインスタンス番号1のパフォーマンスを診断します。

VAR tname VARCHAR2(30);
BEGIN
:tname := 'my ADDM for 7PM to 9PM';
DBMS_ADDM.ANALYZE_INST(:tname, 137, 145, 1);
END;
/

6.3.3 部分モードでのADDMの実行

すべてのデータベース・インスタンスのサブセットを分析するには、部分モードでADDMを実行します。部分モードでADDMを実行するには、DBMS_ADDM.ANALYZE_PARTIALプロシージャを次のように使用します。

BEGIN
DBMS_ADDM.ANALYZE_PARTIAL (
task_name           IN OUT VARCHAR2,
instance_numbers    IN     VARCHAR2,
begin_snapshot      IN     NUMBER,
end_snapshot        IN     NUMBER,
db_id               IN     NUMBER := NULL);
END;
/

task_nameパラメータでは、作成する分析タスクの名前を指定します。instance_numbersパラメータでは、分析するインスタンスのインスタンス番号のカンマ区切りリストを指定します。begin_snapshotパラメータでは、分析期間の開始スナップショットのスナップショット番号を指定します。end_snapshotパラメータでは、分析期間の終了スナップショットのスナップショット番号を指定します。db_idパラメータでは、分析するデータベースのデータベース識別子を指定します。指定しない場合、このパラメータは、現在接続しているデータベースのデータベース識別子にデフォルト設定されます。

次の例では、部分分析モードでADDMタスクを作成して実行し、スナップショット137および145で定義される期間のインスタンス番号1、2、4のパフォーマンスを診断します。

VAR tname VARCHAR2(30);
BEGIN
:tname := 'my ADDM for 7PM to 9PM';
DBMS_ADDM.ANALYZE_PARTIAL(:tname, '1,2,4', 137, 145);
END;
/

6.3.4 ADDMレポートの表示

実行したADDMタスクのテキスト・レポートを表示するには、DBMS_ADDM.GET_REPORTファンクションを次のように使用します。

DBMS_ADDM.GET_REPORT (
task_name           IN VARCHAR2
RETURN CLOB);

次の例では、tname変数によるタスク名で指定されたADDMタスクのテキスト・レポートを表示します。

SET LONG 1000000 PAGESIZE 0;
SELECT DBMS_ADDM.GET_REPORT(:tname) FROM DUAL;

レポートの戻り型は、行サイズ80に合うよう書式設定されたCLOBです。ADDMレポートでADDMの分析結果を確認する方法の詳細は、「ADDMの分析結果」を参照してください。

6.4 ADDM情報を表示するビュー

通常、ADDMの出力結果や情報は、Oracle Enterprise ManagerまたはADDMレポートを使用して参照する必要があります。

ただし、ADDM情報はDBA_ADVISORビューを使用して表示できます。このグループのビューには次のようなものがあります。

- DBA_ADVISOR_FINDINGS
このビューには、すべてのアドバイザで取得されたすべての検出結果が表示されます。各検出結果は、関連する結果ID、名前およびタイプとともに表示されます。複数の実行に関連するタスクの場合、それぞれの検出結果に関連する各タスク実行の名前もリストされます。

- DBA_ADDM_FINDINGS
このビューには、関連するDBA_ADVISOR_FINDINGSビューに表示される検出結果のサブセットが含まれます。このビューには、すべてのアドバイザで取得されたADDMの検出結果のみが表示されます。ADDMの各検出結果は、関連する結果ID、名前およびタイプとともに表示されます。

- DBA_ADVISOR_FINDING_NAMES
アドバイザ・フレームワークに登録されているすべての検出結果名のリストです。

- DBA_ADVISOR_RECOMMENDATIONS
このビューには、完了した診断タスクの結果と、実行ごとに識別された問題に対する推奨事項が表示されます。推奨事項は、RANK列の順序どおりに参照する必要があります。この順序が推奨事項における問題の重要性を伝えているためです。BENEFIT列には、推奨事項を実行した場合に予想される、システムに対するメリットが示されます。複数の実行に関連するタスクの場合、それぞれのアドバイザ・タスクに関連する各タスク実行の名前もリストされます。

- DBA_ADVISOR_TASKS
このビューでは、タスクID、タスク名およびタスク作成日時など、既存のタスクに関する基本情報が示されます。複数の実行に関連するタスクの場合、それぞれのアドバイザ・タスクに関連する最後または現在の実行の名前とタイプもリストされます。

関連項目:
静的データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

7 メモリーの構成および使用方法

この章では、Oracle Databaseメモリー・キャッシュにメモリーを割り当てる方法とこれらのキャッシュの使用方法について説明します。Oracle Databaseメモリー・キャッシュを適切にサイズ設定して効率的に使用すると、データベースのパフォーマンスが大幅に向上します。システムのメモリーは、自動メモリー管理を使用して管理することをお薦めします。ただし、システムのメモリー・プールは、この章の手順に従って手動で調整できます。

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

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

- バッファ・キャッシュの構成および使用方法

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

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

- PGAメモリー管理

- サーバーおよびクライアントの結果キャッシュの管理

関連項目:
Oracleデータベースのメモリー・アーキテクチャの詳細は、『Oracle Database概要』を参照してください。

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

Oracle Databaseでは、メモリー・キャッシュおよびディスクに情報を格納します。メモリー・アクセスは、ディスク・アクセスよりはるかに高速です。ディスク・アクセス(物理I/O)は、メモリー・アクセスに比べ、時間がかかります(通常は約10ミリ秒)。また、物理I/Oでは、デバイス・ドライバやオペレーティング・システムのイベント・スケジューラのパス長のために必要なCPUリソースも増加します。このため、頻繁にアクセスされるオブジェクトに対するデータ・リクエストは、ディスク・アクセスではなくメモリー・アクセスで実行するほうが効率的です。

パフォーマンスの目標は、必要なデータがメモリー内にある可能性を高くしたり、必要なデータを取り出すプロセスをさらに効率的にし、できるだけ多くの物理I/Oオーバーヘッドを削減することです。

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

- Oracleメモリー・キャッシュ

- 自動メモリー管理

- 自動共有メモリー管理

- キャッシュ・サイズの動的な変更

- アプリケーションの考慮事項

- オペレーティング・システムのメモリー使用量

- 構成の繰返し

7.1.1 Oracleメモリー・キャッシュ

パフォーマンスに影響を与える主なOracle Databaseメモリー・キャッシュは次のとおりです。

- 共有プール

- ラージ・プール

- Javaプール

- バッファ・キャッシュ

- ストリーム・プール・サイズ

- ログ・バッファ

- プロセス・プライベート・メモリー(ソートやハッシュ結合に使用されるメモリーなど)

7.1.2 自動メモリー管理

システムのメモリーは、自動メモリー管理を使用して管理することを強くお薦めします。自動メモリー管理により、Oracle Databaseでは、インスタンス・メモリーを自動的に管理およびチューニングできます。自動メモリー管理は、ターゲット・メモリー・サイズ初期化パラメータ(MEMORY_TARGET)と最大メモリー・サイズ初期化パラメータ(MEMORY_MAX_TARGET)を使用して構成します。Oracle Databaseでは、システム・グローバル領域(SGA)とインスタンス・プログラム・グローバル領域(インスタンスPGA)の間で必要に応じてメモリーを再分配し、ターゲット・メモリー・サイズに合ったチューニングを行います。任意のメモリー・プール・サイズを設定する前に、Oracle Databaseの自動メモリー管理機能の使用を検討してください。メモリー割当てを構成する必要がある場合は、メモリー・アドバイザを使用したメモリー管理も検討してください。

関連項目:

- 自動メモリー管理の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- メモリー・アドバイザの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

7.1.3 自動共有メモリー管理

自動共有メモリー管理を使用すると、SGAの構成が簡単になります。自動共有メモリー管理を使用するには、SGA_TARGET初期化パラメータをゼロ以外の値に設定し、STATISTICS_LEVEL初期化パラメータをTYPICALまたはALLに設定します。SGA_TARGETパラメータの値は、SGA専用にするメモリーの容量に設定します。自動SGA管理では、システム上のワークロードに応じて次のメモリー・プールにメモリーが適切に配分されます。

- データベース・バッファ・キャッシュ(デフォルト・プール)

- 共有プール

- ラージ・プール

- Javaプール

- Streamsプール

自動的にチューニングされるこれらのメモリー・プールをゼロ以外の値に設定すると、その値が自動共有メモリー管理における最小レベルとして使用されます。アプリケーション・コンポーネントが最小限のメモリーで正常に機能できる場合は、最小値に設定します。

SGA_TARGETは動的パラメータであり、Oracle Enterprise Managerの「メモリー・パラメータ」の「SGA」ページからSGAサイズ・アドバイザにアクセスするか、V$SGA_TARGET_ADVICEビューを問い合せてALTER SYSTEMコマンドを使用して変更できます。SGA_TARGETは、SGA_MAX_SIZE初期化パラメータの値以下に設定できます。SGA_TARGETの値の変更により、自動的にチューニングされたメモリー・プールが自動的にサイズ変更されます。

関連項目:

- システム・グローバル領域(SGA)の詳細は、『Oracle Database概要』を参照してください。

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

インスタンス起動時に値を0に設定して動的にSGA_TARGETを無効にする場合、自動共有メモリー管理は無効になり、各メモリー・プールには現在の自動チューニングされたサイズが使用されます。必要であれば、DB_CACHE_SIZE、SHARED_POOL_SIZE、LARGE_POOL_SIZE、JAVA_POOL_SIZEおよびSTREAMS_POOL_SIZEの初期化パラメータを使用して、各メモリー・プールのサイズを手動で変更できます。「キャッシュ・サイズの動的な変更」を参照してください。

次のプールは手動でサイズ設定されるコンポーネントで、自動共有メモリー管理の影響は受けません。

- ログ・バッファ

- その他のバッファ・キャッシュ(KEEP、RECYCLEおよび他の非デフォルト・ブロック・サイズなど)

- 固定SGAおよびその他の内部割当て

これらのメモリー・プールを手動でサイズ設定するには、DB_KEEP_CACHE_SIZE、DB_RECYCLE_CACHE_SIZE、DB_nK_CACHE_SIZEおよびLOG_BUFFER初期化パラメータを設定する必要があります。これらのプールに割り当てられたメモリーは、自動共有メモリー管理で、自動的にチューニングするメモリー・プールの値を計算する際に、SGA_TARGETに使用可能な総量から差し引かれます。

関連項目:

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

- STREAMS_POOL_SIZE初期化パラメータの管理の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

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

7.1.4 キャッシュ・サイズの動的な変更

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

- バッファ・キャッシュの構成および使用方法

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

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

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

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

SGAで現在使用されているグラニュルのサイズは、ビューV$SGA_DYNAMIC_COMPONENTSによって表示できます。それと同じグラニュルのサイズがSGAのすべての動的コンポーネントで使用されます。

SGAの総サイズは、SGA_MAX_SIZEパラメータの値まで拡張できます。SGA_MAX_SIZEが設定されていない場合は、必要であれば、1つのキャッシュのサイズを減らして、そのメモリーを別のキャッシュに再割当てできます。SGA_MAX_SIZEは、全コンポーネントの集計にデフォルト設定されています。

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

インスタンスで使用できる最大メモリー量は、インスタンス起動時にSGA_MAX_SIZE初期化パラメータで決定されます。SGA_MAX_SIZEは、すべてのメモリー・コンポーネント(バッファ・キャッシュや共有プールなど)の合計よりも大きいサイズに指定できます。指定しない場合、SGA_MAX_SIZEは、これらのコンポーネントで使用される実際のサイズにデフォルト設定されます。すべてのコンポーネントで使用される合計メモリーよりも大きい値にSGA_MAX_SIZEを設定すると、別のキャッシュのサイズを小さくせずにキャッシュ・サイズを動的に大きくできます。

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

7.1.4.1 動的サイズ変更操作に関する情報の表示

次のビューは、動的サイズ変更操作に関する情報を提供します。

- V$MEMORY_CURRENT_RESIZE_OPSには、現在進行中のメモリー・サイズ変更操作(自動および手動)に関する情報が表示されます。

- V$MEMORY_DYNAMIC_COMPONENTSには、動的にチューニングされたメモリー・コンポーネントの現在のサイズ(SGAおよびインスタンスPGAの合計サイズなど)に関する情報が表示されます。

- V$MEMORY_RESIZE_OPSには、最新800件の実行済メモリー・サイズ変更操作(自動および手動)に関する情報が表示されます。これには現在進行中の操作は含まれません。

- V$MEMORY_TARGET_ADVICEには、MEMORY_TARGET初期化パラメータのチューニング・アドバイスが表示されます。

- V$SGA_CURRENT_RESIZE_OPSには、現在進行中のSGAサイズ変更操作に関する情報が表示されます。動的SGAコンポーネントの拡張または縮小操作があります。

- V$SGA_RESIZE_OPSには、最新800件の実行済SGAサイズ変更操作に関する情報が表示されます。これには現在進行中の操作は含まれません。

- V$SGA_DYNAMIC_COMPONENTSには、SGAの動的コンポーネントに関する情報が表示されます。このビューでは、起動後に発生したすべての実行済SGAサイズ変更操作に基づく情報が要約されます。

- V$SGA_DYNAMIC_FREE_MEMORYには、今後の動的SGAサイズ変更操作で使用可能なSGAメモリーの量に関する情報が表示されます。

関連項目:

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

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

7.1.5 アプリケーションの考慮事項

メモリーを構成する場合、キャッシュをアプリケーションの必要性に適したサイズに設定します。逆に、アプリケーションのキャッシュの使用率をチューニングすると、リソース要件を大幅に削減できます。Oracle Databaseメモリー・キャッシュを効率的に使用すると、ラッチ、CPU、I/Oシステムなどの関連リソースに対する負荷も軽減できます。

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

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

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

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

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

7.1.6 オペレーティング・システムのメモリー使用量

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

- ページングの削減

- 主メモリーへのSGAの格納

- 個々のユーザーへの十分なメモリーの割当て

7.1.6.1 ページングの削減

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

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

7.1.6.2 主メモリーへのSGAの格納

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

注意:
LOCK_SGAパラメータを使用すると、SGAが物理メモリーにロックされるため、ページ・アウトを防止できます。LOCK_SGAパラメータを有効化した場合、MEMORY_TARGETおよびMEMORY_MAX_TARGETパラメータは使用されません。

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

SHOW SGA

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

Total System Global Area  840205000 bytes
Fixed Size                   279240 bytes
Variable Size             520093696 bytes
Database Buffers          318767104 bytes
Redo Buffers                1064960 bytes

7.1.6.3 個々のユーザーへの十分なメモリーの割当て

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

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

7.1.7 構成の繰返し

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

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

7.2 バッファ・キャッシュの構成および使用方法

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

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

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

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

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

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

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

パラレル問合せを使用する場合、直接PGAに読み込むのではなく、データベース・バッファ・キャッシュを使用するようにデータベースを構成できます。この構成は、データベース・サーバーのメモリー容量が大きい場合に適しています。

関連項目:

- 第16章「SQLチューニングの概要」

- パラレル実行の使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

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

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

7.2.2.1 バッファ・キャッシュ・アドバイザの統計

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

- V$DB_CACHE_ADVICE

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

7.2.2.2 V$DB_CACHE_ADVICEの使用

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

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

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

Oracle Databaseでは、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

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

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

キャッシュ内でのブロックの検出成功とキャッシュのサイズ間の関係は、必ずしも滑らかな分布を示しません。バッファ・プールをサイズ設定するときは、キャッシュ・ヒット率の向上にまったく貢献しない(または、ほとんど貢献しない)追加バッファは使用しないでください。図7-1の例では、キャッシュ・サイズの増分の狭い帯状部分のみが考慮に値することを示しています。

図7-1 物理I/Oとバッファ・キャッシュ・サイズ

図7-1を調べると、次のことがわかります。

- ポイントAからポイントBへバッファを増やす場合の利点は、ポイントBからポイントCへバッファを増やす場合よりかなり大きくなります。

- ポイントAとBおよびポイントBとCとの間の物理I/Oの減少は、グラフの点線で示されるように滑らかではありません。

7.2.2.3 バッファ・キャッシュ・ヒット率の計算

バッファ・キャッシュ・ヒット率では、ディスク・アクセスを行わずにバッファ・キャッシュ内で要求されたブロックが検出された頻度を計算します。この率は、動的なパフォーマンス・ビューV$SYSSTATから選択したデータを使用して計算されます。バッファ・キャッシュ・ヒット率を使用して、V$DB_CACHE_ADVICEで予測されたように物理I/Oを検証できます。

表7-1の統計は、ヒット率の計算に使用されます。

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

統計

説明

consistent gets from cache

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

db block gets from cache

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

physical reads cache

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

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

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

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

SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME IN ('db block gets from cache', 'consistent gets from cache', 'physical reads cache');

問合せの出力の値を使用し、次の計算式でバッファ・キャッシュ・ヒット率を計算します。

1 - (('physical reads cache') / ('consistent gets from cache' + 'db block gets from cache'))

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

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

バッファ・キャッシュ・サイズの増減を考慮する前に、調べるファクタは多数あります。たとえば、V$DB_CACHE_ADVICEデータおよびバッファ・キャッシュ・ヒット率を調べる必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.3.2 バッファ・キャッシュに割り当てられたメモリーの削減

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

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

一般に、ほとんどのシステムでは1つのデフォルト・バッファ・プールが適切です。ただし、アプリケーションのバッファ・プールについて詳しい知識を持つユーザーは、複数バッファ・プールを構成すると有益な場合があります。

非定型アクセス・パターンを持つセグメントの場合、それらのセグメントからのブロックを2つの異なるバッファ・プールであるKEEPプールとRECYCLEプールに格納します。セグメントのアクセス・パターンは、常にアクセスされるか(すなわち、ホット)、またはほとんどアクセスされない(たとえば、1日に1回のみバッチ・ジョブでアクセスされる大きなセグメント)というように、非定型である可能性があります。

複数バッファ・プールによって、これらの違いに対処できます。KEEPバッファ・プールを使用してバッファ・キャッシュ内の頻繁にアクセスされるセグメントを保持し、RECYCLEバッファ・プールを使用してオブジェクトがキャッシュ内の領域を不必要に占有するのを防ぐことができます。オブジェクトがキャッシュに関連付けられると、そのオブジェクトのすべてのブロックがそのキャッシュに置かれます。特定のバッファ・プールに割り当てられていないオブジェクトのために、DEFAULTバッファ・プールがあります。デフォルト・バッファ・プールのサイズは、DB_CACHE_SIZEです。各バッファ・プールは、同じ最低使用頻度LRU置換方針を使用します(たとえば、KEEPプールのサイズが十分ではなく、プールに割り当てられたすべてのセグメントを格納できない場合、最も古いブロックがキャッシュから除去されます)。

オブジェクトを適切なバッファ・プールに割り当てると、次の操作を実行できます。

- I/Oの低減または排除

- 個別のキャッシュに対するオブジェクトの隔離または制限

7.2.4.1 大きいセグメントへのランダム・アクセス

非常に大きいセグメントに大きい索引レンジ・スキャンまたは非有界索引レンジ・スキャンでアクセスすると、LRU除外方法では問題が発生する可能性があります。大規模とは、キャッシュのサイズと比較して大きいという意味です。非順次物理読取りのかなりの割合(10%を超える割合)を1つのセグメントが占有する場合、そのセグメントは大規模であると考えられます。大規模セグメントに対するランダム読取りは、他のセグメントのデータを含むバッファがキャッシュから除去される原因となります。大規模セグメントは、キャッシュの大きな割合を消費しますが、キャッシングによる利益はありません。

非常に頻繁にアクセスされるセグメントは、バッファが頻繁にアクセスされるのでキャッシュから除去されないため、大規模セグメントの読取りの影響を受けません。ただし、その問題は、大規模セグメントの読取りによるバッファの除外を免れるほど頻繁にはアクセスされないウォーム・セグメントに影響を与えます。この問題を解決するオプションは、次の3つです。

1. アクセスされたオブジェクトが索引である場合は、索引に選択性があるかどうかを調べます。選択性がない場合は、さらに選択性のある索引を使用するようにSQL文をチューニングします。

2. SQL文をチューニングすると、大きいセグメントを個別のRECYCLEキャッシュに移動できるので、その他のセグメントに影響を与えません。RECYCLEキャッシュはDEFAULTバッファ・プールよりも小さくし、DEFAULTバッファ・プールよりも迅速にバッファを再利用する必要があります。

3. 大規模セグメントではまったく使用されない別のKEEPキャッシュに小さなウォーム・セグメントを移動する方法もあります。KEEPキャッシュをサイズ設定して、キャッシュでのミスを最小におさえられます。特定の問合せによってアクセスされるセグメントをKEEPキャッシュに置き、除去されないようにすることで、その問合せのレスポンス時間をより予測可能にすることができます。

7.2.4.2 Oracle Real Application Clustersのインスタンス

データベース・インスタンスごとに複数バッファ・プールを作成できます。データベースの各インスタンスについて、必ずしも同じバッファ・プール・セットを定義する必要はありません。インスタンスごとにバッファ・プールのサイズを変えることも、バッファを定義しないこともできます。それぞれのアプリケーション要件に従って、各インスタンスをチューニングします。

7.2.4.3 複数バッファ・プールの使用方法

オブジェクトのデフォルト・バッファ・プールを定義するには、STORAGE句のBUFFER_POOLキーワードを使用します。この句は、CREATE TABLE、CREATE CLUSTER、CREATE INDEX、ALTER TABLE、ALTER CLUSTER、ALTER INDEXの各SQL文に有効です。バッファ・プールを指定すると、そのオブジェクトに対して読み取られたブロックは、すべてそのプールに配置されます。

バッファ・プールがパーティション表または索引に対して定義されている場合、オブジェクトの各パーティションは、特定のバッファ・プールで上書きされないかぎり、表または索引定義からバッファ・プールを継承します。

オブジェクトのバッファ・プールがALTER文を使用して変更された場合、変更されたセグメントのブロックを現在格納しているすべてのバッファは、ALTER文を発行する前にあったバッファ・プールに残ります。新たにロードされたブロック、および除去されてリロードされたブロックは、新しいバッファ・プールに入ります。

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

7.2.5 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';

7.2.6 バッファ・プール・ヒット率

V$SYSSTATのデータは、すべてのバッファ・プールに対する論理読取りと物理読取りを1つの統計セットとして表します。バッファ・プールのヒット率を個々に確認するには、V$BUFFER_POOL_STATISTICSビューを問い合せます。このビューは、論理読取りと論理書込みの回数に関するプールごとの統計をメンテナンスします。

バッファ・プール・ヒット率は、次の計算式を使用して決定できます。

1 - (physical_reads/(db_block_gets + consistent_gets))

次の問合せを使用して比率を計算できます。

SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio"
FROM V$BUFFER_POOL_STATISTICS;

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

7.2.7 プール内に多くのバッファを持つセグメントの特定

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

方法1

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

COLUMN OBJECT_NAME FORMAT A40
COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999

SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS
FROM DBA_OBJECTS o, V$BH bh
WHERE o.DATA_OBJECT_ID = bh.OBJD
AND o.OWNER         != 'SYS'
GROUP BY o.OBJECT_NAME
ORDER BY COUNT(*);

OBJECT_NAME                              NUMBER_OF_BLOCKS
---------------------------------------- ----------------
OA_PREF_UNIQ_KEY                                        1
SYS_C002651                                             1
..
DS_PERSON                                              78
OM_EXT_HEADER                                         701
OM_SHELL                                            1,765
OM_HEADER                                           5,826
OM_INSTANCE                                        12,644

方法2

次の手順に従って、ある時点で個々のオブジェクトによって使用されるキャッシュの割合を決定してください。

1. 次の問合せを入力して、セグメントのOracle Database内部オブジェクト番号を検索します。

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;

4. バッファの総数に対するバッファの比率を計算し、現在SEGMENT_NAMEで使用されているキャッシュの割合を取得します。

% cache used by segment_name = [buffers(Step2)/total buffers(Step3)]

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

7.2.8 KEEPプール

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

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

注意:
NOCACHE句は、KEEPキャッシュ内の表に影響を与えません。

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

ヒット率を計算するには、前述の問合せを使用してシステム・パフォーマンスの2つのスナップショットを時間をおいて取ります。物理読取り(physical reads)、ブロック取得(block gets)および一貫性読取り(consistent gets)について、古い値から新しい値を引いて、これらの結果を使用してヒット率を計算します。

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

注意:
オブジェクトのサイズが大きくなった場合に、KEEPバッファ・プールに入りきらなくなることがあります。この場合、キャッシュからブロックが失われ始めます。

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

7.2.9 RECYCLEプール

メモリーに残さないセグメントに属するブロック用のRECYCLEバッファ・プールを構成できます。RECYCLEプールは、ほとんどスキャンされないか頻繁に参照されないセグメントに適しています。アプリケーションがラージ・オブジェクトのブロックをランダム方式でアクセスする場合は、バッファ・プールに格納されているブロックが除去される前に再利用できる可能性はほとんどありません。これは(使用可能物理メモリーの量の制約により)バッファ・プールのサイズに関係なくあてはまります。したがって、そのオブジェクトのブロックをキャッシュする必要はありません。これらのキャッシュ・バッファは、他のオブジェクトに割り当てることができます。

メモリーは、DB_RECYCLE_CACHE_SIZEパラメータを必要なサイズに設定することでRECYCLEバッファ・プールに割り当てられます。このRECYCLEバッファ・プールのメモリーは、デフォルト・プールのサブセットではありません。

あまり早くメモリーからブロックを破棄しないでください。バッファ・プールが小さすぎると、トランザクションまたはSQL文が実行を完了する前に、ブロックがキャッシュから除外されてしまう可能性があります。たとえば、アプリケーションが表から値を選択し、その値を使用してデータを処理し、レコードを更新する場合があります。SELECT文の後でブロックがキャッシュから削除された場合は、更新を実行するために再度ディスクから読み取る必要があります。ブロックは、ユーザー・トランザクションの所要時間中は保存される必要があります。

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

異なるタイプのデータをキャッシュするには、共有プールを使用します。キャッシュされたデータには、PL/SQLブロックおよびSQL文のテキストおよび実行可能フォーム、ディクショナリ・キャッシュ・データ、結果キャッシュ・データおよびその他のデータが含まれています。

共有プールを適切な大きさにして使用すると、次の4つの方法でリソース使用量を低減できます。

- SQL文が共有プールに存在する場合は解析オーバーヘッドをなくせます。このため、ホスト上のCPUリソースとエンド・ユーザーの経過時間が節約されます。

- リソース使用のラッチングが大幅に減少して、スケーラビリティがさらに増大します。

- すべてのアプリケーションがSQL文およびディクショナリ・リソースの同一プールを使用するので、共有プール・メモリーの必要量が低減されます。

- 共有プールのディクショナリ要素はディスク・アクセスが不要なので、I/Oリソースが節約されます。

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

- 共有プールの概念

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

- 共有プールのサイズ設定

- 共有プール統計の解釈

- ラージ・プールの使用

- CURSOR_SPACE_FOR_TIMEの使用

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

- 予約プールの構成

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

- 既存アプリケーションのカーソルの共有

- 接続の維持

注意:
サーバーの結果キャッシュは、問合せの結果とファンクションの結果を格納する共有プール内のオプションのキャッシュです。結果キャッシュに関する情報は、「サーバーおよびクライアントの結果キャッシュの管理」を参照してください。

7.3.1 共有プールの概念

共有プールの主なコンポーネントは、ライブラリ・キャッシュ、ディクショナリ・キャッシュおよび(使用中の構成に応じた)サーバーの結果キャッシュです。ライブラリ・キャッシュは、最近参照されたSQLとPL/SQLコードの実行可能な(解析またはコンパイルされた)形式を格納します。ディクショナリ・キャッシュは、データ・ディクショナリから参照されたデータを格納します。サーバーの結果キャッシュは、問合せの結果とPL/SQLファンクションの結果を格納します。

ライブラリ・キャッシュやディクショナリ・キャッシュなどの共有プール内のキャッシュの多くは、必要に応じてサイズを自動的に増減します。共有プールに空き領域がない場合は、新しいエントリを受け入れるために古いエントリが除去されます。

データ・ディクショナリ・キャッシュまたはライブラリ・キャッシュでのキャッシュ・ミスは、バッファ・キャッシュでのミスよりも影響が大きくなります。このため、頻繁に使用されるデータがキャッシュされるように共有プールをサイズ設定する必要があります。

共有サーバー、パラレル問合せ、Recovery Managerなど、共有プールで大きいメモリーの割当てを行う機能は複数あります。ラージ・プールと呼ばれる個別のメモリー領域を構成して、これらの機能で使用されるSGAメモリーを区別することをお薦めします。

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

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

関連項目:

- 共有プールの予約領域の詳細は、「予約プールの構成」を参照してください。

- ラージ・プールの構成の詳細は、「ラージ・プールの使用」を参照してください。

7.3.1.1 ディクショナリ・キャッシュの概念

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

7.3.1.2 ライブラリ・キャッシュの概念

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

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

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

アプリケーションでSQL文の実行コールを行ったが、以前に作成されたSQL文の実行可能部分が別の文の場所を確保するためにライブラリ・キャッシュから除去(すなわち、割当て解除)されていた場合、Oracle Databaseはその文を暗黙的に再解析し、新しい共有SQL領域を作成し、実行します。この場合も、ハード解析が発生します。通常は、ライブラリ・キャッシュに割り当てるメモリーを増やすことによって実行コールのライブラリ・キャッシュ・ミスを低減できます。

ハード解析を実行するには、ソフト解析の実行時より多くのリソースを使用します。ソフト解析に使用するリソースには、CPUおよびライブラリ・キャッシュ・ラッチ取得が含まれます。ハード解析に必要なリソースには、追加のCPU、ライブラリ・キャッシュ・ラッチ取得および共有プール・ラッチ取得が含まれます。ハード解析およびソフト解析の詳細は、「SQLの実行効率」を参照してください。

7.3.1.3 SQL共有基準

Oracle Databaseでは、SQL文またはPL/SQLブロックを発行する際に、共有プールに同じ文が存在するかどうかを自動的に確認します。

SQL文のテキストと、共有プール内の既存のSQL文を比較する際にOracle Databaseで実行される手順を次に示します。

1. 文のテキストがハッシュされます。一致するハッシュ値がない場合、SQL文は共有プール内に現在存在せず、ハード解析が実行されます。

2. 共有プール内の既存のSQL文に一致するハッシュ値がある場合は、一致した文のテキストが、ハッシュされた文のテキストと比較され、それらが同一であるかどうかが確認されます。SQL文やPL/SQLブロックのテキストは、空白、大文字小文字の区別、コメントも含め、完全に同一である必要があります。たとえば、次の文は同じ共有SQL領域を使用できません。

SELECT * FROM employees;
SELECT * FROM Employees;
SELECT *  FROM employees;

通常は、リテラルのみ異なるSQL文は同じ共有SQL領域を使用できません。たとえば、次の文は同じSQL領域に変換されません。

SELECT count(1) FROM employees WHERE manager_id = 121;
SELECT count(1) FROM employees WHERE manager_id = 247;

唯一の例外は、CURSOR_SHARINGがFORCEに設定されている場合です。CURSOR_SHARINGがFORCEに設定されている場合、類似の文はSQL領域を共有できます。CURSOR_SHARINGを使用する場合のコストと効果については、「CURSOR_SHARINGを非デフォルト値に設定する場合」で説明します。

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

3. 発行された文で参照されたオブジェクトは、共有プール内のすべての既存の文の参照済オブジェクトと比較され、両方のオブジェクトが同一であるかどうかが確認されます。
SQL文やPL/SQLブロック内でスキーマ・オブジェクトを参照する際には、同じスキーマ内の同じオブジェクトである必要があります。たとえば、2人のユーザーが次のSQL文を発行し、各ユーザーに独自のemployees表がある場合、文はユーザーごとに異なる表を参照するので、この文は同一とみなされません。

SELECT * FROM employees;

4. SQL文の中のバインド変数は、名前、データ型および長さで一致している必要があります。
たとえば、次の文で同じ共有SQL領域を使用できないのは、バインド変数名が異なるためです。

SELECT * FROM employees WHERE department_id = :department_id;
SELECT * FROM employees WHERE department_id = :dept_id;

多くのOracle製品(Oracle Formsやプリコンパイラなど)は、文をデータベースに渡す前にSQLを変換します。首尾一貫したSQL文の集合が生成されるように、文字は大文字に統一して変換され、空白は圧縮され、バインド変数は改名されます。

5. セッションの環境は同一である必要があります。たとえば、SQL文は、同一の最適化目標を使用して最適化する必要があります。

7.3.2 共有プールの効果的な使用方法

共有プールの重要な目的は、SQL文とPL/SQL文の実行可能バージョンをキャッシュすることです。これにより、ハード解析にリソースを使用することなく、同じSQLまたはPL/SQLコードを複数回実行できるので、CPU、メモリーおよびラッチの使用が大幅に減少します。

また、共有プールは、データ・ウェアハウス・アプリケーションで非共有SQLをサポートできます。これらのアプリケーションでは、同時実行性が低くリソース使用率の高いSQL文が実行されます。このような状況では、リテラル値を持つ非共有SQLを使用することをお薦めします。バインド変数ではなくリテラル値を使用すると、オプティマイザは優れた列選択性の見積りを行えるので、最適なデータ・アクセス・プランを提供します。

OLTPシステムには、共有プールと関連リソースの効率的な使用を実現するいくつかの方法があります。次の項目についてアプリケーション開発者と検討し、共有プールの効率的な使用方法を決定します。

- 共有カーソル

- 単一のユーザーのログインおよび修飾表の参照

- PL/SQLの使用方法

- DDLの実行の回避

- キャッシュ順序番号

- カーソルのアクセスおよび管理

同時実行性の高いOLTPシステムで共有プールを効率よく使用すると、解析関連アプリケーションのスケーラビリティの問題が発生する確率が大幅に低減します。

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

7.3.2.1 共有カーソル

同じアプリケーションを実行する複数のユーザーのために共有SQLを再利用すると、ハード解析が回避されます。ソフト解析は、共有プール・ラッチやライブラリ・キャッシュ・ラッチなどのリソース使用量を大幅に減少させます。カーソルを共有するには、次のことを行います。

- 可能な場合、SQL文ではリテラルではなくバインド変数を使用します。たとえば、次の2つの文は字面が完全には一致しないので、同じ共有領域は使用できません。

SELECT employee_id FROM employees WHERE department_id = 10;
SELECT employee_id FROM employees WHERE department_id = 20;

リテラルをバインド変数と置換すると、2回実行可能なSQL文が1つのみ生成されます。

SELECT employee_id FROM employees WHERE department_id = :dept_id;

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

- 多数のユーザーが動的な非共有のSQL文を発行するようなアプリケーションを設計しないようにしてください。通常、大半のユーザーが必要とするデータの大部分は、事前に設定されている問合せを使用して満たすことができます。そのような機能が必要な場合は、動的SQLを使用します。

- アプリケーションのユーザーが最適化アプローチと目標を各セッションに対して変更しないことを確認してください。

- アプリケーション開発者に対し、次のポリシーを設定します。

- SQL文とPL/SQLブロックに対して、バインド変数のネーミング規則と、スペーシング規定を標準化します。

- 可能な場合、ストアド・プロシージャを使用することを考慮してください。そうすれば、同じストアド・プロシージャを発行している複数のユーザーが、同じ共有PL/SQL領域を自動的に使用します。ストアド・プロシージャは解析済フォームに格納されるため、ストアド・プロシージャを使用するとランタイム解析が減少します。

- 同一であっても共有されていないSQL文についてV$SQL_SHARED_CURSORを問い合せることで、カーソルが共有されない理由を判断できます。この理由には、オプティマイザの設定とバインド変数の不整合などがあります。

7.3.2.2 単一のユーザーのログインおよび修飾表の参照

ユーザーが独自のユーザーIDでデータベースにログインするような大きいOLTPシステムでは、パブリック・シノニムを使用するのではなく、明示的にセグメントの所有者を修飾すると有益です。これにより、ディクショナリ・キャッシュ内のエントリ数が大幅に削減されます。たとえば、次のようにします。

SELECT employee_id FROM hr.employees WHERE department_id = :dept_id;

表名を認定する別の方法として、個々のユーザーIDではなく単一のユーザーIDでデータベースに接続します。ユーザー・レベルの検証は、中間層でローカルに行われます。個別のユーザーIDの数を削減した場合も、ディクショナリ・キャッシュ上の負荷は低減します。

7.3.2.3 PL/SQLの使用方法

ストアドPL/SQLパッケージを使用すると、多数のユーザーが個々にユーザー・サインオンとパブリック・シノニムを持つシステムにおける、スケーラビリティの問題を克服できます。これは、パッケージがコール元ではなく所有者として実行されるため、ディクショナリ・キャッシュの負荷がかなり削減されるためです。

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

7.3.2.4 DDLの実行の回避

ピーク時間に使用率の高いセグメントでDDL操作を実行しないようにします。そのようなセグメントでDDLを実行すると、多くの場合、依存SQLは無効にされるため、以降の実行で再度解析されることになります。

7.3.2.5 キャッシュ順序番号

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

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

7.3.2.6 カーソルのアクセスおよび管理

使用しているアプリケーション・ツールによっては、アプリケーションの解析コールの実行頻度を制御できます。

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

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

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

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

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

関連項目:

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

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

7.3.2.6.1 OCIによる解析コールの低減

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

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

7.3.2.6.2 Oracleプリコンパイラによる解析コールの低減

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

- HOLD_CURSOR = YES

- RELEASE_CURSOR = NO

- MAXOPENCURSORS = desired_value

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

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

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

7.3.2.6.3 SQLJによる解析コールの低減

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

7.3.2.6.4 JDBCによる解析コールの低減

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

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

7.3.2.6.5 Oracle Formsによる解析コールの低減

Oracle Formsで、カーソル管理の一部を管理できます。トリガー・レベル、フォーム・レベルまたは実行時のいずれかで、この管理を実施できます。

7.3.3 共有プールのサイズ設定

新規にインスタンスを構成する場合、作成する共有プール・キャッシュの適切なサイズを知ることはできません。通常、DBAはキャッシュ・サイズの最初の見積りを行い、次にインスタンス上で代表的なワークロードを実行し、関連する統計を調べて、キャッシュが過小構成か過大構成かを調べます。

OLTPアプリケーションの多くでは、共有プール・サイズはアプリケーション・パフォーマンスにとって重要な要因です。意思決定支援システム(DSS)のような、ごく少数の不連続なSQL文を発行するアプリケーションでは、共有プールのサイズはそれほど重要ではありません。

共有プールが小さすぎると、使用可能領域の限度を補うために、追加リソースを使用することになります。このため、CPUとラッチングのリソースが使用され、競合が発生します。共有プールは、頻繁にアクセスされるオブジェクトをキャッシュするためにちょうど十分な大きさであることが最適です。共有プールに大量の空きメモリーを持つことは、メモリーの無駄になります。データベースの稼働後に統計を調べる際、DBAはこの点についてワークロード内に該当する箇所がないかチェックする必要があります。

7.3.3.1 共有プール: ライブラリ・キャッシュの統計

共有プールをサイズ設定するときの目標は、メモリーを割り当てすぎずに、複数回実行されるSQL文がライブラリ・キャッシュにキャッシュされるようにすることです。

以前にキャッシュされ、すでに除去されたSQL文のリロード(すなわち、再解析)の量の統計は、V$LIBRARYCACHEビューのRELOADS列に示されます。効果的にSQLを再利用するアプリケーションでは、システムが最適な共有プール・サイズを持ち、RELOADS統計が0(ゼロ)に近い値を示します。

V$LIBRARYCACHEビューのINVALIDATIONS列は、ライブラリ・キャッシュのデータが無効にされ、再解析された回数を示しています。INVALIDATIONSは0(ゼロ)に近い値である必要があります。つまり、共有できた可能性のあるSQL文が、ある操作(たとえば、DDL)により無効にされたことを意味します。この統計は、ピーク・ロード中のOLTPシステム上では、0(ゼロ)に近い値となります。

別の重要な統計は、ピーク時の共有プール内の空きメモリー量です。空きメモリー量は、共有プールの空きメモリーを参照するV$SGASTATから問い合せることができます。空きメモリーは、システム上にリロードを発生させない程度で、できるだけ小さい値である必要があります。

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

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

7.3.3.2 V$LIBRARYCACHE

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

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

- SQL AREA

- TABLE/PROCEDURE

- BODY

- TRIGGER

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

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

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

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

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

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

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

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

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

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

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

関連項目:
ある時間間隔の情報を収集する方法の詳細は、第6章「自動パフォーマンス診断」を参照してください。

戻されたデータを調べると、次のことがわかります。

- SQL AREAのNAMESPACEでは、21,536,413回の実行がありました。

- 11,204回の実行でライブラリ・キャッシュ・ミスが発生したため、文またはブロックを暗黙的に再解析するか、またはライブラリ・キャッシュから除去されている場合は、オブジェクト定義をリロード(すなわち、RELOAD)する必要があります。

- SQL文は2回無効化されたため、再度ライブラリ・キャッシュ・ミスが発生しました。

- ヒット率は約99.94%です。これは、実行の0.06%のみが再解析されたことを意味します。

共有プールの空きメモリーの容量は、V$SGASTATでレポートされます。次の問合せを使用してこのビューの現在の値についてレポートを作成します。

SELECT * FROM V$SGASTAT
WHERE NAME = 'free memory'
AND POOL = 'shared pool';

出力は、次のようなものです。

POOL        NAME                            BYTES
----------- -------------------------- ----------
shared pool free memory                   4928280

共有プール内に使用可能な空きメモリーが常にある場合、プールのサイズを増やしても、効果はほとんど(または、まったく)ありません。しかし、共有プールがいっぱいというだけでは、問題があるとはいえません。これは、適切に構成されたシステムであることを示している場合があります。

7.3.3.3 共有プールのアドバイザ統計

ライブラリ・キャッシュに使用可能なメモリー量は、Oracleデータベース・インスタンスの解析率に大きな影響を与えます。共有プールのアドバイザ統計から、データベース管理者はライブラリ・キャッシュ・メモリーについての情報を得ることができ、共有プールのサイズ変更が共有プール内のオブジェクトの除去にどのように影響するかを予測できます。

共有プールのアドバイザ統計では、共有プール・メモリーにおけるライブラリ・キャッシュの使用率が追跡され、異なるサイズの共有プールでライブラリ・キャッシュがどのように動作するかが予測されます。2つの固定ビューにより、ライブラリ・キャッシュのメモリー使用量、現在の確保量、共有プールのLRUリスト上にある量、さらに共有プールのサイズ変更により損失または獲得できる時間を判別する情報が提供されます。

共有プールのアドバイザ統計では、次のビューが使用できます。共有プール・アドバイザをオンにすると、これらのビューにはあらゆるデータが表示されます。共有プール・アドバイザをオフにすると、それらの統計がリセットされます。

7.3.3.3.1 V$SHARED_POOL_ADVICE

このビューには、共有プールのサイズを変更した場合の、見積り解析時間に関する情報が表示されます。サイズの範囲は、同じ時間間隔で、現在の共有プール・サイズまたは確保されたライブラリ・キャッシュ・メモリー量の10%のうち大きい方の値から、現在の共有プール・サイズの200%までです。時間間隔の値は、共有プールの現在のサイズによって異なります。

7.3.3.3.2 V$LIBRARY_CACHE_MEMORY

このビューには、別のNAMESPACEのライブラリ・キャッシュのメモリー・オブジェクトに割り当てられるメモリーに関する情報が表示されます。メモリー・オブジェクトとは、効率的な管理を行うためのメモリーの内部グループ化です。ライブラリ・キャッシュ・オブジェクトは1つ以上のメモリー・オブジェクトで構成されます。

7.3.3.3.3 V$JAVA_POOL_ADVICEおよびV$JAVA_LIBRARY_CACHE_MEMORY

これらのビューには、Javaに使用されるライブラリ・キャッシュ・メモリーについての情報を追跡し、Javaプールのサイズ変更が解析率に及ぼす影響を予測する、Javaプール・アドバイザ統計が含まれます。

V$JAVA_POOL_ADVICEには、プールのサイズを変更した場合の、Javaプールの見積り解析時間に関する情報が表示されます。サイズの範囲は、同じ時間間隔で、現在のJavaプール・サイズまたは確保されたJavaライブラリ・キャッシュ・メモリー量の10%のうち大きい方の値から、現在のJavaプール・サイズの200%までです。時間間隔の値は、Javaプールの現在のサイズによって異なります。

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

7.3.3.4 共有プール: ディクショナリ・キャッシュの統計

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

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

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

表7-2 V$ROWCACHE列

列

説明

PARAMETER

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

GETS

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

GETMISSES

キャッシュで満たされなかったデータ・リクエストで、I/Oを必要とするものの個数を示します。

MODIFICATIONS

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

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

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

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

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

PARAMETER              SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS      UPDATES
--------------------- ---------- -------------- ------------- ------------
dc_database_links             81              1          98.8            0
dc_free_extents            44876          20301          54.8       40,453
dc_global_oids                42              9          78.6            0
dc_histogram_defs           9419            651          93.1            0
dc_object_ids              29854            239          99.2           52
dc_objects                 33600            590          98.2           53
dc_profiles                19001              1         100.0            0
dc_rollback_segments       47244             16         100.0           19
dc_segments               100467          19042          81.0       40,272
dc_sequence_grants           119             16          86.6            0
dc_sequences               26973             16          99.9       26,811
dc_synonyms                 6617            168          97.5            0
dc_tablespace_quotas         120              7          94.2           51
dc_tablespaces            581248             10         100.0            0
dc_used_extents            51418          20249          60.6       42,811
dc_user_grants             76082             18         100.0            0
dc_usernames              216860             12         100.0            0
dc_users                  376895             22         100.0            0

サンプル問合せが戻したデータを調べると、次のことがわかります。

- 使用済エクステント、空きエクステントおよびセグメントには、多数のミスと更新があります。つまり、インスタンスに大量の動的な領域の拡張があったことを示しています。

- 取得成功率およびその統計と、実際の取得数との比較に基づくと、共有プールはディクショナリ・キャッシュ・データを適切に格納できる大きさがあります。

次の計算式を使用して、総合的ディクショナリ・キャッシュ・ヒット率も計算できますが、すべてのキャッシュにわたるデータを合計すると、より細かいデータの粒度は失われます。

SELECT (SUM(GETS - GETMISSES - FIXED)) / SUM(GETS) "ROW CACHE" FROM V$ROWCACHE;

7.3.4 共有プール統計の解釈

共有プール統計は実行可能な調整方法を示します。この項ではそのうちのいくつかについて説明します。

7.3.4.1 メモリー割当ての増加

共有プールのメモリー量を増やすと、ライブラリ・キャッシュ、ディクショナリ・キャッシュおよび結果キャッシュで使用できるメモリー量が増えます(「初期化パラメータによるサーバーの結果キャッシュ・メモリーの管理」を参照)。

7.3.4.1.1 ライブラリ・キャッシュへの追加のメモリー割当て

共有SQL領域がそれらのSQL文を解析した後にキャッシュ内に残るようにするには、V$LIBRARYCACHE.RELOADS値が0(ゼロ)に近くなるまでライブラリ・キャッシュに利用できるメモリー量を増やします。ライブラリ・キャッシュに利用できるメモリーを増やすには、SHARED_POOL_SIZE初期化パラメータの値を増やしてください。このパラメータの最大値はオペレーティング・システムによって異なります。この処置によって、実行のためのSQL文とPL/SQLブロックの暗黙的な再解析が減少します。

7.3.4.1.2 データ・ディクショナリ・キャッシュへの追加のメモリーの割当て

GETSとGETMISSES列を監視することによって、キャッシュ・アクティビティを調べてください。ディクショナリ・キャッシュが頻繁にアクセスされる場合、GETSの合計に対するGETMISSESの合計の割合は、アプリケーションによって異なりますが、10%または15%より低くしてください。

次のすべてに当てはまる場合は、キャッシュに利用できるメモリー量を増やすことを考慮してください。

- アプリケーションは共有プールを効果的に使用している。「共有プールの効果的な使用方法」を参照してください。

- システムは安定状態に達し、項目固有のヒット率が低く、ヒット率の低いキャッシュへの取得数が多い。

初期化パラメータSHARED_POOL_SIZEの値を増やして、データ・ディクショナリ・キャッシュに利用できるメモリーを増やします。

7.3.4.2 メモリー割当ての減少

RELOADSが0に近く、共有プール内の空きメモリーが少ない場合、共有プールは、最も頻繁にアクセスされるデータを保持できる十分な大きさがあります。

常に共有プールに多数の空きメモリーがある場合、このメモリーを他の場所に割り当てるために共有プールのサイズを小さくしても、良好なパフォーマンスを維持できます。

共有プールを小さくするには、SHARED_POOL_SIZEパラメータの値を変更してキャッシュのサイズを小さくします。

7.3.5 ラージ・プールの使用

共有プールとは異なり、ラージ・プールにはLRUリストがありません。Oracle Databaseは、ラージ・プールからオブジェクトを除去しようとしません。

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

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

関連項目:

- パラレル実行方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

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

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

関連項目:
Recovery Managerを使用する場合のラージ・プールのサイズ設定の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

7.3.5.1 共有サーバー・アーキテクチャでのラージ・プールと共有プールのチューニング

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

共有サーバー関連のユーザー・グローバル領域(UGA)の割当てには、共有プールではなくラージ・プールの使用をお薦めします。これは、Oracle Databaseでは、共有SQLやPL/SQLプロシージャなどの他の目的のためのシステム・グローバル領域(SGA)メモリーの割当てに共有プールが使用されるためです。共有プールのかわりにラージ・プールを使用すると、共有プールの断片化も減少します。

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

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

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

関連項目:

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

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

7.3.5.1.1 共有サーバーのUGA記憶域のための効果的な設定の判別

Oracle DatabaseでのUGAの正確な容量は、アプリケーションごとに異なります。ラージ・プールまたは共有プールの効果的な設定を判別するには、一般的なユーザーでのUGAの使用状況を観察して、その容量をユーザー・セッションの見積り数に乗算します。

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

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

7.3.5.1.2 V$SESSTATビューでのシステム統計のチェック

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

表7-3 メモリーを反映したV$SESSTAT統計

統計

説明

session UGA memory

この統計の値は、セッションに割り当てられたメモリー容量です(単位はバイト)。

Session UGA memory max

この統計の値は、セッションに割り当てたメモリー容量の最大値です(単位はバイト)。

値を検索するには、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番目の値よりも最初の値の方がよい見積りになります。

7.3.5.1.3 PRIVATE_SGAの設定による各ユーザー・セッションのメモリー使用量の制限

PRIVATE_SGAリソース制限を設定して、各クライアント・セッションによるSGAのメモリー使用量を制限できます。PRIVATE_SGAによって、1セッションでSGAから使用されるメモリーのバイト数が定義されます。ただし、ほとんどのDBAはユーザー単位でのSGA消費量の制限は行わないため、このパラメータを使用することはほとんどありません。

関連項目:
PRIVATE_SGAリソース制限の設定の詳細は、『Oracle Database SQL言語リファレンス』の ALTER RESOURCE COST文に関する項を参照してください。

7.3.5.1.4 3層の接続でのメモリー使用の低減

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

- TPモニターに比べてアプリケーション設計の制限が大幅に少なくなります。

- ユーザーがサーバーのプールを共有できるので、オペレーティング・システム・プロセス数とコンテキストの切替えが大幅に減ります。

- 共有サーバー・モードでさらに多くのSGAが使用される場合でも総メモリー使用量が大幅に減ります。

7.3.6 CURSOR_SPACE_FOR_TIMEの使用

ライブラリ・キャッシュ・ミスがない場合も、初期化パラメータCURSOR_SPACE_FOR_TIMEの値をtrueに設定することによって実行コールを高速化できる可能性があります。このパラメータは、新しいSQL文の領域を作成するために、ライブラリ・キャッシュからカーソルの割当てを解除するかどうかを指定します。CURSOR_SPACE_FOR_TIMEの値には次の意味があります。

- CURSOR_SPACE_FOR_TIMEがfalseに設定されていると(デフォルト)、SQL文に対応付けられているアプリケーション・カーソルがオープンされているかどうかにかかわらず、ライブラリ・キャッシュからカーソルの割当てを解除できます。この場合は、SQL文を含むカーソルがライブラリ・キャッシュ内にあることを検証する必要があります。

- CURSOR_SPACE_FOR_TIMEをtrueに設定すると、その文に関連するすべてのアプリケーション・カーソルがクローズされる場合のみカーソルの割当てを解除できます。この場合、カーソルに関連するアプリケーション・カーソルがオープンしている間はそのカーソルの割当てを解除できないため、カーソルがキャッシュ内にあるかどうかを確認する必要はありません。

パラメータの値をtrueに設定することで、Oracle Database側の時間が少し短縮されるので、いくらか実行コールのパフォーマンスが改善する可能性があります。この値は、対応付けられているアプリケーション・カーソルがクローズされるまでカーソルの割当て解除も防ぎます。

実行コールでライブラリ・キャッシュ・ミスがあった場合は、CURSOR_SPACE_FOR_TIMEの値をtrueに設定しないでください。そのようなライブラリ・キャッシュ・ミスは、共有プールが十分大きくないので同時にオープンしている全カーソルの共有SQL領域を保持できないことを示しています。値がtrueであり、共有プール内に新しいSQL文のための領域がない場合、文は解析されず、共有メモリーがなくなったことを示すエラーが戻されます。値がfalseであり、新しい文のための領域がない場合は、既存カーソルの割当てが解除されます。カーソルの割当てを解除するとライブラリ・キャッシュ・ミスが後で発生しますが(カーソルが再度実行される場合のみ)、SQL文を解析できないためにアプリケーションが停止するというエラーよりも望ましい対処と言えます。

各ユーザーに利用できるプライベートSQL領域のメモリー量が不十分な場合、CURSOR_SPACE_FOR_TIMEの値をtrueに設定しないでください。また、この値は、オープンしているカーソルに対応付けられているプライベートSQL領域の割当て解除も防ぎます。同時にオープンしているすべてのカーソルのプライベートSQL領域によって使用可能メモリーがいっぱいになり、新しいSQL文の領域がない場合は、文を解析できません。メモリーが十分でないというエラーが戻されます。

7.3.7 セッション・カーソルのキャッシュ

セッション・カーソル・キャッシュには、SQLおよびPL/SQL(再帰的SQLを含む)のクローズされたセッション・カーソルが含まれます。

フォーム間で切替えを行うと、最初のフォームに関連するすべてのセッション・カーソルがクローズされるため、このキャッシュは、Oracle Formsが使用されているアプリケーションで有用です。アプリケーションから何度も同じSQL文で解析コールが発行される場合、セッション・カーソルの再オープンによりパフォーマンスが低下することがあります。カーソルを再使用することにより、データベースは分析時間を削減できるため、結果として全体的な実行時間が短縮されます。

7.3.7.1 セッション・カーソル・キャッシュの機能

セッション・カーソルは、共有子カーソルのインスタンス化を表し、特定のセッションの共有プールに格納されます。各セッション・カーソルには、インスタンス化した子カーソルへの参照が格納されます。

Oracle Databaseでは、ライブラリ・キャッシュをチェックして、特定の文に対して3回以上の解析リクエストが発行されたかどうかを識別します。カーソルが3回クローズされている場合は、文に関連するセッション・カーソルをキャッシュする必要があると推定し、カーソルをセッション・カーソル・キャッシュに移動します。

同じセッションでSQL文の解析リクエストが続けて出されると、共有カーソルへのポインタの配列が検索されます。ポインタが見つかると、データベースはポインタを逆参照して共有カーソルが存在するかどうか特定します。カーソルをキャッシュから再使用するために、キャッシュ・マネージャはキャッシュされたカーソルの状態が現在のセッションとシステム環境に適合するかどうか確認します。

注意:
キャッシュ・カーソルの再使用はハード解析ではありませんが、まだ解析として登録されています。

LRUのアルゴリズムでは、必要に応じてセッション・カーソル・キャッシュ内の項目を除去し、新しい項目のための空間を作成します。また、キャッシュは内部の時間ベースのアルゴリズムを使用して、一定時間アイドル状態になっているカーソルを除去します。

7.3.7.2 セッション・カーソル・キャッシュの有効化

次にカーソル・キャッシュに関連する初期化パラメータを示します。

- SESSION_CACHED_CURSORS
このパラメータは、1セッション当たりのクローズされたキャッシュ・カーソルの最大数を設定します。デフォルト設定は50です。このパラメータを使用して、セッションで大量のカーソルが開かれて、そのためにライブラリ・キャッシュがいっぱいになったり過剰なハード解析が求められるのを回避できます。

- OPEN_CURSORS
このパラメータは、セッションで同時に開くことができるカーソルの最大数を指定します。たとえば、OPEN_CURSORSを1000に設定すると、各セッションは一度に最大1000個のカーソルを開くことができます。

SESSION_CACHED_CURSORSパラメータとOPEN_CURSORSパラメータは無関係です。セッション・カーソルは開いた状態ではキャッシュされないため、たとえば、SESSION_CACHED_CURSORSにOPEN_CURSORSより大きい値を設定できます。

セッション・カーソルのキャッシュを有効にするには:

1. キャッシュに保持するセッション・カーソルの最大数を決定します。

2. 次のいずれかを実行します。

- キャッシュを静的に有効にするには、初期化パラメータSESSION_CACHED_CURSORSに前の手順で決定した数を設定します。

- キャッシュを動的に有効にするには、次の文を実行します。

ALTER SESSION SET SESSION_CACHED_CURSORS = value;

7.3.7.3 セッション・カーソル・キャッシュのチューニング

V$SYSSTATの問合せを行い、セッション・カーソル・キャッシュがデータベース・インスタンスに対して十分なサイズかどうか判断することができます。

セッション・カーソル・キャッシュをチューニングするには:

1. 現在特定のセッションにキャッシュされているカーソルの数を特定します。
たとえば、セッション35に次のクエリを入力します。

sys@DBS1> SELECT a.value curr_cached, p.value max_cached,
2         s.username, s.sid, s.serial#
3  FROM   v$sesstat a, v$statname b, v$session s, v$parameter2 p
4  WHERE  a.statistic# = b.statistic#  and s.sid=a.sid and a.sid=&sid
5  AND    p.name='session_cached_cursors'
6  AND    b.name = 'session cursor cache count';
Enter value for sid: 35
old   4: WHERE  a.statistic# = b.statistic#  and s.sid=a.sid and a.sid=&sid
new   4: WHERE  a.statistic# = b.statistic#  and s.sid=a.sid and a.sid=35

CURR_CACHED MAX_CACHED USERNAME   SID    SERIAL#
----------- ---------- -------- ----- ----------
49 50         APP         35        263

前の結果は、セッション35で現在キャッシュされているカーソルの数が最大値に近いことを示しています。

2. セッション・カーソル・キャッシュでカーソルを見つけた解析コールの割合を取得します。
たとえば、セッション35に次のクエリを入力します。

SQL> SELECT cach.value cache_hits, prs.value all_parses,
2         round((cach.value/prs.value)*100,2) as "% found in cache"
3  FROM   v$sesstat cach, v$sesstat prs, v$statname nm1, v$statname nm2
4  WHERE  cach.statistic# = nm1.statistic#
5  AND    nm1.name = 'session cursor cache hits'
6  AND    prs.statistic#=nm2.statistic#
7  AND    nm2.name= 'parse count (total)'
8  AND    cach.sid= &sid and prs.sid= cach.sid;
Enter value for sid: 35
old   8: AND    cach.sid= &sid and prs.sid= cach.sid
new   8: AND    cach.sid= 35 and prs.sid= cach.sid

CACHE_HITS ALL_PARSES % found in cache
---------- ---------- ----------------
34        700             4.57

前の結果は、セッション35のセッション・カーソル・キャッシュでのヒット数が、解析の合計数と比較して低いことを示しています。

3. 次の内容に当てはまる場合は、SESSION_CACHED_CURSORSを増やすことを検討してください。

- セッション・カーソル・キャッシュ数が最大値に近い。

- セッション・カーソル・キャッシュのヒットの割合が合計解析数と比較して低い。

- アプリケーションが同じ問合せに対して繰り返し解析コールを行っている。

この例では、SESSION_CACHED_CURSORSを100に設定すると、パフォーマンスが向上する可能性があります。

7.3.8 予約プールの構成

非常に大きいメモリーのリクエストは小さいチャンクに分割されますが、システムによっては、メモリーの連続チャンク(たとえば、5KB以上)を検索する必要性が依然存在する場合があります。(デフォルトの最小予約プールの割当ては4400バイトです。)

共有プールに十分な空き領域がない場合は、このリクエストを満たすための十分な空きメモリーを検索する必要があります。この操作では、検出可能期間にラッチ・リソースを保持するため、メモリー割当てで他の同時動作に対して多少の影響が生じる可能性があります。

したがって、共有プールに十分な領域がない場合、Oracle Databaseは使用できる共有プールに内部的に小さいメモリー領域を予約します。この予約プールによって、大きいチャンクの割当てがより効率的に行われます。

デフォルトでは、小さな予約プールを構成します。このメモリーは、PL/SQLおよびトリガーのコンパイルなどの操作や、Javaオブジェクトのロード時の一時領域に使用できます。予約プールから割り当てられたメモリーが解放されると、予約プールに戻ります。

予約されるデフォルトの領域量を変更する必要はほとんどありません。ただし、必要であれば、SHARED_POOL_RESERVED_SIZE初期化パラメータを設定して予約プール・サイズを変更できます。このパラメータは、極端に大きい割当て用の領域を共有プール内に確保します。

大きい割当ての場合、Oracle Databaseは次の順序で共有プールへの領域の割当てを試行します。

1. 共有プールの予約されていない部分。

2. 予約プール。共有プールの予約されていない部分に十分な領域がない場合は、予約プールに十分な領域があるかどうかチェックされます。

3. メモリー。共有プールの予約されていない部分と予約された部分に十分な領域がない場合は、Oracle Databaseは割当てのために十分なメモリーの解放を試みます。次に、共有プールの予約されていない部分と予約されている部分が再試行されます。

7.3.8.1 SHARED_POOL_RESERVED_SIZEの使用

SHARED_POOL_RESERVED_SIZEのデフォルト値はSHARED_POOL_SIZEの5%です。つまり、デフォルトでは、予約リストは構成されています。

SHARED_POOL_RESERVED_SIZEをSHARED_POOL_SIZEの半分を超える量に設定すると、Oracle Databaseはエラー信号を出します。予約プールにメモリーをあまり多くは予約できません。ただし、オペレーティング・システムのメモリー容量が共有プールのサイズを制約する場合があります。一般的には、SHARED_POOL_RESERVED_SIZEはSHARED_POOL_SIZEの10%に設定します。共有プールのチューニングを済ませている場合、ほとんどのシステムではこの値で十分です。この値を大きくすると、データベースは共有プールからメモリーを取り出します。(このため、それより小さい割当てに使用可能な予約されていない共有プールのメモリーの量が減少します。)

V$SHARED_POOL_RESERVEDビューの統計を使用すると、これらのパラメータをチューニングするのに役立ちます。SGAのサイズを大きくするための空きメモリーが豊富にあるシステムでは、REQUEST_MISSESの値を0(ゼロ)にすることが目標です。オペレーティング・システム・メモリーに制約があるシステムの場合は、REQUEST_FAILURESをなくすことが目標で、少なくともこの値が増加しないようにします。

これらの目標値が達成できない場合は、SHARED_POOL_RESERVED_SIZEの値を増やしてください。また、予約リストは共有プールから取られるため、SHARED_POOL_SIZEの値も同じだけ増やします。

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

7.3.8.2 SHARED_POOL_RESERVED_SIZEが小さすぎる場合

REQUEST_FAILURESの値がゼロよりも大きく、増加している場合は、予約プールが小さすぎます。SHARED_POOL_RESERVED_SIZEとSHARED_POOL_SIZEの値をそれぞれ増やすと、これを解決できます。これらのパラメータで選択する設定は、システムのSGAサイズの制約によって異なります。

SHARED_POOL_RESERVED_SIZEの値を増やすと、予約リストで利用可能なメモリーの容量が増えます。予約リストからメモリーを割り当てないユーザーには影響がありません。

7.3.8.3 SHARED_POOL_RESERVED_SIZEが大きすぎる場合

予約リストに割り当てられているメモリーが多すぎることがあります。次の場合です。

- REQUEST_MISSESがゼロの場合(または増加しない場合)

- FREE_SPACEの最小値がSHARED_POOL_RESERVED_SIZEの50%以上になる場合

これらの条件のどちらかが真の場合、SHARED_POOL_RESERVED_SIZEの値を減らします。

7.3.8.4 SHARED_POOL_SIZEが小さすぎる場合

V$SHARED_POOL_RESERVED固定ビューを使用すると、SHARED_POOL_SIZEの値が小さすぎる場合を示すこともできます。これはREQUEST_FAILURESがゼロより大きいかあるいは増加しているような場合です。

予約リストを使用可能にしている場合は、SHARED_POOL_RESERVED_SIZEの値を減らします。予約リストを使用可能にしていない場合は、SHARED_POOL_SIZEを増やします。

7.3.9 除去防止のためのラージ・オブジェクトの保存

エントリが共有プールにロードされた後は、それを移動することはできません。エントリがロードされ、除去されると、空きメモリーが断片化されることもあります。

共有プールを管理するには、PL/SQLパッケージDBMS_SHARED_POOLを使用します。共有SQL領域と共有PL/SQL領域は、古くなるとLRUアルゴリズムによって共有プールから除去されます(これはデータベース・バッファの場合と似ています)。パフォーマンスを改善したり、再解析が行われないようにするために、サイズの大きいSQL領域またはPL/SQL領域が古くなって共有プールから除去されないようにすることが可能です。

DBMS_SHARED_POOLパッケージを使用すると、オブジェクトが共有メモリー内に維持されるため、これらのオブジェクトは通常のLRUメカニズムによって除去されることはありません。DBMS_SHARED_POOLパッケージを使用し、SQL領域とPL/SQL領域をメモリーの断片化が発生する前にロードすると、データベースのオブジェクトはメモリー内に維持されます。この方法を使用すると、メモリーが確実に使用可能になり、SQL領域とPL/SQL領域の除去後にこれらの領域にアクセスする場合に、ユーザーのレスポンス時間中に突然原因不明のスローダウンが発生するのを防ぐことができます。

DBMS_SHARED_POOLパッケージは、次の場合に便利です。

- STANDARDやDIUTILパッケージなどの大きなPL/SQLオブジェクトをロードする場合
大きなPL/SQLオブジェクトがロードされる場合で、領域を確保するために小さなオブジェクトを共有プールから除去する必要がある場合は、ユーザーのレスポンス時間に影響が現れます。場合によっては、このような大きなオブジェクトをロードするには、メモリーが十分でないこともあります。

- 頻繁に実行されるトリガー
頻繁に使用する表のコンパイル済トリガーを共有プール内に維持できます。

- 順序
共有プールから順序が除去されると、順序番号が失われます。DBMS_SHARED_POOLは、共有プール内に順序を保持し、順序番号の消失を防ぎます。

DBMS_SHARED_POOLパッケージを使用してSQL領域またはPL/SQL領域を確保するには、次の手順を実行してください。

1. メモリー内に確保しておくパッケージまたはカーソルを決定します。

2. データベースを起動します。

3. DBMS_SHARED_POOL.KEEPをコールしてオブジェクトを確保します。
この手順により、保存されているオブジェクトがロードされる前にシステムの共有メモリーが使用し尽くされないことが保証されます。その結果、オブジェクトをインスタンスの早い時期に確保することにより、大きなメモリー領域を共有プールの中央に確保するために発生する可能性のある、メモリーの断片化を防ぐことができます。

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

7.3.10既存アプリケーションのカーソル共有

SQL解析の内容では、同一文とは、テキストが他のテキストと空白、大文字小文字の区別、コメントも含めて完全に同一である文を指します。類似文とは、いくつかのリテラル値以外が同一である文です。

解析フェーズでは、文のテキストを共有プールの文と比較して、その文を共有できるかどうかを判断します。初期化パラメータCURSOR_SHARING=EXACT(デフォルト)で、プール内の文が同じでない場合、データベースはSQL領域を共有しません。各文には、その文のリテラルに基づいた独自の親カーソルと独自の実行計画があります。

7.3.10.1 類似した文でSQL領域を共有する方法

SQL文がバインド変数よりもリテラルを使用する場合、CURSOR_SHARINGの非デフォルト設定によって、データベースはリテラルをシステム生成のバインド変数と置き換えることができます。この方法を使用して、データベースは共有SQL領域の親カーソルの数を減らせることがあります。

CURSOR_SHARINGが非デフォルト値に設定されている場合、データベースは解析中に次の手順を実行します。

1. 共有プールでの同一文の検索
同一文が見つかった場合、データベースは手順3にスキップします。そうでない場合は、データベースは次の手順に進みます。

2. 共有プールでの類似文の検索
類似文が見つからない場合は、データベースはハード解析を実行します。類似文が見つかった場合は、データベースは次の手順に進みます。

3. 続けて解析フェーズの残りの手順を行い、既存の文の実行計画が新しい文に適用できるか確認します。

計画を適用できない場合は、データベースはハード解析を実行します。計画が適用できる場合は、データベースは次の手順に進みます。

4. 文のSQL領域の共有

注意:
定数列番号をリテラルと解釈することは構文的に正しくないため、データベースはORDER BY句ではリテラル置換を行いません。ORDER BY句の列番号は問合せ計画と実行に影響するため、データベースは異なる列番号を持つ2つのカーソルを共有することはできません。

関連項目:
実行される各種チェックの詳細は、「SQL共有基準」を参照してください。

7.3.10.2 CURSOR_SHARINGを非デフォルト値に設定する場合

ベスト・プラクティスは、共有可能なSQLを書き込み、CURSOR_SHARINGにデフォルトのEXACTを使用することです。ただし、多くの類似文のあるアプリケーションでは、CURSOR_SHARINGの設定によりカーソル共有が大幅に改善されます。結果としてメモリー使用量が減少し、解析時間が削減され、ラッチの競合が減少します。共有プールの文がリテラルの値のみ異なる場合で、ライブラリ・キャッシュ・ミスの回数が非常に多いためにレスポンス時間が遅くなっている場合には、このアプローチを検討してください。

CURSOR_SHARINGをEXACTに設定してストアド・アウトラインを生成すると、データベースはリテラルを使用して生成されたストアド・アウトラインを使用しません。この問題を回避するには、CURSOR_SHARINGをFORCEに設定してアウトラインを生成し、CREATE_STORED_OUTLINESパラメータを使用します。

CURSOR_SHARINGをFORCEに設定すると、次のデメリットがあります。

- データベースは、共有プール内で類似文を検索するために、ソフト解析の間に追加作業を実行する必要があります。

- SELECT文にリテラルを含む選択された式の最大長(DESCRIBEからの戻り値)が増加します。ただし、戻されたデータの実際の長さは変わりません。

- スター型変換はサポートされません。

CURSOR_SHARINGをFORCEに設定するかどうかを判断するときには、各設定がパフォーマンスに与える影響を考慮してください。CURSOR_SHARINGをFORCEに設定すると、データベースは各個別のSQL文に1つの親カーソルと1つの子カーソルを使用します。データベースは同じ文の各実行に同じ計画を使用します。たとえば、次の文について検討します。

SELECT * FROM hr.employees WHERE employee_id = 101

FORCEを使用している場合、データベースはこの文をバインド変数を含むかのように最適化し、バインド照合を使用してカーディナリティを予測します。バインド変数のみが異なる文は、同じ実行計画を共有します。

注意:
Oracle Database 11gリリース2以上では、CURSOR_SHARINGの値をSIMILARに設定することは推奨されていません。かわりに、適応カーソルの共有を検討してください。

関連項目:

- 「適応カーソル共有」

- 問合せオプティマイザ機能の有効化

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

7.3.11 接続の維持

中間層を持つ大きなOLTPアプリケーションでは、データベース・リクエストごとに接続と切断を行うのではなく、接続を維持するようにします。永続的な接続を維持することで、ラッチなどのCPUリソースとデータベース・リソースが節約されます。

関連項目:
重要なオペレーティング・システム統計の説明は、「オペレーティング・システム統計」を参照してください。

7.4 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.4.1 ログ・バッファのサイズ設定

大量のデータを挿入、変更または削除するアプリケーションは、通常、デフォルトのログ・バッファ・サイズを変更する必要があります。ログ・バッファは総SGAサイズと比較すると小さく、中規模サイズのログ・バッファは、多数の更新を実行するシステムでのスループットを大幅に向上させます。

そのようなシステムにおける合理的な最初の見積りはデフォルト値に対するもので、次のとおりです。

MAX(0.5M, (128K * number of cpus))

ほとんどのシステムでは、ログ・バッファを1MBより大きくサイズ設定しても、パフォーマンスの利点が得られません。ログ・バッファ・サイズを増やしても、パフォーマンスまたはリカバリ能力に対してマイナスの影響を及ぼしません。単に追加のメモリーが使用されます。

7.4.2 ログ・バッファの統計

統計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待機イベントがインスタンスの待機時間における重要な要因でないことをチェックするためのものです。重要な要因でなければ、ログ・バッファ・サイズはほぼ適切です。

7.5 PGAメモリー管理

プログラム・グローバル領域(PGA)は、サーバー・プロセスのデータおよび制御情報を含むプライベート・メモリー領域です。この領域にアクセスできるのはサーバー・プロセスのみで、サーバー・プロセスのかわりとなるOracle Databaseコードでのみ読取りおよび書込みが行われます。そのような情報の例として、カーソルのランタイム領域があります。カーソルを実行するたびに、そのカーソルを実行するサーバー・プロセスのPGAメモリー領域内に、そのカーソルのための新しいランタイム領域が作成されます。

注意:
ランタイム領域の一部は、共有サーバーを使用するときにSGA内に配置できます。

複雑な問合せ(たとえば、意思決定支援の問合せ)の場合、ランタイム領域の大部分が、次のようなメモリー集約型演算子で割り当てられた作業領域に使用されます。

- ソート・ベース演算子(たとえば、ORDER BY、GROUP BY、ROLLUPおよびウィンドウ・ファンクション)

- ハッシュ結合

- ビットマップ・マージ

- ビットマップ作成

- 一括ロード操作で使用される書込みバッファ

ソート演算子は、作業領域(ソート領域)を使用して一連の行のメモリー内ソートを実行します。同様に、ハッシュ結合演算子は作業領域(ハッシュ領域)を使用して、ハッシュ表を左側から入力して作成します。

作業領域のサイズは、制御およびチューニングできます。一般に、作業領域を大きくすると、メモリー消費量は増えますが特定の演算子のパフォーマンスを大幅に向上できます。作業領域のサイズは、関連する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.5.1 自動PGAメモリーの構成

自動PGAメモリー管理モードで実行すると、すべてのセッションの作業領域のサイズ設定は自動になり、*_AREA_SIZEパラメータはそのモードで動作するすべてのセッションで無視されます。常に、インスタンスでアクティブな作業領域に使用できるPGAメモリーの総量は、PGA_AGGREGATE_TARGET初期化パラメータから自動的に導出されます。この量は、システムの他のコンポーネントで割り当てられたPGAメモリー(たとえば、セッションで割り当てられたPGAメモリー)の量をPGA_AGGREGATE_TARGETから減算した値に設定されます。次に、その結果のPGAメモリーは、それぞれ特定のメモリー要件に基づいて個々のアクティブな作業領域に割り当てられます。

自動PGAメモリー管理モードにおけるOracle Databaseの主な目標は、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. インスタンスで代表的なワークロードを実行し、収集されたPGA統計を使用してパフォーマンスを監視して、最大PGAサイズの構成が不十分(または大きすぎる)かを確認する。

3. Oracle PGAのアドバイスの統計を使用して、PGA_AGGREGATE_TARGETをチューニングする。

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

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

- PGA_AGGREGATE_TARGETの初期設定

- 自動PGAメモリー管理のパフォーマンスの監視

- PGA_AGGREGATE_TARGETのチューニング

7.5.1.1 PGA_AGGREGATE_TARGETの初期設定

Oracleデータベース・インスタンスに使用できる総メモリー量に基づいて、PGA_AGGREGATE_TARGET初期化パラメータの値(たとえば、100000KB、2500MB、50GBなど)を設定する必要があります。この値は後からインスタンス・レベルでチューニングしたり動的に変更できます。例7-2に一般的な状況を示します。

例7-2 PGA_AGGREGATE_TARGETの初期設定

Oracleデータベース・インスタンスが4GBの物理メモリーを持つシステム上で動作するように設定されていると仮定します。そのメモリーの一部は、オペレーティング・システムと同じハードウェア・システムで動作しているその他のOracle以外のアプリケーションに残しておく必要があります。たとえば、使用可能なメモリーの80% (3.2GB)のみをOracleデータベース・インスタンス専用にできます。

次に、残りのメモリーをSGAとPGAに分割する必要があります。

- OLTPシステムの場合、PGAメモリーの割合は使用可能なメモリーの総量の一部(例: 20%がPGA用、80%がSGA用)とするのが普通です。

- メモリー集中型の大きな問合せを実行するDSSシステムの場合、PGAメモリーには総量の最大70%(この例では最大2.2GB)までを使用できます。

PGA_AGGREGATE_TARGETパラメータの適切な初期値の例を次に示します。

- OLTPの場合: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 20%

- DSSの場合: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 50%
total_memはシステムで使用可能な物理メモリーの総量です。

この例では、4GBのtotal_memの値を使用することにより、PGA_AGGREGATE_TARGETをDSSシステムの場合は1600MBに、OLTPシステムの場合は655MBに初期設定できます。

7.5.1.2 自動PGAメモリー管理のパフォーマンスの監視

チューニング・プロセスを開始する前に、Oracle Databaseで収集される主要統計の監視および解釈方法を理解して、自動PGAメモリー管理コンポーネントのパフォーマンスを評価する場合の参考にする必要があります。そのための動的パフォーマンス・ビューの例を次に示します。

- V$PGASTAT

- V$PROCESS

- V$PROCESS_MEMORY

- V$SQL_WORKAREA_HISTOGRAM

- V$SQL_WORKAREA_ACTIVE

- V$SQL_WORKAREA

7.5.1.2.1 V$PGASTAT

このビューは、PGAメモリー使用量および自動PGAメモリー・マネージャに関するインスタンス・レベルの統計を示します。たとえば、次のようにします。

SELECT * FROM V$PGASTAT;

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

NAME                                                          VALUE UNIT
-------------------------------------------------------- ---------- ------------
aggregate PGA target parameter                             41156608 bytes
aggregate PGA auto target                                  21823488 bytes
global memory bound                                         2057216 bytes
total PGA inuse                                            16899072 bytes
total PGA allocated                                        35014656 bytes
maximum PGA allocated                                     136795136 bytes
total freeable PGA memory                                    524288 bytes
PGA memory freed back to OS                              1713242112 bytes
total PGA used for auto workareas                                 0 bytes
maximum PGA used for auto workareas                         2383872 bytes
total PGA used for manual workareas                               0 bytes
maximum PGA used for manual workareas                       8470528 bytes
over allocation count                                           291
bytes processed                                          2124600320 bytes
extra bytes read/written                                   39949312 bytes
cache hit percentage                                          98.15 percent

V$PGASTATに表示される主な統計は次のとおりです。

- aggregate PGA target parameter: これは初期化パラメータPGA_AGGREGATE_TARGETの現在の値です。デフォルト値は、SGAサイズの20%です。このパラメータを0(ゼロ)に設定すると、PGAメモリーの自動管理は無効になります。

- aggregate PGA auto target: 自動モードで実行する作業領域に使用できるPGAメモリーの量を示します。この量は、PGA_AGGREGATE_TARGETパラメータの値と現在の作業領域のワークロードから動的に導出されます。したがって、Oracleで継続的に調整されます。この値がPGA_AGGREGATE_TARGETと比べて小さい場合、多くのPGAメモリーがシステムの他のコンポーネント(たとえば、PL/SQLやJavaメモリー)で使用され、ソート作業領域にはメモリーがほとんど残されていません。自動モードで実行される作業領域には十分なPGAメモリーが残されている必要があります。

- global memory bound: AUTOモードで実行された作業領域の最大サイズを示します。この値は、作業領域のワークロードの現在の状態を反映するように継続的に調整されます。通常は、システム内のアクティブな作業領域の数が増えると、グローバル・メモリー・バウンドが縮小します。一般的には、グローバル・バウンドの値は1MBを下回らないようにする必要があります。1MB未満になった場合は、PGA_AGGREGATE_TARGETの値を増やす必要があります。

- 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 Databaseは初期化パラメータ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 Databaseによって計算され、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つであったことがこの値に反映されています。したがって、cache hit percentageはほぼ100%になりますが、それはこの1MB超の余分なパスがわずかなオーバーヘッドであるためです。ただし、大きなソートがワン・パスを実行するソートの場合、EBPは1MBではなく100MBとなり、cache hit percentageは50.73%に低下しますが、それはこの余分なパスがもたらす影響がずっと大きくなるためです。

7.5.1.2.2 V$PROCESS

このビューでは、インスタンスに接続されているOracleプロセス1つにつき行が1つあります。PGA_USED_MEM列、PGA_ALLOC_MEM列、PGA_FREEABLE_MEM列およびPGA_MAX_MEM列を使用して、これらのプロセスのPGAメモリー使用量を監視できます。たとえば、次のようにします。

SELECT PROGRAM, PGA_USED_MEM, PGA_ALLOC_MEM, PGA_FREEABLE_MEM, PGA_MAX_MEM
FROM V$PROCESS;

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

PROGRAM                                PGA_USED_MEM PGA_ALLOC_MEM PGA_FREEABLE_MEM PGA_MAX_MEM
-------------------------------------- ------------ ------------- ---------------- -----------
PSEUDO                                            0             0                0           0
oracle@examp1690 (PMON)                      314540        685860                0      685860
oracle@examp1690 (MMAN)                      313992        685860                0      685860
oracle@examp1690 (DBW0)                      696720       1063112                0     1063112
oracle@examp1690 (LGWR)                    10835108      22967940                0    22967940
oracle@examp1690 (CKPT)                      352716        710376                0      710376
oracle@examp1690 (SMON)                      541508        948004                0     1603364
oracle@examp1690 (RECO)                      323688        685860                0      816932
oracle@examp1690 (q001)                      233508        585128                0      585128
oracle@examp1690 (QMNC)                      314332        685860                0      685860
oracle@examp1690 (MMON)                      885756       1996548           393216     1996548
oracle@examp1690 (MMNL)                      315068        685860                0      685860
oracle@examp1690 (q000)                      330872        716200            65536      716200
oracle@examp1690 (TNS V1-V3)                 635768        928024                0     1255704
oracle@examp1690 (CJQ0)                      533476       1013540                0     1144612
oracle@examp1690 (TNS V1-V3)                 430648        812108                0      812108

7.5.1.2.3 V$PROCESS_MEMORY

このビューは、各Oracleプロセスの名前を付けられたコンポーネント・カテゴリごとに、動的PGAのメモリー使用量を表示します。このビューには、各Oracleプロセスに対して1行ずつ、6行まで(次のそれぞれに対して各1行)が含まれます。

- 名前を付けられた各コンポーネント・カテゴリ: Java、PL/SQL、OLAP、SQL

- 開放可能: オペレーティング・システムによって、特定のカテゴリにではなくプロセスに割り当てられたメモリー。

- その他: 名前を付けられたカテゴリの1つではなく、1つのカテゴリに割り当てられたメモリー。

列CATEGORY、ALLOCATED、USEDおよびMAX_ALLOCATEDを使用して、6つのカテゴリそれぞれのOracleプロセスのPGAメモリー使用量を動的に監視できます。

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

7.5.1.2.4 V$SQL_WORKAREA_HISTOGRAM

このビューには、インスタンス起動後に、最適なメモリー・サイズ、ワン・パス・メモリー・サイズおよびマルチ・パス・メモリー・サイズで実行された作業領域の総数を示します。このビューの統計は、作業領域の最適なメモリー要件によって定義されるバケットに副分割されます。各バケットは、列LOW_OPTIMAL_SIZEおよびHIGH_OPTIMAL_SIZEの値で指定された最適メモリー要件の範囲によって識別されます。

例7-3および例7-4に、V$SQL_WORKAREA_HISTOGRAMの2種類の使用方法を示します。

例7-4 V$SQL_WORKAREA_HISTOGRAMへの問合せ: 空でないバケット

最適に実行する(キャッシュされる)には3MBのメモリーを必要とするソート操作の事例を示します。このソートで使用される作業領域に関する統計は、LOW_OPTIMAL_SIZE = 2097152(2MB)およびHIGH_OPTIMAL_SIZE = 4194303(4MB - 1バイト)で定義されるバケットに配置されます。これは3MBが最適サイズの範囲内に収まるためです。統計は作業領域のサイズでセグメント化されます。最適、ワン・パスまたはマルチ・パスの各モードで作業領域を実行する場合のパフォーマンスの影響は、その作業領域のサイズに大きく依存するためです。

次の問合せでは、空でないすべてのバケットの統計が示されます。空のバケットは述語WHERE TOTAL_EXECUTION != 0で削除されます。

SELECT LOW_OPTIMAL_SIZE/1024 low_kb,
(HIGH_OPTIMAL_SIZE+1)/1024 high_kb,
OPTIMAL_EXECUTIONS, ONEPASS_EXECUTIONS, MULTIPASSES_EXECUTIONS
FROM V$SQL_WORKAREA_HISTOGRAM
WHERE TOTAL_EXECUTIONS != 0;

この問合せの結果を次に示します。

LOW_KB HIGH_KB OPTIMAL_EXECUTIONS ONEPASS_EXECUTIONS MULTIPASSES_EXECUTIONS
------ ------- ------------------ ------------------ ----------------------
8      16             156255                  0                      0
16      32                150                  0                      0
32      64                 89                  0                      0
64     128                 13                  0                      0
128     256                 60                  0                      0
256     512                  8                  0                      0
512    1024                657                  0                      0
1024    2048                551                 16                      0
2048    4096                538                 26                      0
4096    8192                243                 28                      0
8192   16384                137                 35                      0
16384   32768                 45                107                      0
32768   65536                  0                153                      0
65536  131072                  0                 73                      0
131072  262144                  0                 44                      0
262144  524288                  0                 22                      0

1024から2048KBのバケットでは、551の作業領域で最適な量のメモリーが使用されたこと、またワンパス・モードで実行されたものが16ある一方で、マルチ・パス・モードで実行されたものはなかったことがこの問合せ結果に示されています。また、1MB未満のすべての作業領域が最適モードで実行できたことも示されています。

例7-5 V$SQL_WORKAREA_HISTOGRAMへの問合せ: 最適パーセント

V$SQL_WORKAREA_HISTOGRAMを使用すると、起動後に作業領域が最適、ワン・パスまたはマルチ・パスの各モードで実行された回数の割合を調べることもできます。この問合せでは、一定のサイズ(最適メモリー要件が最低64KB)の作業領域のみ考慮されます。

SELECT optimal_count, round(optimal_count*100/total, 2) optimal_perc,
onepass_count, round(onepass_count*100/total, 2) onepass_perc,
multipass_count, round(multipass_count*100/total, 2) multipass_perc
FROM
(SELECT decode(sum(total_executions), 0, 1, sum(total_executions)) total,
sum(OPTIMAL_EXECUTIONS) optimal_count,
sum(ONEPASS_EXECUTIONS) onepass_count,
sum(MULTIPASSES_EXECUTIONS) multipass_count
FROM v$sql_workarea_histogram
WHERE low_optimal_size >= 64*1024);

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

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です。

7.5.1.2.5 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ビューから自動的に削除されます。

7.5.1.2.6 V$SQL_WORKAREA

実行計画が1つ以上の作業領域を使用するカーソルがロードされるたびに、累積された作業領域の統計がメンテナンスされます。作業領域が割当て解除されるたびに、V$SQL_WORKAREA表がその作業領域の実行統計で更新されます。

V$SQL_WORKAREAをV$SQLと結合して、作業領域をカーソルに関連付けることができます。V$SQL_PLANとも結合でき、計画のどの演算子が作業領域を使用しているかを正確に判断できます。

例7-7に、V$SQL_WORKAREA動的ビューでの代表的な問合せを3つ示します。

例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 DESC)
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 a10
col name format a20
SELECT operation, options, object_name name, trunc(bytes/1024/1024) "input(MB)",
trunc(last_memory_used/1024) last_mem,
trunc(estimated_optimal_size/1024) optimal_mem,
trunc(estimated_onepass_size/1024) onepass_mem,
decode(optimal_executions, null, null,
optimal_executions||'/'||onepass_executions||'/'||
multipasses_executions) "O/1/M"
FROM V$SQL_PLAN p, V$SQL_WORKAREA w
WHERE p.address=w.address(+)
AND p.hash_value=w.hash_value(+)
AND p.id=w.operation_id(+)
AND p.address='88BB460C'
AND p.hash_value=3738161960;

OPERATION    OPTIONS  NAME     input(MB) LAST_MEM OPTIMAL_ME ONEPASS_ME O/1/M
------------ -------- -------- --------- -------- ---------- ---------- ------
SELECT STATE
HASH         GROUP BY               4582        8         16         16 16/0/0
HASH JOIN    SEMI                   4582     5976       5194       2187 16/0/0
TABLE 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.5.1.3 PGA_AGGREGATE_TARGETのチューニング

初期化パラメータPGA_AGGREGATE_TARGETのチューニングを容易にするため、V$PGA_TARGET_ADVICEおよびV$PGA_TARGET_ADVICE_HISTOGRAMというビューが提供されています。これらのビューを調べれば、経験的な方法でPGA_AGGREGATE_TARGETの値をチューニングする必要がありません。このビューを使用すると、PGA_AGGREGATE_TARGETの値を変更したときに、主なPGA統計がどのような影響を受けるかを調べることができます。

どちらのビューでも、可能性のある高い値および低い値を評価するため、予測に使用するPGA_AGGREGATE_TARGETの値は、そのパラメータの現在の値の分数または倍数から導出されます。予測に使用される値の範囲は、10MBから最大256GBです。

Oracle Databaseでは、ワークロードの履歴を記録し、その履歴を様々なPGA_AGGREGATE_TARGET値でシミュレートすることによってPGAアドバイス・パフォーマンス・ビューを生成します。このシミュレーション・プロセスはバックグラウンドで実行され、ワークロードの履歴を継続的に更新してシミュレーション結果を生成します。その結果はV$PGA_TARGET_ADVICEまたはV$PGA_TARGET_ADVICE_HISTOGRAMを問い合せることによっていつでも表示できます。

PGAアドバイス・パフォーマンス・ビューの自動生成を有効化するには、次のパラメータが設定されていることを確認してください。

- PGA_AGGREGATE_TARGET。自動PGAメモリー管理が有効化されます(「PGA_AGGREGATE_TARGETの初期設定」を参照)。

- STATISTICS_LEVEL。TYPICAL(デフォルト)またはALLに設定します。このパラメータをBASICに設定すると、PGAパフォーマンス・アドバイス・ビューの生成がオフになります。

これらのPGAアドバイス・パフォーマンス・ビューの内容は、インスタンス起動時またはPGA_AGGREGATE_TARGETの変更時にリセットされます。

注意:
シミュレーションに実際の実行のすべての要因を含めることはできません。したがって、導出された統計が、実際のパフォーマンス統計に完全には一致しない場合があります。PGA_AGGREGATE_TARGETを変更した後は、常にシステムを監視して、新しいパフォーマンスが予測どおりであるかどうかを確認してください。

7.5.1.3.1 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
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に設定する必要があります。

注意:
PGAのcache hit percentageの理論的な最大値が100%の場合でも、作業領域の実際の最大サイズには制限があります。したがって、PGA_AGGREGATE_TARGETの値をさらに増やしても、理論的な最大値に達しない場合があります。これが発生するのは、最適メモリー要件が大きく、cache hit percentageの値が低いヒット率(90%など)に下がる可能性のある大規模DSSシステムのみです。

over allocationゾーンを超えると、PGAのcache hit percentageの値が急速に増加します。これは最適、またはワン・パスで実行される作業領域の数が増加し、マルチ・パス実行の数が減少するためです。この例では、500MB付近で曲線の変化が発生していますが、これはほとんどの(場合によってはすべての)作業領域が最適、または少なくともワン・パスで実行可能になるポイントに対応しています。その変化以降もcache hit percentageは緩やかに増加し、先細りが始まってPGA_AGGREGATE_TARGETの増加による上昇がわずかしか見られないポイントに達します。図7-3で、この状態はPGA_AGGREGATE_TARGETが3GBに達したときに発生しています。この時点のcache hit percentageは83%で、PGAメモリーを1GB増やしてもわずか(2%)しか向上しません。この例では、PGA_AGGREGATE_TARGETの最適値は3GBと考えられます。

PGA_AGGREGATE_TARGETは、最適値に設定するか、少なくともover allocationゾーンを超えた範囲で可能な最大値に設定するのが理想的です。一般的には、PGAのcache hit percentageは60%以上に設定します。60%の時点でシステムは、理想的な状況で実際に処理する必要のあるバイト数のほぼ2倍の量を処理するためです。この例では、PGA_AGGREGATE_TARGETを最低500MBから3GBにできるだけ近い値に設定するのが理想的です。ただし、PGA_AGGREGATE_TARGETパラメータの適切な設定は、PGAコンポーネントにどれだけのメモリーを使用できるかによって異なります。一般的に、PGAメモリーを追加する場合は、共有プールまたはバッファ・キャッシュの場合と同様に、一部のSGAコンポーネントのメモリーを減らす必要があります。これはOracleインスタンスに使用する全メモリーが、システムで使用できる物理メモリー量の制約を受ける場合があるためです。したがって、システム内で使用可能なメモリーと、様々なSGAコンポーネントのパフォーマンス(共有プールのアドバイザの統計およびバッファ・キャッシュ・アドバイザの統計で監視)という、より大きな視点で、PGAメモリーの増量の決定を下す必要があります。メモリーをSGAから取得できない場合は、コンピュータの物理メモリーの追加を検討します。

関連項目:
「共有プールのアドバイザ統計」および「バッファ・キャッシュのサイズ設定」

7.5.1.3.2 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に設定し、75%のcache hit percentageを受け入れます。

最後に、Oracle Databaseで収集される多くの統計がインスタンスの起動時から累積されるのと同様に、時間間隔の始めと終わりにおけるビューのスナップショットを取得できます。その時間間隔の予測値は次のように導出できます。

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 )

7.5.1.3.3 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                0
131072    262144                  0                 48                0
262144    524288                  0                 23                0

この出力は、PGA_AGGREGATE_TARGETを2倍ずつ増やしていくと、16MB未満のすべての作業領域を最適モードで実行できることを示しています。

関連項目:
『Oracle Databaseリファレンス』

7.5.1.4 V$SYSSTATおよびV$SESSTAT

V$SYSSTATビューとV$SESSTATビューの統計は、最適なメモリー・サイズ、ワン・パス・メモリー・サイズおよびマルチ・パス・メモリー・サイズで実行された作業領域の総数を示します。これらの統計は、インスタンスまたはセッションが開始された後から累積されます。

次の問合せは、インスタンスの開始後にこれらのモードで作業領域が実行された回数の総数とパーセンテージを示します。

SELECT name profile, cnt, decode(total, 0, 0, round(cnt*100/total)) percentage
FROM (SELECT name, value cnt, (sum(value) over ()) total
FROM V$SYSSTAT
WHERE name like 'workarea exec%');

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

PROFILE                                    CNT PERCENTAGE
----------------------------------- ---------- ----------
workarea executions - optimal             5395         95
workarea executions - onepass              284          5
workarea executions - multipass              0          0

7.5.2 OLAP_PAGE_POOL_SIZEの構成

OLAP_PAGE_POOL_SIZE初期化パラメータは、OLAPセッションに割り当てられているページング・キャッシュの最大サイズをバイト単位で指定します。

パフォーマンス上の理由のため、通常は、小さいOLAPページング・キャッシュを構成し、DB_CACHE_SIZEを使用して大きいデフォルト・バッファ・プールを設定することが望ましい対処です。4MBのOLAPページング・キャッシュが標準的で、そのうちの2MBはメモリーが制限されたシステムに使用されます。

関連項目:
『Oracle OLAPユーザーズ・ガイド』

7.6 サーバーおよびクライアントの結果キャッシュの管理

結果キャッシュはSGAまたはクライアント・アプリケーション・メモリー内のメモリー領域で、データベースの問合せまたは問合せブロックの結果を再利用するために格納します。キャッシュされた行は、失効しないかぎり文およびセッション間で共有されます。

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

- サーバーの結果キャッシュの管理

- クライアントの結果キャッシュの管理

- サーバーの結果キャッシュに使用するメモリーの管理

- 結果をキャッシュする問合せの指定

- 結果キャッシュの要件

- 結果キャッシュの情報へのアクセス

7.6.1 サーバーの結果キャッシュの管理

サーバーの結果キャッシュは共有プール内のメモリー・プールです。このプールには、SQL問合せの結果を格納するSQL問合せの結果キャッシュと、PL/SQLファンクションによって戻される値を格納するPL/SQLファンクションの結果キャッシュが含まれます。

OLAPアプリケーションは、サーバーの結果キャッシュの使用により多大なメリットを得ることができます。このメリットは、アプリケーションごとに大きく異なります。たとえばデータ・ウェアハウスのように、アクセスする行数が多く、戻す行数の少ない問合せはキャッシュの対象として適しています。たとえば、表を使用するかわりに、同値化を伴う拡張クエリー・リライトを使用して、結果キャッシュに問合せをマテリアライズするマテリアライズド・ビューを作成できます。

関連項目:

- サーバーの結果キャッシュの概要は、『Oracle Database概要』を参照してください。

- PL/SQLファンクションの結果キャッシュの使用方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 結果キャッシュおよび同値化を伴う拡張クエリー・リライトの使用例は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

7.6.1.1 サーバーの結果キャッシュの機能

問合せを実行すると、データベースはキャッシュ・メモリーを検索してその結果がキャッシュに存在するかどうかを判断します。結果が存在する場合、問合せを実行せずにメモリーから結果を取得します。結果がキャッシュされていない場合、データベースは問合せを実行して結果を出力として戻し、その結果を結果キャッシュに格納します。

ユーザーが問合せとファンクションを繰り返し実行する場合、データベースはキャッシュから行を取得するためレスポンス時間が短縮されます。依存するデータベース・オブジェクトのデータが変更された場合、キャッシュされた結果は無効になります。

例7-10ではhr.employeesに問合せを行い、RESULT_CACHEヒントを使用して、サーバー結果キャッシュの行を取得しています。例7-10には実行計画の一部が含まれており、手順1で結果がキャッシュから直接取得されることが示されています。Name列の値は、結果のキャッシュIDです。

例7-10 問合せでのRESULT_CACHEヒントの使用

SELECT   /*+ RESULT_CACHE */ department_id, AVG(salary)
FROM     hr.employees
GROUP BY department_id;
.
.
.
--------------------------------------------------------------
| Id | Operation          | Name                       |Rows
--------------------------------------------------------------
| 0 | SELECT STATEMENT    |                            | 11
| 1 |  RESULT CACHE       | 8fpza04gtwsfr6n595au15yj4y |
| 2 |   HASH GROUP BY     |                            | 11
| 3 |    TABLE ACCESS FULL| EMPLOYEES                  | 107
--------------------------------------------------------------

例7-11に示すように、問合せを実行した後、CACHE_IDの値が実行計画から取得したキャッシュIDと同値であるV$RESULT_CACHE_OBJECTSを問い合せることで、キャッシュされた結果に関する詳細な統計情報を取得できます。

例7-11 キャッシュされた結果の統計情報の問合せ

SELECT ID, TYPE, CREATION_TIMESTAMP, BLOCK_COUNT, COLUMN_COUNT,
PIN_COUNT, ROW_COUNT
FROM   V$RESULT_CACHE_OBJECTS
WHERE  CACHE_ID = '8fpza04gtwsfr6n595au15yj4y';
.
.
.
ID TYPE       CREATION_ BLOCK_COUNT COLUMN_COUNT  PIN_COUNT  ROW_COUNT
---------- ---------- --------- ----------- ------------ ---------- ----------
2 Result     06-MAR-09           1            2          0         12

例7-12では、WITH句のビュー内でRESULT_CACHEヒントを使用しています。この例に、実行計画の一部が示されています。手順3のRESULT CACHE操作では、summaryビューの結果がキャッシュから直接取得されることを示しています。

例7-12 WITH句のビューでのRESULT_CACHEヒントの使用

WITH summary AS
( SELECT /*+ RESULT_CACHE */ department_id, avg(salary) avg_sal
FROM   hr.employees
GROUP BY department_id )
SELECT d.*, avg_sal
FROM   hr.departments d, summary s
WHERE  d.department_id = s.department_id;
.
.
.
---------------------------------------------------------------------------------------------------
| Id  | Operation             | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                            |   11 |   517 |     7  (29)| 00:00:01 |
|*  1 |  HASH JOIN            |                            |   11 |   517 |     7  (29)| 00:00:01 |
|   2 |   VIEW                |                            |   11 |   286 |     4  (25)| 00:00:01 |
|   3 |    RESULT CACHE       | 8nknvkh64ctmz94a5muf2tyb8r |      |       |            |          |
|   4 |     HASH GROUP BY     |                            |   11 |    77 |     4  (25)| 00:00:01 |
|   5 |      TABLE ACCESS FULL| EMPLOYEES                  |  107 |   749 |     3   (0)| 00:00:01 |
|   6 |   TABLE ACCESS FULL   | DEPARTMENTS                |   27 |   567 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------

7.6.1.2 サーバーの結果キャッシュの初期化パラメータ

次のデータベース初期化パラメータにより、サーバーの結果キャッシュが制御されます。

- RESULT_CACHE_MAX_SIZE
このパラメータは、サーバーの結果キャッシュに割り当てられるメモリーを設定します。サーバーの結果キャッシュは、このパラメータを0(キャッシュは無効)に設定しないかぎり、使用可能です。

- RESULT_CACHE_MAX_RESULT
このパラメータは、単一の結果に使用できるサーバーの結果キャッシュ・メモリーの最大量を設定します。デフォルト値は5%ですが、1から100の任意のパーセント値を指定できます。このパラメータは、システム・レベルまたはセッション・レベルで設定できます。

- RESULT_CACHE_REMOTE_EXPIRATION
このパラメータは、サーバーの結果キャッシュ内で、リモート・データベース・オブジェクトに依存する結果の有効期限を指定します。デフォルト値は0分です。この場合、リモート・オブジェクトを使用する結果がキャッシュされないことを示します。

注意:
このパラメータに0以外の値を使用した場合、サーバーの結果キャッシュは、リモート・データベースに対するDMLでは無効化されません。

関連項目:
サーバーの結果キャッシュの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

7.6.1.3 サーバーの結果キャッシュに使用するメモリーの管理

サーバーの結果キャッシュに使用するメモリーを管理するには、データベース初期化パラメータを設定してDBMS_RESULT_CACHEパッケージを使用します。

7.6.1.3.1 初期化パラメータによるサーバーの結果キャッシュ・メモリーの管理

デフォルトでは、Oracle Databaseによってデータベースの起動時に共有プール内のサーバーの結果キャッシュにメモリーが割り当てられます。割り当てられるメモリー・サイズは、共有プールのメモリー・サイズとメモリー管理システムに応じて変化します。データベースでは次のアルゴリズムを使用します。

- MEMORY_TARGET初期化パラメータを使用してメモリー割当てを指定すると、MEMORY_TARGETの0.25%が結果キャッシュに割り当てられます。

- SGA_TARGET初期化パラメータを使用して共有プールのサイズを設定すると、SGA_TARGETの0.5%が結果キャッシュに割り当てられます。

- SHARED_POOL_SIZE初期化パラメータを使用して共有プールのサイズを指定すると、共有プールのサイズの1%が結果キャッシュに割り当てられます。

サーバーの結果キャッシュのサイズは、最大サイズに達するまで大きくなります。キャッシュ内の使用可能領域よりも大きな問合せ結果は、キャッシュされません。データベースはLRUアルゴリズムを使用してキャッシュ済の結果を除去しますが、除去しない場合、メモリーはサーバーの結果キャッシュから自動的に解放されません。DBMS_RESULT_CACHE.FLUSHプロシージャを使用してメモリーを消去できます。

結果キャッシュに割り当てられているメモリーを変更するには、RESULT_CACHE_MAX_SIZE初期化パラメータを設定します。Oracle RAC環境では、結果キャッシュ自体は各インスタンスに固有であり、インスタンスごとに個別にサイズ変更できます。ただし、無効化は、すべてのインスタンスにわたって機能します。クラスタ内のサーバー結果キャッシュを無効にするには、各インスタンスを起動する際に、このパラメータを0に明示的に設定する必要があります。

注意:
Oracle Databaseでは、サーバーの結果キャッシュに共有プールの75%を超える容量が割り当てられることはありません。

7.6.1.3.2 DBMS_RESULT_CACHEによるサーバーの結果キャッシュ・メモリーの管理

DBMS_RESULT_CACHEパッケージでは、サーバーの結果キャッシュのメモリー割当てを管理できる統計、情報および演算子が提供されます。DBMS_RESULT_CACHEパッケージを使用すると、キャッシュの回避、キャッシュ・メモリーの使用に関する統計の取得、キャッシュのフラッシュなどの操作を実行できます。

たとえば、結果キャッシュに使用するメモリー割当ての統計を参照するには、次のSQLプロシージャを使用します。

SQLSET SERVEROUTPUT ON
EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT

このコマンドの出力例を次に示します。

R e s u l t  C a c h e  M e m o r y  R e p o r t
[Parameters]
Block Size = 1024 bytes
Maximum Cache Size = 950272 bytes (928 blocks)
Maximum Result Size = 47104 bytes (46 blocks)
[Memory]
Total Memory = 46340 bytes [0.048% of the Shared Pool]
... Fixed Memory = 10696 bytes [0.011% of the Shared Pool]
... State Object Pool = 2852 bytes [0.003% of the Shared Pool]
... Cache Memory = 32792 bytes (32 blocks) [0.034% of the Shared Pool]
....... Unused Memory = 30 blocks
....... Used Memory = 2 blocks
........... Dependencies = 1 blocks
........... Results = 1 blocks
............... SQL = 1 blocks

PL/SQL procedure successfully completed.

既存のすべての結果を削除して結果キャッシュ・メモリーを消去するには、次のコマンドを使用します。

EXECUTE DBMS_RESULT_CACHE.FLUSH

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

7.6.2 クライアントの結果キャッシュの管理

Oracle Call Interface(OCI)クライアントの結果キャッシュは、OCIアプリケーションのSQL問合せの結果セットをキャッシュする、クライアント・プロセス内のメモリー領域です。クライアント・キャッシュは、各クライアント・プロセスに存在し、プロセス内のすべてのセッションによって共有されます。クライアントの結果キャッシュは、読取り専用またはほぼ読取り専用の表の問合せにお薦めします。

注意:
クライアントの結果キャッシュは、SGA内に存在するサーバーの結果キャッシュとは異なります。クライアントの結果キャッシュが使用可能な場合、クライアント、サーバー、またはその両方で問合せ結果セットをキャッシュできます。クライアントのキャッシュは、サーバーの結果キャッシュが無効の場合も使用できます。

OCCI、JDBC OCIドライバ、ODP.NETなどのOCIドライバは、クライアントの結果キャッシュをサポートします。クライアントの結果キャッシュにおけるパフォーマンスの利点は次のとおりです。

- 問合せのレスポンス時間の短縮
問合せが繰り返し実行される場合、アプリケーションは結果をクライアントのキャッシュ・メモリーから直接取得するため、問合せのレスポンス時間が短縮されます。

- データベース・リソースの使用効率の向上
サーバーのラウンドトリップが減少し、サーバーのCPUやI/Oなどのサーバー・リソースのパフォーマンスが大幅に節約されます。これらのリソースは他のタスクに解放されるため、サーバーのスケーラビリティが向上します。

- メモリー・コストの削減
キャッシュは、サーバー・メモリーよりも安価なクライアント・メモリーを使用します。

7.6.2.1 クライアントの結果キャッシュの機能

クライアントの結果キャッシュは、一番外側の問合せの結果(OCIアプリケーションで定義される列)を格納します。副問合せと問合せブロックはキャッシュされません。

図7-4は、データベースのログイン・セッションのクライアント・プロセスを示しています。このクライアント・プロセスにはクライアントの結果キャッシュが1つあり、これはクライアント・プロセスで実行中の複数のアプリケーション・セッション間で共有されます。最初のアプリケーション・セッションが問合せを実行すると、データベースから行が取得され、クライアントの結果キャッシュにキャッシュされます。その他のアプリケーション・セッションが同じ問合せを実行する場合も、行はクライアントの結果キャッシュから取得されます。

図7-4 クライアントの結果キャッシュ

クライアントの結果キャッシュは、セッション状態、またはセッション状態に影響を与えるデータベースの変更と一致するように結果セットを透過的に維持します。キャッシュされた結果の構築に使用するデータベース・オブジェクトのデータまたはメタデータがトランザクションによって変更される場合、データベースは、サーバーへの次のラウンドトリップ時にOCIクライアントに無効化を送信します。

関連項目:
クライアントの結果キャッシュの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

7.6.2.2 クライアントの結果キャッシュの初期化パラメータ

表7-4に、クライアントの結果キャッシュの有効化またはキャッシュの動作に影響を与えるデータベース初期化パラメータを示します。

表7-4 クライアントの結果キャッシュの初期化パラメータ

初期化パラメータ

説明

CLIENT_RESULT_CACHE_SIZE

クライアント・プロセスごとにクライアントの結果キャッシュの最大サイズを設定します。クライアントの結果キャッシュを使用可能にするには、サイズを32768バイト以上に設定します。これよりも少ない値(デフォルトの0など)を設定すると、クライアントの結果キャッシュは無効になります。

注意: CLIENT_RESULT_CACHE_SIZEの設定によってクライアントのキャッシュを無効にする場合、クライアント・ノードではクライアントのキャッシュを有効にできません。ただし、CLIENT_RESULT_CACHE_SIZEの設定によってクライアントのキャッシュを有効にすると、クライアント・ノードでその設定を上書きできます。たとえば、クライアント・ノードで、クライアントの結果キャッシュを無効にしたり、そのキャッシュ・サイズを増やしたりすることができます。

CLIENT_RESULT_CACHE_LAG

クライアントの結果キャッシュのタイム・ラグ長を指定します。OCIアプリケーションが一定期間データベース・コールを実行しない場合、クライアント・キャッシュ・ラグの設定によって、次の文の実行コールが検証のために確認されます。

OCIアプリケーションによるデータベースへのアクセス頻度が低い場合、このパラメータの値を小さくすると、クライアントの結果キャッシュとデータベースとの同期を維持する目的で、OCIクライアントからデータベースに対するラウンドトリップが増加します。クライアント・キャッシュ・ラグはミリ秒単位で指定します。デフォルト値は3000(3秒)です。

COMPATIBLE

互換性を維持しておくOracle Databaseのリリースを指定します。クライアントの結果キャッシュを使用可能にするには、このパラメータを11.0.0.0以上に設定する必要があります。クライアントのビューでのキャッシュの場合、このパラメータを11.2.0.0.0以上に設定する必要があります。

クライアントの結果キャッシュの場合、オプションのクライアント構成ファイルによって、サーバー・パラメータ・ファイルで設定したキャッシュ・パラメータが上書きされます。クライアントの結果キャッシュ・ラグは、データベース初期化パラメータでのみ設定できることに注意してください。

関連項目:

- クライアントの結果キャッシュの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- クライアント構成ファイルで設定可能なパラメータの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

7.6.3 結果をキャッシュする問合せの指定

サーバーまたはクライアントの結果キャッシュが使用可能な場合、どの問合せがキャッシュの対象となるかを制御できます。

7.6.3.1 結果キャッシュのモード

結果キャッシュ・モードは、どの問合せがクライアントおよびサーバーの結果キャッシュに結果セットを格納するのに適しているかを決定するデータベース設定です。Oracle Databaseでは、読取り専用またはほぼ読取り専用のデータベース・オブジェクトの問合せの結果をキャッシュすることをお薦めします。

RESULT_CACHE_MODE初期化パラメータでは、結果キャッシュの動作を決定します。表7-5に、この初期化パラメータの値を示します。

表7-5 RESULT_CACHE_MODE初期化パラメータの値

値

デフォルト

説明

MANUAL

はい

問合せヒントまたは表注釈を使用した場合のみ問合せの結果を結果キャッシュに格納できます。これは推奨値です。

FORCE

いいえ

すべての結果が結果キャッシュに格納されます。結果がキャッシュ内に存在しない場合、データベースは問合せを実行して結果をキャッシュに格納します。それ以降は、結果キャッシュ・ヒントを含め、同じ文が実行されると、キャッシュのデータが取得されます。

可能な場合、これらの結果がセッションで使用されます。キャッシュからの問合せ結果を除外するには、/*+ NO_RESULT_CACHE */問合せヒントを使用する必要があります。

注意: FORCEモードでは、データベースおよびクライアントがすべての問合せをキャッシュしようとして、パフォーマンスおよびラッチの著しいオーバーヘッドが生じるため、お薦めできません。さらに、確定的でないPL/SQLファンクションを呼び出す問合せもキャッシュされるため、そのように対象範囲が広い場合の結果キャッシュは、大幅に結果を変える原因になる可能性があります。

RESULT_CACHE_MODE初期化パラメータは、インスタンス(ALTER SYSTEM)、セッション(ALTER SESSION)またはサーバー・パラメータ・ファイルで設定できます。

問合せがキャッシュの対象である場合、アプリケーションは結果キャッシュを確認し、問合せ結果セットがキャッシュ内に存在するかどうかを調べます。存在する場合、結果キャッシュから結果を直接取得します。存在しない場合、データベースは問合せを実行して結果を出力として戻し、その結果を結果キャッシュに格納します。

結果キャッシュが有効化されている場合はデータベースでも、確定的ではないPL/SQLファンクションを呼び出す問合せがキャッシュされます。そのようなファンクションを呼び出すSELECT文をキャッシュする際、結果キャッシュは、PL/SQLファンクションおよびデータベース・オブジェクトに対するデータの依存性を追跡します。ただし、ファンクションが使用するデータが追跡されていない場合(順序、SYSDATE、SYS_CONTEXT、パッケージ変数など)、こうしたファンクションを呼び出す問合せで結果キャッシュを使用すると失効します。この点に関して、結果キャッシュの動作はPL/SQLファンクションのキャッシュと同一です。そのため、結果キャッシュを有効化する際は、パフォーマンスだけでなく、データの精度も常に考慮してください。

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

7.6.3.2 SQLの結果キャッシュ・ヒントの使用

結果キャッシュ・ヒントを使用すると、アプリケーション・レベルでキャッシュの動作を制御できます。SQLの結果キャッシュ・ヒントは、結果キャッシュのモードおよび表注釈よりも優先されます。

結果キャッシュ・モードがMANUALの場合、/*+ RESULT_CACHE */ヒントは、問合せブロックの結果をキャッシュに格納し、キャッシュされた結果を今後の実行で使用するようデータベースに指示します。例7-13では、sales表の問合せの行をキャッシュするようデータベースに指示します。

例7-13 RESULT_CACHEヒント

SELECT   /*+ RESULT_CACHE */ prod_id, SUM(amount_sold)
FROM     sales
GROUP BY prod_id
ORDER BY prod_id;

/*+ NO_RESULT_CACHE */ヒントは、データベースがサーバーまたはクライアントの結果キャッシュに結果をキャッシュしないように指示します。例7-14では、sales表の問合せの行をキャッシュしないように指示します。

例7-14 NO_RESULT_CACHEヒント

SELECT   /*+ NO_RESULT_CACHE */ prod_id, SUM(amount_sold)
FROM     sales
GROUP BY prod_id
ORDER BY prod_id;

7.6.3.2.1 問合せブロックのRESULT_CACHEヒント: 例

RESULT_CACHEヒントは、ヒントが指定された問合せブロックにのみ適用されます。ビューにのみヒントが指定されている場合は、その結果のみがキャッシュされます。次にビュー・キャッシュの特質を示します。

- ビューは、標準ビュー(CREATE ... VIEW文で作成されたビュー)、SELECT文のFROM句に指定されたインライン・ビュー、またはWITH句で作成されたインライン・ビューである必要があります。

- 外側の問合せブロックを参照する相関列を使用するビュー問合せの結果は、キャッシュできません。

- 問合せの結果は、クライアントの結果キャッシュではなく、サーバーの結果キャッシュに格納されます。

- キャッシュ・ビューは、外側の(または参照している)問合せブロックにマージされません。RESULT_CACHEヒントをインライン・ビューに追加すると、キャッシュ済結果の再利用性を最大化するために、外部問合せとインライン・ビュー間の最適化は無効化されます。

例7-15では、インライン・ビューview1の問合せを実行します。view1からのSELECTは外側のブロック、employeesからのSELECTは内側のブロックです。RESULT_CACHEヒントは内側のブロックにのみ指定されているため、外側の問合せの結果はキャッシュされません。内側の問合せの結果は、サーバーの結果キャッシュに保存されます。

例7-15 インライン・ビューに指定されたRESULT_CACHEヒント

SELECT *
FROM   ( SELECT /*+ RESULT_CACHE */ department_id, manager_id, count(*) count
FROM   hr.employees
GROUP BY department_id, manager_id ) view1
WHERE  department_id = 30;

同じセッションで、例7-16の文を実行する場合を考えます。この文は、view2の問合せを行います。WITH句の問合せブロックにのみRESULT_CACHEヒントが指定されているため、employeesの問合せ結果はキャッシュの対象となります。これらの結果は例7-15でキャッシュされているため、例7-16のWITH句のSELECT文では、キャッシュされた行を取得できます。

例7-16 WITHビューに指定されたRESULT_CACHEヒント

WITH view2 AS
( SELECT /*+ RESULT_CACHE */ department_id, manager_id, count(*) count
FROM hr.employees
GROUP BY department_id, manager_id )
SELECT *
FROM   view2
WHERE  count BETWEEN 1 and 5;

関連項目:
RESULT_CACHEヒントとNO_RESULT_CACHEヒントの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

7.6.3.3 結果キャッシュの表注釈の使用

表注釈を使用して、結果キャッシュを制御できます。表注釈は、問合せセグメントに対してではなく、問合せ全体にのみ有効です。これらの注釈の主な利点は、結果キャッシュ・ヒントをアプリケーション・レベルで問合せに追加する必要がないことです。

表注釈の優先順位は、SQLヒントよりも低くなります。そのため、表とセッションの設定を上書きするには、問合せレベルでヒントを使用します。RESULT_CACHEの表注釈に許可される値は次のとおりです。

- DEFAULT
問合せの1つ以上の表がDEFAULTに設定されている場合、RESULT_CACHE_MODE初期化パラメータをFORCEに設定するか、RESULT_CACHEヒントを指定しないかぎり、この問合せの結果キャッシュは表レベルでは有効になりません。これはデフォルト値です。

- FORCE
問合せのすべての表がFORCEに設定されている場合、問合せ結果はキャッシュ対象とみなされます。表注釈FORCEは、セッション・レベルで設定したRESULT_CACHE_MODEパラメータの値MANUALよりも優先されます。

例7-17は、結果キャッシュを無効にする表注釈を含むsales表の作成を示しています。この例では、salesの問合せの結果は、表注釈があるためにキャッシュの対象とみなされません。

例7-17 表注釈DEFAULT

CREATE TABLE sales (...) RESULT_CACHE (MODE DEFAULT);

SELECT   prod_id, SUM(amount_sold)
FROM     sales
GROUP BY prod_id
ORDER BY prod_id;

例7-18では、後からsales表の結果キャッシュを強制する場合を想定しています。この例には、salesの2つの問合せが含まれます。最初の問合せは使用頻度が高く数行を戻します。これは表注釈があるためキャッシュの対象となります。2番目の問合せは、1回かぎりの問合せで多くの行を戻します。この問合せではヒントを使用して、結果がキャッシュされないようにしています。

例7-18 表注釈FORCE

ALTER TABLE sales RESULT_CACHE (MODE FORCE);

SELECT   prod_id, SUM(amount_sold)
FROM     sales
GROUP BY prod_id
HAVING   prod_id=136;

SELECT   /*+ NO_RESULT_CACHE */ *
FROM     sales
ORDER BY time_id DESC;

関連項目:
CREATE TABLE構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

7.6.4 結果キャッシュの要件

結果キャッシュを使用可能にする場合、この設定では、クライアントまたはサーバーのキャッシュに特定の結果セットを含めることは保証されません。

7.6.4.1 結果キャッシュの読取り一貫性の要件

スナップショットを再利用可能にするには、スナップショットの読取り一貫性を維持する必要があります。結果セットがキャッシュの対象となるには、次のいずれかの要件が当てはまる必要があります。

- 結果の構築に使用される読取り一貫性スナップショットで、データの最新のコミット済状態を取得していること。

- 問合せが、フラッシュバック問合せを使用して明示的な時点を示していること。

現在のセッションで、問合せ内にアクティブなトランザクションの参照オブジェクトがある場合、この問合せの結果はキャッシュの対象となりません。

7.6.4.2 結果キャッシュのその他の要件

次のオブジェクトまたはファンクションが問合せ内にある場合、結果をキャッシュできません。

- 一時表およびSYSまたはSYSTEMスキーマ内の表

- 順序のCURRVALおよびNEXTVAL擬似列

- SQLファンクションCURRENT_DATE、CURRENT_TIMESTAMP、LOCAL_TIMESTAMP、USERENV/SYS_CONTEXT(非定数変数を含む)、SYS_GUID、SYSDATEおよびSYS_TIMESTAMP

クライアントの結果キャッシュには、その他にも結果をキャッシュする際の制限があります。詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

7.6.4.3 結果キャッシュの問合せパラメータの要件

キャッシュの結果は、問合せが等価であり、パラメータ値が同じである場合、変数の値とともにパラメータ化されていれば再利用できます。値やバインド変数の名前が異なる場合、キャッシュ・ミスが生じる場合があります。次のいずれかの要素が問合せで使用されている場合、結果はパラメータ化されます。

- バインド変数。

- SQLファンクションDBTIMEZONE、SESSIONTIMEZONE、USERENV/SYS_CONTEXT(定数変数を含む)、UIDおよびUSER。

- NLSパラメータ。

7.6.5 結果キャッシュの情報へのアクセス

データベースのビューと表に問合せを実行して、サーバーおよびクライアントの結果キャッシュに関する情報を取得できます。表7-6に、最も役に立つビューおよび表を示します。「説明」列では、適用可能な結果キャッシュを示しています。

表7-6 サーバーおよびクライアントの結果キャッシュに関連するビューと表

ビュー/表

説明

V$RESULT_CACHE_STATISTICS

サーバーの結果キャッシュの様々な設定とメモリー使用量の統計のリスト。

V$RESULT_CACHE_MEMORY

サーバーの結果キャッシュのすべてのメモリー・ブロックとそれに対応する統計のリスト。

V$RESULT_CACHE_OBJECTS

結果がその属性とともにサーバーの結果キャッシュ内にあるすべてのオブジェクトのリスト。

V$RESULT_CACHE_DEPENDENCY

サーバーのキャッシュ内の結果とこれらの結果の依存性間における依存関係の詳細のリスト。

CLIENT_RESULT_CACHE_STATS$

OCIクライアント・プロセスから取得されたクライアントの結果キャッシュのキャッシュ設定とメモリー使用量の統計を格納します。この統計表には、結果キャッシュを使用している各クライアント・プロセスのエントリがあります。クライアント・プロセスの終了後、エントリはこの表から削除されます。クライアント表には、V$RESULT_CACHE_STATISTICSに類似する情報がリストされます。

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

DBA_TABLES、USER_TABLES、ALL_TABLES

表の結果キャッシュ・モードの注釈を示すRESULT_CACHE列が含まれます。表に注釈が付いていない場合、この列にはDEFAULTが表示されます。この列は、サーバーとクライアントの両方の結果キャッシュに適用されます。

次のサンプル問合せは、サーバーの結果キャッシュ統計を監視します(サンプル出力が含まれる)。

COLUMN NAME FORMAT A20
SELECT NAME, VALUE
FROM   V$RESULT_CACHE_STATISTICS;

NAME                          VALUE
--------------------     ----------
Block Size (Bytes)             1024
Block Count Maximum            3136
Block Count Current              32
Result Size Maximum (Blocks)    156
Create Count Success              2
Create Count Failure              0
Find Count                        0
Invalidation Count                0
Delete Count Invalid              0
Delete Count Valid                0

次のサンプル問合せは、クライアントの結果キャッシュ統計を監視します(サンプル出力を含む)。

SELECT STAT_ID, SUBSTR(NAME,1,20), VALUE, CACHE_ID
FROM   CLIENT_RESULT_CACHE_STATS$
ORDER BY CACHE_ID, STAT_ID;

STAT_ID    NAME OF STATISTICS      VALUE   CACHE_ID
=======    ==================      =====   ========
1      Block Size               256         124
2      Block Count Max          256         124
3      Block Count Current      128         124
4      Hash Bucket Count       1024         124
5      Create Count Success      10         124
6      Create Count Failure       0         124
7      Find Count                12         124
8      Invalidation Count         8         124
9      Delete Count Invalid       0         124
10      Delete Count Valid         0         124

CLIENT_RESULT_CACHE_STATS$表には、クライアントの結果をキャッシュするアクティブな各クライアント・プロセスの統計エントリがあります。すべてのクライアント・プロセスには、一意のキャッシュIDがあります。クライアントのキャッシュを実行しているセッションのクライアント接続情報(たとえば、プロセスID)を取得するには、次の操作を実行します。

- CLIENT_RESULT_CACHE_STATS$(列名はCACHE_ID)に存在するCLIENT_REGIDのGV$SESSION_CONNECT_INFOからセッションIDを取得します。

- GV$SESSION_CONNECT_INFOおよびGV$SESSIONで関連する列を問い合せます。

クライアントとサーバーのどちらの結果キャッシュ統計の場合も、結果キャッシュが良好に使用されているデータベースでは、Create Count FailureおよびDelete Count Validの値が比較的小さく、Find Countの値が比較的大きくなります。

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

8 I/O構成および設計

I/Oサブシステムは、Oracleデータベースに不可欠なコンポーネントです。基本的なI/O概念を紹介し、データベースの様々な部分のI/O要件について説明し、I/Oサブシステムの設計のための構成例を示します。

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

- I/Oについて

- I/O構成

- データベース内部のI/O測定

- Oracle Orion測定ツールによるI/O測定

8.1 I/Oについて

Oracle Databaseでディスク上のデータを読み書きする際は、必ずディスクI/Oが生成されます。多くのソフトウェア・アプリケーションのパフォーマンスは、本質的にディスクI/Oによって制限されます。CPUタイムの大部分をI/Oアクティビティが完了するまでの待機に使用するアプリケーションはI/Oバウンドと呼ばれます。

Oracle Databaseは、適切に作成されたアプリケーションのパフォーマンスが、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設計計画を作成する場合は、Oracle Automatic Storage Management(Oracle ASM)の使用を検討します。Oracle ASMは、記憶域の管理を管理者に任せるのではなく、データベースで管理するという方針に基づいた、高いパフォーマンスを実現する統合データベース・ファイル・システムおよびディスク・マネージャです。

データベース・ファイル記憶域には、RAWデバイスやオペレーティング・システムのファイル・システムではなく、Oracle ASMを使用することをお薦めします。Oracle ASMの主な利点を次に示します。

- ストライプ化

- ミラー化

- オンラインでの記憶域の再構成と動的リバランス

- 管理対象ファイルの作成と削除

関連項目:
Oracle ASMの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

8.2 I/O構成

この項では、収集する基本情報およびシステムのI/O構成を定義するときの決定事項について説明します。必要な可用性、リカバリ能力およびパフォーマンスは維持しながら、できるだけ単純な構成を維持します。構成が複雑になるに従って、管理、メンテナンスおよびチューニングが困難になります。

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

- オペレーティング・システムまたはハードウェアのストライプ化を使用したファイルのレイアウト

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

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

- 3つの構成サンプル

- Oracle Managed Files

- データ・ブロック・サイズの選択

8.2.1 オペレーティング・システムまたはハードウェアのストライプ化を使用したファイルのレイアウト

オペレーティング・システムにLVMソフトウェアまたはハードウェア・ベースのストライプ化がある場合、これらのツールを使用してI/Oを分散できます。LVMまたはハードウェア・ストライプ化を使用するときの決定事項には、ストライプ深度およびストライプ幅が含まれます。

- ストライプ深度は、ストライプのサイズで、ストライプ単位とも呼ばれます。

- ストライプ幅は、ストライプ深度とストライプ・セットを構成するドライブ数の積です。

これらの値を適切に選択して、システムが必要なスループットを維持できるようにします。Oracleデータベースにおける適切なストライプ深度は、256KBから1MBです。ストライプ深度によって、得られるアプリケーションの利点の種類が異なります。最適なストライプ深度およびストライプ幅は、次の項目により異なります。

- リクエストされたI/Oサイズ

- I/Oリクエストの同時実行性

- 物理ストライプ境界とブロック・サイズ境界との位置合せ

- 提案されたシステムの管理性

8.2.1.1 リクエストされたI/Oサイズ

表8-1に、I/Oサイズの設定で使用できるOracle Databaseおよびオペレーティング・システムのパラメータを示します。

表8-1 Oracle Databaseおよびオペレーティング・システム操作パラメータ

パラメータ

説明

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サイズですが、プラットフォームごとに異なります。

SORT_AREA_SIZE

ソート操作のためのI/Oサイズおよび同時実行性を決定します。

HASH_AREA_SIZE

ハッシュ操作のためのI/Oサイズを決定します。

I/Oサイズの他に、同時実行性の程度も理想的なストライプ深度を調べる上で役立ちます。ストライプ幅およびストライプ深度を選択する場合は、次の点を考慮してください。

- 同時実行性の低い(順次)システムでは、単一I/Oが同じディスクに2回アクセスしないようにします。たとえば、ストライプ幅が4つのディスクで、ストライプ深度が32KBであると仮定します。1MBの単一I/Oリクエスト(たとえば、全表スキャンの場合)がOracleサーバー・プロセスで発行された場合、ストライプ内の各ディスクは要求されたデータを戻すために8回I/Oを実行する必要があります。このような状況を回避するために、平均I/Oのサイズは、ストライプ深度とストライプ幅の積より小さいサイズにしてください。そうでない場合は、オペレーティング・システムに対してOracle Databaseが単一I/Oリクエストを行うと、同じディスクに対して複数の物理I/Oリクエストが発生します。

- 同時実行性が高い(ランダム)システムでは、単一I/Oリクエストが複数の物理I/Oコールに分解されないようにしてください。そうでなければ、システムで実行される物理I/Oリクエスト数が何倍にもなり、I/Oレスポンス時間が大幅に下がります。

8.2.1.2 I/Oリクエストの同時実行性

従来のOLTP環境などの高度な小さい同時I/Oリクエストが存在するシステムでは、ストライプ深度を大きく保つことが有効です。I/Oサイズより大きいストライプ深度を使用することは粗密なストライプ化と呼ばれます。同時実行性の高いシステムのストライプ深度は次のようになります(n > 1)。

n * DB_BLOCK_SIZE

粗密なストライプ化ではアレイ内の1ディスクで複数のI/Oリクエストに対応できます。この方法では、一連のストライプ化ディスクで多数の同時I/Oリクエストに対応でき、I/Oセットアップ・コストも最小限で済みます。粗密なストライプ化は、全体的なI/Oスループットの最大化を目指します。ストライプ深度が大きく、1つのドライブからサービスできる場合、全表スキャンによるマルチブロック読取りにメリットをもたらします。データ・ウェアハウス環境のパラレル問合せも、粗密なストライプ化の候補です。これは、それぞれ個別のI/Oを発行する個々のプロセスが多数存在するためです。粗密なストライプ化は、同時リクエストが少ないシステムで使用されると、ホット・スポットが生成される可能性があります。

従来のDSS環境や同時実行性の低いOLTPシステムなどの大きいI/Oリクエストが少ないシステムでは、ストライプ深度を小さく保つことが有益です。これは、ファイングレイン・ストライプ化と呼ばれます。このようなシステムでは、ストライプ深度は次のようになります。nはマルチブロック読取りパラメータ(DB_FILE_MULTIBLOCK_READ_COUNT)よりも小さくなります。

n * DB_BLOCK_SIZE

ファイングレイン・ストライプ化では、複数のディスクで単一I/Oリクエストを処理できます。ファイングレイン・ストライプ化では、個々のI/Oリクエストまたはレスポンス時間のパフォーマンスが最大化されます。

8.2.1.3 物理ストライプ境界とブロック・サイズ境界との位置合せ

一部のOracle Databaseポートでは、データベース・ブロック境界がストライプと合わない可能性があります。ストライプ深度がデータベースのブロック・サイズと同じである場合、Oracle Databaseから発行される1つのI/Oによって、2つの物理I/O操作が生じる場合があります。

これは、OLTP環境では最適ではありません。1つの論理I/Oで物理I/Oが1つのみ発生する確率が高くなるようにするには、最小のストライプ深度がOracleブロック・サイズの少なくとも2倍である必要があります。表8-2に、ランダム・アクセスおよび順次読取りでお薦めする最小ストライプ深度を示します。

表8-2 最小ストライプ深度

ディスク・アクセス

最小ストライプ深度

ランダム読取りおよび書込み

最小ストライプ深度は、Oracleブロック・サイズの2倍です。

順次読取り

最小ストライプ深度は、Oracleブロック・サイズを乗算したDB_FILE_MULTIBLOCK_READ_COUNTの値の2倍です。

関連項目:
プラットフォームの固有のマニュアル

8.2.1.4 提案されたシステムの管理性

LVMの場合、最も管理の簡単な構成は、使用可能なすべてのディスク上に単一ストライプ化ボリュームを構成したものです。この場合、ストライプ幅はすべての使用可能なディスクを包含します。すべてのデータベース・ファイルはそのボリューム内に常駐し、効果的に負荷を均等分散します。この単一ボリューム・レイアウトは、ほとんどの状況で適切なパフォーマンスを実現します。

単一ボリューム構成は、RAID 1などの簡単なリカバリを可能にするRAID技術と併用する場合のみ有効です。それ以外の場合、単一のディスクを失うことはすべてのファイルを同時に失うことであり、完全なデータベースのリストアおよびリカバリを実行する必要があることを意味します。

パフォーマンスの他に、管理性の問題があります。システムの設計で、ディスクを簡単に追加できるようにして、データベースの拡張を可能にする必要があります。課題は、負荷のバランスを均一に維持しながら拡張を行うことです。

たとえば、初期構成で、64個の16GBのディスク上に単一ストライプ化ボリュームを作成する必要があるとします。これはプライマリ・データの1TBの合計ディスク領域になります。場合によっては、システムが動作した後に、将来のデータベース拡張を可能にするためにさらに80GB(すなわち、5つのディスク)を追加する必要があります。

この領域をデータベースで使用できるようにするオプションには、5つの新しいディスクを含む第2のボリュームの作成があります。ただし、これらの新しいディスクがその上に配置されたファイルに必要なI/Oスループットを保持できない場合、I/Oボトルネックが発生する可能性があります。

もう1つのオプションは、元のボリュームのサイズを増やすことです。LVMは高度になりつつあり、ストライプ幅の動的な再構成を可能にするので、システムがオンライン中にディスクを追加できます。このため、本番環境で単一ストライプ化ボリューム上にすべてのファイルを配置できるようになってきました。

LVMがストライプへのディスクの動的な追加をサポートできない場合は、より小さく管理しやすいストライプ幅を選択する必要があります。そのようにすると、新しいディスクを追加する場合、ストライプ幅だけシステムを拡張できます。

前述の例で、8個のディスクがより管理しやすいストライプ幅といえます。これは、8個のディスクで1秒間に必要な数のI/Oを維持できる場合のみ可能です。したがって、追加のディスク領域が必要なときは、別の8ディスク・ストライプを追加して、ボリューム間でI/Oのバランスを維持できます。

注意:
ストライプ幅が小さくなるほど、ボリューム上にファイルを分散する時間の必要性が高くなり、このプロシージャは手動によるI/Oの分散に近づきます。

8.2.2 手動によるI/Oの分散

システムにLVMまたはハードウェアのストライプ化がない場合、各ファイルのI/O要件に従ってファイルを分散することにより、使用可能なディスク間でI/Oを手動でバランス化する必要があります。ファイルの配置に関する決定を行うには、データベース・ファイルのI/O要件およびI/Oシステムの機能についてよく理解している必要があります。このようなデータに慣れておらず、解析対象の代表的なワークロードを取得できない場合は、まず推定を行い、次に使用量がわかったときにこのレイアウトをチューニングします。

ディスクを手動でストライプ化するには、ファイルの記憶域要件をI/O要件と関連付ける必要があります。

1. ファイルおよびディスクのサイズをチェックして、データベースのディスク記憶域要件を評価します。

2. 1ファイル当たりの予測I/Oスループットを識別します。最高のI/O率を持つファイルおよび多数のI/Oを持たないファイルを判断します。I/O率を均等にするために、すべての使用可能なディスク上にファイルをレイアウトします。

手動I/O分散の一般的なアプローチとして、頻繁に使用される表をその索引から分離することがあげられます。これは正しくありません。一連のトランザクション中は、索引が読み取られてから表が読み取られます。これらのI/Oは順次に発生するので、表と索引を同じディスク上に格納しても競合は発生しません。データファイルには索引や表データが含まれているため、これを単純に分離するだけでは十分ではありません。ファイルを分離する決定は、そのファイルのI/O率がデータベースのパフォーマンスに影響を与える場合にのみ行ってください。

8.2.3 ファイルを分割する場合

オペレーティング・システムのストライプ化または手動I/O分散を使用するかどうかに関係なく、I/OシステムまたはI/Oレイアウトが要求されたI/O率をサポートできない場合は、I/O率の高いファイルをそれ以外のファイルから分離する必要があります。このようなファイルは計画段階かシステムの本稼働後に確認できます。

ファイルを分離する決定は、I/O率、リカバリ能力の問題、管理性の問題によってのみ影響を受けます。(たとえば、LVMがストライプ幅の動的な再構成をサポートしない場合、同一構成の新しいストライプを作成するために一度にn個のディスクを追加できるように、さらに小さいストライプ幅を作成する必要がある場合があります。)

ファイルを分離する前に、ボトルネックが実際にI/Oの問題であるかどうかを検証します。ボトルネックの調査から生成されたデータでは、最高のI/O率を持つファイルを識別します。

後続の項では、次のファイル・タイプを分離する方法について説明します。

- 表、索引およびTEMP表領域

- REDOログ・ファイル

- アーカイブREDOログ

関連項目:
「高負荷SQLの識別」

8.2.3.1 表、索引およびTEMP表領域

表および索引を含む表領域に属するデータファイルがI/Oの多いファイルである場合は、これらのファイルのI/OをSQLのチューニングまたはアプリケーション・コードのいずれかで削減できるかどうかを識別します。

I/Oの多いファイルがTEMP表領域に属するデータファイルである場合は、このアクティビティを回避するためにディスク・ソートを実行するSQL文をチューニングするか、あるいはソートをチューニングするかを調べます。

不要なI/Oを回避するようにアプリケーションをチューニングした後、I/Oレイアウトが引き続き必要なスループットを維持できない場合は、I/Oの多いファイルの分離を考慮してください。

関連項目:
「高負荷SQLの識別」

8.2.3.2 REDOログ・ファイル

I/Oの多いファイルがREDOログ・ファイルである場合は、REDOログ・ファイルをその他のファイルから分離することを考慮してください。可能な構成には、次のことが含まれています。

- すべてのREDOログを、他のファイルのない1つのディスクに置きます。可用性も考慮します。すなわち、リカバリ可能性の目的で、同じグループのメンバーは異なる物理ディスクおよびコントローラ上にあることが必要です。

- 他のファイルを格納しない個別のディスク上に各REDOログ・グループを置きます。

- オペレーティング・システムのストライプ化ツールを使用して、複数のディスクにまたがってREDOログ・ファイルをストライプ化します。(この場合、手動ストライプ化は不可能です。)

- REDOログにRAID 5を使用しないでください。

REDOログ・ファイルは、ログ・ライター(LGWR)プロセスで順次書き込まれます。同じディスクに対する同時実行アクティビティが存在しない場合、この操作はさらに高速にできます。REDOログ・ファイルに別々の専用ディスクを割り当てると、さらにチューニングしなくても通常はLGWRが円滑に実行されます。システムが非同期I/Oをサポートせず、この機能が現在構成されていない場合、この機能を使用することが有効かどうかを確認します。LGWRに関連するパフォーマンス上のボトルネックはめったにありません。

8.2.3.3 アーカイブREDOログ

アーカイバが遅い場合、アーカイバ読取りとLGWR書込みが分離されるようにして、アーカイバ・プロセスとLGWRの間のI/O競合を防止することが賢明です。これは、ログを代替ドライブに置くことで達成されます。

たとえば、システムに4つのREDOログ・グループが存在し、各グループが2つのメンバーを持っているとします。個別ディスク・アクセスを作成するには、8つのログ・ファイルにそれぞれ1a、1b、2a、2b、3a、3b、4a、4bのラベルを付けてください。この場合、最低でも4つのディスクと、アーカイブ・ファイル用に1つのディスクが必要です。

図8-1は、競合を最小限にするために、ディスク間でREDOメンバーを分散する方法を示しています。

図8-1 ディスク間でのREDOメンバーの分散

この例では、LGWRはログ・グループ1(メンバー1aと1b)から切り替えられ、ログ・グループ2(2aと2b)に書込みを行います。同時に、アーカイバ・プロセスはグループ1から読取りをして、アーカイブ先に書込みを行います。REDOログ・ファイルがどのようにして競合から分離されているかに注意してください。

注意:
REDOログ・ファイルをミラー化する、すなわち各REDOログ・ファイルの複数のコピーを別々のディスク上に保持することで、LGWRが大幅に遅くはなりません。LGWRは、各ディスクに対して並列して書込みを行い、並列書込みの各部が完了するまで待機します。したがって、並列書込みが、最も長い単一のディスク書込みよりも長くなることはありません。

REDOログはシリアルに書き込まれるので、REDOログ・アクティビティ専用のドライブでは一般にヘッドの移動はわずかです。このため、ログ書込みのスピードが大幅に向上します。

8.2.4 3つの構成サンプル

この項では、I/Oシステムを構成する高水準の例を3つ示します。これらの例には、ディスク・トポロジやストライプ深度などを定義する計算例が含まれています。

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

- 異なるディスクへのアーカイブ・ログの移動

- 個別のディスクへのREDOログの移動

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

I/O構成の最も簡単なアプローチは、すべての使用可能ディスクにまたがってストライプ化された、1つの大きなボリュームを作成することです。リカバリ能力を考慮して、ボリュームがミラー化されます(RAID 1)。ディスク当たりのストライプ化の単位は、頻繁なI/O操作のための最大I/Oサイズより大きくする必要があります。そうすると、ほとんどの場合は十分なパフォーマンスが得られます。

8.2.4.2 異なるディスクへのアーカイブ・ログの移動

アーカイブREDOログ・ファイルが他のファイルと同じディスク・セット上でストライプ化されている場合、REDOログがアーカイブされる際、これらのディスク上のI/Oリクエストが影響を受ける可能性があります。個別のディスクにアーカイブREDOログ・ファイルを移動する場合の利点は次のとおりです。

- 非常に高速なアーカイブを実行できます(順次I/Oを使用)。

- アーカイブ先のディスク上でレスポンス時間が低下しても、その影響を受けるものは他にありません。

アーカイブ・ログ用のディスク数は、アーカイブ・ログ生成頻度およびアーカイブ記憶域の必要量により決定されます。

8.2.4.3 個別のディスクへのREDOログの移動

更新の多いOLTPシステムでは、REDOログは書込み中心です。他のディスクおよびアーカイブREDOログ・ファイルから分離されたディスクにREDOログ・ファイルを移動すると、次の利点があります。

- REDOログの書込みは、可能なかぎり高速で行われます。したがって、トランザクション処理のパフォーマンスは最高になります。

- REDOログの書込みが他のI/Oで損われることはありません。

REDOログ用のディスク数は、ほとんどの場合に、現行技術のディスク・サイズと比較して一般に小さいREDOログ・サイズで決定されます。一般に、2つのディスクを持つ構成(フォルト・トレランスのために4つのディスクにミラー化など)で十分です。特に、2つのディスク上でREDOログ・ファイルを交互に使用すると、1つのファイルにREDOログ情報を書き込む場合、アーカイブの完了したREDOログの読取りが妨げられません。

8.2.5 Oracle Managed Files

ファイル・システムにすべてのOracle Databaseデータを取り込むことができる場合、データベース管理はOracle Managed Filesを使用して簡単に行えます。表領域、一時ファイル、オンライン・ログおよび制御ファイルについては、Oracle Databaseは内部的に標準ファイル・システム・インタフェースを使用して、必要に応じてファイルを作成および削除します。管理者は、特定のタイプのファイルに使用するファイル・システム・ディレクトリのみを指定します。データファイルについてはデフォルトの場所を1つ、制御ファイルおよびオンラインREDOログ・ファイルについては複数の場所を最大5つ指定できます。

Oracle Databaseでは、一意のファイルが作成された後、そのファイルが不要になると削除されます。このため、管理者が誤ったファイルを指定したことにより発生する破損、および廃止されたファイルで消費される無駄なディスク領域が減り、テスト・データベースおよび開発データベースの作成が簡素化されます。また、オペレーティング・システム固有のファイル名をSQLスクリプトに設定する必要がないため、ポータブルなサード・パーティのツールの開発を容易にします。

新しいファイルはOracle Managed Filesとして作成できますが、古いファイルは古い方法で管理されます。したがって、データベースにはOracle Managed Filesとユーザー管理ファイルの両方を配置できます。

注意:
Oracle Managed Filesは、RAWデバイスでは使用できません。

Oracle Managed Filesをチューニングする場合はいくつかの点に注意する必要があります。

- Oracle Managed Filesではファイル・システムを使用する必要があるため、DBAはデータのレイアウト方法は管理しません。したがって、ファイル・システムを正しく構成することが重要です。

- Oracle Managed Filesのファイル・システムは、ストライプ化をサポートするLVM上に構築します。ロード・バランシングおよびスループットの向上のために、ファイル・システム内のディスクをストライプ化します。

- Oracle Managed Filesは、動的に拡張可能な論理ボリュームをサポートするLVM上で使用するときに最高の機能を発揮します。それ以外の場合は、論理ボリュームをできるだけ大きく構成します。

- Oracle Managed Filesは、ファイル・システムに大きな拡張可能なファイルがある場合、最高の機能を発揮します。

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

8.2.6 データ・ブロック・サイズの選択

8KBのブロック・サイズはほとんどのシステムにとって最適です。ただし、OLTPシステムではより小さなブロック・サイズを、DSSシステムではより大きなブロック・サイズを使用することがあります。この項では、最適なパフォーマンスを得るためにデータベース・ブロック・サイズを選択するときの考慮事項を説明します。内容は次のとおりです。

- 読取り

- 書込み

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

注意:
管理性の問題があるため、単一データベース・インスタンスでの複数のブロック・サイズの使用はお薦めしません。

8.2.6.1 読取り

データのサイズとは関係なく、目標は必要なデータを取り出すために必要な読取り回数を最小にすることです。

- 行が小さく、アクセスがきわめてランダムな場合は、小さなブロック・サイズを選択します。

- 行が小さく、アクセスがきわめて順次である場合は、大きなブロック・サイズを選択します。

- 行が小さく、アクセスがランダムかつ順次である場合は、大きなブロック・サイズを選択するのが有効です。

- 行が大きい(たとえば、ラージ・オブジェクト(LOB)データが含まれている)場合は、大きなブロック・サイズを選択します。

8.2.6.2 書込み

同時実行性の高いOLTPシステムで、大きなブロック・サイズを使用する場合は、INITRANS、MAXTRANSおよびFREELISTSの適切な値について検討します。これらのパラメータは、ブロック内で許可されている更新の同時実行性の程度に影響を与えます。ただし、自動セグメント領域管理を使用する場合は、FREELISTSの値を指定する必要はありません。

選択する必要があるブロック・サイズが不明な場合、多数のトランザクションを処理するシステムでは、8KBのデータベース・ブロック・サイズを試行してください。これは優れた妥協案であり、通常は有効です。8KBを超えるサイズが必要なのはLOBデータを処理するシステムのみです。

関連項目:
使用しているプラットフォームの最小および最大のブロック・サイズは、オペレーティング・システム固有のOracle Databaseインストール・マニュアルを参照してください。

8.2.6.3 ブロック・サイズの長所と短所

表8-3に、様々なブロック・サイズの長所と短所を示します。

表8-3 ブロック・サイズの長所と短所

ブロック・サイズ

長所

短所

小さい

行数が少なく大量のランダム・アクセスに適しています。

ブロック競合が低減されます。

メタデータ(すなわち、ブロック・ヘッダー)による比較的大きな領域のオーバーヘッドがあります。

行が大きい場合にはお薦めできません。1行がブロックに収まらない場合、1ブロック当たりの格納行数がわずかになったり、さらには行の連鎖が発生する可能性があります。

大きい

オーバーヘッドが少ないため、データを格納する空間が多くなります。

1回のI/Oでバッファ・キャッシュに複数の行を読み取れます(行サイズおよびブロック・サイズにより異なります)。

順次アクセスまたは非常に大きな行(LOBデータなど)に適しています。

ブロック・サイズが大きい場合に少数の行にランダム・アクセスすると、バッファ・キャッシュ内の領域が消費されます。たとえば、8KBのブロック・サイズと50バイトの行サイズでは、ランダム・アクセスを行うときにバッファ・キャッシュ内の7,950バイトが消費されます。

OLTP環境で使用される索引ブロックには適しません。これは、索引リーフ・ブロック上のブロック競合が増えるためです。

8.3 データベース内部のI/O測定

Oracle DatabaseのI/O測定機能では、ストレージ・サブシステムのパフォーマンスを評価し、I/Oパフォーマンス問題がデータベースとストレージ・サブシステムのどちらを原因とするかを判別できます。I/Oを連続的に発行する外部のI/O測定ツールとは異なり、Oracle DatabaseのI/O測定機能では、Oracleデータファイルを使用してI/Oをランダムに発行し、ストレージ・メディアにアクセスするため、よりデータベースの実際のパフォーマンスに近い結果を得ることができます。

この項では、Oracle DatabaseのI/O測定機能の使用方法について説明します。この項には、次の項目があります。

- I/O測定の前提条件

- I/O測定の実行

Oracle Databaseは、OrionによるI/O測定も提供しています。Orionは、Oracleのインストールやデータベースの作成を行わなくてもOracle databaseのパフォーマンスを予測できるツールです。他のI/O測定ツールとは異なり、Oracle Orionは、Oracleと同じI/Oソフトウェア・スタックを使用してOracleデータベースのI/Oワークロードをシミュレートするように特別に設計されたものです。またOrionは、Oracle Automatic Storage Managementによって実行されるストライプ化の効果もシミュレートすることができます。詳細は、「Oracle Orion測定ツールによるI/O測定」を参照してください。

8.3.1 I/O測定の前提条件

I/O測定を実行する前に、次の前提条件が満たされていることを確認してください。

- SYSDBA権限をユーザーに付与する必要があります。

- timed_statisticsがTRUEに設定されている必要があります。

- 非同期I/Oが有効化されている必要があります。
ファイル・システムを使用している場合、初期化パラメータFILESYSTEMIO_OPTIONSをSETALLに設定することで非同期I/Oを有効化できます。

- 次の問合せを実行し、データファイルに対して非同期I/Oが有効化されていることを確認してください。

COL NAME FORMAT A50
SELECT NAME,ASYNCH_IO FROM V$DATAFILE F,V$IOSTAT_FILE I
WHERE  F.FILE#=I.FILE_NO
AND    FILETYPE_NAME='Data File';

また、1つのデータベース・インスタンスに一度に実行できる測定は、1回のみです。

8.3.2 I/O測定の実行

Oracle DatabaseのI/O測定機能には、DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを使用してアクセスします。このプロシージャは、データベース・ファイルにI/O集中型の読取り専用ワークロード(1MBのランダムI/Oで構成されるワークロード)を発行し、ストレージ・サブシステムが耐えられる最大IOPS(1秒当たりのI/Oリクエスト)とMBPS(1秒当たりのI/OのMB)を判定します。

I/O測定は、次の2つの手順で行われます。

- I/O測定の最初の手順では、DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャにより、すべてのデータベース・インスタンスのすべてのデータファイルに対してデータベース・ブロック・サイズのランダムな読取り(デフォルトは8KB)を発行します。この手順では、出力パラメータmax_iopsに、データベースが維持できる最大IOPSが示されます。max_iopsの値は、OLTPデータベースに重要なメトリックです。出力パラメータactual_latencyには、このワークロードの平均待機時間が示されます。特定の目標待機時間が必要な場合は、入力パラメータmax_latencyを使用して目標待機時間を指定できます(データベース・ブロック・サイズのIOリクエストの最大許容待機時間をミリ秒単位で指定)。

- 2番目の測定の手順では、DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャにより、すべてのデータベース・インスタンスのすべてのデータファイルに対して1MBのランダムな読取りを発行します。2番目の手順では、出力パラメータmax_mbpsに、データベースが維持できるI/Oの最大MBPSが示されます。この手順は、データ・ウェアハウスに重要なメトリックを提供します。

ユーザーが入力パラメータnum_physical_disksを指定すると(データベース・ストレージ・システム内の物理ディスクの概数を指定)、より効率的に測定を実行できます。

I/Oワークロードの実行によりオーバーヘッドが発生するため、I/O測定はデータベースがアイドル状態のとき(つまりピーク時以外の時間)にのみ実行し、通常のデータベース・ワークロードに対するI/Oワークロードの影響を最小化する必要があります。

I/O測定を実行し、Oracle Databaseで使用されるストレージ・サブシステムのI/O性能を評価するには、次のようにDBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを使用します。

SET SERVEROUTPUT ON
DECLARE
lat  INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);

DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency  = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/

DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを実行する場合、次のことを考慮してください。

- 同じストレージ・サブシステムを使用するデータベースで一度に実行できる測定は1回のみです。同じストレージ・サブシステムを使用する別のデータベースで同時に測定を実行すると、測定は失敗します。

- インスタンスでのI/Oを最小化するため、データベースを停止します。

- Oracle Real Application Clusters(Oracle RAC)構成の場合、ノード間でストレージ・サブシステムを測定できるようすべてのインスタンスがオープン状態にあることを確認します。

- Oracle Real Application Clusters(Oracle RAC)データベースでは、ワークロードはすべてのインスタンスから同時に生成されます。

- 入力パラメータnum_physical_disksはオプションです。num_physical_disksパラメータにデータベースのストレージ・システム内にある物理ディスクの概数を設定すると、より高速かつ正確に測定できます。

- 場合によっては、非同期I/Oがデータファイルで許可されている一方で、非同期I/Oを発行するI/Oサブシステムが最大限度に達し、I/O測定を継続できなくなります。このような場合、ポート固有のドキュメントを参照して、システムの非同期I/Oの最大限度をチェックしてください。

I/O測定プロセス中は、いつでもV$IO_CALIBRATION_STATUSビューで測定ステータスを問い合せることができます。I/O測定が正常に完了したら、DBA_RSRC_IO_CALIBRATE表でその結果を参照できます。

関連項目:

- DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャの実行方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

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

8.4 Oracle Orion測定ツールによるI/O測定

この項では、Oracle Orion測定ツールについて説明します。この項には次の項目があります。

- Oracle Orion測定ツールの概要

- Orionの開始

- Orionの入力ファイル

- Orionのパラメータ

- Orionの出力ファイル

- Orionのトラブルシューティング

8.4.1 Oracle Orion測定ツールの概要

Oracle Orionは、Oracleのインストールやデータベースの作成を行わなくてもOracleデータベースのパフォーマンスを予測できるツールです。他のI/O測定ツールとは異なり、Oracle Orionは、Oracleと同じI/Oソフトウェア・スタックを使用してOracleデータベースのI/Oワークロードをシミュレートするように特別に設計されたものです。またOrionは、Oracle Automatic Storage Managementによって実行されるストライプ化の効果もシミュレートすることができます。

表8-4に、OrionがサポートするI/Oワークロードのタイプを示します。

Orionは、表8-4に示すワークロードの各タイプについて、様々なI/O負荷を使用してテストを実行し、MBPS、IOPS、およびI/O待機時間などのパフォーマンス・メトリックを測定できます。負荷は、未処理の非同期I/Oの数で表されます。内部的には、Orionソフトウェアはこの各負荷レベルに対して、できるだけ高速にI/Oリクエストを発行し続けてI/O負荷をそのレベルに保ちます。ランダム・ワークロードでは、大規模I/Oと小規模I/Oのどちらを使用する場合でも、負荷レベルは未処理I/Oの数です。大規模な順次ワークロードでは、負荷レベルは順次ストリームの数とストリーム当たりの未処理I/Oの数の組合せです。指定されたワークロードを一定範囲の負荷レベルでテストすると、負荷がパフォーマンスに与える影響を理解するのに役立ちます。

Orionを使用する際には、次の点に注意してください。

- Orionはストレージがアイドル状態(またはほぼアイドル状態)のときに実行してください。Orionは、生成したI/O負荷に基づいてストレージのパフォーマンスを測定するため、Orion以外のI/Oワークロードが同時に実行されていると、パフォーマンスを適切に評価できません。

- ストレージにすでにデータベースが作成されている場合は、別の方法としてPL/SQLルーチンdbms_resource_manager.calibrate_io()を使用してストレージを測定できます。

表8-4 OrionがサポートするI/Oワークロード

ワークロード

説明

小規模なランダムI/O

OLTPアプリケーションは通常、データベースのブロック・サイズと同じサイズ(通常は8KB)のランダム読取りおよびランダム書込みを生成します。このようなアプリケーションでは通常、1秒当たりのI/O(IOPS)で表すスループットと1リクエスト当たりの平均待機時間(I/O応答時間)が重要になります。これらのパラメータは、アプリケーション・レイヤーでトランザクション速度とトランザクション応答時間に変換されます。

Orionは、指定された読取りの書込みに対する割合、指定されたI/Oサイズ、そして指定された未処理I/Oの数を使用して、ランダムI/Oワークロードをシミュレートします。このOrionのワークロード・シミュレーションでは、I/Oはすべてのディスクに配分されます。

大規模な順次I/O

データ・ウェアハウス・アプリケーション、データのロード、バックアップ、およびリストアでは、複数の1MBの未処理I/Oからなる順次読取りおよび順次書込みのストリームが生成されます。このようなアプリケーションは、表全体やデータベース全体など、大量のデータを処理し、通常、1秒当たりのMB(MBPS)で表すデータ全体のスループットが重要になります。

Orionは、指定された数の順次読取りまたは順次書込みストリームを、指定されたI/Oサイズと指定された未処理I/O数でシミュレートできます。Orionは、順次ストリームのテスト時に、オプションでOracle Automatic Storage Managementのストライプ化をシミュレートできます。

大規模なランダムI/O

順次ストリームは通常、他のデータベース通信と同時にディスクにアクセスします。ストライプ化により、順次ストリームは多数のディスクに分散されます。結果として、ディスク・レベルでは、複数の順次ストリームが1MBのランダムI/Oとなります。

混合ワークロード

Orionは、2つの同時ワークロード(小規模なランダムI/Oと、大規模な順次I/Oか大規模なランダムI/Oのどちらか)をシミュレートできます。このワークロード・タイプにより、たとえば8KBのランダム読取りおよびランダム書込みのOLTPワークロードと、4つの1 MB I/Oの順次読取りストリームのバックアップ・ワークロードを一緒にシミュレートできます。

Orionの各データ・ポイントは、一定期間持続する小規模I/O負荷と大規模I/O負荷の特定の混合に対するテストです。Orionテストは複数のデータ・ポイント・テストからなります。これらのデータ・ポイント・テストは、2次元マトリックスとして表すことができます。マトリックスの各列は、同じ小規模I/O負荷によるデータ・ポイント・テストを表しますが、大規模I/O負荷は異なります。各行は、同じ大規模I/O負荷によるデータ・ポイント・テストを表しますが、小規模I/O負荷は異なります。Orionテストは、1つのポイント、1つの行、1つの列に対して、またはマトリックス全体に対して行うことができます。

8.4.1.1 Orionテストのターゲット

Orionを使用して、非同期I/Oをサポートするディスクベースのキャラクタ・デバイスをテストできます。Orionは次のターゲット・タイプについて検証済です。

- DAS(直接接続型)ストレージ: Orionを使用して、1つ以上のローカル・ディスク、ボリューム、またはローカル・ホスト上のファイルのパフォーマンスをテストできます。

- SAN(ストレージ・エリア・ネットワーク): Orionは、そのすべてまたは一部のSANストレージがキャラクタ・デバイスとしてマップされている任意のホストで実行できます。デバイスは、ストレージ・アレイによってエクスポートされたストライプ・ボリュームまたは非ストライプ・ボリューム、個々のディスク、または1つ以上のアレイ全体に相当します。

- NAS(ネットワーク接続ストレージ): Orionを使用して、NASストレージ上のデータファイルのパフォーマンスをテストできます。一般的には、NASストレージでのパフォーマンス結果は、データファイルの作成および更新に使用されたI/Oパターンによって異なります。そのため、Orionを実行する前にデータファイルを適切に初期化する必要があります。

8.4.1.2 Oracle管理者のためのOrion

Oracle管理者は、Orionを使用して、予測されるワークロードに基づいて、様々なストレージ・アレイを評価および比較することができます。またOracle管理者は、Orionを使用して、予測されるピーク・ワークロードに対して、ネットワーク接続、ストレージ・アレイ、ストレージ・アレイ・コントローラ、およびディスクの最適な数を判断できます。

8.4.2 Orionの開始

Orionの使用を開始するには、次のようにします。

1. Orion –testnameパラメータにより、使用するテスト名を選択します。このパラメータにより、Orionの実行に対して固有の識別子が指定されます。たとえば、テスト名「mytest」を使用します。詳細は、「Orionのパラメータ」を参照してください。

2. テスト名に基づいて、Orion入力ファイルを作成します。たとえば、mytest.lunという名前のファイルを作成します。入力ファイルに、テストするRAWボリュームまたはファイルをリストします。1行ごとに1つのボリューム名を追加します。.lunファイルにはコメントなど他のものは入力しないでください。
たとえば、Orion入力ファイルには次を含めることができます。

/dev/raw/raw1
/dev/raw/raw2
/dev/raw/raw3
/dev/raw/raw4
/dev/raw/raw5
/dev/raw/raw6
/dev/raw/raw7
/dev/raw/raw8

詳細は、「Orionの入力ファイル」を参照してください。

3. 入力ファイルで指定されたすべてのボリューム、たとえばmytest.lunが、コマンドddまたは他の同等のファイル表示ユーティリティを使用してアクセスできることを確認します。たとえば、一般的な健全性チェックでは、Linuxシステムで次のことを試してください。

$ dd if=/dev/raw/raw1 of=/dev/null bs=32k count=1024

プラットフォームによって、使用するファイル表示ユーティリティとそのインタフェースは異なる場合があります。

4. プラットフォームに非同期I/Oに必要なライブラリがインストールされていることを確認します。Orionテストは非同期I/Oに完全に依存しています。LinuxおよびSolarisでは、ライブラリlibaioが標準libディレクトリにあるか、またはシェル環境のライブラリパス変数(通常はシェルに応じてLD_LIBRARY_PATHまたはLIBPATH)を使用してこのライブラリにアクセスできることが必要です。Windowsには組込みの非同期I/Oライブラリがあるため、この問題は適用されません。

5. Orionでの最初のテストとして、–runにoltpまたはdssのどちらかのオプションを付けて使用します。データベースが主としてOLTPの場合は、–run oltpを使用します。データベースが主としてデータ・ウェアハウスまたは分析用の場合は、–run dssを使用します。
たとえば、デフォルトの入力ファイル名、orion.lunを使用してOLTPのようなワークロードを実行するには、次のコマンドを使用します。

$ ./orion -run oltp

Orionは、テストされるディスク・スピンドルの数(または–num_disksパラメータで指定された数)を考慮してI/O負荷レベルを生成します。スピンドルの数が入力ファイルで指定されたボリュームの数に関係するかどうかは、これらのボリュームがどのようにマップされているかによって異なることを覚えておいてください。

6. 「Orionの出力ファイル」の項に、Orionの出力ファイルを示す結果例を記載しています。手始めとしてサンプル・ファイルmytest_summary.txtを使用すると、入力パラメータの検証や出力の分析に役立ちます。サンプル・ファイルmytest_*.csvには、複数のI/Oパフォーマンス測定の値がカンマ区切りで含まれています。詳細は、「Orionの出力ファイル」を参照してください。

8.4.3 Orionの入力ファイル

Orion –testname <testname>パラメータを指定すると、Orionの入力および出力ファイル名にテスト名の接頭辞が設定されます。–testnameオプションのデフォルト値は「orion」です。

Orion入力ファイル、<testname>.lunには、改行で区切ったLUNのリストを含める必要があります。

8.4.4 Orionのパラメータ

I/Oワークロードのタイプや他のOrionオプションを指定するには、Orionコマンド・パラメータを使用します。

8.4.4.1 Orionに必要なパラメータ

Orionコマンドには–runパラメータが必要です。表8-5で–runパラメータについて説明します。

表8-5 必要なOrionパラメータ

オプション

説明

デフォルト

–run level

テスト実行レベルをlevelに指定します。このオプションは実行レベルを定義するもので、複雑なコマンドに高度なレベルを指定することができます。–run advancedを設定しないで、–cache_sizeと–verbose以外の他のパラメータを設定すると、結果はエラーになります。

advancedを除くすべての–run level設定は、あらかじめ指定されているパラメータ・セットを使用します。

levelには次のいずれかを指定します。

- oltp
小規模な(8K)ランダムI/Oで負荷を増加させて最大IOPSを特定するためのテストです。

このパラメータは、次のOrion呼び出しに相当します。

%> ./orion -run advanced \
-num_large 0 -size_small 8 -type rand \
-simulate concat -write 0 -duration 60 \
-matrix row

- dss
大規模な(1M)ランダムI/Oで負荷を増加させて最大スループットを特定するためのテストです。

このパラメータは、次のOrion呼び出しに相当します。

%> ./orion -run advanced \
-num_small 0 -size_large 1024 -type rand \
-simulate concat -write 0 -duration 60 \
-matrix column

- simple
一定範囲の負荷レベルでの小規模なランダムI/Oと大規模なランダムI/Oのワークロードを生成します。このオプションでは、小規模I/Oと大規模I/Oが個別にテストされます。この実行レベルで指定できるオプション・パラメータは、–cache_sizeと–verboseのみです。

このパラメータは、次のOrion呼び出しに相当します。

%> ./orion -run advanced \
-size_small 8 -size_large 1024 -type rand \
-simulate concat -write 0 -duration 60 \
-matrix basic

- normal
simpleと同じですが、一定範囲の負荷レベルでの小規模なランダムI/Oと大規模なランダムI/Oの組合せも生成されます。この実行レベルで指定できるオプション・パラメータは、–cache_sizeと–verboseのみです。

このパラメータは、次のOrion呼び出しに相当します。

%> ./orion -run advanced \
-size_small 8 -size_large 1024 -type rand \
-simulate concat -write 0 -duration 60 \
-matrix detailed

- advanced
オプション・パラメータで指定したワークロードをテストします。この実行レベルではどのオプション・パラメータでも指定できます。

normal

8.4.4.2 Orionのオプション・パラメータ

表8-5 Orionのオプション・パラメータ

オプション

説明

デフォルト

–cache_size num

ストレージ・アレイの読取りまたは書込みキャッシュのサイズ(MB)。大規模な順次I/Oワークロードでは、Orionは各データ・ポイントの前に大規模なランダムI/Oを行うことでキャッシュをウォーミングします。Orionはキャッシュ・サイズを使用して、このキャッシュ・ウォーミング操作の期間を決定します。0に設定すると、キャッシュ・ウォーミングは行われません。

このオプションを0に設定しない場合は、Orionは大規模な順次データ・ポイントごとに、その前に複数の未測定のランダムI/Oを発行します。これらのI/Oは、ストレージ・アレイのキャッシュ(存在する場合)をランダム・データで満たし、あるデータ・ポイントからのI/Oが次のデータ・ポイントのキャッシュ・ヒットにならないようにします。読取りテストではジャンク読取りを行い、書込みテストではジャンク書込みを行います。このキャッシュ・ウォーミングは、指定されると、I/Oのnum MBの読取りまたは書込みが終了するまで実行されます。

デフォルト値

指定しないと、ウォーミングはデフォルト時間(2分間)で実行されます。つまり、各データ・ポイントの前に、未測定のランダムI/Oを2分間発行します。

–duration num_seconds

各データ・ポイントをテストする時間を値num_secondsに秒単位で設定します。

デフォルト値: 60

–help

Orionのヘルプ情報を出力します。helpとともに設定されたその他のオプションはすべて無視されます。

–matrix type

一定範囲の負荷でテストする混合ワークロードのタイプ。Orionテストは複数のデータ・ポイント・テストからなります。データ・ポイント・テストは、2次元マトリックスとして表すことができます。

マトリックスの各列は、同じ小規模I/O負荷によるデータ・ポイント・テストを表しますが、大規模I/O負荷は異なります。各行は、同じ大規模I/O負荷によるデータ・ポイント・テストを表しますが、小規模I/O負荷は異なります。Orionテストは、次のマトリックスのtypeに応じて、1つのポイント、1つの列、1つの行に対して、またはマトリックス全体に対して行うことができます。

- basic: 混合ワークロードなし。小規模なランダム・ワークロードと、大規模なランダムまたは順次ワークロードは、個別にテストされます。小規模I/Oのみをテストし、次に大規模I/Oのみをテストします。

- detailed: 小規模なランダム・ワークロードと、大規模なランダムまたは順次ワークロードは、組み合せてテストされます。マトリックス全体をテストします。

- point: S 未処理の小規模なランダムI/OおよびL 未処理の大規模なランダムI/Oまたは順次ストリームによるデータポイント。Sは、–num_smallパラメータで設定されます。Lは、–num_largeパラメータで設定されます。–num_smallにより小規模I/Oを、–num_largeにより大規模I/Oをテストします。

- col: 大規模なランダムまたは順次ワークロードのみ。–num_small小規模I/Oを使用して、大規模I/Oの負荷を変化させてテストします。

- row: 小規模なランダム・ワークロードのみ。–num_large大規模I/Oを使用して、小規模I/Oの負荷を変化させてテストします。

- max: detailedと同じですが、パラメータ–num_smallと–num_largeで指定された最大負荷でのワークロードのみをテストします。–num_smallと–num_largeの制限値まで負荷を変化させてテストします。

デフォルト値: basic

–num_disks value

テストに使用する物理的なディスクの数を指定します。これを使用して負荷の範囲が生成されます。ディスク(物理的なスピンドル)の数を指定します。この数のvalueを使用して、Orionがテストする必要のある負荷の範囲を判断します。このパラメータを増やすと、Orionはより高いI/O負荷を使用します。

デフォルト値: <testname>.lun内のLUNの数

–num_large value

大規模I/O負荷を制御します。

注意: このオプションは、–matrixがrow、point、またはmaxに指定されている場合のみ適用されます。

–typeオプションがrandに設定されている場合は、パラメータ引数のvalueで未処理の大規模I/Oの数を指定します。

–typeオプションがseqに設定されている場合は、パラメータ引数のvalueで順次I/Oストリームの数を指定します。

デフォルト値: デフォルトなし

–num_small

小規模なランダムI/Oワークロードに対する未処理I/Oの最大数を指定します。

注意: このオプションは、–matrixがcol、point、またはmaxに指定されている場合のみ適用されます。

デフォルト値: デフォルトなし

–num_streamIO num

1ストリーム当たりの同時I/Oの数をnumに指定します。

注意: このパラメータは、–typeがseqの場合のみ使用されます。

デフォルト値: 4

–simulate type

大規模な順次I/Oワークロードのシミュレーションのためのデータ・レイアウト。Orionは、これらのいずれかの方法で指定されたLUNの組合せによって形成された仮想LUN上でテストします。typeには次のいずれかを指定します。

- concat: 仮想ボリュームは、指定されたLUNをシリアルにつなぐことによりシミュレートされます。この仮想ボリュームに対する順次テストは、あるポイントから各LUNの終わりまで行われ、続けて次のLUNの先頭から最後までというように続きます。

- raid0: 仮想ボリュームは、指定されたLUNをまたいでストライプ化してシミュレートされます。各順次ストリームは、raid0ストライプ化を使用してすべてのLUNをまたいでI/Oを発行します。ストライプ深度はデフォルトで1Mで、Oracle Automatic Storage Managementのストライプ深度に一致しています。これは–stripeパラメータを使用して変更できます。

I/Oのオフセットは、次のようにして決定されます。

小規模なランダム・ワークロードおよび大規模なランダム・ワークロードの場合:

- LUNは単一の仮想LUN(VLUN)に連結され、VLUN内でランダム・オフセットが選択されます。

大規模な順次ワークロードの場合:

- ストライプ化あり(–simulate raid0)。LUNを使用して単一のストライプ化されたVLUNが作成されます。小規模なランダム・ワークロードが同時にない場合は、順次ストリームはストライプ化されたVLUN内の固定のオフセットで開始されます。nストリームの場合、nが1でなければ、ストリームiはオフセットVLUNsize * (i + 1) / (n + 1)で開始されます。小規模なランダム・ワークロードが同時にある場合は、ストリームはストライプ化されたVLUN内のランダム・オフセットで開始されます。

- ストライプ化なし(–simulate CONCAT)。LUNは単一のVLUNに連結されます。ストリームは単一のVLUN内のランダム・オフセットで開始されます。

このパラメータは通常、–typeがseqの場合のみ使用されます。

デフォルト値: concat

–size_large num

大規模なランダムまたは順次I/OワークロードのI/Oのサイズ(KB)をnumに指定します。

デフォルト値: 1024

–size_small num

小規模なランダムI/OワークロードのI/Oのサイズ(KB)をnumに指定します。

デフォルト値: 8

–storax type

I/Oワークロードのテストに使用するAPI。

- skgfr: オペレーティング・システムI/Oレイヤーを使用します。

- oss: Exadataマシンのセル・サーバーでのI/OにOSS APIを使用します。

- asmlib: I/OにASMLIBディスク・デバイス・ベースのストレージAPIを使用します。

- odmlib: I/OにDirect NFSストレージ・ベースのAPIを使用します。

デフォルト値: skgfr

–testname tname

tnameにテスト実行の識別子を指定します。指定する場合は、LUNディスクを含む入力ファイルまたはファイル名を<tname>.lunという名前にする必要があります。

出力ファイルは、接頭辞<tname>_を付けた名前になります。

デフォルト値: orion

–type [rand | seq]

大規模I/Oワークロードのタイプ。

- rand: ランダムに分配された大規模I/O。

- seq: 順次ストリームの大規模I/O。

デフォルト値: rand

–verbose

ステータスとトレース情報を標準出力に出力します。

デフォルト値: オプションの設定なし

–write num_write

書込みI/Oの割合をnum_writeに指定します。残りは読取りI/Oになります。

このパラメータは大規模I/Oワークロードと小規模I/Oワークロードの両方に適用されます。大規模な順次I/Oの場合、各ストリームは読取り専用か書込み専用のどちらかです。そのため、パラメータは書込み専用のストリームの割合を指定します。ディスクに書き込まれるデータは不要データで、ディスク上の既存データとは無関係です。

注意: 書込みテストでは、指定されたLUN上のすべてのデータが消去されます。

デフォルト値: 0

注意:
書込みテストでは、指定されたLUN上のすべてのデータが消去されます。

8.4.4.3 Orionのコマンドライン例

次に様々なタイプのI/Oワークロードに対するOrionコマンドの例を示します。

1. OLTPデータベースのストレージを評価する場合:

-run oltp

2. データ・ウェアハウスのストレージを評価する場合:

-run dss

3. データの基本セット用:

-run normal

4. 読取り専用の小規模なランダムI/Oワークロードと大規模なランダムI/Oワークロードでのストレージ・パフォーマンスを理解する場合:

$ orion -run simple

5. 小規模なランダムI/Oワークロードと大規模なランダムI/Oワークロードの混合でのストレージ・パフォーマンスを理解する場合:

$ orion -run normal

6. 32KBと1MBの読取りの組合せをランダムな位置に生成する場合:

$ orion -run advanced -size_small 32 \
-size_large 1024 -type rand -matrix detailed

7. 複数の1MBの順次書込みストリームを生成して、1MB RAID0ストライプ化をシミュレートする場合:

$ orion -run advanced -simulate raid0 \
-stripe 1024 -write 100 -type seq -matrix col -num_small 0

8. 32KBと1MBの読取りの組合せをランダムな位置に生成する場合:

-run advanced -size_small 32 -size_large 1024 -type rand -matrix detailed

9. 複数の1MBの順次書込みストリームを生成して、RAID0ストライプ化をシミュレートする場合:

-run advanced -simulate raid0 -write 100 -type seq -matrix col -num_small 0

8.4.5 Orionの出力ファイル

テスト実行の出力ファイルには、接頭辞<testname>_<date>が付きます。ここでdateはyyyymmdd_hhmmです。

表8-7にOrionの出力ファイルを示します。

表8-7 Orionで生成される出力ファイル

出力ファイル

説明

<testname>_<date>_hist.csv

I/O待機時間のヒストグラム。

<testname>_<date>_iops.csv

小規模I/Oのパフォーマンス結果(IOPS)。

<testname>_<date>_lat.csv

小規模I/Oの待機時間(マイクロ秒)。

<testname>_<date>_mbps.csv

大規模I/Oのパフォーマンス結果(MBPS)。

<testname>_<date>_summary.txt

入力パラメータのサマリーが、小規模I/Oの最短待機時間(秒)、最大MBPS、および最大IOPSとともに表示されます。

<testname>_<date>_trace.txt

拡張された、未処理の出力。

注意:
書込みテストを実行する場合は、LUNに格納されたデータが失われることに注意してください。

8.4.5.1 Orionの出力ファイル例

Orionは、表8-7に示すように、複数の出力ファイルを作成します。「Orionの開始」の項で示した例「mytest」の場合、出力ファイルは次のようになります。

- mytest_summary.txt: このファイルには次が含まれます。

- 入力パラメータ

- 大規模なランダムまたは順次ワークロードで観測された最大スループット

- 小規模なランダム・ワークロードで観測された最大I/O率

- 小規模なランダム・ワークロードで観測された最大待機時間

- mytest_mbps.csv: 大規模なランダムまたは順次ワークロードのデータ転送速度(MBPS)結果を含むカンマ区切りのファイル。一般的には、このファイルと他のすべてのCSVファイルには、2次元の表が含まれます。表の各行は大規模なI/O負荷レベルに対応し、各列は特定の小規模なI/O負荷レベルに対応します。このため、列のヘッダーは未処理の小規模I/Oの数、行のヘッダーは未処理の大規模I/Oの数(大規模なランダムI/Oテストの場合)または順次ストリームの数(大規模な順次I/Oテストの場合)になります。
例8-1に、「mytest」に対するOrion MBPSのCSV出力ファイルのデータ・ポイントを先頭からいくつか示します。単純なmytestコマンドラインでは、大規模I/Oと小規模I/Oの組合せはテストされません。このため、MBPSファイルには未処理0の小規模I/Oに対応する1列のみが含まれます。例8-1では、8つの未処理の大規模な読取りと小規模I/Oなしの負荷レベルで、レポート・データは103.06 MBPSのスループットを示しています。

例8-1 Mytestのデータ・ポイント例

Large/Small,       0

1,   19.18
2,   37.59
4,   65.53
6,   87.03
8,  103.06
10,  109.67
. .   . . .
. .   . . .

図8-2に、様々な大規模I/O負荷レベルで測定されたデータ転送速度の例を示します。この図は、mytest_mbps.csvをスプレッドシートに読み込んでデータ・ポイントをグラフ化して生成できます。Orionはこのようなグラフを直接的には生成しません。X軸は未処理の大規模な読取りの数に対応し、Y軸は測定されたスループットに対応します。

図8-2に示すグラフは、標準的なストレージ・システムの動作を示しています。未処理のI/Oリクエストの数が増えるにつれて、スループットは上がります。ただし、特定のポイントでスループット・レベルは変化しなくなり、ストレージ・システムの最大スループット値であることを示します。

図8-2 I/O負荷レベルの例

- mytest_mbps.csv: 小規模なランダム・ワークロードのI/Oスループット(IOPS)結果を含むカンマ区切りのファイル。MBPSファイルと同様に、列のヘッダーは未処理の小規模I/Oの数、行のヘッダーは大規模なランダムI/Oのテストでは未処理の大規模I/Oの数、大規模な順次I/Oのテストでは順次ストリームの数です。
一般的には、CSVファイルには2次元の表が含まれます。ただし、大規模I/Oと小規模I/Oの組合せをテストしない単純なテストの場合は、結果ファイルは1行のみになります。このため、IOPSの結果ファイルは大規模I/Oを含まない1行のみになります。例8-2で示すように、12の未処理の小規模な読取りと大規模I/Oなしのデータ・ポイント例では、スループットは951 IOPSです。

例8-2 12の小規模な読取りと大規模な読取りなしのデータ・ポイント例

Large/Small,     1,     2,     3,     6,     9,    12 . . . .

0,             105,   208,   309,   569,   782,   951 . . . .

図8-3に示すグラフは、mytest_iops.csvをExcelに読み込んでデータをグラフ化して生成したもので、様々な小規模I/O負荷レベルで観測されたIOPSスループットを示しています。

図8-3は、標準的なストレージ・システムの動作を示しています。未処理のI/Oリクエストの数が増えるにつれて、スループットは上がります。ただし、特定のポイントでスループット・レベルは変化しなくなり、ストレージ・システムが最大スループット値に達したことを示します。スループット・レベルが上がるほど、I/Oリクエストの待機時間は大幅に増加します。そのため、このデータをmytest_lat.csvに生成された待機時間結果で提供される待機時間データとともに表示することが重要です。

図8-3 様々な小規模I/O負荷レベルでのI/Oスループット

- mytest_lat.csv: 小規模なランダム・ワークロードの待機時間結果を含むカンマ区切りのファイル。MBPSファイルやIOPSファイルと同様に、列のヘッダーは未処理の小規模I/Oの数、行のヘッダーは未処理の大規模I/Oの数(大規模なランダムI/Oをテストする場合)または順次ストリームの数です。
一般的には、CSVファイルには2次元の表が含まれます。ただし、大規模I/Oと小規模I/Oの組合せをテストしない単純なテストの場合は、結果ファイルは1行のみになります。このため、IOPSの結果ファイルは大規模I/Oを含まない1行のみになります。例8-3に示す例では、12の未処理の小規模な読取りと大規模I/Oなしの負荷レベルで、生成される結果は22.25ミリ秒のI/O応答待機時間を示しています。

例8-3 12の小規模な読取りと大規模な読取りなしのCSVファイル例

Large/Small, 1, 2, 3, 6, 9, 12 . . . .

0, 14.22, 14.69, 15.09, 16.98, 18.91, 21.25 . . . .

図8-4のグラフは、mytest_lat.csvをExcelに読み込んでデータをグラフ化して生成したもので、mytestの様々な小規模I/O負荷レベルでの小規模I/Oの待機時間を示しています。

図8-4 小規模I/O負荷レベルでの待機時間

- mytest_trace.txt: 拡張された、未処理のテスト出力を含みます。

注意:
Orionは、標準出力でのテスト中に発生したエラーを報告します。

8.4.6 Orionのトラブルシューティング

1. <testname>.lunファイルで指定した1つ以上のボリュームでI/Oエラーが発生する場合;

- ddなどのファイル・コピー・プログラムを使用して、テスト、読取り、または書込みと同じモードでボリュームにアクセスできることを確認してください。

- ホストのオペレーティング・システムのバージョンが非同期I/Oを行えることを確認してください。

- LinuxおよびSolarisでは、ライブラリlibaioが標準libディレクトリにあるか、またはシェル環境のライブラリ・パス変数(通常はシェルに対応してLD_LIBRARY_PATHまたはLIBPATH)を使用してこのライブラリにアクセスできることが必要です。

2. NASストレージで実行している場合:

- Orionを実行するには、ファイル・システムを正しくマウントする必要があります。詳細は、Oracleインストレーション・ガイドを参照してください(たとえば、Databaseインストレーション・ガイド for Linux x86のセクション、付録B「NASデバイスの使用」など)。

- mytest.lunファイルには既存のファイルの1つ以上のパスを含める必要があります。Orionはディレクトリやマウント・ポイントに対して機能することはありません。意味のあるテストにするには、ファイルは十分な大きさにする必要があります。このファイルのサイズは、データファイルの最終的な予測サイズ(つまり数年使用後のサイズ)にする必要があります。

- Linux(2.6カーネルを含む)のNFSで非同期I/Oを行うと、パフォーマンスが低下することがあります。

- 読取りテストを行っていて、初期化されていないかまだ書込みが行われていないファイルの未使用ブロックを読取りがヒットしている場合、高性能なNASシステムではゼロ設定されたブロックを返すことで読取りに見せかけることがあります。これが発生した場合は、予想外によいパフォーマンスになります。
これを回避するには、読込みテストを実行する前に、ddなどのツールを使用してすべてのブロックに書込みを行います。

3. OrionをWindowsで実行する場合: RAWパーティションでのテストでは、パーティションを一時的にドライブ文字にマップして、これらのドライブ文字をtest.lunファイルで指定する必要があります。

4. Orion 32ビットLinux/x86バイナリをx86_64システムで実行する場合: 32ビットlibaio.soファイルを、同じLinuxバージョンを実行している32ビットのコンピュータからコピーしてください。

5. 多数のディスク(num_disksが30を超える)を使用してテストする場合:

- 各データ・ポイントに長時間(120秒以上など)を指定するには、-durationオプションを使用してください(詳細はオプション・パラメータのセクションを参照)。Orionはすべてのスピンドルを特定の負荷レベルで実行を継続させようとするため、各データ・ポイントで立ち上げ時間が必要となり、これによってテストに要する時間が長くなることがあります。

- 期間の値を増やすように指示する次のエラー・メッセージが表示されることがあります。

Specify a longer -duration value.

おおよその目安として、期間はスピンドル数の2倍程度にするとよいようです。使用しているディスク技術によって、プラットフォームで必要とする時間は上下します。

6. Orionによって使用されるライブラリに関するエラーが発生した場合:

- Linux/Solaris: I/Oエラーのトラブルシューティングを参照してください。

- NT-Only: 配布に含まれているOracleライブラリの移動や削除は行わないでください。これらはorion.exeと同じディレクトリに置く必要があります。

7. 「信じられないほどよい」パフォーマンス数値になった場合:

- 大規模な読取りまたは書込みキャッシュがあるか、Orionプログラムとディスク・スピンドルの間のどこかでキャッシュの読取りと書込みを行っている場合があります。通常は、最も効果が高いのは、ストレージ・アレイ・コントローラです。このキャッシュのサイズを調べて、-cache_size advancedオプションを使用してそれをOrionに指定してください(詳細はオプション・パラメータのセクションを参照)。

- ボリュームの合計サイズが、これまでの1つ以上のキャッシュと比較して極端に小さい場合があります。キャッシュを無効にするようにしてください。ストレージを共有する他のボリュームが本番環境で著しいI/Oアクティビティを示す(そして結果的に共有キャッシュの大部分を使用する)場合には、これが必要になります。

8. Orionが長い予測実行時間を報告している場合:

- -num_disksが高いときに実行時間は長くなります。Orionは内部的に線形計算式を使用して、指定された数のディスクを維持するためにかかる時間を特定します。

- -cache_sizeパラメータは、指定していない場合でも、実行時間に影響します。Orionはデフォルトでデータ・ポイントごとに2分間のキャッシュ・ウォーミングを行います。キャッシュを無効にする場合は、-cache_size 0を指定します。

- -durationに大きい値を指定すると、予想通り、実行時間は長くなります。

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

この章では、Oracle Databseのパフォーマンスを最適化するためのオペレーティング・システムのチューニング方法について説明します。

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

- オペレーティング・システムのパフォーマンスの問題について

- オペレーティング・システムの問題の解決

- CPUについて

- CPUの問題の解決

関連項目:

- オペレーティング・システム統計情報の重要性の詳細は、「オペレーティング・システム統計」を参照してください。

- オペレーティング・システムのマニュアル

- 各プラットフォームのチューニング情報が記載された特定プラットフォームのOracle Databaseマニュアル

9.1 オペレーティング・システムのパフォーマンスの問題について

オペレーティング・システムのパフォーマンスの問題は、一般にプロセス管理、メモリー管理およびスケジューリングに関係します。Oracleデータベース・インスタンスをチューニングした後で、さらにパフォーマンスを改善する必要がある場合は、作業内容の確認またはシステム時間の短縮を試みてください。I/O帯域幅、CPU能力およびスワップ・スペースが十分にあることを確認してください。ただし、オペレーティング・システムをさらにチューニングしても、それがアプリケーションのパフォーマンスに大きな効果を与えることは期待できません。オペレーティング・システムの簡単なチューニングよりも、Oracle Database構成またはアプリケーションでの変更の方が、オペレーティング・システム効率に大きな差異が生じます。

たとえば、アプリケーションでbuffer busy waitsが非常に頻繁に発生する場合は、システム・コールの回数が増加します。アプリケーションをチューニングすることでbuffer busy waitsを削減すると、システム・コールの数が減少します。

この項では、オペレーティング・システムのパフォーマンスの問題に関する次の項目について説明します。

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

- メモリー使用量

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

9.1.1 オペレーティング・システムのキャッシュの使用

オペレーティング・システムおよびデバイス・コントローラには、Oracle Databaseのキャッシュ管理と直接に競合しないデータ・キャッシュがあります。ただし、これらの構造はリソースを消費し、パフォーマンスにおける利点はほとんどありません。この状況は、LinuxまたはUNIXファイル・システムに格納されたデータベース・ファイルにおいて最も顕著です。デフォルトでは、データベースのすべてのI/Oはファイル・システム・キャッシュを使用します。

一部のLinuxおよびUNIXシステムでは、直接I/Oのファイルストアを使用できます。この場合、ファイル・システム・キャッシュをバイパスして、ファイル・システム内でデータベース・ファイルにアクセスできます。直接I/OによるCPUリソースの節約によって、ファイル・システム・キャッシュをプログラム・テキストやスプール・ファイルなどの非データベース・アクティビティ専用にすることができます。

注意:
この問題はWindowsでは発生しません。データベースから要求されたファイルは、すべてファイル・システム内のキャッシュをバイパスします。

Oracle Databaseバッファ・キャッシュにブロックが格納されるため、多くの場合、オペレーティング・システムのキャッシュは冗長な機能ですが、場合によっては、データベース・バッファ・キャッシュが使用されない場合もあります。この場合、直接I/OまたはRAWデバイスを使用すると、オペレーティング・システム・バッファを使用する場合よりも、パフォーマンスがさらに低下することがあります。これには次のような例があります。

- TEMP表領域での読取りまたは書込み

- NOCACHE LOBに格納されるデータ

- パラレル問合せスレーブで読み取られるデータ

注意:
パラレル問合せのデータは、ディスクからPGAに直接読み込むかわりに、データベース・バッファ・キャッシュにキャッシュできる場合があります。この構成は、データベース・サーバーのメモリー容量が大きい場合に適しています。パラレル実行の使用の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

キャッシュを使用する場合でも、オペレーティング・システム・レベルですべてのファイルをキャッシュするのは望ましくない場合があります。

9.1.1.1 非同期I/O

同期I/Oでは、I/Oリクエストがオペレーティング・システムに発行されても、書込みの完了が確認されないかぎり書込みプロセスによってブロックされます。処理はその後で継続できます。非同期I/Oでは、I/Oリクエストが発行されて処理されている間も処理が継続されます。ボトルネックを回避できる場合は非同期I/Oを使用します。

プラットフォームには、デフォルトで非同期I/Oをサポートしているもの、特殊な構成が必要なもの、基礎となる一定のファイル・システム・タイプでのみ非同期I/Oをサポートしているものがあります。

9.1.1.2 FILESYSTEMIO_OPTIONS初期化パラメータ

FILESYSTEMIO_OPTIONS初期化パラメータを使用して、ファイル・システムのファイルについて非同期I/Oあるいは直接I/Oを、有効化または無効化することができます。このパラメータは、プラットフォーム固有であり、それぞれのプラットフォームに最適なデフォルト値が設定されています。

FILESYTEMIO_OPTIONSは、次のいずれかの値に設定できます。

- ASYNCH: ファイル・システム・ファイル上の非同期I/Oを有効にします。非同期I/Oでは、転送に対する時間的な要件はありません。

- DIRECTIO: ファイル・システム・ファイル上の直接I/Oを有効にします。直接I/Oでは、バッファ・キャッシュがバイパスされます。

- SETALL: ファイル・システム・ファイル上の非同期および直接I/Oを有効にします。

- NONE: ファイル・システム・ファイル上の非同期および直接I/Oを無効にします。

関連項目:
詳細は使用しているプラットフォーム固有のマニュアルを参照してください。

9.1.1.3 NFSサーバー環境における非同期I/Oの制限

一部のNFSサーバー環境では、短期間に大量の非同期I/Oリクエストが作成されると、パフォーマンスが低下する場合があります。そのような場合には、DNFS_BATCH_SIZE初期化パラメータを使用してパフォーマンスを改善し、Oracleプロセスから発行されるI/O数を制限して、システムの安定性を高めます。

DNFS_BATCH_SIZE初期化パラメータは、Direct NFSが有効化されている場合に、Oracleフォアグラウンド・プロセスによってキューに入れることが可能な非同期I/Oの数を制御します。NFSサーバーで未処理の非同期I/Oリクエストを大量に処理できない環境では、このパラメータの値を128に設定することをお薦めします。その後、NFSサーバーのパフォーマンスに応じて、この値を増減できます。

注意:
DNFS_BATCH_SIZE初期化パラメータのデフォルト設定は4096です。推奨値の128を適用できるのは、NFSサーバーで大量の非同期I/Oリクエストを処理できず、サーバー遅延が検出されるシステムのみです。

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

9.1.2 メモリー使用量

メモリー使用量は、バッファ・キャッシュの制限と初期化パラメータの両方の影響を受けます。

9.1.2.1 バッファ・キャッシュの制限

UNIXバッファ・キャッシュはオペレーティング・システムのメモリー・リソースを消費します。あるバージョンのUNIXでは、UNIXバッファ・キャッシュに一定量のメモリーを割り当てることができますが、現在ではより複雑なメモリー管理メカニズムが使用されるのが普通です。通常これらの管理メカニズムでは、I/Oをキャッシュするために空きメモリー・ページを使用できます。そのようなシステムでは、オペレーティング・システムのレポート・ツールは空きメモリーがないことを示すのが普通で、通常は問題になりません。プロセスがより多くのメモリーを必要とする場合、通常はI/Oデータをキャッシュするメモリーが開放されて、そのプロセス・メモリーを割り当てることができます。

9.1.2.2 メモリー使用量に影響を与えるパラメータ

Oracle Databaseセッションのメモリー要件は、様々な要因に依存します。一般的に、大きな要因には次のものがあります。

- オープン・カーソルの数

- PL/SQLで使用されるメモリー(PL/SQL表など)

- SORT_AREA_SIZE初期化パラメータ

Oracle Databaseでは、PGA_AGGREGATE_TARGET初期化パラメータを使用することで、セッションのメモリー使用量に対する制御が向上します。

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

一部のプラットフォームではオペレーティング・システム・リソース・マネージャが提供されます。これらは、CPUリソース割当てに優先順位を付けることによってピーク負荷使用パターンの影響を少なくするように設計されています。これらは通常、ユーザーがアクセス可能なリソースと各ユーザーがこれらのリソースのどの程度を消費可能かを統括する、管理方針を実装します。

オペレーティング・システム・リソース・マネージャは、ドメインや他の類似のファシリティとは異なります。ドメインは、1つのシステム内で1つ以上のまったく別の環境を提供します。ディスク、CPU、メモリーおよびその他すべてのリソースが各ドメイン専用となっており、他のドメインからアクセスできません。他の類似のファシリティは、異なる領域、通常個別のCPUまたはメモリー領域にシステム・リソースの一部のみを完全に分離します。ドメインと同様、個別のリソース領域はその領域に割り当てられた処理専用となっています。プロセスは境界を超えて移行できません。ドメインとは異なり、その他すべてのリソース(通常はディスク)は、システムのすべてのパーティションからアクセスできます。

Oracle Databaseはドメイン内で実行される他、パーティション化されたメモリー(RAM)リソースの割当てが動的でなく、固定されている場合は、その他の不完全なパーティション構造体内で実行されます。

オペレーティング・システム・リソース・マネージャは、リソースのグローバル・プール内、通常はドメインあるいはシステム全体内でのリソース割当てに優先順位を設定します。プロセスはグループに割り当てられ、グループはリソース・プール内の任意の場所にあるリソースに割り当てられます。

注意:
UNIXオペレーティング・システム・リソース・マネージャのメモリー管理および割当て機能では、Oracle Databaseの使用はサポートされていません。Oracleデータベース・インスタンス内のリソース割当て機能を提供するOracle Database Resource Managerは、任意のオペレーティング・システムのリソース・マネージャでは使用できません。

注意:
1つのノードに複数のインスタンスがあり、それらの間でリソースを配分する場合は、各インスタンスを専用のオペレーティング・システム・リソース・マネージャ・グループまたは管理対象エンティティに割り当てる必要があります。管理対象エンティティの複数のインスタンスを実行するには、インスタンス・ケージングを使用して管理対象エンティティ内のCPUリソースをインスタンス間で配分する方法を管理します。Oracle Database Resource Managerは、CPUリソースを管理するときに、各インスタンスに対するCPUリソースが一定量であると予測します。インスタンス・ケージングを使用しない場合は、使用可能なCPUリソースは管理対象エンティティ内のCPUの数と同じであると予測します。インスタンス・ケージングを使用する場合、使用可能なCPUリソースはCPU_COUNT初期化パラメータの値と同じであると予測します。CPUリソースが予測より少ない場合、Oracle Database Resource Managerでりソース計画のリソース割当てを実行したときに適切な結果が得られません。

関連項目:

- Oracle DatabaseおよびOracle Database Resource Managerで動作するオペレーティング・システムのリソース管理、リソースの割当ておよび割当て解除機能の完全なリストは、システム・ベンダーおよびOracle代理から入手してください。特定のリリース・レベルとの互換性において、これらのシステム機能は動作保証されていません。

- Oracle Database Resource Managerの詳細は、『Oracle Database管理者ガイド』を参照してください。

- インスタンス・ケージングの詳細は、『Oracle Database管理者ガイド』を参照してください。

9.2 オペレーティング・システムの問題の解決

この項では、様々なシステムでのチューニングのヒントを示します。次の項目について説明します。

- UNIXベースのシステムのパフォーマンスに関するヒント

- Windowsシステムのパフォーマンスに関するヒント

- HP OpenVMSシステムのパフォーマンスに関するヒント

プラットフォーム固有の問題をよく理解し、使用しているオペレーティング・システムが提供するパフォーマンス・オプションを認識してください。

関連項目:
使用しているプラットフォーム固有のOracleマニュアルおよび使用しているオペレーティング・システム・ベンダーのマニュアル

9.2.1 UNIXベースのシステムのパフォーマンスに関するヒント

UNIXシステムで、オペレーティング・システムのシステム・コールの処理やプロセス・スケジューリングの実行にかかる時間と、アプリケーションの実行時間とで、妥当な比率の確立を試みます。システム・モードではなく、アプリケーション・モード(ユーザー・モードとも呼ばれる)での実行に大部分の時間を費やすことを目標としてください。

各モードで消費される時間の比率は、潜在する問題の徴候にすぎず、次の項目に関係している可能性があります。

- ページングまたはスワッピング

- 実行しているオペレーティング・システム・コールが多すぎる状態

- 実行しているプロセスが多すぎる状態

このような条件が存在する場合は、アプリケーションの実行に使用できる時間は少なくなります。オペレーティング・システム側の時間を多く解放するほど、アプリケーションが実行できるトランザクションの量が増えます。

9.2.2 Windowsシステムのパフォーマンスに関するヒント

UNIXベースのシステムと同様に、Windowsシステムでは、アプリケーション・モードの時間とシステム・モードの時間の比率を適切に設定してください。Windows管理パフォーマンス・ツールで多数の要因を容易に監視できます。CPU、ネットワーク、I/Oおよびメモリーはすべて、これらの領域でのボトルネックを容易に回避できるように同じグラフ上に表示されます。

9.2.3 HP OpenVMSシステムのパフォーマンスに関するヒント

メインフレームのページング・パラメータを検討し、Oracle Databaseが非常に大きな作業セットを利用できる点に留意します。

HP OpenVMS環境での空きメモリーは、どのオペレーティング・システム・プロセスにも実際にマップされていないメモリーです。ビジーなシステムでは、空きメモリーに、1つ以上の現行のアクティブ・プロセスに属するページが含まれる可能性があります。これがアクセスされるとソフト・ページ・フォルトが発生し、ページはそのプロセスの作業セットに組み込まれます。プロセスが作業セットを拡張できない場合は、プロセスによって現在マップされているページの1つを空きセットに移動する必要があります。

任意の数のプロセスが、作業セット内に共有メモリーのページを持つことができます。したがって、作業セットのサイズの合計が使用可能メモリーを著しく超過することがあります。通常、Oracleサーバーを実行している場合、SGA、Oracle Databaseカーネル・コードおよびOracle Formsランタイム実行可能ファイルはすべて共有可能であり、これらはページ・アクセスのおよそ80%または90%を占めます。

9.3 CPUについて

CPUの問題に対処するには、最初に、システムのCPUリソースの使用量について、適切な見積りを設定します。次に、十分なCPUリソースが使用可能かどうかを判断し、システムがいつリソースを使用しすぎているかを認識します。まず、次の3つのシステム状況において、Oracleデータベース・インスタンスのCPUリソースの使用量を判断します。

- システムがアイドル状態で、少数のOracle Databaseおよび非Oracleアクティビティが存在する場合

- システムが平均ワークロードの場合

- システムがピーク・ワークロードの場合

自動ワークロード・リポジトリ、StatspackまたはUTLBSTAT/UTLESTATユーティリティを使用して、様々なワークロードのスナップショットを取得できます。UNIXのvmstat、sarおよびiostatや、Windowsの管理パフォーマンス・モニタリング・ツールなどのオペレーティング・システム・ユーティリティは、V$OSSTATやV$SYSMETRIC_HISTORYビューとともに、自動ワークロード・リポジトリ、Statspack、UTLBSTAT/UTLESTATなどと同じ時間間隔で使用し、統計全体の補完ビューを提供することができます。

関連項目:

- 「自動ワークロード・リポジトリの概要」

- Oracle Databaseツールの詳細は、第6章「自動パフォーマンス診断」を参照してください。

システムのCPU使用率のレベルを評価するときには、ワークロードが重要な要因となります。ピーク・ワークロード時には、CPU使用率が90%の場合アイドルは10%であり、待機時間が発生するのは受容できます。低ワークロード時に使用率が30%となるのも理解できます。しかし、システムが標準のワークロードで高い使用率を示している場合は、ピーク・ワークロードに耐える余裕がありません。次に、図9-1において、午前10:00と午後2:00にピークとなるアプリケーションのワークロードの時間に伴う変化の例を示します。

図9-1 平均のワークロードおよびピーク・ワークロード

この例のアプリケーションでは、1日に8時間作業するユーザーが100人います。各ユーザーが5分ごとに1つのトランザクションを入力すると、1日のトランザクションは9,600になります。8時間にわたってシステムは1時間当たり1,200のトランザクションをサポートする必要があり、1分当たり平均20トランザクションをサポートする必要があります。需要率が一定の場合は、この平均ワークロードを満たすようにシステムを構築します。

ただし、使用率のパターンは一定ではないので、この場合、1分当たり20トランザクションというのは単なる最低条件と考えられます。達成する必要があるピークの割合が1分当たり120トランザクションの場合は、このピーク・ワークロードをサポートできるシステムを構成する必要があります。

この例では、ワークロードがピークのときにOracle DatabaseがCPUリソースの90%を使用するとします。この場合、平均的なワークロード期間にOracle Databaseが使用するのは、次の等式が示すように、使用可能な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能力はありません。

9.4 CPUの問題の解決

CPU容量の問題は、次のように解決します。

- CPUを過剰に消費する問題を検出し、解決します。詳細は、「CPU使用率の確認およびチューニング」を参照してください。

- Oracle Database Resource Managerを使用してCPUリソースの割当てに優先順位を設定して、負荷ピーク時の使用パターンの影響を緩和します。詳細は、「Oracle Database Resource Managerを使用したCPUリソースの管理」を参照してください。

- 複数のCPUを搭載したシステムで複数のデータベース・インスタンスを実行する場合、インスタンス・ケージングを使用してデータベース・インスタンスが同時に使用できるCPU数を制限します。詳細は、「インスタンス・ケージングを使用したCPUリソースの管理」を参照してください。

- ハードウェア・キャパシティを増加し、システム・アーキテクチャを改善します。詳細は、「システム・アーキテクチャ」を参照してください。

9.4.1 CPU使用率の確認およびチューニング

システムで実行されているすべてのプロセスは、使用可能なCPUリソースに影響を与えます。したがって、データベース以外の要素をチューニングすることで、データベースのパフォーマンスが向上する場合もあります。

V$OSSTATまたはV$SYSMETRIC_HISTORYビューを使用して、オペレーティング・システムからのシステム使用率統計を監視します。V$OSSTATおよびV$SYSMETRIC_HISTORYに含まれる有用な統計には、次のものがあります。

- CPUの数

- CPU使用率

- 負荷

- ページング

- 物理メモリー

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

システム全体で実行されているプロセスを確認するには、オペレーティング・システム・モニタリング・ツールを使用します。システムの負荷が非常に高い場合は、この項で後述するメモリー、I/Oおよびプロセス管理の各項目をチェックしてください。

多くのUNIXベースのシステムでは、sar -uなどのツールを使用して、システムのCPU使用率のレベルを確認できます。UNIXでは、統計情報に、ユーザー時間、システム時間、アイドル時間およびI/Oの待機時間が表示されます。標準ワークロードまたは低いワークロードで、アイドル時間およびI/O待機時間が0に近い場合(5%未満)、CPUの問題が存在します。

Windowsでは、管理パフォーマンス・ツールを使用してCPU使用率を監視できます。このユーティリティは、プロセッサ時間、ユーザー時間、特権時間(privileged time)、割込み時間およびDPC時間の統計を提供します。

この項では、システムのCPU使用率のチェックに関する次の項目について説明します。

- メモリー管理のチェック

- I/O管理のチェック

- ネットワーク管理のチェック

- プロセス管理のチェック

注意:
この項では、ほとんどのUNIXベース・システムおよびWindowsシステムにおけるCPU使用率のチェック方法を説明します。その他のプラットフォームについては、使用しているオペレーティング・システムのマニュアルを参照してください。

9.4.1.1 メモリー管理のチェック

次のメモリー管理項目をチェックします。

- ページングとスワッピング

- 大きすぎるページ表

9.4.1.1.1 ページングとスワッピング

V$OSSTATビュー、UNIXのsar、vmstatなどのユーティリティ、またはWindowsの管理パフォーマンス・ツールなどを使用して、ページングとスワッピングの原因を調査します。

9.4.1.1.2 大きすぎるページ表

UNIXでは、処理領域が大きくなりすぎると、ページ表が大きくなりすぎることがあります。これはWindowsシステムでは問題になりません。

9.4.1.2 I/O管理のチェック

スラッシングはI/O管理の課題です。コンピュータのスラッシング(メモリー内外のスワッピングおよびページング処理)が発生しないように、ワークロードがメモリーに収まることを確認してください。オペレーティング・システムは固定サイズのタイム・スライスをユーザーのプロセスに割り当て、プロセスはそのタイム・スライス中にCPUリソースを使用できます。プロセスが実行可能かどうか、および必要な構成要素がすべてコンピュータにあるかどうかを確認するために時間の大半を浪費している場合、実際の処理に使用される時間は、割り当てられた時間の50%のみである可能性があります。

関連項目:
第8章「I/O構成および設計」

9.4.1.3 ネットワーク管理のチェック

クライアント/サーバーのラウンドトリップをチェックします。メッセージを処理する際にはオーバーヘッドが発生します。アプリケーションで多数のメッセージを生成し、ネットワークを介して送信する必要がある場合、メッセージ送信の待機時間によってCPUのオーバーロードが発生することがあります。この問題を緩和するには、多数のラウンドトリップを実行するのではなく、複数のメッセージを1つにまとめます。たとえば、配列挿入、配列フェッチなどを使用できます。

9.4.1.4 プロセス管理のチェック

この項で説明するいくつかのプロセス管理の項目をチェックする必要があります。

9.4.1.4.1 スケジューリングとスイッチング

オペレーティング・システムはスケジューリングおよびスイッチング処理に大量の時間を消費することがあります。使用中のプロセスが多すぎる可能性があるため、オペレーティング・システムの使用方法を調査してください。Windowsシステムでは、データベース以外のプロセスでサーバーが過負荷にならないようにします。

9.4.1.4.2 コンテキストのスイッチング

オペレーティング・システム固有の特性によって、システムがコンテキストのスイッチングに大量の時間を消費することがあります。コンテキストのスイッチングは、特に超大規模SGAの場合には不経済です。インスタンス当たりのプロセスが1つのみであるWindowsでは、コンテキストのスイッチングは問題になりません。すべてのスレッドが同じページ表を共有します。

Oracle Databaseには、複数のコンテキスト・スイッチング機能があります。

- ポスト・ウェイト・ドライバ
Oracleプロセスは、別のOracleプロセスをポスト(メッセージの送信)でき、さらにポストされるのを待機できる必要があります。たとえば、フォアグラウンド・プロセスがLGWRをポストして、指定の時点までのブロックをすべて書き出してコミットを承認するよう、LGWRに通知する必要があります。

このポスト・ウェイト・メカニズムは、UNIXのセマフォを使用して実装するのが普通ですが、これらのセマフォがリソース消費型である場合があります。したがって、一部のプラットフォームでは、ポスト・ウェイト・ドライバを提供しています。通常は、ポスト・ウェイト・インタフェースを軽量に実装できるカーネル・デバイス・ドライバが提供されます。

- メモリーマップ済システム・タイマー
Oracle Databaseでは、システム時間を問い合せてタイミング情報を得る必要が生じる場合があります。その場合、オペレーティング・システム・コールが実行され、比較的コストのかかるコンテキストのスイッチングが発生することがあります。一部のプラットフォームでは、メモリーマップ済タイマーを実装し、プロセス仮想アドレス空間のアドレスに現在のタイミング情報を収集します。このメモリーマップ済タイマーから時間を読み取る方が、システム・コールのコンテキストのスイッチングのオーバーヘッドよりも経済的です。

- 1回のコールで複数の非同期I/Oを発行するリストI/Oインタフェース
リストI/Oとは、個別のシステム・コールで複数のI/Oリクエストを発行するかわりに、1回のシステム・コールで複数の非同期I/Oリクエストを発行できるApplication Program Interfaceです。この機能の主な利点は、コンテキストのスイッチングの所要回数が減少することです。

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

オペレーティング・システムの新規プロセスを開始する際には高いコストがかかります。開発者は、単一目的のプロセスを生成し、そのプロセスを終了後に、また新規のプロセスを生成することがよくあります。この方法ではそのつどプロセスの再生成と破壊が行われるため、特に大規模なSGAを持つアプリケーションではCPUが集中して消費されます。CPUは、そのたびにページ表を構築する必要があります。共有メモリーを確保またはロックするときは、すべてのページにアクセスする必要があるため、問題が増大します。

たとえば、1GBのSGAがある場合は、4KBごとにページ表のエントリがあり、1つのページ表のエントリは8バイトになります。エントリのサイズの合計は(1GB÷4KB)*×8バイトになります。ページ表がロードされていることを絶えず確認する必要があるので、コストが高くなります。

9.4.2 Oracle Database Resource Managerを使用したCPUリソースの管理

Oracle Database Resource Managerは、データベース・ユーザーおよびアプリケーション間のCPUリソースの割当ておよび管理を次のように行います。

- CPU飽和の防止
CPU稼働率が100%の場合、Oracle Database Resource Managerを使用して、各コンシューマ・グループのセッションに最大限のCPUを割り当てることができます。この機能により、優先順位の高いセッションをすぐに実行できるように、優先順位の低いセッションのCPU消費量を削減できます。

- コンシューマ・グループに対するCPU使用量の制限
リソース・マネージャのディレクティブmax_utilization_limitを使用して、コンシューマ・グループが使用できるCPU使用率を厳密に制限できます。この機能は、優先順位の低いセッションのCPU消費量を制限して、コンシューマ・グループ内のワークロードにより安定したパフォーマンスを提供できるようにします。

- リソース集中型の問合せによるダメージの制限
Oracle Database 11gリリース2(11.2.0.2)から、Oracle Database Resource Managerは、コールの最大実行時間を制限することで、または長時間実行問合せを低優先順位の各コンシューマ・グループに移動することで、リソース集中型の問合せによるダメージを制限することができます。

- コンシューマ・グループに対するパラレル文アクティビティの制限
Oracle Database 11gリリース2(11.2.0.2)から、リソース・マネージャのディレクティブparallel_target_percentageを使用して、1つのコンシューマ・グループがすべてのパラレル・サーバーを占有するのを回避できます。データベースは、この制限を超える原因となるパラレル文をキューに入れます。

たとえば、パラレル・サーバーのターゲット数が64で、コンシューマ・グループETLがこのディレクティブを50%に設定しているとします。コンシューマ・グループETLが30個のパラレル・サーバーを使用しており、新しいパラレル文が4個のパラレル・サーバーを必要とする場合、データベースはこの文をキューに入れます。

関連項目:

- Oracle Database Resource Managerの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- パラレル問合せの使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

9.4.3 インスタンス・ケージングを使用したCPUリソースの管理

1つのシステムで複数のデータベース・インスタンスが実行されている場合、インスタンスはCPUリソースを競い合います。1つのリソース集中型のデータベース・インスタンスが、他のインスタンスのパフォーマンスを大きく低下させる場合があります。この問題を回避するには、インスタンス・ケージングを使用して、各インスタンスが使用できるCPU数を制限します。このとき、Oracle Database Resource Managerは、インスタンスに設定されたリソース計画に基づいて様々なデータベース・セッション間にCPUを割り当て、インスタンスがCPUバインドになる可能性を最小限に抑えます。

関連項目:
インスタンス・ケージングの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

データベースの初期構成後は、インスタンスの定期的な監視およびチューニングがパフォーマンスの潜在的なボトルネックを解消するために重要になります。この章では、OracleのV$パフォーマンス・ビューを使用したチューニング・プロセスについて説明します。

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

- インスタンスのチューニング手順

- Oracle Database統計の解釈

- 待機イベント統計

- リアルタイムSQL監視

- インスタンス・リカバリのパフォーマンスのチューニング: ファスト・スタート・フォルト・リカバリ

10.1 インスタンスのチューニング手順

次に、インスタンスのチューニング用のOracleパフォーマンス・メソッドの主な手順を示します。

1. 問題の定義
パフォーマンス問題の範囲についてユーザーから候補フィードバックを取得します。

2. ホスト・システムの検査およびOracle Database統計の調査

- オペレーティング・システム、データベースおよびアプリケーション統計一式を取得後に、パフォーマンスの問題の徴候を探すためにデータを調べます。

- 一般的なパフォーマンス・エラーのリストを検討して、収集されたデータが問題に影響を与えていることを示しているかどうかを確認します。

- 収集されたパフォーマンス・データを使用して、何がシステムで起こっているかを示す概念モデルを構築します。

3. 変更の実装および測定
行う変更および変更を実装した場合に予測される結果を提示します。次に、変更を実装してアプリケーション・パフォーマンスを測定します。

4. 手順1で定義したパフォーマンスの目的が達成されたかどうかを判断します。達成されていない場合は、パフォーマンスの目標が達成されるまで手順2と3を繰り返します。

関連項目:
このパフォーマンス・メソッドの理論的な説明および共通エラーのリストは、「Oracleのパフォーマンス改善方法」を参照してください。

この章の残りの部分では、Oracle Databaseの動的パフォーマンス・ビューを使用したインスタンスのチューニングについて説明します。ただし、機能リストの拡張により、統計の収集、監視およびチューニングには、自動ワークロード・リポジトリ(AWR)および自動データベース診断モニター(ADDM)を使用することをお薦めします。「自動ワークロード・リポジトリの概要」および「自動データベース診断モニターの概要」を参照してください。

注意:
AWRおよびADDM機能がない場合、Statspackを使用してOracleデータベース・インスタンスの統計情報を収集できます。

10.1.1 問題の定義

ソリューションの実装を試みる前に、チューニング調査の目的と問題の性質をよく理解しておくことが不可欠です。これについて理解していないと、事実上、効果的な変更は実装できません。この段階で収集されたデータを使用して、次に行うこと、および調査する事象を簡単に決定できます。

次のデータを収集します。

1. パフォーマンスの目的を識別します。
許容できるパフォーマンスの測定尺度は何ですか。1時間、または1秒間当たり何件のトランザクションで、レスポンス時間が必要なパフォーマンス・レベルを満たしますか。

2. 問題の範囲を識別します。
スローダウンで何が影響を受けますか。たとえば、インスタンス全体は低速ですか。それは、特定のアプリケーション、プログラム、特定の操作またはシングル・ユーザーですか。

3. 問題が発生したときの時間帯を識別します。
その問題はピーク時間のみ明白ですか。パフォーマンスはその日の経過に伴って低下しますか。スローダウンは徐々に(月または週の単位で)発生しましたか、または突然発生しましたか。

4. スローダウンを検証します。
これは、問題の範囲の識別に役立ち、問題の修復のために実装された変更により実際に改善されたかどうかを判断するときの比較結果の測定基準としての役割を果します。一貫して再生可能なレスポンス時間またはジョブ実行時間の測定値を検索します。プログラムの動作が正常だったときよりタイミングがどのくらい悪化していますか。

5. 変更を識別します。
パフォーマンスが許容可能になった後に変化した内容を識別します。これにより、潜在的な原因を素早くつきとめることができます。たとえば、オペレーティング・システムのソフトウェア、ハードウェア、アプリケーション・ソフトウェアまたはOracle Databaseリリースのアップグレードを実行しましたか。さらに多くのデータがシステムにロードされたか、データ・ボリュームまたはユーザー人口が増加しましたか。

このフェーズの終わりまでに、症状についてよく理解しておく必要があります。症状をプログラムまたはプログラム・セットにローカルなものとして識別できる場合、その問題はインスタンス全体のパフォーマンスの問題とは異なる方法で処理されます。

関連項目:
アプリケーションまたはユーザーに固有のパフォーマンスの問題を解決する方法は、第16章「SQLチューニングの概要」を参照してください。

10.1.2 ホスト・システムの検査

データベース・サーバーに対する負荷とデータベース・インスタンスを調べてください。オペレーティング・システム、I/Oサブシステムおよびネットワーク統計を検討してください。これらの領域を調べると、調査する価値のあるものは何かが容易にわかります。多層のシステムでは、アプリケーション・サーバーの中間層ホストも調べてください。

ホスト・ハードウェアを調べると、システム内のボトルネックがよくわかります。この調査によって、相互参照および今後の診断に役立つOracle Databaseパフォーマンス・データを判断できます。

調べるデータには、次のものがあります。

- CPUの使用率

- I/Oの問題の識別

- ネットワークの問題の識別

10.1.2.1 CPUの使用率

アイドル状態のCPUが大量にある場合、I/O、アプリケーションまたはデータベースのボトルネックが存在する可能性があります。I/O待機はアイドル状態のCPUとしてみなす必要があります。

CPU使用率が高い場合は、CPUが効果的に使用されているかどうかを判断してください。CPU使用率の大部分は、CPU使用率の高い少数のプログラムによるものですか、または均等に分散されたワークロードでCPUが消費されていますか。

CPUが使用頻度の高い少量のプログラムで使用されている場合は、プログラムを調べて原因を判断してください。一部のプロセスのみが1つのCPUの能力全体を使用しているかどうかを確認してください。プロセスによっては、この情報はCPUまたはプロセスによりワークロードがバインドされていることを示している場合があり、プロセス・アクティビティを分割またはパラレル化することで解決できます。

10.1.2.1.1 Oracle以外のプロセス

プログラムがOracleのプログラムではない場合は、それらのプログラムがそのような量のCPUを必要としているかどうかを識別してください。必要としている場合は、プログラムの実行をピーク以外の時間に遅らせることができるかどうかを判断します。これらのCPU集中型プロセスを識別することで、I/O、ネットワークおよびページングなどのどのアクティビティがリソースを消費しているかを特定し、データベース・ワークロードとの関係を確認できます。

10.1.2.1.2 Oracleプロセス

少数のOracleプロセスによって多くのCPUリソースが使用されている場合は、SQL_TRACEとTKPROFを使用してSQL文またはPL/SQL文を特定して、特定の問合せまたはPL/SQLプログラム・ユニットをチューニングできるかどうかを確認します。たとえば、SELECT文の実行によりキャッシュ内の多数のデータ読取り(論理読取り)が発生する場合、さらなるSQLの最適化によってCPUの集中的な使用を回避できます。

10.1.2.1.3 Oracle Database CPU統計

Oracle Database CPU統計は、V$ビューで取得できます。

- V$SYSSTATは、すべてのセッションのOracle Database CPU使用率を示します。CPU used by this session統計は、すべてのセッションで使用されているCPUの集計を示します。parse time cpu統計は、解析に使用された合計CPU時間を示します。

- V$SESSTATは、各セッションのOracle Database CPU使用率を示します。このビューを使用して、CPUを最も多く使用している特定のセッションを調べます。

- Oracle Database Resource Managerを実行している場合、各コンシューマ・グループのCPU使用率の統計情報がV$RSRC_CONSUMER_GROUPに表示されます。

10.1.2.1.4 CPU統計の解釈

CPU時間と実時間の違いを認識しておくことは重要です。8個のCPUの場合、実時間で1分間に使用可能なCPU時間は8分間です。この時間は、WindowsおよびUNIXではユーザー時間またはシステム時間です(Windowsでは特権モード)。したがって、システム上のすべてのプロセス(スレッド)で使用される平均CPU時間は、1分の実時間間隔当たり1分を超える可能性があります。

どの特定の時点においても、システム上でOracle Databaseが使用した時間を識別できます。使用可能な時間が8分間で、Oracle Databaseがそのうちの4分間を使用した場合、総CPU時間の50%がOracleによって使用されたことがわかります。ユーザーのプロセスがその時間を消費していない場合は、他のプロセスが消費しています。CPU時間を使用しているプロセスを識別し、原因を解明し、それらのプロセスのチューニングを試行してください。第21章「アプリケーション・トレース・ツールの使用方法」を参照してください。

CPU使用率が多数のOracleサーバー・プロセスに均一に分散している場合は、V$SYS_TIME_MODELビューを調べると、最長時間が消費されているプロセスを正確に把握できます。表10-1「待機イベントおよび潜在的な原因」を参照してください。

10.1.2.2 I/Oの問題の識別

過度にアクティブなI/Oシステムは、2より大きいディスク・キューの長さ、すなわち、20から30ミリ秒を超えるディスク・サービス時間でわかります。I/Oシステムが過度にアクティブである場合、さらに多くのディスク間にI/Oを分散させることで利益を得られる潜在的なホット・スポットの有無をチェックします。また、これらのリソースを使用して、プログラムのリソース要件を少なくして負荷を減らせるかどうかも識別します。I/O問題の原因がOracle Databaseである場合、I/Oチューニングを開始できます。Oracle Databaseが使用可能なI/Oリソースを消費していない場合、I/Oを消費しているプロセスを識別します。プロセスがI/Oを消費している原因を究明して、プロセスをチューニングします。

I/O問題は、Oracle DatabaseのV$ビューおよびオペレーティング・システムのモニタリング・ツールによって識別できます。次の項では、I/O問題の識別について説明します。

- V$ビューを使用したI/Oの問題の識別

- オペレーティング・システムのモニタリング・ツールを使用したI/Oの問題の識別

10.1.2.2.1 V$ビューを使用した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 Databaseから報告された時間とを比較して、それらに一貫性があるかどうかを確認します。

I/Oの問題によって、I/Oに関連しない待機イベントが明らかになる場合もあります。たとえば、バッファ・キャッシュ内で空きバッファを検出できない場合や、ディスクへのログ書込みが完了するまでの待機時間が長い場合も、I/O問題の症状を示す場合があります。I/Oシステムを再構成する必要があるかどうかを調べる前に、I/Oシステム上の負荷を減らせるかどうかを判断します。

Oracle Databaseを原因とするI/O負荷を減らすには、次のビューを使用して、データベースによるすべてのI/Oコールに対して収集されたI/O統計を調査します。

- V$IOSTAT_CONSUMER_GROUP
V$IOSTAT_CONSUMER_GROUPビューには、コンシューマ・グループのI/O統計が取得されます。Oracle Database Resource Managerが有効な場合、現在有効なリソース・プランに含まれるすべてのコンシューマ・グループのI/O統計が取得されます。

- V$IOSTAT_FILE
V$IOSTAT_FILEビューには、現在アクセスされているか、または過去にアクセスされたデータベース・ファイルのI/O統計が取得されます。SMALL_SYNC_READ_LATENCY列には、単一ブロック同期読取り(ミリ秒単位)の待機時間が表示されますが、これはクライアントが次の操作に移行する前に待機する必要のある時間を表します。これにより、現在の負荷に基づいたストレージ・サブシステムのレスポンス性が定義されます。重要なデータファイルに対する待機時間が長い場合、それらのファイルを再配置してサービス時間を短縮することを検討してください。待機時間の統計を計算するには、timed_statisticsがTRUEに設定されている必要があります。

- V$IOSTAT_FUNCTION
V$IOSTAT_FUNCTIONビューには、データベース機能(LGWRやDBWRなど)のI/O統計が取得されます。

I/Oは、異なる機能を持つ様々なOracleプロセスによって発行されます。上位のデータベース機能は、V$IOSTAT_FUNCTIONビューに分類されます。I/O機能間の競合がある場合、そのI/Oはより小さいFUNCTION_IDのバケットに配置されます。たとえば、XDBがバッファ・キャッシュからI/Oを発行する場合、そのI/OはXDB I/Oに分類されますが、これはXDB I/OのFUNCTION_ID値の方が小さいためです。未分類の機能は、Othersバケットに配置されます。次のようにV$IOSTAT_FUNCTIONビューを問い合せると、FUNCTION_IDの階層を表示できます。

select FUNCTION_ID, FUNCTION_NAME
from v$iostat_function
order by FUNCTION_ID;

FUNCTION_ID FUNCTION_NAME
----------- ------------------
0 RMAN
1 DBWR
2 LGWR
3 ARCH
4 XDB
5 Streams AQ
6 Data Pump
7 Recovery
8 Buffer Cache Reads
9 Direct Reads
10 Direct Writes
11 Others

これらのV$IOSTATビューには、単一ブロックと複数ブロックの読取り/書込み操作のI/O統計が含まれます。単一ブロック操作は、128KB以下の小規模なI/Oです。複数ブロック操作は、128KBを超える大規模なI/Oです。これらの操作ごとに、次の統計が収集されます。

- 識別子

- 合計待機時間(ミリ秒単位)

- 実行された待機操作数(コンシューマ・グループおよび機能)

- 操作ごとのリクエスト数

- 単一および複数ブロックの読取りバイト数

- 単一および複数ブロックの書込みバイト数

また、V$SQLAREAビューの問合せか、自動ワークロード・リポジトリ・レポートの「読取りによるSQLのソート」セクションの確認によって、多数の物理読取りを実行するSQL文についても調べる必要があります。これらの文を調べて、I/Oの回数を減らすようにこれらのSQL文をチューニングする方法を調べます。

関連項目:

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

- 第16章「SQLチューニングの概要」

- 散布読取りと順次読取りの違いと、I/Oに与えるその影響は、「db file scattered read」および「db file sequential read」を参照してください。

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

10.1.2.2.2 オペレーティング・システムのモニタリング・ツールを使用したI/Oの問題の識別

オペレーティング・システムのモニタリング・ツールを使用して、システム全体で実行されているプロセスを判別し、すべてのファイルに対するディスク・アクセスを監視してください。データファイルとREDOログ・ファイルを保持しているディスクは、Oracle Databaseに関連しないファイルも保持している可能性があります。データベース・ファイルを含むディスクに対する過度のアクセスを減らしてください。データベース以外のファイルへのアクセスは、V$ビューではなく、オペレーティング・システムの機能でのみ監視できます。

多数のUNIXシステム上のsar -d(またはiostat)やWindowsシステム上の管理パフォーマンス・モニタリング・ツールなどのユーティリティは、システム全体のI/O統計を調べます。

関連項目:
プラットフォームで使用可能なツールのオペレーティング・システムのマニュアル

10.1.2.3 ネットワークの問題の識別

オペレーティング・システムのユーティリティを使用して、ネットワーク・ラウンドトリップのping時間と衝突数を調べます。ネットワークでレスポンス時間の大幅な遅延が発生している場合は、考えられる原因を調べてください。

データベース・ファイルへのリモート・アクセスを原因とするネットワークI/Oを識別するには、V$IOSTAT_NETWORKビューを調査します。このビューには、リモート・データベース・インスタンスのファイルへのアクセスに基づく次のようなネットワークI/O統計が含まれます。

- ネットワークI/Oを開始したデータベース・クライアント(RMANやPLSQLなど)

- 発行された読取りおよび書込み操作の数

- 読取りおよび書込みKB数

- 読取り操作の合計待機時間(ミリ秒単位)

- 書込み操作の合計待機時間(ミリ秒単位)

ネットワーク問題の原因の識別後にネットワーク負荷を減らすには、大きいデータ転送をピーク時間外へスケジュールするか、リモート・ホストに対してリクエスト当たり1回ずつ(またはそれ以上)アクセスせずに、リクエストをバッチ処理するようにアプリケーションをコーディングします。

10.1.3 Oracle Database統計の調査

Oracle Database統計を確認し、それをオペレーティング・システムの統計と照合して、一貫性のある問題の診断を行う必要があります。オペレーティング・システムの統計では、チューニングの出発点となる最適な情報を取得できます。ただし、Oracleデータベース・インスタンスをチューニングすることが目的の場合は、修正処置を行う前に、Oracle Database統計を調べ、データベースの観点からリソースのボトルネックを特定します。「Oracle Database統計の解釈」を参照してください。

チューニング中に使用する一般的なOracleデータ・ソースを次に示します。

10.1.3.1 統計収集のレベルの設定

Oracle Databaseには、データベースのすべての主要な統計収集またはアドバイザを制御する初期化パラメータSTATISTICS_LEVELがあります。このパラメータは、データベースの統計収集レベルを設定します。

STATISTICS_LEVELの設定に応じて、次のように一定のアドバイザまたは統計が収集されます。

- BASIC: アドバイザも統計も収集されません。監視機能および多数の自動機能が無効です。重要なOracle Database機能が無効になるため、この設定は使用しないことをお薦めします。

- TYPICAL: これはデフォルト値であり、すべての主要統計が収集され、データベース全体のパフォーマンスが最高になります。ほとんどの環境では、この設定で十分です。

- ALL: TYPICAL設定を使用して収集されるすべてのアドバイザと統計に加えて、オペレーティング・システム時間統計および行ソース実行統計が含まれます。

関連項目:

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

- STATISTICS_LEVEL、DB_CACHE_ADVICE、TIMED_STATISTICSまたはTIMED_OS_STATISTICS初期化パラメータを設定する場合の考慮事項は、「統計の解釈」を参照してください。

10.1.3.1.1 V$STATISTICS_LEVEL

このビューには、STATISTICS_LEVELで制御される統計またはアドバイザのステータスがリストされます。

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

10.1.3.2 待機イベント

待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示すために、サーバー・プロセスまたはスレッドによって増やされる統計です。待機イベント・データは、ラッチの競合、バッファの競合、I/Oの競合などのパフォーマンスに影響を与えると思われる様々な問題の症状を表します。ただし、これらの問題は実際の原因でなく、問題の症状にすぎないことに注意してください。

待機イベントは、クラス別にグループ化されています。待機イベント・クラスには、Administrative、Application、Cluster、Commit、Concurrency、Configuration、Idle、Network、Other、Scheduler、System I/O、およびUser I/Oがあります。

サーバー・プロセスには、次のような待機があります。

- バッファやラッチなどのリソースが使用可能になるのを待機します。

- I/Oなどのアクションが完了するのを待ちます。

- 実行する追加作業(クライアントが次に実行するSQL文を提供するまで待機する場合など)。サーバー・プロセスが追加作業の待機中であることを識別するイベントのことをアイドル・イベントと呼びます。

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

待機イベント統計には、イベントを待機した回数や、イベントが完了するまでの待機時間があります。TIMED_STATISTICS初期化パラメータをtrueに設定すると、各リソースを待機した時間も表示されます。

ユーザー・レスポンス時間をできるだけ少なくするには、イベントが完了するまでサーバー・プロセスが待機する時間を減らします。すべての待機イベントが同じ待機時間を持っているとはかぎりません。したがって、発生回数の多い待機イベントより、最大の合計時間を持つイベントを調べるほうが重要です。通常は、少なくともパフォーマンスの監視中にTIMED_STATISTICS動的パラメータをtrueに設定することが最善です。STATISTICS_LEVELの設定の詳細は、「統計収集のレベルの設定」を参照してください。

10.1.3.3 待機イベント統計を含む動的パフォーマンス・ビュー

待機イベント統計について、これらの動的パフォーマンス・ビューの問合せを行うことができます。

- V$ACTIVE_SESSION_HISTORY
V$ACTIVE_SESSION_HISTORYビューには、1秒ごとにサンプリングされたアクティブなデータベース・セッションのアクティビティが表示されます。「アクティブ・セッション履歴」を参照してください。

- V$SESS_TIME_MODELおよびV$SYS_TIME_MODEL
V$SESS_TIME_MODELビューおよびV$SYS_TIME_MODELビューには、データベース・コールの所要時間の合計であるDB timeなど、時間モデル統計が含まれます。

- V$SESSION_WAIT
V$SESSION_WAITビューには、各セッションの現在または最後の待機に関する情報(待機ID、クラス、時間など)が表示されます。

- V$SESSION
V$SESSIONビューには、各現行セッションに関する情報が表示されます。また、このビューには、V$SESSION_WAITビューと同じ待機統計が含まれています。該当する場合、このビューには、セッションが現在待機中のオブジェクトの詳細情報(オブジェクト番号、ブロック番号、ファイル番号、行番号など)、現在の待機の原因となったブロック・セッション(ブロック・セッションID、ステータス、タイプなど)、および待機時間も含まれます。

- V$SESSION_EVENT
V$SESSION_EVENTビューは、セッションが開始した後に待機したすべてのイベントのサマリーを示します。

- V$SESSION_WAIT_CLASS
V$SESSION_WAIT_CLASSビューは、待機数および各セッションの待機イベントの各クラスで消費される時間を示します。

- V$SESSION_WAIT_HISTORY
V$SESSION_WAIT_HISTORYビューには、各アクティブ・セッションの最新10件の待機イベントに関する情報(イベント・タイプや待機時間など)が表示されます。

- V$SYSTEM_EVENT
V$SYSTEM_EVENTビューは、インスタンス起動後のインスタンスの、全イベント待機のサマリーを示します。

- V$EVENT_HISTOGRAM
V$EVENT_HISTOGRAMビューには、待機数、最大待機時間およびイベントごとの合計待機時間を示すヒストグラムが表示されます。

- V$FILE_HISTOGRAM
V$FILE_HISTOGRAMビューには、ファイルごとに1ブロック読取り中の待機回数を示すヒストグラムが表示されます。

- V$SYSTEM_WAIT_CLASS
V$SYSTEM_WAIT_CLASSビューは、待機数に対するインスタンス全体の総時間および待機イベントの各クラスで消費される時間を示します。

- V$TEMP_HISTOGRAM
V$TEMP_HISTOGRAMビューには、一時ファイルごとに1ブロック読取り中の待機回数を示すヒストグラムが表示されます。

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

パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・データを調査します。最大時間がリストされるイベントは、多くの場合、パフォーマンス・ボトルネックを顕著に示しています。たとえば、V$SYSTEM_EVENTを参照することで、多くのbuffer busy waitsが発生していると気づくことがあります。おそらく、多数のプロセスが同じブロックに挿入しようとするときに、各プロセスが他のプロセスの挿入を待機してからでないと挿入できないことが原因です。問題となっているオブジェクトに自動セグメント領域管理またはパーティション化を使用することで解決する可能性があります。V$SESSION_WAIT、V$SESSION_EVENTおよびV$SYSTEM_EVENTの各ビューの差異の説明は、「待機イベント統計」を参照してください。

10.1.3.4 システム統計

システム統計は通常、パフォーマンスの問題の原因をさらに示すものを見つけるために、待機イベント・データとともに使用されます。

たとえば、最大の待機イベント(待機時間の点で)がbuffer busy waitsイベントであることをV$SYSTEM_EVENTが示している場合、V$WAITSTATビューで使用できる特定のバッファ待機統計を調べて、どのブロック・タイプが最大の待機カウントと最大の待機時間を持っているかを識別します。

ブロック・タイプを識別した後、問題の発生中にV$SESSIONをリアルタイムで調べるか、問題の発生後にV$ACTIVE_SESSION_HISTORYビューおよびDBA_HIST_ACTIVE_SESS_HISTORYビューを調べ、表示されたオブジェクト番号を使用して競合対象のオブジェクトを識別します。このデータの組合せは、適切な修正アクションを示しています。

統計は、多数のV$ビューで使用できます。次の内容を含む共通ビューもあります。

- V$ACTIVE_SESSION_HISTORY

- V$SYSSTAT

- V$FILESTAT

- V$ROLLSTAT

- V$ENQUEUE_STAT

- V$LATCH

10.1.3.4.1 V$ACTIVE_SESSION_HISTORY

このビューには、1秒ごとにサンプリングされたアクティブなデータベース・セッションのアクティビティが表示されます。「アクティブ・セッション履歴」を参照してください。

10.1.3.4.2 V$SYSSTAT

ロールバック、論理I/O、物理I/O、解析データをはじめとするOracle Databaseの様々な部分の全般的な統計が含まれます。バッファ・キャッシュ・ヒット率などの比率を計算するには、V$SYSSTATからのデータを使用します。

10.1.3.4.3 V$FILESTAT

これには、ファイル当たりのI/O回数や平均読取り時間など、ファイルごとの詳細なファイルI/O統計が含まれています。

10.1.3.4.4 V$ROLLSTAT

これには、詳細なロールバック・セグメントおよびUNDOセグメント統計が含まれています。

10.1.3.4.5 V$ENQUEUE_STAT

これには、エンキューが要求された回数やエンキューを待機した回数、待機時間など、各エンキューの詳細なエンキュー統計が含まれています。

10.1.3.4.6 V$LATCH

これには、各ラッチが要求された回数やラッチを待機した回数など、各ラッチの詳細なラッチ使用統計が含まれています。

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

10.1.3.5 セグメント・レベルの統計

個別のセグメントに関連するパフォーマンス問題に焦点をあてるのに役立つ、セグメント・レベルの統計を収集できます。セグメント・レベルの統計を収集して表示することは、インスタンスで競合度の高い表あるいは索引を効果的に識別するための優れた方法です。

パフォーマンスの問題を識別するために待機イベントおよびシステム統計を表示した後で、セグメント・レベルの統計を使用して問題の原因となっている特定の表または索引を検索できます。バッファ・ビジー待機が、大半の待機時間の原因になっていることをV$SYSTEM_EVENTが示している例を考えます。バッファ・ビジー待機の原因になっているトップ・セグメントをV$SEGMENT_STATISTICSから選択できます。これにより、それらのセグメントの問題の解決に集中できます。

セグメント・レベルの統計は、次の動的ビューを使用して問い合せます。

- V$SEGSTAT_NAME: このビューには収集するセグメント統計と、各種統計(たとえばサンプル統計など)のプロパティがリストされます。

- V$SEGSTAT: これは非常に効率的で、リアルタイム監視が可能なビューであり、統計値、統計名およびその他の基本情報が表示されます。

- V$SEGMENT_STATISTICS: ユーザーが扱いやすい統計値のビューです。V$SEGSTATのすべての列の他、ここにはセグメント所有者や表領域名などの情報があります。統計の理解は容易になりますが、コストがより高くなります。

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

10.1.4 変更の実装および測定

チューニングを実施した後、多くの場合、問題を軽減できると思われる2つまたは3つの変更を識別できます。どの変更が最高の利益を提供するかを識別するには、一度に1回の変更を実装することをお薦めします。変更の効果は、問題定義段階でみられたベースライン・データ測定と対照して測定する必要があります。

一般に、パフォーマンスの問題を持つ大半のサイトでは、一度に重複した変更を実装するので、どの変更が利益を実現したかを識別できません。これはすぐに問題になることはありませんが、どの変更が最も効果をあげ、どのような作業を優先する必要があるかを知ることは不可能なので、今後同様の問題が発生した場合に大きな障害になります。

個別に変更を実装できない場合は、異なる変更の効果の測定を試みてください。たとえば、変更された問合せのパフォーマンスを向上するために新しい索引を作成する効果とは別に、REDOの生成を最適化するために初期化変更を行う効果を測定します。SQLがチューニングされ、オペレーティング・システムのディスク・レイアウトが変更され、初期化パラメータも同時に変更されている場合は、オペレーティング・システムをアップグレードすることの利益は測定できません。

パフォーマンス・チューニングは反復的なプロセスです。インスタンス全体のパフォーマンスの問題を解決する特効薬的な対策が見つかることはほとんどありません。ほとんどの場合、あるボトルネックを解決しても別の(ときにはさらに悪い)問題が発生するため、優れたパフォーマンスにはパフォーマンス・チューニング段階を反復する必要があります。

いつチューニングを停止するかを知ることも重要です。パフォーマンスの最も優れた測定は、統計が理想的な値にどの程度近いかではなく、ユーザーの理解力です。

10.2 Oracle Database統計の解釈

インスタンスにパフォーマンスの問題があった時間範囲の統計を収集します。比較のためのベースライン・データをすでに収集してある場合は、問題のワークロードを最も代表するベースラインからのデータと、現行のデータを比較できます。

2つのレポートを比較する場合、それらのレポートが、システムを比較できるようなワークロードか確認してください。

関連項目:
「データ収集の概要」

10.2.1 負荷の検査

待機イベントは通常、最初に検査するデータです。ただし、ベースライン・レポートがある場合は、負荷が変化したかどうかをチェックします。ベースラインがあるかどうかにかかわらず、リソースの使用率が高いかどうかを確認すると便利です。

検査する負荷に関連する統計には、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 read total bytesおよびphysical write total bytesの合計を使用して、1秒当たりの合計I/O負荷(MB)を調べることも有益です。合計値には、Recovery Manager(RMAN)バックアップおよびリカバリとOracle Databaseバックグラウンド・プロセスによる、バッファ・キャッシュ、REDOログ、アーカイブ・ログでのI/Oが含まれます。

AWRレポートの「ロード・プロファイル」セクションを参照してください。データは、トランザクションおよび秒ごとに正規化されています。

10.2.1.1 負荷の変更

秒ごとの負荷プロファイル統計は、スループットの変化(すなわち、インスタンスの作業実行量が毎秒ごとに増えているかどうか)を示します。トランザクションごとの統計は、アプリケーション特性の変化をベースライン・レポートからの対応する統計と比較することで識別します。

10.2.1.2 高いアクティビティ率

アクティビティ率が非常に高いかどうかを識別するには、秒ごとに正規化した統計を調べます。サイトごとにしきい値が異なり、アプリケーションの特性、CPUの個数と速度、オペレーティング・システム、I/OシステムおよびOracle Databaseのリリースに左右されるため、高い値に関する包括的な推奨事項を示すのは困難です。

次に、いくつかの一般化された例を示します(許容値は各サイトで異なります)。

- 秒当たり100を超えるハード解析率は、非常に大量なハード解析がシステム上にあることを示します。高いハード解析率は重大なパフォーマンスの問題を発生させるので、調査する必要があります。通常は、高いハード解析率に共有プール上のラッチの競合とライブラリ・キャッシュ・ラッチが伴います。

- ライブラリ・キャッシュおよび共有プール・ラッチ・イベント(latch: library cache、latch: library cache pin、latch: library cache lockおよびlatch: shared pool)の待機時間の合計が、V$SYSSTATに表示される統計のDB timeに比べて大きいかどうかを調べます。大きい場合は、AWRレポートのSQL ordered by Parse Callsセクションを調べます。

- 高いソフト解析率は、秒当たり300以上の率になる可能性があります。不必要なソフト解析もアプリケーションのスケーラビリティを制限します。最適な方法として、SQL文をセッション当たり1回ソフト解析し、何回も実行します。

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

Oracleが何かの待機を処理する場合は必ず、定義済待機イベント・セットの1つを使用し、待機を記録します。これらの待機イベントは、待機クラス別にグループ化されます。Idle待機クラスには、実行する作業がなく、さらに作業が実行されるのを待っている場合にプロセスが待機するイベントすべてがグループ化されます。アイドル状態でないイベントはリソースあるいはアクションが完了するまでの非生産的な待機時間を示します。

注意:
すべての症状が待機イベントによって証明されるわけではありません。チェックできる統計は、「追加された統計情報」を参照してください。

待機イベント・データを使用する最も効率的な方法は、待機時間別にイベントを順序付けすることです。この方法は、TIMED_STATISTICSがtrueに設定されているときのみ可能です。設定しない場合は、待機イベントを待機数別に順位付けします。これは、一般的に問題を最もよく表す順序付けではありません。

関連項目:

- STATISTICS_LEVELの設定の詳細は、「統計収集のレベルの設定」を参照してください。

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

どこで時間が消費されているかが判明してから、次の手順を実行してください。

1. V$SYSTEM_EVENTのデータ収集を調べます。対象のイベントは、待機時間別に順位付けする必要があります。
待機時間の最も大きいパーセンテージを持つ待機イベントを識別します。待機時間のパーセンテージを決定するには、アイドル・イベント(Null event、SQL*Net message from client、SQL*Net message to client、SQL*Net more data to clientなど)を除くすべての待機イベントの合計待機時間を加算します。各イベントの待機時間をすべてのイベントの総待機時間で除算し、5つの最も重要なイベントの相対的なパーセンテージを計算します。

関連項目:

- アイドル待機イベントのリストは、「アイドル待機イベント」を参照してください。

- V$EVENT_NAMEビューの説明は、『Oracle Databaseリファレンス』を参照してください。

- 待機イベント情報の詳細は、『Oracle Databaseリファレンス』を参照してください。

別の方法として、自動ワークロード・リポジトリ・レポートの先頭の「トップ5待機イベント」の項を参照してください。この項では、待機イベント(アイドル・イベントを除く)を自動的に順序付けし、相対的なパーセンテージを計算します。

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                % Total
Event                                         Waits    Time (s) Call Time
-------------------------------------- ------------ ----------- ---------
CPU time                                                    559     88.80
log file parallel write                       2,181          28      4.42
SQL*Net more data from client               516,611          27      4.24
db file parallel write                       13,383          13      2.04
db file sequential read                         563           2       .27

状況によっては、同程度のパーセンテージを持つイベントがいくつか存在する場合があります。このため、すべてのイベントが同じタイプのリソース・リクエスト(たとえば、すべてがI/O関連イベント)に関連している場合に、追加の証拠を提供できます。

2. これらのイベントの待機数と平均待機時間を見てください。たとえば、I/O関連イベントの場合、平均時間がI/Oシステムが低速であるかどうかを識別するのに役立つ場合もあります。次に、AWRレポートの「待機イベント」セクションから引用した、このデータの例を示します。

Avg
Total Wait   wait     Waits
Event                           Waits  Timeouts   Time (s)   (ms)      /txn
--------------------------- --------- --------- ---------- ------ ---------
log file parallel write         2,181         0         28     13      41.2
SQL*Net more data from clie   516,611         0         27      0   9,747.4
db file parallel write         13,383         0         13      1     252.5

3. トップの待機イベントは、次に調査する場所を識別します。表10-1に、一般的な待機イベントを示します。高負荷SQLを調べることもお薦めします。

4. 待機イベントで指示される関連データを調べて、このデータから得られる他の情報を確認します。この情報が待機イベント・データとの一貫性を持っているかどうかを判断します。ほとんどの場合、パフォーマンス・ボトルネックの潜在的な原因に関する理論の展開を開始するためのデータは十分にあります。

5. この理論が有効かどうかを確認するには、使用可能な他の統計で調べたデータをクロスチェックして一貫性のあることを確認します。適切な統計は問題により異なりますが、通常はV$SYSSTATやオペレーティング・システム統計などにある、ロード・プロファイル関連のデータが含まれています。他のデータとのクロスチェックを行って、展開中の理論を肯定または否定します。

10.2.3 待機イベントおよび潜在的な原因の表

表10-1に、待機イベントと考えられる原因との関連付けの他、次に検討するのに最も有益と思われるOracleデータの概要を示します。

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

待機イベント

一般的な領域

考えられる原因

検索/調査

buffer busy waits

バッファ・キャッシュ、DBWR

バッファ・タイプによって異なります。たとえば、索引ブロックの待機は、昇順に基づく主キーが原因である場合があります。

問題が発生している間にV$SESSIONを調べ、競合したブロックのタイプを判別します。

free buffer waits

バッファ・キャッシュ、DBWR、I/O

低速なDBWR(おそらくI/Oに起因)

小さすぎるキャッシュ

オペレーティング・システム統計を使用して書込み時間を調べます。キャッシュが小さすぎることの証拠があるかどうかについてバッファ・キャッシュ統計をチェックします。

db file scattered read

I/O、SQL文のチューニング

チューニングが適切ではないSQL

低速なI/Oシステム

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から毎秒のトランザクション数(コミット数+ロールバック数)をチェックします。

また、My Oracle Supportでbuffer busy waits(34405.1)およびfree buffer waits(62172.1)に関する通知を確認することもできます。これらの通知および関連通知にアクセスするには、次のURLで「busy buffer waits」と「free buffer waits」を検索する方法もあります。

http://support.oracle.com/

関連項目:

- 表10-1に示した各イベントの詳細およびクロスチェックするその他の情報は、「待機イベント統計」を参照してください。

- 動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

10.2.4 その他の統計情報

対応する待機イベントのない一部の統計にも、パフォーマンスの問題を示す情報が含まれる場合があります。

10.2.4.1 REDOログ領域リクエスト統計

V$SYSSTAT統計のredo log space requestsは、サーバー・プロセスが、REDOログ・バッファの領域ではなく、オンラインREDOログの領域を待機した回数を示します。この統計および待機イベントは、LGWRではなく、チェックポイント、DBWRまたはアーカイバ・アクティビティのチューニングが必要であることを示しています。ログ・バッファの容量を増加しても役に立ちません。

10.2.4.2 読取り一貫性

システムは、一貫したビューを維持するために、ブロックの変更内容のロールバックに長時間を費やすことがあります。次の状況を考慮してください。

- 多数の小さいトランザクションがあり、変化が起こっている同じ表のバックグラウンド内でアクティブな長時間実行問合せが動作している場合、表の一貫読取りイメージを取得するために、問合せはこれらの変化を頻繁にロールバックする必要がある場合があります。次のV$SYSSTAT統計を比較して、変化が発生しているかどうかを判断します。

- consistentchanges: 統計は、ブロックの読取り一貫性を実施するために、データベース・ブロックにロールバック・エントリが適用される回数を示します。多数のconsistent changesを生成するワークロードは、多数のリソースを消費する可能性があります。

- consistent gets: 統計は、一貫性モードでの論理読取り数をカウントします。

- 大きいロールバック・セグメントがほとんどない場合、システムはどのシステム変更番号(SCN)のトランザクションがコミットされたかを正確に知るために、遅延ブロックのクリーンアウト時に長時間かけてトランザクション表をロールバックする可能性があります。Oracle Databaseでトランザクションをコミットしたとき、変更されたブロックすべてがコミット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.2.4.3 継続行による表フェッチ

V$SYSSTAT内のtable fetch continued row統計数をチェックして、移行行または連鎖行を検出できます。少数の連鎖行(1%以下)は、システム・パフォーマンスに影響を与える可能性はほとんどありません。ただし、連鎖行のパーセンテージが大きいと、パフォーマンスに影響を与える可能性があります。

ブロック・サイズより大きい行の連鎖は避けられません。そのようなデータについては、ブロック・サイズのより大きい表領域の使用を考慮してください。

ただし、小さい行の場合は、適切な領域パラメータとアプリケーション設計を使用することで連鎖を回避できます。たとえば、キー値が入力され、かつその他のほとんどの列がNULLである行を挿入した後に、実際のデータで更新しないでください。その場合は初めからデータが入力された行を挿入します。

UPDATE文によって行のデータ量が増加し、行がそのデータ・ブロックに収まらなくなった場合、Oracle Databaseは行全体を保持するのに十分な空き領域を持つ別のブロックを見つけようとします。そのようなブロックが利用可能であれば、Oracle Databaseは新しいブロックへ行全体を移動します。この操作は、行の移行と呼ばれています。行が大きすぎて利用可能なブロックに収まらない場合、データベースはその行を複数の断片に分割し、各断片を別々のブロックに格納します。この操作は、行の連鎖と呼ばれています。データベースでは、行の挿入時にも行連鎖が発生する可能性があります。

移行と連鎖は、特に次の場合のパフォーマンスに影響があります。

- 移行と連鎖の原因となるUPDATE文のパフォーマンスはよくありません。

- 移行行または連鎖行が追加入出力を実行するため、これらの行を選択する問合せをします。

サンプルの出力表CHAINED_ROWSの定義が、配布媒体上の使用可能なSQLスクリプトに収録されています。このスクリプトの一般的な名前はUTLCHN1.SQLですが、正確な名前と位置は使用しているプラットフォームによって異なります。出力表の列名、データ型およびサイズは、CHAINED_ROWS表と同じである必要があります。

移行行を回避するには、PCTFREEを増やします。ブロック内に使用可能な空き領域を多く残しておくと、行の拡張に対処できます。削除割合が高い表と索引を再編成すなわち再作成することもできます。頻繁に行が削除される表の場合は、データブロックに部分的に空き領域が生じることがあります。行を挿入し後から拡張する場合、行の削除されたブロックにその行が挿入されることがありますが、拡張の余地はありません。表を再編成すると主な空き領域を完全に空のブロックにできます。

注意:
PCTUSEDは、PCTFREEの反対の意味ではありません。

関連項目:

- PCTUSEDの詳細は、『Oracle Database概要』を参照してください。

- 表の再編成の詳細は、『Oracle Database管理者ガイド』を参照してください。

10.2.4.4 解析関連の統計

アプリケーションの解析が長くなるほど、競合の可能性が高くなり、システムの待機時間が長くなります。parse time CPU(CPU解析時間)がCPU時間の大半を占める場合、SQL文の実行ではなく解析に時間が消費されています。この場合には、アプリケーションはリテラルSQLを使用しているためにSQLを共有できないか、または共有プールの構成が適切でないことがあります。

関連項目:
第7章「メモリーの構成および使用方法」

統計により、Oracleが解析に費やした時間の長さを識別することができます。V$SYSSTATから解析関連の統計の問合せを行います。たとえば、次のようにします。

SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME IN (  'parse time cpu', 'parse time elapsed',
'parse count (hard)', 'CPU used by this session' );

様々な比率を計算することで、解析に問題があるかどうかを判断できます。

- parse time CPU / parse time elapsed
この比率は、解析に費やされる時間のうちのどのくらいが、ラッチなどのリソースに対する待機ではなく、解析操作自体によるものかを示します。比率1は良好であり、経過時間が競合率の高いリソースを待機するために費やされなかったことを示します。

- parse time CPU / CPU used by this session
この比率は、Oracleサーバー・プロセスで使用されるCPU全体のうちのどのくらいが解析関係の操作で費やされたかを示します。0(ゼロ)に近い値ほど良好であり、CPUの大部分が解析に費やされないことを示します。

10.3 待機イベント統計

V$SESSION、V$SESSION_WAIT、V$SESSION_HISTORY、V$SESSION_EVENTおよびV$SYSTEM_EVENTの各ビューは、どのようなリソースを待機したかに関する情報を表示し、構成パラメータTIMED_STATISTICSがtrueに設定されている場合は、各リソースを待機した時間に関する情報も表示されます。

関連項目:

- STATISTICS_LEVELの設定の詳細は、「統計収集のレベルの設定」を参照してください。

- V$ビューおよびOracle待機イベントの詳細は、『Oracle Databaseリファレンス』を参照してください。

パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・データを調査します。最大時間がリストされるイベントは、多くの場合、パフォーマンス・ボトルネックを顕著に示しています。

次の各ビューには、同じデータの関連する(ただし、異なる)ビューが含まれています。

- V$SESSIONは、各現行セッションのセッション情報をリストします。このビューには、現在待機されているイベントか、各セッションで最後に待機されたイベントがリストされます。また、このビューには、ブロック・セッション、待機状態および待機時間に関する情報も含まれます。

- V$SESSION_WAITは、現在の状態ビューです。このビューには、現在待機されているイベントか、各セッションで最後に待機されたイベント、待機状態および待機時間がリストされます。

- V$SESSION_WAIT_HISTORYは、各現行セッションの最新10件の待機イベントと、関連する待機時間をリストします。

- V$SESSION_EVENTは、各セッションで待機されるイベントの累積履歴をリストします。セッションが終了した後、そのセッションに対する待機イベント統計はこのビューから削除されます。

- V$SYSTEM_EVENTは、インスタンスの起動以降にインスタンス全体により待機されるイベントと回数(すなわち、ロールアップされた、すべてのセッション待機イベント・データ)をリストします。

V$SESSION_WAITは現在の状態ビューであるため、V$SESSION_EVENTまたはV$SYSTEM_EVENTよりも細かい単位の情報も含まれています。このビューには、P1、P2およびP3の3つのパラメータ列があり、現行イベントの追加識別データが含まれます。

たとえば、V$SESSION_EVENTはセッション124(SID=124)がdb file scattered readで多く待機していたことを示すことはできますが、どのファイルとブロック番号かは示しません。ただし、V$SESSION_WAITはP1内のファイル番号、P2内に読み取られたブロック番号およびP3内に読み取られたブロック数を示します(P1とP2により待機イベントがどのセグメントに対して発生するかを判断できます)。

この項では、V$SESSION_WAITの使用例を中心に説明します。ただし、時間間隔のパフォーマンス・データの収集と、パフォーマンスおよび容量分析のためにこのデータを保存することをお薦めします。この形式のロールアップ・データの問合せは、AWRによりV$SYSTEM_EVENTビューで行います。「自動ワークロード・リポジトリの概要」を参照してください。

最も一般的に発生するイベントについては、この章で、大/小文字を区別するアルファベット順にリストして説明します。調べる対象の他のイベント関連データも含まれています。各イベント名に使用する大/小文字区別は、V$SYSTEM_EVENTビューでの表示と同一です。

Oracle Database 11gでは、待機イベントの待機カウントおよびタイムアウトの累計が過去のリリースとは異なります(V$SYSTEM_EVENTビューなど)。特定のタイプのリソース(エンキューなど)に対する継続的な待機は、内部で短時間の待機コールのセットに分割されます。前のリリースでは、個々の内部の待機コールが、別々の待機としてカウントされていました。リリース11.1から、待機中にセッションで発生した内部タイムアウトの回数にかかわらず、1つのリソースに対する待機は、1つの待機として記録されます。

Oracle Databaseでは、この変更により、待機カウントをより忠実に表現し、リソースの合計待機時間を正確に表示できます。タイムアウトは、個々の内部の待機コールではなく、リソースの待機を参照するようになりました。この変更は、平均待機時間および最大待機時間にも影響を与えます。たとえば、トランザクション行をロックして表の1行を更新するために、ユーザー・セッションがエンキューを待機する必要があり、そのエンキューを取得するのに10秒かかった場合、Oracle Databaseでは、エンキューの待機を3秒間の待機コールに分割します。この例では、3秒間の待機コールが3回と、1秒間の待機コールが1回です。ただし、セッションの観点からは、エンキューの待機は1回のみです。

前のリリースでは、この待機シナリオは、V$SYSTEM_EVENTビューで次のように表現されます。

- TOTAL_WAITS: 待機回数4(3秒間の待機が3回、1秒間の待機が1回)

- TOTAL_TIMEOUTS: タイムアウト回数3(最初の3回の待機はタイムアウトになり、最後の待機中にエンキューを取得)

- TIME_WAITED: 10秒(4回の待機時間の合計)

- AVERAGE_WAIT: 2.5秒

- MAX_WAIT: 3秒

Oracle Database 11gでは、この待機シナリオは次のように表現されます。

- TOTAL_WAITS: 待機回数1(10秒間の待機が1回)

- TOTAL_TIMEOUTS: タイムアウト回数0(リソースの待機中にエンキューを取得)

- TIME_WAITED: 10秒(リソースを待機した時間)

- AVERAGE_WAIT: 10秒

- MAX_WAIT: 10秒

この変更の影響を受ける一般的な待機イベントは次のとおりです。

- エンキュー待機(enq: name - reason待機など)

- ライブラリ・キャッシュ・ロック待機

- ライブラリ・キャッシュ・ピン待機

- 行キャッシュ・ロック待機

この変更の影響を受ける統計情報は次のとおりです。

- 待機回数

- 待機のタイムアウト回数

- 平均待機時間

- 最大待機時間

この変更の影響を受けるビューは次のとおりです。

- V$EVENT_HISTOGRAM

- V$EVENTMETRIC

- V$SERVICE_EVENT

- V$SERVICE_WAIT_CLASS

- V$SESSION_EVENT

- V$SESSION_WAIT

- V$SESSION_WAIT_CLASS

- V$SESSION_WAIT_HISTORY

- V$SYSTEM_EVENT

- V$SYSTEM_WAIT_CLASS

- V$WAITCLASSMETRIC

- V$WAITCLASSMETRIC_HISTORY

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

10.3.1 バッファ・ビジー待機

この待機は、複数のプロセスがバッファ・キャッシュ内のいくつかのバッファに同時にアクセスしようとしていることを示します。バッファのクラスごとに、待機統計についてV$WAITSTATを問い合せます。バッファ・ビジー待機を持つ一般的なバッファ・クラスには、data block、segment header、undo headerおよびundo blockがあります。

次のV$SESSION_WAITパラメータ列をチェックします。

- P1: ファイルID

- P2: ブロックID

- P3: クラスID

10.3.1.1 原因

考えられる原因を判別するには、最初にV$SESSIONを問い合せて、セッションがbuffer busy waitsを待機しているときのROW_WAIT_OBJ#の値を識別します。たとえば、次のようにします。

SELECT row_wait_obj#
FROM V$SESSION
WHERE EVENT = 'buffer busy waits';

競合対象のオブジェクトとオブジェクト型を識別するには、V$SESSIONから戻されるROW_WAIT_OBJ#の値を使用してDBA_OBJECTSを問い合せます。たとえば、次のようにします。

SELECT owner, object_name, subobject_name, object_type
FROM DBA_OBJECTS
WHERE data_object_id = &row_wait_obj;

10.3.1.2 処置

必要な処置は、競合対象のクラスと実際のセグメントにより異なります。

10.3.1.2.1 セグメント・ヘッダー

競合がセグメント・ヘッダー上にある場合、これは最も起こりうる空きリストの競合です。

ローカルに管理されている表領域で自動セグメント領域管理を行えば、PCTUSED、FREELISTSおよびFREELIST GROUPSの各パラメータを指定する必要はありません。可能であれば、手動領域管理から自動セグメント領域管理(ASSM)に切り替えます。

ASSMを使用できない場合(たとえば、表領域でディクショナリ領域管理を使用しているため)、これに関連する情報は次のとおりです。

空きリストは、通常セグメントの様々なエクステント内に存在するブロックを含む空きデータ・ブロックのリストです。空きリストは、空き領域がPCTFREEに達していないブロック、または使用済領域がPCTUSEDを下回っているブロックで構成されます。FREELISTSパラメータでプロセスの空きリスト数を指定します。FREELISTSのデフォルト値は1です。最大値はデータ・ブロック・サイズによって決まります。

そのセグメントの空きリストに対する現在の設定を見つけるには、次を実行します。

SELECT SEGMENT_NAME, FREELISTS
FROM DBA_SEGMENTS
WHERE SEGMENT_NAME = segment name
AND SEGMENT_TYPE = segment type;

空きリスト、または空きリスト数の増分を設定します。さらに空きリストを追加しても問題が軽減されない場合は、空きリスト・グループを使用します(このようにすると、単一のインスタンス内でも違いが出る可能性があります)。Oracle RACを使用する場合、各インスタンスに独自の空きリスト・グループがあることを確認してください。

関連項目:
自動セグメント領域管理、空きリスト、PCTFREEおよびPCTUSEDの詳細は、『Oracle Database概要』を参照してください。

10.3.1.2.2 データ・ブロック

表または索引(セグメント・ヘッダーではない)に対する競合がある場合、次のようにします。

- 昇順インデックスを調べます。これは、多数のプロセスによって同じ点に挿入される索引です。たとえば、キー値に順序番号ジェネレータを使用する索引をチェックしてください。

- ASSMの使用またはグローバル・ハッシュ・パーティション索引の使用を検討します。また、複数のプロセスによる同一ブロックへの挿入を回避するために空きリストの増加も検討してください。

10.3.1.2.3 UNDOヘッダー

ロールバック・セグメント・ヘッダーに対する競合の場合

- 自動UNDO管理を使用しない場合は、さらにロールバック・セグメントを追加してください。

10.3.1.2.4 UNDOブロック

ロールバック・セグメント・ブロックに対する競合の場合

- 自動UNDO管理を使用しない場合は、ロールバック・セグメント・サイズを大きくすることを検討してください。

10.3.2 db file scattered read

このイベントは、ユーザー・プロセスがSGAバッファ・キャッシュにバッファを読み取り、物理I/Oコールが戻るまで待機することを意味します。db file scattered readは、データを複数の不連続メモリー位置に読み取るために散布読取りを発行します。散布読取りは通常、マルチブロック読取りです。全体スキャンの他、(索引の)高速全スキャンでも行うことができます。

db file scattered read待機イベントは、全体スキャンが発生していることを識別します。バッファ・キャッシュへの全体スキャンを実行すると、読み取られたブロックは物理的に相互に接近していないメモリー位置に読み取られます。このような読取りが散布読取りコールと呼ばれるのは、ブロックがメモリー全体に分散されているからです。対応する待機イベントが「db file scattered read」と呼ばれるのは、このためです。バッファ・キャッシュへの全体スキャンのためのマルチブロック(最大でDB_FILE_MULTIBLOCK_READ_COUNTブロック)読取りは、db file scattered readに対する待機として現れます。

次のV$SESSION_WAITパラメータ列をチェックします。

- P1: 絶対ファイル番号

- P2: 読み取られるブロック

- P3: ブロック数(1より大きい値が必要)

10.3.2.1 処置

正常なシステムで、物理読取り待機はアイドル待機後の最大の待機になります。ただし、小さい索引付きアクセスを行う必要のある運用(OLTP)システム上に、直接読取り待機(パラレル問合せによる全表スキャンを意味する)またはdb file scattered read待機があるかどうかも確認してください。

システム上の過剰なI/O負荷を示す他の要素として、次のものがあります。

- 低いバッファ・キャッシュ・ヒット率

- ユーザーへのレスポンス時間を長くしている待機時間のほとんどを発生させている待機イベント

10.3.2.2 過剰なI/Oの管理

過剰なI/O待機には、様々な対処方法があります。有効性の順に示すと、これらの方法は次のとおりです。

- SQLチューニングによるI/Oアクティビティの削減。

- ワークロードの管理による、I/Oを実行する必要性の削減。

- DBMS_STATSパッケージを使用したシステム統計の収集。問合せオプティマイザによる、全体スキャンを使用する可能性のあるアクセス・パスのコストの正確な見積りが可能になります。

- 自動ストレージ管理の使用。

- さらに多くのディスクを追加することによる、各ディスクのI/O数の削減。

- 既存のディスク間へのI/Oの再分散によるI/Oホット・スポットの削減。

関連項目:
第8章「I/O構成および設計」

最初に行うことは、I/Oを削減するためのチャンスを見つけることです。これらのイベントを待機するセッションによって実行されるSQL文と、V$SQLAREAから多数の物理I/Oを実行する文を調査します。過剰なI/Oを実行し、実行計画にマイナスの影響を与える可能性のある要因として、次のものがあります。

- 不適切に最適化されたSQL

- 索引の欠落

- 表の高度な並列度(スキャン方向へオプティマイザを偏らせる)

- オプティマイザの正確な統計がないこと

- DB_FILE_MULTIBLOCK_READ_COUNT初期化パラメータの設定値が全体スキャンには大きすぎること

10.3.2.3 不十分なI/O分散

I/Oを削減する他、ディスク間のファイルのI/O分散も調べます。I/Oはディスク間に均等に分散されていますか、あるいは、いくつかのディスク上にホット・スポットがありますか。データベースのI/Oリクエストを満たすだけの十分な個数のディスクがありますか。

データベースによるI/O操作(読取りと書込み)の総数を調べ、それと使用したディスク数を比較します。必ず、LGWRプロセスとARCHプロセスのI/Oアクティビティを含めてください。

10.3.2.4 I/Oを待機しているセッションで実行されたSQL文の検索

次の問合せを使用して、ある時点でどのセッションがI/Oを待機しているかを判断します。

SELECT SQL_ADDRESS, SQL_HASH_VALUE
FROM V$SESSION
WHERE EVENT LIKE 'db file%read';

10.3.2.5 I/Oを必要とするオブジェクトの検索

考えられる原因を判別するには、最初にV$SESSIONを問い合せて、セッションがdb file scattered readを待機しているときのROW_WAIT_OBJ#の値を識別します。たとえば、次のようにします。

SELECT row_wait_obj#
FROM V$SESSION
WHERE EVENT = 'db file scattered read';

競合対象のオブジェクトとオブジェクト型を識別するには、V$SESSIONから戻されるROW_WAIT_OBJ#の値を使用してDBA_OBJECTSを問い合せます。たとえば、次のようにします。

SELECT owner, object_name, subobject_name, object_type
FROM DBA_OBJECTS
WHERE data_object_id = &row_wait_obj;

10.3.3 db file sequential read

このイベントは、ユーザー・プロセスがSGA内のバッファ・キャッシュにバッファを読み取り、物理I/Oコールが戻るまで待機することを意味します。順次読取りは、単一ブロック読取りです。

単一ブロックI/Oは通常、索引を使用した結果です。非常にまれなケースとして、エクステントの境界のため、またはバッファ・キャッシュ内にバッファが存在するため、全表スキャン・コールが単一ブロック・コールに切り捨てられることがあります。これらの待機もdb file sequential readとして現れます。

次のV$SESSION_WAITパラメータ列をチェックします。

- P1: 絶対ファイル番号

- P2: 読み取られるブロック

- P3: ブロック数(値は1)

関連項目:
過剰I/Oの管理、不適切なI/O分散、さらにI/Oを発生させるSQLおよびI/Oが実行されるセグメントの検索の詳細は、「db file scattered read」を参照してください。

10.3.3.1 処置

正常なシステムで、物理読取り待機はアイドル待機後の最大の待機になります。ただし、パラレル問合せによる全表スキャンを多く実行する必要のある大規模なデータ・ウェアハウスに対するdb file sequential readsがあるかどうかも確認してください。

図10-1は、次の待機イベント間の違いを示したものです。

- db file sequential read(1つのSGAバッファに読み取られる単一ブロック)

- db file scattered read(多数の不連続SGAバッファに読み取られるマルチブロック)

- direct read(SGAをバイパスして、PGAに読み取られる単一またはマルチブロック)

図10-1 散布読取り、順次読取りおよびダイレクト・パス読取り

10.3.4 direct path readおよびdirect path read temp

SGAのバッファ・キャッシュではなく、ディスクからPGAに直接バッファの読取りを実行しているセッションは、このイベントで待機します。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: 読取りコールのブロック数

10.3.4.1 原因

これは次の状況で発生します。

- ソートが大きすぎてメモリーに収まらないため、ソート・データの一部がディスクに直接書き出される。そのデータは、直接読取りで後から再度読み取られます。

- パラレル・スレーブが、データのスキャンに使用される。

- サーバー・プロセスが、I/Oシステムがバッファを戻すより早くバッファを処理する。これは過負荷のI/Oシステムを示します。

10.3.4.2 処置

file_idは、読取りがTEMP表領域内のオブジェクトに対するもの(ディスクへのソート)か、パラレル・スレーブによる全表スキャンに対するものかを示します。この待機は、大規模なデータ・ウェアハウス・サイトでは最大の待機です。ただし、ワークロードが意思決定支援システム(DSS)ワークロードでない場合は、この状況が発生した理由を調査してください。

10.3.4.2.1 ディスクへのソート

待機が発生しているセッションで、現在実行されているSQL文を調べて、ソートの原因を確認します。ソートを生成するSQL文を検索するために、V$TEMPSEG_USAGEを問い合せます。また、ソートのサイズを決定するセッションに関するV$SESSTATからの統計を問い合せます。SQL文をチューニングしてソートを削減できるかどうかを確認します。WORKAREA_SIZE_POLICYがMANUALである場合、システム(ソートが大きすぎない場合)または個々のプロセスのSORT_AREA_SIZEを大きくすることを検討します。WORKAREA_SIZE_POLICYがAUTOである場合、PGA_AGGREGATE_TARGETを大きくするかどうかを調べます。「PGAメモリー管理」を参照してください。

10.3.4.2.2 全表スキャン

高い並列度で表を定義すると、全表スキャンをパラレル・スレーブで検索するようにオプティマイザを偏らせることができます。ダイレクト・パス読取りを使用して読み取るオブジェクトをチェックします。全表スキャンが有効なワークロード部分である場合は、I/Oサブシステムが並列度に対して適切かどうかを確認します。ディスクのストライプ化またはOracle Automatic Storage Management(Oracle ASM)を使用していない場合は、ディスクのストライプ化を使用することを検討してください。

10.3.4.2.3 ハッシュ領域サイズ

ハッシュ結合を呼び出す問合せ計画の場合、過剰なI/OはHASH_AREA_SIZEが小さすぎることから発生する可能性があります。WORKAREA_SIZE_POLICYがMANUALである場合、システムまたは個々のプロセスのHASH_AREA_SIZEを大きくすることを検討してください。WORKAREA_SIZE_POLICYがAUTOである場合、PGA_AGGREGATE_TARGETを大きくするかどうかを調べます。

関連項目:

- 「過剰なI/Oの管理」

- 「PGAメモリー管理」

10.3.5 direct path writeおよびdirect path write temp

プロセスがバッファをPGAから直接書き込む(バッファ・キャッシュからバッファを書き込むDBWRとは反対)場合、プロセスは書込みコールが完了するまでこのイベント上で待機します。ダイレクト・パス書込みを実行する可能性のある操作には、ディスクでのソート、パラレルDML操作、ダイレクト・パスINSERT、パラレルCREATE TABLE AS SELECT処理、およびいくつかのLOB操作があります。

ダイレクト・パス読取りと同様に、I/Oサブシステムが非同期書込みをサポートする場合、待機数は発行された書込みコール数と同じではありません。セッションがPGA内のすべてのバッファを処理し、I/Oリクエストが完了するまで処理を継続できない場合、セッションは待機します。

関連項目:
ダイレクト・パス・インサートの詳細は、『Oracle Database管理者ガイド』を参照してください。

次のV$SESSION_WAITパラメータ列をチェックします。

- P1: 書込みコールのFile_id

- P2: 書込みコールのStart block_id

- P3: 書込みコール内のブロック数

10.3.5.1 原因

これは次の状況で発生します。

- ソートが大きすぎ、メモリー内に収まらないため、ディスクに書き込まれる。

- オブジェクトを作成/移入するために、パラレルDMLが発行される。

- ダイレクト・パス・ロード。

10.3.5.2 処置

大規模なソートは、「ディスクへのソート」を参照してください。

パラレルDMLについては、ディスク間のI/O分散をチェックし、I/Oサブシステムが並列度に対して適切に構成されているかどうかを確認してください。

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

10.3.6.1 ロックおよびロック・ホルダーの検索

ロックを保持するセッションを見つけるには、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;

10.3.6.2 処置

適切な処置は、エンキューのタイプにより異なります。

10.3.6.2.1 STエンキュー

競合されたエンキューがSTエンキューである場合、問題は動的な領域割当てにある可能性が最も高いと言えます。セグメントにそれ以上空き領域がない場合、Oracle Databaseはセグメントにエクステントを動的に割り当てます。このエンキューは、ディクショナリ管理表領域にのみ使用します。

このリソースに対する競合を解決するには、次のようにします。

- 一時(すなわち、ソート)表領域がTEMPFILESを使用するかどうかを確認します。使用しない場合は、TEMPFILESを使用するように切り替えます。

- 動的に拡張するセグメントを含む表領域がディクショナリ管理表領域の場合は、ローカル管理表領域を使用するように切り替えます。

関連項目:
TEMPFILEおよびローカル管理表領域の詳細は、『Oracle Database概要』を参照してください。

- ローカル管理表領域に切り替えることができない場合は、拡張するオブジェクトの次のエクステント・サイズを、一定の領域割当てを回避できる十分な大きさに変更することによって、STエンキュー・リソースの使用量を減らすことができます。どのセグメントが常に拡張するかを判断するには、すべてのSEGMENT_NAMEについてDBA_SEGMENTSビューのEXTENTS列を監視します。領域使用情報の表示の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ALTER TABLE ALLOCATE EXTENT SQL文でエクステントを割り当てるなどして、セグメント内の領域を事前に割り当てます。

10.3.6.2.2 HWエンキュー

HWエンキューは、セグメントの最高水位標を超える領域の割当てをシリアライズする場合に使用します。

- V$SESSION_WAIT.P2 / V$LOCK.ID1は表領域番号です。

- V$SESSION_WAIT.P3 / V$LOCK.ID2は、領域が割り当てられるオブジェクトのセグメント・ヘッダーの相対データ・ブロック・アドレス(DBA)です。

これがオブジェクトの競合点である場合、エクステントの手動割当てにより問題が解決されます。

10.3.6.2.3 TMエンキュー

TMロック上の待機の最も一般的な理由は、制約される列が索引付けされない場合の外部キー制約に関係している傾向があります。この問題を回避するには、外部キー列を索引付けします。

10.3.6.2.4 TXエンキュー

これらのロックは、トランザクションがその最初の変更を開始するときに排他的に取得され、トランザクションがCOMMITまたはROLLBACKを行うまで保持されます。

- モード6のTXの待機は、あるセッションが別のセッションによって保持されている行レベル・ロックを待機しているときに発生します。これは、あるユーザーがある行を更新または削除し、別のセッションがその行を更新または削除する場合に発生します。このタイプのTXエンキュー待機は、待機イベントenq: TX - row lock contentionに対応します。
解決方法は、ロックを保持している最初のセッションにCOMMITまたはROLLBACKを実行させることです。

- モード4のTXの待機は、セッションがブロック内でITL(必要なトランザクション・リスト)スロットを待機している場合に発生する可能性があります。これは、セッションがそのブロック内の行をロックしても、1つ以上の他のセッションの行が同じブロックでロックされ、そのブロック内に空きITLスロットがない場合に発生します。通常は、Oracle Databaseが別のITLスロットを動的に追加します。この操作は、ITLを追加するためのブロック内の空き領域が十分にない場合には実行できません。空き領域が十分にある場合、セッションはモード4でTXエンキューを持つスロットを待機します。このタイプのTXエンキュー待機は、enq: TX - allocate ITL entryに対応します。
解決方法は、表のINITRANSまたはMAXTRANSを変更する(ALTER文を使用するか、それより高い値で表を再作成する)ことによって使用可能なITLの個数を増やすことです。

- モード4のTXの待機は、セッションがUNIQUE索引内の潜在的な重複のためにセッションが待機している場合にも発生します。2つのセッションが同じキー値を挿入しようとする場合、第2のセッションはORA-0001が発生したかどうかを確認するまで、待機する必要があります。このタイプのTXエンキュー待機は、待機イベントenq: TX - row lock contentionに対応します。
解決方法は、ロックを保持している最初のセッションにCOMMITまたはROLLBACKを実行させることです。

- モード4のTXの待機は、共有ビットマップ・インデックス・フラグメントのためにセッションが待機している場合にも可能です。ビットマップ索引は、キー値とROWIDの範囲を索引付けします。ビットマップ索引内の各エントリは、実際の表中の多数の行をカバーできます。2つのセッションが同じビットマップ索引フラグメントでカバーされる行を更新する場合、第2のセッションは、モード4でTXロックを待機して、第1のトランザクションのCOMMITまたはROLLBACKを待機します。このタイプのTXエンキュー待機は、待機イベントenq: TX - row lock contentionに対応します。

- モード4でのTXの待機は、PREPAREDトランザクションを待機している場合にも発生する可能性があります。

- モード4のTXの待機は、索引に1行を挿入するトランザクションが、他のトランザクションによる索引ブロック分割の終了を待つ必要がある場合にも発生します。このタイプのTXエンキュー待機は、待機イベントenq: TX - index contentionに対応します。

関連項目:
参照整合性およびデータの明示的ロックの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

10.3.7 Other待機クラスのイベント

このイベントは、「その他」の待機クラスに属し、通常はシステムで発生しないようにしてください。このイベントは、latch freeなど、「その他」の待機クラスのその他すべてのイベントの集計であり、V$SESSION_EVENTおよびV$SERVICE_EVENTビューでのみ使用されます。これらのビューでは、「その他」待機クラスのイベントは、セッションごとにはメンテナンスされません。かわりに、この1つのイベントにロール・アップされ、「その他」待機クラスのイベント統計をメンテナンスするためのメモリーを削減します。

10.3.8 free buffer waits

この待機イベントは、サーバー・プロセスが空きバッファを検索できず、使用済バッファを書き出すことによって空きバッファを作成するためにデータベース・ライターを転送したことを示します。使用済バッファは、内容が変更されたバッファです。使用済バッファは、DBWRがブロックをディスクに書き込み終えると、再利用するために解放されます。

10.3.8.1 原因

DBWRは、次の状況では使用済バッファの書込みを継続できない場合があります。

- I/Oシステムが低速である。

- I/Oシステムが待機しているラッチなどのリソースがある。

- バッファ・キャッシュが小さすぎるため、DBWRはサーバー・プロセスのバッファのクリーニングに大部分の時間を費やす。

- バッファ・キャッシュが大きすぎるため、DBWRプロセスはリクエストを満たすだけのキャッシュ内のバッファを十分に解放できない。

10.3.8.2 処置

このイベントが頻繁に発生する場合は、DBWRに対するセッション待機を調べて、DBWRを遅らせる原因があるかどうかを確認してください。

10.3.8.2.1 書込み

セッションが書込みを待機している場合は、書込みを遅らせている原因を解明し、修正してください。次の点をチェックします。

- V$FILESTATを調べて、書込みの大半が発生する場所を確認してください。

- I/Oシステムのホスト・オペレーティング・システム統計を調べてください。書込み時間は許容できるものですか。

I/Oが低速である場合は、次のようにしてください。

- さらに高速なI/O手段を使用して書込み時間を高速化することを検討してください。

- 多数のスピンドル(ディスク)とコントローラの間にI/Oアクティビティを拡散してください。I/Oバランシングについては、第8章「I/O構成および設計」を参照してください。

10.3.8.2.2 キャッシュが小さすぎる場合

キャッシュが小さすぎるためにDBWRが非常にアクティブである可能性があります。バッファ・キャッシュ・ヒット率が低いかどうかを確認して、これが考えられる原因であるかどうかを調べます。また、V$DB_CACHE_ADVICEビューを使用して、それより大きいキャッシュ・サイズが有利かどうかを判断します。「バッファ・キャッシュのサイズ設定」を参照してください。

10.3.8.2.3 キャッシュが1つのDBWRに対して大きすぎる場合

キャッシュ・サイズが適切であり、I/Oが均等に分散されている場合は、非同期I/Oを使用するか、複数のデータベース・ライターを使用して、DBWRの動作を修正できます。

10.3.8.3 複数のデータベース・ライター(DBWR)・プロセスまたはI/Oスレーブの検討

複数のデータベース・ライター・プロセスを構成したり、I/Oスレーブを使用するのは、トランザクション・レートが高い場合や、バッファ・キャッシュ・サイズが大きすぎて単一のDBWnプロセスが負荷に耐えられない場合に役立ちます。

10.3.8.3.1 DB_WRITER_PROCESSES

DB_WRITER_PROCESSES初期化パラメータを使用すると、複数のデータベース・ライター・プロセス(DBW0からDBW9までと、DBWaからDBWj)を構成できます。複数のDBWRプロセスを構成すると、書き込まれるバッファの識別に必要な作業が分散され、また、これらのプロセス間にI/O負荷もが分散されます。複数のデータベース・ライター・プロセスは、複数のCPUを持つシステム(CPU 8つにつき最低1つのデータベース・ライター)や、複数のプロセッサ・グループを持つシステム(最低でプロセス・グループと同数のデータベース・ライター)にお薦めします。

Oracle Databaseでは、CPU数またはプロセッサ・グループ数に基づいて、DB_WRITER_PROCESSESに適切なデフォルト設定を選択するか、ユーザー定義の設定を調整します。

10.3.8.3.2 DBWR_IO_SLAVES

複数のDBWRプロセスを使用することが実用的ではない場合、Oracle Databaseには複数のスレーブ・プロセス間にI/O負荷を分散する機能があります。DBWRプロセスは、ブロックを書き出すためにバッファ・キャッシュLRUリストをスキャンする唯一のプロセスです。ただし、これらのブロックのI/OはI/Oスレーブで実行されます。I/Oスレーブの個数は、DBWR_IO_SLAVESパラメータで決定されます。

DBWR_IO_SLAVESは、(CPUが1つの場合など)複数のDB_WRITER_PROCESSESを使用できない場合を想定しています。I/Oスレーブは、非同期I/Oが使用できないときにも役立ちます。これは、書き込まれるキャッシュ内のブロックの識別を継続するためにDBWRを解放することによって、複数のI/Oスレーブが非同期の非ブロック・リクエストをシミュレートするためです。一般的に、非同期I/Oがある場合、オペレーティング・システム・レベルの非同期I/Oをお薦めします。

DBWRのI/Oスレーブは、初回のI/Oリクエストが実行されるときに、データベースが開いた直後に割り当てられます。DBWRは、I/Oの実行とは別に、DBWR関連のすべての作業の実行を継続します。I/Oスレーブは単に、DBWRのためにI/Oを実行します。バッチの書込みはI/Oスレーブ間でパラレル化されます。

注意:
DBWR_IO_SLAVESを実装するには、余分な共有メモリーをI/Oバッファとリクエスト・キューに割り当てる必要があります。複数のDBWRプロセスをI/Oスレーブと併用することはできません。I/Oスレーブを構成すると、1つのDBWRプロセスのみ起動するように設定されます。

10.3.8.3.3 複数のDBWRプロセスとI/Oスレーブの選択

複数のDBWRプロセスを構成すると、単一のDBWRプロセスでは必要なワークロードに耐えられない場合のパフォーマンスに役立ちます。ただし、複数のDBWRプロセスを構成する前に、非同期I/Oが使用でき、システム上に構成されるかどうかを確認します。システムが非同期I/Oをサポートしても現在使用されていない場合は、複数のDBWRプロセスを構成すると問題が軽減されるかどうかを確認するために非同期I/Oを使用可能にします。システムが非同期I/Oをサポートしない場合、または非同期I/Oが構成され、DBWRボトルネックが依然として存在する場合は、複数のDBWRプロセスを構成します。

注意:
プラットフォーム上で非同期I/Oを使用できない場合は、DISK_ASYNCH_IO初期化パラメータをFALSEに設定して非同期I/Oを無効にできます。

複数のDBWRを使用すると、バッファの収集と書込みがパラレル化されます。そのため、複数のDBWnプロセスは同じ数のI/Oスレーブを使用する1つのDBWRプロセスよりもスループットを向上します。このため、複数のDBWRプロセスを優先して、I/Oスレーブの使用は非推奨になりました。I/Oスレーブは、複数のDBWRプロセスを構成できない場合のみ使用してください。

10.3.9 アイドル待機イベント

これらのイベントはIdle待機クラスに属し、作業がないためにサーバー・プロセスが待機中であることを示します。これは通常、ボトルネックが存在する場合にボトルネックがデータベース・リソースに対するものではないことを意味します。チューニングの際、アイドル・イベントの大部分を無視することが必要なのは、アイドル・イベントがパフォーマンス・ボトルネックの性質を示さないためです。アイドル・イベントの中には、ボトルネックでないものを示す際に役立つものがあります。このタイプのイベントの例として、最も一般的に発生するアイドル待機イベントであるSQL Net message from clientがあります。表10-2に、このアイドル・イベントと他のアイドル・イベント(およびそれらのカテゴリ)のリストを示します。

表10-2 アイドル待機イベント

待機名

バックグラウンド・プロセス・アイドル・イベント

ユーザー・プロセス・アイドル・イベント

パラレル問合せアイドル・イベント

共有サーバー・アイドル・イベント

Oracle Real Application Clustersアイドル・イベント

dispatcher timer

.

.

.

×

.

pipe get

.

×

.

.

.

pmon timer

×

.

.

.

.

PX Idle Wait

.

.

×

.

.

PX Deq Credit: need buffer

.

.

×

.

.

rdbms ipc message

×

.

.

.

.

shared server idle wait

.

.

.

×

.

smon timer

×

.

.

.

.

SQL*Net message from client

.

×

.

.

.

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

10.3.10 ラッチ・イベント

ラッチは、メモリー構造を保護するためにOracle Databaseで使用される下位レベルの内部ロックです。ラッチ解放イベントは、サーバー・プロセスがラッチを取得しようとしたときに更新され、ラッチは最初の試行で使用できなくなります。

通常は大きな競合を生成する一般的なラッチ用に、専用のラッチ関連待機イベントがあります。これらのイベントの場合は、latch: library cacheまたはlatch: cache buffers chainsのように、ラッチ名が待機イベント名に含まれます。このため、ラッチに関連するほとんどの競合の原因が特定のタイプのラッチであるかどうかをすばやく確認できます。他のすべてのラッチの待機は、汎用のlatch free待機イベントにグループ化されています。

関連項目:
ラッチおよび内部ロックの詳細は、『Oracle Database概要』を参照してください。

10.3.10.1 処置

このイベントは、ラッチ待機がシステム上の待機時間全体の重要な部分である場合か、または問題が発生している個々のユーザーに対してのみかを考慮してください。

- 関連するリソースのリソース使用量を調べます。たとえば、ライブラリ・キャッシュ・ラッチの競合が大きい場合は、ハードとソフトの解析率を調べます。

- ラッチ競合が発生しているセッションのSQL文を調べて、共通性があるかどうかを確認してください。

次のV$SESSION_WAITパラメータ列をチェックします。

- P1: ラッチのアドレス

- P2: ラッチ番号

- P3: ラッチの待機中にプロセスがスリープした回数

10.3.10.2 例: 現在待機されているラッチの検索

SELECT EVENT, SUM(P3) SLEEPS, SUM(SECONDS_IN_WAIT) SECONDS_IN_WAIT
FROM V$SESSION_WAIT
WHERE EVENT LIKE 'latch%'
GROUP BY EVENT;

前述の問合せには、インスタンスまたは長期的なインスタンスのチューニングよりも、セッションのチューニングまたは短期的なインスタンスのチューニングに関して多くの情報が示されるという問題があります。

次の問合せは長期的なインスタンス・チューニングの詳細情報を提供し、ラッチの待機がデータベース全体の時間に占める割合が大きいかどうかを示します。

SELECT EVENT, TIME_WAITED_MICRO,
ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME
FROM V$SYSTEM_EVENT,
(SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S
WHERE EVENT LIKE 'latch%'
ORDER BY PCT_DB_TIME ASC;

ラッチ待機固有でない、より汎用的な問合せは次のようになります。

SELECT EVENT, WAIT_CLASS,
TIME_WAITED_MICRO,ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME
FROM V$SYSTEM_EVENT E, V$EVENT_NAME N,
(SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S
WHERE E.EVENT_ID = N.EVENT_ID
AND N.WAIT_CLASS NOT IN ('Idle', 'System I/O')
ORDER BY PCT_DB_TIME ASC;

表10-3 ラッチ待機イベント

ラッチ

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.3.10.3 共有プールとライブラリ・キャッシュ・ラッチの競合

共有プールまたはライブラリ・キャッシュ・ラッチの競合の主な原因は解析です。不要な解析およびそのタイプは、いくつかの方法によって識別できます。

- 非共有SQL

- 再解析された共有可能なSQL

- セッション別

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

- キャッシュ・バッファ連鎖

- 行キャッシュ・オブジェクト

10.3.10.3.1 非共有SQL

この方法では、リテラルがバインド変数と置換された場合に共有できる類似したSQL文を識別します。その概念は次のいずれかです。

- 実行を1つのみ持つSQL文を手動で検査して、SQL文が類似しているかどうかを確認します。

SELECT SQL_TEXT
FROM V$SQLSTATS
WHERE EXECUTIONS < 4
ORDER BY SQL_TEXT;

- または、類似した文をグループ化することによって、このプロセスを自動化します。類似した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;

10.3.10.3.2 再解析された共有可能なSQL

V$SQLSTATSビューをチェックします。次の問合せを入力してください。

SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS
FROM V$SQLSTATS
ORDER BY PARSE_CALLS;

PARSE_CALLSの値が指定の文のEXECUTIONS値に近い場合は、その文の再解析を継続できます。解析コールが多い文をチューニングします。

10.3.10.3.3 セッション別

不要な解析コールが発生しているセッションを識別して、不要なコールを識別します。特定のバッチ・プログラムやある種のアプリケーションがほとんどの再解析を行っている場合があります。この目的を達成するには、次の問合せを実行します。

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で、再解析の原因となっているプログラムの名前を検索します。

注意:
この問合せではインスタンス起動後のすべての解析コールがカウントされるため、解析率の高いセッションを検索することをお薦めします。たとえば、50日間の接続が高い解析値を示すとしても、2番目の10分間の接続の方がより速い速度で解析される場合があります。

出力は、次のようなものです。

SID  Hard Parses  Execute Count
------  -----------  -------------
7            1             20
8            3          12690
6           26            325
11           84           1619

10.3.10.3.4 キャッシュ・バッファLRU連鎖

cache buffers lru chainのラッチは、キャッシュ内のバッファのリストを保護します。リストからバッファの追加、移動または削除を行う場合、ラッチを取得する必要があります。

対称型マルチプロセッサ(SMP)システムでは、Oracle Databaseによって、LRUラッチの数がシステムのCPU数の2分の1に等しい値になるように自動的に設定されます。非SMPシステムでは、LRUラッチは1つあれば十分です。

LRUラッチの競合は、多数のCPUを搭載したSMPコンピュータでのパフォーマンスを低下させることがあります。LRUラッチの競合は、V$LATCH、V$SESSION_EVENTおよびV$SYSTEM_EVENTに問い合せることによって検出できます。競合を回避するには、アプリケーションのチューニング、DSSジョブのバッファ・キャッシュのバイパスまたはアプリケーションの再設計を検討してください。

10.3.10.3.5 キャッシュ・バッファ連鎖

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列の値です。

10.3.10.3.6 行キャッシュ・オブジェクト

row cache objectsのラッチは、データ・ディクショナリを保護します。

10.3.11 log file parallel write

このイベントには、ログ・バッファからREDOログ・ファイルへのREDOレコードの書込みが含まれます。

10.3.12 library cache pin

このイベントでは、ライブラリ・キャッシュの同時実行性を管理します。オブジェクトが確保されると、ヒープがメモリーへロードされます。クライアントがオブジェクトを修正または調査する場合、クライアントはロック後にPINを取得する必要があります。

10.3.13 library cache lock

このイベントは、ライブラリ・キャッシュのクライアント間の同時実行性を制御します。オブジェクト処理のロックが取得され、次のいずれかが可能になります。

- 1つのクライアントが、同一オブジェクトに対する他のクライアントからのアクセスを防止

- クライアントは、別のクライアントにオブジェクトの変更を許可しない依存関係を長期間維持

また、このロックはライブラリ・キャッシュにオブジェクトを配置するためにも取得されます。

10.3.14 log buffer space

このイベントは、サーバー・プロセスがログ・バッファ内の空き領域を待機しているときに発生します。これは、LGWRがREDOを書き出すよりも、すべてのREDOが生成されるほうが速いためです。

処置

REDOログ・バッファ・サイズを修正します。ログ・バッファのサイズが適切な場合、オンラインREDOログが存在するディスクでI/O競合が発生しないことを確認します。log buffer space待機イベントは、REDOログが存在するディスク上のディスクI/O競合を示しているか、小さすぎるログ・バッファを示している可能性があります。REDOログを含むディスクのI/Oプロファイルをチェックして、I/Oシステムがボトルネックであるかどうかを調べます。I/Oシステムが問題ではない場合、REDOログ・バッファが小さすぎる可能性があります。このイベントが問題にならなくなるまで、REDOログ・バッファのサイズを大きくします。

10.3.15 log file switch

一般に発生する待機イベントは、次の2つです。

- Log file switch (archiving needed)

- Log file switch (checkpoint incomplete)

これらのイベントが発生すると、LGWRは次のオンラインREDOログ・ファイルへの切替えができません。すべてのコミット・リクエストは、このイベントを待機します。

10.3.15.1 処置

log file switch (archiving needed)イベントの場合、アーカイバがログをアーカイブできない理由を適時調べます。次の理由が考えられます。

- アーカイブ先に空き領域が不足している。

- アーカイバがREDOログを十分高速に読み取れない(LGWRとの競合)。

- アーカイバが十分高速に書込みを行えない(アーカイブ先での競合、またはARCHプロセスの数が不足している)。その他の可能性(ディスクが低速であったり、アーカイブ先がいっぱいなど)が除外された場合は、ARCnプロセス数の増加を検討してください。デフォルトは2です。

- 必須でリモートに転送されるアーカイブ・ログがある場合は、ネットワーク遅延によってこのプロセスが遅くなっていないか、またはエラーによって書込みが完了していないかをチェックしてください。

ボトルネックの性質により、I/Oを再分散したり、アーカイブ先に領域を追加して問題を軽減することが必要な場合があります。log file switch (checkpoint incomplete)イベントの場合、次を実行してください。

- 過負荷または低速のI/OシステムであるためにDBWRが低速であるかどうかをチェックしてください。DBWR書込み時間およびI/Oシステムをチェックし、必要に応じてI/Oを分散します。第8章「I/O構成および設計」を参照してください。

- REDOログが少なすぎないか、または小さすぎないかをチェックしてください。REDOログが少なすぎるか小さすぎる場合(たとえば、2 x 100KBのログ)、またDBWRがチェックポイントを完了する前に、すべてのログを巡回する十分なREDOが生成される場合、REDOログのサイズまたは個数、あるいはその両方を増やします。「REDOログ・ファイルのサイズ指定」を参照してください。

10.3.16 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をバッチ処理することで、ログ・ファイルの同期が少なくてすみます。

10.3.17 rdbms ipc reply

このイベントは、バックグラウンド・プロセスのうちの1つから応答を待機する場合に使用します。

10.3.18 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イベントで説明したとおりに診断する必要があります。

10.3.18.1 SQL*Net message from client

これはアイドル・イベントですが、このイベントを診断に使用できるときに何が問題でないかを説明することが重要です。このイベントは、サーバー・プロセスがクライアント・プロセスからの処理を待機していることを示します。ただし、このイベントが、長いレスポンス時間を経験しているユーザーの待機時間の大半を生成している状況がいくつかあります。その原因は、ネットワーク・ボトルネックまたはクライアント・プロセスでのリソース・ボトルネックのいずれかである可能性があります。

10.3.18.1.1 ネットワーク・ボトルネック

ネットワーク・ボトルネックは、アプリケーションによってサーバーとクライアントとの間で多量の通信が発生し、ネットワークの待機時間(ラウンドトリップの時間)が長い場合に発生する可能性があります。症状には次のものがあります。

- このイベントに対する多数の待機

- データベースとクライアント・プロセスは、時間のほとんどがアイドル状態(ネットワーク通信待ち状態)です。

ネットワーク・ボトルネックを軽減するには、次のことを試行します。

- アプリケーションをチューニングしてラウンドトリップを軽減します。

- 待機時間を削減するためのオプション(たとえば、VSATリンクとは反対の地上回線)を探索します。

- 通信量の大きいコンポーネントを待機時間の少ないリンクに移動するように、システム構成を変更します。

10.3.18.1.2 クライアント・プロセス上のリソース・ボトルネック

クライアント・プロセスがリソースの大半を使用している場合、データベース内で実行できることはありません。症状には次のものがあります。

- 待機数は多くなくても、待機時間は長い。

- クライアント・プロセスは、リソースを多く使用している。

場合によっては、クライアント・プロセスで使用されるCPUの量により、待機しているユーザーのトラッキングのための待機時間がわかります。この場合のクライアントという用語は、n層アーキテクチャにおける、データベース・プロセス(中間層、デスクトップ・クライアント)以外の任意のプロセスを指します。

10.3.18.2 SQL*Net message from dblink

このイベントは、セッションがリモート・ノードにメッセージを送り、データベース・リンクからのレスポンスを待機している状態であることを意味します。この時間は、次の理由で増える可能性があります。

- ネットワーク・ボトルネック
詳細は、「SQL*Net message from client」を参照してください。

- リモート・ノードでSQLを実行するのに要する時間
リモート・ノードで実行されているSQLを確認することが有益です。リモート・データベースにログインし、データベース・リンクで作成されたセッションを検索し、そのセッションで実行されるSQL文を調べます。

- ラウンドトリップ・メッセージの数
セッションとリモート・ノード間の各メッセージにより、遅延時間が長くなり、処理オーバーヘッドが増加します。交換されるメッセージの数を減らすには、配列フェッチと配列挿入を使用します。

10.3.18.3 SQL*Net more data to client

サーバー・プロセスは、クライアントにさらに多くのデータまたはメッセージを送信します。クライアントに対する以前の操作も送信されました。

関連項目:
ネットワーク最適化の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

10.4 リアルタイムSQL監視

Oracle DatabaseのリアルタイムSQL監視機能では、実行中のSQL文のパフォーマンスを監視できます。SQL監視は、SQL文がパラレルに実行されるか、単一の実行で最低5秒以上のCPU時間またはI/O時間を消費すると、デフォルトで自動的に開始されます。

SQL文の実行の統計は、V$SQL_MONITORおよびV$SQL_PLAN_MONITORビューを使用して監視できます。これらのビューを次のビューと組み合せて使用することで、監視対象の実行処理の追加情報を取得できます。

- V$ACTIVE_SESSION_HISTORY

- V$SESSION

- V$SESSION_LONGOPS

- V$SQL

- V$SQL_PLAN

監視を開始すると、動的パフォーマンス・ビューV$SQL_MONITORにエントリが追加されます。このエントリでは、実行に関して収集される主要なパフォーマンス・メトリック(経過時間、CPU時間、読取り/書込み数、I/O待機時間、およびその他の様々な待機時間など)が追跡されます。これらの統計は、文の実行に応じてほぼリアルタイムで(通常は毎秒1回)リフレッシュされます。実行が終了しても監視情報は即座に削除されず、少なくとも1分間はV$SQL_MONITORビューに保持されます。エントリは最終的には削除され、その領域は新しい文の監視用として再利用されます。

V$SQL_MONITORビューには、V$SQLで使用される統計のサブセットが含まれます。ただし、V$SQLとは異なり、監視の統計は複数の実行処理にわたって累積されません。かわりに、V$SQL_MONITORの1つのエントリは、SQL文の1回の実行のみに対応します。同じSQL文の2つの実行を監視する場合、V$SQL_MONITORに各実行のエントリが個別に作成されます。

同じSQL文の2つの実行を一意に識別するため、実行キーと呼ばれるコンポジット・キーが生成されます。この実行キーは、V$SQL_MONITOR内の列にそれぞれ対応する次の3つの属性で構成されます。

- SQL文を識別するためのSQL識別子(SQL_ID)

- 実行開始タイムスタンプ(SQL_EXEC_START)

- この主キーが一意であることを保証する内部生成識別子(SQL_EXEC_ID)

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

- SQL計画の監視

- パラレル実行の監視

- SQL監視レポートの生成

- SQL監視の有効化と無効化

10.4.1 SQL計画の監視

リアルタイムSQL監視には、監視対象のSQL文の実行計画における各操作の監視統計も含まれます。このデータは、V$SQL_PLAN_MONITORビューに表示されます。V$SQL_MONITORビューと同様に、V$SQL_PLAN_MONITORの統計もSQL文の実行に応じて毎秒更新されます。これらの統計が実行終了後も保持される期間は、V$SQL_MONITORと同じです。 監視対象のSQL文ごとにV$SQL_PLAN_MONITORに複数のエントリが存在します。各エントリは、文の実行計画の1つの操作に対応します。

10.4.2 パラレル実行の監視

データベースは、パラレルな問合せ、DML文およびDDL文を、実行の開始と同時に自動的に監視します。V$SQL_MONITORビューとV$SQL_PLAN_MONITORビューは、パラレル実行に参加している各プロセスの監視情報を個別のエントリとして記録します。

V$SQL_MONITORには、パラレル実行のコーディネータ・プロセスに対して1つのエントリと、パラレル実行のサーバー・プロセスごとに1つのエントリが割り当てられます。各エントリにはV$SQL_PLAN_MONITORの対応するエントリがあります。SQL文のパラレル実行に割り当てられた各プロセスは、同じ実行に対して連携動作するため、これらのエントリは同じ実行キー(コンポジットSQL_ID、SQL_EXEC_STARTおよびSQL_EXEC_ID)を共有します。したがって、実行キーを収集することで、パラレル実行の全体的な統計を確認できます。

10.4.3 SQL監視レポートの生成

SQL監視レポートを使用してSQL監視データを参照できます。SQL監視レポートでは、次の各ビューのデータを使用します。

- GV$SQL_MONITOR

- GV$SQL_PLAN_MONITOR

- GV$SQL

- GV$SQL_PLAN

- GV$ACTIVE_SESSION_HISTORY

- GV$SESSION_LONGOPS

SQL監視レポートを生成するには、次のようにDBMS_SQLTUNEパッケージのREPORT_SQL_MONITORファンクションを実行します。

variable my_rept CLOB;
BEGIN
:my_rept :=DBMS_SQLTUNE.REPORT_SQL_MONITOR();
END;
/

print :my_rept

DBMS_SQLTUNE.REPORT_SQL_MONITORファンクションでは、複数の入力パラメータを使用して、実行、レポートの詳細レベル、およびレポート・タイプ(TEXT、HTMLまたはXML)を指定します。例のようにパラメータを指定しない場合、デフォルトで監視対象の最後の実行に関するテキスト・レポートが生成されます。

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

例10-1は、監視対象のSQL文の最後の実行に関するSQL監視レポートの出力を示しています。

例10-1 SQL監視レポートのサンプル

set long 10000000
set longchunksize 10000000
set linesize 200
select dbms_sqltune.report_sql_monitor from dual;

SQL Text
----------------------------------------------------------------------------------------
select * from (select O_ORDERDATE, sum(O_TOTALPRICE)
from  orders o, lineitem l
where l.l_orderkey = o.o_orderkey
group by o_orderdate
order by o_orderdate) where rownum < 100
----------------------------------------------------------------------------------------

Global Information
Status              :  EXECUTING
Instance ID         :  1
Session ID          :  980
SQL ID              :  br4m75c20p97h
SQL Execution ID    :  16777219
Plan Hash Value     :  2992965678
Execution Started   :  06/07/2007 08:36:42
First Refresh Time  :  06/07/2007 08:36:46
Last Refresh Time   :  06/07/2007 08:40:02

-----------------------------------------------------------------------------------
| Elapsed |   Cpu   |    IO    | Application |  Other   | Buffer | Reads | Writes |
| Time(s) | Time(s) | Waits(s) |  Waits(s)   | Waits(s) |  Gets  |       |        |
-----------------------------------------------------------------------------------
|     198 |     140 |       56 |        0.31 |     1.44 |  1195K | 1264K |  84630 |
-----------------------------------------------------------------------------------

SQL Plan Monitoring Details
=======================================================================================
| Id   |         Operation          |   Name   |  Rows   | Cost  |   Time    | Start  |
|      |                            |          | (Estim) |       | Active(s) | Active |
=======================================================================================
|    0 | SELECT STATEMENT           |          |         |  125K |           |        |
|    1 |   COUNT STOPKEY            |          |         |       |           |        |
|    2 |    VIEW                    |          |    2406 |  125K |           |        |
|    3 |     SORT GROUP BY STOPKEY  |          |    2406 |  125K |        99 |   +101 |
| -> 4 |      HASH JOIN             |          |   8984K |  123K |       189 |    +12 |
|      |                            |          |         |       |           |        |
|    5 |       INDEX FAST FULL SCAN | I_L_OKEY |   8984K | 63191 |        82 |     +1 |
|      |                            |          |         |       |           |        |
|    6 |       PARTITION RANGE ALL  |          |  44913K | 57676 |        94 |    +84 |
|    7 |        PARTITION HASH ALL  |          |  44913K | 57676 |        94 |    +84 |
|    8 |         TABLE ACCESS FULL  | ORDERS   |  44913K | 57676 |        95 |    +84 |
|      |                            |          |         |       |           |        |
|      |                            |          |         |       |           |        |
=======================================================================================

continuation of above table
=======================================================================================
Starts |   Rows   | Memory | Temp | Activity  |      Activity Detail      | Progress |
| (Actual) |        |      | (percent) |        (sample #)         |          |
=======================================================================================
1 |          |        |      |           |                           |          |
1 |          |        |      |           |                           |          |
1 |          |        |      |           |                           |          |
1 |        0 |        |      |      4.02 | Cpu (8)                   |          |
1 |   28130K | 10000K | 724M |     25.13 | Cpu (48)                  | 87%      |
|          |        |      |           | direct path read temp (2) |          |
1 |   32734K |        |      |     34.17 | Cpu (58)                  | 100%     |
|          |        |      |           | direct path read (10)     |          |
1 |   45000K |        |      |           |                           |          |
84 |   45000K |        |      |           |                           |          |
672 |   45000K |        |      |     36.68 | Cpu (28)                  |          |
|          |        |      |           | reliable message (3)      |          |
|          |        |      |           | direct path read (42)     |          |
=======================================================================================

このレポートのGlobal InformationセクションのStatusフィールドは、この文がまだ実行中であることを示しています。Time Active(s)列は、操作がアクティブであった期間(アクティブ時間の最初と最後の間の増分秒)を示しています。Start Active列は、SQL文の実行開始時間と比較して、実行計画の操作が開始された時点を秒数で示しています。このレポートによれば、ID 5の高速全スキャン操作が最初に開始され(Start Active列の+1秒より)、最初の82秒間実行されています。

Starts列は、実行計画の操作が実行された回数を示しています。Rows (Actual)列は生成された行の数を示し、Rows (Estim)列はオプティマイザで予測されたカーディナリティを示します。Memory列およびTemp列は、実行計画の各操作で消費されたメモリー領域および一時領域の容量を示します。Activity (percent)列およびActivity Detail (sample #)列は、V$SQL_PLAN_MONITORビューとV$ACTIVE_SESSION_HISTORYビューの結合により導出されます。Activity (percent)は、実行計画の各操作で消費されたデータベース時間の割合を示します。Activity Detail (sample#)は、そのアクティビティの性質(CPUや待機イベントなど)を示します。レポートのこの列によれば、データベース時間のほとんど(36.68%)が操作ID 8(ORDERSのTABLE ACCESS FULL)によって消費されています。このアクティビティは、73のサンプル(28+3+42)で構成されており、アクティビティの半分以上はdirect path read(42のサンプル)に、3分の1はCPU(28のサンプル)に費やされています。最後の列のProgressは、V$SESSION_LONGOPSビューに基づく操作の進捗状況の監視情報を示します。このレポートによれば、ハッシュ結合操作が87%完了しています。

10.4.4 SQL監視の有効化と無効化

SQL監視機能は、STATISTICS_LEVEL初期化パラメータがALLまたはTYPICAL(デフォルト値)に設定されている場合、デフォルトで有効になります。また、SQL監視はOracle Database Tuning Packの機能であるため、CONTROL_MANAGEMENT_PACK_ACCESSパラメータをDIAGNOSTIC+TUNING(デフォルト値)に設定する必要があります。SQL監視は、長時間実行されるすべての問合せに対して自動的に開始されます。

SQL文の監視を強制または回避するために使用できる文レベルのヒントが2つあります。SQL監視を強制するには、次のようにMONITORヒントを使用します。

select /*+MONITOR*/ from dual;

このヒントは、CONTROL_MANAGEMENT_PACK_ACCESSパラメータがDIAGNOSTIC+TUNINGに設定されている場合にのみ有効です。監視対象のヒント付きSQL文を監視から除外するには、NO_MONITOR逆ヒントを使用します。

関連項目:
MONITORおよびNO_MONITORヒントの使用方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

10.5 インスタンス・リカバリのパフォーマンスのチューニング: ファスト・スタート・フォルト・リカバリ

この項では、インスタンス・リカバリと、クラッシュまたはインスタンス障害が発生した場合のOracleのファスト・スタート・フォルト・リカバリによる可用性の向上について説明します。また、クラッシュ・リカバリやインスタンス・リカバリの実行に必要な時間をチューニングするためのガイドラインも示します。

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

- インスタンス・リカバリについて

- キャッシュ・リカバリ時間の構成: FAST_START_MTTR_TARGET

- FAST_START_MTTR_TARGETのチューニングとMTTRアドバイザの使用

10.5.1 インスタンス・リカバリについて

インスタンス・リカバリおよびクラッシュ・リカバリとは、クラッシュやシステム障害後に、Oracleデータ・ブロックにREDOログ・レコードを自動的に適用することです。通常の操作中は、インスタンスが異常終了ではなく(SHUTDOWN IMMEDIATE文を使用する場合のように)正常に停止した場合、ディスクのデータファイルに書き込まれていないメモリー内の変更は、停止時に実行されるチェックポイントの一環としてディスクに書き込まれます。

ただし、シングル・インスタンス・データベースのクラッシュまたはOracle RAC構成のすべてのインスタンスのクラッシュが発生した場合、次の起動時にクラッシュ・リカバリが実行されます。Oracle RAC構成の1つ以上のインスタンスがクラッシュした場合は、残りのインスタンスによってインスタンス・リカバリが自動的に実行されます。インスタンス・リカバリとクラッシュ・リカバリの手順は、キャッシュ・リカバリ、トランザクション・リカバリの順に行われます。

キャッシュ・リカバリが完了するとすぐにデータベースを開くことができるため、可用性の向上にはキャッシュ・リカバリのパフォーマンスの向上が重要になります。

10.5.1.1 キャッシュ・リカバリ(ロールフォワード)

キャッシュ・リカバリ・ステップでは、REDOログ・ファイル内のコミット済およびコミットされていない変更がすべて、影響のあるデータ・ブロックに適用されます。キャッシュ・リカバリ処理に必要な作業量は、データベースの変更率(1秒当たりの更新トランザクション数)とチェックポイント間の時間に比例します。

10.5.1.2 トランザクション・リカバリ(ロールバック)

データベースの一貫性を保つには、クラッシュ時にコミットされなかった変更を元に戻す必要があります(ロールバック)。トランザクション・リカバリ・ステップでは、ロールバック・セグメントを適用してコミットされていない変更が元に戻されます。

10.5.1.3 チェックポイントとキャッシュ・リカバリ

Oracle Databaseでは、チェックポイントが定期的に記録されます。チェックポイントは最大のシステム変更番号(SCN)であるため、このSCN以下のデータ・ブロックはすべてデータファイルに書込み済であることがわかります。障害が発生した場合、チェックポイントよりも高いSCNでの変更を含むREDOレコードのみがリカバリ時に適用される必要があります。キャッシュ・リカバリ処理の時間は、チェックポイントのSCNよりも高いSCNでの変更を含むデータ・ブロックの数と、これらの変更を検出するために読取りが必要なログ・ブロックの数の2つの要因で決定されます。

10.5.1.3.1 チェックポイントによるパフォーマンスへの影響

チェックポイントの頻度が高くなると、そうでない場合よりも高い頻度で使用済バッファがデータファイルに書き込まれるため、インスタンス障害時のキャッシュ・リカバリ時間が短縮されます。チェックポイントの頻度が高い場合、REDOログの現在のチェックポイント位置とログの末尾までの間にあるREDOレコードを適用する際、相対的に少ないデータ・ブロックが処理されます。つまり、リカバリのキャッシュ・リカバリ・フェーズがかなり短くなります。

ただし、更新の多いシステムでは、チェックポイントの頻繁な発生により、実行時のパフォーマンスが低下する可能性があります。これはチェックポイントによってDBWnプロセスで書込みが実行されるためです。

10.5.1.3.2 ファスト・キャッシュ・リカバリのトレードオフ

キャッシュ・リカバリ時間を最短にするには、Oracle Databaseでのチェックポイントを頻繁にして、リカバリ時に適用されるREDOログ・レコードの数を最小限にします。ただし、更新の多いシステムでは、チェックポイントの頻繁な発生により、通常のデータベース操作のオーバーヘッドが増加します。

リカバリ時間の短縮よりも日常の操作効率の方が重要な場合は、チェックポイントによるデータファイルへの書込み頻度を減らします。これにより、操作効率は向上しますが、キャッシュ・リカバリ時間も増加します。

10.5.2 キャッシュ・リカバリ時間の構成: FAST_START_MTTR_TARGET

ファスト・スタート・リカバリ機能により、キャッシュ・リカバリに必要な時間が短縮されます。また、使用済バッファの数、および最新のREDOレコードと最後のチェックポイントとの間に生成されるREDOレコードの数を制限して、リカバリの制御および予測を行うことができます。

ファスト・スタート・フォルト・リカバリの基本は、ファスト・スタート・チェックポイント・アーキテクチャです。バルク書込みを行う従来のイベント・ドリブン(ログ・スイッチ)・チェックポイントではなく、ファスト・スタート・チェックポイントは段階的に発生します。各DBWnプロセスは、定期的にバッファからディスクへの書込みを行い、チェックポイント位置を先に進めます。最も古い変更ブロックは、各書込みによってチェックポイントが先に進められるように最初に書き込まれます。ファスト・スタート・チェックポイントでは、従来のチェックポイントで発生するバルク書込みと、その結果発生するI/Oスパイクを回避できます。

ファスト・スタート・フォルト・リカバリ機能では、初期化パラメータFAST_START_MTTR_TARGETによって、インスタンス障害またはシステム障害からのリカバリ時間を簡単に構成できます。FAST_START_MTTR_TARGETは、平均リカバリ時間(MTTR)の目標値、つまりインスタンスを起動してキャッシュ・リカバリの実行にかかる時間(秒単位)の目標値を指定します。FAST_START_MTTR_TARGETを設定すると、データベースはその目標値を達成するように増分チェックポイントの書込みを管理します。FAST_START_MTTR_TARGETに現実的な値を選択した場合、選択したおおよその平均秒数内でデータベースがリカバリされます。

注意:
FAST_START_MTTR_TARGETを使用する場合は、初期化パラメータFAST_START_IO_TARGET、LOG_CHECKPOINT_INTERVALおよびLOG_CHECKPOINT_TIMEOUTを無効にするか削除する必要があります。これらのパラメータを設定すると、FAST_START_MTTR_TARGETを達成するためにキャッシュ・リカバリ時間の管理に使用するメカニズムが適切に機能しなくなります。

10.5.2.1 FAST_START_MTTR_TARGETの現実的な値

FAST_START_MTTR_TARGETの最大値は3600秒(1時間)です。3600を超える値を設定すると、Oracle Databaseでその値は3600に丸められます。

次に、FAST_START_MTTR_TARGETの値を設定する方法の例を示します。

SQL> ALTER SYSTEM SET FAST_START_MTTR_TARGET=30;

原則ではFAST_START_MTTR_TARGETの最小値は1秒です。ただし、FAST_START_MTTR_TARGETにそのような小さい値を設定できるからといって、その目標値を達成できるということにはなりません。データベースの起動時間などの要因によって、達成可能なMTTR目標値には現実的な下限があります。

FAST_START_MTTR_TARGETの現在の値を前提として、データベースが達成可能なMTTR目標値を有効MTTR目標値といいます。現在の有効MTTRを参照するには、V$INSTANCE_RECOVERYビューのTARGET_MTTR列を参照します。

使用するデータベースの現実的なMTTR目標値の範囲は、そのデータベースで達成可能な有効MTTR目標値の最小値から、最悪の場合(バッファ・キャッシュ全体が使用済の場合)に起動とキャッシュ・リカバリにかかる時間の最大値までです。「FAST_START_MTTR_TARGETの現実的な範囲の決定」に記載された達成可能なMTTR目標値の範囲を決定する手順は、FAST_START_MTTR_TARGET値のチューニング・プロセスの1ステップです。

注意:
FAST_START_MTTR_TARGETを現実的な範囲外の値に設定するのは、通常、有益ではありません。FAST_START_MTTR_TARGETの値が現実的な範囲の下限よりも小さい場合、その効果は現実的な範囲の下限に設定した場合と同様になります。このような場合、有効なMTTR目標値はシステムで達成できる最高のMTTR目標値になりますが、チェックポイントが最高頻度で実行され、通常のデータベースのパフォーマンスに影響を与える可能性があります。FAST_START_MTTR_TARGETを現実的な範囲よりも長い時間に設定する場合、MTTR目標値は最悪の場合と同じになります。

10.5.2.2 ランタイム・パフォーマンスを最適化するためのチェックポイント頻度の低減

チェックポイントの頻度を低くしてランタイム・パフォーマンスを最適化するには、次の手順を実行します。

- FAST_START_MTTR_TARGETの値を3600に設定します。これにより、ファスト・スタート・チェックポイントとファスト・スタート・フォルト・リカバリ機能が有効になりますが、実行時パフォーマンスへの影響は最小限に抑えられ、FAST_START_MTTR_TARGETによるパフォーマンスのチューニングが必要なくなります。

- システムが生成するREDOの量に従って、オンラインREDOログ・ファイルをサイズ設定します。ログの切替えは、最も頻繁に行う場合でも20分間隔とします。ログ・ファイルのサイズが小さすぎると、チェックポイント・アクティビティが増加し、パフォーマンスが低下します。また、すべてのREDOログ・ファイルのサイズが同じになるようにしてください。

関連項目:
チェックポイントの詳細は、『Oracle Database概要』を参照してください。

10.5.2.3 V$INSTANCE_RECOVERYによるキャッシュ・リカバリの監視

V$INSTANCE_RECOVERYビューには、現在のリカバリ・パラメータの設定が表示されます。このビューの統計を使用して、チェックポイントに最大の影響を与えている要因を判断することもできます。

次の表に、キャッシュ・リカバリのパフォーマンスの予測を管理する際に役立つ列を示します。

表10-4 V$INSTANCE_RECOVERYの列

列

説明

TARGET_MTTR

有効なMTTR目標値(秒単位)。FAST_START_MTTR_TARGETを指定しない場合、このフィールドは0です。

ESTIMATED_MTTR

現在の使用済バッファ数およびログ・ブロック数に基づいた、現在の推定MTTR(秒単位)。FAST_START_MTTR_TARGETを指定しているかどうかにかかわらず、このフィールドは常に計算されます。

V$INSTANCE_RECOVERYの列の詳細は、『Oracle Databaseリファレンス』を参照してください。

使用するデータベースで実行中の監視の一環として、V$INSTANCE_RECOVERY.TARGET_MTTRとFAST_START_MTTR_TARGETを定期的に比較できます。この2つの値は、FAST_START_MTTR_TARGETの値が現実的な範囲内にある場合は通常同じになります。TARGET_MTTRがFAST_START_MTTR_TARGETよりも常に大きい場合は、FAST_START_MTTR_TARGETをTARGET_MTTR以上の値に設定します。TARGET_MTTRが常に小さい場合は、FAST_START_MTTR_TARGETをTARGET_MTTR以下の値に設定します。

10.5.3 FAST_START_MTTR_TARGETのチューニングとMTTRアドバイザの使用

使用するデータベースに適切なFAST_START_MTTR_TARGET値を判断するには、次の4つの手順を使用します。

- FAST_START_MTTR_TARGETの測定

- FAST_START_MTTR_TARGETの現実的な範囲の決定

- MTTRアドバイザによる様々な目標値の評価

- 最適なREDOログ・サイズの決定

10.5.3.1 FAST_START_MTTR_TARGETの測定

初期化パラメータFAST_START_MTTR_TARGETにより、REDOログの長さとデータ・キャッシュの使用済データ・バッファの数を制限するために、内部システム・トリガーの値が計算されます。この計算では、REDOブロックの読取りの概算時間、データ・ブロックの読取りと書込みの概算時間、およびシステムの一般的なワークロードの特性(変更ベクトル数に対応する使用済バッファ数など)が使用されます。

最初は、内部的なデフォルト値が計算に使用されます。これらのデフォルト値は、時間の経過とともに、システム操作時および実際のキャッシュ・リカバリ時にI/Oパフォーマンスに関して収集されたデータに置き換えられます。

FAST_START_MTTR_TARGET値を適切に測定するには、インスタンス・リカバリを複数回実行する必要があります。測定を開始する前に、データベース・クラッシュとハードウェア・クラッシュのどちらに対してFAST_START_MTTR_TARGETを測定するかを決定してください。これは、データベース・ファイルがファイル・システムに格納される場合、またはI/Oサブシステムにメモリー・キャッシュがある場合の考慮事項です。ファイルがキャッシュされるかどうかによって、ディスクへの読取り時間と書込み時間に大幅な違いがあるためです。FAST_START_MTTR_TARGETの適切な値は、どのタイプのクラッシュがより迅速にリカバリする必要があるかによって異なります。

FAST_START_MTTR_TARGETを効率的に測定するには、システムの一般的なワークロードを長時間実行し、リカバリ時のREDOブロックの読取り時間およびデータ・ブロックの読取りまたは書込み時間が正確に記録されるようにインスタンス・リカバリを複数回実行します。

10.5.3.2 FAST_START_MTTR_TARGETの現実的な範囲の決定

測定後、テストを実行して、使用するデータベースのFAST_START_MTTR_TARGETの現実的な範囲を決定できます。

10.5.3.2.1 FAST_START_MTTR_TARGETの下限の決定: シナリオ

現実的な範囲の下限を決定するには、FAST_START_MTTR_TARGETを1に設定してデータベースを起動します。次に、V$INSTANCE_RECOVERY.TARGET_MTTRの値を確認して、この値をFAST_START_MTTR_TARGETの有効な下限として使用します。この下限の決定には、通常、キャッシュ・リカバリ時間ではなくデータベースの起動時間の方が主要な要因となります。

たとえば、次のようにFAST_START_MTTR_TARGETを1に設定します。

SQL> ALTER SYSTEM SET FAST_START_MTTR_TARGET=1;

次に、データベースを開いた直後に次の問合せを実行します。

SQL> SELECT TARGET_MTTR, ESTIMATED_MTTR
FROM V$INSTANCE_RECOVERY;

次のような結果が返されます。

TARGET_MTTR ESTIMATED_MTTR
18          15

TARGET_MTTRの18秒という値はシステムで達成可能な最小MTTR目標値、つまりFAST_START_MTTR_TARGETの現実的な下限値です。この最小値は、データベースの平均起動時間に基づいて計算されます。

ESTIMATED_MTTRフィールドには、実行中のデータベースの現在の状態に基づいた、概算平均リカバリ時間が含まれます。データベースは開いた直後であり、システムに含まれるのは少数の使用済バッファであるため、この時点でインスタンスに障害が発生した場合でも、それほど多くのキャッシュ・リカバリは必要ありません。そのため、ESTIMATED_MTTRは、この時点ではTARGET_MTTRに指定可能な最小値よりも小さい値になる場合があります。

ESTIMATED_MTTRは、最近のデータベース・アクティビティによって短期的に影響を受ける場合があります。データベースで大量の更新アクティビティを一定期間行った直後にV$INSTANCE_RECOVERYに対して問合せを実行するとします。次のような結果が返されます。

TARGET_MTTR ESTIMATED_MTTR
18          30

有効MTTR目標値は18秒のままで、(その時点でクラッシュが発生した場合の)概算MTTRは30秒です。これは許容可能な結果です。つまり、一部のチェックポイントの書込みが完了していないため、バッファ・キャッシュには目標よりも多くの使用済バッファが含まれています。

ここで60秒待機してから、V$INSTANCE_RECOVERYに対して再度問合せを発行します。次のような結果が返されます。

TARGET_MTTR ESTIMATED_MTTR
18          25

この期間に一部の使用済バッファが書き込まれたため、今回の概算MTTRは25秒に減少しています。

10.5.3.2.2 FAST_START_MTTR_TARGETの上限の決定

現実的な範囲の上限を決定するには、FAST_START_MTTR_TARGETを3600に設定し、一般的なワークロードでデータベースを一定期間操作します。次にV$INSTANCE_RECOVERY.TARGET_MTTRの値を確認します。この値が、FAST_START_MTTR_TARGETの有効な上限です。

この手順は「FAST_START_MTTR_TARGETの下限の決定: シナリオ」の手順と実質的に似ています。

10.5.3.2.3 FAST_START_MTTR_TARGETの初期値の選択

FAST_START_MTTR_TARGETパラメータの現実的な範囲を決定した後、このパラメータの初期値を選択します。データベースのパフォーマンスを懸念する場合は、現実的な範囲内で高い値を選択し、リカバリ時間の短縮が優先される場合は現実的な範囲内で低い値を選択します。当然のことながら、現実的な範囲が狭いほど、選択は容易になります。

たとえば、現実的な範囲が17から19秒の場合、単純に19を選択できます。これはリカバリ時間にはほとんど差がなく、同時にシステムのパフォーマンスに対するチェックポイントの影響が最小限に抑えられるためです。しかし、現実的な範囲が18から40秒の場合は、中間的な値として30を選択し、この値に従ってパラメータを設定できます。

SQL> ALTER SYSTEM SET FAST_START_MTTR_TARGET=30;

その後、MTTRアドバイザを使用して最適値を判断できます。

10.5.3.3 MTTRアドバイザによる様々な目標値の評価

FAST_START_MTTR_TARGETの初期値を選択した後、MTTRアドバイザを使用して、異なるFAST_START_MTTR_TARGETの設定がシステム・パフォーマンスに与える影響を、選択した設定と比較して評価できます。

10.5.3.3.1 MTTRアドバイザの有効化

MTTRアドバイザを有効にするには、2つの初期化パラメータSTATISTICS_LEVELおよびFAST_START_MTTR_TARGETを設定します。

STATISTICS_LEVELでは、MTTRアドバイザのみでなく、すべてのアドバイザの有効化を制御します。このパラメータがTYPICALまたはALLに設定されていることを確認します。次にFAST_START_MTTR_TARGETをゼロ以外の値に設定すると、MTTRアドバイザが有効になります。

10.5.3.3.2 MTTRアドバイザの使用

MTTRアドバイザを有効にした後、一般的なデータベース・ワークロードを一定期間実行します。MTTRアドバイザが有効な場合、現在のFAST_START_MTTR_TARGET値、およびFAST_START_MTTR_TARGET値の有効範囲内の最大4つの異なるMTTR設定に基づいて、チェックポイント・キュー動作がシミュレートされます。(この場合、FAST_START_MTTR_TARGETの有効範囲が決定されてから、その範囲内の複数の値がテストされます。)

10.5.3.3.3 MTTRアドバイザの結果の表示: V$MTTR_TARGET_ADVICE

動的パフォーマンス・ビューV$MTTR_TARGET_ADVICEでは、MTTRアドバイザによって収集された統計またはアドバイスを表示できます。

V$MTTR_TARGET_ADVICEには、データベースに対するFAST_START_MTTR_TARGETの各設定の影響に関するアドバイスが移入されます。FAST_START_MTTR_TARGETの値ごとに、行にはFAST_START_MTTR_TARGETの値に対してテストに使用されたワークロード下で実行されるキャッシュ書込み数に関する詳細が表示されます。

具体的には、各行には、その行のFAST_START_MTTR_TARGET値でのキャッシュ書込み数、合計物理書込み数(直接書込みを含む)および合計I/O(読取りを含む)に関する情報が、合計操作数と、選択したFAST_START_MTTR_TARGET値での操作との比率の両方で表示されます。たとえば、比率が1.2の場合は、キャッシュ書込みが20%多いことを表しています。

様々なFAST_START_MTTR_TARGET設定がキャッシュの書込みアクティビティやその他のI/Oに与える影響を理解すると、リカバリやパフォーマンスの要件に最適なFAST_START_MTTR_TARGET値をより効率的に決定できます。

MTTRアドバイザが現在有効な場合は、V$MTTR_TARGET_ADVICEに、収集されたアドバイザ情報が表示されます。現在、MTTRアドバイザがOFFの場合、データベースを起動してからMTTRアドバイザが最後にONであったときに収集された情報が表示されます(情報が存在する場合)。最後にMTTRアドバイザを使用してからデータベースが再起動された場合、またはMTTRアドバイザが1回も使用されなかった場合、このビューには行は表示されません。

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

10.5.3.4 最適なREDOログ・サイズの決定

V$INSTANCE_RECOVERYビューのOPTIMAL_LOGFILE_SIZE列を使用して、オンラインREDOログのサイズを決定できます。このフィールドには、FAST_START_MTTR_TARGETの現在の設定に基づいて最適と判断されるREDOログ・ファイルのサイズ(MB単位)が表示されます。このフィールドに、最も小さいオンライン・ログのサイズよりも大きな値が常に表示される場合は、すべてのオンライン・ログをこのサイズ以上に構成する必要があります。

ただし、REDOログ・ファイルのサイズがMTTRに影響を与えることに注意してください。ログ・ファイルのサイズを、希望する最適な値に設定してMTTRアドバイザを再実行すると、選択した最適なFAST_START_MTTR_TARGET値をさらに適切に調整できる場合もあります。

第IV部

SQL文の最適化

この部では、SQL文をチューニングして最適なパフォーマンスを実現する方法について説明します。また、SQL関連のOracleパフォーマンス・ツールについても説明します。

この部の構成は、次のとおりです。

- 第11章「問合せオプティマイザ」

- 第12章「EXPLAIN PLANの使用方法」

- 第13章「オプティマイザ統計の管理」

- 第14章「索引およびクラスタの使用方法」

- 第15章「SQL計画の管理の使用方法」

- 第16章「SQLチューニングの概要」

- 第17章「自動SQLチューニング」

- 第18章「SQLアクセス・アドバイザ」

- 第19章「オプティマイザ・ヒントの使用方法」

- 第20章「プラン・スタビリティの使用方法」

- 第21章「アプリケーション・トレース・ツールの使用方法」

11 問合せオプティマイザ

この章では、SQL処理、最適化方式およびSQL文を実行する特定の計画を問合せオプティマイザ(通常はオプティマイザと呼ばれる)が選択する方法を説明します。

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

- 問合せオプティマイザの概要

- オプティマイザ・アクセス・パスの概要

- 結合の概要

- 実行計画の読み方と理解

- オプティマイザ動作の制御

11.1 問合せオプティマイザの概要

オプティマイザは、SQL文を実行する最も効率的な方法を判断する組込みソフトウェアです。

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

- オプティマイザ操作

- 問合せオプティマイザの構成要素

- バインド変数の照合

11.1.1 オプティマイザ操作

SQL文は、全表スキャン、索引スキャン、ネステッド・ループおよびハッシュ結合などにおいて、様々な方法で実行されます。オプティマイザは、問合せのオブジェクトと条件に関連する様々な要素を考慮して、実行計画を決定します。この決定はSQL処理における重要な手順であり、これによって実行時間に大きな差が生じる可能性があります。

注意:
オプティマイザは、Oracle Databaseのあるバージョンとその次のバージョンで同じ決定を行うとはかぎりません。最新バージョンのオプティマイザは、より高度な情報を使用できるので、異なる決定を行います。

ユーザーがSQL文実行を送信すると、オプティマイザは次のステップを実行します。

1. 使用可能なアクセス・パスおよびヒントに基づき、SQL文の可能な計画のセットを生成します。

2. オプティマイザは、データ・ディクショナリ内の統計に基づき、各計画のコストを見積ります。統計には文がアクセスする表、索引およびパーティションのデータ配分および記憶特性に関する情報が含まれます。
コストとして見積られる値は、特定の計画での文の実行に必要と予測されるリソース使用量に比例しています。オプティマイザは、I/O、CPU、メモリーなどのコンピュータ・リソースの見積りに基づいて、アクセス・パスや結合順序のコストを計算します。

コストの大きいシリアル計画の実行には、コストの小さい計画の実行よりも多くの時間が必要です。パラレル計画を使用する場合は、リソース使用量は経過時間に直接関係しません。

3. オプティマイザは計画を比較して、コストが最も小さい計画を選択します。
オプティマイザからは、最適な実行方法を説明する実行計画が出力されます。この計画により、SQL文を実行するためにOracle Databaseで使用するステップの組合せが示されます。実行される各ステップでは、データベースからの行の物理的な取出し、またはユーザーが発行する文に戻す行の準備のどちらかが実行されます。

関連項目:
ヒントの詳細は、第19章「オプティマイザ・ヒントの使用方法」を参照してください。

オプティマイザは、Oracle Databaseで処理されるSQL文に、表11-1に示す操作を実行します。

表11-1 オプティマイザ操作

操作

説明

式と条件の評価

オプティマイザは、まず、定数が含まれている式と条件を可能なかぎり完全に評価します。

文の変換

たとえば、相関副問合せやビューなどに関連する複合文について、オプティマイザは元の文を同等の結合文に変換する場合があります。

オプティマイザの目標の選択

オプティマイザでは、最適化の目標が判別されます。「オプティマイザの目標の選択」を参照してください。

アクセス・パスの選択

文がアクセスするそれぞれの表について、オプティマイザは、表データを取得するために1つ以上の使用可能なアクセス・パスを選択します。「オプティマイザ・アクセス・パスの概要」を参照してください。

結合順序の選択

2つ以上の表を結合する結合文について、オプティマイザは、最初に結合する表のペアを選択し、その後、その結果に結合する表を順次選択していきます。「問合せオプティマイザによる結合の実行計画の選択方法」を参照してください。

場合によっては、特定のアプリケーションのデータに関して、オプティマイザよりも多くの情報を入手できることがあります。このような場合には、SQL文のヒントを使用して、文の実行方法についてオプティマイザに指示を与えることができます。

関連項目:

- 第13章「オプティマイザ統計の管理」

- 第19章「オプティマイザ・ヒントの使用方法」

- SQL処理およびオプティマイザの概要は、『Oracle Database概要』を参照してください。

11.1.2 問合せオプティマイザの構成要素

問合せオプティマイザ操作には、次のものがあります。

- 問合せ変換

- 見積り

- プラン・ジェネレータ

図11-1はオプティマイザの構成要素を示しています。

図11-1 オプティマイザの構成要素

11.1.2.1 問合せ変換

文の各問合せ部分は、問合せブロックと呼ばれます。問合せトランスフォーマへの入力は、一連の問合せブロックによって表される解析済問合せです。

次の例では、SQL文は2つの問合せブロックで構成されています。括弧内の副問合せは、内側の問合せブロックです。SQL文の残りの部分が外側の問合せブロックで、副問合せによって提供されたIDを持つ部門内の従業員の名前を取り出します。

SELECT first_name, last_name
FROM   employees
WHERE  department_id
IN     (SELECT department_id FROM departments WHERE location_id = 1800);

問合せの形式によって、問合せブロックの相互関係が判断されます。トランスフォーマは、元のSQL文をより効率的に処理できる意味的に同等のSQL文にリライトすることが有利かどうかを判断します。

問合せトランスフォーマは、複数の問合せ変換手法を備えています。次のような方法があります。

- ビューのマージ

- 述語のプッシュ

- 副問合せのネスト解除

- マテリアライズド・ビューを使用したクエリー・リライト

これらの変換の組合せを問合せに適用できます。

11.1.2.1.1 ビューのマージ

問合せで参照されるビューは、パーサーによって個別の問合せブロックに拡張されます。ブロックは、基本的にはビュー定義を表しますが、このため必然的にビューの結果も表すことになります。オプティマイザには、ビューの問合せブロックの1つを分離して分析し、ビュー・サブプランを生成するというオプションがあります。オプティマイザは、問合せ計画全体の生成にビュー・サブプランを使用することで、残りの問合せを処理します。この手法は、そのビューが個別に最適化されるため、通常は最適な問合せ計画とはなりません。

ビューのマージでは、トランスフォーマはビューを表す問合せブロックを包含的な問合せブロックにマージします。たとえば、次のようにビューを作成します。

CREATE VIEW employees_50_vw AS
SELECT employee_id, last_name, job_id, salary, commission_pct, department_id
FROM   employees
WHERE  department_id = 50;

それから次のようにしてビューを問い合せます。

SELECT employee_id
FROM   employees_50_vw
WHERE  employee_id > 150;

オプティマイザはビューのマージを使用して、employees_50_vwの問合せを次の同等の問合せに変換できます。

SELECT employee_id
FROM   employees
WHERE  department_id = 50
AND    employee_id > 150;

ビューのマージによる最適化は、選択、射影、および結合のみを含むビューに適用されます。つまり、マージ可能なビューには、集合演算子、集計機能、DISTINCT、GROUP BY、CONNECT BYなどは含まれません。

オプティマイザがユーザーによって発行されるすべての問合せにビューのマージを使用できるようにするには、MERGE ANY VIEW権限をユーザーに付与する必要があります。オプティマイザが特定のビューに対する問合せにビューのマージを使用できるようにするには、これらのビューのMERGE VIEW権限をユーザーに付与します。これらの権限は、セキュリティで障害をチェックするためにビューがマージされない場合などの特定の状況でのみ必要です。

関連項目:

- MERGE ANY VIEW権限およびMERGE VIEW権限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

11.1.2.1.2 述語のプッシュ

述語のプッシュでは、オプティマイザは関連する述語を、それを含む問合せブロックからビューの問合せブロックにプッシュします。マージされていないビューでは、プッシュされた述語は、索引へのアクセスまたはフィルタとして使用できるので、この方法を使用するとマージされていないビューのサブプランが改善されます。

たとえば、2つの従業員表を参照するビューを作成するとします。ビューは、次のようにUNION集合演算子を使用した複合問合せによって定義されます。

CREATE VIEW all_employees_vw AS
( SELECT employee_id, last_name, job_id, commission_pct, department_id
FROM   employees )
UNION
( SELECT employee_id, last_name, job_id, commission_pct, department_id
FROM   contract_workers );

それから次のようにしてビューを問い合せます。

SELECT last_name
FROM   all_employees_vw
WHERE  department_id = 50;

ビューは複合問合せのため、オプティマイザはビューの問合せをアクセス問合せブロックにマージすることはできません。そのかわりに、オプティマイザは、その述語であるWHERE句の条件department_id=50をビューの複合問合せにプッシュすることで、アクセス文を変換できます。同等の変換された問合せは次のとおりです。

SELECT last_name
FROM   ( SELECT employee_id, last_name, job_id, commission_pct, department_id
FROM   employees
WHERE  department_id=50
UNION
SELECT employee_id, last_name, job_id, commission_pct, department_id
FROM   contract_workers
WHERE  department_id=50 );

11.1.2.1.3 副問合せのネスト解除

副問合せのネスト解除では、オプティマイザはネストされた問合せを同等の結合文に変換してから、その結合を最適化します。この変換により、オプティマイザは結合オプティマイザ手法を活用することができます。オプティマイザがこの変換を実行できるのは、結果の結合文が元の文とまったく同じ行を戻すことが保証されており、副問合せにAVGなどの集計機能が含まれていない場合のみです。

たとえば、ユーザーshとして接続して、次の問合せを実行するとします。

SELECT *
FROM   sales
WHERE  cust_id IN ( SELECT cust_id FROM customers );

customers.cust_id columnはプライマリ・キーのため、オプティマイザは複雑な問合せを、同じデータを戻すことが保証されている次の結合文に変換できます。

SELECT sales.*
FROM   sales, customers
WHERE  sales.cust_id = customers.cust_id;

オプティマイザが複雑な文を結合文に変換できない場合は、親の文と副問合せを個別の文として、それぞれに対して実行計画を選択します。それからオプティマイザは副問合せを実行し、戻された行を使用して親の問合せを実行します。問合せ計画全体の実行速度を上げるため、オプティマイザはサブプランを効率的な順序で並べます。

11.1.2.1.4 マテリアライズド・ビューを使用したクエリー・リライト

マテリアライズド・ビューは、問合せの結果をマテリアライズして表に保存するのと同じです。ユーザーの問合せが、マテリアライズド・ビューに関連付けられた問合せと互換性がある場合、データベースではその問合せをマテリアライズド・ビューの観点からリライトできます。この手法では、ほとんどの問合せ結果があらかじめ計算されているため、問合せの実行が改善されます。

問合せトランスフォーマは、ユーザー問合せと互換性のあるマテリアライズド・ビューを検索し、1つ以上のマテリアライズド・ビューを選択してユーザー問合せをリライトします。問合せをリライトするためのマテリアライズド・ビューの使用はコストベースです。したがって、マテリアライズド・ビューを使用せずに生成された計画のコストが、マテリアライズド・ビューを使用して生成された計画のコストより低い場合、問合せはリライトされません。

次のマテリアライズド・ビュー、cal_month_sales_mvについて検討します。これは各月の販売金額(ドル)を集計するものです。

CREATE MATERIALIZED VIEW cal_month_sales_mv
ENABLE QUERY REWRITE
AS
SELECT t.calendar_month_desc, SUM(s.amount_sold) AS dollars
FROM   sales s, times t
WHERE  s.time_id = t.time_id
GROUP BY t.calendar_month_desc;

販売数は通常の月で約百万と仮定します。ビューには、各月の販売金額(ドル)について、あらかじめ計算されている集計があります。次の問合せを考えてみます。これは各月の販売金額の合計を問い合せるものです。

SELECT t.calendar_month_desc, SUM(s.amount_sold)
FROM   sales s, times t
WHERE  s.time_id = t.time_id
GROUP BY t.calendar_month_desc;

クエリー・リライトを行わない場合、データベースはsalesディレクトリにアクセスして販売金額の合計を計算する必要があります。この方法ではsalesからの何百万行もの読取りが行われるため、問合せのレスポンス時間は必然的に遅くなります。また結合では、データベースが何百万もの行で結合を計算する必要があるため、問合せレスポンスはさらに遅くなります。クエリー・リライトを使用すると、オプティマイザは次のように問合せを透過的にリライトします。

SELECT calendar_month, dollars
FROM   cal_month_sales_mv;

関連項目:
クエリー・リライトの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

11.1.2.2 見積り

エスティメータは、指定された実行計画の全体コストを判断します。エスティメータは、この目標を達成するために3つのタイプの異なるメジャーを生成します。

- 選択性
このメジャーは行セットの一部の行を表します。選択性は、last_name = 'Smith'などの問合せ述語、または述語の組合せに拘束されています。

- カーディナリティ
このメジャーは、行セット内の行数を表します。

- コスト
このメジャーは、作業単位または使用されるリソースを表します。問合せオプティマイザはディスクI/O、CPU使用量、メモリー使用量を作業単位として使用します。

統計が使用可能な場合、エスティメータは統計を使用してメジャーを計算します。統計によって、メジャーの正確さの度合いは改良されます。

11.1.2.2.1 選択性

選択性は行セットの一部の行を表します。行セットとは、実表、ビュー、結合結果またはGROUP BY演算子の結果です。選択性は、last_name = 'Smith'などの問合せ述語、またはlast_name = 'Smith' AND job_type = 'Clerk'などの述語の組合せに拘束されています。

述語は、行セット内の特定の行数をフィルタします。したがって、述語の選択性は、どれだけの行数が述語テストを通過するかを示します。選択性には、0.0から1.0の範囲があります。選択性が0.0の場合、行セットから行は選択されません。一方、選択性が1.0の場合、すべての行が選択されます。値が0.0に近づくほど述語の選択性は高くなり、値が1.0に近づくほど選択性は低くなります。

オプティマイザは統計を使用できるかどうかに応じて、選択性を見積もります。

- 統計が使用不可
OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータの値に応じて、オプティマイザは、動的統計と内部のデフォルト値のいずれかを使用します。述語のタイプに応じて、使用する内部デフォルト値が異なります。たとえば、等価述語(last_name = 'Smith')の内部デフォルト値は範囲述語(last_name > 'Smith')の内部デフォルト値より小さくなります。これは等価述語の方が少ない行数を戻すことが予測されるためです。「動的統計の制御」を参照してください。

- 統計が使用可能
統計が使用可能な場合、エスティメータは統計を使用して選択性を推測します。150の個別の従業員の名字があると仮定します。等価述語last_name = 'Smith'の場合、選択性はlast_nameの個別値の数nの逆数です。この例では、問合せは150の個別値から1つの個別値を含む行を選択するため、選択性は.006になります。

last_name列でヒストグラムが使用可能な場合、エスティメータは個別値のかわりにヒストグラムを使用します。ヒストグラムには列内の異なる値の分散が示されているので、特に偏ったデータが含まれる列では、より適切な選択性の見積りが行われます。「ヒストグラムの表示」を参照してください。

11.1.2.2.2 カーディナリティ

カーディナリティは、行セット内の行数を表します。ここでの行セットとは、実表、ビュー、結合結果またはGROUP BY演算子の結果です。

11.1.2.2.3 コスト

コストは、作業単位または操作で使用されるリソースを表します。オプティマイザはディスクI/O、CPU使用量、メモリー使用量を作業単位として使用します。すなわち、操作には表をスキャンすること、索引を使用して表から行にアクセスすること、2つの表を結合すること、または行セットをソートすることなどがあります。コストは、データベースが問合せを実行してその結果を生成するときに発生すると予測される作業単位の数です。

アクセス・パスは、実表からデータを得るときに実行される作業単位数です。アクセス・パスには、表スキャン、高速全索引スキャンまたは索引スキャンがなどがあります。

- 表スキャンまたは高速全索引スキャン
表スキャンまたは高速全索引スキャンの間、データベースは単一I/Oでディスクから多数のブロックを読み取ります。そのため、スキャンのコストは、スキャンされるブロック数およびマルチブロックREADカウントに左右されます。

- 索引スキャン
索引スキャンのコストは、Bツリーにおけるレベル、つまりスキャンされる索引リーフ・ブロック数、索引キーのROWIDを使用してフェッチされる行数に左右されます。ROWIDを使用して行をフェッチするコストは、索引クラスタ化係数に依存します。「ブロックのI/O(行ではなく)の想定」を参照してください。

結合コストは、結合されている2つの行セットの個別のアクセス・コストの組合せと、結合操作のコストを表します。

関連項目:
「結合の概要」

11.1.2.3 プラン・ジェネレータ

プラン・ジェネレータは、別のアクセス・パス、結合方法および結合順序を試行することによって、問合せブロックに対する様々な計画を探索します。異なるアクセス・パス、結合方法および結合順序の様々な組合せを使用して、同じ結果をもたらすことができるため、様々な計画が可能になります。ジェネレータの目的は、コストが最も小さい計画を選択することです。

11.1.2.3.1 結合順序

結合順序は、異なる結合項目(表など)がアクセスされて結合される順序です。データベースがtable1、table2、table3を結合するとします。結合順序は次のようになります。

1. データベースはtable1にアクセスします。

2. データベースはtable2にアクセスし、その行をtable1に結合します。

3. データベースはtable3にアクセスし、そのデータをtable1とtable2の結合結果に結合します。

11.1.2.3.2 問合せサブプラン

オプティマイザは、ネストされた副問合せまたはマージされていないビューを、それぞれ個別の問合せブロックによって表し、サブプランを生成します。データベースは、問合せブロックを下位から上位へ順番に最適化します。このため、データベースは最も内側の問合せブロックを最初に最適化してそのサブプランを生成し、そして最後に問合せ全体を表す外側の問合せブロックを生成します。

問合せブロックに使用できる可能性のある計画の数は、FROM句にある結合項目の数に比例します。この数は、結合項目の数によって指数関数的に上昇します。たとえば、5つの表の結合に使用できる可能性のある計画の数は、2つの表の結合に使用できる可能性のある計画の数より大幅に多くなります。

11.1.2.3.3 計画の選択のカットオフ

プラン・ジェネレータは内部カットオフを使用して計画数を削減し、最もコストの低い計画を検索しようとします。カットオフの基準は、現行の最適な計画のコストです。現行の最適コストが大きい場合、プラン・ジェネレータはコストがより低い別の計画を探索します。現行の最適コストが低い場合は、さらなる大幅なコストの改善ができないため、プラン・ジェネレータは検索を速やかに終了します。

最適な状態に最も近いコストで計画を生成する初期結合順序で、プラン・ジェネレータが始動する場合は、カットオフが有効に機能します。適切な初期結合順序の検索は困難です。

11.1.3 バインド変数の照合

バインド変数の照合(バインド照合とも呼ばれる)では、オプティマイザはデータベースが文のハード解析を実行しているときにバインド変数の値を参照します。

問合せがリテラルを使用する場合、オプティマイザはリテラル値を使用して最良の計画を見つけることができます。ただし、問合せがバインド変数を使用する場合は、オプティマイザはSQLテキストにリテラルが存在しない状態で最良の計画を選択する必要があります。このタスクはきわめて困難になる可能性があります。バインド値を照合することにより、まるでリテラルが使用されたかのようにWHERE句条件の選択性を判断することができ、これによって計画が改善されます。

例11-1 バインド照合

データベースに次のような100,000行のemp表が存在すると仮定します。表には次の定義があります。

SQL> DESCRIBE emp

Name                   Null?    Type
---------------------- -------- ----------------------------------
ENAME                           VARCHAR2(20)
EMPNO                           NUMBER
PHONE                           VARCHAR2(20)
DEPTNO                          NUMBER

データはdeptno列で極端に偏っています。99.9%の行には値10が入っています。その他の各deptno値(0から9)は、1%の行に入っています。表の統計を収集し、結果としてdeptno列にヒストグラムが生成されました。次のように、バインド変数を定義して、バインド値9を使用してempの問合せを行います。

VARIABLE deptno NUMBER
EXEC :deptno := 9

SELECT /*ACS_1*/ count(*), max(empno)
FROM   emp
WHERE  deptno = :deptno;

問合せは10行を戻します。

COUNT(*) MAX(EMPNO)
---------- ----------
10         99

問合せの実行計画を生成するために、データベースはハード解析中に値9で照合しました。オプティマイザは、ユーザーが次の問合せを実行したかのように選択性の見積りを生成しました。

select /*ACS_1*/ count(*), max(empno)
from emp
where deptno = 9;

計画を選択するときには、オプティマイザはハード解析中にバインド値でのみ照合します。この計画は値によっては最適でない場合があります。

11.1.3.1 適応カーソル共有

適応カーソル共有機能により、バインド変数を含む1つの文が複数の実行計画を使用できるようになります。カーソル共有には「適応」機能があります。つまり、データベースが各実行または各バインド変数値に常に同じ計画を使用することがないように、カーソルがその動作を適応させます。

適切な問合せでは、データベースは、様々なバインド値に対して時間の経過とともにアクセスされるデータを監視し、特定のバインド値に対して最適なカーソルを確実に選択できるようにします。たとえば、オプティマイザは、バインド値9とバインド値10に対して、それぞれ異なる計画を選択することもあります。カーソル共有には「適応」機能があります。つまり、各実行または各バインド変数値に常に同じ計画が使用されることがないように、カーソルがその動作を適応させます。

適応カーソル共有は、デフォルトでデータベースに対して有効になっており、無効にできません。適応カーソル共有は、14を超えるバインド変数を含むSQL文に適用されません。

注意:
適応カーソル共有は、CURSOR_SHARING初期化パラメータとは無関係です(「既存アプリケーションのカーソルの共有」を参照してください)。適応カーソル共有は、ユーザー定義のバインド変数やシステム生成のバインド変数を含む文にも同様に適用できます。

11.1.3.1.1 バインド依存カーソル

バインド依存カーソルは、最適な計画がバインド変数の値に依存するカーソルです。データベースは、別の計画が有効であるかどうかを判断するために、別のバインド値を使用するバインド依存カーソルの動作を監視します。

オプティマイザは、次の基準を使用してカーソルがバインド依存かどうかを判断します。

- オプティマイザはバインド値を照合して選択性の見積りを生成しました。

- バインド値を含む列にヒストグラムが存在します。

例11-2 バインド依存カーソル

例11-1では、deptnoにバインド値9を使用して、emp表を問い合せました。ここで問合せ計画を表示するために、DBMS_XPLAN.DISPLAY_CURSOR機能を実行します。

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR);

出力は次のようになります。

----------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time|
----------------------------------------------------------------------------------
|  0 | SELECT STATEMENT             |        |      |       |   2 (100)|         |
|  1 |  SORT AGGREGATE              |        |    1 |    16 |          |         |
|  2 |   TABLE ACCESS BY INDEX ROWID| EMP    |    1 |    16 |   2   (0)| 00:00:01|
|* 3 |    INDEX RANGE SCAN          | EMP_I1 |    1 |       |   1   (0)| 00:00:01|
----------------------------------------------------------------------------------

計画は、オプティマイザが索引レンジ・スキャンを選択したことを示しています。これは値9の選択性(1%のみ)から予測されます。V$SQLを問い合せてカーソルに関する統計を表示することができます。

COL BIND_SENSI FORMAT a10
COL BIND_AWARE FORMAT a10
COL BIND_SHARE FORMAT a10
SELECT CHILD_NUMBER, EXECUTIONS, BUFFER_GETS, IS_BIND_SENSITIVE AS "BIND_SENSI",
IS_BIND_AWARE AS "BIND_AWARE", IS_SHAREABLE AS "BIND_SHARE"
FROM   V$SQL
WHERE  SQL_TEXT LIKE 'select /*ACS_1%';

次の出力に表示されるように、この文には1つの子カーソルが存在し、1回実行されています。子カーソルに関係するバッファ読取りは少数です。deptnoデータに偏りがあるため、ヒストグラムが作成されました。このヒストグラムにより、データベースはカーソルをバインド依存(IS_BIND_SENSITIVEがY)としてマークします。

CHILD_NUMBER EXECUTIONS BUFFER_GETS BIND_SENSI BIND_AWARE BIND_SHARE
------------ ---------- ----------- ---------- ---------- ----------
0          1          56 Y          N          Y

新しいバインド値で問合せを実行するたびに、データベースは新しい値の実行統計を記録し、それらを前の値の実行統計と比較します。実行統計が大幅に異なると、データベースはカーソルをバインド対応としてマークします。

11.1.3.1.2 バインド対応カーソル

バインド対応カーソルは、バインド値ごとに異なる計画を使用するのに適したバインド依存カーソルです。カーソルをバインド対応にした後で、オプティマイザは、バインド値とその選択性の見積りを基に、今後の実行のための計画を選択します。

バインド依存カーソルを含む文を実行する場合、データベースはカーソルをバインド対応としてマークするかどうかを判断します。これは、カーソルが生成するデータ・アクセス・パターンが、バインド値によって大幅に異なるかどうかによって判断されます。データベースがカーソルをバインド対応としてマークすると、次回そのカーソルが実行されたときに、データベースは次のことを行います。

- 新しいバインド値に基づいて、新規計画を生成します。

- その文に生成された元のカーソルを共有不可(V$SQL.IS_SHAREABLEがN)としてマークします。このカーソルは使用できなくなり、まず共有SQL領域から除去されます。

例11-3 バインド対応カーソル

例11-1では、バインド値9を使用してempを問い合せました。ここでバインド値10を使用してempを問い合せます。問合せは値10を含む99,900行を戻します。

COUNT(*)   MAX(EMPNO)
---------- ----------
99900      100000

この文のカーソルはバインド依存のため、オプティマイザはそのカーソルを共有可能とみなします。結果として、オプティマイザは値10に値9と同じ索引レンジ・スキャンを使用します。

V$SQL出力に、2回目(10を使用した問合せ)に同じバインド依存カーソルが実行され、最初の実行より多くのバッファ読取りが要求されたことが示されます。

SELECT CHILD_NUMBER, EXECUTIONS, BUFFER_GETS, IS_BIND_SENSITIVE AS "BIND_SENSI",
IS_BIND_AWARE AS "BIND_AWARE", IS_SHAREABLE AS "BIND_SHARE"
FROM   V$SQL
WHERE  SQL_TEXT LIKE 'select /*ACS_1%';

CHILD_NUMBER EXECUTIONS BUFFER_GETS BIND_SENSI BIND_AWARE BIND_SHARE
------------ ---------- ----------- ---------- ---------- ----------
0          2        1010 Y          N          Y

ここで2回目に値10を使用して問合せを実行します。データベースは前の実行の統計と比較して、カーソルをバインド対応としてマークします。この場合、オプティマイザは新しい計画が有効であると判断し、文のハード解析を実行して新しい計画を生成します。新しい計画は、索引レンジ・スキャンのかわりに全表スキャンを使用します。

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |   208 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |    16 |            |          |
|*  2 |   TABLE ACCESS FULL| EMP  | 95000 |  1484K|   208   (1)| 00:00:03 |
---------------------------------------------------------------------------

V$SQLの問合せにより、全表スキャンを含む計画を表す別の子カーソル(子番号1)が作成されたことが示されます。この新しいカーソルはバッファ読取りの数が少なく、バインド対応としてマークされています。

SELECT CHILD_NUMBER, EXECUTIONS, BUFFER_GETS, IS_BIND_SENSITIVE AS "BIND_SENSI",
IS_BIND_AWARE AS "BIND_AWARE", IS_SHAREABLE AS "BIND_SHARE"
FROM   V$SQL
WHERE  SQL_TEXT LIKE 'select /*ACS_1%';

CHILD_NUMBER EXECUTIONS BUFFER_GETS BIND_SENSI BIND_AWARE BIND_SHARE
------------ ---------- ----------- ---------- ---------- ----------
0          2        1010 Y          N          Y
1          2        1522 Y          Y          Y

値10で問合せを2回実行した後で、選択性がより高い値9を使用してもう一度問合せを実行します。適応カーソル共有により、オプティマイザはカーソルを「適応」させて、この値に対して全表スキャンではなく索引レンジ・スキャンを選択します。

V$SQLの問合せにより、問合せの実行に対して新しい子カーソル(子番号2)が作成されたことが示されます。

CHILD_NUMBER EXECUTIONS BUFFER_GETS BIND_SENSI BIND_AWARE BIND_SHARE
------------ ---------- ----------- ---------- ---------- ----------
0          2        1010 Y          N          N
1          1        1522 Y          Y          Y
2          1           7 Y          Y          Y

適応カーソル共有が使用されるようになったため、バインド対応でない元のカーソル(子0)は今後使用されなくなります。使用されなくなったカーソルは、共有SQL領域から除去されます。

11.1.3.1.3 カーソルのマージ

オプティマイザがバインド対応カーソルの計画を作成し、この計画が既存のカーソルと同じである場合、オプティマイザはカーソルのマージを実行できます。この場合、データベースは共有SQL領域を節約するためにカーソルをマージします。データベースは、新しいバインドの選択性を含めるために、カーソルの選択性の範囲を拡大します。

既存のカーソルの選択性の範囲内にないバインド値を使用して問合せを実行したと仮定します。データベースはハード解析を実行し、新規計画と新規カーソルを生成します。この新規計画が既存のカーソルで使用される計画と同じである場合、データベースはこれらの2つのカーソルをマージして、古いカーソルのもう一方を削除します。

11.1.3.2 バインド関連のパフォーマンスデータの表示

適応カーソル共有では、V$ビューを使用して選択性の範囲、カーソル情報(カーソルがバインド対応かバインド依存かなど)および実行統計を表示できます。

- V$SQLは、カーソルがバインド依存とバインド対応のどちらであるかを示します。

- V$SQL_CS_HISTOGRAMは、3バケットの実行履歴ヒストグラムにより、実行カウントの配分を示します。

- V$SQL_CS_SELECTIVITYは、カーソル共有をチェックするために選択性が使用された場合に、バインド変数を含むすべての述語に格納されている選択性の範囲を示します。

- V$SQL_CS_STATISTICSは、カーソルをバインド対応としてマークするかどうかを判断するためにオプティマイザが使用する情報を示します。

11.2 オプティマイザ・アクセス・パスの概要

アクセス・パスは、データベースからデータを取り出す経路です。一般に、表の行の小さいサブセットを取得する文には索引アクセス・パスが役立ちますが、表の大きな部分にアクセスする場合は全体スキャンのほうが効率的です。オンライン・トランザクション処理(OLTP)アプリケーションは、選択性が高く実行の短いSQL文から構成されており、多くの場合は索引アクセス・パスを使用するという特徴があります。ただし、意思決定支援システムでは、パーティション表を使用して、関連するパーティションの全体スキャンを実行する傾向があります。

この項では、表の行を検索して取得するために使用されるデータ・アクセス・パスについて説明します。

- 全表スキャン

- ROWIDスキャン

- 索引スキャン

- クラスタ・アクセス

- ハッシュ・アクセス

- サンプル表スキャン

- 問合せオプティマイザによるアクセス・パスの選択方法

11.2.1 全表スキャン

このタイプのスキャンでは、表にあるすべての行の読取り、選択基準を満たしていない行のフィルタが実行されます。全表スキャンでは、最高水位標以下の、表のすべてのブロックがスキャンされます。最高水位標は、使用済領域の量、またはデータを受け取るようにフォーマットされている領域を示します。各行が文のWHERE句を満たすかどうかを判断するために、各行が検査されます。

Oracle Databaseでは、全表スキャンを実行する際に、ブロックを順次読み取ります。ブロックは隣接しているため、単一ブロックよりも大きなI/Oコールによってプロセスを高速化できます。読取りコールのサイズは、1ブロックから初期化パラメータDB_FILE_MULTIBLOCK_READ_COUNTで示されるブロック数までです。マルチブロック読取りを使用すると、全表スキャンを効率的に実行できます。データベースは、各ブロックを1回のみ読み取ります。

例11-14「EXPLAIN PLAN出力」には、employees表の全表スキャン例が含まれています。

11.2.1.1 大量データにアクセスする場合に全表スキャンのほうが高速になる理由

表の中の大部分のブロックにアクセスする場合、索引レンジ・スキャンより全表スキャンのほうがコストはかかりません。全表スキャンでは、より大きなI/Oコールを使用できます。少数の大きなI/Oコールのほうが、多数の小さなI/Oコールよりもコストがかかりません。

11.2.1.2 オプティマイザが全表スキャンを使用する場合

オプティマイザは、次のいずれかの場合に全表スキャンを使用します。

11.2.1.2.1 索引の欠落

既存の索引を使用できない場合、問合せは全表スキャンを使用します。たとえば、問合せで索引付きの列にファンクションが使用されている場合、オプティマイザが索引を使用できないとき、かわりに全表スキャンを使用します。

大/小文字を区別しない検索に索引を使用する必要がある場合は、大/小文字混合データを検索列に許可しないか、検索列にUPPER(last_name)のようなファンクション索引を作成します。「パフォーマンスを考慮したファンクション索引の使用方法」を参照してください。

11.2.1.2.2 大量のデータ

表のほとんどのブロックを必要とする問合せの場合、オプティマイザは、索引が使用可能であっても、全表スキャンを使用します。

11.2.1.2.3 小さい表

表に含まれる最高水位標以下のブロック数が、1回のI/Oコールで読取り可能なDB_FILE_MULTIBLOCK_READ_COUNTブロック数に満たない場合は、アクセスされる表の部分や索引の有無にかかわらず、索引レンジ・スキャンよりも全表スキャンの方がコストがかかりません。

11.2.1.2.4 高い並列度

表の並列度が高いと、レンジ・スキャンよりも全表スキャンの方向にオプティマイザを偏らせます。表の並列度を判断するには、ALL_TABLES内のDEGREE列を調べます。

11.2.1.3 全表スキャンのヒント

オプティマイザに全表スキャンの使用を指示する場合は、ヒントFULL(table alias)を使用します。FULLヒントの詳細は、「アクセス・パスに関するヒント」を参照してください。

取得したブロックがバッファ・キャッシュのどこに置かれるかを示すには、CACHEおよびNOCACHEヒントを使用できます。CACHEヒントは、全表スキャンを実行する際、取得されたブロックがバッファ・キャッシュ内で最後に使用されたLRUリストの最後に配置されるようオプティマイザに指示します。

小規模表は、表11-2の基準に従って自動的にキャッシュされます。

表11-2 表のキャッシュ基準

表サイズ

サイズ基準

キャッシュ

小規模

ブロックの数が20より少ない、またはキャッシュされているブロックの合計の2%のうち、大きいもの

STATISTICS_LEVELをTYPICAL以上に設定した場合、表スキャン履歴に応じて表をキャッシュするかどうかを決定します。キャッシュされるブロックが今後の表スキャンで検索される可能性がある場合にのみ、表をキャッシュします。STATISTICS_LEVELをBASICに設定した場合、表はキャッシュされません。

中規模

小規模表よりも大きいが、キャッシュされているブロックの合計が10%より少ない

表スキャンおよびワークロードの履歴に基づいて、表をキャッシュするかどうかを決定します。キャッシュされるブロックが今後の表スキャンで検索される可能性がある場合にのみ、表をキャッシュします。

大規模

キャッシュされているブロックの合計が10%より大きい

キャッシュされません。

小規模表の自動キャッシュは、CACHE属性で作成または変更された表に対しては使用禁止です。

11.2.1.4 パラレル問合せの実行

全表スキャンが必要な場合、複数のパラレル実行サーバーを使用すると、レスポンス時間が改善されます。場合によっては、データベースのメモリーが大容量の場合、PGAへの直接読込みを使用するかわりに、パラレル問合せのデータをSGAにキャッシュできます。パラレル問合せは、リソースを使用する可能性があるため、通常では同時実行性の低いデータ・ウェアハウスで実行されます。

関連項目:

- 『Oracle Databaseデータ・ウェアハウス・ガイド』

- パラレル実行の使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

11.2.2 ROWIDスキャン

行のROWIDは、行が含まれるデータファイルとデータ・ブロック、およびブロック内での行の位置を指定します。ROWIDの指定による行の位置特定は、単一行を取得する最も高速な方法です。これは、取得する行のデータベース内での正確な位置が指定されるためです。

ROWIDによる表へのアクセスでは、最初に、文のWHERE句か、表の1つ以上の索引の索引スキャンにより、選択された行のROWIDを取得します。次に、ROWIDに基づいて、表内で選択された各行の位置を特定します。

例11-14「EXPLAIN PLAN出力」の計画には、jobs表およびdepartments表の索引スキャンが含まれます。データベースは、取得したROWIDを使用して行を返します。

11.2.2.1 オプティマイザがROWIDを使用する場合

通常、これは索引からROWIDを取得した後の第2のステップです。索引内に存在しない文の中の列には、表アクセスが必要になる場合があります。

ROWIDによるアクセスでは、すべての索引スキャンに従う必要はありません。文に必要な列がすべて索引に含まれていると、ROWIDによる表アクセスは行われない場合があります。

注意:
ROWIDは、データがどこに格納されているかを表すOracleの内部表現です。ROWIDは、バージョン間で変わってしまう場合があります。行の移行、行チェーン、エクスポートとインポート、およびその他の操作によって、行は移動する可能性があるため、位置に基づいたデータへのアクセスはお薦めできません。外部キーは主キーに基づいている必要があります。ROWIDの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

11.2.3 索引スキャン

この方法では、文で指定された索引付きの列の値を使用して索引が検索され、行が取得されます。索引スキャンでは、索引の1つ以上の列値に基づいて索引からデータが取得されます。索引スキャンでは、文がアクセスする索引列の値の索引を検索します。文が索引の列にのみアクセスする場合は、表からではなく、索引から直接に索引列の値を読み取ります。

索引には、索引の値の他に、その値を持っている行のROWIDも含まれています。したがって、文が索引列に加え、他の列にもアクセスする場合、ROWIDで表にアクセスするか、クラスタ・スキャンを使用して、表の行を見つけることができます。

索引スキャンには次のタイプがあります。

- ブロックのI/O(行ではなく)の想定

- 索引一意スキャン

- 索引レンジ・スキャン

- 索引レンジ・スキャン降順

- 索引スキップ・スキャン

- 全体スキャン

- 高速全索引スキャン

- 索引結合

- ビットマップ索引

11.2.3.1 ブロックのI/O(行ではなく)の想定

Oracle Databaseでは、ブロック単位でI/Oを実行します。したがって、全表スキャンを使用するかどうかのオプティマイザの決定は、行でなくアクセスされるブロックのパーセンテージに影響されます。これは索引クラスタ化係数と呼ばれています。ブロックに単一行が含まれている場合、アクセスされる行とアクセスされるブロックは同じです。

ただし、大半の表には各ブロック内に複数の行があります。したがって、目的の行数は、少数のブロックにクラスタ化されているか、多数のブロックにわたって分散している場合もあります。

クラスタ化係数は索引のプロパティですが、実際には、表のデータ・ブロック内の類似した索引付き列の値の拡散度合いに関連します。低いクラスタ化係数は、個々の行が表の少数のブロック内に集中されることを示します。逆に、高いクラスタ化係数は、個々の行が表の複数のブロックにわたってランダムに分散されることを示します。したがって、高いクラスタ化係数の場合はレンジ・スキャンを使用してROWIDで行をフェッチするのでよりコストがかかりますが、これはデータを戻すために表の中のさらに多くのブロックにアクセスする必要があるためです。例11-4では、クラスタ化係数がコストにどのような影響を与えるかを示しています。

例11-4 クラスタ化係数がコストに与える影響

次の状況を想定します。

- 9つの行を持つ表があります。

- 表のcol1に一意でない索引があります。

- c1列は現在、値A、BおよびCを格納しています。

- 表には、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を持つすべての行を取得するために、すべて読み取る必要があるためです。

11.2.3.2 索引一意スキャン

このスキャンは1つのROWIDしか戻しません。Oracle Databaseでは、1つの行にのみアクセスすることを保証するUNIQUE制約またはPRIMARY KEY制約が文に含まれる場合、一意スキャンを実行します。

「EXPLAIN PLAN出力」では、job_id_pk索引とdept_id_pk索引を使用してjobs表およびdepartments表の索引スキャンを実行します。

11.2.3.2.1 オプティマイザが索引一意スキャンを使用する場合

このアクセス・パスが使用されるのは、一意(Bツリー)索引または等価条件の指定された主キー制約によって作成された索引のすべての列をユーザーが指定した場合です。

関連項目:
索引構造の詳細とBツリーの検索方法の詳細は、『Oracle Database概要』を参照してください。

11.2.3.2.2 索引一意スキャンのヒント

一般に、一意スキャンを行うためのヒントを使用する必要はありません。ただし、表がデータベース・リンクにまたがっていて、ローカル表からアクセスされる場合や、表が小さく、オプティマイザが全表スキャンを選択する場合があります。

ヒントINDEX(alias index_name)は使用する索引を指定しますが、アクセス・パス(レンジ・スキャンや一意スキャン)は指定しません。INDEXヒントの詳細は、「アクセス・パスに関するヒント」を参照してください。

11.2.3.3 索引レンジ・スキャン

索引レンジ・スキャンは、選択性の高いデータにアクセスする共通の操作です。このスキャンは、境界(両側で境界付き)スキャンまたは非有界(片側または両側で)スキャンとすることができます。データは、索引列の昇順に戻されます。同じ値を持つ複数の行は、ROWIDで昇順にソートされます。

データをソートする必要がある場合は、索引には依存せず、ORDER BY句を使用します。索引でORDER BY句を満たすことが可能な場合、オプティマイザはこのオプションを使用し、ソートを回避します。

例11-5では、順序がレガシー・システムからインポートされており、レガシー・システムで使用された参照順に問合せを行います。この参照がorder_dateであると仮定します。

例11-5 索引レンジ・スキャン

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でソートされます。

11.2.3.3.1 オプティマイザが索引レンジ・スキャンを使用する場合

オプティマイザは、次のように条件で指定された索引の1つ以上の先頭列を検出したとき、レンジ・スキャンを使用します。

- col1 = :b1

- col1 < :b1

- col1 > :b1

- 索引内の先頭列に対する前述の条件のAND組合せ

- ワイルド・カード検索col1 like 'ASD%'は、先頭に指定しないでください。そうでない場合、条件col1 like '%ASD'によって、レンジ・スキャンが生じません。

レンジ・スキャンでは、一意索引または非一意索引を使用できます。レンジ・スキャンでは、索引列がORDER BY/GROUP BY句を構成しているときにソートを回避します。

11.2.3.3.2 索引レンジ・スキャンのヒント

オプティマイザが他の索引を選択したり、全表スキャンを使用する場合は、ヒントが必要になる場合があります。ヒントINDEX(table_alias index_name)では、特定の索引を使用するようにオプティマイザに指示します。INDEXヒントの詳細は、「アクセス・パスに関するヒント」を参照してください。

11.2.3.4 索引レンジ・スキャン降順

索引レンジ・スキャン降順は、データが降順で戻されること以外、索引レンジ・スキャンと同じです。デフォルトでは、索引は昇順に格納されます。通常、このスキャンが使用されるのは、最初に最新のデータを戻すためにデータを降順に並べる場合か、指定された値より小さい値を検索する場合です。

11.2.3.4.1 オプティマイザが索引レンジ・スキャン降順を使用する場合

索引で降順ソート句を満たすことが可能な場合、オプティマイザは索引レンジ・スキャン降順を使用します。

11.2.3.4.2 索引レンジ・スキャン降順のヒント

このアクセス・パスには、INDEX_DESC(table_alias index_name)ヒントを使用します。INDEX_DESCヒントの詳細は、「アクセス・パスに関するヒント」を参照してください。

11.2.3.5 索引スキップ・スキャン

索引スキップ・スキャンにより、接頭辞の付いていない列による索引スキャンが改善されます。多くの場合、索引ブロックをスキャンするほうが、表データ・ブロックをスキャンするより高速です。

スキップ・スキャンにより、コンポジット索引をさらに小さい副索引に論理的に分割できます。スキップ・スキャンでは、コンポジット索引の初期列が問合せで指定されていません。つまり、その列がスキップされます。

論理副索引の個数は、最初の列にある個別値の数によって判断されます。スキップ・スキャンは、コンポジット索引の先頭列に個別値がほとんどなく、索引の非先頭キーに個別値が多数ある場合に有効です。

コンポジット索引の先頭列が問合せ述語で指定されていない場合、データベースは索引スキップ・スキャンを選択することがあります。たとえば、sh.customers表の顧客に対して次の問合せを行うと仮定します。

SELECT * FROM sh.customers WHERE cust_email = 'Abbey@company.com';

customers表には列cust_genderがあり、この値はMかFのどちらかです。コンポジット索引が次のようにして作成された列(cust_gender、cust_email)に存在するとします。

CREATE INDEX customers_gender_email ON sh.customers (cust_gender, cust_email);

例11-6に、索引エントリの一部を示します。

例11-6 コンポジット索引エントリ

F,Wolf@company.com,rowid
F,Wolsey@company.com,rowid
F,Wood@company.com,rowid
F,Woodman@company.com,rowid
F,Yang@company.com,rowid
F,Zimmerman@company.com,rowid
M,Abbassi@company.com,rowid
M,Abbey@company.com,rowid

この索引のスキップ・スキャンは、cust_genderがWHERE句で指定されていない場合でも使用できます。

スキップ・スキャンでは、論理副索引の個数は、先頭列にある個別値の数によって判断されます。例11-6では、先頭列に可能な値は2つあります。索引は、キーFを持つ1つの副索引と、キーMを持つ2番目の副索引に論理的に分割されます。

電子メールがAbbey@company.comの顧客のレコードを検索する場合、最初に値Fを持つ副索引が検索され、次に値Mを持つ副索引が検索されます。概念上、データベースで問合せが次のように処理されます。

SELECT * FROM sh.customers WHERE cust_gender = 'F'
AND cust_email = 'Abbey@company.com'
UNION ALL
SELECT * FROM sh.customers WHERE cust_gender = 'M'
AND cust_email = 'Abbey@company.com';

関連項目:
スキップ・スキャンの詳細は、『Oracle Database概要』を参照してください。

11.2.3.6 全体スキャン

全索引スキャンを行うとソート操作が必要なくなります。これはデータが索引キーで並べられるためです。全体スキャンではブロックが単独で読み取られます。Oracle Databaseでは全体スキャンを次のような状況で使用します。

- 次の要件を満たすORDER BY句が問合せに存在する場合。

- ORDER BY句の列すべてが索引に含まれている。

- ORDER BY句の列の順序が先行する索引列の順序と一致している。

ORDER BY句には、索引内のすべての列、または索引内の列のサブセットを含めることができます。

- 問合せにソート/マージ結合が必要な場合。問合せが次の要件を満たす場合、全表スキャンの後にソートを実行するのではなく、全索引スキャンを実行できます。

- 問合せで参照される列すべてが索引に含まれている。

- 問合せで参照される列の順序が先行する索引列の順序と一致している。

問合せには、索引内のすべての列、または索引内の列のサブセットを含めることができます。

- GROUP BY句が問合せ内に存在し、GROUP BY句の列が索引内に存在する場合。列の順序を索引やGROUP BY句の順序と同じにする必要はありません。GROUP BY句には、索引内のすべての列、または索引内の列のサブセットを含めることができます。

関連項目:
「ソート/マージ結合」

11.2.3.7 高速全索引スキャン

高速全索引スキャンは、問合せに必要なすべての列が索引に含まれており、索引キーの1つ以上の列にNOT NULL制約が設定されている場合に、全表スキャンの代替となるスキャンです。高速全スキャンは、表にアクセスすることなく索引そのものに存在するデータにアクセスします。データが索引キー順にソートされていないため、このスキャンを使用してソート操作を排除できません。高速全スキャンでは、全索引スキャンとは異なり、マルチブロック読取りを使用して索引全体が読み取られ、パラレルでスキャンできます。

初期化パラメータOPTIMIZER_FEATURES_ENABLEまたはINDEX_FFSヒントを使用して高速全索引スキャンを指定できます。高速全スキャンは、表スキャンと同様にマルチブロックI/Oを使用してパラレルで実行できるため、通常の全索引スキャンより高速です。

注意:
索引にPARALLELを設定してもコスト計算には影響しません。

11.2.3.7.1 高速全索引スキャンのヒント

高速全体スキャンには、特別な索引ヒントINDEX_FFSがあります。この形式と引数は、通常のINDEXヒントと同じです。INDEX_FFSヒントの詳細は、「アクセス・パスに関するヒント」を参照してください。

11.2.3.8 索引結合

索引結合は、問合せで参照される表の列すべてが含まれている複数の索引のハッシュ結合です。索引結合を使用すると、関連するすべての列値を索引から取得できるため、表にアクセスする必要はありません。索引結合を使用して、ソート操作を排除することはできません。

11.2.3.8.1 索引結合のヒント

索引結合は、INDEX_JOINヒントを使用して指定できます。INDEX_JOINヒントの詳細は、「アクセス・パスに関するヒント」を参照してください。

11.2.3.9 ビットマップ索引

ビットマップ結合は、キー値用のビットマップおよび各ビット位置をROWIDに変換するマッピング機能を使用します。ビットマップは、AND条件とOR条件の変換にブール演算を使用して、WHERE句内の複数の条件に対応する索引を効果的にマージできます。

注意:
ビットマップ索引とビットマップ結合索引は、Oracle Enterprise Editionでのみ使用できます。

関連項目:
ビットマップ索引の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

11.2.4 クラスタ・アクセス

クラスタ・スキャンは、索引クラスタに格納された表から、同じクラスタ・キー値を持つすべての行を取得する場合に使用します。索引クラスタでは、同じクラスタ・キー値を持つすべての行が同じデータ・ブロックに格納されます。クラスタ・スキャンを実行するには、最初に、クラスタ索引をスキャンして、選択された行の1つのROWIDを取得します。次に、このROWIDに基づいて行の位置を特定します。

11.2.5 ハッシュ・アクセス

ハッシュ・スキャンでは、ハッシュ値に基づいてハッシュ・クラスタ内の行の位置を特定します。ハッシュ・クラスタ内においては、同一のハッシュ値を持つすべての行が同じデータ・ブロックに格納されています。ハッシュ・スキャンを実行するには、最初に、文で指定されたクラスタ・キー値にハッシュ関数を適用することによって、ハッシュ値を取得します。次に、そのハッシュ値を持つ行が含まれているデータ・ブロックをスキャンします。

11.2.6 サンプル表スキャン

サンプル表スキャンでは、単純な表、または結合およびビューを含む文などの複合SELECT文からデータのランダムなサンプルが取り出されます。このアクセス・パスは、文のFROM句にSAMPLE句またはSAMPLE BLOCK句が含まれているときに使用されます。SAMPLE句を使用した行単位のサンプリングでサンプル表スキャンを実行する場合、データベースは表の行を指定されたパーセントだけ読み取ります。SAMPLE BLOCK句を使用したブロック単位のサンプリングでサンプル表スキャンを実行する場合、データベースは表のブロックを指定されたパーセントだけ読み取ります。

例11-7は、サンプル表スキャンを使用して、ブロックによるサンプリングを行ってemployees表の1%にアクセスします。

例11-7 サンプル表スキャン

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

11.2.7 問合せオプティマイザによるアクセス・パスの選択方法

問合せオプティマイザは、次の要因に従ってアクセス・パスを選択します。

- 文で使用可能なアクセス・パス

- 各アクセス・パスまたはパスの組合せを使用して文を実行するための見積りコスト

アクセス・パスを選択する場合、オプティマイザは、文のWHERE句、およびFROM句の条件を調べて、使用可能なアクセス・パスを最初に判断します。次に、オプティマイザは、使用可能なアクセス・パスを使用して可能な実行計画のセットを生成し、文にアクセス可能な索引、列および表の統計を使用して各見積りコストを生成します。そして最後に、オプティマイザは見積りコストが最も少ない実行計画を選択します。

アクセス・パスを選択する場合、問合せオプティマイザは次の影響を受けます。

- オプティマイザ・ヒント
ヒントを使用し、特定のアクセス・パスを使用するようオプティマイザに指示できます。ただし、文のFROM句にSAMPLEまたはSAMPLE BLOCKが含まれているときを除きます。

関連項目:
SQL文のヒントの詳細は、第19章「オプティマイザ・ヒントの使用方法」を参照してください。

- 古い統計

たとえば、表が作成された後に解析されなかった場合およびブロックが最高水位標以下のDB_FILE_MULTIBLOCK_READ_COUNTより少ない場合は、オプティマイザはその表は小さいと判断し、全表スキャンが使用されます。ALL_TABLES表内のLAST_ANALYZED列およびBLOCKS列を見て、統計を調べてください。

11.3 結合の概要

結合は、複数の表からデータを取得する文です。結合の特徴は、FROM句内に複数の表が並んでいる点です。WHERE句に存在する結合条件は、表の関係を定義します。結合では、片方の行セットが内部と呼ばれ、もう一方が外部と呼ばれます。

この項では、次の内容を説明します。

- 問合せオプティマイザによる結合文の実行方法

- 問合せオプティマイザによる結合の実行計画の選択方法

- ネステッド・ループ結合

- ハッシュ結合

- ソート/マージ結合

- デカルト結合

- 外部結合

11.3.1 問合せオプティマイザによる結合文の実行方法

結合文に実行計画を選択するために、オプティマイザは、相互に関連する次の決定を行う必要があります。

- アクセス・パス
単純な文では、オプティマイザは、結合文の各表からデータを取り出すアクセス・パスを選択する必要があります。

- 結合方法
行ソースの各ペアを結合するには、結合操作を実行する必要があります。結合方法には、ネステッド・ループ結合、ソート/マージ結合、デカルト結合およびハッシュ結合があります。

- 結合順序
Oracle Databaseでは、3つ以上の表を結合する文を実行する場合、2つの表を結合し、その結果作成された行ソースを次の表に結合します。このプロセスは、すべての表が結合されて結果が生成されるまで続きます。

関連項目:
「オプティマイザ・アクセス・パスの概要」

11.3.2 問合せオプティマイザによる結合の実行計画の選択方法

実行計画を選択するとき、問合せオプティマイザでは次の点が考慮されます。

- オプティマイザは、2つ以上の表を結合した結果を、最大1つの行を含む行ソースに限定するかどうかを最初に判断します。オプティマイザは、このような状況を表のUNIQUE制約およびPRIMARY KEY制約に基づいて認識します。このような状況が存在する場合、オプティマイザはこれらの表を結合順序の最初に並べます。その後で、残りの表の結合を最適化します。

- 外部結合条件を持つ結合文では、外部結合演算子のある表の結合順序は、条件内のその他の表の後にしてください。オプティマイザは、この規則に違反する結合順序を考慮しません。同様に、副問合せがアンチ結合またはセミ結合に変換されたときは、その副問合せからの表は、それらが接続または相互に関連付けされた外部問合せブロック内の表の後に置きます。ただし、ある環境では、ハッシュ・アンチ結合およびセミ結合はこの順序条件を上書きできます。

問合せオプティマイザでは、適用可能な結合順序、結合方法および使用可能なアクセス・パスに従ってオプティマイザが実行計画のセットを生成します。次に、オプティマイザは各計画のコストを見積り、コストが最も小さいものを選択します。オプティマイザは、次の方法でコストを見積ります。

- ネステッド・ループ操作のコストは、外部表で選択されている各行およびその行に対する内部表の一致行をメモリーに読み取るコストが基準になっています。オプティマイザは、データ・ディクショナリ内の統計を使用してこれらのコストを見積ります。

- ソート/マージ結合のコストは、主に、すべてのソースをメモリーに読み取ってソートするコストを基準にしています。

- ハッシュ結合のコストは、主に、結合への入力側の1つ上にハッシュ表を作成するコストと、それを調べるために結合のもう一方からの行を使用するコストに基づきます。

オプティマイザは、各操作のコストを判断するときにはその他の要因についても考慮します。たとえば、次のようにします。

- ソート領域のサイズが小さいと、小さいソート領域内でのソートにCPU時間とI/Oがより多く消費されるため、ソート/マージ結合のコストが大きくなる傾向があります。SQL作業領域のサイズ設定の詳細は、「PGAメモリー管理」を参照してください。

- マルチブロックREADカウントが大きいと、ネステッド・ループ結合に関してソート/マージ結合のコストが少なくなる傾向があります。1回のI/Oでディスクから多数の連続ブロックが読み取られる場合は、ネステッド・ループ結合の内部表の索引によって、全表スキャンよりパフォーマンスが向上する可能性は低くなります。マルチブロック読取り数は、初期化パラメータDB_FILE_MULTIBLOCK_READ_COUNTによって指定されます。

ORDEREDヒントを使用して、オプティマイザが選択した結合順序を上書きできます。ORDEREDヒントによって、外部結合に関するこの規則に違反する結合順序が指定された場合、オプティマイザはこのヒントを無視して順序を選択します。結合方法に関するオプティマイザの選択も、ヒントを使用して上書きできます。

関連項目:
オプティマイザ・ヒントの詳細は、第19章「オプティマイザ・ヒントの使用方法」を参照してください。

11.3.3 ネステッド・ループ結合

ネステッド・ループ結合は、次の条件に該当する場合に役立ちます。

- 小さなデータ・サブセットを結合する場合。

- 結合条件が第2の表へのアクセスの効率的な方法である場合。

内部表が、外部表によって駆動される(依存する)ことを確認することが重要です。内部表のアクセス・パスが外部表とは独立している場合は、外部ループを繰り返すたびに同じ行が取得されます。これは、パフォーマンスをかなり低下させてしまいます。そのような場合は、2つの独立した行ソースを結合するハッシュ結合のほうがパフォーマンスが優れています。

ネステッド・ループ結合には、次のステップがあります。

1. オプティマイザで駆動表が決定され、これが外部表に指定されます。

2. その他の表は、内部表に指定します。

3. 外部表の行ごとに、内部表のすべての行がアクセスされます。外部ループは外部表にあるすべての行に対するものであり、内部ループは内部表の中にあるすべての行に対するものです。次のように、外部ループは実行計画の内部ループの前に表示されます。

NESTED LOOPS
outer_loop
inner_loop

関連項目:
「デカルト結合」

11.3.3.1 ネステッド・ループ結合の従来の実装と新規の実装

Oracle Database 11gには、新しいネステッド・ループ結合の実装が含まれます。そのため、ネステッド・ループを含む実行計画は、以前のリリースのOracle Databaseとは異なる状態で表示されます。Oracle Database 11gでは、ネステッド・ループ結合の新規の実装と従来の実装の両方が可能です。そのため実行計画を分析する場合は、NESTED LOOPS結合の行ソースの数が異なることを理解しておくことが重要です。

11.3.3.1.1 ネステッド・ループ結合の従来の実装

次の問合せについて考えます。

SELECT e.first_name, e.last_name, e.salary, d.department_name
FROM hr.employees e, hr.departments d
WHERE d.department_name IN ('Marketing', 'Sales')
AND e.department_id = d.department_id;

Oracle Database 11gより前のリリースでは、この問合せの実行計画は、次の実行計画のように表示されます。

-------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                   |    19 |   722 |     3  (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMPLOYEES         |    10 |   220 |     1  (0)| 00:00:01 |
|   2 |   NESTED LOOPS              |                   |    19 |   722 |     3  (0)| 00:00:01 |
|*  3 |    TABLE ACCESS FULL        | DEPARTMENTS       |     2 |    32 |     2  (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN         | EMP_DEPARTMENT_IX |    10 |       |     0  (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("D"."DEPARTMENT_NAME"='Marketing' OR "D"."DEPARTMENT_NAME"='Sales')
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

この例では、結合の外部側はhr.departments表のスキャンで構成され、このスキャンによって、条件department_name IN ('Marketing', 'Sales')に一致する行が戻されます。内部ループにより、これらの部署に関連付けられている従業員がhr.employees表に取得されます。

11.3.3.1.2 ネステッド・ループ結合の新規の実装

Oracle Database 11gでは、新しいネステッド・ループ結合の実装が導入され、物理I/Oの全体の待機時間が短縮されました。バッファ・キャッシュに索引または表ブロックが存在せず、結合の処理に必要な場合、物理I/Oが必要となります。Oracle Database 11gでは、一度に1つのリクエストを処理するのではなく、ベクターI/Oを使用して複数の物理I/Oリクエストをまとめて処理できます。

ネステッド・ループ結合の新規の実装の一環として、NESTED LOOPS結合の2つの行ソースが実行計画に表示されます。以前のリリースでは1行のみが表示されていました。この場合、Oracle Databaseでは結合の外部側の表の値と内部側の索引とを結合するためにNESTED LOOPS結合の1つの行ソースを割り当てます。もう1つの行ソースは、最初の結合の結果を結合するために割り当てられます。これにより、索引に格納されている行IDが含まれ、結合の内部側に表が存在します。

「ネステッド・ループ結合の従来の実装」の問合せについて考えます。Oracle Database 11gの新しいネステッド・ループ結合の実装を使用すると、この問合せの実行計画は次の実行計画のように表示されます。

------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name              | Rows  | Bytes | Cost(%CPU)| Time      |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                   |    19 |   722 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |                   |       |       |            |          |
|   2 |   NESTED LOOPS               |                   |    19 |   722 |     3   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS FULL         | DEPARTMENTS       |     2 |    32 |     2   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | EMP_DEPARTMENT_IX |    10 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| EMPLOYEES         |    10 |   220 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("D"."DEPARTMENT_NAME"='Marketing' OR "D"."DEPARTMENT_NAME"='Sales')
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

この場合、hr.departments表の行は、最初の結合の外部側で構成されます。最初の結合の内部側は索引emp_department_ixです。最初の結合の結果は、2番目の結合の外部側で構成されます。これにより、結合の内部側にhr.employees表が存在します。

2番目の結合の行ソースが割り当てられない場合があります。この場合、実行計画は以前のリリースと同様に表示されます。次にこのような状況について説明します。

- 結合の内部側で必要なすべての列が索引に存在するため、表にアクセスする必要がない。この場合、Oracle Databaseでは結合の1つの行ソースのみが割り当てられます。

- 戻された行の順序が以前のリリースの順序と異なっている。したがって、Oracle Databaseで行の特定の順序を予約しようとする場合(たとえばORDER BYソートを行う必要がない場合など)、Oracle Databaseではネステッド・ループ結合の従来の実装が使用されます。

- OPTIMIZER_FEATURES_ENABLE初期化パラメータが、Oracle Database 11gより前のリリースに設定されている。この場合、Oracle Databaseではネステッド・ループ結合の従来の実装が使用されます。

11.3.3.2 オプティマイザがネステッド・ループ結合を使用する場合

オプティマイザは、2つの表の間で適切な駆動条件で少数の行を結合する場合に、ネステッド・ループ結合を使用します。外部ループから内部ループに起動するので、実行計画の中の表の順序が重要になります。

外部ループは駆動行ソースです。このループは、結合条件を駆動するための一連の行を生成します。行ソースは、索引スキャンまたは全表スキャンでアクセスされる表にすることができます。また、他の操作からでも行を生成できます。たとえば、ネステッド・ループ結合からの出力は、別のネステッド・ループ結合の行ソースとなります。

内部ループは外部ループから戻された行ごとに、索引スキャンによって反復されます。内部ループのアクセス・パスが外部ループに依存していない場合は、デカルト積で終了することが可能で、外部ループの反復ごとに、内部ループは同じ行セットを生成します。したがって、2つの独立した行ソースをまとめて結合する場合は、他の結合方法を使用することをお薦めします。

11.3.3.3 ネステッド・ループ結合のヒント

オプティマイザが他の結合方法の使用を選択した場合は、USE_NL(table1 table2)ヒントを使用できます。table1とtable2は、結合される表の別名です。

データが十分に小さいSQL例の場合は、オプティマイザは全表スキャンを優先してハッシュ結合を使用します。例11-8「ハッシュ結合」は、そのSQLの例です。ただし、USE_NLを追加してオプティマイザに指示し、結合方法をネステッド・ループに変更できます。USE_NLヒントの詳細は、「結合操作のヒント」を参照してください。

11.3.3.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

11.3.4 ハッシュ結合

ハッシュ結合は、大きなデータ・セットの結合に使用されます。オプティマイザは、2つの表またはデータ・ソースの小さいほうを使用して、メモリー内の結合キーにハッシュ表を作成します。次に、大きいほうの表をスキャンし、ハッシュ表を調べて結合された行を見つけます。

この方法は、小さいほうの表が使用可能なメモリーに収まる場合に最適です。これにより、コストが2つの表のデータに対する1回のリード・パスに制限されます。

11.3.4.1 オプティマイザがハッシュ結合を使用する場合

オプティマイザは、2つの表が等価結合で結合され、次の条件のいずれかが真である場合に、ハッシュ結合で2つの表を結合します。

- 大量のデータを結合する必要がある。

- 小規模表の大きな部分を結合する必要がある。

例11-8では、orders表を使用してハッシュ表を作成します。より大きなorder_itemsは、後でスキャンします。

例11-8 ハッシュ結合

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

11.3.4.2 ハッシュ結合のヒント

2つの表を結合するときに、ハッシュ結合を使用するようにオプティマイザに指示するには、USE_HASHヒントを適用します。SQL作業領域のサイズ設定の詳細は、「PGAメモリー管理」を参照してください。USE_HASHヒントの詳細は、「結合操作のヒント」を参照してください。

11.3.5 ソート/マージ結合

ソート/マージ結合では、2つの独立したソースの行を結合できます。ハッシュ結合は、一般に、ソート/マージ結合よりパフォーマンスが優れています。ただし、次の条件が2つとも存在する場合は、ハッシュ結合よりソート/マージ結合のほうが優れたパフォーマンスを実現します。

- 行ソースはソート済。

- ソート操作を終了する必要なし。

ソート/マージ結合に、より低速のアクセス方法(全表スキャンとは対照的な索引スキャン)の選択が含まれている場合、ソート/マージを使用する利点が失われる可能性があります。

ソート/マージ結合は、2つの表の間の結合条件が<、<=、>または>=などの等価条件ではない場合に有効です。ソート/マージ結合は、大きいデータ・セットの場合にネステッド・ループ結合よりパフォーマンスが優れています。等価条件がないかぎり、ハッシュ結合を使用できません。

マージ結合には、駆動表の概念はありません。結合には、2つのステップが含まれています。

1. ソート結合操作: 両方の入力が、結合キーでソートされる。

2. マージ結合処理: ソートされたリストがマージされる。

入力を結合列でソートすると、その行ソースのソート結合操作は行われません。ただし、ソート/マージ結合では、最後の一致に戻ることができるように結合の右側に対して位置調整できるソート・バッファが常に作成されます。この場合、重複した結合キー値は結合の左側から取り出されます。

11.3.5.1 オプティマイザがソート/マージ結合を使用する場合

オプティマイザは、次の条件が真である場合に、ハッシュ結合よりソート/マージ結合を選択して大量のデータを結合します。

- 2つの表の結合条件が、等価結合ではない。

- 他の操作でソートが必要なため、オプティマイザは、ハッシュ結合よりソート/マージを使用するほうがコストが低いと判断した。

11.3.5.2 ソート/マージ結合のヒント

ソート/マージ結合を使用するようオプティマイザに指示するには、USE_MERGEヒントを適用します。また、アクセス・パスを設定するためのヒントを与える必要がある場合があります。

USE_MERGEヒントを使用してオプティマイザを上書きすることが適切な場合もあります。たとえば、オプティマイザは表に対する全体スキャンを選択して問合せ内でのソート操作を回避できます。ただし、大きい表は全表スキャンによる高速アクセスの場合とは異なり、索引および単一ブロック読取りでアクセスされるため、コストがかかります。

USE_MERGEヒントの詳細は、「結合操作のヒント」を参照してください。

11.3.6 デカルト結合

文に他の表との結合条件のない表が1つ以上存在する場合、デカルト結合が使用されます。オプティマイザは、データ・ソースにあるすべての行を、2つのセットのデカルト積を作成しながら、別のデータ・ソースにあるすべての行と結合します。

11.3.6.1 オプティマイザがデカルト結合を使用する場合

オプティマイザは、結合条件のない2つの表を結合する指示を受けると、デカルト結合を実行します。場合によっては、2つの表の間に共通のフィルタ条件が存在して、オプティマイザが可能な結合条件として採用する可能性があります。また、オプティマイザが、同じ大きい表に結合されている非常に小さい2つの表のデカルト積を生成するように決定する場合もあります。

11.3.6.2 デカルト結合のヒント

ORDEREDヒントを適用して、デカルト結合を使用するようにオプティマイザに指示します。結合表を指定する前に表を指定すると、オプティマイザはデカルト結合を行います。

11.3.7 外部結合

外部結合は単純結合の結果を拡張したものです。外部結合は、結合条件に一致するすべての行および結合条件が他の表のどの行とも一致しない、表の一部またはすべての行を戻します。

11.3.7.1 ネステッド・ループ外部結合

この操作は、2つの表の外部結合をループ処理する場合に使用されます。外部結合は、内部(オプション)表に対応する行がない場合でも、外部(保存されている)表の行を戻します。

正規の外部結合で、オプティマイザはコストに基づいて表(駆動する側と駆動される側)の順序を選択します。ただし、ネステッド・ループ外部結合では、結合条件によって表の順序が決まります。行が保存される外部表を使用して、内部表を駆動します。

オプティマイザは、ネステッド・ループ結合を使用し、次の状況で外部結合を処理します。

- 外部表から内部表まで起動できる。

- データ量が少なく、ネステッド・ループ方法が効果的と判断できる。

ネステッド・ループ外部結合の例の場合は、USE_NLヒントを例11-9に追加して、ネステッド・ループを使用するようにオプティマイザに指示できます。たとえば、次のようにします。

SELECT /*+ USE_NL(c o) */ 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;

11.3.7.2 ハッシュ結合外部結合

オプティマイザは、次の場合に外部結合にハッシュ結合を使用します。

- データ量が十分に多く、ハッシュ結合法が効果的である。

- 外部表から内部表まで起動することができない。

表の順序はコストにより決定されます。外部表は、保存された行も含めて、ハッシュ表を作成する場合に使用されるか、またはハッシュ表を調べるときに使用される場合があります。

例11-9に、ハッシュ結合外部結合を使用した一般的な問合せを示します。この例では、与信限度が1000を超えるすべての顧客を問い合せています。外部結合は、オーダーを持たない顧客を見逃さないようにするために必要です。

例11-9 ハッシュ結合外部結合

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

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------|   0 | SELECT STATEMENT    |           |       |       |     7 (100)|          |
|   1 |  HASH GROUP BY      |           |   168 |  3192 |     7  (29)| 00:00:01 |
|*  2 |   HASH JOIN OUTER   |           |   318 |  6042 |     6  (17)| 00:00:01 |
|*  3 |    TABLE ACCESS FULL| CUSTOMERS |   260 |  3900 |     3   (0)| 00:00:01 |
|*  4 |    TABLE ACCESS FULL| ORDERS    |   105 |   420 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C"."CUSTOMER_ID"="O"."CUSTOMER_ID")

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------
3 - filter("C"."CREDIT_LIMIT">1000)
4 - filter("O"."CUSTOMER_ID">0)

この問合せは、様々な条件に一致する顧客を検索します。内部表に対応する行が見つからないと、外部結合は外部(保たれている)表の行とともに内部表の列に対してNULLを戻します。この操作で、orders行も持たないcustomers行がすべて検索されます。

この場合、外部結合条件は次のとおりです。

customers.customer_id = orders.customer_id(+)

この条件の構成要素を次に示します。

- 外部表はcustomersです。

- 内部表はordersです。

- この結合は、orders内に対応する行を持たない行を含むcustomers行を保存します。

行を戻すには、NOT EXISTS副問合せを使用できます。ただし、表の全行の問合せを行っているため、ハッシュ結合のほうがパフォーマンスが優れています(NOT EXISTS副問合せがネストされていない場合を除く)。

例11-10では、外部結合はマルチ表ビューに対して行われます。オプティマイザは通常の結合のようにビューを操作したり、述語をプッシュできないので、ビューの行セット全体を作成します。

例11-10 マルチ表ビューへの外部結合

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 AS
SELECT l.product_id, SUM(l.quantity*unit_price) revenue,
o.order_id, o.customer_id
FROM orders o, order_items l
WHERE o.order_id = l.order_id
GROUP BY l.product_id, o.order_id, o.customer_id;

11.3.7.3 ソート/マージ外部結合

外部結合で、外部(保たれている)表から内部(オプション)表への駆動ができない場合、外部結合ではハッシュ結合またはネステッド・ループ結合が使用できません。その場合、外部結合では結合操作を実行するためにソート/マージ外部結合を使用します。

オプティマイザは、次の場合に外部結合にソート/マージを使用します。

- ネステッド・ループ結合の効率が悪い場合。データ量により、ネステッド・ループ結合は効率が悪い場合があります。

- 他の操作でソートが必要であるため、ハッシュ結合よりソート/マージを使用するほうがコストが低いと判断した場合。

11.3.7.4 完全外部結合

完全外部結合は、左と右の外部結合の組合せのように動作します。内部結合では、内部結合の結果で戻されなかった両方の表からの行は保たれており、NULLで拡張されます。つまり、完全外部結合を使用すると、表をまとめて結合できますが、結合される表内に対応する行を持たない行も示すことができます。

例11-11の問合せでは、全部門と、その各部門に属する全社員を取得しますが、これには次の内容も含まれます。

- 部門に属さない全社員

- 社員のいない全部門

例11-11 完全外部結合

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.

Oracle Database 11g以上では、可能なかぎり、完全外部結合を実行する場合、ハッシュ結合に基づいたネイティブの実行方法が自動的に使用されます。新しい方法を使用して完全外部結合を実行する場合、問合せの実行計画にはHASH JOIN FULL OUTERが含まれます。例11-12に、例11-11の問合せの実行計画を示します。

例11-12 完全外部結合の実行計画

----------------------------------------------------------------------------------------
| Id  | Operation               | Name       | Rows  | Bytes | Cost (%CPU)| Time      |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |            |   122 |  4758 |     6  (34)| 00:0 0:01 |
|   1 |  SORT ORDER BY          |            |   122 |  4758 |     6  (34)| 00:0 0:01 |
|   2 |   VIEW                  | VW_FOJ_0   |   122 |  4758 |     5  (20)| 00:0 0:01 |
|*  3 |    HASH JOIN FULL OUTER |            |   122 |  1342 |     5  (20)| 00:0 0:01 |
|   4 |     INDEX FAST FULL SCAN| DEPT_ID_PK |    27 |   108 |     2   (0)| 00:0 0:01 |
|   5 |     TABLE ACCESS FULL   | EMPLOYEES  |   107 |   749 |     2   (0)| 00:0 0:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

HASH JOIN FULL OUTERが計画に含まれている点に注意してください。そのため、問合せではハッシュ完全外部結合の実行方法が使用されます。2つの表の完全外部結合条件が等価結合の場合、通常はハッシュ完全外部結合の実行方法が可能であるため、Oracle Databaseでは自動的にこの方法が使用されます。

ハッシュ完全外部結合の実行方法の使用を考慮するようにオプティマイザに指示するには、NATIVE_FULL_OUTER_JOINヒントを適用します。ハッシュ完全外部結合の実行方法の使用を考慮しないようにオプティマイザに指示するには、NO_NATIVE_FULL_OUTER_JOINヒントを適用します。NO_NATIVE_FULL_OUTER_JOINヒントでは、オプティマイザに対して、指定した各表を結合する際にネイティブの実行方法を除外するように指示します。かわりに、左外部結合と逆結合を組み合せたものとして完全外部結合が実行されます。

11.4 実行計画の読み方と理解

Oracle Databaseでは、SQL文を実行するために多数のステップを実行する必要があります。実行される各ステップでは、データベースからのデータ行の物理的な取出し、またはユーザーが発行する文に返すデータ行の準備のどちらかが実行されます。文を実行するためにOracle Databaseが使用するステップの組合せが実行計画です。実行計画には、文がアクセスする各表へのアクセス・パスと、適切な結合方法に基づく表の順序(結合順序)が含まれています。

関連項目:

- 「オプティマイザ・アクセス・パスの概要」

- 第12章「EXPLAIN PLANの使用方法」

11.4.1 EXPLAIN PLANの概要

オプティマイザがSQL文に対して選択した実行計画を確認するには、EXPLAIN PLAN文を使用します。文が発行されると、オプティマイザが実行計画を選択した後で、計画を説明するデータがデータベース表に挿入されます。EXPLAIN PLAN文を発行して、出力表を問い合せます。

EXPLAIN PLAN文の基本的な使用方法は次のとおりです。

- SQLスクリプトCATPLAN.SQLを使用し、使用しているスキーマ内にPLAN_TABLEというサンプル出力表を作成します。「PLAN_TABLE出力表」を参照してください。

- SQL文の前に、EXPLAIN PLAN FOR句を含めます。「EXPLAIN PLANの実行」を参照してください。

- EXPLAIN PLAN文を発行した後、Oracle Databaseから提供されるスクリプトまたはパッケージのいずれかを使用して最新の計画表出力を表示します。「PLAN_TABLE出力の表示」を参照してください。

- EXPLAIN PLANの出力実行順序は、最も右端にインデントされている行から始まります。次のステップは、その行の親です。2つの行が等しくインデントされている場合、通常、一番上の行が最初に実行されます。

注意:

- この章のEXPLAIN PLAN出力表は、utlxpls.sqlスクリプトで表示したものです。

- この章のEXPLAIN PLAN出力のステップは、システムによって異なる場合があります。データベース構成によって、オプティマイザは異なる実行計画を選択する場合があります。

例11-13では、EXPLAIN PLANを使用して、IDが103より小さい従業員のemployee_id、job_title、salaryおよびdepartment_nameを選択するSQL文を確認します。

例11-13 EXPLAIN PLANの使用方法

EXPLAIN PLAN FOR
SELECT e.employee_id, j.job_title, e.salary, d.department_name
FROM employees e, jobs j, departments d
WHERE  e.employee_id < 103
AND e.job_id = j.job_id
AND e.department_id = d.department_id;

例11-14の結果の出力表では、例にあるSQL文を実行するためにオプティマイザで選択された実行計画が示されています。

例11-14 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"

-------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |               |     3 |   189 |     8  (13)| 00:00:01 |
|   1 |  NESTED LOOPS                   |               |       |       |            |          |
|   2 |   NESTED LOOPS                  |               |     3 |   189 |     8  (13)| 00:00:01 |
|   3 |    MERGE JOIN                   |               |     3 |   141 |     5  (20)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID | JOBS          |    19 |   513 |     2   (0)| 00:00:01 |
|   5 |      INDEX FULL SCAN            | JOB_ID_PK     |    19 |       |     1   (0)| 00:00:01 |
|*  6 |     SORT JOIN                   |               |     3 |    60 |     3  (34)| 00:00:01 |
|   7 |      TABLE ACCESS BY INDEX ROWID| EMPLOYEES     |     3 |    60 |     2   (0)| 00:00:01 |
|*  8 |       INDEX RANGE SCAN          | EMP_EMP_ID_PK |     3 |       |     1   (0)| 00:00:01 |
|*  9 |    INDEX UNIQUE SCAN            | DEPT_ID_PK    |     1 |       |     0   (0)| 00:00:01 |
|  10 |   TABLE ACCESS BY INDEX ROWID   | DEPARTMENTS   |     1 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

6 - access("E"."JOB_ID"="J"."JOB_ID")
filter("E"."JOB_ID"="J"."JOB_ID")
8 - access("E"."EMPLOYEE_ID"<103)
9 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

11.4.2 実行計画のステップ

出力表内の各行は、実行計画内の1つのステップに対応しています。アスタリスクの付いたステップIDは、Predicate Informationセクションにリストされています。

関連項目:
第12章「EXPLAIN PLANの使用方法」

実行計画の各ステップは、行のセットを戻します。次のステップでは、これらの行を使用するか、最後のステップの場合は、SQL文を発行しているユーザーまたはアプリケーションに行を戻します。行セットは、各ステップで戻される行のセットです。

ステップIDの番号は、EXPLAIN PLAN文へのレスポンスに表示されるステップIDの順序を表しています。実行計画の各ステップでは、データベースから行を取り出すか、1つ以上の行ソースから行を入力として受け入れます。

- 例11-14の次のステップでは、データベース内のオブジェクトからデータが物理的に取り出されます。

- ステップ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を持つ行を取得します。

- 例11-14の次のステップでは、直前の行ソースから戻された行を処理します。

- ステップ2では、ステップ3およびステップ4から戻される行ソースを受け入れ、ステップ3からの各行ソースをステップ4の対応する行に結合し、その結果の行をステップ2に戻す、ネステッド・ループ操作を、jobs表およびemployees表のjob_idで実行します。

- ステップ1では、ステップ2およびステップ6から戻される行ソースを受け入れ、ステップ2からの各行をステップ6の対応する行に結合し、その結果の行をステップ1に戻すネステッド・ループ操作を実行します。

関連項目:

- アクセス・パスの詳細は、「オプティマイザ・アクセス・パスの概要」を参照してください。

- Oracle Databaseでの行ソースの結合方法の詳細は、「結合の概要」を参照してください。

11.5 オプティマイザ動作の制御

表11-3は、問合せオプティマイザの動作を制御するために使用できる初期化パラメータを示します。これらのパラメータを使用して、様々なオプティマイザの機能を有効にすることで、SQLの実行のパフォーマンスを向上できます。

表11-3 オプティマイザ動作を制御する初期化パラメータ

初期化パラメータ

説明

CURSOR_SHARING

SQL文のリテラル値をバインド変数に変換します。値を変換するとカーソル共有が改善され、SQL文の実行計画は影響を受けます。オプティマイザは、実際のリテラル値でなくバインド変数の有無に基づいて実行計画を生成します。

DB_FILE_MULTIBLOCK_READ_COUNT

全表スキャンまたは高速全索引スキャン時に単一I/Oで読み取られるブロックの個数を指定します。オプティマイザは、DB_FILE_MULTIBLOCK_READ_COUNTの値を使用して、全表スキャンと高速全索引スキャンのコストを計算します。値が大きいほど全表スキャンのコストは低くなり、オプティマイザは索引スキャンより全表スキャンを選択します。このパラメータが明示的に設定されていない場合(または0に設定されている場合)のデフォルト値は、効率的に実行可能な最大I/Oサイズです(プラットフォームごとに異なります)。

OPTIMIZER_INDEX_CACHING

ネステッド・ループとともに索引プローブのコスト計算を制御します。値0から100の範囲は、ネステッド・ループおよびINリスト・イテレータの索引キャッシュに関するオプティマイザの仮定を変更するバッファ・キャッシュ内の索引ブロックの割合を示します。この値が100となっている場合、索引ブロックの100%がバッファ・キャッシュに見つかる可能性が推測されます。オプティマイザはそれに応じて索引プローブまたはネステッド・ループのコストを調整します。実行計画は索引のキャッシュに応じて変更される可能性があるため、このパラメータを使用するときは注意してください。

OPTIMIZER_INDEX_COST_ADJ

索引プローブのコストを調整します。値の範囲は1から10000です。デフォルト値は100ですが、これは索引が標準のコスト計算モデルに基づいてアクセス・パスとして評価されることを意味します。値10は、索引アクセス・パスのコストが標準コストの1/10であることを意味します。

OPTIMIZER_MODE

インスタンスの起動時のオプティマイザのモードを設定します。可能な値は、ALL_ROWS、FIRST_ROWS_nおよびFIRST_ROWSです。これらのパラメータ値の詳細は、「OPTIMIZER_MODE初期化パラメータの設定」を参照してください。

PGA_AGGREGATE_TARGET

ソートおよびハッシュ結合に割り当てられるメモリーの量を自動的に制御します。ソートまたはハッシュ結合に大量のメモリーが割り当てられると、これらの操作のオプティマイザ・コストが減少します。

STAR_TRANSFORMATION_ENABLED

オプティマイザはスター・クエリーのスター型変換のコストを計算できます(trueの場合)。スター型変換により、様々なファクト表の列でビットマップ索引が結合されます。

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

11.5.1 問合せオプティマイザ機能の有効化

OPTIMIZER_FEATURES_ENABLE初期化パラメータは、リリースに応じて、一連のオプティマイザ関連機能を有効にします。10.2.0.1または11.2.0.1などのリリース番号に対応する有効な文字列値のいずれかを受け入れます。

このパラメータを使用して、データベースのアップグレード後もオプティマイザの以前の動作を保持できます。たとえば、Oracle Database 11gをリリース1(11.1.0.7)からリリース2(11.2.0.2)にアップグレードすると、OPTIMIZER_FEATURES_ENABLEパラメータのデフォルト値は、11.1.0.7から11.2.0.2に変更されます。このアップグレードによって、11.2.0.2に基づいた最適化機能が有効になります。

下位互換性のために、問合せ計画が新規リリースのオプティマイザ機能によって変更されないようにする場合もあります。そのような場合は、OPTIMIZER_FEATURES_ENABLEパラメータを以前のバージョンに設定します。

注意:
以前のリリースにOPTIMIZER_FEATURES_ENABLEパラメータを明示的に設定することはお薦めしません。実行計画の変更から生じる可能性があるSQLパフォーマンスの低下を回避するには、かわりに、SQL計画の管理を使用することを検討してください。第15章「SQL計画の管理の使用方法」を参照してください。

OPTIMIZER_FEATURES_ENABLEの設定手順:

1. 現在のオプティマイザ機能設定を問い合せます。
たとえば、次のSQL*Plusコマンドを実行します。

SQL> SHOW PARAMETER optimizer_features_enable

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_features_enable            string      11.2.0.2

2. インスタンスまたはセッション・レベルでオプティマイザ機能設定を設定します。
たとえば、次のSQL文を実行してオプティマイザ・バージョンを10.2.0.5に設定します。

SQL> ALTER SYSTEM SET optimizer_features_enable='10.2.0.5';

前の文により、10.2.0.5より後のリリースで追加されたすべての新規オプティマイザ機能が無効になります。リリースをアップグレードし、使用可能な新機能を有効にする場合は、OPTIMIZER_FEATURES_ENABLE初期化パラメータを明示的に設定する必要はありません。

関連項目:
OPTIMIZER_FEATURES_ENABLEパラメータを各リリースの値に設定すると有効になるオプティマイザ機能の詳細は、『Oracle Databaseリファレンス』を参照してください。

11.5.2 オプティマイザの目標の選択

オプティマイザの目標の設定および問合せオプティマイザの代表的な統計の収集によって、オプティマイザの選択を変えることができます。次のオプティマイザの目標を使用できます。

- 最高のスループット(デフォルト)
データベースは最小限のリソースを使用して文がアクセスするすべての行を処理します。

Oracle Reportsアプリケーションのように、バッチで実行されるアプリケーションの場合は、最高のスループットを目標に最適化してください。アプリケーションを起動するユーザーの関心は、アプリケーションを完了するために必要な時間のみに向けられているため、通常、バッチ・アプリケーションではスループットの重要度が高くなります。アプリケーションの実行中に、ユーザーは個々の文の結果を検証しないため、レスポンス時間はそれほど重要ではありません。

- 最短のレスポンス時間
データベースは最小限のリソースを使用してSQL文がアクセスする最初の行を処理します。

Oracle FormsアプリケーションやSQL*Plusの問合せのような対話形式のアプリケーションの場合は、最短のレスポンス時間を目標に最適化してください。通常、対話形式のアプリケーションでは、文が最初の行または最初の数行にアクセスするのをユーザーが待機しているため、レスポンス時間は重要です。

SQL文の最適化アプローチおよび目標を選択する際のオプティマイザの動作は、次の要素に左右されます。

- OPTIMIZER_MODE初期化パラメータの設定

- オプティマイザの目標変更に対するヒントの使用

- データ・ディクショナリ内のオプティマイザ統計

11.5.2.1 OPTIMIZER_MODE初期化パラメータの設定

OPTIMIZER_MODE初期化パラメータで、インスタンスに最適化アプローチを選択するためのデフォルト動作を設定します。表11-4に、設定できる値および説明を示します。

表11-4 OPTIMIZER_MODE初期化パラメータ値

値

説明

ALL_ROWS

オプティマイザは、セッション内のSQL文に対して、統計の存在の有無にかかわりなくコストベースのアプローチを使用し、最高のスループット(最小のリソースを使用して文全体を完成させること)を目標として最適化します。これはデフォルト値です。

FIRST_ROWS_n

オプティマイザは統計の有無とは関係なく、コストベースのアプローチを使用し、最短レスポンス時間で最初のn行を戻すように最適化します。ここでnは1、10、100または1000です。

FIRST_ROWS

オプティマイザは、コストと経験則を組み合せて、最初の数行の高速配信のための最適な計画を見つけます。

経験則を使用すると、オプティマイザは、経験則を適用しない計画のコストよりも非常に高いコストの計画を生成する場合があることに注意してください。FIRST_ROWSは、下位互換性とプラン・スタビリティのためのものです。かわりにFIRST_ROWS_nを使用してください。

初期化ファイル内のパラメータ値を変更するか、ALTER SESSION SET OPTIMIZER_MODE文によって、セッション内のすべてのSQL文の問合せオプティマイザの目標を変更できます。たとえば、次のようにします。

- 初期化パラメータ・ファイル内の次の文は、インスタンスのすべてのセッションの問合せオプティマイザの目標を最短のレスポンス時間に設定します。

OPTIMIZER_MODE = FIRST_ROWS_1

- 次のSQL文は、現行セッションの問合せオプティマイザの目標を最短のレスポンス時間に変更します。

ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1;

オプティマイザがコストベースのアプローチをSQL文に使用するときに、文がアクセスする一部の表に統計が存在しない場合、オプティマイザはそれらの表に割り当てられているデータ・ブロック数などの内部情報を使用して表に対する別の統計を見積ります。

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

11.5.2.2 オプティマイザの目標変更に対するヒントの使用

各SQL文に対するオプティマイザの目標を指定する場合は、表11-5のヒントを使用します。これらのヒントを各SQL文で使用して、SQL文のOPTIMIZER_MODE初期化パラメータを上書きできます。

表11-5 問合せオプティマイザの目標変更に対するヒント

ヒント

説明

FIRST_ROWS(n)

このヒントは、個々のSQL文を最適化して最初のn行を最短レスポンス時間で戻すようOracle Databaseに指示します(nは正の整数)。このヒントでは、SQL文に対して、統計の存在の有無にかかわりなくコストベースのアプローチが使用されます。

ALL_ROWS

このヒントでは、最高のスループットを目標としてSQL文を最適化するために、コストベースのアプローチが明示的に選択されます。

関連項目:
第19章「オプティマイザ・ヒントの使用方法」

11.5.2.3 データ・ディクショナリ内のオプティマイザ統計

問合せオプティマイザで使用される統計は、データ・ディクショナリに格納されます。DBMS_STATSパッケージを使用して、これらのスキーマ・オブジェクト内の物理的な記憶域の特性とデータ配分に関する正確な統計または見積り統計を収集できます。

問合せオプティマイザの有効性を維持するには、データを代表する統計が必要です。値の重複数のバリエーションが多いデータ(偏ったデータと呼ばれる)が存在する表列については、ヒストグラムを収集する必要があります。

その結果の統計によって、データの一意性と配分についての情報が問合せオプティマイザに提供されます。この情報を使用することにより、問合せオプティマイザは計画コストを精密に計算し、最小のコストを基に最良の実行計画を選択できるようになります。

デフォルトでは、SQL文のコンパイル時に、オプティマイザは、最適な実行計画を生成するために使用可能な統計が十分にあるかどうかを検討し、動的統計を使用するかどうかを自動的に判断します(「オプティマイザで動的統計を使用するタイミング」参照)。使用可能な統計が不十分な場合、オプティマイザは動的統計を使用して既存の統計を拡張します。

Oracle Database 11gリリース2 (11.2.0.4)以上では、OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータの値として11があり、オプティマイザは必要時に必ず動的統計を収集できるようになっています。たとえば、オプティマイザでは、表スキャン、索引アクセス、結合およびGROUP BY操作の動的統計を収集でき、その結果、オプティマイザの決定の品質が向上します。

関連項目:
第13章「オプティマイザ統計の管理」

12 EXPLAIN PLANの使用方法

この章では、実行計画について紹介し、SQL文EXPLAIN PLANを解説し、その出力の解釈方法を説明します。さらに、アプリケーションのパフォーマンス特性を制御するアウトラインを管理するプロシージャを示します。

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

- EXPLAIN PLANについて

- PLAN_TABLE出力表

- EXPLAIN PLANの実行

- PLAN_TABLE出力の表示

- EXPLAIN PLAN出力の読み方

- EXPLAIN PLANによるパラレル実行の表示

- EXPLAIN PLANによるビットマップ索引の表示

- EXPLAIN PLANによる結果キャッシュの表示

- EXPLAIN PLANによるパーティション・オブジェクトの表示

- PLAN_TABLE列

関連項目:

- EXPLAIN PLAN文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 第11章「問合せオプティマイザ」

12.1 EXPLAIN PLANについて

EXPLAIN PLAN文は、SELECT、UPDATE、INSERTおよびDELETE文に関して、オプティマイザによって選択された実行計画を表示します。文の実行計画とは、その文を実行するためにデータベースで行われる一連の処理です。

行ソース・ツリーは、実行計画の中核です。このツリーには、次の情報が表示されます。

- 文によって参照される表の順序

- 文で言及される各表へのアクセス方法

- 文の結合操作の影響を受ける表の結合方法

- フィルタ、ソート、集計などのデータ操作

PLAN TABLEには、行ソース・ツリーの他、次の情報が含まれています。

- 最適化。各操作のコストとカーディナリティについて。

- パーティション化。アクセスされたパーティションのセットなど。

- パラレル実行。結合入力の配分方法など。

EXPLAIN PLANの結果により、オプティマイザが特定の実行計画(たとえば、ネステッド・ループ結合)を選択するかどうかを判断できます。また、オプティマイザの決定(たとえば、オプティマイザがハッシュ結合でなくネステッド・ループ結合を選択した理由)および問合せのパフォーマンスについても理解できます。

12.1.1 実行計画の変化理由

問合せオプティマイザを使用すると、実行計画は基礎となるオプティマイザ入力が変化するたびに変化します。EXPLAIN PLANの出力は、EXPLAINされたSQL文をOracle Databaseがどのように実行するかを示します。実行環境とEXPLAIN PLAN環境が異なるため、SQL文を実際に実行する際の計画は、EXPLAIN PLANの実行計画とは異なる可能性があります。

注意:
実行計画の変更から生じる可能性があるSQLパフォーマンスの低下を回避するには、SQL計画の管理を使用することを検討してください。

実行計画は、次の理由により異なります。

- スキーマの相違

- コストの相違

関連項目:
第15章「SQL計画の管理の使用方法」

12.1.1.1 スキーマの相違

- 実行とEXPLAIN PLANのデータベースが異なる場合。

- 文をEXPLAINするユーザーが、文を実行するユーザーとは異なる場合。2人のユーザーが同じデータベース内の異なるオブジェクトを指していれば、異なる実行計画が発生します。

- 2つの操作間でスキーマが変更された場合(多くは索引の変更)。

12.1.1.2 コストの相違

スキーマが同じであっても、コストに違いがある場合、オプティマイザは異なる実行計画を選択する可能性があります。コストに影響を与えるいくつかの要因には次のものがあります。

- データ量と統計

- バインド変数の型と値

- グローバルまたはセッション・レベルで設定された初期化パラメータ

12.1.2 排除行数の最少化

EXPLAIN PLANを調べることにより、次の場合の排除行数を確認できます。

- 全表スキャン

- 選択性のないレンジ・スキャン

- 遅延した述語フィルタ

- 誤った結合順序

- 遅延したフィルタ処理

たとえば、次のEXPLAIN PLANでは、最後のステップは非常に選択性のないレンジ・スキャンです。このレンジ・スキャンは76563回実行され、11432983行にアクセスし、アクセスした行の99パーセントを排除して76563行を保持します。11432983行にアクセスした結果、必要な行が76563行のみであると認識された理由について考えます。

例12-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_ALL
11432983      INDEX RANGE SCAN (object id 186024)

12.1.3 実行計画以外の考慮事項

実行計画の操作のみでは、よく調整された文とうまく機能しない文を区別できません。たとえば、文による索引の使用がEXPLAIN PLAN出力で示されたとしても、その文が効率的に機能するとはかぎりません。効率的でない索引もあります。この場合、次のことを調べる必要があります。

- 使用される索引の列

- その索引の選択性(アクセスされる表の一部)

EXPLAIN PLANを使用してアクセス計画を判断し、後からテストによってそれが最適な計画であることを確認するのが最もよい方法です。計画を評価する際は、文の正確なリソース使用量を調べてください。

12.1.3.1 V$SQL_PLANビューの使用

EXPLAIN PLANコマンドを実行して計画を表示するのみではなく、V$SQL_PLANビューを使用してSQL文の実行計画を表示できます。

文の実行後に、V$SQL_PLANビューを問い合せて計画を表示できます。V$SQL_PLANには、共有SQL領域に格納されたすべての文の実行計画が含まれます。その定義は、PLAN_TABLEに類似しています。「PLAN_TABLE列」を参照してください。

V$SQL_PLANがEXPLAIN PLANよりも優れている点は、特定の文の実行に使用されたコンパイル環境を知らなくてもかまわないということです。EXPLAIN PLANの場合は、文の実行時に同じ計画を取得するために同一環境をセットアップする必要があります。

V$SQL_PLAN_STATISTICSビューは、出力行数や経過時間など、計画に含まれる操作ごとに実際の実行統計を提供します。出力行数を除き、すべての統計は累積されます。たとえば、結合操作の統計には、2つの入力の統計も含まれます。V$SQL_PLAN_STATISTICSの統計は、STATISTICS_LEVEL初期化パラメータをALLに設定してコンパイルされたカーソルに使用できます。

V$SQL_PLAN_STATISTICS_ALLビューを使用すると、行数と経過時間に関してオプティマイザにより提供される見積りを並べて表示できます。このビューでは、各カーソルのV$SQL_PLANおよびV$SQL_PLAN_STATISTICS情報が結合されます。

関連項目:

- V$SQL_PLAN_MONITORビューの詳細は、「リアルタイムSQL監視」を参照してください。

- V$SQL_PLANビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

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

12.1.4 EXPLAIN PLANの制限事項

Oracle Databaseでは、日付バインド変数の暗黙的な型変換を実行する文でのEXPLAIN PLANをサポートしません。一般にバインド変数では、EXPLAIN PLANが実際の実行計画を表していない場合があります。

TKPROFは、SQL文のテキストからバインド変数の型を判断することはできません。型はCHARACTERであると想定され、これ以外の場合はエラー・メッセージが表示されます。この制限事項は、SQL文に適切な型変換を入れることで対処できます。

関連項目:
第21章「アプリケーション・トレース・ツールの使用方法」

12.2 PLAN_TABLE出力表

PLAN_TABLEは、グローバル一時表に対するパブリック・シノニムとして自動的に作成されます。この一時表に、すべてのユーザーに対するEXPLAIN PLAN文の出力が保持されます。PLAN_TABLEは、EXPLAIN PLAN文が実行計画について記述している行を挿入するデフォルトのサンプル出力表です。表内の列の詳細は、「PLAN_TABLE列」を参照してください。

PLAN_TABLE表は各ユーザーに対し自動的に設定されますが、SQLスクリプトcatplan.sqlを使用して、グローバル一時表とPLAN_TABLEシノニムを手動で作成できます。このスクリプトの名前と位置は、使用するオペレーティング・システムによって異なります。UNIXおよびLinux上では、このスクリプトは$ORACLE_HOME/rdbms/adminディレクトリにあります。

たとえば、SQL*Plusセッションを開始し、SYSDBA権限で接続し、そして次のようにスクリプトを実行します。

@$ORACLE_HOME/rdbms/admin/catplan.sql

データベースのバージョンを更新した場合は、列が変更される可能性があるため、ローカルのPLAN_TABLE表を削除して再作成することをお薦めします。表を指定する場合は、スクリプトの実行が失敗したり、TKPROFが失敗する場合があります。

名前PLAN_TABLEを使用しない場合は、catplan.sqlスクリプトの実行後に新しいシノニムを作成します。たとえば、次のようにします。

CREATE OR REPLACE PUBLIC SYNONYM my_plan_table for plan_table$

12.3 EXPLAIN PLANの実行

SQL文をEXPLAINする場合は、文の直前でEXPLAIN PLAN FOR句を使用します。たとえば、次のようにします。

EXPLAIN PLAN FOR
SELECT last_name FROM employees;

計画をEXPLAINしたものがPLAN_TABLE表に挿入されます。PLAN_TABLEから実行計画を選択できるようになります。「PLAN_TABLE出力の表示」を参照してください。

12.3.1 EXPLAIN PLANでの文の指定

複数の文があるときは、文の識別子を指定し、その識別子で特定の実行計画を識別できます。SET STATEMENT IDを使用する前に、その文と同じ識別子を持つ既存の行を削除してください。

例12-2の場合は、st1が文の識別子として指定されています。

例12-2 STATEMENT ID句でのEXPLAIN PLANの使用方法

EXPLAIN PLAN
SET STATEMENT_ID = 'st1' FOR
SELECT last_name FROM employees;

12.3.2 EXPLAIN PLANでの別の表の指定

INTO句を指定して、別の表を指定できます。

例12-3 INTO句でのEXPLAIN PLANの使用方法

EXPLAIN PLAN
INTO my_plan_table
FOR
SELECT last_name FROM employees;

INTO句を使用する場合は、文の識別子を指定できます。

EXPLAIN PLAN
SET STATEMENT_ID = 'st1'
INTO my_plan_table
FOR
SELECT last_name FROM employees;

関連項目:
EXPLAIN PLAN構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

12.4 PLAN_TABLE出力の表示

計画をEXPLAINした後、Oracle Databaseから提供される次のSQLスクリプトまたはPL/SQLパッケージを使用して最新のPLAN TABLE出力を表示します。

- UTLXPLS.SQL
このスクリプトは、シリアル処理のためのPLAN TABLE出力を表示します。例11-14「EXPLAIN PLAN出力」は、UTLXPLS.SQLスクリプトを使用した場合のPLAN TABLE出力の例です。

- UTLXPLP.SQL
このスクリプトは、パラレル実行列を含むPLAN TABLE出力を表示します。

- DBMS_XPLAN.DISPLAYテーブル・ファンクション
このファンクションは、PLAN TABLE出力を表示するオプションを受け入れます。指定できるのは次のとおりです。

- PLAN_TABLEとは別の表を使用している場合のPLAN TABLE名

- EXPLAIN PLANに文の識別子を設定した場合の文の識別子

- 詳細レベルを決定するフォーマット・オプション: BASIC、SERIALおよびTYPICAL、ALL

DBMS_XPLANを使用してPLAN_TABLE出力を表示するいくつかの例を次に示します。

SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());

SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY('MY_PLAN_TABLE', 'st1','TYPICAL'));

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

12.4.1 PLAN_TABLE出力のカスタマイズ

文の識別子を指定した場合は、PLAN_TABLEを問い合せるための独自のスクリプトを書くことができます。たとえば、次のようにします。

- START WITH ID = 0およびSTATEMENT_IDを指定します。

- CONNECT BY句を使用して親から子へツリーを移動します。結合キーは、STATEMENT_ID = PRIOR STATEMENT_IDおよびPARENT_ID = PRIOR IDです。

- 疑似列LEVEL(CONNECT BYに関連付けられている)を使用して子をインデントします。

SELECT cardinality "Rows",
lpad(' ',level-1)||operation||' '||options||' '||object_name "Plan"
FROM PLAN_TABLE
CONNECT BY prior id = parent_id
AND prior statement_id = statement_id
START WITH id = 0
AND statement_id = 'st1'
ORDER BY id;

Rows Plan
------- ----------------------------------------
SELECT STATEMENT
TABLE ACCESS FULL EMPLOYEES

Rows列のNULLは、オプティマイザが表に統計を持っていないことを示します。表をANALYZEすると、次の内容が表示されます。

Rows Plan
------- ----------------------------------------
16957 SELECT STATEMENT
16957  TABLE ACCESS FULL EMPLOYEES

COSTも選択できます。これは、実行計画を比較する場合や、オプティマイザが複数の中からある実行計画を選択した理由を理解する場合に便利です。

注意:
これらの単純な例は、再帰的SQLの場合には有効ではありません。

12.5 EXPLAIN PLAN出力の読み方

この項では、EXPLAIN PLANの例を使用して実行計画を説明します。例12-4の文によって、実行計画が表示されます。

例12-4 EXPLAIN PLANを表示する文

SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, 'statement_id','BASIC'));

この文の出力例を、例12-5および例12-6に示します。

例12-5 文ID ex_plan1のEXPLAIN PLAN

EXPLAIN PLAN
SET statement_id = 'ex_plan1' FOR
SELECT phone_number FROM employees
WHERE phone_number LIKE '650%';

---------------------------------------
| Id  | Operation         | Name      |
---------------------------------------
|   0 | SELECT STATEMENT  |           |
|   1 |  TABLE ACCESS FULL| EMPLOYEES |
---------------------------------------

この計画は、SELECT文の実行を示します。表employeesは、全表スキャンでアクセスされます。

- 表employeesのすべての行がアクセスされ、各行がWHERE句の条件に基づいて評価されます。

- SELECT文により、WHERE句の条件に一致する行が戻されます。

例12-6 文ID ex_plan2のEXPLAIN PLAN

EXPLAIN PLAN
SET statement_id = 'ex_plan2' FOR
SELECT last_name FROM employees
WHERE last_name LIKE 'Pe%';

SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, 'ex_plan2','BASIC'));

----------------------------------------
| Id  | Operation        | Name        |
----------------------------------------
|   0 | SELECT STATEMENT |             |
|   1 |  INDEX RANGE SCAN| EMP_NAME_IX |
----------------------------------------

この計画は、SELECT文の実行を示します。

- データベースでは、EMP_NAME_IXのレンジ・スキャンによってWHERE句の条件を評価します。

- SELECT文により、WHERE句の条件を満たす行が戻されます。

12.6 EXPLAIN PLANによるパラレル実行の表示

パラレル問合せのチューニングは、パラレルでない問合せのチューニングの場合と同様に駆動表を選択することにより、開始されます。ただし、選択を管理するルールは異なります。パラレルでない問合せの場合は、通常、制限条件が適用された後に最も少ない行が生成される駆動表が最適です。少数の行は、一意でない索引を使用して大きな表に結合されます。たとえば、CUSTOMER、ACCOUNTおよびTRANSACTIONで構成された表階層の場合について考えます。

図12-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

- PARALLEL_TO_PARALLEL
通常は、各ステップのワークロードがほぼ同じであるかぎり、PARALLEL_TO_PARALLEL操作によって最適なパフォーマンスが得られます。

- PARALLEL_COMBINED_WITH_CHILD

- PARALLEL_COMBINED_WITH_PARENT
PARALLEL_COMBINED_WITH_PARENT操作は、ステップを親ステップと同時に実行する場合に発生します。

パラレル・ステップで多数の行が生成される場合、行の生成される速さにQCの処理が追いつかない場合があります。この状況を改善する方法はほとんどありません。

関連項目:
表12-1「PLAN_TABLE列」のOTHER_TAG列を参照してください。

12.6.1 EXPLAIN PLANによるパラレル問合せの表示

EXPLAIN PLANをパラレル問合せとともに使用すると、データベースは1つのパラレル計画をコンパイルおよび実行します。この計画は、QC計画にパラレル・サポートに固有の行ソースを割り当てることで、シリアル計画から導出されます。2つのスレーブ・セットPQモデルで要求される、表キューの行ソース(PX SendおよびPX Receive)、グラニュル・イテレータおよびバッファ・ソートは、パラレル計画に直接挿入されます。この計画は、パラレルで実行された場合はすべてのスレーブで、またシリアルで実行された場合はすべてのQCで、まったく同じ計画となります。

例12-7は、パラレル問合せのEXPLAIN PLANを説明するための単純な問合せです。

例12-7 パラレル問合せの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(問合せコーディネータ)を表します。

12.7 EXPLAIN PLANによるビットマップ索引の表示

ビットマップ索引を使用する索引行ソースは、索引のタイプを示す語BITMAPとともにEXPLAIN PLAN出力に表示されます。例12-8の問合せおよび計画の例を検討します。

例12-8 ビットマップ検索によるEXPLAIN PLAN

EXPLAIN PLAN FOR

SELECT * FROM t
WHERE c1 = 2
AND c2 <> 6
OR c3 BETWEEN 10 AND 20;

SELECT STATEMENT
TABLE ACCESS T BY INDEX ROWID
BITMAP CONVERSION TO ROWID
BITMAP OR
BITMAP MINUS
BITMAP MINUS
BITMAP INDEX C1_IND SINGLE VALUE
BITMAP INDEX C2_IND SINGLE VALUE
BITMAP INDEX C2_IND SINGLE VALUE
BITMAP MERGE
BITMAP INDEX C3_IND RANGE SCAN

この例では、述語c1=2によってビットマップが生成され、そこから減算が行われます。このビットマップから、c2 = 6に対応するビットマップ内のビットが減算されます。同様に、c2 IS NULLに対応するビットマップ内のビットが減算され、この計画の中に2つのMINUS行ソースがある理由がわかります。NULL減算は、NOT NULL制約が列に設定されていないかぎり、意味上の正確さを保つために必要です。TO ROWIDSオプションは、表アクセスに必要な行IDを生成します。

注意:
ビットマップ結合索引を使用した問合せは、ビットマップ結合索引のアクセス・パスを指示します。ビットマップ結合索引の操作は、ビットマップ索引と同じです。

12.8 EXPLAIN PLANによる結果キャッシュの表示

問合せにresult_cacheヒントが含まれる場合、ResultCache演算子が実行計画に挿入されます。

例として、次の問合せを検討します。

select /*+ result_cache */ deptno, avg(sal)
from emp
group by deptno;

この問合せのEXPLAIN PLANを表示するには、次のコマンドを使用します。

EXPLAIN PLAN FOR
select /*+ result_cache */ deptno, avg(sal)
from emp
group by deptno;

select PLAN_TABLE_OUTPUT from TABLE (DBMS_XPLAN.DISPLAY());

この問合せのEXPLAIN PLAN出力は、次のようになります。

---------------------------------------------------------------------------------------------
| Id  | Operation           | Name                        |Rows |Bytes |Cost(%CPU)|Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |                             | 11  | 77   |  4 (25)  | 00:00:01|
|   1 |  RESULT CACHE       |b06ppfz9pxzstbttpbqyqnfbmy   |     |      |          |         |
|   2 |   HASH GROUP BY     |                             | 11  | 77   |  4 (25)  | 00:00:01|
|   3 |    TABLE ACCESS FULL| EMP                         |107  | 749  |  3 (0)   | 00:00:01|
---------------------------------------------------------------------------------------------

このEXPLAIN PLANでは、ResultCache演算子はそのCacheId(b06ppfz9pxzstbttpbqyqnfbmy)によって識別されます。このCacheIdを使用して、V$RESULT_CACHE_OBJECTSビューに対して問合せを実行できます。

12.9 EXPLAIN PLANによるパーティション・オブジェクトの表示

EXPLAIN PLANを使用して、特定の問合せのパーティション化オブジェクトへのOracle Databaseのアクセス方法を表示します。

プルーニング後にアクセスされたパーティションは、PARTITION START列とPARTITION STOP列に表示されます。レンジ・パーティションの行ソース名は、PARTITION RANGEです。ハッシュ・パーティションの場合、行ソース名はPARTITION HASHです。

結合されるいずれかの表のPLAN TABLEのDISTRIBUTION列にPARTITION(KEY)が存在する場合、結合はパーシャル・パーティション・ワイズ結合を使用して実装されます。パーシャル・パーティション・ワイズ結合が可能なのは、結合される表のいずれかが結合列でパーティション化されており、かつ、表がパラレル化されている場合です。

EXPLAIN PLAN出力の結合行ソースの前にパーティション行ソースがある場合、結合はフル・パーティション・ワイズ結合を使用して実装されます。フル・パーティション・ワイズ結合が可能なのは、両方の結合表がそれぞれの結合列でパーティション化されている場合のみです。次に、いくつかの種類のパーティションに対する実行計画の例を示します。

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

hire_dateで範囲ごとにパーティション化されている次のemp_range表を参考に、プルーニングの表示方法を例示します。Oracle Databaseサンプル・スキーマの表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 |
--------------------------------------------------------------------------------------

前の例では、hire_dateの述語を使用してその他のパーティションをプルーニングするため、パーティション行ソースはパーティション4から5を反復します。

最後に、次の文を検討します。

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のみがアクセスされ、それがコンパイル時に認識されます。したがって、パーティション行ソースは必要ありません。

12.9.1.1 ハッシュ・パーティション化の計画

ハッシュ・パーティション・オブジェクトでは、パーティション行ソース名がPARTITION RANGEではなくPARTITION HASHであることを除き、同じ情報が表示されます。また、ハッシュ・パーティション化では、プルーニングが可能なのは等価述語かINリスト述語を使用している場合のみです。

12.9.2 コンポジット・パーティション・オブジェクトでのプルーニング情報の例

Oracle Databaseでのコンポジット・パーティション・オブジェクトのプルーニング情報の表示を、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 Databaseがコンポジット・オブジェクトの全パーティションの全サブパーティションにアクセスする場合の計画を示します。この目的を達成するために、2つのパーティション行ソースを使用します。1つはパーティションを反復するレンジ・パーティション行ソースで、もう1つはアクセスされる各パーティションのサブパーティションを反復するハッシュ・パーティション行ソースです。

次の例では、プルーニングを実行しないため、レンジ・パーティション行ソースはパーティション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 Databaseでは、各パーティション内の1つのサブパーティションにのみアクセスするため、この行ソースのオプションはSINGLEです。PARTITION_STARTおよびPARTITION_STOPはKEYに設定されます。これは、Oracle Databaseによりサブパーティションの番号が実行時に判別されることを意味します。

12.9.3 パーシャル・パーティション・ワイズ結合の例

次の例では、emp_range_didがパーティション化列department_idで結合され、パラレル化されます。dept2表がパーティション化されていないことにより、パーシャル・パーティション・ワイズ結合が使用可能になります。Oracle Databaseでは、結合前にdept2表を動的にパーティション化します。

例12-9 レンジ・パーティション化を使用したパーシャル・パーティション・ワイズ結合

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)、表キューを介して、パーシャル・パーティション・ワイズ結合を実行する同じスレーブに送られることを示します。

次の例では、emp_compがパーティション化列で結合され、パラレル化されます。dept2表がパーティション化されていないことにより、パーシャル・パーティション・ワイズ結合が使用可能になります。データエースは、結合前にdept2表を動的にパーティション化します。

例12-10 コンポジット・パーティション化を使用したパーシャル・パーティション・ワイズ結合

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表が再びパーティション化されることを意味します。

例12-9および例12-10では、問合せオプティマイザがこの問合せのコストに基づいて異なる計画を選択する可能性があるため、PQ_DISTRIBUTEヒントにより、パーシャル・パーティション・ワイズ結合が明示的に強制されています。

12.9.4 フル・パーティション・ワイズ結合の例

次の例では、emp_compとdept_hashがハッシュ・パーティション化列で結合されます。これにより、フル・パーティション・ワイズ結合が使用可能になります。PARTITION HASH行ソースが、PLAN TABLE出力の結合行ソースの上に表示されます。

PX PARTITION HASH行ソースはPLAN TABLE出力で結合行ソースの上に表示されますが、PX PARTITION RANGE行ソースはemp_compのスキャンにまたがって表示されます。各パラレル・スレーブは、emp_compのハッシュ・パーティション全体とdept_hashのパーティション全体の結合を実行します。

例12-11 フル・パーティション・ワイズ結合

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

12.9.5 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 STATEMENT
INLIST ITERATOR
TABLE ACCESS       BY ROWID          EMP
INDEX              RANGE SCAN        EMP_EMPNO

INLIST ITERATOR操作は、INリスト述語内の各値に対して、計画内の次の操作を反復します。パーティション表およびパーティション索引には3種類のINリスト列が使用可能ですが、これについては次の項で説明します。

12.9.5.1 INリスト列が索引列である場合

INリスト列empnoが索引列で、パーティション列ではない場合、計画は次のようになります(INリスト演算子は表操作の前に表示されますが、パーティションの操作よりは後に表示されます)。

OPERATION        OPTIONS              OBJECT_NAME PARTITION_START PARTITION_STOP
---------------- ------------         ----------- --------------- --------------
SELECT STATEMENT
PARTITION RANGE  ALL                               KEY(INLIST)     KEY(INLIST)
INLIST ITERATOR
TABLE ACCESS     BY LOCAL INDEX ROWID EMP          KEY(INLIST)     KEY(INLIST)
INDEX            RANGE SCAN           EMP_EMPNO    KEY(INLIST)     KEY(INLIST)

パーティションの開始キーおよび終了キーに対するKEY(INLIST)指定は、索引の開始キーおよび終了キーにINリスト述語が表示されることを指定します。

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

empnoが索引付けされている列で、それがパーティション列でもある場合、計画にはパーティション操作の前にINLIST ITERATOR操作が含まれています。

OPERATION        OPTIONS              OBJECT_NAME PARTITION_START PARTITION_STOP
---------------- ------------         ----------- --------------- --------------
SELECT STATEMENT
INLIST ITERATOR
PARTITION 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)

12.9.5.3 INリスト列がパーティション列である場合

empnoがパーティション列で、索引が存在しない場合は、INLIST ITERATOR操作は割り当てられません。

OPERATION         OPTIONS        OBJECT_NAME   PARTITION_START   PARTITION_STOP
----------------  ------------   -----------   ---------------   --------------
SELECT STATEMENT
PARTITION RANGE   INLIST                       KEY(INLIST)       KEY(INLIST)
TABLE ACCESS      FULL           EMP           KEY(INLIST)       KEY(INLIST)

emp_empnoがビットマップ索引である場合、計画は次のとおりです。

OPERATION          OPTIONS           OBJECT_NAME
----------------   ---------------   --------------
SELECT STATEMENT
INLIST ITERATOR
TABLE ACCESS       BY INDEX ROWID    EMP
BITMAP CONVERSION  TO ROWIDS
BITMAP INDEX       SINGLE VALUE      EMP_EMPNO

12.9.6 ドメイン索引およびEXPLAIN PLANの例

また、EXPLAIN PLANを使用して、ドメイン索引に対するユーザー定義のCPUおよびI/Oコストを導出できます。EXPLAIN PLANは、これらの統計をPLAN_TABLEのOTHER列に表示します。

たとえば、resume列にドメイン索引emp_resumeを持つユーザー定義演算子CONTAINSが表empに存在し、emp_resumeの索引タイプが演算子CONTAINSをサポートしている場合に、次の問合せをします。次の問合せの計画をEXPLAINします。

SELECT * FROM emp WHERE CONTAINS(resume, 'Oracle') = 1

次のような計画が表示されます。

OPERATION            OPTIONS      OBJECT_NAME     OTHER
-----------------    -----------  ------------    ----------------
SELECT STATEMENT
TABLE ACCESS         BY ROWID     EMP
DOMAIN INDEX                      EMP_RESUME      CPU: 300, I/O: 4

12.10 PLAN_TABLE列

EXPLAIN PLAN文に使用されるPLAN_TABLEには、表12-1に示す列があります。

表12-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

この列の値の詳細は、表12-3を参照してください。

OPTIONS

VARCHAR2(225)

OPERATION列に記述されている操作に関するバリエーションです。

この列の値の詳細は、表12-3を参照してください。

OBJECT_NODE

VARCHAR2(128)

オブジェクト(表名またはビュー名)を参照するために使用されたデータベース・リンクの名前です。パラレル実行を指定したローカル問合せの場合、この列は、処理からの出力をデータベースが使用する順序を説明します。

OBJECT_OWNER

VARCHAR2(30)

表または索引を含むスキーマを所有しているユーザーの名前です。

OBJECT_NAME

VARCHAR2(30)

表または索引の名前です。

OBJECT_ALIAS

VARCHAR2(65)

SQL文に含まれる表またはビューの一意の別名です。索引の場合は、基礎となる表のオブジェクトの別名です。

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): パラレル実行。ステップの入力は、同じパラレル処理の前のステップから受け取ります。子からのプロセス間通信はありません。

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)

プロデューサ問合せサーバーからコンシューマ問合せサーバーへ行を分配する方法です。

この列に使用可能な値の詳細は、表12-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)

フィルタにかけた後で行を生成する場合に使用する述語です。

PROJECTION

VARCHAR2(4000)

操作によって生成される式です。

TIME

NUMBER(20,2)

問合せの最適化によって見積られた操作の秒単位の経過時間です。ルールベース・アプローチを使用する文では、この列はNULLになります。

QBLOCK_NAME

VARCHAR2(30)

問合せブロックの名前です。システム生成またはQB_NAMEヒントによるユーザー定義のいずれかとなります。

表12-2で、DISTRIBUTION列に使用される値を説明します。

表12-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句がない場合に使用します。

表12-3に、EXPLAIN PLAN文によって生成されるOPERATIONとOPTIONSの各組合せおよびその実行計画におけるそれぞれの意味を示します。

表12-3 EXPLAIN PLANによって生成されるOPERATION値とOPTIONS値

操作

オプション

説明

AND-EQUAL

複数のROWIDのセットを受け取り、重複をなくして、そのセットの共通部分を戻す処理。この処理は単一列索引のアクセス・パスに対して使用されます。

BITMAP

CONVERSION

TO ROWIDSは、ビットマップ表現を、表にアクセスするために使用できる実際のROWIDに変換します。

FROM ROWIDSは、ROWIDをビットマップ表現に変換します。

COUNTは、実際の値を必要としない場合にROWIDの数を戻します。

BITMAP

INDEX

SINGLE VALUEは、索引内の単一のキー値のビットマップを参照します。

RANGE SCANは、ある範囲のキー値のビットマップを取り出します。

FULL SCANは、開始キーまたは終了キーがない場合にビットマップ索引の全体スキャンを実行します。

BITMAP

MERGE

レンジ・スキャンの結果の複数のビットマップを1つのビットマップにマージします。

BITMAP

MINUS

片方のビットマップのビットを、もう一方のビットマップから減算します。行ソースは否定述語に対して使用されます。減算が発生する可能性があるビットマップを作成する非否定述語がある場合にのみ使用できます。「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式によって制限するカウント処理。

CUBE SCAN

すべてのキューブ・アクセスで内部結合を使用します。

CUBE SCAN

PARTIAL OUTER

少なくとも1つのディメンションで外部結合を使用し、その他のディメンションで内部結合を使用します。

CUBE SCAN

OUTER

すべてのキューブ・アクセスで外部結合を使用します。

DOMAIN INDEX

ドメイン索引からの1つ以上のROWIDの取出し。オプション列には、ユーザー定義ドメイン・インデックス・コスト関数から与えられた情報が含まれています。

FILTER

行のセットを受け取り、そのいくつかを取り除き、残りを戻す処理。

FIRST ROW

問合せで選択される最初の行のみの取出し。

FOR UPDATE

FOR UPDATE句が含まれている問合せによって選択される行を取り出し、ロックする処理。

HASH

GROUP BY

GROUP BY句を持つ問合せで、行のセットを複数のグループにハッシュする処理。

HASH

GROUP BY PIVOT

GROUP BY句を持つ問合せで、行のセットを複数のグループにハッシュする処理。PIVOT操作は、HASH 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

ハッシュ(右側)外部結合。

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の取得。コストベース・オプティマイザでのみ使用可能です。

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を使用してマテリアライズド・ビューの行が指定される場合。

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 Databaseは、外側のセットの各行を内側のセットの各行と比較し、条件を満たす行を戻します。この結合方法は、小さいサブセットのデータを結合する場合(OLTP)に役立ちます。この結合条件は、第2の表にアクセスする場合に有効です。

NESTED LOOPS

OUTER

外部結合文を実行するネステッド・ループ操作。

PARTITION

PARTITION_START列およびPARTITION_STOP列によって指定された範囲の各パーティションに対して、計画内の次の操作を反復します。PARTITIONは、単一のパーティション・オブジェクト(表または索引)や同じ数でパーティション化されたオブジェクトのセット(パーティション表やそのローカル索引)に適用できるパーティションの区間を示します。パーティションの区間は、PARTITIONのPARTITION_STARTおよびPARTITION_STOPの値で指定されます。パーティションの開始および終了の有効な値は、表12-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操作と同じですが、パラレル計画に表示されます。

PX RECEIVE

PX SENDノード上で実行される送信側/プロデューサ(QCまたはスレーブ)からパーティション化されたデータを読み取る、コンシューマ/受信側スレーブ・ノードを示します。以前は、この情報はDISTRIBUTION列に表示されていました。表12-2を参照してください。

PX SEND

QC (RANDOM)、HASH、RANGE

スレーブの2つのパラレル・セットの間における配分方法を実装します。2つのスレーブ・セット間の境界と、送信側/プロデューサ側(QCまたはスレーブ)でのデータのパーティション化方法を示します。以前は、この情報はDISTRIBUTION列に表示されていました。表12-2を参照してください。

REMOTE

リモート・データベースからのデータの取出し。

SEQUENCE

順序値のアクセスを伴う処理。

SORT

AGGREGATE

選択した行のグループにグループ関数を適用した結果として取得される単一行の取出し。

SORT

UNIQUE

行のセットをソートし、重複をなくす処理。

SORT

GROUP BY

GROUP BY句を持つ問合せで、行のセットを複数のグループにソートする処理。

SORT

GROUP BY PIVOT

GROUP BY句を持つ問合せで、行のセットを複数のグループにソートする処理。PIVOT操作は、SORT 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

表がパーティション化されており、グローバル索引のみを使用して行が指定される場合。

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です。

TRANSPOSE

GROUP BYの結果を入れ換えて最終的にピボットされたデータを生成するPIVOT操作を評価する操作。

UNION

2つの行のセットを受け取り、重複をなくして、そのセットの連結結果を戻す処理。

UNPIVOT

列から行にデータを回転させる操作。

VIEW

ビューの問合せを実行し、結果の行を別の処理に戻す処理。

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

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

この章では、問合せオプティマイザにとって統計が重要である理由、およびDBMS_STATSパッケージを使用したオプティマイザ統計の収集方法と使用方法を説明します。

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

- オプティマイザ統計の概要

- 自動オプティマイザ統計収集の管理

- 手動での統計の収集

- システム統計

- 統計の管理

- 動的統計の制御

- 統計の表示

13.1 オプティマイザ統計の概要

オプティマイザ統計は、データベースおよびデータベース内のオブジェクトに関する詳細を表します。問合せオプティマイザは、これらの統計を使用して各SQL文に最適な実行計画を選択します。

オプティマイザ統計には次のものがあります。

- 表統計

- 行数

- ブロック数

- 行の平均長さ

- 列統計情報

- 列内の個別値(NDV)数

- 列内のNULL数

- データ配分(ヒストグラム)

- 拡張統計

- 索引統計

- リーフ・ブロック数

- レベル

- クラスタ化係数

- システム統計

- I/Oパフォーマンスと使用率

- CPUパフォーマンスと使用率

注意:
オプティマイザ統計と、V$ビューで参照可能なパフォーマンス統計を混同しないでください。

オプティマイザ統計は、データ・ディクショナリに格納されます。これらの統計は、データ・ディクショナリ・ビューを使用してアクセスできます。

データベース内のオブジェクトは絶えず変化するため、オブジェクトを正確に表すには統計を定期的に更新する必要があります。Oracle Databaseでは、オプティマイザ統計は自動的に管理されます。

DBMS_STATSパッケージを使用して、オプティマイザ統計を手動で管理できます。たとえば、統計のコピーを保存し、リストアできます。データベースから統計をエクスポートし、別のデータベースにインポートできます。たとえば、本番システムからテスト・システムに統計をエクスポートできます。また、統計が変更されないようにロックすることもできます。

関連項目:

- 「統計の表示」

- 「自動オプティマイザ統計収集の管理」または「手動での統計の収集」

- 「表統計またはスキーマ統計のロック」

13.2 自動オプティマイザ統計収集の管理

自動オプティマイザ統計収集は、有効にすることをお薦めします。有効な場合は、統計がないか失効している表のオプティマイザ統計を自動的に収集します。表に新規の統計が必要な場合は、表と、関連する索引の両方について統計が収集されます。

自動収集により、オプティマイザの管理に関連する多数の手動タスクが削減されます。また、統計の欠如または失効のために不適切な実行計画が生成されるリスクが大幅に減ります。

自動オプティマイザ統計収集は、DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROCプロシージャをコールします。この内部プロシージャの動作は、GATHER AUTOオプションを使用したDBMS_STATS.GATHER_DATABASE_STATSプロシージャに類似しています。主な違いは、GATHER_DATABASE_STATS_JOB_PROCでは、統計を必要とするデータベース・オブジェクトが優先され、メンテナンス・ウィンドウがクローズする前に、統計の更新を最も必要としているオブジェクトが最初に処理されます。

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

- 自動オプティマイザ統計収集の有効化と無効化

- 統計収集時の考慮事項

13.2.1 自動オプティマイザ統計収集の有効化と無効化

自動化メンテナンス・タスク・インフラストラクチャ(AutoTask)は、メンテナンス・ウィンドウと呼ばれるOracle Schedulerウィンドウで自動的に実行されるようにタスクをスケジュールします。デフォルトでは、1つのウィンドウが週の各曜日にスケジュールされます。自動オプティマイザ統計収集は、AutoTaskの一部として実行されます。デフォルトで有効になっており、事前定義されたすべてのメンテナンス・ウィンドウで実行されます。

なんらかの理由で自動オプティマイザ統計収集が無効な場合は、DBMS_AUTO_TASK_ADMINパッケージのENABLEプロシージャを使用してこの機能を有効にすることができます。

BEGIN
DBMS_AUTO_TASK_ADMIN.ENABLE(
client_name => 'auto optimizer stats collection'
,    operation   => NULL
,    window_name => NULL
);
END;
/

自動オプティマイザ統計収集を無効化する場合、次のようにDBMS_AUTO_TASK_ADMINパッケージのDISABLEプロシージャを使用してこの機能を無効化できます。

BEGIN
DBMS_AUTO_TASK_ADMIN.DISABLE(
client_name => 'auto optimizer stats collection'
,    operation   => NULL
,    window_name => NULL
);
END;
/

自動オプティマイザ統計収集は、「失効している統計の判別」で説明するように変更監視機能に依存します。この機能が無効な場合、自動オプティマイザ統計収集ジョブは、失効した統計を検出できません。この機能は、STATISTICS_LEVELパラメータがTYPICALまたはALLに設定されている場合に有効になります。デフォルト値はTYPICALです。

関連項目:

- 自動タスク・インフラストラクチャの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

13.2.2 統計収集時の考慮事項

この項では、次の内容を説明します。

- 手動統計を使用する場合

- 前のバージョンの統計のリストア

- 統計のロック

13.2.2.1 手動統計を使用する場合

適度な速さで変更されるほとんどのデータベース・オブジェクトには、自動オプティマイザ統計収集で十分です。ただし、場合によっては、適切に収集できないことがあります。収集はメンテナンス・ウィンドウで実行されるため、1日を通して大幅に変更される表の統計は古くなる可能性があります。通常、この種のオブジェクトには次の2つのタイプがあります。

- 日中に削除または切り捨てられて再作成される変化しやすい表

- オブジェクトの合計サイズの10%以上が追加される大規模バルク・ロードの対象となるオブジェクト

揮発性の高い表の場合は、次の2つのアプローチがあります。

- これらの表では、統計をNULLに設定できます。Oracle Databaseでは、統計のない表が検出されると、問合せ最適化の一部として必要な統計を動的に収集します。OPTIMIZER_DYNAMIC_SAMPLINGパラメータは、この動的統計機能を制御します。このパラメータの値を2(デフォルト)以上に設定します。統計をNULLに設定するには、統計を削除した後、ロックします。

BEGIN
DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS');
DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');
END;
/

動的統計レベルの設定方法については、「動的統計レベル」を参照してください。

- この種の表の統計は、表の典型的な状態を表す値に設定できます。表に典型的な行数が含まれているときに、その表の統計を収集し、統計をロックする必要があります。
通常、この方法は自動オプティマイザ統計収集よりも効率的です。これは、夜間のバッチ・ウィンドウで表に関して生成された統計が、日中のワークロードに関して最も適切な統計であるとはかぎらないためです。

バルク・ロードの対象となる表では、ロード処理の直後に、統計収集プロシージャを実行します。可能であれば、バルク・ロードの実行と同じスクリプトまたはジョブの一部としてプロシージャを実行します。

データベースは次の方法で外部表の統計を収集できます。

- GATHER_TABLE_STATSプロシージャ

- GATHER_SCHEMA_STATSプロシージャ

- GATHER_DATABASE_STATSプロシージャ

- 自動オプティマイザ統計収集処理

GATHER_TABLE_STATSを使用している場合は、外部表のサンプリングがサポートされていないため、ESTIMATE_PERCENTオプションをNULL、100、またはAUTO_SAMPLEに明示的に設定します。外部表に対するデータ操作は許可されないため、データベースで外部表の統計が失効としてマークされることはありません。たとえば基礎となるデータファイルが変更されたなどの理由で、外部表に新しい統計が必要な場合は、既存の統計を削除してから統計を再収集します。

STATISTICS_LEVELをBASICに設定して監視機能を無効にすると、自動オプティマイザ統計収集では失効している統計を検出できません。この場合、統計を手動で収集する必要があります。自動監視機能の詳細は、「失効している統計の判別」を参照してください。

システム統計は、手動で収集する必要のある別のタイプの統計です。データベースでは、これらの統計を自動的に収集しません。詳細は、「システム統計」を参照してください。

動的パフォーマンス表などの固定オブジェクトでは、GATHER_FIXED_OBJECTS_STATSプロシージャを使用して手動で統計を収集する必要があります。固定オブジェクトは、現在のデータベース・アクティビティを記録します。統計は、代表的なアクティビティがデータベースで行われているときに収集する必要があります。

13.2.2.2 前のバージョンの統計のリストア

ディクショナリ内で統計が変更されるたびに、後でリストアできるように前のバージョンの統計が自動的に保存されます。統計をリストアするには、DBMS_STATSパッケージのRESTOREプロシージャを使用します。詳細は、「前のバージョンの統計のリストア」を参照してください。

13.2.2.3 統計のロック

「手動統計を使用する場合」で説明したように、揮発性の高い表など、表またはスキーマに関してDBMS_STATS_JOBプロセスによる新規統計の収集を中止する必要がある場合があります。このような場合は、DBMS_STATSパッケージに表またはスキーマの統計をロックするためのプロシージャが用意されています。詳細は、「表統計またはスキーマ統計のロック」を参照してください。

13.3 手動での統計の収集

自動オプティマイザ統計収集を使用しない場合は、DBMS_STATSを実行して、システム・スキーマを含むすべてのスキーマで統計を手動で収集する必要があります。データベースの内容が定期的に変更される場合は、データベース・オブジェクトの特性を正確に表すために統計も定期的に収集する必要があります。

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

- DBMS_STATSプロシージャによる統計の収集

- 手動統計収集のプリファレンスの設定

- 統計を収集する時期

- DBMS_STATSファンクションによる統計の比較

13.3.1 DBMS_STATSプロシージャによる統計の収集

DBMS_STATSパッケージを使用して統計を収集できます。このPL/SQLパッケージは、統計の変更、表示、エクスポート、インポートおよび削除にも使用されます。

注意:
オプティマイザ統計の収集に、ANALYZE文でCOMPUTE句およびESTIMATE句を使用しないでください。これらの句は下位互換性のためにのみサポートされており、将来のリリースでは削除される可能性があります。DBMS_STATSパッケージを使用するほうが、より広範囲で正確な統計セットが効率的に収集されます。
オプティマイザ統計の収集に関係しない次のような用途には、引き続きANALYZE文を使用できます。

- VALIDATE句、LIST CHAINED ROWS句の使用

- 空きリスト・ブロックの情報を収集する場合

DBMS_STATSパッケージでは、表と索引の統計、および表の個別の列とパーティションの統計を収集できます。クラスタ統計は収集しません。ただし、クラスタ全体ではなく、個別の表の統計をDBMS_STATSを使用して収集できます。

表、列または索引の統計を生成する場合に、分析したオブジェクトの統計がデータ・ディクショナリに含まれる場合、Oracle Databaseは既存の統計を更新します。古い統計は保存されます。必要に応じて、後でリストアできます。「前のバージョンの統計のリストア」を参照してください。

システム・スキーマの統計を収集する場合は、DBMS_STATS.GATHER_DICTIONARY_STATSプロシージャを使用できます。このプロシージャでは、SYSやSYSTEMを含むすべてのシステム・スキーマと、CTXSYSやDRSYSなどの他のオプション・スキーマの統計が収集されます。

データベース・オブジェクトの統計が更新されると、そのオブジェクトにアクセスする現在解析済のSQL文は無効になります。文が次に実行されるときに、文が再解析され、オプティマイザは新しい統計に基づいて新しい実行計画を自動的に選択します。リモート・データベース上で新しい統計を持つオブジェクトにアクセスする分散型の文は、無効にされません。新しい統計は、次回にSQL文が解析されると有効になります。

表13-1に、DBMS_STATSパッケージにおけるデータベース・オブジェクトの統計収集のためのプロシージャを示します。

表13-1 DBMS_STATSパッケージの統計収集プロシージャ

プロシージャ

収集対象

GATHER_INDEX_STATS

索引統計

GATHER_TABLE_STATS

表、列および索引の統計

GATHER_SCHEMA_STATS

スキーマ内のすべてのオブジェクトの統計

GATHER_DICTIONARY_STATS

すべてのディクショナリ・オブジェクトの統計

GATHER_DATABASE_STATS

データベース内のすべてのオブジェクトの統計

関連項目:
すべてのDBMS_STATSプロシージャの構文と例については、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

前述のプロシージャを統計収集に使用する場合は、次のようにいくつか重要な考慮事項があります。

- サンプリングを使用した統計収集

- パラレル統計収集

- パーティション・オブジェクトの統計

- 列統計情報とヒストグラム

- 失効している統計の判別

- ユーザー定義統計

13.3.1.1 サンプリングを使用した統計収集

統計収集操作では、サンプリングを使用して統計を予測できます。サンプリングは、統計収集の重要なテクニックです。サンプリングを使用せずに統計を収集するには、全表スキャンと表全体のソートが必要です。サンプリングを使用すると、統計収集に必要なリソースが最小限に抑えられます。

サンプリングは、DBMS_STATSプロシージャのESTIMATE_PERCENT引数を使用して指定します。サンプリング率は任意の値に設定できますが、必要な統計を正確に収集し、最大のパフォーマンスを得るには、DBMS_STATS収集プロシージャのESTIMATE_PERCENTパラメータをDBMS_STATS.AUTO_SAMPLE_SIZEに設定することをお薦めします。AUTO_SAMPLE_SIZEを使用すると、オブジェクトの統計プロパティに基づいて、適切な統計のために必要な最善のサンプル・サイズがOracle Databaseにより決定されます。統計のタイプごとに要件が異なるため、実際に取得されるサンプルのサイズは、表、列または索引間で異なる場合があります。たとえば、自動サンプリングでOEスキーマ内のすべての表に関する表統計および列統計情報を収集するには、次のように使用できます。

EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS('OE',DBMS_STATS.AUTO_SAMPLE_SIZE);

ESTIMATE_PERCENTパラメータを手動で指定すると、指定されたパーセントで生成されたサンプルの大きさが十分でない場合に、DBMS_STATS収集プロシージャによりサンプリング率が自動的に増加されます。これによって、見積り値の変動が少なくなり、安定性が保証されます。

13.3.1.2 パラレル統計収集

統計の収集操作は、シリアルまたはパラレルのどちらでも実行できます。並列度は、DBMS_STATS収集プロシージャのDEGREE引数で指定できます。データベースでは、パラレル統計収集をサンプリングと併用できます。DEGREEパラメータをDBMS_STATS.AUTO_DEGREEに設定することをお薦めします。このように設定すると、Oracle Databaseは、オブジェクトのサイズとパラレル関連のinit.oraパラメータの設定に基づいて適切な並列度を選択できます。

クラスタ索引、ドメイン索引およびビットマップ結合索引など、特定のタイプの索引統計は、パラレルでは収集されないことに注意してください。

13.3.1.3 パーティション・オブジェクトの統計

パーティション表および索引に対して、DBMS_STATSは、各パーティションの個別の統計を収集できます。また、全表または全索引のグローバル統計も収集できます。コンポジット・パーティションについても同様に、DBMS_STATSはサブパーティション、パーティション、全表および全索引の個別の統計を収集できます。

13.3.1.3.1 統計収集の精度

最適化を行ったSQL文によっては、オプティマイザがパーティション統計、サブパーティション統計またはグローバル統計を使用するかどうかを選択できます。大多数のアプリケーションにとっては、グローバル統計とパーティション統計の両方とも重要です。

収集するパーティション統計のタイプは、DBMS_STATSプロシージャのGRANULARITY引数で指定します。GRANULARITYをAUTOに設定して、パーティションのタイプに応じてサブパーティション統計、パーティション統計またはグローバル統計を収集することをお薦めします。ALL設定では、常にすべての統計タイプが収集されます。

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

13.3.1.3.2 増分統計収集

通常、パーティション表では、新しいパーティションに新しいデータを追加します。新しいパーティションを追加し、データをロードした場合、新しいパーティションで統計を収集してグローバルな統計を最新の状態に維持する必要があります。

INCREMENTALを使用して、データベースで全表スキャンを実行してパーティション表のグローバル統計を維持するかどうかを決定できます。DBMS_STATS.SET_TABLE_PREFプロシージャを使用して、INCREMENTAL値を変更できます。

INCREMENTAL=false(デフォルト)の場合、データベースは常に全表スキャンを使用してグローバル統計を維持します。大規模な表では、これは大量にリソースを消費し、時間のかかる操作です。必須の全表スキャンのかわりとなるのが、増分統計の収集です。次の条件を満たす場合、データベースは変更されたパーティションのみをスキャンしてグローバル統計を増分的に更新します。

- パーティション表のINCREMENTAL値がtrueです。

- パーティション表のPUBLISH値がtrueです。

- 表の統計を収集するときに、ユーザーがESTIMATE_PERCENTにAUTO_SAMPLE_SIZEを、GRANULARITYにAUTOを指定しています。

表の統計を増分的に収集すると、次のような結果になります。

- SYSAUX表領域では、パーティション表のグローバル統計を維持するために追加の領域が使用されます。

- 表がコンポジット・パーティションを使用する場合は、データベースは変更されたサブパーティションの統計のみを収集します。データベースは、未変更のサブパーティションに対しては、サブパーティション・レベルの統計を収集しません。このようにして、データベースは未変更のパーティションをスキップして作業を減らします。

- 表が増分統計を使用しており、この表にローカルでパーティション化された索引がある場合は、データベースは、変更された(未変更でない)索引パーティションに対してグローバル・レベルで索引統計を収集します。データベースは、パーティション・レベルの統計からグローバル索引統計を生成することはしません。そのかわりに、データベースは全索引スキャンを実行してグローバル索引統計を収集します。

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

13.3.1.4 列統計情報とヒストグラム

表の統計を収集する場合、DBMS_STATSでは表内の列のデータ配分情報が収集されます。データ配分に関して最も基本的な情報は、列の最大値と最小値です。ただし、列のデータに偏りがある場合、このレベルの統計ではオプティマイザのニーズが十分に満たされない場合があります。データ配分に偏りがある場合は、指定した列のデータ配分を記述するヒストグラムも列統計の一部として作成できます。ヒストグラムの詳細は、「ヒストグラムの表示」を参照してください。

ヒストグラムは、DBMS_STATS収集プロシージャのMETHOD_OPT引数を使用して指定します。METHOD_OPTはFOR ALL COLUMNS SIZE AUTOに設定することをお薦めします。この設定では、ヒストグラムが必要な列および各ヒストグラムのバケット数(サイズ)が自動的に決定されます。また、これらの情報は手動でも指定できます。

注意:
DBMS_STATSを使用するとき表からすべての行を削除する必要がある場合、同じ表を削除して再度作成するかわりに、TRUNCATEを使用します。表を削除すると、自動ヒストグラム収集機能が使用するワークロード情報と、RESTORE_*_STATSプロシージャが使用する保存された統計履歴が消失します。このデータなしでは、これらの機能は適切に動作しません。

13.3.1.5 失効している統計の判別

データベース・オブジェクトは時間の経過とともに変化するため、統計を定期的に収集する必要があります。Oracle Databaseの表監視機能により、特定のデータベース・オブジェクトの新しいデータベース統計が必要かどうかを確認できます。この監視機能は、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%を超えた場合、これらの統計は失効したものとみなされ、再度収集されます。

13.3.1.6 ユーザー定義統計

ユーザー定義のオプティマイザ統計を作成して、ユーザー定義の索引およびファンクションをサポートできます。統計タイプを列またはドメイン索引に対応付ける場合、データベース・オブジェクトの統計が収集されるたびに、統計タイプの統計コレクション・メソッドがコールされます。

式の等価の列統計情報を収集できるように、ファンクション索引の作成後に表で新しい列統計を収集する必要があります。このタスクを実行するには、METHOD_OPT引数をFOR ALL HIDDEN COLUMNSに設定して統計収集プロシージャをコールします。

13.3.2 手動統計収集のプリファレンスの設定

DBMS_STATS.SET_*_PREFSプロシージャを使用して、統計を収集するDBMS_STATSプロシージャで使用するパラメータのデフォルト値を設定できます。各パラメータのプリファレンスを表、スキーマ、データベースおよびグローバル・レベルで設定して、きめの細かい制御を提供できます。

注意:
前のリリースでは、デフォルトのパラメータ値の設定に、DBMS_STATS.SET_PARMプロシージャを使用していました。これらの変更の有効範囲は、SET_PARMの実行後に発生したすべての操作でした。Oracle Database 11gでは、SET_PARMは非推奨です。

DBMS_STATS.SET_*_PREFSプロシージャを使用して、次のパラメータを変更できます。

- AUTOSTATS_TARGET(SET_GLOBAL_PREFSのみ)

- CASCADE

- DEGREE

- ESTIMATE_PERCENT

- GRANULARITY

- INCREMENTAL

- METHOD_OPT

- NO_INVALIDATE

- PUBLISH

- STALE_PERCENT

表13-2に、プリファレンスを設定するDBMS_STATSプロシージャのリストを示します。DBMS_STAT.GATHER_*_STATSプロシージャで設定したパラメータ値は、他の設定を上書きします。パラメータが設定されていない場合、データベースは表レベルのプリファレンスをチェックします。表のプリファレンスが存在しない場合は、GLOBALプリファレンスを使用します。

表13-2 統計収集のプリファレンスの設定

プロシージャ

目的

SET_TABLE_PREFS

指定した表においてDBMS_STATS.GATHER_*_STATSプロシージャで使用するデフォルトのパラメータ値を変更できます。

SET_SCHEMA_PREFS

指定したスキーマのすべての既存オブジェクトにおいてDBMS_STATS.GATHER_*_STATSプロシージャで使用するデフォルトのパラメータ値を変更できます。

このプロシージャは、指定されたスキーマの各表でSET_TABLE_PREFSをコールします。SET_TABLE_PREFSが使用されるため、実行後に作成された新しいオブジェクトは、SET_SCHEMA_PREFSコールの影響を受けません。新しいオブジェクトは、GLOBAL_PREF値をすべてのパラメータで使用します。

SET_DATABASE_PREFS

データベースのすべてのユーザー定義のスキーマにおいてDBMS_STATS.GATHER_*_STATSプロシージャで使用するデフォルトのパラメータ値を変更できます。ADD_SYSパラメータをTRUEに設定すると、SYSおよびSYSTEMなどのシステム所有のスキーマを含めることができます。

このプロシージャは、指定されたスキーマの各表でSET_TABLE_PREFSをコールします。SET_TABLE_PREFSが使用されるため、実行後に作成された新しいオブジェクトは、SET_SCHEMA_PREFSコールの影響を受けません。新しいオブジェクトは、GLOBAL_PREF値をすべてのパラメータで使用します。

SET_GLOBAL_PREFS

既存の表プリファレンスを持たないデータベース内のオブジェクトにおいてDBMS_STATS.GATHER_*_STATSプロシージャで使用するデフォルトのパラメータ値を変更できます。

表プリファレンスが設定されているか、DBMS_STATS.GATHER_*_STATSコマンドでパラメータを明示的に設定しないかぎり、すべてのパラメータのデフォルトはグローバル設定です。このプロシージャによる変更は、実行後に作成された新しいオブジェクトに影響を与えます。新しいオブジェクトは、GLOBAL_PREF値をすべてのパラメータで使用します。

GLOBAL_PREFSを使用して、AUTOSTAT_TARGETパラメータのデフォルト値を設定できます。この追加のパラメータは、夜間のメンテナンス・ウィンドウで実行される自動統計収集ジョブによって管理されるオブジェクトを制御します。このパラメータの値は、ALL、ORACLEおよびAUTO(デフォルト)のいずれかです。

関連項目:
すべてのDBMS_STATSプロシージャの構文と例については、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

13.3.3 統計を収集する時期

統計を手動で収集する場合は、その収集方法を決定するのみでなく、新規統計の収集時期と頻度も決定する必要があります。

表の増分変更が行われるアプリケーションの場合は、新規の統計を週または月に1回収集するのみでかまいません。このような環境で最も簡単に統計を収集する方法は、スクリプトまたはジョブ・スケジューリング・ツールを使用して、GATHER_SCHEMA_STATSおよびGATHER_DATABASE_STATSプロシージャを定期的に実行することです。収集の頻度によって、統計収集プロセスで起こるオーバーヘッドの処理に対し、オプティマイザの正確な統計を出すタスクのバランスをとります。

バルク・ロードを使用する場合など、バッチ操作で大幅に変更される表の場合は、その表の統計をバッチ操作の一部として収集します。ロード操作が完了した直後に、DBMS_STATSプロシージャをコールします。

ときには、単一パーティションのみが変更される場合があります。この場合は、表全体ではなく、変更されたパーティションでのみ統計を収集できます。ただし、パーティション表のグローバル統計の収集も必要な場合があります。

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

13.3.4 DBMS_STATSファンクションによる統計の比較

DBMS_STATSを使用すると、2つの異なるソースの表の統計を比較できます。表13-3に、統計を比較するためのDBMS_STATSパッケージのファンクションを示します。

表13-3 統計を比較するDBMS_STATSパッケージのファンクション

プロシージャ

比較対象

DIFF_TABLE_STATS_IN_PENDING

保留中の統計とタイムスタンプの時点の統計またはディクショナリの統計

DIFF_TABLE_STATS_IN_STATTAB

2つの異なるソースの表の統計

DIFF_TABLE_STATS_IN_HISTORY

過去の2つのタイムスタンプからの表の統計、およびそれらのタイムスタンプの時点の統計

表13-3のファンクションでは、索引、列およびパーティションなどの依存オブジェクトの統計も比較します。これらの統計間の差分が特定のしきい値を超える場合、両方のソースのオブジェクトの統計が表示されます。ファンクションの引数としてしきい値を指定できます。デフォルトは10%です。Oracle Databaseでは、最初のソースに相当する統計を基本として使用し、異なる割合を計算します。

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

13.4 システム統計

システム統計は、問合せオプティマイザに対してシステムのハードウェア特性(I/OとCPUのパフォーマンスおよび使用率など)を記述します。実行計画の選択時に、オプティマイザで各問合せに必要なI/OおよびCPUリソースが見積られます。システム統計を使用すると、問合せオプティマイザはI/OおよびCPUコストをより正確に見積ることができ、問合せオプティマイザはより適切な実行計画を選択できます。

Oracle Databaseでは、システム統計を収集する際に、指定された期間のシステム・アクティビティを分析するか(作業負荷統計)、作業負荷をシミュレートします(非作業負荷統計)。統計は、DBMS_STATS.GATHER_SYSTEM_STATSプロシージャを使用して収集されます。システム統計を収集することをお薦めします。

注意:
ディクショナリ・システム統計を更新するには、DBA権限またはGATHER_SYSTEM_STATISTICSロールが必要です。

表13-4に、DBMS_STATSパッケージにより収集されたオプティマイザのシステム統計と、特定のシステム統計の収集または手動設定のオプションを示します。

表13-4 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に設定するか、または統計を手動で設定します。

バイト/ミリ秒

cpuspeed

作業負荷をかけた場合のCPU速度を表します。CPU速度は、1秒当たりのCPU平均サイクル数です。

なし

gathering_mode = NOWORKLOAD、INTERVAL、START|STOPに設定するか、統計を手動で設定します。

100万/秒

maxthr

最大I/Oスループットは、I/Oサブシステムが発揮できる最大スループットです。

なし

gathering_mode = NOWORKLOAD、INTERVAL、START|STOPに設定するか、統計を手動で設定します。

バイト/秒

slavethr

スレーブI/Oスループットは、パラレル・スレーブの平均I/Oスループットです。

なし

gathering_mode = INTERVALまたはSTART|STOPに設定するか、統計を手動で設定します。

バイト/秒

sreadtim

単一ブロック読取り時間は、単一ブロックをランダムに読み取る平均時間です。

なし

gathering_mode = INTERVALまたはSTART|STOPに設定するか、統計を手動で設定します。

ミリ秒

mreadtim

マルチブロック読取りは、マルチブロックを順に読み取る平均時間です。

なし

gathering_mode = INTERVALまたはSTART|STOPに設定するか、統計を手動で設定します。

ミリ秒

mbrc

マルチブロック・カウントは、平均マルチブロック順次読取りカウントです。

なし

gathering_mode = INTERVALまたはSTART|STOPに設定するか、統計を手動で設定します。

ブロック

表、索引、列の統計とは異なり、システム統計の更新時には、解析済のSQL文は無効にされません。新しいSQL文はすべて、新しい統計を使用して解析されます。

システム統計の収集方法には2つのオプションがあります。

- 作業負荷統計

- 非作業負荷統計

これらのオプションは、物理データベースおよび作業負荷の収集プロセスを容易にします。作業負荷システム統計が収集されると、非作業負荷システム統計は無視されます。非作業負荷システム統計は、データベースの初回の起動時にデフォルト値に初期化されます。

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

13.4.1 作業負荷統計

作業負荷統計には次のものがあります。

- シングルおよびマルチブロックの読取り時間

- mbrc

- CPU速度(cpuspeed)

- 最大システム・スループット

- 平均スレーブ・スループット

シングルおよびマルチブロックの読取り時間、mbrc、CPU速度(cpuspeed)、最大システム・スループットおよび平均スレーブ・スループット。データベースでは、作業負荷の開始から終了までの間の、物理的な順次およびランダム読取りの数を比較して、sreadtim、mreadtimおよびmbrcを計算します。これらの値は、バッファ・キャッシュが同期読取りリクエストを完了したときに変更されるカウンタを通して実装されます。

このカウンタはバッファ・キャッシュ内にあるため、これらにはI/O遅延のほかに、ラッチの競合およびタスク・スイッチングに関連する待機も含まれます。このように、作業負荷統計は、作業負荷ウィンドウでシステムが実行するアクティビティに応じて異なります。システムがI/Oバウンドの場合(ラッチ競合およびI/Oスループット)、この状況は統計に反映されるため、データベースで統計が使用された後にI/O集中の低減化計画が推奨されます。さらに、作業負荷統計収集は、追加のオーバーヘッドを生成しません。

13.4.1.1 作業負荷統計の収集

作業負荷統計を収集するには、次のいずれかのタスクを実行します。

- 作業負荷ウィンドウの開始時に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()を実行します。作業負荷統計が削除され、デフォルトの非作業負荷統計にリセットされます。

13.4.1.2 マルチブロック読取りカウント

作業負荷統計を収集する場合、作業負荷統計の一部として収集されたmbrcの値を使用して全表スキャンのコストを見積ることができます。ただし、作業負荷統計の収集プロセスでシリアル作業負荷の間に表スキャンが実行されない場合(OLTPシステムでしばしば発生します)、mbrcおよびmreadtimの値が収集されない場合があります。また、DSSシステムでは全表スキャンが頻繁に実行されますが、パラレル実行によってバッファ・キャッシュがバイパスされる可能性があります。このような場合でも、バッファ・キャッシュを使用して索引参照が実行されるため、sreadtimの値は収集されます。

mbrcまたはmreadtimの値を収集できないか、または収集してもそれらの検証ができない場合で、sreadtimおよびcpuspeedの値が収集されている場合は、sreadtimおよびcpuspeedの値のみがコスト計算に使用されます。この場合、オプティマイザは初期化パラメータDB_FILE_MULTIBLOCK_READ_COUNTの値を使用して全表スキャンを見積ることができます。ただし、DB_FILE_MULTIBLOCK_READ_COUNTを設定しないか、0(ゼロ)に設定する場合、オプティマイザは値8を使用してコストを見積ります。

13.4.2 非作業負荷統計

非作業負荷統計は、I/O転送速度、I/Oシーク時間およびCPU速度(cpuspeednw)で構成されています。作業負荷統計と非作業負荷統計の主な違いは、収集方法にあります。

非作業負荷統計は、すべてのデータファイルに対してランダム読取りを発行してデータを収集しますが、作業負荷統計は、データベース・アクティビティの発生時に更新されるカウンタを使用します。ioseektimは、ディスク・ヘッドがデータを読み取る位置に移動する時間を表します。この値は通常、ディスクの回転速度およびディスクまたはRAIDの仕様に応じて5から15ミリ秒の間で変化します。I/O転送速度は、オペレーティング・システムの1つのプロセスでI/Oサブシステムからのデータの読取りが可能な速度を表します。この値は、毎秒数MBから数百MBまで大きく変化します。Oracle Databaseでは、I/O転送速度に比較的低い値のデフォルト設定を使用しています。

デフォルトでは、Oracle Databaseで非作業負荷統計とCPUコスト・モデルが使用されます。非作業負荷統計の値は、最初のインスタンス起動時にデフォルトに初期化されます。

ioseektim = 10ms
iotrfspeed = 4096 bytes/ms
cpuspeednw = gathered value, varies based on system

作業負荷統計を収集する場合、非作業負荷統計は無視され、作業負荷統計が使用されます。

13.4.2.1 非作業負荷統計の収集

非作業負荷統計を収集するには、引数なしでDBMS_STATS.GATHER_SYSTEM_STATS()を実行します。非作業負荷統計の収集プロセスの際に、I/Oシステムにオーバーヘッドが発生します。この収集プロセスは、I/Oのパフォーマンスおよびデータベースのサイズによって数秒から数分かかることがあります。

この情報は分析され、整合性が検証されます。場合により、非作業負荷統計の値はデフォルト値のままになることがあります。このような場合は、統計収集プロセスを繰り返すか、DBMS_STATS.SET_SYSTEM_STATSプロシージャを使用してI/Oシステムの仕様に応じた値に手動で設定します。

13.5 統計の管理

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

- 統計の保留

- 拡張統計の管理

- 前のバージョンの統計のリストア

- 統計のエクスポートとインポート

- 統計のリストアとインポートまたはエクスポートの相違点

- 表統計またはスキーマ統計のロック

- 統計の設定

- 統計の欠落の処理

13.5.1 統計の保留

Oracle Database 11gリリース2(11.2)以上では、統計を収集する際に次のオプションがあります。

- 収集操作の終了時に統計を自動的に公開します(デフォルト動作)。

- 新しい統計を保留中として保存します。

新規統計を保留中として保存すると、新規統計を検証して、それらが適切である場合にのみ公開できます。

統計を収集したらすぐに自動的に公開するかどうかを確認するには、次のようにDBMS_STATSパッケージを使用します。

SELECT DBMS_STATS.GET_PREFS('PUBLISH') PUBLISH FROM DUAL;

この問合せは、TRUE またはFALSEを戻します。TRUEは統計が収集時に公開されることを示し、FALSEは統計が保留中として保存されることを示します。

注意:
公開された統計は、USER_TAB_STATISTICSやUSER_IND_STATISTICSなどのデータ・ディクショナリ・ビューに格納されます。保留中の統計は、USER_TAB_PENDING_STATSやUSER_IND_PENDING_STATSなどのビューに格納されます。

PUBLISH設定は、スキーマ・レベルまたは表レベルで変更できます。たとえば、SHスキーマのcustomers表のPUBLISH設定を変更するには、次の文を実行します。

EXEC DBMS_STATS.SET_TABLE_PREFS('SH', 'CUSTOMERS', 'PUBLISH', 'false');

これで、customers表の統計が収集される場合に、その統計は収集ジョブの完了時に自動的に公開されなくなります。かわりに、新規に収集された統計はUSER_TAB_PENDING_STATS表に格納されます。

デフォルトでは、オプティマイザはデータ・ディクショナリ・ビューに格納されている公開済の統計を使用します。新規に収集された保留中の統計をオプティマイザで使用する場合は、OPTIMIZER_USE_PENDING_STATISTICS初期化パラメータをTRUEに設定し(デフォルト値はFALSE)、表またはスキーマに対してワークロードを実行します。

ALTER SESSION SET OPTIMIZER_USE_PENDING_STATISTICS = TRUE;

オプティマイザでは、SQL文をコンパイルする際に、公開された統計ではなく、保留中の統計を使用します。保留中の統計が有効である場合、次の文を実行して公開できます。

EXEC DBMS_STATS.PUBLISH_PENDING_STATS(null, null);

特定のデータベース・オブジェクトに関する保留中の統計を公開することもできます。たとえば、次の文を使用します。

EXEC DBMS_STATS.PUBLISH_PENDING_STATS('SH','CUSTOMERS');

保留中の統計を公開しない場合は、次の文を実行してそれらの統計を削除します。

EXEC DBMS_STATS.DELETE_PENDING_STATS('SH','CUSTOMERS');

保留中の統計は、DBMS_STATS.EXPORT_PENDING_STATSファンクションを使用してエクスポートできます。保留中の統計をテスト・システムにエクスポートすると、新規統計に対してすべてのワークロードを実行できます。

13.5.2 拡張統計の管理

DBMS_STATSでは拡張統計の収集が可能で、複数の述語が1つの表の異なる列に存在する場合や、述語で式を使用する場合に、拡張統計によりカーディナリティ予測を改善できます。拡張は、列グループまたは式のいずれかになります。

Oracle Databaseでは次の種類の拡張統計がサポートされます。

- 列グループの統計
この種類の拡張統計では、同じ表の複数の列が1つのSQL文に同時に存在する場合のカーディナリティ予測を改善できます。「列グループの統計の管理」を参照してください。

- 式の統計
この種類の拡張統計では、組込みファンクションやユーザー定義ファンクションなどの式を述語で使用する際にオプティマイザの見積りが改善されます。「式の統計の管理」を参照してください。

注意:
仮想列の拡張統計を作成することはできません。仮想列の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。

13.5.2.1 列グループの統計の管理

問合せのWHERE句に、1つの表からの複数の列を指定した場合(複数の単一列条件)、列グループの総合的な選択性が列の関係に大きく左右される場合があります。

例として、shスキーマのcustomers表を検討します。cust_state_province列とcountry_id列は、各顧客のcust_state_provinceがcountry_idを決定するという関係にあります。次のように、cust_state_provinceがCaliforniaであるという条件でcustomers表を問い合せるとします。

SELECT COUNT(*)
FROM   sh.customers
WHERE  cust_state_province = 'CA';

この問合せは、次の値を戻します。

COUNT(*)
----------
3341

country_id列が52790(アメリカ合衆国)の場合、次のようにcountry_idに関する別の条件を追加しても結果は変わりません。次の問合せを実行します。

SELECT COUNT(*)
FROM   customers
WHERE  cust_state_province = 'CA'
AND    country_id=52790;

この問合せは、前の問合せと同じ値を戻します。

COUNT(*)
----------
3341

次の問合せのように、country_idが52775(ブラジル)などの異なる値を持つ場合を考えます。

SELECT COUNT(*)
FROM   customers
WHERE  cust_state_province = 'CA'
AND    country_id=52775;

この場合、次の値を戻します。

COUNT(*)
----------
0

個々の列の統計を使用すると、オプティマイザでは、cust_state_province列とcountry_id列の関係を認識できません。これらの列をグループ(列グループ)として統計を収集することで、オプティマイザでは、個々の列統計に基づいて値を生成することなく、そのグループに関するより正確な選択値を得ることができます。

DBMS_STATSパッケージを使用して手動で列グループを作成できます。このパッケージを使用すると、列グループの作成、列グループ名の取得、または表からの列グループの削除が可能になります。

13.5.2.1.1 列グループの作成

CREATE_EXTENDED_STATISTICSファンクションを使用して、列グループを作成します。CREATE_EXTENDED_STATISTICSファンクションでは、新規に作成された列グループのシステム生成名が戻されます。表13-5に、このファンクションの入力パラメータを示します。

表13-5 create_extended_statisticsファンクションのパラメータ

パラメータ

説明

ownname

スキーマ所有者。NULLは現在のスキーマを示します。

tabname

列グループが追加される表の名前。

extension

列グループの列。

たとえば、cust_state_provinceおよびcountry_id列で構成される列グループをSHスキーマのcustomers表に追加するには、次のPL/SQLブロックを実行します。

DECLARE
cg_name VARCHAR2(30);
BEGIN
cg_name := DBMS_STATS.CREATE_EXTENDED_STATS(null,'customers',
'(cust_state_province,country_id)');
END;
/

13.5.2.1.2 列グループの取得

show_extended_stats_nameファンクションを使用して、任意の列セットに対応する列グループの名前を取得します。表13-6に、このファンクションの入力パラメータを示します。

表13-6 show_extended_stats_nameファンクションのパラメータ

パラメータ

説明

ownname

スキーマ所有者。NULLは現在のスキーマを示します。

tabname

列グループが属している表の名前。

extension

列グループの名前。

たとえば、次の問合せを使用すると、customers表の列セットの列グループ名を取得できます。

SELECT SYS.DBMS_STATS.SHOW_EXTENDED_STATS_NAME('sh','customers',
'(cust_state_province,country_id)') col_group_name
FROM   DUAL;

出力は、次のようなものです。

COL_GROUP_NAME
----------------
SYS_STU#S#WF25Z#QAHIHE#MOFFMM

13.5.2.1.3 列グループの削除

DROP_EXTENDED_STATSファンクションを使用して、表から列グループを削除します。表13-7に、このファンクションの入力パラメータを示します。

表13-7 drop_extended_statsファンクションのパラメータ

パラメータ

説明

ownname

スキーマ所有者。NULLは現在のスキーマを示します。

tabname

列グループが属している表の名前。

extension

削除する列グループの名前。

たとえば、次の文を使用すると、customers表から列グループを削除できます。

EXEC DBMS_STATS.DROP_EXTENDED_STATS('sh','customers',
'(cust_state_province,country_id)');

13.5.2.1.4 列グループの監視

ディクショナリ表USER_STAT_EXTENSIONSを使用して、複数列の統計に関する情報を取得します。

SELECT EXTENSION_NAME, EXTENSION
FROM   USER_STAT_EXTENSIONS
WHERE  TABLE_NAME='CUSTOMERS';

EXTENSION_NAME                     EXTENSION
-------------------------------------------------------------------------
SYS_STU#S#WF25Z#QAHIHE#MOFFMM_     ("CUST_STATE_PROVINCE","COUNTRY_ID")

次の問合せを使用すると、個別値の数と、列グループにヒストグラムが作成されているかどうかを確認できます。

SELECT e.EXTENSION col_group, t.NUM_DISTINCT, t.HISTOGRAM
FROM   USER_STAT_EXTENSIONS e, USER_TAB_COL_STATISTICS t
WHERE  e.EXTENSION_NAME=t.COLUMN_NAME
AND    e.TABLE_NAME=t.TABLE_NAME
AND    t.TABLE_NAME='CUSTOMERS';

COL_GROUP                             NUM_DISTINCT        HISTOGRAM
-------------------------------------------------------------------------------
("COUNTRY_ID","CUST_STATE_PROVINCE")  145                 FREQUENCY

13.5.2.1.5 列グループの統計の収集

DBMS_STATSパッケージのMETHOD_OPT引数を使用して、列グループの統計を収集します。この引数の値をFOR ALL COLUMNS SIZE AUTOに設定すると、オプティマイザは、既存のすべての列グループに関する統計を収集します。新規の列グループに関する統計を収集するには、FOR COLUMNSを使用してグループを指定します。列グループは、統計収集の一部として自動的に作成されます。

たとえば、次の文では、customers表のcust_state_provinceおよびcountry_id列に対応する新規列グループが作成され、表全体と新規列グループに関する統計(ヒストグラムを含む)が収集されます。

EXEC DBMS_STATS.GATHER_TABLE_STATS('SH','CUSTOMERS',METHOD_OPT =>
'FOR ALL COLUMNS SIZE SKEWONLY
FOR COLUMNS (CUST_STATE_PROVINCE,COUNTRY_ID) SIZE SKEWONLY');

注意:
オプティマイザは、等価述語でのみ複数列の統計を使用します。

13.5.2.2 式の統計の管理

問合せのWHERE句で列に関数が適用される場合(function(col1)=constant)、オプティマイザでは、その関数が列の選択性に与える影響を認識できません。式function(col1)に関する式の統計を収集することで、より正確な選択値を取得できます。

このような関数の例は、次のとおりです。

SELECT COUNT(*)
FROM   CUSTOMERS
WHERE  LOWER(CUST_STATE_PROVINCE)='ca';

13.5.2.2.1 式の統計の作成

GATHER_TABLE_STATSプロシージャの一部として、次のように式の統計を作成できます。

EXEC DBMS_STATS.GATHER_TABLE_STATS('sh','customers', method_opt =>
'FOR ALL COLUMNS SIZE SKEWONLY
FOR COLUMNS (LOWER(cust_state_province)) SIZE SKEWONLY');

これを行うには、次のようにCREATE_EXTENDED_STATISTICSファンクションも使用できます。

SELECT
DBMS_STATS.CREATE_EXTENDED_STATS(null,'customers','(LOWER(cust_state_province))')
FROM DUAL;

13.5.2.2.2 式の統計の監視

ディクショナリ表user_stat_extensionsを使用して、式の統計に関する情報を取得します。

SELECT EXTENSION_NAME, EXTENSION
FROM   USER_STAT_EXTENSIONS
WHERE  TABLE_NAME='CUSTOMERS';

EXTENSION_NAME                    EXTENSION
------------------------------------------------------------------------
SYS_STUBPHJSBRKOIK9O2YV3W8HOUE    (LOWER("CUST_STATE_PROVINCE"))

次の問合せを使用すると、個別値の数と、ヒストグラムが作成されているかどうかを確認できます。

SELECT e.EXTENSION col_group, t.NUM_DISTINCT, t.HISTOGRAM
FROM   USER_STAT_EXTENSIONS e, USER_TAB_COL_STATISTICS t
WHERE  e.EXTENSION_NAME=t.COLUMN_NAME
AND    t.TABLE_NAME='CUSTOMERS';

COL_GROUP                        NUM_DISTINCT          HISTOGRAM
------------------------------------------------------------------------
(LOWER("CUST_STATE_PROVINCE"))   145                   FREQUENCY

13.5.2.2.3 式の統計の削除

DROP_EXTENDED_STATSファンクションを使用して、表から式の統計を削除します。

EXEC DBMS_STATS.DROP_EXTENDED_STATS(null,'customers','(lower(country_id))');

13.5.3 前のバージョンの統計のリストア

ディクショナリ内で統計が変更されるたびに、後でリストアできるように前のバージョンの統計が自動的に保存されます。統計をリストアするには、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_RETENTION: 現行の統計履歴の保存値を取得できます。

- GET_STATS_HISTORY_AVAILABILITY: このファンクションを使用すると、統計履歴が使用可能な最も古いタイムスタンプを取得できます。最も古いタイムスタンプより前のタイムスタンプには、統計をリストアできません。

前のバージョンの統計をリストアする場合は、次の制限が適用されます。

- RESTOREプロシージャでは、ユーザー定義統計はリストアできません。

- 統計の収集にANALYZEコマンドが使用された場合、古いバージョンの統計は格納されません。

注意:
DBMS_STATSを使用する際に、表からすべての行を削除するには、同じ表を削除して再度作成するかわりに、TRUNCATEを使用します。表を削除すると、自動ヒストグラム収集機能が使用するワークロード情報と、RESTORE_*_STATSプロシージャが使用する保存された統計履歴が消失します。このデータなしでは、これらの機能は適切に動作しません。

13.5.4 統計のエクスポートとインポート

統計をデータ・ディクショナリからエクスポートして、ユーザー所有の表にインポートできます。これにより、同じスキーマについて複数の統計のバージョンを作成できます。また、データベース間で統計のコピーもできます。この操作により、統計を本番データベースから小規模なテスト・データベースにコピーできます。

注意:
統計のエクスポートとインポートは、データ・ポンプ・エクスポートおよびインポート・ユーティリティとは異なる概念です。

統計をエクスポートする前に、その統計を保持する表を作成する必要があります。統計表は、DBMS_STATS.CREATE_STAT_TABLEプロシージャで作成します。表を作成した後、DBMS_STATS.EXPORT_*_STATSプロシージャを使用して、データ・ディクショナリから統計表に統計をエクスポートできます。統計をインポートするには、DBMS_STATS.IMPORT_*_STATSプロシージャを使用します。

オプティマイザでは、ユーザー所有の表に格納されている統計が使用されないことに注意してください。オプティマイザで使用されるのは、データ・ディクショナリに格納されている統計のみです。ユーザー所有の表内の統計をオプティマイザで使用するには、統計インポート・プロシージャを使用して、その統計をデータ・ディクショナリにインポートする必要があります。

統計をデータベース間で移動するには、最初のデータベース上の統計をエクスポートしてから、データ・ポンプ・エクスポートおよびインポート・ユーティリティまたは他のメカニズムを使用して統計表を第2のデータベースにコピーし、最後に統計を第2のデータベースにインポートする必要があります。

注意:
データ・ポンプ・エクスポートとインポート・ユーティリティは、データベースから表とともにオプティマイザ統計をエクスポートおよびインポートします。列にシステム生成の名前が付けられている場合、元のエクスポートでは統計をデータとともにエクスポートできませんが、この制限はデータ・ポンプのエクスポートには適用されません。

13.5.5 統計のリストアとインポートまたはエクスポートの相違点

統計リストア機能は、ある面では統計のインポートおよびエクスポート機能に類似しています。通常、次の場合にはリストア機能を使用します。

- 統計の古いバージョンをリカバリする場合。たとえば、オプティマイザの動作を前の日付までリストアする場合などです。

- データベースで統計履歴の保存および消去を管理する場合。

次の場合には、EXPORT/IMPORT_*_STATSプロシージャを使用する必要があります。

- 複数の統計セットを試験的に使用して値を増減させる場合。

- データベース間で統計を移動する場合。たとえば、本番システムからテスト・システムに統計を移動する場合などです。

- 既知の統計セットを統計のリストアに必要な保存日数よりも長期間にわたって保存する場合。

13.5.6 表統計またはスキーマ統計のロック

表またはスキーマの統計は、ロックすることができます。統計をロックすると、ロックを解除するまで統計を変更できません。ロック・プロシージャは、統計が変化しないことを保証する必要のある静的環境に役立ちます。

DBMS_STATSパッケージには、ロックするための2つのプロシージャ(LOCK_SCHEMA_STATSおよびLOCK_TABLE_STATS)と、統計のロックを解除するための2つのプロシージャ(UNLOCK_SCHEMA_STATSおよびUNLOCK_TABLE_STATS)が用意されています。

13.5.7 統計の設定

SET_*_STATISTICSプロシージャを使用して、表、列、索引およびシステムの統計を設定できます。統計が不正確であったり一貫性がないとパフォーマンスが低下するため、この方法での統計の設定はお薦めしません。

13.5.8 統計の欠落の処理

Oracle Databaseでは、統計が欠落している表が検出されると、デフォルトでオプティマイザに必要な統計を動的に収集します。ただし、リモート表や外部表などの特定のタイプの表に対しては、Oracle Databaseは動的統計を収集しません。これらの場合および動的統計が無効になっている場合、オプティマイザの統計ではデフォルト値が使用されます。表13-8および表13-9を参照してください。

表13-8 統計が欠落しているときの表のデフォルト値

表統計

オプティマイザによって使用されるデフォルト値

カーディナリティ

ブロック数×(ブロック・サイズ - キャッシュ層)÷行の平均の長さ

行の平均長さ

100バイト

ブロック数

100、またはエクステント・マップに基づく実際の値

リモート・カーディナリティ

2000行

リモートの行の平均長さ

100バイト

表13-9 統計が欠落しているときの索引のデフォルト値

索引統計

オプティマイザによって使用されるデフォルト値

レベル

1

リーフ・ブロック

25

リーフ・ブロック/キー

1

データ・ブロック/キー

1

個別キー

100

クラスタ化係数

800

13.6 動的統計の制御

デフォルトでは、オプティマイザ統計が存在しないか、拡張が必要な場合、Oracle Databaseでは、動的統計が自動的に収集されます。統計を得るために、データベースは解析中に再帰的SQLを使用して表ブロックの小さなランダム・サンプルをスキャンします。

注意:
以前のリリースでは、動的統計は動的サンプリングと呼ばれていました。

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

- 動的統計の目的

- 動的統計の概念

- 動的統計レベルの手動設定

- 動的統計の無効化

13.6.1 動的統計の目的

オプティマイザ統計で存在しないものや不十分なものが拡張されると、オプティマイザは、述語選択の評価を向上させてプランを改善することができます。動的統計は、表ブロック・カウント、適用可能な索引ブロック・カウント、表のカーディナリティ(概算行数)および関連する結合列の統計などの統計を補完できます。

13.6.2 動的統計の概念

動的統計は、データベースにおいてデフォルトで有効化されています。この機能を無効化するには、初期化パラメータOPTIMIZER_DYNAMIC_SAMPLING=0を設定します。

13.6.2.1 動的統計レベル

動的統計レベルでは、データベースで動的統計を収集するタイミングと、統計の収集にオプティマイザが使用するサンプル・サイズの両方が制御されます。動的統計レベルを設定するには、OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータまたは文ヒントのいずれかを使用します。

表13-10に動的統計レベルを示します。デフォルトのレベルは2です。Oracle Database 11gリリース2 (11.2.0.4)以上では、レベル11を設定すると、データベースは、オプティマイザが最適と判断するあらゆるタイミングとレベルで統計を収集するようになりました。

表13-10 動的統計レベル

レベル

オプティマイザで動的統計を使用するタイミング

サンプル・サイズ(ブロック)

0

動的統計を使用しません。

該当なし

1

次の基準を満たす場合のみ、統計を含まないすべての表に動的統計を使用します。

- 統計を含まない問合せにパーティション化されていない表が少なくとも1つ存在する場合。

- この表に索引がない場合。

- この表の動的統計で使用されるブロック数よりこの表のブロック数が多くある場合。

32

2

文の少なくとも1つの表に統計がない場合は、動的統計を使用します。これがデフォルトの設定です。

64

3

次のいずれかの条件に当てはまる場合は、動的統計を使用します。

- 文がレベル2の基準を満たす場合。

- WHERE SUBSTR(cust_last_name,1,3)など、WHERE句の述語で使用される1つ以上の式が文にある場合。

64

4

次のいずれかの条件に当てはまる場合は、動的統計を使用します。

- 文がレベル3の基準を満たす場合。

- 文が複雑な述語を使用している(同じ表で複数の述語をORまたはAND演算子でつないでいる)場合。

64

5

文がレベル4の基準を満たす場合は、動的統計を使用します。

128

6

文がレベル4の基準を満たす場合は、動的統計を使用します。

256

7

文がレベル4の基準を満たす場合は、動的統計を使用します。

512

8

文がレベル4の基準を満たす場合は、動的統計を使用します。

1024

9

文がレベル4の基準を満たす場合は、動的統計を使用します。

4086

10

文がレベル4の基準を満たす場合は、動的統計を使用します。

すべてのブロック

11

オプティマイザが必要と判断した場合は、常に自動的に動的統計が使用されます。

自動的に決定

関連項目:
DYNAMIC_SAMPLINGヒントの統計レベルの設定に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

13.6.2.2 オプティマイザで動的統計を使用するタイミング

動的統計を使用するかどうかを決める主な要因は、最適な計画を生成するために十分な統計が使用可能かどうかということです。統計が十分でない場合、オプティマイザは動的統計を使用します。

一般に、オプティマイザは、動的統計ではなく、デフォルトの統計を使用して、表、索引および列の最適化時に必要な統計を計算します。オプティマイザは、いくつかの要因に基づいて動的統計を使用するかどうかを決定します。たとえば、並列実行がSQL文で使用されていると、データベースは自動的に動的統計を使用します。

オプティマイザは、次のような場合に、自動的に動的統計を収集します。

- 統計の欠落
問合せ内の表に統計がない場合、オプティマイザは最適化の前にこれらの表の基本的な統計を収集します。アプリケーションで、統計を収集するためのDBMS_STATSへのフォローアップ・コールなしに新しいオブジェクトが作成された、または統計が収集される前にオブジェクトで統計がロックされたという理由で、統計が欠落することがあります。

この場合、統計はDBMS_STATSパッケージを使用して収集された統計ほど高品質ではなく、完全でもありません。これは、文のコンパイル時間に及ぼす影響を限定的にするために妥協されます。

- 統計の失効
DBMS_STATSによって収集された統計は、古くなることがあります。通常、最後に統計が収集されて以降、表内の10%以上の行が変更されると、統計は失効します。

- 不十分な統計
オプティマイザが、列間の相関、列データ配分の偏り、式の統計などを考慮に入れずに、述語(フィルタまたは結合)の選択性またはGROUP BY句を見積る場合、統計は常に不十分なものになる可能性があります。

拡張統計により、オプティマイザは複雑な条件式に対して的確な品質のカーディナリティ予測を得ることができます。オプティマイザは、動的統計を使用して拡張統計の欠落を補完したり、たとえば非等価述語に対する拡張統計が使用できないときに動的統計を使用したりすることができます。

注意:
データベースは、AS OF句を含む問合せに対して動的統計を使用しません。

Oracle Database 11gリリース2 (11.2.0.4)から、オプティマイザは、すべてのSQL文に対して、動的統計が有用であるかどうか、および使用する統計レベルを自動的に決定できるようになりました。OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータまたはSQLヒントのいずれかによってサンプリングレベルが11 (表13-10参照)に明示的に設定された場合にかぎり、オプティマイザはこのように動作します。

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

13.6.3 動的統計レベルの手動設定

動的統計レベルを設定するベスト・プラクティスは、ALTER SESSIONを使用してOPTIMIZER_DYNAMIC_SAMPLING初期化パラメータに値を設定することです。すべてのSQL文に利点のある、システム全体の設定を決定することは容易ではありません。

前提事項

このチュートリアルでは、次のことが前提となっています。

- 次の問合せに対して選択性の見積りを修正する場合で、2つの相関列にWHERE句の述語があります。

SELECT *
FROM   sh.customers
WHERE  cust_city='Los Angeles'
AND    cust_state_province='CA';

- 前述の問合せはシリアル処理を使用します。

- sh.customers表は、問合せの条件を満たす932の行を含みます。

- sh.customers表に収集された統計があります。

- cust_city列とcust_state_province列に索引を作成しています。

- OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータが、デフォルト・レベルの2に設定されています。

動的統計レベルを手動設定する手順は次のとおりです。

1. 適切な権限でSQL*Plusをデータベースに接続し、実行計画を次のようにEXPLAINします。

EXPLAIN PLAN FOR
SELECT *
FROM   sh.customers
WHERE  cust_city='Los Angeles'
AND    cust_state_province='CA';

2. その計画を次のように問い合せます。

SET LINESIZE 130
SET PAGESIZE 0
SELECT *
FROM   TABLE(DBMS_XPLAN.DISPLAY);

出力が次のように表示されます(この例はページに収まるように再フォーマットされています)。

-------------------------------------------------------------------------------
|Id| Operation                   | Name             |Rows|Bytes|Cost | Time   |
-------------------------------------------------------------------------------
| 0| SELECT STATEMENT            |                   | 53| 9593|53(0)|00:00:01|
| 1|  TABLE ACCESS BY INDEX ROWID|CUSTOMERS          | 53| 9593|53(0)|00:00:01|
|*2|   INDEX RANGE SCAN          |CUST_CITY_STATE_IND| 53| 9593| 3(0)|00:00:01|
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("CUST_CITY"='Los Angeles' AND "CUST_STATE_PROVINCE"='CA')

WHERE句の列には実世界の相関関係がありますが、オプティマイザはロサンゼルスがカリフォルニアにあることを認識せず、両方の述語により、戻される行の数が減少すると想定しています。このように、表には条件を満たす932の行が含まれますが、太字で示すようにオプティマイザは53と見積っています。

データベースでこの計画に動的統計を使用したとすれば、計画出力のNoteセクションでこの事実が指摘されることになります。オプティマイザで動的統計が使用されなかった理由は、文がシリアルに実行されたことや、標準統計が存在することのほか、OPTIMIZER_DYNAMIC_SAMPLINGパラメータがデフォルトの2に設定されていることがあげられます。

3. 次の文を使用して、セッションで動的統計レベルを4に設定します。

ALTER SESSION SET OPTIMIZER_DYNAMIC_SAMPLING=4;

4. この計画を再び次のようにEXPLAINします。

EXPLAIN PLAN FOR
SELECT *
FROM   sh.customers
WHERE  cust_city='Los Angeles'
AND    cust_state_province='CA';

この新しい計画では、太字で示されている値932のように、行数の見積りがより正確に示されています。

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------
Plan hash value: 2008213504

-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |   932 |   271K|   406   (1)| 00:00:05 |
|*  1 |  TABLE ACCESS FULL| CUSTOMERS |   932 |   271K|   406   (1)| 00:00:05 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("CUST_CITY"='Los Angeles' AND "CUST_STATE_PROVINCE"='CA')

Note
-----
- dynamic statistics used for this statement (level=4)

計画の一番下のメモは、サンプリング・レベルが4であることを示します。追加された動的統計によって、オプティマイザにcust_city列とcust_state_province列間の実世界の関係を認識させることで、行数が53ではなく932という、より正確な見積りを生成できるようになります。

関連項目:

- DYNAMIC_SAMPLINGヒントを使用したサンプリング・レベルの設定の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

13.6.4 動的統計の無効化

一般的には、繰返しのないOLTP問合せなど、コンパイル時間を可能なかぎり速くすることが必要な問合せに対して、動的統計のコストが発生しないようにすることがベスト・プラクティスです。OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータを設定することでその機能を無効にできます。

セッション・レベルの動的統計を無効化する手順は次のとおりです。

1. 適切な権限でSQL*Plusをデータベースに接続します。

2. 動的統計レベルを0に設定します。
たとえば、次の文を実行します。

ALTER SESSION SET OPTIMIZER_DYNAMIC_SAMPLING=0;

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

13.7 統計の表示

この項では、次の内容を説明します。

- 表、索引および列の統計

- ヒストグラムの表示

13.7.1 表、索引および列の統計

表、索引および列の統計は、データ・ディクショナリに格納されます。データ・ディクショナリ内の統計を表示するには、適切なデータ・ディクショナリ・ビューを問い合せます(USER、ALLまたはDBA)。次のようなビューがあります。

- DBA_TABLESおよびDBA_OBJECT_TABLES

- DBA_TAB_STATISTICSおよびDBA_TAB_COL_STATISTICS

- DBA_TAB_HISTOGRAMS

- DBA_TAB_COLS

- DBA_COL_GROUP_COLUMNS

- DBA_INDEXESおよびDBA_IND_STATISTICS

- DBA_CLUSTERS

- DBA_TAB_PARTITIONSおよびDBA_TAB_SUBPARTITIONS

- DBA_IND_PARTITIONSおよびDBA_IND_SUBPARTITIONS

- DBA_PART_COL_STATISTICS

- DBA_PART_HISTOGRAMS

- DBA_SUBPART_COL_STATISTICS

- DBA_SUBPART_HISTOGRAMS

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

13.7.2 ヒストグラムの表示

列の統計をヒストグラムとして格納できます。これらのヒストグラムは、列データの配分の正確な見積りを提供します。ヒストグラムによって、データが偏っている場合の選択性の見積りの精度が改善され、均一でないデータ配分が存在する最適な実行計画が得られます。

Oracle Databaseでは、列統計に次のタイプのヒストグラムを使用します。

- 高さ調整済ヒストグラム

- 頻度ヒストグラム

このタイプのヒストグラムは、*TAB_COL_STATISTICSビュー(USERおよびDBA)のHISTOGRAM列に格納されます。この列の値は、HEIGHT BALANCED、FREQUENCYまたはNONEです。

13.7.2.1 高さ調整済ヒストグラム

高さ調整済ヒストグラムでは、列値がバケットに分割され、各バケットにほぼ同数の行が存在します。ヒストグラムは、値範囲でのエンドポイントの位置を示します。

値の範囲が1から100で、ヒストグラムが10バケットである列my_colについて考えます。my_colのデータ配分が均一な場合のヒストグラムは、図13-1のようになります。数字はエンドポイントの値です。たとえば、7番目のバケットには、値が60から70の行が含まれます。

図13-1 データ配分が均一の高さ調整済ヒストグラム

各バケットの行数は、全行数の10%です。この均一に配分された例では、60から100の値の行が40%を占めます。

データ配分が均一でない場合のヒストグラムは、図13-2のようになります。この場合、ほとんどの行で、この列の値が5になっています。60から100の間の値を持っている行は、10%のみです。

図13-2 データ配分が非均一の高さ調整済ヒストグラム

高さ調整済ヒストグラムは、USER_TAB_HISTOGRAMS表を使用して表示できます(例13-1)。

例13-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_TAB_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

例13-1の問合せ出力では、各行(1から10)はヒストグラムの各バケットに対応しています。Oracle Databaseでは、1番目のバケットの値(27)はquantity_on_hand列の最小値ではないため、このヒストグラムに特殊な0番目のバケットが追加されています。0番目のバケットは、quantity_on_handの最小値0です。

13.7.2.2 頻度ヒストグラム

頻度ヒストグラムでは、列の各値がヒストグラムの1つのバケットに対応しています。各バケットには、この単一値の発生数が含まれます。たとえば、warehouse_id列の1の値が、36行に含まれているとします。値が1のエンドポイントのエンドポイント番号は36です。

次の条件に当てはまる場合、高さ調整済ヒストグラムのかわりに頻度ヒストグラムが自動的に作成されます。

- 個別値の数が、指定されたヒストグラム・バケットの数(最大254)以下である。

- 各列の値の繰返しが1回のみではない。

頻度ヒストグラムは、USER_TAB_HISTOGRAMSビューを使用して表示できます(例13-2)。

例13-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_TAB_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

例13-2の最初のバケットは、warehouse_idが1のバケットです。表の値は36倍で表示されます。これは次の問合せで確認できます。

oe@PROD> SELECT COUNT(*) FROM inventories WHERE warehouse_id = 1;

COUNT(*)
----------
36

14 索引およびクラスタの使用方法

この章では、索引およびクラスタを使用してパフォーマンスを強化できる、または低下させるデータ・アクセス方法の概要を説明します。

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

- 索引パフォーマンスについて

- パフォーマンスを考慮したファンクション索引の使用方法

- パフォーマンスを考慮したパーティション索引の使用方法

- パフォーマンスを考慮した索引構成表の使用方法

- パフォーマンスを考慮したビットマップ索引の使用方法

- パフォーマンスを考慮したビットマップ結合索引の使用方法

- パフォーマンスを考慮したドメイン索引の使用方法

- パフォーマンスを考慮した表クラスタの使用方法

- パフォーマンスを考慮したハッシュ・クラスタの使用方法

14.1 索引パフォーマンスについて

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

- 論理構造のチューニング

- SQLアクセス・アドバイザを使用した索引のチューニング

- 索引を付ける列と式の選択

- コンポジット索引の選択

- 索引を使用する文の記述

- 索引を使用しない文の記述

- 索引の再作成

- 一意でない索引による一意性の規定

- ENABLE NOVALIDATE制約の使用方法

14.1.1 論理構造のチューニング

問合せの最適化により、問合せの実行における非選択的索引の使用を回避できますが、SQLエンジンは、索引が問合せで使用されるかどうかにかかわらず、表に対して定義されたすべての索引を継続的にメンテナンスする必要があります。書込み集中型アプリケーションでは、索引のメンテナンスにCPUとI/Oリソースが大量に必要となる場合があります。したがって、必要がなければ索引を作成しないでください。

最適なパフォーマンスを保つために、アプリケーションで使用していない索引を削除してください。使用されていない索引は、典型的なワークロードのかかる期間にわたってALTER INDEX MONITORING USAGE機能を使用することで検出できます。この監視機能は、索引が使用されたかどうかを記録します。使用されていない索引が検出された場合は、削除してください。サンプリングした負荷以外の負荷で使用されている索引を削除しないように、典型的な負荷を監視していることを確認してください。

また、アプリケーション内では、文の実行計画の調査ですぐには明らかにならない索引の使用方法もあります。その例が、共有ロックが子表上に取り出されないようにする親表上の外部キー索引です。

新しい索引を作成して文のチューニングを行うかどうかを決定する場合、EXPLAIN PLAN文を使用して、アプリケーションの実行時にオプティマイザがこれらの索引を使用するかどうかを調べることもできます。新しい索引を作成して現在解析中の文をチューニングする場合、Oracle Databaseはその文を無効にします。

その文が次に解析されるとき、オプティマイザは、新しい索引を使用する可能性のある新しい実行計画を自動的に選択します。新しい索引をリモート・データベース上に作成して分散型の文をチューニングする場合は、その文が次に解析されるとき、オプティマイザがこれらの索引について検討します。

索引を作成してある文をチューニングした場合、他の文の実行計画に対するオプティマイザの選択に影響を及ぼす場合があるので注意してください。たとえば、ある文によって使用される索引を作成した場合、オプティマイザは、アプリケーションの他の文に対しても、その索引の使用を選択する場合があります。このため、最初にチューニング対象と判断した文をチューニングした後、アプリケーションのパフォーマンスおよび実行計画を再検査し、SQLトレース機能を利用します。

関連項目:

- ALTER INDEX MONITORING USAGE文の構文およびセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 外部キーの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

14.1.2 SQLアクセス・アドバイザを使用した索引のチューニング

SQLアクセス・アドバイザは、どの索引が必要であるかを手動で判別する作業に対する代替機能です。このアドバイザをOracle Enterprise Managerから起動するか、DBMS_ADVISORパッケージAPIを介して実行すると、索引セットを推奨します。SQLアクセス・アドバイザはワークロードの使用を推奨するか、または指定のスキーマに関する仮定的なワークロードを生成します。

ワークロードのソースには、SQLキャッシュの現在の内容、ユーザー定義のSQL文のセットまたはSQLチューニング・セットなどを使用できます。ワークロードを指定すると、SQLアクセス・アドバイザにより推奨事項のセットが生成され、実装する索引を選択できます。実装するには、提供されたスクリプトを手動で実行するか、Oracle Enterprise Managerを使用して自動的に実装します。

関連項目:
SQLアクセス・アドバイザの概要

14.1.3 索引を付ける列と式の選択

キーは、索引を付ける列または式です。次のガイドラインに従って、索引を付けるキーを選択します。

- WHERE句に頻出するキーの索引付けを検討します。

- SQL文で表の結合に頻繁に使用されるキーの索引付けを検討します。結合の最適化の詳細は、「パフォーマンスを考慮したハッシュ・クラスタの使用方法」を参照してください。

- 選択性の高い索引キーを選択します。索引の選択性は、索引付けするキー値と同じ値を持つ行が表に含まれる割合です。同じ値を持つ行がほとんどない場合、索引の選択性は最適です。

注意:
整合性制約で定義されたキーおよび一意キーと主キーの式では、Oracle Databaseが自動的に索引を作成するか、既存の索引が使用されます。

データ配分に偏りがあるため、他の値と比較して1つまたは2つの値の発生が非常に少ない場合、選択性の低い列の索引付けが役立つ場合もあります。

- 個別値をほとんど持たないキーまたは式には、標準のBツリー索引を使用しません。通常、そのようなキーや式は選択性が低いので、頻繁に選択されるキー値がその他のキー値に比べてそれほど多くない場合を除くと、パフォーマンスは最適化されません。このような場合には、ビットマップ索引を使用すると効果的です。ただし、同時実行性の高いOLTPアプリケーションのように、索引が頻繁に変更される場合には向きません。

- 変更が頻繁に行われる列は、索引付けしないでください。索引付きの列を修正するUPDATE文および索引付きの表を修正するINSERT文とDELETE文では、索引がない場合よりも、処理に長い時間が必要となります。このようなSQL文では、索引のデータおよび表のデータの変更が必要です。また、追加のUNDOおよびREDOも作成されます。

- ファンクションや演算子を含むWHERE句のみに指定されるキーには索引を付けません。索引付きのキーにMINやMAX以外のファンクションや演算子を使用するWHERE句は、ファンクション索引を除く索引を使用するアクセス・パスを選択しません。

- 同時実行の数多くのINSERT文およびUPDATE文、DELETE文が親表と子表をアクセスする場合、参照整合性制約の外部キーに索引を付けることを検討します。このような索引を使用すると、子表を共有ロックせずに親表でUPDATEおよびDELETEを実行できます。

- 索引を付けるキーを選択するとき、問合せのパフォーマンス向上が、INSERT、UPDATE、DELETEのパフォーマンス損失および索引を格納するために必要となる領域の使用に見合う価値があるかどうか検討してください。SQL文の処理時間を索引の有無によって実際に比較することをお薦めします。SQLトレース機能で処理時間を測定できます。

関連項目:
ロックへの外部キーの影響の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

14.1.4 コンポジット索引の選択

コンポジット索引には複数のキー列が含まれます。コンポジット索引には、次のような単一列索引を上回る利点があります。

- 選択性の向上
選択性の低い複数の列または式を組み合せることで、選択性の高いコンポジット索引を作成できる場合があります。

- I/Oの削減
Oracle Databaseでは、問合せで選択されるすべての列がコンポジット索引に含まれている場合、表にアクセスすることなく、索引でこれらの値を戻すことができます。

SQL文の構成メンバーが索引の先頭部分を使用する場合、その文はコンポジット索引を含むアクセス・パスを使用できます。

注意:
このことは、索引スキップ・スキャンには現在、該当しなくなっています。「索引スキップ・スキャン」を参照してください。

索引の先頭部分とは、その索引を作成したCREATE INDEX文で列リストの先頭から連続的に指定された1つ以上の列の組合せのことです。次のCREATE INDEX文について考えてみます。

CREATE INDEX comp_ind
ON table1(x, y, z);

- x、xy、xyzの各列の組合せは、索引の先頭部分です。

- yz、y、zの各列の組合せは、索引の先頭部分ではありません。

14.1.4.1 コンポジット索引のキーの選択

コンポジット索引を構成するキーを選択するために、次のガイドラインに従ってください。

- AND演算子で結合してWHERE句の条件で頻繁に使用されるキー、特に、各キーの個別の選択性と比較して、キーを組み合せることで選択性が高くなる場合、コンポジット索引の作成を検討します。

- 複数の問合せが1つ以上のキー値に基づいて同じキー・セットを選択する場合、これらのキーのすべてを含むコンポジット索引を作成することを検討します。

また、索引を作成する際の一般的なパフォーマンスの利点およびトレードオフに関する前述のガイドラインも検討してください。

14.1.4.2 コンポジット索引のキーの順序付け

コンポジット索引内でのキーの順序を指定するために次のガイドラインに従ってください。

- WHERE句で使用されるキーが先頭部分を構成するように、索引を作成してください。

- 一部のキーがWHERE句で頻繁に使用される場合は、これらのキーのみを使用する文が索引を使用できるように、頻繁に選択されるキーが先頭部分を構成するように索引を作成します。

- すべてのキーがWHERE句で均等に使用され、そのキーの1つでデータが物理的に順序付けられている場合には、そのキーをコンポジット索引の先頭にしてください。

14.1.5 索引を使用する文の記述

索引を作成しても、単に索引が存在するのみでは、オプティマイザはその索引を使用するアクセス・パスを選択できません。オプティマイザは、SQL文にアクセス・パスを使用可能にする構造が含まれている場合にかぎり、そのようなアクセス・パスを選択できます。索引アクセス・パスを使用するというオプションを問合せオプティマイザで可能にするには、文が索引アクセス・パスを使用可能にする構文になっていることを確認してください。

14.1.6 索引を使用しない文の記述

場合によっては、既存の索引を使用するアクセス・パスをSQL文で使用しないことも可能です。この方法は、索引の選択性が低く、全表スキャンの方が効率的であることがわかっている場合に採用できます。そのような索引アクセス・パスを使用可能にする条件が文に含まれている場合は、次に示す方法の1つを使用して、オプティマイザに全表スキャンを使用するように強制できます。

- NO_INDEXヒントを使用して特定索引の使用を禁止にし、問合せオプティマイザに最大限の柔軟性を持たせることができます。

- FULLヒントを使用し、オプティマイザに対して索引スキャンのかわりに全表スキャンを選択するように指示します。

- INDEXヒントまたはINDEX_COMBINEヒントを使用し、オプティマイザに、ある索引(またはリストされている索引セット)を別の索引(または索引セット)のかわりに使用するように指示します。

関連項目:
NO_INDEX、FULL、INDEX、INDEX_COMBINEおよびヒントの詳細は、第19章「オプティマイザ・ヒントの使用方法」を参照してください。

パラレル実行は、索引を効果的に利用します。このオプションは、パラレル索引レンジ・スキャンを実行しませんが、ネステッド・ループ・ジョインをパラレル実行するためにパラレル索引参照を実行します。索引の選択性が高い(各索引エントリの行数が少ない)場合は、パラレル表スキャンよりも順次索引参照を使用することをお薦めします。

14.1.7 索引の再作成

索引を縮小し分断化された領域を最小化するため、または索引の記憶特性を変更するために索引を再作成する場合があります。既存の索引のサブセットとなる新しい索引を作成する場合、または新しい記憶特性を使用して既存の索引を再構築する場合、Oracle Databaseでは、実表ではなく既存の索引を使用することで索引作成のパフォーマンスが向上する場合があります。

ただし、既存の索引ではなく、実表を使用することが有効な場合もあります。多くのDMLが実行された表の索引を考えてみてください。DMLのために索引のサイズが大きくなり、各ブロックが50%以下しか満たされなくなる場合があります。索引が表のほとんどの列を参照している場合、索引が表よりも大きくなりかねません。その場合は、索引よりも実表を使用した方が、索引の再作成が速くできます。

ALTER INDEX ... REBUILD文は、既存の索引を再編成または縮小するため、または既存の索引の記憶特性を変更するために使用します。REBUILD文は、新しい索引の基礎として既存の索引を使用します。STORAGE(エクステントの割当て用)、TABLESPACE(索引を新しい表領域に移動する)およびINITRANS(エントリの最初の数を変更する)などのすべての索引記憶用の文がサポートされています。

ALTER INDEX ... REBUILDは、高速全体スキャン機能を使用するので、通常は索引を削除して再作成するよりも高速です。この文は、マルチブロックI/Oを使用して索引ブロックをすべて読み取ってから、ブランチ・ブロックを廃棄します。さらに、このアプローチには、再作成の実行中の問合せには、旧索引を利用できるという利点があります。

関連項目:
CREATE INDEX文とALTER INDEX文、および索引の再作成に関する制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

14.1.8 索引の縮小

COALESCEオプションを持つALTER INDEX文を使用して索引のリーフ・ブロックを結合できます。このオプションでは、索引のリーフ・レベルを結合して空きブロックにし、再利用できます。また、索引をオンラインで再作成することもできます。

関連項目:
この文の構文の詳細は、『Oracle Database SQL言語リファレンス』および『Oracle Database管理者ガイド』を参照してください。

14.1.9 一意でない索引による一意性の規定

UNIQUE制約、またはPRIMARY KEY制約の一意性の側面に関して、一意性を規定するために、表の既存の一意でない索引を使用できます。このアプローチの利点は、制約が使用禁止にされているときでも索引が使用可能であり、妥当であるということです。したがって、使用禁止にされているUNIQUE制約またはPRIMARY KEY制約を使用可能にするために、その制約に対応付けられている一意索引を再作成する必要はありません。これにより、大規模表で操作を使用可能にする際に時間を大幅に節約できます。

さらに、一意でない索引を使用して一意性を規定すると、索引の重複を排除できます。主キー列がコンポジット索引の接頭辞として組み込まれている場合、その列に対する一意索引は不要です。制約を使用可能または規定するときに、既存の索引を使用できます。また、索引を複製しないので、領域を大幅に節約できます。ただし、既存の索引がパーティション化されている場合は、索引のパーティション・キーもUNIQUEキーのサブセットである必要があります。サブセットでない場合、Oracle Databaseでは、一意索引が追加作成され、制約を規定します。

14.1.10 ENABLE NOVALIDATE制約の使用方法

ENABLE NOVALIDATE制約は、新しいデータのENABLE VALIDATE制約と同じように動作します。制約をENABLE NOVALIDATE状態にすることは、表に入力された新規データが制約に準拠する必要があることを意味します。既存のデータはチェックされません。制約をENABLE NOVALIDATE状態にすることにより、表をロックしないで制約を使用可能にできます。

制約を使用禁止から使用可能に変更する場合、表をロックする必要があります。使用可能にする際に、表に対する操作が制約に準拠していることを確認できないため、新しいDML、問合せまたはDDLは実行できません。ENABLE NOVALIDATE状態では、制約に違反する操作を表に対して実行できません。

表のパラレル一貫読取り問合せにより、ENABLE NOVALIDATE制約を検証して、制約に違反するデータがあるかどうかを判断できます。ロックされないため、表の読取りも書込みも使用可能化操作によってブロックされません。さらに、ENABLE NOVALIDATE制約はパラレルで検査できます。複数の制約を同時に検査し、パラレル問合せを使用して各制約の妥当性をチェックできます。

制約と索引を持つ表を作成するアプローチは次のとおりです。

1. 制約を持つ表を作成します。NOT NULL制約には名前を付けなくても構いませんが、使用可能かつ検証済で作成してください。他のすべての制約(CHECK、UNIQUE、PRIMARY KEYおよびFOREIGN KEY)に名前を付け、使用禁止で作成します。

注意:
デフォルトでは、制約はENABLED状態で作成されます。

2. 旧データを表にロードします。

3. 制約に必要な索引を含め、すべての索引を作成します。

4. 未検査の制約をすべて使用可能にします。これは、外部キーの前に主キーに対して行ってください。

5. ユーザーがデータを問合せおよび変更できるようにします。

6. 制約ごとに別個のALTER TABLE文を使用して、すべての制約を検証します。これは、外部キーの前に主キーに対して行ってください。次に例を示します。

CREATE TABLE t (a NUMBER CONSTRAINT apk PRIMARY KEY DISABLE,
b NUMBER NOT NULL);
CREATE TABLE x (c NUMBER CONSTRAINT afk REFERENCES t DISABLE);

ここで、表tにデータをロードします。

CREATE UNIQUE INDEX tai ON t (a);
CREATE INDEX tci ON x (c);
ALTER TABLE t MODIFY CONSTRAINT apk ENABLE NOVALIDATE;
ALTER TABLE x MODIFY CONSTRAINT afk ENABLE NOVALIDATE;

この時点で、ユーザーは、表tでINSERT、UPDATE、DELETEおよびSELECTの各操作を実行できます。

ALTER TABLE t ENABLE CONSTRAINT apk;
ALTER TABLE x ENABLE CONSTRAINT afk;

これで、制約はENABLE VALIDATEになりました。

関連項目:
整合性制約の詳細は、『Oracle Database概要』を参照してください。

14.2 パフォーマンスを考慮したファンクション索引の使用方法

ファンクション索引には、ファンクション(たとえば、UPPERファンクション)で変換される列、または式(たとえば、col1 + col2)に含まれている列があります。ファンクション索引により、索引で計算集中型の式を保存できます。

変換された列または式でファンクション索引を定義すると、そのファンクションまたは式をWHERE句またはORDER BY句で使用するとき、その索引を使用してデータを戻すことができます。これにより、SELECT文およびDELETE文を処理する際に式の値の計算をバイパスできます。したがって、ファンクション索引は、頻繁に実行されるSQL文のWHERE句またはORDER BY句の中に変換列(または式の中の列)が含まれているときに有益です。

Oracle Databaseでは、降順の索引は、ファンクション索引として処理されます。DESCのマークのある列は、降順でソートされます。

たとえば、UPPER(column_name)キーワードまたはLOWER(column_name)キーワードで定義されたファンクション索引を使用すると、大/小文字を区別しない検索ができます。次の文で索引を作成します。

CREATE INDEX uppercase_idx ON employees (UPPER(last_name));

これを使用すると、次のような問合せの処理が容易になります。

SELECT * FROM employees
WHERE UPPER(last_name) = 'MARKSON';

関連項目:

- ファンクション索引の使用の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』および『Oracle Database管理者ガイド』を参照してください。

- CREATE INDEX文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

14.3 パフォーマンスを考慮したパーティション索引の使用方法

パーティション表と同様に、パーティション索引を使用すると、管理性、可用性、パフォーマンスおよびスケーラビリティが向上します。パーティション索引は、個別にパーティション化するか(グローバル索引)、または表のパーティション・メソッドに自動的にリンクできます(ローカル索引)。

Oracle Databaseでは、レンジ・パーティション化およびハッシュ・パーティション化されたグローバル索引をサポートします。レンジ・パーティション化されたグローバル索引では、各索引パーティションに、パーティション・バウンドで定義された値が含まれます。ハッシュ・パーティション化されたグローバル索引では、各パーティションに、Oracle Databaseハッシュ関数により決定された値が含まれます。

マルチユーザーのOLTP環境で、索引内の少数のリーフ・ブロックに競合が多い場合、ハッシュ・メソッドにより索引のパフォーマンスが向上します。OLTPアプリケーションによっては、索引の右端にのみ索引が挿入される場合があります。この状況は、単調に増える列に対して索引を定義した場合に起こります。この状況では、索引ページ、バッファ、更新のラッチ、および追加索引メンテナンス・アクティビティの競合により、索引の右端がホットスポットとなり、パフォーマンスが低下します。

ハッシュ・パーティション化されたグローバル索引では、索引エントリはパーティション・キーおよびパーティション数に基づいて異なるパーティションにハッシュされます。これにより、定義済のパーティション数全体に競合が拡散され、スループットが向上します。ハッシュ・パーティション化されたグローバル索引を使用すると、バッファ・ラッチの競合が複数のパーティションにわたって拡散されるため、大規模PDMLとして大きなファクト表に実行されるTPC-Hリフレッシュ関数には有効です。

ハッシュ・パーティション化では、索引エントリはOracle Databaseで生成されたハッシュ値に基づいて特定の索引パーティションにマップされます。ハッシュ・パーティション化されたグローバル索引を作成するための構文は、ハッシュ・パーティション表と非常によく似ています。索引パーティション・キーについての等価述語およびIN述語を伴う問合せでは、グローバル・ハッシュ・パーティション索引を効率的に使用して問合せにすばやく回答できます。

関連項目:
グローバル索引表の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

14.4パフォーマンスを考慮した索引構成表の使用方法

索引構成表は、表のデータが、対応付けられた索引に保持されるという点で普通の表とは異なります。新しい行の追加、行の更新、行の削除など、表データを変更すると、索引のみが更新されます。データ行は索引に格納されるため、索引構成表では完全一致、範囲検索またはその両方を含む問合せの表データに対するさらに高速なキー・ベースのアクセスが可能になります。

親/子関係は、索引構成表を保証する状況の一例です。たとえば、メンバー表に電話番号を含む子表があるとします。メンバーの電話番号は、時間の経過とともに変更および追加されます。ヒープ構成表では、行は適合するデータ・ブロックに挿入されます。ただし、メンバー表に問合せを行う場合、電話番号は常に子表から取得されます。取得の効率性を高めるために、指定のメンバーの電話レコードが互いにデータ・ブロック内の近くに挿入されるように、索引構成表に電話番号を格納できます。

特定の状況では、索引構成表の方がヒープ構成表よりもパフォーマンスの面で利点があります。たとえば、問合せに必要なキャッシュ内のブロック数が比較的少ない場合、データベースではバッファ・キャッシュがより効率的に使用されます。問合せに必要な個別のブロック数が比較的少ない場合は、1回の物理I/Oによって必要なデータがすべて取得されるため、各問合せに必要なI/Oの量はわずかで済みます。

グローバル・ハッシュ・パーティション索引は索引構成表でサポートされており、マルチユーザーのOLTP環境でパフォーマンスが向上します。索引構成表は、関連するデータをまとめて格納する場合、またはデータを特定の順序で物理的に格納する場合に役立ちます。

関連項目:
索引構成表の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

14.5 パフォーマンスを考慮したビットマップ索引の使用方法

ビットマップ索引は、次のすべての特性を持つ問合せのパフォーマンスを大幅に向上できます。

- カーディナリティが低いか中位である列に関する述語がWHERE句に複数含まれています。

- カーディナリティが低いか中位である列に関する個々の述語が大量の行を選択しています。

- カーディナリティが低いか中位である列の一部または全部に対して、問合せで使用されるビットマップ索引が作成されています。

- 問合せの表に多数の行が含まれています。

複数のビットマップ索引を使用して、単独の表に対する条件を評価できます。このため、ビットマップ索引は、長いWHERE句を含む複合非定型問合せにとって非常に有効です。ビットマップ索引は、集合問合せでもスター・スキーマでの結合の最適化でも最適なパフォーマンスを提供します。

関連項目:
ビットマップ索引の詳細は、『Oracle Database概要』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

14.6 パフォーマンスを考慮したビットマップ結合索引の使用方法

単一表のビットマップ索引の他に、ビットマップ結合索引を作成できます。この索引は、複数の表を結合するためのビットマップ索引です。ビットマップ結合索引では、事前に制限事項を実行することで、結合する必要のあるデータ量を削減して領域を節約できます。ビットマップ結合索引は、表の列の値ごとに、別の表の対応する行のROWIDを格納します。データ・ウェアハウス環境では、結合条件は、ディメンション表の主キー列、およびファクト表の外部キー列との間の等価内部結合です。

ビットマップ結合索引は、マテリアライズド結合ビューより格納の効率がはるかによく、事前に結合をマテリアライズする方法の代替手段です。マテリアライズド結合ビューは、ファクト表のROWIDを圧縮しません。

関連項目:
ビットマップ結合索引の例および制限については、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

14.7 パフォーマンスを考慮したドメイン索引の使用方法

ドメイン索引は、ユーザー定義の索引タイプで指定された索引作成論理で作成されます。索引タイプを使用すると、特定の演算子の述部に合うデータに効率よくアクセスできます。通常、ユーザー定義の索引タイプは、Spatialオプションのように、Oracle Databaseオプションの一部です。たとえば、SpatialIndextypeを使用すると、ある条件ボックスにオーバーラップするSpatialデータを効率よく取り出せます。

ドメイン索引の作成と保守で指定できるパラメータは、カートリッジによって異なります。同様に、ドメイン索引のパフォーマンスと記憶域の特性は、カートリッジ固有のマニュアルを参照してください。

次の情報は、適切なカートリッジ・マニュアルを参照してください。

- 索引付けの可能なデータ型

- 使用できる索引タイプ

- 索引タイプで使用できる演算子

- ドメイン索引を作成およびメンテナンスする方法

- 問合せで演算子を効率よく使用する方法

- パフォーマンス特性の内容

注意:
索引タイプはCREATE INDEXTYPE文でも作成できます。

関連項目:
SpatialIndextypeの詳細は、『Oracle Spatial開発者ガイド』を参照してください。

14.8 パフォーマンスを考慮した表クラスタの使用方法

表クラスタは、共通の列を共有し、通常はSQL文で同時に使用されるため、物理的にまとめて格納される1つ以上の表のグループです。データベースでは、関連する行が物理的にまとめて格納されるため、ディスク・アクセス時間が向上します。クラスタを作成するには、CREATE CLUSTER文を使用します。

関連項目:
クラスタの詳細は、『Oracle Database概要』を参照してください。

表をクラスタ化するかどうかを判断するために、次のガイドラインに従ってください。

- アプリケーションが結合処理で頻繁にアクセスする表をクラスタ化します。

- アプリケーションが表の結合を頻繁には行わない場合、または共通の列の値を頻繁に修正する場合、それらの表はクラスタ化しません。Oracle Databaseでは、行のクラスタ・キー値を変更すると、クラスタを維持するために変更された行を別のブロックに移行することが必要になる場合があるため、非クラスタ化表の値を変更する場合よりも時間がかかります。

- アプリケーションが複数の表の1つについてのみ頻繁に全表スキャンを行う場合、それらの表はクラスタ化しません。クラスタ化表の全表スキャンに要する処理時間は、非クラスタ化表の全表スキャンよりも長くなる可能性があります。表がまとめて格納されているため、より多くのブロックの読取りが必要になる可能性があります。

- マスター・レコードを選択してから対応するディテール・レコードを選択することがよくある場合、マスター/ディテール表をクラスタ化します。ディテール・レコードはマスター・レコードと同じデータ・ブロックに格納されるため、選択する際にそれらがメモリー内に存在している可能性があります。これにより、Oracle Databaseでは、必要なI/O処理が減少します。

- 同じマスターについて多くのディテール・レコードを選択することがよくある場合、ディテール表のみをクラスタに格納します。このようにすれば、同じマスターについて多くの詳細レコードを選択する問合せのパフォーマンスが改善され、マスター表に対する全表スキャンのパフォーマンスも低下させずに済みます。別の方法として、索引構成表を使用する方法があります。

- 同じクラスタ・キー値を持つすべての表からのデータが、1または2データ・ブロックを超過する場合、それらの表はクラスタ化しません。Oracle Databaseでは、クラスタ化表の行にアクセスする際に、その値を持つ行を含むすべてのブロックを読み取ります。これらの行が複数のブロックを使用している場合、単一行をアクセスすることによって、非クラスタ化表で同じ行をアクセスする場合よりも多くの読取り処理が必要になる場合があります。

- 各クラスタ・キー値の行数が大きく異なっている場合は表をクラスタ化しないてください。クラスタ化した場合、カーディナリティの低いキー値の場合には領域が無駄になり、カーディナリティの高いキー値の場合には衝突が発生します。衝突が発生するとパフォーマンスが下がります。

アプリケーションでのクラスタの長所と短所を検討してください。たとえば、結合文のパフォーマンス向上が、クラスタ・キー値を修正する文のパフォーマンス低下を上回る場合もあります。表をクラスタ化した場合と別々に格納した場合について実験して、処理時間を比較してください。

関連項目:
クラスタの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

14.9 パフォーマンスを考慮したハッシュ・クラスタの使用方法

ハッシュ・クラスタは、ハッシュ関数をそれぞれの行のクラスタ・キー値に適用することによって、表データをグループ分けします。同じクラスタ・キー値を持つすべての行が、ディスク上にまとめて格納されます。アプリケーションでのハッシュ・クラスタの長所と短所を検討してください。特定の表について、ハッシュ・クラスタの場合と、索引付きで単独の場合とで実験を行って処理時間を比較してください。

ハッシュ・クラスタを使用する場合を判断するために、次のガイドラインに従ってください。

- 同じ列または列の組合せを使用する等価条件がWHERE句に含まれる場合、WHERE句を持つSQL文により頻繁にアクセスされる表を格納するために、ハッシュ・クラスタが使用されます。この列または列の組合せをクラスタ・キーとして指定します。

- 即時および将来において挿入する行を含め、特定のクラスタ・キー値を持つすべての行を保持するのに必要な領域を判断できる場合は、ハッシュ・クラスタに表を格納します。

- ハッシュ関数の各値に対応する行が特定の列において昇順でソートされる場合、ソートされたクラスタ・データで操作のレスポンス時間が改善される場合は、ソートされたハッシュ・クラスタを使用します。

- アプリケーションが全表スキャンを実行する場合が多く、表が拡大することを見越してハッシュ・クラスタに大きな領域を割り当てる必要がある場合は、その表をハッシュ・クラスタに格納しません。そのような全表スキャンでは、いくつかのブロックにはほとんど行が含まれていなくても、ハッシュ・クラスタに割り当てられているブロックをすべて読み取る必要があります。表を単独で格納することによって、全表スキャンにより読み取られるブロック数が減少します。

- アプリケーションがクラスタ・キー値を頻繁に修正する場合、ハッシュ・クラスタに表は格納しません。Oracle Databaseでは、行のクラスタ・キー値を変更すると、クラスタを維持するために変更された行を別のブロックに移行することが必要になる場合があるため、非クラスタ化表の値を変更する場合よりも時間がかかる可能性があります。

前述の考慮事項に基づいてハッシングが適切であるかぎり、他の表と頻繁に結合されるかどうかにかかわらず、単一の表をハッシュ・クラスタに格納することは有益です。

関連項目:

- ハッシュ・クラスタの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE CLUSTER文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

15 SQL計画の管理の使用方法

この章では、SQL計画の管理を使用してSQL実行計画を管理する方法について説明します。SQL計画の管理を使用すると、SQL計画の情報を取得、選択および改良するためのコンポーネントが用意されているため、SQL文の実行計画に対する突然の変更によるパフォーマンスの低下を回避できます。

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

- SQL計画ベースラインの概要

- SQL計画ベースラインの管理

- SQLチューニング・アドバイザでのSQL計画ベースラインの使用

- 固定SQL計画ベースラインの使用

- SQL計画ベースラインの表示

- SQL管理ベース

- SQL計画ベースラインのインポートとエクスポート

- ストアド・アウトラインのSQL計画ベースラインへの移行

15.1 SQL計画ベースラインの概要

SQL計画管理は、SQL文の実行計画を時間の経過とともに記録し、評価を行う予防メカニズムです。このメカニズムにより、承認されたSQL文の計画セット、SQL計画ベースラインを構築できます。承認された計画は、適切に機能することが証明されています。

15.1.1 SQL計画ベースラインの目的

SQL計画ベースラインの目的は、データベースの変更にかかわらず、対応するSQL文のパフォーマンスを維持することです。たとえば、次のような変更が発生する場合があります。

- 新しいバージョンのオプティマイザ

- オプティマイザ統計およびオプティマイザ・パラメータに対する変更

- スキーマ定義およびメタデータ定義に対する変更

- システム設定に対する変更

- SQLプロファイルの作成

SQL計画ベースラインでは、索引の削除などによる元に戻せない実行計画の変更を防止することはできません。

Oracle DatabaseのSQLチューニング機能は、オプティマイザが適切なチューニング計画を作成できるようにSQLプロファイルを生成します。ただし、このメカニズムは事後対応であり、データベースに重大な変更が生じた場合は安定したパフォーマンスを保証できません。SQLチューニングは、パフォーマンスの問題が発生して特定された後にしか解決できません。たとえば、計画が変更されてSQL文の負荷が高くなった場合でも、SQLチューニングでは計画の変更が発生した後にのみ問題を解決できます。

SQL計画の管理によってSQLパフォーマンスを向上または維持できる一般的なシナリオは、次のとおりです。

- 新しいバージョンのオプティマイザをインストールするデータベースのアップグレードでは、通常、ほんのわずかなSQL文に対して計画の変更が発生します。ほとんどの計画の変更においてパフォーマンスに変化や向上は見られません。ただし、一部の計画の変更は、パフォーマンスの低下の原因となることがあります。SQL計画ベースラインにより、アップグレードがもたらす低下の可能性を最小限に抑えられます。

- 継続的なシステムおよびデータの変更は、一部のSQL文の計画に影響を及ぼし、パフォーマンスの低下を招く可能性があります。SQL計画ベースラインにより、パフォーマンスの低下を最小限に抑えて安定したSQLパフォーマンスを維持できます。

- 新しいアプリケーション・モジュールのデプロイメントは、新しいSQL文をデータベースに導入することを意味します。アプリケーション・ソフトウェアは、新しい文に対して標準のテスト構成で作成された適切なSQL実行計画を使用できます。システム構成がテスト構成と大幅に異なる場合、データベースはSQL計画ベースラインを時間の経過とともに進化させてパフォーマンスを改善します。

15.1.2 SQL計画ベースラインのアーキテクチャ

SQL計画ベースラインには、次の情報を含む1つ以上の承認済の計画が含まれます。

- ヒント・セット

- 計画のハッシュ値

- 計画に関連する情報

計画履歴は、時間の経過とともにSQL文に対して生成された承認済および未承認の計画のセットです。SQL計画ベースラインには承認された計画のみが含まれるため、ベースラインの計画は計画履歴のサブセットです。たとえば、SQL計画ベースラインの最初の承認計画がオプティマイザによって生成された場合、それ以降の計画は計画履歴の一部になりますが、計画ベースラインには含まれません。

SQL計画ベースラインに計画を追加するプロセスが、計画の改良です。計画の改良の対象とするには、オプティマイザによる計画の使用を有効にしておく必要があります。

図15-1では、SQL計画ベースラインに、1つのSELECT文に対する2つの承認済の計画があります。SQL計画履歴には、適切に機能することが立証されていない他の2つの計画が含まれます。

図15-1 SQL計画ベースラインとSQL計画履歴

SQL管理ベース(SMB)は、データ・ディクショナリの一部で、SYSAUX表領域でSQL計画ベースラインと計画履歴を格納します。SMBはSQLプロファイルも含みます。SMBでは、自動領域管理を使用しています。

15.2 SQL計画ベースラインの管理

SQL計画ベースラインの管理には、次のフェーズがあります。

- SQL計画ベースラインの取得

- SQL計画ベースラインの選択

- SQL計画ベースラインの改良

15.2.1 SQL計画ベースラインの取得

SQL計画ベースラインの取得フェーズでは、データベース管理者が計画を改良(検証)することができるように、計画の変更が検出されて新しい計画が記録されます。そのために、データベースでは各SQL文の計画履歴を管理します。非定型SQL文は繰り返し使用されず、パフォーマンスが低下することはないため、データベースでは繰返し可能なSQL文のみの計画履歴を管理します。

繰返し可能なSQL文を認識するため、データベースはオプティマイザによって評価された様々なSQL文のSQL IDを含む文ログを維持します。データベースは、SQL文がログに記録された後に再度解析または実行されると、そのSQL文を繰返し可能と認識します。

繰返し可能な各SQL文は、オプティマイザによって生成されたすべての計画が格納された計画履歴で管理されます。計画履歴にあるすべての承認済の計画セットがSQL計画ベースラインです。

繰返し可能なSQL文の計画履歴およびSQL計画ベースラインを自動で取得するようにSQL計画ベースラインの取得フェーズを構成できます。または、計画をSQL計画ベースラインとして手動でロードすることもできます。

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

- 計画の自動取得

- 既存計画からのベースラインの作成

15.2.1.1 計画の自動取得

計画の自動取得を有効にすると、オプティマイザが提供する情報を使用して、SQL文の計画履歴が自動的に作成され管理されます。計画履歴には、実行計画を再作成するためにオプティマイザが使用する関連情報(SQLテキスト、アウトライン、バインド変数、コンパイル環境など)が含まれます。

オプティマイザは、SQL文の最初の計画を承認済としてマークし、それを計画履歴およびSQL計画ベースラインとして追加します。計画履歴にはそれ以降のすべての計画が含まれます。SQL計画ベースラインの改良フェーズでは、データベースはパフォーマンスの低下が生じないことが検証された計画をベースラインに追加します。

計画の自動取得を使用可能にするには、OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES初期化パラメータをTRUEに設定します。デフォルトでは、このパラメータはFALSEです。

15.2.1.2 既存計画からのベースラインの作成

SQL計画ベースラインを作成するには、既存のSQL文セットの計画を計画ベースラインとして手動でロードする方法もあります。データベースは手動でロードされた計画のパフォーマンスについて検証しませんが、既存または新規のSQL計画ベースラインに容認された計画として追加します。計画の手動ロードは、計画の自動取得とともに使用するか、自動取得のかわりに使用することもできます。

手動で計画をロードするには、次の操作を実行します。

- SQLチューニング・セットおよびAWRスナップショットからの計画のロード

- 共有SQL領域からの計画のロード

関連項目:
「SQL管理ベース」

15.2.1.2.1 SQLチューニング・セットおよびAWRスナップショットからの計画のロード

SQLチューニング・セットから計画をロードするには、DBMS_SPMパッケージのLOAD_PLANS_FROM_SQLSETファンクションを使用します。次の例では、tset1というSQLチューニング・セットに保存された計画をロードします。

DECLARE
my_plans PLS_INTEGER;
BEGIN
my_plans := DBMS_SPM.LOAD_PLANS_FROM_SQLSET( sqlset_name => 'tset1');
END;
/

自動ワークロード・リポジトリ(AWR)から計画をロードするには、LOAD_PLANS_FROM_SQLSETファンクションを使用する前に、AWRスナップショットに保存された計画をSQLチューニング・セットにロードします。詳細はこの項で後述します。

関連項目:

- 「自動ワークロード・リポジトリの概要」

- 「SQLチューニング・セットの管理」

- LOAD_PLANS_FROM_SQLSETファンクションで使用する追加のパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

15.2.1.2.2 共有SQL領域からの計画のロード

共有SQL領域から計画をロードするには、次のようにDBMS_SPMパッケージのLOAD_PLANS_FROM_CURSOR_CACHEファンクションを使用します。次の例では、sql_idで識別されるSQL文について共有SQL領域で検索された計画がOracle Databaseによってロードされます。

DECLARE
my_plans PLS_INTEGER;
BEGIN
my_plans := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE( sql_id => '99twu5t2dn5xd');
END;
/

共有SQL領域の計画を識別するには、次の要素を使用します。

- SQL識別子(SQL_ID)

- SQLテキスト(SQL_TEXT)

- 次のいずれかの属性

- PARSING_SCHEMA_NAME

- MODULE

- ACTION

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

15.2.2 SQL計画ベースラインの選択

SQL計画ベースラインの選択フェーズでは、格納された計画履歴に基づいて計画の変更を検出し、SQL文セットのパフォーマンスが低下する可能性を回避する計画を選択します。

各SQL文のコンパイル時に、オプティマイザは次のことを行います。

1. コストベースの検索方法を使用してコストが最適な計画を構築します。

2. SQL計画ベースラインで一致する計画を検索します。

3. 一致する計画が見つかったかどうかに応じて、次のいずれかを行います。

- 見つかった場合、オプティマイザは一致する計画を使用します。

- 見つからなかった場合は、オプティマイザはSQL計画ベースラインの容認された計画ごとにコストを評価し、コストが最も低い計画を選択します。

SQL文の計画履歴に一致する計画が見つからなかった場合、最良のコスト計画は新しい計画として追加されます。データベースはこの計画を未承認の計画として計画履歴に追加します。新しい計画は、パフォーマンスを低下させないことが検証されるまで、使用されません。しかし、システムの変更(削除された索引など)によって、承認済の計画がすべて再生不可能になった場合、オプティマイザは最適なコスト計画を選択します。このように、SQL計画ベースラインが存在するために、オプティマイザはSQL文に対して慎重な計画の選択方法を使用することになります。

SQL計画ベースラインを使用可能にするには、OPTIMIZER_USE_SQL_PLAN_BASELINES初期化パラメータをTRUEに設定します(デフォルト)。

15.2.3 SQL計画ベースラインの改良

SQL計画ベースラインの改良フェーズでは、新しい計画のパフォーマンスを評価し、より優れたパフォーマンスの計画をSQL計画ベースラインに組み込みます。

オプティマイザがSQL文の新しい計画を見つけた場合、その計画は未承認の計画として計画履歴に追加されます。データベースはSQL計画ベースラインのパフォーマンスと比較してその計画のパフォーマンスを検証します。承認されていない計画の検証では、承認されていない計画のパフォーマンスとSQL計画ベースラインから選択された計画のパフォーマンスを比較し、承認されていない計画のパフォーマンスの方が良好であることが確認されると、検証が成功します。未承認の計画がパフォーマンスの低下の原因にならないことが検証されると、承認された計画に変更され、ベースラインに統合されます。

この項では、SQL計画ベースラインの改良方法について説明します。この項には、次の項目があります。

- 手動の計画ロードによる計画の改良

- DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEによる計画の改良

15.2.3.1 手動の計画ロードによる計画の改良

既存のSQL計画ベースラインは、共有SQL領域またはSQLチューニング・セットから手動でロードして計画を改良できます。計画を手動でSQL計画ベースラインにロードすると、ロードされた計画は、承認された計画として追加されます。

関連項目:
「既存計画からのベースラインの作成」

15.2.3.2DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEによる計画の改良

PL/SQLファンクションDBMS_SPM.EVOLVE_SQL_PLAN_BASELINEは、オプティマイザが既存の計画ベースラインの計画履歴に追加した新しい計画の改良を試みます。ファンクションにより、新規計画のパフォーマンスの方が対応するSQL計画ベースラインから選択された計画より優れていると判断されると、その新規計画は承認された計画として追加されます。

DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEファンクションの次の例では、SQLハンドルで識別されるSQL文の新しい計画を改良します。このSQLハンドルは文字列形式の一意のSQL識別子です。SQLハンドルは、DBA_SQL_PLAN_BASELINES.SQL_HANDLEの問合せによって見つけられます。

SET SERVEROUTPUT ON
SET LONG 10000
DECLARE
report clob;
BEGIN
report := DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(
sql_handle => 'SYS_SQL_593bc74fca8e6738');
DBMS_OUTPUT.PUT_LINE(report);
END;
/

次の出力は、Oracle Databaseによって計画が正常に改良されたことを示します。

REPORT
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Evolve SQL Plan Baseline Report
--------------------------------------------------------------------------------

Inputs:
-------
SQL_HANDLE = SYS_SQL_593bc74fca8e6738
PLAN_NAME  =
TIME_LIMIT = DBMS_SPM.AUTO_LIMIT
VERIFY     = YES
COMMIT     = YES

Plan: SYS_SQL_PLAN_ca8e6738a57b5fc2
-----------------------------------
Plan was verified: Time used .07 seconds.
Passed performance criterion: Compound improvement ratio >= 7.32.
Plan was changed to an accepted plan.

Baseline Plan      Test Plan     Improv. Ratio
-------------      ---------     -------------
Execution Status:        COMPLETE       COMPLETE
Rows Processed:                40             40
Elapsed Time(ms):              23              8              2.88
CPU Time(ms):                  23              8              2.88
Buffer Gets:                  450             61              7.38
Disk Reads:                     0              0
Direct Writes:                  0              0
Fetches:                        0              0
Executions:                     1              1

-------------------------------------------------------------------------------
Report Summary
-------------------------------------------------------------------------------
Number of SQL plan baselines verified: 1.
Number of SQL plan baselines evolved: 1.

または、DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEを使用して次のものを指定できます。

- 改良する特定の計画の名前

- 改良する計画のリスト

- 値なし
値を指定しないで、SMBで現在容認されていないすべての計画を改良できます。

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

15.3SQLチューニング・アドバイザでのSQL計画ベースラインの使用

SQLチューニング・アドバイザでSQL文をチューニングする場合、アドバイザによって、チューニングされた計画のパフォーマンスが対応するSQL計画ベースラインから選択された計画より優れていると判断されると、SQLプロファイルを受け入れるよう推奨事項が作成されます。SQLプロファイルが受け入れられると、データベースはチューニング済の計画を対応するSQL計画ベースラインに追加します。ただし、SQLチューニング・アドバイザは、計画履歴にある既存の未承認の計画を検証しません。

Oracle Database 11gでは、メンテナンス期間中に自動構成されたタスクによってSQLチューニング・アドバイザが実行されます。このタスクの対象は高負荷SQL文です。高負荷SQL文は、自動ワークロード・リポジトリ(AWR)スナップショットで収集される実行パフォーマンス・データによって識別されます。自動SQLチューニング・タスクは、SQLチューニング・アドバイザによって作成されたSQLプロファイルの推奨事項を実装します。このため、チューニング済の計画は、識別された高負荷SQL文のSQL計画ベースラインに自動的に追加されます。

関連項目:

- 「SQLチューニング・アドバイザによる事後対応のチューニング」

- 「SQLプロファイルの管理」

- 「自動ワークロード・リポジトリの概要」

15.4 固定SQL計画ベースラインの使用

SQL計画ベースラインにFIXED属性がYESに設定された使用可能な計画が1つでも含まれる場合、そのSQL計画ベースラインは固定です。固定SQL計画ベースラインは、任意のSQL文に対応する使用可能な計画のセット(通常は1つの計画)を固定する場合や、固定計画としてアウトライン計画をロードすることにより既存のストアド・アウトラインを移行する場合に使用できます。

固定SQL計画ベースラインに固定されていない計画も含まれる場合、オプティマイザは、固定されていない計画より固定計画を優先します。このため、オプティマイザは、固定されていない計画のコストの方が低い場合でも、最小コストの固定計画を選択します。再生可能な固定計画が存在しない場合は、固定されていない計画のうち最良のものを選択します。

オプティマイザは、固定SQL計画ベースラインに新規計画を追加しません。オプティマイザによって新しい計画が自動的に追加されないため、DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEを実行する際に、固定SQL計画ベースラインは改良されません。ただし、新規計画を共有SQL領域またはSQLチューニング・セットから手動で固定SQL計画ベースラインにロードして改良することができます。

SQLチューニング・アドバイザを使用して固定SQL計画ベースラインを持つSQL文をチューニングする場合、SQLプロファイルの推奨は特別な意味を持ちます。SQLプロファイルが受け入れられると、チューニング済の計画は、固定されていない計画として固定SQL計画ベースラインに追加されます。ただし、前述のとおり、再生可能な固定計画が存在する場合、オプティマイザはチューニング済の計画を使用しません。したがって、SQLチューニングのメリットは実現されない可能性があります。チューニング済の計画を使用可能にするには、FIXED属性をYESに設定し、チューニング済の計画を手動で固定計画に変更します。

15.5 SQL計画ベースラインの表示

特定の文についてSQL計画ベースラインに保存された計画を表示するには、DBMS_XPLANパッケージのDISPLAY_SQL_PLAN_BASELINEファンクションを使用します。次の例では、ハンドル(sql_handle)で指定したSQL文について1つ以上の実行計画を表示します。

SELECT * FROM TABLE(
DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE(
sql_handle=>'SYS_SQL_209d10fabbedc741',
format=>'basic'));

または、計画名(plan_name)を指定して1つの計画を表示することもできます。

このファンクションは、SQL管理ベースに保存された計画の情報を使用して計画の詳細を表示します。この例では、DISPLAY_SQL_PLAN_BASELINEファンクションは、ハンドルSYS_SQL_209d10fabbedc741で指定されたSQL文の実行計画を表示します。

SQL handle: SYS_SQL_209d10fabbedc741
SQL text: select cust_last_name, amount_sold from customers c,
sales s where c.cust_id=s.cust_id and cust_year_of_birth=:yob
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
Plan name: SYS_SQL_PLAN_bbedc741a57b5fc2
Enabled: YES      Fixed: NO      Accepted: NO      Origin: AUTO-CAPTURE
----------------------------------------------------------------------------------
Plan hash value: 2776326082

----------------------------------------------------------------------------------
| Id  | Operation                                | Name                          |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                               |
|   1 | HASH JOIN                                |                               |
|   2 |   TABLE ACCESS BY INDEX ROWID            | CUSTOMERS                     |
|   3 |     BITMAP CONVERSION TO ROWIDS          |                               |
|   4 |     BITMAP INDEX SINGLE VALUE            | CUSTOMERS_YOB_BIX             |
|   5 |    PARTITION RANGE ALL                   |                               |
|   6 |    TABLE ACCESS FULL                     | SALES                         |
----------------------------------------------------------------------------------

----------------------------------------------------------------------------------
Plan name: SYS_SQL_PLAN_bbedc741f554c408
Enabled: YES     Fixed: NO      Accepted: YES       Origin: MANUAL-LOAD
----------------------------------------------------------------------------------
Plan hash value: 4115973128

----------------------------------------------------------------------------------
| Id  | Operation                                | Name                          |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                               |
|   1 |   NESTED LOOPS                           |                               |
|   2 |     NESTED LOOPS                         |                               |
|   3 |       TABLE ACCESS BY INDEX ROWID        | CUSTOMERS                     |
|   4 |         BITMAP CONVERSION TO ROWIDS      |                               |
|   5 |           BITMAP INDEX SINGLE VALUE      | CUSTOMERS_YOB_BIX             |
|   6 |       PARTITION RANGE                    |                               |
|   7 |        BITMAP CONVERSION TO ROWIDS       |                               |
|   8 |          BITMAP INDEX SINGLE VALUE       | SALES_CUST_BIX                |
|   9 |     TABLE ACCESS BY LOCAL INDEX ROWID    | SALES                         |
----------------------------------------------------------------------------------

また、次の例に示すように、DBA_SQL_PLAN_BASELINESビューに対してSELECT文を直接使用してSQL計画ベースラインの情報を表示することもできます。

SELECT SQL_HANDLE, PLAN_NAME, ENABLED, ACCEPTED, FIXED
FROM   DBA_SQL_PLAN_BASELINES;

SQL_HANDLE                PLAN_NAME                      ENA  ACC    FIX
------------------------------------------------------------------------
SYS_SQL_209d10fabbedc741  SYS_SQL_PLAN_bbedc741a57b5fc2  YES  NO     NO
SYS_SQL_209d10fabbedc741  SYS_SQL_PLAN_bbedc741f554c408  YES  YES    NO

関連項目:
DISPLAY_SQL_PLAN_BASELINEファンクションで使用する追加のパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

15.6 SQL管理ベース

SQL管理ベース(SMB)は、SYSAUX表領域にあるデータ・ディクショナリの一部です。SMBには、文のログ、計画履歴、SQL計画ベースラインおよびSQLプロファイルが格納されます。週次で未使用の計画およびログを消去できるようにするには、SMBで自動領域管理を使用します。

また、一連のSQL文について計画をSMBに手動で追加することもできます。この機能を使用すると、新しいバージョンのオプティマイザを使用して計画が低下することを最小限に抑えることができるため、Oracle Database 11gより前のバージョンからデータベースをアップグレードする場合に特に便利です。

SMB全体がSYSAUX内に存在するため、この表領域が使用可能でない場合、データベースはSQL計画管理およびSQLチューニング機能を使用しません。

15.6.1 ディスク領域の使用量

SMBで使用されるディスク領域は、SYSAUX表領域のサイズに基づいた制限と定期的に照合されます。デフォルトでは、SMBの制限はSYSAUXのサイズの10%程度です。この制限の許容範囲は1から50%です。

週に1回のバックグラウンド・プロセスによって、SMBが使用する総領域が測定されます。定義した制限を超過すると、アラート・ログに警告が書き込まれます。次のいずれかの条件を満たすまで、毎週アラートが生成されます。

- SMB領域の上限が上げられた場合

- SYSAUX表領域のサイズが増やされた場合

- SQL管理オブジェクト(SQL計画ベースラインまたはSQLプロファイル)を消去してSMBで使用されるディスク領域が減らされた場合

制限の比率を変更するには、次のようにDBMS_SPMパッケージのCONFIGUREプロシージャを使用します。次の例では、領域の制限が30%に変更されます。

BEGIN
DBMS_SPM.CONFIGURE('space_budget_percent',30);
END;
/

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

15.6.2 消去方針

週次にスケジュールされた消去タスクにより、SQL計画の管理で使用されるディスク領域は管理されます。このタスクは、メンテナンス期間に自動化タスクとして実行されます。

データベースは使用されていない期間が53週を超える計画を消去します。LAST_EXECUTED消去対象は、SMBに保存されたその計画のLAST_EXECUTEDタイムスタンプで識別されます。53週という期間により、年次のSQL処理の間、計画の情報は使用可能であることが保証されます。未使用計画の保存期間は、5から523週(約10年)です。

保存期間を構成するには、次のようにDBMS_SPM PL/SQLパッケージのCONFIGUREプロシージャを使用します。次の例では、保存期間が105週間に変更されます。

BEGIN
DBMS_SPM.CONFIGURE( 'plan_retention_weeks',105);
END;
/

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

15.6.3 SQL管理ベースの構成パラメータ

SQL管理ベースの現在の構成設定は、DBA_SQL_MANAGEMENT_CONFIGビューを使用して表示できます。次の問合せにより、この情報が表示されます。

SELECT PARAMETER_NAME, PARAMETER_VALUE
FROM   DBA_SQL_MANAGEMENT_CONFIG;

PARAMETER_NAME                 PARAMETER_VALUE
------------------------------ ---------------
SPACE_BUDGET_PERCENT                        30
PLAN_RETENTION_WEEKS                       105

15.7 SQL計画ベースラインのインポートとエクスポート

Oracle Databaseでは、Oracle Data Pump ImportおよびOracle Data Pump Exportユーティリティを使用したSQL計画ベースラインのエクスポートとインポートをサポートしています。DBMS_SPMパッケージを使用して、SQL計画ベースラインの圧縮および解凍に使用できるステージング表を定義します。

システム間で一連のSQL計画ベースラインをインポートするには、次のようにします。

1. 元のデータベースで、次のようにCREATE_STGTAB_BASELINEプロシージャを使用してステージング表を作成します。
次の例では、stage1というステージング表が作成されます。

BEGIN
DBMS_SPM.CREATE_STGTAB_BASELINE(
table_name => 'stage1');
END;
/

2. SQL管理ベースからエクスポートするSQL計画ベースラインを、次のようにPACK_STGTAB_BASELINEファンクションを使用してステージング表に圧縮します。
次の例では、ユーザーdba1が作成した有効な計画ベースラインをステージング表stage1に圧縮します。SQL計画ベースラインは、計画名(plan_name)、SQLハンドル(sql_handle)またはその他の計画基準を使用して選択できます。table_nameパラメータは必須です。

DECLARE
my_plans number;
BEGIN
my_plans := DBMS_SPM.PACK_STGTAB_BASELINE(
table_name => 'stage1',
enabled => 'yes',
creator => 'dba1');
END;
/

3. Oracle Data Pump Exportユーティリティを使用して、ステージング表stage1をフラット・ファイルにエクスポートします。

4. このフラット・ファイルをターゲット・システムに送信します。

5. Oracle Data Pump Importユーティリティを使用して、ステージング表stage1をフラット・ファイルからインポートします。

6. ターゲット・システムで、次のようにUNPACK_STGTAB_BASELINEファンクションを使用してSQL計画ベースラインをステージング表からSQL管理ベースに解凍します。
次の例では、ステージング表stage1に格納された固定計画ベースラインがすべて解凍されます。

DECLARE
my_plans number;
BEGIN
my_plans := DBMS_SPM.UNPACK_STGTAB_BASELINE(
table_name => 'stage1',
fixed => 'yes');
END;
/

関連項目:

- DBMS_SPMパッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- データ・ポンプ・エクスポートおよびインポート・ユーティリティの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

15.8 ストアド・アウトラインのSQL計画ベースラインへの移行

この項では、ストアド・アウトラインの移行の概要およびタスクについて説明します。この項では、次の項目について説明します。

- ストアド・アウトラインの移行の概要

- ストアド・アウトラインの移行の準備

- アウトラインの移行によるSQL計画管理機能の使用

- アウトラインの移行でのストアド・アウトライン動作の保存

- ストアド・アウトラインの移行後のフォーローアップ・タスクの実行

15.8.1 ストアド・アウトラインの移行の概要

ストアド・アウトラインは、SQL文のヒントのセットです。ヒントは、文に対する特定の計画を選択するようオプティマイザに指示します。ストアド・アウトラインは、計画の安定性を提供するためのレガシー・テクニックです。

ストアド・アウトラインの移行は、保存されたアウトラインをSQL計画ベースラインに変換するためにユーザーが開始するプロセスです。SQL計画ベースラインは、優れたパフォーマンスを提供することが立証された計画のセットです。

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

- ストアド・アウトラインの移行の目的

- ストアド・アウトラインの移行方法

- ストアド・アウトラインの移行のためのユーザー・インタフェース

- ストアド・アウトラインの移行の基本ステップ

15.8.1.1 ストアド・アウトラインの移行の目的

この項では、計画の安定性を維持し、パフォーマンスの低下を防止するために、ストアド・アウトラインに依存していることが前提となっています。この項の目的は、ストアド・アウトラインからSQL計画ベースラインに安全に移行する便利な方法を提供することです。移行した後、ストアド・アウトラインを使用した場合と同じ計画の安定性を維持し、SQL計画管理フレームワークで提供された拡張機能を使用できます。

この項では、特に、次の問題の対処方法を説明します。

- ストアド・アウトラインは、時間の経過とともに自動的に進化しません。したがって、ストアド・アウトラインは、作成した時点では最適であっても、データベースの変更後に劣悪な計画となってパフォーマンスの低下をもたらす場合があります。

- ストアド・アウトラインのヒントは、無効になる場合があります(たとえば、削除された索引に対する索引ヒントなど)。この場合、データベースでは、無効なヒントを除外してアウトラインを使用し続け、多くの場合、元の計画またはオプティマイザによって生成される現在の最適なコスト計画より劣悪な計画が生じます。

- SQL文では、現在指定されているカテゴリでストアド・アウトラインに定義された計画のみを選択できます。パフォーマンスが向上する場合でも、異なるカテゴリのストアド・アウトラインからの選択、または現在のコストベースの計画は選択できません。

- ストアド・アウトラインは、事後対応型のチューニング・テクニックです。したがって、パフォーマンス問題が発生した後にのみストアド・アウトラインを使用して問題に対処します。たとえば、高負荷になったSQL文の計画を修正するストアド・アウトラインを実装できます。この場合、高負荷になる前に予防的に文をチューニングせずに、ストアド・アウトラインを使用します。

ストアド・アウトライン移行PL/SQL APIは、次のように前述の問題を解決するのに役立ちます。

- SQL計画ベースラインにより、オプティマイザが同じ最適な計画を使用し、時間の経過とともに計画を進化させることができます。
指定したSQL文の新しい計画は、パフォーマンスの低下が生じないことを検証した後にSQL計画ベースラインとして追加できます。

- SQL計画ベースラインは、無効なヒントのために計画が劣悪になることを防止します。
計画ベースラインに格納されたヒントが無効になった場合、その計画は再生可能な計画ではありません。この場合は、代替の再生可能な計画ベースラインまたはオプティマイザによって生成された現在の最適なコスト計画が選択されます。

- 特定のSQL文に対する複数の計画ベースラインを管理できます。
オプティマイザは、特定のSQL文の計画を最適な計画のセットから選択できるため、ストアド・アウトラインでのカテゴリごとに1つの計画といった要件に制限されることはありません。

15.8.1.2 ストアド・アウトラインの移行方法

この項では、ストアド・アウトラインをSQL計画ベースラインに移行する方法について説明します。この情報は、ストアド・アウトラインの移行タスクの実行に関する重要な情報です。

15.8.1.2.1 ストアド・アウトラインの移行ステージ

次の図は、ストアド・アウトラインの移行における主なステージを示しています。

移行プロセスには、次のステージがあります。

1. ユーザーが、移行するアウトラインを指定するファンクションを起動します。

2. データベースでアウトラインが次のように処理されます。

1. データベースが計画ベースラインに必要なアウトラインの情報をコピーします。
データベースでは、情報を直接コピーするか、アウトラインの情報に基づいて計算します。たとえば、SQL文のテキストは両方のスキーマに存在するので、テキストをアウトラインからベースラインにコピーできます。

2. データベースでは、ヒントを再解析してアウトラインにない情報を取得します。
計画のハッシュ値および計画のコストは、アウトラインの既存情報から得られないため、ヒントの再解析が必要です。

3. データベースがベースラインを作成します。

3. データベースでは、初めてSQL計画ベースラインを選択して同じSQL文を実行する際に、不足している情報を取得します。
コンパイル環境および実行統計は、実行する際に、計画ベースラインを解析およびコンパイルするときにのみ取得できます。

これらのフェーズが完了した後、移行が完了します。

15.8.1.2.2 アウトラインのカテゴリとベースライン・モジュール

アウトラインはヒントのセットであり、SQL計画ベースラインは計画のセットです。これらは異なる技術であるため、アウトラインの一部の機能は、ベースラインの機能に正確にマップされません。たとえば、1つのSQL文に、カテゴリの異なる複数のアウトラインが存在する可能性がありますが、現在ベースラインに存在するカテゴリはDEFAULTのみです。

アウトラインのカテゴリは、SQL計画ベースラインのモジュールに相当します。表15-1に、アウトラインのカテゴリがどのようにモジュールにマップするかを説明します。

表15-1 アウトラインのカテゴリ

概念

説明

デフォルト値

アウトライン・カテゴリ

ユーザーにより定義されたストアド・アウトライン・セットの分類。

カテゴリを使用して、ストアド・アウトラインの異なるSQL文を管理できます。たとえば、1つの文が、OLTPカテゴリとDWカテゴリのアウトラインを持つことができます。

各SQL文には、1つ以上のストアド・アウトラインがあります。各ストアド・アウトラインは、1つのカテゴリにのみ分類されます。1つの文にはカテゴリの異なる複数のストアド・アウトラインがありますが、各文には1つのカテゴリにつき1つのストアド・アウトラインのみ存在します。

移行の際に、各アウトライン・カテゴリは、SQL計画ベースライン・モジュールにマップされます。

DEFAULT

ベースライン・モジュール

実行されている高度な機能。

SQL計画ベースラインは、1つのモジュールにのみ所属できます。

アウトラインのSQL計画ベースラインへの移行後、デフォルトのモジュール名はアウトライン・カテゴリ名です。

ベースライン・カテゴリ

SQL計画ベースラインには、カテゴリが1つのみ存在します。それはDEFAULTという名前のカテゴリです。ストアド・アウトラインを移行する際に、SQL計画ベースラインのモジュール名は、ストアド・アウトラインのカテゴリ名に設定されます。

1つの文は、DEFAULTカテゴリに複数のSQL計画ベースラインを持つことができます。

DEFAULT

Oracle Databaseでは、ストアド・アウトラインをSQL計画ベースラインに移行する際に、すべてのアウトライン・カテゴリを同名のSQL計画ベースライン・モジュールにマップします。次の図に示すように、アウトラインのOLTPカテゴリは、ベースラインのOLTPモジュールにマップされます。移行後、DEFAULTは、すべてのSQL計画ベースラインを含むスーパー・カテゴリです。

15.8.1.3 ストアド・アウトラインの移行のためのユーザー・インタフェース

DBMS_SPMパッケージを使用してストアド・アウトラインを移行できます。表15-2に、このパッケージの関連ファンクションを示します。

表15-2 ストアド・アウトラインの移行に関連するDBMS_SPMファンクション

DBMS_SPMファンクション

説明

MIGRATE_STORED_OUTLINE

既存のストアド・アウトラインを計画ベースラインに移行します。

次のいずれかの形式を使用します。

- アウトライン名、SQLテキスト、アウトライン・カテゴリまたはすべてのストアド・アウトラインを指定します。

- アウトライン名のリストを指定します。

ALTER_SQL_PLAN_BASELINE

SQL文に関連付けられた1つの計画またはすべての計画の属性を変更します。

DROP_MIGRATED_STORED_OUTLINE

SQL計画ベースラインに移行されたストアド・アウトラインを削除します。

DBA_OUTLINESビューでMIGRATEDとマークされたストアド・アウトラインを検出して、データベースから削除します。

ストアド・アウトラインおよび計画ベースラインの動作は、初期化パラメータおよびセッション・パラメータで制御できます。表15-3に、関連パラメータを示します。これらのパラメータ設定の相互作用の説明は、表15-5および表15-6を参照してください。

表15-3 ストアド・アウトラインの移行に関連するパラメータ

初期化またはセッション・パラメータ

説明

CREATE_STORED_OUTLINES

セッション中に発行された各問合せのアウトラインを自動的に作成して保存するかどうかを決定します。

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES

繰返し可能なSQL文の自動認識およびそれらの文のSQL計画ベースラインの生成を有効または無効にします。

USE_STORED_OUTLINES

オプティマイザが実行計画の生成にストアド・アウトラインを使用するかどうかを決定します。

注意: これは初期化パラメータではなく、セッション・パラメータです。

OPTIMIZER_USE_SQL_PLAN_BASELINES

SQL管理ベースに格納されたSQL計画ベースラインの使用を有効または無効にします。

データベース・ビューを使用して、ストアド・アウトラインの移行に関連する情報にアクセスできます。表15-4に、主なビューを示します。

表15-4 ストアド・アウトラインの移行に関連するビュー

ビュー

説明

DBA_OUTLINES

データベースのすべてのストアド・アウトラインについて説明します。

MIGRATED列は、アウトラインの移行に関する重要な情報を示します。値は、NOT-MIGRATEDおよびMIGRATEDです。MIGRATEDの場合、ストアド・アウトラインは計画ベースラインに移行されており、使用できません。

DBA_SQL_PLAN_BASELINES

特定のSQL文に関して現在作成されているSQL計画ベースラインの情報を表示します。

ORIGIN列は、計画ベースラインがどのように作成されたかを示します。値がSTORED-OUTLINEの場合、アウトラインの移行によってベースラインが作成されたことを示します。

関連項目:

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

- 初期化パラメータおよびデータベースの固定ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

15.8.1.4 ストアド・アウトラインの移行の基本ステップ

この項では、PL/SQL APIを使用してストアド・アウトラインを移行する場合の基本ステップを示します。基本ステップは、次のとおりです。

1. ストアド・アウトラインの移行の準備をします。
移行の前提条件を確認し、移行後の計画ベースラインの動作を決定します。

「ストアド・アウトラインの移行の準備」を参照してください。

2. 次のいずれかを実行します。

- ベースラインに移行して、SQL計画管理の機能を使用します。
「アウトラインの移行によるSQL計画管理機能の使用」を参照してください。

- ストアド・アウトラインの動作を正確に維持して、ベースラインに移行します。
「アウトラインの移行でのストアド・アウトライン動作の保存」を参照してください。

3. 移行後の確認およびクリーンアップを実行します。
「ストアド・アウトラインの移行後のフォーローアップ・タスクの実行」を参照してください。

15.8.2 ストアド・アウトラインの移行の準備

この項では、ストアド・アウトラインの移行の準備について説明します。

ストアド・アウトラインの移行の準備を行うには、次の手順を実行します。

1. SQL*Plusを起動し、SYSDBA権限またはDBMS_SPMパッケージのEXECUTE権限を持つユーザーとしてログオンします。
たとえば、オペレーティング・システム認証を使用してデータベースにSYSとしてログオンするには、次のコマンドを実行します。

% sqlplus /nolog
SQL> CONNECT / AS SYSDBA

2. データベースのストアド・アウトラインの問合せを実行します。
次の例では、SQL計画ベースラインに移行されていないすべてのストアド・アウトラインを問い合せます。

SELECT NAME, CATEGORY, SQL_TEXT
FROM   DBA_OUTLINES
WHERE  MIGRATED = 'NOT-MIGRATED';

3. どのストアド・アウトラインが次の前提条件を満たして移行の対象となるかを判断します。

- 文は、ランタイムのINSERT AS SELECT文ではない。

- 文は、リモート・オブジェクトを参照していない。

- この文は、プライベート・ストアド・アウトラインではない。

4. すべてのアウトラインを移行するか、指定したストアド・アウトラインか、指定したアウトライン・カテゴリに属するアウトラインかを決定します。
一部のアウトラインを移行する場合は、移行するアウトラインまたはカテゴリをリストします。

5. SQL計画ベースラインに移行するストアド・アウトラインで固定計画を使用するか、非固定計画かを決定します。

- 固定計画
固定計画は、固定されています。固定計画が、計画ベースラインに格納されたヒントを使用して再生可能な計画である場合、オプティマイザは、固定でない計画ベースラインよりも最小コストの固定計画ベースラインを常に選択します。本質的に、固定計画ベースラインは、有効なヒントを含むストアド・アウトラインとして機能します。

計画ベースラインに格納されたヒントに基づいて文を解析し、計画ベースラインと同じ計画ハッシュ値を使用して計画を作成できる場合、固定計画は再生可能です。1つ以上のヒントが無効になった場合、同じ計画ハッシュ値を使用して計画を作成することはできません。この場合、計画は非再生可能です。

ヒントを使用して解析したとき、固定計画を再生できなかった場合、オプティマイザは別の計画を選択します。次のいずれかを選択できます。

- SQL計画ベースラインの別の計画

- オプティマイザによって作成された現在のコストベースの計画

場合によっては、計画が異なるためにパフォーマンスが低下し、SQLチューニングが必要になります。

- 非固定計画
計画ベースラインに固定計画が含まれていない場合、SQL計画管理は、SQL文の計画を選択する際に、計画を同等に検討します。

6. 実際の移行を開始する前に、Oracleデータベースが次の前提条件を満たしていることを確認します。

- データベースはEnterprise Editionである。

- データベースはオープンしている必要があり、一時停止状態であってはならない。

- データベースは、制限付きアクセス(DBA)、読取り専用または移行モードであってはならない。

- OCIが使用可能である。

関連項目:

- 管理者権限の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

15.8.3 アウトラインの移行によるSQL計画管理機能の使用

このタスクの目的は、次のとおりです。

- 移行後、SQL文に対して同じ固定計画を適用するのではなく、SQL計画管理で計画ベースラインのすべての計画から選択できるようにする。

- ベースラインに新しい計画を追加して、データベースの変更があった場合にSQL計画ベースラインが進化できるようにする。

この項のシナリオは、次のことが前提となっています。

- すべてのアウトラインを移行する。
特定のアウトラインを移行する場合、DBMS_SPM.MIGRATE_STORED_OUTLINEファンクションの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- ベースラインのモジュール名と移行するアウトラインのカテゴリ名を同じ名前にする。

- SQL計画を固定しない。
デフォルトでは、生成される計画は固定ではなく、SQL計画管理では、SQL文の計画を選択する際にすべての計画を同等に検討します。この状況により、計画を改良する拡張機能では、SQL文の新しい計画を取得し、パフォーマンスを検証して新しい計画を計画ベースラインに受け入れることが可能になります。

ストアド・アウトラインをSQL計画ベースラインに移行するには、次の手順を実行します。

1. SQL*Plusで、PL/SQLファンクションMIGRATE_STORED_OUTLINEをコールします。
次のPL/SQLブロック・サンプルは、すべてのストアド・アウトラインを固定ベースラインに移行します。

DECLARE
my_report CLOB;
BEGIN
my_report := DBMS_SPM.MIGRATE_STORED_OUTLINE( attribute_name => 'all' );
END;
/

関連項目:

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

- ALTER SYSTEM文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

15.8.4 アウトラインの移行でのストアド・アウトライン動作の保存

このタスクの目標は、ストアド・アウトラインをSQL計画ベースラインに移行し、固定計画ベースラインを作成して元のストアド・アウトラインの動作を保持することです。固定計画は、同じSQL文に対する他の計画よりも優先順位が高くなります。計画が固定されている場合、計画ベースラインは進化できません。計画ベースラインに固定計画が含まれていると、新しい計画は追加されません。

この項では、次のことが前提となっています。

- firstrowというカテゴリのストアド・アウトラインのみを移行する。
DBMS_SPM.MIGRATE_STORED_OUTLINEファンクションの構文およびセマンティクスは、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- ベースラインのモジュール名と移行するアウトラインのカテゴリ名を同じ名前にする。

ストアド・アウトラインを計画ベースラインに移行するには、次の手順を実行します。

1. SQL*Plusで、PL/SQLファンクションMIGRATE_STORED_OUTLINEをコールします。
次のPL/SQLブロック・サンプルは、firstrowカテゴリのストアド・アウトラインを固定ベースラインに移行します。

DECLARE
my_report CLOB;
BEGIN
my_outlines := DBMS_SPM.MIGRATE_STORED_OUTLINE(
attribute_name => 'category',
attribute_value => 'firstrow',
fixed => 'YES' );
END;
/

移行後、SQL計画ベースラインのモジュールはfirstrow、カテゴリはDEFAULTです。

関連項目:

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

- ALTER SYSTEM文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

15.8.5 ストアド・アウトラインの移行後のフォーローアップ・タスクの実行

このタスクの目的は、次のとおりです。

- SQL計画ベースラインに移行されたストアド・アウトラインで、ストアド・アウトラインではなく、計画ベースラインを使用するようにデータベースを構成する。

- ストアド・アウトラインではなく、SQL計画ベースラインを作成して、今後のSQL文で使用する。

- SQL計画ベースラインに移行されたストアド・アウトラインを削除する。

この項では、次のことが前提となっています。

- ストアド・アウトラインの移行の基本ステップが完了している。

- 一部のストアド・アウトラインは、Oracle Database 10gより前のリリースで作成されている可能性がある。
Oracle Database 10gより前のリリースでは、ローカル・ヒント形式のヒントを使用しています。移行後、計画ベースラインに格納されたヒントは、Oracle Database 10gで導入されたグローバル・ヒント形式を使用します。

この項では、ストアド・アウトラインおよび計画ベースラインに関連する初期化パラメータの設定について説明します。OPTIMIZER_CAPTURE_SQL_PLAN_BASELINESおよびCREATE_STORED_OUTLINES初期化パラメータは、ストアド・アウトラインおよびSQL計画ベースラインを作成する方法および時期を指定します。表15-5に、これらのパラメータ間の相互作用を示します。

表15-5 アウトラインおよびベースラインの作成

CREATE_STORED_OUTLINES初期化パラメータ

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES初期化パラメータ

データベースの動作

FALSE

FALSE

SQL文を実行する際に、ストアド・アウトラインもSQL計画ベースラインも作成されません。

FALSE

TRUE

繰返し可能なSQL文の自動認識およびこれらの文のSQL計画ベースラインの生成は有効です。SQL文を実行する際に、その文に対してDEFAULTというカテゴリ名の新規SQL計画ベースラインのみが作成されます(存在しない場合)。

TRUE

FALSE

セッション中に発行された各問合せのアウトラインが自動的に作成され、保存されます。SQL文を実行する際に、その文に対してDEFAULTというカテゴリ名の新規ストアド・アウトラインのみが作成されます(存在しない場合)。

category

FALSE

SQL文を実行する際に、その文に対して指定されたカテゴリ名の新規ストアド・アウトラインのみが作成されます(存在しない場合)。

TRUE

TRUE

セッション中に発行された各問合せのアウトラインが自動的に作成され、保存されます。繰返し可能なSQL文の自動認識およびこれらの文のSQL計画ベースラインの生成も有効です。

SQL文を実行する際に、DEFAULTというカテゴリ名のストアド・アウトラインおよびSQL計画ベースラインが作成されます。

category

TRUE

セッション中に発行された各問合せのアウトラインが自動的に作成され、保存されます。繰返し可能なSQL文の自動認識およびこれらの文のSQL計画ベースラインの生成も有効です。

SQL文を実行する際に、指定されたカテゴリ名のストアド・アウトラインが作成され、DEFAULTというカテゴリ名のSQL計画ベースラインが作成されます。

USE_STORED_OUTLINESセッション・パラメータ(これは初期化パラメータではない)およびOPTIMIZER_USE_SQL_PLAN_BASELINES初期化パラメータは、ストアド・アウトラインおよび計画ベースラインの使用方法を指定します。表15-6に、これらのパラメータの相互作用を示します。

表15-6 ストアド・アウトラインおよびSQL計画ベースラインの使用方法

USE_STORED_OUTLINESセッション・パラメータ

OPTIMIZER_USE_SQL_PLAN_BASELINES初期化パラメータ

データベースの動作

FALSE

FALSE

SQL文の計画を選択する際に、ストアド・アウトラインも計画ベースラインも使用しません。

FALSE

TRUE

SQL文の計画を選択する際に、SQL計画ベースラインのみを使用します。

TRUE

FALSE

SQL文の計画を選択する際に、DEFAULTというカテゴリ名のストアド・アウトラインを使用します。

category

FALSE

SQL文の計画を選択する際に、指定されたカテゴリ名のストアド・アウトラインを使用します。

指定されたカテゴリ名のストアド・アウトラインが存在しない場合は、DEFAULTカテゴリのストアド・アウトラインを使用します(存在する場合)。

TRUE

TRUE

SQL文の計画を選択する際に、計画ベースラインよりもストアド・アウトラインが優先されます。

その文にDEFAULTというカテゴリ名のストアド・アウトラインが存在し、適用可能な場合は、ストアド・アウトラインを適用します。それ以外の場合は、SQL計画ベースラインを使用します。

category

TRUE

SQL文の計画を選択する際に、計画ベースラインよりもストアド・アウトラインが優先されます。

その文に、指定されたカテゴリ名またはDEFAULTというカテゴリ名のストアド・アウトラインが存在し、適用可能な場合は、ストアド・アウトラインを適用します。それ以外の場合は、SQL計画ベースラインを使用します。ただし、ストアド・アウトラインのプロパティがMIGRATEDの場合は、アウトラインを使用せずに対応するSQL計画ベースラインを使用します(存在する場合)。

移行後に、データベースを適切な状態に設定するには、次の手順を実行します。

1. 移行によって、SQL計画ベースラインが作成されたことを確認します。
計画が使用可能であり、承認されていることを確認します。たとえば、次の問合せを入力します(サンプル出力の一部が含まれます)。

SELECT SQL_HANDLE, PLAN_NAME, ORIGIN, ENABLED, ACCEPTED, FIXED, MODULE
FROM   DBA_SQL_PLAN_BASELINES;

SQL_HANDLE                     PLAN_NAME  ORIGIN         ENA ACC FIX MODULE
------------------------------ ---------- -------------- --- --- --- ------
SYS_SQL_f44779f7089c8fab       STMT01     STORED-OUTLINE YES YES NO  DEFAULT
.
.
.

2. オプションとして、SQL計画ベースラインの属性を変更します。
たとえば、次の文を使用して、指定したSQL文のベースラインのステータスをfixedに変更します。

DECLARE
v_cnt PLS_INTEGER;
BEGIN
v_cnt := DBMS_SPM.ALTER_SQL_PLAN_BASELINE(
sql_handle=>'SYS_SQL_f44779f7089c8fab',
attribute_name=>'FIXED',
attribute_value=>'NO');
DBMS_OUTPUT.PUT_LINE('Plans altered: ' || v_cnt);
END;
/

3. 元のストアド・アウトラインのステータスを確認します。
たとえば、次の問合せを入力します(サンプル出力の一部が含まれます)。

SELECT NAME, OWNER, CATEGORY, USED, MIGRATED
FROM   DBA_OUTLINES
ORDER BY NAME;

NAME       OWNER      CATEGORY   USED   MIGRATED
---------- ---------- ---------- ------ ------------
STMT01     SYS        DEFAULT    USED   MIGRATED
STMT02     SYS        DEFAULT    USED   MIGRATED
.
.
.

4. SQL計画ベースラインに移行されたすべてのストアド・アウトラインを削除します。
たとえば、次の文を使用して、DBA_OUTLINESのMIGRATEDステータスのすべてのストアド・アウトラインを削除します。

DECLARE
v_cnt PLS_INTEGER;
BEGIN
v_cnt := DBMS_SPM.DROP_MIGRATED_STORED_OUTLINE();
DBMS_OUTPUT.PUT_LINE('Migrated stored outlines dropped: ' || v_cnt);
END;
/

5. 初期化パラメータを次のように設定します。

- SQL文を実行する際に、計画ベースラインを作成し、ストアド・アウトラインを作成しないように設定します。

- 同等のSQL計画ベースラインが存在しない場合、ストアド・アウトラインのみを使用するように設定します。

たとえば、次のSQL文は、SQL文を実行する際に、ストアド・アウトラインではなくSQL計画ベースラインを作成するようデータベースに指示します。また、allrowsまたはDEFAULTカテゴリのストアド・アウトラインは、それが存在し、SQL計画ベースラインに移行されていない場合にのみ適用するようデータベースに指示しています。それ以外の場合は、かわりにSQL計画ベースラインを適用します。

ALTER SYSTEM
SET CREATE_STORED_OUTLINE = false;

ALTER SYSTEM
SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = true;

ALTER SYSTEM
SET OPTIMIZER_USE_SQL_PLAN_BASELINES = true;

ALTER SESSION
SET USE_STORED_OUTLINES = allrows;

関連項目:

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

- データベースの固定ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

16 SQLチューニングの概要

この章では、チューニングの目的、多くのリソースを消費するSQL文の識別方法および収集する内容の説明と、チューニングの提案を示します。また、SQLテスト・ケースを作成してSQLの問題をトラブルシューティングする方法を解説します。

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

- SQLチューニングの概要

- チューニングの目的

- 高負荷SQLの識別

- 自動SQLチューニング機能

- 効率的なSQL文の開発

- SQLテスト・ケースの作成

関連項目:

- SQLの概要は、『Oracle Database概要』を参照してください。

- データベースの監視方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

16.1 SQLチューニングの概要

SQLチューニングには次の基本手順が含まれます。

- システムで使用可能な過去のSQL実行履歴を検討し、アプリケーションのワークロードおよびシステム・リソースの大部分に関係している高負荷または上位SQL文を識別します。

- これらの文について問合せオプティマイザにより生成される実行計画が適切に実行されるかどうかを確認します。

- 修正アクションを実装し、パフォーマンスの低いSQL文について適切な実行計画を生成します。

システム・パフォーマンスが十分なレベルに達するか、他にチューニングできる文がなくなるまで、前の手順を繰り返します。

16.2 チューニングの目的

システムをチューニングする目的は、システムのエンド・ユーザーへのレスポンス時間を短縮したり、同じ作業の処理に使用されるリソースを削減することです。これには、次の方法があります。

- ワークロードの削減

- ワークロードの均衡化

- ワークロードのパラレル化

16.2.1 ワークロードの削減

一般に、SQLチューニングには、同じワークロードをより効率的に処理する方法を見つけ出すことが含まれます。機能性を変えることなく文の実行計画を変更し、リソース使用量を削減することは可能です。

リソース使用量を削減する方法として、次に2つの例を示します。

1. よく実行する問合せが、表のほんの一部のデータにアクセスする場合は、索引を使用すると、効率的に実行できます。索引を作成すれば、使用するリソースの量を削減できます。

2. 特定のソート順序で戻される10,000行の最初の20行を参照する場合、および索引によって問合せ(およびソート順序)が満たされる場合、最初の20行を参照するために、10,000行にアクセスしてソートする必要はありません。

16.2.2 ワークロードの均衡化

システムは、実ユーザーがシステムに接続している昼間に使用量が最大に達し、夜間には低下する傾向があります。重要でないレポートやバッチ・ジョブを夜間に実行するようにスケジューリングし、昼間の並行性を削減することで、日中は重要なプログラムのためにリソースを解放できます。

16.2.3 ワークロードのパラレル化

多くの場合、大量のデータにアクセスする問合せ(一般的なデータ・ウェアハウス問合せ)は、パラレルに実行できます。並列化は、並行性の低いデータ・ウェアハウスのレスポンス時間の短縮に非常に役立ちます。ただし、並行性の高いOLTP環境の場合は、プログラムの総リソース使用量が増加し、他のユーザーに影響を与える可能性があります。

16.3 高負荷SQLの識別

この項では、高負荷SQL文の識別およびデータ収集を行う手順を説明します。高負荷のSQLとは、Oracleデータベースのパフォーマンスに影響を与える、非効率的なリソース集中型のSQL文です。負荷の高いSQL文を識別するには、次のツールを使用できます。

- 自動データベース診断モニター

- 自動SQLチューニング

- 自動ワークロード・リポジトリ

- V$SQLビュー

- カスタム・ワークロード

- SQLトレース

16.3.1 多くのリソースを消費するSQLの識別

リソース集中型のSQLを識別する最初のステップは、検討する問題の分類です。

- 単一(または少数)のプログラムに固有の問題であるか。

- アプリケーション全体にわたる一般的な問題であるか。

16.3.1.1 特定のプログラムのチューニング

特定のプログラム(GUIまたは3GL)をチューニングする場合、検討するSQLの識別は、プログラム内で実行されたSQLを見るだけの簡単な作業です。Oracle Enterprise Manager(Enterprise Manager)に用意されているツールを使用して、リソースを多く使用するSQL文の識別、EXPLAIN PLANの生成およびSQLパフォーマンスの評価ができます。

SQLを識別できない(たとえば、SQLが動的に生成される)場合は、SQL_TRACEを使用して、実行されたSQLを含むトレース・ファイルを生成し、次にTKPROFを使用して出力ファイルを生成します。

TKPROF出力ファイル内のSQL文は、実行経過時間(exeela)などの各種パラメータで順序付けできるため、通常は、SQL文を経過時間で順序付けする(経過時間が最も長いSQL文をファイルの一番上に置く)ことで識別に利用されます。これにより、ファイル内にSQL文が多数ある場合に、パフォーマンスの低いSQLを識別するジョブの実行が容易になります。

関連項目:

- 第21章「アプリケーション・トレース・ツールの使用方法」

- 第17章「自動SQLチューニング」

16.3.1.2 アプリケーションのチューニング/負荷の軽減

アプリケーション全体のパフォーマンスが悪い場合、またはデータベース・サーバーのCPUまたはI/Oの全体的な負荷を削減する場合、多くのリソースを消費するSQLを識別するには、次の手順を実行します。

1. 調査する時間帯を決定します。通常は、アプリケーションの処理のピーク時間です。

2. その期間の開始時と終了時に、オペレーティング・システムおよびOracle Databaseの統計を収集します。収集する必要のある最小限のOracle Database統計は、ファイルI/O(V$FILESTAT)、システム統計(V$SYSSTAT)、およびSQL統計(V$SQLAREA、V$SQLまたはV$SQLSTATS、V$SQLTEXT、V$SQL_PLANおよびV$SQL_PLAN_STATISTICS)です。

関連項目:

- Oracleデータベース・インスタンスのパフォーマンス・データの収集の方法は、第6章「自動パフォーマンス診断」を参照してください。

- V$SQL_PLAN_MONITORビューの詳細は、「リアルタイムSQL監視」を参照してください。

3. ステップ2で収集したデータを使用して、多くのリソースを使用するSQL文を識別します。候補のSQL文を識別するには、V$SQLSTATSを問い合せる方法が適しています。V$SQLSTATSには、共有プール内のすべてのSQL文に関するリソース使用率の情報が含まれています。V$SQLSTATS内のデータは、リソース使用率で順序付けします。共通リソースの主なものは、次のとおりです。

- バッファ読取り(V$SQLSTATS.BUFFER_GETS。CPU使用率が高い文の場合)

- ディスク読取り(V$SQLSTATS.DISK_READS。I/Oが高い文の場合)

- ソート(V$SQLSTATS.SORTS。ソートが多い場合)

負荷の最も大きいSQL文を識別する方法の1つは、その期間内にSQL文で使用されたリソースを、同じ期間内に使用されたそのリソースの総量と比較することです。BUFFER_GETSの場合、各SQL文のBUFFER_GETSの回数を、期間中のバッファ読取りの総数で除算します。システム内のバッファ読取りの総数はV$SYSSTAT表のsession logical readsの統計情報からわかります。

同様に、V$SQL_STATS.DISK_READSをV$SYSSTAT統計の物理読取りの値で除算すると、システムによって実行されるディスク読取りの総数のうち、文によって実行されるディスク読取りの割合を計算できます。自動ワークロード・リポジトリ・レポートのSQLセクションにはこのデータが含まれているため、割合を手動で計算する必要はありません。

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

候補のSQL文を識別した後、文を調べるために必要な情報を収集し、チューニングします。

16.3.2 識別したSQLに関するデータの収集

CPUが問題となっている場合は、一定期間内に最も多くのBUFFER_GETSを実行した上位のSQL文を調べます。その他の場合は、最も多くのDISK_READSを実行したSQL文から始めます。

16.3.2.1 チューニング中に収集する情報

チューニング・プロセスではまず、基礎となる表と索引の構造を判別します。収集する情報は、次のとおりです。

1. V$SQLTEXTからの完全なSQLテキスト

2. SQL文で参照される表の構造(通常はSQL*Plusの表を記述)

3. 索引(列、列の順序)の定義と、各索引が一意かどうか

4. セグメントのオプティマイザ統計(表ごとの行数、索引列の選択性など)、およびセグメントが最後に分析された日付

5. SQL文で参照されるビューの定義

6. ステップ5で検出された、ビュー定義で参照されている表について、ステップ2、3および4を繰り返します。

7. SQL文(EXPLAIN PLAN、V$SQL_PLANまたはTKPROF出力のいずれかからのもの)のオプティマイザ計画

8. そのSQL文の以前のオプティマイザ計画

注意:
アプリケーション内の主要なSQL文すべてについて、実行計画を生成し、見直すことが重要です。これにより、SQL文が効率よく実行されたときのオプティマイザの実行計画と、そうでないときの計画とを比較できます。データ量の変化などの情報とあわせて比較を行うと、パフォーマンスの低下の原因を正確に識別できます。

16.4 自動SQLチューニング機能

手動SQLチューニング・プロセスはアプリケーション開発者に多数の作業が発生するため、SQLチューニング・プロセスはOracle Databaseの自動SQLチューニング機能により自動化されています。これらの機能は、OLTPタイプとデータ・ウェアハウス・タイプのアプリケーションで同様に機能するように設計されています。

- ADDM

- SQLチューニング・アドバイザ

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

- SQLアクセス・アドバイザ

関連項目:
第17章「自動SQLチューニング」

16.4.1 ADDM

自動データベース診断モニター(ADDM)では、高負荷SQL文など、Oracle Databaseにおいて考えられるパフォーマンス上の問題について、AWRによって収集された情報が分析されます。「自動データベース診断モニターの概要」を参照してください。

16.4.2 SQLチューニング・アドバイザ

SQLチューニング・アドバイザでは、高負荷SQL文として識別されたSQL文が最適化されます。デフォルトでは、Oracle Databaseは問題のあるSQL文を自動的に識別します。また、高負荷SQL文の実行計画を改善する方法を調査し、自動化メンテナンス・タスクとしてシステム・メンテナンス・ウィンドウ中にSQLチューニング・アドバイザを使用してチューニング推奨事項を実装します。パフォーマンスを向上するために、任意のSQLワークロードに対していつでもSQLチューニング・アドバイザを実行できます。「SQLチューニング・アドバイザによる事後対応のチューニング」を参照してください。

16.4.3 SQLチューニング・セット

複数のSQL文をADDM、SQLチューニング・アドバイザまたはSQLアクセス・アドバイザに入力する場合は、SQLチューニング・セット(STS)を作成し、格納します。STSには、SQL文のセットと、関連する実行コンテキストおよび基本実行統計が含まれます。「SQLチューニング・セットの管理」を参照してください。

16.4.4 SQLアクセス・アドバイザ

SQLチューニング・アドバイザに加え、SQLアクセス・アドバイザは、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログについてアドバイスを提供します。SQLアクセス・アドバイザでは、指定のワークロードに関するマテリアライズド・ビュー、マテリアライズド・ビュー・ログおよび索引の適切なセットが推奨されるため、パフォーマンスの目標を達成するのに役立ちます。一般に、マテリアライズド・ビューおよび索引の数と、これらに割り当てられている領域が増えるにつれて、問合せのパフォーマンスが向上します。SQLアクセス・アドバイザでは、領域使用量と問合せパフォーマンスの兼合いが考慮され、新規および既存のマテリアライズド・ビューおよび索引の最もコスト効率の高い構成が推奨されます。「SQLアクセス・アドバイザの使用方法」を参照してください。

16.5 効率的なSQL文の開発

この項では、SQL文の効率を高める方法を説明します。

- オプティマイザ統計の確認

- 実行計画の検討

- SQL文の再構成

- 索引の再構成

- トリガーおよび制約の変更または無効化

- データの再構成

- 実行計画の長期的な保持

- データへのアクセスを最小限に削減

注意:
この項で説明するガイドラインは、頻繁に実行されるSQLの生成に関するものです。この項で推奨されないほとんどの技法は、パフォーマンスが重要でない非定型文または頻繁に実行されないアプリケーションでは使用してもかまいません。

16.5.1 オプティマイザ統計の確認

問合せオプティマイザでは、最適な実行計画の判別時に、表と索引について収集された統計を使用します。これらの統計が収集されなかった場合、または、統計がデータベース内に格納されているデータをすでに反映しなくなっている場合、オプティマイザには最適な計画を生成するための十分な情報がありません。

チェックする内容

- データベース内のいくつかの表に関する統計が必要な場合は、すべての表に関する統計を収集するのが望ましい方法です。このことは、結合を実行するSQL文がアプリケーションに含まれている場合に特に言えます。

- データ・ディクショナリ内のオプティマイザ統計が表と索引内のデータを反映しなくなっている場合は、新しい統計を収集します。ディクショナリ統計が失効しているかどうかをチェックする方法の1つは、表の実際のカーディナリティ(行数)と、DBA_TABLES.NUM_ROWSの値を比較することです。また、述語列に大きなデータの偏りがある場合は、ヒストグラムを使用することを検討してください。

16.5.2 実行計画の検討

OLTP環境でSQL文をチューニング(または作成)する場合、最も選択性の高いフィルタを持つ表から駆動することを目標とします。つまり、次のステップに渡される行を少なくするということです。次のステップが結合である場合は、少数の行しか結合されないということになります。アクセス・パスが最適かどうかを確認してください。

オプティマイザの実行計画を調べる場合は、次の内容を確認します。

- 駆動表には最適なフィルタがある。

- 各ステップの結合順序が、最も少ない行数を次のステップに戻す(つまり、可能な場合、結合順序は最適な未使用フィルタでの処理を反映する必要があります)。

- 結合方法が、それによって戻される行数からみた場合に、適切なものであること。たとえば、文が多数の行を戻す場合、索引でのネステッド・ループ結合は最適でない場合があります。

- データベースでのビューの効率的な使用。SELECT構文のリストを見て、ビューへのアクセスが必要であるかどうかを確認してください。

- 意図しないデカルト積(小さい表の場合も含む)があるかどうか。

- 各表が効率的にアクセスされていること。
SQL文の述語と、表の行数を評価します。大量の行を持つ表の全表スキャンなど、WHERE句に述語を持つ疑わしいアクティビティを探します。そのような選択的な述語に索引が使用されない理由を判別します。

全表スキャンが非効率的というわけではありません。小さい表で全表スキャンを行う場合や、戻される行数に対してよりよい結合方法(たとえば、hash_join)を活用するために、全表スキャンを行うほうが効率がよい場合があります。

これらの条件のうち最適でないものがある場合は、SQL文の再構成や、表で使用できる索引について考慮します。

16.5.3 SQL文の再構成

非効率的なSQL文は、修正するよりも書きなおす方が簡単なことがよくあります。元の文の意図を理解していれば、要件を満たす新しい文を迅速かつ容易に作成できます。

16.5.3.1 ANDと=を使用した条件の組立て

SQLの効率性を高めるには、可能なかぎり等価結合を使用します。変換されない列値に対して等価結合を実行する文は、最も容易にチューニングできます。

16.5.3.2 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 Databaseではこの式を次のように変換します。

AND TO_NUMBER(charcol) = numexpr

次に示すタイプの複合式は使用しないようにしてください。

- col1 = NVL (:b1,col1)

- NVL (col1,-999) = ….

- TO_DATE()、TO_NUMBER()など

ここに示した式によって、オプティマイザは有効なカーディナリティまたは選択性の見積りを割り当てることができなくなります。この結果、全体の計画および結合方法に悪い影響を与えます。

NVL()のかわりに述語を追加します。

たとえば、次のようにします。

SELECT employee_num, full_name Name, employee_id
FROM mtl_employees_current_view
WHERE (employee_num = NVL (:b1,employee_num)) AND (organization_id=:1)
ORDER BY employee_num;

これは次のようにします。

SELECT employee_num, full_name Name, employee_id
FROM mtl_employees_current_view
WHERE (employee_num = :b1) AND (organization_id=:1)
ORDER BY employee_num;

述語をリテラル値でフィルタするためにNUMBER型の列をWHERE句で使用する場合には、WHERE句の述語でTO_NUMBER関数を使用してその索引がNUMBER列で使用できるようにしてください。たとえば、numcolがNUMBER型の列である場合、numcol=TO_NUMBER('5')を含むWHERE句によってデータベースでnumcolの索引を使用できるようになります。

問合せが2つの表を結合し、結合列が異なるデータ型(たとえば、NUMBERとVARCHAR2)を持つ場合には、Oracle Databaseにおいてデータ型の変換が暗黙的に行われます。たとえば、結合条件がvarcol=numcolであるとすると、データベースはこの条件をTO_NUMBER(varcol)=numcolに暗黙的に変換します。索引がvarcol列に存在する場合、型変換を明示的にvarcol=TO_CHAR(numcol)に設定して、データベースが索引を使用できるようにします。

関連項目:
ファンクション索引の詳細は、第14章「索引およびクラスタの使用方法」を参照してください。

16.5.3.3 特定のタスクに対する専用のSQL文の作成

SQLは、手続き型言語ではありません。1つのSQLを使用して様々なことを実行すると、通常は各タスクに最適でない結果が生じます。SQLを使用して様々なタスクを実行する場合は、1つの文にパラメータを指定して異なるタスクを実行するのではなく、様々な文を作成してください。

注意:
Oracle FormsとOracle Reportsは、PL/SQL(トリガーまたはプログラム・ユニット)を使用してアプリケーション・ロジックをコード化するための強力な開発ツールです。FormsまたはReportsで複雑なロジックを処理することによって、SQL文の複雑さを減らすことができます。また、規模の大きな単一の複雑なSQL文のかわりに、少数のSQL文を実行するサーバー側のPL/SQLパッケージを起動することもできます。このパッケージはサーバー側のユニットであるため、クライアントとデータベースの間のラウンドトリップやネットワークの通信量の問題は発生しません。

通常、異なるタスクには個別のSQL文を作成するほうが適していますが、使用するSQL文を1つにする必要がある場合は、UNION ALL演算子を使用することによって、非常に複雑な文を多少簡略化できます。

最適化(実行計画の決定)は、問合せに代入される値をデータベースが認識する前に行われます。したがって、実行計画はそれらの値が何であるかに依存しません。たとえば、次のようにします。

SELECT info
FROM tables
WHERE ...

AND somecolumn BETWEEN DECODE(:loval, 'ALL', somecolumn, :loval)
AND DECODE(:hival, 'ALL', somecolumn, :hival);

この例では、データベースはsomecolumn列に対して索引を使用できません。この列を含む式が、BETWEENの両辺で同じ列を使用するためです。

このことは、選択性の高い、索引作成可能な他の条件が別にあって、それを使用して駆動表にアクセスできる場合には問題になりません。ただし、これにあてはまらない場合もよくあります。この例のような条件で索引を使用することは多くありますが、:lovalなどの値を、あらかじめ知っておく必要があります。この情報があれば、索引を使用できないALLのケースを除外できます。

:lovalと:hivalに実際の値が指定されたときに索引を使用する場合(:lovalと:hivalの間が狭く、多くの場合等しいことが期待できる場合)は、この例を論理的に等しい次の形式にリライトできます。

SELECT /* change this half of UNION ALL if other half changes */ info
FROM   tables
WHERE  ...

AND    somecolumn BETWEEN :loval AND :hival
AND   (:hival != 'ALL' AND :loval != 'ALL')

UNION ALL
SELECT /* Change this half of UNION ALL if other half changes. */ info
FROM   tables
WHERE  ...

AND (:hival = 'ALL' OR :loval = 'ALL');

この新しい問合せでEXPLAIN PLANを実行した場合、望ましい実行計画と望ましくない実行計画の両方が得られるように思われます。しかし、UNION ALLの前半と後半のどちらを実行するかを決めるためにデータベースが最初に評価する条件は、:hivalと:lovalがALLであるかどうかの複合条件です。データベースは、問合せの前半と後半のどちらかの実行計画から実際に行を取得する前に、この条件を評価します。

UNION ALL問合せの一方に関して条件がfalseであれば、その部分はそれ以上評価されません。与えられている値に関して最適な実行計画の部分のみが実際に実行されます。:hivalと:lovalに関する最終条件はどちらか一方のみがtrueであることが保証されているので、実際に行を戻すのはUNION ALLの半分のみです。(UNION ALL内のALLは、この排他性により論理的に有効です。これにより、問合せの両半分の結果から重複行を除外するためにコストの高いソートを実行することなく、計画を実行できます。)

16.5.4 ヒントによるアクセス・パスおよび結合順序の制御

オプティマイザのアプローチと目標の設定および問合せオプティマイザの代表的な統計の収集によって、オプティマイザの選択を変えることができます。特定のアプリケーション・データに関して、オプティマイザよりも多くの情報を持つアプリケーション設計者であれば、より効率よくSQL文を実行する方法を選択できる場合があります。SQL文のヒントを使用すれば、文を実行する方法をオプティマイザに指示できます。

/*+FULL */などのヒントは、アクセス・パスを制御します。たとえば、次のようにします。

SELECT /*+ FULL(e) */ e.last_name
FROM employees e
WHERE e.job_id = 'CLERK';

関連項目:
第11章「問合せオプティマイザ」および第19章「オプティマイザ・ヒントの使用方法」

結合順序は、パフォーマンスに大きな影響を与えることがあります。SQLのチューニングの主な目的は、結果に影響しない不要な行にアクセスする作業を回避することです。このことから次の3つの一般ルールが導かれます。

- 索引を介して必要な行を取得するほうが効率的な場合には、全表スキャンを避けてください。

- 100行をフェッチする別の索引を使用できる場合には、駆動表から10,000行をフェッチする索引を使用するようなことは避けてください。

- 結合順序の後ろへ行くほど結合する行が少なくなるように結合順序を選択してください。

次の例は、結合順序を効果的にチューニングする方法を示しています。

SELECT info
FROM taba a, tabb b, tabc c
WHERE a.acol BETWEEN 100 AND 200

AND b.bcol BETWEEN 10000 AND 20000
AND c.ccol BETWEEN 10000 AND 20000
AND a.key1 = b.key1
AND a.key2 = c.key2;

1. 駆動表と駆動索引(存在する場合)を選択します。
前述の例における最初の3つの条件は、それぞれ1つの表にのみ適用されるフィルタ条件です。最後の2つの条件は結合条件です。

フィルタ条件は、駆動表と駆動索引の選択を左右します。一般に、表内の排除される部分の比率が最も高くなるフィルタ条件を含む表は駆動表です。この例では、100から200の範囲はacolの範囲に比べて狭く、10000から20000の範囲は相対的に大きいため、tabaは駆動表であり、他はすべて同じです。

ネステッド・ループ結合の場合、結合はすべて結合索引を介して行う必要があります。この結合索引は、主キーまたは外部キーに付けられているもので、その表を結合ツリー内のそれより前にある表に結びつけるために使用します。駆動表を除いて、非結合条件にこの結合索引を使用することはほとんどありません。そのため、tabaを駆動表として選択すると、b.key1とc.key2の索引を使用してtabbとtabcをそれぞれ駆動します。

2. 未使用の最適なフィルタを最初に駆動する最適な結合順序を選択します。
最適な未使用フィルタを持つ表に先に結合することで、その後の結合の作業を削減できます。したがって、「bcol BETWEEN ...」が「ccol BETWEEN ...」よりも限定的な(表示される行をより高い比率で排除する)場合は、tabbをtabcよりも前に結合すると、最後の結合が容易になります(行数が少なくなります)。

3. ORDEREDまたはSTARヒントを使用して、結合順序を強制的に設定できます。

関連項目:
「結合順序のヒント」

16.5.4.1 ビューを管理するときの注意

ビューの結合、ビューへの外部結合、および既存ビューの新規目的への再利用に対しては、注意が必要です。

16.5.4.1.1 複合ビューを結合するときの注意

複合ビューへの結合、特に、ある複合ビューから別の複合ビューへの結合はお薦めできません。そのような結合を行うと、多くの場合、ビュー全体がインスタンス化され、ビュー・データに対して問合せが行われる結果になります。

たとえば、次の文は従業員および部門をリストするビューを作成します。

CREATE OR REPLACE VIEW emp_dept
AS
SELECT d.department_id, d.department_name, d.location_id,
e.employee_id, e.last_name, e.first_name, e.salary, e.job_id
FROM  departments d
,employees e
WHERE e.department_id (+) = d.department_id;

次の問合せは指定した状態の従業員を検索します。

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

16.5.4.1.2 ビューの再利用禁止

ある用途のために作成したビューを他の用途に使用することは、不適切な場合があるため注意してください。ビューから問合せを行うと、データを戻すために、そのビューに関連するすべての表がアクセスされます。ビューを再利用する前に、ビュー内のすべての表にアクセスしてデータを戻す必要があるかどうかを判別してください。その必要がない場合は、ビューを使用しないでください。かわりに、実表を使用するか、必要に応じて新しいビューを定義してください。その目的は、必要なデータを戻すために参照する表およびビューの数を最小限にすることにあります。

次の例を見てください。

SELECT department_name
FROM emp_dept
WHERE department_id = 10;

ビュー全体ではまず、employees表とdepartments表の結合によりインスタンス化され、次にデータが集計されます。ただし、department_nameとdepartment_idは、departments表から直接取得できます。emp_deptビューを問い合せてこの情報を取得することは非効率的です。

16.5.4.1.3 副問合せのネストを解除するときの注意

副問合せのネストの解除によって、副問合せ本体が解除され、その副問合せが含まれている文の本体にマージされます。これにより、オプティマイザは、アクセス・パスと結合を評価するときに、副問合せと本体の両方をいっしょに考慮させてしまいます。

関連項目:
副問合せのネスト解除における危険性の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

16.5.4.1.4 ビューへの外部結合を実行するときの注意

複数表のビューに対する外部結合の場合、等価述語が定義されていれば、問合せオプティマイザ(リリース8.1.6以上)は外部結合列から駆動できます。

ビュー内での外部結合は、外部結合のパフォーマンスに与える影響が読めないため、問題が発生しやすくなります。

16.5.4.2 中間結果の格納

中間の表、すなわちステージング表がリレーショナル・データベース・システムで比較的よく利用されるのは、それらの表に中間結果を一時的に格納するためです。これは、多くのアプリケーションで有効ですが、これらの作成にさらなるリソースが必要になります。したがって、これらの表による利益が、作成のコストに見合うものかどうかを常に考慮してください。ステージング表は、その情報が何回も再利用されない場合は、作成しないようにしてください。

他の考慮事項

- ステージング表に中間結果を格納することで、アプリケーション・パフォーマンスを向上できる場合があります。一般に、中間結果が、引き続きその後の複数の問合せで使用可能であれば、その結果をステージング表に格納する価値があります。中間結果の再利用により、複雑な文を使用して何度もデータの取得を行わないことの利点は、中間結果をマテリアライズするコストより優れています。

- 長く複雑な問合せは、理解し、最適化することが困難です。ステージング表を使用することで、複雑なSQL文をいくつかの小さい文に分解でき、このとき、各ステップの結果を格納します。

- マテリアライズド・ビューを使用することを検討してください。マテリアライズド・ビューは、ファクト表やディメンション表からの集計データや結合データを格納する、あらかじめ計算済の表です。

関連項目:
マテリアライズド・ビューの使用方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

16.5.5 索引の再構成

多くの場合は、索引を再構成すると、パフォーマンスが向上します。これには、次の内容が含まれます。

- 非選択的な索引を削除して、DMLの速度を上げます。

- パフォーマンス重視のアクセス・パスの索引を作成します。

- 既存の連結索引で列を並び換えることを考慮します。

- 索引に列を追加して、選択性を向上します。

索引を万能策として使用しないでください。アプリケーション開発者は、索引を多く作成すればパフォーマンスが改善されると考える場合があります。1人のプログラマが適切に索引を作成すれば、アプリケーションのパフォーマンスは十分に改善される可能性があります。ただし、50人の開発者が別々に索引を作成すると、アプリケーションのパフォーマンス改善は望めません。

16.5.6 トリガーおよび制約の変更または無効化

トリガーを使用すると、システムのリソースが消費されます。トリガーを多用すると、パフォーマンスに悪影響を及ぼす場合があります。この場合、トリガーを変更または無効にする必要があります。

16.5.7 データの再構成

索引と文を再構成した後で、データの再構成について検討します。

- 導出された値を用意しておきます。レスポンス重視のコードでは、GROUP BYの使用を回避します。

- データ設計を検討します。変更によりパフォーマンスの向上が見込める場合は、システムの設計を変更します。

- 必要に応じて、パーティション化を考慮します。

16.5.8 実行計画の長期的な保持

格納されている統計またはSQL計画ベースラインを使用すると、SQL文の既存の実行計画を長期的に保持できます。表のオプティマイザの統計を格納すると、その表を参照するすべてのSQL文にその統計が適用されます。実行計画をSQL計画ベースラインとして格納すると、SQL文セットに対する計画が保持されます。SQL文で統計およびSQL計画ベースラインが使用可能な場合、オプティマイザは最初に、コストベースの検索方法を使用してコストが最適な計画の構築を試み、次にSQL計画ベースラインで一致する計画を検索します。一致が見つかった場合、オプティマイザはこの計画を使用します。それ以外の場合は、SQL計画ベースラインの承認された各計画のコストを評価し、コストが最も低い計画を選択します。

関連項目:

- 第15章「SQL計画の管理の使用方法」

- 第13章「オプティマイザ統計の管理」

16.5.9 データへのアクセスを最小限に削減

アプリケーションから各行へのアクセスを、可能なかぎり1回のみにします。そうすることで、ネットワークの通信量が削減され、データベースの負荷が軽減されます。次を実行することを考慮してください。

- CASE式を使用した複数のスキャンの組合せ

- RETURNING句を持つDMLの使用

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

16.5.9.1 CASE式を使用した複数のスキャンの組合せ

多くの場合、様々な表セットで異なった集計を行う必要があります。通常、この目的を達成するには、表に複数のスキャンを実行しますが、単一のスキャンですべての集計を計算すると簡単です。n-1回のスキャンを排除することで、パフォーマンスが大幅に向上する可能性があります。

複数のスキャンを1つのスキャンに結合するには、各スキャンのWHERE条件を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;

これは、きわめて単純な例です。範囲が重なっていたり、集計の関数が異なっていることもあります。

16.5.9.2 RETURNING句を持つDMLの使用

適時、INSERT、UPDATEまたはDELETE...RETURNINGを使用して、1回のコールでデータを選択および変更します。この技法は、データベースのコール回数を減らすことでパフォーマンスを改善します。

関連項目:
INSERT文、UPDATE文、およびDELETE文の構文については、『Oracle Database SQL言語リファレンス』を参照してください。

16.5.9.3 1つの文での必要なすべてのデータの変更

可能であれば、配列処理を使用します。これは、バインド変数値の配列をOracle Databaseに渡して繰返し実行することを意味します。これは、あるセットの複数行が同じ操作の対象である場合の繰り返し処理に適しています。

たとえば、次のようにします。

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を発行すると、データベースは、1回のDELETE文で複数の行を自動的に削除します。

関連項目:
分散問合せのチューニング方法の詳細は、『Oracle Database管理者ガイド』またはOracle Database Heterogeneous Connectivityユーザーズ・ガイドを参照してください。

16.6 SQLテスト・ケースの作成

多くのSQL関連の問題では、再現可能なテスト・ケースを取得することで問題の解決が容易になります。Oracle Database 11gリリース2(11.2)以上には、SQLテスト・ケース・ビルダーが含まれます。このSQLテスト・ケース・ビルダーは、問題とその問題が発生した環境に関する情報を可能なかぎり収集および再現するという、多少困難で時間のかかるプロセスを自動化します。

SQLテスト・ケース・ビルダーは、別のデータベースで問題を再現およびテストできるように、SQL関連の問題に関する情報と、その問題が発生した正確な環境を取得します。テスト・ケースの準備ができたら、ユーザーは問題をOracleサポートにアップロードし、サポート担当者にその問題の再現とトラブルシューティングを依頼できます。

SQLテスト・ケース・ビルダーによって収集される情報には、実行された問合せ、表および索引の定義(実際のデータではありません)、PL/SQLファンクション、プロシージャおよびパッケージ、オプティマイザ統計、初期化パラメータ設定が含まれます。

16.6.1 テスト・ケースの作成

SQLテスト・ケース・ビルダーには、Enterprise Managerからアクセスできます。または、DBMS_SQLDIAGパッケージを使用して手動でもアクセスできます。

16.6.1.1 Enterprise ManagerからのSQLテスト・ケース・ビルダーへのアクセス

Enterprise ManagerからSQLテスト・ケース・ビルダーにアクセスできるのは、SQLインシデントが発生した場合のみです。SQL関連の問題は、SQLインシデントと呼ばれ、各SQLインシデントはインシデント番号で識別されます。SQLテスト・ケース・ビルダーには、Enterprise Managerの「サポート・ワークベンチ」ページからアクセスできます。

「サポート・ワークベンチ」ページには、次のいずれかの方法でアクセスできます。

- Enterprise Managerの「データベース」の「ホーム」ページで、「診断サマリー」の下にある「アクティブなインシデント」(アクティブ・インシデントの数を示す)へのリンクをクリックします。これにより、インシデントがリストされた表を含む「サポート・ワークベンチ」ページが表示されます。

- 「関連リンク」の「アドバイザ・セントラル」をクリックすると、「アドバイザ・セントラル」ページが表示されます。次に、「SQLアドバイザ」をクリックしてから「ここをクリックしてサポート・ワークベンチに移動します。」をクリックすると、「サポート・ワークベンチ」ページが表示されます。

「サポート・ワークベンチ」ページから、次のようにSQLテスト・ケース・ビルダーにアクセスします。

1. インシデントIDをクリックすると、その特定のインシデントに関する問題の詳細が表示されます。

2. 次に、「調査と解決」セクションで「Oracleサポート」をクリックします。

3. 「追加的なダンプとテスト・ケースの生成」をクリックします。

4. 特定のインシデントについて、「タスクに移動」列のアイコンをクリックし、SQLテスト・ケース・ビルダーを実行します。
SQLテスト・ケース・ビルダーの出力は、すべての必須オブジェクトおよび環境を再生成するのに必要なコマンドを含むSQLスクリプトです。SQLテスト・ケース・ビルダーは、次の場所にファイルを格納します。inc_numはインシデント番号を、run_numは実行番号を指します。

$ADR_HOME/incident/incdir_inc_num/SQLTCB_run num

たとえば、有効な出力ファイル名は次のようになります。

$ORACLE_HOME/log/diag/rdbms/dbsa/dbsa/incident/incdir_2657/SQLTCB_1

16.6.1.2 DBMS_SQLDIAGを使用したSQLテスト・ケース・ビルダーへのアクセス

SQLテスト・ケース・ビルダーは、DBMS_SQLDIAGパッケージを使用して手動で起動することもできます。このパッケージは、SQLテスト・ケース・ビルダー用の様々なサブプログラムで構成されます。表16-1に、そのサブプログラムの一部を示します。

表16-1 DBMS_SQLDIAGのSQLテスト・ケース・ビルダーのプロシージャ

プロシージャ名

機能

EXPORT_SQL_TESTCASE

SQLテスト・ケースを生成します。

EXPORT_SQL_TESTCASE_DIR_BY_INC

引数で渡されたインシデントIDに対応するSQLテスト・ケースを生成します。

EXPORT_SQL_TESTCASE_DIR_BY_TXT

引数で渡されたSQLテキストに対応するSQLテスト・ケースを生成します。

このパッケージと、そのすべてのプロシージャおよびパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

17 自動SQLチューニング

この章では、Oracle Databaseの自動SQLチューニング機能について説明します。自動SQLチューニングにより、複雑で繰返しの多い時間のかかる手動プロセスを自動化できます。

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

- 自動チューニング・オプティマイザの概要

- 自動SQLチューニング・アドバイザの管理

- SQLチューニング・アドバイザによる事後対応のチューニング

- SQLチューニング・セットの管理

- SQLプロファイルの管理

- SQLチューニング・ビュー

関連項目:
Oracle Enterprise Manager(Enterprise Manager)での自動SQLチューニング機能の使用方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

17.1 自動チューニング・オプティマイザの概要

Oracle Databaseでは、オプティマイザを使用して、発行されたSQL文の実行計画を生成します。オプティマイザは、次のモードで動作します。

- 標準モード
オプティマイザは、SQLをコンパイルして実行計画を生成します。標準モードでは、大多数のSQL文に対して妥当な実行計画が生成されます。標準モードでは、オプティマイザは通常はミリ秒単位の厳密な時間的制約に従って動作します。

- チューニング・モード
オプティマイザは、追加の分析を実行して、標準モードで生成された計画をさらに改善できるかどうかをチェックします。オプティマイザの出力は、実行計画ではなく、さらに優れた計画を生成するための一連のアクションと、その理論的根拠および予測されるメリットを示します。チューニング・モードで実行する場合、オプティマイザは自動チューニング・オプティマイザと呼ばれます。

チューニング・モードのオプティマイザでは、1つの文のチューニングに数分かかることがあります。問合せのハード解析を行うたびに自動チューニング・オプティマイザを起動すると、多くの時間およびリソースが消費されます。自動チューニング・オプティマイザは、データベースに重要な影響を及ぼす複雑で負荷の高いSQL文向けに設計されています。

自動データベース診断モニター(ADDM)は、SQLチューニングの最適な候補となる負荷の高いSQL文を事前に識別します(第6章「自動パフォーマンス診断」を参照)。自動SQLチューニング機能は、問題のあるSQL文を自動的に識別し、自動メンテナンス・タスクとしてシステム・メンテナンス期間中にチューニング推奨事項を実装します。

自動チューニング・オプティマイザは、次のタイプのチューニング分析を実行します。

- 統計分析

- SQLプロファイリング

- アクセス・パス分析

- SQL構造分析

- 代替計画分析

17.1.1 統計分析

オプティマイザは、実行計画を生成する際にオブジェクトの統計に依存します。これらの統計が失効しているか統計情報がない場合、オプティマイザは必要な情報を得られないため、不適切な実行計画が生成される可能性があります。自動チューニング・オプティマイザは、問合せオブジェクトごとに統計の欠落や失効がないかどうかをチェックし、次の2つのタイプの出力を生成します。

- 統計が失効または欠落しているオブジェクトに関して関連統計を収集するための推奨事項
オプティマイザ統計は自動的に収集されリフレッシュされるため、この問題が発生するのは自動オプティマイザ統計収集が無効になっている場合のみです。「自動オプティマイザ統計収集の管理」を参照してください。

- 統計が欠落しているオブジェクトに関する補足統計と、統計が失効しているオブジェクトに関する統計調整ファクタ

この補足情報は、SQLプロファイルと呼ばれるオブジェクトに格納されます。

17.1.2 SQLプロファイリング

SQLプロファイルは、SQL文に固有の補足情報です。概念上、SQL文に対するSQLプロファイルの役割は、表または索引に対する統計情報の役割と同じです。データベースでは、補足情報を使用して実行計画を改善できます。

関連項目:
「SQLプロファイルの管理」

17.1.3 アクセス・パス分析

アクセス・パスは、データベースからデータを取り出すための手段です。たとえば、索引を使用する問合せと、全表スキャンを使用する問合せでは、使用するアクセス・パスが異なります。

索引を使用すると、大規模な表の全体スキャンを実行する必要性が減少し、SQL文のパフォーマンスを大幅に改善できます。効率的な索引付けは、一般的なチューニング・テクニックです。自動チューニング・オプティマイザは、新しい索引によって、問合せパフォーマンスを大幅に改善できるかどうかを調査します。改善できる場合は、アドバイザにより索引作成が推奨されます。

自動チューニング・オプティマイザでは、索引に関する推奨事項がSQL全体のワークロードにどのように影響するかは分析されないため、典型的なSQLワークロードを持つSQL文に対してSQLアクセス・アドバイザを実行することも推奨されます。SQLアクセス・アドバイザは、索引作成がSQL全体のワークロードに与える影響を調べてから、推奨事項を作成します。「自動SQLチューニング機能」を参照してください。

17.1.4 SQL構造分析

自動チューニング・オプティマイザは、パフォーマンスを低下させる可能性のあるSQL文の構造の一般的な問題を識別します。たとえば、構文、セマンティクスまたは設計上の問題があります。いずれの場合も、自動チューニング・オプティマイザは、文の再構成に関連する提案を行います。提案される代替策は、元の文と類似していますが同じではありません。

たとえば、オプティマイザから、UNION演算子をUNION ALLで置き換えたり、NOT INをNOT EXISTSで置き換えるように提案される場合があります。このとき、提案された事項が、状況に適用可能かどうかを判断します。たとえば、スキーマの設計上、重複が発生する可能性がない場合は、UNION ALL演算子の方が、UNION演算子よりはるかに効率的です。このように変更するには、データ・プロパティを十分に理解し、実装前に慎重に考慮する必要があります。

17.1.5 代替計画分析

SQLチューニング・アドバイザは、SQL文をチューニングする際に、リアルタイムおよび履歴パフォーマンス・データに文の代替実行計画があるかどうかを検索します。最初の計画以外の計画が存在する場合、SQLチューニング・アドバイザは、代替計画が見つかったことを報告します。

SQLチューニング・アドバイザは、代替実行計画を検証し、再生可能でない計画がある場合は通知します。再生可能な代替計画が見つかった場合、SQL計画ベースラインを作成して、将来これらの計画を選択するようオプティマイザに指示できます。

例17-1に、SELECT文の代替計画の検出を示します。

例17-1 代替計画の検出

2- Alternative Plan Finding
---------------------------
Some alternative execution plans for this statement were found by searching
the system's real-time and historical performance data.

The following table lists these plans ranked by their average elapsed time.
See section "ALTERNATIVE PLANS SECTION" for detailed information on each
plan.

id plan hash  last seen            elapsed (s)  origin          note
-- ---------- -------------------- ------------ --------------- ----------------
1 1378942017  2009-02-05/23:12:08        0.000 Cursor Cache    original plan
2 2842999589  2009-02-05/23:12:08        0.002 STS

Information
-----------
- The Original Plan appears to have the best performance, based on the
elapsed time per execution.  However, if you know that one alternative
plan is better than the Original Plan, you can create a SQL plan baseline
for it. This will instruct the Oracle optimizer to pick it over any other
choices in the future.
execute dbms_sqltune.create_sql_plan_baseline(task_name => 'TASK_XXXXX',
object_id => 2, task_owner => 'SYS', plan_hash => xxxxxxxx);

例17-1では、SQLチューニング・アドバイザにより、2つの計画が見つかりました(共有SQL領域とSQLチューニング・セットに各1個)。共有SQL領域の計画は、最初の計画と同じです。

SQLチューニング・アドバイザは、最初の計画の経過時間が代替計画よりも劣る場合のみ代替計画を推奨します。この場合、SQLチューニング・アドバイザは、パフォーマンスの最も優れている計画で、SQL計画ベースラインを作成するよう推奨します。例17-1では、代替計画よりも最初の計画の方がパフォーマンスが優れているため、SQLチューニング・アドバイザは代替計画の使用を推奨していません。

例17-2では、SQLチューニング・アドバイザ出力の代替計画セクションに、最初の計画と代替計画が含まれ、それらのパフォーマンスが要約されています。最も重要な統計は、経過時間です。最初の計画では索引が使用されていますが、代替計画では全表スキャンが使用され、経過時間が.002秒だけ増加しています。

例17-2 代替計画セクション

Plan 1
------

Plan Origin                 :Cursor Cache
Plan Hash Value             :1378942017
Executions                  :50
Elapsed Time                :0.000 sec
CPU Time                    :0.000 sec
Buffer Gets                 :0
Disk Reads                  :0
Disk Writes                 :0

Notes:
1. Statistics shown are averaged over multiple executions.
2. The plan matches the original plan.

--------------------------------------------
| Id  | Operation            | Name        |
--------------------------------------------
|   0 | SELECT STATEMENT     |             |
|   1 |  SORT AGGREGATE      |             |
|   2 |   MERGE JOIN         |             |
|   3 |    INDEX FULL SCAN   | TEST1_INDEX |
|   4 |    SORT JOIN         |             |
|   5 |     TABLE ACCESS FULL| TEST        |
--------------------------------------------

Plan 2
------

Plan Origin                 :STS
Plan Hash Value             :2842999589
Executions                  :10
Elapsed Time                :0.002 sec
CPU Time                    :0.002 sec
Buffer Gets                 :3
Disk Reads                  :0
Disk Writes                 :0

Notes:
1. Statistics shown are averaged over multiple executions.

-------------------------------------
| Id  | Operation           | Name  |
-------------------------------------
|   0 | SELECT STATEMENT    |       |
|   1 |  SORT AGGREGATE     |       |
|   2 |   HASH JOIN         |       |
|   3 |    TABLE ACCESS FULL| TEST  |
|   4 |    TABLE ACCESS FULL| TEST1 |
-------------------------------------

SQLチューニング・アドバイザの推奨にかかわらず、代替計画を適用するには、DBMS_SQLTUNE.CREATE_SQL_PLAN_BASELINEをコールします。このプロシージャを使用して、任意の既存の再生可能な計画でSQL計画ベースラインを作成できます。

17.2 自動SQLチューニング・アドバイザの管理

SQLチューニング・アドバイザは、入力として1つ以上のSQL文を取得し、自動チューニング・オプティマイザを起動して文に対するSQLチューニングを実行します。出力には、提案または推奨事項と、各推奨事項の理論的根拠と予測されるメリットが含まれます。推奨事項は、オブジェクトの統計、新しい索引の作成、SQL文の再構成またはSQLプロファイルの作成に関するものです。ユーザーは、推奨事項を受け入れるかどうかを選択してSQL文のチューニングを完了できます。

データベースでは、システム・メンテナンス期間中に、SQLチューニング・アドバイザを使用して、問題のある文を識別し、チューニング推奨事項を実装して、自動的にSQL文をチューニングできます。自動的に実行する場合、SQLチューニング・アドバイザは自動SQLチューニング・アドバイザと呼ばれています。

この項では、自動SQLチューニング・アドバイザの管理方法について説明します。

- 自動SQLチューニングの動作

- 自動SQLチューニングの有効化と無効化

- 自動SQLチューニングの構成

- 自動SQLチューニング・レポートの表示

関連項目:
自動メンテナンス・タスクの詳細は、『Oracle Database管理者ガイド』を参照してください。

17.2.1 自動SQLチューニングの動作

Oracle Databaseでは、自動ワークロード・リポジトリ(AWR)から、チューニングの対象となる選択された高負荷SQL文に対して自動的にSQLチューニング・アドバイザを実行します。このタスクは、自動SQLチューニングと呼ばれ、夜間にデフォルト・メンテナンス・ウィンドウで実行されます。デフォルトでは、自動SQLチューニングの実行は、最大でも約1時間です。メンテナンス・ウィンドウの属性(開始時刻と終了時刻、頻度、曜日など)は、カスタマイズできます。

データベースでは、自動SQLチューニングの開始後、次のステップが実行されます。

1. AWR内でSQLのチューニング候補を識別します。
Oracle Databaseでは、AWRの統計を分析して、チューニング対象として可能なSQL文のリストを生成します。これらの文には、データベースに重大な影響を及ぼす、繰り返し実行される負荷の高い文が含まれます。

データベースでは、改善の可能性が高い実行計画を持つSQL文のみをチューニングします。再帰的SQL、最近1か月以内にチューニングされた文、パラレル問合せ、DML、DDL、および並行処理の問題によってパフォーマンスに問題のあるSQL文は、無視されます。

チューニングの候補として選択されたSQL文を、パフォーマンスへの影響に基づいて順序付けします。データベースでは、過去1週間に選択された文について、AWRでCPU時間とI/O回数を合計して影響を計算します。

2. SQL文ごとにSQLチューニング・アドバイザをコールして個別にチューニングします。
チューニング・プロセスでは、すべてのタイプの推奨事項が検討および報告されますが、自動的に実装できるのはSQLプロファイルのみです。

3. SQL文を実行してSQLプロファイルをテストします。
SQLプロファイルが推奨された場合は、プロファイルを使用したSQL文と、使用しない場合のSQL文を実行して、新しいプロファイルをテストします。パフォーマンスの改善が3倍以上である場合、そのSQLプロファイルを受け入れます(ACCEPT_SQL_PROFILESタスク・パラメータがTRUEの場合のみ)。それ以外の場合は、自動SQLチューニング・レポートで、SQLプロファイルを作成するよう推奨のみを行います。

4. オプションとして、3倍のパフォーマンスの向上という基準を満たしている場合は、SQLプロファイルを実装します。
SQLプロファイルを実装するかどうかを決定する際に、他の要素も考慮されます。たとえば、SQL文で参照されているオブジェクトのオプティマイザ統計が失効している場合、プロファイルは実装されません。自動的に実装されたSQLプロファイルは、タイプがAUTOであることがDBA_SQL_PROFILESビューに示されます。

データベースでSQL計画管理を使用している場合で、SQL文のSQL計画ベースラインが存在する場合は、SQLプロファイルを作成する際に新しい計画ベースラインが追加されます。これにより、オプティマイザは、プロファイル作成後すぐに新しい計画を使用します。第15章「SQL計画の管理の使用方法」を参照してください。

自動SQLチューニング・レポートを使用すると、自動SQLチューニング・プロセスの実行中または実行後の任意の時点でその結果を参照できます。このレポートには、分析されたすべてのSQL文、生成された推奨事項、および自動的に実装されたSQLプロファイルの詳細が含まれます。

図17-1は、自動SQLチューニング中にデータベースによって実行される手順を示しています。

図17-1 自動SQLチューニング

17.2.2 自動SQLチューニングの有効化と無効化

自動SQLチューニングは、自動化メンテナンス・タスク・インフラストラクチャの一部として実行されます。

自動SQLチューニングを有効化するには、次のようにDBMS_AUTO_TASK_ADMINパッケージのENABLEプロシージャを使用します。

BEGIN
DBMS_AUTO_TASK_ADMIN.ENABLE(
client_name => 'sql tuning advisor'
,   operation   => NULL
,   window_name => NULL
);
END;
/

自動SQLチューニングを無効にするには、DBMS_AUTO_TASK_ADMINパッケージのDISABLEプロシージャを使用します。

BEGIN
DBMS_AUTO_TASK_ADMIN.DISABLE(
client_name => 'sql tuning advisor'
,   operation   => NULL
,   window_name => NULL
);
END;
/

window_nameパラメータを使用して特定のウィンドウ名を渡すと、そのメンテナンス・ウィンドウのタスクのみを有効化または無効化できます。

STATISTICS_LEVELパラメータをBASICに設定すると、AWRによる自動統計収集が無効になり、その結果、自動SQLチューニングも無効になります。

関連項目:

- 自動タスク・インフラストラクチャの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

17.2.3 自動SQLチューニングの構成

Oracle Database 11gリリース2(11.2.0.2)以降、DBMS_AUTO_SQLTUNEパッケージを使用して自動SQLチューニング・タスクの動作を設定できるようになりました。前のリリースでは、かわりにDBMS_SQLTUNEを使用します。

表17-2に、自動SQLチューニングに固有の構成パラメータを示します。

表17-1 SET_AUTO_TUNING_TASK_PARAMETERの自動SQLチューニング・パラメータ

パラメータ

説明

ACCEPT_SQL_PROFILE

SQLプロファイルを自動的に受け入れるかどうかを指定します。

EXECUTION_DAYS_TO_EXPIRE

アドバイザ・フレームワーク・スキーマにタスク履歴を保存する日数を指定します。デフォルトでは、タスク履歴は30日間保存され、期限切れとなります。

MAX_SQL_PROFILES_PER_EXEC

各自動SQLチューニング・タスクで受け入れるSQLプロファイルの制限数を指定します。各自動SQLチューニング・タスクで受け入れるSQLプロファイルの制限数は、日次ベースでシステムに加えることのできる変更の許容レベルに基づいて設定してください。

MAX_AUTO_SQL_PROFILES

受け入れるSQLプロファイルの合計制限数を指定します。

DBMS_AUTO_SQLTUNEパッケージを使用するには、DBAロールを持つか、管理者によって付与されたEXECUTE権限を持つ必要があります。EXECUTE_AUTO_TUNING_TASKプロシージャのみは例外で、これはSYSによってのみ実行できます。

自動SQLチューニングを設定する方法

1. SQL*Plusを起動し、DBA権限でデータベースに接続します(またはEXECUTE_AUTO_TUNING_TASKを実行する予定であれば、SYSとして接続します)。

2. DBMS_AUTO_SQLTUNE.SET_AUTO_TUNING_TASK_PARAMETERプロシージャを実行します。
次の例では、SQLチューニング・アドバイザによって推奨されたSQLプロファイルを自動的に受け入れるよう自動SQLチューニング・タスクを設定しています。

BEGIN
DBMS_AUTO_SQLTUNE.SET_AUTO_TUNING_TASK_PARAMETER(
parameter => 'ACCEPT_SQL_PROFILES', value => 'TRUE');
END;
/

関連項目:

- SQLチューニング・タスクで構成可能なその他のパラメータの詳細は、「SQLチューニング・タスクの構成」を参照してください。

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

17.2.4 自動SQLチューニング・レポートの表示

Oracle Database 11gリリース2(11.2.0.2)以降、DBMS_AUTO_SQLTUNE.REPORT_AUTO_TUNING_TASKファンクションを使用して自動SQLチューニング・レポートを生成できるようになりました。前のリリースでは、かわりにDBMS_SQLTUNEパッケージを使用します。

このレポートには、自動SQLチューニング・タスクの実行に関する様々な情報が含まれます。レポートに含まれるセクションに応じて、次のセクションで自動SQLチューニング・タスクに関する情報を参照できます。

- 一般情報
一般情報セクションには、自動SQLチューニング・タスクの概要(レポートに指定された入力に関する情報、メンテナンス中にチューニングされたSQL文の数、作成されたSQLプロファイルの数など)が含まれます。

- サマリー
サマリー・セクションには、メンテナンス・ウィンドウ内にチューニングされたSQL文(SQL識別子別)と各SQLプロファイルの利点の見積り、またはそのSQLプロファイルを使用したSQL文のテスト実行後の実際の実行統計がリストされます。

- チューニングの検出結果
このセクションには、SQLチューニング・アドバイザによって分析された各SQL文に関する次の情報が含まれます。

- 各SQL文に関連付けられたすべての検出結果

- データベースでプロファイルが受け入れられたかどうかと、その理由

- データベースでSQLプロファイルが現在有効であるかどうか

- SQLプロファイルのテスト時に取得された実行統計の詳細

- EXPLAIN PLAN
このセクションには、SQLチューニング・アドバイザにより分析された各SQL文で使用された新旧のEXPLAIN PLANが表示されます。

- エラー
このセクションには、自動SQLチューニング・タスクで発生したすべてのエラーがリストされます。

DBMS_AUTO_SQLTUNEを使用して自動SQLチューニング・レポートを表示する方法

1. SQL*Plusを起動し、適切な権限でデータベースに接続します。

2. DBMS_AUTO_SQLTUNE.REPORT_AUTO_TUNING_TASKファンクションを実行します。
次の例では、実装されなかった推奨事項を含め、最新の実行において分析されたすべてのSQL文を表示するテキスト・レポートが生成されます。

VARIABLE my_rept CLOB;
BEGIN
:my_rept :=DBMS_AUTO_SQLTUNE.REPORT_AUTO_TUNING_TASK(
begin_exec   => NULL,
end_exec     => NULL,
type         => 'TEXT',
level        => 'TYPICAL',
section      => 'ALL',
object_id    => NULL,
result_limit => NULL);
END;
/

PRINT :my_rept

関連項目:

- Enterprise Managerを使用して自動SQLチューニング・レポートを表示する方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

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

17.3 SQLチューニング・アドバイザによる事後対応のチューニング

SQLチューニング・アドバイザを手動で起動して、1つ以上のSQL文をオンデマンドでチューニングできます。複数の文をチューニングする場合、SQLチューニング・セット(STS)を作成する必要があります。SQLチューニング・セットは、SQL文とその実行コンテキストを格納するデータベース・オブジェクトです。SQLチューニング・セットは、コマンドラインAPIまたはEnterprise Managerを使用して作成できます。「SQLチューニング・セットの管理」を参照してください。

17.3.1 入力ソース

SQLチューニング・アドバイザの入力は、以下を含む複数のソースから取り込むことができます。

- ADDM(自動データベース診断モニター)
主入力ソースは、ADDMです。デフォルトで、ADDMは1時間ごとにプロアクティブに実行され、過去1時間に自動ワークロード・リポジトリ(AWR)により収集された主要統計が分析され、高負荷のSQL文など、パフォーマンスの問題が識別されます。高負荷のSQL文が識別されると、ADDMにより、そのSQLに対してSQLチューニング・アドバイザを実行するように推奨されます。「自動データベース診断モニターの概要」を参照してください。

- AWR
2番目に重要な入力ソースは、自動ワークロード・リポジトリ(AWR)です。AWRは、CPU使用率や待機時間など、関連統計でランク付けされた高負荷のSQL文を含むシステム・アクティビティについて、通常のスナップショットを作成します。

AWRを参照して負荷の高いSQL文を手動で識別できます。これらの文に対してSQLチューニング・アドバイザを実行できますが、この操作は自動SQLチューニングの一環としてOracle Databaseによって自動的に実行されます。デフォルトで、AWRには過去8日間のデータが保持されます。この方法を使用してAWRの保存期間内に実行された負荷の高いSQLを見つけてチューニングできます。「自動ワークロード・リポジトリの概要」を参照してください。

- 共有SQL領域
3番目の入力ソースは共有SQL領域です。このソースを使用して、AWRにまだ取得されていない最近のSQL文をチューニングします。共有SQL領域とAWRは、現在の時刻からAWRの許容保存期間(デフォルトは8日以上)までの高負荷のSQL文を識別してチューニングする機能を提供します。

- SQLチューニング・セット
SQLチューニング・アドバイザのもう1つの入力ソースは、SQLチューニング・セットです。SQLチューニング・セット(STS)は、SQL文とその実行コンテキストを格納するデータベース・オブジェクトです。STSには、パフォーマンスを個別に測定することや、パフォーマンスが予測より低下しているSQL文を識別することを目的として、まだデプロイされていないSQL文を含めることができます。SQL文のセットを入力として使用する場合、最初にSTSを作成し、使用する必要があります。「SQLチューニング・セットの管理」を参照してください。

17.3.2 チューニング・オプション

SQLチューニング・アドバイザには、チューニング・タスクの有効範囲と期間を管理するオプションがあります。チューニング・タスクの有効範囲は、次のいずれかに設定できます。

- 制限付き
この場合、SQLチューニング・アドバイザでは、統計チェック、アクセス・パス分析およびSQL構造分析に基づいて推奨事項が生成されます。SQLプロファイルの推奨事項は生成されません。

- 包括的
この場合、SQLチューニング・アドバイザでは、制限付きの有効範囲で実行されるすべての分析と、SQLプロファイリングが実行されます。このオプションを選択した場合は、チューニング・タスクの時間制限も指定できます。デフォルトでは30分です。

17.3.3 アドバイザ出力

SQL文を分析した後、SQLチューニング・アドバイザにより、実行計画の最適化に関するアドバイス、提案された最適化の理論的根拠、見積られるパフォーマンスの向上およびアドバイスを実装するコマンドが提供されます。SQL文を最適化するには、推奨事項を受け入れるかどうかを選択します。

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

SQLチューニング・アドバイザを実行するための推奨インタフェースは、Enterprise Managerです。可能なかぎり、SQLチューニング・アドバイザは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』で説明しているように、Enterprise Managerで実行します。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を使用して手動で作成するか、Enterprise Managerを使用して自動的に作成できます。「SQLチューニング・セットの管理」を参照してください。

図17-2は、DBMS_SQLTUNEパッケージを使用してSQLチューニング・アドバイザを実行する場合に必要な手順を示しています。

図17-2 SQLチューニング・アドバイザAPI

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

- SQLチューニング・タスクの作成

- SQLチューニング・タスクの構成

- SQLチューニング・タスクの実行

- SQLチューニング・タスクのステータスのチェック

- SQLチューニング・アドバイザの進捗のチェック

- SQLチューニング・タスクの結果の表示

- SQLチューニング・タスクに関するその他の操作

関連項目:

- Enterprise Managerを使用してSQLチューニング・アドバイザを手動で実行する方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

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

17.3.4.1 SQLチューニング・タスクの作成

チューニング・タスクは、1つのSQL文のテキスト、複数の文を含むSQLチューニング・セット、共有SQL領域からSQL識別子で選択したSQL文、またはAWRから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 '      ||
'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';

17.3.4.2 SQLチューニング・タスクの構成

作成後にそのパラメータをDBMS_SQLTUNEパッケージのSET_TUNING_TASK_PARAMETERプロシージャを使用して構成することで、SQLチューニング・タスクを微調整できます。

BEGIN
DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER(
task_name => 'my_sql_tuning_task',
parameter => 'TIME_LIMIT', value => 300);
END;
/

前述の例では、SQLチューニング・タスクの最大実行時間が300秒に変更されています。

表17-2に、SET_TUNING_TASK_PARAMETERプロシージャを使用して構成できるパラメータを示します。

表17-2 SET_TUNING_TASK_PARAMETERプロシージャのパラメータ

パラメータ

説明

MODE

チューニング・タスクの有効範囲を次のように指定します。

- LIMITED: 各SQL文を約1秒でチューニングしますが、SQLプロファイルは推奨しません。

- COMPREHENSIVE: 完全な分析を実行し、適切であればSQLプロファイルを推奨します(ただし、相当な時間がかかることがあります)。

USERNAME

SQL文の解析を行うユーザー名

DAYS_TO_EXPIRE

タスクが削除されるまでの日数

DEFAULT_EXECUTION_TYPE

タスクの実行時にEXECUTE_TUNING_TASKファンクションで指定されていない場合のデフォルトの実行タイプ

TIME_LIMIT

タスクがタイムアウトするまでの時間制限(秒単位)

LOCAL_TIME_LIMIT

各SQL文の時間制限(秒単位)

TEST_EXECUTE

推奨事項の利点を検証するために、SQLチューニング・アドバイザ・テストでSQL文を実行するかどうかを次のように指定します。

- FULL - 必要なかぎり多くのローカル時間制限でSQL文をテスト実行します。

- AUTO - 自動時間制限を使用してSQL文をテスト実行します。

- OFF - SQL文のテストを実行しません。

BASIC_FILTER

SQLチューニング・セットで使用される基本フィルタ

OBJECT_FILTER

SQLチューニング・セットで使用されるオブジェクト・フィルタ

PLAN_FILTER

SQLチューニング・セットで使用されるプラン・フィルタ

RANK_MEASURE1

SQLチューニング・セットで使用される第1ランキング・メジャー

RANK_MEASURE2

SQLチューニング・セットで使用される第2ランキング・メジャー

RANK_MEASURE3

SQLチューニング・セットで使用される第3ランキング・メジャー

RESUME_FILTER

SQLチューニング・セットで使用される(BASIC_FILTER以外の)追加フィルタ

SQL_LIMIT

チューニングされるSQL文の最大数

SQL_PERCENTAGE

SQLチューニング・セットからの文のパーセンテージ・フィルタ

17.3.4.3 SQLチューニング・タスクの実行

チューニング・タスクを作成した後、タスクを実行し、チューニング・プロセスを開始します。たとえば、次のPL/SQLコードを実行します。

BEGIN
DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'my_sql_tuning_task' );
END;
/

他のSQLチューニング・アドバイザ・タスクと同様に、EXECUTE_TUNING_TASK APIを使用して自動チューニング・タスクSYS_AUTO_SQL_TUNING_TASKを実行することもできます。SQLチューニング・アドバイザは、自動的に実行する場合と同じ分析およびアクションを実行します。実行名をAPIに渡して、新規実行の名前を付けることも可能です。

17.3.4.4 SQLチューニング・タスクのステータスのチェック

USER_ADVISOR_TASKSビューの情報を検討してタスクの状態をチェックするか、V$SESSION_LONGOPSビューでタスク実行の進捗をチェックできます。たとえば、次の問合せを実行します。

SELECT status
FROM   USER_ADVISOR_TASKS
WHERE  task_name = 'my_sql_tuning_task';

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

17.3.4.6 SQLチューニング・タスクの結果の表示

タスクの実行後に、REPORT_TUNING_TASKファンクションを使用して結果レポートを表示します。たとえば、次のようにします。

SET LONG 1000
SET LONGCHUNKSIZE 1000
SET LINESIZE 100
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'my_sql_tuning_task')
FROM   DUAL;

このレポートには、SQLチューニング・アドバイザのすべての検出結果および推奨事項が含まれます。提案される推奨事項ごとに、その実装に必要なSQL文、理論的根拠およびメリットが提供されます。

DBAビューに、チューニング・タスクおよび結果に関する追加の情報があります。「SQLチューニング・ビュー」を参照してください。

17.3.4.7 SQLチューニング・タスクに関するその他の操作

次のAPIを使用して、SQLチューニング・タスクを管理できます。

- INTERRUPT_TUNING_TASK(実行中にタスクに割り込み、中間結果を取得して通常終了)

- RESUME_TUNING_TASK(前回割り込まれたタスクを再開)

- CANCEL_TUNING_TASK(実行中にタスクを取り消し、タスクからすべての結果を削除)

- RESET_TUNING_TASK(実行中にタスクをリセットし、タスクからすべての結果を削除し、タスクを初期の状態に戻す)

- DROP_TUNING_TASK(タスクを削除し、タスクに関連付けられたすべての結果を削除)

17.4 SQLチューニング・セットの管理

SQLチューニング・セット(STS)は、1つ以上のSQL文とその実行統計および実行コンテキストを含むデータベース・オブジェクトであり、ユーザーによる優先順位ランキングを含む場合もあります。SQL文は、AWR、共有SQL領域またはユーザー提供のカスタムSQLなど、様々なSQLソースからSQLチューニング・セットにロードできます。STSに含まれるのは、次のとおりです。

- SQL文のセット

- 関連する実行コンテキスト(ユーザー・スキーマ、アプリケーション・モジュール名およびアクション、バインド値のリストおよびカーソル・コンパイル環境など)

- 関連する基本実行統計(経過時間、CPUタイム、バッファ読取り、ディスク読取り、処理された行数、カーソル・フェッチ、実行数、実行完了数、オプティマイザ・コストおよびコマンドのタイプなど)

- 各SQL文の関連実行計画と行ソース統計(オプション)

SQL文は、アプリケーション・モジュール名とアクション、または任意の実行統計を使用してフィルタできます。また、実行統計の任意の組合せに基づいて文をランク付けすることもできます。

STSをSQLチューニング・アドバイザへの入力として使用して、ユーザー指定の他の入力パラメータに基づいてSQL文の自動チューニングを実行できます。SQLチューニングセットを別のデータベースにエクスポートすることで、SQLワークロードをデータベース間で転送してリモート・パフォーマンス診断およびチューニングを実行できます。本番データベースにパフォーマンスの悪いSQL文がある場合、開発者が直接本番システム上で調査およびチューニングを実行することは望ましくありません。DBAにより、開発者が安全に分析およびチューニングできるテスト用データベースに、問題のあるSQL文を転送できます。SQLチューニング・セットを転送するには、DBMS_SQLTUNEパッケージを使用します。

可能な場合、SQLチューニング・セットは、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』で説明しているように、Enterprise Managerで管理します。Enterprise Managerが使用可能でない場合、DBMS_SQLTUNEパッケージのプロシージャを使用してSQLチューニング・セットを管理できます。

通常、STS操作を使用する順序は次のとおりです。

1. 新規STSの作成
このタスクについては、「SQLチューニング・セットの作成」を参照してください。

2. STSのロード
このタスクについては、「SQLチューニング・セットのロード」を参照してください。

3. STSを選択して内容を確認
このタスクについては、「SQLチューニング・セットの内容の表示」を参照してください。

4. 必要に応じてSTSを更新
このタスクについては、「SQLチューニング・セットの変更」を参照してください。

5. 入力にSTSを使用してチューニング・タスクを作成

6. 必要に応じて、他のシステムへのSTSの転送
このタスクについては、「SQLチューニング・セットの転送」を参照してください。

7. 完了時にSTSを削除
このタスクについては、「SQLチューニング・セットの削除」を参照してください。

このAPIを使用するには、所有するSQLチューニング・セットを管理するためのADMINISTER SQL TUNING SETシステム権限が必要です。または、任意のSQLチューニング・セットを管理するためのADMINISTER ANY SQL TUNING SETシステム権限が必要です。

図17-3に、SQLチューニング・セットAPIを使用する場合の手順を示します。

図17-3 SQLチューニング・セットAPI

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

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

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

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

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

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

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

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

関連項目:

- Enterprise Managerを使用してSQLチューニング・セットを管理する方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

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

17.4.1 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に割り当てられた説明です。

17.4.2 SQLチューニング・セットのロード

LOAD_SQLSETプロシージャでは、選択したSQL文がSTSに移入されます。STSに移入するための標準ソースは、ワークロード・リポジトリ、他のSTSまたは共有SQL領域です。ワークロード・リポジトリおよび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;
/

17.4.3 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ビューを使用して表示できます。

17.4.4 SQLチューニング・セットの変更

検索条件に基づいて、STSで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;
/

17.4.5 SQLチューニング・セットの転送

SQLチューニング・セットは、転送できます。転送するには、STSをデータベースからステージング表にエクスポートした後、ステージング表から別のデータベースにSTSをインポートします。

Oracle Database 10g(リリース2)以降で作成された任意のデータベースにSQLチューニング・セットを転送できます。これは、SQLパフォーマンス・アナライザを使用してテスト用データベースで回帰をチューニングする場合に役立ちます。たとえば、次のシナリオでSTSを転送できます。

- Oracle Database 11gリリース2(11.2)で作成した本番データベースに、低下したSQLを含むSTSが存在する場合。

- Oracle Database 11gリリース1(11.1)またはOracle Database 10gで作成したリモートのテスト用データベースでSQLパフォーマンス・アナライザの試行を実行する場合。

- STSを本番データベースからテスト用データベースにコピーして、SQLパフォーマンス・アナライザの試行で回帰をチューニングする場合。

SQLチューニング・セットを転送するには、次の手順を実行します。

1. CREATE_STGTAB_SQLSETプロシージャを使用して、SQLチューニング・セットのエクスポート先にステージング表を作成します。
次の例では、dba1にmy_10g_staging_tableを作成し、ステージング表の形式を10.2に指定します。

BEGIN
DBMS_SQLTUNE.create_stgtab_sqlset(
table_name  => 'my_10g_staging_table',
schema_name => 'dba1',
db_version  => DBMS_SQLTUNE.STS_STGTAB_10_2_VERSION );
END;
/

2. PACK_STGTAB_SQLSETプロシージャを使用して、このステージング表にSQLチューニング・セットをエクスポートします。
次の例では、dba1.my_10g_staging_tableに、hrが所有するSTS my_stsを移入します。

BEGIN
DBMS_SQLTUNE.pack_stgtab_sqlset(
sqlset_name          => 'my_sts',
sqlset_owner         => 'hr',
staging_table_name   => 'my_10g_staging_table',
staging_schema_owner => 'dba1',
db_version           => DBMS_SQLTUNE.STS_STGTAB_10_2_VERSION );
END;
/

3. 選択したメカニズム(Oracle Data Pumpまたはデータベース・リンクなど)を使用して、SQLチューニング・セットのインポート先のデータベースにステージング表を移動します。

4. SQLチューニング・セットのインポート先となるデータベースで、UNPACK_STGTAB_SQLSETプロシージャを使用してステージング表からSQLチューニング・セットをインポートします。
次の例は、ステージング表にあるSQLチューニング・セットをインポートする方法を示しています。

BEGIN
DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET(
sqlset_name  => '%',
replace  => TRUE,
staging_table_name => 'my_10g_staging_table');
END;
/

17.4.6 SQLチューニング・セットの削除

DROP_SQLSETプロシージャは、不要になったSTSを削除します。たとえば、次のようにします。

BEGIN
DBMS_SQLTUNE.DROP_SQLSET( sqlset_name => 'my_sql_tuning_set' );
END;
/

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

次のAPIを使用してSTSを管理できます。

- STS内のSQL文の属性の更新
UPDATE_SQLSETプロシージャは、STS名およびSQL識別子で識別される既存のSTS内のSQL文の属性(PRIORITYまたはOTHERなど)を更新します。

- 全システム・ワークロードの取得
CAPTURE_CURSOR_CACHE_SQLSETファンクションでは、特定の間隔で共有SQL領域を繰り返しポーリングして、全システム・ワークロードを取得できます。このファンクションは、SELECT_CURSOR_CACHEおよびLOAD_SQLSETプロシージャを繰り返し使用する場合よりも効率的に共有SQL領域を長期間にわたって取得できます。また、高負荷SQL文のワークロードのみを取得するAWR、またはデータ・ソースに1度のみアクセスするLOAD_SQLSETプロシージャとは対照的に、ワークロード全体を効果的に取得します。

- STSへの参照の追加および削除
ADD_SQLSET_REFERENCEファンクションでは、既存のSTSへの新規参照が追加され、クライアントが使用中であることが示されます。このファンクションでは、追加された参照の識別子が戻されます。REMOVE_SQLSET_REFERENCEプロシージャは、STSを非アクティブにし、クライアントにより使用されなくなったことを示します。

17.5 SQLプロファイルの管理

SQLプロファイルは、SQL文に固有の補足情報です。

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

- SQLプロファイルの概要

- SQLプロファイルの受入れ

- SQLプロファイルの変更

- SQLプロファイルの削除

- SQLプロファイルの転送

関連項目:
Enterprise Managerを使用してSQLプロファイルを管理する方法は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

17.5.1 SQLプロファイルの概要

SQLプロファイルには、自動SQLチューニングの際に検出された不適切なオプティマイザの見積りに対する修正が含まれます。この情報により、オプティマイザによるカーディナリティおよび選択性の予測が改善され、より適切な計画を選択できるようになります。

SQLプロファイルには、個別の実行計画に関する情報は含まれません。オプティマイザには、計画を選択する際に、次の情報ソースがあります。

- データベース構成、バインド変数値、オプティマイザ統計、データ・セットなどを含む環境。

- SQLプロファイルの補足的な統計情報。

SQLプロファイルの環境が変化した場合、オプティマイザは新しい計画を作成できます。

SQLプロファイルは、SQL計画管理とともに使用することも、SQL計画管理なしで使用することもできます。SQL計画管理を使用する場合、オプティマイザが選択する計画は、有効な計画ベースラインである必要があります。ベースラインに文の計画が複数存在する場合、プロファイルを使用することでベースラインで最小コストの計画を選択できます。

図17-4に、SQL文とSQLプロファイルの関係を示します。オプティマイザは、プロファイルと環境を使用して問合せの計画を生成します。この例では、文の計画は、SQL計画ベースラインにあります。

図17-4 SQLプロファイル

SQLプロファイルには、次の利点があります。

- プロファイルは、ヒントおよびストアド・アウトラインとは異なり、オプティマイザを特定の計画またはサブプランに結び付けません。プロファイルは、不適切な見積りを修正し、それぞれの状況に合った最適な計画を選択する柔軟性をオプティマイザに提供します。

- プロファイルを使用する場合は、ヒントとは異なり、アプリケーション・ソース・コードの変更は不要です。
データベースによるSQLプロファイルの使用は、ユーザーに対して透過的です。

17.5.1.1 SQLプロファイルの推奨事項

SQLをチューニングする際に、自動チューニングを行う文を選択し、SQLチューニング・アドバイザを実行します。データベースでは、次のタイプの文をプロファイルできます。

- DML文(SELECT、SELECT句を含むINSERT、UPDATEおよびDELETE)

- CREATE TABLE文(AS SELECT句の場合のみ)

- MERGE文(更新または挿入操作)

SQLチューニング・アドバイザは、自動チューニング・オプティマイザを起動して推奨事項を生成します。SQLプロファイルの受入れの推奨は、検出で発生します。

例17-3では、コストの高いいくつかの結合を使用するSELECT文に対して、よりよい計画が検出されています。DBMS_SQLTUNE.ACCEPT_SQL_PROFILEを実行してプロファイルを受け入れることで、文の実行が98.53%高速化します。

例17-3 サンプルSQLプロファイルの検出

-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
A potentially better execution plan was found for this statement. Choose
one of the following SQL profiles to implement.

Recommendation (estimated benefit: 99.45%)
------------------------------------------
- Consider accepting the recommended SQL profile.
execute dbms_sqltune.accept_sql_profile(task_name => 'my_task',
object_id => 3, task_owner => 'SH', replace => TRUE);

Validation results
------------------
The SQL profile was tested by executing both its plan and the original plan
and measuring their respective execution statistics. A plan may have been
only partially executed if the other could be run to completion in less time.

Original Plan  With SQL Profile  % Improved
-------------  ----------------  ----------
Completion Status:             PARTIAL          COMPLETE
Elapsed Time(us):            15467783            226902      98.53 %
CPU Time(us):                15336668            226965      98.52 %
User I/O Time(us):                  0                 0
Buffer Gets:                  3375243             18227      99.45 %
Disk Reads:                         0                 0
Direct Writes:                      0                 0
Rows Processed:                     0               109
Fetches:                            0               109
Executions:                         0                 1

Notes
-----
1. The SQL profile plan was first executed to warm the buffer cache.
2. Statistics for the SQL profile plan were averaged over next 3 executions.

SQLチューニング・アドバイザは、自動並列度(自動DOP)機能を使用するプロファイルを受け入れるよう推奨する場合もあります。パラレル問合せプロファイルは、元の計画がシリアルの場合で、パラレル実行により実行時間の長い問合せのレスポンス時間を大幅に削減できる場合にのみ推奨されます。SQLチューニング・アドバイザが自動DOPを使用するプロファイルを推奨する場合、SQL文にパラレル実行を使用した場合のパフォーマンスのオーバーヘッドの詳細がレポートで提供されます。

パラレル実行の推奨では、SQLチューニング・アドバイザは、2つのSQLプロファイルの推奨(シリアル実行とパラレル実行に各1個)を提供する場合があります。この場合、パラレルで実行するためのディレクティブを除いて、パラレル・プロファイルは標準プロファイルと同一です。

例17-4に、パラレル問合せの推奨を示します。この例では、並列度が7の場合、レスポンス時間が大幅に改善されますが、リソースの消費がほぼ25%増加します。ユーザーは、データベース・スループットの削減がレスポンス時間の増加に値するかどうかを判断する必要があります。

例17-4 パラレル問合せの推奨

Recommendation (estimated benefit: 99.99%)
------------------------------------------
- Consider accepting the recommended SQL profile to use parallel execution
for this statement.
execute dbms_sqltune.accept_sql_profile(task_name => 'gfk_task',
object_id => 3, task_owner => 'SH', replace => TRUE,
profile_type => DBMS_SQLTUNE.PX_PROFILE);

Executing this query parallel with DOP 7 will improve its response time
82.22% over the SQL profile plan. However, there is some cost in enabling
parallel execution. It will increase the statement's resource consumption by
an estimated 24.43% which may result in a reduction of system throughput.
Also, because these resources are consumed over a much smaller duration, the
response time of concurrent statements might be negatively impacted if
sufficient hardware capacity is not available.

The following data shows some sampled statistics for this SQL from the past
week and projected weekly values when parallel execution is enabled.

Past week sampled statistics for this SQL
-----------------------------------------
Number of executions                                                   0
Percent of total activity                                            .29
Percent of samples with #Active Sessions > 2*CPU                       0
Weekly DB time (in sec)                                            76.51

Projected statistics with Parallel Execution
--------------------------------------------
Weekly DB time (in sec)                                            95.21

17.5.1.2 SQLプロファイルの作成

プロファイルを承諾した場合、プロファイルが作成されてデータ・ディクショナリに永続的に保存されます。プロファイルが構築された文をユーザーが発行した場合、問合せオプティマイザは(標準モード)、環境およびSQLプロファイルを使用して適切にチューニングされた計画を構築します。

データベースでSQL計画管理を使用している場合で、SQL文のSQL計画ベースラインが存在する場合は、SQLプロファイルを作成する際に、ベースラインに新しい計画が追加されます。それ以外の場合、新しい計画ベースラインは追加されません。

SQLプロファイルと計画ベースラインの間に厳密な関係は存在しません。ハード解析の際に、オプティマイザはSQLプロファイルを使用して、使用可能な計画から最善の計画ベースラインを選択します。場合によっては、SQLプロファイルによって、オプティマイザが異なる計画ベースラインを選択することもあります。

関連項目:
第15章「SQL計画の管理の使用方法」

17.5.1.3 SQLプロファイルのAPI

通常、SQLプロファイルは自動SQLチューニングの一部としてEnterprise Managerで処理されますが、DBMS_SQLTUNEパッケージを使用してSQLプロファイルを管理することもできます。APIを使用するには、ADMINISTER SQL MANAGEMENT OBJECT権限が必要です。

表17-3に、SQLプロファイルを管理する主なプロシージャおよびファンクションを示します。

表17-3 SQLプロファイルのDBMS_SQLTUNE API

プロシージャまたはファンクション

説明

項

ACCEPT_SQL_PROFILE

指定されたチューニング・タスクのSQLプロファイルを作成します。

「SQLプロファイルの受入れ」

ALTER_SQL_PROFILE

既存のSQLプロファイル・オブジェクトの特定の属性を変更します。

「SQLプロファイルの変更」

DROP_SQL_PROFILE

指定されたSQLプロファイルをデータベースから削除します。

「SQLプロファイルの削除」

CREATE_STGTAB_SQLPROF

システム間でのSQLプロファイルのコピーに使用されるステージング表を作成します。

「SQLプロファイルの転送」

PACK_STGTAB_SQLPROF

プロファイル・データをSYSスキーマからステージング表に移動します。

「SQLプロファイルの転送」

UNPACK_STGTAB_SQLPROF

ステージング表に格納されたプロファイル・データを使用して、システムでプロファイルを作成します。

「SQLプロファイルの転送」

図17-5に、SQLプロファイルのAPIを使用する場合に実行できるアクションを示します。

図17-5 SQLプロファイルのAPI

表が大きくなり、索引が作成または削除されると、プロファイルの計画が変化する可能性があります。対応する文のデータ配分やアクセス・パスに変更があっても、プロファイルは引き続き関連付けられています。一般に、SQLプロファイルをリフレッシュする必要はありません。

長い間に、プロファイルの内容は古くなる可能性があります。この場合、対応するSQL文のパフォーマンスが低下する場合があります。パフォーマンスの悪い文は、負荷の高いSQLまたは上位SQLとして現れる場合があります。この場合、自動SQLチューニング・タスクが文を高負荷のSQLとして再び取得します。文の新しいプロファイルを作成できます。

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

17.5.2 SQLプロファイルの受入れ

DBMS_SQLTUNE.ACCEPT_SQL_PROFILEプロシージャまたはファンクションを使用して、SQLチューニング・アドバイザが推奨するSQLプロファイルを受け入れることができます。このプロシージャは、SQLプロファイルを作成してデータベースに格納します。

通常では、SQLチューニング・アドバイザが推奨するSQLプロファイルを受け入れます。索引およびSQLプロファイルが推奨されている場合は、両方とも使用するか、SQLプロファイルのみを使用します。索引を作成した場合、オプティマイザは、新しい索引を選択するためにプロファイルが必要になる場合があります。

場合によっては、SQLチューニング・アドバイザは、改善されたシリアル計画よりも、さらによいパラレル計画を検出する場合もあります。この場合は、標準およびパラレルのSQLプロファイルが推奨され、文に対する最善のシリアル計画と最善のパラレル計画のいずれかを選択できます。パラレル計画は、レスポンス時間の増加がスループットの低下に値する場合にのみ受け入れます(例17-4を参照)。

SQLプロファイルを受け入れるには、次のようにします。

- DBMS_SQLTUNE.ALTER_SQL_PROFILEプロシージャをコールします。
次の例で、my_sql_tuning_taskはSQLチューニング・タスクの名前で、my_sql_profileはSQLプロファイルの名前です。PL/SQLブロックは、パラレル実行を使用するプロファイルを受け入れます(profile_type)。

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',
profile_type => DBMS_SQLTUNE.PX_PROFILE,
force_match  => TRUE );
END;
/

force_match設定は、文の一致を制御します。通常、SQLプロファイルを受け入れると、ハッシュ関数を使用して生成されるSQLシグネチャを通じてSQL文に関連付けられます。このハッシュ関数は、シグネチャを生成する前に、SQL文を大文字に変更し、余分な空白をすべて削除します。したがって、大/小文字および空白のみが異なるすべてのSQL文で同じSQLプロファイルを使用できます。

force_matchをTRUEに設定した場合、リテラル値をバインド変数に正規化した後、同じテキストを持つすべてのSQL文がSQLプロファイルの追加の対象となります。この設定により、テキストのリテラル値のみが異なるSQLでは、SQLプロファイルの共有が可能になるため、リテラル値のみを使用するアプリケーションに有効です。SQLテキストにリテラル値とバインド変数の両方が使用されている場合、またはforce_matchパラメータがFALSE(デフォルト値)に設定されている場合、リテラル値は正規化されません。

SQLプロファイルの情報は、DBA_SQL_PROFILESビューに表示できます。

17.5.3 SQLプロファイルの変更

ALTER_SQL_PROFILEプロシージャで既存のSQLプロファイルの属性を変更できます。変更可能な属性は、STATUS、NAME、DESCRIPTIONおよびCATEGORYです。

CATEGORY属性により、プロファイルを適用できるユーザー・セッションが決まります。DBA_SQL_PROFILES.CATEGORYへの問合せによって、CATEGORY属性を参照できます。デフォルトでは、すべてのプロファイルはDEFAULTカテゴリです。これは、SQLTUNE_CATEGORY初期化パラメータがDEFAULTに設定されたすべてのセッションがプロファイルを使用できることを意味します。

SQLプロファイルのカテゴリを変更することで、どのセッションが作成するプロファイルの影響を受けるかを確認できます。たとえば、カテゴリをDEVに設定すると、SQLTUNE_CATEGORY初期化パラメータがDEVに設定されているセッションのみがプロファイルを使用できます。他のすべてのセッションは、SQLプロファイルにアクセスできないため、SQL文の実行計画がSQLプロファイルの影響を受けることはありません。この方法によって、限定的な環境でプロファイルをテストしてから、他のセッションで使用することができます。

SQLプロファイルを変更するには、次のようにします。

- DBMS_SQLTUNE.ALTER_SQL_PROFILEプロシージャをコールします。
次の例では、my_sql_profileのSTATUS属性がDISABLEDに変更されています。これにより、SQLプロファイルは、SQLのコンパイルの際に使用されません。

BEGIN
DBMS_SQLTUNE.ALTER_SQL_PROFILE(
name            => 'my_sql_profile',
attribute_name  => 'STATUS',
value           => 'DISABLED');
END;
/

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

17.5.4 SQLプロファイルの削除

DROP_SQL_PROFILEプロシージャを使用して、SQLプロファイルを削除できます。指定したプロファイル名が存在しない場合、エラーを無視するかどうかを指定できます。この例では、デフォルト値のFALSEを使用します。

SQLプロファイルを削除するには、次のようにします。

- DBMS_SQLTUNE.DROP_SQL_PROFILEプロシージャをコールします。
次の例では、my_sql_profileというプロファイルを削除します。

BEGIN
DBMS_SQLTUNE.DROP_SQL_PROFILE( name => 'my_sql_profile' );
END;
/

17.5.5 SQLプロファイルの転送

SQLプロファイルを転送することができます。転送するには、SQLプロファイルをデータベースのSYSスキーマからステージング表にエクスポートした後、ステージング表から別のデータベースにSQLプロファイルをインポートします。SQLプロファイルは、同じリリースまたはそれ以降のリリースで作成された任意のOracleデータベースに転送できます。

SQLプロファイルを転送するには、次のようにします。

1. CREATE_STGTAB_SQLPROFプロシージャを使用して、SQLプロファイルのエクスポート先のステージング表を作成します。
次の例では、DBA1スキーマにmy_staging_tableを作成します。

BEGIN
DBMS_SQLTUNE.create_stgtab_sqlprof(
table_name  => 'my_staging_table',
schema_name => 'DBA1' );
END;
/

2. PACK_STGTAB_SQLPROFプロシージャを使用して、SQLプロファイルをステージング表にエクスポートします。
次の例では、SQLプロファイルmy_profileをdba1.my_staging_tableに移入します。

BEGIN
DBMS_SQLTUNE.pack_stgtab_sqlprof(
profile_name         => 'my_profile',
staging_table_name   => 'my_staging_table',
staging_schema_owner => 'dba1' );
END;
/

3. 選択したメカニズム(Oracle Data Pumpまたはデータベース・リンクなど)を使用して、SQLプロファイルのインポート先のデータベースにステージング表を移動します。

4. SQLプロファイルのインポート先となるデータベースで、UNPACK_STGTAB_SQLPROFプロシージャを使用してステージング表からSQLプロファイルをインポートします。
次の例に、ステージング表にあるSQLプロファイルをインポートする方法を示します。

BEGIN
DBMS_SQLTUNE.UNPACK_STGTAB_SQLPROF(
replace  => TRUE,
staging_table_name => 'my_staging_table');
END;
/

17.6 SQLチューニング・ビュー

この項では、SQL文のチューニング用に収集された情報を表示するビューをまとめています。これらのビューにアクセスするには、DBA権限が必要です。

- アドバイザ情報ビュー(DBA_ADVISOR_TASKS、DBA_ADVISOR_EXECUTIONS、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ビューに表示されます。
TYPE = MANUALの場合、SQLプロファイルはSQLチューニング・アドバイザによって手動で作成されました。TYPE = AUTOの場合、プロファイルは自動SQLチューニングによって作成されました。

- アドバイザの実行進捗情報は、V$ADVISOR_PROGRESSビューに表示されます。

- SQLチューニングの関連情報を含む動的ビュー(V$SQL、V$SQLAREA、V$SQLSTATSおよびV$SQL_BIND_DATAビューなど)。

関連項目:
静的データ・ディクショナリ・ビューおよび動的ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

18 SQLアクセス・アドバイザ

この章では、SQLアクセス・アドバイザの使用方法について説明します。SQLアクセス・アドバイザは、パーティション化、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログによるデータベースのパフォーマンス向上についてアドバイスを提供するチューニング・ツールです。この章には次の項があります。

- SQLアクセス・アドバイザの概要

- SQLアクセス・アドバイザの使用

- 高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング

18.1 SQLアクセス・アドバイザの概要

データ集中型の複雑な問合せの実行時に最適なパフォーマンスを実現できるようにデータベースをチューニングする場合、マテリアライズド・ビュー、パーティションおよび索引が必要不可欠です。SQLアクセス・アドバイザでは、特定のワークロードに関するマテリアライズド・ビュー、マテリアライズド・ビュー・ログ、パーティションおよび索引の適切なセットを推奨して、パフォーマンスの目標達成を支援します。SQLを最適化する際には、これらの構造を理解して使用することが重要です。これにより、データを取り出す際のパフォーマンスが大幅に向上します。ただし、このような利点を利用するにはそれなりの負担が伴います。これらのオブジェクトの作成やメンテナンスには時間がかかり、領域要件も重要になります。特に、パーティション化されていない実表のパーティション化は、慎重な計画を必要とする複雑な操作です。

SQLアクセス・アドバイザの索引の推奨事項には、ビットマップ索引、ファンクション索引およびBツリー索引が含まれます。ビットマップ索引を使用すると、多くのタイプの非定型問合せのレスポンス時間が短縮され、その他の索引付けの方法と比べて記憶域要件が軽減されます。ビットマップ索引は、一意またはほぼ一意のキーに索引を付ける方法で、データ・ウェアハウスで最も一般的に使用されています。SQLアクセス・アドバイザのマテリアライズド・ビューの推奨には、通常のリライトまたはテキストの完全一致リライトでの、高速リフレッシュおよび完全リフレッシュの可能なMVの推奨も含まれます。

SQLアクセス・アドバイザでは、TUNE_MVIEWプロシージャを使用することで、高速リフレッシュが可能で、通常のクエリー・リライトを活用できるマテリアライズド・ビューの最適化の方法も推奨されます。

また、SQLアクセス・アドバイザは、既存のパーティション化されていない実表のパーティション化によるパフォーマンスの改善を推奨する場合もあります。さらに、パーティション化された新しい索引およびマテリアライズド・ビューを推奨することもあります。パーティション化された新しい索引およびマテリアライズド・ビューの作成は、パーティション化されていない場合と同じですが、既存の実表のパーティション化は慎重に実行する必要があります。表に索引、ビュー、制約またはトリガーが定義されている場合は、特に慎重に行う必要があります。このタスクをオンラインで実行する場合、実表のパーティション化における問題の詳細は、「スクリプトにパーティション推奨事項が含まれる場合の特別な考慮事項」を参照してください。

SQLアクセス・アドバイザを実行するには、Oracle Enterprise ManagerからSQLアクセス・アドバイザ・ウィザードを使用するか(「アドバイザ・セントラル」ページからアクセス可能)、DBMS_ADVISORパッケージを起動します。DBMS_ADVISORパッケージは、任意のPL/SQLプログラムからコール可能な分析およびアドバイザ用のファンクションおよびプロシージャの集合です。

図18-1に、SQLアクセス・アドバイザが指定されたワークロードをユーザー定義の表またはSQLキャッシュから取得し、アクセス構造を推奨する方法を示します。ワークロードを指定しない場合、SQLアクセス・アドバイザは、仮想ワークロードを生成し、使用できます(ただし、CREATE DIMENSIONキーワードで定義されたディメンションがユーザー・スキーマに含まれていることが前提となります)。

図18-1 マテリアライズド・ビューとSQLアクセス・アドバイザ

Enterprise ManagerのSQLアクセス・アドバイザ・ウィザードまたはAPIを使用して、次の操作を実行できます。

- 収集した情報、ユーザー指定の情報、または仮想ワークロード情報に基づいてマテリアライズド・ビューと索引を推奨します。

- 表、索引およびマテリアライズド・ビューのパーティション化を推奨します。

- 推奨事項をマーク、更新および削除します。

また、SQLアクセス・アドバイザのAPIを使用して、次の操作を実行できます。

- 単一SQL文を使用してクイック・チューニングを実行します。

- マテリアライズド・ビューを高速でリフレッシュする方法を示します。

- マテリアライズド・ビューを変更して汎用的なクエリー・リライトを可能にする方法を示します。

推奨する際に、SQLアクセス・アドバイザは、ディメンション・レベルの列、JOIN KEY列およびファクト表のキー列における表および索引のカーディナリティに関する構造の統計情報に依存します。DBMS_STATSパッケージを使用して、正確な統計または見積り統計を収集できます。統計の収集は時間のかかる処理であり、完全な統計精度は必要ないため、通常は統計を見積ることをお薦めします。特定の表に関する統計情報を収集しない場合、その表を参照する問合せはワークロードで無効とマークされ、それらの問合せについては推奨事項は生成されません。また、既存のすべての索引とマテリアライズド・ビューを分析しておくこともお薦めします。DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.1.1 SQLアクセス・アドバイザの使用の概要

SQLアクセス・アドバイザを使用するには、Enterprise Managerの「アドバイザ・セントラル」ページからウィザードを起動する方法が簡単です。DBMS_ADVISORパッケージからSQLアクセス・アドバイザを使用する場合は、この項で説明する基本コンポーネントおよびプロシージャのコール順序を参照してください。

この項では、一連の推奨事項を生成するための4つの手順について説明します。

- タスクの作成

- ワークロードの定義

- 推奨事項の生成

- 推奨事項の表示と実装

手順1: タスクの作成

アドバイザ・タスクはデータ・ディクショナリ内のコンテナで、インテリジェントなアドバイザ分析への入力内容や実行結果を格納します。結果を含めて推奨操作に関連する情報はすべて、タスクに格納されています。

SQLアクセス・アドバイザによる推奨を生成するには、次のいずれかを使用して最初にタスクを作成しておく必要があります。

- タスクを自動的に作成するOracle Enterprise ManagerのウィザードまたはDBMS_ADVISOR.QUICK_TUNEプロシージャ

- DBMS_ADVISOR.CREATE_TASKプロシージャ

タスクの処理内容を制御するには、DBMS_ADVISOR.SET_TASK_PARAMETERプロシージャを使用してタスクのパラメータを定義します。

関連項目:
「タスクの作成」

手順2: ワークロードの定義

ワークロードは1つ以上のSQL文と、各文を完全に説明する統計や属性で構成されています。全ワークロードには、対象となるビジネス・アプリケーションのすべてのSQL文が含まれます。部分ワークロードには、SQL文のサブセットが含まれます。これらの違いは、全ワークロードの場合、使用されていないマテリアライズド・ビューと索引を削除するようSQLアクセス・アドバイザが推奨する点にあります。

ワークロードなしでSQLアクセス・アドバイザを使用することはできません。ワークロードには様々な種類の文が含まれることがあります。SQLアクセス・アドバイザは特定の統計、ビジネスの重要性、またはその2つの組合せに応じてエントリにランクを付けます。これにより、アドバイザは最も重要なSQL文を先に処理できるようになります。

SQLアクセス・アドバイザでは、有効なワークロードに特定の属性が存在する必要があります。項目が欠落していてもアドバイザは分析を実行できますが、推奨事項の品質が低下する場合があります。たとえば、SQLアクセス・アドバイザでは、SQL問合せとこの問合せを実行したユーザーがワークロードに含まれている必要があります。その他の属性はオプションです。ただし、ワークロードにI/OおよびCPUデータも含む場合、SQLアクセス・アドバイザは、文の効率をより正確に評価できます。

データベースはワークロードをSQLチューニング・セットとして格納します。ワークロードにはDBMS_SQLTUNEパッケージを使用してアクセスし、多くのアドバイザ・タスク間で共有できます。ワークロードは独立しているため、DBMS_ADVISOR.ADD_STS_REFプロシージャを使用してタスクにリンクする必要があります。このリンクが確立された後は、すべてのアドバイザ・タスクからワークロードに対する依存性が削除されるまで、ワークロードを削除または変更できません。ユーザーが親アドバイザ・タスクを削除するか、DBMS_ADVISOR.DELETE_STS_REFプロシージャを使用してタスクからワークロード参照を手動で削除すると、ワークロード参照は削除されます。

ディメンションと制約を分析することで、スキーマから仮想ワークロードを作成できます。最良の結果を得るには、ワークロードをSQLチューニング・セットとして提供します。DBMS_SQLTUNEパッケージに提供されているヘルパー・ファンクションにより、一般的なワークロード・ソース(SQLキャッシュ、表に格納されたユーザー定義のワークロード、仮想ワークロードなど)からSQLチューニング・セットを作成できます。

推奨事項の生成時に、ワークロードにフィルタを適用して分析対象を制限できます。こうして制限することで、様々なワークロード・シナリオに基づいた推奨事項のセットを生成できます。SQLアクセス・アドバイザ・パラメータは、ワークロードの推奨プロセスとカスタマイズを制御します。これらのパラメータは、必要な推奨事項のタイプや推奨内容のネーミング規則など、プロセスの様々な側面を制御します。

これらのパラメータを設定するには、SET_TASK_PARAMETERプロシージャを使用します。パラメータは、タスクの存続期間は設定されたままであるという点において永続的です。SET_TASK_PARAMETERを使用してパラメータ値を設定した場合、このプロシージャをもう1回コールするまで、その値は変わりません。

手順3: 推奨事項の生成

タスクにワークロードをリンクし、適切なパラメータを設定したら、DBMS_ADVISOR.EXECUTE_TASKプロシージャを使用して推奨事項を生成できます。これらの推奨事項は、SQLアクセス・アドバイザ・リポジトリに格納されます。

推奨プロセスにより、複数の推奨事項が生成されます。各推奨事項には、1つ以上のアクションが指定されます。たとえば、1つの推奨事項には、複数のマテリアライズド・ビュー・ログの作成、マテリアライズド・ビューの作成、およびその分析による統計の収集が含まれます。

タスクの推奨事項は、簡単な提案から、一連の既存の実表のパーティション化や、索引、マテリアライズド・ビューおよびマテリアライズド・ビュー・ログなどの一連のデータベース・オブジェクトの実装を必要とする複雑なソリューションにまで及びます。アドバイザ・タスクが実行されると、SQLアクセス・アドバイザでは、収集されたデータとユーザー調整のタスク・パラメータが慎重に分析されます。分析の後、ユーザーが表示および実装できる構造化された推奨が形成されます。

推奨事項の生成の詳細は、「推奨事項の生成」を参照してください。

手順4: 推奨事項の表示と実装

SQLアクセス・アドバイザからの推奨事項は、次のいずれかの方法で表示できます。

- カタログ・ビューを使用

- DBMS_ADVISOR.GET_TASK_SCRIPTプロシージャを使用してスクリプトを生成

SQLアクセス・アドバイザの処理が完了したら、Enterprise Managerで推奨事項を表示できます。推奨事項を表示するためにカタログ・ビューを使用する方法の詳細は、「推奨事項の表示」を参照してください。スクリプトの作成方法の詳細は、「SQLスクリプトの生成」を参照してください。

すべての推奨事項を受け入れる必要はありません。推奨事項のスクリプトに含める推奨事項をマークできます。ただし、実表のパーティション化が推奨された場合、一部の推奨事項はそれ以外の推奨事項に依存します。たとえば、索引の実表に対するパーティション推奨事項を実装しなければ、ローカル索引も実装できません。

最終手順では、推奨事項を実装し、問合せのパフォーマンスが向上したかどうかを検証します。

18.1.1.1 SQLアクセス・アドバイザ・リポジトリ

SQLアクセス・アドバイザによって生成されたすべての必要情報は、データベース・ディクショナリの一部であるアドバイザ・リポジトリに格納されます。リポジトリを使用する利点は、次のとおりです。

- SQLアクセス・アドバイザの完全なワークロードが収集されます。

- 履歴データがサポートされます。

- サーバーによって管理されます。

18.2 SQLアクセス・アドバイザの使用

この項では、SQLアクセス・アドバイザに関する一般情報およびSQLアクセス・アドバイザを使用するために必要な手順について説明します。この項の内容は次のとおりです。

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

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

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

- SQLアクセス・アドバイザのワークロード

- 推奨事項の処理

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

- タスクの管理

- SQLアクセス・アドバイザの定数の使用方法

関連項目:
Oracle Enterprise ManagerでSQLアクセス・アドバイザを使用する方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

18.2.1SQLアクセス・アドバイザの使用手順

図18-2に、SQLアクセス・アドバイザの使用手順、SQLアクセス・アドバイザのすべてのパラメータの概要およびどの時点でそれらのパラメータを使用するのが適切かを示します。

図18-2 SQLアクセス・アドバイザのフローチャート

18.2.2 SQLアクセス・アドバイザの使用に必要な権限

SQLアクセス・アドバイザを管理または使用するには、ADVISOR権限が必要です。ワークロードを処理する際、SQLアクセス・アドバイザは表と列の参照を識別するために各文の検証を試みます。検証では、本来のユーザーが文を実行する場合と同様に各文が処理されます。

ユーザーに特定の表に対するSELECT権限がない場合、SQLアクセス・アドバイザはその表を参照している文をバイパスします。この動作によって、多くの文が分析から除外される可能性があります。SQLアクセス・アドバイザがワークロードのすべての文を除外した場合、ワークロードは無効になります。SQLアクセス・アドバイザは、次のメッセージを戻します。

QSM-00774, there are no SQL statements to process for task TASK_NAME

重要なワークロード問合せが欠落しないようにするには、現在のデータベース・ユーザーが、マテリアライズド・ビューの分析対象の表に対するSELECT権限を持っている必要があります。これらの表では、ロールを通じてこれらのSELECT権限を取得することはできません。

また、SQLチューニング・セット・オブジェクトのワークロードを作成および管理するには、ADMINISTER SQL TUNING SET権限も必要です。他のユーザーが所有するSQLチューニング・セットでアドバイザを実行するには、ADMINISTER ANY SQL TUNING SET権限が必要です。

18.2.3 タスクとテンプレートの設定

この項では、タスクとテンプレートの設定に関する次の側面について説明します。

- タスクの作成

- テンプレートの使用方法

- テンプレートの作成

18.2.3.1 タスクの作成

タスクでは、アドバイザが分析する内容と分析結果の格納場所を定義します。ユーザーは、各タスクが特化した任意の数のタスクを作成できます。これらすべてのタスクは同じアドバイザ・タスク・モデルに基づいており、同じリポジトリを共有します。

タスクを作成するには、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);

次に、このプロシージャの使用例を示します。

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プロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.3.2 テンプレートの使用方法

タスクまたはワークロードの理想的な構成が判明した場合は、その構成をテンプレートとして保存しておき、今後のタスクおよびワークロードのベースとして使用できます。

タスクまたはワークロードをテンプレートとして設定すると、今後のタスクの作成で、インテリジェントな出発点またはテンプレートとして使用できます。テンプレートを設定することにより、チューニング分析の実行時間を短縮できます。また、このアプローチにより、ビジネス・オペレーションに適合したチューニング分析が可能になります。

テンプレートからタスクを作成するには、新しいタスクの作成時に使用するテンプレートを指定します。このとき、SQLアクセス・アドバイザは、新しく作成されたタスクにテンプレートからデータおよびパラメータ設定をコピーします。また、既存のタスクをテンプレートとして設定するには、タスクの作成時にテンプレート属性を設定するか、後でUPDATE_TASK_ATTRIBUTEプロシージャを使用します。

タスクをテンプレートとして使用するには、新しいタスクの作成時にタスクを使用することをSQLアクセス・アドバイザに通知します。このとき、SQLアクセス・アドバイザは、新しく作成されたタスクにテンプレートのデータおよびパラメータ設定をコピーします。または、コマンドラインまたはEnterprise Managerでテンプレートの属性を設定して、既存のタスクをテンプレートとして設定することもできます。

18.2.3.3 テンプレートの作成

テンプレートの作成例は、次のとおりです。

1. MY_TEMPLATEと呼ばれるテンプレートを作成します。

VARIABLE template_id NUMBER;
VARIABLE template_name VARCHAR2(255);
EXECUTE :template_name := 'MY_TEMPLATE';
EXECUTE DBMS_ADVISOR.CREATE_TASK('SQL Access Advisor',:template_id, -
:template_name, is_template => 'TRUE');

2. テンプレートのパラメータを設定します。たとえば、次の例では、推奨される索引とマテリアライズド・ビューのネーミング規則とデフォルトの表領域を設定します。

-- set naming conventions for recommended indexes/mvs
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'INDEX_NAME_TEMPLATE', 'SH_IDX$$_<SEQ>');

EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'MVIEW_NAME_TEMPLATE', 'SH_MV$$_<SEQ>');

-- set default tablespace for recommended indexes/mvs
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'DEF_INDEX_TABLESPACE', 'SH_INDEXES');

EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'DEF_MVIEW_TABLESPACE', 'SH_MVIEWS');

3. これで、このテンプレートは、次のようにタスクを作成するときの開始ポイントとして使用できます。

VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'MYTASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK('SQL Access Advisor', :task_id, -
:task_name, template=>'MY_TEMPLATE');

次の例では、事前定義済テンプレートSQLACCESS_WAREHOUSEを使用します。詳細は、表18-3を参照してください。

EXECUTE DBMS_ADVISOR.CREATE_TASK('SQL Access Advisor', -
:task_id, :task_name,  template=>'SQLACCESS_WAREHOUSE');

18.2.4 SQLアクセス・アドバイザのワークロード

SQLアクセス・アドバイザでは、異なるタイプのワークロードがサポートされます。この項では、ワークロードの管理に関する次の側面について説明します。

- SQLチューニング・セットのワークロード

- SQLチューニング・セットの使用方法

- タスクとワークロードのリンク

18.2.4.1 SQLチューニング・セットのワークロード

SQLアクセス・アドバイザの入力ワークロード・ソースは、SQLチューニング・セットです。SQLチューニング・セットの使用による重要な利点は、SQLチューニング・セットが個別のエンティティとして格納されるため、多くのアドバイザ・タスク間で簡単に共有できることです。SQLチューニング・セット・オブジェクトがアドバイザ・タスクによって参照された後は、すべてのアドバイザ・タスクからデータに対する依存性が削除されるまで、データを削除または変更できません。ワークロード参照が削除されるのは、親アドバイザ・タスクが削除された場合、またはアドバイザ・タスクからワークロード参照がユーザーによって手動で削除された場合です。

SQLアクセス・アドバイザのパフォーマンスは、実際の使用状況に基づいたワークロードが使用可能な場合に最も高くなります。複数のワークロードをSQLチューニング・セットとして保存することにより、長期およびデータベース・インスタンスの起動から停止までの全ライフサイクルにわたって、実際のデータ・ウェアハウスまたはトランザクション処理環境の様々な使用状況を参照できます。

18.2.4.2 SQLチューニング・セットの使用方法

SQLチューニング・セットのワークロードは、DBMS_SQLTUNEパッケージを使用して実装します。SQLチューニング・セットの作成および管理の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

DBMS_ADVISORパッケージは、既存のSQLワークロード・オブジェクトをSQLチューニング・セットに移行するために、SQLワークロード・データをユーザーが指定したSQLチューニング・セットにコピーするプロシージャを提供します。このプロシージャを使用するには、SQLチューニング・セットの必要な権限とADVISOR権限が必要です。

この構文は、次のとおりです。

DBMS_ADVISOR.COPY_SQLWKLD_TO_STS (
workload_name        IN VARCHAR2,
sts_name             IN VARCHAR2,
import_mode          IN VARCHAR2 := 'NEW');

次に使用例を示します。

EXECUTE DBMS_ADVISOR.COPY_SQLWKLD_TO_STS('MYWORKLOAD','MYSTS','NEW');

COPY_SQLWKLD_TO_STSプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.4.3 タスクとワークロードのリンク

推奨プロセスを開始するには、あらかじめSQLチューニング・セットにタスクをリンクしておく必要があります。そのためには、ADD_STS_REFプロシージャを使用して、タスクとチューニング・セットをそれぞれの名前を使用してリンクします。このプロシージャは、アドバイザ・タスクとチューニング・セット間のリンクを確立します。リンクが定義された後は、削除または更新されないようにSQLチューニング・セットが保護されます。この構文は、次のとおりです。

DBMS_ADVISOR.ADD_STS_REF (task_name IN VARCHAR2,

sts_owner IN VARCHAR2,
sts_name  IN VARCHAR2);

sts_ownerパラメータはNULLでもかまいませんが、その場合、STSの所有者は現在のユーザーであると想定されます。

次の例では、作成したタスクMYTASKと現在のユーザーのSQLチューニング・セットMYWORKLOADをリンクします。

EXECUTE DBMS_ADVISOR.ADD_STS_REF('MYTASK', null, 'MYWORKLOAD');

ADD_STS_REFプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.4.3.1 SQLチューニング・セットのワークロードとタスク間のリンクの削除

タスクまたはSQLチューニング・セット・ワークロードを削除するには、最初に、DELETE_STS_REFプロシージャを使用してタスクとワークロード間のリンクを削除する必要があります(リンクが設定されている場合)。次の例では、タスクMYTASKと現在のユーザーのSQLチューニング・セットMYWORKLOADの間のリンクを削除します。

EXECUTE DBMS_ADVISOR.DELETE_STS_REF('MYTASK', null, 'MYWORKLOAD');

18.2.5 推奨事項の処理

この項では、推奨事項の処理に関する次の側面について説明します。

- 推奨事項とアクション

- 推奨オプション

- 評価モード

- 推奨事項分析中の中間結果の表示

- 推奨事項の生成

- 推奨事項の表示

- 推奨プロセスの停止

- 推奨事項のマーキング

- 推奨事項の変更

- SQLスクリプトの生成

- スクリプトにパーティション推奨事項が含まれる場合の特別な考慮事項

- 推奨事項が必要なくなった場合

18.2.5.1 推奨事項とアクション

SQLアクセス・アドバイザは複数の推奨事項を提供し、各推奨事項には1つ以上の個別のアクションが含まれます。一般に、各推奨事項は、1つ以上の問合せに対して利点をもたらします。利点を最大限に得るには、推奨事項の個々のアクションをすべてまとめて実装する必要があります。複数の推奨事項でアクションを共有できます。

たとえば、CREATE INDEX文は複数の問合せに対して利点をもたらしますが、それらの問合せの一部は、他のCREATE MATERIALIZED VIEW文から利点を得ることがあります。その場合、アドバイザは2つの推奨事項を生成します。最適に実行するのに、索引のみを必要とする問合せセット用と、索引とマテリアライズド・ビューの両方を必要とする問合せセット用です。

パーティションの推奨事項は、特殊なタイプの推奨です。SQLアクセス・アドバイザは、指定された実表のパーティション化によってワークロードのパフォーマンスが向上すると判断した場合、その実表を参照する問合せが含まれるすべての推奨事項にパーティション・アクションを追加します。この方法により、索引およびマテリアライズド・ビューの推奨事項が、適切にパーティション化された表に実装されます。

18.2.5.2 推奨オプション

アドバイザで推奨事項を生成するには、最初にSET_TASK_PARAMETERプロシージャを使用してタスクのパラメータを定義する必要があります。パラメータの定義がない場合、データベースはデフォルトを使用します。

タスクのパラメータを設定するには、SET_TASK_PARAMETERプロシージャを使用します。この構文は、次のとおりです。

DBMS_ADVISOR.SET_TASK_PARAMETER (
task_name           IN VARCHAR2,
parameter           IN VARCHAR2,
value               IN [VARCHAR2 | NUMBER]);

タスク・パラメータは多数存在するため、関連するパラメータを識別しやすいように、これらのカテゴリ分けした表を表18-1に示します。ワークロード・フィルタのタスク・パラメータはすべて非推奨になっていることに注意してください。

表18-1 アドバイザのタスク・パラメータのタイプとその使用方法

ワークロード・フィルタ

タスク構成

スキーマ属性

推奨オプション

END_TIME

DAYS_TO_EXPIRE

DEF_INDEX_OWNER

ANALYSIS_SCOPE

INVALID_ACTION_LIST

JOURNALING

DEF_INDEX_TABLESPACE

COMPATIBILITY

INVALID_MODULE_LIST

REPORT_DATE_FORMAT

DEF_MVIEW_OWNER

CREATION_COST

INVALID_SQLSTRING_LIMIT

DEF_MVIEW_TABLESPACE

DML_VOLATILITY

INVALID_TABLE_LIST

DEF_MVLOG_TABLESPACE

LIMIT_PARTITION_SCHEMES

INVALID_USERNAME_LIST

DEF_PARTITION_TABLESPACE

MODE

RANKING_MEASURE

INDEX_NAME_TEMPLATE

PARTITIONING_TYPES

SQL_LIMIT

MVIEW_NAME_TEMPLATE

REFRESH_MODE

START_TIME

STORAGE_CHANGE

TIME_LIMIT

USE_SEPARATE_TABLESPACES

VALID_ACTION_LIST

WORKLOAD_SCOPE

VALID_MODULE_LIST

VALID_SQLSTRING_LIST

VALID_TABLE_LIST

VALID_USERNAME_LIST

次の例では、タスクMYTASKの記憶域変更が100MBに設定されています。これは、推奨事項の追加領域が100MBであることを示しています。値が0の場合は、追加領域を割り当てることができません。マイナス値は、指定した量だけアドバイザが現在の領域使用量を削減する必要があることを示しています。

EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER('MYTASK','STORAGE_CHANGE', 100000000);

次の例では、SH.SALESおよびSH.CUSTOMERS表を構成していないすべての問合せを、フィルタで除外するようにVALID_TABLE_LISTパラメータを設定します。

EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
'MYTASK', 'VALID_TABLE_LIST', 'SH.SALES, SH.CUSTOMERS');

SET_TASK_PARAMETERプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.5.3 評価モード

SQLアクセス・アドバイザは、問題解決モードと評価モードの2つのモードで動作します。SQLアクセス・アドバイザは、デフォルトでは、アクセス方法の問題を解決するために、索引構造、パーティション、マテリアライズド・ビューおよびマテリアライズド・ビュー・ログの拡張を求めます。たとえば、問題解決モードで実行すると、新しい索引の作成やマテリアライズド・ビュー・ログへの新しい列の追加などが推奨されます。

評価のみで実行すると、SQLアクセス・アドバイザは、指定されたワークロードによって使用されるアクセスの構造についてのみコメントします。評価のみの実行では、索引の保持やマテリアライズド・ビューの保持などの推奨のみとなります。評価モードでは、ワークロードがどの索引およびマテリアライズド・ビューを使用するのか正確に知ることができます。SQLアクセス・アドバイザは、既存の実表のパーティション化によるパフォーマンスへの影響は評価しません。

18.2.5.4 推奨事項分析中の中間結果の表示

SQLアクセス・アドバイザでは、分析操作中に中間結果を表示できるようになりました。以前は、分析操作の結果は、処理が完了するか、ユーザーが割り込むまで使用できませんでした。現在は、SQLアクセス・アドバイザ・タスクが実行中であっても、対応する推奨事項およびアクション表の結果にアクセスできます。その利点は、長時間続くタスクで、長時間にわたる実行が完了するのを待たずにタスクに割り込むことによって、最新の結果を受け取ることができるようになったことです。

最新の推奨事項セットを受け取るには、タスクに割り込む必要があります。この割込みによって、SQLアクセス・アドバイザは処理を停止し、タスクはINTERRUPTEDとマークされます。その時点で、推奨事項の属性を更新してスクリプトを生成できます。または、SQLアクセス・アドバイザに推奨プロセスを完了させることもできます。

中間結果は、その時点までのワークロードの内容に対する推奨事項であることに注意してください。推奨事項がワークロード全体の影響を受けやすいことが重要である場合は、タスクの実行を正常に完了させることをお薦めします。また、推奨プロセスの初期段階でアドバイザによって作成される推奨事項には、実表のパーティション化に関する推奨は含まれません。パーティション化分析では、パーティション化が有効かどうかを決定する前に、ワークロードの大部分を処理する必要があります。したがって、SQLアクセス・アドバイザが利点を検出した場合は、より遅い段階での中間結果に実表のパーティション化に関する推奨事項が含まれます。

18.2.5.5 推奨事項の生成

推奨事項を生成するには、タスク名を指定してEXECUTE_TASKプロシージャを使用します。プロシージャが終了した後、DBA_ADVISOR_LOG表をチェックし、実際の実行ステータスや、生成された推奨事項およびアクションの数を確認できます。{DBA, USER}_ADVISOR_RECOMMENDATIONSでは、タスク名で推奨項目の問合せができます。{DBA, USER}_ADVISOR_ACTIONSでは、これらの推奨事項のアクションをタスクごとに参照できます。

18.2.5.5.1 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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.5.6 推奨事項の表示

SQLアクセス・アドバイザによって生成された各推奨事項は、(DBA, USER)_ADVISOR_RECOMMENDATIONSなどのいくつかのカタログ・ビューを使用して表示できます。ただし、GET_TASK_SCRIPTプロシージャを使用するか、またはEnterprise ManagerでSQLアクセス・アドバイザを使用する方が簡単です。この場合、推奨事項がグラフィック表示され、推奨事項の利点を得るSQL文を簡単に参照するためのハイパーリンクが用意されています。SQLアクセス・アドバイザによって生成された各推奨事項は、その利点を得るSQL文にリンクされています。

次の例は、アドバイザの実行によって生成される推奨事項(rec_id)とそのランクおよび全利点を示します。ランクとは、推奨事項がサポートする問合せの重要性の尺度です。利点とは、推奨事項を使用したすべての問合せの実行コスト(オプティマイザのコストの観点から)における改善結果です。

VARIABLE workload_name VARCHAR2(255);
VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'MYTASK';
EXECUTE :workload_name := 'MYWORKLOAD';

SELECT REC_ID, RANK, BENEFIT
FROM USER_ADVISOR_RECOMMENDATIONS WHERE TASK_NAME = :task_name;

REC_ID       RANK    BENEFIT
---------- ---------- ----------
1          2       2754
2          3       1222
3          1       5499
4          4        594

推奨事項が役立つ問合せを確認するには、DBA_*およびUSER_ADVISOR_SQLA_WK_STMTSビューを使用します。事前コストと事後コストの数は、それぞれ推奨されたアクセス構造の変更がある場合とない場合とで見積られたオプティマイザのコスト(EXPLAIN PLANを参照)に関するものです。各問合せの推奨事項を表示するには、次の文を発行します。

SELECT sql_id, rec_id, precost, postcost,
(precost-postcost)*100/precost AS percent_benefit
FROM USER_ADVISOR_SQLA_WK_STMTS
WHERE TASK_NAME = :task_name AND workload_name = :workload_name;

SQL_ID     REC_ID    PRECOST   POSTCOST PERCENT_BENEFIT
---------- ---------- ---------- ---------- ---------------
121          1       3003        249      91.7082917
122          2       1404        182       87.037037
123          3       5503          4      99.9273124
124          4        730        136       81.369863

各推奨事項は1つ以上のアクションから構成されます。推奨事項の利点を得るには、これらのアクションをまとめて実装する必要があります。SQLアクセス・アドバイザでは、次のタイプのアクションを生成します。

- PARTITION BASE TABLE

- CREATE|DROP|RETAIN MATERIALIZED VIEW

- CREATE|ALTER|RETAIN MATERIALIZED VIEW LOG

- CREATE|DROP|RETAIN INDEX

- GATHER STATS

PARTITION BASE TABLEアクションは、既存のパーティション化されていない実表をパーティション化します。CREATEアクションは、新しいアクセス構造に対応します。RETAIN推奨事項は、既存のアクセス構造を維持する必要があることを示します。DROP推奨事項が生成されるのは、WORKLOAD_SCOPEパラメータがFULLに設定されている場合のみです。GATHER STATSアクションは、DBMS_STATSプロシージャへのコールを生成し、新しく生成されたアクセス構造に関する統計を収集します。複数の推奨事項が同じアクションを参照する場合があります。ただし、推奨事項のスクリプトの生成では、各アクションは1回のみ表示されます。

次の例では、この一連の推奨事項について個別アクションの数を確認できます。

SELECT 'Action Count', COUNT(DISTINCT action_id) cnt
FROM USER_ADVISOR_ACTIONS WHERE task_name = :task_name;

'ACTIONCOUNT        CNT
------------   --------
Action Count         20

-- see the actions for each recommendations
SELECT rec_id, action_id, SUBSTR(command,1,30) AS command
FROM user_advisor_actions WHERE task_name = :task_name
ORDER BY rec_id, action_id;

REC_ID  ACTION_ID COMMAND
---------- ---------- ------------------------------
1          5 CREATE MATERIALIZED VIEW LOG
1          6 ALTER MATERIALIZED VIEW LOG
1          7 CREATE MATERIALIZED VIEW LOG
1          8 ALTER MATERIALIZED VIEW LOG
1          9 CREATE MATERIALIZED VIEW LOG
1         10 ALTER MATERIALIZED VIEW LOG
1         11 CREATE MATERIALIZED VIEW
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にあります。その他すべての属性は、アクションごとに異なります。

表18-2に、SQLアクセス・アドバイザのアクション情報とそれに対応するDBA_ADVISOR_ACTIONS内の列を示します。表内の「MV」は、マテリアライズド・ビューを意味します。

表18-2 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

ターゲット表名

未使用

未使用

未使用

未使用

未使用

未使用

PARTITION TABLE

表名

RANGE、INTERVAL、LIST、HASH、RANGE-HASH、RANGE-LIST

パーティション化のパーティション・キー(列名または列名のリスト)

サブパーティション化のパーティション・キー(列名または列名のリスト)

SQL PARTITION句

SQL SUBPARTITION句

未使用

PARTITION INDEX

索引名

LOCAL、RANGE、HASH

パーティション化のパーティション・キー(列名のリスト)

未使用

SQL PARTITION句

未使用

未使用

PARTITION ON MATERIALIZED VIEW

MV名

RANGE、INTERVAL、LIST、HASH、RANGE-HASH、RANGE-LIST

パーティション化のパーティション・キー(列名または列名のリスト)

サブパーティション化のパーティション・キー(列名または列名のリスト)

SQL SUBPARTITION句

SQL SUBPARTITION句

未使用

RETAIN INDEX

索引名

未使用

ターゲット表

BITMAPまたはBTREE

索引列

未使用

索引の記憶域のサイズ(バイト単位)

RETAIN MATERIALIZED VIEW

MV名

未使用

REFRESH COMPLETEまたはREFRESH FAST

未使用

SQL SELECT文

未使用

MVの記憶域のサイズ(バイト単位)

RETAIN MATERIALIZED VIEW LOG

ターゲット表名

未使用

未使用

未使用

未使用

未使用

未使用

次のPL/SQLプロシージャは、推奨事項の属性の一部を出力できます。

CONNECT SH/SH;
CREATE OR REPLACE PROCEDURE show_recm (in_task_name IN VARCHAR2) IS
CURSOR curs IS
SELECT DISTINCT action_id, command, attr1, attr2, attr3, attr4
FROM user_advisor_actions
WHERE task_name = in_task_name
ORDER BY action_id;
v_action        number;
v_command     VARCHAR2(32);
v_attr1       VARCHAR2(4000);
v_attr2       VARCHAR2(4000);
v_attr3       VARCHAR2(4000);
v_attr4       VARCHAR2(4000);
v_attr5       VARCHAR2(4000);
BEGIN
OPEN curs;
DBMS_OUTPUT.PUT_LINE('=========================================');
DBMS_OUTPUT.PUT_LINE('Task_name = ' || in_task_name);
LOOP
FETCH curs INTO
v_action, v_command, v_attr1, v_attr2, v_attr3, v_attr4 ;
EXIT when curs%NOTFOUND;
DBMS_OUTPUT.PUT_LINE('Action ID: ' || v_action);
DBMS_OUTPUT.PUT_LINE('Command : ' || v_command);
DBMS_OUTPUT.PUT_LINE('Attr1 (name)      : ' || SUBSTR(v_attr1,1,30));
DBMS_OUTPUT.PUT_LINE('Attr2 (tablespace): ' || SUBSTR(v_attr2,1,30));
DBMS_OUTPUT.PUT_LINE('Attr3             : ' || SUBSTR(v_attr3,1,30));
DBMS_OUTPUT.PUT_LINE('Attr4             : ' || v_attr4);
DBMS_OUTPUT.PUT_LINE('Attr5             : ' || v_attr5);
DBMS_OUTPUT.PUT_LINE('----------------------------------------');
END LOOP;
CLOSE curs;
DBMS_OUTPUT.PUT_LINE('=========END RECOMMENDATIONS============');
END show_recm;
/
-- see what the actions are using sample procedure
set serveroutput on size 99999
EXECUTE show_recm(:task_name);
A fragment of a sample output from this procedure is as follows:
Task_name = MYTASK
Action ID: 1
Command : CREATE MATERIALIZED VIEW LOG
Attr1 (name)      : "SH"."CUSTOMERS"
Attr2 (tablespace):
Attr3             : ROWID, SEQUENCE
Attr4             :  INCLUDING NEW VALUES
Attr5             :
----------------------------------------
..
----------------------------------------
Action ID: 15
Command : CREATE MATERIALIZED VIEW
Attr1 (name)      : "SH"."SH_MV$$_0004"
Attr2 (tablespace): "SH_MVIEWS"
Attr3             : REFRESH FAST WITH ROWID
Attr4             : ENABLE QUERY REWRITE
Attr5             :
----------------------------------------
..
----------------------------------------
Action ID: 19
Command : CREATE INDEX
Attr1 (name)      : "SH"."SH_IDX$$_0013"
Attr2 (tablespace): "SH_INDEXES"
Attr3             : "SH"."SH_MV$$_0002"
Attr4             : BITMAP
Attr5             :

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

18.2.5.7 推奨プロセスの停止

EXECUTE_TASKプロシージャを使用してSQLアクセス・アドバイザの推奨事項を生成する際に、処理に時間がかかりすぎる場合は、CANCEL_TASKプロシージャをコールしてその推奨プロセスのtask_nameを渡すと、処理を停止できます。CANCEL_TASKを使用した場合、SQLアクセス・アドバイザの推奨事項はありません。そのため、推奨事項が必要な場合は、INTERRUPT_TASKプロシージャの使用を検討してください。

18.2.5.7.1 タスクへの割込み

INTERRUPT_TASKプロシージャを使用すると、アドバイザ操作は正常終了に達したものとして終了されます。これにより、ユーザーには、割込みポイントまでに形成された推奨事項が表示されます。

割り込まれたタスクは再開できません。この構文は、次のとおりです。

DBMS_ADVISOR.INTERRUPT_TASK (task_name IN VARCHAR2);

次に、このプロシージャの使用例を示します。

EXECUTE DBMS_ADVISOR.INTERRUPT_TASK ('MY_TASK');

18.2.5.7.2 タスクの取消

CANCEL_TASKプロシージャを使用すると、現在実行中の操作が終了します。この場合、アドバイザ操作がこのリクエストに応答するのに数秒かかることがあります。すべてのアドバイザ・タスクのプロシージャは同期操作であるため、操作を取り消すには、別のデータベース・セッションを使用する必要があります。

取消コマンドは、取り消された操作の開始前の状態にタスクを効率的にリストアします。このため、取り消されたタスクまたはデータ・オブジェクトは再開できません(ただし、DBMS_ADVISOR.RESET_TASKを使用してからタスクを再実行することで、タスクをリセットできます)。この構文は、次のとおりです。

DBMS_ADVISOR.CANCEL_TASK (task_name   IN  VARCHAR2);

次に、このプロシージャの使用例を示します。

EXECUTE DBMS_ADVISOR.CANCEL_TASK('MYTASK');

CANCEL_TASKプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.5.8 推奨事項のマーキング

デフォルトでは、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');

アドバイザにより、パーティション化されていない1つ以上の実表のパーティション化が推奨された場合、その推奨事項をスキップする前に慎重に検討してください。表のパーティション化スキームを変更すると、その表に定義されたすべての問合せ、索引およびマテリアライズド・ビューのコストに影響を及ぼします。このため、パーティション化の推奨事項をスキップした場合は、その表に対してアドバイザが行ったその他の推奨も最適ではありません。パーティション化を含めずにワークロードの推奨事項を確認するには、ANALYSIS_SCOPEパラメータを変更してパーティション化の推奨を除外し、アドバイザ・タスクをリセットして、再度タスクを実行します。

MARK_RECOMMENDATIONSプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.5.9 推奨事項の変更

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
推奨オブジェクトの表領域を指定します。

次の例では、推奨事項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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.5.10 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)を制御する複数のタスク・パラメータがあります。

次の例は、推奨事項のスクリプトが含まれるCLOBを生成する方法を示します。

EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT('MYTASK'),
'ADVISOR_RESULTS', 'advscript.sql');

スクリプトをファイルに保存するには、CREATE_FILEプロシージャにスクリプトの格納先を示すディレクトリ・パスを指定する必要があります。また、このディレクトリには読取りおよび書込み権限を付与する必要があります。次の例は、CLOBアドバイザ・スクリプトをファイルに保存する方法を示します。

-- create a directory and grant permissions to read/write to it
CONNECT SH/SH;
CREATE DIRECTORY ADVISOR_RESULTS AS '/mydir';
GRANT READ ON DIRECTORY ADVISOR_RESULTS TO PUBLIC;
GRANT WRITE ON DIRECTORY ADVISOR_RESULTS TO PUBLIC;

次の例は、このスクリプトによって生成されたスクリプトのフラグメントです。また、このスクリプトには、推奨されたアクセス構造に関する統計を収集するPL/SQLコールが含まれ、最後に推奨事項にIMPLEMENTEDとマークします。

Rem  Access Advisor V11.1.0.0.0 - Production
Rem
Rem  Username:        SH
Rem  Task:            MYTASK
Rem  Execution date:  15/08/2006 11:35
Rem
set feedback 1
set linesize 80
set trimspool on
set tab off
set pagesize 60
whenever sqlerror CONTINUE

CREATE MATERIALIZED VIEW LOG ON "SH"."PRODUCTS"
WITH ROWID, SEQUENCE("PROD_ID","PROD_SUBCATEGORY")
INCLUDING NEW VALUES;
ALTER MATERIALIZED VIEW LOG FORCE ON "SH"."PRODUCTS"
ADD ROWID, SEQUENCE("PROD_ID","PROD_SUBCATEGORY")
INCLUDING NEW VALUES;
..
CREATE MATERIALIZED VIEW "SH"."MV$$_00510002"
REFRESH FAST WITH ROWID
ENABLE QUERY REWRITE
AS SELECT SH.CUSTOMERS.CUST_STATE_PROVINCE C1, COUNT(*) M1 FROM
SH.CUSTOMERS WHERE (SH.CUSTOMERS.CUST_STATE_PROVINCE = 'CA') GROUP
BY SH.CUSTOMERS.CUST_STATE_PROVINCE;
BEGIN
DBMS_STATS.GATHER_TABLE_STATS('"SH"', '"MV$$_00510002"', NULL,
DBMS_STATS.AUTO_SAMPLE_SIZE);
END;
/
..
CREATE BITMAP INDEX "SH"."MV$$_00510004_IDX$$_00510013"
ON "SH"."MV$$_00510004" ("C4");
whenever sqlerror EXIT SQL.SQLCODE
BEGIN
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',1,'IMPLEMENTED');
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',2,'IMPLEMENTED');
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',3,'IMPLEMENTED');
DBMS_ADVISOR.MARK_RECOMMENDATION('"MYTASK"',4,'IMPLEMENTED');
END;
/

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

18.2.5.11 スクリプトにパーティション推奨事項が含まれる場合の特別な考慮事項

アドバイザは、問合せパフォーマンスを向上させるために既存のパーティション化されていない実表のパーティション化を推奨することがあります。アドバイザの実装スクリプトにパーティション推奨事項が含まれる場合は、次の問題に注意してください。

- 既存の表のパーティション化は複雑で広範な作業であるため、新しい索引やマテリアライズド・ビューを実装するよりも非常に時間がかかる場合があります。この推奨事項の実装には、時間を十分に取っておく必要があります。

- 索引およびマテリアライズド・ビューの推奨事項は、索引やビューを削除すれば簡単に元に戻せますが、表をパーティション化すると簡単には元の状態に戻せません。このため、パーティション化の推奨が含まれるスクリプトを実行する前に、データベースのバックアップが必要です。

- 実表を再パーティション化する際に、SQLアクセス・アドバイザのスクリプトにより、元の表の一時コピーが作成されますが、その一時コピーは元の表と同じ容量の領域を使用します。そのため、再パーティション化プロセスには、再パーティション化する最も大きな表のコピーをもう1つ作成できる程度に十分な空きディスク領域が必要です。実装スクリプトを実行する前に、使用可能な領域を確保しておく必要があります。
パーティション実装スクリプトは、索引、マテリアライズド・ビューおよび制約などの依存オブジェクトの移行を試みます。しかし、一部のオブジェクトは、自動的に移行できません。たとえば、再パーティション化された実表に対するPL/SQLストアド・プロシージャの定義は、通常では無効になり、再コンパイルが必要です。

- アドバイザのパーティション化の推奨を実装しない場合、同じスクリプトの同じ表に対するその他のすべての推奨事項(CREATE INDEXおよびCREATE MATERIALIZED VIEWなどの推奨)は、パーティション化の推奨に依存していることに注意してください。正確な推奨を得るには、パーティション化の推奨をスクリプトから単純に削除しないでください。かわりに、パーティション化を無効にしてアドバイザを再実行します(たとえば、ANALYSIS_SCOPEパラメータの値にTABLEキーワードを含めないなど)。

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

18.2.5.12 推奨事項が必要なくなった場合

RESET_TASKプロシージャは、タスクを初期の開始ポイントにリセットします。これにより、すべての推奨事項と中間データがタスクから削除されます。実際のタスクのステータスは、INITIALに設定されます。この構文は、次のとおりです。

DBMS_ADVISOR.RESET_TASK (task_name     IN VARCHAR2);

次に、このプロシージャの使用例を示します。

EXECUTE DBMS_ADVISOR.RESET_TASK('MYTASK');

RESET_TASKプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.6 クイック・チューニングの実行

単一のSQL文をチューニングするには、task_nameとSQL文を入力として受け入れるQUICK_TUNEプロシージャを使用します。このプロシージャは、タスクとワークロードを作成し、そのタスクを実行します。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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.7 タスクの管理

推奨事項を生成すると、常にタスクが作成されます。これらのタスクを管理しなければ、やがてタスク数が増加して記憶域が占領されます。また、一部のタスクを保持する場合は、誤って削除されないように保護します。タスクの管理では、次のような操作を実行できます。

- タスク属性の更新

- タスクの削除

- DAYS_TO_EXPIREパラメータの設定

18.2.7.1 タスク属性の更新

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

次の例では、タスク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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.7.2 タスクの削除

DELETE_TASKプロシージャでは、アドバイザの既存のタスクがリポジトリから削除されます。この構文は、次のとおりです。

DBMS_ADVISOR.DELETE_TASK (task_name  IN VARCHAR2);

次に、このプロシージャの使用例を示します。

EXECUTE DBMS_ADVISOR.DELETE_TASK('MYTASK');

DELETE_TASKプロシージャとそのパラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

18.2.7.3 DAYS_TO_EXPIREパラメータの設定

タスクまたはワークロード・オブジェクトを作成すると、DAYS_TO_EXPIREパラメータが30に設定されます。この値は、タスクまたはオブジェクトが自動的に削除されるまでの日数を示します。タスクまたはワークロードを無期限に保存し続けるには、DAYS_TO_EXPIREパラメータをADVISOR_UNLIMITEDに設定します。

18.2.8 SQLアクセス・アドバイザの定数の使用方法

SQLアクセス・アドバイザでは、表18-3に示されている定数を使用できます。

表18-3 SQLアクセス・アドバイザの定数

定数

説明

ADVISOR_ALL

すべての可能な値を示す値。文字列パラメータでは、この値はワイルドカード文字である%と同等です。

ADVISOR_CURRENT

現在の時刻またはアクティブな要素セットを示します。通常、これは時間パラメータで使用します。

ADVISOR_DEFAULT

デフォルト値を示します。通常、タスクまたはワークロード・パラメータの設定時に使用します。

ADVISOR_UNLIMITED

無制限な数値を表す値です。

ADVISOR_UNUSED

未使用のエンティティを表す値。パラメータがADVISOR_UNUSEDに設定されている場合、現在の処理はこのパラメータの影響を受けません。通常、この定数を使用して、パラメータに依存する処理でパラメータを未使用に設定します。

SQLACCESS_GENERAL

SQLアクセスの汎用タスク・テンプレートのデフォルト名を指定します。このテンプレートは、DML_VOLATILITYタスク・パラメータをTRUEに設定し、ANALYSIS_SCOPEをINDEX、MVIEWに設定します。

SQLACCESS_OLTP

SQLアクセスのOLTPタスク・テンプレートのデフォルト名を指定します。このテンプレートは、DML_VOLATILITYタスク・パラメータをTRUEに設定し、ANALYSIS_SCOPEをINDEXに設定します。

SQLACCESS_WAREHOUSE

SQLアクセスのウェアハウス・タスク・テンプレートのデフォルト名を指定します。このテンプレートは、DML_VOLATILITYタスク・パラメータをFALSEに設定し、EXECUTION_TYPEをINDEX、MVIEWに設定します。

SQLACCESS_ADVISOR

SQLアクセス・アドバイザの正式名称を格納します。プロシージャでアドバイザ名を引数として指定する必要がある場合、この名前を指定できます。

18.2.9 SQLアクセス・アドバイザの使用例

この項では、SQLアクセス・アドバイザの一般的な使用例について説明します。Oracle Databaseでは、この章の例を含むaadvdemo.sqlというスクリプトが提供されています。

18.2.9.1 ユーザー定義のワークロードの推奨事項

次の例では、ユーザー定義表SH.USER_WORKLOADからワークロードがインポートされます。次に、MYTASKというタスクが作成され、記憶域割当量が100MBに設定されて、タスクが実行されます。PL/SQLプロシージャによって、推奨事項が表示されます。最後に、推奨事項を実装するためのスクリプトが生成されます。

手順1: USER_WORKLOAD表の準備

SQL文を使用してUSER_WORKLOAD表をロードします。

CONNECT SH/SH;
-- aggregation with selection
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT   t.week_ending_day, p.prod_subcategory,
SUM(s.amount_sold) AS dollars, s.channel_id, s.promo_id
FROM sales s, times t, products p WHERE s.time_id = t.time_id
AND s.prod_id = p.prod_id AND s.prod_id > 10 AND s.prod_id < 50
GROUP BY t.week_ending_day, p.prod_subcategory,
s.channel_id, s.promo_id')
/

-- aggregation with selection
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT   t.calendar_month_desc, SUM(s.amount_sold) AS dollars
FROM     sales s , times t
WHERE    s.time_id = t.time_id
AND    s.time_id between TO_DATE(''01-JAN-2000'', ''DD-MON-YYYY'')
AND TO_DATE(''01-JUL-2000'', ''DD-MON-YYYY'')
GROUP BY t.calendar_month_desc')
/

--Load all SQL queries.
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc,
SUM(s.amount_sold) sales_amount
FROM sales s, times t, customers c, channels ch
WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id
AND s.channel_id = ch.channel_id AND c.cust_state_province = ''CA''
AND   ch.channel_desc IN (''Internet'',''Catalog'')
AND   t.calendar_quarter_desc IN (''1999-Q1'',''1999-Q2'')
GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc')
/

-- order by
INSERT INTO user_workload (username, module, action, priority, sql_text)
VALUES ('SH', 'Example1', 'Action', 2,
'SELECT c.country_id, c.cust_city, c.cust_last_name
FROM customers c WHERE c.country_id IN (52790, 52789)
ORDER BY c.country_id, c.cust_city, c.cust_last_name')
/
COMMIT;

CONNECT SH/SH;
set serveroutput on;

VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
VARIABLE workload_name VARCHAR2(255);

手順2: SQLチューニング・セットMYWORKLOADの作成

EXECUTE :workload_name := 'MYWORKLOAD';
EXECUTE DBMS_SQLTUNE.CREATE_SQLSET(:workload_name, 'test purposeV);

手順3: ユーザー定義表SH.USER_WORKLOADからのSQLチューニング・セットのロード

DECLARE
sqlset_cur DBMS_SQLTUNE.SQLSET_CURSOR;    /*a sqlset cursor variable*/
BEGIN
OPEN  sqlset_cur FOR
SELECT
SQLSET_ROW(null, sql_text, null, null, username, null,
null, 0,0,0,0,0,0,0,0,0,null, 0,0,0,0)
AS ROW
FROM USER_WORKLOAD;
DBMS_SQLTUNE.LOAD_SQLSET(:workload_name, sqlset_cur);
END;

手順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, 'ANALYSIS_SCOPE, INDEX');

手順6: SQLチューニング・セットとタスク間のリンクの作成

EXECUTE DBMS_ADVISOR.ADD_STS_REF(:task_name, :workload_name);

手順7: タスクの実行

EXECUTE DBMS_ADVISOR.EXECUTE_TASK(:task_name);

手順8: 推奨事項の表示

-- See the number of recommendations and the status of the task.

SELECT rec_id, rank, benefit
FROM user_advisor_recommendations WHERE task_name = :task_name;

詳細は、「推奨事項の表示」または「SQLスクリプトの生成」を参照してください。

-- See recommendation for each query.
SELECT sql_id, rec_id, precost, postcost,
(precost-postcost)*100/precost AS percent_benefit
FROM user_advisor_sqla_wk_stmts
WHERE task_name = :task_name AND workload_name = :workload_name;

-- See the actions for each recommendations.
SELECT rec_id, action_id, SUBSTR(command,1,30) AS command
FROM user_advisor_actions
WHERE task_name = :task_name
ORDER BY rec_id, action_id;

-- See what the actions are using sample procedure.
SET SERVEROUTPUT ON SIZE 99999
EXECUTE show_recm(:task_name);

手順9: 推奨事項を実装するためのスクリプトの生成

EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT(:task_name),
'ADVISOR_RESULTS', 'Example1_script.sql');

18.2.9.2 タスク・テンプレートを使用した推奨事項の生成

次の例では、テンプレートを作成し、それを使用してタスクを作成します。次にこのタスクを使用して、「ユーザー定義のワークロードの推奨事項」と同様に、ユーザー定義表から推奨事項が生成されます。

CONNECT SH/SH;
VARIABLE template_id NUMBER;
VARIABLE template_name VARCHAR2(255);

手順1: テンプレートMY_TEMPLATEの作成

EXECUTE :template_name := 'MY_TEMPLATE';

EXECUTE DBMS_ADVISOR.CREATE_TASK ( -
'SQL Access Advisor',:template_id, :template_name, is_template=>'TRUE');

手順2: テンプレート・パラメータの設定

推奨される索引およびマテリアライズド・ビューのネーミング規則を設定します。

EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name,  'INDEX_NAME_TEMPLATE', 'SH_IDX$$_<SEQ>');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'MVIEW_NAME_TEMPLATE', 'SH_MV$$_<SEQ>');

--Set default owners for recommended indexes/materialized views.
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'DEF_INDEX_OWNER', 'SH');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'DEF_MVIEW_OWNER', 'SH');

--Set default tablespace for recommended indexes/materialized views.
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'DEF_INDEX_TABLESPACE', 'SH_INDEXES');
EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER ( -
:template_name, 'DEF_MVIEW_TABLESPACE', 'SH_MVIEWS');

手順3: テンプレートを使用したタスクの作成

VARIABLE task_id NUMBER;

VARIABLE task_name VARCHAR2(255);
EXECUTE :task_name := 'MYTASK';
EXECUTE DBMS_ADVISOR.CREATE_TASK ( -
'SQL Access Advisor', :task_id, :task_name, template => 'MY_TEMPLATE');

--See the parameter settings for task
SELECT parameter_name, parameter_value
FROM user_advisor_parameters
WHERE task_name = :task_name AND (parameter_name LIKE '%MVIEW%'
OR parameter_name LIKE '%INDEX%');

手順4: SQLチューニング・セットMYWORKLOADの作成

EXECUTE :workload_name := 'MYWORKLOAD';
EXECUTE DBMS_SQLTUNE.CREATE_SQLSET(:workload_name, 'test_purpose');

手順5: ユーザー定義表SH.USER_WORKLOADからのSQLチューニング・セットのロード

DECLARE
sqlset_cur DBMS_SQLTUNE.SQLSET_CURSOR;  /*a sqlset cursor variable*/
BEGIN
OPEN sqlset_cur FOR
SELECT
SQLSET_ROW(null,sql_text,null,null,username, null, null, 0,0,0,0,0,0,0,0,0,
null,0,0,00) AS row
FROM user_workload;
DBMS_SQLTUNE.LOAD_SQLSET(:workload_name, sqlsetcur);
END;

手順6: ワークロードとタスクの間のリンクの作成

EXECUTE DBMS_ADVISOR.ADD_STS_REF(:task_name, :workload_name);

手順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');

18.2.9.3 索引およびマテリアライズド・ビューの現在の使用状況の評価

この例では、SQLアクセス・アドバイザを使用して、既存の索引およびマテリアライズド・ビューの使用状況を評価する方法を示します。「ユーザー定義のワークロードの推奨事項」に記載されているように、ワークロードをUSER_WORKLOAD表にロードするとします。特定のワークロードによって使用されている索引およびマテリアライズド・ビューは、SQLアクセス・アドバイザの推奨事項でRETAINアクションとして表示されます。

VARIABLE task_id NUMBER;
VARIABLE task_name VARCHAR2(255);
VARIABLE workload_name VARCHAR2(255);

手順1: SQLチューニング・セットWORKLOADの作成

EXECUTE :workload_name := 'MYWORKLOAD';

EXECUTE DBMS_SQLTUNE.CREATE_SQLSET(:workload_name, 'test_purpose');

手順2: ユーザー定義表SH.USER_WORKLOADからのSQLチューニング・セットのロード

DECLARE
sqlset_cur DBMS_SQLTUNE.SQLSET_CURSOR;  /*a sqlset cursor variable*/
BEGIN
OPEN sqlset_cur FOR
SELECT
SQLSET_ROW(null,sql_text,null,null,username, null, null, 0,0,0,0,0,0,0,0,0,
null, 0,0,0,0)
AS ROW
FROM user_workload;
DBMS_SQLTUNE.LOAD_SQLSET(:workload_name, :sqlsetcur);
END;

手順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_STS_REF(:task_name, :workload_name);

手順5: EVALUATION ONLYタスクを示すタスク・パラメータの設定

EXECUTE DBMS_ADVISOR.SET_TASK_PARAMETER (:task_name, 'EVALUATION_ONLY', 'TRUE');

手順6: タスクの実行

EXECUTE DBMS_ADVISOR.EXECUTE_TASK(:task_name);

手順7: 評価結果の表示

--See the number of recommendations and the status of the task.

SELECT rec_id, rank, benefit
FROM user_advisor_recommendations WHERE task_name = :task_name;

--See the actions for each recommendation.
SELECT rec_id, action_id, SUBSTR(command,1,30) AS command, attr1 AS name
FROM user_advisor_actions WHERE task_name = :task_name
ORDER BY rec_id, action_id;

18.3 高速リフレッシュとクエリー・リライトのためのマテリアライズド・ビューのチューニング

高速リフレッシュおよびクエリー・リライトのために最適化されたマテリアライズド・ビューを作成するには、いくつかのDBMS_MVIEW プロシージャが役立ちます。EXPLAIN_MVIEWプロシージャは、マテリアライズド・ビューが高速リフレッシュ可能かどうか、また、通常のクエリー・リライトを実行できるかどうかを示します。EXPLAIN_REWRITEは、クエリー・リライトが行われるかどうかを示します。ただし、これらのプロシージャでは、高速リフレッシュやクエリー・リライトを実行する方法は示されません。

マテリアライズド・ビューをさらに使いやすくするため、TUNE_MVIEWプロシージャでは、CREATE MATERIALIZED VIEW文を最適化する方法と、高速リフレッシュや通常のクエリー・リライトのためのその他の要件(マテリアライズド・ビュー・ログやリライト同値化関係など)を満たす方法が示されます。TUNE_MVIEWにより、CREATE MATERIALIZED VIEW文の分析と処理が行われ、2つの出力結果(マテリアライズド・ビューの実装とCREATE MATERIALIZED VIEW操作の取消し)が生成されます。この2セットの出力結果は、ビューまたはSQLアクセス・アドバイザによって作成される外部スクリプト・ファイルを通じてアクセスできます。これらの外部スクリプト・ファイルを実行すると、マテリアライズド・ビューを実装できます。

TUNE_MVIEWプロシージャを使用すると、マテリアライズド・ビューおよび必要なコンポーネント(マテリアライズド・ビュー・ログなど)が適切に作成されるため、マテリアライズド・ビューの詳細を理解する必要なしに、アプリケーションにマテリアライズド・ビューを作成できます。

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

18.3.1 DBMS_ADVISOR.TUNE_MVIEWプロシージャ

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

- TUNE_MVIEWの構文と操作

- TUNE_MVIEWの出力結果へのアクセス

18.3.1.1 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)は、不要と判断した場合にマテリアライズド・ビューとリライト同値化を削除するためのものです。

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データベース・インスタンスに存在する場合もあります。

18.3.1.2 TUNE_MVIEWの出力結果へのアクセス

TUNE_MVIEWの出力結果へのアクセス方法は2通りあります。

- DBMS_ADVISOR.GET_TASK_SCRIPTファンクションとDBMS_ADVISOR.CREATE_FILEプロシージャによるスクリプト生成

- USER_TUNE_MVIEWビューまたはDBA_TUNE_MVIEWビューの使用方法

18.3.1.2.1 USER_TUNE_MVIEWビューおよびDBA_TUNE_MVIEWビュー

TUNE_MVIEWを実行すると、結果はSQLアクセス・アドバイザのリポジトリ表に出力され、データ・ディクショナリのビューであるUSER_TUNE_MVIEWとDBA_TUNE_MVIEWからアクセスできます。詳細は、『Oracle Databaseリファレンス』を参照してください。

18.3.1.2.2 DBMS_ADVISORファンクションおよびプロシージャによるスクリプトの生成

推奨事項の実行スクリプトを生成する最も簡単な方法は、DBMS_ADVISOR.GET_TASK_SCRIPTプロシージャを使用することです。次に簡単な例を示します。最初に、結果を格納するディレクトリを定義する必要があります。

CREATE DIRECTORY TUNE_RESULTS AS  '/tmp/script_dir';
GRANT READ, WRITE ON DIRECTORY TUNE_RESULTS TO PUBLIC;

次に、実装スクリプトと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プロシージャの使用例を次にいくつか示します。

例18-1 高速リフレッシュのための問合せ定義の最適化

この例では、TUNE_MVIEWによって問合せ定義を高速リフレッシュできるように変更する方法を示します。CREATE MATERIALIZED VIEW文は、変数create_mv_ddlで定義されています。これに、FAST REFRESH句が含まれています。問合せ定義に1つの問合せブロックがあり、その集計列SUM(s.amount_sold)には高速リフレッシュをサポートするための必須集計列がありません。TUNE_MVIEW文をこのMATERIALIZED VIEW CREATE文とともに実行すると、その結果のマテリアライズド・ビューの推奨事項は高速リフレッシュ可能です。

VARIABLE task_cust_mv VARCHAR2(30);
VARIABLE create_mv_ddl VARCHAR2(4000);
EXECUTE :task_cust_mv := 'cust_mv';

EXECUTE :create_mv_ddl := '
CREATE MATERIALIZED VIEW cust_mv
REFRESH FAST
DISABLE QUERY REWRITE AS
SELECT s.prod_id, s.cust_id, SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id
GROUP BY s.prod_id, s.cust_id';

EXECUTE DBMS_ADVISOR.TUNE_MVIEW(:task_cust_mv, :create_mv_ddl);

cust_mvの元の問合せ定義は、高速リフレッシュを可能にするために集計列が追加されて、変更されています。

TUNE_MVIEWからの出力には、次のように、最適化されたマテリアライズド・ビューの問合せ定義が含まれます。

CREATE MATERIALIZED VIEW SH.CUST_MV
REFRESH FAST WITH ROWID
DISABLE QUERY REWRITE AS
SELECT SH.SALES.PROD_ID C1, SH.CUSTOMERS.CUST_ID C2,
SUM("SH"."SALES"."AMOUNT_SOLD") M1,
COUNT("SH"."SALES"."AMOUNT_SOLD") M2,
COUNT(*) M3
FROM SH.SALES, SH.CUSTOMERS
WHERE SH.CUSTOMERS.CUST_ID = SH.SALES.CUST_ID
GROUP BY SH.SALES.PROD_ID, SH.CUSTOMERS.CUST_ID;

UNDOの出力は次のとおりです。

DROP MATERIALIZED VIEW SH.CUST_MV;

例18-2 USER_TUNE_MVIEWビューからのIMPLEMENTATIONの出力へのアクセス

SELECT STATEMENT FROM USER_TUNE_MVIEW
WHERE TASK_NAME= :task_cust_mv AND SCRIPT_TYPE='IMPLEMENTATION';

例18-3 スクリプト・ファイルへの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');

例18-4 複数のマテリアライズド・ビューの作成によるクエリー・リライトの有効化

この例では、クエリー・リライトでサポートされない集合演算子UNIONを含むマテリアライズド・ビューの問合せ定義を、複数のサブマテリアライズド・ビューに分解し、クエリー・リライトを可能にします。入力ディテール表は、sales、customersおよびcountriesです。これらの表には、マテリアライズド・ビュー・ログがありません。最初に、TUNE_MVIEW文をcreate_mv_ddl変数で定義されているCREATE MATERIALIZED VIEW文とともに実行する必要があります。

EXECUTE :task_cust_mv := 'cust_mv2';

EXECUTE :create_mv_ddl := '
CREATE MATERIALIZED VIEW cust_mv
ENABLE QUERY REWRITE AS
SELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amount
FROM sales s, customers cs, countries cn
WHERE s.cust_id = cs.cust_id AND cs.country_id = cn.country_id
AND cn.country_name IN (''USA'',''Canada'')
GROUP BY s.prod_id, s.cust_id
UNION
SELECT s.prod_id, s.cust_id, COUNT(*) cnt, SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (1005,1010,1012)
GROUP BY s.prod_id, s.cust_id';

マテリアライズド・ビューの問合せ定義には、通常のクエリー・リライトをサポートしないUNION集合演算子が含まれています。ただし、これを複数のマテリアライズド・ビューに分解すると、クエリー・リライトが可能になります。通常のクエリー・リライトをサポートするには、MATERIALIZED VIEWの問合せ定義を分解します。

EXECUTE DBMS_ADVISOR.TUNE_MVIEW(:task_cust_mv, :create_mv_ddl);

TUNE_MVIEWからの次の推奨事項には、マテリアライズド・ビュー・ログと複数のマテリアライズド・ビューが含まれます。

CREATE MATERIALIZED VIEW LOG ON "SH"."CUSTOMERS"
WITH ROWID, SEQUENCE("CUST_ID")
INCLUDING NEW VALUES;

ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."CUSTOMERS"
ADD ROWID, SEQUENCE("CUST_ID")
INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW LOG ON
"SH"."SALES"
WITH ROWID, SEQUENCE("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES;

ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."SALES"
ADD ROWID, SEQUENCE("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW LOG ON
"SH"."COUNTRIES"
WITH ROWID, SEQUENCE("COUNTRY_ID","COUNTRY_NAME")
INCLUDING NEW VALUES;

ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."COUNTRIES"
ADD ROWID, SEQUENCE("COUNTRY_ID","COUNTRY_NAME")
INCLUDING NEW VALUES;

ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."CUSTOMERS"
ADD ROWID, SEQUENCE("CUST_ID","COUNTRY_ID")
INCLUDING NEW VALUES;

ALTER MATERIALIZED VIEW LOG FORCE ON
"SH"."SALES"
ADD ROWID, SEQUENCE("PROD_ID","CUST_ID","AMOUNT_SOLD")
INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW SH.CUST_MV$SUB1
REFRESH FAST WITH ROWID ON COMMIT
ENABLE QUERY REWRITE
AS SELECT SH.SALES.PROD_ID C1, SH.CUSTOMERS.CUST_ID C2,
SUM("SH"."SALES"."AMOUNT_SOLD")
M1, COUNT("SH"."SALES"."AMOUNT_SOLD") M2, COUNT(*) M3 FROM SH.SALES,
SH.CUSTOMERS WHERE SH.CUSTOMERS.CUST_ID = SH.SALES.CUST_ID AND
(SH.SALES.CUST_ID IN (1012, 1010, 1005))
GROUP BY SH.SALES.PROD_ID, SH.CUSTOMERS.CUST_ID;

CREATE MATERIALIZED VIEW SH.CUST_MV$SUB2
REFRESH FAST WITH ROWID ON COMMIT
ENABLE QUERY REWRITE
AS SELECT SH.SALES.PROD_ID C1, SH.CUSTOMERS.CUST_ID C2,
SH.COUNTRIES.COUNTRY_NAME  C3, SUM("SH"."SALES"."AMOUNT_SOLD") M1, COUNT("SH"."SALES".
"AMOUNT_SOLD")
M2, COUNT(*) M3 FROM SH.SALES, SH.CUSTOMERS, SH.COUNTRIES WHERE
SH.CUSTOMERS.CUST_ID        = SH.SALES.CUST_ID AND SH.COUNTRIES.COUNTRY_ID = SH.CUSTOMERS.COUNTRY_ID
AND (SH.COUNTRIES.COUNTRY_NAME IN ('USA', 'Canada')) GROUP BY
SH.SALES.PROD_ID,
SH.CUSTOMERS.CUST_ID, SH.COUNTRIES.COUNTRY_NAME;

CREATE MATERIALIZED VIEW SH.CUST_MV
REFRESH FORCE WITH ROWID
ENABLE QUERY REWRITE
AS  (SELECT "CUST_MV$SUB2"."C1" "PROD_ID","CUST_MV$SUB2"."C2"
"CUST_ID",SUM("CUST_MV$SUB2"."M3")
"CNT",SUM("CUST_MV$SUB2"."M1") "SUM_AMOUNT" FROM "SH"."CUST_MV$SUB2"
"CUST_MV$SUB2" GROUP BY "CUST_MV$SUB2"."C1","CUST_MV$SUB2"."C2")UNION
(SELECT "CUST_MV$SUB1"."C1" "PROD_ID","CUST_MV$SUB1"."C2"
"CUST_ID",SUM("CUST_MV$SUB1"."M3")
"CNT",SUM("CUST_MV$SUB1"."M1") "SUM_AMOUNT" FROM "SH"."CUST_MV$SUB1"
"CUST_MV$SUB1" GROUP BY "CUST_MV$SUB1"."C1","CUST_MV$SUB1"."C2");

BEGIN
DBMS_ADVANCED_REWRITE.BUILD_SAFE_REWRITE_EQUIVALENCE ('SH.CUST_MV$RWEQ',
'SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs, countries cn
WHERE s.cust_id = cs.cust_id AND cs.country_id = cn.country_id
AND cn.country_name IN (''USA'',''Canada'')
GROUP BY s.prod_id, s.cust_id
UNION
SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (1005,1010,1012)
GROUP BY s.prod_id, s.cust_id',
'(SELECT "CUST_MV$SUB2"."C3" "PROD_ID","CUST_MV$SUB2"."C2" "CUST_ID",
SUM("CUST_MV$SUB2"."M3") "CNT",
SUM("CUST_MV$SUB2"."M1") "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB2" "CUST_MV$SUB2"
GROUP BY "CUST_MV$SUB2"."C3","CUST_MV$SUB2"."C2")
UNION
(SELECT "CUST_MV$SUB1"."C2" "PROD_ID","CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1")',-1553577441)
END;
/;

DROPの出力は次のとおりです。

DROP MATERIALIZED VIEW SH.CUST_MV$SUB1
DROP MATERIALIZED VIEW SH.CUST_MV$SUB2
DROP MATERIALIZED VIEW SH.CUST_MV
DBMS_ADVANCED_REWRITE.DROP_REWRITE_EQUIVALENCE('SH.CUST_MV$RWEQ')

cust_mvの元の問合せ定義は、cust_mv$SUB1およびcust_mv$SUB2という2つのサブマテリアライズド・ビューに分解されました。COUNT(amount_sold)という新しい列がcust_mv$SUB1に追加され、マテリアライズド・ビューの高速リフレッシュが可能になりました。

cust_mvの元の問合せ定義は、2つのサブマテリアライズド・ビューを問い合せるように変更され、両方のサブマテリアライズド・ビューで高速リフレッシュと通常のクエリー・リライトが可能です。

必要なマテリアライズド・ビュー・ログが追加され、サブマテリアライズド・ビューの高速リフレッシュが可能です。ディテール表ごとに、2つのマテリアライズド・ビュー・ログ文が生成されます。1つはCREATE MATERIALIZED VIEW文、もう1つはALTER MATERIALIZED VIEW FORCE文です。これらの文により、CREATEスクリプトを複数回実行できます。

BUILD_SAFE_REWRITE_EQUIVALENCE文は、古い問合せ定義を、新しいトップレベルのマテリアライズド・ビューの問合せ定義に結合します。これにより、クエリー・リライトでは、問合せへの応答に新しいトップレベルのマテリアライズド・ビューが使用されます。

例18-5 USER_TUNE_MVIEWビューからのIMPLEMENTATIONの出力へのアクセス

SELECT * FROM USER_TUNE_MVIEW
WHERE TASK_NAME='cust_mv2'
AND SCRIPT_TYPE='IMPLEMENTATION';

例18-6 スクリプト・ファイルへの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');

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

この例では、TUNE_MVIEWを使用して、高速リフレッシュを行えるようにマテリアライズド・ビューを最適化する方法を示します。この例では、集合演算子を持つマテリアライズド・ビューの問合せ定義が1つのサブマテリアライズド・ビューと1つのトップレベル・マテリアライズド・ビューに変換されます。元の問合せ定義の副問合せの形式は類似しており、条件式は結合されます。

マテリアライズド・ビュー自体が高速リフレッシュできないよう、マテリアライズド・ビューの問合せ定義にはUNION集合演算子が含まれています。ただし、マテリアライズド・ビューの問合せ定義の2つの副問合せを、1つの問合せとして結合できます。

例18-7 高速リフレッシュのためのサブマテリアライズド・ビューの最適化

EXECUTE :task_cust_mv := 'cust_mv3';

EXECUTE :create_mv_ddl := '

CREATE MATERIALIZED VIEW cust_mv
REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE AS
SELECT s.prod_id, s.cust_id, COUNT(*) cnt, 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';

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",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=2005 OR "CUST_MV$SUB1"."C1"=1020)
UNION
(SELECT "CUST_MV$SUB1"."C2" "PROD_ID","CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=1012 OR "CUST_MV$SUB1"."C1"=1010 OR
"CUST_MV$SUB1"."C1"=1005)

DBMS_ADVANCED_REWRITE.BUILD_SAFE_REWRITE_EQUIVALENCE ('SH.CUST_MV$RWEQ',
'SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (2005,1020)
GROUP BY s.prod_id, s.cust_id UNION
SELECT s.prod_id, s.cust_id, COUNT(*) cnt,
SUM(s.amount_sold) sum_amount
FROM sales s, customers cs
WHERE s.cust_id = cs.cust_id AND s.cust_id IN (1005,1010,1012)
GROUP BY s.prod_id, s.cust_id',
'(SELECT "CUST_MV$SUB1"."C2" "PROD_ID",
"CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=2005OR "CUST_MV$SUB1"."C1"=1020)
UNION
(SELECT "CUST_MV$SUB1"."C2" "PROD_ID",
"CUST_MV$SUB1"."C1" "CUST_ID",
"CUST_MV$SUB1"."M3" "CNT","CUST_MV$SUB1"."M1" "SUM_AMOUNT"
FROM "SH"."CUST_MV$SUB1" "CUST_MV$SUB1"
WHERE "CUST_MV$SUB1"."C1"=1012 OR "CUST_MV$SUB1"."C1"=1010 OR
"CUST_MV$SUB1"."C1"=1005)',
1811223110);

cust_mvの元の問合せ定義は、サブマテリアライズド・ビューCUST_MV$SUB1の2つの副問合せの条件を結合することで最適化されています。また、必要なマテリアライズド・ビュー・ログも追加され、サブマテリアライズド・ビューの高速リフレッシュが可能です。

DROPの出力は次のとおりです。

DROP MATERIALIZED VIEW SH.CUST_MV$SUB1
DROP MATERIALIZED VIEW SH.CUST_MV
DBMS_ADVANCED_REWRITE.DROP_REWRITE_EQUIVALENCE('SH.CUST_MV$RWEQ');

次の文では、IMPLEMENTATIONの出力が、/myscript/mv_create3.sqlにあるスクリプト・ファイルに保存されます。

CREATE DIRECTORY TUNE_RESULTS AS '/myscript'
GRANT READ, WRITE ON DIRECTORY TUNE_RESULTS TO PUBLIC;
EXECUTE DBMS_ADVISOR.CREATE_FILE(DBMS_ADVISOR.GET_TASK_SCRIPT('cust_mv3'),
'TUNE_RESULTS', 'mv_create3.sql');

19 オプティマイザ・ヒントの使用方法

オプティマイザ・ヒントをSQL文で使用して実行計画を変更できます。ヒントを使用して、特定のアプローチの使用をオプティマイザに指示する方法を説明します。

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

- オプティマイザ・ヒントの概要

- ヒントの指定方法

- ビューでのヒントの使用方法

19.1 オプティマイザ・ヒントの概要

ヒントはオプティマイザに対する指示です。SQLを記述する際に、オプティマイザが認識していないデータに関する情報を、設計者が認識している場合があります。ヒントを使用することで、通常オプティマイザによって行われる決定を行うことができ、コストのかかる計画をオプティマイザに選択させることもできます。

テスト環境または開発環境で、ヒントを使用して特定のアクセス・パスのパフォーマンスをテストできます。たとえば、ある問合せに対しては、特定の索引を選択する方がよい場合もあります。この場合は、ヒントを使用して、オプティマイザが適切な実行計画を使用するように指示できます。

ヒントのデメリットは、管理、チェックおよび制御の必要なコードが追加される点です。データベースやホスト環境の変更によって、ヒントが非推奨になり、負の結果をもたらす場合もあります。このため、ヒントはテストの際に使用しますが、SQL実行計画の管理には、SQLチューニング・アドバイザやSQL計画ベースラインなどの他の方法を使用します。

Oracle Databaseでは60を超えるヒントがサポートされ、各ヒントには0個または1つ以上のパラメータがあります。文ブロックはヒントを含むコメントを1つだけ持つことができ、SELECT、UPDATE、INSERT、MERGEまたはDELETEの各キーワードに続けてコメントを指定します。たとえば、次のヒントは、employees表の最初の10行を最小限のコストで戻す問合せ計画を選択するよう、オプティマイザに指示します。

SELECT /*+ FIRST_ROWS(10) */ * FROM employees;

関連項目:
Oracle Databaseでサポートされるヒントの一覧については、『Oracle Database SQL言語リファレンス』を参照してください。

19.1.1 ヒントの型

ヒントは、次の一般的な型に分類されます。

- 単一表
単一表ヒントは、1つの表またはビュー上で指定します。単一表ヒントの例として、INDEXおよびUSE_NLがあります。

- 複数表
複数表ヒントは単一表ヒントに似ていますが、ヒントで1つ以上の表またはビューを指定できる点が異なります。複数表ヒントの例には、LEADINGがあります。USE_NL(table1 table2)は、USE_NL(table1)およびUSE_NL(table2)のショートカットであるため、複数表ヒントとはみなされません。

- 問合せブロック
問合せブロック・ヒントでは、単一の問合せブロックが処理されます。問合せブロック・ヒントの例として、STAR_TRANSFORMATIONおよびUNNESTがあります。

- 文
文ヒントはSQL文全体に適用されます。文ヒントの例には、ALL_ROWSがあります。

19.1.2 カテゴリ別のヒント

オプティマイザ・ヒントは次のカテゴリにグループ分けされます。

- 最適化アプローチと目標のヒント

- オプティマイザ機能を有効化するヒント

- アクセス・パスに関するヒント

- 結合順序のヒント

- 結合操作のヒント

- オンライン・アプリケーション・アップグレードのヒント

- パラレル実行のヒント

- 問合せの変換に関するヒント

- その他のヒント

このようなカテゴリと各カテゴリ内に含まれるヒントについては、次の各項で説明します。

関連項目:
構文と各ヒントの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

19.1.2.1 最適化アプローチと目標のヒント

ALL_ROWSヒントおよびFIRST_ROWS(n)ヒントでは、最適化アプローチまたは目標のいずれかを選択できます。最適化アプローチと目標を指定するヒントがSQL文に含まれている場合、オプティマイザは、統計の有無、OPTIMIZER_MODE初期化パラメータの値およびALTER SESSION文のOPTIMIZER_MODEパラメータにかかわらず、指定されたアプローチを使用します。

注意:
オプティマイザの目標は直接実行される問合せにのみ適用されます。ヒントを使用して、PL/SQLの内部から実行されるSQL文のためのアクセス・パスを指定してください。ALTER SESSION ... SET OPTIMIZER_MODE文は、PL/SQLの内部から実行されるSQLには作用しません。

SQL文にALL_ROWSヒントまたはFIRST_ROWS(n)ヒントを指定した場合、データ・ディクショナリ内に、文がアクセスする表に関する統計情報が作成されていないと、オプティマイザは、デフォルトの統計値(そのような表に割り当てられている記憶域など)を使用して、欠けている統計を見積ってから、実行計画を選択します。これらの見積りはDBMS_STATSパッケージで収集した値ほど正確でない場合があるため、統計値の収集にはDBMS_STATSを使用します。

ALL_ROWSヒントまたはFIRST_ROWS(n)ヒントとともに、アクセス・パスまたは結合操作のヒントを指定した場合、オプティマイザはヒントによって指定されたアクセス・パスと結合操作を優先します。

関連項目:
マージ可能なビューでのヒントの動作については、「ビューでの最適化アプローチと目標のヒント」を参照してください。

19.1.2.2 オプティマイザ機能を有効化するヒント

OPTIMIZER_FEATURES_ENABLEヒントは、Oracle Databaseのリリース番号に基づいて、一連のオプティマイザ機能を有効化する包括的パラメータとして機能します。このヒントは、データベースのアップグレード後に、計画の回帰をチェックするのに役立ちます。

リリース番号をヒントの引数として指定します。次の例は、Oracle Database 11gリリース1(11.1.0.6)のオプティマイザ機能を使用して問合せを実行します。

SELECT /*+ optimizer_features_enable('11.1.0.6') */ employee_id, last_name
FROM    employees
ORDER BY employee_id;

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

19.1.2.3 アクセス・パスに関するヒント

次のヒントは、特定のアクセス・パスを使用して表にアクセスするようオプティマイザに指示します。

- FULL

- CLUSTER

- HASH

- INDEXおよびNO_INDEX

- INDEX_ASCおよびINDEX_DESC

- INDEX_COMBINEおよびINDEX_JOIN

- INDEX_JOIN

- INDEX_FFSおよびNO_INDEX_FFS

- INDEX_SSおよびNO_INDEX_SS

- INDEX_SS_ASCおよびINDEX_SS_DESC

これらのヒントの1つを指定すると、索引またはクラスタの存在およびSQL文の構文の構成に基づいて、指定したアクセス・パスが使用可能な場合にのみ、指定したアクセス・パスがオプティマイザによって選択されます。ヒントで指定されたアクセス・パスが使用可能でない場合、オプティマイザはその指定を無視します。

アクセスする表は、文に指定する場合と同じように正確に指定してください。文が表の別名を使用している場合、表の名前ではなく、表の別名をヒントで使用する必要があります。スキーマ名が文中にある場合は、ヒント内の表名にそのスキーマ名を入れないでください。

注意:
アクセス・パスのヒントで、SELECT文のFROM句にSAMPLEオプションを指定した場合、Oracle Databaseはヒントを無視します。

関連項目:

- マージ可能なビューでのヒントの動作については、「ビューに対するアクセス・パスと結合のヒント」および「ビュー内のアクセス・パスと結合のヒント」を参照してください。

- SAMPLEオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

19.1.2.4 結合順序のヒント

次のヒントは結合順序を指示します。

- LEADING

- ORDERED

19.1.2.5 結合操作のヒント

次のヒントでは、オプティマイザが表の特定の結合操作を使用するように指示します。

- USE_NLおよびNO_USE_NL

- USE_NL_WITH_INDEX

- USE_MERGEおよびNO_USE_MERGE

- USE_HASHおよびNO_USE_HASH

- NO_USE_HASH

USE_NLヒントとUSE_MERGEヒントは、結合順序のヒントとともに使用することをお薦めします。「結合順序のヒント」を参照してください。Oracle Databaseでは、参照表を結合の内部表として使用する場合、これらのヒントを使用します。参照表が外部表の場合は、これらのヒントを無視します。

マージ可能なビューでのヒントの動作については、「ビューに対するアクセス・パスと結合のヒント」および「ビュー内のアクセス・パスと結合のヒント」を参照してください。

19.1.2.6 オンライン・アプリケーション・アップグレードのヒント

オンライン・アプリケーション・アップグレードのヒントは、編集ベースの再定義を使用してオンライン・アプリケーション・アップグレードを実行する際にINSERT操作とUPDATE操作の競合を処理する方法を提案します。

- CHANGE_DUPKEY_ERROR_INDEX

- IGNORE_ROW_ON_DUPKEY_INDEX

- RETRY_ON_ROW_CHANGE

CHANGE_DUPKEY_ERROR_INDEXヒントとIGNORE_ROW_ON_DUPKEY_INDEXヒントを使用して、オンライン・アプリケーション・アップグレードの際にINSERT操作の競合を処理できます。CHANGE_DUPKEY_ERROR_INDEXを使用して、指定した列または索引セットの一意キー違反を識別できます。一意キー違反がINSERT操作またはUPDATE操作で検出されると、ORA-001ではなくORA-38911エラーが報告されます。IGNORE_ROW_ON_DUPKEY_INDEXを使用すると、指定した列または索引セットの一意キー違反を無視できます。一意キー違反が単一表のINSERT操作の際に検出された場合、行レベルのロールバックが行われ、実行は次の入力行から再開します。このため、一意キー違反によって、INSERT操作が終了またはエラーが報告されることはありません。

RETRY_ON_ROW_CHANGEヒントを使用して、オンライン・アプリケーション・アップグレードの際にUPDATE操作の競合を処理できます。変更する行セットを決定した時点からその行セットを実際に変更するまでに1つ以上の行が変更された場合、このヒントを使用して、UPDATE操作またはDELETE操作を再試行できます。

関連項目:
編集ベースの再定義を使用したオンライン・アプリケーション・アップグレードの実行の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

19.1.2.7 パラレル実行のヒント

パラレル実行のヒントは、オプティマイザが操作を並列化するかどうか、および並列化の方法を指示します。次のパラレル・ヒントを使用できます。

- PARALLELおよびNO_PARALLEL

- PARALLEL_INDEXおよびNO_PARALLEL_INDEX

- PQ_DISTRIBUTE

次の項では、ヒントを機能別のカテゴリに分類しています。

関連項目:

- パラレル実行の使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

- パラレル実行の詳細は、『Oracle Database 2日でデータ・ウェアハウス・ガイド』を参照してください。

19.1.2.7.1 並列度を制御するヒント

PARALLELキーワードで始まるヒントは、問合せの並列度を示します。NO_PARALLELで始まるヒントは、並列性を無効にします。

注意:
/*+ NOAPPEND PARALLEL */ヒントを使用すると、従来の挿入をパラレル・モードで実行できます。

並列度は、文またはオブジェクト・レベルで指定できます。ヒントにオブジェクトが明示的に指定されていない場合、並列性は文レベルで起こります。ほとんどのヒントとは対照的に、文レベルのパラレル・ヒントは、オブジェクト・レベルのヒントよりも優先されます。

オブジェクト・レベルと文レベルの並列設定の違いを理解するには、たとえば、次の手順を実行します。

1. employees表の並列度を2に設定し、departments表の並列度を無効にします。次に例を示します。

ALTER TABLE employees PARALLEL 2;
ALTER TABLE departments NOPARALLEL;

2. 次のようなSELECT文を実行します。

SELECT /*+ PARALLEL(employees 3) */ e.last_name, d.department_name
FROM   employees e, departments d
WHERE  e.department_id=d.department_id;

employeesのPARALLELヒントは、手順1で指定したこの表の並列度2を上書きします。

例19-1の実行計画で、IN-OUT列のPCWPはemployeesのパラレル・アクセスを示し、Sはdepartmentsのシリアル・アクセスを示しています。departmentsへのアクセスは、手順1でこの表にNOPARALLELを適用しているため、シリアル化されています。

例19-1 /*+ PARALLEL(employees 3) */ヒントが指定された問合せの実行計画

----------------------------------------------------------------------------------------------------------------
| Id | Operation               | Name        | Rows | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib
----------------------------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT        |             |   14 |   588 |     5  (20)| 00:00:01 |        |      |          |
|  1 |  PX COORDINATOR         |             |      |       |            |          |        |      |          |
|  2 |   PX SEND QC (RANDOM)   | :TQ10001    |   14 |   588 |     5  (20)| 00:00:01 |  Q1,01 | P->S | QC (RAND)|
|* 3 |    HASH JOIN            |             |   14 |   588 |     5  (20)| 00:00:01 |  Q1,01 | PCWP |          |
|  4 |     BUFFER SORT         |             |      |       |            |          |  Q1,01 | PCWC |          |
|  5 |      PX RECEIVE         |             |    4 |    88 |     2   (0)| 00:00:01 |  Q1,01 | PCWP |          |
|  6 |       PX SEND BROADCAST | :TQ10000    |    4 |    88 |     2   (0)| 00:00:01 |        | S->P | BROADCAST|
|  7 |        TABLE ACCESS FULL| DEPARTMENTS |    4 |    88 |     2   (0)| 00:00:01 |        |      |          |
|  8 |     PX BLOCK ITERATOR   |             |   14 |   280 |     2   (0)| 00:00:01 |  Q1,01 | PCWC |          |
|  9 |      TABLE ACCESS FULL  | EMPLOYEES   |   14 |   280 |     2   (0)| 00:00:01 |  Q1,01 | PCWP |          |
----------------------------------------------------------------------------------------------------------------

3. 次のようなSELECT文を実行します。

SELECT /*+ PARALLEL(4) */ hr_emp.last_name, d.department_name
FROM   employees hr_emp, departments d
WHERE  hr_emp.department_id=d.department_id;

PARALLELヒントにスキーマ・オブジェクトが指定されていないため、ヒントの有効範囲はオブジェクトではなく文です。この文では、employees表およびdepartments表の問合せが並列度4で実行され、各表に定義された並列設定は上書きされます。

19.1.2.7.2 結合の分散方法を制御するヒント

PQ_DISTRIBUTEヒントは、指定した結合操作の分散方法を制御します。基本構文は次のとおりです。このdistributionは、結合の左側と右側にプロデューサ・スレーブとコンシューマ・スレーブを使用して分散させる方法です。

/*+ PQ_DISTRIBUTE(tablespec, distribution) */

たとえば、HASH,HASH分散では、結合キーにハッシュ関数を使用して、各表の行はコンシューマ問合せサーバーにマップされます。マッピングが完了すると、各問合せサーバーは、結果として生成されるパーティション・ペアで結合を実行します。この分散は、表のサイズがほぼ等しく、結合操作をハッシュ結合またはソート/マージ結合で行う場合にお薦めします。次の問合せのヒントでは、ハッシュ分散を使用しています。

SELECT /*+ORDERED PQ_DISTRIBUTE(departments HASH, HASH) USE_HASH (departments)*/
e.employee_id, d.department_name
FROM   employees e, departments d
WHERE  e.department_id=d.department_id;

関連項目:
PQ_DISTRIBUTEヒントの有効な構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

19.1.2.7.3 ロードの分散方法を制御するヒント

PQ_DISTRIBUTEヒントは、パラレルINSERT ... SELECT文とパラレルCREATE TABLE AS SELECT文に適用されて、プロデューサ(問合せ)スレーブとコンシューマ(ロード)スレーブ間での行の分散方法を指定します。

たとえば、PARTITION分散は、ロードする表のパーティション情報を使用して、問合せスレーブからロード・スレーブに行を分散します。この方法は、次の条件を満たす場合に使用します。

- 問合せとロードの操作をそれぞれスレーブとして統合することが不可能である(または望ましくない)場合。

- ロードするパーティションの数がロード・スレーブの数に等しいかそれ以上の場合。

- 入力データがロードするパーティション間に均等に分布している場合。

次のサンプル文は、表を作成し、PARTITION分散方法を指定しています。

CREATE /*+ PQ_DISTRIBUTE(lineitem, PARTITION) */ TABLE lineitem
NOLOGGING PARALLEL 16
PARTITION BY HASH (l_orderkey) PARTITIONS 512
AS SELECT * FROM lineitemxt;

一方、NONE分散は、問合せとロードの操作をそれぞれスレーブとして統合します。このため、すべてのスレーブがすべてのパーティションをロードします。偏りがない場合、この分散を使用すると、行の分散によるオーバーヘッドを回避できます。次のサンプルSQL文では、lineitem表へのINSERTにNONE分散を指定しています。

INSERT /*+ APPEND PARALLEL(LINEITEM, 16) PQ_DISTRIBUTE(LINEITEM, NONE) */
INTO lineitem
(SELECT * FROM lineitemxt);

19.1.2.8 問合せの変換に関するヒント

次の各ヒントは、特定の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

19.1.2.9 その他のヒント

この項ではその他のいくつかのヒントを説明します。

- APPEND、APPEND_VALUESおよび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

19.2 ヒントの指定方法

ヒントは、それらが含まれるSQL文ブロックの最適化のみに適用されます。文ブロックは、次のいずれかの文または文の一部です。

- 単純なSELECT文、UPDATE文またはDELETE文

- 複合文の親文または副問合せ

- 複合問合せの一部

たとえば、UNION演算子で結合した2つの構成要素の問合せから成る複合問合せには、各構成要素の問合せに対して1つずつ、合計2つのブロックがあります。このため、この最初の構成要素の問合せにおけるヒントはその最適化のみに適用され、2番目の構成要素の問合せの最適化には適用されません。

次の各項では、ヒントの使用方法をさらに詳しく説明します。

19.2.1 ヒント全セットの指定方法

ヒントを使用するとき、最適な実行計画を確保するために、ヒントの完全なセットを指定することが必要な場合があります。たとえば、多数の表の結合を含む非常に複雑な問合せで、特定の表にのみINDEXヒントを指定した場合、オプティマイザは、使用するその他のアクセス・パスおよび対応する結合方法を決定する必要があります。したがって、INDEXヒントを指定しても、オプティマイザが選択する結合方法およびアクセス・パスによっては、要求した索引を使用できない場合もあるため、オプティマイザの判断により、そのヒントは使用されない場合もあります。

例19-2では、LEADINGヒントにより正確な結合順序が指定されています。また、結合方法も指定されています。

例19-2 ヒント全セットの指定方法

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;

19.2.2 ヒントにおける問合せブロックの指定方法

問合せにおける問合せブロックを識別するために、ヒントでオプションの問合せブロック名を使用して、ヒントが適用される問合せブロックを指定できます。問合せブロック引数の構文の形式は@queryblockです。queryblockは、問合せ内のブロックを指定する識別子です。queryblock識別子は、システム生成またはユーザー指定のいずれかとなります。

次のガイドラインに留意してください。

- 問合せでEXPLAIN PLANを使用すると、システム生成の識別子を取得できます。NO_QUERY_TRANSFORMATIONヒントを使用して問合せのEXPLAIN PLANを実行することで、変換前の問合せブロック名を調べることができます。

- QB_NAMEヒントを使用して、ユーザー指定の名前を設定できます。

前提事項

このチュートリアルでは、次のことが前提となっています。

- ネストされた問合せブロックが含まれるemployeesとjob_historyの結合ビューを作成します。

- ビューのすべての行を問い合せますが、NO_UNNESTヒントは問合せブロックにのみ適用します。

NO_UNNESTヒントを問合せブロックに適用するには、次の手順を実行します。

1. SQL*Plusを起動し、ユーザーhrとしてログインします。

2. ビューを作成します。
たとえば、次の文を実行します。

CREATE OR REPLACE VIEW v_emp_job_history 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;

3. v_emp_job_historyの問合せについてEXPLAIN PLANを実行します。
たとえば、次のSQL文を実行します。

EXPLAIN PLAN FOR SELECT * FROM v_emp_job_history;

4. PLAN TABLEを問い合せます。
たとえば、次のSQL文を実行します。

SELECT PLAN_TABLE_OUTPUT
FROM   TABLE(DBMS_XPLAN.DISPLAY(NULL, NULL, 'ALL'));

計画が表示されます。

5. 問合せ計画出力で、問合せブロックに関連付けられた操作IDを取得した後、そのIDを使用して問合せブロック名を見つけます。
たとえば、次の計画は、employees表の全体スキャンが操作11で発生し、この操作が問合せブロック@SEL$4に対応していることを示しています。

------------------------------------------------------------------------------
|Id| Operation                        |Name        |Rows|Bytes|Cost |Time
------------------------------------------------------------------------------
|0 | SELECT STATEMENT                 |            |1   |46   |9(34)|00:00:01|
.
.
.
|11|          TABLE ACCESS FULL       | EMPLOYEES  |107 |749  |3(0) |00:00:01|
.
.
.
-------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

1 - SEL$2980E977 / V_EMP_JOB_HISTORY@SEL$1
2 - SEL$2980E977
8 - SEL$8F9407EC / VW_SQ_1@SEL$32F848CB
9 - SEL$8F9407EC
11 - SEL$8F9407EC / E2@SEL$4

6. NO_UNNESTヒントを使用してビューを問い合せます。
たとえば、NO_UNNESTヒントを問合せブロック@SEL$4(サンプル出力を参照)に適用するには、次のSQL文を実行します。

SQL> SELECT /*+ NO_UNNEST( @SEL$4 ) */ * FROM v_emp_job_history;

FIRST_NAME           LAST_NAME                 JOB_ID      TOTAL_SAL
-------------------- ------------------------- ---------- ----------
Michael              Hartstein                 MK_REP           6000

19.2.3 グローバル表のヒントの指定方法

表を指定するヒントは、一般に、ヒントが呼び出される場所であるDELETE、SELECTまたはUPDATE問合せブロック内の表を参照します。文によって参照されるビュー内の表は参照しません。ビュー内に表示される表のヒントを指定する場合は、ビューに埋め込まれているヒントではなくグローバル・ヒントを使用することをお薦めします。この章で説明する表ヒントは、ビュー名と表名を含む拡張tablespec構文を使用して、グローバル・ヒントに変換できます。

また、tablespec構文の前にオプションの問合せブロック名を使用できます。「ヒントにおける問合せブロックの指定方法」を参照してください。

表を指定するヒントには、次の構文を使用します。viewはビュー名を指定し、tableは表の名前または別名を指定します。

tablespec::=

ビューのパスが指定されている場合、ヒントは左側から順に解決されます。この場合、1つ目のビューはFROM句に含まれる必要があり、それ以降の各ビューは、前のビューのFROM句で指定されている必要があります。

注意:
オプティマイザが解析中に追加のビューを生成するため、ANSI結合構文を使用した問合せには、グローバル・ヒントに対するview_name.table_name表記は使用できません。ANSI結合構文を使用する場合には、view_name.table_name表記のかわりにヒントに問合せブロック名を指定してください。

たとえば、例19-3では、ビューvを作成して、部門内で給与が最高である各従業員について、従業員の姓名、従業員の最初のジョブおよび従業員の直属の部下全員の合計給与を戻します。データを問い合せる場合、ビューe2の表e3に索引emp_job_ixを使用することを強制できます。

例19-3 グローバル・ヒントの使用例

CREATE OR REPLACE VIEW v AS
SELECT e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal
FROM   employees e1, ( SELECT * FROM employees e3) e2, job_history j
WHERE e1.employee_id = e2.manager_id
AND e1.employee_id = j.employee_id
AND e1.hire_date = j.start_date
AND e1.salary = ( SELECT max(e2.salary) FROM employees e2
WHERE e2.department_id = e1.department_id )
GROUP BY e1.first_name, e1.last_name, j.job_id
ORDER BY total_sal;

グローバル・ヒント構造を使用することで、ビューe2の本体に索引ヒントを指定して、ビューvの変更を防ぐことができます。表e3の索引emp_job_ixを使用するよう強制するには、次のいずれかの文を使用します。

SELECT /*+ INDEX(v.e2.e3 emp_job_ix) */  * FROM v;

SELECT /*+ INDEX(@SEL$2 e2.e3 emp_job_ix) */ * FROM v;

SELECT /*+ INDEX(@SEL$3 e3 emp_job_ix) */ * FROM v;

注意:
Oracle Databaseでは、複数の問合せブロックを参照するグローバル・ヒントを無視します。たとえば、次の問合せのLEADINGヒントでは、表aおよびビュー問合せブロックvを含むメイン問合せブロックにドット表記を使用しているため、このヒントは無視されます。

SELECT /*+ LEADING(v.b a v.c) */ *
FROM a, v
WHERE a.id = v.id;

この問題を回避するため、ヒントでの問合せブロックの指定には@SEL表記を使用することをお薦めします。

SELECT /*+ LEADING(A@SEL$1 B@SEL$2 C@SEL$2) */
FROM a a, v v
WHERE a.id = v.id;

例19-4 NO_MERGEを含むグローバル・ヒントの使用方法

例19-4に示すように、グローバル・ヒント構文は、マージ不可のビューにも適用されます。

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にプッシュされます。

関連項目:
「ビューでのヒントの使用方法」

19.2.4 複合索引ヒントの指定方法

索引を指定するヒントには、次のように、単純な索引名またはカッコで括られた列のリストのいずれかを使用できます。

indexspec::=

セマンティクスは、次のとおりです。

- tableは表の名前を指定します。

- columnは、指定された表内の列名を指定します。

- オプションで列の前に表修飾子を付けることができるため、ヒントにより、索引列が索引付きの表とは別の表にあるビットマップ結合索引を指定できます。問合せに表修飾子がある場合は、別名ではなく、実表である必要があります。

- 索引指定の各列は、式ではなく、指定された表のベース列である必要があります。索引指定で指定された列がファンクション索引の接頭辞を形成している場合を除き、列指定を使用してファンクション索引をヒントで指定することはできません。

- indexは、索引名を指定します。
ヒントの指定でtablespecの次にindexspecが続く場合、表名と索引名を区切るカンマを挿入できますが、必須ではありません。複数のindexspecを区切るカンマも挿入できますが、必須ではありません。

ヒントは次のように解決されます。

- 索引名が指定されている場合は、指定された索引のみが考慮されます。

- 列リストが指定されており、指定された列と数および順序が一致する列を持つ索引が存在する場合は、その索引のみが考慮されます。このような索引が存在しない場合、指定された列が接頭辞として指定順序どおりに含まれる、表に対する索引が考慮されます。いずれの場合も、一致するすべての索引に対してユーザーが個別に同じヒントを指定した場合と同じ動作になります。

たとえば、例19-3のjob_history表には、employee_id列に対する単一列索引と、employee_idおよびstart_date列に対する連結索引があります。特定の索引を使用するようオプティマイザに指示するには、問合せに次のようなヒントを指定します。

SELECT /*+ INDEX(v.j jhist_employee_ix (employee_id start_date)) */ * FROM v;

19.3 ビューでのヒントの使用方法

あるコンテキストで定義されたビューが、別のコンテキストで使用される可能性があるため、ビュー内、またはビュー(副問合せ)に対するヒントはお薦めできません。また、このようなヒントによって予想外の実行計画が発生する可能性があります。特に、ビュー内のヒントまたはビューに対するヒントは、そのビューがトップレベルの問合せにマージ可能かどうかによって処理方法が異なります。

ビューまたは副問合せで表のヒントを指定するには、グローバル・ヒント構文をお薦めします。「グローバル表のヒントの指定方法」を参照してください。

次の項では、ビューでヒントを使用する場合の動作について説明します。

19.3.1 ヒントおよび複合ビュー

デフォルトでは、複合ビューでヒントは使用できません。たとえば、複合ビューに対する選択を行う問合せでヒントを指定しても、ビュー内にヒントがプッシュされないため、そのヒントは適用されません。

注意:
ビューが単一表の場合、ヒントは伝播されません。

ヒントは、ベース・ビュー内に存在する場合を除き、ビューに対する問合せからは適用されません。

19.3.2 ヒントとマージ可能ビュー

マージ可能なビューは、ビューを定義する問合せで置換できるビューのことです。たとえば、次のようにビューを作成します。

CREATE OR REPLACE VIEW emp_view AS
SELECT last_name, department_name FROM employees e, departments d
WHERE e.department_id=d.department_id;

このビューがマージ可能なのは、次のように、ビュー自体を使用するのではなく、ビューを定義するSELECT文を使用して問合せを最適化できるからです。

SELECT * FROM emp_view;

19.3.2.1 ビューでの最適化アプローチと目標のヒント

最適化アプローチと目標のヒントは、トップレベルの問合せまたはビュー内で起こります。

- このようなヒントがトップレベルの問合せに存在する場合、ビュー内のヒントの有無にかかわらず、このヒントを使用します。

- トップレベルのオプティマイザ・モード・ヒントがない場合、参照されるビューですべてのモード・ヒントに一貫性がある場合、それらのモード・ヒントを使用します。

- 参照されるビューで複数のモード・ヒントが競合する場合、ビューのモード・ヒントをすべて廃棄し、デフォルトまたはユーザー指定のセッション・モードを使用します。

19.3.2.2 ビューに対するアクセス・パスと結合のヒント

参照されるビューに対するアクセス・パス・ヒントと結合ヒントは、そのビューが単一の表を含んでいる場合または単一の表を持つその他のヒント・ビューを参照している場合以外は、無視されます。このような単一表ビューの場合、ビューに対するアクセス・パス・ヒントまたは結合ヒントは、ビュー内の表に対して適用されます。

19.3.2.3 ビュー内のアクセス・パスと結合のヒント

アクセス・パス・ヒントと結合ヒントは、ビュー定義に含めることができます。

- ビューがインライン・ビューである場合(つまり、ビューがSELECT文のFROM句にある場合)、ビューをトップレベルの問合せとマージするとき、ビュー内のすべてのアクセス・パス・ヒントと結合ヒントが保持されます。

- インライン・ビュー以外のビューでは、参照問合せが他の表またはビューを参照していない場合(つまり、SELECT文のFROM句にそのビューしか含まれていない場合)のみ、ビュー内のアクセス・パス・ヒントおよび結合ヒントが保持されます。

19.3.3 ヒントおよびマージ不可能なビュー

マージ不可能なビューでは、ビュー内の最適化アプローチおよび目標のヒントは無視されます。つまり、トップレベルの問合せにより最適化モードが決定されます。

マージ不可能なビューはトップレベルの問合せとは別々に最適化されるため、ビュー内のアクセス・パスおよび結合のヒントは保持されます。同じ理由から、トップレベルの問合せ内のビューに対するアクセス・パス・ヒントは無視されます。

ただし、この場合、マージ不可能なビューは表に類似しているため、トップレベルの問合せ内のビューに対する結合ヒントは保持されます。

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

この章では、プラン・スタビリティを使用してパフォーマンス特性を保持する方法について説明します。プラン・スタビリティにより、新しいOracle Databaseリリースにアップグレードするとき、ルールベース・オプティマイザから問合せオプティマイザへの移行も容易になります。

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

- 実行計画を保持するためのプラン・スタビリティの使用方法

- 問合せオプティマイザのアップグレードによるプラン・スタビリティの使用方法

注意:
ストアド・アウトラインは、SQL計画の管理を優先するために将来のリリースではサポートされなくなります。Oracle Database 11gでは、ストアド・アウトラインは以前のリリースと同様に引き続き機能します。ただし、新規アプリケーションではSQL計画の管理を使用することを強くお薦めします。SQL計画の管理により作成されるSQL計画ベースラインでは、ストアド・アウトラインより優れたSQLパフォーマンスおよび安定性が提供されます。
既存のストアド・アウトラインがある場合、「ストアド・アウトラインのSQL計画ベースラインへの移行」の手順に従って、SQL計画ベースラインへの移行を検討してください。移行が完了したら、ストアド・アウトラインを無効化または削除してください。

関連項目:

- SQL計画の管理の詳細は、第15章「SQL計画の管理の使用方法」を参照してください。

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

- お使いのデータベース・エディションにSQL計画の管理が含まれているかどうかは、『Oracle Databaseライセンス情報』を参照してください。

20.1 実行計画を保持するためのプラン・スタビリティの使用方法

プラン・スタビリティは、データベース環境の一定の変更がアプリケーションのパフォーマンス特性に影響を与えないようにします。このような変更には、オプティマイザ統計の変更、オプティマイザ・モード設定の変更、およびメモリー構造のサイズに影響を与えるパラメータ(SORT_AREA_SIZEやBITMAP_MERGE_AREA_SIZEなど)の変更が含まれます。プラン・スタビリティは、アプリケーションのパフォーマンスの変化を望まない場合に非常に便利です。

プラン・スタビリティでは、ストアド・アウトラインに実行計画を保持します。アウトラインは、SQL文に関連するオプティマイザ・ヒントのセットとして実装されます。Oracle Databaseでは、文にアウトラインが使用可能な場合、格納されたヒントを自動的に考慮し、ヒントに基づいて実行計画の生成を試みます。

Oracle Databaseでは、1つまたはすべてのSQL文のパブリックまたはプライベートのストアド・アウトラインを作成できます。ストアド・アウトラインの使用を有効化すると、オプティマイザによりアウトラインから同等の実行計画が生成されます。アウトラインをカテゴリに分類して、どのカテゴリのアウトラインを使用するかを制御することで、アウトラインの管理とデプロイメントが容易になります。

Oracle Databaseによりストアド・アウトラインで管理される計画は、システムの構成または統計に変更が生じた場合でも一貫性が維持されます。また、今後のOracleリリースでオプティマイザが変更されても、ストアド・アウトラインを使用することで、生成された実行計画が安定したものになります。

注意:
大量配布用のアプリケーションを開発する場合、ストアド・アウトラインを使用すると、すべての顧客が同じ実行計画に確実にアクセスできます。

20.1.1 プラン・スタビリティでのヒントの使用方法

Oracle Databaseでは、ヒントを使用して格納計画が記録されるため、プラン・スタビリティが実行計画を制御する度合は、Oracle Databaseのヒント・メカニズムがどれだけ実行計画を制御するかによります。

SQLテキストとそのストアド・アウトラインの間には、1対1の対応関係があります。述語内で異なるリテラルを指定すると、異なるアウトラインが適用されます。この状況を回避するには、アプリケーションのリテラルをバインド変数に置換します。

関連項目:
類似した文では、リテラルをシステム生成のバインド変数に置換することで、SQLを共有できます。アウトラインがCREATE OUTLINE文ではなくCREATE_STORED_OUTLINESパラメータを使用して生成されている場合、この操作はプラン・スタビリティでも機能します。また、アウトラインは、CURSOR_SHARINGパラメータがFORCEに設定された状態で作成されている必要があり、アウトラインの使用を試みる場合もこのパラメータがFORCEに設定されている必要があります。詳細は、第7章「メモリーの構成および使用方法」を参照してください。

プラン・スタビリティは、パフォーマンスが望ましい状態にある時点での実行計画を保持する機能です。ただし、多くの環境で、datesやorder numbersなどのデータ型の属性は急速に変化します。この場合、実行計画を永続的に使用すると、データ特性の変化につれて時間経過とともにパフォーマンスが低下する可能性があります。

つまり、動的環境で計画を保持する技術は、問合せ最適化の使用目的に対してはやや逆効果です。問合せ最適化では、データ状態を正確に反映する統計に基づいて実行計画を生成しようとします。そのため、プラン・スタビリティを制御する必要性と、データ特性の変化に対応できるオプティマイザの機能から得られる利点をバランスさせる必要があります。

20.1.1.1 アウトラインによるヒントの使用方法

アウトラインは、特定のSQL文の実行計画生成に対するオプティマイザの結果と同等の一連のヒントで主に構成されます。アウトラインを作成するとき、プラン・スタビリティが最適化の結果を検査するために使用するデータは、実行計画の生成に使用されたデータと同じです。つまり、Oracle Databaseでは、実行計画への入力を使用してアウトラインを生成し、実行計画自体は使用しません。

注意:
Oracle Databaseでは、OL$表とOL$HINTS表のデータに基づいて、USER_OUTLINESビューとUSER_OUTLINE_HINTSビューがSYS表領域に作成されます。OL$、OL$HINTSおよびOL$NODES表を直接操作することは禁止されています。
SQL文にヒントを埋め込んだ場合でも、Oracle Databaseでのアウトラインの使用方法には影響しません。Oracle Databaseでは、ヒントを指定して修正されたSQL文を、アウトラインに格納された元のSQL文とは別のものとして認識します。

20.1.2 アウトラインの格納

Oracle Databaseでは、アウトライン・データをOL$、OL$HINTSおよびOL$NODES表に格納します。これらの表を削除しないかぎり、アウトラインは永続的に保存されます。

アウトラインによる実行計画のキャッシュでの影響は、キャッシュに計画があるかどうかを確認する際に、SQLテキストに加えてアウトラインのカテゴリ名が使用される点のみです。これにより、あるカテゴリでコンパイルされた実行計画が、別のカテゴリでコンパイルする必要のあるSQL文の実行に使用されることはありません。

20.1.3 プラン・スタビリティの有効化

アウトラインを適切に機能させるには、いくつかのパラメータ(特に_ENABLEDという接尾辞で終わるパラメータ)の設定を実行環境全体で統一する必要があります。これらのパラメータは次のとおりです。

- QUERY_REWRITE_ENABLED

- STAR_TRANSFORMATION_ENABLED

- OPTIMIZER_FEATURES_ENABLE

20.1.4 付属パッケージを使用したストアド・アウトラインの管理

DBMS_OUTLNおよびDBMS_OUTLN_EDITパッケージには、ストアド・アウトラインとそのアウトライン・カテゴリの管理に使用できるプロシージャが含まれます。

DBMS_OUTLNを実行するにはEXECUTE_CATALOG_ROLEロールが必要ですが、パブリックはDBMS_OUTLN_EDITの実行権限を保持しています。DBMS_OUTLN_EDITパッケージは、実行者権限パッケージです。

DBMS_OUTLNおよびDBMS_OUTLN_EDITの有益なプロシージャの一部は次のとおりです。

- CLEAR_USED - 指定したアウトラインを消去します。

- DROP_BY_CAT - 指定したカテゴリに属するアウトラインを削除します。

- UPDATE_BY_CAT - アウトラインのカテゴリを、指定したカテゴリから新しく指定したカテゴリに変更します。

- EXACT_TEXT_SIGNATURES - テキストの完全一致スキームに従ってアウトラインのシグネチャを計算します。

- GENERATE_SIGNATURE - 指定したSQLテキストのシグネチャを生成します。

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

20.1.5 アウトラインの作成

Oracle Databaseでは、すべてのSQL文のアウトラインの作成を自動的に行うか、特定のSQL文についてアウトラインを作成することができます。いずれの場合も、アウトラインはオプティマイザからその入力データを導出します。

初期化パラメータCREATE_STORED_OUTLINESをtrueに設定すると、ストアド・アウトラインが自動的に作成されます。この機能をアクティブにすると、すべてのコンパイル済のSQL文でアウトラインが作成されます。ユーザーは、CREATE OUTLINE文を使用して特定の文のストアド・アウトラインを作成できます。

プライベート・アウトラインを作成または編集すると、そのアウトライン・データはSYSTEMスキーマのグローバル一時表に書き込まれます。これらの表には、OL$、OL$HINTSおよびOL$NODESシノニムを使用してアクセスできます。

注意:
アウトラインが作成されるスキーマに、CREATE ANY OUTLINE権限が付与されていることを確認してください。権限がない場合、CREATE_STORED_OUTLINE初期化パラメータを有効にしても、アプリケーションの実行後、データベースにはアウトラインがありません。
また、CREATE_STORED_OUTLINES初期化パラメータを有効化した状態で、実行中のアプリケーションにリテラルSQL文が多く含まれると、デフォルトのシステム表領域が使い果される可能性があります。この問題が発生した場合、DBMS_OUTLN.DROP_UNUSEDプロシージャを使用してこれらのリテラルSQLアウトラインを削除してください。

関連項目:

- CREATE OUTLINE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

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

- ルールベース・オプティマイザから問合せオプティマイザへの移行方法の詳細は、「RBOから問合せオプティマイザへの移行」を参照してください。

20.1.5.1 ストアド・アウトラインのカテゴリ名の使用方法

アウトラインをカテゴリに分類すると、管理タスクが簡素化されます。CREATE OUTLINE文では、カテゴリを指定できます。指定しない場合、DEFAULTカテゴリが選択されます。同様に、CREATE_STORED_OUTLINES初期化パラメータでもカテゴリ名を指定できます。trueを指定すると、DEFAULTカテゴリにアウトラインが生成されます。

CREATE_STORED_OUTLINES初期化パラメータを使用してカテゴリ名を指定した場合、カテゴリ名を再設定するまで、それ以降に作成されるすべてのアウトラインにそのカテゴリが割り当てられます。パラメータをfalseに設定すると、アウトライン生成は一時停止されます。

CREATE_STORED_OUTLINESをtrueに設定するか、カテゴリ名を指定せずにCREATE OUTLINE文を使用した場合、DEFAULTというカテゴリ名がアウトラインに割り当てられます。

20.1.6 ストアド・アウトラインの使用方法

ストアド・アウトラインの使用がアクティブ化されている場合は、常に問合せオプティマイザを使用します。アウトラインは、ヒントに依存します。ほとんどのヒントは、その効果を得るにはオプティマイザが必要です。

SQL文をコンパイルする際にストアド・アウトラインを使用するには、システム・パラメータUSE_STORED_OUTLINESをtrueに設定するか、カテゴリ名を指定します。USE_STORED_OUTLINESがtrueの場合は、defaultカテゴリのアウトラインが使用されます。USE_STORED_OUTLINESパラメータでカテゴリを指定すると、このパラメータを別のカテゴリ名に再設定するまで、またはUSE_STORED_OUTLINESをfalseに設定してアウトラインの使用を一時停止するまで、指定したカテゴリのアウトラインが使用されます。カテゴリ名が指定され、SQL文に一致するそのカテゴリのアウトラインが見つからなかった場合、データベースではdefaultカテゴリのアウトラインを検索します。

あるカテゴリのすべてのアウトラインではなく、特定のアウトラインを使用するには、ALTER OUTLINE文を実行して特定のアウトラインを有効にします。カテゴリの特定のアウトラインを除き、他のすべてのアウトラインを使用するには、ALTER OUTLINE文を使用して、使用するカテゴリで特定のアウトラインを無効にします。ALTER OUTLINE文では、ストアド・アウトラインの名前変更、異なるカテゴリへの再割当て、または再生成も可能です。

指定したアウトラインにより制御できるのは、アウトラインを保持するSQL文のコンパイルのみです。USE_STORED_OUTLINESがfalseの場合は、アウトラインを使用しません。USE_STORED_OUTLINESがfalseで、CREATE_STORED_OUTLINESがtrueの場合、アウトラインを使用しませんが、アウトラインの作成は行われます。

USE_PRIVATE_OUTLINESパラメータを使用すると、プライベート・アウトラインの使用を制御することができます。プライベート・アウトラインは、現在のセッションでのみ表示されるアウトラインで、そのデータは現在の解析スキーマに存在します。このアウトラインに対する変更は、システムの他のセッションからは認識されません。プライベート・アウトラインを文のコンパイルに適用する操作は、USE_PRIVATE_OUTLINESパラメータを使用して現在のセッションでのみ実行できます。編集内容をパブリック領域に保存するよう明示的に選択した場合にのみ、それらの変更は他のユーザーにも表示されます。

オプティマイザでは、通常、問合せに対する最適な計画が選択されますが、オプティマイザが準拠する経験則とは一致しない実行環境に関する知識をユーザーが保持していることもあります。アウトラインを直接編集することで、アプリケーションを変更することなくSQL問合せをチューニングできます。

USE_PRIVATE_OUTLINESパラメータが有効化され、アウトライン化されたSQL文が発行される場合、USE_STORED_OUTLINESの有効時には、オプティマイザでは使用中のパブリック領域ではなくセッションのプライベート領域からアウトラインを取得します。セッションのプライベート領域にアウトラインが存在しない場合、オプティマイザはアウトラインを使用せずに文をコンパイルします。

CREATE OUTLINE文の実行には、CREATE ANY OUTLINE権限が必要です。FROM句を指定する場合、SELECT権限も必要です。この権限は、アウトライン文に関連するSQLテキストとヒント・テキストを表示する資格を持つユーザーにのみ付与する必要があります。CREATE OUTLINE FROMコマンドの発行者がアウトラインの所有者でない場合、このロールはこのコマンドに対して必須です。

注意:
USE_STORED_OUTLINESおよびUSE_PRIVATE_OUTLINESパラメータは、システムまたはセッションに固有です。初期化パラメータではありません。これらのパラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

アウトラインが使用されているかどうかをテストするには、V$SQLビューを使用します。SQL文と組み合せてOUTLINE_CATEGORY列を問い合せます。アウトラインが適用されている場合、この列に、アウトラインのカテゴリが表示されます。それ以外の場合、この列はNULLです。OUTLINE_SID列は、特定のカーソルが使用するアウトラインについて、パブリック・アウトラインを使用している(値は0)か、プライベート・アウトライン(アウトラインを使用している対応するセッションのSID)かを示します。

たとえば、次のようにします。

SELECT OUTLINE_CATEGORY, OUTLINE_SID
FROM V$SQL
WHERE SQL_TEXT LIKE 'SELECT COUNT(*) FROM emp%';

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

20.1.7 アウトライン・データの表示

Oracle Databaseでデータ・ディクショナリに格納されているアウトラインの情報および関連するヒントのデータには、次のビューからアクセスできます。

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

アウトラインの互換性、形式、および有効かどうかの情報を得るには、_OUTLINESビューのフラグを確認します。たとえば、アウトラインが有効かどうかを判別するには、USER_OUTLINESビューのENABLEDフィールドをチェックします。

SELECT NAME, CATEGORY, ENABLED FROM USER_OUTLINES;

関連項目:
アウトラインに関連するビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

20.1.8 アウトライン表の移動

Oracle Databaseでは、OL$表とOL$HINTS表のデータに基づいて、USER_OUTLINESビューとUSER_OUTLINE_HINTSビューを作成します。これらの表およびOL$NODES表は、outlnスキーマにあります。

outlnスキーマは、SYSTEM表領域にデータを格納します。アウトラインがSYSTEM表領域で使用する領域が多すぎる場合、それらのデータを移動できます。この目的を達成するには、別の表領域を作成して、その表領域にアウトライン表を移動します。

注意:
CREATE_STORED_OUTLINESパラメータを有効化した状態で、実行中のアプリケーションにリテラルSQL文が多く含まれると、デフォルトのシステム表領域が使い果される可能性があります。この場合、DBMS_OUTLN.DROP_UNUSEDプロシージャを使用して、リテラルSQLアウトラインを削除してください。

アウトライン表を新しい表領域に移動するには、次の手順を実行します。

1. Oracle Data Pumpのエクスポート・ユーティリティを使用して、OL$、OL$HINTSおよびOL$NODES表をエクスポートします。
次の例では、outln_dirオブジェクトにマップするディレクトリ内のexp.dmpファイルにこれらの表をエクスポートします。

% expdp outln DIRECTORY=outln_dir DUMPFILE=exp.dmp TABLES=OL$,OL$HINTS,OL$NODES
Password: password

2. SQL*Plusを起動し、outlnユーザーとしてデータベースに接続します。次に例を示します。

SQL> CONNECT outln
Enter password: password

3. 以前のOL$表、OL$HINTS表およびOL$NODES表を削除します。次に例を示します。

SQL> DROP TABLE OL$;
SQL> DROP TABLE OL$HINTS;
SQL> DROP TABLE OL$NODES;

4. 表の新しい表領域を作成します。
次の例では、SYSTEMとして接続し、outln_tsという表領域を作成します。

SQL> CONNECT SYSTEM
Enter password: password

SQL> CREATE TABLESPACE outln_ts DATAFILE 'tspace.dat' SIZE 2M
2 DEFAULT STORAGE ( INITIAL 10K NEXT 20K MINEXTENTS 1 MAXEXTENTS 999
3                   PCTINCREASE 10 ) ONLINE;

5. outlnスキーマのデフォルト表領域を変更します。
次の文は、デフォルトの表領域をoutln_tsに変更します。

SQL> ALTER USER OUTLN DEFAULT TABLESPACE outln_ts;

6. outln_ts表領域へのインポートを実行するには、次のタスクを実行します。

1. outlnユーザーに対するSYSTEM表領域の割当て制限を0Kに設定します。

2. 表領域に対する無制限の権限または割当てを持つRESOURCEロールなど、UNLIMITED TABLESPACE権限およびすべてのロールを取り消します。

3. outln表領域の割当て制限を設定します。

7. データ・ポンプのインポート・ユーティリティを使用して、OL$表、OL$HINTS表およびOL$NODES表をインポートします。次に例を示します。

% impdp outln DIRECTORY=outln_dir DUMPFILE=exp.dmp TABLES=OL$,OL$HINTS,OL$NODES
Password: password

インポートが完了すると、OL$表、OL$HINTS表およびOL$NODES表は、outlnというスキーマに再作成され、outln_ts表領域にあります。

8. オプションとして、前のステップで削除した権限およびロールを追加して、outlnユーザーの表領域の割当て制限を適切に調整します。

関連項目:

- データ・ポンプ・エクスポートおよびインポート・ユーティリティの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- DBMS_OUTLNパッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

20.2 問合せオプティマイザのアップグレードによるプラン・スタビリティの使用方法

この項では、問合せオプティマイザの機能を利用してパフォーマンスを大幅に向上する際に使用できる手順について説明します。プラン・スタビリティでは、システムの目標とする実行計画を望ましいパフォーマンスで維持する方法が提供されますが、残りのSQL文に関しては新しい問合せオプティマイザの機能も利用できます。

ある種のSQL文および機能では、元の実行計画が正確に再現されない可能性がありますが、それにもかかわらずプラン・スタビリティは、移行における非常に有効な要素です。移行前に、アプリケーションのSQL文の大部分または全部がカバーされるまで、実行計画のアウトライン取得を有効化する必要があります。

移行後に、特定のSQL文でパフォーマンスの問題が発生した場合は、以前の動作に戻す方法として、指定した文のストアド・アウトラインを有効にすることができます。移行に関連するパフォーマンスの問題をストアド・アウトラインを使用して解決することは、変化するデータ・プロパティに計画が適合するのを阻止するため、必ずしも最善の方法ではありません。ストアド・アウトラインは、このような問題に対処する際に使用できる様々な方法のうちの1つです。

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

- RBOから問合せオプティマイザへの移行

- 問合せオプティマイザを使用する新規Oracleリリースへの移行

20.2.1 RBOから問合せオプティマイザへの移行

アプリケーションがルールベース・オプティマイザを使用して開発されている場合、作業の大部分はSQL文を手動でチューニングしてパフォーマンスを最適化することに費やされています。プラン・スタビリティを使用すると、ルールベース・オプティマイザから問合せオプティマイザにアップグレードする際に、アプリケーションの動作を保存することで、パフォーマンス・チューニングでの作業内容を活用できます。

問合せオプティマイザへの移行前にアプリケーションのアウトラインを作成することで、ルールベース・オプティマイザにより生成された計画を使用できます。一方で、移行後に新規に開発されたアプリケーションにより生成された文は、問合せ計画を使用します。アプリケーションのアウトラインを作成および使用するには、次の手順を実行します。

注意:
この手順を慎重に確認し、その意味をよく検討してから実行してください。

1. アウトラインが作成されるスキーマに、CREATE ANY OUTLINE権限が付与されていることを確認します。たとえば、SYSからの場合は次のようにします。

GRANT CREATE ANY OUTLINE TO user-name

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. RBOCATカテゴリのアウトラインを使用するには、次の構文を入力します。

ALTER SESSION SET USE_STORED_OUTLINES = rbocat;

8. アプリケーションを実行します。
プラン・スタビリティの制限により、このアプリケーションのSQL文のアクセス・パスは変更できません。

注意:
手順2で問合せを実行しなかった場合、問合せオプティマイザへの移行後も問合せの古い動作を取得できます。この目標を達成するには、オプティマイザ・モードをRULEに変更し、問合せのアウトラインを作成してから、オプティマイザ・モードをCHOOSEに戻します。

20.2.2 問合せオプティマイザを使用する新規Oracleリリースへの移行

問合せオプティマイザを使用する新しいOracle Databaseリリースにアップグレードする場合、オプティマイザに変更が生じるため、一部のSQL文の実行計画が変更される場合があります。このような変更はパフォーマンスの向上に役立ちますが、その一方で、優れたパフォーマンスを実現しているアプリケーションでは、アプリケーションの動作の変更が不必要なリスクとなる場合もあります。このようなアプリケーションについては、アップグレード前に次の手順を使用してアウトラインを作成できます。

注意:
この手順を慎重に確認し、その意味をよく検討してから実行してください。

1. 次の構文を入力し、アウトライン作成を有効化します。

ALTER SESSION SET CREATE_STORED_OUTLINES = ALL_QUERIES;

2. 重要なすべてのSQL文のストアド・アウトラインを取得できる程度に長い期間、アプリケーションを実行します。

3. 次の構文を入力し、アウトライン生成を一時停止します。

ALTER SESSION SET CREATE_STORED_OUTLINES = FALSE;

4. 本番システムを新規リリースのRDBMSにアップグレードします。

5. アプリケーションを実行します。

アップグレード後に、ストアド・アウトラインの使用を有効化できます。または、アップグレード後にパフォーマンスの低下を示した文があった場合、バックアップとして保存してあるアウトラインを使用できます。

後者のアプローチでは、このような問題のある文に対して、次のように選択的にストアド・アウトラインを使用できます。

1. 問題のあるSQL文ごとに、関連するストアド・アウトラインのCATEGORYを次のようなカテゴリ名に変更します。

ALTER OUTLINE outline_name CHANGE CATEGORY TO problemcat;

2. problemcatカテゴリのアウトラインを使用するには、次の構文を入力します。

ALTER SESSION SET USE_STORED_OUTLINES = problemcat;

20.2.2.1 テスト・システムでのアップグレード

本番データベースとは別個のテスト用データベースは、アップグレード後のオプティマイザの動作を検証するのに役立ちます。インポートおよびエクスポート機能を使用して、本番システムからテスト・システムに統計を移行できます。この方法を使用すると、テスト用データベースの表にデータを簡単に挿入できます。

アウトラインは、カテゴリ別にシステム間を移動できます。たとえば、problemcatカテゴリにアウトラインを作成した後に、問合せベースのエクスポート・オプションを使用してカテゴリ別にアウトラインをエクスポートできます。これは、ソース・データベースにあるすべてのアウトラインをエクスポートせずに、あるデータベースから別のデータベースに選択したアウトラインのみをエクスポートするための簡単で効率的な方法です。次の例のように、QUERYパラメータを指定してデータ・ポンプ・エクスポート・ユーティリティを使用します(行の継続文字が使用されている点に注意してください)。

% expdp outln DIRECTORY=outln_dir DUMPFILE=exp_file.dmp \
?  TABLES=OL$,OL$HINTS,OL$NODES QUERY='WHERE CATEGORY="problemcat"'
Password: password

関連項目:
データ・ポンプ・エクスポートおよびインポート・ユーティリティの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

21 アプリケーション・トレース・ツールの使用方法

Oracle Databaseには、Oracleデータベースで実行されるアプリケーションの監視および分析に役立ついくかのトレース・ツールがあります。

エンドツーエンド・アプリケーションのトレースでは、高負荷のSQL文などの過剰なワークロードのソースを、クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベース全体によって識別できます。これによって、問題が特定のユーザー、サービス、セッションまたはアプリケーション・コンポーネントに特定されます。

Oracle Databaseには、特定の基準に基づいてトレース情報を統合するtrcsessコマンドライン・ユーティリティがあります。

SQLトレース機能およびTKPROFは、Oracleデータベースで実行されるアプリケーションの監視に役立つ2つの基本的なパフォーマンス診断ツールです。

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

- エンドツーエンド・アプリケーションのトレース

- trcsessユーティリティの使用方法

- SQLトレースとTKPROFについて

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

- TKPROFの解釈における誤りの回避

- TKPROFの出力例

関連項目:
自動トレースを使用したSQL*Plus文のトレースおよびチューニングの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

21.1 エンドツーエンド・アプリケーションのトレース

エンドツーエンド・アプリケーションのトレースは、複数層環境のパフォーマンス上の問題の診断プロセスを単純化します。これらの環境では、エンド・クライアントからのリクエストは中間層により様々なデータベース・セッションにルーティングされるため、異なるデータベース・セッション間でクライアントを追跡するのは困難です。エンドツーエンド・アプリケーションのトレースでは、クライアントIDを使用して、データベースへのすべての層を通じて特定のエンド・クライアントを一意にトレースします。

この機能では、高負荷のSQL文などの過剰なワークロードのソースを識別でき、担当する特定のユーザーに連絡をとることができます。また、問題が発生しているユーザーから連絡を受けることもできます。これにより、データベース・レベルで、ユーザーのセッションが何を実行しているかを識別できます。

さらに、エンドツーエンド・アプリケーションのトレースでは、あるサービスの特定のモジュールおよびアクションを追跡することで、アプリケーション・ワークロードの管理が簡素化されます。エンドツーエンド・アプリケーションのトレースでは、ワークロードの問題を次のように識別できます。

- クライアント識別子
HR.HRなどのログオンIDに基づいてエンド・ユーザーを指定します。

- サービス
単一のアプリケーション(会計アプリケーションの場合はACCTGなど)を指定するか、共通の属性、サービス・レベルのしきい値および優先順位持つアプリケーション・グループを指定します。

- モジュール
売掛勘定または総勘定元帳など、アプリケーションの機能ブロックを指定します。

- アクション
モジュールのINSERT操作やUPDATE操作などのアクションを指定します。

- セッション
データベースへの現在のユーザー・ログイン状態を示します。

- インスタンス
システム・グローバル領域(SGA)およびバックグラウンド・プロセスの組合せを示します。

トレース情報がファイルに書き込まれた後、この情報をtrcsessユーティリティで統合し、TKPROFなどの分析ユーティリティで診断できます。

単一インスタンスのOracleデータベースでサービスを作成するには、DBMS_SERVICE.CREATE_SERVICEプロシージャを使用するか、SERVICE_NAMES初期化パラメータを設定します。

モジュール名およびアクション名は、アプリケーション開発者が設定します。たとえば、PL/SQLプログラムでこれらの値を設定するには、DBMS_APPLICATION_INFOパッケージのSET_MODULEおよびSET_ACTIONプロシージャを使用します。

エンドツーエンド・トレースの推奨されるインタフェースは、Oracle Enterprise Managerです。Enterprise Managerを使用する場合、各コンシューマ・タイプの上位コンシューマを表示して、特定のコンシューマの統計収集およびSQLトレースを使用可能または使用禁止にできます。可能なかぎり、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従って、Enterprise Managerを使用してエンドツーエンド・トレースを管理する必要があります。Oracle Enterprise Managerが使用可能でない場合は、次の項で説明するように、DBMS_MONITOR APIを使用してこの機能を管理できます。

- エンドツーエンド・トレースにおける統計収集の有効化および無効化

- エンドツーエンド・アプリケーションのトレースで収集した統計の表示

- エンドツーエンド・トレースにおける有効化および無効化

- エンドツーエンド・トレースにおける使用可能なトレースの表示

関連項目:

- サービスの詳細は、『Oracle Database概要』を参照してください。

- OCIアプリケーションの必要なパラメータの設定方法は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

- DBMS_MONITOR、DBMS_SESSION、DBMS_SERVICEおよびDBMS_APPLICATION_INFOの各パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- V$ビューおよび初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

21.1.1 エンドツーエンド・トレースにおける統計収集の有効化および無効化

PL/SQLを使用して適切な統計を収集するには、DBMS_MONITORパッケージのプロシージャを使用して、クライアント識別子、サービス、モジュールまたはアクションに対する統計収集を使用可能にする必要があります。

統計は次の基準でも収集できます。

- クライアント識別子に対する統計収集

- サービス、モジュールおよびアクションに対する統計収集

デフォルト・レベルは、セッション・レベルの統計収集です。統計収集はデータベース全体を対象にしており、インスタンスの再起動後も引き続き行われます。

21.1.1.1 クライアント識別子に対する統計収集

プロシージャ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');

21.1.1.2 サービス、モジュールおよびアクションに対する統計収集

プロシージャSERV_MOD_ACT_STAT_ENABLEでは、サービス、モジュールおよびアクションの組合せに対する統計収集が使用可能になります。たとえば、次のようにします。

EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'ACCTG',
module_name => 'PAYROLL');

EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'ACCTG',
module_name => 'GLEDGER', action_name => 'INSERT ITEM');

前述のコマンドが両方とも実行された場合、統計は次のように収集されます。

- ACCTGサービスに関する統計(各サービス名の累積がデフォルトであるため)

- PAYROLLモジュール内のすべてのアクションに関する統計

- GLEDGERモジュール内のINSERT ITEMアクションに関する統計

プロシージャSERV_MOD_ACT_STAT_DISABLEでは、サービス、モジュールおよびアクションの組合せに対する統計収集が使用禁止になります。たとえば、次のようにします。

EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_DISABLE(service_name => 'ACCTG',
module_name => 'GLEDGER', action_name => 'INSERT ITEM');

統計の収集に関して、これらのプロシージャでモジュールまたはアクションを変更する場合、その変更は次のユーザー・コールがセッションで実行されると有効になります。たとえば、モジュールがセッションでmodule1に設定され、そのモジュールがセッションのユーザー・コールでmodule2にリセットされた場合、このユーザー・コールでは、モジュールはmodule1のままです。モジュールは、セッションの次のユーザー・コールでmodule2に変更されます。

21.1.2 エンドツーエンド・アプリケーションのトレースで収集した統計の表示

収集した統計情報は、いくつかの動的ビューで表示できます。

- 現在使用可能な統計の累積グローバル統計は、DBA_ENABLED_AGGREGATIONSビューで表示できます。

- 指定されたクライアント識別子の累積統計は、V$CLIENT_STATSビューで表示できます。

- 指定されたサービスの累積統計は、V$SERVICE_STATSビューで表示できます。

- 指定されたサービス、モジュールおよびアクションの組合せの累積統計は、V$SERV_MOD_ACT_STATSビューで表示できます。

- データベース・コールの経過時間およびCPU使用率の累積統計は、V$SERVICEMETRICビューで表示できます。

21.1.3 エンドツーエンド・トレースにおける有効化および無効化

クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベースのトレースを使用可能にするには、DBMS_MONITORパッケージの適切なプロシージャを実行します。次の基準により、特定の診断およびワークロード管理のトレースを使用可能にできます。

- クライアント識別子のトレース

- サービス、モジュールおよびアクションのトレース

- セッションのトレース

- インスタンス全体またはデータベース全体のトレース

指定した基準により、特定のトレース情報がトレース・ファイルのセットに収集され、1つの出力トレース・ファイルに結合されます。

21.1.3.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');

21.1.3.2 サービス、モジュールおよびアクションのトレース

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

21.1.3.3 セッションのトレース

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

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

21.1.3.4 インスタンス全体またはデータベース全体のトレース

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

21.1.4 エンドツーエンド・トレースにおける使用可能なトレースの表示

Oracle Enterprise ManagerのレポートまたはDBA_ENABLED_TRACESビューに、未処理のトレースを表示できます。DBA_ENABLED_TRACESビューでは、トレース・タイプを含め、トレースを使用可能にした方法に関する詳細を判断できます。トレース・タイプは、クライアント識別子、セッション、サービス、データベース、またはサービス、モジュールおよびアクションの組合せについてトレースが使用可能かどうかを指定します。

21.2 trcsessユーティリティの使用方法

trcsessユーティリティでは、次の複数の基準に基づいて、選択されたトレース・ファイルからのトレース出力が統合されます。

- セッションID

- クライアントID

- サービス名

- アクション名

- モジュール名

trcsessによりトレース情報が1つの出力ファイルにマージされた後、出力ファイルをTKPROFによって処理できます。

trcsessは、パフォーマンスまたはデバッグを向上させるため、特定のセッションのトレースを統合する際に便利です。特定のセッションのトレースは、専用サーバー・モデルでは、1つの専用プロセスが存続期間中ずっと1つのセッションに対応するため、通常は問題になりません。このセッションのトレース情報は、このセッションに対応する専用サーバーに属するトレース・ファイルで参照できます。ただし、共有サーバー構成では、ユーザー・セッションが様々なプロセスで対応される場合があります。ユーザー・セッションに関連するトレースは、様々なプロセスに属する各種トレース・ファイル間で分散されます。そのため、セッションの存続期間におけるすべての状況を把握しにくくなります。

21.2.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オプションが複数指定されている場合、指定されたすべての基準を満たすトレース・ファイルが出力ファイルに統合されます。

21.2.2 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

21.3 SQLトレースとTKPROFについて

SQLトレース機能およびTKPROFを使用すると、アプリケーションが実行するSQL文の効率を正確に評価できます。最善の結果を得るには、EXPLAIN PLANを単体ではなくこれらのツールとともに使用してください。

21.3.1 SQLトレース機能について

SQLトレース機能は、個々のSQL文に関するパフォーマンス情報を提供します。この機能は、文単位に次の統計を生成します。

- 解析、実行、フェッチのカウント

- CPU時間と経過時間

- 物理読取りと論理読取り

- 処理された行数

- ライブラリ・キャッシュでのミス

- それぞれの解析が行われるユーザー名

- 各コミットおよびロールバック

- 各SQL文の待機イベント・データおよび各トレース・ファイルの要約

また、SQL文のカーソルがクローズされている場合は、SQLトレースにより次の内容を含む行ソース情報が提供されます。

- 各SQL文の実際の実行計画を示す行操作

- 行数、一貫性のある読取りの数、物理読取り数、物理書込み数および行の各操作の経過時間

1つのセッションまたはインスタンスに対してSQLトレース機能を使用可能にできますが、かわりにDBMS_SESSIONまたはDBMS_MONITORパッケージを使用することをお薦めします。セッションまたはインスタンスに対してSQLトレース機能を使用可能にすると、ユーザー・セッションまたはインスタンスで実行されるすべてのSQL文のパフォーマンス統計がトレース・ファイルに格納されます。SQLトレース機能を使用するとパフォーマンスに重大な影響を与えることがあり、システム・オーバーヘッドの増加、過剰なCPU使用率およびディスク領域の不足をもたらす場合があります。

関連項目:
DBMS_SESSIONまたはDBMS_MONITORパッケージを使用してセッションまたはインスタンスに対するSQLトレースを使用可能にする方法の詳細は、「エンドツーエンド・トレースにおける有効化および無効化」を参照してください。

Oracle Databaseには、セッションまたはクライアントIDなどの特定の基準に基づいて複数のトレース・ファイルからトレース情報を統合する、trcsessコマンドライン・ユーティリティがあります。「trcsessユーティリティの使用方法」を参照してください。

21.3.2 TKPROFについて

TKPROFプログラムを実行すると、トレース・ファイルの内容をフォーマットし判読可能なファイルとして出力できます。TKPROFは次のことも実行します。

- 統計をデータベースに格納するSQLスクリプトを作成します。

- SQL文の実行計画を判断します。

注意:
SQL文のカーソルがクローズされていない場合、SQL文の実際の実行計画がTKPROF出力に自動的に含まれることはありません。この場合は、TKPROFでEXPLAINオプションを使用して、実行計画を生成できます。

TKPROFは、実行した各文を、消費したリソースおよびコールした回数、処理した行数とともにレポートします。この情報を使用すると、リソースを最も多く使用している文を簡単に検出できます。経験、または参考にできる基準をもとに、使用されたリソースが実行された作業に対して妥当であるかどうかを評価できます。

21.4 SQLトレース機能とTKPROFの使用方法

SQLトレース機能およびTKPROFを使用するには、次の手順に従います。

1. トレース・ファイル管理用の初期化パラメータを設定します。
「手順1: トレース・ファイル管理用の初期化パラメータの設定」を参照してください。

2. 対象とするセッションに対してSQLトレース機能を使用可能にして、アプリケーションを実行します。手順2では、アプリケーションによって発行されたSQL文に関する統計を含むトレース・ファイルが作成されます。
「手順2: SQLトレース機能を使用可能にする方法」を参照してください。

3. 手順2で作成されるトレース・ファイルを判読可能な出力ファイルに変換するために、TKPROFを実行します。手順3ではオプションとして、データベースへの統計の格納に使用できるSQLスクリプトを作成できます。
「手順3: TKPROFによるトレース・ファイルのフォーマット」を参照してください。

4. 手順3で作成した出力ファイルを解釈します。
「手順4: TKPROF出力の解釈」を参照してください。

5. 任意で、手順3で作成したSQLスクリプトを実行してデータベースに統計を格納します。
「手順5: SQLトレース機能統計の格納」を参照してください。

次の項に、各手順の詳細を示します。

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

セッションに対してSQLトレース機能が使用可能になると、Oracle Databaseはトレース・ファイルを生成します。このファイルには、そのセッションでトレースされたSQL文に関する統計が記録されています。インスタンスに対してSQLトレース機能が使用可能になると、Oracle Databaseはプロセスごとに個別のトレース・ファイルを作成します。SQLトレース機能を有効にする前に、次のことを行ってください。

1. 表21-1に従って、TIMED_STATISTICS、MAX_DUMP_FILE_SIZEおよびDIAGNOSTIC_DEST初期化パラメータの設定をチェックします。

表21-1 SQLトレース機能を有効にする前にチェックする初期化パラメータ

パラメータ

説明

DIAGNOSTIC_DEST

自動診断リポジトリ(ADR)ホームの場所を指定します。各データベース・インスタンスの診断ファイルは、この専用ディレクトリ内にあります。DIAGNOSTIC_DEST初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

MAX_DUMP_FILE_SIZE

SQLトレース機能がデータベース・インスタンス・レベルで使用可能になっている場合、データベースをコールするたびに、オペレーティング・システムのファイル形式を持つファイルにテキスト行が書き込まれます。これらのファイルの最大サイズ(オペレーティング・システム・ブロック単位)は、初期化パラメータによって制限されます。デフォルト値はUNLIMITEDです。トレース・ファイルのサイズを制御する方法については、『Oracle Database管理者ガイド』を参照してください。

TIMED_STATISTICS

SQLトレース機能によるCPU時間や経過時間などの時間統計の収集、およびV$ビューの中の様々な統計の収集を使用可能または使用禁止にできます。

STATISTICS_LEVELをTYPICALまたはALLに設定した場合、TIMED_STATISTICSのデフォルト値はTRUEになります。STATISTICS_LEVELをBASICに設定した場合、デフォルト値はFALSEになります。STATISTICS_LEVEL初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

時間計測を使用可能にすると、下位レベル操作に対する時間計測呼出しが余分に発生します。これは動的パラメータです。セッション・パラメータでもあります。TIMED_STATISTICS初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

2. 結果のトレース・ファイルを認識する方法を考えます。
トレース・ファイルを名前で区別できるようにしてください。SELECT 'program_name' FROM DUALのような文をプログラムに組み込むことによって、トレース・ファイルにタグを付けることができます。これにより、各ファイルの生成元のプロセスを追跡できます。

TRACEFILE_IDENTIFIER初期化パラメータを設定し、トレース・ファイル名の一部となるカスタム識別子も指定できます。たとえば、次の文によって、後続のトレース・ファイル名にmy_trace_idを追加し、識別しやすくできます。

ALTER SESSION SET TRACEFILE_IDENTIFIER = 'my_trace_id';

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

3. オペレーティング・システムがファイルの複数のバージョンを保持している場合、SQLトレース機能が生成するトレース・ファイルの数に対して、バージョンの上限が十分に高い値に設定されていることを確認してください。

4. 生成されたトレース・ファイルの所有者は、データベース管理者以外のオペレーティング・システム・ユーザーの場合があります。データベース管理者がTKPROFを実行してこれらのファイルをフォーマットする場合は、このユーザーが前もって、管理者がトレース・ファイルを利用できる状態にしておく必要があります。

関連項目:

- STATISTICS_LEVELの設定の詳細は、「統計収集のレベルの設定」を参照してください。

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

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

次のいずれかのレベルでSQLトレース機能を使用可能にします。

- データベース・インスタンス
DBMS_MONITOR.DATABASE_TRACE_ENABLEプロシージャを使用してトレースを使用可能にし、DBMS_MONITOR.DATABASE_TRACE_DISABLEプロシージャを使用してトレースを使用禁止にします。

- データベース・セッション
DBMS_SESSION.SET_SQL_TRACEプロシージャを使用して、トレースを使用可能(TRUE)または使用禁止(FALSE)にします。

注意:
SQLトレース機能を実行するとシステムのオーバーヘッドが増加するため、この機能はSQL文をチューニングするときにのみ使用可能にし、チューニングが終了してから使用禁止にしてください。

データベース・インスタンス・レベルでトレースを使用可能および使用禁止にする手順は次のとおりです。

1. SQL*Plusを起動し、管理者権限でデータベースに接続します。

2. データベース・インスタンス・レベルでトレースを使用可能にします。
次の例では、orclインスタンスに対するトレースを使用可能にします。

EXEC DBMS_MONITOR.DATABASE_TRACE_ENABLE(INSTANCE_NAME => 'orcl');

3. トレースする文を実行します。

4. データベース・インスタンスに対するトレースを使用禁止にします。
次の例では、orclインスタンスに対するトレースを使用禁止にします。

EXEC DBMS_MONITOR.DATABASE_TRACE_DISABLE(INSTANCE_NAME => 'orcl');

セッション・レベルでトレースを使用可能および使用禁止にする手順は次のとおりです。

1. SQL*Plusを起動し、必要な資格証明を使用してデータベースに接続します。

2. 現行のセッションに対するトレースを使用可能にします。
次の例では、現行のセッションに対するトレースを使用可能にします。

EXEC DBMS_SESSION.SET_SQL_TRACE(sql_trace => TRUE);

3. トレースする文を実行します。

4. 現行のセッションに対するトレースを使用禁止にします。
次の例では、現行のセッションに対するトレースを使用禁止にします。

EXEC DBMS_SESSION.SET_SQL_TRACE(sql_trace => FALSE);

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

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

TKPROFは、SQLトレース機能によって生成されたトレース・ファイルを入力として受け入れ、フォーマットされた出力ファイルを生成します。TKPROFは、実行計画の生成にも使用できます。

SQLトレース機能によってトレース・ファイルが生成されると、次を実行できるようになります。

- トレース・ファイルごとにTKPROFを実行して、フォーマットされた出力ファイルを各セッションに1つずつ作成できます。

- トレース・ファイルを連結し、その結果のファイルに対してTKPROFを実行して、インスタンス全体のフォーマットされた出力ファイルを生成できます。

- trcsessコマンドライン・ユーティリティを実行して複数のトレース・ファイルからトレース情報を統合し、結果に対してTKPROFを実行します。「trcsessユーティリティの使用方法」を参照してください。

TKPROFは、トレース・ファイルに記録されているCOMMITおよびROLLBACKをレポートしません。

21.4.3.1 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       0
Execute    1     0.00      0.00         0        0       0       0
Fetch      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 JOIN
14      TABLE ACCESS (FULL) OF 'EMP'

この文では、TKPROF出力に次の情報が含まれています。

- SQL文のテキスト

- 表形式で示されたSQLトレース統計

- 文の解析と実行におけるライブラリ・キャッシュ・ミスの回数

- 文を最初に解析したユーザー

- EXPLAIN PLANによって生成された実行計画

TKPROFは、トレース・ファイルのユーザー・レベル文と再帰的SQLコールの要約も提供します。

21.4.3.2 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を実行するときには表21-2の引数を使用します。

表21-2 TKPROF引数

引数

説明

filename1

入力ファイル、つまりSQLトレース機能によって生成された統計を収録しているトレース・ファイルを指定します。このファイルは、単一のセッションに対して生成されたトレース・ファイル、または複数のセッションの個々のトレース・ファイルを結合して生成したファイルのどちらでもかまいません。

filename2

TKPROFが、フォーマット済の出力を書き出すファイルを指定します。

WAITS

トレース・ファイル内の待機イベントのサマリーを記録するかどうかを指定します。値はYESまたはNOのいずれかです。デフォルトはYESです。

SORT

トレースした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

フェッチ中の現行モード・ブロック読取りの回数

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 Databaseに接続した後、EXPLAIN PLAN文を発行して実行計画を判断します。指定されたユーザーは、CREATE SESSIONシステム権限を持っている必要があります。 EXPLAINオプションが使用されている場合は、TKPROFが大きなトレース・ファイルを処理するのに要する時間が長くなります。

RECORD

トレース・ファイル内の非再帰的SQL文をすべて収録したSQLスクリプトを、指定したfilename4で作成します。このスクリプトを使用して、トレース・ファイルからユーザー・イベントを再実行できます。

WIDTH

EXPLAIN PLANなど、一部のTKPROF出力の出力行幅を制御する整数です。このパラメータは、TKPROF出力の後処理に役立ちます。

21.4.3.3 TKPROF文の例

この項では、TKPROFの2つの使用例を簡単に説明します。TKPROF出力例の詳細は、「TKPROFの出力例」を参照してください。

21.4.3.3.1 TKPROFの例1

SORTパラメータとPRINTパラメータの組合せを使用して大規模なトレース・ファイルを処理する場合は、リソースを最も多く使用する文のみを含むTKPROF出力ファイルを生成できます。たとえば、次の文は、トレース・ファイルに格納されている、ほとんどの物理I/Oを生成した10個の文を印刷します。

TKPROF ora53269.trc ora53269.prf SORT = (PRSDSK, EXEDSK, FCHDSK) PRINT = 10

21.4.3.3.2 TKPROFの例2

この例では、TKPROFを実行して、examp12_jane_fg_sqlplus_007.trcという名前のトレース・ファイルを取り込み、outputa.prfという名前のフォーマット済の出力ファイルに書き込みます。

TKPROF examp12_jane_fg_sqlplus_007.trc OUTPUTA.PRF
EXPLAIN=scott/tiger TABLE=scott.temp_plan_table_a INSERT=STOREA.SQL SYS=NO
SORT=(EXECPU,FCHCPU)

この例は、スクリーン上で複数行にわたって表示される可能性があるので、使用しているオペレーティング・システムによっては継続文字を使用する必要があります。

この例で使用されている他のパラメータに注意してください。

- EXPLAINの値によって、TKPROFがユーザーscottとして接続され、トレースされた各SQL文の実行計画を生成するためにEXPLAIN PLAN文が使用されます。これを使用してアクセス・パスおよび行ソース行数を取得できます。

注意:
SQL文のカーソルがクローズされていない場合、SQL文の実際の実行計画がTKPROF出力に自動的に含まれることはありません。この場合は、TKPROFでEXPLAINオプションを使用して、実行計画を生成できます。

- TABLEの値によって、TKPROFがスキーマscottの表temp_plan_table_aを一時的なPLAN TABLEとして使用します。

- INSERTの値によって、TKPROFがトレースされたすべてのSQL文に関する統計をデータベース内に格納するSQLスクリプト、STOREA.SQLを生成します。

- SYSパラメータに値NOが指定されていることにより、TKPROFは出力ファイルに再帰的SQL文のリストを作成しません。このため、一時表操作などのOracle Databaseの内部の文は無視できます。

- SORTの値によって、TKPROFはSQL文を出力ファイルに書き込む前に、SQL文の実行にかかったCPU時間と行のフェッチにかかったCPU時間の合計値の順にSQL文をソートします。効率を最大にするためには、SORTパラメータを常に使用してください。

21.4.4 手順4: TKPROF出力の解釈

この項では、TKPROF出力を解釈するためのヒントを示します。

- TKPROFの表形式の統計

- 行ソースの操作

- 待機イベント情報

- 統計の精度の解釈

- 再帰的コールについて

- TKPROFのライブラリ・キャッシュ・ミス

- SQLトレースでの文の切捨て

- TKPROFでのSQL文を発行するユーザーの識別

- TKPROFの実行計画

- チューニングする文の決定

TKPROFは非常に有用な分析を提供しますが、効率の最も正確なメジャーは、対象アプリケーションの実際のパフォーマンスです。TKPROF出力の最後の部分は、トレース実行期間中にプロセスがデータベース・エンジンで実行した作業のサマリーです。

21.4.4.1 TKPROFの表形式の統計

TKPROFは、SQLトレース機能によって戻されるSQL文の統計のリストを行と列に作成します。各行は、SQL文を処理する3つのステップの1つに対応します。統計は、次に示すCALL列の値によって識別されます。表21-3を参照してください。

表21-3 CALL列の値

CALLの値

意味

PARSE

適切なセキュリティ認可のチェック、および表、列、その他の参照オブジェクトの存在のチェックを行ってSQL文を実行計画に変換します。

EXECUTE

Oracleによって行われる実際の文の実行です。INSERT文、UPDATE文およびDELETE文では、データの変更が行われます。SELECT文では、選択された行が識別されます。

FETCH

問合せを満たす行を取得します。フェッチは、SELECT文についてのみ実行されます。

SQLトレース機能の出力におけるその他の列は、すべての文の解析、実行、フェッチについての統計です。queryとcurrentの合計が、アクセスされたバッファの総数となります。これは論理I/O(LIO)とも呼ばれます。表21-4を参照してください。

表21-4 解析、実行およびフェッチのSQLトレース統計

SQLトレース統計

意味

COUNT

文が解析、実行またはフェッチされた回数です。

CPU

文に対するすべての解析コール、実行コールまたはフェッチ・コールにかかったCPU時間の合計(単位は秒)です。TIMED_STATISTICSがオンになっていない場合、この値は0(ゼロ)になります。

ELAPSED

文に対するすべての解析コール、実行コールまたはフェッチ・コールにかかった経過時間の合計(単位は秒)です。TIMED_STATISTICSがオンになっていない場合、この値は0(ゼロ)になります。

DISK

すべての解析コール、実行コールまたはフェッチ・コールに対して、ディスク上のデータファイルから物理的に読み取ったデータ・ブロックの総数です。

QUERY

すべての解析コール、実行コールまたはフェッチ・コールに対して、一貫モードで取り出されたバッファの総数です。通常バッファは 問合せに対して一貫モードで取り出されます。

CURRENT

現行モードで取り出されたバッファの総数です。INSERT、UPDATE、DELETEなどの文では、バッファは現行モードで取り出されます。

処理された行に関する統計は、ROWS列に表示されます。表21-5を参照してください。

表21-5 ROWS列のSQLトレース統計

SQLトレース統計

意味

ROWS

SQL文によって処理された行の総数です。この値には、SQL文の副問合せによって処理された行は含まれません。

SELECT文の場合、戻された行数はフェッチ・ステップに表示されます。UPDATE文、DELETE文およびINSERT文の場合、処理された行数は実行ステップに表示されます。

注意:
行ソースの件数は、カーソルがクローズされたときに表示されます。SQL*Plusでは、ユーザー・カーソルは1つしかないため、文が実行されるたびに直前のカーソルがクローズされます。これにより、行ソースの件数が表示されます。PL/SQLには、独自のカーソル処理方法があり、親カーソルがクローズされても子カーソルはクローズされません。終了(または再接続)によって、件数が表示されます。

21.4.4.2 行ソースの操作

行ソースの操作では、行に対して実行される各操作で処理される行数と、物理読取りおよび書込みなど、行ソースの追加情報が提供されます。出力例は次のようになります。

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は、時間をマイクロ秒単位で指定します。

21.4.4.3 待機イベント情報

待機イベント情報が存在する場合、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';

21.4.4.4 統計の精度の解釈

タイミング統計の精度は100分の1秒であるため、100分の1秒以下のカーソル操作は正確に計測できません。統計を解読するときには、このことを覚えておいてください。非常に高速に実行する単純な問合せの結果を解読するときには特に注意してください。

21.4.4.5 再帰的コールについて

ユーザーが発行したSQL文を実行するために、Oracle Databaseは内部的に追加の文を発行する必要があります。このような文を再帰的コールまたは再帰的SQL文と呼びます。たとえば、十分な領域のない表に行を挿入しようとすると、Oracle Databaseは再帰的コールを実行して動的に領域を割り当てます。データ・ディクショナリの情報がデータ・ディクショナリ・キャッシュにないため、ディスクから取り出す必要がある場合にも、再帰的コールが生成されます。

SQLトレース機能が使用可能になっているときに、再帰的コールが発生すると、TKPROFは再帰的SQL文の統計を生成し、出力ファイルで再帰的SQL文を明確に示します。SYSコマンドライン・パラメータをNOに設定して、出力ファイルへのOracle Database内部再帰的コール(たとえば、領域管理)のリスト表示を抑止できます。再帰的SQL文の統計は、再帰的コールを発生させたSQL文のリストでなく、再帰的SQL文のリストに表示されます。したがって、SQL文の処理に必要なリソースの合計を計算するときは、その文自体の統計と、その文によって生じる再帰的コールの統計を考慮する必要があります。

注意:
再帰的SQL統計は、SQLレベルの操作には組み込まれません。

21.4.4.6 TKPROFのライブラリ・キャッシュ・ミス

TKPROFは、各SQL文の解析ステップと実行ステップの結果として生じるライブラリ・キャッシュ・ミス回数のリストも作成します。これらの統計は、表形式の統計に続く別の行に表示されます。文でライブラリ・キャッシュ・ミスが発生しなかった場合、TKPROFはその統計のリストを作成しません。「TKPROFの出力例」における解析ステップでは、ライブラリ・キャッシュ・ミスが1回発生し、実行ステップではライブラリ・キャッシュ・ミスは発生しませんでした。

21.4.4.7 SQLトレースでの文の切捨て

次のSQL文は、SQLトレース・ファイルで25文字に切り捨てられます。

SET ROLE
GRANT
ALTER USER
ALTER ROLE
CREATE USER
CREATE ROLE

21.4.4.8 TKPROFでのSQL文を発行するユーザーの識別

TKPROFは、各SQL文を発行したユーザーのユーザーIDを出力します。SQLトレース入力ファイルに複数のユーザーからの統計が含まれ、文が複数のユーザーによって発行された場合、TKPROFは、文を解析した最後のユーザーのIDを出力します。すべてのデータベース・ユーザーのユーザーIDは、列ALL_USERS.USER_IDのデータ・ディクショナリに表示されます。

21.4.4.9 TKPROFの実行計画

TKPROFのコマンドラインにEXPLAINパラメータを指定すると、TKPROFはEXPLAIN PLAN文を使用して、トレースされたSQL文ごとに実行計画を生成します。TKPROFは実行計画の各ステップによって処理された行数も表示します。

注意:
インスタンスの始動直後に生成されたトレース・ファイルは、スタートアップ・プロセスのアクティビティを反映するデータを含みます。特に、これらは、システム・グローバル領域(SGA)のキャッシュがいっぱいになったときの不均衡な量のI/Oアクティビティを反映します。チューニングを行うときには、このようなトレース・ファイルは無視してください。

関連項目:
実行計画の解釈に関する詳細は、第12章「EXPLAIN PLANの使用方法」を参照してください。

21.4.4.10 チューニングする文の決定

CPUリソースまたはディスク・リソースを最も消費するSQL文を検出する必要があります。TIMED_STATISTICSパラメータがオンになっている場合は、CPUの高いアクティビティをCPU列で見つけられます。TIMED_STATISTICSがオンになっていない場合は、QUERY列とCURRENT列をチェックします。

関連項目:
リソースを最も多く使用する文を検出する例は、「TKPROF文の例」を参照してください。

ロックの問題と効率の悪いPL/SQLループを除いて、問題の文を発見するためにはCPU時間と経過時間のどちらも必要ありません。重要なのは、問合せモード(すなわち、読取り一貫性の対象)と現行モード(読取り一貫性の非対象)の両方でアクセスするブロックの数です。セグメント・ヘッダーと更新されるブロックは現行モードで獲得されますが、すべての問合せ処理と副問合せ処理は問合せモードでデータを要求します。これらのメジャーは、インスタンス統計CONSISTENT GETSおよびDB BLOCK GETSとまったく同じです。高ディスク・アクティビティはディスク列で見つけられます。

次のリストには、あるSQL文のTKPROF出力が出力ファイルに表示されるときと同じ状態で示されています。:

SELECT *
FROM emp, dept
WHERE emp.deptno = dept.deptno;

call   count      cpu    elapsed     disk    query current    rows
---- -------  -------  --------- -------- -------- -------  ------
Parse     11     0.08      0.18        0       0       0         0
Execute   11     0.23      0.66        0       3       6         0
Fetch     35     6.70      6.83      100   12326       2       824
------------------------------------------------------------------
total     57     7.01      7.67      100   12329       8       826

Misses in library cache during parse: 0

7.01 CPU秒で、824行を取り出せる場合は、これ以上このトレース出力を検索する必要はありません。事実上、チューニング作業でのTKPROFレポートの主な用途は、詳細なチューニング段階のプロセスを排除することです。

1つの文に対して11の解析コールが存在していたため、10の不要な解析コールが作成され、その配列フェッチ操作が実行されたことも確認できます。これは、フェッチで取り出された行よりも多くの行がフェッチされていることからわかります。CPU時間と経過時間の大きなギャップは、物理I/O(PIO)の存在を示します。

21.4.5 手順5: SQLトレース機能統計の格納

SQLトレース機能によって生成されたアプリケーションに関する統計の履歴を保持し、別の時点でこれらの統計を比較することがあります。TKPROFは、表を作成して、統計の行をその表に挿入するSQLスクリプトを生成します。このスクリプトには、次の内容が記述されています。

- TKPROF_TABLEという出力表を作成するCREATE TABLE文

- トレースしたSQL文ごとに統計行を1行ずつTKPROF_TABLEに追加するINSERT文

TKPROFの実行後にこのスクリプトを実行すると、統計をデータベースに格納できます。

21.4.5.1 TKPROFによる出力SQLスクリプトの生成

TKPROFを実行する場合は、INSERTパラメータを使用して、生成されるSQLスクリプトの名前を指定します。このパラメータを指定しないと、TKPROFはスクリプトを生成しません。

21.4.5.2 TKPROFによる出力SQLスクリプトの編集

TKPROFによってSQLスクリプトが作成された後、SQLスクリプトを実行する前にスクリプトを編集できます。以前に収集した統計の出力表が作成され、新しい統計をこの表に追加する場合は、スクリプトからCREATE TABLE文を削除します。これにより、スクリプトが新しい行を既存の表に挿入します。

異なるデータベースの統計を別々の表に格納するためなど、複数の出力表を作成している場合は、CREATE TABLE文とINSERT文を編集して、出力表の名前を変更してください。

21.4.5.3 出力表の問合せ

次の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列の値は出力ファイルの解析ステップに関するカウント統計に対応しています。

表21-6の列は、統計が入っている行を識別する際に役立ちます。

表21-6 統計の行を識別するTKPROF_TABLE列

列

説明

SQL_STATEMENT

SQLトレース機能が収集した統計行の対象となるSQL文です。この列にはLONGデータ型があるため、式またはWHERE句の条件では使用できません。

DATE_OF_INSERT

行が表に挿入された日時です。この値は、SQLトレース機能によって統計が収集された時刻と完全には一致しません。

DEPTH

SQL文が発行された再帰レベルを示します。たとえば、値0はユーザーがその文を発行したことを示します。値1は、Oracle Databaseが値0の文(ユーザー発行の文)を処理するために再帰的コールとしてその文を生成したことを示します。値nは、Oracle Databaseが値n-1の文を処理する再帰的コールとしてその文を生成したことを示します。

USER_ID

この文を発行するユーザーを識別します。この値はフォーマットした出力ファイルにも出力されます。

CURSOR_NUM

Oracle Databaseでは、この列の値を使用して、各SQL文が割り当てられたカーソルの追跡を行います。

文の実行計画は出力表に格納されません。次の問合せは、出力表からの統計を返します。これらの統計は、「TKPROFの出力例」で示したフォーマットされた出力に対応します。

SELECT * FROM TKPROF_TABLE;

Oracle Databaseのレスポンスを次に示します。

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

21.5 TKPROFの解釈における誤りの回避

この項では、TKPROFの解釈における細かなポイントをいくつか説明します。

- 引数トラップの回避

- 読取り一貫性トラップの回避

- スキーマ・トラップの回避

- タイム・トラップの回避

21.5.1 引数トラップの回避

実行時にバインドされる値を認識していない場合は、引数トラップに陥る可能性があります。EXPLAIN PLANは、SQL文のテキストからバインド変数の型を判断できないので、型は常にvarcharであると想定されます。バインド変数が実際には番号または日付である場合、TKPROFが暗黙的データ変換を行い、その結果、効率の悪い計画が実行される可能性があります。この状況を回避するには、異なるデータ型を使用して問合せを試みます。

この問題を回避するには、各自で変換を行ってください。

関連項目:
TKPROFおよびバインド変数の詳細は、「EXPLAIN PLANの制限事項」を参照してください。

21.5.2 読取り一貫性トラップの回避

次の例は、読取り一貫性トラップを示しています。コミットされていないトランザクションがNAME列に一連の更新を行ったことを知らないと、多くのブロックがアクセスされる理由を判断することは非常に困難です。

通常、このようなケースは再現可能ではありません。そのプロセスが再度実行された場合に、別のトランザクションが同じようにそのプロセスに影響を及ぼすことはあまりありません。

SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';

call     count     cpu     elapsed     disk     query current     rows
----     -----     ---     -------     ----     ----- -------     ----
Parse        1    0.10        0.18        0         0       0        0
Execute      1    0.00        0.00        0         0       0        0
Fetch        1    0.11        0.21        2       101       0        1

Misses in library cache during parse: 1
Parsing 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)

21.5.3 スキーマ・トラップの回避

この例は極端な場合を示しているので、スキーマ・トラップは容易に検出できます。最初は、明らかに単純に索引付けされた問合せが多くのデータベース・ブロックを検索する必要がある理由、または現行モードでブロックにアクセスすることが必要な理由を理解することは困難です。

SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';

call        count        cpu      elapsed     disk  query current rows
--------  -------   --------    ---------  ------- ------ ------- ----
Parse           1       0.06         0.10        0      0       0    0
Execute         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: 0
Parsing 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)

2つの統計は、問合せが全表スキャンを使用して実行された可能性があることを示しています。これらの統計は、現行モードでのブロック・アクセスと、実行計画のTable Access行ソースに由来する行数です。これは、トレース・ファイルが生成された後、TKPROFが実行される前に、必要な索引が構築されたことを示しています。

新規トレース・ファイルを生成すると次のデータが与えられます。

SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';

call    count    cpu   elapsed  disk  query current     rows
-----  ------ ------  -------- ----- ------ -------    -----
Parse       1   0.01      0.02     0      0       0        0
Execute     1   0.00      0.00     0      0       0        0
Fetch       1   0.00      0.00     0      2       0        1

Misses in library cache during parse: 0
Parsing 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ミリ秒というクロック刻みがデータの実行およびフェッチに要する時間と比べて非常に長いためです。このような場合、文を多く実行して統計的に有効な数値を得ることが重要になります。

21.5.4 タイム・トラップの回避

次の例で示すように、特定の問合せに長時間かかる理由がわからないことがあります。

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           0
Execute        1      0.62      19.62       22      526      12           7
Fetch          0      0.00       0.00        0        0       0           0

Misses in library cache during parse: 1
Parsing user id: 02  (USER2)

Rows     Execution Plan
-------  ---------------------------------------------------
0  UPDATE STATEMENT
2519  TABLE ACCESS (FULL) OF 'CQ_NAMES'

ここでも、別のトランザクションによる妨害というのが答えです。この場合は、別のトランザクションが更新を発行する前後の数秒間、表cq_namesで共有ロックが保持されています。妨害の影響が発生していることを診断できるようになるにはかなりの経験が必要です。一方で、妨害によって発生する遅延が短時間である(または前の例のようにブロック・アクセスにおける増加がわずかである)場合は、比較用のデータが必要です。ただし、妨害によるオーバーヘッドが少なく、本質的に文が効率的である場合は、統計を分析する必要はありません。

21.6 TKPROFの出力例

この項では、TKPROF出力の例を示します。簡潔化のために各部分を編集してあります。

21.6.1 TKPROFヘッダーのサンプル

TKPROF: Release 10.1.0.0.0 - Mon Feb 10 14:43:00 2003

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

Trace file: main_ora_27621.trc
Sort options: default

********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

21.6.2 TKPROF本体のサンプル

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        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: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 44

Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait  Total Waited
----------------------------------------   Waited  ----------  ------------
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1       28.59         28.59
********************************************************************************

select condition
from
cdef$ where rowid=:1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        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
Optimizer mode: CHOOSE
Parsing 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 employees
WHERE salary =
(SELECT max(salary) FROM employees)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.02       0.01          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        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: 1
Optimizer mode: FIRST_ROWS
Parsing 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)
)

call     count       cpu    elapsed       disk      query    current rows
------- ------  -------- ---------- ---------- ---------- ---------- ----------
Parse        1      0.00       0.00          0          0          0          0
Execute      1     29.60      60.68     266984      43776     131172      28144
Fetch        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: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing 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
********************************************************************************

21.6.3 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           0
Execute      5      0.00       0.04          0          0          0           0
Fetch        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: 4
Misses in library cache during execute: 1
Elapsed 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

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        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.trc
Trace file compatibility: 9.00.01
Sort options: default
1  session in tracefile.
5  user  SQL statements in trace file.
1  internal SQL statements in trace file.
6  SQL statements in trace file.
6  unique SQL statements in trace file.
76  lines in trace file.
128  elapsed seconds in trace file.

用語集

アクセス・パス

データベースからデータを取り出す方法。たとえば、索引を使用する問合せと、全表スキャンを使用する問合せでは、使用するアクセス・パスが異なります。

非同期I/O

送受信の時期を調整する必要がなく、送受信が完了する前に他の処理を開始できる独立したI/O。

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

問題の検出および自己チューニングを目的として、パフォーマンス統計を収集、処理およびメンテナンスします。

自動トレース

SQLオプティマイザが使用した実行パス、および文の実行統計に関するレポートを生成します。レポートは、DML文のパフォーマンスの監視およびチューニングに役立ちます。

バインド変数

SQL文の中の変数。SQL文を正常に実行するには、バインド変数を有効な値または値のアドレスに置換する必要があります。

ブロック

主メモリーとディスク間でのデータ転送の単位。メモリー・アドレス空間の1セクションにある多数のブロックが1つのセグメントを形成します。

ボトルネック

一般にはシステムの帯域幅がデータの処理される速度で中継されてくる量をサポートできないときのデータ伝送の遅延。ただし、システム内にボトルネックを生成する可能性のある要因は多数あります。

バッファ

ディスクから読み取られて、現在使用されているデータまたは最近使用されたデータを、バッファ・マネージャがキャッシュする主メモリーのアドレス。時間の経過につれて、バッファが保持するブロックは変わります。新しいブロックが必要なときは、バッファ・マネージャは古いブロックを破棄して、新しいブロックで置換します。

バッファ・プール

バッファの集まり。

キャッシュ

バッファ・キャッシュとも呼ばれます。すべてのバッファおよびバッファ・プール。

キャッシュ・リカバリ

Oracle Databaseによりコミット済および未コミットのREDOログ・ファイル内のすべての変更が、対象となるデータ・ブロックに適用されるインスタンス・リカバリの部分。インスタンス・リカバリのロールフォワード・フェーズとも呼ばれます。

デカルト積

結合条件を使用しない結合はデカルト積(クロス積)に帰結します。デカルト積は、各表から1つずつ選んだ行の作成可能なすべての組合せです。つまり、2つの表の結合において、1つの表の各行がもう一方の表のすべての行とそれぞれ組み合せられます。3つ以上の表のデカルト積は、1つの表の各行と残りの表のデカルト積のすべての行をそれぞれ組み合せた結果です。その他のすべての種類の結合は、デカルト積から、効率的に結合条件を満たさない行を絞り込んで作成されたデカルト積のサブセットです。

複合問合せ

2つ以上の単純な文または複合文を組み合せるために集合演算子(UNION、UNION ALL、INTERSECTまたはMINUS)を使用する問合せ。複合問合せ内の単純な文または複合文それぞれは、コンポーネント問合せと呼ばれます。

競合

あるプロセスが別のプロセスで使用されているリソースを待機する必要のある場合。

ディクショナリ・キャッシュ

データベース、その構造およびそのユーザーに関する参照情報を含むデータベース表とビューを集めたもの。Oracle Databaseは、SQL文を解析する際にデータ・ディクショナリに頻繁にアクセスします。ディクショナリ・データを保持するために、メモリー内に2つの特別な場所があります。1つはデータ・ディクショナリ・キャッシュと呼ばれ、データをバッファ(データ・ブロック全体を保持する)のかわりに行として保持するために行キャッシュとも呼ばれます。もう1つの領域はライブラリ・キャッシュです。すべてのOracleプロセスは、データ・ディクショナリ情報にアクセスするためにこれらの2つのキャッシュを共有します。

直接I/O

バッファ・キャッシュをバイパスするI/O。「PIO」を参照してください。

分散型の文

分散データベースの2つ以上の個別ノード/インスタンスのデータにアクセスする文。リモート文は、分散データベースの1つのリモート・ノードのデータにアクセスします。

動的パフォーマンス・ビュー

データベース管理者が動的パフォーマンス表(現在のデータベース・アクティビティを記録する仮想表)に作成するビュー。データベース管理者が変更または削除できないため、固定ビューと呼ばれます。

動的統計

述語の選択性を見積もるために、データベースが再帰的SQL文を実行して表ブロックの小さいランダム・サンプルをスキャンする最適化手法。

エンキュー

ロックの別の用語。

等価結合

等価演算子が含まれている結合条件。

エスティメータ

統計を使用して、選択性、カーディナリティおよび実行計画のコストを評価します。エスティメータの主な目標は、実行計画のコスト全体を算出することです。

実行計画

SQL文を実行するためにデータベースによって使用されるステップの組合せ。各処理では、データベースからデータ行を物理的に検索するか、文を発行したユーザーのためにデータ行を準備します。実行計画はヒントを使用して上書きできます。

EXPLAIN PLAN

DML文に対してオプティマイザが選択した実行計画を検証できるSQL文。EXPLAIN PLANを実行すると、オプティマイザは実行計画を選択し、計画を説明するデータをデータベース表に格納します。

高速全索引スキャン

データベースが索引ブロックを特定の順序によらずに読み取る全索引スキャン。データベースでは、表にアクセスすることなく、索引自体の中のデータにアクセスします。

全索引スキャン

データベースによって索引全体が順に読み取られる索引のスキャン。

全表スキャン

データベースによって表のすべての行が順に読み取られ、選択基準を満たさない行が除外される表データのスキャン。全表スキャンでは、最高水位標以下のすべてのデータ・ブロックがスキャンされます。

ハッシュ結合

データベースで、2つの表またはデータ・ソースの小さい方を使用して、メモリー内にハッシュ表を作成する結合。ハッシュ結合では、データベースは大きい方の表をスキャンし、ハッシュ表を調べて小さい方の表の一致する行のアドレスを見つけます。

ヒント

SQL文の中のコメントを介してオプティマイザに渡される命令。オプティマイザでは、このヒントを使用して文の実行計画が選択されます。

索引クラスタ化係数

名字などの索引値に関連する行順序の尺度。行の記憶域の中でこの値に関する順序性がよいほど、クラスタ化係数は小さくなります。

インスタンス・リカバリ

データベース障害後に、データ・ブロックにREDOログのレコードを自動的に適用することです。

結合

複数の表からデータを選択する問合せ。結合の特徴は、FROM句内に複数の表が並んでいる点です。Oracle Databaseは、WHERE句に指定された条件を使用して、それぞれの表の行を結合し、結果の行を戻します。この条件は結合条件と呼ばれ、通常、結合されたすべての表の列はこの条件によって比較されます。

ラッチ

システム・グローバル領域で共有されているデータ構造を保護するための簡素な下位レベルのシリアライズ・メカニズム。

ライブラリ・キャッシュ

共有されているSQL領域とPL/SQL領域を保持するメモリー構造。ライブラリ・キャッシュは共有プールの3つの部分のうちの1つです。

LIO

論理I/O。バッファ・キャッシュから読むことができる場合とできない場合のあるブロック読取り。

リテラル

コンパイル時に書き込まれ、実行時に読取り専用の定数の値。データベースは、リテラルに迅速にアクセス可能で、変更する必要がない場合はその値を使用します。

ミラー化

同じ内容のデータのコピーを1つ以上のディスクで保持することです。一般的にミラー化はオペレーティング・システム・レベルで二重化されたハードディスクにおいて実現するので、いずれかのディスクが使用不可能になった場合、中断せずにもう一方のディスクでリクエストを処理できます。

MTBF

平均障害間隔時間。一般的なデータベース統計で、I/Oのチューニングに重要です。

非等価結合

等価演算子以外の演算子が含まれている結合条件。

オプティマイザ

SQL文を実行する最も効率的な方法を決定する組込みのデータベース・ソフトウェア。問合せオプティマイザは、問合せトランスフォーマ、エスティメータおよびプラン・ジェネレータで構成されます。

オプティマイザは、SQL文の潜在的な実行計画セットの生成、各計画のコストの見積り、計画を生成するプラン・ジェネレータのコールを実行し、コストを比較して最も低コストの計画を選択します。この方法は、SQL文でアクセスされる1つ以上の表の統計がデータ・ディクショナリに含まれている場合に使用されます。

オプティマイザ・モード

オプティマイザは、標準モードかチューニング・モードで動作します。標準モードでは、オプティマイザはSQLをコンパイルして実行計画を生成します。チューニング・モードでは、オプティマイザは追加分析を実行し、さらに優れた計画を生成するための一連のアクションと、その理論的根拠と予測されるメリットを示します。チューニング・モードで実行する場合、オプティマイザは自動チューニング・オプティマイザと呼ばれます。

外部結合

表のどれか1つの1つ以上の列で外部結合演算子(+)を使用する結合条件。Oracle Databaseは、この結合条件に一致する行をすべて戻します。また、外部結合演算子を指定した表で一致する行がない場合、外部結合演算子を使用せずに表からすべての行を戻します。

ページング

プログラムの作業メモリーのうちの使用頻度の低い部分を主メモリーから二次記憶媒体(通常はディスク)に移動することによって使用可能なメモリー領域を増やすための手法。転送単位はページと呼ばれます。

解析

ハード解析は、SQL文が実行され、かつSQL文が共有プール内にないか、共有プール内にあっても共有できないときに行われます。SQL文は、2つのSQL文のメタデータが異なる場合に共有されません。これは、あるSQL文が既存のSQL文とテキストでは同一だが、2つの文で参照される表が物理的に異なる表に変換される場合、またはオプティマイザ環境が異なる場合に発生する可能性があります。

ソフト解析は、セッションでSQL文を実行する際に、その文が共有プール内にあり、その文を使用(すなわち、共有)できる場合に行われます。共有される文の場合、既存のSQL文に関連するすべてのデータ(オプティマイザ実行計画などのメタデータも含む)が発行対象の現在の文に同じように適用できる必要があります。

解析コール

SQL文実行の準備のためにOracle Databaseに行われるコール。このコールには、SQL文の構文チェック、SQL文の最適化、SQL文の実行可能形式の作成(または指定)が含まれています。

パーサー

SQL文の構文分析とセマンティック分析を実行し、(問合せで参照される)ビューを個別の問合せブロックに展開します。

PGA

プログラム・グローバル領域。サーバー・プロセスのデータと制御情報が含まれる非共有のメモリー領域。サーバー・プロセスの開始時に作成します。

PIO

物理I/O。ブロックがバッファ・キャッシュに存在しなかったか、I/Oがバッファ・キャッシュをバイパスする直接I/Oであるため、バッファ・キャッシュから読むことのできなかったブロック読取り。

プラン・ジェネレータ

問合せオプティマイザが最も低コストの計画を選択できるように、特定の問合せに対して考えられる様々な計画を試行します。異なるアクセス・パス、結合方法および結合順序を試行することによって、問合せブロックに対する様々な計画を調査します。

述語

SQL内のWHERE条件。

問合せオプティマイザ

「オプティマイザ」を参照してください。

問合せトランスフォーマ

ユーザー問合せをリライトして、より効率的な問合せ計画を生成するかどうかを判断し、ビューをマージして副問合せのネスト解除を実行します。

RAID

Redundant Arrays of Inexpensive Disks。RAID構成では、ストライプ化(手動によるデータの分散化)とともに、高いデータの信頼性を実現します。パフォーマンスとコストに基づいて様々なRAID構成(レベル)が選択され、そのI/O特性に応じて、適応がふさわしいアプリケーションは異なります。

行ソース・ジェネレータ

オプティマイザから最適な計画を受け取り、SQL文の実行計画を出力します。行ソースは、1組の行を反復方式で処理し、行セットを生成する反復制御構造です。

セグメント

表、索引、クラスタなどの各タイプのデータベース・オブジェクトに割り当てられるエクステントのセット。

選択性

問合せにおいて、行セットからどれだけの行数が述語テストを通過するかを示す尺度。たとえば、WHERE last_name = 'Smith'などです。

単純な問合せ

1つの表のみを参照し、GROUP BYファンクションの参照は行わないSELECT文。

単純な文

単一表のみに関連するINSERT文、UPDATE文、DELETE文またはSELECT文。

SGA

システム・グローバル領域。高速アクセスのためにデータを格納するメイン・メモリー内のメモリー領域。Oracleデータベースでは、共有SQLおよびPL/SQLプロシージャのSGAメモリーの割当てに共有プールを使用します。

スキュー・データ

重複数のバリエーションが多い値。

SQLコンパイラ

SQL文を共有カーソルにコンパイルします。SQLコンパイラは、パーサー、オプティマイザおよび行ソース・ジェネレータで構成されます。

SQLプロファイル

問合せオプティマイザがSQL文に対して最適の実行計画を作成できるようにする情報の収集。

SQL文(同一)

テキストが同じSQL文は、すべての点で同一です。

SQL文(類似)

類似するSQL文は、リテラル値を変更するという点のみ異なります。リテラル値がバインド変数に置換された場合、SQL文はテキストで同一になります。

SQLトレース

Oracleデータベースに対して実行されるアプリケーションの監視およびチューニングに役立つ、基本的なパフォーマンス診断ツール。SQLトレースを使用すると、アプリケーションで実行されるSQL文の効率性を評価し、各文の統計を生成できます。このツールで生成されるトレース・ファイルは、TKPROFの入力となります。

SQLチューニング・セット(STS)

1つ以上のSQL文、実行統計および実行コンテキストを含むデータベース・オブジェクト。

SQL*Loader

入力ファイルを読み取り、解析します。大量のデータをロードする場合に、このツールを使用します。

Statspack

パフォーマンス・データの収集、自動化、格納および表示を可能にするSQL、PL/SQLおよびSQL*Plusスクリプトのセット。この機能は自動ワークロード・リポジトリに置き換えられています。

ストライプ化

ディスクにまたがるデータの関連ブロックのインターリーブ。適切なストライプ化はI/Oを減らし、パフォーマンスを向上させます。

- ストライプ深度は、ストライプのサイズで、ストライプ単位とも呼ばれます。

- ストライプ幅は、ストライプ深度とストライプ・セットを構成するドライブ数の積です。

TKPROF

Oracleデータベースに対して実行されるアプリケーションの監視およびチューニングに役立つ診断ツール。TKPROF主に、SQLトレースの出力ファイルを処理して読取り可能な出力ファイルに変換し、トレース・ファイルに関してユーザー・レベルの文と再帰的SQLコールのサマリーを提供します。また、SQL文の効率性の評価、実行計画の生成、データベースに統計を格納するSQLスクリプトの作成を実行できます。

トランザクション・リカバリ

Oracle Databaseがコミットされない変更を元に戻すためにロールバック・セグメントを適用するインスタンス・リカバリの部分。インスタンス・リカバリのロールバック・フェーズとも呼ばれます。

UGA

ユーザー・グローバル領域。ユーザー・セッションに使用されるラージ・プール内のメモリー領域。

待機イベント

処理を継続する前にイベントが完了するまで待機する必要があることを示すために、サーバー・プロセス/スレッドによって増やされる統計です。待機イベントは、事後パフォーマンス・チューニングの実行時に最初に検証する事項の1つです。

待機イベント(アイドル)

これらのイベントは、サーバー・プロセスがアイドル状態で待機中であることを示します。これらのイベントはパフォーマンスのボトルネックの性質を示さないため、チューニングの際に無視できます。

作業領域

モリーのプライベート割当てであり、ソート、ハッシュ結合およびメモリー消費型のその他の操作に使用されます。ソート演算子は、作業領域(ソート領域)を使用して一連の行のメモリー内ソートを実行します。同様に、ハッシュ結合演算子は作業領域(ハッシュ領域)を使用して、ハッシュ表を左側から入力して作成します。

索引
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W

A

アクセス・パス

クラスタ・スキャン, 11.2.4

定義, 11.4.2

実行計画, 11.4

ハッシュ・スキャン, 11.2.5

索引スキャン, 11.2.3

アクティブ・セッション履歴, 5.1.1.3

レポート

アクティビティの経過, 5.3.9.8

ロード・プロファイル, 5.3.9.2

上位イベント, 5.3.9.1

上位ファイル, 5.3.9.7

上位Java, 5.3.9.5

上位ラッチ, 5.3.9.7

上位オブジェクト, 5.3.9.7

上位PL/SQL, 5.3.9.4

上位セッション, 5.3.9.6

上位SQL, 5.3.9.3

使用, 5.3.9

適応しきい値, 5.2.3 ALL_OUTLINE_HINTSビュー

ストアド・アウトライン・ヒント, 20.1.7

ALL_OUTLINESビュー

ストアド・アウトライン, 20.1.7

ALL_ROWSヒント, 11.5.2.2 メモリーの割当て, 7.1 ALTER INDEX文, 14.1.7 ALTER SESSION文

例, 21.4.2

SET SESSION_CACHED_CURSORS句, 7.3.7.2

ANALYZE文, 13.3.1 アンチ結合, 11.3.2 アプリケーション

デプロイ, 2.7

設計の原則, 2.5

開発の傾向, 2.5.7

実装, 2.5.6

自動データベース診断モニター

推奨事項のアクションと理論的根拠, 6.1.3

分析結果の例, 6.1.4

DB time, 6.1.1

CONTROL_MANAGEMENT_PACK_ACCESSパラメータ, 6.2

DBIO_EXPECTED, 6.2

レポートの例, 6.1.4

検出結果, 6.1.3

概要, 6.1

結果, 6.1.3

設定, 6.2

STATISTICS_LEVELパラメータ, 6.2

考慮される問題のタイプ, 6.1.1

推奨事項のタイプ, 6.1.3

自動データベース診断モニター, 1.2.1, 16.4.1 自動セグメント領域管理, 4.1.4.1, 8.2.6.2, 10.3.1.2.1 自動共有メモリー管理, 7.1.3 自動SQLチューニング, 1.2.1, 16.4.2

分析, 17.1

概要, 17

自動チューニング・オプティマイザ, 17.1 自動UNDO管理, 4.1.2, 4.1.2 自動ワークロード・リポジトリ, 1.2.1

構成, 5.2

データの収集, 5.1

DBMS_WORKLOAD_REPOSITORYパッケージ, 5.3.1, 5.3.2, 5.3.3

デフォルト設定, 5.2.4

領域使用量に影響する要因, 5.2.4

APIによる管理, 5.3.1, 5.3.2, 5.3.3

領域使用量の最小化, 5.2.4

概要, 5.2

保存期間に関する推奨事項, 5.2.4

レポート, 5.3.6, 5.3.7, 5.3.8

保存期間, 5.2.4

DBA_HIST_WR_CONTROLビューで設定, 5.3.1.3

領域使用量, 5.2.4

収集される統計, 5.2

自動スナップショット収集をオフに設定, 5.2.4

レポートの例外的なパーセンテージ, 5.3.6

データへのアクセスに使用するビュー, 5.3.5

awrrpt.sql

自動ワークロード・リポジトリ・レポート, 5.3.6, 5.3.7, 5.3.8

B

ベースライン, 1.1.2.2, 5.2.2

パフォーマンス, 5.1

ワークロードのベンチマーク, 2.6.2.2 ビッグ・バン・ロールアウトの方法, 2.7.1 バインド変数, 7.3.1.3

照合, 11.1.3

ビットマップ索引, 2.5.3.2.2

INLIST ITERATOR, 12.9.5.3

結合, 14.6

用途, 14.5

ブロック・クリーンアウト, 10.2.4.2 ブロック・サイズ

選択, 8.2.6

最適, 8.2.6

ボトルネック

解消, 1.1.2.4.2

修正, 3.1

特定, 3.1

メモリー, 7.1

リソース, 10.3.18.1.2

ブロードキャスト

分散値, 12.10

Bツリー索引, 2.5.3.2.1 buffer busy waitsイベント, 10.2.3, 10.3.1

処置, 10.3.1.2

バッファ・キャッシュ

競合, 10.3.2, 10.3.3, 10.3.10.2

ヒット率, 7.2.2.3

バッファ数の低減, 7.2.3.2, 7.3.4.2

バッファ・プール

デフォルト・キャッシュ, 7.2.4.1

ヒット率, 7.2.6

KEEP, 7.2.8

KEEPキャッシュ, 7.2.4.1

複数, 7.2.4

RECYCLEキャッシュ, 7.2.4.1

ビジネス・ロジック, 2.4.1.2.2, 2.5.6 BYTES列

PLAN_TABLE表, 12.10

C

CARDINALITY列

PLAN_TABLE表, 12.10

カーディナリティ, 列 11.1.2.2 デカルト結合, 11.3.6 連鎖行, 10.2.4.3 クラス

待機イベント, 5.1.1.1, 10.1.3.2

クライアント/サーバー・アプリケーション, 9.4.1.2 クラスタ, 14.8, 14.8

ハッシュおよびスキャン, 11.2.5

スキャン, 11.2.4

ソートされたハッシュ, 14.9

列の順序

索引, 2.5.3.5

列

カーディナリティ11.1.2.2

索引付け, 14.1.3

COMPATIBLE初期化パラメータ, 4.1.1 コンポーネント

ハードウェア, 2.4.1.1

ソフトウェア, 2.4.1.2

コンポジット索引, 14.1.4 コンポジット・パーティション化

例, 12.9.2

概念的なモデル化, 3.1.2 一貫性

読取り, 10.2.4.2

consistent gets from cache統計, 7.2.2.3 一貫モード

TKPROF, 21.4.4.1

制約, 14.1.10 競合

ライブラリ・キャッシュ・ラッチ, 10.3.10.3

メモリー, 7.1, 10

共有プール, 10.3.10.3

チューニング, 10

待機イベント, 10.3.10

コンテキスト・スイッチ, 9.4.1.4.2 CONTROL_FILES初期化パラメータ, 4.1.1 CONTROL_MANAGEMENT_PACK_ACCESS初期化パラメータ

自動データベース診断モニターの有効化, 6.2

コスト

オプティマイザ計算, 11.1.1

COST列

PLAN_TABLE表, 12.10

コストベースの最適化,

プラン・スタビリティの手順, 20.2

アップグレード, 20.2.2

CPU, 2.4.1.1.1

統計, 5.1.2.1, 10.1.2.1.3

使用率, 9.4.1

CREATE INDEX文

PARALLEL句, 4.2.3

CREATE OUTLINE文, 20.1.5 create_extended_statistics, 13.5.2.1.1, 13.5.2.2.1 CREATE_STORED_OUTLINES初期化パラメータ, 20.1.5, 20.1.5.1 CREATE_STORED_OUTLINESパラメータ, 20.1.5 現行モード

TKPROF, 21.4.4.1

CURSOR_NUM列

TKPROF_TABLE表, 21.4.5.3

CURSOR_SHARING初期化パラメータ, 7.3.2.1 CURSOR_SPACE_FOR_TIME初期化パラメータ, 7.3.6 カーソル

アクセス, 7.3.2.6

共有, 7.3.2.6

D

データ

トランザクション, 2.4.1.2.4

キャッシュ, 9.1.1

収集, 5.1

モデル化, 2.5.2

問合せ, 2.4.2

検索, 2.4.2

データ・ディクショナリ, 7.3.4.1.2

統計, 13.7.1

最適化で使用されるビュー, 13.7.1

データ・ポンプ

エクスポート・ユーティリティ

システム生成の列名の統計, 13.5.4

インポート・ユーティリティ

統計のコピー, 13.5.4

データベース監視, 1.2.1, 16.4.1

診断, 6.1

Database Resource Manager, 9.1.3, 9.1.3, 9.4.2, 10.1.2.1.3 データベース・チューニング

一時的なパフォーマンスの問題, 5.3.8

データベース

バッファ, 7.2.3.2, 7.3.4.2

診断と監視, 6.1

サイズ, 2.4.2

統計, 5.1.1

DATE_OF_INSERT列

TKPROF_TABLE表, 21.4.5.3

db block gets from cache統計, 7.2.2.3 db file scattered read待機イベント, 10.2.3, 10.3.2, 10.3.2

処置, 10.3.2.1, 10.3.3.1

db file sequential read待機イベント, 10.2.3, 10.3.2, 10.3.3

処置, 10.3.3.1

DB time

メトリック, 6.1.1

統計, 5.1.1.2

DB_BLOCK_SIZE初期化パラメータ, 4.1.1, 8.2.1.2 DB_CACHE_ADVICEパラメータ, 7.2.3.1 DB_CACHE_SIZE初期化パラメータ, 7.2.3.2, 7.2.4 DB_DOMAIN初期化パラメータ, 4.1.1 DB_FILE_MULTIBLOCK_READ_COUNT初期化パラメータ, 8.2.1.1, 8.2.1.2, 8.2.1.3, 10.3.2, 11.2.1

コストベースの最適化, 11.3.2

DB_KEEP_CACHE_SIZE

初期化パラメータ, 7.2.8

DB_NAME初期化パラメータ, 4.1.1 DB_nK_CACHE_SIZE初期化パラメータ, 7.2.3.1 DB_RECYCLE_CACHE_SIZE

初期化パラメータ, 7.2.9

DB_WRITER_PROCESSES初期化パラメータ, 10.3.8.3.1 DBA_HISTビュー, 5.3.5 DBA_HIST_WR_CONTROLビュー

自動ワークロード・リポジトリ設定, 5.3.1.3

DBA_OBJECTSビュー, 7.2.7 DBA_OUTLINE_HINTSビュー

ストアド・アウトライン・ヒント, 20.1.7

DBA_OUTLINESビュー

ストアド・アウトライン, 20.1.7

DBIO_EXPECTEDパラメータ, 6.2 DBMS_ADDMパッケージ

自動データベース診断モニター, 6.3

DBMS_ADVISORパッケージ, 18.1

DBIO_EXPECTEDの設定, 6.2

ADDM用の設定, 6.2, 6.2

DBMS_MONITORパッケージ

エンドツーエンド・アプリケーションのトレース, 21.1

DBMS_OUTLNパッケージ

アウトライン管理用のプロシージャ, 20.1.4

DBMS_OUTLN_EDITパッケージ

アウトライン管理用のプロシージャ, 20.1.4

DBMS_RESULT_CACHE, 7.6.1.3, 7.6.1.3.2 DBMS_SHARED_POOLパッケージ

共有プールの管理, 7.3.9

DBMS_SPM

EVOLVE_SQL_PLAN_BASELINE, 15.2.3.2

DBMS_SQLDIAG, 16.6.1.2 DBMS_SQLTUNEパッケージ

SQLチューニング・アドバイザ, 17.3.4, 17.4

SQLチューニング・セット, 17.4

dbms_statsファンクション

create_extended_statistics, 13.5.2.1.1

drop_extended_stats, 13.5.2.1.3, 13.5.2.2.3

gather_table_stats, 13.5.2.2.1

show_extended_stats_name, 13.5.2.1.2

dbms_statsパッケージ

method_opt, 13.5.2.1.5

DBMS_STATSパッケージ, 13.3.1, 13.3.4, 18.1

問合せオプティマイザ統計の管理, 11.5.2.3

収集プロシージャのサンプル・サイズの手動決定, 13.3.1.1

DBMS_STATS_DISCOVER, 13.5.2.1 DBMS_WORKLOAD_REPOSITORYパッケージ

自動ワークロード・リポジトリの管理, 5.3.1, 5.3.2, 5.3.3

DBMS_XPLANパッケージ

PLAN TABLE出力の表示, 12.4

設計のデバッグ, 2.6.4 デフォルト・キャッシュ, 7.2.4.1 アプリケーションのデプロイ, 2.7 DEPTH列

TKPROF_TABLE表, 21.4.5.3

設計の原則, 2.5 設計

デバッグ, 2.6.4

テスト, 2.6.4

検証, 2.6.4

開発環境, 2.5.6 診断モニター, 1.2.1, 6.1, 16.4.1

概要, 6.1

DIAGNOSTIC_DEST初期化パラメータ, 21.4.1 direct path

readイベント, 10.3.4

readイベントの処置, 10.3.4.2

readイベントの原因, 10.3.4.1

待機イベント, 10.3.5

writeイベントの処置, 10.3.5.2

writeイベントの原因, 10.3.5.1

使用禁止にされた制約, 14.1.10 ディスク

オペレーティング・システムファイル・アクティビティの監視, 10.1.2.2

統計, 5.1.2.3

DISTRIBUTION列

PLAN_TABLE表, 12.10

ドメイン索引

EXPLAIN PLAN, 12.9.6

使用, 14.7

drop_extended_stats, 13.5.2.1.3, 13.5.2.2.3 動的統計

プロセス, 13.6.2.1

サンプリング・レベル, 13.6.2.1

用途, 13.6.4

E

緊急事態

パフォーマンス, 3.2

パフォーマンスの緊急の問題に対処する方法, 3.2.1 使用可能にされた制約, 14.1.10 エンドツーエンド・アプリケーションのトレース, 21, 21.1

アクション名とモジュール名, 2.5.6, 21.1

サービスの作成, 21.1

DBMS_APPLICATION_INFOパッケージ, 21.1

DBMS_MONITORパッケージ, 21.1

規定された制約, 14.1.10 enqueue待機イベント, 10.2.3, 10.3.6

処置, 10.3.6.2

統計, 10.1.3.4.5

等価結合, 16.5.3.1 エラー・メッセージ・マニュアル, Preface ワークロードの見積り, 2.6.2

ベンチマーク, 2.6.2.2

推定, 2.6.2.1

例

ALTER SESSION文, 21.4.2

EXPLAIN PLAN出力, 21.4.4.10

SQLトレース機能の出力, 21.4.4.10

EXECUTE_TASKプロシージャ, 18.2.5.5.1 実行計画

SQL計画ベースラインの取得, 15.2.1

SQL計画ベースラインの改良, 15.2.3

例, 21.4.3.1

結合, 11.3.1

SQLチューニング・セットからのロード, 15.2.1.2.1

AWRスナップショットからのロード, 15.2.1.2.1

カーソル・キャッシュからのロード, 15.2.1.2.2

SQL計画ベースラインの管理, 15.2

概要, 11.4

プラン・スタビリティ, 20.1

プラン・スタビリティによる保持, 20.1

SQL計画ベースラインの選択, 15.2.2

TKPROF, 21.4.3.1, 21.4.3.2

utlxpls.sqlスクリプトによる表示, 11.4.1

EXPLAIN PLAN文

アクセス・パス, 11.2.6

ドメイン索引, 12.9.6

フル・パーティション・ワイズ結合, 12.9.4

パーシャル・パーティション・ワイズ結合, 12.9.3

パーティション・オブジェクト, 12.9

基本ステップ, 11.4.1

出力の例, 21.4.4.10

出力ステップの実行順序, 11.4.1

TKPROFプログラムでの起動, 21.4.3.2

PLAN_TABLE表, 12.2

制限事項, 12.1.4

出力表示用スクリプト, 11.4.1

出力の表示, 11.4.1

EXPLAIN_MVIEWプロシージャ, 18.3 式

型が混在, 16.5.3.2

式の統計, 13.5.2.2 拡張統計, 13.5.2 拡張構文

ヒントにおける表の指定, 19.2.3

グローバル・ヒント, 19.2.3

EXTENT MANAGEMENT LOCAL

一時表領域の作成, 4.1.4.2

ワークロードの推定, 2.6.2.1

F

FAST_START_MTTR_TARGET

インスタンス・リカバリのチューニング, 10.5.3

ファスト・スタート・チェックポイント・アーキテクチャ, 10.5.2 ファスト・スタート・リカバリ機能, 10.5, 10.5.2 機能, 新規, Preface FILESYSTEMIO_OPTIONS初期化パラメータ, 9.1.1.2 FIRST_ROWS(n)ヒント, 11.5.2.2 free buffer waitsイベント, 10.2.3, 10.3.8 空きリスト, 10.3.1.2.1 FULLヒント, 14.1.6 完全外部結合, 11.3.7.4 フル・パーティション・ワイズ結合, 12.9.4 全表スキャン, 10.3.4.2.2 ファンクション索引, 2.5.3.2.3, 14.2

G

GATHER_INDEX_STATSプロシージャ

DBMS_STATSパッケージ, 13.3.1

GATHER_DATABASE_STATSプロシージャ

DBMS_STATSパッケージ, 13.3.1

GATHER_DICTIONARY_STATSプロシージャ

DBMS_STATSパッケージ, 13.3.1 13.3.4

GATHER_SCHEMA_STATSプロシージャ

DBMS_STATSパッケージ, 13.3.1 13.3.4

gather_table_stats, 13.5.2.2.1 GATHER_TABLE_STATSプロシージャ

DBMS_STATSパッケージ, 13.3.1 13.3.4

GETMISSES列

V$ROWCACHE表, 7.3.4.1.2

GETS列

V$ROWCACHEビュー, 7.3.4.1.2

グローバル・ヒント, 19.2.3 GV$BUFFER_POOL_STATISTICSビュー, 7.2.6

H

ハード解析, 2.5.5

ハードウェア

コンポーネント, 2.4.1.1

コンポーネントの制限, 2.3.3

コンポーネントのサイズ指定, 2.3.3

ハッシュ

分散値, 12.10

ハッシュ・クラスタ

スキャン, 11.2.5

ソート, 14.9

ハッシュ結合, 11.3.4

コストベースの最適化, 11.3.2

索引結合, 11.2.3.8.1

ハッシュ・パーティション, 12.9

例, 12.9.1

ハッシング, 14.9 最高水位標, 11.2.1 ヒント

アクセス・パス, 16.5.4, 19.1.2.8

アウトラインでの使用, 20.1.1.1

サンプル・アクセス・パスは上書き不可, 11.2.7

並列度, 19.1.2.7

FULL, 14.1.6

グローバル, 19.2.3

グローバルとローカルの比較, 19.2.3

INDEX_FFS, 11.2.3.7

INDEX_JOIN, 11.2.3.8

indexspec構文, 19.2.4

位置構文, 19.2.2

NO_INDEX, 14.1.6

最適化アプローチと目標, 19.1.2.1

オプティマイザの選択を上書き, 11.2.7

OPTIMIZER_MODEの上書き, 11.5.2.2

パラレル問合せオプション, 19.1.2.7

問合せブロックの指定, 19.2.2

索引の指定, 19.2.4

tablespec構文, 19.2.3

拡張構文の使用, 19.2.3

ヒストグラム

頻度, 13.7.2.2

高さ調整済, 13.7.2.1

HOLD_CURSOR句, 7.3.2.6.2 サービス時間, 2.4.2 HWエンキュー

競合, 10.3.6.2.2

I

ID列

PLAN_TABLE表, 12.10

アイドル待機イベント, 10.3.9

SQL*Net message from client, 10.3.18.1

ビジネス・ロジックの実装, 2.4.1.2.2 INDEXヒント, 14.1.6 INDEX_COMBINEヒント, 14.1.6 INDEX_FFSヒント, 11.2.3.7, 11.2.3.7.1 INDEX_JOINヒント, 11.2.3.8 索引

列の追加, 2.5.3.1

列の追加, 2.5.3.1

不使用, 14.1.6

ビットマップ, 2.5.3.2.2, 14.5

Bツリー, 2.5.3.2.1

列の選択, 14.1.3

列の順序, 2.5.3.5

コンポジット, 14.1.4

コスト, 2.5.3.3

作成, 4.2.3

設計, 2.5.3

ドメイン, 14.7

削除, 14.1.1

一意性の規定, 14.1.9

使用の保証, 14.1.5

ファンクション索引, 2.5.3.2.3, 14.2

選択性の向上, 14.1.4

索引結合, 11.2.3.8.1

結合, 11.2.3.8.1

低選択性, 14.1.6

値の修正, 14.1.3

一意でない, 14.1.9

パーティション化, 2.5.3.2.4

ディスク上の配置, 8.2.2

再作成, 14.1.7

再作成, 14.1.7

I/Oの削減, 2.5.3.5

逆キー, 2.5.3.2.5

スキャン, 11.2.3

選択性, 2.5.3.5

選択性, 14.1.3

順序, 2.5.3.4

シリアライズ, 2.5.3.4

ヒントでの指定, 19.2.4

統計の収集, 13.5

indexspec

ヒント構文, 19.2.4

初期化パラメータ

CONTROL_FILES, 4.1.1

DB_BLOCK_SIZE, 4.1.1

DB_DOMAIN, 4.1.1

DB_FILE_MULTIBLOCK_READ_COUNT, 11.3.2

DB_NAME, 4.1.1

DIAGNOSTIC_DEST, 21.4.1

OPEN_CURSORS, 4.1.1

OPTIMIZER_FEATURES_ENABLE, 11.2.3.7, 11.2.3.8

OPTIMIZER_MODE, 11.5.2.1, 19.1.2.1

PGA_AGGREGATE_TARGET, 4.2.3.1

PROCESSES, 4.1.1

SESSIONS, 4.1.1

STREAMS_POOL_SIZE, 4.1.1, 7.1.3

INLIST ITERATOR操作, 12.9.5 INLIST, 12.9.5 インスタンス・ケージング, 9.4 インスタンスの構成

初期化ファイル, 4.1.1

パフォーマンスの考慮事項, 4.1

インスタンス・リカバリ

ファスト・スタート・リカバリ機能, 10.5.2

パフォーマンス・チューニング, 10.5

インターネットのスケーラビリティ, 2.3.2 I/O

SQL文, 10.3.2.4

競合, 5.1.1.1, 10.1.2.2.1, 10.1.3.2, 10.3.2.2, 10.3.14

過剰なI/O待機, 10.3.2.2

監視, 10.1.2.2

I/O待機を発生させるオブジェクト, 10.3.2.5

削減, 14.1.4

J

結合

アンチ結合, 11.3.2

デカルト, 11.3.6

実行計画, 11.3.1

完全外部, 11.3.7.4

ハッシュ, 11.3.4

索引結合, 11.2.3.8.1

結合順序および実行計画, 11.4

ネステッド・ループ, 11.3.3

ネステッド・ループおよびコストベースの最適化, 11.3.2

順序, 16.5.4, 16.5.4

外部, 11.3.7

パーティション・ワイズ

フルの例, 12.9.4

パーシャルの例, 12.9.3

フル, 12.9.4

セミ結合, 11.3.2 ソート/マージ, 11.3.5 ソート/マージおよびコストベースの最適化, 11.3.2, 11.3.2

K

KEEPバッファ・プール, 7.2.8

KEEPキャッシュ, 7.2.4.1

L

LARGE_POOL_SIZE初期化パラメータ, 7.3.5.1

ラッチの競合

ライブラリ・キャッシュ・ラッチ, 10.2.1.2

共有プール・ラッチ, 10.2.1.2

latch free待機イベント, 10.2.3

処置, 10.3.10.1

ラッチ待機イベント, 10.3.10 ラッチ, 5.3.9.7.3

チューニング, 1.1.2.3, 10.3.10.3

ライブラリ・キャッシュ

ラッチの競合, 10.3.10.3

ラッチ待機イベント, 10.3.10.1

ロック, 10.3.13

メモリー割当て, 7.3.4.1.1

PIN, 10.3.12

線形のスケーラビリティ, 2.3.3 ロックおよびロック・ホルダー

検索, 10.3.6.1

ログ・バッファ

space待機イベント, 10.2.3, 10.3.14

チューニング, 7.4.1

log file

parallel write待機イベント, 10.3.11

switch待機イベント, 10.3.15

sync待機イベント, 10.2.3, 10.3.16

ログ・ライター・プロセス

チューニング, 8.2.3.2

LOG_BUFFER初期化パラメータ, 7.4

設定, 7.4.2

LRU

除去方針, 7.2.4

ラッチの競合, 110.3.10.3.4

M

ユーザー・インタフェースの管理, 2.4.1.2.1

マテリアライズド・ビュー

チューニング, 18.3

最大セッション・メモリー統計, 7.3.5.1.2 MAX_DISPATCHERS初期化パラメータ, 4.3.1.1 MAX_DUMP_FILE_SIZE初期化パラメータ

SQLトレース, 21.4.1

MAXOPENCURSORS句, 7.3.2.6.2 メモリー

ハードウェア・コンポーネント, 2.4.1.1.2

メモリー割当て

重要性, 7.1

ライブラリ・キャッシュ, 7.3.4.1.1

共有SQL領域, 7.3.4.1.1

チューニング, 7.1.7

method_opt, 13.5.2.1.5 メトリック, 5.1 移行行, 10.2.4.3 ミラー化

REDOログ, 8.2.3.3

モデル化

概念的, 3.1.2

データ, 2.5.2

ワークロード, 2.6.3

監視

診断, 1.2.1, 16.4.1

複数列の統計, 13.5.2.1 複数バッファ・プール, 7.2.4

N

NAMESPACE列

V$LIBRARYCACHEビュー, 7.3.3.2

ネステッド・ループ結合, 11.3.3

コストベースの最適化, 11.3.2

ネットワーク

ハードウェア・コンポーネント, 2.4.1.1.4

速度, 2.4.2

統計, 5.1.2.4

ネットワーク通信待機イベント, 10.3.18

db file scattered read待機イベント, 10.3.2

db file sequential read待機イベント, 10.3.2, 10.3.3

SQL*Net message from dblink, 10.3.18.2

SQL*Net more data to client, 10.3.18.3

新機能, Preface NO_INDEXヒント, 14.1.6 NOT IN副問合せ, 11.3.2

O

OBJECT_INSTANCE列

PLAN_TABLE表, 12.10

OBJECT_NAME列

PLAN_TABLE表, 12.10

OBJECT_NODE列

PLAN_TABLE表, 12.10

OBJECT_OWNER列

PLAN_TABLE表, 12.10

OBJECT_TYPE列

PLAN_TABLE表, 12.10

オブジェクト指向, 2.5.7 OLAP_PAGE_POOL_SIZE初期化パラメータ, 7.5.2 OPEN_CURSORS初期化パラメータ, 4.1.1 オペレーティング・システム

データ・キャッシュ, 9.1.1

ディスクI/Oの監視, 10.1.2.2

統計, 5.1.2

OPERATION列

PLAN_TABLE表, 12.10, 12.10

最適化

アプローチの選択, 11.5.2.1

コスト計算, 11.1.1

コストベースおよびアクセス・パスの選択, 11.2.7

説明, 11.1

ヒント, 11.2.3.7, 11.2.3.8, 11.5.2.2

手動, 11.5.2.2

実行される操作, 11.1.1

オプティマイザ

コスト計算, 11.1.1

エスティメータ11.1.2.2

目標, 11.5.2

概要, 1.1.3.1, 11.1

モード, 17.1

RBOからの移行, 20.2.1

操作, 11.1.1

設定モードのパラメータ, 11.5.2.1

プラン・スタビリティ, 20.1

問合せ, 11.3.1

統計, 13.1

スループット, 11.5.2

アップグレード, 20.2.2

OPTIMIZER列

PLAN_TABLE, 12.10

OPTIMIZER_FEATURES_ENABLE初期化パラメータ, 11.2.3.7, 11.2.3.8 OPTIMIZER_MODE初期化パラメータ, 11.5.2.1, 11.5.2.1, 19.1.2.1

ヒントの影響, 11.5.2.2

OPTIONS列

PLAN_TABLE表, 12.10

Oracle CPU統計, 10.1.2.1.3 Oracle Enterprise Manager

アドバイザ, 1.2.1

「パフォーマンス」ページ, 1.2.1

Oracle Forms

解析とプライベートSQL領域の制御, 7.3.2.6.5

Oracle Managed Files, 8.2.5

チューニング, 8.2.5

Oracle Orion,

測定ツール・パラメータ, 8.4.4

コマンドライン・オプション, 8.4.4

Oracleのパフォーマンス改善方法, 3.1

手順, 3.1.1

順序

結合, 16.5.4

OTHER列

PLAN_TABLE表, 12.10

OTHER_TAG列

PLAN_TABLE表, 12.10

外部結合, 11.3.7, 16.5.4.1 アウトライン

CREATE OUTLINE文, 20.1.5

作成と使用, 20.1.5

説明, 20.1

実行計画とプラン・スタビリティ, 20.1

ヒント, 20.1.1.1

表の移動, 20.1.8

コストベース・オプティマイザへの移行, 20.2.1

格納要件, 20.1.2

使用, 20.1.6

データの表示, 20.1.7

P

パッケージ

DBMS_RESULT_CACHE, 7.6.1.3, 7.6.1.3.2

パッケージ

DBMS_ADVISOR, 18.1

DBMS_STATS, 18.1

ページ表, 9.4.1.1.2 ページング, 9.4.1.2

削減, 7.1.6.1

PARALLEL句

CREATE INDEX文, 4.2.3

パラメータ

RESULT_CACHE_MAX_SIZE, 7.6.1.3.1

RESULT_CACHE_MODE, 7.6.3.1

PARENT_ID列

PLAN_TABLE表, 12.10

解析

ハード, 2.5.5

Oracle Forms, 7.3.2.6.5

Oracleプリコンパイラ, 7.3.2.6.2

不要コールの低減, 7.3.2.6

ソフト, 2.5.5

PARTITION_ID列

PLAN_TABLE表, 12.10

PARTITION_START列

PLAN_TABLE表, 12.10

PARTITION_STOP列

PLAN_TABLE表, 12.10

パーティション索引, 2.5.3.2.4 パーティション・オブジェクト

EXPLAIN PLAN文, 12.9

パーティション化

分散値, 12.10

例, 12.9.1

コンポジットの例, 12.9.2

ハッシュ, 12.9

レンジ, 12.9

開始列と終了列, 12.9.1

パーティション・ワイズ結合

フル, 12.9.4

フル, EXPLAIN PLAN出力, 12.9.4

パーシャル, EXPLAIN PLAN出力, 12.9.3

PCTFREEパラメータ, 4.2, 10.2.4.3 PCTUSEDパラメータ, 10.2.4.3, 10.2.4.3 照合

バインド変数, 11.1.3

パフォーマンス

緊急事態, 3.2

改善方法, 3.1

改善方法の手順, 3.1.1

メインフレーム, 9.2.3

Windowsでのメモリーの監視, 9.4.1.1.1

診断およびチューニング用のツール, 1.2

UNIXベース・システム, 9.2.1

実行計画の表示, 11.4.1

Windows, 9.2.2

パフォーマンスの問題

一時的, 5.3.8

パフォーマンス・チューニング

ファスト・スタート・リカバリ機能, 10.5

インスタンス・リカバリ, 10.5

FAST_START_MTTR_TARGET, 10.5.2

FAST_START_MTTR_TARGETの設定, 10.5.3

V$INSTANCE_RECOVERYの使用, 10.5.2.3

PGA_AGGREGATE_TARGET初期化パラメータ, 4.1.1, 4.2.3.1, 7.5.1, 9.1.2.2 physical reads from cache統計, 7.2.2.3 プラン・スタビリティ, 20.1

制限, 20.1.1

実行計画の保持, 20.1

コストベース・オプティマイザの手順, 20.2

ヒントの使用, 20.1.1

PLAN_TABLE表

BYTES列, 12.10

CARDINALITY列, 12.10

COST列, 12.10

作成, 12.2, 12.2

表示, 12.4

DISTRIBUTION列, 12.10

ID列, 12.10

OBJECT_INSTANCE列, 12.10

OBJECT_NAME列, 12.10

OBJECT_NODE列, 12.10

OBJECT_OWNER列, 12.10

OBJECT_TYPE列, 12.10

OPERATION列, 12.10

OPTIMIZER列, 12.10

OPTIONS列, 12.10

OTHER列, 12.10

OTHER_TAG列, 12.10

PARENT_ID列, 12.10

PARTITION_ID列, 12.10

PARTITION_START列, 12.10

PARTITION_STOP列, 12.10

POSITION列, 12.10

REMARKS列, 12.10

SEARCH_COLUMNS列, 12.10

STATEMENT_ID列, 12.10

TIMESTAMP列, 12.10

PL/SQLプロシージャ

EXPLAIN_MVIEW, 18.3

TUNE_MVIEW, 18.3

POSITION列

PLAN_TABLE表, 12.10

プリコンパイラ

解析とプライベートSQL領域の制御, 7.3.2.6.2

PRIMARY KEY制約, 14.1.9 PRIVATE_SGA変数, 7.3.5.1.3 権限

SQLアクセス・アドバイザ, 18.2.2

プロアクティブな監視, 1.1.2.4.1 プロセス

スケジューリング, 9.4.1.4.1

PROCESSES初期化パラメータ, 4.1.1 プログラム・グローバル領域(PGA)

direct path read, 10.3.4

direct path write, 10.3.5

共有サーバー, 7.3.5.1.1

プログラミング言語, 2.5.6

Q

問合せ

索引不使用, 14.1.6

データ, 2.4.2

索引使用の保証, 14.1.5

問合せオプティマイザ, 1.1.3.1

「オプティマイザ」を参照

R

レンジ

分散値, 12.10

パーシャルの例, 12.9.1

パーティション, 12.9

rdbms ipc reply待機イベント, 10.3.17 読取り一貫性, 10.2.4.2 read待機イベント

direct path, 10.3.4

scattered, 10.3.2

REBUILD句, 14.1.7 再帰的コール, 21.4.4.5 RECYCLEキャッシュ, 7.2.4.1 REDO BUFFER ALLOCATION RETRIES統計, 7.4.2 REDOログ, 4.1.3

バッファ・サイズ, 10.3.14

ミラー化, 8.2.3.3

ディスク上の配置, 8.2.3.2

サイズ設定, 4.1.3

領域リクエスト, 10.2.4.1

低減

ディスパッチャの競合, 4.3.1.1

データ・ディクショナリ・キャッシュ・ミス, 7.3.4.1.2

ページングとスワッピング, 7.1.6.1

不要解析コール, 7.3.2.6

RELEASE_CURSOR句, 7.3.2.6.2 REMARKS列

PLAN_TABLE表, 12.10

リソース

割当て, 2.4.1.2.3, 2.5.6

ボトルネック, 10.3.18.1.2

待機イベント, 10.3.3

レスポンス時間, 2.4.2

コストベースのアプローチ, 11.5.2.1

結果キャッシュ, 7.6.1 逆キー索引, 2.5.3.2.5 ロールアウトの方法

ビッグ・バン・アプローチ, 2.7.1

トリクル・アプローチ, 2.7.1

ラウンドロビン

分散値, 12.10

行キャッシュ・オブジェクト, 10.3.10.3.6 行ソース, 11.4.2 ROWID

表アクセス, 11.2.2

行

行ソース, 11.4.2

位置特定に使用されるROWID, 11.2.2

S

SAMPLE BLOCK句, 11.2.6

アクセス・パスおよびヒント, 11.2.7

SAMPLE句, 11.2.6

アクセス・パスおよびヒントによる上書き不可, 11.2.7

サンプル表スキャン, 11.2.6

ヒントによる上書き不可, 11.2.7

sar UNIXコマンド, 9.4.1.1.1 スケーラビリティ, 2.3.1

妨げる要因, 2.3.3, 2.3.3

インターネット, 2.3.2

線形, 2.3.3

スキャン

索引, 11.2.3

索引結合, 11.2.3.8.1

タイプ・ビットマップの索引, 11.2.3.9

サンプル表, 11.2.6

サンプル表およびヒントは上書き不可, 11.2.7

scattered read待機イベント, 10.3.2

処置, 10.3.2.1

SEARCH_COLUMNS列

PLAN_TABLE表, 12.10

セグメント・レベルの統計, 10.1.3.5 SELECT文

SAMPLE句, 11.2.6

選択性

索引の作成, 14.1.3

索引の向上, 14.1.4

索引, 14.1.6

索引内の列の順序付け, 2.5.3.5

セミ結合, 11.3.2 sequential read待機イベント

処置, 10.3.3.1

サービス時間, 2.4.2 セッション・メモリー統計, 7.3.5.1.2 SESSIONS初期化パラメータ, 4.1.1 SGAサイズ, 7.4.1 SGA_TARGET初期化パラメータ, 4.1.1

自動共有メモリー管理, 7.1.3

自動メモリー管理, 7.1.3

共有プール競合, 10.3.10.3 共有サーバー

パフォーマンス問題, 4.3

競合の低減, 4.3

チューニング, 4.3

メモリーのチューニング, 7.3.5.1

共有SQL領域

メモリー割当て, 7.3.4.1.1

SHARED_POOL_RESERVED_SIZE初期化パラメータ, 7.3.8.2 SHARED_POOL_SIZE初期化パラメータ, 7.3.4.1.2, 7.3.4.2, 7.3.8.4

ライブラリ・キャッシュの割当て, 7.3.4.1.1

共有プールのチューニング, 7.3.5.1.4

SHOW SGA文, 7.1.6.2 show_extended_stats_name, 13.5.2.1.2 REDOログのサイズ設定, 4.1.3 スナップショット

概要, 5.2.1

ソフト解析, 2.5.5 ソフトウェア

コンポーネント, 2.4.1.2

ソート領域

チューニング, 7.5

ソート/マージ結合, 11.3.5

コストベースの最適化, 11.3.2

SQLアクセス・アドバイザ, 18.1, 18.1, 18.2.3.2

定数, 18.2.8

タスクの作成, 18.1.1

EXECUTE_TASKプロシージャ, 18.2.5.5.1

推奨事項の生成, 18.1.1

権限, 18.2.2

推奨プロセス, 18.2.5.7

使用手順, 18.1.1

SQL管理ベース

概要, 15.6

ディスク領域の使用量, 15.6.1

消去方針, 15.6.2

SQL計画ベースライン

計画の自動取得, 15.2.1.1

取得

自動, 15.2.1.1

手動, 15.2.1.2

手動による改良, 15.2.3.1 DBMS_SPM.EVOLVE_SQL_PLAN_BASELINEによる改良, 15.2.3.2 SQLチューニング・セットからの計画のロード, 15.2.1.2.1 AWRスナップショットからの計画のロード, 15.2.1.2.1 カーソル・キャッシュからの計画のロード, 15.2.1.2.2 計画の手動ロード, 15.2.1.2 SQLチューニング・アドバイザ, 15.3 SQL計画ベースライン, 固定, 15.4 SQL計画ベースライン

概要, 15.2.1

取得, 15.2.1

表示, 15.5

有効化, 15.2.2

改良, 15.2.3

インポートとエクスポート, 15.7

管理, 15.2

計画の履歴, 15.2.1

選択, 15.2.2

文のログ, 15.2.1

SQL文

索引不使用, 14.1.6

索引使用の保証, 14.1.5

実行計画, 11.4

索引データの修正, 14.1.3

I/Oを待機, 10.3.2.4

SQLテスト・ケース・ビルダー, 16.6 SQLトレース機能, 21.3.1, 21.4.3

出力の例, 21.4.4.10

出力, 21.4.4.1

文の切捨て, 21.4.4.7

実行手順, 21.4

トレース・ファイル, 21.4.1

SQLチューニング・アドバイザ, 1.2.1, 16.4.2

APIを使用した管理, 17.3.4, 17.4

入力ソース, 17.3.1

概要, 17.2

チューニング・オプション, 17.3.2

SQLチューニング・セット

説明, 16.4.3, 17.3, 17.3.1, 17.3.4

APIによる管理, 17.4, 17.4

SQL*Net

message from clientアイドル・イベント, 10.3.18.1

message from dblink待機イベント, 10.3.18.2

more data to client待機イベント, 10.3.18.3

SQL, 再帰的, 13.6 SQL_STATEMENT列

TKPROF_TABLE, 21.4.5.3

SQLアクセス・アドバイザ, 1.2.1, 16.4.4 SQLTUNE_CATEGORY初期化パラメータ

SQLプロファイルのカテゴリの判別, 17.5.3

STエンキュー

競合, 10.3.6.2.1

開始列

パーティション化とEXPLAIN PLAN文, 12.9.1

STATEMENT_ID列

PLAN_TABLE表, 12.10

統計

STATISTICS_LEVEL初期化パラメータ, 1.2

ベースライン, 5.1

consistent gets from cache, 7.2.2.3

データベース, 5.1.1

db block gets from cache, 7.2.2.3

ビューに表示, 13.7.1

エクスポートとインポート, 13.5.4

収集, 5.1

失効した統計の収集, 13.3.1.5

サンプリングを使用した収集, 13.3.1.1

DBMS_STATSパッケージによる収集, 13.3.1, 13.3.4

DBMS_STATSプロシージャによる収集, 13.3.1

前のバージョンのリストアに関する制限, 13.5.3

ロック, 13.5.6

手動による収集, 13.3

最大セッション・メモリー, 7.3.5.1.2

欠落, 13.5.8

オペレーティング・システム, 5.1.2

CPU統計, 5.1.2.1

ディスク統計, 5.1.2.3

ネットワーク統計, 5.1.2.4

仮想メモリー統計, 5.1.2.2

オプティマイザ, 13.1 オプティマイザ・モード, 11.5.2.1 physical reads from cache, 7.2.2.3 旧バージョンのリストア, 13.5.3 セグメント・レベル, 10.1.3.5 セッション・メモリー, 7.3.5.1.2 共有サーバー・プロセス, 4.3.2 失効, 13.3.1.5 システム, 13.4 時間モデル, 5.1.1.2 ユーザー定義, 13.3.1.6 収集する時期, 13.3.3 STATISTICS_LEVEL初期化パラメータ, 5.1.3, 10.1.3.1

自動ワークロード・リポジトリ, 5.2

自動データベース診断モニターの有効化, 6.2

統計収集用の設定, 1.2

終了列

パーティション化とEXPLAIN PLAN文, 12.9.1

ストアド・アウトライン

作成と使用, 20.1.5

実行計画とプラン・スタビリティ, 20.1

ヒント, 20.1.1.1

表の移動, 20.1.8

格納要件, 20.1.2

使用, 20.1.6

データの表示, 20.1.7

STREAMS_POOL_SIZE初期化パラメータ, 4.1.1, 7.1.3 ストライプ化

手動, 8.2.2

副問合せ

NOT IN, 11.3.2

ネスト解除, 16.5.4.1.3

スワッピング, 9.4.1.1.1, 9.4.1.2

削減, 7.1.6.1

プロセスのスイッチング, 9.4.1.4.1 システム・アーキテクチャ, 2.4

構成, 2.4.2

ハードウェア・コンポーネント, 2.4.1.1

CPU, 2.4.1.1.1

I/Oサブシステム2.4.1.1.3

メモリー, 2.4.1.1.2

ネットワーク, 2.4.1.1.4

ソフトウェア・コンポーネント, 2.4.1.2

データおよびトランザクション, 2.4.1.2.4

ビジネス・ロジックの実装, 2.4.1.2.2

ユーザー・インタフェースの管理, 2.4.1.2.1

ユーザー・リクエストおよびリソース割当て, 2.4.1.2.3

システム・グローバル領域のチューニング, 7.1.6.2

T

表

作成, 4.2

設計, 2.5.3

全表スキャン, 10.3.4.2.2

ディスク上の配置, 8.2.2

記憶領域オプションの設定, 4.2

表領域, 4.1.4

作成, 4.1.4, 4.1.4.2

一時, 4.1.4, 4.1.4.2

tablespec

ヒント構文, 19.2.3

テンプレート

SQLアクセス・アドバイザ, 18.2.3.2

一時表領域, 4.1.4

作成, 4.1.4.2

設計のテスト, 2.6.4 スラッシング, 9.4.1.2 しきい値

適応, 5.2.3

スループット

オプティマイザの目標, 11.5.2

時間モデル統計, 5.1.1.2 TIMED_STATISTICS初期化パラメータ

SQLトレース, 21.4.1

TIMESTAMP列

PLAN_TABLE表, 12.10

TKPROFプログラム, 21.3.2, 21.4.3

出力SQLスクリプトの編集, 21.4.5.2

出力の例, 21.4.4.10

出力SQLスクリプトの生成, 21.4.5.1

行ソースの操作, 21.4.4.2

構文, 21.4.3.2

EXPLAIN PLAN文の使用, 21.4.3.2

待機イベント情報, 21.4.4.3

TKPROF_TABLE, 21.4.5.3, 21.4.5.3 TMエンキューの競合, 10.3.6.2.3 パフォーマンス・チューニングのツール, 1.2 上位Java

アクティブ・セッション履歴レポート, 5.3.9.5

上位PL/SQL

アクティブ・セッション履歴レポート, 5.3.9.4

上位セッション

アクティブ・セッション履歴レポート, 5.3.9.6

上位SQL

アクティブ・セッション履歴レポート, 5.3.9.3

TRACEFILE_IDENTIFIER初期化パラメータ

トレース・ファイルの識別, 21.4.1

トレース

trcsessとの統合, 21.2

ファイルの識別, 21.4.1

トランザクションおよびデータ, 2.4.1.2.4 trcsessユーティリティ, 21.2 トリクル・ロールアウトの方法, 2.7.1 TUNE_MVIEWプロシージャ, 18.3 チューニング

ボトルネックの解消, 1.1.2.4.2

プロアクティブな監視, 1.1.2.4.1

ラッチ, 1.1.2.3, 10.3.10.3

論理構造, 14.1.1

メモリー割当て, 7.1.7

リソースの競合, 10

共有サーバー, 4.3

ソート, 7.5

SQLチューニング・アドバイザ, 17.2

システム・グローバル領域(SGA), 7.1.6.2

TXエンキューの競合, 10.3.6.2.4 型変換, 16.5.3.2

U

UNDO管理, 自動モード, 4.1.2

UNDO TABLESPACE句, 4.1.2

UNDO_MANAGEMENT初期化パラメータ, 4.1.1, 4.1.2

UNDO_TABLESPACE初期化パラメータ, 4.1.1

UNIQUE制約, 14.1.9

一意性, 14.1.9

UNIXシステム・パフォーマンス, 9.2.1

変換されない列値, 16.5.3.2

アップグレード

コストベース・オプティマイザ, 20.2.2

USE_STORED_OUTLINESパラメータ, 20.1.6, 20.1.6 ユーザー・グローバル領域(UGA)

共有サーバー, 4.3, 7.3.5.1

V$SESSTAT, 7.3.5.1.2

ユーザー・リクエスト, 2.4.1.2.3 USER_DUMP_DEST初期化パラメータ

SQLトレース, 21.4.1

USER_ID列, TKPROF_TABLE, 21.4.5.3 USER_OUTLINE_HINTSビュー

ストアド・アウトライン・ヒント, 20.1.7

USER_OUTLINESビュー

ストアド・アウトライン, 20.1.7

user_stat_extensions, 13.5.2.1.4, 13.5.2.2.2 ユーザー定義のバインド変数, 11.1.3 ユーザー

対話方式, 2.4.2

インタフェース, 2.5.6

位置, 2.4.2

ネットワーク速度, 2.4.2

数, 2.4.2

リクエスト, 2.5.6

レスポンス時間, 2.4.2

SQL計画の管理の使用方法, 15 UTLCHN1.SQLスクリプト, 10.2.4.3 UTLXPLP.SQLスクリプト

PLAN TABLE出力の表示, 12.4

EXPLAIN PLANの表示用, 11.4.1

UTLXPLS.SQLスクリプト

PLAN TABLE出力の表示, 12.4

EXPLAIN PLANの表示用, 11.4.1

EXPLAIN PLANの表示に使用, 11.4.1

V

V$ACTIVE_SESSION_HISTORYビュー, 5.1.1.3, 10.1.3.3

V$ADVISOR_PROGRESSビュー, 17.3.4.5, 17.6

V$BHビュー, 7.2.7

V$BUFFER_POOL_STATISTICSビュー, 7.2.6, 7.2.6

V$DB_CACHE_ADVICEビュー, 7.2.2.1, 7.2.2.3, 7.2.3, 7.2.3.1, 7.2.3.2, 7.2.5

V$EVENT_HISTOGRAMビュー, 10.1.3.3

V$FILE_HISTOGRAMビュー, 10.1.3.3

V$JAVA_LIBRARY_CACHE_MEMORYビュー, 7.3.3.3.3

V$JAVA_POOL_ADVICEビュー, 7.3.3.3.3

V$LIBRARY_CACHE_MEMORYビュー, 7.3.3.3.2

V$LIBRARYCACHEビュー

NAMESPACE列, 7.3.3.2

V$OSSTATビュー, 5.1.2.1 V$PGASTATビュー, 7.5.1.2.1 V$PROCESSビュー, 7.5.1.2.2 V$PROCESS_MEMORYビュー, 7.5.1.2.3 V$QUEUEビュー, 4.3.2 V$ROWCACHEビュー

GETMISSES列, 7.3.4.1.2

GETS列, 7.3.4.1.2

パフォーマンス統計, 7.3.3.4

V$RSRC_CONSUMER_GROUPビュー, 10.1.2.1.3 V$SESS_TIME_MODELビュー, 5.1.1.2, 10.1.3.3 V$SESSIONビュー, 10.1.3.3, 10.1.3.4, 10.3 V$SESSION_EVENTビュー, 10.1.3.3, 10.3 V$SESSION_WAITビュー, 10.1.3.3, 10.3 V$SESSION_WAIT_CLASSビュー, 10.1.3.3 V$SESSION_WAIT_HISTORYビュー, 10.1.3.3, 10.1.3.3, 10.3 V$SESSTATビュー, 7.3.5.1.2, 10.1.2.1.3 V$SHARED_POOL_ADVICEビュー, 7.3.3.3.1 V$SHARED_POOL_RESERVEDビュー, 7.3.8.4 V$SQL_PLANビュー

実行計画の表示に使用, 12.1.3.1

V$SQL_PLAN_STATISTICSビュー

実行計画の統計表示に使用, 12.1.3.1

V$SQL_PLAN_STATISTICS_ALLビュー

実行計画の情報表示に使用, 12.1.3.1

V$SQL_WORKAREAビュー, 7.5.1.2.6 V$SQL_WORKAREA_ACTIVEビュー, 7.5.1.2.5 V$SQL_WORKAREA_HISTOGRAMビュー, 7.5.1.2.4 V$SYS_TIME_MODELビュー, 5.1.1.2, 5.1.2.1, 10.1.3.3 V$SYSMETRIC_HISTORYビュー, 5.1.2.1 V$SYSSTATビュー

REDOバッファ割当て, 7.4.2

使用, 7.2.2.3

V$SYSTEM_EVENTビュー, 10.1.3.3, 10.3 V$SYSTEM_WAIT_CLASSビュー, 10.1.3.3 V$TEMP_HISTOGRAMビュー, 10.1.3.3 V$UNDOSTATビュー, 4.1.2 V$WAITSTATビュー, 10.1.3.4 設計の検証, 2.6.4 ビュー, 2.5.4

DBA_HIST, 5.3.5

統計, 13.7.1

仮想メモリー統計, 5.1.2.2 vmstat UNIXコマンド, 9.4.1.1.1

W

待機イベント, 5.1.1.1

buffer busy waits, 10.3.1

クラス, 5.1.1.1, 10.1.3.2

競合待機イベント, 10.3.10

direct path, 10.3.5

エンキュー, 10.3.6

free buffer waits, 10.3.8

アイドル待機イベント, 10.3.9

ラッチ, 10.3.10

ライブラリ・キャッシュ・ラッチ, 10.3.10.1

log buffer space, 10.3.14

log file parallel write, 10.3.11

log file switch, 10.3.15

log file sync, 10.3.16

ネットワーク通信待機イベント, 10.3.18

rdbms ipc reply, 10.3.17

リソース待機イベント, 10.3.3

Windowsのパフォーマンス, 9.2.2 ワークロード, 2.6.2, 2.6.2.1, 2.6.2.2, 2.6.3, 2.6.4

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。