Oracle Application Server 10g (9.0.4): Manually Managed Cluster

(1)

Oracle Application Server 10g（9.0.4）: ク

ラスタの手動管理

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

(2)

Oracle Application Server 10g（9.0.4）:

クラスタの手動管理

Oracle Application Server クラスタ化の概要... 3

対象ユーザー... 3

Oracle Application Server クラスタ化フレームワーク ... 3

用語 ... 3

クラスタ化フレームワーク ... 4

Oracle Application Server クラスタの種類 ... 6

手動管理 Oracle Application Server クラスタの構成... 6

手動管理クラスタは本当に必要か... 7

1. データベースの要件 ... 7

2. 階層化配置... 7

手動管理クラスタの構成手順... 9

1. OracleAS インスタンスの全体的な関連付け ... 10

2. OC4J インスタンスの構成... 11

3. クラスタ用に J2EE アプリケーションを構成... 13

4. フェイルオーバーとロード・バランシング用に OHS を構成14

まとめ ... 16

(3)

Oracle Application Server 10g（9.0.4）:

クラスタの手動管理

Oracle Application Server クラスタ化の概要

Oracle Application Server 10g は、分散トポロジに展開可能な多数のコンポーネントから構成されます。Oracle Application Server に高い可用性を提供する基盤パラダイムは、クラスタ化です。クラスタ化は、各種の Oracle Application Server コンポーネントを特定な配置で結合してスケーラブルで統一された機能を提供し、さらに個々のコンポーネントのいずれかに障害が発生した場合には冗長性を提供します。

システムのコンポーネントをクラスタ化すると、クライアントの観点からコンポーネントを機能的に 1 つのエンティティとして見ることができます。数種のクラスタが Oracle Application Server コンポーネントと共存できます。このホワイト・ペーパーでは、手動管理 OracleAS Cluster の作成および構成手順を説明します。

対象ユーザー

このホワイト・ペーパーでは、様々な実装シナリオに応じて構成ファイルを実際に修正する技術者またはサポート・アナリストが対象です。マネージャおよびア ーキテクト向けのハイレベル・ビューは、Oracle Application Server 10g: 高可用性ガイドを参照してください。

Oracle Application Server クラスタ化フレームワーク

用語

Oracle Application Server クラスタ化フレームワークの検討前に、用語を定義します。

• Oracle Application Server ファーム: Oracle Application Server ファームは、 同じアプリケーション・サーバー・インフラストラクチャを共有、または File-Based Repository（FBR）として、同じアプリケーションサーバー・インスタンスを使用するアプリケーション・サーバー・インスタンスの集合です。

• Oracle Application Server インスタンス: Oracle Application Server インス タンスは、アプリケーション・サーバーのインストールにより構成されるコンポーネント群（Oracle ホーム）の実行に必要な一連のプロセスです。 • コンポーネント・インスタンス: コンポーネント・インスタンスは、1 つ

の Oracle HTTP Server プロセスまたは複数の Oracle Application Server Containers for J2EE（OC4J）インスタンスを含みます。

(4)

• Oracle Application Server クラスタ: Oracle Application Server クラスタ （OracleAS クラスタ）は、同一の構成およびアプリケーション配置を持つ

アプリケーション・サーバー・インスタンスの集合です。

• OC4J アイランド: Oracle Application Server Containers for J2EE（OC4J）ア イランドは OC4J プロセスのグループで、アイランドの一部である各 OC4J プロセス間で、ステートフルな Web アプリケーションのセッションステートをレプリケートします。アイランド内の OC4J プロセスは、複数のノード上に存在することも可能です。

関連項目: Oracle Application Server 10g 概要

図 1: OracleAS クラスタ・アーキテクチャ

クラスタ化フレームワーク

クラスタ化フレームワークを構成する各種のコンポーネントは次のとおりです。 • Oracle Process Manager and Notification Server（OPMN）は、監視対象の プロセスに問題が検出された場合に、プロセス停止を検出しプロセスを再起動し、異なるプロセス間のチャネル通知を提供します。

(5)

• Distributed Configuration Management（DCM）は、構成情報をクラスタ 内のコンポーネントに伝播し、リポジトリに保存します。 OPMN は、プロセス監視（つまりフォルト・トレランス）を提供し、DCM とリポジトリは構成クローニング（つまり分散配置）を提供します。mod_oc4j はスマート・ルーティング（つまりロード・バランシング）を提供します。

