| Oracle® Fusion Middleware管理者ガイド 11gリリース1 (11.1.1.8.0) B60984-07 |
|
 前 |
 次 |
この章では、Oracle Fusion Middlewareを様々なタイプの障害および停止(メディア障害またはホストの破損など)からリカバリするための推奨されるリカバリ戦略および手順について説明します。
この章の項目は次のとおりです。
この項では、ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害またはメディア障害などが関係する停止に対するリカバリ戦略の概要を示します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。
|
注意: この章に記載されている手順では、最後のバックアップ以降、管理上の変更は加えられていないことを前提としています。最後のバックアップ以降、管理上の変更が加えられている場合は、リカバリの完了後にそれらの変更を再適用する必要があります。 |
ファイルのリストア時に圧縮ファイルを解凍するには、第16.4項の説明に従って、それに適したツールを使用します。
使用しているツールが、ファイルの権限とタイムスタンプを保持することを確認してください。
必要なファイルを間違ってオーバーライドしないよう、バックアップからファイルをリストアする前に既存のファイルおよびディレクトリの名前を変更してください。
この項では、ディスクをリストアできないような、実データの損失や破損、またはメディア障害などが関係する停止に対するリカバリ戦略について説明します。適切に機能しなくなったアプリケーションに対するリカバリ戦略についても説明します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。次の項目が含まれます。
|
注意: エンティティは、元のエンティティと同じパスにのみリストアできます。そのパスは、同じホスト上であっても、異なるホスト上であってもかまいません。 |
破損したりファイルが削除されたMiddlewareホームをリカバリできます。
Middlewareホームをリカバリする手順は次のとおりです。
関連するすべてのプロセスを停止します。つまり、管理サーバー、ノード・マネージャ、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle Fusion Middlewareプロセスの停止の詳細は、第4.1項を参照してください。
バックアップからMiddlewareホーム・ディレクトリをリカバリします。次に例を示します。
cd MW_HOME
(UNIX) tar -xf mw_home_backup_042012.tar
(Windows) jar xtf mw_home_backup_042012.jar
関連するすべてのプロセスを起動します。つまり、Middlewareホームで実行するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
Oracle Fusion Middlewareプロセスの起動の詳細は、第4.1項を参照してください。
ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリすることができます。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリする手順は次のとおりです。
関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle Fusion Middlewareプロセスの停止の詳細は、第4.1項を参照してください。
バックアップからドメイン・ディレクトリをリカバリします。
cd DOMAIN_HOME
(UNIX) tar -xf domain_backup_042012.tar
(Windows) jar xtf domain_backup_042012.jar
関連するすべてのプロセスを起動します。つまり、このドメインに関連するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
Oracle Fusion Middlewareプロセスの起動の詳細は、第4.1項を参照してください。
管理サーバーを起動できない場合は、第18.2.5項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、第18.2.6項の説明に従って、管理対象サーバーをリカバリします。
特定のコンポーネントのOracleホームをリカバリする手順は次のとおりです。
バックアップ・ファイルからOracleホームを元のディレクトリにリカバリします。次に例を示します。
cd ORACLE_HOME
tar -xf Oracle_home_backup_042012.tar
WLSTのstartコマンドを使用して、アプリケーションのデプロイ先の管理対象サーバーを再起動します。次に例を示します。
connect('username', 'password', 'localhost:7001')
cd('servers/server_name')
start('server_name','Server')
Oracleインスタンス・ホームには、Oracle HTTP ServerやOracle Internet Directoryなどのシステム・コンポーネントに関する構成情報が含まれています(システム・コンポーネントの一覧は、第3.5.2項を参照)。次の各項目で、Oracleインスタンス・ホームをリカバリする方法について説明します。
ファイル・システムから削除されたり破損したOracleインスタンス・ホームをリカバリする手順は次のとおりです。
関連するすべてのプロセスを停止します。つまり、Oracleインスタンスに関連するすべてのプロセスを強制終了します。
バックアップ・ファイルからOracleインスタンス・ホーム・ディレクトリをリカバリします。次に例を示します。
cd ORACLE_INSTANCE
(UNIX) tar -xf Instance_home_backup_042012.tar
(Windows) jar xtf Instance_home_backup_042012.jar
関連するすべてのプロセスを起動します。つまり、Oracleインスタンスに関連するすべてのプロセスを起動します。
opmnctl startall
ドメインから登録解除されたOracleインスタンス・ホームをリカバリする手順は次のとおりです。
バックアップ・ファイルからOracleインスタンス・ホーム・ディレクトリをリカバリします。たとえばLinuxでは、次のように指定します。
cd ORACLE_INSTANCE
tar -xf Instance_home_backup_042012.tar
opmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。次に例を示します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir -instanceName Instance_name -wlserverHome Middleware_Home
ファイルの削除またはファイル・システムの破損が原因で、管理サーバーの構成が失われた場合でも、問題の発生時に管理サーバーのコンソールがすでに起動しているときには、このコンソールは引き続き機能します。管理サーバー・ディレクトリは、セキュリティ情報を除き、自動的に再生成されます。その結果、管理サーバーを起動するたびに、ユーザー名とパスワードの入力を求めるプロンプトが表示されます。これを避けるには、構成をリカバリします。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
管理サーバーの構成をリカバリする手順は次のとおりです。
管理サーバー、管理対象サーバーおよびノード・マネージャが起動している場合はこれらも含めて、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle Fusion Middlewareプロセスの停止の詳細は、第4.1項を参照してください。
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーが正常に起動しており、アクセス可能であることを確認します。
構成が次回変更されるときに、管理サーバーの構成が、管理対象サーバーにプッシュされます。管理対象サーバーが再起動するたびに、管理サーバーから構成が取得されます。
管理対象サーバーのファイルが削除されたり破損した場合、その構成ファイルを含めて、それらのファイルをリカバリできます。
次の各項目で、管理対象サーバーのファイルをリカバリする方法について説明します。
ディレクトリが異なるOracle SOA Suite管理対象サーバーのリカバリ
この項は、Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合に関連します。
このシナリオでは、管理対象サーバーの構成が削除されたり破損したために、あるいは構成が誤って変更され変更内容を確認できないために、管理対象サーバーが適切に動作しなかったり起動できない場合を考えます。
管理対象サーバーを起動できない場合のリカバリの手順は次のとおりです。
管理サーバーにアクセスできない場合は、第18.2.5項の説明に従って、管理サーバーをリカバリします。
管理サーバーが起動しない場合、必要に応じて、Middlewareホームをバックアップからリカバリします。次に例を示します。
tar -xf mw_home_backup_042012.tar
ファイル・システムが損失した場合、次の手順を実行します。
packユーティリティを使用して、管理サーバーのドメイン・テンプレート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オプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
unpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。
unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info
|
注意: unpackコマンドの-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。環境で必要な場合は、-overwrite_domainオプションを使用してください。 |
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
ステージング、ステージングなし、または外部ステージング・モードの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
第4.2.3項の説明に従って、管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
このシナリオでは、管理対象サーバーが実行されていて、管理対象サーバーのファイル・システムが損失または破損している場合を考えます。
管理対象サーバーをリカバリする手順は次のとおりです。
管理対象サーバーを停止します。次に例を示します。
DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url username password
必要に応じて、Middlewareホームをバックアップからリカバリします。
tar -xf mw_home_backup_042012.tar
packユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。次に例を示します。
pack.sh -domain=/scratch/oracle/config/domains/WLS_SOAWC -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
unpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。
unpack.sh -template=/scratch/temp.jar -domain=/scratch/oracle/config/domains/WLS_SOAWC -log=/scratch/logs/new.log -log_priority=info
|
注意: unpackコマンドの-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。環境で必要な場合は、-overwrite_domainオプションを使用してください。 |
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
第4.2.3項の説明に従って、管理対象サーバーを再起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、管理対象サーバー・ディレクトリをリストアする必要があります。たとえば、ドメインに2つの管理対象サーバーがあり(その1つにOracle SOA Suiteが含まれています)、いずれの管理対象サーバーのディレクトリも管理サーバーと同じディレクトリ構造内には存在しないとします。
この場合、管理対象サーバーをバックアップからリストアする必要があります。
バックアップから管理対象サーバーをリストアします。
cd ManagedServer_Home
tar -xf managed_server_backup_042012.tar
第4.2.3項の説明に従って、管理対象サーバーを再起動します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
次の各項目で、ほとんどのコンポーネントについてリカバリする方法を説明します。
一部のコンポーネントについては、別の手順に従う必要があります。表18-1に、そのようなコンポーネントと、そのリカバリ手順を説明している項を示します。
表18-1 特定のコンポーネントのリカバリ手順
| コンポーネント | 手順 |
|---|---|
|
Oracle Access Manager |
|
|
Oracle Adaptive Access Manager |
|
|
Oracle BI Enterprise Edition |
|
|
Oracle Business Intelligence Publisher |
|
|
Oracle Business Process Management |
|
|
Oracle Essbase |
|
|
Oracle Data Integrator |
|
|
Oracle Hyperion Calculation Manager |
|
|
Oracle Hyperion Financial Reporting |
|
|
Oracle Hyperion Smart View |
|
|
Oracle Identity Manager |
|
|
Oracle Identity Navigator |
|
|
Oracle WebCenter Content: Imaging |
|
|
Oracle Information Rights Management |
|
|
Oracle Real-Time Decisions |
|
|
Oracle WebCenter Content |
|
|
Oracle WebCenter Content: Records |
|
|
Oracle WebCenter Portalのアクティビティ・グラフ |
|
|
Oracle WebCenter Portal分析 |
|
コンポーネントのファイルが削除されたり破損した場合、またはコンポーネントの構成が変更されコミットされたためにコンポーネントが起動できないまたは適切に機能しない場合、コンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
Oracle SOA SuiteなどのJavaコンポーネントの場合は、第18.2.6項の説明に従って、管理対象サーバーをリカバリします。
システム・コンポーネントの場合(Oracle HTTP ServerやWeb Cacheなど):
コンポーネントを停止します。たとえば、Oracle HTTP Serverを停止するには、次のコマンドを使用します。
opmnctl stopproc ias-component=component_name
コンポーネントの停止方法の詳細は、第4.3項を参照してください。
バックアップからコンポーネント固有のファイルをリカバリします。第16.5項に、各コンポーネントに必要なディレクトリとファイルを示します。たとえば、Oracle HTTP Serverのファイルをリカバリするには、次のディレクトリをリカバリします。
ORACLE_INSTANCE/config/OHS/component_name ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
コンポーネントを起動します。たとえば、Oracle HTTP Serverを起動するには、次のコマンドを使用します。
opmnctl startproc ias-component=component_name
コンポーネントの起動方法の詳細は、第4.3項を参照してください。
クラスタ・レベルで構成が変更されコミットされたために、クラスタ内のコンポーネントが適切に機能しないまたは起動できない場合、それらのコンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
コンポーネントをリカバリする手順は次のとおりです。
クラスタを停止します。
stop('cluster_name', 'Cluster')
管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle Fusion Middlewareプロセスの停止の詳細は、第4.1項を参照してください。
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTのstartコマンドを次のように使用します。
start('clusterName', 'Cluster')
最新の構成が管理サーバーからクラスタのすべてのメンバーに取得されます。
Oracle Identity Managerをリカバリする手順は次のとおりです。
第18.2.2項の説明に従って、ドメインをリストアします。
第18.2.3項の説明に従って、Oracleホームをリストアします。
OIM、MDS、SOAINFRAおよびOIDスキーマが含まれるデータベースを同じ時点にリストアします。第18.2.10項を参照してください。
Oracle Identity Managerでは、ユーザーおよびロールをLDAPストアに格納します。データベースをLDAPストアと異なる時点にリストアする場合、リコンシリエーション・エンジンでは変更ログをチェックして、LDAPストアとデータベースのリストアの間に発生したすべての変更を再度適用します。たとえば、データベースをLDAPストアの10時間後の時点にリストアする場合、リコンシリエーション・エンジンは変更ログをチェックしてLDAPストアで直前の10時間以内に発生したすべての変更をデータベースに再度適用します。
リコンシリエーションを明示的にトリガーする必要はありません。LDAP同期は定期的なスケジュール済タスクとして設定され、定期的にリコンシリエーション・イベントを発行します。また、リコンシリエーション・プロセスを手動で起動して、Oracle Identity Managerコンソールからリコンシリエーション・イベントを監視することもできます。『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のリコンシリエーションの構成に関する項を参照してください。
|
注意: 前述のリカバリ・シナリオでバルク・リコンシリエーションが発生する場合、エンド・ユーザーによるOracle Identity Managerアプリケーションの使用を停止することをお薦めします。バルク・リコンシリエーションが完了したら、エンド・ユーザーによるOracle Identity Managerアプリケーションの使用を再開してください。リコンシリエーションは、Oracle Identity Managerコンソールで監視できます。 |
Oracle Access Managerをリカバリする手順は次のとおりです。
第18.2.1項の説明に従って、Middlewareホーム、およびOracle Access Manager管理対象サーバーのドメイン・ホームをリストアします。
第18.2.2項の説明に従って、ドメインをリストアします。
必要に応じて、第18.2.3項の説明に従って、Webゲートが含まれるOracle HTTP ServerのOracleホームをリストアします。
必要に応じて、第18.2.4項の説明に従って、Webゲートが含まれるOracle HTTP ServerのOracleインスタンスをリストアします。
必要に応じて、Oracle Access Managerポリシー・ストア用にOESで使用されるスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。
Oracle Business Process Managementをリカバリする手順は次のとおりです。
Oracle WebCenter Portalのアクティビティ・グラフをリカバリする手順は次のとおりです。
次の各項目で、Oracle Business Intelligence Enterprise Edition (Oracle BI EE)をリカバリする方法について説明します。
|
注意: Oracle BI EEをリカバリする場合、Oracle BI Presentation CatalogとOracle BI EEリポジトリ(RPD)は、同じバックアップ・セットを使用して、同じ時点にリストアされるようにする必要があります。 |
このシナリオでは、Oracle BI Enterprise Editionが非クラスタ環境で実行されていると想定します。
障害の程度に応じて、次のものをリストアします。
第18.2.5項の説明に従って、管理サーバーをリカバリします。
第18.2.6項の説明に従って、管理対象サーバーをリカバリします。
必要に応じて、Oracle BI EEのスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。
第18.2.7.10.3項の説明に従って、LDAPデータベースとOracle BI EEリポジトリ(RPD)を、第18.2.7.10.4項の説明に従って、LDAPデータベースとOracle BI Presentation Catalogを調整します。
このシナリオでは、Oracle BI Enterprise Editionがクラスタ環境で実行されていると想定します。
クラスタ環境でOracle BI EEをリカバリする手順は次のとおりです。
障害の程度に応じて、次のものをリストアします。
第18.2.5項の説明に従って、管理サーバーをリカバリします。
第18.2.6項の説明に従って、すべての管理対象サーバーをリカバリします。
必要に応じて、第18.2.10項の説明に従って、Oracle BI EEスキーマが含まれるデータベースをリストアします。
第18.2.7.10.3項の説明に従って、LDAPデータベースとOracle BI EEリポジトリ(RPD)を、第18.2.7.10.4項の説明に従って、LDAPデータベースとOracle BI Presentation Catalogを調整します。
LDAPデータベースは、Oracle BI EEリポジトリ(RPD)と調整する必要があります。
Oracle BI Enterprise Editionを使用して、同期を実行できます。常に自動同期を有効にすることも一時的に同期を実行することもできます。(NQSConfig.iniファイルの編集の詳細は、『Oracle Fusion Middleware 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 Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ・ビルダーズ・ガイドのリポジトリ・オブジェクトの一貫性のチェックに関する項を参照してください。
LDAPデータベースがOracle BI Presentation Catalogの背後にあるよりも以前の時点にLDAPデータベースをリストアする場合は、次のコマンドを使用してLDAPデータベースとOracle BI Presentation Catalogを調整します。
runcat.cmd -cmd forgetAccounts
runcatコマンドの詳細は、次のようにヘルプを参照してください。
./runcat.sh -cmd maintenanceMode -help
Oracle Business Intelligence Publisherをリカバリする手順は次のとおりです。
第18.2.6項の説明に従って、Oracle Business Intelligence Publisherコンポーネントが含まれる管理対象サーバーをリカバリします。
必要に応じて、第18.2.10項の説明に従って、Oracle Business Intelligence Publisherスキーマが含まれるデータベースをリストアします。
バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。
Oracle Real-Time Decisionsをリカバリする手順は次のとおりです。
第18.2.6項の説明に従って、Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。
バックアップ・アーティファクトが別の時点からリストアされると、分析モデルで学習期間が失われますが、インテリジェント機能には影響しません。
Oracle Hyperion Calculation Managerをリカバリする手順は次のとおりです。
第18.2.6項の説明に従って、Oracle Hyperion Calculation Managerがデプロイされている管理対象サーバーをリカバリします。
必要に応じて、データベースを直近の時点にリカバリするか、Oracle Hyperion Calculation Managerインポート・ツールを使用してアーティファクトをインポートします。
Oracle Hyperion Financial Reportingをリカバリする手順は次のとおりです。
Oracle Hyperion Smart Viewをリカバリする手順は次のとおりです。
第16.5.9.4項の説明に従って、バックアップしたOracle Hyperion Smart Viewのデータ・ファイルを元の場所にリストアします。
Oracle Information Rights Managementをリカバリする手順は次のとおりです。
Oracle WebCenter Content: Imagingでは、データが次の場所に格納されています。
Imagingの構成データのデータベース
ドキュメント・リポジトリとして機能するデータベース
JMS永続キュー
Imagingをリカバリする場合、すべてのデータが同じ時点からリストアされるようにする必要があります。
Imagingをリカバリする手順は次のとおりです。
Oracle WebCenter Contentをリカバリする手順は次のとおりです。
必要に応じて、第18.3.6項の説明に従って、データベースをリストアします。
第18.2.2項の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
cd /net/home/vault tar -xf vault_backup_042012.tar
データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。
Oracle WebCenter Content: Recordsは、Oracle WebCenter Contentに依存しており、追加でバックアップまたはリカバリするアーティファクトがないため、Oracle WebCenter Contentのリカバリ手順(第18.2.7.20項)を参照してください。
次の各項目で、クラスタをリカバリする方法について説明します。
このシナリオでは、クラスタが間違って削除されたり、JMS構成またはコンテナレベルのデータ・ソースなどのクラスタレベルの構成が誤って変更されコミットされた場合を考えます。サーバーが起動できないか適切に動作しない、あるいはサーバー内部で実行されるサービスが開始されていません。変更内容は確認できません。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
構成の変更が少ない場合、最も簡単な方法は、構成の変更を再実行することです。この方法を実行できない場合は、次の手順に従って構成をリカバリします。
クラスタを停止します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
stop('clusterName', 'Cluster')
管理サーバーを停止します。次に例を示します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
start('clusterName', 'Cluster')
クラスタのメンバーシップを誤って変更した場合に、クラスタをリカバリできます。たとえば、クラスタからメンバーを誤って削除した場合、メンバーをクラスタにリストアできます。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
クラスタのメンバーシップをリカバリする手順は次のとおりです。
管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle Fusion Middlewareプロセスの停止の詳細は、第4.1項を参照してください。
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
削除されたメンバーがクラスタに戻ります。
管理対象サーバーなど、すべてのプロセスを起動します。たとえば、Linux上で管理対象サーバーを起動するには、次のスクリプトを使用します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
start('clusterName', 'Cluster')
これで、削除されたメンバーがクラスタの一部となります。
クラスタのすべてのメンバーを起動します(起動していない場合)。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
次の各項目で、アプリケーションをリカバリする方法について説明します。
アプリケーションのリカバリについては、次の点に注意してください。
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
デプロイメント・モードがステージングなしまたは外部ステージングの場合、追加のアプリケーション・アーティファクトが使用可能であることを確認してください。たとえば、アプリケーションがドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
|
関連項目: アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
.earファイルなどのアプリケーションのアーティファクトが損失または破損した場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリする手順は次のとおりです。
アプリケーションのデプロイ先の管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
このコマンドを実行すると、構成が管理サーバーと同期されます。
管理対象サーバーが再起動するたびに、構成およびアプリケーション・アーティファクトが管理サーバーから取得されます。
Java EEアプリケーションが管理対象サーバーに再デプロイされ(管理対象サーバーがクラスタの一部であるかどうかは関係ない)、アプリケーションが機能しなくなった場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリする手順は次のとおりです。
必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
バックアップから古いバージョンのアプリケーションを再デプロイします。
元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。
デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリする手順は次のとおりです。
必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
バックアップから古いバージョンのアプリケーションを再デプロイします。アプリケーションがクラスタにデプロイされた場合、同じクラスタにアプリケーションを再デプロイします。
元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。
コンポジット・アプリケーション(SOAアプリケーション)の新規バージョンが管理対象サーバーまたはクラスタに再デプロイされました。このアプリケーションが機能しなくなったとします。
アプリケーションをリカバリする手順は次のとおりです。
必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
アプリケーションの古いバージョンを再デプロイします。アプリケーションがクラスタにデプロイされた場合、同じクラスタにアプリケーションを再デプロイします。
MDSリポジトリなどのメタデータ・リポジトリが含まれるデータベースが破損している場合、RMANを使用してそのデータベースをリカバリできます。データベースは、完全リカバリまたは表領域リカバリのいずれかの必要な粒度でリカバリできます。
最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これにより、確実に最新のデータがリカバリされます。次に例を示します。
rman> restore database; rman> recover database;
各コンポーネントで使用するスキーマについては、付録Dを参照してください。
詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項では、Oracle Fusion Middlewareの元の動作環境が損なわれた後、その環境をリカバリする方法について説明します。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。この項の項目は次のとおりです。
|
注意: ホストの破損からリカバリする場合、元のホストで使用していたものと同じパスを使用してファイルをリストアする必要があります。 |
Oracle WebLogic Serverドメインをリカバリする手順は次のとおりです。
関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle Fusion Middlewareプロセスの停止の詳細は、第4.1項を参照してください。
バックアップからドメイン・ディレクトリをリカバリします。
cd DOMAIN_HOME
(UNIX) tar -xf domain_backup_042012.tar
(Windows) jar xtf domain_backup_042012.jar
関連するすべてのプロセスを起動します。つまり、このドメインに関連するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーを起動できない場合は、第18.3.2項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、第18.3.3項の説明に従って、管理対象サーバーをリカバリします。
管理サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
このシナリオでは、管理サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。たとえば、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されているとします。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをリカバリする必要があります。
同じホストに管理サーバーをリカバリする手順は次のとおりです。
ファイル・システムをリカバリします。たとえば、第18.3.1項の説明に従って、この管理サーバーが含まれるドメインをリカバリします。
管理サーバーを起動してみます。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーが起動する場合は、これ以上の手順は必要ありません。
管理サーバーが起動しない場合は、ホストAで次の手順を実行します。
関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle Fusion Middlewareプロセスの停止の詳細は、第4.1項を参照してください。
必要に応じて、Middlewareホームをリカバリします。
tar -xf mw_home_backup_042012.tar
ドメイン・ディレクトリがMiddlewareホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。
cd DOMAIN_HOME
tar -xf domain_backup_042012.tar
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
ホストの管理用URLを指定して、管理対象サーバーを起動します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
ノード・マネージャを起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをホストCに移行する必要があります。
別のホストに管理サーバーをリカバリする手順は次のとおりです。
MiddlewareホームをホストC(新しいホスト)にリカバリします。
cd MW_HOME
tar -xf mw_home_backup_042012.tar
ドメイン・ディレクトリがMiddlewareホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。
cd DOMAIN_HOME
tar -xf domain_backup_042012.tar
管理サーバーにリスニング・アドレスが指定されている場合は、第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。
元のホストでノード・マネージャが構成されていた場合は、ホストCでノード・マネージャを起動します。
cd WL_HOME/server/bin
./startNodeManager
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
管理対象サーバーを起動します。『Oracle Fusion Middleware Oracle WebLogic Serverでの管理サーバーの起動と停止』の障害が発生した管理サーバーの再起動に関する項には、構成方法に応じて様々な再起動の方法が説明されています。
オプションの1つとして、次のスクリプトの使用があります。このコマンドでは、新しいホストの管理用URLを指定します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
追加のアプリケーション・アーティファクトが使用可能であることを確認します。たとえば、デプロイメント・モードがステージングなしまたは外部ステージングの場合、アプリケーションはドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
第18.3.5.7項の説明に従って、Oracle Inventoryを更新します。
環境にOracle HTTP Serverが含まれる場合、第18.3.5.4項の説明に従って、mod_wl_ohs.confファイルを修正します。
第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
Oracle Management Service (Fusion Middleware Controlに含まれる)は、元のホスト上に配置されており、管理サーバーのリストア時に新しいホストにリカバリされます。Oracle Management Agentは、Oracle Management Serviceに接続して、特定のコンポーネントを監視します。使用している環境に、Oracle Internet DirectoryやOracle Virtual Directoryなど、Oracle Management Agentを使用するコンポーネントが含まれるが、それらが別のホストに配置されている場合、これらのコンポーネントが含まれる各ホストで次の手順を実行する必要があります。たとえば、ホストAにあった管理サーバーを、Oracle Management ServiceとともにホストBにリストアするとします。Oracle Internet DirectoryはホストCに、Oracle Virtual DirectoryはホストDに配置されているとします。この場合、ホストCとホストDの両方で、次の手順を実行する必要があります。
次のファイルを編集します。
(UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties (Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties
ホスト名を管理サーバーの新しいホストに置き換えて、次のエントリを更新します。
emdWalletSrcUrl=http://newhost.domain.com:port/em/wallets/emd REPOSITORY_URL=http://newhost.domain.com:port/em/upload/ EMD_URL=http://newhost.domain.com:port/emd/main/
EMエージェント・プロセスを停止して、再起動します。
cd ORACLE_INSTANCE/EMAGENT/emagent_dir ./emctl stop agent ./emctl start agent ./emctl status agent
ステータス・コマンドに、新しいホストを指すREPOSITORY_URLが示されます。
これで、ホストCで実行されている管理コンソールを使用して、ホストBの管理対象サーバーを起動および停止できます。
Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、第18.3.5項を参照してください。
管理対象サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
ディレクトリが異なるOracle SOA Suite管理対象サーバーのリカバリ
この項は、Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合に関連します。
このシナリオでは、管理対象サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストBにリカバリする必要があります。
同じホストに管理対象サーバーをリカバリする手順は次のとおりです。
ホストBでノード・マネージャを起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが起動した場合、管理対象サーバーは管理サーバーに接続し、構成の変更を更新します。これ以上の手順は必要ありません。
管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次の手順を実行します。
WLSTを使用して、ノード・マネージャを停止します。
java weblogic.WLST wls:/offline> stopNodeManager()
必要に応じて、MiddlewareホームをバックアップからホストBにリカバリします。
tar -xf mw_home_backup_042012.tar
管理対象サーバーにOracle Portal、Oracle Reports、Oracle Forms ServicesまたはOracle Business Intelligence Discovererが含まれており、管理対象サーバーのドメイン・ディレクトリがMiddlewareホームの外部に存在する場合、Middlewareホームに加えてドメインをリストアします。次に例を示します。
cd Domain_Home
tar -xf domain_home_backup_042012.tar
ステップeに進みます。
ステップcに示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。
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 Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
ノード・マネージャが起動していない場合は、起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストCにリカバリする必要があります。
|
重要: 元と同じ場所にMiddlewareホームをリカバリします。 |
別のホストに管理対象サーバーをリカバリする手順は次のとおりです。
管理対象サーバーのMiddlewareホームをホストCにリカバリします。
tar -xf mw_home_backup_042012.tar
管理対象サーバーにOracle Portal、Oracle Reports、Oracle Forms ServicesまたはOracle Business Intelligence Discovererが含まれており、管理対象サーバーのドメイン・ディレクトリがMiddlewareホームの外部に存在する場合、Middlewareホームに加えてドメインをリストアします。次に例を示します。
cd Domain_Home
tar -xf domain_home_backup_042012.tar
ステップ4に進みます。
ステップ2に示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。
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 Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
ホストCでノード・マネージャが起動していない場合は、起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
WLSTを使用して管理サーバーに接続し、新しいホストで実行されているノード・マネージャを管理サーバーに登録します。
connect('username','password','t3://host:port')
nmEnroll('/scratch/oracle/config/domains/domain_name',
'MW_HOME/wlserver_n/common/nodemanager')
管理対象サーバーの構成を、新しいホストを指すように変更します。
WebLogic Server管理コンソールで、1つ以上のWebLogic Serverをホストするコンピュータの論理的な表現であるマシンを作成し、新しいホストを指すように指定します(「ホーム」ページで、「マシン」を選択します。続いて、「新規」をクリックします)。管理コンソール・ヘルプの指示に従います。
リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のホスト名検証の使用方法に関する項を参照してください。
管理対象サーバーの構成を、新しいマシンを指すように変更します(コンソールの左ペインから、「環境」→「サーバー」を展開します。続いて、サーバーの名前を選択します。「構成」タブ、続いて「一般」タブを選択します。「マシン」フィールドで、サーバーの割当て先のマシンを選択します。)
「リスニング・アドレス」を新しいホストに変更します。リスニング・アドレスが空白に設定されている場合は、それを変更する必要はありません。
管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
第18.3.5.7項の説明に従って、Oracle Inventoryを更新します。
環境にOracle HTTP Serverが含まれる場合、第18.3.5.4項の説明に従って、mod_wl_ohs.confファイルを修正します。
第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
これで、ホストAで実行されている管理サーバーを使用して、ホストCの管理対象サーバーを起動および停止できます。
Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、管理対象サーバー・ディレクトリをリストアする必要があります。たとえば、ドメインに2つの管理対象サーバーがあり(その1つにOracle SOA Suiteが含まれています)、いずれの管理対象サーバーのディレクトリも管理サーバーと同じディレクトリ構造内には存在しないとします。
同じホストまたは別のホストにリカバリするには、第18.2.6.3項で説明している手順を使用します。
コンポーネント(およびその管理対象サーバー(該当する場合))を含むホストが破損した場合、次の各項目で説明する手順を使用して、ほとんどのコンポーネントを同じホストまたは別のホストにリカバリできます。
コンポーネントによっては追加操作が必要なものがあります。それらは、表18-2で示した項で説明しています。
表18-2 特定コンポーネントのホスト破損の際のリカバリ手順
| コンポーネント | 手順 |
|---|---|
|
Oracle Access Manager |
|
|
Oracle Adaptive Access Manager |
|
|
Oracle BI Discoverer |
|
|
Oracle BI Enterprise Edition |
|
|
Oracle BI Publisher |
|
|
Oracle Business Process Management |
ホストの破損については、追加手順は必要ありません。第18.2.7.7項の手順に従ってください。 |
|
Oracle Data Integrator |
|
|
Oracle Directory Integration Platform |
|
|
Oracle Essbase |
|
|
Oracle Forms Services |
|
|
Oracle Hyperion Calculation Manager |
|
|
Oracle Hyperion Financial Reporting |
|
|
Oracle Hyperion Smart View |
ホストの破損については、追加手順は必要ありません。第18.2.7.16項の手順に従ってください。 |
|
Oracle HTTP Server |
|
|
Oracle Identity Federation |
|
|
Oracle Identity Manager |
|
|
Oracle Identity Navigator |
|
|
Oracle WebCenter Content: Imaging |
ホストの破損については、追加手順は必要ありません。第18.2.7.19項の手順に従ってください。 |
|
Oracle Information Rights Management |
ホストの破損については、追加手順は必要ありません。第18.2.7.18項の手順に従ってください。 |
|
Oracle Internet Directory |
|
|
Oracle Portal |
|
|
Oracle Real-Time Decisions |
|
|
Oracle Reports |
|
|
Oracle SOA Suite |
同じホストにリカバリする場合は、追加手順は必要ありません。第18.3.4.6項の手順に従ってください。 |
|
Oracle WebCenter Content |
|
|
Oracle WebCenter Content: Records |
|
|
Oracle Virtual Directory |
|
|
Oracle Web Cache |
|
|
Oracle WebCenter Portalのアクティビティ・グラフ |
ホストの破損については、追加手順は必要ありません。第18.2.7.8項の手順に従ってください。 |
|
Oracle WebCenter Portal分析 |
ホストの破損については、追加手順は必要ありません。第18.2.7.9項の手順に従ってください。 |
Oracle SOA SuiteなどのJavaコンポーネントを同じホストにリカバリする手順は次のとおりです。
第18.2.6.1項の説明に従って、管理対象サーバーをリカバリします。
表18-2に示すように、コンポーネントに追加手順が必要な場合は、それらの手順を実行します。
Oracle SOA SuiteなどのJavaコンポーネントを別のホストにリカバリする手順は次のとおりです。
第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
ただし、表18-2に示すように、一部のコンポーネントでは追加手順が必要です。
Oracle HTTP Serverなどのシステム・コンポーネントを同じホストにリカバリするには、次の一般的な手順に従います。ただし、表18-2に示すように、一部のコンポーネントでは追加手順が必要です。
関連するすべてのプロセスを停止します。つまり、このコンポーネントに関連するすべてのプロセスを停止します。たとえば、Oracle HTTP Serverを停止するには、次のコマンドを使用します。
opmnctl stopproc ias-component=component_name
コンポーネントの停止方法の詳細は、第4.3項を参照してください。
バックアップからコンポーネント固有のファイルをリカバリします。第16.5項に、各コンポーネントに必要なディレクトリとファイルを示します。たとえば、Oracle HTTP Serverのファイルをリカバリするには、次のディレクトリをリカバリします。
ORACLE_INSTANCE/config/OHS/component_name ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
Oracleインスタンス・ホームが管理サーバーから登録解除されている場合は、Oracleインスタンスを登録します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -wlserverHome wlserver_home_location
ファイル・システムのみをリカバリする場合は、Oracleインスタンスを登録する必要はありません。
第4.3項の説明に従って、関連するすべてのプロセスを起動します。
Oracle HTTP Serverなどのシステム・コンポーネントを別のホストにリカバリするには、次の一般的な手順に従います。ただし、表18-2に示すように、ほとんどのコンポーネントでは追加手順が必要です。
第18.2.1項の説明に従って、Middlewareホームをリカバリします。
関連するすべてのプロセスを起動します。第4.3項に、コンポーネントの起動方法の説明があります。
新しいホストでopmnctl updateinstanceregistrationコマンドを使用して、管理サーバーへのOracleインスタンスの登録を更新します。次に例を示します。
opmnctl updateinstanceregistration -adminHost admin_server_host
このコマンドは、OPMNのinstance.propertiesファイルを更新します。
新しいホストでopmnctl updatecomponentregistrationコマンドを使用して、管理サーバーへのコンポーネントの登録を更新します。たとえば、Oracle Virtual Directoryの登録を更新するには、次のコマンドを使用します。
opmnctl updatecomponentregistration -Host new_host -componentName ovd1 -componentType OVD
第18.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
ほとんどのアイデンティティ管理コンポーネントでは、第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
一部のコンポーネントでは、次の各項で説明しているように、別のホストへのリカバリに追加手順が必要です。
別のホストにOracle Internet Directoryをリカバリする手順は次のとおりです。
第18.3.4.4項の説明に従って、コンポーネントをリカバリします。
UNIXシステムおよびLinuxシステムでは、Oracle Internet Directoryの起動を試行する前に、次のファイルを、root権限を持つように設定します。
ORACLE_HOME/bin/oidldapd
次に例を示します。
chown root oidldapd chmod 4710 oidldapd
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
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 Virtual Directoryをリカバリする手順は次のとおりです。
第18.3.4.4項の説明に従って、コンポーネントをリカバリします。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
別のホストにOracle Directory Integration Platformをリカバリする手順は次のとおりです。
第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
管理対象サーバーを起動する前に、次のディレクトリにあるファイルをリストアします。
DOMAIN_HOME/servers/wls_ods1/stage/DIP/11.1.1.1.0/
管理対象サーバーおよび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
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。次に例を示します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -wlserverHome wlserver_home_location
Oracle Identity FederationではSSO機能が提供されるため、ホスト破損からのリカバリの一環としてOracle Identity Federationを実行しているホストの名前を変更すると、リモート・パートナが影響を受けます。この場合、リモート・パートナで操作を続行するには、リモート・パートナでホスト名に関する変更を加える必要があります。リモート・パートナでデータを更新するには数日かかる場合があり、これは許容できない生産性の低下を招くことにもなりかねません。スタンドアロンのOracle Identity Federationサーバーのホスト名は変更しないことを強くお薦めします。
ロード・バランサが環境の一部であり、Oracle Identity FederationをリカバリしているホストがVIPのリストに含まれている場合は、ホスト名の変更は必要ありません。
Oracle Identity Federationのスタンドアロン・インストールの場合は、影響を最小限に抑えるために、同じ名前の新しいホストを使用することをお薦めします。ただし、どのような理由であれ、リカバリしているOracle Identity Federationに別のホスト名を使用する必要がある場合は、Oracle Identity Federationおよびリモート・パートナに対してホスト名を手動で更新する必要があります。
別のホストにOracle Identity Federationをリカバリする手順は次のとおりです。
第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。次に例を示します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -wlserverHome wlserver_home_location
更新されたデータをリモート・パートナに提供します。
Fusion Middleware Controlを使用して、ホスト名を変更します。
ナビゲーション・ペインで、ファームを開いてから、「Identity and Access」を開きます。
Oracle Identity Federationインスタンスを選択します。
「Oracle Identity Federation」メニューで、「管理」→「サーバー・プロパティ」を選択します。
「サーバー・プロパティ」ページが表示されます。
「ホスト」で、以前のホスト名を新しいホスト名に置き換えます。
ポート番号が変更されている場合は、「ポート」のポート番号を置き換えます。
SOAPポート番号が変更されている場合は、「SOAPポート」のポート番号を置き換えます。
「アイデンティティ・プロバイダ」→「共通」を選択します。「プロバイダID」を新しいホスト名に変更します。
「サービス・プロバイダ」→「共通」を選択します。「プロバイダID」を新しいホスト名に変更します。
LDAPがデータ・ストアの場合は、「データ・ストア」を選択します。ユーザー・データ・ストアおよびフェデレーション・データ・ストアに対する接続URLの値を、新しいホスト名に変更します。
「認証エンジン」→「LDAPディレクトリ」を選択します。「接続URL」を新しいホスト名に設定します。
「適用」をクリックします。
Oracle Identity Federationのデプロイ先の管理対象サーバーを再起動します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Oracle Identity FederationがSSLサーバーとして機能している場合は、Oracle Identity Federationからクライアントに示されているSSL証明書を、新しいホスト名を持つ新しい証明書に置き換える必要があります。そうしないと、クライアントによるホスト名の検証が失敗する場合があります。
別のホストにOracle Identity Managerをリカバリする手順は次のとおりです。
第18.3.2項の説明に従って、ドメインをリストアします。
第18.2.3項の説明に従って、Oracleホームをリストアします。
必要に応じて、OIM、OID、MDSおよびSOAINFRAスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。
Oracle Identity ManagerデータベースとLDAPプロバイダを同期します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』を参照してください。
weblogicExportMetadata.shスクリプトを使用して、oim-config.xmlファイルをエクスポートします。SOA URLのホスト名またはIPアドレスを変更することによって、エクスポートしたファイルを編集します。weblogicImportMetadata.shスクリプトを使用して、このファイルをMDSにインポートします。
第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。
第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストにOracle Identity Navigatorをリカバリする手順は次のとおりです。
第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。
第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストにOracle Access Managerをリカバリする手順は次のとおりです。
第18.2.7.5項の手順に従います。
WLSエージェントをリストアするには、第18.3.3.2項の説明に従って、管理対象サーバーをリストアします。
Oracle Access Managerコンソールにログインします。
ホスト名を変更して、Oracle Access Managerプロキシ・サーバーの新しいホスト名を指定します。Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドの個々のOAMサーバーおよびプロキシ設定の表示または編集に関する項を参照してください。
オプションで、ロード・バランサがある場合、ホスト名を変更します。Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドのAccess Managerのロード・バランシングおよびセキュア・エラー・モードの管理に関する項を参照してください。
保護されているページがある場合、 Oracle Single Sign-OnまたはWebGateをOracle Access Managerでのパートナとして再び登録する必要があります。
Oracle Access Managerコンソールにログインします。
「システム構成」タブを選択し、「Access Manager」を選択します。
すべての構成済SSOエージェントの場合、新しいホストの名前ですべてのホスト名を更新します。
設定されている場合、「サーバー・リスト」は新しいホスト名を参照します。
設定されている場合、ユーザー定義パラメータは新しいホスト名を参照します。
設定されている場合、ログアウトのリダイレクトURLは新しいホスト名を参照します。
または、Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドのリモート登録ツールに関する項の説明に従って、oamregツールを使用できます。同じマニュアルのOSSOリモート登録リクエストに関する項も参照してください。
第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。
Webゲート構成ファイルのObAccessClient.xmlを編集して、Oracle Access Managerサーバーのホスト名を更新します。このファイルは、次のディレクトリにあります。
DOMAIN_HOME/output/agentName/
第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストにOracle Adaptive Access Managerをリカバリする手順は次のとおりです。
第18.2.7.6項の手順に従います。
第18.3.5.5項の説明に従って、新しいホスト名で新しいマシンを作成します。
第18.3.5.6項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、第18.3.3.3項で説明している手順に従ってください。それ以外の場合は、この項の手順に従ってください。
同じホストにOracle SOA Suite管理対象サーバーをリカバリするには、第18.3.3.1項の説明に従って、管理対象サーバーをリカバリします。
ホストの破損後に別のホストにOracle SOA Suite管理対象サーバーをリカバリする手順は次のとおりです。
リカバリを実行する前に、新しいホスト名とポートを指すようにWSDLファイルを更新します。
第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
Oracle SOA Suite管理対象サーバーのリカバリ後に、次の操作を実行します。
antコマンドを使用してコンポジットをデプロイする場合は、deploy-sar.xmlファイルを編集します。このファイルは次の場所にあります。
(UNIX) ORACLE_HOME/bin (Windows) ORACLE_HOME\bin
次の行で、以前のホスト名を新しいホスト名に置き換えます。
<property name="wlsHost" value="newhostname"/>
ロード・バランサを使用する場合は、このプロパティは変更しないでください。かわりに、新しいホストをロード・バランサに登録します。
SOAインフラMBeanでホスト名を変更します。
Fusion Middleware Controlで、管理対象サーバーにナビゲートします。
「WebLogicサーバー」メニューから、「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「SoaInfraConfig」を開きます。「soa-infra」を選択します。
「属性」タブで、「ServerURL」をクリックします。ServerURL属性に値が含まれている場合は、ホスト名を新しいホスト名に変更します。
「適用」をクリックします。
WSDLファイルが新しいホスト名に更新されたアプリケーションをすべて再デプロイします。
|
注意: 環境にロード・バランサが構成されておらず、Oracle SOA Suiteを別のホストにリカバリする必要がある場合、タスク・フローからのレスポンスおよび非同期レスポンスを保留している進行中のインスタンスはリカバリされません。ロード・バランサを使用して、別のホストにリカバリできるようにすることをお薦めします。 |
環境にロード・バランサが構成されている場合は、次の追加手順を実行します。
Oracle WebLogic Server管理サーバーにログインします。
ドメイン構造で、「サーバー」にナビゲートします。管理対象サーバーごとに「プロトコル」タブ→「HTTP」タブを選択します。
「フロントエンド・ホスト」に、新しいホスト名を入力します。
「フロントエンドHTTPポート」および「フロントエンドHTTPSポート」(該当する場合)に、新しいポート番号を入力します。
管理対象サーバーをそれぞれ再起動します。
Web層は、Oracle HTTP ServerとOracle Web Cacheで構成されています。次の各項目で、これらのコンポーネントを別のホストにリカバリする方法について説明します。
別のホストにOracle HTTP Serverをリカバリする手順は次のとおりです。
第18.3.4.4項の説明に従って、コンポーネントをリカバリします。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
次のファイルにあるServerNameエントリを、新しいホスト名を持つように変更します。
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/httpd.conf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\httpd.conf
Oracle HTTP Serverを再起動します。
opmnctl startproc ias-component=component_name
別のホストにOracle Web Cacheをリカバリする手順は次のとおりです。
第18.3.4.4項の説明に従って、コンポーネントをリカバリします。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
webcache.xmlファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
Oracle Web Cacheを再起動します。
opmnctl startproc ias-component=component_name
次の各項目で、これらのコンポーネントを別のホストにリカバリする方法について説明します。
別のホストにOracle Portalをリカバリする手順は次のとおりです。
Middlewareホーム、ドメイン・ディレクトリおよびOracleインスタンス・ディレクトリを新しいホストにリストアします。詳細は、第18.3.3.2項を参照してください。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
Oracleインスタンスが登録解除されている場合は、新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。次に例を示します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -wlserverHome wlserver_home_location
新しいホストでopmnctl updateinstanceregistrationコマンドを使用して、管理サーバーへのOracleインスタンスの登録を更新します。次に例を示します。
opmnctl updateinstanceregistration -adminHost admin_server_host
このコマンドは、OPMNのinstance.propertiesファイルを更新します。
次のファイルを変更して、以前のホスト名を新しいホスト名に置き換えます。
ORACLE_INSTANCE/config/OHS/ohs_name/httpd.conf ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf/portal.conf
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セクションを変更し、ステップ6のファイルのパスが含まれるようにします。
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
次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。
webcache.xml。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
以前のホスト名をすべて新しいホスト名に置き換えます。
instance.properties。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/OPMN/opmn (Windows) ORACLE_INSTANCE\config\OPMN\opmn
管理サーバーのホスト名が変更されている場合は、次の行で、以前のホスト名を新しいホスト名に置き換えます。
adminHost=host_name
Oracle Portalへのアクセスに使用する公開ホストを変更する場合は、次の手順に従います。これは、Oracle Web CacheとWLS_PORTALの両方が含まれる単一ノード・インストールを使用している場合に発生する可能性があり、これらのプロセスを別のホストに移動する必要があります。別のシナリオは、Oracle Web CacheをノードでWLS_PORTALからリモートで実行しており、Oracle Web Cacheを別のホストに移動する必要がある場合です。いずれの場合も、Oracle Portal内の公開ホスト情報を更新するには次の手順を実行します。(注意: ロード・バランサまたはリバース・プロキシ構成を使用している場合は、これらの手順は必要ありません。)
次のディレクトリからすべてのコンテンツを再帰的に削除します。ただし、ディレクトリ自体を削除しないでください。
ORACLE_INSTANCE/portal/cache
Fusion Middleware Controlにログインします。ファームを開き、「Portal」を右クリックします。「設定」→「ワイヤ構成」を選択します。
「ポータル中間層」セクションで、「公開ホスト」を新しいホスト名で更新します。
「Oracle Web Cache」セクションで、「ホスト」を新しいホスト名で更新します。
WLS_PORTALインスタンスを再起動します。
別のホストにOracle Forms Servicesをリカバリする手順は次のとおりです。
第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。次に例を示します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -wlserverHome wlserver_home_location
次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。
webcache.xml。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
以前のホスト名をすべて新しいホスト名に置き換えます。
instance.properties。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/OPMN/opmn (Windows) ORACLE_INSTANCE\config\OPMN\opmn
管理サーバーのホスト名が変更されている場合は、次の行で、以前のホスト名を新しいホスト名に置き換えます。
adminHost=host_name
forms.conf。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf
WebLogicHostパラメータ内のホスト名を新しいホスト名に置き換えます。
管理サーバーのホストで、次のファイルを編集します。
DOMAIN_HOME/opmn/topology.xml
Oracle Forms Servicesの<ias-component id>要素のプロパティを追加します。次の例は、変更後の要素を示しています。
</ias-component>
<ias-component id="forms" type="FormsComponent" >
<em-properties>
<property name="OracleHome" value="/path_to_oracle_home" />
<property name="instName" value="instance_name" />
<property name="EMTargetType" value="oracle_forms" />
<property name="version" value="11.1.1" />
</em-properties>
</ias-component>
Oracleインスタンスをリカバリした新しいホストで、opmnctl updatecomponentregistrationコマンドを使用して、管理サーバーへのコンポーネントの登録を更新します。
次に例を示します。
opmnctl updatecomponentregistration -Host new_host -Port nonSSLPort -componentName forms -componentType FormsComponent
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セクションを変更し、ステップ7のファイルのパスが含まれるようにします。
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をリカバリする手順は次のとおりです。
第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。次に例を示します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -wlserverHome wlserver_home_location
次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。
reports_install.properties。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/reports (Windows) ORACLE_INSTANCE\reports
SERVER_NAME、OHS_HOSTおよびREPORTS_MANAGED_WLS_HOSTの各パラメータを編集します。
webcache.xml。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
以前のホスト名をすべて新しいホスト名に置き換えます。
instance.properties。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/OPMN/opmn (Windows) ORACLE_INSTANCE\config\OPMN\opmn
管理サーバーのホスト名が変更されている場合は、次の行で、以前のホスト名を新しいホスト名に置き換えます。
adminHost=host_name
reports_ohs.conf。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf (Windows) ORACLE_INSTANCE\config\OHS\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>要素を変更して、新しいホスト名を使用します。
次のディレクトリで、新しいホスト名を含むようにサブディレクトリの名前を変更します。
(UNIX) ORACLE_INSTANCE/diagnostics/logs/ReportsServer (Windows) ORACLE_INSTANCE\diagnostics\logs\ReportsServer
次のディレクトリで、old_host_name.datファイルの名前を新しいホスト名に変更します。
(UNIX) ORACLE_INSTANCE/reports/server (Windows) ORACLE_INSTANCE\reports\server
次のディレクトリで、新しいホスト名を含むようにサブディレクトリの名前を変更します。
(UNIX) ORACLE_INSTANCE/config/ReportsServer (Windows) ORACLE_INSTANCE\config\ReportsServer
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セクションを変更し、ステップ8のファイルのパスが含まれるようにします。
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
次のファイルで、ホスト名を新しいホスト名に置き換えます。
(UNIX) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF/mbeans.xml (Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF\mbeans.xml
次のファイルで、ホスト名を新しいホスト名に置き換えます。
(UNIX) DOMAIN_HOME/sysman/state/targets.xml (Windows) DOMAIN_HOME\sysman\state\targets.xml
次のような文字列で始まる要素内のホスト名を変更します。
<Target TYPE="oracle_repapp" ..> <Target TYPE="oracle_repserv" ..>
別のホストにOracle Business Intelligence Discovererをリカバリする手順は次のとおりです。
第18.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第18.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。次に例を示します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -wlserverHome wlserver_home_location
次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。
module_disco.conf。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name//moduleconf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf
webcache.xml。このファイルは次の場所にあります。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
以前のホスト名をすべて新しいホスト名に置き換えます。
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セクションを変更し、ステップ5のファイルのパスが含まれるようにします。
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 BI EEを別のホストにリカバリできます。
次の各項目で、Oracle BI EEを同じ名前の別のホストに移動する方法について説明します。
別のホストにOracle BI EEをリカバリする手順は、オペレーティング・システムによって異なります。ホスト名は元のホストと同じ名前にする必要があります。
UNIXでは、次の手順に従います。
Windowsでは、次の手順に従います。
第18.2.1項の説明に従って、Middlewareホームをバックアップからリストアし、作成したMiddlewareホームを新しいインストールで上書きします。
必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第18.3.6項を参照してください。
次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
第18.3.4.9.4項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。
このシナリオでは、ホストAとホストBの2つのホストにOracle BI EEクラスタがある場合を考えます。ホストAにはinstance1が含まれ、ホストBにはinstance2が含まれています。なんらかの理由(ホストのクラッシュなど)により、ホストAが置き換えられたため、ホストCにリカバリし、ホストCにinstance3が含まれるようにシステムをスケールアウトする必要があります。
次の手順を実行します。
第18.2.1項の説明に従って、MiddlewareホームをバックアップからホストCにリストアします。
必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第18.3.6項を参照してください。
Windowsでは、次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
Windowsでは、第18.3.4.9.4項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。
障害が発生したノードに管理サーバーが含まれている場合、第18.3.2.2項のステップ1から5の説明に従ってリカバリします。
Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのAPPHOST2上のBIシステムのスケールアウトに関する項の説明に従って、Oracle BI EEシステムをスケールアウトします。
次の点に注意してください。
ドメイン・ホームおよびアプリケーション・ホームのディレクトリの指定を入力する場合、存在していないディレクトリまたは空のディレクトリの指定を入力します。
ドメイン・ホーム・フィールドが空の場合は、ドメイン・ディレクトリを含むように次のファイルを更新します。
MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.domains
ノード・マネージャを起動する前に、次の手順を実行します。
ノード・マネージャが実行されている場合は、停止します。
ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh
ノード・マネージャを再起動し、次のコマンドを使用して動的登録を有効にします。
cd WL_HOME/server/bin
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh
|
注意: 管理サーバーを管理するノード・マネージャの起動時には、-DDomainRegistrationEnabled=trueを設定することが重要です。コンピュータ上に管理サーバーがなく、このコンピュータが管理サーバーのフェイルオーバー・ノードでない場合、ノード・マネージャは次のように起動できます。 ./startNodeManager.sh |
Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのシステム・コンポーネントのスケールアウトに関する項の説明に従って、システム・コンポーネントをスケールアウトします。それらの構成を変更すると、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 Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項を参照してください。
Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのbi_server2管理対象サーバーのリスニング・アドレスの設定に関する項の説明に従って、bi_servern管理対象サーバーのリスニング・アドレスを設定します。
Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのbi_server2管理対象サーバーのホスト名検証の無効化に関する項の説明に従って、bi_servern管理対象サーバーのホスト名検証を無効にします。
環境に応じて、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのOracle Business Intelligenceの可用性のための追加構成の実行に関する項の説明に従って、追加構成を実行します。
Oracle HTTP Serverがインストールされている場合は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の管理コンソールのフロントエンドURLに関する項の説明に従って、Oracle BI SearchのURLが正しく設定されるようにOracle WebLogic ServerクラスタのフロントエンドHTTPホストおよびポートを設定します。
Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの管理対象サーバーのノード・マネージャの構成に関する項の説明に従って、管理対象サーバーのノード・マネージャを構成します。
Oracle BI EE管理対象サーバーおよびすべてのOPMNの管理対象コンポーネントを起動します。
環境に応じて、第18.3.4.9.2項の手順を実行した後に、追加手順を実行する必要がある場合があります。
ホストにマスターBIサーバー、プライマリ・クラスタ・コントローラ、およびプライマリOracle BIスケジューラが含まれている環境で障害が発生したときに、新しいインスタンスをマスターBIサーバーにする必要がある場合、必要に応じて次の手順を実行します。インスタンス2を引き続きマスターBIサーバーにする場合は、この追加手順を実行する必要はありません。
マスターBIサーバーが失われた場合、次の手順を実行します。
すべてのノードでOracle WebLogic ServerおよびOPMNプロセスを停止します。
新しいマスターBIサーバーを指定するように次の構成ファイルを更新します。
DOAMIN_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 Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項を参照してください。
障害が発生したホストにBIサーバー、セカンダリ・クラスタ・コントローラ、およびセカンダリOracle BIスケジューラが含まれる場合、セカンダリ・クラスタ・コントローラまたはスケジューラとして新しいホストを指定します。
障害が発生したホストにBIサーバーおよびBIプレゼンテーション・サービスやBI Javaホストなどのシステム・コンポーネントが含まれる場合、追加手順は不要です。
障害が発生したホストに次の関連するコンポーネントが含まれる場合、それらをリカバリします。
Oracle Business Intelligence Publisher: 第18.3.4.10項を参照
Oracle Real-Time Decisions: 第18.3.4.11項を参照
Oracle Essbase: 第18.3.4.12項を参照
Oracle Hyperion Calculation Manager: 第18.3.4.13項を参照
Oracle Hyperion Financial Reporting: 第18.3.4.14項を参照
Oracle Hyperion Smart View: 第18.2.7.16項を参照
Windowsでは、Oracle BI EEレジストリ・エントリを新しいホストにインポートする必要があります。第17.3.3項には元のホストからそれらをエクスポートする方法が説明されています。
元のホストからエクスポートされたすべてのファイルを新しいホストにコピーします。
元のホストからコピーした各ファイルをダブルクリックします。入力を求められたら「はい」をクリックして、ファイルをレジストリにインポートします。
別のホストにOracle Business Intelligence Publisherをリカバリする手順は次のとおりです。
第18.3.3項の説明に従って、Oracle Business Intelligence Publisherコンポーネントが含まれる管理対象サーバーをリカバリします。
必要に応じて、Oracle Business Intelligence Publisherスキーマが含まれるデータベースをリストアします。第18.2.10項を参照してください。
Oracle BIプレゼンテーション・サービスに対するサーバー値を変更します。
http://hostname:port/xmlpserverでBI Publisherアプリケーションを開いてログインします。
「管理」→「統合」→「Oracle BIプレゼンテーション・サービス」をクリックします。
「サーバー」を新しいホスト名に変更します。
「適用」をクリックします。
コールド・フェイルオーバー・クラスタ環境で動作するようにOracle BI Publisherを変換するには、BI SchedulerのJMS構成を変更する必要があります。
BI Publisherアプリケーションで、「管理」をクリックします。
システム管理セクションで、スケジューラ構成をクリックします。
「Weblogic JNDI URL」を新しいホストURLに変更します。たとえば、t3://hostname:portと指定します。
「適用」をクリックします。
コールド・フェイルオーバー・クラスタを使用している場合は、仮想IPアドレスをリスニングするように管理対象サーバーを構成します。『Oracle Fusion Middleware高可用性ガイド』のOracle WebLogic管理対象サーバーの変換に関する項を参照してください。次に、管理コンソールまたはWLSTコマンドラインを使用して、管理対象サーバーを再起動します。
BI Publisherでは、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更するか、作成する必要があります(新規作成する場合は新しい仮想ホストを使用)。データソースを変更する手順は次のとおりです。
BI Publisherアプリケーションで、次の手順を実行します。
「データソース」の下にある「JDBC接続」をクリックします。
このインスタンスのBI Enterprise Editionのデータ・ソースをすべて編集して、新しいホストに対する値を反映するようにします。
バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。
別のホストにOracle Real-Time Decisionsをリカバリする手順は次のとおりです。
第18.3.3項の説明に従って、Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。
バックアップ・アーティファクトが別の時点からリストアされると、分析モデルで学習期間が失われますが、インテリジェント機能には影響しません。
Oracle Essbaseがクラスタ環境に配置されており、障害が発生したホストにEssbaseシステム・コンポーネントのクラスタリングが含まれている場合には、OPMNを使用して次の追加手順を実行し、Oracle Essbaseをリカバリします。このシナリオでは、ノードAとノードBにOracle Essbaseのクラスタリングが設定されており、ノードAが破損します。新しいEssbaseコンポーネントをノードCに作成し、Essbaseコンポーネントを含む新しいクラスタをノードCとノードBに作成します。以前のクラスタは使用できないため、決してリカバリしないでください。
第18.3.4.9項の手順6および7の説明に従って、新しいホスト(ノードC)でOracle BI EEシステムとシステム・コンポーネントをスケールアウトします。
共有化されているARBORPATHディレクトリを、ノードBとノードCの両方で、同じパスにマウントします。たとえば、Windowsの場合、ノードBとノードCの両方でYドライブにディレクトリをマップします。
ノードBおよびノードCで次のファイルを編集して、adminHostプロパティを更新します。
ORACLE_INSTANCE/config/OPMN/opmn/instance.properties
次に例を示します。
adminHost=ADMINVHN
ノードCでウォレットをコピーして、管理サーバーにプッシュします。
ノードBからノードCにウォレットをコピーします。ウォレットは次の場所にあります。
ORACLE_INSTANCE/config/OPMN/opmn/wallet
opmn.xmlファイルで、ssl enabled="true"になっていることを確認します。
次のコマンドを使用して、管理サーバーにウォレットをプッシュします。
./opmnctl updateinstanceregistration
このコマンドによって、Oracle WebLogic Serverの管理者パスワードの入力を求めるプロンプトが表示されます。updateinstanceregistrationコマンドは、管理サーバーに登録された、Oracleインスタンスの情報を更新します。特に、updateinstanceregistrationコマンドは、登録されたOPMNリモート・ポート、リモート・ホストおよびウォレットを現在のOPMN設定から更新します。
すべてのノードでOPMNを再起動します。
opmnctl startall
新しいクラスタにノードBのOracle Essbaseインスタンスを含めるために停止します。
opmnctl stopproc ias-component=essbaseserver1 process-type=Essbase
Fusion Middleware Controlにログインし、「Business Intelligence」を開きます。その後、「Business Intelligenceインスタンス」を選択します。
「可用性」タブを選択して、「フェイルオーバー」タブを選択します。「Essbaseエージェント」セクションで、「共有フォルダ・パス」の値を指定します。
「適用」をクリックして、「変更のアクティブ化」をクリックします。
同じタブの「プライマリ/セカンダリ構成」セクションの「セカンダリ・ホスト / インスタンス」で、ノードCのセカンダリOracle Essbaseインスタンスを選択します。
「適用」をクリックして、「変更のアクティブ化」をクリックします。
Oracle Essbaseインスタンスが作成され、両方のサーバーがクラスタの一部になります。
ノードBおよびノードCで、すべてのOPMNコンポーネントを停止し、再起動します。
opmnctl stopall opmnctl startall
ホスト破損後に、Oracle Hyperion Calculation Managerをリカバリするには、第18.2.7.14項の手順に従います。
データベースのリストアが必要な場合は、データベースをリストアし、エクスポートしたファイルからCalculation Managerのルールおよびルール・セットをインポートします。
Calculation Managerで、「ファイル」→「インポート」を選択します。
Oracle Hyperion Financial Reportingを含むホストが破損した場合は、同じホストまたは異なるホストにリカバリできます。Oracle Hyperion Financial Reportingをリカバリするには、第18.2.3項の説明に従って、Oracleホームをリカバリし、第18.2.4項の説明に従って、Oracleインスタンスをリカバリします。
データベース・ホストが変更されている場合は、次のコマンドを使用してホスト名を更新します。
Epmsys_registry updateproperty financial_reporting_product/@host new_host Epmsys_registry updateproperty financial_reporting_product/logical_web_app/@host new_host Epmsys_registry updateproperty financial_reporting_product/logical_web_app/financial_reporting_web_app@host new_host
別のホストにOracle Data Integratorをリカバリする手順は次のとおりです。
データベースを別のホストにリストアする必要がある場合は、第18.3.6項の説明に従って、データベースをリストアします。
第18.2.3項の説明に従って、バックアップからOracle Data IntegratorのOracleホームをリカバリします。
第18.3.2項の説明に従って、ドメインをリストアします。
各スタンドアロン・エージェント、およびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを停止します。
データベースが別のホストにある場合は、トポロジ内のリポジトリ接続情報を変更します。
ODI Studioを使用して、リストアされたOracle Data Integratorリポジトリに接続します。『Oracle Fusion Middleware Oracle Data Integratorのための開発者ガイド』のマスター・リポジトリへの接続に関する項の説明に従って、新しいデータベース・ホストへのマスター・リポジトリの新しい接続を作成します。
作業リポジトリをそれぞれ編集します。「接続」をクリックして、作業リポジトリが含まれる新しいデータベース・ホストを指すJDBC URLが含まれるように接続情報を編集します。
各物理エージェントの構成を編集し、更新したホスト名の値を指定して、ポートの値を変更した場合はポートの値も指定します。
スタンドアロン・エージェントのスクリプトが生成されていて、それらに-PORTプロパティが含まれる場合は、-PORTの値を新しいポートの値に変更します。スクリプトの名前は、agentName_agent.shまたはagentName_agent.batです。
スタンドアロン・エージェントごとに次のファイルを編集し、データベースが別のホストにある場合は、新しいデータベース・ホストの場所に一致するようにODI_MASTER_URLパラメータを変更します。
oracledi/agent/bin/odiparams.*
次のファイルを編集して、データベース接続情報とポート番号を変更します。
oracledi/agent/bin/odi_opmn_standaloneagent_template.xml
Oracle WebLogic Server構成で、新しいデータベース・ホストの場所に一致するようにデータソースを編集します。
スタンドアロン・エージェント、およびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを再起動します。
次の各項で、Oracle WebCenter ContentおよびOracle WebCenter Content: Recordsを別のホストにリカバリする方法について説明します。
別のホストにOracle WebCenter Contentをリカバリする手順は次のとおりです。
データベースを別のホストにリストアする必要がある場合は、第18.3.6項の説明に従って、データベースをリストアします。
第18.3.2項の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリに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
データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。
Oracle WebCenter Content: Recordsは、Oracle WebCenter Contentに依存しており、追加でバックアップまたはリカバリするアーティファクトがないため、Oracle WebCenter Contentのリカバリ手順(第18.3.4.16.1項)を参照してください。
リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち1つ以上を実行する必要がある場合があります。そのような場合は、エンティティをリカバリする方法を説明している項に明記されています。
次の各項目で、実行することが必要な可能性のある操作について説明します。
別のホストにFusion Middleware Controlをリカバリするには、次の手順に従います。
次のファイル内のホスト名を更新します。
DOMAIN_HOME/config/fmwconfig/servers/AdminServer/applications/em/META-INF/emoms.properties
このファイルで、次のプロパティのホスト名を変更します。
oracle.sysman.emSDK.svlt.ConsoleServerHost oracle.sysman.emSDK.svlt.ConsoleServerName
次のファイルを編集します。
(UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties (Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties
このファイルで、Oracle Management Agentによって監視されている各コンポーネントの次のエントリを編集し、ホスト名を置き換えます。
REPOSITORY_URL=http://newhost.domain.com:port/em/upload/ EMD_URL=http://newhost.domain.com:port/emd/main/ emdWalletSrcUrl=http://newhost.domain.com:%EM_UPLOAD_PORT%/em/wallets/emd
別のホストにコンポーネントをリカバリする場合、Fusion Middleware Controlのtargets.xmlファイルを更新する必要があります。このファイルは次の場所にあります。
(UNIX) DOMAIN_HOME/sysman/state/targets.xml (Windows) DOMAIN_HOME\sysman\state\targets.xml
このファイルで、別のホストにリカバリするコンポーネントのホスト名を新しいホスト名に変更します。
多くのコンポーネントでは、別のホストにリカバリするときに、ホストの破損の場合と同様に、Fusion Middleware Controlがコンポーネントを管理できるように、Oracle Management Agentをリカバリする操作を実行する必要があります。これは、次のインストール・タイプやコンポーネントに関連しています。
アイデンティティ管理コンポーネント
Oracle Identity Federation
Oracle Portal
Oracle Business Intelligence Discoverer
Oracle Forms Services
Oracle Reports
Oracle Management Agentをリカバリするには、次の手順を実行します。
次のファイルを編集します。
(UNIX) DOMAIN_HOME/sysman/state/targets.xml (Windows) DOMAIN_HOME\sysman\state\targets.xml
ファイル内で、次の要素を編集し、ホスト名を置き換えます。
<Target TYPE="host" NAME="newhost.domain.com" DISPLAY_NAME="newhost.domain.com"/>
次のファイルを編集します。
(UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties (Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties
次のエントリを更新して、ホスト名を置き換えます。
REPOSITORY_URL=http://newhost.domain.com:port/em/upload/ EMD_URL=http://newhost.domain.com:port/emd/main/
次のコマンドを使用して、Oracle Management Agentを起動します。
opmnctl startproc ias-component=EMAGENT
管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーを起動すると、Fusion Middleware Controlも起動されます。
管理サーバーまたは管理対象サーバーを別のホストにリカバリする場合、環境にOracle HTTP Serverが含まれていると、新しいホスト上で次のファイルを変更する必要があります。
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/mod_wl_ohs.conf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\mod_wl_ohs.conf
そのファイルで、ホスト名、ポート、およびクラスタのエントリのすべてのインスタンス(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>
次のアイデンティティ管理コンポーネント(およびリスニング・アドレスを使用している場合は管理サーバー)の場合、管理サーバーを起動する前に、新しいホスト名で新しいマシンを作成する必要があります。
Oracle Access Manager
Oracle Adaptive Access Manager
Oracle Identity Manager
Oracle Identity Navigator
次の手順を実行します。
新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。
wls:/offline> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> machine = create('newhostname', 'Machine')
wls:/offline/sampledomain> cd('/Machine/newhostname')
wls:/offline/sampledomain> nm = create('newhostname', 'NodeManager')
wls:/offline/sampledomain> cd('/Machine/newhostname/NodeManager/newhostname')
wls:/offline/sampledomain> set('ListenAddress', 'newhostname')
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。
wls:/offline> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> cd ('/Machine/newhostname')
wls:/offline/sampledomain> machine = cmo
wls:/offline/sampledomain> cd ('/Server/AdminServer')
wls:/offline/sampledomain> set('Machine', machine)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
管理サーバーのリスニング・ポートを設定します。
wls:/offline/sampledomain> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> cd('/Server/AdminServer')
wls:/offline/sampledomain> cmo.setListenPort(8001)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
次のアイデンティティ管理コンポーネントのバックアップをリストアすると、Weblogicユーザーは、前に関連付けられていたグループとは関連付けられなくなります。
Oracle Access Manager
Oracle Adaptive Access Manager
Oracle Identity Manager
Oracle Identity Navigator
Weblogicユーザーをグループに再関連付けする必要があります。
ユーザーのグループへの関連付けの詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのユーザーのグループへの追加に関する項を参照してください。
多くのコンポーネントで、別のホストにリカバリするときは、ホストの破損の場合と同様に、Oracleインベントリを更新する必要があります。そのためには、次のスクリプトを実行します。
ORACLE_HOME/oui/bin/attachHome.sh
また、beahomelistを更新して、Middlewareホームの場所を編集する必要があります。次のファイルを編集して、Middlewareホームの情報を更新します。
(UNIX) user_home/bea/beahomelist
(Windows) C:\bea\beahomelist
Windows上で別のホストにコンポーネントをリカバリするときは、ホストの破損の場合と同様に、Oracle Fusion Middlewareに関連するすべてのWindowsレジストリ・キーを新しいホストにインポートする必要があります。(レジストリ・キーは、第17.3.3項でエクスポートしたものです。)
次のレジストリ・キーをリカバリします。
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
キーのインポートにはレジストリ・エディタを使用することもできます。詳細は、レジストリ・エディタのヘルプを参照してください。
データベースを含むホストが破損した場合、RMANを使用してリカバリできます。
次に例を示します。
rman> restore database; rman> recover database;
最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これにより、確実に最新のデータがリカバリされます。また、データベースに同じ名前を使用します。次の点に注意してください。
各コンポーネントで使用するスキーマについては、付録Dを参照してください。
Oracle BPEL Process Managerのポイント・イン・タイム・リカバリを使用すると、最新のプロセス定義および進行中のインスタンスがリストアされます。ただし、これによってプロセスの手順が再実行される場合があります。できるかぎり、Oracle BPEL Process Managerの冪等プロセスを使用することをお薦めします。冪等以外のプロセスがシステムに含まれている場合は、それらをデハイドレーション・ストアからクリーンアップしてからOracle Fusion Middlewareを起動する必要があります。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
データベースのリカバリおよびRMANの使用の詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
