| Oracle® Fusion Middleware Oracle Fusion Middlewareの管理 12c (12.1.2) E47968-02 |
|
 前 |
 次 |
この章では、Oracle Fusion Middlewareを様々なタイプの障害および停止(メディア障害またはホストの破損など)からリカバリするための推奨されるリカバリ戦略および手順について説明します。
この章の内容は次のとおりです。
この項では、ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害またはメディア障害などが関係する停止に対するリカバリ戦略の概要を示します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。
|
注意: この章に記載されている手順では、最後のバックアップ以降、管理上の変更は加えられていないことを前提としています。最後のバックアップ以降、管理上の変更が加えられている場合は、リカバリの完了後にそれらの変更を再適用する必要があります。 |
ファイルのリストア時に圧縮ファイルを解凍するには、第16.4項の説明に従って、それに適したツールを使用します。
使用しているツールが、ファイルの権限とタイムスタンプを保持することを確認してください。
必要なファイルを間違ってオーバーライドしないよう、バックアップからファイルをリストアする前に既存のファイルおよびディレクトリの名前を変更してください。
環境をリカバリする場合は、正しい順序でエンティティをリカバリすることが重要です。
Oracleホーム(リカバリが必要な場合)。第18.2.1項を参照してください。
ドメイン全体(リカバリが必要な場合)。WebLogic Server管理対象ドメインのリカバリの詳細は、第18.2.2項および第18.3.1項を参照してください。スタンドアロン・ドメインのリカバリの詳細は、第18.2.3項を参照してください。
管理対象サーバー(管理対象サーバーが管理サーバードメイン・ディレクトリになく、リカバリが必要な場合)。18.2.5項および18.3.4項を参照してください。
Javaコンポーネントは、管理対象サーバーをリカバリする際にリカバリされます。システム・コンポーネントは、ドメインをリカバリする際にリカバリされます。
ただし、ホストが破損している場合は、コンポーネントのリカバリに追加の手順が必要です。第18.3.5項を参照してください。
アプリケーション(リカバリが必要な場合)。第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_042013.tar (Windows) jar xf oracle_home_backup_042013.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_042013.tar (Windows) jar xf domain_backup_042013.jar
関連するプロセスをすべて起動します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを開始します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
Oracle HTTP Serverなどのシステム・コンポーネントの開始の詳細は、第4.3.2項を参照してください。
管理サーバーを起動できない場合は、第18.2.4項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、第18.2.5項の説明に従って、管理対象サーバーをリカバリします。
ファイル・システムから削除されたり、破損した、Oracle HTTP Serverなどのシステム・コンポーネントが含まれているスタンドアロン・ドメインをリカバリできます。
スタンドアロン・ドメインをリカバリするには、次の手順に従います。
第4.2.2項の説明に従って、ノード・マネージャを停止します。
ドメイン・ホームをリカバリします。
(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項の説明に従って、管理サーバーをリカバリします。
管理サーバーが起動しない場合、必要に応じて、Oracleホームをバックアップからリカバリします。次に例を示します。
tar -xf oracle_home_backup_042013.tar
第4.2.2項の説明に従って、ノード・マネージャを停止します。
ファイル・システムが損失した場合、次の手順を実行します。
管理サーバーのホストでpackユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。次に例を示します。
pack.sh -domain=/scratch/oracle/config/domains/domain_name -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
管理対象サーバーのホストでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。次の例では、temp.jarはpackコマンドにより作成されたアーカイブです。
unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info
|
注意:
|
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
ステージング、ステージングなし、または外部ステージング・モードの詳細は、『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
必要に応じて、Oracleホームをバックアップからリカバリします。
tar -xf oracle_home_backup_042013.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
|
注意:
|
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
管理対象サーバーを再起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Oracle WebLogic ServerやOracle HTTP Serverなどのコンポーネントの場合は、次の各トピックの手順を使用してコンポーネントをリカバリします。
コンポーネントのファイルが削除されたり破損した場合、またはコンポーネントの構成が変更されコミットされたためにコンポーネントが起動できないまたは適切に機能しない場合、コンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
クラスタ・レベルで構成が変更されコミットされたために、クラスタ内のコンポーネントが適切に機能しないまたは起動できない場合、それらのコンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
コンポーネントをリカバリする手順は次のとおりです。
WLST停止コマンドを使用してクラスタを停止します。
shutdown('cluster_name','Cluster')
管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。
DOMAIN_HOME/config
管理サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startWebLogic.sh
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTのstartコマンドを次のように使用します。
start('cluster_name', 'Cluster')
最新の構成が管理サーバーからクラスタのすべてのメンバーに取得されます。
次の各項目で、クラスタをリカバリする方法について説明します。
このシナリオでは、クラスタが間違って削除されたり、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
クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。
start('cluster_name', 'Cluster')
クラスタのメンバーシップを誤って変更した場合に、クラスタをリカバリできます。たとえば、クラスタからメンバーを誤って削除した場合、メンバーをクラスタにリストアできます。
|
注意: ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。 |
クラスタのメンバーシップをリカバリする手順は次のとおりです。
管理対象サーバーや管理サーバーなど、すべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
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')
これで、削除されたメンバーがクラスタの一部となります。
クラスタのすべてのメンバーを起動します(起動していない場合)。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
次の各項目で、アプリケーションをリカバリする方法について説明します。
アプリケーションのリカバリについては、次の点に注意してください。
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。
デプロイメント・モードがステージングなしまたは外部ステージングの場合、追加のアプリケーション・アーティファクトが使用可能であることを確認してください。たとえば、アプリケーションがドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
|
関連項目: アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照 |
.earファイルなどのアプリケーションのアーティファクトが損失または破損した場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリする手順は次のとおりです。
アプリケーションのデプロイ先の管理対象サーバーを起動します。次に例を示します。
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
このコマンドを実行すると、構成が管理サーバーと同期されます。
管理対象サーバーが再起動するたびに、構成およびアプリケーション・アーティファクトが管理サーバーから取得されます。
Java EEアプリケーションが管理対象サーバーに再デプロイされ(管理対象サーバーがクラスタの一部であるかどうかは関係ない)、アプリケーションが機能しなくなった場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリする手順は次のとおりです。
必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
バックアップから古いバージョンのアプリケーションを再デプロイします。
元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。
デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合、そのアプリケーションをリカバリできます。
アプリケーションをリカバリする手順は次のとおりです。
必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
バックアップから古いバージョンのアプリケーションを再デプロイします。アプリケーションがクラスタにデプロイされた場合、同じクラスタにアプリケーションを再デプロイします。
元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。
コンポジット・アプリケーションの新規バージョンが管理対象サーバーまたはクラスタに再デプロイされました。このアプリケーションが機能しなくなったとします。
アプリケーションをリカバリする手順は次のとおりです。
必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。
アプリケーションの古いバージョンを再デプロイします。アプリケーションがクラスタにデプロイされた場合、同じクラスタにアプリケーションを再デプロイします。
MDSリポジトリなどのメタデータ・リポジトリが含まれるデータベースが破損している場合、RMANを使用してそのデータベースをリカバリできます。データベースは、完全リカバリまたは表領域リカバリのいずれかの必要な粒度でリカバリできます。
最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これにより、確実に最新のデータがリカバリされます。次に例を示します。
rman> restore database; rman> recover database;
各コンポーネントで使用されるスキーマについては、『Repository Creation Utilityによるスキーマの作成』を参照してください。
詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項では、Oracle Fusion Middlewareの元の動作環境が損なわれた後、その環境をリカバリする方法について説明します。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。この項の項目は次のとおりです。
|
注意: ホストの破損からリカバリする場合、元のホストで使用していたものと同じパスを使用してファイルをリストアする必要があります。 |
Oracle WebLogic Serverドメインをリカバリする手順は次のとおりです。
ドメイン・ホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。
バックアップからドメイン・ディレクトリをリカバリします。
(UNIX) tar -xf domain_backup_042013.tar (Windows) jar xf domain_backup_042013.jar
関連するプロセスをすべて起動します。つまり、このドメインに関連するすべてのプロセスを起動します。たとえば、管理サーバーを起動します。
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーを起動できない場合は、第18.3.3項の説明に従って、管理サーバーをリカバリします。
管理対象サーバーを起動できない場合は、第18.3.4項の説明に従って、管理対象サーバーをリカバリします。
スタンドアロンドメインを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。
このシナリオでは、オペレーティング・システムの再インストール後に、スタンドアロン・ドメインを同じホストにリカバリします。
スタンドアロン・ドメインを同じホストにリカバリするには、次の手順に従います。
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
このシナリオでは、スタンドアロン・ドメインを別のホストにリカバリします。
スタンドアロン・ドメインを別のホストにリカバリするには、次の手順に従います。
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
スタンドアロン・ドメインでは、デフォルトで、ノード・マネージャはローカル・ホストでリスニングします。ただし、そうではない場合、次のWLSTコマンドを使用してListenAddressを更新できます。
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
ノード・マネージャを起動します。
(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で次の手順を実行します。
関連するプロセスをすべて停止します。つまり、管理サーバーや管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
必要に応じて、Oracleホームをリカバリします。
tar -xf oracle_home_backup_042013.tar
ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。まず、ドメイン・ホームの親にするディレクトリに変更します。
tar -xf domain_backup_042013.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_042013.tar
ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。まず、ドメイン・ホームの親にするディレクトリに変更します。
tar -xf domain_backup_042013.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')
ノード・マネージャのプロパティ・ファイルを編集して、リスニング・アドレス・プロパティを変更します。ドメインベースのノード・マネージャの場合、ファイルは次の場所にあります。
DOMAIN_HOME/nodemanager/nodemanager.properties
または、次のWLSTコマンドを使用してプロパティを変更できます。
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',port_num)
元のホストでノード・マネージャが構成されていた場合は、ホスト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_042013.tar
第4.2.2項の説明に従って、ノード・マネージャを停止します。
packユーティリティを使用して、ホストAで実行されている管理サーバーのドメイン・テンプレートjarファイルを作成します。次に例を示します。
pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
ホスト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)
ノード・マネージャが起動していない場合は、起動します。
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_042013.tar
新しいホストを指すように、トポロジを再構成します。
バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、第2.3.2項で説明しているようにWebLogic Serverの構成をロックします。
WebLogic Server管理コンソールで、machine_2の構成を、新しいホストを指すように変更します。
管理コンソールの左ペインから、「環境」を展開して「マシン」を選択します。machine_2を選択して、「構成」タブを選択します。次に、「ノード・マネージャ」を選択します。「リスニング・アドレス」をホストCのアドレスに変更します。「保存」をクリックします。
リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。詳細は、Oracle WebLogic Serverのセキュリティの管理のホスト名検証の使用を参照してください。
管理対象サーバーの構成を、新しいホストを指すように変更します。
コンソールの左ペインから、「環境」→「サーバー」を開いて、サーバーの名前を選択します。続いて、サーバーの名前を選択します。「構成」タブ、続いて「一般」タブを選択します。
マシンをmachine_2に変更します。
「リスニング・アドレス」を新しいホストに変更します。リスニング・アドレスが空白に設定されている場合は、それを変更する必要はありません。
「構成の解放」をWebLogic Server管理コンソールでクリックして、Oracle WebLogic Server構成のロックを解除します。
表18-1の説明に従って、必要な手順があればそれを実行します。
第4.2.2項の説明に従って、ノード・マネージャを停止します。
packユーティリティを使用して、ホストAで実行されている管理サーバーからドメイン・テンプレートjarファイルを作成します。次に例を示します。
pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true
-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。
ホストCでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。
unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info
管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。
|
注意:
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。 |
次のWLSTコマンドを使用して、ListenAddressを更新します。
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
ホスト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 HTTP Serverなどのシステム・コンポーネントを別のホストにリカバリするには、次の手順に従います。
システム・コンポーネントがスタンドアロン・ドメインにある場合は、第18.3.2項の説明に従って、ドメインをリカバリします。
システム・コンポーネントがOracle WebLogic Serverドメインにある場合は、第18.3.1項の説明に従って、ドメインをリカバリします。
ただし、表18-1に示すように、ほとんどのコンポーネントでは追加手順が必要です。
Web層はOracle HTTP Serverで構成されています。次の各項目で、これらのコンポーネントを別のホストにリカバリする方法について説明します。
スタンドアロン・ドメインのOracle HTTP Serverをリカバリするには、次の手順に従います。
WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリするには、次の手順に従います。
第18.3.1項の説明に従って、ドメインをリカバリします。
ホストBにあったOracle HTTP Serverインスタンスの構成を変更します。
Fusion Middleware Controlのナビゲーション・ペインで、ドメインを開いてから、「Web層」を開きます。
Oracle HTTP Serverインスタンス(ohs1など)を選択します。
Oracle HTTP Serverのメニューから「管理」を選択し、「ポート構成」を選択します。
表の各ポートでポートを選択し、「編集」をクリックします。「IPアドレス」を変更します。
「任意」を選択した場合、変更を行う必要はありません。
「OK」をクリックします。
Oracle HTTP Serverの各インスタンスについて、mod_wl_ohsワイヤリングを更新します。
Fusion Middleware Controlのナビゲーション・ペインで、ドメインを開いてから、「Web層」を開きます。
Oracle HTTP Serverインスタンス(ohs1など)を選択します。
Oracle HTTP Serverのメニューから「管理」を選択し、「mod_wl_ohs構成」を選択します。
「ロケーション」のセクションで、「自動入力」をクリックします。
WebLogic Serverの有効なエンドポイント位置がすべて表示されます。
「適用」をクリックします。
障害が発生したマシン上ではないOracle HTTP Serverインスタンスに移動し、「起動」をクリックして、そうしたインスタンスをすべて再起動します。
ホストC上の各Oracle HTTP Serverインスタンスに移動し、「起動」をクリックして起動します。
Oracle Data Integratorをリカバリするには、障害に応じて次のトピックのうちの1つまたは両方の手順に従います。
Oracle Data Integratorリポジトリを別のホストにリストアする必要がある場合は、次の手順を実行します。
第18.3.7項の説明に従ってデータベースをリストアします。
ODI Studioを使用して、リストアされたOracle Data Integratorリポジトリに接続します。『Oracle Fusion Middleware 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アプリケーションを再起動します。
リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち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>
管理サーバーにリスニング・アドレスがある場合は、管理サーバーを起動する前に新しいホスト名の新規マシンを作成する必要があります。
次の手順を実行します。
新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。
wls:/offline> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> machine = create('newhostname', 'Machine')
wls:/offline/sampledomain> cd('/Machine/newhostname')
wls:/offline/sampledomain> nm = create('newhostname', 'NodeManager')
wls:/offline/sampledomain> cd('/Machine/newhostname/NodeManager/newhostname')
wls:/offline/sampledomain> set('ListenAddress', 'newhostname')
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。
wls:/offline> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> cd ('/Machine/newhostname')
wls:/offline/sampledomain> machine = cmo
wls:/offline/sampledomain> cd ('/Server/AdminServer')
wls:/offline/sampledomain> set('Machine', machine)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
管理サーバーのリスニング・ポートを設定します。
wls:/offline/sampledomain> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> cd('/Server/AdminServer')
wls:/offline/sampledomain> cmo.setListenPort(8001)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
必要に応じて、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
キーのインポートにはレジストリ・エディタを使用することもできます。詳細は、レジストリ・エディタのヘルプを参照してください。
データベースを含むホストが破損した場合、RMANを使用してリカバリできます。
次に例を示します。
rman> restore database; rman> recover database;
最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これにより、確実に最新のデータがリカバリされます。また、データベースに同じ名前を使用します。次の点に注意してください。
各コンポーネントで使用されるスキーマについては、『Repository Creation Utilityによるスキーマの作成』を参照してください。
データベースのリカバリおよびRMANの使用の詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
