環境のリカバリ

18 環境のリカバリ

Oracle Fusion Middlewareを様々なタイプの障害および停止(メディア障害やホストの破損など)からリカバリするための推奨されるリカバリ戦略および手順が用意されています。

リカバリ戦略の概要
リカバリ戦略により、実データの損失などの重大な障害からのリカバリが可能になります。
データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ
実データの損失や破損、またはディスクのリストアが不可能なメディア障害を伴う停止の場合に、環境の一部または全体をリカバリする必要があります。また、状況によっては、正しく機能しなくなったアプリケーションをリカバリする必要もあります。このタイプの障害では、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 Access Managerのリカバリ
Oracle Access Management Mobile and Social	該当なし	別のホストへのOracle Access Management Mobile and Socialのリカバリ
セキュリティ・トークン・サービス	該当なし	ホスト破損後のOracle Access Management Security Token Serviceのリカバリ
Oracle Access Management Identity Federation	該当なし	別のホストへのOracle Access Management Identity Federationのリカバリ
Oracle B2B	Oracle B2Bのリカバリ	Oracle B2Bのリカバリ
Oracle BI EE	Oracle BI Enterprise Editionのリカバリ	同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「別のホストへのOracle BI Enterprise Editionのリカバリ」を参照してください。
Oracle Business Intelligence Publisher	該当なし	同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「別のホストへのOracle Business Intelligence Publisherのリカバリ」を参照してください。
Oracle Data Integrator	該当なし	別のホストへのOracle Data Integratorのリカバリ
Oracleディレクトリ統合プラットフォーム	該当なし	別のホストへのOracle Directory Integration Platformのリカバリ
Oracle Forms Services	該当なし	同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「別のホストへのOracle Forms Servicesのリカバリ」を参照してください。
Oracle HTTP Server	該当なし	別のホストへのWeb層コンポーネントのリカバリ
Oracle Identity Governance	Oracle Identity Governanceのリカバリ	別のホストへのOracle Identity Governanceのリカバリ
Oracle Internet Directory	該当なし	別のホストへのOracle Internet Directoryのリカバリ
Oracle Platform Security Services	Oracle Platform Security Servicesのリカバリ	Oracle Platform Security Servicesのリカバリ
Oracle Reports	該当なし	別のホストへのOracle Reportsのリカバリ
Oracle SOA Suite	該当なし	同じホストにリカバリする場合は、追加ステップは必要ありません。別のホストにリカバリする場合は、「ホスト破損後のOracle SOA Suiteのリカバリ」を参照してください。
Oracle WebCenter Content	Oracle WebCenter Contentのリカバリ	別のホストへのOracle WebCenter Contentのリカバリ
Oracle WebCenter Content: Records。	Oracle WebCenter Contentをリカバリします。「Oracle WebCenter Contentのリカバリ」を参照してください。	Oracle WebCenter Contentをリカバリします。「別のホストへのOracle WebCenter Contentのリカバリ」を参照してください。
Oracle WebCenter Portalの分析	Oracle WebCenter Portal分析のリカバリ	Oracle WebCenter Portal分析のリカバリ
Oracle WebLogic Server	Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、「サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ」を参照してください。	Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、「サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ」を参照してください。

アプリケーション(リカバリが必要な場合)。「アプリケーションのリカバリ」を参照してください。

親トピック: リカバリ戦略の概要

データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

実データの損失や破損、またはディスクのリストアが不可能なメディア障害を伴う停止の場合に、環境の一部または全体をリカバリする必要があります。また、状況によっては、正しく機能しなくなったアプリケーションをリカバリする必要もあります。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。

ノート:

エンティティは、元のエンティティと同じパスにのみリストアできます。そのパスは、同じホスト上であっても、異なるホスト上であってもかまいません。

親トピック: 環境のリカバリ

Oracleホームのリカバリ

破損したりファイルが削除されたOracleホームをリカバリできます。

Oracleホームをリカバリするには:

関連するすべてのプロセスを停止します。つまり、管理サーバー、ノード・マネージャ、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
```
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
```
Oracleホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。
バックアップからOracleホーム・ディレクトリをリカバリします。たとえば:
```
(UNIX) tar -xf oracle_home_backup_06052017.tar
(Windows) jar xf oracle_home_backup_06052017.jar
```
関連するすべてのプロセスを起動します。つまり、管理サーバーや管理対象サーバーなど、Oracleホームで実行されているすべてのプロセスを開始します。たとえば、管理サーバーを起動します。
```
DOMAIN_HOME/bin/startWebLogic.sh 
```

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

Oracle WebLogic Serverドメインのリカバリ

破損したりファイル・システムから削除された場合、またはドメインが格納されているホストが破損した場合、Oracle WebLogic Serverドメインをリカバリすることができます。

注意:

ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

破損したりファイル・システムから削除されたOracle WebLogic Serverドメインをリカバリするには:

関連するプロセスが実行中である場合、そのプロセスをすべて停止します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。
```
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
```
Oracle HTTP Serverなどのシステム・コンポーネントの停止の詳細は、「コマンド行を使用したコンポーネントの起動と停止」を参照してください。
ドメイン・ホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。

バックアップからドメイン・ディレクトリをリカバリします。

(UNIX) tar -xf domain_backup_06052017.tar 
(Windows) jar xf domain_backup_06052017.jar

関連するすべてのプロセスを起動します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを開始します。たとえば、管理サーバーを起動します。
```
DOMAIN_HOME/bin/startWebLogic.sh 
```
Oracle HTTP Serverなどのシステム・コンポーネントの起動の詳細は、「コマンド行を使用したコンポーネントの起動と停止」を参照してください。
管理サーバーを起動できない場合は、「管理サーバー構成のリカバリ」の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、「管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。

サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ

データベース・リース(たとえば、サーバー全体の移行)を使用して、Oracle WebLogic Serverをリカバリする場合は、リース表内の情報を破棄する必要があります。単にリース表を破棄して再作成する場合は、リース表作成スクリプトを実行します。(サーバー全体の移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照。)

親トピック: Oracle WebLogic Serverドメインのリカバリ

スタンドアロン・ドメインのリカバリ

