Oracle Real Application Testing：SQL Performance … Real Application Testing：SQL Performance Analyzer を使用した Oracle9i Database からOracle Database 10g Release 2...

Oracle Real Application Testing：SQL Performance Analyzer を使用した

Oracle9i Database から Oracle Database 10g Release 2 へのアップグレードによ

る SQLパフォーマンスへの影響のテス

ト

Oracle ホワイト・ペーパー 2008 年 4 月

Oracle Real Application Testing：SQL Performance Analyzer を使用した Oracle9i Database から Oracle Database 10g Release 2 へのアップグ

レードによる SQL パフォーマンスへの影響のテスト

2

Oracle Corporation 発行「Testing the SQL Performance Impact of a 9i to 10gR2 upgrade with SQL Performance Analyzer」の翻訳版です。

SQL Performance Analyzer を使用した

Oracle9i Database から Oracle Database 10g Release 2 へのアップグレードによる

SQL パフォーマンスへの影響のテスト

はじめに .............................................................................................................. 3 SQL Performance Analyzer の機能 ..................................................................... 4 推奨される使用シナリオの概要....................................................................... 5 制限 ...................................................................................................................... 6 アップグレードのテストの準備....................................................................... 6

本番システムからの必要な情報の取得 ..................................................... 6 Oracle Database 10.2 テスト・システムの作成.......................................... 9 Oracle Database 11g SPA システムの作成 ................................................. 12

テストの実行 .................................................................................................... 13 SPA タスク・コンテナの作成 ................................................................... 13 Oracle9i Database パフォーマンス・データからの SPA トライアルの作

成................................................................................................................... 15 Oracle Database 10.2 パフォーマンス・データからの SPA トライアルの

作成............................................................................................................... 15 比較レポートの生成................................................................................... 16

結果の把握 ........................................................................................................ 20 テスト実行手法........................................................................................... 20 環境の考慮事項........................................................................................... 21 パフォーマンス・メトリックの考慮事項 ............................................... 21 推奨される比較戦略................................................................................... 23

パフォーマンスの低下した SQL の修正 ....................................................... 28 同じ実行計画でパフォーマンスの低下した SQL................................... 29 異なる実行計画でパフォーマンスの低下した SQL............................... 29

提案された修正のテスト ................................................................................ 33 アップグレード用の本番システムの準備..................................................... 33 アップグレード後の予期しない問題の対処................................................. 34 結論 .................................................................................................................... 34 付録 A：小規模なハードウェア構成でのテスト ......................................... 35 付録 B：SPA コマンドライン API の例......................................................... 36

SQL Tuning Set への SQL トレース・データのロード........................... 36 SQL Performance Analyzer の実行.............................................................. 37 SQL Tuning Advisor の実行 ........................................................................ 40 エクスポート用の SQL プロファイルの準備.......................................... 42

付録 C：SQL Trace の有効化によるパフォーマンスへの影響 ................... 44 参考資料 ............................................................................................................ 47

SQL Performance Analyzerを使用したOracle9i Databaseから Oracle Database 10g Release 2 へのアップグ


はじめに

本書では、SQL Performance Analyzer（SPA）の機能に対しておこなわれる変更を

説明し、Oracle9i Database から Oracle Database 10g Release 2 にデータベース・シス

テムをアップグレードする顧客をサポートします。Oracle Database 11g Release 1

(11.1.0.6)の SPA には、さまざまな変更を加えて繰り返し実行可能な汎用 SQL パ

フォーマンス・テスト機能があります。アップグレード・テストについては、Oracle

Database 10g Release 2 から Oracle Database 11g（初のリリースの Oracle Database

11g）へのアップグレードのサポートに焦点を当てました。この数か月で SPA が

拡張され、Oracle9i Database から Oracle Database 10.2 へのアップグレードのユース

ケースにも対応しました。Oracle Database 11g および Oracle Database 10.2 リリース

を実行するテスト・データベース・システムにこれらの拡張機能をインストール

できます（[SPAMET]）。SPA へこれらを追加することで、Oracle9i Database の本

番 SQL トレース・ファイルを Oracle Database 11g テスト・システムにロードし、

Oracle Database 10g Release 2 テスト・データベース上で SQL を実行して、アップ

グレード後のパフォーマンス・データを構築し、Oracle Database 11g テスト・シス

テムでパフォーマンス・データを比較できます。

SQL Performance Analyzer（SPA）が拡

張されて、Oracle9i Database から Oracle Database 10g Release 2 へのアップグ

レードがサポートされました。Oracle Real Application Testing オプションに

SPA のライセンスが付与されます。

このホワイト・ペーパーでは、このアップグレードによる SQL パフォーマンスへ

の影響をテストする一連のベスト・プラクティスをできるだけ明確に列挙します。

いくつかの項では、SQL パフォーマンスの重要な概念を説明し、ほかの項ではテ

ストの各手順の実行方法に関する詳細な推奨事項を提供します。Oracle9i Database

から Oracle Database 10.2 にアップグレードするユースケースを中心に説明します

が、ここで説明する原則はほかのデータベースの変更やアップグレードにも同様

に適用されます。SPA は、Oracle Database 10.2 から Oracle Database 11g、Oracle

Database 10.2 のパッチセットから別のパッチセット、またはほかのデータベース

に変更するアップグレードのテストに対して効果的に使用できるツールです。

SPA テストのコンポーネントと SQL パフォーマンス・テストに必要な基盤を把握

すれば、同じように独自のテスト・シナリオを作成できます。このドキュメント

の手順をほとんど変更せずに実行できるテストもあります（たとえば、ここで説

明されている手法を使用して、Oracle Database 10.1 から Oracle Database 11g への

アップグレードをテストできます）が、若干異なる構成を必要とするテストもあ

ります。



3




4


SPA の機能の概要から開始して、ガイドとして SPA を使用したシステム・アップ

グレード・テストの主要な手順を実行します。テストに使用するシステムを準備

し、Oracle9i Database 本番システムからアップグレード前のパフォーマンス・デー

タを取得して、Oracle Database 10g テスト環境で SQL を実行します。後に、結

果を比較および分析します。SPA で検出されたリグレッションを調査および

チューニングする方法の推奨事項で終了し、アップグレードによる影響自体をテ

ストする場合と同様に、SPA を使用してそれらの修正をテストできることを確認

します。これによって、テストが安定した状態になり、本番システムをアップグ

レードできます。また、本番ワークロードに悪影響を及ぼす前に大きいサブセッ

トの SQL パフォーマンスの問題が修正されたことがわかります。

SQL Performance Analyzer の機能

データベースの更新や新しい索引の追加など、SQL 文の実行計画に影響を与える

変更により、予測不可能な方法で SQL 文のパフォーマンスが重大な影響を受ける

ことがあります。結果として、DBA は、変更によってパフォーマンスの低下した

SQL 文の特定と修正に多大な時間と労力を費やすことになります。SQL

Performance Analyzer（SPA）は、Oracle Database 11g で導入された Oracle Real

Application Testing オプションの主要な機能であり、システム変更によって発生す

る SQL パフォーマンスの向上と低下を予測および定量化できます。

SPA は、環境の変更前と変更後でテスト・システムの SQL 文を分離して実行する

ことで、環境の変更が SQL の実行計画と実行統計情報に及ぼす影響をより細かく

表示します。管理しやすいレポートを提供するため、ロードまたは同時実行性の

問題などの複雑な問題は考慮しません。また、変更前と変更後に SQL 文の実行結

果を比較し、パフォーマンスの低下した SQL文だけでなく、システムの変更によっ

てもたらされたワークロードに対する純益を得る利点を説明するレポートも生成

します。パフォーマンスの低下した SQL 文については、適切な実行計画の詳細と

SQL 文を修正するときの推奨事項が提示されます。

SPA の機能と使用モデルの詳細は、『SPA Oracle OpenWorld』ホワイト・ペーパー

（[SPAOOW]）を参照してください。

推奨される使用シナリオの概要

次の図は、SPA を使用した Oracle9i Database から Oracle Database 10.2 へのデータ

ベース・アップグレードのテストに含まれる主要な手順に関するハイレベルな概

要を示しています。

ここでの SPA テストには、3 つのデータ

ベース（ワークロードを実行する Oracle9i Database 本番データベース、テスト用の

Oracle Database 10.2 本番システムのレ

プリカ、小規模な Oracle Database 11gテスト・システム）が含まれます。

1. Oracle9i Database 本番システムの信頼できる SQL ワークロードを一連の

SQL トレース・ファイルに取り込みます。

2. Oracle9i Database 本番システムの SQL トレース・ファイルの情報をデコー

ドするオブジェクト・マッピング表を作成します。

3. SPA テストの中心となる Oracle Database 11g および Oracle Database 10.2

のテスト・データベース・システムのペアを構築する方法を説明します。

手順 1 と 2 で生成された SQL トレース・ファイルとマッピング表が Oracle

Database 11g テスト・システムにコピーされます。

4. Oracle Database 11g テスト・システムで、SQL トレース・ファイルとマッ

ピング表から SQL Tuning Set（STS）を作成します。STS は、一連の SQL

文を実行コンテキストおよびパフォーマンス・データで表すデータベー

ス・オブジェクトです。SPA の主要な入力として使用できます。

5. Oracle Database 11g テスト・システムから、SPA を使用してデータベース・

リンク経由で Oracle Database 10.2 システムに接続し、SQL ワークロード

を 1 つの文ずつ実行して、Oracle Database 11g データベースの中にすべて

のパフォーマンス・データを収集します。

6. 後に、収集した 2 つのセットのパフォーマンス・データを SPA を使用

して分析し、パフォーマンスが低下した SQL をチューニングして、シス

テムが安定した状態になるまで提案された修正のテストを繰り返します。



5


制限

Oracle9i Database から Oracle Database 10.2 へのアップグレードのユースケースで、

次のテクノロジーはサポートされていません。

− 共有サーバー（MTS）アーキテクチャはサポートされていません。

− パラレル問合せとパラレル DML はサポートされていません。これらのリ

リース間のパラレル処理アーキテクチャの変更によって、これらのリ

リース間のパラレル計画の比較が非常に複雑になります。

− 行がリモート・データベースからフェッチされてローカルで処理される

REMOTE 計画操作を除き、リモート SQL はサポートされていません。

アップグレードのテストの準備

すでに説明したとおり、SPA を使用したアップグレードのテストは、異なるデー

タベース・システムで実行される多くの手順で構成されています。この項では、

Oracle9i データベースを実行する本番システムから必要な情報を収集する方法と、

有効なテストを保証するために各システムを適切に設定する方法を説明します。

この作業を実行すれば、実際に SPA テストを開始できます。

本番システムからの必要な情報の取得

SQL トレースを取得する推奨戦略

Oracle9i SQL パフォーマンスを識別するために SPA が使用するベースラインのパ

フォーマンス・データは、本番システムから取得した SQL トレースにあります。

実際のオンライン・ワークロードが含まれるため、本番システムはパフォーマン

スを測定するどのテスト・システムよりも信頼できると考えられます。ただし、

全体の SQL ワークロードを実行するテスト・システムの場合、代わりにトレース

を実行できます。これには、SQL トレースの有効化によるパフォーマンスのオー

バーヘッドが本番システムに影響を与えない利点があります。

Oracle9i Database 本番データベースで、

すべての重要な SQL 文のバインド値を含

む SQL トレースを取得します。

この手順の主要な要件は、バインド値を含む SQL トレースを取得し、システムの

多くの重要な SQL にできるだけ対応することです。主要なビジネス・トランザク

ションとバッチ・ジョブに対応できることを確認してください。各 SQL に何度も

対応する必要はありません。SPA は、確認された初の実行を検討し、残りは無

視します。また、取得されていない SQL は SPA 分析に対応していないので、全

体のパフォーマンスを重視するワークロードを取得する必要があります。SQL ト

レースを有効にすると非常に大きいトレース・ファイルの書込みで I/O システム

