ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Portal管理者ガイド
11g リリース1(11.1.1)
B61385-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

2 Oracle Portalの計画

この章では、Oracle Portalの計画、インストール、構成および管理に含まれるタスク・フローの詳細について説明します。この章を読むと、ポータルを効果的に構築するのに必要なハードウェアおよびソフトウェアをどのように計画すればよいかを理解することができます。

この章の内容:


注意:

この章で使用されている用語の詳細は、第1章「Oracle Portalのアーキテクチャについて」を参照してください。

2.1 考慮すべき要点

ポータルの構成を計画するには、システムで実現する目標を明確にすることが重要です。次の各項では、これらの重要な決定事項としてそれぞれ何が含まれるのかを確認します。

2.1.1 適切なトポロジの選択

Oracle Fusion Middlewareには、様々なトポロジ・オプションが用意されています。Oracle Fusion Middlewareの推奨トポロジには、小規模で一般的な開発の実装から、大規模な企業全体の実装までが含まれています。


関連項目:

  • Oracle Fusion Middleware概要』の推奨トポロジの概要
  • WebLogic Serverの高可用性


2.1.2 必要なハードウェア

Webポータルをサポートするサーバー、データベースおよびリソースは、特にピーク間隔では様々なユーザー通信量を処理する必要があります。

Webポータルと同様に、ポータルを配置するのに必要なサーバーおよびデータベースの容量は、主に、予想されるユーザー・リクエストの数によって決まります。1つのページをユーザーに表示するには、ユーザーがページの表示を許可されているかどうかの検証、ページに表示されるイメージのロード、ページの書式情報が含まれているスタイル・シートのコールなど、様々な処理が別個に必要になる場合があります。

必要な容量の上限および下限は、ユーザーがどのようにポータルを使用するかによって決まります。ポータルの主要機能が統合の場合は、一般的に負荷の大半が中間層にかかります。一方、大幅にカスタマイズしたコンテンツ・ドリブンのポータルの場合は、リポジトリやインフラストラクチャに負荷がシフトします。少なくとも、ユーザーが受け入れることができるレスポンス時間と、業務時間中の平均負荷を満たすだけのサーバー容量が必要です。可能であれば、ユーザー業務のピーク間隔中に予想されるページ・リクエストの量を満たすようにします。CPU、メモリー、I/O容量、ネットワーク帯域幅などのハードウェア・リソースは、レスポンス時間を短縮するための重要な要素です。Oracle Portalは、多数のトランザクションを処理できるサーバー、またはサーバー・グループにインストールする必要があります。このようにしない場合は、レスポンス時間が長くなることがあります。

サーバーおよびデータベースの容量を追加すると、Webポータルのパフォーマンスは確実に向上しますが、資金を自由に投入できる場合を除き、十分なパフォーマンスと新しいハードウェアおよびソフトウェアを使用できるようにするためのコストとのバランスを保つ必要があります。


関連項目:

『Oracle Fusion Middleware Administrator's Guide』

2.1.3 パフォーマンスを最大にする方法

レスポンス時間は、ユーザー・リクエストが発行されてから、そのリクエストに対するレスポンスが完了するまでの経過時間です。Webポータルは、最小のソフトウェアおよびハードウェア・オーバーヘッドを使用して、できるだけ早く応答する必要があります。パフォーマンスについては、次の点について考慮する必要があります。

  • 負荷を分散させる

    Webポータル上に大量の通信量が予想される場合は、独自の中間層インスタンスを持つ複数のサーバーに負荷を分散することができます。過剰な通信量によって1つのサーバーがオーバーロードした場合は、別のサーバーがオーバーフローを処理できます。詳細は、第2.1.8.1項「ロード・バランス」を参照してください。

  • 障害が発生しないようにする

    Oracle Portalを分散構成にすると、Webポータルで利用できるソフトウェア・リソースおよびハードウェア・リソースが増加するので、単一サーバー構成よりも可用性が向上します。サーバーおよびソフトウェアを追加してフェイルオーバーを提供することで、システムに高い安定性を実現できます。詳細は、第2.1.8.2項「フェイルオーバーと冗長性」を参照してください。

  • キャッシュ・クラスタを実装する

    キャッシュ・クラスタを構成すると、中規模および大規模のデプロイメントの可用性とスケーラビリティを高めることができます。キャッシュ・クラスタによって、障害検出とフェイルオーバーが実現され、Webサイトの可用性が向上します。詳細は、第1.3項「Oracle Portalのキャッシュについて」を参照してください。


    関連項目:

    『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

  • ページ、ポートレット・インスタンスおよびテンプレートに合せて最適なキャッシュ・オプションを選択する

    キャッシュは、Oracle Portalのパフォーマンスを最大化するための主要な方法です。分散アーキテクチャを使用するとシステムの可用性と速度は向上しますが、キャッシュ法のほうがはるかに重要です。パフォーマンスとスケーラビリティを高めるために、Oracle Portalではいくつかのキャッシュ・オプションが用意されています。詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』にあるページのパフォーマンスの向上に関する章を参照してください。

