Oracle9i Reportsのチューニング

Oracle9i Reports

のチューニング

オラクル・ホワイト・ペーパー

Oracle9i Reports

のチューニング

はじめに... 3 方法論... 4 パフォーマンス解析ツール製品 ... 4 データへのアクセス... 9 データのフォーマット... 14 レイアウトについての一般的なガイドライン ... 18 Oracle9i Formsからのレポートの呼出し ... 19 レポートの実行... 19 結論... 20 付録 A... 22 付録 B ... 24

Oracle9i Reports

のチューニング

はじめに

Oracle9i Reportsは、エンタープライズ・レベルの動的なレポート作成に活用でき る強力な高性能レポート作成ツールです。レポート作成要求や対象となるユー ザーの範囲が拡大するにつれ、パフォーマンスに注意を払うことが不可欠になり、 また、はっきりとしたパフォーマンスを改善するために何が可能かを理解するこ とが重要です。 関連するコスト、コンピューティング環境の複雑さ、およびレポート作成などの 単一のコンピューティング領域でパフォーマンスを改善する際に発生する機能の トレード・オフ、等々について考慮する必要があります。これらの事項を調査す ることで、パフォーマンスを相当改善することができます。なかには、パフォー マンスの改善が若干である場合や、実際のレポート・パフォーマンスに影響しな い事もありますが、多くの場合、目に見えて実行時間を改善することができます。 このホワイト・ペーパーでは、個々の Oracle9i レポートの作成、実装、チューニ ングに適したパフォーマンス技法についてのガイドラインや提案事項を紹介しま す。ここでは、レポートの配布やスケーラビリティの問題は扱いません。記載し ている提案はあくまで一般的なもので、すべての提案がすべての場合に適用され るとは言い切れません。ですが、多くの場合では、使用されているアプリケーショ ン環境に、提案事項のいくつか、またはすべてを実行すればレポート実行のパ フォーマンス（実際と見た目の両方）が改善されるでしょう。

方法論

Oracle9i Reportsをチューニングする際に重点的に取り組むべき分野を次に示しま す。 • レポートで時間がかかる箇所を調べます。一度この調査が完了すると、問 合せの評価、データベース最適化の見直し、およびレポートで使用してい る特定のコードに関する調査を行うために利用可能なパフォーマンス・ ツールが利用できます。 • レポート情報の書式設定およびレイアウトをチェックします。 • レポートのパフォーマンスおよび配布を最大にするための実行時パラ メータを設定します。 パフォーマンスのボトルネックを切り離し、データ・アクセスの最適化を図り、 フォーマット処理を効率化させ、実行時の効率を最大にするため、少しづつ変更 を加える必要があります。1 つの分野で行った変更が、別の分野のパフォーマン スに影響を与える可能性があります。

パフォーマンス解析ツール製品

レポートをチューニングする際に最初に行うのは、レポートの実行に要する時間 の大部分が費やされる部分を特定することです。データ・ソース内での実際のデー タの取出しやデータ取出し後の書式設定処理内、実行時のリソース待ちや配布待 ちのうちのどれが、レポートの実行時間の大部分を占めているかを判断してくだ さい。レポートには簡素化されチューニングされたレイアウト・モデルが用意さ れている場合がありますが、それらを適用しても効率の悪い SQL のためにデータ の取得に時間の大半を費やしている場合はパフォーマンスにほとんど関係ありま せん。

レポート・トレース

「レポート・トレース」オプションにより、レポート実行時に処理された一連のス テップを記述したテキスト・ファイルが生成されます。トレース・オプションは、 すべてのイベントを記録するか、またはイベントのサブセットのみを記録するよ うに（たとえば、SQL 実行ステップのみ、または実行時間のみ）、設定できます。 トレース・ファイルには、パフォーマンスのチューニングだけではなく、レポー トのデバッグにも役立つ様々な情報が入っています。 トレース機能は様々なレポート実行方法について設定できます。トレース機能の 対象となるのは、SQL データ・ソースまたは非 SQL データ・ソース（XML およ びテキスト・トランスポータブル・データ・ソースなど）が入っている rdf および jspレポート定義です。トレース機能を使用するためのレポート実行方法および構 文の詳細は、付録 A を参照してください。トレース・ファイルのサンプルは、付 録 B を参照してください。 トレース・ファイルを生成すると、データのフェッチに要した時間と、レポート の書式設定に要した時間を比較し割り出すことができます。これは、パフォーマ ンスのボトルネックを突き止めるのに役に立ちます。

トレース・ファイルを生成するコマンドラインの例を、次に示します。

rwrun module=emp.rdf userid=scott/tiger@orcl destype=file desformat=pdf desname=emp_pdf.pdf traceopts=trace_prf tracemode=trace_replace tracefile=emp_tr.txt

一度このコマンドラインが実行されると、トレース・ファイル emp_tr.txt が生成さ れ、これを調べることができます。

+---+ | Report Builder Profiler statistics | +---+

Total Elapsed Time: 8.00 seconds

Reports Time: 7.00 seconds (87.50% of TOTAL)

ORACLE Time: 1.00 seconds (12.50% of TOTAL)

UPI: 0.00 seconds

SQL: 1.00 seconds

TOTAL CPU Time used by process: N/A

プロファイラ統計情報には、レポートの実行時間（Total Elapsed Time: 実行 経過時間合計）、取り出されたデータの書式設定に要した時間（Reports Time: レポート時間）、およびデータが取り出されるまでの待機時間（ORACLE Time: ORACLE時間）が表示されます。SQL 問合せの場合、UPI はデータベース接続を 開設し、SQL を解析し実行するのに要した時間を表します。SQLは、データ・サー バーがデータをフェッチするのに要した時間（SRW.DO_SQL()文、EXEC_SQL 文、 PL/SQL Cursorsなどを実行するのに要した時間のパーセント）を表します。 この例では、データの問合せやフェッチではなく、データの書式設定（レイアウ ト作成）にほとんどの時間が費やされています。したがって、ここが、チューニ ング作業を集中的に行う必要のある部分です。 注意 注意注意 注意 データ・ソースが、テキストまたは XML トランスポータブル・データ・ソース などの非 SQL データ・ソースの場合は、ORACLE Time、UPI および SQL の値は ゼロになります。

効率的な Oracle9i SQL

Oracle9i Reportsでは、Structured Query Language（SQL）を使用してデータベース からデータを取り出します。特に大きいサイズのレポートでは、効率の悪い SQL によりパフォーマンスが損なわれることがあります。レポートのチューニング担 当者は、SQL の実用的な知識を十分持ち、データベースがこれらの文をどのよう