に負荷がかかり、追跡される SQL のパフォーマンスが大幅に低下する可能性があ

るので、本番システム全体で SQL トレースを有効にしないことが推奨されます。

代わりに、一度にいくつかのセッションの SQL トレースを有効にして、できるだ

け多くの重要な SQL に対応するまで繰り返し試行します。



6




7


この戦略でスループットの問題が回避されますが、追跡される SQL の応答時間に

トレースが影響を与える可能性があります。トレースで初に実行される場合、

こうした SQL の追加の厳密な解析をおこないます。また、ランタイム・パフォー

マンス・メトリックを収集する場合に SQL の実行（とくに CPU 時間）が遅くな

ります。応答時間の影響を把握するため、一連の OLTP および DSS の問合せにお

ける SQL トレースのオーバーヘッドを計算するテストをおこないました。付録 C

にすべての結果が記載されています。簡潔に説明すると、ほとんどの SQL で応答

時間の影響が 20%未満であることがわかりました。ただし、固定した実行単位の

トレース・ファイルの書込みによって、高速で実行される（10ms 未満）SQL 文で

高いオーバーヘッドが確認されました。単一のサブセットのセッションのみのト

レースを有効にする推奨事項にしたがえば、ほとんどのシステムにおいて応答時

間への影響が許容範囲であると考えられます。

SQL トレースの有効化

一部のアプリケーションは、SQL トレースのネイティブ・サポートを提供します。

アプリケーションでバインド値を含むトレースをサポートし、セッションを繰り

返して十分な SQLを取得できる限り、この方法が許容できる一連のトレース・ファ

イルを作成するもっとも簡単な方法です。それ以外の場合は、次の方法から選択

して、トレースを有効にします。

− データベース・セッション用の dbms_support.start_trace の呼出しの追加：

これらのセッションが接続されている限り、SQL トレースが有効になり

ます。SQLPlus で次のコマンドを実行して、dbms_support パッケージを

ロードする必要があります。

@?/rdbms/admin/dbmssupp

（詳細は、[SUPP]を参照してください）。現在のセッションのトレース

を有効にする場合、バインドが取得されていることを確認します。

dbms_support.start_trace(binds => TRUE, waits => FALSE);

セッションでSQLトレースを停止する場合は、stop_traceを呼び出します。

dbms_support.stop_trace;

このメソッドは正しく動作しますが、かならず実行できるとは限らない

アプリケーション・コードの変更が必要になります。



8


− 外部で dbms_support.start_trace_in_session プロシージャを起動して、別の

セッションで SQL トレースを有効にします。

dbms_support.start_trace_in_session(sid => sid, serial => ser, binds => TRUE, waits => FALSE);

追跡するセッションの SID およびシリアル番号を検索する v$session の問

合せを実行します。

select sid, serial# from v$session where ...;

アプリケーション・ソースの変更が可能ではない場合に、このメソッド

を使用します。これによって、特定のセッションで実行される今後のす

べての SQL トレースが切断されるまで有効になります。SQL トレースを

終了するには、stop_trace_in_session を呼び出します。

dbms_support.stop_trace_in_session(sid => sid, serial => ser);

また、テスト・システムの SQL トレースを取得する場合、次のコマンドを使用し

てシステム全体の SQL トレースを有効にできます。

− alter system set events "10046 trace name context forever,

level 4‘：これによって、将来のセッションだけにシステム全体のSQL

トレースが有効になるので、すべてのSQL実行のトレースが保証されます。

"alter system set events "10046 trace name context off‘"

でトレースを無効にします。

また、pfile/spfile の EVENT パラメータを使用して、システム全体の SQL

トレースを有効にできます。これには、インスタンスの再起動が必要で

す。

EVENT=‘10046 trace name context forever, level 4‘;

生成されるトレースの量や実行処理に含まれるパフォーマンスのオーバー

ヘッドのため、このコマンドは本番システムでは推奨されていません。

次のパラメータを設定して、SQL トレースの動作を制御する必要があります。

− timed_statistics = TRUE：パフォーマンス・タイミングの取得に必要です

− user_dump_dest = '<dir>' ：トレース・ファイルの出力場所です

オプションで次のパラメータを設定して、トレース・ファイルを生成したあとに

簡単に検索できます。

− trace_file_identifier = '<string>' ：あとで簡単に検索できるように、文字列

で SQL トレース・ファイルにタグをつけます

トレースが完了してから、生成した ORA トレース・ファイルを安全な外部の場所

にコピーします。ここでは、設定後に Oracle Database 11g テスト・システムに移

動します。

マッピング表の作成およびエクスポート

Oracle9i Database の SQL トレース・ファイルは、名前ではなく数値の識別子でオ

ブジェクトとユーザーを参照します。SQL トレース・ファイルを SQL Tuning Set

に変換するには、マップする ID と名前を指定するマッピング表が SPA で必要に

なります。トレースが取得されたシステムにこのマッピング表を作成し、Oracle

Database 11g テスト・システムに移動します。SELECT_CATALOG_ROLE をもつ

ユーザーとして、次の DDL を使用して Oracle9i データベース・システムにマッピ

ング表を作成します。

create table mapping_table as select object_id id, owner,

substr(object_name, 1, 30) name from dba_objects where object_type NOT IN