• DCM Metadata Repository は、管理サービスを提供する OracleAS メタデ ータ・リポジトリの必要不可欠な部分です。これは、OracleAS インスタンス、OracleAS クラスタ、および OracleAS ファーム全体の完全な構成情報を保存します。DCM リポジトリは、OracleAS 中間層のインストール・オプションによって、file-based または database-based のどちらかを選択可能です。

• Oracle HTTP Server（OHS）のプラグインである mod_oc4j は、AJP を使用 するすべての OC4J インスタンスへのリクエストに対し、構成可能でインテリジェントなルーティングを提供します。リクエストは、OPMN との通信を介して mod_oc4J がアライブ（活動状態）だと判断したプロセスやコンポーネントにのみルーティングされます。図 2 は、前述の機能も含め、OracleAS インスタンスのアーキテクチャを示しています。この場合、DCM メタデータは OracleAS メタデータ・リポジトリの一部として Oracle データベース内に保存されます。図 2: OracleAS インスタンスのアーキテクチャ

(6)

Oracle Application Server クラスタの種類

Oracle Application Server クラスタには次の 2 種類があります。

• OracleAS が管理するクラスタ: OracleAS で管理されるクラスタは、クラ スタ内のすべてのアプリケーション・サーバー・インスタンスに構成情報を自動的に伝播するため、構成と配置が簡素になります。OracleAS で管理されるクラスタは、同じ OracleAS ファームの一部であり、そのリポジトリはファイルベースまたはデータベースベースのどちらかです。 • 手動で管理するクラスタ: 手動管理クラスタは、クラスタ内の各インスタ ンスの構成を管理者が手動で行います。手動で構成された OracleAS クラスタの場合、アプリケーション・サーバー・インスタンスのグループをクラスタとして動作させることは管理者の仕事です。しかし、これらの OracleAS クラスタの構成およびアプリケーション配置情報の手動による維持は、面倒な作業です。手動管理クラスタは、構成管理なしで、次に示すロード・バランシングおよび高可用性サービスを提供します。 ° アプリケーション・サーバーのすべてのクラスタ化インスタンス全体で、セッション状態をレプリケートします。 ° クラスタ内アプリケーション・サーバーにおけるすべてのインスタンスにわたり、リクエストをロード・バランスします。 ° ノードまたはコンテナに障害が発生した場合、クラスタ内の残りノードまたはコンテナに透過的にリクエストをフェイルオーバーします。このシナリオでは、各 OracleAS インスタンスは個々に独立した管理が必要です。構成上の変更は、全てのインスタンスで同一になるよう手動で行う必要があります。1 つのインスタンスに配置したアプリケーションは、その他のすべてのインスタンスにも個々に配置が必要です。この構成では、Distributed Configuration Management（DCM）機能は使用できません。要するに、手動構成の OracleAS クラスタはスケーラビリティと可用性は提供しますが、管理性は提供しません。クラスタ全体の OracleAS インスタンスの構成を同期化する責任は管理者が負います。 注:この文書では、手動で管理されるクラスタの作成および構成手順のみを説 明します。OracleAS で管理されるクラスタの構成手順については、Oracle Application Server 10g: 高可用性ガイドを参照してください。

手動管理 Oracle Application Server クラスタの構成

Oracle Application Server 10g（9.0.4）以降、ユーザーには file-based の DCM メタデータ・リポジトリを使用するオプションがあります（OracleAS 中間層インストール・オプションで選択）。File-Based Repository（FBR）の利用により、OracleAS クラスタの手動管理が不要になるわけではありませんが、その必要性が大幅に軽減されます。

(7)

手動管理クラスタは本当に必要か

Oracle Application Server 10g（9.0.4）のリリース以前、ユーザーが手動で管理する（または「管理しない」）OracleAS クラスタの構成を考えたのは、次に示す理由からです。 1. データベースの要件 2. 階層化配置

1. データベースの要件

手動管理クラスタ構成が望まれた主な理由の 1 つは、OracleAS 管理クラスタの構成に必要となるメタデータ・リポジトリ用のデータベースを持たないようにするためでした。今では FBR オプションがあるため、データベース内にメタデータ・リポジトリを保存せずに OracleAS 管理クラスタを構成できます。OracleAS 10g （9.0.4）以降、DCM メタデータ・リポジトリはファイルベース（FBR）またはデータベースベース（DBR）のどちらでも可能です。