破損したりファイル・システムから削除された場合、またはホストが破損して同じホストにリカバリする必要がある場合、Oracle HTTP Serverなどのシステム・コンポーネントが含まれているスタンドアロン・ドメインをリカバリできます。

スタンドアロン・ドメインをリカバリするには、次の手順に従います。

Oracle HTTP Serverなどのシステム・コンポーネントやノード・マネージャが実行中の場合は、停止します。

破損している場合は、Oracleホームをリカバリします。

(UNIX) tar xf oracle_home_backup_05_21_2013.tar
(Windows) jar xf oracle_home_backup_05_21_2013.jar

ドメイン・ホームをリカバリします。

(UNIX) tar xf domain_backup_05_21_2013.tar
(Windows) jar xf domain_backup_05_21_2013.jar

ノード・マネージャを起動します。

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。
```
(UNIX) Domain_Home/bin/startComponent.sh ohs1
(Windows) Domain_Home\bin\startComponent.cmd ohs1
```

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

管理サーバー構成のリカバリ

ファイルの削除やファイル・システムの破損によって管理サーバー構成が失われた場合、問題発生時に管理コンソールがすでに起動されていれば、管理コンソールは機能し続けます。管理サーバーがユーザー名やパスワードのプロンプトを表示しないようにするには、「資格証明を入力しないサーバーの起動の有効化」を参照してください。

注意:

管理サーバーの構成をリカバリするには:

管理サーバー、管理対象サーバーおよびノード・マネージャが起動している場合はこれらも含めて、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
```
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
```
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
```
DOMAIN_HOME/config
```
管理サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startWebLogic.sh 
```
管理サーバーが正常に起動しており、アクセス可能であることを確認します。

構成が次回変更されるときに、管理サーバーの構成が、管理対象サーバーにプッシュされます。管理対象サーバーが再起動するたびに、管理サーバーから構成が取得されます。

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

管理対象サーバーのリカバリ

管理対象サーバーのファイルが削除されたり破損した場合、その構成ファイルを含めて、それらのファイルをリカバリできます。

このシナリオでは、管理対象サーバーが管理サーバーと同じホストに存在しておらず、適切に動作しない場合や起動できない場合を想定しています。この原因としては、構成の削除、構成の破損、構成を誤って変更したがその変更内容が不明であることなどが考えられます。

管理対象サーバーをリカバリするには、次の手順に従います。

管理サーバーにアクセスできない場合は、「管理サーバー構成のリカバリ」の説明に従って、管理サーバーをリカバリします。

管理対象サーバーが稼働中である場合は、停止します。たとえば:

DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url
        username password

必要に応じて、Oracleホームをバックアップからリカバリします。たとえば:
```
tar -xf oracle_home_backup_06052017.tar 
```
「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。
管理サーバーのホストでpackユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば:
```
pack.sh -domain=/scratch/oracle/config/domains/WLS_domain
  -template=/scratch/temp.jar -template_name=test_install 
  -template_author=myname -log=/scratch/logs/my.log -managed=true
```
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
管理対象サーバーのホストでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。次の例では、temp.jarはpackコマンドにより作成されたアーカイブです。
```
unpack.sh -template=/scratch/temp.jar
   -domain=/scratch/oracle/config/domains/WLS_domain
   -log=/scratch/logs/new.log -log_priority=info
```
ノート:
- 次のディレクトリが存在している必要があります。存在しない場合、unpackコマンドが失敗します。
```
ORACLE_HOME/config/domains/
```
- unpackコマンドの-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。環境で必要な場合は、-overwrite_domainオプションを使用してください。
- -app_dir引数を使用して別の場所に渡さないかぎり、アプリケーションはデフォルトで次のディレクトリに格納されます。
```
ORACLE_HOME/user_projects/applications/Domain_Name
```
管理対象サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
```
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

コンポーネントのリカバリ

コンポーネントのファイルが削除されたり破損した場合、またはコンポーネントの構成が変更されコミットされたためにコンポーネントが起動できないまたは適切に機能しない場合、コンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。

Javaコンポーネントの場合は、「管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
スタンドアロン・ドメインにあるOracle HTTP Serverなどのシステム・コンポーネントの場合は、「スタンドアロン・ドメインのリカバリ」の説明に従って、ドメインをリカバリします。
Oracle WebLogic ServerドメインにあるOracle HTTP Serverなどのシステム・コンポーネントの場合は、「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、ドメインをリカバリします。

次の項では、特定のコンポーネントに対して実行する必要がある追加のステップについて説明します。

Oracle Platform Security Servicesのリカバリ
Oracle B2Bのリカバリ
Oracle Identity Governanceのリカバリ
Oracle Access Management Access Managerのリカバリ
Oracle WebCenter Portal分析のリカバリ
Oracle WebCenter Contentのリカバリ
Oracle BI Enterprise Editionのリカバリ

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

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 Identity Governanceのリカバリ

Oracle Identity Governanceをリカバリするには:

「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、ドメインをリストアします。
「Oracleホームのリカバリ」の説明に従って、Oracleホームをリストアします。
OIM、MDS、SOAINFRAおよびOIDスキーマが含まれるデータベースを同じ時点にリストアします。「データベースのリカバリ」を参照してください。

Oracle Identity Governanceでは、LDAPストアにユーザーおよびロールを格納します。データベースをLDAPストアと異なる時点にリストアする場合、リコンシリエーション・エンジンでは変更ログをチェックして、LDAPストアとデータベースのリストアの間に発生したすべての変更を再度適用します。たとえば、データベースをLDAPストアの10時間後の時点にリストアする場合、リコンシリエーション・エンジンは変更ログをチェックしてLDAPストアで直前の10時間以内に発生したすべての変更をデータベースに再度適用します。

リコンシリエーションを明示的にトリガーする必要はありません。LDAP同期は定期的なスケジュール済タスクとして設定され、定期的にリコンシリエーション・イベントを発行します。また、リコンシリエーション・プロセスを手動で起動することや、Oracle Identity Governanceコンソールからリコンシリエーション・イベントを監視することもできます。『Oracle Identity Governanceの管理』のリコンシリエーションの構成に関する項を参照してください。

ノート:

前述のリカバリ・シナリオでバルク・リコンシリエーションが発生する場合、エンド・ユーザーによるOracle Identity Governanceアプリケーションの使用を停止することをお薦めします。バルク・リコンシリエーションが完了したら、エンド・ユーザーによるOracle Identity Governanceアプリケーションの使用を再開してください。リコンシリエーションは、Oracle Identity Governanceコンソールで監視できます。

親トピック: コンポーネントのリカバリ

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をリカバリするには:

必要に応じて、「データベース・ホストの破損後のリカバリ」の説明に従って、データベースをリストアします。
「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
```
cd /net/home/vault
tar -xf vault_backup_042012.tar 
```

データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、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ファイルの構成設定に関する項を参照してください。)

同期を有効にするには:
1. 次のファイルを編集します。
```
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI 
```
  フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSをyesに設定します。
2. サーバーを再起動します。LDAPデータベースの情報とRPDが同期化されます。
同期を無効にするには:
1. 同期を無効にするには、次のファイルを編集します。
```
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI 
```
  フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSをnoに設定します。
2. サーバーを再起動します。

Windows上のOracle BI管理ツールには、リポジトリの妥当性をチェックして不整合を修正できるConsistency Check Managerが用意されています。整合性チェック・マネージャの詳細は、『Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ・オブジェクトの整合性のチェックに関する項を参照してください。

親トピック: Oracle BI Enterprise Editionのリカバリ

LDAPデータベースとOracle BI Presentation Catalogの調整

LDAPデータベースがOracle BI Presentation Catalogの背後にあるよりも以前の時点にLDAPデータベースをリストアする場合は、次のコマンドを使用してLDAPデータベースとOracle BI Presentation Catalogを調整します。

runcat.cmd -cmd forgetAccounts

runcatコマンドの詳細は、次のようにヘルプを参照してください。

./runcat.sh -cmd maintenanceMode -help

親トピック: Oracle BI Enterprise Editionのリカバリ

クラスタのリカバリ

次の状況では、クラスタをリカバリする必要があります。

クラスタが誤って削除されているか、クラスタ・メンバーが誤って削除されている。
JMS構成またはコンテナレベルのデータ・ソースなどのクラスタレベルの構成が誤って変更されコミットされている。コンポーネントまたはサーバーは起動できないか、または適切に動作せず、サーバー内で実行中のサービスは起動されていません。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。

注意:

構成の変更が少ない場合、最も簡単な方法は、構成の変更を再実行することです。この方法を実行できない場合は、次の手順に従って構成をリカバリします。

クラスタを停止します。Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
```
shutdown('cluster_name', 'Cluster')
```
管理サーバーや管理対象サーバーなど、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
```
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
```
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
```
DOMAIN_HOME/config
```
管理サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startWebLogic.sh 
```
削除されたメンバーがすべてクラスタに戻ります。
管理対象サーバーなど、すべてのプロセスを起動します。たとえば、Linux上で管理対象サーバーを起動するには、次のスクリプトを使用します。
```
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
```
クラスタを起動します。Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
```
start('cluster_name', 'Cluster')
```

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

アプリケーションのリカバリ

アプリケーションのリカバリについては、次の点に注意してください。

アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
デプロイメント・モードがステージングなしまたは外部ステージングの場合、追加のアプリケーション・アーティファクトが使用可能であることを確認してください。たとえば、アプリケーションがドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。新しいファイル・システム上でのアプリケーション・ファイルの相対位置は、元の管理サーバーのファイル・システムと同じにする必要があります。

アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

次の各項目で、アプリケーションをリカバリする方法について説明します。

親トピック: データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

アプリケーション・アーティファクトのリカバリ

.earファイルなどのアプリケーションのアーティファクトが損失または破損した場合、そのアプリケーションをリカバリできます。

アプリケーションをリカバリするには:

アプリケーションのデプロイ先の管理対象サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
```
このコマンドを実行すると、構成が管理サーバーと同期されます。

管理対象サーバーが再起動するたびに、構成およびアプリケーション・アーティファクトが管理サーバーから取得されます。

親トピック: アプリケーションのリカバリ

Java EEアプリケーションのリカバリ

次の場合、Java EEアプリケーションをリカバリできます。

Java EEアプリケーションが管理対象サーバーに再デプロイされ(管理対象サーバーがクラスタの一部であるかどうかは関係ない)、アプリケーションが機能しなくなった場合。
デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合。
コンポジット・アプリケーションの新規バージョンが管理対象サーバーまたはクラスタに再デプロイされました。このアプリケーションが機能しなくなったとします。

アプリケーションをリカバリするには:

必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
バックアップから古いバージョンのアプリケーションを再デプロイします。

元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。

親トピック: アプリケーションのリカバリ

データベースのリカバリ

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ホームをリカバリします。

(UNIX) tar xf oracle_home_backup_05_21_2017.tar
(Windows) jar xf oracle_home_backup_05_21_2017.jar

ドメイン・ホームをリカバリします。

(UNIX) tar xf domain_backup_05_21_2017.tar
(Windows) jar xf domain_backup_05_21_2017.jar

スタンドアロン・ドメインでは、デフォルトで、ノード・マネージャはローカル・ホストでリスニングします。ただし、そうではない場合、次のWLSTコマンドを使用してListenAddressを更新できます。
```
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()
```

ノード・マネージャを起動します。

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

システム・コンポーネントの構成ファイルをすべて、手動で更新します。

特定コンポーネントの詳細は、「コンポーネント・ホストの破損後のリカバリ」を参照してください。
ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。たとえば:
```
(UNIX) Domain_Home/bin/startComponent.sh ohs1
(Windows) Domain_Home\bin\startComponent.cmd ohs1
```
「Oracleインベントリの更新」の説明に従って、Oracleインベントリを更新します。
Windowsの場合は、「Windowsレジストリのリカバリ」の説明に従って、Windowsレジストリを更新します。

親トピック: スタンドアロン・ドメイン・ホストの破損後のリカバリ

管理サーバー・ホストの破損後のリカバリ

管理サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

親トピック: ホスト破損後のリカバリ

同じホストへの管理サーバーのリカバリ

このシナリオでは、管理サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。たとえば、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されているとします。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをリカバリする必要があります。

同じホストに管理サーバーをリカバリするには:

ファイル・システムをリカバリします。たとえば、「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」の説明に従って、この管理サーバーが含まれるドメインをリカバリします。
管理サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startWebLogic.sh 
```
管理サーバーが起動する場合は、これ以上のステップは必要ありません。
管理サーバーが起動しない場合は、ホストAで次のステップを実行します。
1. 関連するすべてのプロセスを停止します。つまり、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。
2. 必要に応じて、Oracleホームをリカバリします。
```
tar -xf oracle_home_backup_06052017.tar 
```
3. ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。
```
tar -xf domain_backup_06052017.tar 
```
4. 管理サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startWebLogic.sh 
```
5. ホストの管理用URLを指定して、管理対象サーバーを起動します。
```
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
```
6. ノード・マネージャを起動します。
```
DOMAIN_HOME/bin/startNodeManager.sh
```

親トピック: 管理サーバー・ホストの破損後のリカバリ

別のホストへの管理サーバーのリカバリ

このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをホストCに移行する必要があります。

別のホストに管理サーバーをリカバリするには:

OracleホームをホストC (新規ホスト)にリカバリします。
```
tar -xf oracle_home_backup_06052017.tar 
```
ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。
```
tar -xf domain_backup_06052017.tar 
```
管理サーバーにリスニング・アドレスが指定されている場合は、「特定のコンポーネントの新しいマシンの作成」の説明に従って、新しいホスト名で新しいマシンを作成します。
管理サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startWebLogic.sh 
```
WLSTを使用して管理サーバーに接続し、新しいホストで実行されているノード・マネージャを管理サーバーに登録します。
```
connect('username','password','t3://host:port')
nmEnroll('/scratch/oracle/config/domains/domain_name',
  'DOMAIN_HOME/nodemanager')
```
Windowsの場合は、UNIXの場合と同様に、nmEnrollコマンドではバックスラッシュ(\)ではなくスラッシュ(/)を使用します。
ノード・マネージャのプロパティ・ファイルを編集して、リスニング・アドレス・プロパティを変更します。ドメインベースのノード・マネージャの場合、ファイルは次の場所にあります。
```
DOMAIN_HOME/nodemanager/nodemanager.properties
```
または、次のWLSTコマンドを使用してプロパティを変更できます。
```
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',port_num)
updateDomain()
```
元のホストでノード・マネージャが構成されていた場合は、ホストCでノード・マネージャを起動します。
```
cd DOMAIN_HOME/bin
./startNodeManager.sh
```
管理対象サーバーを起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』の障害が発生した管理サーバーの再起動に関する項では、構成に応じた様々な再起動方法について説明されています。
オプションの1つとして、次のスクリプトの使用があります。このコマンドでは、新しいホストの管理用URLを指定します。
```
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ファイルを修正します。

これで、ホストCで実行されている管理コンソールを使用して、ホストBの管理対象サーバーを起動および停止できます。

Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、「ホストの破損後にエンティティをリカバリするための追加の操作」を参照してください。

親トピック: 管理サーバー・ホストの破損後のリカバリ

管理対象サーバー・ホストの破損後のリカバリ

管理対象サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

親トピック: ホスト破損後のリカバリ

同じホストへの管理対象サーバーのリカバリ

このシナリオでは、管理対象サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストBにリカバリする必要があります。

同じホストに管理対象サーバーをリカバリするには:

ホストBでノード・マネージャを起動します。
```
cd DOMAIN_HOME/bin
./startNodeManager.sh
```
管理対象サーバーを起動します。たとえば:
```
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
```
管理対象サーバーが起動した場合、管理対象サーバーは管理サーバーに接続し、構成の変更を更新します。これ以上のステップは必要ありません。
管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次のステップを実行します。
1. 必要に応じて、OracleホームをバックアップからホストBにリカバリします。
```
tar -xf oracle_home_backup_06052017.tar 
```
2. 「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。
3. 管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。たとえば:
```
cd Domain_Home
tar -xf domain_home_backup_06052017.tar 
```
  ステップ3.eに進みます。