2.1.4 ポータルを拡張する方法

冗長性は、同じ構成とした複数台のコンピュータを用意することでリクエストに対応する能力を十分に高め、障害やエラーの発生時にバックアップを提供することによって、システムのスケーリングを可能にします。

さらに、ページ、ポートレット・インスタンスおよびテンプレートに合せた最適なキャッシュ・オプションを選択することでスケーラビリティが向上します。Oracle Portalには、そのためのキャッシュ・オプションがいくつか用意されています。詳細は、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』にあるページのパフォーマンスの向上に関する章を参照してください。

詳細は、第2.1.8.3項「スケーラビリティ」および第1.3項「Oracle Portalのキャッシュについて」を参照してください。

2.1.5 ポータルの可用性を向上させる方法

クラスタリングを行うと、単一のOracle Fusion Middlewareインスタンスを使用した場合よりもシステムの可用性を高めることができます。1つのOracle Fusion Middleware上の単一のインスタンスで稼働しているアプリケーションは、そのサーバーが稼働しているオペレーティング・システムとホストに依存しています。このような場合には、ホストが停止するとアプリケーションも使用できなくなるため、ホストはシングル・ポイント障害を引き起こします。


関連項目:

『Oracle Fusion Middleware高可用性ガイド』

2.1.6 ポータルを保護する方法

重要なデータは、すべてのユーザーが使用するコンテンツに影響を与えずに、セキュリティで保護する必要があります。

Oracle Portalでは、このような柔軟な方法でWebコンテンツへのアクセスを管理できるように、Oracle Fusion Middlewareの他のコンポーネントとOracle Database 11gを活用して、ポータルを強力に保護します。Oracle Portalでは、そのセキュリティ・モデルを実装するために、次のすべてのコンポーネントと対話します。

  • Oracle Application Server Single Sign-On

  • mod_osso(J2EE Webアプリケーションのシングル・サインオンを容易にするOracle HTTP Serverのリスナー・モジュール)

  • Oracle Web Cache

  • Oracle Internet Directory

  • Oracle Delegated Administration Services

  • Oracleディレクトリ統合プラットフォーム

詳細は、第7章「Oracle Portalの保護」を参照してください。

2.1.7 ハードウェアとソフトウェアを構成する方法

この項では、Oracle PortalおよびOracle Fusion Middlewareの関連するすべてのコンポーネントを最適に使用するために、ハードウェアとソフトウェアのインストールをどのように構成するかについて説明します。ここでは、多数のユーザーにサービスを行う大規模なサイトの配置だけでなく、小規模な開発環境を設定するために、ハードウェアをどのように構成するかを説明します。

2.1.7.1 単一のコンピュータの使用

最も単純な構成では、Oracle Fusion Middlewareのすべてのコンポーネントを、図2-1に示すように1台のコンピュータにインストールします。実際には、1つのデータベースをコンピュータに常駐させ、Oracle Portal、Oracle Internet DirectoryおよびOracleAS Single Sign-Onに個別のスキーマを格納することも可能です。

図2-1 Oracle Portal単一のコンピュータ構成

図2-1の説明が続きます
「図2-1 Oracle Portal単一のコンピュータ構成」の説明