('CONSUMER GROUP', 'EVALUATION CONTEXT', 'FUNCTION', 'INDEXTYPE', 'JAVA CLASS', 'JAVA DATA', 'JAVA RESOURCE', 'LIBRARY', 'LOB', 'OPERATOR', 'PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'QUEUE', 'RESOURCE PLAN', 'TRIGGER', 'TYPE', 'TYPE BODY')

union all select user_id id, username owner, null name from dba_users;

マッピング表の作成後、ダンプ・ファイルにエクスポートします。Oracle Database

11g テスト・システムにはあとでインポートします。

Oracle Database 10.2 テスト・システムの作成

SPA テストの主要なコンポーネントの 1 つに、アップグレード後のパフォーマン

スを測定するOracle Database 10.2システムがあります。SPAは、Oracle Database 11g

テスト・システムからこのシステムに接続して、ワークロードの SQL のテストを

リモートで実行します。このシステムの正しい設定は、Oracle9i Database データと

正確に比較してリグレッションを予測できる、信頼性の高い Oracle Database 10.2

パフォーマンス・データを生成するための重要な手順です。有効な比較をおこな

うには、トレースが取得された Oracle9i データベース・システムと Oracle Database

10.2 システムをできるだけ同じにする必要があります。

最終的な Oracle Database 10.2 本番シス

テムと同じ環境で Oracle Database 10.2テスト・システムを構築する必要があり

ます。

この Oracle Database 10.2 テスト・システムを作成する次のプロセスが推奨されます。

1. できるだけ本番と同じ構成（init.ora パラメータなど）を使用して、テスト

環境でリストアされる Oracle9i Database ベースライン・システムの全体

バックアップから開始します。

2. テスト用にこのシステムをターゲットの Oracle Database 10.2（バージョン

10.2.0.2 以上）にアップグレードして、Oracle Database 10.2 の本番システ

ムで実行する環境を変更します。Oracle Database 10.2 テスト・システムの

環境と 10.2 本番システムの環境（Oracle9i Database の本番環境とアップグ

レード中におこなわれる変更）を同じにする必要があります。



9




10


3. Oracle Database Release 10.2.0.2/3/4 では、システムに SPA 拡張機能をイン

ストールします（[SPAMET]）。以降の Oracle Database 10.2 リリースでは、

拡張機能がデフォルトで含まれます。Oracle Real Application Testing オプ

ションにこのシステムのライセンスが付与されます。

4. データベース・リンクを接続するユーザーに DBMS_SQLPA パッケージ

の EXECUTE 権限と ADVISOR 権限を付与します。

システム環境の次の主要な項目を正しく初期化してください。

− ルールベース・オプティマイザ（RBO）は、Oracle Database 10g でサポー

トされません。Oracle9i Database の RBO を使用している場合、アップグ

レードの一部としてコストベース・オプティマイザ（CBO）に移行する

必要があります。詳細は、CBO への移行に関するオラクルのホワイト・

ペーパーを参照してください（[CBO]）。

− 本番システムと同じように、DBMS_STATS を構成する必要があります。

SQL パフォーマンスに大きな影響を与える可能性のある Oracle Database

10g のオプティマイザ統計を収集するには、デフォルト動作にいくつかの

重要な変更があります。オプティマイザの変更に関するオラクルのホワ

イト・ペーパー（[OPT]）を参照し、DBMS_STATS.SET_PARAM API を

使用して DBMS_STATS を構成します。

dbms_stats.set_param(pname, pval);

− DBMS_STATS 自動収集ジョブを無効にして、手動で統計を収集します。

デフォルトで Oracle Database 10g のこのジョブは有効になっていますが、

本番システムで使用する場合でもテスト・システムでは無効にしてくだ

さい。テスト中にオプティマイザ統計を変更できるので、問題の診断が

さらに困難になります。これは、次のように実行できます。

dbms_scheduler.disable(”GATHER_STATS_JOB‘);

Oracle Database 10gの新のオプティマイザ統計を収集する前に、Oracle9i

オプティマイザ統計を表にバックアップし、ダンプ・ファイルにエクス

ポートして保存します。これによって、古い統計に戻ってアップグレー

ド後のパフォーマンス低下の原因を診断できます。DBMS_STATS.

CREATE_STAT_TABLE/EXPORT_DATABASE_STATS API を使用します。

dbms_stats.create_stat_table(<user>, ”STATTAB‘); dbms_stats.export_database_stats(”STATTAB‘);



11


次に、本番システムと同じ戦略を使用して、新の統計を収集します。

ディクショナリのアップグレード中にのみオプティマイザ統計が収集さ

れるので、SPA テストで新しい Oracle Database 10g 統計を使用できるよう

にアプリケーション・データ用に手動でオプティマイザ統計を収集する

必要があります。たとえば、自動ジョブの動作と同じようにデータベー

ス全体の統計を収集するには、DBMS_STATS.GATHER_DATABASE_

STATS API を使用します。

dbms_stats.gather_database_stats( options => ”GATHER AUTO‘);

− オプティマイザ・システム統計を収集して、オプティマイザの新しい CPU

コスト計算アルゴリズムを活用します。テスト・システムで、次のように

DBMS_STATS.GATHER_SYSTEM_STATS API を使用して生成できます。

dbms_stats.gather_system_stats(

gathering_mode => ”NOWORKLOAD‘);

詳細は、オプティマイザ変更の Oracle ホワイト・ペーパー（[OPT]）を参

照してください。

− PGA_AGGREGATE_TARGET パラメータによって、Oracle Database 10g の

PGA メモリがデフォルトで管理されます。*_AREA_SIZE パラメータに設

定されている値は無視されます。設定されていない場合は、SGA サイズ

の 20%のデフォルト値を仮定します。この値がシステムで適切ではない

場合、本番システムのようにテスト・システムで固有のカスタム値に設

定する必要があります。

Oracle9i Database システムのクローンから Oracle Database 10.2 テスト・システムを

構築することを推奨します。これは、アップグレード前のパフォーマンスが取得

された Oracle9i Database システムと Oracle Database 10.2 システムをできるだけ同

じにする適な方法です。このクローンされたOracle Database 10gシステムで SPA

がリモートで SQL を実行する場合、この類似性によって、意図しないシステムの

違いではなくアップグレードによる違いを確認できるきわめて高い信頼度が得ら

れます。Oracle Database 10g テスト・システムが同じハードウェアを装備した本番

システムの完全なコピーではない場合、Oracle9i と Oracle 10g のデータベースのス

ケールダウン・バージョンでテストを実行する必要があります。詳しくは、付録

A を参照してください。



12


Oracle Database 11g SPA システムの作成

SPA テスト自体は、Oracle Database 11g テスト・システムから統合されます。アプ

リケーション・データを保存する必要がないので、小規模なデータベースになる

可能性があります。同様に、ここではパフォーマンスの測定がおこなわれないの

で、このシステムの構成は重要ではありません。ただし、Oracle Real Application

Testingオプションをローカルでインストールする必要があります。Oracle Database

11g Release 1 (11.1.0.6)データベース・テスト・システムでは、このユースケー

ス用の新機能がインストールされた SPA 拡張機能が必要です（[SPAMET]）。今

後の Oracle Database 11g のリリースでは、完全な SPA 機能がデフォルトでインス

トールされます。

SPA と Oracle Database 10.2 テスト・システムを接続するには、Oracle Database 11g

テスト・システムから Oracle Database 10.2 テスト・システムへのパブリック・デー

タベース・リンクを作成します。SQL 文をリモートでテスト実行できるように、

ADVISOR権限およびDBMS_SQLPAパッケージのEXECUTE権限をもつユーザー

にリンクを接続してください。

パブリック・データベース・リンクの作成には、次の構文が必要です。

CREATE PUBLIC DATABASE LINK mylink CONNECT TO user IDENTIFIED BY pwd USING ”connect_string‘ /

残された SPAテストの準備は、SPAで直接使用できる SQL Tuning SetへのOracle9i

SQL トレース・データのロードです。次の手順を実行して、SQL Tuning Set を作

成およびロードします。

− Oracle Database 11g をホストするシステムに ORA トレース・ファイルを

コピーします。

− それらの場所を指すディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY MYDIR AS ‘</path/to/traces>‘;

− Oracle9i 本番データベース・システムで作成されたマッピング表をイン

ポートします。

− DBMS_SQLTUNE API で SQL Tuning Set を構築します。CREATE_SQLSET

API を使用して STS を作成し、SELECT_SQL_TRACE から返されるカー

ソルを LOAD_SQLSET に渡します。

declare mycur dbms_sqltune.sqlset_cursor;

begin dbms_sqltune.create_sqlset('9i_prod_wkld'); open mycur for select value(p) from table(dbms_sqltune.select_sql_trace(

directory => 'MYDIR', file_name => '%ora%', mapping_table_name => 'MAPPING_TABLE', select_mode =>

dbms_sqltune.SINGLE_EXECUTION)) p;

dbms_sqltune.load_sqlset( sqlset_name => '9i_prod_wkld', populate_cursor => mycur, commit_rows => 1000);

close mycur;

end; /

これによって、SQL トレース・ファイルから STS にデータがロードされます。SQL

ごとに 1 回の実行のみのデータが使用されます。めったに実行されない SQL と頻

繁に実行される SQL を区別するために必要な実行頻度を SPA で取得する利点があ

りますが、全体の累積ワークロードに対応していないので SQL トレースからこの

情報を取得できません。詳細な API の例が付録 B に記載されています。COMMIT_

ROWS の値を指定すると、1000 の SQL がロードされたあとにロード API がコミッ

トされます。このように、DBA_SQLSET/USER_SQLSET ビューの問合せを実行し

て、ロードの進捗状況を監視できます。非常に大きいトレース・ファイルからの

SQL Tuning Set のロードに時間がかかる場合があるので、これは便利です。

テストの実行

Oracle Database 10.2およびOracle Database 11gテスト・システムを設定すると、SPA

テストの主要な手順（SPA タスクの作成、SPA トライアルへの SQL Tuning Set 統

計の変換、2つ目のSPAトライアルを構築するOracle Database 10.2のSQLのリモー

ト実行）を実行できます。SPA トライアルは、テスト・ワークフローで生成され

た個別のパフォーマンス・データ（各 SQL 文を分離した一連の基本測定）を表し

ます。SPA タスクは、一連のトライアルのコンテキストを提供してトライアル間

を比較するためのコンテナとして役立ちます。この項では、次の手順で比較をお

こなうために必要なパフォーマンス・データが含まれる初の 2 つのトライアル

およびタスクを作成する手順を実行します。

SPA テストは、タスクと呼ばれるデータ

ベース・コンテナにモデル化されます。

個別にサブテスト（このタスク内のトラ

イアル）が呼び出されます。

SPA は、Oracle Database 11g 以降の各リリースの Oracle Enterprise Manager を完全

にサポートします。ただし、現在 Oracle9i Database のアップグレードをサポート

している新機能には、データベース拡張機能のみが含まれます。このため、この

ドキュメントでは、コマンドライン API のみを参照します。ドキュメントを読み

やすくするため、各 API の使用例を付録 B に記載しています。今後のリリースで

Oracle Enterprise Manager サポートが追加されます。

SPA タスク・コンテナの作成

SPA テストは、実行されている現在のテストの状態を管理する、タスクと呼ばれ

る単一のデータベース・オブジェクトを中心とします。単一の SPA タスクを作成

し、アップグレード・テスト中にこのタスクを使用します。主要な各手順で、新

しいトライアルを作成してテストに追加するタスクを実行します。タスクの主要

な入力は、テストするワークロードおよび SPA テストの実行方法を示す一連のパ

ラメータを含んだ SQL Tuning Set です。



13




14


タスクの作成は、DBMS_SQLPA パッケージの CREATE_ANALYSIS_TASK API

で実行できる軽量の操作です。

dbms_sqlpa.create_analysis_task( task_name => ”9i_10g_spa‘, description => ”Experiment for 9i to 10gR2 upgrade‘, sqlset_name => ”9i_prod_wkld‘);

− task_name：作成するタスク・コンテナの名前

− description：テストの説明

− sqlset_name：Oracle9i Database SQL トレース・ファイルから作成された

SQL Tuning Set の名前（"Oracle Database 11g SPA システムの作成"の項を

参照）

タスクの作成後、USER_/DBA_ADVISOR_TASKS ビューに表示されます。テスト

に使用される次のタスク・パラメータの設定を推奨します（SET_ANALYSIS_

TASK_PARAMETER API を参照）。

dbms_sqlpa.set_analysis_task_parameter( task_name => ”9i_10g_spa‘, parameter => [see below], value => [see below]);

− LOCAL_TIME_LIMIT：リモート実行手順でワークロードの単一の SQL

を実行できる秒単位の大時間。この設定によって、パフォーマンスの

大幅に低下した SQL に SPA が長期間とどまることを防ぎます。ワーク

ロードの重要な SQL を完全に実行するために必要な長時間に設定して

ください。

− WORKLOAD_IMPACT_THRESHOLD：SPA が向上または低下を分類する

前にワークロードに影響を与える SQL の割合としての小しきい値。SPA

に使用する SQL Tuning Set に実行頻度情報が含まれないので、この値は 0

に設定してください。

− SQL_IMPACT_THRESHOLD：ワークロードの影響のしきい値に加えて、

SPAが向上または低下を分類する前に影響するSQLの実行単位のパフォー

マンスに関する割合としての小しきい値。このパラメータのデフォル

ト値は 1 です。ワークロードの影響に関するしきい値の削除を補完して、

小さい無関係のリグレッションのレポートを避けるためにこの値を 5 に

設定することを推奨します。これらの 2 つの値を設定すると、SPA は、

残りのワークロードを無視して個別のパフォーマンスが少なくとも 5%

向上または低下するSQLの改善/リグレッション調査結果を作成できます。



15


Oracle9i Database パフォーマンス・データからの SPA トライアルの

作成

タスクの入力として使用される SQL Tuning Set には、SPA が Oracle9i Database 本

番システムで必要とするすべてのパフォーマンス・データが含まれます。SPA で

このデータを処理するには、トライアル実行としてモデル化する必要があります。

DBMS_SQLPA パッケージの簡単な API 呼出しを通じて特殊なモードでタスクを

実行し、このトライアルを構築します。この手順で STS からタスクに統計をコピー

しますが、SQL を実行しないので非常に軽量になります。次のように EXECUTE_

ANALYSIS_TASK の呼出しを発行します。

dbms_sqlpa.execute_analysis_task( task_name => ”9i_10g_spa‘, execution_name => ”9i_trial‘, execution_type => ”CONVERT SQLSET‘, execution_desc => ”9i sql trial generated from STS‘);

API に渡される実行名は、SPA トライアルのハンドルとして使用されます。'CONVERT

SQLSET'は、SQL を新しく実行するのではなく STS から統計を読み取って SPA が

SQL トライアルを作成する実行タイプです。

Oracle Database 10.2 パフォーマンス・データからの SPA トライアル

の作成

アップグレード後のパフォーマンス・データで SPA トライアルを作成するには、

Oracle Database 11g システムで EXECUTE_ANALYSIS_TASK への別の呼出しを発

行し、Oracle Database 10g システムのワークロードの各 SQL をリモートで一度実

行します。

dbms_sqlpa.execute_analysis_task( task_name => ”9i_10g_spa‘, execution_name => ”10g_trial‘, execution_type => ”TEST EXECUTE‘, execution_desc => ”remote test-execute trial on 10g db‘, execution_params => dbms_advisor.arglist(

”DATABASE_LINK‘, ”MYLINK.SERIES.OF.GLOBAL.SUFFIXES‘));

ここでの DATABASE_LINK タスク・パラメータの処理のように EXECUTE_

ANALYSIS_TASK API にタスク・パラメータを渡すと、この実行の値だけを指定

できます。DATABASE_LINK タスク・パラメータのパブリック・データベース・

リンクのグローバル（完全修飾）名を渡してください。

実際にリモート・システムで各 SQL を実行する必要があるため、この手順は前の

手順よりも大幅に時間がかかります。次のように Oracle Database 11g システムの

V$ADVISOR_PROGRESS ビューの問合せを実行して、この手順の進捗状況を簡単

に監視できます。

select sofar, totalwork from v$advisor_progress where task_id = <tid>;



16


'sofar'列は、これまでに実行された SQL の総数を示します。'totalwork'列は、ワー

クロードの SQL 数を示します。

比較レポートの生成

SPA パフォーマンス分析の性質

この時点で、SPA は、テストに必要なすべてのパフォーマンス測定を実行しまし

た。ここでは、SPA を使用してこのデータを分析します。SQL ごとにワークロー

ドが段階的に実行され、2 つのトライアルの実行計画と統計が比較されます。SPA

は、以下の内容を含む 2 つのトライアル間の興味深い違いを探します。

− 大幅に向上または低下したパフォーマンス

− 実行計画の変更

− いずれかのトライアルで発生したエラー

− データの違いによる返された行の数の差異

分析が完了すると、SPA は調査結果を説明する HTML またはテキストのレポート

を構築できます。分析を実行する場合、比較に使用するパフォーマンス・メトリッ

クが SPA に必要です。特定のペアの実行で向上するメトリックや低下するメト

リックが発生する可能性があるので、SQL の向上または低下に関連する特定のパ

フォーマンス・メトリックのみになります。たとえば、ネステッド・ループ結合

からハッシュ結合に変更すると、実行される I/O 操作の数の改善と CPU 時間のリ

グレッションを確認することがあります。CPU バウンド・システムでは許容でき

ない場合でも、I/O バウンド・システムでは向上と見なされることがあります。SPA

は、使用している環境に関連性の深いパフォーマンス・メトリックを提供し、パ

フォーマンスの変更を識別するために必要な知識を組み込むことを要求します。



17


比較用の最適なメトリックの選択

ほとんどの専門家は、SQL パフォーマンスの比較において複数のメトリックを使

用することが重要であるという点に同意します。SPA テストのコンテキストでは、

2 つの形式から選択できます。いくつかのメトリック（CPU 時間と I/O 時間など）

を組み合わせたユーザー提供形式に基づく単一の分析を実行するか、または個別

のメトリックに基づいてそれぞれ実行される複数の分析を実行するかです。ここ

では、後者のアプローチを推奨します。統計を分離して、いずれかのディメンショ

ンに従って SQL のパフォーマンス改善と劣化を確認し、すべての知識を組み込ん

だチューニングを実行できるためです。また、すべてのパフォーマンス・メトリッ

クが同じように意味をもつものではありません。したがって、信頼性の高い統計

と低い統計を組み合わせると、きわめて高い信頼度で結果を表示することが非常

に困難になります。多くの場合、これらの組合せには、経験則ベースの単位の換

算（たとえば、論理 I/O から I/O ごとに必要な推定時間に基づく時間）が必要です。

このため、結果がさらに不正確になります。

ここでは、測定内容が繰り返し可能で包括性のある統計を中心とする SQL パ

フォーマンス分析が適切であると考えます。テストでは、初の条件の再現性が

重要です。各コレクションの測定が大幅に変更される場合、取得された結果を明

確に示すことはできません。2 つ目の包括性も同様に重要です。考慮されている

メトリックに SQL のパフォーマンスの有意義な側面が取り込まれない場合、分析

の結果は一部だけになります。これらの 2 つの目標を考慮し、使用できるパフォー

マンス・メトリックを調査して、条件をもっとも満たすパフォーマンス・メトリッ

クを確認しました。SPA が収集するメトリックから、繰り返す可能性が高く、組

み合わせると SQLパフォーマンスの全体が形成される少量のセットを選択します。

次の表は、上記の要件に準拠した SPA が取得するメトリックを示しています。

メトリックディメン

ション再現性包括性コメント

PARSE_TIME 解析で使用

される CPU 有無複数の実行に分割する必要が

あります

ELAPSED_TIME 時間無有現在の環境（バッファ・キャッ

シュの状態など）に大きく依存

します

CPU_TIME 実行で使用

される CPU 有有 SQL パフォーマンスの大きい

ディメンションの包括的な測

定をおこなう頻繁に繰り返す

ことができるメトリックです

USER_IO_TIME 物理 I/O 無有包括的ですが、バッファ・キャッ

シュの状態に大きく依存します

BUFFER_GETS 論理 I/O 有有繰り返し可能で包括的ですが、

物理 I/O への変換が困難です

DISK_READS 物理 I/O の読

取り無有バッファ・キャッシュの状態に

大きく依存します

DIRECT_WRITES ダイレクト・

パスの書込み

無有範囲が狭いので幅広く使用で

きません。バッファ・キャッ

シュの状態に依存します

OPTIMIZER_COST コストの見

積もり有無実際のパフォーマンスを測定

しません

表に示されているとおり、再現性を損なわないで SQL のパフォーマンスを取得で

きる統計は CPU_TIME です。I/O 領域で包括性が不足し、Oracle9i SQL 実行の CPU_

TIME が SQL トレースから不自然に影響を受けるので、BUFFER_GETS 統計の分

析も推奨します。論理 I/O が物理 I/O に変換される数を予測することが非常に困難

なので、BUFFER_GETS には重大な欠点があります。ただし、すべてのコストを

負担する場合、唯一の繰り返し可能な I/O 統計なので考慮する価値はあります。

BUFFER_GETS および CPU_TIME SQLパフォーマンス・メトリックに専念する

ことを推奨します。



18




19


分析の実行

2 つの SPA パフォーマンス分析（CPU_TIME の分析と BUFFER_GETS の分析）の

実行を推奨します。SPA 分析の作成は、大きいワークロードでも素早く簡単に実

行できます。2 つの新しいタスク・トライアル（統計ごとに 1 つ）を作成します。

dbms_sqlpa.execute_analysis_task( task_name => '9i_10g_spa', execution_name => 'compare_9i_102_cpu', execution_type => ”COMPARE PERFORMANCE‘, execution_params => dbms_advisor.arglist(

'COMPARISON_METRIC', 'CPU_TIME', 'EXECUTION_NAME1', '9i_trial', 'EXECUTION_NAME2', '10g_trial'),

execution_desc => 'Compare 9i SQL Trace Performance ' || 'to 10g Test-Execute for CPU_TIME');

dbms_sqlpa.execute_analysis_task(

task_name => '9i_10g_spa', execution_name => 'compare_9i_102_bgets', execution_type => ”COMPARE PERFORMANCE‘, execution_params => dbms_advisor.arglist(

'COMPARISON_METRIC', ”BUFFER_GETS', 'EXECUTION_NAME1', '9i_trial', 'EXECUTION_NAME2', '10g_trial'),

execution_desc => 'Compare 9i SQL Trace Performance ' || 'to 10g Test-Execute for BUFFER_GETS');

各統計で、次のレポート（HTML）の生成を推奨します。

− サマリー・レポート

− パフォーマンスの低下したすべての SQL の詳細なレポート

次のレポートを一度だけ生成できます（どちらのトライアルでも同じです）。

− 計画が変更されたすべての SQL の詳細なレポート

REPORT_ANALYSIS_TASK API でレポートが生成されます。例を以下に示します。

--spool reports to files set heading off long 1000000000 longchunksize 10000 echo off; set linesize 1000 trimspool on; --summary report for CPU_TIME metric spool cpu_summary.html select xmltype(dbms_sqlpa.report_analysis_task(

'9i_10g_spa', /* task_name */ 'html', /* type */ 'typical', /* level */ 'summary', /* section */ null, /* object_id */ 100, /* top_sql */ 'compare_9i_102_cpu') /* execution_name */

).getclobval(0,0) from dual; spool off

execution_name、level、section、top_sqlパラメータを変更して、異な

る詳細レベルでほかのトライアルからレポートをフェッチします。完全なAPIの詳

細は、付録Bに記載されています。各レポートは、任意のWebブラウザで開くこと

ができる自己完結型のHTMLファイルです。サマリー・レポートを参照して、SQL

パフォーマンスへのアップグレードの影響の全体概要を確認できます。CPU_TIMEを適

切な統計であると考えているので、サマリー・レポートから開始することを推奨

します。

結果の把握

構築した SPA レポートには確認する点が多くあります。この項では、レポートか

ら適切な結果を抽出できるよう、結果を分析する際に考慮するいくつかの主要事

項を説明します。

テスト実行手法

SPA が Oracle Database 10g で SQL を実行するリモート・トライアルを実行する場

合、SQL Tuning Set（STS）の単一セットのバインド値だけを使用して、Oracle Database

10g 環境で一度だけ各 SQL を実行します。SPA 分析では、この単一のテストの実

行中に確認された統計と、Oracle9i Database SQL トレースから STS にロードされ

た統計を比較します。上記の"Oracle Database 11g SPA システムの作成"の項で

SELECT_ SQL_TRACE APIのSINGLE_EXECUTIONオプションの使用を推奨しているので、

SQL Tuning Set には、各 SQL の 1 回の実行のみの情報が含まれます。SPA 比較の

コンテキストでは、Oracle9i Database の単一セットのバインド値を使用した 1 回の

実行と Oracle Database 10g の同じバインド値を使用した 1 回の実行の比較を意味

します。どちらの場合も、測定した単一の実行がその SQL の平均的なパフォーマ

ンスを示すわけではありません。たとえば、異なるバインド値の使用がさまざま

な選択結果につながる場合は、特定のバインド値を使用した SQL の実行が高速に

なります。また、使用できるメモリ量が変更された場合に特定の環境の SQL の実

行が高速になることがあります。SQL のパフォーマンスで実行単位の違いが大き

くなるほど、SPA の誤差が大きくなります。たとえば、Oracle9i Database で 0.1 秒、

Oracle Database 10g で 0.2 秒で実行される SQL の場合、0.1 秒の違いは測定の誤差

の範囲内ですが、SPA は 2 倍のリグレッションを示します。非常に複雑で大きな

データ依存性が存在するため、SPA はこの誤差を計算しません。

各SQLのアップグレード前の 1回の実行

とアップグレード後の 1 回の実行に関す

るデータのみをSPA テストで使用します。個別の実行の違いから、SPA の結果に誤

差が生じる場合があります。

実行ごとに SQL のパフォーマンスが大きく異なる場合があることがわかります。

SPA はこの違いを計算できないため、通知されるワークロードの影響が極端にな

ります。このため、SPA により検出されたすべてのリグレッションがほとんどの

SQL の実行で発生し、重要ではないと判断された変更がほとんどの SQL の実行に

おいて、実際に問題ないことを確認するために、変更された計画は可能な限り多

く確認してください。システムに関する自身の知識を活用して、疑わしい点を手

動のテストを通じて検証することで、もっとも重要なリグレッションにチューニ

ングの焦点を当てることができます。



20


環境の考慮事項

SPA が測定の誤差に関して特別な準備をおこなわないように、SQL を実行する環

境にもとらわれません。SQL パフォーマンスに影響する可能性のあるさまざまな

要素をすべて列挙するには数が多すぎ、SPA がすべて処理するには変化に富みす

ぎているため、この時点ではトライアルごとの環境の変更が検出されません。SPA

は環境の違いを通知しないので、Oracle Database 10g 本番システムと同じ環境

（Oracle9i Database 本番システムの環境とアップグレードの一部としておこなわれ

る任意の変更）で Oracle Database 10g テスト・システムを設定することがいっそ

う重要になります。SPA 環境には、すべてのパフォーマンス関連の SQL パラメー

タ値、メモリ構成、および SQL パフォーマンスに影響するすべての要素が含まれま

す。たとえば、Oracle9i Database では*_AREA_SIZE init.ora パラメータで PGA の使

用を管理し、 Oracle Database 10g では独自のカスタム値に

PGA_AGGREGATE_TARGET を設定する場合、Oracle Database 10g テスト・シス

テムでもこの設定にする必要があります。

Oracle9i Database 本番システムと Oracle Database 10gテストの環境の違いによっ

て、SPA 測定で問題が発生する可能性が

あります。

パフォーマンス・メトリックの考慮事項

Oracle9i Database SQL トレースで取得したパフォーマンス・メトリックが Oracle

Database 10g のテスト実行中に確認されたパフォーマンス・メトリックと不自然に

異なる場合、これには 2 つの主要な理由があります。ここでその理由を取り上げ、

テストに導入される偏りを説明します。SPA によって通知されるアップグレード

前後のパフォーマンス統計を確認する場合、これらの要素を考慮する必要があり

ます。

ハードウェア/データの違いによる偏り

上記の"Oracle Database 10.2 テスト・システムの作成"で、本番システムと同じハー

ドウェアおよびデータを使用してテスト・システムを構築することが推奨されま

した。これは、SPA がシステムのハードウェアまたはデータに関する情報をもた

ないためです。したがって、パフォーマンスを分析する場合、ハードウェアの変

更による人為的なリグレッションとアップグレードによる実際のリグレッション

の違いは識別できません。アップグレードをテストする場合に異なるハードウェ

アで収集した結果を比較すると、テスト・システムに大きく偏った分析になり、

ほとんど理解できなくなります。本番システムの正確なレプリカを構築できない

場合、Oracle9i Database の取得と小規模なテスト・システムの Oracle Database 10g

のリモート・テストを実行する必要があります。付録 A の推奨事項を参照してく

ださい。テストと本番の唯一の違いは、データベース・バージョンです。ハード

ウェア、データ、データ・ディクショナリ、およびほかの管理要素に違いはあり

ません。



21


新しいハードウェアのシステムでテストする場合、SPA を使用してハードウェア

の変更をテストしてもこのルールは適用されません。SPA はデータベース・アッ

プグレードと同様に効果的にハードウェアの変更をテストできますが、それぞれ

のケースをサポートするテスト・システムの構成はそれぞれ異なるものになりま

す。どちらのテストも同じ原則にしたがいますが、テスト・システムを本番シス

テムのコピーと本番でおこなう変更により構成する必要があります。

SQL トレースによる偏り

Oracle9i Database システムの SQL トレースを有効にすると、測定する SQL パ

フォーマンスに大きな影響を与える場合があります。SQL トレース・パフォーマ

ンスとOracle Database 10gテスト実行パフォーマンスを比較する場合、SQLトレー

スが無効である別の実行コード・パスと比較します。トレース情報をディスクに

書き込み、余分な統計測定をSQL実行に導入することで、SQLトレースがパフォー

マンスに影響を与えます。場合によっては SQL トレース・データに大きな偏りが

発生するため、SPA レポートの利用者はこれを認識しなければなりません。また、

これらの要素は統計に大きな影響を与えるので注意してください。

このユースケースでは、CPU_TIME および BUFFER_GETS 測定の調査を推奨して

いるので、一連の OLTP および DSS 問合せのテストを実行して、SQL トレースの

有効化によるこれらの統計への影響を特定しました。予想どおり、BUFFER_GETS

への影響はありませんでしたが、ほとんどの問合せの CPU_TIME に影響がありま

した。付録 C にすべての結果を記載しています。簡潔に説明すると、ほとんどの

SQL で応答時間への影響が 20%未満であることがわかりました。ただし、固定し

た実行単位のトレース・ファイルの書込みによって、高速で実行される（10ms 未

満の）SQL 文で高いオーバーヘッドが確認されました。また、中間の実行計画操

作で多くの行が交換される場合に、実行に時間のかかる SQL で高いオーバーヘッ

ドが発生しました。

SQL トレースは、Oracle9i Database パ

フォーマンス・データの偏りを生成しま

す。このため、SPA に検出されたリグレッ

ションがさらに重要になります。

このため、トレースの影響は SQL ごとに大きく異なる場合があります。OLTP お

よび DSS ワークロードのプロファイルは、かなり異なって見えます。この影響の

予測は不可能であるため、SPA は調整をおこないません。つまり、CPU の比較で

は Oracle9i データに偏りがあるため、SPA に検出されるパフォーマンスの低下が

SQL トレースの偏りを上回るほど大きい場合は、非常に重要になる可能性があり

ます。このため、真剣に対処する必要があります。SPA ではすべての SQL の正確

な CPU の影響を確認できない場合がありますが、もっとも重要なリグレッション

を迅速に通知できます。修正後、パフォーマンスが低下している可能性のあるほ

かの SQL（SPA が計画変更を検出し、パフォーマンスの変化が SQL トレースの偏

りを上回るほど大きいリグレッションを発生させていない SQL）の計画変更に注

意が向けられます。ただし、トレースの影響に関係なく、SPA は発生した計画変

更を通知できるので、重要なパフォーマンスの変化がトレースの影響によって見

えない場合でも、計画変更を表示して調査の適切なソースとして使用できます。



22




23


SQL トレース中のデータ変更

テスト・システムのデータと本番データを一致させるように何度も強調してきま

したが、SQL トレース中に確認されたデータとリモート・テスト実行トライアル

中に確認されたデータを完全に一致させることができない場合もあります。ワー

クロードに DML または DDL が含まれる場合、データの変更中に SQL のトレー

ス・データが収集されますが、リモート・テスト実行のトライアル中に実行され

た SQL は同じセットのデータを参照します。DML のテストを実行する場合は問

合せの部分のみが実行され、データの変更がおこなわれないため、後者の点が保

証されます。

つまり、どれだけ試行しても同じデータで生成された実行統計を収集できない場

合があります。さまざまな行が SQL によって返される場合、SPA はデータの違い

を検出できます。その場合の SPA は、調査結果を含む詳細なレポートを作成しま

す。また、SPA のテスト実行が常にカーソルを利用するので、本番ワークロード

で SQL のすべての行をフェッチしない場合はこの調査結果を確認できます。SQL

のこの調査結果を確認する場合、データの違いによって SPA の予測が影響を受け

る可能性があるので注意してください。たとえば、SQL が Oracle9i Database で 100

行を返し、Oracle Database 10.2 で 10 行だけを返す場合、少ないデータが表示され

るのでパフォーマンスは向上します。このような SQLの計画変更を確認する際は、

各計画を実行し、同じデータセットで実行する場合にリグレッションが検出され

ないことを確認してください。

推奨される比較戦略

上記の"比較レポートの生成"の項で、HTML 形式で次の 5 つのレポートを生成し

ました。

− CPU_TIME 統計での変更の影響に関する概要

− BUFFER_GETS 統計の変更の影響に関する概要

− CPU_TIME 統計から識別されるパフォーマンスが低下した SQL

− BUFFER_GETS 統計から識別されるパフォーマンスが低下した SQL

− 計画が変更されたすべての SQL

この項では、これらのレポートを調査する推奨戦略を説明して、もっとも重要な

点を 1 つずつ確認します。



24


サマリー・レポート

サマリー・レポートを参照すると、アップグレードの全体の影響を迅速に確認し

て適な方向性を決定できます。たとえば、Oracle Database 10g のテスト実行で多

くの SQL にエラーが発生し、Oracle9i Database SQL トレースではエラーが発生し

ていないことを示すサマリー・レポートの場合、パフォーマンス・データを初

に参照しないで発生理由（不十分な環境設定）を調査します。

アップグレードが全体のパフォーマンスを向上または低下させているかどうかを

確認してください。テストが成功した場合、パフォーマンスが向上および低下し

た SQL の数のハンドルを取得し、SQL への変更の影響範囲を確認します。次の手

順のリグレッションをチューニングする場合、これらの問題のさまざまな根本原

因に関する収集可能な情報によって次の行動が決定されます。一方、テストが失

敗した場合、トレースが収集された Oracle9i Database システムに合わせてシステ

ムが正しく構築されなかった兆候を探してください。誤ってシステムを構成した

場合、先に進む前に構成を修正し、後のいくつかの手順を再実行して、新しい

リモート・トライアルの構築および新しいレポートの生成を実行します。

サマリー・レポートの主要な"必須"要素には、以下が含まれます。

− 全体の影響：ワークロードの変更の累積的な影響。この場合、SQL Tuning

Set では単一の実行統計のみを使用するため、比較用に選択したメトリッ

クによるワークロードでの各 SQL の実行単位のパフォーマンスを合計し

た差異になります。

− 向上の影響：向上した SQL（少なくとも 5%パフォーマンスが向上した

SQL）のワークロード・レベルの影響

− 低下の影響：低下した SQL（少なくとも 5%パフォーマンスが低下した

SQL）のワークロード・レベルの影響。これはゼロに縮小するべきターゲッ

トなので、全体の影響と向上の影響が同じになります。

− 計画およびパフォーマンスの変化によって分類された SQL の数

− アップグレードのワークロード・レベルの影響で並び替えられたトップ

100 の SQL

CPU_TIME サマリー・レポートの次のスクリーンショットは、この情報の表示例

を示しています。

（残りの記述は削除）

CPU_TIME および BUFFER_GETS のサマリー・レポートを確認したあと、SQL の

アップグレードの影響範囲を把握できます。基本的なテストが成功した場合、次

にパフォーマンスが低下した各 SQL の詳細を確認します。



25


パフォーマンスが低下した SQL のレポート

アップグレードによる影響の範囲を取得して、環境設定のエラーを解決したあと、

SQL ごとの詳細な確認を開始できます。また、パフォーマンスが低下した SQL の

レポートから開始するのが適です。これには、実行単位のパフォーマンスが低

下（選択した比較メトリックの少なくとも 5%）している SQL のすべての情報が

含まれます。できる限り詳細に多くの SQL を分析して、これらのリグレッション

を分類できるので、リグレッションの影響をなくす適な方法に関する通知済み

の決定を実行に移せます。

レポートには、各 SQL の次の情報が含まれます。

− すべての SQL テキストおよび解析スキーマ

− Oracle9i DatabaseおよびOracle Database 10.2パフォーマンスのすべての実

行統計（比較メトリックを超えた場合も含む）

− Oracle9i Database SQL トレースおよび Oracle Database 10.2 テスト実行で

取得された実行計画

− 分析中に SPA でおこなわれた調査結果

次のスクリーンショットは、単一の SQL の例を示しています。



26


通常、パフォーマンスが低下した SQLのレポートは、ワークロードのリグレッショ

ンの絶対的な影響の順に並べられます。実行パフォーマンスの変更と実行頻度を

組み合わせて、各変更の関連性を正確に定義します。収集した SQL トレースに有

意義な実行頻度情報が含まれていないので、この場合は実行できません。SQL ト

レースは、完全なワークロードの包括的なビューの作成を目的としていませんで

した。少なくとも 1 回、重要な各 SQL の取得を考慮しただけです。このため、各

SQL 比較メトリックの実行単位の変更によりレポートが整理されます。つまり、

この特定のユースケースでは SPA が各 SQL の相対的な重要性を識別できないこ

とを意味します。自身のワークロードに関する知識を活用して、重要な SQL また

は重要ではない SQLのリグレッションまたは計画変更の通知を識別する必要があ

ります。

レポートを確認し、この情報と上記の"パフォーマンス・メトリックの考慮事項"

の注意事項を考慮して、誤検出を初に排除します。SPA によりパフォーマンス

の低下が検出された SQL でも、本番システムにおいて実際に問題が発生しないと

思われる SQL をさらに検討する必要はありません。次に、余分なリグレッション

の発生した SQL を削除します。SQL がほとんど実行されない場合またはリグレッ

ションが小さくパフォーマンスに大きな影響を与えない場合、SQL をチューニン

グする価値はなく、むしろ潜在的なリスクが発生します。



27


残りの SQL は、チューニング対象のすべての有意義なリグレッションで構成され

ます。これらを次の個別のリストに分類します。

a) 同じ実行計画のパフォーマンスの低下した SQL

b) 異なる実行計画のパフォーマンスの低下した SQL