4. 管理対象サーバーに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
```
5. 管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
  ノート:
  - ステージングなしおよび外部ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバー・ホスト・ディレクトリからアプリケーション・アーティファクトをコピーします。
  - ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。
  アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
6. 次のWLSTコマンドを使用して、ノード・マネージャのプロパティListenAddressを更新します。
```
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()
```
7. ノード・マネージャが起動していない場合は、起動します。
```
cd DOMAIN_HOME/bin
./startNodeManager.sh
```
8. 管理対象サーバーを起動します。たとえば:
```
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 
```
新しいホストを指すように、トポロジを再構成します。
1. バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、「WebLogic Server構成のロック」で説明しているようにWebLogic Serverの構成をロックします。
2. Fusion Middleware Controlで、新しいホストを指し示すようmachine_2の構成を変更します。
  
  「WebLogicドメイン」メニューから「環境」を展開し、「マシン」を選択します。「マシン」ページで、machine_2を選択して、「構成」タブを選択します。次に、「ノード・マネージャ」を選択します。「リスニング・アドレス」をホストCのアドレスに変更します。「保存」をクリックします。
  
  リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。詳細および手順については、『Oracle WebLogic Serverセキュリティの管理』のホスト名検証の使用に関する項を参照してください。
3. 管理対象サーバーの構成を、新しいホストを指すように変更します。
  
  管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。続いて、サーバーの名前を選択します。「構成」タブ、続いて「一般」タブを選択します。
  
  マシンをmachine_2に変更します。
  
  「リスニング・アドレス」を新しいホストに変更します。(リスニング・アドレスが空白に設定されている場合は、それを変更する必要はありません。)
  
  「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
4. 「セッションの編集」メニューで「構成の解放」をクリックして、Oracle WebLogic Server構成のロックを解除します。
表18-1の説明に従って、必要なステップがあればそれを実行します。
「ノード・マネージャの起動と停止」の説明に従って、ノード・マネージャを停止します。
管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。たとえば:
```
cd Domain_Home
tar -xf domain_home_backup_042012.tar 
```
ステップ7に進みます。
ステップ5に示されているコンポーネントが管理対象サーバーに含まれていない場合は、次のステップに従います。
1. 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オプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
2. ホスト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コンポーネントを同じホストにリカバリするには、次の手順に従います。

「同じホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
表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でホスト名を変更します。
  1. Fusion Middleware Controlで、管理対象サーバーにナビゲートします。
  2. 「WebLogicサーバー」メニューから、「システムMBeanブラウザ」を選択します。
  3. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「SoaInfraConfig」を開きます。「soa-infra」を選択します。
  4. 「属性」タブで、「ServerURL」をクリックします。ServerURL属性に値が含まれている場合は、ホスト名を新しいホスト名に変更します。
  5. 「適用」をクリックします。
- WSDLファイルが新しいホスト名に更新されたアプリケーションをすべて再デプロイします。
ノート:

環境にロード・バランサが構成されておらず、Oracle SOA Suiteを別のホストにリカバリする必要がある場合、タスク・フローからのレスポンスおよび非同期レスポンスを保留している進行中のインスタンスはリカバリされません。ロード・バランサを使用して、別のホストにリカバリできるようにすることをお薦めします。
環境にロード・バランサが構成されている場合は、次の追加ステップを実行します。
1. Fusion Middleware Controlで、「WebLogicドメイン」メニューから、「環境」、「クラスタ」の順に選択します。
2. 構成するクラスタを選択します。
3. 「WebLogicクラスタ」メニューから、「管理」、「HTTP」の順に選択します。
4. 「フロントエンド・ホスト」に、新しいホスト名を入力します。
5. 「フロントエンドHTTPポート」および「フロントエンドHTTPSポート」(該当する場合)に、新しいポート番号を入力します。
6. 管理対象サーバーをそれぞれ再起動します。

親トピック: コンポーネント・ホストの破損後のリカバリ

別のホストへのWeb層コンポーネントのリカバリ

Web層はOracle HTTP Serverで構成されています。次の各項目では、別のホストにリカバリする方法について説明します。

親トピック: コンポーネント・ホストの破損後のリカバリ

スタンドアロン・ドメインのOracle HTTP Serverを別のホストにリカバリする

スタンドアロン・ドメインのOracle HTTP Serverをリカバリするには:

「スタンドアロン・ドメイン・ホストの破損後のリカバリ」のステップ1 - 4を実行します。
次のディレクトリの構成ファイルを更新します。
```
(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instance_name
```
たとえば、httpd.conf, admin.confおよびmod_wl_ohs.conf (必要な場合)のIPアドレスとホスト名を更新します。
「スタンドアロン・ドメイン・ホストの破損後のリカバリ」のステップ6 - 8を実行します。

親トピック: 別のホストへのWeb層コンポーネントのリカバリ

WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリする

Oracle WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリするには:

「Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ」の説明に従って、ドメインをリカバリします。
ホストBにあったOracle HTTP Serverインスタンスの構成を変更します。
1. Fusion Middleware Controlのナビゲーション・ペインで、「HTTPServer」を展開します。
2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。
3. 「Oracle HTTP Server」メニューから「管理」、「ポート構成」の順に選択します。
4. 表の各ポートでポートを選択し、「編集」をクリックします。「IPアドレス」を変更します。
  
  「任意」を選択した場合、変更を行う必要はありません。
5. 「OK」をクリックします。
Oracle HTTP Serverの各インスタンスについて、mod_wl_ohsワイヤリングを更新します。
1. Fusion Middleware Controlのナビゲーション・ペインで、「HTTP Server」を展開します。
2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。
3. 「Oracle HTTP Server」メニューから「管理」、「mod_wl_ohs構成」の順に選択します。
4. 「ロケーション」のセクションで、「自動入力」をクリックします。
  
  WebLogic Serverの有効なエンドポイント位置がすべて表示されます。
5. 「適用」をクリックします。
障害が発生したマシン上にはないOracle HTTP Serverインスタンスに移動し、「起動」をクリックして、そうしたインスタンスをすべて再起動します。
ホストC上の各Oracle HTTP Serverインスタンスに移動し、「起動」をクリックして起動します。

親トピック: 別のホストへのWeb層コンポーネントのリカバリ

別のホストへのOracle Forms Servicesのリカバリ

別のホストにOracle Forms Servicesをリカバリするには:

「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。

ssoregスクリプトを実行します。これは次の場所にあります。

Identity_Management_ORACLE_HOME/sso/bin

次のコマンドを使用します。

ssoreg.sh -site_name newhost:http_listen_port 
    -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE
    -oracle_home_path $ORACLE_HOME -config_file any_new_file_path
    -admin_info cn=orcladmin -virtualhost -remote_midtier

たとえば:

ssoreg.sh -site_name example.com:8090 
   -mod_osso_url http://example.com:8090 -config_mod_osso TRUE 
   -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf  
   -admin_info cn=orcladmin -virtualhost -remote_midtier

前のステップのファイルを新しいホストにコピーします。

新しいホストで、次のファイルのOssoConfigFileセクションを変更し、ステップ2のファイルのパスが含まれるようにします。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf

たとえば:

<IfModule mod_osso.c>
    OssoIpCheck off
    OssoSecureCookies off
    OssoIdleTimeout off
    OssoConfigFile /tmp/path_of_file_created

親トピック: コンポーネント・ホストの破損後のリカバリ

別のホストへのOracle Reportsのリカバリ

別のホストにOracle Reportsをリカバリするには:

「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。

次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。

nodemanager.properties。このファイルの場所は次のとおりです。
```
(UNIX) DOMAIN_HOME/nodemanager
(Windows) DOMAIN_HOME\nodemanager
```

reports_ohs.conf。このファイルの場所は次のとおりです。

(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs_name/moduleconf
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instances\ohs_name\moduleconf

rwservlet.properties。このファイルの場所は次のとおりです。

(UNIX) DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration
(Windows) DOMAIN_HOME\config\fmwconfig\servers\server_name\applications\reports_version\configuration

ファイル内で、<server>要素を変更して、新しいホスト名を使用します。

mbeans.xml。このファイルの場所は次のとおりです。

(Unix) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF
(Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF

親トピック: コンポーネント・ホストの破損後のリカバリ

別のホストへのOracle BI Enterprise Editionのリカバリ

Oracle BI EEを別のホストにリカバリできます。

次の各トピックでは、Oracle BI EEを同じ名前の別のホストに移動する方法について説明します。

親トピック: コンポーネント・ホストの破損後のリカバリ

非クラスタ環境での別のホストへのOracle BI EEのリカバリ

Windowsでは、障害が発生したエンティティをリカバリした後、次の追加ステップを実行します。

次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。
```
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
```
「Oracle BI EEレジストリ・エントリのインポート」の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。

親トピック: 別のホストへのOracle BI Enterprise Editionのリカバリ

クラスタ環境での別のホストへの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
 
```
  ノード・マネージャを起動する前に、次のステップを実行します。
  1. ノード・マネージャが実行されている場合は、停止します。
  2. ノード・マネージャを起動する前に、ORACLE_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
```
cd ORACLE_HOME/oracle_common/common/bin
./setNMProps.sh
```
  3. ノード・マネージャを再起動します。
```
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をセカンダリ・インスタンスにします。
1. instance 2をプライマリ・インスタンスにし、セカンダリ・インスタンスにはなにも指定しません。Fusion Middleware Controlのプロンプトに表示されたとおりにインスタンスをアクティブ化し、再起動します。
2. 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サーバーにする場合、必要に応じて次のステップを実行します。instance2を引き続きプライマリBIサーバーにする場合は、この追加ステップを実行する必要はありません。
- プライマリBIサーバーが失われた場合:
  1. すべてのノードでOracle WebLogic Serverおよびシステム・コンポーネント・プロセスを停止します。
  2. 新しいプライマリ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)))
```
  3. 他のホストにファイルをコピーします。
  4. 管理サーバーおよび管理対象サーバーを再起動します。
- プライマリ・クラスタ・コントローラまたはスケジューラが失われた場合、スタンバイ・クラスタ・コントローラまたはスケジューラにフェイルオーバーされます。これはプライマリ・クラスタ・コントローラになるように再構成するか、プライマリ・コンポーネントに障害が発生しているために有効にされているセカンダリのままにするかを決定する必要があります。『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 Enterprise Editionのリカバリ

Oracle BI EEレジストリ・エントリのインポート

Windowsでは、Oracle BI EEレジストリ・エントリを新しいホストにインポートする必要があります。「Windowsレジストリ・エントリのバックアップ」に、元のホストからそれらをエクスポートする方法が説明されています。

元のホストからエクスポートされたすべてのファイルを新しいホストにコピーします。
元のホストからコピーした各ファイルをダブルクリックします。入力を求められたら「はい」をクリックして、ファイルをレジストリにインポートします。

親トピック: 別のホストへのOracle BI Enterprise Editionのリカバリ

別のホストへのOracle Business Intelligence Publisherのリカバリ

障害が発生したエンティティをリカバリした後、次の追加ステップを実行します。

Oracle BIプレゼンテーション・サービスに対するサーバー値を変更します。
1. http://hostname:port/xmlpserverでBI Publisherアプリケーションを開いてログインします。
2. 「管理」→「統合」→「Oracle BIプレゼンテーション・サービス」をクリックします。
3. 「サーバー」を新しいホスト名に変更します。
4. 「適用」をクリックします。
コールド・フェイルオーバー・クラスタ環境で動作するようにOracle BI Publisherを変換するには、BIスケジューラのJMS構成を変更する必要があります。
1. BI Publisherアプリケーションで、「管理」をクリックします。
2. システム管理セクションで、スケジューラ構成をクリックします。
3. 「Weblogic JNDI URL」を新しいホストURLに変更します。たとえば、t3://hostname:portと指定します。
4. 「適用」をクリックします。
コールド・フェイルオーバー・クラスタを使用している場合は、仮想IPアドレスをリスニングするように管理対象サーバーを構成します。『高可用性ガイド』のOracle WebLogic管理対象サーバーの変換に関する項を参照してください。次に、Fusion Middleware Control、管理コンソールまたはWLSTコマンド行を使用して、管理対象サーバーを再起動します。
BI Publisherでは、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更するか、作成する必要があります(新規作成する場合は新しい仮想ホストを使用)。データ・ソースを変更するには:
1. BI Publisherアプリケーションで、次の手順を実行します。
2. 「データ・ソース」の下にある「JDBC接続」をクリックします。
3. このインスタンスのBI Enterprise Editionのデータ・ソースをすべて編集して、新しいホストに対する値を反映するようにします。

バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。

親トピック: コンポーネント・ホストの破損後のリカバリ

別のホストへのOracle Data Integratorのリカバリ

Oracle Data Integratorをリカバリするには、障害に応じて、次のトピックの一方または両方の手順に従います。

親トピック: コンポーネント・ホストの破損後のリカバリ

Oracle Data Integratorリポジトリのリカバリ

Oracle Data Integratorリポジトリを別のホストにリストアする必要がある場合は、次の手順を実行します。

「データベース・ホストの破損後のリカバリ」の説明に従って、データベースをリストアします。
ODI Studioを使用して、リストアされたOracle Data Integratorリポジトリに接続します。『Oracle Data Integratorでの統合プロジェクトの開発』のマスター・リポジトリへの接続に関する項の説明に従って、新しいデータベース・ホストへのプライマリ・リポジトリの新しい接続を作成します。
作業リポジトリをそれぞれ編集します。「接続」をクリックして、作業リポジトリが含まれる新しいデータベース・ホストを指すJDBC URLが含まれるように接続情報を編集します。
Oracle WebLogic Server構成内のOracle Data Integrator JEEエージェント・リポジトリ構成の場合は、新しいデータベース・ホストの場所と一致するようデータ・ソースを編集します。

次のWLSTオフライン・コマンドを使用して、Oracle Data Integratorスタンドアロン・エージェント・リポジトリ構成を更新します。

cd ORACLE_HOME/odi/common/bin
./wlst.sh
readDomain('DOMAIN_DIRECTORY')
cd('/JdbcSystemResource/OdiMasterRepository/JdbcResource/OdiMasterRepository/JDBCDriverParams/NO_NAME_0');
set('URL','NEW_JDBC_URL_TO_RECOVERED_DB');
updateDomain();
exit();

親トピック: 別のホストへのOracle Data Integratorのリカバリ

別のホストへのOracle Data Integratorエージェントのリカバリ

別のホストにOracle Data Integratorエージェントをリカバリするには:

「管理対象サーバー・ホストの破損後のリカバリ」の説明に従って管理対象サーバーをリストアすることによって、Oracle Data Integrator JEEエージェントをリストアします。
「コンポーネント・ホストの破損後のリカバリ」の説明に従って、Oracle Data Integratorスタンドアロン・システム・コンポーネントをリストアします。
ODI Studioを使用して、各物理エージェントの構成を編集し、更新したホスト名の値を指定して、ポートの値を変更した場合はポートの値も指定します。

次のコマンドを使用して、Oracle Data Integratorスタンドアロン・エージェントのホストおよびポート構成を更新します。

cd ORACLE_HOME/odi/common/bin
./wlst.sh
readDomain('DOMAIN_HOME')
cd('ODI/ODI_STANDALONE_AGENT_NAME')
set("ServerListenAddress",'UPDATED_HOST_NAME');
set("ServerListenPort",'UPDATED_PORT');
updateDomain();
exit();

スタンドアロン・エージェントおよびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを再起動します。

親トピック: 別のホストへのOracle Data Integratorのリカバリ

別のホストへのOracle WebCenter Contentのリカバリ

別のホストにOracle WebCenter Contentをリカバリするには:

データベースを別のホストにリストアする必要がある場合は、「データベース・ホストの破損後のリカバリ」の説明に従って、データベースをリストアします。
「管理サーバー・ホストの破損後のリカバリ」の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
```
cd /net/home/vault
tar -xf vault_backup_042012.tar 
```
次のファイルを編集します。
```
DOMAIN_HOME/ucm_domain/ucm/cs/config/config.cfg
```
このファイルで、新しいホストを指定するようにHttpServerAddressの設定を変更します。たとえば:
```
HttpServerAddress=hostname:port_number
```

親トピック: コンポーネント・ホストの破損後のリカバリ

別のホストへのアイデンティティ管理コンポーネントのリカバリ

ほとんどのIdentity Managementコンポーネントの場合、「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。

一部のコンポーネントでは、次の各項で説明しているように、別のホストへのリカバリに追加ステップが必要です。

親トピック: コンポーネント・ホストの破損後のリカバリ

別のホストへのOracle Internet Directoryのリカバリ

別のホストにOracle Internet Directoryをリカバリするには:

「同じホストまたは別のホストへのシステム・コンポーネントのリカバリ」の説明に従って、コンポーネントをリカバリします。
UNIXシステムおよびLinuxシステムでは、Oracle Internet Directoryの起動を試行する前に、次のファイルを、root権限を持つように設定します。
```
ORACLE_HOME/bin/oidldapd
```
たとえば:
```
chown root oidldapd
chmod 4710 oidldapd
```
Oracle Directory Services Managerがデプロイされている管理対象サーバーを別のサーバーに移動し、SSLを有効にする場合は、新しいホスト上の次のファイルを削除する必要があります。
```
DOMAIN_HOME/servers/wls_ods1/tmp/_WL_user/odsm_version/randomid/war/conf/odsm.cer
```
Oracle Directory Services Managerでは、このファイルがキーストアおよびトラスト・ストアとして使用され、パスワードがJKSに格納されます。ただし、Oracle Directory Services Managerが別のホストにコピーされ、起動された場合は、別のパスワードが生成されます。このファイルを削除すると、Oracle Directory Services Managerの起動時に、新しいパスワードとともに新しいファイルが作成されます。

親トピック: 別のホストへのアイデンティティ管理コンポーネントのリカバリ

別のホストへのOracle Directory Integration Platformのリカバリ

別のホストにOracle Directory Integration Platformをリカバリするには:

「別のホストへの管理対象サーバーのリカバリ」の説明に従って、管理対象サーバーをリカバリします。
管理対象サーバーを起動する前に、次のディレクトリにあるファイルをリストアします。
```
DOMAIN_HOME/servers/wls_ods1/stage/DIP/version/
```
管理対象サーバーおよびOracleインスタンスを起動します。

Oracle Internet Directoryも別のホストに移動する場合は、管理対象サーバーとOracleインスタンスの起動直後に次のコマンドを実行します。

set ORACLE_HOME Oracle_home_path
set WLS_HOME WLS_Home_path
cd ORACLE_HOME/bin
./manageDIPServerConfig set -h dip_server_host -p dip_server_port 
    -D weblogic_user -attribute oidhostport -value oid_host:oid_ssl_port

manageDIPServerConfigコマンドから、パスワードの入力を求められます。

たとえば:

./manageDIPServerConfig set -h hostname -p 19523 -D weblogic
            -attribute oidhostport -value hostname.domain.com:24163

親トピック: 別のホストへのアイデンティティ管理コンポーネントのリカバリ

別のホストへの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でのパートナとして再び登録する必要があります。
1. Oracle Access Managerコンソールにログインします。
2. 起動パッドから、Application Managementで、「SSOエージェント」をクリックします。
3. すべての構成済SSOエージェントの場合、新しいホストの名前ですべてのホスト名を更新します。
  - 設定されている場合、「サーバー・リスト」は新しいホスト名を参照します。
  - 設定されている場合、ユーザー定義パラメータは新しいホスト名を参照します。
  - 設定されている場合、ログアウトのリダイレクトURLは新しいホスト名を参照します。
または、『Oracle Access Management管理者ガイド』のエージェントおよびアプリケーションの登録の説明に従って、oamregツールを使用できます。同じマニュアルでリモート登録ツールの取得および設定に関する項も参照してください。
「特定のコンポーネントの新しいマシンの作成」の説明に従って、新しいホスト名で新しいマシンを作成します。
WebGate構成ファイルのObAccessClient.xmlを編集して、Access Managerサーバーのホスト名を更新します。このファイルは次のディレクトリにあります。
```
DOMAIN_HOME/output/agentName/
```
「特定のアイデンティティ管理コンポーネントの、ユーザーのグループへの再関連付け」の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。

親トピック: 別のホストへのアイデンティティ管理コンポーネントのリカバリ

ホスト破損後のOracle Access Management Security Token Serviceのリカバリ

ホスト破損後にSecurity Token Serviceをリカバリするには:

Middlewareホームをリカバリします。
```
tar -xf mw_home_backup_11052013.tar
```
ドメイン・ディレクトリがMiddlewareホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。
```
cd DOMAIN_HOME
tar -xf domain_backup_11052013.tar 
```

管理サーバーを起動します。たとえば:

DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
    -Dweblogic.management.password=password
    -Dweblogic.system.StoreBootIdentity=true

ホストの管理用URLを指定して、管理対象サーバーを起動します。
```
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
```

ノード・マネージャを起動します。

java weblogic.WLST
wls:/offline> startNodeManager()

親トピック: 別のホストへのアイデンティティ管理コンポーネントのリカバリ

別のホストへのOracle Access Management Mobile and Socialのリカバリ

別のホストにMobile and Socialをリカバリするには:

「Oracleホームのリカバリ」および「Oracle WebLogic Serverドメインのリカバリ」の説明に従って、Oracleホームおよびドメイン・ホームをリストアします。
次のサーバー・プロバイダ用にAccess Managerホストのホスト名を更新します。
- OAMAuthorization
- OAMAuthentication
次のWLSTコマンドを使用すると、ホスト名を変更できます。
```
updateServiceProvider('oracle.security.idaas.rest.provider.authorization.OAMS
     DKAuthZServiceProvider', 'Authorization', '[]','
     [{OAM_VERSION: OAM_11G},{WEBGATE_ID: accessgate-oic},
     {ENCRYPTED_PASSWORD: aaaa},{DEBUG_VALUE: 0},{TRANSPORT_SECURITY: OPEN},
     {OAM_SERVER_1: "new_server1:5575"},{OAM_SERVER_1_MAX_CONN: 4},
     {OAM_SERVER_2: "new_server2:5575"},{OAM_SERVER_2_MAX_CONN: 4}]',
     'OAMAuthorization', 'Out Of The Box Oracle Access Manager (OAM)
        Authorization Service Provider')
 
```
updateServiceProviderコマンドの詳細は、『WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンス』のupdateServiceProviderに関する項を参照してください。

または、Access Managerコンソールを使用できます。詳細は、『Oracle Access Management管理者ガイド』のOracle Access Management Mobile and Socialの管理を参照してください。

親トピック: 別のホストへのアイデンティティ管理コンポーネントのリカバリ

別のホストへの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を使用して、ホスト名を変更します。
1. ナビゲーション・ペインで、ファームを開いてから、「Identity and Access」を開きます。
2. Identity Federationインスタンスを選択します。
3. 「Identity Federation」メニューで、「管理」→「サーバー・プロパティ」を選択します。
  
  「サーバー・プロパティ」ページが表示されます。
4. 「ホスト」で、以前のホスト名を新しいホスト名に置き換えます。
5. ポート番号が変更されている場合は、「ポート」のポート番号を置き換えます。
6. SOAPポート番号が変更されている場合は、「SOAPポート」のポート番号を置き換えます。
7. 「適用」をクリックします。
8. Identity Federationのデプロイ先の管理対象サーバーを再起動します。
```
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
          admin_url 
```
Identity FederationがSSLサーバーとして機能している場合は、Identity Federationからクライアントに示されているSSL証明書を、新しいホスト名を持つ新しい証明書に置き換える必要があります。そうしないと、クライアントによるホスト名の検証が失敗する場合があります。

親トピック: 別のホストへのアイデンティティ管理コンポーネントのリカバリ

ホストの破損後にエンティティをリカバリするための追加の操作

リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち1つ以上を実行することが必要な場合があります。そのような場合は、エンティティをリカバリする方法を説明している項に明記されています。

次の各項目で、実行することが必要な可能性のある操作について説明します。

親トピック: ホスト破損後のリカバリ

別のホストへのFusion Middleware Controlのリカバリ

Fusion Middleware Controlを別のホストにリカバリするには、システムMBeanブラウザを使用してプロパティを更新します。

Fusion Middleware Controlの「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ペインで「アプリケーション定義のMBean」、「emoms.props」、「サーバー: AdminServer」、「アプリケーション: em」、そして「プロパティ」と展開します。
「emoms.properties」をクリックします。
「属性」ペインで「操作」タブを選択し、「SetProperty」をクリックします。
次のプロパティの値を新しいホスト名に変更します。
- oracle.sysman.emSDK.svlt.ConsoleServerHost
- oracle.sysman.emSDK.svlt.ConsoleServerName
たとえば、「キー」に「oracle.sysman.emSDK.svlt.ConsoleServerHost」と入力します。次に、値として「host.example.com:7001_Management_Service」と入力します。
「呼出し」をクリックします。

親トピック: ホストの破損後にエンティティをリカバリするための追加の操作

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>

親トピック: ホストの破損後にエンティティをリカバリするための追加の操作

特定のコンポーネントの新しいマシンの作成

管理サーバーにリスニング・アドレスがある場合は、管理サーバーを起動する前に新しいホスト名の新規マシンを作成する必要があります。

次のステップを実行します。

新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。

readDomain('DOMAIN_HOME')
machine = create('newhostname', 'Machine')
cd('/Machine/newhostname')
nm = create('newhostname', 'NodeManager')
cd('/Machine/newhostname/NodeManager/newhostname')
set('ListenAddress', 'newhostname')
updateDomain()

管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。
```
readDomain('DOMAIN_HOME')
cd ('/Machine/newhostname')
machine = cmo
cd ('/Server/AdminServer')
set('Machine', machine)
updateDomain()
```

WLSTを使用して、管理サーバーのリスニング・ポートを設定します。

readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.setListenPort(8001)
updateDomain()

必要に応じて、WLSTを使用して管理サーバーのアドレス・リスニングを更新します。

readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.getListenAddress()
cmo.setListenAddress('newhostname')
updateDomain()
exit()

親トピック: ホストの破損後にエンティティをリカバリするための追加の操作

特定のアイデンティティ管理コンポーネントの、ユーザーのグループへの再関連付け

次のアイデンティティ管理コンポーネントのバックアップをリストアすると、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

レジストリ・エディタのヘルプに説明されているように、キーのインポートにはレジストリ・エディタを使用することもできます。

親トピック: ホストの破損後にエンティティをリカバリするための追加の操作

データベース・ホストの破損後のリカバリ

データベースのリカバリの詳細は、「データベースのリカバリ」を参照してください。

親トピック: ホスト破損後のリカバリ