に実行するかを理解することが必須です。Oracle9i Reports には、SQL についての 経験が浅い方でも問合せが作成できるように手助けをするウィザードがあります。 ただし、これらのウィザードには、非効率的な SQL（使用可能な索引を使用しな い SQL など）が作成されないようにする機能はありません。 レポート内で SQL のチューニングを行う際に重要な役割を果たすのが、Oracle データベースに用意されている SQL トレース機能です。SQLトレースにより、デー タの解析、実行およびフェッチに要した時間と同様に、データデータベースに送 られた SQL 文を調べることができます。トレース・ファイルが生成されると、 TKPROFデータベース・ユーティリティを使用して EXPLAIN PLAN マップを生 成することができます。これは、Oracle Optimizer で使用される実行計画をグラフ で表示したものです。たとえば EXPLAIN PLAN では全表スキャンが行われた箇所 が表示されますが、表に索引を作成するよう促す場合があります（パフォーマン ス・ヒットによって異なります）。 SQL-TRACE という名前を持つレポート・レベルの計算式列を次に示すコードで 追加すると、Reports Builder で SQL トレースをオンにすることができます。

SRW.DO_SQL('ALTER SESSION SET SQL_TRACE=TRUE'); return(1);

注意 注意 注意

注意: SQL TRACE は、Before Report または Before Parameter Form トリガーから呼 び出すこともできます。 次の EXPLAIN PLAN マップは、データベースの SQL トレース機能を使用して生 成したものです。詳細は、『Oracle9i SQL Language』を参照してください。 例 例 例 例 次の文を実行します。

Select e.ename, d.dname From emp e, dept d

Where e.deptno (+) = d.deptno

生成される EXPLAIN PLAN は、次のとおりです。

OPERATION OPTIONS OBJECT_NAME POSITION

--- --- --- ---SELECT STATEMENT

MERGE JOIN OUTER 1

SORT JOIN 1

TABLE ACCESS FULL DEPT 1

SORT JOIN 2

TABLE ACCESS FULL EMP 1

Oracle9i Reportsのデータのチューニングでは、Oracle9i RDBMS には、コストベー スのオプティマイザとルールベースのオプティマイザの 2 つがあることを理解し

ておく必要があります。デフォルトでは、コストベースのオプティマイザはスルー プットにあわせて最適化する実行計画を作成します（最小限のリソースを使用し てアクセス対象の行をすべて処理します）。 オプティマイザの取り組み方法および目標を設定し、コストベースの最適化につ いての統計情報を収集することにより、オプティマイザの選択項目を操作できま す。コストベースのオプティマイザを使用すると、SQL のチューニングは大幅に 簡素化されますが、データの配布およびオプティマイザのルールを理解すること により、最適な方法が選択できるようになり、実行計画をコントロールする範囲 も広がります。たとえば、SQL 文の中に、最速の応答時間（アクセスする先頭行 の処理に、最小リソースを使用）を目的としたオプティマイザのヒントを指定し たり、または索引を使用しないという判断を下すことができます。 注意 注意注意 注意 特に長い問合せでは、次に示すどちらかを行う必要があります。 コストベースのオプティマイザをアクティブにし、DBMS_STATS パッケー ジ、COMPUTE STATISTICS オプションまたは ANALYZE コマンドを使用し て、統計情報を収集する。 または、ルールベースのオプティマイザについて規定されているルールに 従って、すべての SQL を最適化する。 データベース・オプティマイザ機能の詳細は、Oracle9i Server のドキュメントを参 照してください。

PL/SQL

レポートで使用する PL/SQL プログラム・ユニットのチューニングには、 ORA_PROFパッケージを使用します。ORA_PROF パッケージには、コードの実 行に要する時間が追跡できるプロシージャ、関数および例外が入っています。 例 例例 例

PROCEDURE timed_proc (test VARCHAR2) IS i PLS_INTEGER; BEGIN Ora_Prof.Create_Timer('loop2'); Ora_Prof.Start_Timer('loop2'); ColorBand_Program_Unit; Ora_Prof.Stop_Timer('loop2');

Text_IO.Putf('Loop executed in %s seconds.¥n', Ora_Prof.Elapsed_Time('loop2'));

Ora_Prof.Destroy_Timer('loop2'); END;

このプロシージャでは、タイマーの作成と起動、サブプログラムを実行、タイマー を停止、最後にサブプログラムの実行所要時間を表示します。処理が終了すると タイマーは消去されます。

ORA_PROFビルトイン機能の詳細は、Reports Builder のオンライン・ヘルプを参 照してください。 データベース操作のかなりの部分を行う PL/SQL プログラム・ユニットがストア ド・データベース・プロシージャとしてインプリメントされている場合は処理能 力が高いことを銘記してください。このストアド・プロシージャは、Oracle デー タベース上で実行されます。 これは、ストアド・プロシージャの方が、レポートのみを対象としたローカルの PL/SQL（レポート内で PL/SQL パーサーを使用してから、データベース内で SQL パーサーを使用し、ネットワーク・トリップも追加する PL/SQL）よりも、操作の 実行時間が短いことを意味しています。PL/SQL プログラム・ユニットにデータ ベース操作がなにも含まれていない場合は、逆のことが言えます。この場合は、 Object Navigatorでプログラム・ユニット・ノードを使用して、できるだけローカ ルに PL/SQL の記述を行う必要があります。また、外部の PL/SQL ライブラリにあ る PL/SQL を実行する場合に比べてパフォーマンス上のメリットがあります。 PL/SQLライブラリのパフォーマンスのオーバーヘッドが重要性を帯びるのは、 コードを共有する利点が使用できる場合のみです。 SRW.DO_SQL()はできるだけ使用しないようにしてください。理由としては、 SRW.DO_SQL()をコールするたびに、解析を行って新しいカーソルのオープンと コマンドとをバインドする必要があるからです（通常の問合せと同様）。しかし 問合せと違って、SRW.DO_SQL()のあるオブジェクトが起動されるたびに操作が 行われます。たとえば、計算式列内の PL/SQL のブロックが、SRW.DO_SQL()を 呼び出し、計算式が存在するデータ・モデル・グループが 100 個のレコードを返 すと、カーソルの解析、バインド、作成操作は 100 回発生します。したがって、 通常の SQL の中で実行することができない操作（たとえば、一時表の作成や他の DDLを実行する場合）で、できるだけ少ない回数で実行する箇所（たとえば、レ ポートあたり 1 回のみ起動されるトリガーなど）で SRW.DO_SQL()を使用するこ とをお薦めします。 SRW.DO_SQLは、主に一時表の作成や削除などの DDL 操作を実行するために使 用します。たとえば、Runtime Parameter Form から入力するパラメータにより名前 が決定される表を、SRW.DO_SQL に作成させることができます。