リグレッションを分類すると、根本原因

を理解し、可能性のある修正を把握でき

ます。

SQL チューニング候補のこれらの 2 つのリストを構築すると、あとでパフォーマ

ンスが向上する戦略を設計できます（"パフォーマンスの低下した SQL の修正"）。

それぞれのリストで、同様の問題のサブグループをできる限り構築すると、問題

をあとで効果的に修正できます。多くの SQL が基本となる同じ問題に直面してい

ることがわかった場合、一度だけ修正を適用して、グループ全体のパフォーマン

スの問題を解決できます。

計画が変更された SQL のレポート

SPA で検出された既知のリグレッションを分析したあと、変更の影響に関係なく

できるだけ多くの変更された計画を確認することを推奨します。サマリー・レポー

トおよびパフォーマンスが低下した SQL のレポートで SQL パフォーマンスのもっ

とも疑わしい変更が提案された場合、計画が変更されたレポートでパフォーマン

スが向上および低下しそうな追加の SQL を示すことができます。一連の既知の問

題を確認したあと、これまでに説明した多くの理由によって、SPA の分析により

検出できなかった可能性のある問題の簡潔な調査を実行します。

実行計画の変更を確認したあと、問題となる変更のセットを検出できます。この

場合、計画変更が悪影響を与える可能性のある条件（特定の環境やバインド値な