2. 階層化配置

WebCache、OHS、OC4J およびデータベースをそれぞれ別の層で実行する「階層化配置」が必要なときは OracleAS 管理クラスタを構成できないと、誤って思い込む人がいます。各層の構成方法によっては、OracleAS 管理クラスタも使用できます。 OracleAS コンポーネントをカスタムでインストールできないため、特定の層にインストールしたいときは不要なコンポーネントの停止または無効化が必要です。たとえば J2EE & WebCache タイプのインストールは、少なくとも OHS と OC4J をインストールしますが、その層で OC4J を実行したくない場合は、その OracleAS インスタンス内の OC4J コンポーネントを停止または無効化します。ある層で不要コンポーネントの停止を決定した場合は（無効化とは違って）、 OracleAS 管理クラスタを使用できます。次の 2 種類の構成をさらに詳しく見ます。 a. 不要なコンポーネントが停止可能である場合 b. 不要なコンポーネントを無効化する必要がある場合 a. 停止可能な不要コンポーネント 特定の層で不要コンポーネントの無効化が必要でなければ、単に停止し（実行しない）、すべての層を 1 つの OracleAS ファームに入れられます。これにより、 OracleAS 管理クラスタを作成し、手動管理クラスタを回避できます。図 3 にこの構成を示します。 b. 無効が必要な不要コンポーネント 特定の層における不要なコンポーネントの無効化が業務上の要件となる場合は、手動管理クラスタの構成が必要になります。これは、OracleAS 管理クラスタ内では OracleAS インスタンス内のコンポーネントをカスタムで無効化できないためです。OracleAS インスタンス内の 1 つのコンポーネントを無効化すると、OracleAS 管理クラスタ内のすべての OracleAS インスタンスで同じコンポーネントが無効に

(8)

なります。たとえば 1 つの OracleAS インスタンスで OHS を無効化すると、そのクラスタにあるすべての OracleAS インスタンスで OHS が無効になります。不要コンポーネントの無効化が必要な場合は、すべての層を OracleAS 管理クラスタに入れることはできません。しかし OracleAS ファームにはすべての層を入れられます。また、手動管理クラスタの構成時に相互の関連付けを懸念する必要はありません。図 4 にこの構成を示します。 注: 他にもいくつか配置の方法はありますが、この 2 つの方法が、その他の配 置方法の基礎となります。図 3: 停止されたコンポーネントを持つ構成可能な限り、OracleAS 管理クラスタの構成を推奨します。OracleAS 管理クラスタはスケーラビリティや可用性とともに管理性を提供し、クラスタ全体のアプリケーション・サーバー・インスタンス構成の同期化をサポートします。しかし OracleAS 管理クラスタが望ましくない状況、または実現不可能な場合でも、ユーザーには手動管理クラスタを構成するオプションがあります。手動管理クラスタの作成および構成手順を次に詳しく説明します。

(9)

図 4: 無効化されたコンポーネントを持つ構成

手動管理クラスタの構成手順

次に示す手順に従って、Web および EJB のステートのレプリケーションが両方とも有効な OracleAS インスタンスの手動管理クラスタを構成します。使用可能な OracleAS インスタンス間でロード・バランシングとフェイルオーバーが可能な、 J2EE アプリケーションの構成方法も説明します。次の手順では、次のユースケースを前提とします。

• カスタム J2EE アプリケーションである myapp に、手動管理 OracleAS クラスタが必要である。

• 手動管理クラスタは、inst1 および inst2 というインスタンス名のファームに関連付けされていない 2 つのスタンドアロン OracleAS インスタンスを持つ。

• 2 つの OracleAS インスタンス（inst1 と inst2）は、2 台の異なるマシン上、または 1 台のマシン上に 2 つの異なる ORACLE_HOME にインストールされる。

(10)

• J2EE アプリケーションの myapp は、どの OracleAS コンポーネント（たとえば OC4J_BI_Forms や OC4J_Portal など）も内部的に使用しない home という名前の OC4J インスタンスに配置される。ここでは、次の手順について説明します。 1. OracleAS インスタンスの全体的な関連付け 2. OC4J インスタンスの構成 3. クラスタ用に J2EE アプリケーションを構成 4. フェイルオーバーとロード・バランシング用に OHS を構成

