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