ど）を検索する手動のテストの実行を推奨します。追加のテストで問題が確認さ

れた場合、これらの SQL を上記のリスト b に追加する必要があります。また、こ

れらの望ましくない計画変更を分類する一般的な症状に注意してください。各変

更タイプのすべての SQL の完全なリストの作成が実用的ではない場合でも、この

ような変更を削除する場合にこれらのパターンが非常に役立ちます。

パフォーマンスの低下した SQL の修正

SPA 分析の手順を実行して検出された疑わしいパフォーマンスの低下を分類した

あと、SQL のチューニングを開始できます。異なるタイプの問題には、異なるチュー

ニング戦略が効果的です。この項では、このアップグレード後に直面する可能性

のある主要な問題のカテゴリを確認して、それぞれを解決する方法について推奨

します。検出されたリグレッションを分類し、各カテゴリをドリルダウンしてリ

グレッションの根本原因を検出し、追加の SPA 分析で疑わしい根本原因を検証す

る戦略を推奨します。初に、後の手順で定義された 2 つの上位レベルのカ

テゴリでパフォーマンスが低下した計画の根本原因を検索します。同じ実行計画

のパフォーマンスが低下した SQL を検索してから、計画変更のパフォーマンスが

低下した SQL を検索します。



28


同じ実行計画のパフォーマンスの低下した SQL

計画を変更しないで SQL のパフォーマンスが低下した場合、一般的に 2 つのトラ