この構成は、開発者がOracle Portalの宣言インタフェースを使用してページ、ポートレットおよびアプリケーションを構築する、小規模な開発環境に適しています。また、完成したWebポータルの小規模なデプロイメントを簡単にサポートできます。より多くのコンテンツをより多くのユーザーに配信する大規模なサイトをデプロイする場合は、図2-1に示すような単一のサーバーまたは単純な構成では不十分です。

2.1.7.2 複数のコンピュータの使用

単一のコンピュータ構成がニーズに適さない場合は、Oracle Portalアーキテクチャの様々な要素を別のコンピュータに移動することを検討します。Webポータルを構成する場合は、使用するサイトの規模に応じて、それぞれ専門の処理を担当する複数のサーバーが必要になります。ハードウェアを追加することでパフォーマンスが向上し、ソフトウェア・インスタンスを追加することで冗長性をサポートできます。

大規模なWebポータル・サイトを構成する場合の配置オプションには、次の作業が必要です。

配置したWebポータルの要件が実現されるまで、これらの作業を実行します。たとえば、サイトで通常の作業負荷のみを処理する場合は、最初に中間層をデータベースから切り離してから、Oracle Identity Managementを別のサーバーに移動することを考えます。前述の構成作業をすべて実行する必要はありません。ただし、サイトが拡大するにつれ、前述した順序で基になる構成を拡張する必要があります。


注意:

Webポータルをオンラインにする前に、小規模なテスト・システムで設定およびテストを行うことをお薦めします。これにより、最終的に使用するユーザーに影響を与えずに、実際の使用パターンに基づいて、役に立つ構成情報および調整情報を集めることができます。

2.1.7.2.1 Oracle Metadata Repositoryからの中間層の切離し

大規模なシステムを構成する際に最初に考慮すべきことは、図2-2に示すように、中間層を別にインストールすることです。


関連項目

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

図2-2 インフラストラクチャ層からのOracle Fusion Middleware中間層の切離し

図2-2の説明が続きます
「図2-2 インフラストラクチャ層からのOracle Fusion Middleware中間層の切離し」の説明

これにより、Oracle Metadata Repositoryと中間層は、I/O、メモリー、ディスク容量などのハードウェア・リソースの競合から解放されます。また、これらのコンポーネントを別個のコンピュータにインストールすると、パフォーマンスをより柔軟に調整できます。これは、Oracle Metadata Repositoryに多数のコンテンツを格納するようなサイトでは重要です。オペレーティング・システムなどに関する調整パラメータは、HTTP Serverなどの中間層コンポーネントの調整パラメータとは別個になります。一方のパフォーマンス・パラメータを設定しても、もう一方のパフォーマンスが調整されない場合があります。

2.1.7.2.2 Oracle Identity Managementの個別のインストール

OracleAS Single Sign-Onは、Oracle Portalおよび他のアプリケーションのOracle Internet Directoryを使用してユーザー証明書を認証します。したがって、ユーザーは、1つのユーザー名とパスワードを使用してWebポータルに1回ログインするだけで、複数のアカウントとアプリケーションにアクセスできるようになります。

配置されたOracle Portalサイトにログインすると、そのユーザーは、その他のOracleAS Single Sign-Onのセキュアなすべてのアプリケーションにアクセスできます。

図2-3に示すように、Oracle Identity Managementは、Oracle Metadata Repositoryとは別のコンピュータに配置されています。1つのOracle Identity Managementインスタンスを、複数のOracle製品(Oracle Portalの中間層の複数のインスタンスなど)で使用するように構成できます。

図2-3 個別のコンピュータにインストールされたOracle Identity Management

図2-3の説明が続きます
「図2-3 個別のコンピュータにインストールされたOracle Identity Management」の説明

図2-3に示すシステムは、分散構成の例です。この構成では、複数の中間層インスタンスのサポートが可能な集中型のOracle Identity Managementサーバーを採用しています。Oracle Identity Managementを専用サーバーに移動すると、そのパフォーマンスをデータベースと中間層とは無関係に調整できます。

さらに、Oracle Identity Managementを中間層インストールから切り離すことにより、分散システム全体の安定性が高まります。中間層がインストールされているコンピュータに障害が発生しても、OracleAS Single Sign-On、およびログインの検証をSingle Sign-Onに依存するその他の中間層インスタンスは、影響を受けません。また、複数のセキュリティ・ポリシーを使用して、構成内の様々なコンピュータを管理できます。


