18 環境のリカバリ
- リカバリ戦略の概要
リカバリ戦略により、実データの損失などの重大な障害からのリカバリが可能になります。 - データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ
実データの損失や破損、またはディスクのリストアが不可能なメディア障害を伴う停止の場合に、環境の一部または全体をリカバリする必要があります。また、状況によっては、正しく機能しなくなったアプリケーションをリカバリする必要もあります。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。 - ホストの破損後のリカバリ
Oracle Fusion Middlewareの元の動作環境が損なわれた場合、その環境をリカバリする必要があります。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。
親トピック: 高度な管理: バックアップとリカバリ
リカバリ戦略の概要
-
Oracleソフトウェア・ファイル
-
構成ファイル
-
Oracleシステム・ファイル
-
Windowsレジストリ・キー
-
アプリケーション・アーティファクト
Oracle Fusion Middleware環境のリカバリは、Oracle Fusion Middlewareがオフラインのときに実行できます。
次の各項目では、リカバリ戦略について説明します。
親トピック: 環境のリカバリ
リカバリのタイプ
Oracle Fusion Middleware環境は、その一部または全体をリカバリできます。次のリカバリが可能です。
-
Oracleホーム
-
WebLogic Serverドメイン
-
スタンドアロン・ドメイン
-
管理サーバー
-
管理対象サーバー
-
Oracle SOA SuiteやOracle HTTP Serverなどのコンポーネント
-
WebLogic Serverクラスタ
-
デプロイ済アプリケーション
-
データベース
親トピック: リカバリ戦略の概要
推奨されるリカバリ戦略
ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害またはメディア障害などが関係する停止に対するこれらのリカバリ戦略に従う必要があります。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。
ノート:
この章に記載されている手順では、最後のバックアップ以降、管理上の変更は加えられていないことを前提としています。最後のバックアップ以降、管理上の変更が加えられている場合は、リカバリの完了後にそれらの変更を再適用する必要があります。
リカバリに関しては次の重要な点に注意してください。
-
リカバリの実行中は、Oracle Fusion Middleware環境をオフラインにする必要があります。
-
必要なファイルを間違ってオーバーライドしないよう、バックアップからファイルをリストアする前に既存の重要なファイルおよびディレクトリの名前を変更してください。
-
1、2個のファイルのみが消失または破損しているように見える場合もありますが、1、2個のファイルのみをリストアするのではなく、ドメインなど要素全体のディレクトリ構造をリストアする必要があります。そうすることで、リカバリが成功する可能性が高くなります。
-
ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これは通常、データベースに障害が発生する直前の状態です。
-
ファイルのリストア時に圧縮ファイルを解凍するには、「バックアップおよびリカバリで使用するツール」の説明に従って、それに適したツールを使用します。
使用しているツールが、ファイルの権限とタイムスタンプを保持することを確認してください。
環境をリカバリする場合は、正しい順序でエンティティをリカバリすることが重要です。
-
データベース(リカバリが必要な場合)。「データベースのリカバリ」および「データベース・ホストの破損後のリカバリ」を参照してください。
-
Oracleホーム(リカバリが必要な場合)。「Oracleホームのリカバリ」を参照してください。
-
ドメイン全体(リカバリが必要な場合)。WebLogic Server管理対象ドメインのリカバリについては、「Oracle WebLogic Serverドメインのリカバリ」および「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」を参照してください。スタンドアロン・ドメインのリカバリについては、「スタンドアロン・ドメインのリカバリ」を参照してください。
-
管理サーバー(ドメインのリカバリが不要な場合)。「管理サーバー構成のリカバリ」および「管理サーバー・ホストの破損後のリカバリ」を参照してください。
-
管理対象サーバー(管理対象サーバーが管理サーバードメイン・ディレクトリになく、リカバリが必要な場合)。「管理対象サーバーのリカバリ」および「管理対象サーバー・ホストの破損後のリカバリ」を参照してください。
Javaコンポーネントは、管理対象サーバーをリカバリする際にリカバリされます。システム・コンポーネントは、ドメインをリカバリする際にリカバリされます。状況によっては、「コンポーネントのリカバリ」および「コンポーネント・ホストの破損後のリカバリ」の説明に従って特定のステップを実行する必要があります。
-
コンポーネントによっては追加操作が必要なものがあります。それらは、表18-1で示した項で説明しています。
表18-1 特定のコンポーネントの追加のリカバリ手順
コンポーネント データの損失、破損、メディア障害の場合 ホスト破損の場合 Oracle Access Management Access Manager
該当なし
Oracle Access Management Mobile and Social
該当なし
セキュリティ・トークン・サービス
該当なし
Oracle Access Management Identity Federation
該当なし
Oracle B2B
Oracle BI EE
同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「別のホストへのOracle BI Enterprise Editionのリカバリ」を参照してください。
Oracle Business Intelligence Publisher
該当なし
同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「別のホストへのOracle Business Intelligence Publisherのリカバリ」を参照してください。
Oracle Data Integrator
該当なし
Oracleディレクトリ統合プラットフォーム
該当なし
Oracle Forms Services
該当なし
同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「別のホストへのOracle Forms Servicesのリカバリ」を参照してください。
Oracle HTTP Server
該当なし
Oracle Identity Governance
Oracle Internet Directory
該当なし
Oracle Platform Security Services
Oracle Reports
該当なし
Oracle SOA Suite
該当なし
同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「ホスト破損後のOracle SOA Suiteのリカバリ」を参照してください。
Oracle WebCenter Content
Oracle WebCenter Content: Records。
Oracle WebCenter Contentをリカバリします。「Oracle WebCenter Contentのリカバリ」を参照してください。
Oracle WebCenter Contentをリカバリします。「別のホストへのOracle WebCenter Contentのリカバリ」を参照してください。
Oracle WebCenter Portalの分析
Oracle WebLogic Server
Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、「サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ」を参照してください。
Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、「サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ」を参照してください。
-
アプリケーション(リカバリが必要な場合)。「アプリケーションのリカバリ」を参照してください。
親トピック: リカバリ戦略の概要
データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ
ノート:
エンティティは、元のエンティティと同じパスにのみリストアできます。そのパスは、同じホスト上であっても、異なるホスト上であってもかまいません。
- Oracleホームのリカバリ
- Oracle WebLogic Serverドメインのリカバリ
- スタンドアロン・ドメインのリカバリ
- 管理サーバー構成のリカバリ
- 管理対象サーバーのリカバリ
- コンポーネントのリカバリ
- クラスタのリカバリ
- アプリケーションのリカバリ
- データベースのリカバリ
親トピック: 環境のリカバリ
Oracle WebLogic Serverドメインのリカバリ
破損したりファイル・システムから削除された場合、またはドメインが格納されているホストが破損した場合、Oracle WebLogic Serverドメインをリカバリすることができます。
注意:
ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。
破損したりファイル・システムから削除されたOracle WebLogic Serverドメインをリカバリするには:
サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ
データベース・リース(たとえば、サーバー全体の移行)を使用して、Oracle WebLogic Serverをリカバリする場合は、リース表内の情報を破棄する必要があります。単にリース表を破棄して再作成する場合は、リース表作成スクリプトを実行します。(サーバー全体の移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照。)
スタンドアロン・ドメインのリカバリ
破損したりファイル・システムから削除された場合、またはホストが破損して同じホストにリカバリする必要がある場合、Oracle HTTP Serverなどのシステム・コンポーネントが含まれているスタンドアロン・ドメインをリカバリできます。
スタンドアロン・ドメインをリカバリするには、次の手順に従います。
管理サーバー構成のリカバリ
ファイルの削除やファイル・システムの破損によって管理サーバー構成が失われた場合、問題発生時に管理コンソールがすでに起動されていれば、管理コンソールは機能し続けます。管理サーバーがユーザー名やパスワードのプロンプトを表示しないようにするには、「資格証明を入力しないサーバーの起動の有効化」を参照してください。
注意:
ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。
管理サーバーの構成をリカバリするには:
構成が次回変更されるときに、管理サーバーの構成が、管理対象サーバーにプッシュされます。管理対象サーバーが再起動するたびに、管理サーバーから構成が取得されます。
管理対象サーバーのリカバリ
管理対象サーバーのファイルが削除されたり破損した場合、その構成ファイルを含めて、それらのファイルをリカバリできます。
このシナリオでは、管理対象サーバーが管理サーバーと同じホストに存在しておらず、適切に動作しない場合や起動できない場合を想定しています。この原因としては、構成の削除、構成の破損、構成を誤って変更したがその変更内容が不明であることなどが考えられます。
管理対象サーバーをリカバリするには、次の手順に従います。
コンポーネントのリカバリ
コンポーネントのファイルが削除されたり破損した場合、またはコンポーネントの構成が変更されコミットされたためにコンポーネントが起動できないまたは適切に機能しない場合、コンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
-
Javaコンポーネントの場合は、「管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
-
スタンドアロン・ドメインにあるOracle HTTP Serverなどのシステム・コンポーネントの場合は、「スタンドアロン・ドメインのリカバリ」の説明に従って、ドメインをリカバリします。
-
Oracle WebLogic ServerドメインにあるOracle HTTP Serverなどのシステム・コンポーネントの場合は、「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、ドメインをリカバリします。
次の項では、特定のコンポーネントに対して実行する必要がある追加のステップについて説明します。
Oracle Platform Security Servicesのリカバリ
Oracle Platform Security Servicesの場合は、次のファイルをリストアします。
DOMAIN_HOME/config/fmwconfig/jps-config.xml DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml DOMAIN_HOME/config/fmwconfig/cwallet.sso DOMAIN_HOME/config/fmwconfig/bootstrap/cwallet.sso DOMAIN_HOME/config/fmwconfig/keystores.xml DOMAIN_HOME/config/config.xml DOMAIN_HOME/config/fmwconfig/ids_config.xml DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml (if present) DOMAIN_HOME/config/fmwconfig/jps_mbeans.xml
親トピック: コンポーネントのリカバリ
Oracle B2Bのリカバリ
リカバリ後、ファイルXengine.tar.gzが解凍されていない場合は解凍します。たとえば:
cd B2B_ORACLE_HOME/soa/thirdparty/edifecs
tar xzvf XEngine.tar.gz
親トピック: コンポーネントのリカバリ
Oracle Access Management Access Managerのリカバリ
Access Managerをリカバリするには:
- 「Oracleホームのリカバリ」の説明に従って、Oracleホームをリストアします。
- 「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、Access Manager管理対象サーバーのドメインをリストアします。
- 必要に応じて、「Oracleホームのリカバリ」の説明に従って、WebGateが含まれるOracle HTTP ServerのOracleホームをリストアします。
- 必要に応じて、Access Managerポリシー・ストア用にOESで使用されるスキーマが含まれるデータベースをリストアします。「データベースのリカバリ」を参照してください。
親トピック: コンポーネントのリカバリ
Oracle WebCenter Portal分析のリカバリ
Oracle WebCenter Portal分析をリカバリするには:
- 「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、ドメインをリストアします。
- 「Oracleホームのリカバリ」の説明に従って、Oracleホームをリストアします。
- 必要に応じて、ACTIVITIESスキーマおよびMDSスキーマが含まれるデータベースをリストアします。
親トピック: コンポーネントのリカバリ
Oracle WebCenter Contentのリカバリ
Oracle WebCenter Contentをリカバリするには:
データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。
親トピック: コンポーネントのリカバリ
Oracle BI Enterprise Editionのリカバリ
クラスタ環境でOracle BI EEをリカバリするには:
-
「LDAPデータベースとRPDの調整」の説明に従って、LDAPデータベースとOracle BI EEリポジトリ(RPD)を調整します。
-
「LDAPデータベースとOracle BI Presentation Catalogの調整」の説明に従って、LDAPデータベースとOracle BI Presentation Catalogを調整します。
LDAPデータベースとRPDの調整
LDAPデータベースは、Oracle BI EEリポジトリ(RPD)と調整する必要があります。
Oracle BI Enterprise Editionを使用して、同期を実行できます。常に自動同期を有効にすることも一時的に同期を実行することもできます。(NQSConfig.iniファイルの編集の詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のNQSConfig.INIファイルの構成設定に関する項を参照してください。)
-
同期を有効にするには:
-
次のファイルを編集します。
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI
フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSを
yes
に設定します。 -
サーバーを再起動します。LDAPデータベースの情報とRPDが同期化されます。
-
-
同期を無効にするには:
-
同期を無効にするには、次のファイルを編集します。
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI
フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSを
no
に設定します。 -
サーバーを再起動します。
-
Windows上のOracle BI管理ツールには、リポジトリの妥当性をチェックして不整合を修正できるConsistency Check Managerが用意されています。整合性チェック・マネージャの詳細は、『Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ・オブジェクトの整合性のチェックに関する項を参照してください。
クラスタのリカバリ
次の状況では、クラスタをリカバリする必要があります。
-
クラスタが誤って削除されているか、クラスタ・メンバーが誤って削除されている。
-
JMS構成またはコンテナレベルのデータ・ソースなどのクラスタレベルの構成が誤って変更されコミットされている。コンポーネントまたはサーバーは起動できないか、または適切に動作せず、サーバー内で実行中のサービスは起動されていません。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
注意:
ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。
構成の変更が少ない場合、最も簡単な方法は、構成の変更を再実行することです。この方法を実行できない場合は、次の手順に従って構成をリカバリします。
アプリケーションのリカバリ
アプリケーションのリカバリについては、次の点に注意してください。
-
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
-
デプロイメント・モードがステージングなしまたは外部ステージングの場合、追加のアプリケーション・アーティファクトが使用可能であることを確認してください。たとえば、アプリケーションがドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。新しいファイル・システム上でのアプリケーション・ファイルの相対位置は、元の管理サーバーのファイル・システムと同じにする必要があります。
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
次の各項目で、アプリケーションをリカバリする方法について説明します。
アプリケーション・アーティファクトのリカバリ
.earファイルなどのアプリケーションのアーティファクトが損失または破損した場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリするには:
親トピック: アプリケーションのリカバリ
Java EEアプリケーションのリカバリ
次の場合、Java EEアプリケーションをリカバリできます。
-
Java EEアプリケーションが管理対象サーバーに再デプロイされ(管理対象サーバーがクラスタの一部であるかどうかは関係ない)、アプリケーションが機能しなくなった場合。
-
デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合。
-
コンポジット・アプリケーションの新規バージョンが管理対象サーバーまたはクラスタに再デプロイされました。このアプリケーションが機能しなくなったとします。
アプリケーションをリカバリするには:
親トピック: アプリケーションのリカバリ
データベースのリカバリ
MDSリポジトリなどのメタデータ・リポジトリが含まれるデータベースが破損している場合、RMANを使用してそのデータベースをリカバリできます。データベースは、完全リカバリまたは表領域リカバリのいずれかの必要な粒度でリカバリできます。
最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合。)これにより、確実に最新のデータがリカバリされます。たとえば:
rman> restore database; rman> recover database;
各コンポーネントで使用されるスキーマについては、『Repository Creation Utilityによるスキーマの作成』を参照してください。
データベースのリカバリの詳細なステップは、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
ホスト破損後のリカバリ
Oracle Fusion Middlewareの元の動作環境が損なわれた場合、その環境をリカバリする必要があります。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。
- Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ
- スタンドアロン・ドメイン・ホストの破損後のリカバリ
- 管理サーバー・ホストの破損後のリカバリ
- 管理対象サーバー・ホストの破損後のリカバリ
- コンポーネント・ホストの破損後のリカバリ
- ホストの破損後にエンティティをリカバリするための追加の操作
- データベース・ホストの破損後のリカバリ
親トピック: 環境のリカバリ
Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ
ホストの破損後に、Oracle WebLogic Serverドメインをリカバリするには、「Oracle WebLogic Serverドメインのリカバリ」のステップに従います。
親トピック: ホスト破損後のリカバリ
スタンドアロン・ドメイン・ホストの破損後のリカバリ
スタンドアロンドメインを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
同じホストへのスタンドアロン・ドメインのリカバリ
オペレーティング・システムの再インストール後に、スタンドアロン・ドメインを同じホストにリカバリするには、「スタンドアロン・ドメインのリカバリ」の手順に従います。
親トピック: スタンドアロン・ドメイン・ホストの破損後のリカバリ
別のホストへのスタンドアロン・ドメインのリカバリ
このシナリオでは、スタンドアロン・ドメインを別のホストにリカバリします。
スタンドアロン・ドメインを別のホストにリカバリするには、次の手順に従います。
親トピック: スタンドアロン・ドメイン・ホストの破損後のリカバリ
管理サーバー・ホストの破損後のリカバリ
管理サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
同じホストへの管理サーバーのリカバリ
このシナリオでは、管理サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。たとえば、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されているとします。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをリカバリする必要があります。
同じホストに管理サーバーをリカバリするには:
-
ファイル・システムをリカバリします。たとえば、「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」の説明に従って、この管理サーバーが含まれるドメインをリカバリします。
-
管理サーバーを起動します。たとえば:
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーが起動する場合は、これ以上のステップは必要ありません。
-
管理サーバーが起動しない場合は、ホストAで次のステップを実行します。
-
関連するすべてのプロセスを停止します。つまり、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。
-
必要に応じて、Oracleホームをリカバリします。
tar -xf oracle_home_backup_06052017.tar
-
ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。
tar -xf domain_backup_06052017.tar
-
管理サーバーを起動します。たとえば:
DOMAIN_HOME/bin/startWebLogic.sh
-
ホストの管理用URLを指定して、管理対象サーバーを起動します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
-
ノード・マネージャを起動します。
DOMAIN_HOME/bin/startNodeManager.sh
-
親トピック: 管理サーバー・ホストの破損後のリカバリ
別のホストへの管理サーバーのリカバリ
このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをホストCに移行する必要があります。
別のホストに管理サーバーをリカバリするには:
これで、ホストCで実行されている管理コンソールを使用して、ホストBの管理対象サーバーを起動および停止できます。
Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、「ホストの破損後にエンティティをリカバリするための追加の操作」を参照してください。
親トピック: 管理サーバー・ホストの破損後のリカバリ
管理対象サーバー・ホストの破損後のリカバリ
管理対象サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
同じホストへの管理対象サーバーのリカバリ
このシナリオでは、管理対象サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストBにリカバリする必要があります。
同じホストに管理対象サーバーをリカバリするには:
-
ホストBでノード・マネージャを起動します。
cd DOMAIN_HOME/bin ./startNodeManager.sh
-
管理対象サーバーを起動します。たとえば:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが起動した場合、管理対象サーバーは管理サーバーに接続し、構成の変更を更新します。これ以上のステップは必要ありません。
-
管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次のステップを実行します。
-
必要に応じて、OracleホームをバックアップからホストBにリカバリします。
tar -xf oracle_home_backup_06052017.tar
-
「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。
-
管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。たとえば:
cd Domain_Home tar -xf domain_home_backup_06052017.tar
ステップ3.eに進みます。
-
管理対象サーバーにOracle Forms ServicesまたはOracle Reportsが含まれない場合、次のステップを実行します。
-
packユーティリティを使用して、ホストAで実行されている管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば:
pack.sh -domain=/scratch/oracle/config/domains/domain_name -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
-
ホストBでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。
unpack.sh -template=/scratch/temp.jar -domain=/scratch/oracle/config/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
-
-
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
ノート:
-
ステージングなしおよび外部ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバー・ホスト・ディレクトリからアプリケーション・アーティファクトをコピーします。
-
ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
-
-
次のWLSTコマンドを使用して、ノード・マネージャのプロパティListenAddressを更新します。
readDomain('Domain_Home') cd('/') cd('NMProperties') set('ListenAddress','localhost') set('ListenPort',9001) updateDomain()
-
ノード・マネージャが起動していない場合は、起動します。
cd DOMAIN_HOME/bin ./startNodeManager.sh
-
管理対象サーバーを起動します。たとえば:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
-
親トピック: 管理対象サーバー・ホストの破損後のリカバリ
別のホストへの管理対象サーバーのリカバリ
このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストCにリカバリする必要があります。1台以上のWebLogic Serversをホストするコンピュータの論理表現である2台のマシン、ホストAのmachine_1およびホストBのmachine_2があります。
ノート:
Oracleホームは元と同じ場所にリカバリしてください。
別のホストに管理対象サーバーをリカバリするには:
-
管理対象サーバーのOracleホームをホストCにリカバリします。
tar -xf oracle_home_backup_06052014.tar
-
新しいホストを指すように、トポロジを再構成します。
-
バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、「WebLogic Server構成のロック」で説明しているようにWebLogic Serverの構成をロックします。
-
Fusion Middleware Controlで、新しいホストを指し示すようmachine_2の構成を変更します。
「WebLogicドメイン」メニューから「環境」を展開し、「マシン」を選択します。「マシン」ページで、machine_2を選択して、「構成」タブを選択します。次に、「ノード・マネージャ」を選択します。「リスニング・アドレス」をホストCのアドレスに変更します。「保存」をクリックします。
リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。詳細および手順については、 『Oracle WebLogic Serverセキュリティの管理』のホスト名検証の使用に関する項を参照してください。
-
管理対象サーバーの構成を、新しいホストを指すように変更します。
管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。続いて、サーバーの名前を選択します。「構成」タブ、続いて「一般」タブを選択します。
マシンをmachine_2に変更します。
「リスニング・アドレス」を新しいホストに変更します。(リスニング・アドレスが空白に設定されている場合は、それを変更する必要はありません。)
「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
-
「セッションの編集」メニューで「構成の解放」をクリックして、Oracle WebLogic Server構成のロックを解除します。
-
-
表18-1の説明に従って、必要なステップがあればそれを実行します。
-
「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。
-
管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。たとえば:
cd Domain_Home tar -xf domain_home_backup_042012.tar
ステップ7に進みます。
-
ステップ5に示されているコンポーネントが管理対象サーバーに含まれていない場合は、次のステップに従います。
-
packユーティリティを使用して、ホストAで実行されている管理サーバーからドメイン・テンプレートjarファイルを作成します。たとえば:
pack.sh -domain=/scratch/oracle/config/domains/domain_name -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
-
ホストCでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。
unpack.sh -template=/scratch/temp.jar -domain=/scratch/oracle/config/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
別のドメイン・ホームにリカバリする場合は、unpackコマンドで-app_dirスイッチを使用します。
-
-
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
ノート:
-
ステージングなしおよび外部ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバー・ホスト・ディレクトリからアプリケーション・アーティファクトをコピーします。
-
ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
-
-
次のWLSTコマンドを使用して、ListenAddressを更新します。
readDomain('Domain_Home') cd('/') cd('NMProperties') set('ListenAddress','localhost') set('ListenPort',9001) updateDomain()
-
ホストCでノード・マネージャが起動していない場合は、起動します。
cd DOMAIN_HOME/bin ./startNodeManager.sh
-
管理対象サーバーを起動します。たとえば:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
-
「Oracleインベントリの更新」の説明に従って、Oracleインベントリを更新します。
-
Windowsでは、「Windowsレジストリのリカバリ」の説明に従って、Windowsレジストリをリカバリします。
-
環境にOracle HTTP Serverが含まれる場合、「mod_wl_ohs.confファイルの変更」の説明に従って、mod_wl_ohs.confファイルを修正します。
これで、ホストAで実行されている管理サーバーを使用して、ホストCの管理対象サーバーを起動および停止できます。
親トピック: 管理対象サーバー・ホストの破損後のリカバリ
コンポーネント・ホストの破損後のリカバリ
コンポーネント(およびその管理対象サーバー(該当する場合))を含むホストが破損した場合、次の各項目で説明する手順を使用して、ほとんどのコンポーネントを同じホストまたは別のホストにリカバリできます。
コンポーネントによっては追加操作が必要なものがあります。それらは、表18-1で示した項で説明しています。
- 同じホストまたは別のホストへのJavaコンポーネントのリカバリ
- 別のホストへのJavaコンポーネントのリカバリ
- 同じホストまたは別のホストへのシステム・コンポーネントのリカバリ
- ホスト破損後のOracle SOA Suiteのリカバリ
- 別のホストへのWeb層コンポーネントのリカバリ
- 別のホストへのOracle Forms Servicesのリカバリ
- 別のホストへのOracle Reportsのリカバリ
- 別のホストへのOracle BI Enterprise Editionのリカバリ
- 別のホストへのOracle Business Intelligence Publisherのリカバリ
- 別のホストへのOracle Data Integratorのリカバリ
- 別のホストへのOracle WebCenter Contentのリカバリ
- 別のホストへのアイデンティティ管理コンポーネントのリカバリ
親トピック: ホスト破損後のリカバリ
同じホストまたは別のホストへのJavaコンポーネントのリカバリ
Javaコンポーネントを同じホストにリカバリするには、次の手順に従います。
- 「同じホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
- 表18-1に示すように、コンポーネントに追加ステップが必要な場合は、それらのステップを実行します。
親トピック: コンポーネント・ホストの破損後のリカバリ
別のホストへのJavaコンポーネントのリカバリ
別のホストにJavaコンポーネントをリカバリするには:
- 「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
- 表18-1に示すように、コンポーネントに追加ステップが必要な場合は、それらのステップを実行します。
親トピック: コンポーネント・ホストの破損後のリカバリ
同じホストまたは別のホストへのシステム・コンポーネントのリカバリ
Oracle HTTP Serverなどのシステム・コンポーネントを同じホストまたは別のホストにリカバリするには、次のようにします。
-
スタンドアロン・ドメインにあるOracle HTTP Serverなどのシステム・コンポーネントの場合は、「スタンドアロン・ドメイン・ホストの破損後のリカバリ」の説明に従って、ドメインをリカバリします。
-
Oracle WebLogic ServerドメインにあるOracle HTTP Serverなどのシステム・コンポーネントの場合は、「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」の説明に従って、ドメインをリカバリします。
ただし、表18-1に示すように、一部のコンポーネントでは追加ステップが必要です。
親トピック: コンポーネント・ホストの破損後のリカバリ
ホスト破損後のOracle SOA Suiteのリカバリ
同じホストにOracle SOA Suite管理対象サーバーをリカバリするには、「同じホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
ホストの破損後に別のホストにOracle SOA Suite管理対象サーバーをリカバリするには:
-
リカバリを実行する前に、新しいホスト名とポートを指すようにWSDLファイルを更新します。
-
「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
-
Oracle SOA Suite管理対象サーバーのリカバリ後に、次の操作を実行します。
-
SOAインフラMBeanでホスト名を変更します。
-
Fusion Middleware Controlで、管理対象サーバーにナビゲートします。
-
「WebLogicサーバー」メニューから、「システムMBeanブラウザ」を選択します。
-
「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「SoaInfraConfig」を開きます。「soa-infra」を選択します。
-
「属性」タブで、「ServerURL」をクリックします。ServerURL属性に値が含まれている場合は、ホスト名を新しいホスト名に変更します。
-
「適用」をクリックします。
-
-
WSDLファイルが新しいホスト名に更新されたアプリケーションをすべて再デプロイします。
ノート:
環境にロード・バランサが構成されておらず、Oracle SOA Suiteを別のホストにリカバリする必要がある場合、タスク・フローからのレスポンスおよび非同期レスポンスを保留している進行中のインスタンスはリカバリされません。ロード・バランサを使用して、別のホストにリカバリできるようにすることをお薦めします。
-
-
環境にロード・バランサが構成されている場合は、次の追加ステップを実行します。
-
Fusion Middleware Controlで、「WebLogicドメイン」メニューから、「環境」、「クラスタ」の順に選択します。
-
構成するクラスタを選択します。
-
「WebLogicクラスタ」メニューから、「管理」、「HTTP」の順に選択します。
-
「フロントエンド・ホスト」に、新しいホスト名を入力します。
-
「フロントエンドHTTPポート」および「フロントエンドHTTPSポート」(該当する場合)に、新しいポート番号を入力します。
-
管理対象サーバーをそれぞれ再起動します。
-
親トピック: コンポーネント・ホストの破損後のリカバリ
別のホストへのWeb層コンポーネントのリカバリ
Web層はOracle HTTP Serverで構成されています。次の各項目では、別のホストにリカバリする方法について説明します。
親トピック: コンポーネント・ホストの破損後のリカバリ
スタンドアロン・ドメインのOracle HTTP Serverを別のホストにリカバリする
スタンドアロン・ドメインのOracle HTTP Serverをリカバリするには:
親トピック: 別のホストへのWeb層コンポーネントのリカバリ
WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリする
Oracle WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリするには:
-
「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」の説明に従って、ドメインをリカバリします。
-
ホストBにあったOracle HTTP Serverインスタンスの構成を変更します。
-
Fusion Middleware Controlのナビゲーション・ペインで、「HTTPServer」を展開します。
-
Oracle HTTP Serverインスタンス(ohs1など)を選択します。
-
「Oracle HTTP Server」メニューから「管理」、「ポート構成」の順に選択します。
-
表の各ポートでポートを選択し、「編集」をクリックします。「IPアドレス」を変更します。
「任意」を選択した場合、変更を行う必要はありません。
-
「OK」をクリックします。
-
-
Oracle HTTP Serverの各インスタンスについて、mod_wl_ohsワイヤリングを更新します。
-
Fusion Middleware Controlのナビゲーション・ペインで、「HTTP Server」を展開します。
-
Oracle HTTP Serverインスタンス(ohs1など)を選択します。
-
「Oracle HTTP Server」メニューから「管理」、「mod_wl_ohs構成」の順に選択します。
-
「ロケーション」のセクションで、「自動入力」をクリックします。
WebLogic Serverの有効なエンドポイント位置がすべて表示されます。
-
「適用」をクリックします。
-
-
障害が発生したマシン上にはないOracle HTTP Serverインスタンスに移動し、「起動」をクリックして、そうしたインスタンスをすべて再起動します。
-
ホストC上の各Oracle HTTP Serverインスタンスに移動し、「起動」をクリックして起動します。
親トピック: 別のホストへのWeb層コンポーネントのリカバリ
別のホストへのOracle BI Enterprise Editionのリカバリ
Oracle BI EEを別のホストにリカバリできます。
次の各トピックでは、Oracle BI EEを同じ名前の別のホストに移動する方法について説明します。
親トピック: コンポーネント・ホストの破損後のリカバリ
クラスタ環境での別のホストへのOracle BI EEのリカバリ
このシナリオでは、ホストAとホストBの2つのホストにOracle BI EEクラスタがある場合を考えます。ホストAにはinstance1が含まれ、ホストBにはinstance2が含まれています。なんらかの理由(ホストのクラッシュなど)により、ホストAが置き換えられたため、ホストCにリカバリし、ホストCにinstance3が含まれるようにシステムをスケールアウトする必要があります。
障害が発生したエンティティをリカバリした後、次の追加ステップを実行します。
-
Windowsでは、次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
-
Windowsでは、「Oracle BI EEレジストリ・エントリのインポート」の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。
-
障害が発生したノードに管理サーバーが含まれている場合、「別のホストへの管理サーバーのリカバリ」のステップ1 - 4の説明に従ってリカバリします。
-
『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のOracle Business Intelligenceのスケールアウトに関する項の説明に従って、Oracle BI EEシステムをスケールアウトします。
次の点に注意してください。
-
ドメイン・ホームおよびアプリケーション・ホームのディレクトリの指定を入力する場合、存在していないディレクトリまたは空のディレクトリの指定を入力します。
-
ドメイン・ホーム・フィールドが空の場合は、ドメイン・ディレクトリを含むように次のファイルを更新します。
DOMAIN_HOME/nodemanager/nodemanager.domains
ノード・マネージャを起動する前に、次のステップを実行します。
-
ノード・マネージャが実行されている場合は、停止します。
-
ノード・マネージャを起動する前に、ORACLE_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティを
true
に設定します。cd ORACLE_HOME/oracle_common/common/bin ./setNMProps.sh
-
ノード・マネージャを再起動します。
cd DOMAIN_HOME/bin ./startNodeManager.sh
-
-
-
『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のBIHOST1上のコンポーネントのクローニングに関する項の説明に従って、システム・コンポーネントをスケールアウトします。それらの構成を変更すると、Fusion Middleware Controlに、各インスタンスの再起動を求めるプロンプトが表示されます。インスタンスを再起動します。
ホストAのinstance1は使用できないので、BIサーバー、プレゼンテーション・サービス、およびJavaHostの数を0に変更する必要があります。それらの構成を変更すると、Fusion Middleware Controlに、各インスタンスの再起動を求めるプロンプトが表示されます。インスタンスを再起動します。
-
Fusion Middleware Controlを使用して、instance2をプライマリ・インスタンスに、instance3をセカンダリ・インスタンスにします。
-
instance 2をプライマリ・インスタンスにし、セカンダリ・インスタンスにはなにも指定しません。Fusion Middleware Controlのプロンプトに表示されたとおりにインスタンスをアクティブ化し、再起動します。
-
instance3をセカンダリ・インスタンスにします。Fusion Middleware Controlのプロンプトに表示されたとおりにインスタンスをアクティブ化し、再起動します。
『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のBIHOST1上のコンポーネントのクローニングに関する項を参照してください。
-
-
bi_servern管理対象サーバーのリスニング・アドレスを設定します。
-
Oracle HTTP Serverがインストールされている場合、Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定して、Oracle BIの検索URLが正しく設定されていることを保証します。
-
管理対象サーバーのノード・マネージャを構成します。
-
Oracle BI EE管理対象サーバーおよびすべてのシステム・コンポーネントを起動します。
環境に応じて、前のステップを実行した後に、追加ステップを実行する必要がある場合があります。
-
障害が発生したホストにマスターBIサーバー、プライマリ・クラスタ・コントローラおよびプライマリOracle BIスケジューラが含まれており、新しいインスタンスをマスターBIサーバーにする必要がある場合、必要に応じて次のステップを実行します。インスタンス2を引き続きマスターBIサーバーにする場合は、この追加ステップを実行する必要はありません。
-
マスターBIサーバーが失われた場合、次の手順を実行します。
-
すべてのノードでOracle WebLogic Serverおよびシステム・コンポーネント・プロセスを停止します。
-
新しいマスターBIサーバーを指定するように次の構成ファイルを更新します。
DOMAIN_HOME/config/fmwconfig/biee-domain.xml
<AvailabilityOptions>セクションで、次のように編集します。
masterBIServerOracleInstanceId="instance_name" masterBIServerComponentId="component_id"
また、次の設定も更新します。
<OracleInstance id="instance1" host="hostname" instanceHome="path_to_instance_home" opmnLocalPort="9500" opmnRemotePort="number"> <SchedulerOptions dataSource="(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname(PORT=number)))
-
他のホストにファイルをコピーします。
-
管理サーバーおよび管理対象サーバーを再起動します。
-
-
プライマリ・クラスタ・コントローラまたはスケジューラが失われた場合、スタンバイ・クラスタ・コントローラまたはスケジューラにフェイルオーバーされます。これはプライマリ・クラスタ・コントローラになるように再構成するか、プライマリ・コンポーネントに障害が発生しているために有効にされているセカンダリのままにするかを決定する必要があります。『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のOracle BIEEデータ・ソースの設定に関する項を参照してください。
-
-
障害が発生したホストにBIサーバー、セカンダリ・クラスタ・コントローラおよびセカンダリOracle BIスケジューラが含まれている場合、セカンダリ・クラスタ・コントローラまたはスケジューラとして新しいホストを指定します。
-
障害が発生したホストにBIサーバーおよびBIプレゼンテーション・サービスやBI Javaホストなどのシステム・コンポーネントが含まれる場合、追加ステップは不要です。
-
障害が発生したホストに次の関連するコンポーネントが含まれる場合、それらをリカバリします。
-
Oracle Business Intelligence Publisher: 「別のホストへのOracle Business Intelligence Publisherのリカバリ」を参照してください。
-
Oracle Real-Time Decisions。
-
Oracle BI EEレジストリ・エントリのインポート
Windowsでは、Oracle BI EEレジストリ・エントリを新しいホストにインポートする必要があります。「Windowsレジストリ・エントリのバックアップ」に、元のホストからそれらをエクスポートする方法が説明されています。
- 元のホストからエクスポートされたすべてのファイルを新しいホストにコピーします。
- 元のホストからコピーした各ファイルをダブルクリックします。入力を求められたら「はい」をクリックして、ファイルをレジストリにインポートします。
別のホストへのOracle Business Intelligence Publisherのリカバリ
障害が発生したエンティティをリカバリした後、次の追加ステップを実行します。
-
Oracle BIプレゼンテーション・サービスに対するサーバー値を変更します。
-
http://hostname:port/xmlpserver
でBI Publisherアプリケーションを開いてログインします。 -
「管理」→「統合」→「Oracle BIプレゼンテーション・サービス」をクリックします。
-
「サーバー」を新しいホスト名に変更します。
-
「適用」をクリックします。
-
-
コールド・フェイルオーバー・クラスタ環境で動作するようにOracle BI Publisherを変換するには、BIスケジューラのJMS構成を変更する必要があります。
-
BI Publisherアプリケーションで、「管理」をクリックします。
-
システム管理セクションで、スケジューラ構成をクリックします。
-
「Weblogic JNDI URL」を新しいホストURLに変更します。たとえば、
t3://hostname:port
と指定します。 -
「適用」をクリックします。
-
-
コールド・フェイルオーバー・クラスタを使用している場合は、仮想IPアドレスをリスニングするように管理対象サーバーを構成します。『高可用性ガイド』のOracle WebLogic管理対象サーバーの変換に関する項を参照してください。次に、Fusion Middleware Control、管理コンソールまたはWLSTコマンド行を使用して、管理対象サーバーを再起動します。
-
BI Publisherでは、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更するか、作成する必要があります(新規作成する場合は新しい仮想ホストを使用)。データ・ソースを変更するには:
-
BI Publisherアプリケーションで、次の手順を実行します。
-
「データ・ソース」の下にある「JDBC接続」をクリックします。
-
このインスタンスのBI Enterprise Editionのデータ・ソースをすべて編集して、新しいホストに対する値を反映するようにします。
-
バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。
親トピック: コンポーネント・ホストの破損後のリカバリ
別のホストへのOracle Data Integratorのリカバリ
Oracle Data Integratorをリカバリするには、障害に応じて、次のトピックの一方または両方の手順に従います。
親トピック: コンポーネント・ホストの破損後のリカバリ
別のホストへのOracle WebCenter Contentのリカバリ
別のホストにOracle WebCenter Contentをリカバリするには:
データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。
親トピック: コンポーネント・ホストの破損後のリカバリ
別のホストへのアイデンティティ管理コンポーネントのリカバリ
ほとんどのIdentity Managementコンポーネントの場合、「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
一部のコンポーネントでは、次の各項で説明しているように、別のホストへのリカバリに追加ステップが必要です。
- 別のホストへのOracle Internet Directoryのリカバリ
- 別のホストへのOracle Directory Integration Platformのリカバリ
- 別のホストへのOracle Identity Governanceのリカバリ
- 別のホストへのOracle Access Management Access Managerのリカバリ
- ホスト破損後のOracle Access Management Security Token Serviceのリカバリ
- 別のホストへのOracle Access Management Mobile and Socialのリカバリ
- 別のホストへのOracle Access Management Identity Federationのリカバリ
親トピック: コンポーネント・ホストの破損後のリカバリ
別のホストへのOracle Directory Integration Platformのリカバリ
別のホストにOracle Directory Integration Platformをリカバリするには:
別のホストへのOracle Identity Governanceのリカバリ
別のホストにOracle Identity Governanceをリカバリするには:
- 「管理サーバー・ホストの破損後のリカバリ」の説明に従って、ドメインをリストアします。
- 「Oracleホームのリカバリ」の説明に従って、Oracleホームをリストアします。
- 必要に応じて、OIM、OID、MDS、OPSSおよびSOAINFRAスキーマが含まれるデータベースをリストアします。「データベースのリカバリ」を参照してください。
- Oracle Identity GovernanceデータベースとLDAPプロバイダを同期します。『Oracle Identity Governanceの管理』のOracle Identity GovernanceとLDAP間のユーザー定義フィールドの同期に関する項を参照してください。
- weblogicExportMetadata.shスクリプトを使用して、oim-config.xmlファイルをエクスポートします。SOA URLのホスト名またはIPアドレスを変更することによって、エクスポートしたファイルを編集します。weblogicImportMetadata.shスクリプトを使用して、このファイルをMDSにインポートします。
- 「特定のコンポーネントの新しいマシンの作成」の説明に従って、新しいホスト名で新しいマシンを作成します。
- 「特定のアイデンティティ管理コンポーネントの、ユーザーのグループへの再関連付けの説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストへのOracle Access Management Access Managerのリカバリ
別のホストにAccess Managerをリカバリするには:
-
「Oracleホームのリカバリ」および 「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、Oracleホームおよびドメイン・ホームをリストアします。
-
必要に応じて、「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、WebGateが含まれるOracle HTTP ServerのOracleホームをリストアします。
-
Oracle HTTP Serverをリストアします。
-
WLSエージェントをリストアするには、「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリストアします。
-
Access Managerコンソールにログインします。
-
ホスト名を変更して、Access Managerプロキシ・サーバーの新規ホスト名を指定します。『Oracle Access Management管理者ガイド』の個々のOAMサーバーおよびプロキシ設定の表示または編集を参照してください。
-
オプションで、ロード・バランサがある場合、ホスト名を変更します。『Oracle Access Management管理者ガイド』のロード・バランシングの管理を参照してください。
-
保護されているページがある場合、Oracle Single Sign-OnまたはWebGateをAccess Managerでのパートナとして再び登録する必要があります。
-
Oracle Access Managerコンソールにログインします。
-
起動パッドから、Application Managementで、「SSOエージェント」をクリックします。
-
すべての構成済SSOエージェントの場合、新しいホストの名前ですべてのホスト名を更新します。
-
設定されている場合、「サーバー・リスト」は新しいホスト名を参照します。
-
設定されている場合、ユーザー定義パラメータは新しいホスト名を参照します。
-
設定されている場合、ログアウトのリダイレクトURLは新しいホスト名を参照します。
-
または、『Oracle Access Management管理者ガイド』のエージェントおよびアプリケーションの登録の説明に従って、oamregツールを使用できます。同じマニュアルでリモート登録ツールの取得および設定に関する項も参照してください。
-
-
「特定のコンポーネントの新しいマシンの作成」の説明に従って、新しいホスト名で新しいマシンを作成します。
-
WebGate構成ファイルのObAccessClient.xmlを編集して、Access Managerサーバーのホスト名を更新します。このファイルは次のディレクトリにあります。
DOMAIN_HOME/output/agentName/
-
「特定のアイデンティティ管理コンポーネントの、ユーザーのグループへの再関連付け」の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストへのOracle Access Management Identity Federationのリカバリ
Identity FederationではSSO機能が提供されるため、ホスト破損からのリカバリの一環としてIdentity Federationを実行しているホストの名前を変更すると、リモート・パートナが影響を受けます。この場合、リモート・パートナで操作を続行するには、リモート・パートナでホスト名に関する変更を加える必要があります。リモート・パートナでデータを更新するには数日かかる場合があり、これは許容できない生産性の低下を招くことにもなりかねません。スタンドアロンのIdentity Federationサーバーのホスト名は変更しないことを強くお薦めします。
ロード・バランサが環境の一部であり、Identity FederationをリカバリしているホストがVIPのリストに含まれている場合は、ホスト名の変更は必要ありません。
Identity Federationのスタンドアロン・インストールの場合は、影響を最小限に抑えるために、同じ名前の新しいホストを使用することをお薦めします。ただし、どのような理由であれ、リカバリしているIdentity Federationに別のホスト名を使用する必要がある場合は、Identity Federationおよびリモート・パートナに対してホスト名を手動で更新する必要があります。
別のホストにIdentity Federationをリカバリするには:
-
「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
-
更新されたデータをリモート・パートナに提供します。
-
Fusion Middleware Controlを使用して、ホスト名を変更します。
-
ナビゲーション・ペインで、ファームを開いてから、「Identity and Access」を開きます。
-
Identity Federationインスタンスを選択します。
-
「Identity Federation」メニューで、「管理」→「サーバー・プロパティ」を選択します。
「サーバー・プロパティ」ページが表示されます。
-
「ホスト」で、以前のホスト名を新しいホスト名に置き換えます。
-
ポート番号が変更されている場合は、「ポート」のポート番号を置き換えます。
-
SOAPポート番号が変更されている場合は、「SOAPポート」のポート番号を置き換えます。
-
「適用」をクリックします。
-
Identity Federationのデプロイ先の管理対象サーバーを再起動します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
-
-
Identity FederationがSSLサーバーとして機能している場合は、Identity Federationからクライアントに示されているSSL証明書を、新しいホスト名を持つ新しい証明書に置き換える必要があります。そうしないと、クライアントによるホスト名の検証が失敗する場合があります。
ホストの破損後にエンティティをリカバリするための追加の操作
リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち1つ以上を実行することが必要な場合があります。そのような場合は、エンティティをリカバリする方法を説明している項に明記されています。
次の各項目で、実行することが必要な可能性のある操作について説明します。
- 別のホストへのFusion Middleware Controlのリカバリ
- mod_wl_ohs.confファイルの変更
- 特定のコンポーネントの新しいマシンの作成
- 特定のアイデンティティ管理コンポーネントの、ユーザーのグループへの再関連付け
- Oracleインベントリの更新
- Windowsレジストリのリカバリ
親トピック: ホスト破損後のリカバリ
別のホストへのFusion Middleware Controlのリカバリ
Fusion Middleware Controlを別のホストにリカバリするには、システムMBeanブラウザを使用してプロパティを更新します。
mod_wl_ohs.confファイルの変更
管理サーバーまたは管理対象サーバーを別のホストにリカバリする場合、環境にOracle HTTP Serverが含まれていると、新しいホスト上で次のファイルを変更する必要があります。
(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_name/mod_wl_ohs.conf (Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\ohs_name\mod_wl_ohs.conf
WebLogic ServerドメインのOracle HTTP Serverでは、このディレクトリは管理サーバーのドメイン・ホームにあります。スタンドアロン・ドメインのOracle HTTP Serverでは、このディレクトリはOracle HTTP Serverのドメイン・ホームです。
そのファイルで、ホスト名、ポート、およびクラスタのエントリのすべてのインスタンス(WebLogicHost、WebLogicPort、WebLogicClusterなどの要素)を変更します。たとえば:
<Location /console> SetHandler weblogic-handler WebLogicHost Admin_Host WeblogicPort Admin_Port WLProxySSL ON WLProxySSLPassThrough ON </Location> . . . <Location /soa-infra> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN2:8001,*SOAHOST2VHN1*:*8001* WLProxySSL ON WLProxySSLPassThrough ON </Location>
特定のアイデンティティ管理コンポーネントの、ユーザーのグループへの再関連付け
次のアイデンティティ管理コンポーネントのバックアップをリストアすると、Weblogicユーザーは、前に関連付けられていたグループとは関連付けられなくなります。
-
Oracle Access Management Access Manager
-
Oracle Identity Governance
Weblogicユーザーをグループに再関連付けする必要があります。
ユーザーのグループへの関連付けの詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのユーザーのグループへの追加に関する項を参照してください。
Oracleインベントリの更新
多くのコンポーネントで、別のホストにリカバリするときは、ホストの破損の場合と同様に、Oracleインベントリを更新する必要があります。そのためには、次のスクリプトを実行します。
(UNIX) ORACLE_HOME/oui/bin/attachHome.sh (Windows) ORACLE_HOME\oui\bin\attachHome.cmd
Windowsレジストリのリカバリ
Windows上で別のホストにコンポーネントをリカバリするときは、ホストの破損の場合と同様に、Oracle Fusion Middlewareに関連するすべてのWindowsレジストリ・キーを新しいホストにインポートする必要があります。(レジストリ・キーは、「Windowsレジストリ・エントリのバックアップ」でエクスポートしたものです。)
次のレジストリ・キーをリカバリします。
HKEY_LOCAL_MACHINE\Software\Oracle
さらに、次のレジストリ・キー内のOracleで始まる各ノードをリカバリします。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services
前にエクスポートしたキーをインポートするには、次のコマンドを使用します。
regedit /I FileName
たとえば:
regedit /I C:\oracleregistry.reg
レジストリ・エディタのヘルプに説明されているように、キーのインポートにはレジストリ・エディタを使用することもできます。