イアルの実行環境の非一貫性が原因です。一般的に、データベースの実行時の動

作を変更すると、あらゆる状況で改善が確認されます。このため、この領域での

多くのリグレッションは想定していません。ただし、2 つの環境で意図しない違

いが発生すると、実行ごとにパフォーマンスが低下する可能性があります。たと

えば、テスト実行環境で使用できるメモリが不足する場合または特定の状況に

限ってほかのワークロードがシステムで実行される場合、パフォーマンスの違い

を確認できます。このタイプの多くのリグレッションを確認した場合、Oracle9i

および Oracle Database 10g のデータベース・システムの徹底的な比較をおこなっ

て、環境の不一致を検出および修正することを推奨します。疑わしい問題に関連

する変更をおこなう前に、両方のシステムの疑わしい実行時のリグレッションを

手動で再現する必要があります。

めったにないものの、実行時の動作の変更が重要な問題の原因である場合、該当

するいくつかの SQL を詳細に確認し、問題の原因を特定して不適切な動作を無効

にすることで問題を修正します。問題を調査および解決する方法がわからない場

合は、Oracle サポートにお問い合わせください。

パフォーマンスの低下した SQL と実行計画の変更

ほとんどの SQL チューニングが実行計画の変更に関連すると考えられます。SPA

が検出した各問題を調査して根本原因を特定し、変更を適用して根本原因を修正

し、この変更の影響をテストする必要があります。オラクルは、これらの問題を

修正する多くの異なる方法を提供します。それぞれを検討して長所と短所を理解

することが非常に重要です。一般的に、問題の修正は、単一の SQL にのみ影響す

る変更を含むポイント・ソリューションと 1 つの修正が多くの SQL に影響を与え

る体系的なソリューションに分割されます。誤った方法を選択すると、今後の変

更に十分に対応していない場合、解決できる問題よりも多くの問題が発生する可

能性があります。

一連のリグレッションの根本原因の把握

は、適切な修正を検出する最適な方法で

す。

検出したリグレッションのタイプを分類するほど、効果が期待できます。多くの

場合、同様の問題をもつ多くの SQL を単一の変更で修正できます。体系的な問題

にポイント・ソリューションを選択すると、問題が発生した各 SQL が１回につき

１箇所ずつ修正されるため、1 つの問題を解決するのに多くのシステム変更が必

要になります。また、取得した SQL トレースにはワークロードのすべての SQL

が含まれないので、検出された体系的な問題も未知の SQL に影響を与える場合が

あります。このような未知の SQL のパフォーマンスが低下した場合、これらのリ

グレッションを解決したあとで、問題に使用されるポイント・ソリューションを

再適用する必要があります。多くの SQL に影響を与える可能性のある変更をおこ

なって 1 つの SQL を修正しても、ほとんど意味がありません。１つの SQL の修

正によってほかの 100 の SQL に問題が発生する可能性があります。



29




30


パフォーマンスが低下した SQL をいくつか検出した場合、それぞれのポイント・

ソリューションを実行することを推奨します。この項では、体系的な問題および

部分的な問題のいくつか可能性のあるソースを説明し、確認するソリューション

を提案します。次の"提案された修正のテスト"では、SPA を使用して修正の効果

を確認する方法を説明します。パフォーマンスの低下した計画の根本原因を理解

するには、オラクルのオプティマイザ変更に関するホワイト・ペーパー（[OPT]）

を参照してください。詳細は、Oracle サポートにお問い合わせください。

体系的な問題の調査および解決

システムで SQL のサブセットのパフォーマンスを低下させる Oracle Database 10g

のもっとも注目すべき変更は、以下のとおりです。

− オプティマイザ・パラメータの変更：Oracle Database 10g ではルールベー

ス・オプティマイザがサポートされないため、デフォルトの optimizer_

mode が ALL_ROWS に変更されました。オプティマイザは、オブジェク

ト統計が欠落する場合に動的なサンプリングを使用します。このため、

optimizer_dynamic_sampling のデフォルト値も変更されています。異なる

サンプル・サイズとともに、分析されていないすべての表で実行されま

す。両方のパラメータが実行計画に影響を与える可能性があります。

optimizer_mode パラメータを CHOOSE、optimizer_dynamic_sampling パラ

メータを 1 に設定してテスト用に Oracle9i のデフォルト動作に戻し、こ

れらのパラメータがリグレッションの原因かどうかをテストできます。

optimizer_mode の CHOOSE 値が Oracle Database 10g でサポートされないた

め、永続的な修正としてこれらを実装できないことに注意してください。

一部の SQL 用のコストベース・オプティマイザの移行によって発生した

リグレッションを修正するには、コストベース・オプティマイザへの移

行に関するオラクルのホワイト・ペーパーを参照してください（[CBO]）。

次の項（"単一の SQL にのみ影響を与える問題の修正"）で説明されてい

るとおり、これらの SQL でも SQL Tuning Advisor を実行できます。

− PGA_AGGREGATE_TARGET：Oracle Database 10g のこのパラメータは、

デフォルトで有効です。明示的に上書きしない限り、SGA サイズの 20%

に設定してください。厳密にはオプティマイザ・パラメータではありま

せんが、オプティマイザのコスト計算モデルの重要な要素です。SQL の

実行時に使用できるメモリ量は、ハッシュ結合やソートなどの特定の演

算子のパフォーマンスに大きな影響を与える場合があります。オプティマ

イザは、このパラメータを使用して、予測される使用可能なメモリ量の費

用の高さを判断します。デフォルトで、Oracle Database 10g の*_AREA_SIZE

パラメータは無視されます。Oracle9i Database で設定され、これがリグ

レッションの原因であると考えられる場合、古い*_AREA_SIZE パラメー

タ値とともにWORKAREA_SIZE_POLICY init.oraパラメータをMANUAL

に設定して古いモデルに戻し、リグレッションがなくなるかどうかを確

認できます。これが問題の原因である場合、PGA_AGGREGATE_TARGET

値を手動でチューニングしてシステムに適切な値に変更するか、

*_AREA_ SIZE/WORKAREA_SIZE_POLICY 値を維持することを推奨します。



31


− DBMS_STATS の変更：オプティマイザ統計が収集される方法（自動収集、

デフォルトのヒストグラムの収集、サンプル・サイズの計算の有効化を

含む）のデフォルト動作で多くの変更がおこなわれました。これらの変

更によって、計画が変更される可能性があります。新しい統計によって

リグレッションが発生したかどうかをテストするには、以前の統計に戻っ

て、リグレッションが修正されるかどうかを確認します。"Oracle Database

10.2 テスト・システムの作成"の項で、Oracle9i Database 統計を統計表に

コピーすることを推奨しました。このため、この手順で、リグレッショ

ンの根本原因かどうかを確認するためにリストアできます。

DBMS_STATS. IMPORT_DATABASE_STATS API を使用して、これを実行できます。

dbms_stats.import_database_stats(”STATTAB‘);

− CPU のコスト計算：Oracle Database 10g のデフォルトの CBO コスト計算

アルゴリズムでは、CPU コストを推定します。Oracle9i のデフォルト動作

は、システム統計自体を収集しない限り I/O のみに基づくコスト計画です。

DBMS_STATS でシステム統計を収集しない場合、CBO に使用される値

がシステムに十分に適用されない可能性があるので、重要な計画変更が

発生することがあります。オプティマイザのコスト計算に対するこれら

の変更により問題が発生したと考えられる場合、DBMS_STATS パッケー

ジでオプティマイザ・システム統計が収集されていることを確認してく

ださい。DBMS_STATS.GATHER_SYSTEM_STATS API を使用して、これ

を実行できます。

dbms_stats.gather_system_stats( gathering_mode => ”NOWORKLOAD‘);

− 新しいオプティマイザの変換/動作：オラクルは、リリースごとのオプティ

マイザの改善に常に取り組んでいます。また、導入された新しい動作に

よって全体が向上すると考えています。ただし、特定の変更によって、SQL

とワークロードの一部に利点がもたらされない場合があります。一般的な

計画変更は、新しいオプティマイザ機能によって発生します。Oracle Database

10g のパフォーマンスの向上を活用する必要がない場合、OPTIMIZER_

FEATURES_ENABLE を以前のリリースに設定してその値でテストする

ことで、これらの機能を無効にできます。特定の機能を無効化すること

について、詳しくは Oracle サポートにお問い合わせください。

新しいオプティマイザ機能が問題の原因かどうかをテストするには、

OPTIMIZER_FEATURES_ENABLE パラメータを'9.2.0'に設定して、リグ

レッションがなくなるかどうかを確認します。

多くの SQL を含むリグレッションの原因の特定が困難な場合、適切な原因を推測

してください。次の手順（"提案された修正のテスト"）で修正をテストするので、

問題が解決されない処理を試行するリスクはありません。後続の SPA の実行は、

問題が修正されていないことを示します。次に繰り返して実行することで異なる

修正を試行できます。



32


単一の SQL にのみ影響を与える問題の修正

個別の問題が発生していると考えられる SQL 文の場合、次の潜在的な修正から選

択することを推奨します。

− SQL プロファイル：SQL に次善の計画がある場合、システムは Oracle

Database 10g の SQL Tuning Advisor を使用して、SQL プロファイルと呼ば

れる新しいソリューションを推奨できます。問題の根本原因に対処する

柔軟なソリューションなので、初の修正として SQL プロファイルの使

用を推奨します。また、SQL プロファイルは、データの変更によって実

行計画で対応する変更が必要になる今後の状況にも十分に対応します。

アドバイザからのほかの推奨事項にとくに注意してください。大きな利

点をもたらす可能性のある強力な代替手段が示される場合があります。

SQL テキストとバインド値を直接コマンドライン API に渡して、一度に

単一の SQL に SQL Tuning Advisor を実行できます。または、SQL Tuning

Set を Oracle Database 10g にエクスポートし、全体の STS の単一のチュー

ニング・タスクを作成して、1回の手順で複数のSQLにSQL Tuning Advisor

を実行できます。通常、Oracle Database 11g から Oracle Database 10.2 への

STS の移行はサポートされていないので、このように STS をエクスポー

トする場合は特殊な手順が必要になります。付録 B の例を参照してくだ

さい。SQL Tuning Advisor の実行には、使用するシステムのチューニン

グ・パックのライセンスが必要です。

− ストアド・アウトライン：SQL チューニングでリグレッションを修正で

きない場合、Oracle9i 本番システムから取得したストアド・アウトライン

を使用できます。本番システムの CREATE STORED OUTLINE DDL を使

用して、ストアド・アウトラインを作成し、OUTLN スキーマから SPA

でテストできる Oracle Database 10g テスト・システムにエクスポートでき

ます。詳細は、オプティマイザ変更に関するホワイト・ペーパー（[OPT]）

を参照してください。ストアド・アウトラインは、問合せ計画の安定性

を提供します。ただし、将来のデータ変更や将来のリリースのオプティ

マイザ拡張機能には対応しません。計画のコストがあとで高くなった場

合、DBA が SQL を再度チューニングするまでオプティマイザは例外なし

に選択を継続します。

− 手動のヒント：ストアド・アウトラインを作成する代替手段として、SQL

Tuning Advisor が SQL プロファイルの作成に失敗した場合、手動の SQL

のヒントを検討してください。たとえば、/*+ OPTIMIZER_FEATURES_

ENABLE ('9.2.0') */ヒントを追加して、9.2 の計画を生成できます。



33


この方法ではアプリケーション・コードの変更が必要ですが、単一の計

画に永続的に組み込むのではなく限定された数のオプティマイザによる

決定のみを固定するので、ストアド・アウトラインよりも柔軟性があり

ます。この方法の短所は、不正確に実行された場合、あとで問題を修正

するために追加のアプリケーション変更が必要になることです。含まれ

るデータの関係を把握しているユーザーが正しく実行した場合、手動の

ヒントによって、特定の重要な適化決定が常に正しくおこなわれるこ