1. OracleAS インスタンスの全体的な関連付け

このユースケースでは、2 つの OracleAS インスタンスがスタンドアロン、つまり OracleAS ファームへの関連付けがないことが前提です。ただし（file-based または database-based のリポジトリを使用して）すでに OracleAS ファームに OracleAS インスタンスが関連付けられている場合は、次のステップ 2 に進んでください。 inst1 と inst2 の両方で、次のコマンドを実行します。 %cd $ORACLE_HOME/dcm/bin %dcmctl getOPMNPort このコマンドは、ローカルのアプリケーション・サーバー・インスタンスのホス ト名と ONS リモート・ポートを返します。この情報は ons.conf ファイルから取得 します。たとえば出力は次に示す IPaddress:PortNumber の形式になります。 127.2.141.148:6200

inst1 からの<IP of inst1:Port of inst1>という出力と、inst2 からの<IP of inst2:Port of inst2>という出力を参照します。

inst1 では、次のコマンドを実行します。 %cd $ORACLE_HOME/dcm/bin

%dcmctl addOPMNLink <IP of inst2:Port of inst2> inst2 では、次のコマンドを実行します。

%cd $ORACLE_HOME/dcm/bin

%dcmctl addOPMNLink <IP of inst1:Port of inst1>

前述のコマンドを実行することで、2 つの OracleAS インスタンスが同じ OracleAS ファーム内にあるかのように、2 つの OPMN が相互に通信します。

(11)

注:

• addOPMNLink の実行には、すべてのインスタンスのインストールタイプが J2EE および Web Cache である必要があります。また、インスタンスは OracleAS ファームの一部でない（リポジトリに関連付けられていない）必要があります。これらの条件を満たさない場合、コマンドは失敗します。 • クラスタ内のインスタンスの ONS リモート・ポートを変更したい場合は、 removeOPMNLink コマンドを実行し、インスタンスをクラスタから外します。リモート・ポートを変更した後、addOPMNLink コマンドを実行して、クラスタに追加しなおす必要があります。コマンドは各 Oracle ホームで実行します。 • クラスタの作成後、そのクラスタに別のインスタンスを追加する場合は、すべての Oracle ホームでコマンドの実行が必要です（実質的に追加インスタンスを含めた新しいクラスタを作成します）。

2. OC4J インスタンスの構成

OracleAS クラスタ内の OracleAS インスタンス間でステートフルなアプリケーションのステートを維持するには、ステートをレプリケーションするよう Web および EJB アプリケーションの構成を行う必要があります。レプリケーションの範囲は OC4J レベルであり、J2EE アプリケーション・レベルではありません。つまりこれらは一旦有効になると、OC4J インスタンスに配置されたすべての J2EE アプリケーション用として適用されます。セッションステートのレプリケーションを必要としない場合、または J2EE アプリケーションがステートレスな場合は、次のステップ 3 に進んでください。 Web アプリケーションに関するセッション状態は、アプリケーション境界を越え、かつクラスタ全体にわたって、同じ名前で OC4J アイランド内にレプリケートされます。ステートフル・アプリケーションとともに高可用性を保証するため、 OC4J アイランド名はクラスタ全体の各 OC4J インスタンス内で同じである必要があります。ここでは、次の手順について説明します。 a. Web アプリケーションでのステートのレプリケーション構成 b. EJB アプリケーションでのステートのレプリケーション構成 a. Web アプリケーションでのステートのレプリケーション構成 ステートフル Web アプリケーションで、ステートのレプリケーションを構成するには、inst1 と inst2 の両方のインスタンスで次の手順を実行します。

• OracleAS コントロールを起動して"home"という名前の OC4J インスタンスのホームページまでナビゲートします。 • 管理リンクを選択します。 • インスタンス・プロパティ列からレプリケーション・プロパティを選択します。 • Web アプリケーション・セクションまで、下にスクロールします。図 5 にこのセクションを示します。

(12)