関連項目:

『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』

2.1.7.2.3 中間層インスタンスの追加

きわめて大規模なWebポータルに対応するには、それぞれ同一の構成設定とした冗長中間層インスタンスを追加します。追加した中間層インスタンスは、図2-4のようになります。ハードウェアの障害を切り分けることができるように、中間層インスタンスのそれぞれを専用のコンピュータにインストールすることをお薦めします。

図2-4 複数の中間層

図2-4の説明が続きます
「図2-4 複数の中間層」の説明

中間層はポータル・ページに対するユーザー・リクエストをプロバイダに転送し、返されたコンテンツを使用してページを作成します。中間層インスタンスをOracle Portal構成に追加すると、より多くのユーザー・リクエストを処理できるようになり、ポータル全体のパフォーマンスが向上します。データベースとネットワーク・リソースがより効率的に使用されます。


注意:

この構成の場合、ロード・バランス・ルーター(LBR)を使用する必要があります。詳細は、第2.1.8.1項「ロード・バランス」を参照してください。

2.1.7.2.4 中間層からOracle Web Cacheを切り離したインストール

Oracle Web Cacheサーバーを中間層から切り離して、データのキャッシュ率の向上、リクエスト時間の短縮、中間層における負荷の軽減を実現することもできます。

Oracle Web CacheはCPUよりもメモリーを消費するため、切り離すと、システムの調整が容易になりパフォーマンスが向上します。また、コンポーネントを切り離すと、キャッシュされたデータとエンド・ユーザーの距離が縮まり、特定のユーザー・コミュニティのネットワーク・エッジでキャッシュされるコンテンツを制限することで効果的にセキュリティが向上します。たとえば、一般的な内部または外部のシナリオでは、特定のキャッシュされたコンテンツを有するコミュニティを対象にOracle Web Cacheの切離しを行うことができます。

2.1.7.2.5 インフラストラクチャに対する高可用性の構成

Oracle Fusion Middleware 11gでは、Cold Failover Cluster、Data Guard、Real Application Clusters(Oracle RAC)などのすべてのOracle高可用性(HA)ソリューションをOracleAS Infrastructureで使用できます。


関連項目:

『Oracle Fusion Middleware高可用性ガイド』

2.1.8 構成の機能を向上させる方法

Oracle Portalを分散構成にすると、Webポータルで利用できるソフトウェア・リソースおよびハードウェア・リソースが増加するので、単一サーバー構成よりも可用性が向上します。しかし、利点はこれにとどまりません。サーバーおよびソフトウェアを追加してフェイルオーバーを提供することで、システムに高い安定性を実現できます。さらに、複数のサーバー間でロード・バランシングを使用することで、1日を通してWebポータルに発生すると考えられる負荷の大幅な変動に対処できます。最終的に、分散構成にサーバーを増設してユーザーの増加に対応することで、高いスケーラビリティを得ることもできます。

2.1.8.1 ロード・バランス

Webポータル上に大量の通信量が予想される場合は、独自の中間層インスタンスを持つ複数のサーバーに負荷を分散することができます。過剰な通信量によって1つのサーバーがオーバーロードした場合は、別のサーバーがオーバーフローを処理できます。

Oracle Fusion Middlewareは、着信リクエストを処理するサーバー・インスタンスのプーリングを利用して、独自のロード・バランス機能を提供します。1つのインスタンスが応答しない場合、リクエストは別のインスタンスに転送されます。これにより、配置されたサイトのユーザーは、コンテンツとアプリケーションを常に利用できるようになります。

非常に大規模なサイトの場合は、ロード・バランスのハードウェアまたはソフトウェアを追加して、着信リクエストを中間層サーバーに分散できます。図2-5は、この目的で使用するロード・バランス・ルーター(LBR)を示しています。LBRは、ネットワーク・リクエストを多数のサーバーに配布する高速ネットワーク・デバイスです。これは最も一般的なロード・バランスの方法です。ロード・バランス・ルーターは、各リクエストを特定の中間層サーバーに送信するかわりに、ポータル・ユーザーに公開アドレスを1つだけ提供します。

図2-5 ロード・バランス・ルーターを使用する複数のサーバー構成

