| Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド 11g リリース1(11.1.1) B61394-04 |
|
 前 |
 次 |
この章では、様々なOracle製品スイート内のOracle Fusion Middlewareコンポーネントの障害保護の要件について説明し、これらのコンポーネントの同期化に関する推奨事項も示します。前に説明したとおり、ストレージ・レプリケーションを使用して中間層のコンテンツを同期化し、Oracle Data Guardを使用してOracle Fusion Middleware障害時リカバリ・トポロジに含まれているOracle Database・リポジトリまたはカスタム・アプリケーション・データベース内のデータを同期化します。
この章では、次のOracle製品スイート内のコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracleインベントリ、beahomelistファイル、oratabファイル、oraInst.locファイルなどの特定のアーティファクトは、すべてのOracle製品デプロイメント間で共通です。これらのアーティファクトが異なっていることはほとんどなく、通常のストレージ・レプリケーションおよび同期化アクティビティの一部とする必要はありません。Oracleインベントリ、beahomelistファイル、oratabファイルおよびoraInst.locファイルはマシンのローカル・ディスクに配置することをお薦めします。これらのアーティファクトは、作成時およびパッチ・アップデートの適用時に手動で更新する必要があります。環境で必要な場合は、これらのアーティファクトを共有記憶域に配置することも可能です。
Oracle WebLogic Serverは、エンタープライズ対応のスケーラブルなEnterprise Edition(Java EE)アプリケーション・サーバーです。Oracle WebLogic Serverインフラストラクチャは、様々なタイプの分散アプリケーションのデプロイメントをサポートしており、サービス指向アーキテクチャ(SOA)に基づいてアプリケーションを構築するための理想的な基盤となります。
Oracle WebLogic Serverの共通アーティファクトと考慮事項
コンポーネント固有の推奨事項に加えて、次のアーティファクトと考慮事項がすべてのWebLogic Serverコンポーネントに適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームから構成されます。
ドメイン・ホーム: ドメイン・ホームには、WebLogicドメインの構成データおよびアプリケーションが含まれます。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
環境でサーバー全体の移行を構成する必要がある場合、サーバー全体の移行で構成されている管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用することをお薦めします。障害時リカバリ操作後にリスニング・アドレスを手動で更新しなくても済むようにするには、ホスト名をプライマリ・サイトとスタンバイ・サイトの両方で解決できるようにしてください。
本番サイトとスタンバイ・サイトの両方で、WebLogic Serverアプリケーションへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。
この項の残りの部分では、次のOracle WebLogic Serverコンポーネントの障害時リカバリに関する推奨事項を示します。
この項では、様々なOracle WebLogic Server JMSおよびトランザクション・ログ・アーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
ファイルベースの永続ストア: JMS/トランザクション・ログのファイル・ストアの場所(ファイルベースの永続ストアを使用する場合)。
JMSメッセージを含むスキーマ(データベース・ベースの永続ストアを使用する場合)。このスキーマには、JDBC LLRオプションを利用するWebLogicアプリケーションのロギング・ラスト・リソース(LLR)トランザクション・ログ・レコードが含まれます。
サーバー全体の自動移行が構成されている場合、必要なリース表はデータベース内にあります。
システムのリストア・ポイントよりも後にエンキューされていた未処理のメッセージは失われます。システムのリストア・ポイントよりも前にエンキューされており、その後デキューされて確認応答またはコミット(処理)されたメッセージについては、メッセージの複製が作成されます。
永続ストアがJMS専用のカスタム・ストアである場合は、ストア全体を削除できます。
システムのさまざまな部分をさまざまな時点でリストアすると、データに不整合が生じる可能性があります。メッセージ・ストア、トランザクション・ログまたはアプリケーション・データベースが別々に同期化されると、このような状況が発生することがあります。たとえば、存在しないデータベース行をメッセージが参照する場合(またはその逆)などです。これにより、重複メッセージに加えて未処理のメッセージが削除されることがあります。
ストアがJMS専用でない場合は、Oracle WebLogic Server JMSメッセージ管理ツールを使用します。このツールを使用して、管理コンソール、MBeanおよびWLSTからインポート、エクスポート、移動および削除の各操作を行うことができます。
アプリケーションがキューとトピックの両方を使用する場合は、キューとトピックの両方のサブスクリプションを処理してください。
JMSデータの重要性が高い場合には、同期レプリケーションを使用して、トランザクション・ログ・データとJMSデータをリアル・タイムで同期化することをお薦めします。同期レプリケーションを使用するとパフォーマンスに影響する場合があることに注意してください。
各層間でのデータの整合性が重要な場合は、データベース層とアプリケーション層が同時にレプリケートされていることを確認します。こうすると、異なる層をまったく同じ時点でリカバリできるようにするために役立ちます。
データベース・ベースの永続ストアを使用している場合は、Oracle Data Guardを使用して、プライマリ・サイトとスタンバイ・サイトをレプリケートします。
ブロックレベルのスナップショット機能をサポートしていないストレージ・デバイスを使用している場合は、JMSサーバーを停止して、一貫性バックアップを作成します。これにより、コピー操作の実行中に永続ストアへの書込みが行われないようになります。クラスタ環境の場合は、一度に1つのサーバーを停止し、バックアップを作成して、再起動します。WLSTを使用してこれらの操作を実行するスクリプトを作成することもできます。
WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーとともに、永続ストアを含むデータベース・スキーマを直近の時点にリカバリします。
さらに、重複メッセージを回避するために、リカバリに関する次の推奨事項に従います。
リカバリの前に次の手順を実行して、永続ストアのリカバリ後にJMSキュー内のメッセージを排出し、重複メッセージの処理を回避します。
|
注意: メッセージを排出および破棄する前に、保存の必要なデータがメッセージに含まれていないことを確認してください。リカバリしたメッセージには、処理済の重複メッセージに加えて、重要なアプリケーション・データが含まれる未処理のメッセージが含まれている可能性があります。 |
Oracle WebLogic Server管理コンソールにログインします。
リカバリを実行する前に、起動時の生成、挿入および消費の各操作を休止するようにJMSサーバーを構成します。これは、新しいメッセージが生成されたり宛先に挿入されたりしないようにするため、または失効したメッセージを排出する前に宛先から消費されないようにするためです。その手順は次のとおりです。
「サービス」→「メッセージング」→「JMSサーバー」を開きます。
「JMSサーバーのサマリー」ページで、メッセージの休止を構成するJMSサーバーをクリックします。
「構成: 全般」ページで「詳細」をクリックして、メッセージの休止オプションを定義します。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。
「保存」をクリックします。
前述の変更をアクティブ化するには、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。
リカバリ後に実行する手順は次のとおりです。
永続ストアのリカバリ後に、管理対象サーバーを起動します。
次の手順を実行して、失効したメッセージをJMS宛先から排出します。
「サービス」→「メッセージング」→「JMSモジュール」を開きます。
JMSモジュールを選択して、宛先を選択します。
「監視」→「メッセージの表示」を選択します。
「すべて削除」をクリックします。
次の手順を実行して、操作を再開します。
「サービス」→「メッセージング」→「JMSサーバー」を開きます。
「JMSサーバーのサマリー」ページで、メッセージの休止を構成するJMSサーバーをクリックします。
「構成: 全般」ページで「詳細」をクリックします。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。
「保存」をクリックします。
前述の変更をアクティブ化するには、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。
この項では、様々なOracle Platform Security Servicesアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Platform Security Servicesにはデータベース依存性がないため、適用されません。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをリカバリします。
Oracle ADFは、Java Platform, Enterprise Edition(Java EE)標準やオープンソース・テクノロジに基づいて、サービス指向アプリケーションの実装を簡略化および高速化するエンドツーエンド・アプリケーション・フレームワークです。Oracle ADFは、Web、ワイヤレス、デスクトップまたはWebサービス・インタフェースを使用してデータを検索、表示、作成、変更および検証するアプリケーションを作成するエンタープライズ開発者に適しています。
この項では、様々なOracle ADFアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、Oracle ADFドメインの構成データおよびアプリケーションが含まれます。
カスタム・アプリケーション・ディレクトリ: これは、様々なカスタム・アプリケーションおよび関連ライブラリのストレージの場所です。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、アプリケーションへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。
Oracle ADFアプリケーションでは、MDSリポジトリを使用してアプリケーション・ステータスと構成データが保持される場合があります。データが保持されるかどうかは、アプリケーションがどのようにコード化されているかによって異なります。
ほとんどのOracle ADFアプリケーションは、アプリケーション・データの格納にMDSリポジトリを使用することはなく、その代わりに別のデータ・ストア(通常はデータベース)を使用してアプリケーション・データを格納します。
構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
ADFまたはWebCenterアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Portalは、Java Server Faces(JSF)の標準ベースの宣言型開発機能と、ポータルの柔軟性とパワー、および一連の統合されたWeb 2.0サービスを組み合せたものです。
Oracle WebCenter Portalの共通アーティファクトと考慮事項
製品固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle WebCenter Portal製品に適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle WebCenter Portalバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、Oracle WebCenter Portalドメインの構成データが含まれます。
Oracle WebCenter Portalデータベースの一部であるOracle WebCenter Portalメタデータには、一部のOracle WebCenter Portalサービスのデータが格納され、MDSリポジトリには、WebCenterのメタデータおよび構成情報が格納されます。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Portal製品へのアクセスに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、Oracle WebCenter Portalスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
Oracle WebCenter Portalアプリケーションを実行している管理対象サーバーとともに、Oracle WebCenter Portalスキーマを含むデータベースを直近の時点にリカバリする必要があります。
この項の残りの部分では、次のOracle WebCenter Portal製品の障害時リカバリに関する推奨事項を示します。
Oracle WebCenter Portal: Spacesは、一連の強力なサービスとアプリケーションによって、ソーシャル・ネットーワーク、通信、コラボレーションおよび個人の生産性向上を実現する、統合された単一のWebベース環境を提供します。
この項では、様々なSpacesアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
WEBCENTERスキーマには、一部のOracle WebCenter Portalサービスのデータが格納され、MDSリポジトリには、WebCenter Portalのメタデータおよび構成情報が格納されます。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、WEBCENTERスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenter Portalドメインとともに、WebCenter PortalスキーマとMDSリポジトリを含むデータベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Portalは、標準ベースのポートレット(JSR 168、WSRP 1.0および2.0)と、従来のOracle PDK-Javaベースのポートレットの両方のデプロイメントと実行をサポートしています。Oracle WebCenter Portalには、OmniPortlet、Webクリッピング、リッチ・テキスト・ポートレット、WSRPツールなど、すぐに使用可能なプロデューサがいくつか用意されています。
この項では、様々なポートレット・プロデューサ・アーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle WebCenter Portalスキーマの一部であるPORTLETスキーマには、ユーザー・カスタマイズが格納され、MDSリポジトリには、ポートレットのメタデータおよび構成情報が格納されます。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、PORTLETスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenter Portalドメインとともに、PORTLETスキーマとMDSリポジトリを含むデータベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Portalのディスカッション・サーバーは、ディスカッション・フォーラムとお知らせをアプリケーションに統合する機能を提供します。
この項では、様々なディスカッション・サーバー・アーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle WebCenter Portalスキーマの一部であるDISCUSSIONSスキーマには、メタデータとデータが格納されます。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、DISCUSSIONSスキーマとメタデータ・リポジトリを含むOracle Database用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenter Portalドメインとともに、ディスカッション・サーバー・スキーマを含むデータベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Contentサーバーは、WikiとブログをWebCenter Portalアプリケーションに統合する機能を提供します。アプリケーション・ユーザーが各自のWikiとブログを作成できるようにするための機能もサポートします。
この項では、様々なOracle WebCenter Wiki and Blog Serverアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle WebCenter Portalスキーマの一部であるOCSERVERスキーマには、メタデータとデータが格納されます。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、OCSERVERスキーマを含むOracle Database用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenter Portalドメインとともに、OCSERVERスキーマを含むデータベースを直近の時点にリカバリする必要があります。
ポータル管理者およびビジネス所有者は、Oracle WebCenter PortalのAnalyticsコレクタによって、ポータルの使用状況を追跡して分析できます。
この項では、バックアップおよびリストアが必要なOracle WebCenter PortalのAnalyticsコレクタのデータについて説明します。
構成ファイル
構成情報は、AnalyticsスキーマのACTIVITIESに格納されます。
データベース・リポジトリに依存するもの
ACTIVITIESスキーマおよびMDSスキーマ
バックアップに関する推奨事項
Oracleホーム、ドメイン・ホーム、およびACTIVITIESスキーマとMDSスキーマが含まれるデータベースをバックアップします。
リカバリに関する推奨事項
Oracleホームおよびドメイン・ホームをリカバリします。
必要に応じて、データベースを直近の時点にリカバリします。
Oracle WebCenter Portalアクティビティは、WebCenter Portalのサービスであり、ユーザーが関心を寄せている可能性のある人、項目および空間を提案します。アクティビティ・グラフ・サービスで使用するエンジンは、エンタープライズ・アプリケーションによって収集されるアクション用の中央リポジトリを提供します。アクティビティ・グラフに格納されたデータは、分析され、ノードのランクの計算、新しいアクションの予測および推奨事項の作成に使用されます。
この項では、バックアップおよびリストアが必要なOracle WebCenter Portalアクティビティ・グラフのデータについて説明します。
構成ファイル
構成情報は、ACTIVITIESスキーマに格納されます。
データベース・リポジトリに依存するもの
ACTIVITIESスキーマ
バックアップに関する推奨事項
Oracleホーム、ドメイン・ホーム、およびACTIVITIESスキーマが含まれるデータベースをバックアップします。
リカバリに関する推奨事項
Oracleホームおよびドメイン・ホームをリカバリします。
必要に応じて、データベースを直近の時点にリカバリします。
Oracle SOA Suiteは、Oracle Fusion Middlewareのミドルウェア・コンポーネントです。Oracle SOA Suiteにより、SOAコンポジット・アプリケーションを設計、デプロイおよび管理するサービス・インフラストラクチャ・コンポーネントの完全なセットが提供されます。Oracle SOA Suiteでは、サービスの作成および管理、SOAコンポジット・アプリケーションへの編成が可能です。コンポジットにより、複数のテクノロジ・コンポーネントを1つのSOAコンポジット・アプリケーションに組み込むことができます。SOAコンポジット・アプリケーションは、次のものから構成されています。
サービス・コンポーネント: サービス・コンポーネントとは、SOAコンポジット・アプリケーションの基本となるビルディング・ブロックです。サービス・コンポーネントにより、SOAコンポジット・アプリケーション全体のビジネス・ロジックの一部が実装されます。サービス・コンポーネントの例としては、Oracle BPEL Process Manager、Oracle Mediator、Oracle Human Workflow、Oracle Business Rulesなどがあります。
バインディング・コンポーネント: バインディング・コンポーネントは、SOAコンポジット・アプリケーションを外部サービス、アプリケーションおよびテクノロジに接続します。バインディング・コンポーネントは、次の2つのグループから構成されています。
サービス: SOAコンポジット・アプリケーションへのエントリ・ポイントを外部に提供します。サービスのWSDLファイルによって、そのサービスの機能が外部のアプリケーションに通知されます。サービスのバインディングでは、SOAコンポジット・サービスをどのように呼び出すことができるか(例: SOAP経由で)が定義されます。
参照: SOAコンポジット・アプリケーションから外部のサービスにメッセージを送信できます(たとえば、パートナ・リンクがBPELプロセスに対して提供するものと同じ機能であっても、より高度なSOAコンポジット・アプリケーション・レベルで提供されます)。
|
注意: Oracle SOA Suiteリリース11.1.1.1では、soa-infraおよびサービス・エンジン構成ファイルは、ドメイン構成の一部としてローカルまたは共有のストレージ・ファイルに格納されていました。 Oracle SOA Suite 11.1.1.2以降、これらのファイルは、メタデータ・リポジトリに移動されています。そのため、soa-infraおよびサービス・エンジン構成変更は、クラスタ全体に即座に伝播されるようになりました。 Oracle SOA Suite 11.1.1.3では、Oracle BPM SuiteをSOA Suiteインストール上にデプロイできます。 Oracle SOA Suiteの障害時リカバリに関する推奨事項では、Oracle SOA Suite 11.1.1.2を使用しているものと想定しています。 |
Oracle SOA Suiteアーティファクトは、メタデータ・リポジトリだけでなく、ローカルまたは共有のファイル・システムに格納されます。コンポジット・アーティファクトは、メタデータ・リポジトリに格納され、バイナリおよびドメイン関連の構成ファイルは、ローカルまたは共有のファイル・システムに格納されます。
すべてのSOA Suiteコンポーネントの共通アーティファクトと考慮事項
コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのSOA Suiteコンポーネントに適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle SOA Suiteバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、SOAドメインの構成データおよびSOAコンポジットが含まれます。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。IPアドレスを仮想ホスト名に更新する手順については、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
本番サイトとスタンバイ・サイトの両方で、SOA Suiteコンポーネントへのアクセスに必要なロード・バランサの仮想ホストを構成する必要があります。
Oracle SOA Suiteスキーマ、サービス・インフラストラクチャとサービス・エンジンの構成、およびコンポジット定義は、Oracle SOA Suiteのデータベースとメタデータ・リポジトリに格納されます。
ドメイン関連の構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
データベースを直近の時点にリカバリして、最新のコンポジット定義および進行中のインスタンスがリストアされるようにする必要があります。
進行中のインスタンスで処理が続行されるようにするには、コンポジット定義が一致している必要があります。このため、メタデータ・リポジトリ(コンポジット定義が格納されている場所)とOracle SOA Suiteデータベース(プロセス・ステータスが維持される場所)は、同じ時点にリカバリされる必要があります。
再デプロイされたコンポジットの場合、データベース・リカバリにより、デハイドレーションされた進行中のプロセスと、対応するそれらの定義間の一貫性が確保されます。これは、デハイドレーションされたインスタンスが格納されているデータベース・リポジトリにプロセス定義が格納されているからです。
この項では、次のOracle SOA Suiteコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracle SOA Service Infrastructureは、Oracle Fusion Middleware SOA Suiteを実行するための基礎となるサービスを提供するJava EEアプリケーションです。このJava EEアプリケーションは、Oracle Fusion Middleware SOA Suiteのインストール時に自動的にデプロイされるランタイム・エンジンです。コンポジット(サービス・コンポーネント・アーキテクチャ内の基本アーティファクト)をOracle SOA Infrastructureにデプロイすると、コンポジットの実行に必要なサービスが提供されます。Oracle SOA Infrastructureは、コンポジット用のデプロイメント、接続およびスレッド管理サービスを提供します。これらのサービスにより、コンポジットのライフサイクルとランタイム操作が維持されます。
この項では、様々なOracle SOA Service Infrastructureアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
コンポジット定義と構成ファイルは、MDSリポジトリに格納されます。コンポジット・インスタンス・ステータスの永続性は、SOA Service Infrastructureデータベース内に格納されます。
ドメイン関連の構成の変更、コンポジットのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
データベースを直近の時点にリカバリして、最新のコンポジット定義および進行中のインスタンスがリストアされるようにする必要があります。
Oracle BPEL Processエンジンは、BPELプロセスの実行を可能にする、SOA Service Infrastructure内で実行されるサービス・エンジンです。BPELプロセスは、一連の独立したサービスをエンドツーエンドのプロセス・フローに組み込み、エンドツーエンドのBPELプロセス・フローへの同期および非同期サービスを開発するための標準を提供します。それは、長時間実行される非同期プロセスのプロセス編成および格納を可能にします。
この項では、様々なOracle BPEL Process Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
プロセス定義と構成ファイルは、MDSリポジトリに格納されます。BPELプロセス・ステータスの永続性は、Oracle SOA Suiteデータベース内に格納されます。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
データベースを直近の時点にリカバリして、最新のプロセス定義および進行中のインスタンスがリストアされるようにする必要があります。Oracle BPEL Process Managerの冪等プロセスを使用すると、障害時リカバリ操作の実行後にクリーンアップする必要がないため、これを使用することをお薦めします。冪等以外のOracle BPEL Process Managerプロセスを使用する場合は、障害時リカバリ操作の実行後に、デハイドレーション・ストアからプロセスをクリーンアップする必要があります(特に、プロセスが進行中の場合)。
Oracle Mediatorは、Oracle SOA Service Infrastructure内のサービス・エンジンです。Oracle Mediatorは、様々なプロバイダとサービスやイベントのコンシューマの間を仲介するフレームワークを提供します。Mediatorサービス・エンジンは、SOA Service Infrastructure Java EEアプリケーションとともに実行されます。
この項では、様々なOracle Mediatorアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Mediatorサービス・エンジンは、パラレル・ルーティング・ルールの非同期ルーティングのために、メッセージをデータベース内に格納します(順次ルーティング・ルールでは、実行時にメッセージがデータベース内に保持されることはありません)。Mediatorコンポーネント・インスタンス・ステータスおよび監査の詳細もデータベース内に格納されます。
メタデータ・リポジトリには、コンポジット定義の一部としてMediatorコンポーネント定義が格納されます。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
管理サーバー、およびsoa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。
Oracle Human Workflowは、人間による対話型プロセスの実行を可能にする、Oracle SOA Service Infrastructure内で実行されるサービス・エンジンです。ヒューマン・ワークフローは、プロセス内またはプロセス外で承認、拒否、再割当てアクションなどの人間による対話型のアクションをサポートします。Human Workflowサービスは、人間がビジネス・プロセスに関するさまざまな操作を実行できるようにするためのいくつかのサービスで構成されています。
この項では、様々なOracle Human Workflowアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
ヒューマン・ワークフロー・インスタンス・データおよび他のワークリスト・データ(休暇ルール、グループ・ルール、フィールド・マッピング、ビュー定義など)は、データベース内に格納されます。
メタデータ・リポジトリは、SOAコンポジットによって使用される共有のヒューマン・ワークフロー・サービス定義およびスキーマの格納に使用されます。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle Human Workflowのエンジンは、Oracle User Messaging Serviceを使用して通知を送信および取得します。Oracle User Messaging Serviceの詳細は、第2.4.7項「Oracle User Messaging Serviceに関する推奨事項」を参照してください。
Oracle B2Bは、SOAコンポジット・アプリケーションを外部サービス、アプリケーションおよびテクノロジに接続します。Oracle B2Bは、業界が認めるB2B標準対応マルチプロトコル・ゲートウェイを提供します。Oracle B2Bは、Oracle SOA Suiteを、電子データ交換(EDI)、ebXML、HL7、RosettaNetなどのビジネス・プロトコル標準で拡張します。Oracle B2Bは、SOA Service Infrastructure内のバインディング・コンポーネントとして実装されます。
この項では、様々なOracle B2Bアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
JMS ストア: ファイルベースのJMS永続ストアを含むボリューム。表2-1に、Oracle B2Bによって内部的に使用されるJMSキューおよびトピックを示します。
表2-1 Oracle B2Bによって使用されるJMSキューおよびトピック
| JMSアーティファクト名 | タイプ | JNDI名 |
|---|---|---|
|
|
分散キュー |
|
|
|
分散キュー |
|
|
|
分散キュー |
|
|
|
分散トピック |
|
Oracle B2Bメッセージおよびメッセージ・ステータスの永続性は、パートナ、ドキュメントおよびチャネル定義とともに、Oracle SOA Suiteデータベース内に格納されます。メタデータ・リポジトリは、Oracle B2Bメタデータの格納に使用されます。
これらのアダプタを使用する場合は、スタンバイ・サイトで外部FTPサーバーおよび電子メール・サーバーが使用可能である必要があります。
Oracle B2B JMSキューの同期化とリカバリの詳細は、第2.1.1項「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle B2Bは、JMSキューおよびSOAランタイム・データベース内に状態情報を格納するので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが正常に実行されるようになります。
Oracle Web Services Manager(Oracle WSM)は、組織全体でWebサービスを一貫して管理および保護するポリシー・フレームワークを提供します。それは、セキュリティ、WSRM、MTOM、アドレス指定ポリシーなどのWeb Serviceポリシーを構築、適用、実行および監視する機能を提供します。Oracle Web Services Managerは、ポリシー・マネージャとエージェントから構成されています。
ポリシー・マネージャは、MDSリポジトリから、事前定義されたポリシーとカスタム・ポリシーを含め、セキュリティおよび管理ポリシーの読取りおよび書込みを行います。ポリシー・マネージャは、ステートレスJava EEアプリケーションです。ステートレス・セッションBeanによって、その機能が公開されます。ポリシー・マネージャはデータをキャッシュしませんが、基礎となるMDSインフラストラクチャはデータをキャッシュします。
エージェントは、ポリシーの適用と実行、および実行時統計の収集を行います。エージェントは、すべてのOracle Fusion Middleware管理対象サーバー上で使用可能であり、保護対象のアプリケーションと同じサーバー上に構成されます。エージェントは、ポリシー・アクセス・ポイント(PAP)とポリシー・インターセプタの2つから構成されています。
この項では、様々なOracle Web Services Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
MDSリポジトリは、ポリシーの格納に使用されます。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。すべてのポリシーはMDSリポジトリ内に格納されるので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが正常に実行されるようになります。
Oracle User Messaging Service(Oracle UMS)は、ユーザーとデプロイ済アプリケーション間の双方向通信を可能にします。電子メール、IM、SMS、テキストから音声に変換したメッセージなど、様々なチャネルに対応しています。Oracle User Messaging Serviceは、Oracle BPEL PM、Oracle Human Workflow、Oracle BAM、Oracle WebCenter PortalなどのOracle Fusion Middlewareコンポーネントに統合されます。通常、これは、Oracle SOAサービス・インフラストラクチャとともにデプロイされます。Oracle User Messaging Serviceは、UMSサーバー、UMSドライバおよびUMSクライアント・アプリケーションで構成されています。
この項では、様々なOracle User Messaging Serviceアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
JMS ストア: ファイルベースのJMS永続ストアを含むボリューム。表2-2に、Oracle User Messaging Serviceによって内部的に使用されるJMSリソースを示します。
表2-2 Oracle User Messaging Serviceによって使用されるJMSリソース
| JMSアーティファクト名 | タイプ | JNDI名 |
|---|---|---|
|
|
分散キュー |
|
|
|
分散キュー |
|
|
|
分散キュー |
|
|
|
分散キュー |
|
|
|
分散キュー |
|
|
|
分散キュー |
|
Oracle User Messaging Serviceは、外部データベース・リポジトリを使用してメッセージおよび構成の状態を維持管理します。
Oracle User Messaging Serviceは、JMSを使用して、メッセージング・アプリケーション間にメッセージを配信します。デフォルトでは、ファイルベースの永続性JMSストアを使用するように構成されているので、それらのファイルが配置されているストレージ・デバイスに依存します。
構成の変更、追加のOracle User Messaging Serviceドライバのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
usermessagingserverアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。Oracle User Messaging Serviceは、外部データベース・リポジトリ内にメッセージおよび構成の状態を保持し、JMSキュー内にメッセージを保持するので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが問題なく機能するようになります。JMSデータの同期化に関する推奨事項は、第2.1.1項「Oracle WebLogic Server JMSおよびトランザクション・ログに関する考慮事項」の「同期化に関する推奨事項」を参照してください。
Oracle JCA Adaptersは、Service Infrastructureが異なるプロトコルを使用してエンドポイントと通信できるようにするJCAバインディング・コンポーネントです。Oracle JCA Adaptersは、Oracle SOA Service Infrastructureの一部としてではなく、JCAリソース(RAR)の一部としてデプロイされます。
Oracle JCA Adaptersには、次のような幅広いカテゴリのものがあります。
Oracleテクノロジ・アダプタ
レガシー・アダプタ
パッケージ化されたアプリケーションのアダプタ
Oracleアプリケーション用のOracleアダプタ
Oracle JCA Adaptersのタイプの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。
この項では、様々なOracle JCA Adapterアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
特定のアダプタは、その特性に応じて、ローカルまたは共有のストレージ・ファイルを使用します。例:
ファイルベースの永続ストアとともにWebLogic JMSを使用するJMSアダプタ: フェイルオーバー後に処理を再開するには、永続ストアがスタンバイ・サイトと同期化される必要があります。
FileアダプタまたはFTPアダプタのいずれかからのインバウンドおよびアウトバウンド・ファイル: フェイルオーバー後に処理を再開するには、関連ファイルがスタンバイ・サイトと同期化される必要があります。
アダプタ構成は、ear JCAリソース(RAR)のweblogic-ra.xmlデプロイメント・ディスクリプタ内に保持されます。各weblogic-ra.xmlのファイルの場所は、ファイルの作成時に管理者によって決定されており、スタンバイ・サイトにレプリケートされる必要があります。
アダプタ・アーティファクトは、コンポジット・プロジェクトの一部として設計時に生成されます。これらのアーティファクトは、残りのコンポジット定義とともにメタデータ・リポジトリに格納されます。
ドメイン関連の構成の変更(つまり、アダプタ構成の変更)後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
JCAアダプタを実行している管理対象サーバーおよび管理サーバーとともに、データベースを直近の時点にリカバリする必要があります。
Oracle Business Activity Monitoring(BAM)は、エンタープライズ内のビジネス・サービスおよびプロセスを監視するためのツールを提供します。これにより、市場の指標を実際のビジネス・プロセスと相関させることや、ビジネス・プロセスをすばやく変更したり、ビジネス環境の変化に応じて修正を加えたりすることが可能になります。Oracle BAMは、ダッシュボード(リアルタイムのデータ流入を表示し、特定の状況でアラートを送信するためのルールを定義する場所)の作成に必要なツールとランタイム・サービスを提供します。
この項では、様々なOracle BAMアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle BAMデータおよびレポート・メタデータは、Oracle BAMスキーマを含むOracle BAMデータベース内に格納されます。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、BAMスキーマとメタデータ・リポジトリを含むOracle SOA Suiteデータベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle BAMを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。
Oracle Business Process Management(BPM) Suiteは、ビジネス・プロセスを中心にしたビジネス・アプリケーションを開発、管理および使用するための統合環境を提供します。それは、設計時および実装からランタイムおよびアプリケーション管理まで、アプリケーション開発ライフサイクルの全ステージをシームレスに統合します。
Oracle BPM SuiteはOracle SOA Suiteの上位レイヤーになり、次を含む製品コンポーネントの多くを共有しています。
Oracle Business Rules
ヒューマン・ワークフロー
統合のためのOracleアダプタ・フレームワーク
SOAコンポジット・アーキテクチャ
この項では、様々なOracle BPMアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
ファイル・システム上のアーティファクト
BPM JMS永続ストア(BPMJMSFileStore_auto): ファイルベースのJMS永続ストア。フェイルオーバー後に処理を再開するには、永続ストアがスタンバイ・サイトと同期化される必要があります。
プロセス定義、デプロイ済アプリケーションおよび構成ファイルは、メタデータ・サービス(MDS)リポジトリに格納されます。Oracle BPMでは、プロセス・アナリストとプロセス開発者の間でプロジェクトとプロジェクト・テンプレートを共有するために、別のMDSパーティションも使用します。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle SOA Suiteデータベースおよびメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始されると、スタンバイ・データベースも同じ時点まで更新されます。スナップショット・スタンバイ・データベースが使用される場合は、これをお薦めします。
soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。
Oracle Identity Management製品では、様々なサーバー間でユーザー、デバイスおよびサービスのアイデンティティを構成および管理し、それらのアイデンティティの管理を委任して、エンド・ユーザーにセルフサービス権限を付与することができます。これらの製品を使用して、アプリケーション間でシングル・サインオンを構成し、ユーザーの資格証明を処理して、有効な資格証明を持つユーザーのみがログインし、オンライン・リソースにアクセスできるようにすることが可能です。
すべてのOracle Identity Managementコンポーネントの共通アーティファクトと考慮事項
コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle Identity Managementコンポーネントに適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle Identity Managementバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびアイデンティティ管理アプリケーションが含まれます。
Oracleインスタンス: Oracleインスタンスには、Oracle Internet DirectoryやOracle Virtual Directoryなどの非J2EEアイデンティティ管理アプリケーションの構成データが含まれます。OPMN構成データとEnterprise Managerエージェント構成データも含まれます。
アイデンティティ管理スキーマは、アイデンティティ管理データベース内にあります。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、アイデンティティ管理コンポーネントへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
該当のアイデンティティ管理コンポーネントとともに、アイデンティティ管理スキーマを含むデータベースを直近の時点にリカバリする必要があります。
この項の残りの部分では、次のOracle Identity Managementコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracle Internet Directoryは、分散するユーザー、ネットワーク構成および他のリソースに関する情報の迅速な取得と一元管理を可能にするLDAPバージョン3対応のサービスです。
この項では、様々なOracle Internet Directoryアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Internet Directoryによって使用されるODSおよびODSSMスキーマは、アイデンティティ管理データベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle Internet Directoryに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Internet DirectoryをODSおよびODSSMスキーマと一緒に最新の時点にリカバリする必要があります。
Oracle Virtual Directoryは、1つ以上のエンタープライズ・データソースの抽象化されたビューを提供するLDAPバージョン3対応のサービスです。Oracle Virtual Directoryは、複数のデータソースを単一のディレクトリ・ビューに統合し、LDAP対応アプリケーションを様々なディレクトリ・サーバーのデータ・ストアに統合することを可能にします。
この項では、様々なOracle Virtual Directoryアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Virtual Directoryには、データベース依存性はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle Virtual Directoryに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Virtual Directoryインスタンスをリカバリします。
Oracle Directory Integration Platformは、他のディレクトリまたはデータベースとOracle Internet Directoryの間でデータを同期化できるようにするJ2EEアプリケーションです。Oracle Directory Integration Platformは、他のエンタープライズ・リポジトリとともに同期化ソリューションをデプロイできるようにするためのサービスとインタフェースを提供します。また、これを使用して、サード・パーティのメタディレクトリ・ソリューションとOracle Internet Directoryの相互運用性を実現することもできます。
この項では、様々なOracle Directory Integration Platformアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
ODSおよびODSSMスキーマは、アイデンティティ管理データベースの一部です。Quartzジョブは、ODSSMスキーマ内にあります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層およびデータ層をスタンバイ・サイトと同期化する必要があります。
Oracle Directory Integration Platformアプリケーションを実行している管理対象サーバーおよび関連付けられたOracle Internet Directoryインスタンスとともに、Oracle Internet DirectoryをODSおよびODSSMスキーマと一緒に直近の時点にリカバリする必要があります。
企業では、Oracle Identity Federationを使用して、個々のセキュリティ・ドメイン間におけるサービスの提供とアイデンティティの共有、および許可されていないアクセスからの保護を実現できます。
この項では、様々なOracle Identity Federationアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Identity Federationは、アイデンティティ管理データベースの一部であるOIFスキーマを使用します。RDBMSユーザー・ストア、構成ストア、Federationストア、メッセージ・データ・ストアまたはセッション・ストアがOracle Identity Federation用に構成されている場合、これらのストアは、外部データベースに格納されます。
本番サイトとスタンバイ・サイトの両方で、Oracle Identity Federation用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Identity Federationアプリケーションを実行している管理対象サーバーとともに、Oracle Identity Federationスキーマを含むデータベースとデータ・ストアを直近の時点にリカバリする必要があります。
Oracle Directory Services Managerは、Oracle Virtual DirectoryとOracle Internet Directoryのための統合されたグラフィカル・ユーザー・インタフェース(GUI)です。Webベースのフォームおよびテンプレートを使用できるようにすることで、Oracle Virtual DirectoryとOracle Internet Directoryの管理と構成を簡略化します。
この項では、様々なOracle Directory Services Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Directory Services Managerアプリケーションにはデータベース依存性がないため、適用されません。
本番サイトとスタンバイ・サイトの両方で、Oracle Directory Services Manager用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
管理サーバーとともに、Oracle Directory Services Managerアプリケーションを実行している管理対象サーバーをリカバリします。
Oracle Access Managerは、Webシングル・サインオン、ユーザーのセルフサービスと自己登録、高度なワークフロー機能、監査とアクセス・レポート、ポリシー管理、動的グループ管理、委任管理など、広範なアイデンティティ管理およびセキュリティ機能を提供します。
この項では、様々なOracle Access Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Access Managerは、Oracle Identity Managementデータベースの一部であるOAM、IAU(Audit Services)スキーマおよびODSスキーマ(Oracle Internet Directory用)を使用します。
Oracle Access Managerは、構成およびユーザー情報をOracle Internet Directoryに格納します。
特別な考慮事項
Oracle Access Managerコンソールは、ドメインの管理サーバーにデプロイされます。本番サイトとスタンバイ・サイトの両方で、Oracle Access Manager用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Access Managerアプリケーションを実行している管理対象サーバー、管理サーバーおよび関連するOracle Internet Directoryインスタンスをリカバリします。OAM、IAUおよびODSスキーマを、最新の時点にリカバリする必要があります。
Oracle Adaptive Access Managerは、エンタープライズ向けにWebアクセスのリアルタイム不正検出およびオンライン多要素認証セキュリティを提供するOracle Identity Managementのソリューションです。Oracle Adaptive Access Managerは、異機種が混在する複雑なエンタープライズ環境をサポートするように設計されています。
この項では、様々なOracle Adaptive Access Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Adaptive Access Managerは、Oracle Identity Managementデータベースの一部であるOAAM、OAAM PARTN、MDS、IAU(Audit Services)およびODS(Oracle Internet Directory)スキーマを使用します。
パーティション・スキーマ・サポート付きのOracle Adaptive Access Managerの場合、 Identity Management - Oracle Adaptive Access Manager (パーティション・サポート) スキーマを選択します。デフォルトで、 AS共通スキーマ - メタデータ・サービス ・スキーマも選択されます。
Oracle Adaptive Access Managerは、構成およびユーザー情報をOracle Internet Directoryに格納します。
本番サイトとスタンバイ・サイトの両方で、Oracle Adaptive Access Manager用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Adaptive Access Managerアプリケーションを実行している管理対象サーバーおよび関連するOracle Internet Directoryインスタンスをリカバリします。OAAM、OAAM_PARTN、MDS、IAUおよびODSスキーマを、最新の時点にリカバリする必要があります。
Oracle Identity Managerは、ユーザー・プロビジョニングおよび管理ソリューションです。これによって、アプリケーションやディレクトリに対してユーザー・アカウントの追加、更新および削除を行うプロセスが自動化されます。さらに、どのユーザーがどのアプリケーションにアクセスできるかを特定するきめ細かいレポートと証明サポートを提供し、法規制のコンプライアンスが向上します。Oracle Identity Managerは、スタンドアロン製品として、またはOracleのIdentity and Access Management Suiteの一部として使用可能です。
Oracle Identity Managerは、ワークフローにOracle SOAを使用します。また、Oracle SOAの障害時リカバリに関する推奨事項にも従う必要があります。詳細は、「Oracle SOA Suiteに関する推奨事項」を参照してください。
この項では、様々なOracle Identity Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
ファイル・システム上のアーティファクト
JMS ストア: ファイルベースのJMS永続ストアを含むボリューム。
Oracle Identity Managerは、Oracle Identity Managementデータベースの一部であるOIM、SOAINFRA、ORASPDMおよびMDSスキーマを使用します。
スタンドアロン・モードで使用した場合、Oracle Identity Managerは、外部のLDAPストアには依存しません。LDAP同期が有効なときや、Oracle Access ManagerまたはOracle Identity Federationに統合されているときは、Oracle Identity Managerは外部LDAPストアとユーザーを同期します。
本番サイトとスタンバイ・サイトの両方で、Oracle Identity Manager用のロード・バランサの仮想ホストを構成する必要があります。
Oracle Identity ManagementとSOA管理対象サーバーは、浮動IPアドレスをリスニングするように構成されています。これは、サーバー移行のために必要です。本番サイトとスタンバイ・サイトの両方で、浮動IPアドレスが同じ仮想名で構成されていることを確認してください。
Oracle Identity Managerのコネクタはファイルベースです。これらは、別のエンタープライズ・アプリケーションのレコードをプロビジョニングまたは調整するために使用されます。Oracle Identity Managerおよびアプリケーションでコネクタが使用可能なことを確認してください。
Oracle Identity Managementは、JMS永続性ストアにも依存しています。詳細は、「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
JMS永続性ストアの詳細は、「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。
Oracle Identity Managerアプリケーションを実行している管理対象サーバーおよび関連するOracle Internet Directoryインスタンスをリカバリします。OIM、SOAINFRA、ORASPDMおよびMDSスキーマを、最新の時点にリカバリする必要があります。LDAP同期が有効なとき、Oracle Identity ManagementはODSスキーマに依存します。その場合は、ODSも最新の時点にリカバリしてください。
Oracle Identity Navigatorは、Oracle Identity Managementの全製品のアプリケーション・コンソールとして機能するように設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。Oracle Identity Navigatorにはブラウザ経由でアクセスし、これを使用してOracle Access Manager、Oracle Adaptive Access Manager、Oracle Identity Manager、Directory Services(ODSM)およびその他のOracle Identity Managementのサービスのコンソールにアクセスします。これらのコンソールに接続するようにOracle Identity Navigatorを構成するには、直接URLを指定するか、製品検出機能を使用します。Oracle Identity Management Navigatorを使用すると、Oracle Identityのすべてのコンソールを1つのサイトから簡単に管理できます。
この項では、様々なOracle Identity Navigatorアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Identity Navigatorでは、スキーマは使用しません。
Oracle Identity Navigatorは、構成情報をLDAPストアに格納します。
特別な考慮事項
本番サイトとスタンバイ・サイトの両方で、Oracle Identity Navigator用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Identity Navigatorアプリケーションを実行している管理サーバーをリカバリします。
この項では、次のOracleコンポーネント・スイートのアーティファクトおよび障害時リカバリに関する推奨事項を示します。
Oracle Portal
Oracle Forms
Oracle Reports
Oracle Business Intelligence Discoverer(Discoverer)
Oracle Portal、Forms、ReportsおよびDiscovererの共通アーティファクトと考慮事項
この項で示すアーティファクトと考慮事項は、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererに共通です。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererのバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびOracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererアプリケーションが含まれます。
Oracleインスタンス: Oracleインスタンスには、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererコンポーネントの構成データが含まれます。OPMNとEMAgentの構成データも含まれます。
データベース・メタデータ・リポジトリには、Oracle Portal、Oracle ReportsおよびDiscovererコンポーネント・スキーマおよびユーザー構成済データベースが含まれます。
データベース・メタデータ・リポジトリ(RCU)にはOracle Formsコンポーネント・スキーマはありませんが、Oracle Forms経由でアクセスされているユーザー構成済データベース内に顧客データが存在する可能性があります。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
Oracle Portal、Oracle ReportsおよびDiscovererコンポーネント・スキーマを含むデータベースを最新の時点にリカバリする必要があります。Oracle Portal、Oracle Forms、Oracle ReportsおよびDiscovererコンポーネント・アプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。
この項の残りの部分では、次のコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracle Portalは、Oracle Fusion Middlewareと密接に統合されたポータルを構築、デプロイおよび管理するするための完全なポータル・フレームワークを提供します。Oracle Portalは、ポータルWebインタフェースを作成して動的データにアクセスするための機能豊富な宣言型環境を、Java EEベースのエンタープライズ・アプリケーションにアクセスするための拡張可能なフレームワークとともに提供します。
この項では、様々なOracle Portalアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Portal、Portal_Demo、Portal_App、Portal_PublicおよびPortal_Approvalスキーマは、Oracle Portalメタデータ・リポジトリの一部です。
本番サイトとスタンバイ・サイトの両方で、ポータルにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Portalスキーマを含むデータベースを最新の時点にリカバリする必要があります。Oracle Portalアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。
Oracle Formsは、エンタープライズ・アプリケーションを迅速かつ効率的に設計および構築するための、長年にわたって築き上げられてきたOracleのテクノロジです。
この項では、Oracle Forms固有のアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Formsアプリケーション用のユーザー構成済データベース。
本番サイトとスタンバイ・サイトの両方で、Oracle Formsにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardがユーザー構成済アプリケーション・データベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Formsアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。ユーザー構成済データベースがある場合は、それらを最新の時点にリカバリする必要があります。
Oracle Reportsは、Oracle Fusion Middlewareのレポート公開コンポーネントです。それは、形式と場所を問わずどのようなデータでも動的に取得、書式設定および配布する高品質な本番レポートを作成するためのエンタープライズ・レポート・サービスです。Oracle Reportsを使用して、Webベース環境と非Webベース環境の両方でレポートを公開できます。
この項では、様々なOracle Reportsアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Reportsホーム: レポート定義ファイルを含むユーザー定義の場所です。これは、OracleインスタンスまたはOracleホームの下にある場合もあります。
Oracle Reportsは、スケジュール済ジョブのデータ、過去のジョブのデータ、ジョブ・ステータスのデータなど、ジョブ関連情報をデータベースに格納するように構成できます。これは、ユーザー構成済データベースです。
本番サイトとスタンバイ・サイトの両方で、Oracle Reportsにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
構成またはユーザー情報を他のコンポーネント(Oracle PortalやOracle Internet Directoryなど)に格納するようにReports Serverが構成されている場合は、本番サイトとスタンバイ・サイト間でこれらのコンポーネントを確実に同期化するようにしてください。
Oracle Data GuardがOracle Reportsデータベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Reportsアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。ユーザー構成済データベースがある場合は、それらを最新の時点にリカバリする必要があります。また、関連付けられているOracle PortalおよびOracle Internet Directoryインスタンスもリカバリしてください。
Oracle Business Intelligence Discoverer(Discoverer)は、データ分析用のビジネス・インテリジェンス・ツールです。これは、Oracle Fusion Middlewareの重要なコンポーネントです。Discovererでは、直感的な非定型の問合せ、レポート作成、分析およびWeb公開機能で構成される統合化ビジネス・インテリジェンス・ソリューションが提供されます。これらのツールを使用して、技術者ではないユーザーでもデータ・マート、データ・ウェアハウス、マルチディメンショナル(OLAP)データソースおよびオンライン・トランザクション処理システムの情報に即時にアクセスできます。Discovererは、Oracle PortalおよびOracle WebCenter Portalとシームレスに統合されるため、Discovererのワークブックおよびワークシートを各Webポータルに迅速にデプロイできます。
この項では、様々なDiscovererアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
DISCOVERERおよびDISCOVERER_PSスキーマは、Discovererメタデータ・リポジトリの一部です。
本番サイトとスタンバイ・サイトの両方で、Discovererにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Discovererスキーマを含むデータベースを直近の時点にリストアする必要があります。
Discovererアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。
J2EEアプリケーション・サーバーのWeb層は、Webブラウザなど、主にHTTPリクエストおよびレスポンスの形式でのエンド・ユーザーとの対話を処理します。これは、HTTPスタックにおける一番外側の層で、エンド・ユーザーに最も近い層です。
この項では、次のOracle Web Tierコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。それは、Oracle WebLogic Server用のリスナーと、静的ページ、動的ページおよびWeb上のアプリケーションをホストするフレームワークを提供します。
Oracle HTTP Serverは、Apache 2.2.xインフラストラクチャに基づいており、Oracleによって特別に開発されたモジュールを含んでいます。シングル・サインオン、クラスタ・デプロイメントおよび高可用性の機能により、Oracle HTTP Serverの操作が強化されます。
この項では、様々なOracle HTTP Serverアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracleホーム: Oracleホームは、Oracle HTTP Serverバイナリから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
Oracleインスタンス: Oracleインスタンスには、Oracle HTTP Serverの構成データと診断データが含まれます。OPMNとEnterprise Managerエージェントの構成データも含まれます。
静的コンテンツ・ボリューム: このボリュームには、Oracle HTTP Serverインスタンスによって処理される静的コンテンツが格納されます。静的なHTMLコンテンツを格納するこのボリュームはオプションです。Oracle Fusion Middlewareは、このボリュームがなくても正常に機能します。
Oracle HTTP Serverにはデータベース依存性がないため、適用されません。
Oracle HTTP Serverの特別な考慮事項は、次のとおりです。
本番サイトとスタンバイ・サイトの両方で、Oracle HTTP Serverにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。
このマニュアルでは、共有記憶域に11g Oracle Fusion Middlewareインスタンス(Oracle HTTP Serverインスタンスを含む)をインストールしたと想定しています。Oracle HTTP Server 11gのOracleインスタンスが、信頼できるファイル・ロック機能を持たない共有記憶域(NASストレージ、NFSストレージ、SANストレージなど)に構成されている場合、Oracle HTTP Serverでパフォーマンスの問題が発生する可能性があります。
一部の共有ストレージ・システムは、11g Oracle HTTP Serverが必要としている、信頼できるファイル・ロック機能を提供していません。その場合、httpd.confファイル内のLockFileディレクティブを、ローカル・ファイル・システムを指すように変更する必要があります。
LockFileディレクティブの詳細は、次のURLにあるApacheのドキュメントを参照してください。
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex
11g Oracle HTTP Serverインスタンスが共有記憶域にインストールされており、パフォーマンスの問題が発生している場合は、Oracle HTTP Serverインスタンスに対して次の手順を実行して、ローカル・ファイル・システムのLockFileディレクティブを指すようにします。
デフォルトでは、LockFileは次の形式で、httpd.confファイル内のprefork MPM構成ブロックとworker MPM構成ブロックの両方の下に構成されています。
${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME/http_lock
適切な方法を使用して、$ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.confファイルを編集します。
正しいMPM構成の下のLockFileディレクティブを、ローカル・ファイル・システムを指すように変更します。
LockFile /<local_disk>/<path>/http_lock
Oracle HTTP Serverを再起動します。
これらの手順を実行した後、LockFileディレクティブによって指定されたディレクトリにhttp_lockファイルが存在することを確認します。
構成の変更後は、手動でOracle HTTP Serverインスタンスをスタンバイ・サイトと同期化する必要があります。
スタンバイ・サイトでOracle HTTP Serverインスタンスおよび関連する構成ファイルをリストアします。
Oracle Web Cacheは、Web層で使用されるコンテンツ認識型のサーバー・アクセラレータ(リバース・プロキシ)です。Oracle HTTP ServerやOracle WebLogic Serverといった任意のWebサーバーまたはアプリケーション・サーバーで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。
Oracle Web Cacheは、Oracle Fusion Middlewareとともに提供される主要なキャッシュ・メカニズムです。キャッシュにより、頻繁にアクセスされるURLをメモリーに格納して、Oracle Fusion Middleware上で稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を向上させることができます。
この項では、様々なOracle Web Cacheアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracleホーム: Oracleディレクトリ・ホームは、Oracle Web Cacheバイナリから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
Oracleインスタンス: Oracleインスタンスには、Oracle Web Cacheの構成データが含まれます。OPMNとEnterprise Managerエージェントの構成データも含まれます。
Oracle Web Cacheにはデータベース依存性がないため、適用されません。
本番サイトとスタンバイ・サイトの両方で、Oracle Web Cacheにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。
構成の変更後は、手動でOracle Web Cacheインスタンスをスタンバイ・サイトと同期化する必要があります。
スタンバイ・サイトでOracle Web Cacheインスタンスおよび関連する構成ファイルをリストアします。
Oracle WebCenter Contentは、コンテンツの管理のために設計された製品の統合スイートです。このOracle WebCenter Contentプラットフォームにより、業界最先端のドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード管理機能を利用して、ビジネス・アプリケーションを構築できます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築すると、コストの削減、エンタープライズ間のコンテンツ共有の容易化、リスクの最小化、高価で時間のかかる手動プロセスの自動化、および単一プラットフォームへの複数Webサイトの統合化が促進されます。
すべてのOracle WebCenter Contentコンポーネントの共通アーティファクトと考慮事項
コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle WebCenter Contentコンポーネントに適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle WebCenter Contentバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびOracle WebCenter Contentアプリケーションが含まれます。
Oracleインスタンス: Oracleインスタンスには、OPMN構成データやEnterprise Managerエージェント構成データなどの非J2EE Oracle WebCenter Contentアプリケーションの構成データが含まれます。
Oracle WebCenter Contentスキーマは、Oracle WebCenter Contentデータベース内にあります。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle Enterprise Content Managementコンポーネントへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
該当のアイデンティティ管理コンポーネントとともに、Oracle WebCenter Contentスキーマを含むデータベースを直近の時点にリカバリする必要があります。
この項の残りの部分では、次のOracle Enterprise Content Managementコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracle WebCenter Contentは、様々な種類のコンテンツ管理を目的とした統合アプリケーションです。
Oracle WebCenter Contentはエンタープライズ・コンテンツ管理プラットフォームであり、これを使用すると、ドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード保持機能を活用して、ビジネス・アプリケーションの構築と補完を行うことができます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築すると、コストの削減、エンタープライズ間のコンテンツ共有の容易化、リスクの最小化、高価で時間のかかる手動プロセスの自動化、および複数のWebサイトの単一プラットフォームへの(一元管理を目的とした)統合化が促進されます。Oracle WebCenter Contentでは、ユーザーフレンドリなインタフェース、ロールベースの認証およびセキュリティ・モデルを使用することによって、全社規模のユーザーでコンテンツに対する表示、共同作業および廃棄ができるようになるため、配布済または公開済のアクセス可能な情報は、すべてセキュア、正確かつ最新な状態であることが保証されます。
この項では、様々なOracle WebCenter Contentアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Secure Filesまたはファイルベースの永続ストア。
OCSスキーマは、Oracle WebCenter Contentデータベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Contentに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
ファイルベースの永続ストアの場合、スタンバイ・サイトのファイルベースの永続ストアを同期化する必要があります。
OCSおよびMDSスキーマとともに、Oracle WebCenter Contentを最新の時点にリカバリする必要があります。
Oracle WebCenter Content: Inbound Refineryは、ドキュメント、デジタル・イメージ、動画などの電子アセット用のファイル変換を管理する変換サーバーです。変換の他に、ドキュメントとイメージに対するサムネイル機能、ビデオのストーリーボード作成機能、デジタル・イメージからEXIFデータを抽出して使用する機能、およびAdobe PhotoshopやAdobe Illustratorなどのプログラムから生成された電子ファイルからXMPデータを抽出して使用する機能があります。Oracle WebCenter Content: Inbound Refineryを使用して、Oracle Content Serverに格納されているコンテンツ項目を変換できます。
この項では、様々なOracle WebCenter Content: Inbound Refineryアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle WebCenter Content: Inbound Refineryには、データベース依存性はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Content: Inbound Refineryに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle WebCenter Content: Inbound Refineryインスタンスをリカバリします。
Oracle WebCenter Content: Imagingは、プロセス志向のイメージング・アプリケーションやイメージ利用のソリューションを開発するための、拡張性の高いソリューションを提供します。Oracle Document CaptureおよびOracle Distributed Document Captureを使用したイメージの取込み、イメージの注釈付けとマークアップ、ルーティングと承認の自動化に対するワークフロー・サポート、および数百万件の項目を処理する大容量アプリケーションのサポートなどを利用できます。Oracle WebCenter Content: Imagingを使用すると、Oracle E-Business Suite、PeopleSoft Enterprise、JD Edwards EnterpriseOneなどのOracleエンタープライズ・アプリケーションに、組織のコンテンツとプロセスを迅速に直接統合できます。トランザクション・ベースの全コンテンツに対してソースを一元化することにより、ユーザーは二重入力が不要になるなどの利点を得ることができます。
この項では、様々なOracle WebCenter Content: Imagingアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
IPM入力エージェントは、共通のファイル共有からファイルを取得します。このIPMファイルは、スタンバイ・サイトと同期化される必要があります。
IPMスキーマは、Oracle WebCenter Content: Imagingデータベースの一部です。Oracle WebCenter Content: Imagingは、Oracle WebCenter Content: ImagingリポジトリとしてOracle WebCenter Contentを使用するために、OCSスキーマも必要とします。
構成の変更後およびパッチの適用後は、手動でアプリケーション層およびデータ層をスタンバイ・サイトと同期化する必要があります。
JMSストアであるIPMJMSServerStoreをファイルベースの永続ストアと同期化する必要があります。詳細は、第2.1.1項「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。
Oracle WebCenter Content: Imagingアプリケーションを実行している管理対象サーバーおよび関連付けられたインスタンスとともに、Oracle WebCenter Content: ImagingとIPMスキーマを直近の時点にリカバリする必要があります。
Oracle WebCenter Content: Information Rightsは、一元管理されているサーバーとデスクトップ・エージェントの間で権利の管理を行います。
Oracle WebCenter Content: Information Rightsでは、Microsoft Windowsデスクトップ、オーサリング・アプリケーション、電子メール・クライアントおよびコンテンツ管理/コラボレーション・リポジトリに統合されているシール・ツールを使用して、ドキュメントや電子メールが、それらのライフサイクルの任意の段階で、自動または手動でシールされるようにできます。シール処理により、強力な暗号化およびデジタル署名によって保護された層に、ドキュメントと電子メールがラップされます。このとき、該当する情報を所有する組織によって運用され、復号化キーおよび関連するアクセス権が格納されている、ネットワークでホストされているサーバーに戻るための消去不能なリンクが一緒に含められます。
シール済ドキュメントおよび電子メールは、電子メール、Web、ファイル共有などの既存の手段で分散できます。
この項では、様々なOracle WebCenter Content: Information Rightsアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
ORAIRMスキーマは、Oracle WebCenter Content: Information Rightsデータベースの一部です。Oracle WebCenter Content: Information Rightsをインストールする際に、Oracle IRM J2EEアプリケーションで使用されるキー・ストアがデータベースとともに作成されます。キー・ストアは、ドメイン・ホームの下のディレクトリに配置することをお薦めします。そうすれば、ドメインのリストア時にキー・ストアが自動的に使用可能になります。キー・ストアがドメインの下に格納されていない場合、手動でキー・ストアをレプリケートされたシステムにコピーする必要があります。
本番サイトとスタンバイ・サイトの両方で、Oracle Identity Federation用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenter Content: Information Rightsアプリケーションを実行している管理対象サーバーとともに、Oracle WebCenter Content: Rightsスキーマおよびデータ・ストアを含むデータベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Content: Recordsは、各コンテンツ・アイテムのライフ・サイクルを決定する保存スケジュールに従って、コンテンツ・アイテムを効率的に管理します。
レコード管理の主眼は、履歴やアーカイブとして、または法的な目的でコンテンツを保持することに置かれる傾向がありますが、一方で保持管理も実行されます。保持管理の主眼は、コンテンツの保存にかかるコストが、それを保持することにより得られる価値を上回る場合に、スケジュールに従ってコンテンツを削除することに置かれる傾向があります。
Oracle WebCenter Content: Recordsは、レコード管理と保存管理を1つのソフトウェア・システムに統合しています。Oracle WebCenter Content: Recordsを使用すると、必要に応じたコンテンツの追跡および保存、または不要になったコンテンツの処分が可能になります。
この項では、様々なOracle WebCenter Content: Recordsアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
URMSERVERおよびMDSスキーマは、Oracle WebCenter Content: Recordsデータベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle WebCenter Content: Records用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
管理サーバーとともに、Oracle WebCenter Content: Recordsアプリケーションを実行している管理対象サーバーをリカバリします。
Oracle Business Intelligence(BI)は、テクノロジとアプリケーションの製品ラインであり、業界で最初に統合されたエンドツーエンドのエンタープライズ・パフォーマンス管理システムです。このシステムには、BIのファウンデーションおよびツール、さらに財務実績管理アプリケーション、運用BIアプリケーションおよびデータ・ウェアハウスが含まれます。
すべてのOracle Business Intelligenceコンポーネントの共通アーティファクトと考慮事項
コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle Business Intelligenceコンポーネントに適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle Business Intelligenceバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびOracle Business Intelligenceアプリケーションが含まれます。
Oracleインスタンス: Oracleインスタンスには、1つ以上のOracleシステム・コンポーネント(Oracle BI Server、Oracle BI Presentation Services、Oracle HTTP Serverなど)の構成ファイル、ログ・ファイルおよび一時ファイルが格納されます。
Oracle Business Intelligenceスキーマは、Oracle Business Intelligenceデータベース内にあります。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle Business Intelligenceコンポーネントへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracle Databaseメタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
該当のアイデンティティ管理コンポーネントとともに、Oracle Business Intelligenceスキーマを含むデータベースを直近の時点にリカバリする必要があります。
この項の残りの部分では、次のOracle Business Intelligenceコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracle Business Intelligence Enterprise Edition(Oracle BI EE)は包括的な一連のエンタープライズ・ビジネス・インテリジェンス・ツールおよびインフラストラクチャであり、拡張性のある効率的な問合せおよび分析サーバー、非定型の問合せおよび分析ツール、インタラクティブ・ダッシュボード、プロアクティブ・インテリジェンスとアラート、リアルタイム予測インテリジェンス、エンタープライズ・レポート・エンジンなどが含まれます。Oracle Business Intelligence Enterprise Editionは、ビジネスの可視性と洞察力を幅広いユーザーに向けて高められるように設計されています。
BIPLATFORMスキーマは、Oracle Business Intelligence Enterprise Edition(EE)データベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle Business Intelligence Enterprise Edition(EE)用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Middlewareホーム、ドメイン、およびOracle Business Intelligence Enterprise Edition(EE)コンポーネントを含むOracleインスタンスをリカバリします。Windowsに、Oracle Business Intelligence Enterprise Edition(EE)レジストリ・エントリをインポートします。必要に応じて、データベースを直近の時点にリカバリします。
Oracle Business Intelligence Publisher (BI Publisher、旧名はXML Publisher)を使用すると、印刷に適した書式に設定されたレポートを作成できます。BI Publisherレポートは、BI Publisherデータ・モデルに基づいて作成されます。BI Publisherデータ・モデルは、BIサーバーや分析からのサブジェクト・エリア、リレーショナル・データベースに対するSQL問合せ、Subbaseや他のOLAPソースに対するMDX問合せ、LDAP、Webサービス、Microsoft Excel、HTTPフィード、XMLファイルなどの広範なソースからのデータ・セットで構成されます。BI Publisherでは、様々なレイアウト・タイプがサポートされるため、組織で必要なあらゆる種類のドキュメントを作成できます。Oracle BI EE内で、BI Publisherレポートの表示、作成、編集およびスケジュールを行ったり、レポートをダッシュボード・ページに含めたりできます。
BIPLATFORMスキーマは、Oracle Business Intelligence Publisherデータベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle Business Intelligence Publisher用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Business Intelligence Publisherコンポーネントを含む管理対象サーバーをリカバリします。
Oracle Real-Time Decisions (Oracle RTD)は、適応性の高いエンタープライズ・ソフトウェア・ソリューションの開発を可能にします。こうした適応性のあるソリューションは、ビジネス・トランザクションが実行される際に継続的に学習し、クローズ・ループ型のビジネス・ルールと予測モデルに従って、各トランザクションをリアルタイムで自動的に最適化します。
分析モデルおよびRTDスキーマは、Oracle Real-Time Decisionsデータベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle Real-Time Decisions用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。
