| Oracle® Fusion Middleware Oracle Fusion Middlewareの管理 12c (12.2.1) E69938-01 |
|
 前 |
 次 |
この章では、Oracle Fusion Middlewareを様々なタイプの障害および停止(メディア障害またはホストの破損など)からリカバリするための推奨されるリカバリ戦略および手順について説明します。
この章の内容は次のとおりです。
リカバリ戦略により、実データの損失などの重大な障害からのリカバリが可能になります。損失のタイプにもよりますが、次のファイル・タイプのどのような組合せでもリカバリできます。
Oracleソフトウェア・ファイル
構成ファイル
Oracleシステム・ファイル
Windowsレジストリ・キー
アプリケーション・アーティファクト
Oracle Fusion Middleware環境のリカバリは、Oracle Fusion Middlewareがオフラインのときに実行できます。
次の各項目では、リカバリ戦略について説明します。
Oracle Fusion Middleware環境は、部分的にまたは全体をリカバリできます。次のリカバリが可能です。
Oracleホーム
WebLogic Serverドメイン
スタンドアロン・ドメイン
管理サーバー
管理対象サーバー
Oracle SOA SuiteやOracle HTTP Serverなどのコンポーネント
WebLogic Serverクラスタ
デプロイ済アプリケーション
データベース
この項では、ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害またはメディア障害などが関係する停止に対するリカバリ戦略の概要を示します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。
|
注意: この章に記載されている手順では、最後のバックアップ以降、管理上の変更は加えられていないことを前提としています。最後のバックアップ以降、管理上の変更が加えられている場合は、リカバリの完了後にそれらの変更を再適用する必要があります。 |
リカバリに関しては次の重要な点に注意してください。
Oracle Fusion Middleware環境は、リカバリの実行中はオフラインにする必要があります。
必要なファイルを間違ってオーバーライドしないよう、バックアップからファイルをリストアする前に既存の重要なファイルおよびディレクトリの名前を変更してください。
1、2個のファイルのみが消失または破損しているように見える場合もありますが、1、2個のファイルのみをリストアするのではなく、ドメインなど要素全体のディレクトリ構造をリストアする必要があります。そうすることで、リカバリが成功する可能性が高くなります。
ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これは通常、データベースに障害が発生する直前の状態です。
ファイルのリストア時に圧縮ファイルを解凍するには、第16.3項の説明に従って、それに適したツールを使用します。
使用しているツールが、ファイルの権限とタイムスタンプを保持することを確認してください。
環境をリカバリする場合は、正しい順序でエンティティをリカバリすることが重要です。
Oracleホーム(リカバリが必要な場合)。第18.2.1項を参照してください。
ドメイン全体(リカバリが必要な場合)。WebLogic Server管理対象ドメインのリカバリの詳細は、第18.2.2項および第18.3.1項を参照してください。スタンドアロン・ドメインのリカバリの詳細は、第18.2.3項を参照してください。
管理対象サーバー(管理対象サーバーが管理サーバードメイン・ディレクトリになく、リカバリが必要な場合)。18.2.5項および18.3.4項を参照してください。
Javaコンポーネントは、管理対象サーバーをリカバリする際にリカバリされます。システム・コンポーネントは、ドメインをリカバリする際にリカバリされます。一部の環境では、第18.2.6項および第18.3.5項で説明されている特定の手順を実行する必要があります。
コンポーネントによっては追加操作が必要なものがあります。それらは、表18-1で示した項で説明しています。
表18-1 特定のコンポーネントの追加のリカバリ手順
| コンポーネント | データの損失、破損、メディア障害の場合 | ホスト破損の場合 |
|---|---|---|
|
Oracle B2B |
|
|
|
Oracle BI EE |
|
同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.8項を参照してください。 |
|
Oracle Business Intelligence Publisher |
NA |
同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.9項を参照してください。 |
|
Oracle Data Integrator |
NA |
|
|
Oracle Forms Services |
NA |
同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.6項を参照してください。 |
|
Oracle HTTP Server |
NA |
|
|
Oracle Platform Security Services |
|
|
|
Oracle Reports |
NA |
|
|
Oracle SOA Suite |
NA |
同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.4項を参照してください。 |
|
Oracle WebCenter Content |
|
|
|
Oracle WebCenter Content: Records |
Oracle WebCenter Contentをリカバリします。第18.2.6.4項を参照してください。 |
Oracle WebCenter Contentをリカバリします。第18.3.5.11項を参照してください。 |
|
Oracle WebCenter Portalの分析 |
|
|
|
Oracle WebLogic Server |
Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、第18.2.2.1項を参照してください。 |
Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、第18.2.2.1項を参照してください。 |
アプリケーション(リカバリが必要な場合)。第18.2.8項を参照してください。
この項では、ディスクをリストアできないような、実データの損失や破損、またはメディア障害などが関係する停止に対するリカバリ戦略について説明します。適切に機能しなくなったアプリケーションに対するリカバリ戦略についても説明します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。次の項目が含まれます。
|
注意: エンティティは、元のエンティティと同じパスにのみリストアできます。そのパスは、同じホスト上であっても、異なるホスト上であってもかまいません。 |
破損したりファイルが削除されたOracleホームをリカバリできます。
Oracleホームをリカバリする手順は、次のとおりです。
関連するすべてのプロセスを停止します。つまり、管理サーバー、ノード・マネージャ、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracleホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。
バックアップからOracleホーム・ディレクトリをリカバリします。次に例を示します。
(UNIX) tar -xf oracle_home_backup_06052014.tar (Windows) jar xf oracle_home_backup_06052014.jar
関連するプロセスをすべて起動します。つまり、管理サーバーや管理対象サーバーなど、Oracleホームで実行されているすべてのプロセスを開始します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
ファイル・システムから削除されたり破損した場合、またはドメインを含むホストが破損した場合、Oracle WebLogic Serverドメインをリカバリすることができます。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリする手順は次のとおりです。
関連するプロセスが実行中である場合、そのプロセスをすべて停止します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Oracle HTTP Serverなどのシステム・コンポーネントの停止の詳細は、第4.3.2項を参照してください。
ドメイン・ホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。
バックアップからドメイン・ディレクトリをリカバリします。
(UNIX) tar -xf domain_backup_06052014.tar (Windows) jar xf domain_backup_06052014.jar
関連するプロセスをすべて起動します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを開始します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
Oracle HTTP Serverなどのシステム・コンポーネントの開始の詳細は、第4.3.2項を参照してください。
管理サーバーを起動できない場合は、第18.2.4項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、第18.2.5項の説明に従って、管理対象サーバーをリカバリします。
データベース・リース(たとえば、サーバー全体の移行)を使用して、Oracle WebLogic Serverをリカバリする場合は、リース表内の情報を破棄する必要があります。単にリース表を破棄して再作成する場合は、リース表作成スクリプトを実行します。(サーバー全体の移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。)
ファイル・システムから削除されたり破損した場合、またはホストが破損して同じホストにリカバリする必要がある場合、Oracle HTTP Serverなどのシステム・コンポーネントが含まれているスタンドアロン・ドメインをリカバリできます。
スタンドアロン・ドメインをリカバリするには、次の手順に従います。
Oracle HTTP Serverなどのシステム・コンポーネントやノードマネージャが実行中の場合は、停止します。
破損している場合は、Oracleホームをリカバリします。
(UNIX) tar xf oracle_home_backup_05_21_2013.tar (Windows) jar xf oracle_home_backup_05_21_2013.jar
ドメイン・ホームをリカバリします。
(UNIX) tar xf domain_backup_05_21_2013.tar (Windows) jar xf domain_backup_05_21_2013.jar
ノード・マネージャを起動します。
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh (Windows) DOMAIN_HOME\bin\startNodeManager.cmd
ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。
(UNIX) Domain_Home/bin/startComponent.sh ohs1 (Windows) Domain_Home\bin\startComponent.cmd ohs1
ファイルの削除またはファイル・システムの破損が原因で、管理サーバーの構成が失われた場合でも、問題の発生時に管理サーバーのコンソールがすでに起動しているときには、このコンソールは引き続き機能します。管理サーバーがユーザー名やパスワードのプロンプトを表示しないようにするには、第4.2.4項を参照してください。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
管理サーバーの構成をリカバリする手順は次のとおりです。
管理サーバー、管理対象サーバーおよびノード・マネージャが起動している場合はこれらも含めて、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーが正常に起動しており、アクセス可能であることを確認します。
構成が次回変更されるときに、管理サーバーの構成が、管理対象サーバーにプッシュされます。管理対象サーバーが再起動するたびに、管理サーバーから構成が取得されます。
管理対象サーバーのファイルが削除されたり破損した場合、その構成ファイルを含めて、それらのファイルをリカバリできます。
このシナリオでは、管理対象サーバーが管理サーバーと同じホストに存在しておらず、適切に動作しない場合や起動できない場合を想定しています。この原因としては、構成の削除、構成の破損、構成を誤って変更したがその変更内容が不明であることなどが考えられます。
管理対象サーバーをリカバリするには、次の手順に従います。
管理サーバーにアクセスできない場合は、第18.2.4項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーが稼働中である場合は、停止します。次に例を示します。
DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url username password
必要に応じて、Oracleホームをバックアップからリカバリします。次に例を示します。
tar -xf oracle_home_backup_06052014.tar
第4.2.2項の説明に従って、ノード・マネージャを停止します。
管理サーバーのホストでpackユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。次に例を示します。
pack.sh -domain=/scratch/oracle/config/domains/WLS_domain -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
管理対象サーバーのホストでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。次の例では、temp.jarはpackコマンドにより作成されたアーカイブです。
unpack.sh -template=/scratch/temp.jar -domain=/scratch/oracle/config/domains/WLS_domain -log=/scratch/logs/new.log -log_priority=info
|
注意:
|
管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
コンポーネントのファイルが削除されたり破損した場合、またはコンポーネントの構成が変更されコミットされたためにコンポーネントが起動できないまたは適切に機能しない場合、コンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
Javaコンポーネントでは、第18.2.5項の説明に従って、管理対象サーバーをリカバリします。
Oracle HTTP Serverなどのシステム・コンポーネントがスタンドアロン・ドメインにある場合は、第18.2.3項の説明に従って、ドメインをリカバリします。
Oracle HTTP Serverなどのシステム・コンポーネントがOracle WebLogic Serverドメインにある場合は、第18.2.2項の説明に従って、ドメインをリカバリします。
次の項では、特定のコンポーネントに対して実行する必要がある追加の手順について説明します。
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をリカバリする手順は次のとおりです。
必要に応じて、第18.3.7項の説明に従って、データベースをリストアします。
第18.2.2項の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。
cd /net/home/vault tar -xf vault_backup_042012.tar
データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。
クラスタ化環境でOracle BI EEをリカバリする手順は次のとおりです。
第18.2.6.5.1項の説明に従って、LDAPデータベースとOracle BI EEリポジトリ(RPD)を調整します。
第18.2.6.5.2項の説明に従って、LDAPデータベースとOracle BI Presentation Catalogを調整します。
LDAPデータベースは、Oracle BI EEリポジトリ(RPD)と調整する必要があります。
Oracle BI Enterprise Editionを使用して、同期を実行できます。常に自動同期を有効にすることも一時的に同期を実行することもできます。(NQSConfig.iniファイルの編集の詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のNQSConfig.INIファイルの構成設定に関する項を参照してください。)
同期を有効にする手順は次のとおりです。
次のファイルを編集します。
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI
フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSをyesに設定します。
サーバーを再起動します。LDAPデータベースの情報とRPDが同期化されます。
同期を無効にする手順は次のとおりです。
同期を無効にするには、次のファイルを編集します。
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI
フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSをnoに設定します。
サーバーを再起動します。
Windows上のOracle BI管理ツールには、リポジトリの妥当性をチェックして不整合を修正できるConsistency Check Managerが用意されています。詳細は、『Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ・オブジェクトの一貫性のチェックに関する項を参照してください。
LDAPデータベースがOracle BI Presentation Catalogの背後にあるよりも以前の時点にLDAPデータベースをリストアする場合は、次のコマンドを使用してLDAPデータベースとOracle BI Presentation Catalogを調整します。
runcat.cmd -cmd forgetAccounts
runcatコマンドの詳細は、次のようにヘルプを参照してください。
./runcat.sh -cmd maintenanceMode -help
次の状況では、クラスタをリカバリする必要があります。
クラスタが誤って削除され、クラスタ・メンバーが誤って削除されている。
JMS構成またはコンテナレベルのデータ・ソースなどのクラスタレベルの構成が誤って変更されコミットされている。コンポーネントまたはサーバーは起動できないか、または適切に動作せず、サーバー内で実行中のサービスは起動されていません。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
構成の変更が少ない場合、最も簡単な方法は、構成の変更を再実行することです。この方法を実行できない場合は、次の手順に従って構成をリカバリします。
クラスタを停止します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
shutdown('cluster_name', 'Cluster')
管理サーバーや管理対象サーバーなど、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
削除されたメンバーがすべてクラスタに戻ります。
管理対象サーバーなど、すべてのプロセスを起動します。たとえば、Linux上で管理対象サーバーを起動するには、次のスクリプトを使用します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
start('cluster_name', 'Cluster')
次の各項目で、アプリケーションをリカバリする方法について説明します。
アプリケーションのリカバリについては、次の点に注意してください。
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
デプロイメント・モードがステージングなしまたは外部ステージングの場合、追加のアプリケーション・アーティファクトが使用可能であることを確認してください。たとえば、アプリケーションがドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
.earファイルなどのアプリケーションのアーティファクトが損失または破損した場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリする手順は次のとおりです。
アプリケーションのデプロイ先の管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
このコマンドを実行すると、構成が管理サーバーと同期されます。
管理対象サーバーが再起動するたびに、構成およびアプリケーション・アーティファクトが管理サーバーから取得されます。
次の場合、Java EEアプリケーションをリカバリできます。
Java EEアプリケーションが管理対象サーバーに再デプロイされ(管理対象サーバーがクラスタの一部であるかどうかは関係ない)、アプリケーションが機能しなくなった場合。
デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合。
コンポジット・アプリケーションの新規バージョンが管理対象サーバーまたはクラスタに再デプロイされました。このアプリケーションが機能しなくなったとします。
アプリケーションをリカバリする手順は次のとおりです。
必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
バックアップから古いバージョンのアプリケーションを再デプロイします。
元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。
MDSリポジトリなどのメタデータ・リポジトリが含まれるデータベースが破損している場合、RMANを使用してそのデータベースをリカバリできます。データベースは、完全リカバリまたは表領域リカバリのいずれかの必要な粒度でリカバリできます。
最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合。)これにより、確実に最新のデータがリカバリされます。次に例を示します。
rman> restore database; rman> recover database;
各コンポーネントで使用されるスキーマについては、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項では、Oracle Fusion Middlewareの元の動作環境が損なわれた後、その環境をリカバリする方法について説明します。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。この項の項目は次のとおりです。
|
注意: ホストの破損からリカバリする場合、元のホストで使用していたものと同じパスを使用してファイルをリストアする必要があります。 |
ホストの破損後に、Oracle WebLogic Serverドメインをリカバリするには、第18.2.2項の手順に従います。
スタンドアロンドメインを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
オペレーティング・システムの再インストール後に、スタンドアロン・ドメインを同じホストにリカバリするには、第18.2.3項の手順に従います。
このシナリオでは、スタンドアロン・ドメインを別のホストにリカバリします。
スタンドアロン・ドメインを別のホストにリカバリするには、次の手順に従います。
Oracleホームをリカバリします。
(UNIX) tar xf oracle_home_backup_05_21_2014.tar (Windows) jar xf oracle_home_backup_05_21_2014.jar
ドメイン・ホームをリカバリします。
(UNIX) tar xf domain_backup_05_21_2014.tar (Windows) jar xf domain_backup_05_21_2014.jar
スタンドアロン・ドメインでは、デフォルトで、ノード・マネージャはローカル・ホストでリスニングします。ただし、そうではない場合、次のWLSTコマンドを使用してListenAddressを更新できます。
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()
ノード・マネージャを起動します。
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh (Windows) DOMAIN_HOME\bin\startNodeManager.cmd
システム・コンポーネントの構成ファイルをすべて、手動で更新します。
特定コンポーネントの場合の詳細は、第18.3.5項を参照してください。
ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。次に例を示します。
(UNIX) Domain_Home/bin/startComponent.sh ohs1 (Windows) Domain_Home\bin\startComponent.cmd ohs1
第18.3.6.4項の説明に従って、Oracle Inventoryを更新します。
Windowsの場合は、第18.3.6.5項の説明に従ってWindowsレジストリを更新します。
管理サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
このシナリオでは、管理サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。たとえば、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されているとします。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをリカバリする必要があります。
同じホストに管理サーバーをリカバリする手順は次のとおりです。
ファイル・システムをリカバリします。たとえば、第18.3.1項の説明に従って、この管理サーバーが含まれるドメインをリカバリします。
管理サーバーを起動してみます。次に例を示します。
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に移行する必要があります。
別のホストに管理サーバーをリカバリする手順は次のとおりです。
OracleホームをホストC (新規ホスト)にリカバリします。
tar -xf oracle_home_backup_06052014.tar
ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。
tar -xf domain_backup_06052014.tar
管理サーバーにリスニング・アドレスが指定されている場合は、第18.3.6.3項の説明に従って、新しいホスト名で新しいマシンを作成します。
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
WLSTを使用して管理サーバーに接続し、新しいホストで実行されているノード・マネージャを管理サーバーに登録します。
connect('username','password','t3://host:port')
nmEnroll('/scratch/oracle/config/domains/domain_name',
'DOMAIN_HOME/nodemanager')
Windowsの場合は、UNIXの場合と同様に、nmEnrollコマンドではバックスラッシュ(\)ではなくスラッシュ(/)を使用します。
ノード・マネージャのプロパティ・ファイルを編集して、リスニング・アドレス・プロパティを変更します。ドメインベースのノード・マネージャの場合、ファイルは次の場所にあります。
DOMAIN_HOME/nodemanager/nodemanager.properties
または、次のWLSTコマンドを使用してプロパティを変更できます。
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',port_num)
updateDomain()
元のホストでノード・マネージャが構成されていた場合は、ホストCでノード・マネージャを起動します。
cd DOMAIN_HOME/bin
./startNodeManager.sh
管理対象サーバーを起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』の障害が発生した管理サーバーの再起動に関する項では、構成に応じた様々な再起動方法について説明されています。
オプションの1つとして、次のスクリプトの使用があります。このコマンドでは、新しいホストの管理用URLを指定します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
追加のアプリケーション・アーティファクトが使用可能であることを確認します。たとえば、デプロイメント・モードがステージングなしまたは外部ステージングの場合、アプリケーションはドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
第18.3.6.4項の説明に従って、Oracle Inventoryを更新します。
Windowsの場合は、第18.3.6.5項の説明に従って、Windowsレジストリをリカバリします。
環境にOracle HTTP Serverが含まれる場合、第18.3.6.2項の説明に従って、mod_wl_ohs.confファイルを修正します。
これで、ホストCで実行されている管理コンソールを使用して、ホストBの管理対象サーバーを起動および停止できます。
Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、第18.3.6項を参照してください。
管理対象サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
このシナリオでは、管理対象サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。ホスト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
第4.2.2項の説明に従って、ノード・マネージャを停止します。
管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。次に例を示します。
cd Domain_Home
tar -xf domain_home_backup_042012.tar
ステップeに進みます。
管理対象サーバーにOracle Forms ServicesまたはOracle Reportsが含まれない場合、次の手順を実行します。
packユーティリティを使用して、ホストAで実行されている管理サーバーのドメイン・テンプレートjarファイルを作成します。次に例を示します。
pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
ホストBでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。
unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
次のWLSTコマンドを使用して、ノード・マネージャのプロパティListenAddressを更新します。
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()
ノード・マネージャが起動していない場合は、起動します。
cd DOMAIN_HOME/bin
./startNodeManager.sh
管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストCにリカバリする必要があります。1台以上のWebLogic Serversをホストするコンピュータの論理表現である2台のマシン、ホストAのmachine_1およびホストBのmachine_2があります。
|
重要: Oracleホームは元と同じ場所にリカバリしてください。 |
別のホストに管理対象サーバーをリカバリする手順は次のとおりです。
管理対象サーバーのOracleホームをホストCにリカバリします。
tar -xf oracle_home_backup_06052014.tar
新しいホストを指すように、トポロジを再構成します。
バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、第2.2.5項で説明しているようにWebLogic Serverの構成をロックします。
WebLogic Server管理コンソールで、machine_2の構成を、新しいホストを指すように変更します。
管理コンソールの左ペインから、「環境」を展開して「マシン」を選択します。machine_2を選択して、「構成」タブを選択します。次に、「ノード・マネージャ」を選択します。「リスニング・アドレス」をホストCのアドレスに変更します。「保存」をクリックします。
リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のホスト名検証の使用に関する項を参照してください。
管理対象サーバーの構成を、新しいホストを指すように変更します。
コンソールの左ペインから、「環境」→「サーバー」を開いて、サーバーの名前を選択します。続いて、サーバーの名前を選択します。「構成」タブ、続いて「一般」タブを選択します。
マシンをmachine_2に変更します。
「リスニング・アドレス」を新しいホストに変更します。(リスニング・アドレスが空白に設定されている場合は、それを変更する必要はありません。)
「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
「構成の解放」をWebLogic Server管理コンソールでクリックして、Oracle WebLogic Server構成のロックを解除します。
表18-1の説明に従って、必要な手順があればそれを実行します。
第4.2.2項の説明に従って、ノード・マネージャを停止します。
管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。次に例を示します。
cd Domain_Home
tar -xf domain_home_backup_042012.tar
ステップ7に進みます。
ステップ5に示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。
packユーティリティを使用して、ホストAで実行されている管理サーバーからドメイン・テンプレートjarファイルを作成します。次に例を示します。
pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
ホストCでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。
unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info
別のドメイン・ホームにリカバリする場合は、unpackコマンドで-app_dirスイッチを使用します。
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
次のWLSTコマンドを使用して、ListenAddressを更新します。
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()
ホストCでノード・マネージャが起動していない場合は、起動します。
cd DOMAIN_HOME/bin
./startNodeManager.sh
管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。
第18.3.6.4項の説明に従って、Oracle Inventoryを更新します。
Windowsの場合は、第18.3.6.5項の説明に従って、Windowsレジストリをリカバリします。
環境にOracle HTTP Serverが含まれる場合、第18.3.6.2項の説明に従って、mod_wl_ohs.confファイルを修正します。
これで、ホストAで実行されている管理サーバーを使用して、ホストCの管理対象サーバーを起動および停止できます。
コンポーネント(およびその管理対象サーバー(該当する場合))を含むホストが破損した場合、次の各項目で説明する手順を使用して、ほとんどのコンポーネントを同じホストまたは別のホストにリカバリできます。
コンポーネントによっては追加操作が必要なものがあります。それらは、表18-1で示した項で説明しています。
Javaコンポーネントを同じホストにリカバリするには、次の手順に従います。
第18.3.4.1項の説明に従って、管理対象サーバーをリカバリします。
表18-1に示すように、コンポーネントに追加手順が必要な場合は、それらの手順を実行します。
別のホストにJavaコンポーネントをリカバリするには、次の手順を実行します。
第18.3.4.2項の説明に従って、管理対象サーバーをリカバリします。
表18-1に示すように、コンポーネントに追加手順が必要な場合は、それらの手順を実行します。
Oracle HTTP Serverなどのシステム・コンポーネントを同じホストまたは別のホストにリカバリするには、次の手順を実行します。
Oracle HTTP Serverなどのシステム・コンポーネントがスタンドアロン・ドメインにある場合は、第18.3.2項の説明に従って、ドメインをリカバリします。
Oracle HTTP Serverなどのシステム・コンポーネントがOracle WebLogic Serverドメインにある場合は、第18.3.1項の説明に従って、ドメインをリカバリします。
ただし、表18-1に示すように、一部のコンポーネントでは追加手順が必要です。
同じホストにOracle SOA Suite管理対象サーバーをリカバリするには、第18.3.4.1項の説明に従って、管理対象サーバーをリカバリします。
ホストの破損後に別のホストにOracle SOA Suite管理対象サーバーをリカバリする手順は次のとおりです。
リカバリを実行する前に、新しいホスト名とポートを指すようにWSDLファイルを更新します。
第18.3.4.2項の説明に従って、管理対象サーバーをリカバリします。
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を別のホストにリカバリする必要がある場合、タスク・フローからのレスポンスおよび非同期レスポンスを保留している進行中のインスタンスはリカバリされません。ロード・バランサを使用して、別のホストにリカバリできるようにすることをお薦めします。 |
環境にロード・バランサが構成されている場合は、次の追加手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
ドメイン構造で、「クラスタ」にナビゲートします。構成するクラスタを選択し、「構成」タブの下の「HTTP」タブに移動します。
「フロントエンド・ホスト」に、新しいホスト名を入力します。
「フロントエンドHTTPポート」および「フロントエンドHTTPSポート」(該当する場合)に、新しいポート番号を入力します。
管理対象サーバーをそれぞれ再起動します。
Web層はOracle HTTP Serverで構成されています。次の各項目では、別のホストにリカバリする方法について説明します。
スタンドアロン・ドメインのOracle HTTP Serverをリカバリするには、次の手順に従います。
WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリするには、次の手順に従います。
第18.3.1項の説明に従って、ドメインをリカバリします。
ホスト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 Forms Servicesをリカバリする手順は次のとおりです。
第18.3.4.2項の説明に従って、管理対象サーバーをリカバリします。
管理サーバーのホストで、次のファイルを編集します。
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="12.2.1" />
</em-properties>
</ias-component>
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セクションを変更し、ステップ3のファイルのパスが含まれるようにします。
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.4.2項の説明に従って、管理対象サーバーをリカバリします。
次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。
nodemanager.properties。このファイルは次の場所にあります。
(UNIX) DOMAIN_HOME/nodemanager (Windows) DOMAIN_HOME\nodemanager
reports_ohs.conf。このファイルは次の場所にあります。
(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs_name/moduleconf (Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instances\ohs_name\moduleconf
rwservlet.properties。このファイルは次の場所にあります。
(UNIX) DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration (Windows) DOMAIN_HOME\config\fmwconfig\servers\server_name\applications\reports_version\configuration
ファイル内で、<server>要素を変更して、新しいホスト名を使用します。
mbeans.xml。このファイルは次の場所にあります。
(Unix) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF (Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF
Oracle BI EEを別のホストにリカバリできます。
次の各項目で、Oracle BI EEを同じ名前の別のホストに移動する方法について説明します。
Windowsでは、障害が発生したエンティティをリカバリした後、次の追加手順を実行します。
次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
第18.3.5.8.3項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。
このシナリオでは、ホスト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では、第18.3.5.8.3項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。
障害が発生したノードに管理サーバーが含まれている場合、第18.3.3.2項のステップ1 - 4の説明に従ってリカバリします。
『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 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 Business Intelligenceエンタープライズ・デプロイメント・ガイド』のシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項を参照してください。
『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のbi_server2管理対象サーバーのリスニング・アドレスの設定に関する項の説明に従って、bi_servern管理対象サーバーのリスニング・アドレスを設定します。
『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のbi_server2管理対象サーバーのホスト名検証の無効化に関する項の説明に従って、bi_servern管理対象サーバーのホスト名検証を無効にします。
環境に応じて、『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のOracle Business Intelligenceの可用性のための追加構成の実行に関する項の説明に従って、追加構成を実行します。
Oracle HTTP Serverがインストールされている場合は、『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の管理コンソールのフロントエンドURLに関する項の説明に従って、Oracle BI SearchのURLが正しく設定されるようにOracle WebLogic ServerクラスタのフロントエンドHTTPホストおよびポートを設定します。
『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の管理対象サーバーのノード・マネージャの構成に関する項の説明に従って、管理対象サーバーのノード・マネージャを構成します。
Oracle BI EE管理対象サーバーおよびすべてのOPMNの管理対象コンポーネントを起動します。
環境に応じて、前の手順を実行した後に、追加手順を実行する必要がある場合があります。
ホストにマスター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 Business Intelligenceエンタープライズ・デプロイメント・ガイド』のシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項を参照してください。
障害が発生したホストにBIサーバー、セカンダリ・クラスタ・コントローラ、およびセカンダリOracle BIスケジューラが含まれる場合、セカンダリ・クラスタ・コントローラまたはスケジューラとして新しいホストを指定します。
障害が発生したホストにBIサーバーおよびBIプレゼンテーション・サービスやBI Javaホストなどのシステム・コンポーネントが含まれる場合、追加手順は不要です。
障害が発生したホストに次の関連するコンポーネントが含まれる場合、それらをリカバリします。
Oracle Business Intelligence Publisher: 第18.3.5.9項を参照
Oracle Real-Time Decisions。
Windowsでは、Oracle BI EEレジストリ・エントリを新しいホストにインポートする必要があります。第17.3.3項には元のホストからそれらをエクスポートする方法が説明されています。
元のホストからエクスポートされたすべてのファイルを新しいホストにコピーします。
元のホストからコピーした各ファイルをダブルクリックします。入力を求められたら「はい」をクリックして、ファイルをレジストリにインポートします。
障害が発生したエンティティをリカバリした後、次の追加手順を実行します。
Oracle BIプレゼンテーション・サービスに対するサーバー値を変更します。
http://hostname:port/xmlpserverでBI Publisherアプリケーションを開いてログインします。
「管理」→「統合」→「Oracle BIプレゼンテーション・サービス」をクリックします。
「サーバー」を新しいホスト名に変更します。
「適用」をクリックします。
コールド・フェイルオーバー・クラスタ環境で動作するようにOracle BI Publisherを変換するには、BIスケジューラのJMS構成を変更する必要があります。
BI Publisherアプリケーションで、「管理」をクリックします。
システム管理セクションで、スケジューラ構成をクリックします。
「Weblogic JNDI URL」を新しいホストURLに変更します。たとえば、t3://hostname:portと指定します。
「適用」をクリックします。
コールド・フェイルオーバー・クラスタを使用している場合は、仮想IPアドレスをリスニングするように管理対象サーバーを構成します。『高可用性ガイド』のOracle WebLogic管理対象サーバーの変換に関する項を参照してください。次に、管理コンソールまたはWLSTコマンド行を使用して、管理対象サーバーを再起動します。
BI Publisherでは、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更するか、作成する必要があります(新規作成する場合は新しい仮想ホストを使用)。データ・ソースを変更する手順は次のとおりです。
BI Publisherアプリケーションで、次の手順を実行します。
「データ・ソース」の下にある「JDBC接続」をクリックします。
このインスタンスのBI Enterprise Editionのデータ・ソースをすべて編集して、新しいホストに対する値を反映するようにします。
バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。
Oracle Data Integratorをリカバリするには、障害に応じて、次の項目のうちの1つまたは両方の手順に従います。
Oracle Data Integratorリポジトリを別のホストにリストアする必要がある場合は、次の手順を実行します。
第18.3.7項の説明に従ってデータベースをリストアします。
ODI Studioを使用して、リストアされたOracle Data Integratorリポジトリに接続します。Oracle Data Integratorによる統合プロジェクトの開発のマスター・リポジトリへの接続に関する項の説明に従って、新しいデータベース・ホストへのマスター・リポジトリの新しい接続を作成します。
作業リポジトリをそれぞれ編集します。「接続」をクリックして、作業リポジトリが含まれる新しいデータベース・ホストを指すJDBC URLが含まれるように接続情報を編集します。
Oracle WebLogic Server構成内のOracle Data Integrator JEEエージェント・リポジトリ構成の場合は、新しいデータベース・ホストの場所と一致するようデータ・ソースを編集します。
次のWLSTオフライン・コマンドを使用して、Oracle Data Integratorスタンドアロン・エージェント・リポジトリ構成を更新します。
cd ORACLE_HOME/odi/common/bin ./wlst.sh readDomain('DOMAIN_DIRECTORY') cd('/JdbcSystemResource/OdiMasterRepository/JdbcResource/OdiMasterRepository/JDBCDriverParams/NO_NAME_0'); set('URL','NEW_JDBC_URL_TO_RECOVERED_DB'); updateDomain(); exit();
別のホストにOracle Data Integratorエージェントをリカバリする手順は次のとおりです。
第18.3.4項の説明に従って管理対象サーバーをリストアすることによって、Oracle Data Integrator JEEエージェントをリストアします。
第18.3.5項の説明に従って、Oracle Data Integratorスタンドアロン・システム・コンポーネントをリストアします。
ODI Studioを使用して、各物理エージェントの構成を編集し、更新したホスト名の値を指定して、ポートの値を変更した場合はポートの値も指定します。
次のコマンドを使用して、Oracle Data Integratorスタンドアロン・エージェントのホストおよびポート構成を更新します。
cd ORACLE_HOME/odi/common/bin ./wlst.sh readDomain('DOMAIN_HOME') cd('ODI/ODI_STANDALONE_AGENT_NAME') set("ServerListenAddress",'UPDATED_HOST_NAME'); set("ServerListenPort",'UPDATED_PORT'); updateDomain(); exit();
スタンドアロン・エージェント、およびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを再起動します。
別のホストにOracle WebCenter Contentをリカバリする手順は次のとおりです。
データベースを別のホストにリストアする必要がある場合は、第18.3.7項の説明に従って、データベースをリストアします。
第18.3.3項の説明に従って、ドメインをリストアします。
ドメイン・ディレクトリに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を使用して、手動でリカバリを実行できます。
リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち1つ以上を実行する必要がある場合があります。そのような場合は、エンティティをリカバリする方法を説明している項に明記されています。
次の各項目で、実行することが必要な可能性のある操作について説明します。
Fusion Middleware Controlを別のホストにリカバリするには、システムMBeanブラウザを使用してプロパティを更新します。
Fusion Middleware ControlのWebLogicドメイン・メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ペインで「アプリケーション定義のMBean」、「emoms.props」、「サーバー: AdminServer」、「アプリケーション: em」、そして「プロパティ」と展開します。
「emoms.properties」をクリックします。
「属性」ペインで「操作」タブを選択し、「SetProperty」をクリックします。
次のプロパティの値を新しいホスト名に変更します。
oracle.sysman.emSDK.svlt.ConsoleServerHost
oracle.sysman.emSDK.svlt.ConsoleServerName
たとえば、「キー」に「oracle.sysman.emSDK.svlt.ConsoleServerHost」と入力します。次に、値として「host.example.com:7001_Management_Service」と入力します。
「起動」をクリックします。
管理サーバーまたは管理対象サーバーを別のホストにリカバリする場合、環境にOracle HTTP Serverが含まれていると、新しいホスト上で次のファイルを変更する必要があります。
(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_name/mod_wl_ohs.conf (Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\ohs_name\mod_wl_ohs.conf
WebLogic ServerドメインのOracle HTTP Serverの場合、このディレクトリは管理サーバーのドメイン・ホームであることに気を付けてください。スタンドアロン・ドメインのOracle HTTP Serverでは、このディレクトリはOracle HTTP Serverのドメイン・ホームです。
そのファイルで、ホスト名、ポート、およびクラスタのエントリのすべてのインスタンス(WebLogicHost、WebLogicPort、WebLogicClusterなどの要素)を変更します。次に例を示します。
<Location /console>
SetHandler weblogic-handler
WebLogicHost Admin_Host
WeblogicPort Admin_Port
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
.
.
.
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8001,*SOAHOST2VHN1*:*8001*
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
管理サーバーにリスニング・アドレスがある場合は、管理サーバーを起動する前に新しいホスト名の新規マシンを作成する必要があります。
次の手順を実行します。
新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。
readDomain('DOMAIN_HOME')
machine = create('newhostname', 'Machine')
cd('/Machine/newhostname')
nm = create('newhostname', 'NodeManager')
cd('/Machine/newhostname/NodeManager/newhostname')
set('ListenAddress', 'newhostname')
updateDomain()
管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。
readDomain('DOMAIN_HOME')
cd ('/Machine/newhostname')
machine = cmo
cd ('/Server/AdminServer')
set('Machine', machine)
updateDomain()
WLSTを使用して、管理サーバーのリスニング・ポートを設定します。
readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.setListenPort(8001)
updateDomain()
必要に応じて、WLSTを使用して管理サーバーのアドレス・リスニングを更新します。
readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.getListenAddress()
cmo.setListenAddress('newhostname')
updateDomain()
exit()
多くのコンポーネントで、別のホストにリカバリするときは、ホストの破損の場合と同様に、Oracleインベントリを更新する必要があります。そのためには、次のスクリプトを実行します。
(UNIX) ORACLE_HOME/oui/bin/attachHome.sh (Windows) ORACLE_HOME\oui\bin\attachHome.cmd
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
キーのインポートにはレジストリ・エディタを使用することもできます。詳細は、レジストリ・エディタのヘルプを参照してください。
データベースのリカバリの詳細は、第18.2.9項を参照してください。
