| Oracle® Fusion Middleware管理者ガイド 11gリリース1（11.1.1） B60984-01 |
|
 戻る |
 次へ |
この章では、Oracle Fusion Middlewareを様々なタイプの障害および停止からリカバリするための推奨されるリカバリ計画および手順について説明します。
この章の項目は次のとおりです。
この項では、ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害またはメディア障害などが関係する停止に対するリカバリ計画の概要を示します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。
|
注意: この章に記載されている手順では、最後のバックアップ以降、管理上の変更は加えられていないことを前提としています。最後のバックアップ以降、管理上の変更が加えられている場合は、リカバリの完了後にそれらの変更を再適用する必要があります。 |
ファイルのリストア時、圧縮ファイルの解凍には、それに適したツールを使用します。
Windowsでのオンライン・バックアップにはcopy、Windowsでのオフライン・バックアップにはcopy、xcopyまたはjarを使用します。
一部のバージョンのWindowsでは、ファイル名が256文字を超えていると失敗します。この問題が発生しないようにするには、次のスイッチを指定したxcopyコマンドを使用できます。
xcopy /s/e "C:\Temp\*.*" "C:\copy"
構文と制限の詳細は、xcopyのヘルプを参照してください。
Winzipは、長いファイル名や拡張子には対応していないため使用しないでください。
たとえば、LinuxおよびUNIXの場合はtarを使用します。
使用しているツールが、ファイルの権限とタイムスタンプを保存することを確認してください。
必要なファイルを間違って上書きしないよう、バックアップからファイルをリストアする前に既存のファイルおよびディレクトリの名前を変更してください。
この項では、ディスクをリストアできないような、実データの損失や破損、またはメディア障害などが関係する停止に対するリカバリ計画について説明します。適切に機能しなくなったアプリケーションに対するリカバリ計画についても説明します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。この項の項目は次のとおりです。
破損したりファイルが削除されたMiddlewareホームをリカバリできます。
関連するすべてのプロセスを停止します。つまり、管理サーバー、ノード・マネージャ、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
バックアップからMiddlewareホーム・ディレクトリをリカバリします。たとえば、次のように指定します。
cd MW_HOME
(UNIX) tar -xf mw_home_backup_032010.tar
(Windows) jar xtf mw_home_backup_032010.jar
関連するすべてのプロセスを起動します。つまり、Middlewareホームで実行するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリすることができます。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリする手順は次のとおりです。
関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
バックアップからドメイン・ディレクトリをリカバリします。
cd DOMAIN_HOME
(UNIX) tar -xf domain_backup_032010.tar
(Windows) jar xtf domain_backup_032010.jar
関連するすべてのプロセスを起動します。つまり、このドメインに関連するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
管理サーバーを起動できない場合は、第17.2.5項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、第17.2.6項の説明に従って、管理対象サーバーをリカバリします。
特定のコンポーネントのOracleホームをリカバリする手順は次のとおりです。
バックアップ・ファイルからOracleホームを元のディレクトリにリカバリします。たとえば、次のように指定します。
cd ORACLE_HOME
tar -xf Oracle_home_backup_032010.tar
WLSTのstartコマンドを使用して、アプリケーションのデプロイ先の管理対象サーバーを再起動します。たとえば、次のように指定します。
wls:/mydomain/serverConfig> start('myserver','Server')
Oracleインスタンス・ホームには、Oracle HTTP ServerやOracle Internet Directoryなどのシステム・コンポーネントに関する構成情報が含まれています（システム・コンポーネントの一覧は、第3.5.2項を参照）。次の各項目で、Oracleインスタンス・ホームをリカバリする方法について説明します。
ファイル・システムから削除されたり破損したOracleインスタンス・ホームをリカバリする手順は次のとおりです。
関連するすべてのプロセスを停止します。つまり、Oracleインスタンスに関連するすべてのプロセスを強制終了します。
バックアップ・ファイルからOracleインスタンス・ホーム・ディレクトリをリカバリします。たとえば、次のように指定します。
cd ORACLE_INSTANCE
(UNIX) tar -xf sc_home_backup_032010.tar
(Windows) jar xtf sc_home_backup_032010.jar
関連するすべてのプロセスを起動します。つまり、Oracleインスタンスに関連するすべてのプロセスを起動します。
opmnctl startall
ドメインから登録解除されたOracleインスタンス・ホームをリカバリする手順は次のとおりです。
バックアップ・ファイルからOracleインスタンス・ホーム・ディレクトリをリカバリします。たとえばLinuxでは、次のように指定します。
cd ORACLE_INSTANCE
tar -xf Instance_home_backup_032010.tar
opmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir -instanceName Instance_name -wlserverHome Middleware_Home
ファイルの削除またはファイル・システムの破損が原因で、管理サーバーの構成が失われた場合でも、問題の発生時に管理サーバーのコンソールがすでに起動しているときには、このコンソールは引き続き機能します。管理サーバー・ディレクトリは、セキュリティ情報を除き、自動的に再生成されます。その結果、管理サーバーを起動するたびに、ユーザー名とパスワードの入力を求めるプロンプトが表示されます。これを避けるには、構成をリカバリします。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
管理サーバーの構成をリカバリする手順は次のとおりです。
管理サーバー、管理対象サーバーおよびノード・マネージャが起動している場合はこれらも含めて、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。たとえば、次のように指定します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
管理サーバーが正常に起動しており、アクセス可能であることを確認します。
構成が次回変更されるときに、管理サーバーの構成が、管理対象サーバーにプッシュされます。管理対象サーバーが再起動するたびに、管理サーバーから構成が取得されます。
管理対象サーバーのファイルが削除されたり破損した場合、その構成ファイルを含めて、それらのファイルをリカバリできます。
次の各項目で、管理対象サーバーのファイルをリカバリする方法について説明します。
ディレクトリが異なるOracle SOA Suite管理対象サーバーのリカバリ
この項は、Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合に関連します。
このシナリオでは、管理対象サーバーの構成が削除されたり破損したために、あるいは構成が誤って変更され変更内容を確認できないために、管理対象サーバーが適切に動作しなかったり起動できない場合を考えます。
管理対象サーバーを起動できない場合のリカバリの手順は次のとおりです。
管理サーバーにアクセスできない場合は、第17.2.5項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次の手順を実行します。
必要に応じて、Middlewareホームをバックアップからリカバリします。たとえば、次のように指定します。
tar -xf mw_home_backup_032010.tar
packユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。
pack.sh -domain=MW_HOME/user_projects/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/aime1/ms.jar -domain=MW_HOME/user_projects/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
ステージング、ステージングなしおよび外部ステージング・モードの各アプリケーションの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
管理対象サーバーを起動します。たとえば、次のように指定します。
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_032010.tar
packユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。
pack.sh -domain=MW_HOME/user_projects/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/aime1/ms.jar
-domain=MW_HOME/user_projects/domains/WLS_SOAWC
-log=/scratch/logs/new.log -log_priority=info
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
管理対象サーバーを再起動します。たとえば、次のように指定します。
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_032010.tar
管理対象サーバーを再起動します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
次の各項目で、ほとんどのコンポーネントについてリカバリする方法を説明します。
一部のコンポーネントについては、別の手順に従う必要があります。表17-1に、そのようなコンポーネントと、そのリカバリ手順を説明している項を示します。
表17-1 特定のコンポーネントのリカバリ手順
| コンポーネント | 手順 |
|---|---|
|
Oracle Access Manager |
|
|
Oracle Adaptive Access Manager |
|
|
Oracle BI Enterprise Edition |
|
|
Oracle Business Intelligence Publisher |
|
|
Oracle Business Process Management |
|
|
Oracle Real-Time Decisions |
|
|
Oracle Data Integrator |
|
|
Oracle Identity Manager |
|
|
Oracle Identity Navigator |
|
|
Oracle Imaging and Process Management |
|
|
Oracle Information Rights Management |
|
|
Oracle Universal Content Management |
|
|
Oracle Universal Records Management |
|
コンポーネントの構成が変更されコミットされたために適切に機能しないまたは起動できないコンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。また、コンポーネントのファイルが削除されたり破損した場合、それらのファイルをリカバリできます。
Oracle SOA SuiteなどのJavaコンポーネントの場合は、第17.2.6項の説明に従って、管理対象サーバーをリカバリします。
システム・コンポーネントの場合（Oracle HTTP ServerやWeb Cacheなど）:
コンポーネントを停止します。たとえば、Oracle HTTP Serverを停止するには、次のコマンドを使用します。
opmnctl stopproc ias-component=component_name
コンポーネントの停止方法の詳細は、第4.3項を参照してください。
バックアップからコンポーネント固有のファイルをリカバリします。第15.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項を参照してください。
クラスタ・レベルで構成が変更されコミットされたために、クラスタ内のコンポーネントが適切に機能しないまたは起動できない場合、それらのコンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
コンポーネントをリカバリする手順は次のとおりです。
管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。たとえば、次のように指定します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTのstartコマンドを次のように使用します。
start('clusterName', 'Cluster')
最新の構成が管理サーバーからクラスタのすべてのメンバーに取得されます。
Oracle Access Managerをリカバリする手順は次のとおりです。
第17.2.1項の説明に従って、Middlewareホーム、およびOracle Access Manager管理対象サーバーのドメイン・ホームをリカバリします。
第17.2.2項の説明に従って、ドメインをリストアします。
必要に応じて、第17.2.3項の説明に従って、Webゲートが含まれるOracle HTTP ServerのOracleホームをリカバリします。
必要に応じて、第17.2.4項の説明に従って、Webゲートが含まれるOracle HTTP ServerのOracleインスタンスをリストアします。
必要に応じて、Oracle Access Managerポリシー・ストア用にOESで使用されるスキーマが含まれるデータベースをリストアします。第17.2.10項を参照してください。
Oracle Business Process Managementをリカバリする手順は次のとおりです。
次の各項目で、Oracle Business Intelligence Enterprise Edition（Oracle BI EE）をリカバリする方法について説明します。
このシナリオでは、Oracle BI Enterprise Editionが非クラスタ環境で実行されていると想定します。
障害の程度に応じて、次のものをリストアします。
必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第17.2.10項を参照してください。
|
注意: Windowsでは、Oracle BI EEは、Oracle Fusion Middlewareインストールには含まれていないレジストリ設定と.dllファイル（Microsoft C++など）を使用します。この手順は、それらのファイルのリストアをサポートしていません。 |
このシナリオでは、Oracle BI Enterprise Editionが非クラスタ環境で実行されていると想定します。障害の程度に応じて、次のものをリカバリします。
障害の程度に応じて、次のものをリストアします。
第17.2.5項の説明に従って、管理サーバーをリカバリします。
第17.2.6項の説明に従って、管理対象サーバーをリカバリします。
必要に応じて、Oracle BI EEスキーマが含まれるデータベースをリストアします。第17.2.10項を参照してください。
|
注意: Windowsでは、Oracle BI EEは、Oracle Fusion Middlewareインストールには含まれていないレジストリ設定と.dllファイル（Microsoft C++など）を使用します。この手順は、それらのファイルのリストアをサポートしていません。 |
Oracle Business Intelligence Publisherをリカバリする手順は次のとおりです。
第17.2.6項の説明に従って、Oracle Business Intelligence Publisherコンポーネントが含まれる管理対象サーバーをリカバリします。
必要に応じて、Oracle Business Intelligence Publisherスキーマが含まれるデータベースをリストアします。第17.2.10項を参照してください。
バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。
Oracle Real-Time Decisionsをリカバリする手順は次のとおりです。
第17.2.6項の説明に従って、Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。
バックアップ・アーティファクトが別の時点からリストアされると、分析モデルで学習期間が失われますが、インテリジェント機能には影響しません。
Oracle Information Rights Managementをリカバリする手順は次のとおりです。
Oracle Imaging and Process Management（Oracle I/PM）では、データが次の場所に格納されています。
Oracle I/PM構成データ用データベース
ドキュメント・リポジトリとして機能するデータベース
JMS永続キュー
Oracle I/PMをリカバリする場合、すべてのデータが同じ時点からリストアされるようにする必要があります。
Oracle I/PMをリカバリする手順は次のとおりです。
Oracle Universal Content Managementをリカバリする手順は次のとおりです。
データベースをリストアする必要がある場合は、第17.3.6項の説明に従って、データベースをリストアします。
第17.2.2項の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
cd /net/home/vault tar -xf vault_backup_032010.tar
データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。
Oracle Universal Records Managementは、Oracle Universal Content Managementに依存しており、追加でバックアップまたはリカバリするアーティファクトがないため、Oracle Universal Content Managementのリカバリ手順（第17.2.7.14項）を参照してください。
次の各項目で、クラスタをリカバリする方法について説明します。
このシナリオでは、クラスタが間違って削除されたり、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 -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
start('clusterName', 'Cluster')
クラスタのメンバーシップを誤って変更した場合に、クラスタをリカバリできます。たとえば、クラスタからメンバーを誤って削除した場合、メンバーをクラスタにリストアできます。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
クラスタのメンバーシップをリカバリする手順は次のとおりです。
管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。たとえば、次のように指定します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
削除されたメンバーがクラスタに戻ります。
管理対象サーバーなど、すべてのプロセスを起動します。たとえば、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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。次のリンクから入手可能です。
http://www.oracle.com/technology/documentation/database.html
この項では、Oracle Fusion Middlewareの元の動作環境が損なわれた後、その環境をリカバリする方法について説明します。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。この項の項目は次のとおりです。
|
注意: ホストの破損からリカバリする場合、元のホストで使用していたものと同じパスを使用してファイルをリストアする必要があります。 |
Oracle WebLogic Serverドメインをリカバリする手順は次のとおりです。
関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
バックアップからドメイン・ディレクトリをリカバリします。
cd DOMAIN_HOME
(UNIX) tar -xf domain_backup_032010.tar
(Windows) jar xtf domain_backup_032010.jar
関連するすべてのプロセスを起動します。つまり、このドメインに関連するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
管理サーバーを起動できない場合は、第17.3.2項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、第17.3.3項の説明に従って、管理対象サーバーをリカバリします。
管理サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
このシナリオでは、管理サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。たとえば、管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストAに障害が発生し、管理サーバーをリカバリする必要があるとします。
管理サーバーをリカバリする手順は次のとおりです。
管理サーバーを起動してみます。たとえば、次のように指定します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
管理サーバーが起動する場合は、これ以上の手順は必要ありません。
管理サーバーが起動しない場合は、ホストAで次の手順を実行します。
関連するすべてのプロセスを停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
必要に応じて、Middlewareホームをリカバリします。
tar -xf mw_home_backup_032010.tar
ドメイン・ディレクトリがMiddlewareホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。
cd DOMAIN_HOME
tar -xf domain_backup_032010.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()
このシナリオでは、管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストAに障害が発生し、管理サーバーをホストCに移行する必要がある場合を考えます。
MiddlewareホームをホストC（新しいホスト）にリカバリします。
cd MW_HOME
tar -xf mw_home_backup_032010.tar
ドメイン・ディレクトリがMiddlewareホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。
cd DOMAIN_HOME tar -xf domain_backup_032010.tar
管理サーバーにリスニング・アドレスが指定されている場合は、第17.3.5.4項の説明に従って、新しいホスト名で新しいマシンを作成します。
元のホストでノード・マネージャが構成されていた場合は、ホストCでノード・マネージャを起動します。
java weblogic.WLST wls:/offline> startNodeManager()
管理サーバーを起動します。たとえば、次のように指定します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
管理対象サーバーを起動します。『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』の障害が発生した管理サーバーの再起動に関する項で、構成に応じてサーバーを再起動する様々な方法が説明されています。
オプションの1つとして、次のコマンドの使用があります。このコマンドでは、新しいホストの管理用URLを指定します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
追加のアプリケーション・アーティファクトが使用可能であることを確認します。たとえば、デプロイメント・モードがステージングなしまたは外部ステージングの場合、アプリケーションはドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
第17.3.5.6項の説明に従って、Oracle Inventoryを更新します。
第17.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
Fusion Middleware Controlの一部であるOracle Management Serviceは、元のホストに配置されており、管理サーバーのリストア時に新しいホストにリカバリされます。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/
EMエージェント・プロセスを停止して、再起動します。
cd ORACLE_INSTANCE/EMAGENT/emagent_dir ./emctl stop agent ./emctl start agent ./emctl status agent
ステータス・コマンドに、新しいホストを指すREPOSITORY_URLが示されます。
これで、ホストCで実行されている管理コンソールを使用して、ホストBの管理対象サーバーを起動および停止できます。
Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、第17.3.5項を参照してください。
管理対象サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
ディレクトリが異なるOracle SOA Suite管理対象サーバーのリカバリ
この項は、Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合に関連します。
このシナリオでは、管理対象サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストBに障害が発生し、管理対象サーバーをホストBにリカバリする必要があるとします。
ホストBでノード・マネージャを起動します。
java weblogic.WLST wls:/offline> startNodeManager()
管理対象サーバーを起動します。たとえば、次のように指定します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが起動した場合、管理対象サーバーは管理サーバーに接続し、構成の変更を更新します。これ以上の手順は必要ありません。
管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次の手順を実行します。
ノード・マネージャを停止します。
java weblogic.WLST wls:/offline> stopNodeManager()
必要に応じて、MiddlewareホームをバックアップからホストBにリカバリします。
tar -xf mw_home_backup_032010.tar
管理対象サーバーにOracle Portal、Oracle Reports、Oracle Forms ServicesまたはOracle Business Intelligence Discovererが含まれており、管理対象サーバーのドメイン・ディレクトリがMiddlewareホームの外部に存在する場合、Middlewareホームに加えてドメインをリストアします。たとえば、次のように指定します。
cd Domain_Home
tar -xf domain_home_backup_032010.tar
手順eに進みます。
手順cに示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。
packユーティリティを使用して、ホストAで実行されている管理サーバーのドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。
pack.sh -domain=MW_HOME/user_projects/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/aime1/ms.jar -domain=MW_HOME/user_projects/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
ノード・マネージャが起動していない場合は、起動します。
java weblogic.WLST wls:/offline> startNodeManager()
管理対象サーバーを起動します。たとえば、次のように指定します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
このシナリオでは、管理サーバーがホストAで実行され、管理対象サーバーがホストBで実行されているときに、なんらかの理由でホストBに障害が発生し、管理対象サーバーをホストCにリカバリする必要がある場合を考えます。
|
重要: 元と同じ場所にMiddlewareホームをリカバリします。 |
次の手順に従います。
管理対象サーバーのMW_HOMEをホストCにリカバリします。
tar -xf mw_home_backup_032010.tar
管理対象サーバーにOracle Portal、Oracle Reports、Oracle Forms ServicesまたはOracle Business Intelligence Discovererが含まれており、管理対象サーバーのドメイン・ディレクトリがMiddlewareホームの外部に存在する場合、Middlewareホームに加えてドメインをリストアします。たとえば、次のように指定します。
cd Domain_Home
tar -xf domain_home_backup_032010.tar
手順4に進みます。
手順2に示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。
packユーティリティを使用して、ホストAで実行されている管理サーバーからドメイン・テンプレートjarファイルを作成します。たとえば、次のように指定します。
pack.sh -domain=MW_HOME/user_projects/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/aime1/ms.jar -domain=MW_HOME/user_projects/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
別のドメイン・ホームにリカバリする場合は、unpackコマンドで-app_dirスイッチを使用します。
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
ホストCでノード・マネージャが起動していない場合は、起動します。
java weblogic.WLST wls:/offline> startNodeManager()
WLSTを使用して管理サーバーに接続し、新しいホストで実行されているノード・マネージャを管理サーバーに登録します。
connect('username','password','http://host:port')
nmEnroll('MW_HOME/user_projects/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
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
第17.3.5.6項の説明に従って、Oracle Inventoryを更新します。
第17.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
これで、ホストAで実行されている管理サーバーを使用して、ホストCの管理対象サーバーを起動および停止できます。
Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、管理対象サーバー・ディレクトリをリストアする必要があります。たとえば、ドメインに2つの管理対象サーバーがあり（その1つにOracle SOA Suiteが含まれています）、いずれの管理対象サーバーのディレクトリも管理サーバーと同じディレクトリ構造内には存在しないとします。
同じホストまたは別のホストにリカバリするには、第17.2.6.3項で説明している手順を使用します。
コンポーネント（およびその管理対象サーバー（該当する場合））を含むホストが破損した場合、次の各項目で説明する手順を使用して、ほとんどのコンポーネントを同じホストまたは別のホストにリカバリできます。
コンポーネントによっては追加操作が必要なものがあります。それらは、表17-2で示した項で説明しています。
表17-2 特定コンポーネントのホスト破損の際のリカバリ手順
| コンポーネント | 手順 |
|---|---|
|
Oracle Access Manager |
|
|
Oracle Adaptive Access Manager |
|
|
Oracle BI Discoverer |
|
|
Oracle BI Enterprise Edition |
|
|
Oracle BI Publisher |
|
|
Oracle Business Process Management |
ホストの破損については、追加手順は必要ありません。Oracle Business Process Managementのリカバリの詳細は、第17.2.7.7項を参照してください。 |
|
Oracle Data Integrator |
|
|
Oracle Directory Integration Platform |
|
|
Oracle Forms Services |
|
|
Oracle HTTP Server |
|
|
Oracle Identity Federation |
|
|
Oracle Identity Manager |
|
|
Oracle Identity Navigator |
|
|
Oracle Imaging and Process Management |
ホストの破損については、追加手順は必要ありません。Oracle Imaging and Process Managementのリカバリの詳細は、第17.2.7.13項を参照してください。 |
|
Oracle Information Rights Management |
ホストの破損については、追加手順は必要ありません。Oracle Information Rights Managementのリカバリの詳細は、第17.2.7.12項を参照してください。 |
|
Oracle Internet Directory |
|
|
Oracle Portal |
|
|
Oracle Real-Time Decisions |
|
|
Oracle Reports |
|
|
Oracle SOA Suite |
同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする手順の詳細は、第17.3.4.6項を参照してください。 |
|
Oracle Universal Content Management |
|
|
Oracle Universal Records Management |
|
|
Oracle Virtual Directory |
|
|
Oracle Web Cache |
|
Oracle SOA SuiteなどのJavaコンポーネントをリカバリする手順は次のとおりです。
第17.2.6.1項の説明に従って、管理対象サーバーをリカバリします。
表17-2に示すように、コンポーネントに追加手順が必要な場合は、それらの手順を実行します。
Oracle SOA SuiteなどのJavaコンポーネントをリカバリする手順は次のとおりです。
第17.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第17.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
ただし、表17-2に示すように、一部のコンポーネントでは追加手順が必要です。
Oracle HTTP Serverなどのシステム・コンポーネントをリカバリするには、次の一般的な手順に従います。ただし、表17-2に示すように、一部のコンポーネントでは追加手順が必要です。
関連するすべてのプロセスを停止します。つまり、このコンポーネントに関連するすべてのプロセスを停止します。たとえば、Oracle HTTP Serverを停止するには、次のコマンドを使用します。
opmnctl stopproc ias-component=component_name
コンポーネントの停止方法の詳細は、第4.3項を参照してください。
バックアップからコンポーネント固有のファイルをリカバリします。第15.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 -adminPassword password -wlserverHome wlserver_home_location
ファイル・システムのみをリカバリする場合は、Oracleインスタンスを登録する必要はありません。
第4.3項の説明に従って、関連するすべてのプロセスを起動します。
Oracle HTTP Serverなどのシステム・コンポーネントをリカバリするには、次の一般的な手順に従います。ただし、表17-2に示すように、ほとんどのコンポーネントでは追加手順が必要です。
第17.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 -Port nonSSLPort -componentName ovd1 -componentType OVD
第17.3.5.2項の説明に従って、Fusion Middleware Controlのtargets.xmlファイルを編集します。
ほとんどのアイデンティティ管理コンポーネントでは、第17.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
一部のコンポーネントでは、次の各項で説明しているように、別のホストへのリカバリに追加手順が必要です。
別のホストにOracle Internet Directoryをリカバリする手順は次のとおりです。
第17.3.4.4項の説明に従って、コンポーネントをリカバリします。
UNIXシステムおよびLinuxシステムでは、Oracle Internet Directoryの起動を試行する前に、次のファイルを、root権限を持つように設定します。
ORACLE_HOME/bin/oidldapd
たとえば、次のように指定します。
chown root oidldapd chmod 4710 oidldapd
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
Oracle Directory Services Managerがデプロイされている管理対象サーバーを別のサーバーに移動し、SSLを有効にする場合は、新しいホスト上の次のファイルを削除する必要があります。
DOMAIN_HOME/servers/wls_ods1/tmp/_WL_user/odsm_11.1.1.1.0/randomid/war/conf/odsm.cer
Oracle Directory Services Managerでは、このファイルがキーストアおよびトラスト・ストアとして使用され、パスワードがJKSに格納されます。ただし、Oracle Directory Services Managerが別のホストにコピーされ、起動された場合は、別のパスワードが生成されます。このファイルを削除すると、Oracle Directory Services Managerの起動時に、新しいパスワードとともに新しいファイルが作成されます。
別のホストにOracle Virtual Directoryをリカバリする手順は次のとおりです。
第17.3.4.4項の説明に従って、コンポーネントをリカバリします。
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
別のホストにOracle Directory Integration Platformをリカバリする手順は次のとおりです。
第17.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 -adminPassword 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をリカバリする手順は次のとおりです。
第17.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
更新されたデータをリモート・パートナに提供します。
Fusion Middleware Controlを使用して、ホスト名を変更します。
ナビゲーション・ペインで、ファームを開いてから、「Identity and Access」を開きます。
Oracle Identity Federationインスタンスを選択します。
「Oracle Identity Federation」メニューで、「管理」→「サーバー・プロパティ」を選択します。
「サーバー・プロパティ」ページが表示されます。
「ホスト」で、以前のホスト名を新しいホスト名に置き換えます。
ポート番号が変更されている場合は、「ポート」のポート番号を置き換えます。
SOAPポート番号が変更されている場合は、「SOAPポート」のポート番号を置き換えます。
「適用」をクリックします。
Oracle Identity Federationのデプロイ先の管理対象サーバーを再起動します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Oracle Identity FederationがSSLサーバーとして機能している場合は、Oracle Identity Federationからクライアントに示されているSSL証明書を、新しいホスト名を持つ新しい証明書に置き換える必要があります。そうしないと、クライアントによるホスト名の検証が失敗する場合があります。
別のホストにOracle Identity Managerをリカバリする手順は次のとおりです。
第17.3.2項の説明に従って、ドメインをリストアします。
第17.2.3項の説明に従って、Oracleホームをリストアします。
必要に応じて、OIM、OID、MDSおよびSOAINFRAスキーマが含まれるデータベースをリストアします。第17.2.10項を参照してください。
Oracle Identity ManagerデータベースとLDAPプロバイダを同期します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』を参照してください。
weblogicExportMetadata.shスクリプトを使用して、oim-config.xmlファイルをエクスポートします。SOA URLのホスト名またはIPアドレスを変更することによって、エクスポートしたファイルを編集します。weblogicImportMetadata.shスクリプトを使用して、このファイルをMDSにインポートします。
第17.3.5.4項の説明に従って、新しいホスト名で新しいマシンを作成します。
第17.3.5.5項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストにOracle Identity Navigatorをリカバリする手順は次のとおりです。
第17.3.5.4項の説明に従って、新しいホスト名で新しいマシンを作成します。
第17.3.5.5項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストにOracle Access Managerをリカバリする手順は次のとおりです。
第17.2.7.5項の手順に従います。
WLSエージェントをリストアするには、第17.3.3.2項の説明に従って、管理対象サーバーをリストアします。
Oracle Access Managerコンソールにログインします。
Oracle Access Managerプロキシ・サーバーを選択します。
新しいホスト名を指定して、「ホスト」を変更します。
保護されたページを使用している場合は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドのリモート登録ツールに関する項で説明されているoamregツールを使用して、Oracle Single Sign-OnまたはWebゲートをパートナとしてOracle Access Managerに登録する必要があります。同じマニュアルのOSSOリモート登録リクエストに関する項も参照してください。
第17.3.5.4項の説明に従って、新しいホスト名で新しいマシンを作成します。
Webゲート構成ファイルのobAccessClient.xmlを編集して、Oracle Access Managerサーバーのホスト名を更新します。このファイルは、次のディレクトリにあります。
DOMAIN_HOME/output/agentName/
第17.3.5.5項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
別のホストにOracle Adaptive Access Managerをリカバリする手順は次のとおりです。
第17.2.7.6項の手順に従います。
第17.3.5.4項の説明に従って、新しいホスト名で新しいマシンを作成します。
第17.3.5.5項の説明に従って、WebLogicユーザーを任意のグループに再関連付けします。
Oracle SOA Suiteがドメイン内で構成されており、どの管理対象サーバーもドメイン・ディレクトリを管理サーバーと共有していない場合は、第17.3.3.3項で説明している手順に従ってください。それ以外の場合は、この項の手順に従ってください。
同じホストにOracle SOA Suite管理対象サーバーをリカバリするには、第17.3.3.1項の説明に従って、管理対象サーバーをリカバリします。
ホストの破損後に別のホストにOracle SOA Suite管理対象サーバーをリカバリする手順は次のとおりです。
リカバリを実行する前に、新しいホスト名とポートを指すようにWSDLファイルを更新します。
第17.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」→「oaInfraConfig」を開きます。「soa-infra」を選択します。
「属性」タブで、「ServerURL」をクリックします。ServerURL属性に値が含まれている場合は、ホスト名を新しいホスト名に変更します。
「適用」をクリックします。
WSDLファイルが新しいホスト名に更新されたアプリケーションをすべて再デプロイします。
|
注意: 環境にロード・バランサが構成されておらず、Oracle SOA Suiteを別のホストにリカバリする必要がある場合、タスク・フローからのレスポンスおよび非同期レスポンスを保留している進行中のインスタンスはリカバリされません。ロード・バランサを使用して、別のホストにリカバリできるようにすることをお薦めします。 |
環境にロード・バランサが構成されている場合は、次の追加手順を実行します。
Oracle WebLogic Server管理サーバーにログインします。
ドメイン構造で、「サーバー」にナビゲートします。管理対象サーバーごとに「プロトコル」タブ→「HTTP」タブを選択します。
「フロントエンド・ホスト」に、新しいホスト名を入力します。
「フロントエンドHTTPポート」および「フロントエンドHTTPSポート」（該当する場合）に、新しいポート番号を入力します。
管理対象サーバーをそれぞれ再起動します。
Web層は、Oracle HTTP ServerとOracle Web Cacheで構成されています。次の各項目で、これらのコンポーネントをリカバリする方法について説明します。
別のホストにOracle HTTP Serverをリカバリする手順は次のとおりです。
第17.3.4.4項の説明に従って、コンポーネントをリカバリします。
第17.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 Web Cacheをリカバリする手順は次のとおりです。
第17.3.4.4項の説明に従って、コンポーネントをリカバリします。
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
webcache.xmlファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。このファイルは、次のディレクトリにあります。
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
次の各項目で、これらのコンポーネントを別のホストにリカバリする方法について説明します。
別のホストにOracle Portalをリカバリする手順は次のとおりです。
Middlewareホーム、ドメイン・ディレクトリおよびOracleインスタンス・ディレクトリを新しいホストにリストアします。詳細は、第17.3.3.2項を参照してください。
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
Oracleインスタンスが登録解除されている場合は、新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword 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をリカバリする手順は次のとおりです。
第17.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword 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をリカバリする手順は次のとおりです。
第17.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword 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
次のファイルで、ホスト名を新しいホスト名に置き換えます。
ORACLE_INSTANCE/EMAGENT/emagent_<instanceName>/sysman/emd/targets.xml
次のような文字列で始まる要素内のホスト名を変更します。
<Target TYPE="oracle_repapp" ..> <Target TYPE="oracle_repserv" ..>
別のホストにOracle Business Intelligence Discovererをリカバリする手順は次のとおりです。
第17.3.3.2項の説明に従って、管理対象サーバーをリカバリします。
第17.3.5.3項の説明に従って、Oracle Management Agentをリカバリします。
新しいホストでopmnctl registerinstanceコマンドを使用して、Oracleインスタンスをそのすべてのコンポーネントとともに、管理サーバーに登録します。たとえば、次のように指定します。
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword 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 Enterprise Editionを別のホストにリカバリできますが、新しいホストの名前は元のホストと同じである必要があります。
|
注意: Oracle BI EE、またはOracle BI EEと同じ場所にあるその他のコンポーネントを、新しいホスト名の新しいホストにリカバリすることはできません。Oracle BI EEとその他のコンポーネントは、元のホストと同じ名前の新しいホストにのみリカバリできます。たとえば、Oracle BI EEがOracle Real-Time DecisionsおよびOracle Business Intelligence Publisherと同じ場所にある場合、いずれのコンポーネントも別の名前の新しいホストにリカバリすることはできません。 |
次の各項目で、Oracle BI EEを同じ名前の別のホストに移動する方法について説明します。
非クラスタ環境で、元のホストと同じ名前の別のホストにOracle BI EEをリカバリするには、次の手順に従います。
別のホストにOracle BI EEをリカバリする手順は、オペレーティング・システムによって異なります。
UNIXでは、元のホストと同じ名前の別のホストにOracle BI EEをリカバリするには、第17.2.1項の説明に従って、Middlewareホームをリストアします。
Windowsでは、次の手順に従います。
Windowsでは、Oracle BI EEは、Microsoftによって提供されているC++ファイルをMiddlewareホームの外部の場所にインストールするため、Oracle BI EEの新たなインストールを実行する必要があります。エンタープライズ・インストールを実行します。
第17.2.1項の説明に従って、Middlewareホームをバックアップからリストアし、作成したMiddlewareホームを新しいインストールで上書きします。
Fusion Middleware ControlのOracle BI EEページで、新しいホストで実行するコンポーネント・インスタンスを選択します。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのFusion Middleware Controlを使用したシステム・コンポーネントのスケールに関する項を参照してください。
詳細な構成オプションを再適用します。Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのFusion Middleware Controlを使用したOracle Business Intelligence構成設定の更新に関する項を参照してください。
別のホストにOracle Business Intelligence Publisherをリカバリする手順は次のとおりです。
第17.3.3項の説明に従って、Oracle Business Intelligence Publisherコンポーネントが含まれる管理対象サーバーをリカバリします。
必要に応じて、Oracle Business Intelligence Publisherスキーマが含まれるデータベースをリストアします。第17.2.10項を参照してください。
バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。
別のホストにOracle Real-Time Decisionsをリカバリする手順は次のとおりです。
第17.3.3項の説明に従って、Oracle Real-Time Decisionsコンポーネントが含まれる管理対象サーバーをリカバリします。
バックアップ・アーティファクトが別の時点からリストアされると、分析モデルで学習期間が失われますが、インテリジェント機能には影響しません。
別のホストにOracle Data Integratorをリカバリする手順は次のとおりです。
データベースを別のホストにリストアする必要がある場合は、第17.3.6項の説明に従って、データベースをリストアします。
第17.2.3項の説明に従って、バックアップからOracle Data IntegratorのOracleホームをリカバリします。
第17.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 Universal Content ManagementおよびOracle Universal Records Managementを別のホストにリカバリする方法について説明します。
別のホストにOracle Universal Content Managementをリカバリする手順は次のとおりです。
データベースを別のホストにリストアする必要がある場合は、第17.3.6項の説明に従って、データベースをリストアします。
第17.3.2項の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
cd /net/home/vault tar -xf vault_backup_032010.tar
次のファイルを編集します。
DOMAIN_HOME/ucm_domain/ucm/cs/config/config.cfg
このファイルで、新しいホストを指定するようにHttpServerAddressの設定を変更します。たとえば、次のように指定します。
HttpServerAddress=hostname:port_number
データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。
Oracle Universal Records Managementは、Oracle Universal Content Managementに依存しており、追加でバックアップまたはリカバリするアーティファクトがないため、Oracle Universal Content Managementのリカバリ手順（第17.3.4.13.1項）を参照してください。
リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち1つ以上を実行する必要がある場合があります。そのような場合は、エンティティをリカバリする方法を説明している項に明記されています。
次の各項目で、実行することが必要な可能性のある操作について説明します。
別のホストにFusion Middleware Controlをリカバリするには、次の手順に従います。
次のファイル内のホスト名を更新します。
DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/em/hsz5x1/META-INF/emoms.properties
このファイルで、次のプロパティのホスト名を変更します。
mas.conn.url oracle.sysman.emSDK.svlt.ConsoleServerHost
次のファイルを編集します。
(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/
別のホストにコンポーネントをリカバリする場合、Fusion Middleware Controlのtargets.xmlファイルを更新する必要があります。このファイルは次の場所にあります。
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) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/emd/targets.xml (Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\emd\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
次のエントリを更新して、ホスト名を置き換えます。
EMD_URL=http://newhost.domain.com:port/emd/main
次のコマンドを使用して、Oracle Management Agentを起動します。
opmnctl startproc ias-component=EMAGENT
管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
管理サーバーを起動すると、Fusion Middleware Controlも起動されます。
次のアイデンティティ管理コンポーネント（およびリスニング・アドレスを使用している場合は管理サーバー）の場合、管理サーバーを起動する前に、新しいホスト名で新しいマシンを作成する必要があります。
Oracle Access Manager
Oracle Adaptive Access Manager
Oracle Identity Manager
Oracle Identity Navigator
次の手順に従います。
新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。
wls:/offline>readDomain('DomainHome')
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('DomainHome')
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()
次のアイデンティティ管理コンポーネントのバックアップをリストアすると、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上で別のホストにコンポーネントをリカバリするときは、ホストの破損の場合と同様に、次のWindowsレジストリ・キーをリカバリする必要があります。
HKEY_LOCAL_MACHINE\Software\oracle
また、Oracle Web Cacheなどのシステム・コンポーネントをリカバリするときは、次のWindowsレジストリキーをリカバリする必要があります。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。次のリンクから入手可能です。
http://www.oracle.com/technology/documentation/database.html
