| Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド 11g リリース1(11.1.1) B61394-01 |
|
 前 |
 次 |
この章では、様々なOracle製品スイート内のOracle Fusion Middlewareコンポーネントの障害保護の要件について説明し、これらのコンポーネントの同期化に関する推奨事項も示します。前に説明したとおり、ストレージ・レプリケーションを使用して中間層のコンテンツを同期化し、Oracle Data Guardを使用してOracle Fusion Middleware障害時リカバリ・トポロジに含まれているOracleデータベース・リポジトリまたはカスタム・アプリケーション・データベース内のデータを同期化します。
この章では、次の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データベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。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データベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に実行されます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
ADFまたはWebCenterアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。
Oracle WebCenterは、Java Server Faces(JSF)の標準ベースの宣言型開発機能と、ポータルの柔軟性とパワー、および一連の統合されたWeb 2.0サービスを組み合せたものです。
Oracle WebCenterの共通アーティファクトと考慮事項
製品固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle WebCenter製品に適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle WebCenterバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、Oracle WebCenterドメインの構成データが含まれます。
Oracle WebCenterスキーマには、一部のOracle WebCenterサービスのデータが格納されます。また、Oracle WebCenterスキーマは、Oracle WebCenterデータベースの一部となります。MDSリポジトリには、WebCenterのメタデータおよび構成情報が格納されます。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、WebCenter製品へのアクセスに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、WebCenterスキーマとメタデータ・リポジトリを含むOracleデータベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に実行されます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
WebCenterアプリケーションを実行している管理対象サーバーとともに、Oracle WebCenterスキーマを含むデータベースを直近の時点にリカバリする必要があります。
この項の残りの部分では、次のOracle WebCenter製品の障害時リカバリに関する推奨事項を示します。
Oracle WebCenter Spacesは、一連の強力なサービスとアプリケーションによって、ソーシャル・ネットーワーク、通信、コラボレーションおよび個人の生産性向上を実現する、統合された単一のWebベース環境を提供します。
この項では、様々なOracle WebCenter Spacesアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
WebCenterスキーマには、一部のOracle WebCenterサービスのデータが格納されます。また、WebCenterスキーマは、Oracle WebCenterスキーマの一部となります。MDSリポジトリには、WebCenterのメタデータおよび構成情報が格納されます。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、WebCenterスキーマとメタデータ・リポジトリを含むOracleデータベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenterドメインとともに、WebCenterスキーマとMDSリポジトリを含むデータベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Portletsは、標準ベースのポートレット(JSR 168、WSRP 1.0および2.0)と、従来のOracle PDK-Javaベースのポートレットの両方のデプロイメントと実行をサポートしています。Oracle WebCenterは、OmniPortlet、Web Clipping、Rich Text Portlet、WSRPツールなど、追加設定が不要なプロデューサをいくつか提供します。
この項では、様々なOracle WebCenter Portletsアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Portletスキーマには、ユーザー・カスタマイズが格納されます。また、Portletスキーマは、Oracle WebCenterスキーマの一部となります。MDSリポジトリには、Portletのメタデータおよび構成情報が格納されます。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、WebCenterスキーマとメタデータ・リポジトリを含むOracleデータベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenterドメインとともに、WebCenter PortletスキーマとMDSリポジトリを含むデータベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Discussions Serverは、ディスカッション・フォーラムとお知らせをアプリケーションに統合する機能を提供します。
この項では、様々なOracle WebCenter Discussions Serverアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Discussionsスキーマには、メタデータとデータが格納されます。Discussionsスキーマは、Oracle WebCenterスキーマの一部です。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、WebCenterスキーマとメタデータ・リポジトリを含むOracleデータベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenterドメインとともに、WebCenter Discussionsスキーマを含むデータベースを直近の時点にリカバリする必要があります。
Oracle WebCenter Wiki and Blog Serverは、Wikiとブログをアプリケーションに統合する機能を提供します。アプリケーション・ユーザーが各自のWikiとブログを作成できるようにするための機能もサポートします。
この項では、様々なOracle WebCenter Wiki and Blog Serverアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Wikiスキーマには、メタデータとデータが格納されます。Wikiスキーマは、Oracle WebCenterスキーマの一部です。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data Guardが、WebCenterスキーマとメタデータ・リポジトリを含むOracleデータベース用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle WebCenterドメインとともに、WebCenter Wikiスキーマを含むデータベースを直近の時点にリカバリする必要があります。
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プロセス・フローへの同期および非同期サービスを開発するための標準を提供します。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標準をサポートするマルチプロトコル・ゲートウェイを提供し、電子データ交換(EDI)、ebXML、HL7、RosettaNetなどのビジネス・プロトコル標準でOracle SOA Suiteを拡張します。Oracle B2Bは、SOA Service Infrastructure内のバインディング・コンポーネントとして実装されます。
この項では、様々なOracle B2Bアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
JMS ストア: ファイルベースのJMS永続ストアを含むボリューム。表2-1に、Oracle B2Bによって内部的に使用されるJMSキューおよびトピックを示します。
表2-1 Oracle B2Bによって使用されるJMSキューおよびトピック
| JMSアーティファクト名 | タイプ | JNDI名 |
|---|---|---|
|
dist_B2BEventQueue_auto |
分散キュー |
jms/b2b/B2BEventQueue |
|
dist_B2B_IN_QUEUE_auto |
分散キュー |
jms/b2b/B2B_IN_QUEUE |
|
dist_B2B_OUT_QUEUE_auto |
分散キュー |
jms/b2b/B2B_OUT_QUEUE |
|
dist_B2BBroadcastTopic_auto |
分散トピック |
jms/b2b/B2BBroadcastTopic |
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サービスを一貫して管理および保護するポリシー・フレームワークを提供します。Oracle WSMは、セキュリティ、WSRM、MTOM、アドレス指定ポリシーなどのWeb Serviceポリシーを構築、適用、実行および監視する機能を提供します。Oracle Web Services Managerは、ポリシー・マネージャとエージェントから構成されています。
ポリシー・マネージャは、MDSリポジトリから、事前定義されたポリシーとカスタム・ポリシーを含め、セキュリティおよび管理ポリシーの読取りおよび書込みを行います。ポリシー・マネージャは、ステートレスなJava EEアプリケーションであり、ステートレスなセッション・ビーンを通じてその機能を公開します。ポリシー・マネージャはデータをキャッシュしませんが、基礎となるMDSインフラストラクチャはデータをキャッシュします。
エージェントは、ポリシーの適用と実行、および実行時統計の収集を行います。エージェントは、すべてのOracle Fusion Middleware管理対象サーバー上で使用可能であり、保護対象のアプリケーションと同じサーバー上に構成されます。エージェントは、ポリシー・アクセス・ポイント(PAP)とポリシー・インターセプタの2つから構成されています。
この項では、様々なOracle Web Services Managerアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
MDSリポジトリは、ポリシーの格納に使用されます。
ドメイン関連の構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracleデータベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
soa-infraアプリケーションを実行している管理対象サーバーとともに、データベースを直近の時点にリカバリする必要があります。すべてのポリシーはMDSリポジトリ内に格納されるので、データベースおよび管理対象サーバーのリカバリにより、アプリケーションが正常に実行されるようになります。
Oracle User Messaging Service(Oracle UMS)は、ユーザーとデプロイ済アプリケーション間の双方向通信を可能にします。Oracle User Messaging Serviceは、電子メール、IM、SMS、テキスト読上げメッセージなど、様々なチャネルをサポートしており、Oracle BPEL PM、Oracle Human Workflow、Oracle BAM、Oracle WebCenterなどのOracle Fusion Middlewareコンポーネントと統合されています。Oracle User Messaging Serviceは通常、Oracle SOA Service Infrastructureとともにデプロイされ、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名 |
|---|---|---|
|
OraSDPMAppDefRcvQ1_auto |
分散キュー |
OraSDPM/Queues/OraSDPMAppDefRcvQ1 |
|
OraSDPMDriverDefSndQ1_auto |
分散キュー |
OraSDPM/Queues/OraSDPMDriverDefSndQ1 |
|
OraSDPMEngineCmdQ_auto |
分散キュー |
OraSDPM/Queues/OraSDPMEngineCmdQ |
|
OraSDPMEngineRcvQ1_auto |
分散キュー |
OraSDPM/Queues/OraSDPMEngineRcvQ1 |
|
OraSDPMEngineSndQ1_auto |
分散キュー |
OraSDPM/Queues/OraSDPMEngineSndQ1 |
|
OraSDPMWSRcvQ1_auto |
分散キュー |
OraSDPM/Queues/OraSDPMWSRcvQ1 |
Oracle User Messaging Serviceは、外部データベース・リポジトリを使用してメッセージおよび構成の状態を維持管理します。
Oracle User Messaging Serviceは、JMSを使用して、メッセージング・アプリケーション間にメッセージを配信します。デフォルトでは、ファイルベースの永続性JMSストアを使用するように構成されているので、それらのファイルが配置されているストレージ・デバイスに依存します。
構成の変更、追加のOracle User Messaging Serviceドライバのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracleデータベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。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 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データベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。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データベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。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 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データベース・メタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。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 Access Managerのインストール・ディレクトリには、Oracle Access Manager製品の構成データと製品バイナリの両方、およびアイデンティティ・サーバー、アクセス・サーバー、ポリシー・マネージャ、WebパスのOracleホームが含まれます。ポリシー・マネージャとWebパスは、OAMADMINHOSTにインストールされているOracle HTTP Serverインスタンスとホームを共有します。
Oracle HTTP ServerのOracleホーム: これは、Oracle Access Managerトポロジのフロント・エンドとなるOracle HTTP ServerインスタンスのOracleホームです。
Oracle HTTP ServerのOracleインスタンス: Oracle HTTP ServerのOracleインスタンスには、Oracle Access Managerトポロジのフロント・エンドとなるOracle HTTP Serverインスタンスの構成データが含まれます。
Webゲートのインストール・ディレクトリ: Webゲートのインストール・ディレクトリには、Oracle WebGateのバイナリと構成データが含まれます。
Oracle Access Managerは、Oracle Identity Managementデータベースの一部であるOAMおよびAUスキーマを使用します。
Oracle Access Managerは、構成情報をLDAPストアに格納します。
本番サイトとスタンバイ・サイトの両方で、Oracle Access Manager用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracleデータベース・メタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
関連付けられているOracle HTTP Serverインスタンスとともに、Oracle Access Managerのアイデンティティ・サーバー、アクセス・サーバー、ポリシー・マネージャおよびWebパス・サーバーをリカバリします。
この項では、次の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データベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。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データベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。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は、形式と場所を問わずどのようなデータでも動的に取得、書式設定および配布する高品質な本番レポートを作成するためのエンタープライズ・レポート・サービスです。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)データソースおよびオンライン・トランザクション処理システムの情報に即時にアクセスできます。Oracle BI Discovererは、Oracle PortalおよびOracle WebCenterとシームレスに統合されるため、Discovererのワークブックおよびワークシートを各Webポータルに迅速にデプロイできます。
この項では、様々なDiscovererアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
DISCOVERERおよびDISCOVERER_PSスキーマは、Discovererメタデータ・リポジトリの一部です。
本番サイトとスタンバイ・サイトの両方で、Discovererにアクセスするためのロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracleデータベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Discovererスキーマを含むデータベースを直近の時点にリストアする必要があります。
Discovererアプリケーションを実行している管理対象サーバーおよびOracleインスタンスをリストアする必要があります。
J2EEアプリケーション・サーバーのWeb層は、Webブラウザなど、主にHTTPリクエストおよびレスポンスの形式でのエンド・ユーザーとの対話を処理します。Web層は、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 Enterprise Content Management Suiteは、コンテンツの管理のために設計された製品の統合スイートです。このOracle Enterprise Content Managementプラットフォームにより、業界最先端のドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード管理機能を利用して、ビジネス・アプリケーションを構築できます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築すると、コストの削減、エンタープライズ間のコンテンツ共有の容易化、リスクの最小化、高価で時間のかかる手動プロセスの自動化、および単一プラットフォームへの複数Webサイトの統合化が促進されます。
すべてのOracle Enterprise Content Managementコンポーネントの共通アーティファクトと考慮事項
コンポーネント固有の考慮事項に加えて、次のアーティファクトと考慮事項がすべてのOracle Enterprise Content Managementコンポーネントに適用されます。
MW_HOME: Middlewareホームは、WebLogic Serverバイナリが格納されるWebLogicホームと、Oracle Enterprise Content Managementバイナリが格納されるOracleホームから構成されます。
Oracle_Common_Home: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホーム。
ドメイン・ホーム: ドメイン・ホームには、そのドメインの管理サーバーおよび管理対象サーバーの構成データ、およびOracle Enterprise Content Managementアプリケーションが含まれます。
Oracleインスタンス: Oracleインスタンスには、OPMN構成データやEnterprise Managerエージェント構成データなどの非J2EE Oracle Enterprise Content Managementアプリケーションの構成データが含まれます。
Oracle Enterprise Content Management Suiteスキーマは、Oracle Enterprise Content Management Suiteデータベース内に格納されます。
Oracle WebLogic管理サーバーおよび管理対象サーバーの両方のリスニング・アドレスとして、仮想ホスト名を使用することをお薦めします。このホスト名が本番サイトおよびスタンバイ・サイトの両方で解決されるかぎり、障害時リカバリ操作後にこの値を更新する必要はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle Enterprise Content Managementコンポーネントへのアクセスに使用されるロード・バランサの仮想ホストを構成する必要があります。
構成の変更、アプリケーションのデプロイおよびパッチの適用を行った後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracleデータベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に実行されます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動による強制」およびOracle Data Guard概要と管理の物理スタンバイ・データベースへのREDOデータの適用に関する項を参照してください。
該当のアイデンティティ管理コンポーネントとともに、Oracle Enterprise Content Management Suiteスキーマを含むデータベースを直近の時点にリカバリする必要があります。
この項の残りの部分では、次のOracle Identity Managementコンポーネントの障害時リカバリに関する推奨事項を示します。
Oracle Universal Content Managementは、複数の異なる種類のコンテンツ管理のための統合アプリケーションを提供します。
Oracle Universal Content Managementは、ドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード保持管理機能を利用してビジネス・アプリケーションを構築および補完できるようにする、エンタープライズ・コンテンツ管理プラットフォームです。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築すると、コストの削減、エンタープライズ間のコンテンツ共有の容易化、リスクの最小化、高価で時間のかかる手動プロセスの自動化、および複数のWebサイトの単一プラットフォームへの(一元管理を目的とした)統合化が促進されます。ユーザー・フレンドリなインタフェース、ロールベースの認証およびセキュリティ・モデルを通じて、Oracle Universal Content Managementは、エンタープライズ全体のユーザーがコンテンツの表示、コンテンツでのコラボレーションおよびコンテンツのリタイアを行うことを可能にします。これにより、配布済または公開済のアクセス可能なすべての情報が確実に保護され、正確かつ最新のものとなります。
この項では、様々なOracle Universal Content Managementアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Secure Filesまたはファイルベースの永続ストア。
OCSスキーマは、Oracle Universal Content Managementデータベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle Universal Content Managementに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracleデータベース・メタデータ・リポジトリ用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
ファイルベースの永続ストアの場合、スタンバイ・サイトのファイルベースの永続ストアを同期化する必要があります。
Oracle Universal Content ManagementをOCSおよびMDSスキーマと一緒に最新の時点にリカバリする必要があります。
Oracle Inbound Refineryは、ドキュメント、デジタル・イメージ、動画などの電子アセット用のファイル変換を管理する変換サーバーです。変換の他に、ドキュメントとイメージに対するサムネイル機能、ビデオのストーリーボード作成機能、デジタル・イメージからEXIFデータを抽出して使用する機能、およびAdobe PhotoshopやAdobe Illustratorなどのプログラムから生成された電子ファイルからXMPデータを抽出して使用する機能があります。Oracle Inbound Refineryを使用して、Oracle Content Serverに格納されているコンテンツ項目を変換できます。
この項では、様々なOracle Inbound Refineryアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
Oracle Inbound Refineryには、データベース依存性はありません。
本番サイトとスタンバイ・サイトの両方で、Oracle Inbound Refineryに必要なロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でディレクトリ層をスタンバイ・サイトと同期化する必要があります。
Oracle Inbound Refineryインスタンスをリカバリします。
Oracle Imaging and Process Managementは、プロセス志向のイメージング・アプリケーションおよびイメージを利用したソリューションを開発するための、拡張性の高いソリューションを提供します。Oracle Document CaptureおよびOracle Distributed Document Captureを使用したイメージの取込み、イメージの注釈付けとマークアップ、ルーティングと承認の自動化に対するワークフロー・サポート、および数百万件の項目を処理する大容量アプリケーションのサポートなどを利用できます。Oracle Imaging and Process Managementを使用することにより、企業のコンテンツとプロセスを直接Oracle E-Business Suite、PeopleSoft Enterprise、JD Edwards EnterpriseOneなどのオラクル社のエンタープライズ・アプリケーションに迅速に統合できます。トランザクション・ベースの全コンテンツに対してソースを一元化することにより、ユーザーは二重入力が不要になるなどの利点を得ることができます。
この項では、様々なOracle Imaging and Process Managementアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
IPM入力エージェントは、共通のファイル共有からファイルを取得します。このIPMファイルは、スタンバイ・サイトと同期化される必要があります。
IPMスキーマは、Oracle Imaging and Process Managementデータベースの一部です。Oracle Imaging and Process Managementは、Oracle Imaging and Process ManagementリポジトリとしてOracle Universal Content Managementを使用するためにOCSスキーマも必要とします。
構成の変更後およびパッチの適用後は、手動でアプリケーション層およびデータ層をスタンバイ・サイトと同期化する必要があります。
JMSストアであるIPMJMSServerStoreをファイルベースの永続ストアと同期化する必要があります。詳細は、第2.1.1項「Oracle WebLogic Server JMSおよびトランザクション・ログに関する推奨事項」を参照してください。
Oracle Imaging and Process Managementアプリケーションを実行している管理対象サーバーおよび関連付けられたインスタンスとともに、Oracle Imaging and Process ManagementとIPMスキーマを直近の時点にリカバリする必要があります。
Oracle Information Rights Managementは、一元管理されているサーバーとデスクトップ・エージェントの間で権利の管理を行います。
Oracle Information Rights Managementでは、Microsoft Windowsデスクトップ、オーサリング・アプリケーション、電子メール・クライアントおよびコンテンツ管理/コラボレーション・リポジトリに統合されているシール・ツールを使用して、ドキュメントや電子メールが、それらのライフサイクルの任意の段階で、自動または手動でシールされるようにできます。シール処理により、強力な暗号化およびデジタル署名によって保護された層に、ドキュメントと電子メールがラップされます。このとき、該当する情報を所有する組織によって運用され、復号化キーおよび関連するアクセス権が格納されている、ネットワークでホストされているサーバーに戻るための消去不能なリンクが一緒に含められます。
シール済ドキュメントおよび電子メールは、電子メール、Web、ファイル共有などの既存の手段で分散できます。
この項では、様々なOracle Information Rights Managementアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
ORAIRMスキーマは、Oracle Information Rights Managementデータベースの一部です。Oracle Information Rights Managementのインストール時に、データベースに加えて、Oracle IRM J2EEアプリケーションが使用するキー・ストアが作成されます。キー・ストアは、ドメイン・ホームの下のディレクトリに配置することをお薦めします。そうすれば、ドメインのリストア時にキー・ストアが自動的に使用可能になります。キー・ストアがドメインの下に格納されていない場合、手動でキー・ストアをレプリケートされたシステムにコピーする必要があります。
本番サイトとスタンバイ・サイトの両方で、Oracle Identity Federation用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
Oracle Data GuardがOracleデータベース・メタデータ・リポジトリおよびデータ・ストア用に構成されている必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
Oracle Information Rights Managementアプリケーションを実行している管理対象サーバーとともに、Oracle Information Rights Managementスキーマを含むデータベースとデータ・ストアを直近の時点にリカバリする必要があります。
Oracle Universal Records Managementは、保存スケジュールに従って効率的にコンテンツ項目を管理します。保存スケジュールによって、コンテンツ項目のライフ・サイクルが決まります。
レコード管理の主眼は、履歴やアーカイブとして、または法的な目的でコンテンツを保持することに置かれる傾向がありますが、一方で保持管理も実行されます。保持管理の主眼は、コンテンツの保存にかかるコストが、それを保持することにより得られる価値を上回る場合に、スケジュールに従ってコンテンツを削除することに置かれる傾向があります。
Oracle Universal Records Managementは、レコード管理と保持管理を1つのソフトウェア・システムに組み合わせたものです。Oracle Universal Records Managementを使用して、必要に応じてコンテンツを追跡および保存したり、必要がなくなったコンテンツを廃棄したりすることができます。
この項では、様々なOracle Universal Records Managementアーティファクトについて説明し、障害時リカバリに関する推奨事項を示します。
URMSERVERおよびMDSスキーマは、Oracle Universal Records Managementデータベースの一部です。
本番サイトとスタンバイ・サイトの両方で、Oracle Universal Records Management用のロード・バランサの仮想ホストを構成する必要があります。
構成の変更後およびパッチの適用後は、手動でアプリケーション層をスタンバイ・サイトと同期化する必要があります。
ストレージ上でアプリケーション層の同期化が開始された場合は、スタンバイ・データベースを同期化することをお薦めします。Oracle Data Guardがデータベースに対して管理リカバリ・モード(推奨構成)に構成されているため、この同期化は自動的に行われます。スタンバイ・データベースが管理リカバリ・モードでない場合は、スタンバイ・データベースを手動で同期化する必要があります。
管理サーバーとともに、Oracle Universal Records Managementアプリケーションを実行している管理対象サーバーをリカバリします。