• セッション状態レプリケーションチェックボックスを選択します。マルチキャスト・ホストとマルチキャスト・ポートには何も入力しないでください。オプションとして、マルチキャスト・ホスト IP アドレスおよびポート番号を指定できます。マルチキャスト・アドレス用にホストとポートを指定しない場合は、デフォルト値としてホスト IP アドレス 230.0.0.1 およびポート番号 9127 がとられます。ホスト IP アドレスは 224.0.0.2∼ 239.255.255.255 の間でなければなりません。HTTP と EJB マルチキャスト・アドレスの両方に同じマルチキャスト・アドレスは使用できません。図 5: Web 状態レプリケーション構成 b. EJB アプリケーションでのステートのレプリケーション構成 EJB アプリケーションでのステートのレプリケーションを構成するには、inst1 と inst2 の両方のインスタンスで次の手順を実行します。

• OracleAS コントロールを起動して"home"という名前の OC4J インスタンスのホームページまでナビゲートします。 • 管理リンクを選択します。 • インスタンス・プロパティ列からレプリケーション・プロパティを選択します。 • EJB アプリケーション・セクションにあるレプリケート状態チェックボックスを選択します。図 6 にこのセクションを示します。 • マルチキャスト・ホストとマルチキャスト・ポートには何も入力しないでください。オプションとして、マルチキャスト・ホスト IP アドレスおよびポート番号を指定できます。マルチキャスト・アドレス用にホストとポートを指定しない場合は、デフォルト値としてホスト IP アドレス 230.0.0.1 およびポート番号 23791 がとられます。ホスト IP アドレスは 224.0.0.2∼ 239.255.255.255 の間でなければなりません。HTTP と EJB マルチキャスト・アドレスの両方に同じマルチキャスト・アドレスは使用できません。 • クラスタ内のその他のホストに認証用のユーザー名とパスワードを指定します。クラスタ内のその他のホスト用のユーザー名とパスワードが異

(13)

なる場合は、通信に失敗します。マルチキャスト・アドレス内では、複数のユーザー名とパスワードの組合せが可能です。同じユーザー名/パスワードの組合せは、固有なクラスタと見なされます。 • RMI サーバー・ホスト名を指定します。これは通常、OC4J インスタンスが実行されているマシンの名前です。 • [適用]および[OK]をクリックして確認します。図 6: EJB 状態レプリケーション構成

3. クラスタ用に J2EE アプリケーションを構成

J2EE アプリケーションのクラスタ対応（クラスタ・アウェア）には、inst1 と inst2 の両方のインスタンスで各アプリケーションを次のように変更します。

a. web.xml に<distributable> タグを追加 b. orion-web.xml に<cluster-config> タグを追加 c. orion-ejb-jar.xml に replication 属性を追加 a. web.xml に<distributable> タグを追加

すべての web.xml ファイルに<distributable/> タグを追加します。Web アプ リケーションがシリアル化できる場合は、このタグを web.xml ファイルに追加し ます。 web.xml に追加されたこのタグの例を次に示します。 <web-app> <distributable/> <servlet> ... </servlet> </web-app>

(14)

b. orion-web.xml に<cluster-config> タグを追加 すべての orion-web.xml ファイルに<cluster-config/> タグを追加します。 orion-web.xml に追加されたこのタグの例を次に示します。 <orion-web-app ...> ... <cluster-config/> </orion-web-app> c. orion-ejb-jar.xml に replication 属性を追加

orion-ejb-jar.xml ファイルを修正して、ステートフル Session Bean 用にステートの

レプリケーション構成を追加します。ステートフル Session Bean 用のレプリケーション・タイプが Bean デプロイメント・ディスクリプタ内に構成されるため、各 Bean は異なるタイプのレプリケーション（VMTermination または EndOfCall）を使用できます。

orion-ejb-jar.xml に追加されたこの属性の例を次に示します。

<session-deployment ... replication=”EndOfCall” />

4. フェイルオーバーとロード・バランシングのための OHS の設定