図2-5の説明が続きます
「図2-5 ロード・バランス・ルーターを使用する複数のサーバー構成」の説明

LBRを追加して、着信リクエストを中間層サーバーへ分散させる方法の詳細は、第6.3項「ロード・バランス・ルーターを使用する複数の中間層の構成」を参照してください。

たとえば、通信量の多い個人用サイトMy.Oracle.com(MOC)で、LBRを使用してリクエストを振り分けるとします。負荷を分散するソフトウェア・ロジックは、中間層サーバーごとに個別にインストールするのではなく、LBR自体に用意されています。このため、LBRを使用すると、構成の管理コストを低減できます。MOCはイントラネットおよびエクストラネットのWebサイトです。MOCは、オラクル社のオンライン・サービスおよび外部プロバイダのビジネス情報に対するカスタマイズ可能な単一エントリ・ポイントを、オラクル社の従業員に提供します。

LBRを追加すれば、負荷の変動にも対応できます。ユーザーはサイトにアクセスし、アプリケーションを使用して、特定のピーク間隔(ほとんどのユーザーがログインして業務を開始する9 a.m.から10 a.m.など)に非常に高い頻度でコンテンツをリクエストすることがあります。このような大量の通信量が発生する時間に、LBRは、ページ・リクエストを様々な中間層インスタンスに分散して、迅速なレスポンスを確保することができます。

ピーク負荷が定期的に発生する場合は、ピーク負荷要件に対応するための構成を検討します。ピーク負荷の頻度が低い場合は、ハードウェアの投資を追加しないで、ピーク間隔にレスポンス時間の遅延が発生する状態で使用することもできます。

LBR自体を構成してフェイルオーバーをサポートすることもできます。図2-6に示すMy.Oracle.comの構成では、主ルーターに障害が発生した場合に利用できる、2番目のLBRを追加できます。

2.1.8.2 フェイルオーバーと冗長性

フェイルオーバーは、サーバーやデータベースなど、システムの一部に障害が発生した場合にバックアップに切り替える機能です。たとえば、Oracle Database 11gのいずれかに障害が発生しても、バックアップに保存された状態情報を使用して、サービスが再開されます。

冗長性は、同じ構成とした複数台のコンピュータを用意する技法です。冗長コンピュータは、リクエストを十分に処理できる能力を提供するほか、障害やエラーが発生した場合のバックアップとして機能します。冗長性は、構成の中でコンピュータを増設することによって実装します。1台のサーバーがアクティブになっているときは、他のサーバーがそのサーバーの動作を監視して、障害が発生した場合はただちにその処理を引き継ぎます。

図2-6に示すように、My Oracle.comは、他のサーバーで障害の原因となる問題が発生した場合に、引き継ぐことができる追加の中間層サーバーを使用して、フェイルオーバーを提供します。


注意:

図2-6に示しているコンポーネントは、考えられる構成の1つを表しています。オラクル社では、これらの特定のベンダーやコンポーネントを特にお薦めしたり支持しているわけではありません。

図2-6 My Oracle.comの中間層の構成

図2-6の説明が続きます
「図2-6 My Oracle.comの中間層の構成」の説明

冗長中間層インスタンスを設定するには、同じサイト名およびサーバー・ポート・エントリ(サイト名がmy.oracle.com、ポートが5000など)で、元のインスタンスと各冗長インスタンスを構成します。つまり、物理的なサイト名とポートが同じである必要はありませんが、冗長層の仮想ホスト参照は同じでなくてはなりません。

冗長性のかわりに、構成全体の余剰容量を使用してフェイルオーバーを提供することもできます。たとえば、75%の容量で稼働中の4台の中間層サーバーがあるとします。1台のサーバーで障害が発生した場合、他の3台が4分の1の作業負荷を引き継ぐことができます(25%×3 = 75%、障害が発生したサーバーの容量に相当)。

2.1.8.3 スケーラビリティ

スケーラビリティは、時間の経過とともにユーザー数およびコンテンツのボリュームが増加したときに、増加したリクエストをWebポータルで処理できるようにする機能です。ポータルで処理可能なトラフィックが増えるため、レスポンス間隔やエラー頻度からユーザーがパフォーマンスの変化に気づくことはありません。スケーラビリティを目標とする場合は、必要に応じてデータベース容量とサーバーを追加しながら、それ以外の構成には影響を与えないような柔軟な構成が必要です。