とが保証されます。

提案された修正のテスト

テストは、提案された予想どおりの変更を確認して実装するだけではありません。

多くの場合、変更によってパフォーマンスが向上する SQL とパフォーマンスが低

下する SQL があります。したがって、本番システムで重要な SQL のパフォーマ

ンスが低下しないように、追加の変更をおこなう必要があります。このため、SPA

が繰り返し使用されます。同じタスク・コンテナ内で複数のテスト実行トライア

ルを許可して、作成されたトライアルのペアの比較をサポートします。

後の手順で検出された問題の一連の提案された修正を作成したあと、Oracle

Database 10g テスト・システムを変更し、別の SPA テスト実行トライアル（この

あとに、既存の Oracle9i トライアルと新しい Oracle Database 10.2 トライアルを比

較する新しい SPA 分析トライアルのペア）を実行することを推奨します。すべて

の重要なリグレッションがなくなるまで、上記の項の手順を繰り返して新しい修

正の検索およびテストを継続してください。リグレッションの根本原因の検索は

非常に困難でエラーが発生しやすくなる可能性があります。可能性のある各修正

の個別のテストは、プロセスに妥当性をもたらす適な方法です。

アップグレード用の本番システムの準備

十分な数の SPA を繰り返したあと、既知のパフォーマンスの低下に使用する一連

の修正に集中します。アップグレードの実行時にこれらを本番システムに配置し

てください。SPA を使用して問題と修正を事前に把握できるので、リグレッショ

ンが発生するまで待機してから対応する必要はありません。

テスト・システムと同じように、ここで推奨されるほとんどの修正を本番システ

ムに実装できます。SQL プロファイルでは、DBMS_SQLTUNE の API（付録 B を

参照）を使用し、ステージング表を介してテスト・システムに作成された SQL プ

ロファイルを本番システムにエクスポートし、アップグレード後の本番システム

における SQL Tuning Advisor の再実行を回避できます。SQL プロファイルが基本

となるデータの関係を表すので、テスト・システムにすべての本番データが含ま

れない場合、移行後に本番システムの SQL プロファイルを手動でテストする必要

があります。



34


アップグレード後の予期しない問題の対処

徹底的にテストを実行しても、環境の変更、同時実行性の問題、テスト/本番シス

テムの違いなどによってアップグレード後の予期しない問題を完全に防止できま

せん。SPA などの科学的なツールによるテストの目的は、このような予期しない

リグレッションをできるだけ制限することです。アップグレード後のパフォーマ

ンス・データの AWR スナップショットを自動的に取得し、アップグレード前の

Statspack スナップショットと比較してパフォーマンスの向上または低下の状態を

確認する場合、Diagnostic Pack のライセンスを推奨します。リグレッションが存

在する場合、リグレッションに該当するワークロードの一部を検索して原因（計

画変更など）を特定するのに、このデータが非常に役立ちます。

アップグレード後に SQL のパフォーマンスが低下する場合、SQL Tuning Advisor

の実行を推奨します。SQL Tuning Advisor は、SQL パフォーマンスの問題の根本

原因を検索し、タイムリーに問題の修正を提供します。プロファイルの作成に失

敗した場合、OPTIMIZER_FEATURES_ENABLED が古いリリースに設定されてい

るセッションのストアド・アウトラインを生成したり、もとの計画に戻す SQL の

手動のヒントを設定したりできます。

結論

本番データベースのアップグレードは、ほとんどの Oracle ユーザーにとって重大

なタスクであり、準備とテストに多くの工数がかかります。適切なテスト・ツー

ルや戦略がない場合、アップグレードのあとまで問題が検出されないことがあり

ます。また、以前のリリースの許容範囲のパフォーマンスをリストアしようとす

る負担から、新しいリリースの機能の保証がすぐに見落とされる可能性がありま

す。Oracle Database 11g の SQL Performance Analyzer で、アップグレード前にほと

んどの SQL パフォーマンスの低下を検出できる信頼性の高い科学的なテスト・

ツールをデータベースに組み込みました。

Oracle9i Database から Oracle Database 10g に現在アップグレードしている顧客の

ニーズを満たすため、新しいシナリオのサポートを SPA に組み込みました。これ

によって、Oracle9i Database の SQL トレース・ファイルで収集された SQL パフォー

マンスと Oracle Database 10g のリモート・テスト実行の SQL パフォーマンスが比

較されます。このドキュメントでは、このシナリオの実装方法、SPA を使用した

プロセスの各手順の実行方法、および SPA の結果を参照する場合の注意事項を説

明しました。この知識を取得することで、多くの DBA は本番システムへのアップ

グレードの影響について、信頼性の高い正確な予測をおこない、本番システムで

問題が発生する前に修正を実装して、望ましくない費用のかかる停止時間を回避

できます。



35


付録 A：小規模なハードウェア構成でのテスト

このホワイト・ペーパー全体で、"Oracle Database 10.2 テスト・システムの作成"の

項から Oracle9i Database 本番システムと同じハードウェアとデータを使用した Oracle

Database 10g テスト・システムの SPA テストの必要性を主張してきました。SPA

がこれらのシステムのパフォーマンスを比較するので、ここで説明されているシ

ナリオにはこの条件が不可欠です。また、ハードウェアの変更とデータベースの

アップグレードが組み合わされた場合、問題の原因を特定できません。

このため、オラクルでは、多くの顧客によるテスト目的の本番システムの完全な

レプリカの構築が現実的ではないことを認識しています。ここではこのケースの

別のシナリオを用意して、このような制約下でも SPA を効果的に使用できること

を示します。この場合、本番システムと類似した環境の Oracle9i Database テスト・

システム（少し規模を縮小し SQL トレースを有効にして本番システムとできるだ

け同じワークロードを実行する環境）の構築を推奨します。SPA リモート・テス

ト実行インフラストラクチャはOracle9i Databaseに存在しないので、機能テスト、

サード・パーティ・ツール、手動スクリプトなどの任意の手段を使用して SQL ワー

クロードを実行します。ワークロードを繰り返したあと、"Oracle Database 11g SPA

システムの作成"に示されているように、作成した SQL トレース・ファイルとマッ

ピング表を小規模な Oracle Database 11g テスト・システムに移動し、パフォーマ

ンス・データを SQL Tuning Set にロードします。

次に、SQL トレースが生成された Oracle9i Database テスト・システムを Oracle

Database 10.2 にアップグレードして、リモート・テスト実行トライアルに使用し

ます。このため、変更前と変更後のパフォーマンス・データが同じシステムに生

成されます。両方の統計が同じ環境に生成されるので、信頼性の高いパフォーマ

ンスの比較を実行できます（"パフォーマンス・メトリックの考慮事項"）。

このシナリオの残りの作業は、このホワイト・ペーパーの残りと同じです。SPA

タスクの 2 つのトライアルが完了したあと、追加の SPA トライアルを作成するアッ

プグレード以外に、SPA を使用して、CPU と BUFFER_GETS のデータの分析、レ

ポートの詳細な調査、パフォーマンスの低下した SQL の修正の実装、およびこう

した修正のテストを実行します。このシナリオには、テストに使用されるハード

ウェアとデータを本番システムから取得するほど本番システムで発生する処理を

正確に予測できなくなるという短所があります。ただし、本番システムの完全な

レプリカを構築できない場合、使用できる適なオプションであると考えられま

す。本番システムの完全なクローンを使用しない場合でも、テストを適切に実行

すれば非常に貴重な実習となります。



36


付録 B：SPA コマンドライン API の例

SQL Tuning Set への SQL トレース・データのロード

次の例は、SPA を準備するためにデータベースに SQL トレース・ファイルを読み

込む方法と SQL Tuning Set に SQL トレース・ファイルをロードする方法を示して

います。現在のスキーマに'9i_prod_wkld'という STS を作成します。

非常に大きいトレース・ファイルを解析するには、時間がかかります。

DBA_/USER_SQLSET ビューの問合せを実行して、ロード操作の進捗状況を監視

できます。STATEMENT_COUNT 列は、その時点までにロードされた SQL 文の数

を示します。

--create a database link to the 10.2 system CREATE PUBLIC DATABASE LINK mylink CONNECT TO user IDENTIFIED BY pwd USING ”connect_string‘ / --create a dir obj pointing to the location of the trace files create or replace directory mydir as '</path/to/trace/files>'; declare

mycur dbms_sqltune.sqlset_cursor; begin

--read all ORA trace files in directory 'mydir' into an STS dbms_sqltune.create_sqlset('9i_prod_wkld');

open mycur for

select value(p) from table(dbms_sqltune.select_sql_trace( directory => 'MYDIR', file_name => '%ora%', mapping_table_name => 'MAPPING_TABLE', select_mode => dbms_sqltune.SINGLE_EXECUTION)) p;

dbms_sqltune.load_sqlset(

sqlset_name => '9i_prod_wkld', populate_cursor => mycur, commit_rows => 1000);

close mycur;

end; /



37


SQL Performance Analyzer の実行

STS をロードしたあと、SPA を実行できます。次の例では、タスクを作成し、Oracle

Database 10g のテストを実行して、トライアル間の CPU_TIME と BUFFER_GETS

の変更を比較する HTML レポートを生成します。

declare tname varchar2(30);

begin tname := dbms_sqlpa.create_analysis_task(

task_name => '9i_10g_spa', sqlset_name => '9i_prod_wkld', description => 'Experiment for 9i to 10gR2 upgrade');

--no more than 5 minutes to execute each SQL dbms_sqlpa.set_analysis_task_parameter(

task_name => '9i_10g_spa', parameter => 'LOCAL_TIME_LIMIT', value => 300);