例 例 例 例

SRW.DO_SQL (`CREATE TABLE' || :tname ||

`(ACCOUNT NUMBER

NOT NULL PRIMARY KEY, COMP NUMBER (10,2))');

注意

注意

注意

注意

「WITH」やインライン・ビューなどの Oracle9i SQL 拡張機能を使用しても、同様 の結果が得られます。ただし、それぞれのニーズについて十分な結果が得られる かどうか調べる必要があります。

Java

ストアド・プロシージャ

ストアド・プロシージャを使用すると、サーバー・レベルでビジネス・ロジック を実装できるため、アプリケーションのパフォーマンス、スケーラビリティおよ びセキュリティが向上します。Oracle9i では、PL/SQL と Java ストアド・プロシー ジャのどちらもデータベースに格納できます。 一般に、プロシージャの拡張機能を使用したい SQL プログラマは PL/SQL を好み、 Oracleデータに直接アクセスしたい Java プログラマは Java を好みます。Java スト アド・プロシージャを使用すると、十分なフレキシビリティは得られますが、多 少のオーバーヘッドが伴います。個々のニーズに応じて、パフォーマンスとフレ キシビリティそれぞれのトレードオフのバランスを取る必要があります。

Javaストアド・プロシージャの詳細は、『Oracle9i Java ストアド・プロシージャ 開発者ガイド』を参照してください。

Java Importer

Oracle PL/SQLは、強力で生産性の高い開発環境ですが、外部のアプリケーショ ン・サービスやプロバイダの多くが Java 環境での統合を提供する傾向が強くなっ ているため、ときにはこうしたサービスやプロバイダとの統合を図る必要に迫ら れるかもしれません。

Oracle9i Reportsを Oracle Java Importer と統合させると、外部中間層の Java クラス に含まれているビジネス・ロジックの起動が容易になります。Java Importer は、 選択された各クラスに対して、宣言による PL/SQL ラッパー・パッケージの作成 を行い、クラスに指定されているメソッドを PL/SQL ファンクションおよびプロ シージャにより公開します。これにより、レポートを実行するときに Java オブジェ クト・インスタンスのインスタンス化、使用および破棄を行うことができます。 この強力な拡張機能により、Java コードを自分で記述する必要がなくなりますが、 幾分オーバーヘッドがあります。PL/SQL パッケージは、指定したクラスごとに個 別に作成されます。PL/SQL ジェネレータは、Java メソッドから PL/SQL パッケー ジを生成するときに、型変換を実行します。

Java Importerにより生成された PL/SQL パッケージ内の新しい関数によって、Java オブジェクトのインスタンスが作成されると、その結果は JOBJECT 型の変数に格 納されます。グローバル参照は削除しないと蓄積していき JVM のメモリー消費量 が増加するので、Java Object persistence は注意して処理する必要があります。

データへのアクセス

レポートの実行時間のほとんどが、データ・ソースからデータへのアクセスに費 やされていることがパフォーマンス測定ツールによって判明した場合は、データ の構造およびデータの使用方法を再確認することをお薦めします。スキーマが効 率的に設計されていないと、レポートのパフォーマンスに大きな影響を与えるこ

とになります。たとえば、データ・モデルを過度に正規化すると、排除可能な結 合または問合せが増える結果となります。

非 SQL データ・ソース

Oracle9i Reportsでは、組込可能な(Pluggable)、トランスポータブル・データ・ソー ス・アーキテクチャを使用してデータをデータ・ソースから公開することができ ます。標準の Oracle9i Reports は、XML、テキスト、JDBC トランスポータブル・ データ・ソースなどの非 SQL データ・ソースをサポートします。XML およびテ キスト・トランスポータブル・データ・ソースは、リモート URL 経由でアクセス できます（ファイアウォールをまたぐアクセスも可能です）。スピードが問題に なる場合、リモートの URL ではなくデータをローカルにダウンロードして、ロー カルのデータ・ストリームを使用してください。プロキシ・サーバーをバイパス させるドメインも指定できます。 XMLトランスポータブル・データ・ソースでは、実行時における XML データの 妥当性チェックがサポートされています。この機能は、XML Query ウィザードの 「データ・ソースの妥当性チェック」チェックボックスを選択することによりアク ティブにすることができます。データ・ソースの妥当性チェックを選択すると、 XMLデータがフェッチされるときに、DTD または XML スキーマで指定したデー タ定義と照合してこのデータの妥当性がチェックされます。これはコストのかか る操作ですが、レポートの作成時に役に立つことがあります。しかし、一度本番 で使用し XML データの妥当性を確認したら、妥当性チェックをアクティブにし ないことをお薦めします。特に XML データ・ストリームが大きい場合、顕著に パフォーマンスが違うでしょう。 データ定義では、オプションで XML スキーマか DTD のいずれかを指定できます。 XMLスキーマを使用すると、タイプ・チェックが強制実行されます。DTD の場 合は、すべてのデータが文字列として処理されるため、タイプ・チェックは不要 です。しかし、文字と文字列以外のデータ型に依存する場合、他の問合せとの結 合に影響する場合があることに注意してください。

XMLデータ・ストリームに対応する XSL（extensible style sheet language）ファイ ルを指定すると、このデータ・ストリームのフォーマットを単純な行セットまた は行データ・フィードに変換できます。 XSLを実行時に適用する必要が絶対にない限り、最初に正しいフォーマットで データを持つことをお薦めします。 テキスト・トランスポータブル・データ・ソースは、セル・ラッパーに対応しま す。セル・ラッパーを使用すると、ラッパーが定義されているフィールドごとに、 ファイル・フォーマット・レベルのデリミタが無視されます。この機能が実際に 必要な場合を除き、パフォーマンス上の理由によりセル・ラッパーは使用しない ことをお薦めします。 JDBCトランスポータブル・データ・ソースは、JDBC ブリッジのほかに Thin お よび Thick JDBC ドライバもサポートします。どのドライバを選択するかによって、 データのフェッチに直接の影響があります。どのドライバを選択するかは、使用 するアプリケーションおよびデータベースによって決まります。一般に、システ ム固有のドライバを使用した方が、パフォーマンスが向上します。

データベースの索引

一般的に、SQL WHERE 句が使用されている列では索引を設定する必要がありま す。 レポートの主問合せにおける列で使用している索引は、1 回のみデータベースを アクセスする問合せと同様に、それほど影響はないでしょう。ただし、大幅なパ フォーマンス向上を目指す場合は、ディテール問合せ内のリンクされた列に索引 を使用する必要があります。 適切な索引がない場合は、全表スキャンの回数が増え、パフォーマンスに大きい 影響を与える可能性があることに注意してください。

計算

サマリー列または計算式列を使用して、レポート内部で計算を行う場合は、デー タ・ソースにより実行できる計算が多ければ多いほど、良い結果が得られます。 SQL問合せの場合、レポートにより取り出されたすべてのデータが計算の対象に なるのではなく、データベースによって計算が行われます。データベースに格納 されたユーザー定義関数およびプロシージャも、Oracle9i または JDBC 問合せの クエリーの選択リスト内に入れることができます。計算されたデータがデータ ベースからの結果セットの一部として返されるため、（たとえば計算式列内で） ローカル関数を使用するよりも、この方法の方が効率的です。 例 例 例 例 次の PL/SQL 関数は Oracle9i データベースに格納することができます。

CREATE OR REPLACE FUNCTION CityState (

p_location_id world_cities.location_id%TYPE) RETURN VARCHAR2 is

v_result VARCHAR2(100); BEGIN

SELECT city || ','||state INTO v_result

FROM world_cities

WHERE location_id = p_location_id; RETURN v_result;

END CityState;

この関数はカンマおよびスペースで区切られた市と州の名称を返します。この書 式設定は、データベース・レベルで行われ、レポートに戻され表示されます。

レポート内で定義する SQL 問合せの例を次に示します。

Select location_id, citystate(location_id)"City & State" from world_cities

LOCATION_ID CITY & STATE

--- ---1 Redwood Shores, California 2 Seattle, Washington

3 Los Angeles, California 4 New York, New York

冗長なデータ

レポートでは冗長な問合せ（レポートに必要ないデータを返す問合せ）を使用せ ず、また問合せではまったく必要のない列は選択しないでください。これらはす べて、パフォーマンスに影響します。一般的に、問合せが少ないほど、レポート の実行速度は早くなります。複数の問合せを含むデータ・モデルよりも、問合せ が 1 つのデータ・モデルの方が実行速度は早くなります。 ただし、レポートではユーザーごとに異なった書式にする必要がある状況だけで なく、異なった問合せ文の使用が必要になる状況が発生する場合があります。こ うした状況は、2 つの異なるレポートを作成することで対処できますが、レポー トは 1 つにする方がメンテナンスが容易になります。この場合は、 SRW.SET_MAXROW()プロシージャを使用して冗長な問合せを無効化する必要が あります。 例 例 例 例 次に示すのは、ユーザー・パラメータに応じて Query_Emp または Query_Dept の いずれかを無効化する Before Report トリガーのコードです。

IF :Parameter_1 = 'A' then

SRW.SET_MAXROW('Query_Emp',0); ELSE SRW.SET_MAX_ROW('Query_Dept',0); END IF; 注意 注意注意 注意 SRW.SET_MAXROW()を使用する意味がある場所は、Before Report トリガーの内 部のみです（問合せの解析が終了した後）。この時点より後で、 SRW.SET_MAXROW()を呼び出すと、SRW.MAXROW_UNSET パッケージ例外が 発生します。 問合せの解析および結合は行われますが、レポートにはデータは返されません。 XMLまたはテキスト・トランスポータブル・データ・ソースに基づく問合せを定 義する場合は、問合せに使用するフィールドを選択できます（すべてのフィール ドを使用可能にするか、またはサブセットを使用）。データ・ソースから使用で

きるフィールドのサブセットを使用する必要がある場合は、問合せレベルで使用 することをお薦めします。その場合は、すべての値をフェッチした後、グループ・ フィルタまたはレイアウト・レベルのフォーマット・トリガーを使用してこれら の値をフィルタ処理するのではなく、パラメータを使用します。

ブレーク・グループ

ブレーク・グループ数を制限すると、レポートのパフォーマンスが向上します。 ブレーク順序プロパティ（最下位の子グループは除く）が設定されているデータ・ モデル内の各列について、Oracle9i Reports はブレーク・レベルを設定し、Oracle9i SQL問合せの場合は、問合せ内の ORDER BY 句の追加列として付加します。 ORDER BY句内の列が少ないほど、指定された順序でデータを返す前にデータ ベースが実行する必要のある作業が減少します。ブレーク・グループを作成する と、問合せの中に定義された ORDER BY 句が冗長になる場合があります。この場 合はデータベースで余分な処理をしなければならないため、この冗長な ORDER BY句を削除する必要があります。 レポートでブレーク・グループを使用する必要がある場合は、ブレーク順序プロ パティを設定するブレーク・グループ内の列数はできるだけ少なくしてください。 ブレーク順序列は、Reports Builder のデータ・モデル・ビューにあるグループ内の 列名の左側にある小さい矢印で示されます。問合せの最下位の子グループより上 にある各ブレーク・グループに、ブレーク順序プロパティを設定するには、それ ぞれのブレーク・グループ内に列を少なくとも 1 つ持たせる必要があります。ソー トが不要な列からブレーク順序を削除しても、パフォーマンスは向上します。 ブレーク・グループを設定するのは 1 つの列のみに制限するようにしてください。 こうした列は、できるだけ少なくしてください。また、サマリー列や計算式列で はなく、できるだけデータベース列にする必要があります。これらの条件のどち らも、最大の効率を得るためにデータの書式設定を行う前に、Oracle9i Reports で ローカルにキャッシュすることができます。常にこれらの条件が満たされるわけ ではありませんが、活用すると効率が改善されます。

グループ・フィルタ

グループ・フィルタの主な使用目的は、データ・ソースから取り出すレコード数 を減らすことです。グループ・フィルタを使用する場合も、問合せはデータ・ソー スに渡され、その時点でフィルタが行われるレポートにすべてのデータが返され ます。上位 5 つのレコードのみを表示するようにフィルタを定義しても、レポー トに返される結果セットには、問合せにより返されるすべてのレコードが入って います。 そのため、可能なかぎり問合せの WHERE 句または問合せプロパティの最大行に、 グループ・フィルタの機能を取り込む方が、効率的です。これにより、データベー スより返されるデータが制限されます。

リンクの作成の是非

複数の表を含むデータ・モデルを作成する方法はいろいろあります。社内の各部 門のすべての従業員をリストするレポートを作成するために、dept と emp を結合

させる標準的な事例を考えます。

この場合、次の単一問合せを使用するか、

Select d.dname, e.ename From emp e, dept d

Where e.deptno(+) = d.deptno

または、2 つの問合せを作成し、deptno 列についてのこれらの問合せ間に列のリ ンクを作成します。

Select deptno, dname from dept Select deptno, ename from emp

レポートのデータ・モデルを設計する場合は、単純な（単一表）問合せをいくつ か使用するよりも、少ない数のサイズの大きい（複数表）問合せを使用して、実 際の問合せ数を最小限に抑えることをお薦めします。問合せが発行されるたびに、 Oracle9i Reportsはカーソルを解析し結合してから実行する必要があります。これ により、単一問合せのレポートは、必要なすべてのデータを多数のカーソルでは なく、1 つのカーソルにまとめて返すことができます。 マスター・ディテール問合せの場合、ディテール問合せは取り出されたマスター・ レコードごとに解析され、結合されてから実行されることにも注意してください。 この場合は、2 つの問合せをマージし、ブレーク・グループを使用して、マスター・ ディテール効果を生み出す方がより効率的です。 問合せのサイズが大きくなり、複雑化すると、メンテナンスが難しくなる点に留 意してください。各サイトでは、どこでパフォーマンスとメンテナンスの要件を バランスさせるかを決める必要があります。

データのフォーマット

データ・ソースからデータを取り出した後、Oracle9i Reports はレポート・レイア ウトを生成し、出力をフォーマットする必要があります。「ペーパー・レイアウ ト」の場合は、レイアウトに要する時間は要因数によって決まります。しかし、 結局は別のオブジェクトによって上書きされないようにするために必要となる作 業の量や、フォーマット・トリガーで実行する計算または関数の効率によって決 まることになります。Oracle9i Reports では Web ページが所有されずレンダリン グ・メカニズムが制御されないので、「Web レイアウト」ではルールが幾分異な りますが、単にデータを通常の JSP に'注入'するにすぎません。

ペーパー・レイアウト

デフォルトのペーパー・レイアウトを生成する場合、Oracle9i Reports はほとんど すべてのオブジェクトをフレームで囲みます。そのため、レポート実行時にオブ ジェクトが上書きされることはありません。実行時には、オブジェクトが上書き される可能性を調べるために、すべてのレイアウト・オブジェクト（フレーム、 フィールド、定型挿入文など）がチェックされます。ある状況（たとえば、ボイ ラープレート・テキスト列ヘッダーなど）では、オブジェクトが上書きされる危

険性は明らかにないので、即座に周囲にあるフレームを削除することができます。 これにより、Oracle9i Reports がフォーマットする必要のあるオブジェクト数が減 り、結果的にパフォーマンスが向上します。 同様に、未定義サイズ（可変で、水平または垂直に拡大または縮小）を使用して オブジェクトを定義すると、特別な処理が必要になります。これは、Oracle9i Reportsがオブジェクト・サイズのインスタンスを判断して、そのオブジェクトと それを取り囲むオブジェクトをフォーマットする必要があるためです。サイズ指 定の場合は、オブジェクトのサイズとオブジェクト間の位置関係がすでにわかっ ています。そのため、サイズ指定が固定できる場合、この追加処理は不要になり ます。 ペーパー・レイアウト作成時にパフォーマンスを向上させるためのガイドライン を次に示します。 • 非グラフィカル・レイアウト・オブジェクト（ボイラープレート・テキス トや、テキストのあるフィールドなど）をサイズ固定モードにします。つ まり、フィールドの「垂直に拡大」および「水平に拡大」プロパティを「固 定」に設定します。特に、反復フレームおよびそのコンテキストのサイズ を固定すると、パフォーマンスが向上します。可変サイズの非グラフィカ ル・オブジェクトの場合、Reports Builder はそのサイズを判断して後、 フォーマットする必要があるため追加処理が発生します。固定サイズの非 グラフィカル・オブジェクトは、サイズがすでに既知であるため、この追 加処理は発生しません。 • グラフィカル・レイアウト・オブジェクト（イメージやグラフなど）の場 合は、オブジェクトの「垂直に拡大」および「水平に拡大」プロパティを 「可変」に設定して、可変サイズ・モードにします。通常、固定サイズの グラフィカル・オブジェクトは、その内容をスケーリングして、オブジェ クト内部に収める必要があります。オブジェクトの内容のスケーリングで は、追加処理が発生します。可変サイズのオブジェクトは、内容の拡大ま たは縮小を行うため、スケーリングは不要です。 • テキストが含まれているフィールドは、1 行の長さに固定し、その内容が 指定された長さに収まるようにします（SUBSTR 関数を使用）。テキスト のあるフィールドが複数行にわたる場合、Reports Builder はワード・ラッ プ・アルゴリズムを使用してフィールドの書式設定をする必要があります。 書式設定するフィールドの長さを 1 行のみにすることにより、ワード・ラッ プ・アルゴリズムで追加処理が発生しません。 • 同一フィールドまたはボイラープレート・テキスト内で使用するフォー マット属性の種類（フォントなど）をできるだけ少なくします。フィール ドまたはボイラープレート・オブジェクト内のテキストに、様々な種類の フォーマット属性が含まれていると、書式設定に要する時間が長くなりま す。 • Report Builderレイアウトでフィールドの文字列を切捨てるのではなく、 レポート問合せで SUBSTR 関数を使用してデータベース・レベルでデー タを切捨てることをお薦めします。

レポートにペーパー・レイアウトのみ含まれている場合、.RDF および.REP ファ イルの実行速度は.JSP ファイルよりも速くなることに留意してください。これ は、.RDF または.REP ファイルがタグ付きフォーマットではなくシリアル化ファ イルで、解析を必要としないためです。また、.REP はプラットフォームに対応し てコンパイルされるため、.RDF ファイルよりも実行速度が早くなります。

ペーパー・レイアウトでのフォーマット・トリガー

フォーマット・トリガーは、実行時にオブジェクトを動的に有効化および無効化 し、実行時にオブジェクトの外観を動的に変更する機能を持っています。フォー マット・トリガーは慎重に使用してください。フォーマット・トリガーは、関連 するオブジェクトのインスタンスが生成されるごとに起動するほか、実行時にオ ブジェクトの書式設定が行われるごとに起動します。 この 2 つのシナリオは同じように思えるかもしれませんが、次の状況を考えてみ てください。 垂直に拡大できる反復フレームが 1 つあり、「ページ・プロテクト」プロパティ が「オン」に設定されている表形式のレポートがあります。このレポートの書式 設定を行ったところ、最初のページの最下部に 1 行分の余白が発生しました。 Oracle9i Reportsは、反復フレームの次のインスタンスをフォーマットし、そのイ ンスタンスと関連するフォーマット・トリガーを起動します。その結果、反復フ レーム内部のオブジェクトの 1 つが拡張されたため、反復フレームのこのインス タンスは次のページに移動されます。反復フレーム用のフォーマット・トリガー が再び起動されます。 反復フレームは次のページの先頭に 1 回表示されるだけですが、フォーマット・ トリガーは 2 回起動されました。特定のオブジェクトに対してフォーマット・ト リガーが何回起動されるかはわからないため、フォーマット・トリガーでは DML を実行しないように注意してください。上述の例では、フォーマット・トリガー に INSERT 文があると仮定した場合、データが 2 行挿入されます。 トリガーの起動回数をできるだけ少なくするために、フォーマット・トリガーは、 オブジェクトおよびフレーム階層内のできるだけ上位のレベルに置く必要があり ます。 たとえば、次のようにします。

Oracle9i Reports内部で任意のトリガーまたは PL/SQL プログラム・ユニットを定 義する場合は、コードの効率を最大にする必要があります。たとえば、フィール ドの表示属性を動的に変更する場合（たとえば、正常値でない値であることを注 意させたい場合）、その属性は SRW.SET_TEXT_COLOR などの個々のビルトイン 機能を使用して変更する必要があります。一般的な PL/SQL のチューニングにつ いては、『PL/SQL ユーザーズ・ガイドおよびリファレンス』を参照してください。 レイアウト・オブジェクト（フレーム、反復フレームなど）に透過型の境界線と 塗りつぶしパターンを指定すると、パフォーマンスも向上します。透過オブジェ クトはビットマップ・ファイルにレンダリングする必要はありません。そのため、 オブジェクトが透過的な場合、処理速度が早くなります。

Web

レイアウトおよび JSP レポート定義

Oracle9i Reportsでは、JavaServer Pages（JSP）テクノロジを十分活用した高品質な Webパブリッシングが実現します。好みの Web オーサリング・ツールを使用して Webページの静的な部分を設計してから、Oracle9i Reports を使用してページの適 切なセクションに動的な部分（データ）を配置することができます。Web ページ の設計が悪いと目に見えてパフォーマンスに影響することは言うまでもありませ ん。もう 1 つの方法として、Oracle9i Reports に付属している Web テンプレートを 使用して Web ページを作成する方法もあります。 Javaコードを JSP に含めることが可能なので、ビジネスとデータ・アクセスの Java コードをプレゼンテーション・ロジックと混在させることが簡単になり夢中にな ります。 これによって JSP のフットプリントが増加し、システム・リソースの効率的な使 用と管理が制限されるので、避けるようにしてください。 Webページの書式設定をカスタマイズする操作は、通常コストが高くつきます。 Oracle9i Reportsでは実現しないタイプの書式設定（データ・ブロックの背景色の

変更など）は、Java を使用して直接的な方法で実行してください。書式設定に PL/SQLラッパーを使用することはお薦めできません。 .JSPレポート定義には、ペーパー・レイアウトと Web レイアウト定義の両方を含 めることができます。JSP レポートの Web レイアウト・セクションにはペーパー・ レイアウト・オブジェクトを参照する<rw:include>タグを含めることができるので、 Oracle9i Reportsではレポートを実行するときには必ずペーパー・レイアウトの書 式設定が行われます。JSP レポートでペーパー・レイアウト・オブジェクトをまっ たく参照しない場合、SUPPRESLAYOUT コマンドライン・オプションを使用して ペーパー・レイアウトの実行を抑止することをお薦めします。 JSPテクノロジのパフォーマンスに関するヒントの詳細は、Oracle Technology Network (http://technet.oracle.com英語サイト）または Oracle Technology Network （http://otn.oracle.co.jp/ 日本語サイト）に掲載されている『Oracle9iAS のパフォー マンスと拡張性についてのベスト・プラクティス』ホワイト・ペーパーを参照し てください。

レイアウトについての一般的なガイドライン

先読みフェッチ

Oracle9i Reportsでは、ページ合計数やレポートのマージンで表された総数などの データを表示したり、レポート・ヘッダー・ページのデータを表示できます。こ れは非常に便利な機能ですが、レポート全体の「先読みフェッチ」を強制実行し ます。 つまり、最初のページが出力される前に、レポート全体が処理されます。通常の モデルの場合は、必要に応じてページをフォーマットします。先読みフェッチ機 能を使用しても、レポート生成に要する合計時間に影響は与えませんが、必要な 一時記憶域の容量と最初のページが表示されるまでに要する時間に影響を与えま す。これは見た目のパフォーマンスと実際のパフォーマンスとが異なる例です。 本番環境で、レポートを実行して画面に表示する場合は、パフォーマンスが許容 範囲内にあると思われる場合を除き、先読みフェッチ機能は使用しないようにし てください。

バースティングおよび配布

レポート・バースティング機能を導入すると、レポート・レイアウトをヘッダー、 ボディ、トレーラの 3 つのセクションに構成できます。1 つのレポートを、これ ら 3 つのセクションで構成するか、または 1 つのレポート内に 3 つの個別レポー トが入っているように表示してもかまいません。Oracle9i Reports では、グループ・ レコード・レベルでバースティングが制御でき、さらに細分化されたレベルでレ ポートのバースティングが行えます。この機能は、各個別セクションの「配布」 および「繰返しオン」プロパティにより実現します。バースティングと配布を同 時に使用するときに、パフォーマンスの向上が明らかになります。このように使 用することにより、レポートの各セクションに複数の異なるフォーマットを持た せ、複数の宛先に送ることができます。配布オプションを設定した後は、問合せ を 1 回実行するレポートを 1 回実行するだけで、複数の宛先にレポートが出力さ

れます（これまでは、レポートを何回も実行する必要がありました）。

Oracle9i Forms

からのレポートの呼出し

Forms Builderおよび Reports Builder で構築されたアプリケーションでは、アプリ ケーションの Oracle9i Forms セクションによってすでに取り出されたか、または 更新されたデータに関するなんらかのレポートが必要になる場合があります。 Oracle9i Formsと Oracle9i Reports のコンポーネント間は密接に統合されているた め、関連する製品間でのデータ・ブロックの受渡しができます。 これにより、後続の問合せを実行する必要がなくなります。この方法は、「問合 せのパーティション化」と呼ばれています。つまり、Oracle9i Reports は、問合せ は処理せず、データの書式設定のみ処理し、その結果、トリガーおよび字句パラ メータによる問合せの動的変更は無視されることになります。Oracle9i Forms と Reports間でのデータの受渡しは、フォームからレポートを呼び出するための Run_Report_Objectビルトイン機能とともに、レコード・グループとデータ・パラ メータを使用することで実現します。フォームからレポートを呼び出す方法とし てサポートされるのは、唯一この方法のみであることに注意してください。 Oracle9i Formsアプリケーションから行うレポートの呼出しの詳細は、Oracle Technology Network (http://technet.oracle.com英語サイト）の『Oracle9i Forms Server Report Integration』ホワイト・ペーパーを参照してください。 注意 注意 注意 注意 これらのデータ・パラメータのサイズがかなり大きいか、または非常に複雑化し た問合せでないかぎり、見た目のパフォーマンスはそれほど改善されません。ま た、レポートで最上位のレベルにあるグループのみフォームから渡されたデー タ・パラメータを受け取ることができることも注意する必要があります。

レポートの実行

効率的なレポートを設計した後は、特定のランタイム引数を設定することにより、 全体のパフォーマンスをさらに向上させることができます。 デフォルトでは、Reports Builder はペーパー・レイアウトおよびバインド変数につ いてのエラー・チェックを自動的に行いますが、ランタイム・パラメータ RUNDEBUGを NO に設定すると、実行時にこの特別なエラー・チェックが無効 になります。JSPレポート定義についても同様に、デフォルトにより Reports Builder はタグの妥当性チェックおよび重複するフィールド指定または属性の設定不良な どのチェックを行います。設計段階では、この機能は非常に便利ですが、本番環 境でレポートを実行する際にはあまり便利ではありません。Reports Services では、 タグの妥当性チェックはデフォルトにより無効になっています。この機能を有効 にする必要がある場合は、http リクエストで VALIDATTAG オプションを YES に 指定して使用するとこの機能を有効にできます。

ドライン・オプションが使用できます。デフォルトにより、このオプションは YES に設定されます。その結果、PL/SQL プログラム・ユニットの無効な外部参照は再 コンパイルされます。これは開発環境で役に立つ機能ですが、本番環境では無効 に切り替えてください。

Oracle9i SQL問合せでは、Oracle9i Reports は Oracle データベースの配列処理機能 を活用してデータをフェッチすることができます。これにより、データベースか らレコードを 1 つずつ取り出さずに、一括して取り出せるようになります。その 結果、データベースの呼出し回数が大幅に減少します。配列処理のマイナス面は、 返されたレコードの配列を格納するのに、実行プラットフォームで必要になるメ モリー領域が増える点です。ネットワークにかかる負荷が本番環境で大きなボト ルネックになる場合は、ARRAYSIZE コマンドライン・パラメータ（キロバイト で定義）にできるだけ大きい値（本番環境で可能な最大値）を設定すると、レポー ト用のデータをフェッチするために行うネットワーク・トリップの回数を減らせ ます。 同様に、レポートが LONG、CLOB または BLOB のいずれかのデータ型を使用し て大量のデータを取り出す場合は、LONGCHUNK パラメータにできるだけ大きい 値を設定すると、Oracle9i Reports が長い値を取り出す場合に必要な増分回数が減 らせます。Oracle8i または Oracle9i Server を使用する場合は、LONG または LONG RAWではなく CLOB または BLOB のいずれかのデータ型を使用する方が効率的 です。

ペーパー・レイアウトのパラメータ・フォームが不要な場合は、PARAMFORM 引 数を NO に設定すると、このパラメータ・フォームは読み飛ばされます。

PostScriptで出力する場合は、慎重に COPIES パラメータを使用してください。 PostScriptレポートの場合、COPIES に 1 以上の値を設定すると、Oracle9i Reports はページを照合するため、これらのページを一時記憶域に保存しなければなりま せん。その結果、使用する一時ディスク領域が大幅に増え、追加ファイルの書込 みによるオーバーヘッドによってパフォーマンスが低下します。

結論

Oracle9i Reportsモジュールを開発する際は、レポートのみを単独で検討するので はなく、次の事項に照らして検討する必要があります。 • アプリケーション要件 • 基盤となるデータ・モデルの正確性 • レポートが実行される環境（クライアント/サーバー、Web、ネットワー クとの関係など） • 必要になるユーザーとの対話レベル これらの関連事項を特定した後に行うチューニングでは、データ・ソースへの呼 出しの最適化および最小化、不要なレイアウトのフォーマット処理の最小化に照 準を合わせる必要があります。Reports Server で追加のチューニングを行うことも できます。 このホワイト・ペーパーで紹介した提案事項は、一般的なものであるため、あら

ゆる状況に当てはまるわけではないことに注意してください。ですが、多くの場 合、使用しているアプリケーション環境に紹介してきたテクニックの一部または すべてを実施することにより、レポート実行のパフォーマンス（実際のパフォー マンスおよび目に見えて判断されるパフォーマンスの両方）が改善するでしょう。

付録 A

レポート・トレース・ファイルの生成

トレースをチューニングする手順は、次のとおりです。

• Reports Builderで、「プログラム」→「トレース」を選択します。Builder 全体のセッションについての情報が、トレース・ファイルに記録されます。 • rwbuilder.conf構成ファイルで、次のように指定します。

<trace traceFile="trace_file_name" traceOpts="trace_all"

traceMode="trace_replace"/> トレース・ファイルの位置は、レポート・ロ グ・ディレクトリ（<ORACLE_HOME>/reports/log）に対する相対位置か、または 絶対位置（フル・パス名が指定されている場合）です。トレース・ファイルを指 定しない場合は、デフォルトのトレース・ファイル名として <hostname>-rwbuilder.trcが使用されます。 • コマンドラインの実行可能ファイル RWBUILDER および RWRUN で、 tracefile=trace_file_name traceopts=trace_all tracemode=trace_replaceのように指定します。トレース・ファイル の位置は、現在作業中のディレクトリに対する相対位置か、または絶対位 置（フル・パス名が指定されている場合）です。 コマンドラインのトレース引数は、rwbuilder.conf ファイル内に指定された 引数より優先されます。 • 実行可能ファイル RWSERVER の場合、トレース・オプションは <servername.conf>ファイルから指定できます。トレース・ファイルは、サー バーおよびエンジンについて個別に生成されます。次に例を示します。

<trace traceFile="trace_file_name" traceOpts="trace_all" traceMode="trace_replace"/> トレース・ファイルの位置は、サーバー・ログ・ディレクトリ （<ORACLE_HOME>/reports/log）に対する相対位置です。トレース・ファイル名を 指定しない場合は、デフォルトのサーバー・トレース・ファイル名として <serverName.trc>、デフォルトのエンジン・トレース・ファイル名として <severName>-<engineName>-<engineNo>.trcが使用されます。 • RWSERVLETの場合、トレース・オプションは rwservlet.properties 構成ファ イルから設定できます。次に示すように、オプションごとに改行します。 TRACEOPTS=TRACE_ALL TRACEFILE=rwservlet.trc TRACEMODE=TRACE_REPLACE

TRACEFILE、TRACEMODE および TRACEOPTS

TRACEFILE=<tracefile> tracefileには、トレース情報が記録される任意のファイル名を指定します。

TRACEMODE=<TRACE_APPEND | TRACE_REPLACE>

TRACE_APPENDによりトレース・ファイルの内容が上書きされます。

TRACEOPTS=<TRACE_APP | TRACE_BRK | TRACE_DBG | TRACE_DST | TRACE ERR | TRACE INF | TRACE LOG TRACE_PLS | TRACE_PRF | TRACE_SQL | TRACE_STA | TRACE_TMS | TRACE_WRN | TRACE_ALL>

TRACE_ERR - エラー・メッセージと警告を示します。 TRACE_PRF - パフォーマンス統計を示します。 TRACE_APP - すべてのレポート・オブジェクトに関する情報を記録しま す。 TRACE_PLS - すべての PL/SQL オブジェクトに関する情報を記録します。 TRACE_SQL - すべての SQL に関する情報を記録します。 TRACE_TMS - ファイル内のエントリごとにタイムスタンプを記録しま す。 TRACE_DST - 配布リストを示します。この属性は、どのセクションがど の宛先に送信されたかを判断するのに便利です。 TRACE_ALL - すべての情報を記録します。（デフォルト） コマンドラインでは、オプションを組み合せて使用できます。たとえば、 TRACEOPTS=(TRACE_APP, TRACE_PRF)のように指定すると、すべてのレポー ト・オブジェクトおよびパフォーマンス統計に関する情報が、ログ・ファイルに 格納されます。

付録 B

サンプル・レポートのトレース・ファイルのセクション

これは、traceopts=all を指定して取得した 14 行の emp 表に対して前述したレポー トのグループで生成した、サンプルのトレース・ファイルです。このレポートの 最初のページのみ示してあります。 LOG : Report: MODULE2 Logged onto server: Username: scott

16:15:59 APP ( Frame 16:15:59 APP . ( Text Boilerplate B_OR$BODY_SECTION

16:15:59 APP . ) Text Boilerplate B_OR$BODY_SECTION 16:15:59 APP . ( Generic Graphical Object B_1_SEC2 16:15:59 APP . ) Generic Graphical Object B_1_SEC2 16:15:59 APP . ( Text Boilerplate B_DATE1_SEC2 16:15:59 APP . ) Text Boilerplate B_DATE1_SEC2 16:15:59 APP . ( Text Boilerplate B_PAGENUM1_SEC2 16:15:59 APP . ) Text Boilerplate B_PAGENUM1_SEC2 16:15:59 APP . ( Text Field F_DATE1_SEC2

16:15:59 APP .. ( Database Column Name unknown 16:15:59 APP .. ) Database Column Name unknown 16:15:59 APP . ) Text Field F_DATE1_SEC2 16:15:59 APP ) Frame

16:15:59 APP ( Frame

16:15:59 APP . ( Frame M_G_DNAME_GRPFR 16:15:59 APP .. ( Repeating Frame

R_G_DNAME

16:15:59 APP ... ( Group G_dname Local Break: 0 Global Break: 0 16:15:59 APP .... ( Query Q_1

16:15:59 SQL EXECUTE QUERY : select d.dname, e.ename from emp e, dept d where e.deptno(+)=d.deptno

16:15:59 APP .... ) Query Q_1 16:15:59 APP ... ) Group G_dname 16:15:59 APP ... ( Text Field F_ENAME 16:15:59 APP .... ( Database Column ename 16:15:59 APP .... ) Database Column ename 16:15:59 APP ... ) Text Field F_ENAME 16:15:59 APP ... ( Text Field F_DNAME 16:15:59 APP .... ( Database Column dname 16:15:59 APP .... ) Database Column dname 16:15:59 APP ... ) Text Field F_DNAME

16:15:59 APP ... ( Group G_dname Local Break: 1 Global Break: 1 16:15:59 APP ... ) Group G_dname

16:15:59 APP ... ( Text Field F_ENAME 16:15:59 APP .... ( Database Column ename 16:15:59 APP .... ) Database Column ename 16:15:59 APP ... ) Text Field F_ENAME

+---+ | Report Builder Profiler statistics | +---+

Total Elapsed Time: 8.00 seconds

Reports Time: 7.00 seconds (87.50% of TOTAL)

ORACLE Time: 1.00 seconds (12.50% of TOTAL)

UPI: 0.00 seconds SQL: 1.00 seconds

Oracle9i Reportsのチューニング 2002年 5 月 著者: Christian Bauwens 共同執筆者: Barry Hiern Danny Richardson James Safcik

Oracle Corporation発行の「Tuning Oracle9i Reports」の翻訳版です。

この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。 万一、誤植などにお気づきの場合は、オラクル社までお知らせください。オラクル社は本書の内容に関していかなる保証もしません。また、本書の内容に 関連したいかなる損害についても責任を負いかねます。 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 オラクル社は、インターネット上での活動を強化するソフトウェアを提供します。 Oracleはオラクル社の登録商標です。 このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。 その他のすべての製品名およびサービス名は、各社の商標です。

Copyright © 2002 Oracle Corporation All rights reserved.