Oracle Application Server 管理者ガイド 10gリリース3(10.1.3.1.0) B31834-01 |
|
この章では、Oracle Application Serverのリカバリ計画および手順について、障害および停止のタイプ別に説明します。
この章の項目は次のとおりです。
この項では、様々な障害および停止のタイプ別に、Oracle Application Serverのリカバリ計画について説明します。この項の項目は次のとおりです。
この項では、ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害、またはメディア障害などが関係する停止に対するリカバリ計画について説明します。このタイプの障害では、Oracle Application Server環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。
この項で説明する計画では、中間層のPoint-in-Timeリカバリを使用します。
この項で説明するリカバリ計画には、次の前提を適用します。
表18-1に、リカバリ計画を示します。
中間層インストールでデータの損失、ホスト障害またはメディア障害が発生した場合は、この表の情報を参照します。該当する損失のタイプを検索し、推奨される手順を実行してください。
損失のタイプ | リカバリ計画 |
---|---|
ホストの破損 |
ホストが破損した場合、次の2つのオプションがあります。 いずれの場合も、第18.2.2項「新しいホストへの中間層インストールのリストア」の手順に従います。 元のホストに中間層インストールとInfrastructureがある場合、別のホスト名またはIPアドレスを持つホストに中間層をリストアすることはできません。 |
Oracleソフトウェア/バイナリの削除または破損 |
Oracleバイナリで損失または破損が発生した場合、中間層全体を同じホストにリストアする必要があります。 第18.2.1項「同じホストへの中間層インストールのリストア」の手順に従います。 |
構成ファイルの削除および破損 |
中間層のOracleホームにある構成ファイルのいずれかを損失した場合、それらをリストアできます。 第18.2.3項「中間層の構成ファイルのリストア」の手順に従います。 |
この項では、プロセスの障害およびシステムの停止に対するリカバリ計画について説明します。このタイプの停止にはデータの損失は含まれないため、ファイルをリカバリする必要はありません。一部のケースでは、障害が透過的であるため、障害が発生したコンポーネントのリカバリに手動で介入する必要がない場合もあります。ただし、プロセスまたはコンポーネントの再起動に、手動による介入が必要な場合もあります。これらの計画は、バックアップおよびリカバリのカテゴリには厳密には一致しませんが、万全を期すためこのマニュアルに含まれています。
表18-2に、プロセスの障害およびシステムの停止に対するリカバリ計画を示します。
中間層インストールで障害または停止が発生した場合は、この表を参照します。該当する停止のタイプを検索し、推奨される手順を実行してください。この表に記載しているのはUNIXのコマンドです。Windowsではスラッシュを「¥」と読み替えると、同じコマンドを使用できます。
停止のタイプ | ステータス確認と再起動の方法 |
---|---|
ホストの障害(データの損失なし) |
再起動するには:
|
Application Server Controlコンソールの障害 |
ステータスを確認するには: opmnctl status 再起動するには: opmnctl startproc process-type=OC4J_instance_name |
Oracle HTTP Serverプロセスの障害 |
ステータスを確認するには: opmnctl status 再起動するには: opmnctl startproc ias-component=HTTP_Server |
OC4Jインスタンスの障害 |
ステータスを確認するには: opmnctl status 再起動するには: opmnctl startproc process-type=OC4J_instance_name |
OPMNデーモンの障害 |
ステータスを確認するには: opmnctl status 再起動するには: opmnctl start |
この項では、様々なタイプのリカバリを実行するための手順について説明します。
この項の項目は次のとおりです。
同じホストに中間層インストールをリストアするには、第17.3.4項「同じホストのインスタンスのリカバリ」を参照してください。
この項では、新しいホストに中間層インストールをリストアおよびリカバリする方法について説明します。この手順を使用して、次のことを実行できます。
第17.3.3項「新しいホストでのノードのリストア」の手順を実行して、イメージのバックアップ、システム・ファイルおよびインスタンスの再構成をリストアします。中間層の構成は、元のインスタンスの状態と同じままです。ホスト名が同じままの場合、インスタンスのリストアを実行し、目的の時点のインスタンスに戻します。ホスト名が異なる場合、元のホストのバックアップは別のホスト名が有効でないので、状態を変更できません。
この項では、中間層のOracleホーム内の構成ファイルをリストアする方法について説明します。構成ファイルの損失または破損が発生した場合は、この手順を使用します。
この項は、次の作業で構成されています。
手順の詳細は、第3.2.2項「中間層インスタンスの停止」を参照してください。
最新のバックアップからすべての構成ファイルをリストアします。この作業は、独自の手順またはOracleAS Recovery Managerを使用して実行できます。たとえば、OracleAS Recovery Managerを使用して次のコマンドを実行します。
bkp_restore.sh -m restore_config -t timestamp
bkp_restore.bat -m restore_config -t timestamp
最後のオンライン・バックアップ以降、管理上の変更を加えた場合は、この時点でそれらの変更を再適用します。
手順の詳細は、第3.2.1項「中間層インスタンスの起動」を参照してください。
次のコマンドを使用して、Oracle Application Serverインスタンスを特定の時点の状態にリストアします。
bkp_restore.sh -m restore_instance -t 2006-09-21_06-12-45 bkp_restore.bat -m restore_instance -t 2006-09-21_06-12-45
クラスタ内のインスタンスでリストア操作(restore_instance
またはrestore_config
)を実行する前に、クラスタ全体のすべてのOC4Jプロセスを停止する必要があります。次のコマンドを使用してプロセスを停止します。
ORACLE_HOME/opmn/bin/opmnctl @cluster
stopproc ias-component=OC4J
一部のOC4Jコンポーネントにはias-component=OC4J
がありません。このようなコンポーネントについては、uniqueid値を使用してOC4Jプロセスを停止します。uniqueidを持つコンポーネントを確認するには、次のコマンドを使用します。
ORACLE_HOME¥opmn¥bin¥opmnctl @cluster status -fmt %typ%uid%prt -noheaders
次に、このコマンドを実行した結果の例を示します。
CUSTOM | N/A | ASG LOGLDR | N/A | logloaderd OHS | 1500577870 | HTTP_Server performance | 1500577873 | performance_server messaging | 1500577874 | messaging_server
次のコマンドを実行して、2番目の列(uid)の値がN/Aではない、すべてのOC4Jプロセスを停止します。
ORACLE_HOME¥opmn¥bin¥opmnctl @cluster stopproc uniqueid=1500577865 opmnctl: stopping opmn managed processes...
リストア操作の完了後、次のコマンドを使用してクラスタ全体のOC4Jプロセスを再起動します。
ORACLE_HOME/opmn/bin/opmnctl @cluster
startproc ias-component=OC4J
uniqueid
を使用するコンポーネントについては、適切なias-component値を使用するか次のコマンドを実行してプロセスを再起動します。
opmnctl startall
|
Copyright © 2002, 2006, Oracle. All Rights Reserved. |
|