2.2 必要な作業

この項では、Oracle Portalの計画、インストール、構成および管理に含まれるタスク・フローの詳細について説明します。

Oracle Portalを適切に配置するためには、次の手順が必要です。

  1. ポータルの計画

  2. Oracle Portalのアップグレード(必要な場合)

  3. インストール前の要件の確認

  4. Oracle Fusion Middlewareのインストール

  5. インストール後の構成の実行(基本的な構成および管理)

  6. 拡張構成の実行

  7. Oracle Portalの保護

  8. Oracle Portalの監視

  9. Oracle Portalのトラブルシューティング

次の各項では、各手順の概要を説明し、様々な参照先(この構成ガイド、Oracle Fusion Middleware 11gドキュメント・ライブラリのその他のドキュメント、テクニカル・ホワイト・ペーパーおよびOTN(http://www.oracle.com/technology/)など)の詳細情報について説明します。

2.2.1 ポータルの計画

Oracle Portalを初めて使用する場合は、第1章「Oracle Portalのアーキテクチャについて」を読むと、Oracle PortalがOracle Fusion Middlewareのアーキテクチャにどのように適合するかを理解することができます。

Oracle Portal構成の計画の詳細は、Portal Center(http://www.oracle.com/technology/products/ias/portal/index.html)を参照してください。

2.2.2 Oracle Portalのアップグレード

Oracle Portalの以前のリリースからのアップグレードに関する最新情報は、OTNのhttp://www.oracle.com/technetwork/middleware/ias/upgrade-087279.htmlを参照してください。アップグレードに関するページには、次の情報が用意されています。

  • アップグレード・スクリプトのダウンロード手順

  • アップグレードに関するオンライン・ドキュメント

2.2.3 インストール前の要件の確認

インストールをスムーズに行うためには、すべての前提条件を満たしており、インストール前の手順がすべて実行されていることを確認する必要があります。『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』には、Oracle Fusion Middlewareの一般的な要件が記載されていますが、第3章「インストール前およびインストール後の作業」には、ポータル特有の手順が説明されています。

2.2.4 Oracle Fusion Middlewareのインストール

Oracle Fusion Middlewareインストレーション・プランニング・ガイド』では、Oracle Portalを実行するのに必要なOracle Fusion Middleware中間層およびInfrastructureをインストールする手順を説明しています。詳細は、第3章「インストール前およびインストール後の作業」を参照してください。

2.2.5 インストール後の構成の実行

第5章「基本的な構成および管理」では、Oracle Portalの管理者が実行できる、構成後のすべての作業について説明しています。

詳細は、Portal Center(http://www.oracle.com/technology/products/ias/portal/index.html)を参照してください。

2.2.6 拡張構成の実行

第III部「拡張構成」は、Oracle Fusion Middlewareの管理者を対象としています。第6章「拡張構成」では、仮想ホスト、ロード・バランス・ルーター、プロキシ・サーバー、Oracle Web CacheおよびOracleAS Single Sign-Onの構成など、Oracle Portalの拡張構成と統合構成を実行する方法を説明しています。第III部の他の章では、検索、インポートとエクスポートなどの機能の詳細について説明しています。

2.2.7 Oracle Portalの保護

第7章「Oracle Portalの保護」では、Oracle Portalでセキュリティ機能を構成するための詳細情報を説明しています。

2.2.8 Oracle Portalの監視

Oracle Portalは、Oracle Enterprise Manager 11g Fusion Middleware Controlから監視できます。詳細は、第8章「Oracle Portalの監視と管理」を参照してください。

また、ポータルのパフォーマンスを監視するパフォーマンス・レポートを生成できます。付録G「パフォーマンス・ログの有効化」を参照してください。このパフォーマンスに関する情報は、この後のOracle Portalのパフォーマンスのチューニングで役立ちます。第10章「Oracle Portalのパフォーマンスの調整」を参照してください。

2.2.9 Oracle Portalのトラブルシューティング

付録G「Oracle Portalのトラブルシューティング」では、様々な問題を解決および診断する方法について説明しています。