--ignore workload impact (only one exec per sql captured) dbms_sqlpa.set_analysis_task_parameter(

task_name => '9i_10g_spa', parameter => ”WORKLOAD_IMPACT_THRESHOLD', value => 0);

--at least 5% impact per execution dbms_sqlpa.set_analysis_task_parameter(

task_name => '9i_10g_spa', parameter => ”SQL_IMPACT_THRESHOLD', value => 5);

--load 9i data into a spa trial dbms_sqlpa.execute_analysis_task(

task_name => '9i_10g_spa', execution_name => '9i_trial', execution_type => 'CONVERT SQLSET');

--collect 10g data through remote test-execute dbms_sqlpa.execute_analysis_task(

task_name => '9i_10g_spa', execution_name => '10g_trial', execution_type => 'TEST EXECUTE', execution_params => dbms_advisor.arglist(

'DATABASE_LINK', 'MYLINK.SERIES.OF.GLOBAL.SUFFIXES'));

--compare 9i to 10g for CPU dbms_sqlpa.execute_analysis_task(

task_name => '9i_10g_spa', execution_name => 'compare_9i_102_cpu', execution_type => ”COMPARE PERFORMANCE‘, execution_params => dbms_advisor.arglist(

'COMPARISON_METRIC', 'CPU_TIME', 'EXECUTION_NAME1', '9i_trial', 'EXECUTION_NAME2', '10g_trial'),

execution_desc => 'Compare 9i SQL Trace Performance ' || 'to 10g Test-Execute for CPU_TIME');



38


--compare 9i to 10g for buffer_gets dbms_sqlpa.execute_analysis_task(

task_name => '9i_10g_spa', execution_name => 'compare_9i_102_bgets', execution_type => ”COMPARE PERFORMANCE‘, execution_params => dbms_advisor.arglist(

'COMPARISON_METRIC', ”BUFFER_GETS', 'EXECUTION_NAME1', '9i_trial', 'EXECUTION_NAME2', '10g_trial'),

execution_desc => 'Compare 9i SQL Trace Performance ' || 'to 10g Test-Execute for BUFFER_GETS');

end; / --spool reports to files set heading off long 1000000000 longchunksize 10000 echo off; set linesize 1000 trimspool on; --summary report for CPU comparison spool cpu_summary.html select xmltype(dbms_sqlpa.report_analysis_task(


).getclobval(0,0) from dual; spool off --regressed details for CPU comparison spool cpu_regress.html select xmltype(dbms_sqlpa.report_analysis_task(


).getclobval(0,0) from dual; spool off --summary report for BUFFER_GETS comparison spool bg_summary.html select xmltype(dbms_sqlpa.report_analysis_task(





39


--regressed details for BUFFER_GETS comparison spool bg_regress.html select xmltype(dbms_sqlpa.report_analysis_task(


).getclobval(0,0) from dual; spool off --changed plans spool chgd_plans.html select xmltype(dbms_sqlpa.report_analysis_task(





40


SQL Tuning Advisor の実行

Oracle Database 10g システムの SQL Tuning Advisor を実行するには、各 SQL の個

別のチューニング・タスクまたはパフォーマンスの低下したすべての SQL の単一

のチューニング・タスクを作成できます。少ない SQL を使用している場合、SQL

テキストとバインド値を単一の文の CREATE_TUNING_TASK API に貼り付けて、

それぞれのチューニング・タスクを作成できます。ここでは、関連性の高い 2 つ

目のオプションの例を示します。

多くのSQLをチューニングする場合、パフォーマンスの低下したSQLのSQL Tuning

Set（STS）のサブセットを対象のデータベースに移行する必要がある 2 つ目のオ

プションを使用します。SQL Tuning Set を Oracle Database 11g ステージング表に組

み込み、Oracle Database 10g と互換性のある 2 つ目のステージング表に SQL をコ

ピーし、Data Pump クライアントを使用してこの 2 つ目のステージング表を Oracle

Database 10g システムに移動することで実行できます。Oracle Database 11g システ

ムで、上記の"単一のSQLにのみ影響を与える問題の修正"で構築したように、チュー

ニングする SQL_ID のリストを含む単一の列の sql_id を使用した tuning_candidate_tab

と呼ばれる表を初に作成します。

次に、以下のコマンドを実行して、チューニングする SQL のサブセットを使用し

た STS を実体化し、ステージング表に組み込みます。

declare mycur dbms_sqltune.sqlset_cursor; basf varchar2(32767);

begin --put the subset of sqls we want to tune into another STS basf := 'sql_id in (select sql_id

from tuning_candidate_tab)';

dbms_sqltune.create_sqlset('sqls_to_tune'); open mycur for

select value(p) from table(dbms_sqltune.select_sqlset('9i_prod_wkld',

basf, null, null, null, null, 1, null,'BASIC')) p;

dbms_sqltune.load_sqlset('sqls_to_tune', mycur); close mycur; --pack the sts into a staging table dbms_sqltune.create_stgtab_sqlset('STGTAB'); dbms_sqltune.pack_stgtab_sqlset(

sqlset_name => 'sqls_to_tune', staging_table_name => 'STGTAB');

end; /



41


次のコマンドを実行して、これらの SQL を Oracle Database 10g Release 2 と互換性

のあるステージング表にコピーします。

exec dbms_sqltune.create_stgtab_sqlset(”STGTAB_10G‘); insert into stgtab_10g

(name, owner, description, sql_id, force_matching_signature, sql_text, parsing_schema_name, bind_data, bind_list, module, action, elapsed_time, cpu_time, buffer_gets, disk_reads, direct_writes, rows_processed, fetches, executions, end_of_fetch_count, optimizer_cost, optimizer_env, priority, command_type, first_load_time, stat_period, active_stat_period, other, plan_hash_value, spare2)

select name, owner, description, sql_id, force_matching_signature, sql_text, parsing_schema_name, bind_data, bind_list, module, action, elapsed_time, cpu_time, buffer_gets, disk_reads, direct_writes, rows_processed, fetches, executions, end_of_fetch_count, optimizer_cost, null, priority, command_type, first_load_time, stat_period, active_stat_period, other, plan_hash_value, 1

from stgtab; commit;

次に、Data Pump を使用して、ステージング表（STGTAB_10G）を Oracle Database

10g Release 2 システムに移動します。以下に例を示します。

expdp user/pwd tables=STGTAB_10G version=10.2.0.4 directory=WORK_DIR dumpfile=stgtab10g.dmp <copy file to 10.2 system> impdp user/pwd directory=WORK_DIR dumpfile=stgtab10g.dmp

後に、Oracle 10g システムで、ステージング表をアンパックして、STS を再構築

できます。

begin dbms_sqltune.unpack_stgtab_sqlset(

sqlset_name => ”%‘, sqlset_owner => ”%‘, staging_table_name => ”STGTAB‘, replace => TRUE);

end; /



42


Oracle Database 10g の STS を使用すると、SQL Tuning Advisor の実行とレポートの

取得が簡単です。

declare tname varchar2(30);

begin tname := dbms_sqltune.create_tuning_task(

sqlset_name => 'sqls_to_tune', task_name => 'tune_regressed_sqls');

--10 mins to tune each SQL dbms_sqltune.set_tuning_task_parameter(

task_name => 'tune_regressed_sqls', parameter => 'LOCAL_TIME_LIMIT', value => 600);

dbms_sqltune.execute_tuning_task('tune_regressed_sqls');

end; / set heading off long 1000000000 longchunksize 10000 echo off; --sql tune report spool sqltune_report.txt select dbms_sqltune.report_tuning_task('tune_regressed_sqls') from dual; spool off --accept a SQL profile exec dbms_sqltune.accept_sql_profile(

task_name => ”tune_regressed_sqls‘, object_id => <object id from report>);

エクスポート用の SQL プロファイルの準備

SQL プロファイルを実装してリグレッションの修正を選択する場合、Oracle

Database 10.2 にアップグレードしたあとにこれらのプロファイルを本番システム

にコピーする必要があります。これを実行するには、次のように Oracle Database

10.2 テスト・システムのステージング表にプロファイルを組み込んで、本番シス

テムでアンパックします。

begin dbms_sqltune.create_stgtab_sqlprof(

table_name => 'SQLPROF_TAB');

--pack all sql profiles, for export dbms_sqltune.pack_stgtab_sqlprof(

profile_name => '%', staging_table_name => 'SQLPROF_TAB');

end; /



43


Oracle Database 10.2 の本番システムにアップグレードしたあと、ステージング表

を本番システムに移動して、次のようにステージング表をアンパックします。

begin --pack all sql profiles, for export dbms_sqltune.unpack_stgtab_sqlprof(

replace => TRUE, staging_table_name => 'SQLPROF_TAB');

end; /

付録 C：SQL Trace の有効化によるパフォーマンスへの影響

本番システムへの SQL トレースの影響を把握して、Oracle9i Database データに対

する SPA 結果の偏りを見積もるため、OLTP を多用するアプリケーションの一連

の 55,000の問合せとDSSを多用するアプリケーションの 100の問合せを使用した

テストを実行しました。CPU 時間統計にほとんどの影響が発生していることが

わかりました。

DSS の結果では、10～20%前後の変化を中心に鐘形の曲線が形成されています。

テストした SQL の 77.8%が 20%未満の SQL トレース・オーバーヘッドであること

は、望ましい結果です。つまり、実行に時間のかかる多くの SQL に対して SQL

トレースが大きく影響しないことを意味します。しかし、OLTP 問合せの結果は

複雑になります。



44


上記よりも向上している SQL がこのグラフに表示され、68.8%の SQL が SQL ト

レースの影響を受けていないことがわかります（DSS の 17.4%と比較）。ただし、

一部の SQL が低下します。23.9%の SQL が 90%以上のリグレッションを示してい

ます（DSS の 1.2%と比較）。

これらの大幅にパフォーマンスが低下した SQL を調査するため、トレース前の

CPU 時間の観点からどのように SQL が分散されたかを確認して、データのパター

ンを検索しました。

これらの結果では、オーバーヘッドが大きいほとんどの SQL の応答時間が非常に

少ないことを示しています。87.6%の SQL が 10 ミリ秒未満の応答時間でした。し

たがって、大きくリグレッションするほとんどの SQL の応答時間が非常に高速で

あることがわかります。これは、SQL トレースには、回避できないトレース・ファ

イルの各実行の小固定コストがあるためです。再帰実行がおこなわれるたびに

この固定コストが何倍にも増加したので、多くの再帰 SQL（PL/SQL 下など）を



45




46


実行する SQL のオーバーヘッドがさらに大きくなりました。逆に、実行に時間の

かかる SQL ではすべての実行時間で影響が分散されたので、影響が目立たなくな

りました。

総合すると、これらのテストによって、SQL トレースの SQL 実行の偏りを正しく

認識できます。SQL ごとにオーバーヘッドが大きく異なり、多くの場合に目立ち

ますが、認識できなくなるほどには SQL のパフォーマンス・データに影響しませ

ん。非常に大きな影響がある場合は、SQL の実行時間が短く、余分なコード・パ

スが非常に目立つためです。また、OLTP および DSS ワークロードのパターンが

非常に異なるので、SQL にもっとも適切なパターンにしたがって解釈を調整する

必要があります。



47


参考資料

− Real Application Testing Backport for Pre-11g Database Releases：Metalink

Note 560977.11 [SPAMET]

− Oracle Database Real Application Testing 追加情報（製品ドキュメント）：

http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/nav/portal

_3.htm

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

マンス・アナライザ：

http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/nav/portal

_3.htm

− SQL Performance Analyzer（Oracleホワイト・ペーパー、英語） [SPAOOW]：

http://www.oracle.com/technology/products/manageability/database/pdf/ow07/s

pa_white_paper_ow07.pdf

− Upgrading from Oracle 9i Database to Oracle Database 10g: what to expect from the optimizer（Oracle ホワイト・ペーパー、英語） [OPT]：

http://www.oracle.com/technology/products/bi/db/10g/pdf/ twp_bidw_

optimizer_10gr2_0208.pdf

− The DBMS_SUPPORT Package：Metalink Note 62294.11 [SUPP]

− コストベース・オプティマイザへの移行 [CBO]：

http://otndnld.oracle.co.jp/products/database/oracle10g/bi/pdf/twp_general_cbo_

migration_10gr2_0405.pdf

− Oracle Upgrade Companion：Metalink Note 466181.11

− Oracle's SQL Performance Analyzer（IEEE Data Engineering Bulletin Vol 38

No.1、2008 年 3 月、英語）：

http://sites.computer.org/debull/A08mar/yagoub.pdf

1 MetaLink 情報の参照および MetaLink からのパッチのダウンロードには、MetaLink アカウントが必要

です。（ https://metalink.oracle.com/ ）

http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/nav/portal_3.htm




http://www.oracle.com/technology/products/manageability/database/pdf/ow07/spa_white_paper_ow07.pdf

http://www.oracle.com/technology/products/manageability/database/pdf/ow07/spa_white_paper_ow07.pdf

http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf

http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf

http://otndnld.oracle.co.jp/products/database/oracle10g/bi/pdf/twp_general_cbo_migration_10gr2_0405.pdf

http://otndnld.oracle.co.jp/products/database/oracle10g/bi/pdf/twp_general_cbo_migration_10gr2_0405.pdf

http://sites.computer.org/debull/A08mar/yagoub.pdf

https://metalink.oracle.com/

Oracle Real Application Testing：SQL Performance Analyzer を使用した Oracle9i から Oracle Database 10g Release 2 へのアップグレードによる SQL パ

フォーマンスへの影響のテスト 2008 年 3 月著者：Pete Belknap 共著者：Benoit Dageville、Prabhaker Gongloor（GP）、Shantanu Joshi、Khaled Yagoub、Hailing Yu、Cecilia Grant、Maria Colgan Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2007, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容

は予告なく変更されることがあります。本文書は一切間違いがないことを保

証するものではなく、さらに、口述による明示または法律による黙示を問わ

ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含

み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書に

よって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目

的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成

または送信することはできません。Oracle は米国 Oracle Corporation および

その子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商

標です。

Oracle Real Application Testing：SQL Performance … Real Application Testing：SQL Performance Analyzer を使用した Oracle9i Database からOracle Database 10g Release 2...

Documents