Oracle HTTP Server（OHS）のモジュールである mod_oc4j は、処理が必要なリクエストの識別、これらのリクエストをルーティングする OC4J の判断、通信の特定なプロセスを決定します。配置されたすべての J2EE（web）アプリケーション の root context への対応付けが必要です。この root context （つまり URL プリフィ ックス）は、mod_oc4j による処理が必要なリクエストの識別子の機能を果たします。リクエストは、OPMN との通信を介して mod_oc4J がアライブ（活動状態）だと判断した OC4J インスタンスとプロセスにのみルーティングされます。 mod_oc4j 構成 mod_oc4j 関連の構成情報はすべて、 $ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf ファイルに保存されます。 OHS は Oc4jMount ディレクティブを使用して、アプリケーションが配置された OC4J インスタンスにルート・コンテキストをマッピングします。使用できる OC4J インスタンスおよびロード・バランシング情報の表が保持されます。その他の OracleAS インスタンス内の OC4J インスタンスにリクエストを送 信するには、mod_oc4j.conf ルーティングの更新が必要です（ローカル OC4J イン スタンスがダウンした場合）。リクエスト・ルーティングについて

Oracle HTTP Server（OHS）は、mod_oc4j.conf ファイル内に定義された Oc4jMount ディレクティブを使用して、宛先への特定なパスが入ったリクエストをルーティングします。宛先は 1 つの OC4J プロセスまたは OC4J インスタンスのセットが可能です。

(15)

Oc4jMount path [destination] コンテキスト・ルートのパスは、アプリケーションの展開中に指定されたアプリケーション・コンテキスト・ルートと同じである必要があります。また宛先は次に示すタイプの 1 つです。 • ajp13_dest • cluster_dest（これはデフォルトの宛先タイプです） • instance_dest 詳細は、Oracle HTTP Server管理者ガイド 10g（9.0.4）を参照してください。デフォルト mod_oc4j.conf ファイルの Oc4jMount セクションの一部は次のとおりです。 Oc4jMount /j2ee/* Oc4jMount /webapp home Oc4jMount /webapp/* home

インスタンス名の識別この構成に関係する各 OracleAS インスタンスの完全修飾名を識別します。 inst1 と inst2 の両方で、次のコマンドを実行します。 %cd $ORACLE_HOME/dcm/bin %dcmctl whichInstance このコマンドは、ローカル・アプリケーション・サーバー・インスタンスの名前を返します。inst1 からの出力を<inst1_name>、inst2 からの出力を<inst2_name>と呼びます。リクエスト・ルーティングの構成デフォルトのマウント・ポイントは、ローカル OC4J インスタンスのみを示します。この構成の場合は、Oc4jMount ディレクティブを編集して構成内の各 OracleAS インスタンス/OC4J インスタンスを指す必要があります。 Oc4jMount ディレクティブがデプロイメント・プロセスの一部としてファイルに書き込まれるため、アプリケーションの配置前ではなく配置後に、次のように編集してください。OracleAS インスタンス、inst1 と inst2 の両方で次の手順を実行します（inst2 の OHS を使用せずに inst1 の OHS のみを使用したい場合は、1 つのインスタンスで実行します）。

• OracleAS コントロールを起動し、"HTTP_Server"のホームページまでナビゲートします。

• 管理リンクを選択し、拡張サーバー・プロパティを選択します。 • File Name 列から mod_oc4j.conf を選択します。

(16)

• エディタ内で、下方へスクロールし、配置したアプリケーションの Oc4jMount ディレクティブを探して、次のように変更します。 Oc4jMount /myapp instance://<inst1_name>:home, <inst2_name>:home

Oc4jMount /myapp/* instance://<inst1_name>:home, <inst2_name>:home この構成により自動的にこれらのインスタンス（inst1 と inst2）を相互のフェイルオーバー候補にします。 • [適用]および[OK]をクリックして確認します。これには Oracle HTTP Server（OHS）の再起動が必要です。

まとめ

Oracle Application Server 10g（9.0.4）に file-based リポジトリ（FBR）が採用されたため、手動管理クラスタを構成する必要性が大幅に減少しました。このホワイト・ペーパーでは、OracleAS 管理クラスタが最適ではない状況、または実現不可能な場合に使用する手動管理クラスタの構成に必要な詳細手順を説明しました。ここでは、その他のタイプのセットアップの基礎となる共通のデプロイメント・セットアップについて説明しましたが、この他にもいくつかの組合せが可能です。

(17)

Oracle Application Server 10g (9.0.4): Manually Managed Cluster 2004 年 6 月

著書: Shail Goel

寄稿者: John Lang, Rick Ehrsam 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 はオラクル社の登録商標です。このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。その他のすべての製品名およびサービス名は、各社の商標です。

(18)