10gリリース3（10.1.3.2.0）
E05047-01
 目次 |
 索引 |
| Oracle Application Server 管理者ガイド 10gリリース3（10.1.3.2.0） E05047-01 |
|
この章では、Oracle Application Serverのバックアップ計画および手順について説明します。
この章の項目は次のとおりです。
この項では、Oracle Application Serverに推奨されるバックアップ計画について説明します。この計画に従って、このマニュアルで説明するリカバリ手順を実行することができます。
バックアップ計画には、次のものがあります。
図17-1のフロー・チャートは、特定の状況に適したバックアップ・タイプの決定方法の概要を示しています。
最初に実行するバックアップは、イメージのバックアップです。このバックアップには、環境内のすべてのファイルが含まれます。環境の記録も作成してください。
このバックアップは、以降のすべてのインスタンス・バックアップに対するベースラインとして機能します。
詳細は、第17.2.3項「Oracle Application Server環境の完全バックアップの実行」を参照してください。
環境を再構成する必要がある場合、この記録を参照できます。
詳細は、第17.2.1項「Oracle Application Server構成の記録の作成」を参照してください。
管理上の変更を実行するたびに、または（これが不可能な場合は）定期的に、Oracle Application Server環境のインスタンスのバックアップを実行してください。
詳細は、第17.2.2項「コマンドラインからのOracle Application Serverインスタンスのバックアップの実行」を参照してください。
Oracle Application Server環境に大きな変更を加えた場合は、Oracle Application Server環境のイメージのバックアップを改めて実行する必要があります。このバックアップは、以降のすべてのインスタンス・バックアップに対するベースラインとして機能します。また、環境の記録を新しい構成情報で更新する必要もあります。
次の処理の後に、イメージのバックアップを実行します。
そのためには、次の手順を実行します。
詳細は、第17.2.1項「Oracle Application Server構成の記録の作成」を参照してください。
詳細は、第17.2.3項「Oracle Application Server環境の完全バックアップの実行」を参照してください。
改めてOracle Application Server環境の完全バックアップを実行した後で、作業2に戻り、インスタンスの定期的なバックアップを実行します。
アプリケーションにリモートのポートレット・プロデューサが含まれている場合は、ポートレット・プロデューサのカスタマイズ・データおよびパーソナライズ・データをバックアップする必要があります。
この項では、バックアップ手順の詳細を説明します。構成データの一貫性を維持するには、各Oracle Application Serverインスタンスのバックアップを同時に作成する必要があります。あるOracle Application Serverインスタンスをバックアップしている間は、他のインスタンスの構成を変更しないでください。
この項の項目は次のとおりです。
Oracle Application Server環境のリストアおよびリカバリが必要な場合、必要なすべての情報を入手し、対処することが重要です。これは、特にOracle Application Server環境全体（またはその一部）を新しいディスクまたはホストに再構成する必要があるような、ハードウェアの損失が発生した場合に当てはまります。
この項で説明されている情報を含む、Oracle Application Server環境の最新記録を維持管理する必要があります。この情報は、印刷物と電子形式の両方で保管してください。電子形式のデータは、Oracle Application Server環境とはまったく別のホストまたは電子メール・システム上に格納する必要があります。
Oracle Application Serverのハードウェアおよびソフトウェア構成の記録には、次のものが含まれます。
この項では、Oracle Application Serverインスタンスの各種バックアップをコマンドラインから実行する方法について説明します。インスタンス・レベルのバックアップでは、構成ファイル、中間層用のリポジトリを含む、アプリケーション・サーバー・インスタンスに必要なすべてのコンポーネントがバックアップされます。
Oracle Application Server環境の完全バックアップを実行したら、それ以降は、管理上の変更があるたびに、またはそれが不可能であれば定期的に、インスタンス・レベルのバックアップを実行する必要があります。
次のコマンドを使用して、Oracle Application Serverインスタンスのコールド・バックアップを実行します。
bkp_restore.sh -m backup_instance_cold bkp_restore.bat -m backup_instance_cold
次のコマンドを使用して、Oracle Application Serverインスタンスの増分コールド・バックアップを実行します。
bkp_restore.sh -m backup_instance_cold_incr bkp_restore.bat -m backup_instance_cold_incr
次のコマンドを使用して、Oracle Application Serverインスタンスのオンライン・バックアップを実行します。
bkp_restore.sh -m backup_instance_online bkp_restore.bat -m backup_instance_online
次のコマンドを使用して、Oracle Application Serverインスタンスの増分オンライン・バックアップを実行します。
bkp_restore.sh -m backup_instance_online_incr -l level bkp_restore.bat -m backup_instance_online_incr -l level
この項では、Oracle Application Server環境の完全バックアップを実行する方法について説明します。インストールまたはアップグレードの後には、ノードのバックアップを実行する必要があります。ホスト上のインスタンスごとに次の作業を実行します。
次のコマンドを実行して、ノードの構成のバックアップを作成します。
UNIXの場合:
bkp_restore.sh -m configure
Windowsの場合:
bkp_restore.bat -m configure
次のコマンドを実行して、ノードのバックアップを準備します。
UNIXの場合:
bkp_restore.sh -m node_backup -o prepare
Windowsの場合:
bkp_restore.bat -m node_backup -o prepare
この作業では、Oracleホーム、oratab、セントラル・インベントリ、Windowsレジストリなどを含むインスタンスのアーカイブを作成します。UNIXの場合、ルートからコマンドを実行する必要があります。次のコマンドを実行して、インスタンスのイメージのバックアップを作成します。
UNIXの場合:
bkp_restore.sh -m node_backup -o image_backup -P archive path
Windowsの場合:
bkp_restore.bat -m node_backup -o image_backup -P archive path
コマンドが完了すると、バックアップはarchive pathで指定されているディレクトリに格納されます。
リモート・ポートレット・プロデューサを含むアプリケーションを完全にバックアップおよびリカバリするには、次の2つの項目を追加でバックアップおよびリカバリする必要があります。
Predeploymentツールを使用すると、Oracle Metadata Services（OMS）を構成するときに、-backupオプションを使用してOMSリポジトリの場所を指定できます。これにより、Recovery Managerでは、config_misc_files.inpファイルにこの場所を追加することによって、OMSリポジトリをバックアップできます。
ポートレット・プロデューサのプリファレンス・ストアをバックアップするには、JPSおよびPDK-Javaのプリファレンス・ストア移行ユーティリティを使用できます。
JPSプリファレンス・ストアをバックアップするには、次の手順を実行します。
java -classpath wsrp-container.jar:cache.jar:saaj-api.jar:orasaaj.jar:ojdbc14.jar oracle.portlet.server.containerimpl.PersistenceMigrationTool -sourceType db -destType file -sourceDatabase portaldb.mycompany.com:1521:orcl -sourceUsername p1 -sourcePassword p1 -destPath /tmp/portletbkp
PersistenceMigrationToolの構文は次のとおりです。
java oracle.webdb.wsrp.server.PersistenceMigrationTool -sourceType file | db -destType file | db {-sourcePath dir | -sourceUsername username -sourcePassword password -sourceDatabase db} {-destPath dir | destUsername username -destPassword password -destDatabase db} [-debug]
前述の構文に関する説明を次に示します。
sourceTypeは、ソース・ストアがファイルまたはデータベースのどちらに存在するかを示します。ソース・ストアとバックアップ先ストアのタイプが同じ場合があります。したがって、異なるデータベース間やファイル・システム間での移行が可能です。
destTypeは、バックアップ先ストアがファイルまたはデータベースのどちらに存在するかを示します。ソース・ストアとバックアップ先ストアのタイプが同じ場合があります。したがって、異なるデータベース間やファイル・システム間での移行が可能です。
sourcePathは、ファイルベースのプリファレンス・ストアの場所です。この引数は、sourceTypeがfileである場合に必要です。
sourceUsernameは、プリファレンス・ストアのデータベースのデータベース・ユーザー名です。この引数は、sourceTypeがdbである場合に必要です。
sourcePasswordは、プリファレンス・ストアのデータベースのデータベース・パスワードです。この引数は、sourceTypeがdbである場合に必要です。
sourceDatabaseは、プリファレンス・ストアのデータベースの名前です。この引数は、sourceTypeがdbである場合に必要です。
destPathは、ファイルベースのプリファレンス・ストアの場所です。この引数は、destTypeがfileである場合に必要です。
destUsernameは、プリファレンス・ストアのデータベースのデータベース・ユーザー名です。この引数は、destTypeがdbである場合に必要です。
destPasswordは、プリファレンス・ストアのデータベースのデータベース・パスワードです。この引数は、destTypeがdbである場合に必要です。
destDatabaseは、プリファレンス・ストアのデータベースの名前です。この引数は、destTypeがdbである場合に必要です。
debugを指定すると、標準出力を使用するフル・ロギングが有効になり、ツール実行時に発生する問題を診断できます。
WSRPプロデューサのプリファレンス・ストアのタイプを調べるには、web.xmlファイル（例17-1）を確認します。
<env-entry> <env-entry-name>oracle/portal/wsrp/server/persistentStore</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>File</env-entry-value> </env-entry> <env-entry> <env-entry-name>oracle/portal/wsrp/server/fileStoreRoot</env-entry-name> <env-entry-type>java.lang.String</env-entry/type> <env-entry-value>portletdata</env-entry-value> </env-entry>
JPSポートレット移行ユーティリティの詳細は、『Oracle WebCenter Framework開発者ガイド』を参照してください。
PDK-Javaプリファレンス・ストアをバックアップするには、次の手順を実行します。
java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool -mode dbtofile -remap locale -countries AR,MX -pref1UseHashing true -pref1User portlet_prefs -pref1Password portlet_prefs -pref1URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid -pref2RootDirectory /tmp/portletbkp
移行ユーティリティの構文は次のとおりです。
java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool -mode [file | db | filetodb | dbtofile | dbtodb] [-remap language | locale] [-countries iso_country_code] [-pref1UseHashing true | false] {-pref1RootDirectory directory | -pref1User username -pref1Password password -pref1URL url} [-pref1UseHashing true | false] {-pref2RootDirectory directory | -pref2User username -pref2Password password -pref2URL url} [-upfixwpi filename]
前述の構文に関する説明を次に示します。
-modeは、プリファレンス・ストアの移行およびアップグレードを行うユーティリティの実行モードです。
-remapは、localePersonalizationLevel（languageまたはlocale）です。このオプションを使用する必要があるのは、アップグレードや移行の一環としてlocalePersonalizationLevelを変更する場合のみです。
-countriesを使用して、ISO国コードに優先順位を付けたリストを指定できます。このリストは、複数の国のプリファレンスを再マップして競合が発生した場合のプリファレンスの優先順位を示します。-countriesは、-remapオプションも同時に指定した場合にのみ機能します。
-pref1UseHashingは、この操作のソースでハッシングを使用するかどうかを示します。
-pref1RootDirectoryは、ソース・ファイル・システムのパス（j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sampleなど）です。
-pref1Userは、ソース・データベースのユーザー名です。
-pref1Passwordは、ソース・データベースのパスワードです。
-pref1URLは、ソース・データベースのURL（jdbc:oracle:thin:@myserver.mydomain.com:1521:mysidなど）です。
-pref2UseHashingは、アップグレードまたは移行でハッシングを使用するかどうかを示します。
-pref2RootDirectoryは、アップグレードまたは移行を行う対象となるファイル・システムのパス（j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sampleなど）です。
-pref2Userは、アップグレードまたは移行を行う対象となるデータベースのユーザー名です。
-pref2Passwordは、アップグレードまたは移行を行う対象となるデータベースのパスワードです。
-pref2URLは、アップグレードまたは移行を行う対象となるデータベースのURL（jdbc:oracle:thin:@myserver.mydomain.com:1521:mysidなど）です。
-upfixwpiは、操作のログ・ファイルを示します。
PDK-Javaプロデューサのプリファレンス・ストアのタイプを調べるには、provider.xmlファイル（例17-2）を確認します。
<provider class="oracle.portal.provider.v2.DefaultProviderDefinition"> <localePersonalizationLevel>none</localePersonalizationLevel> <session>true</session> <defaultLocale>en</defaultLocale> <preferenceStore class="oracle.portal.provider.v2.preference.FilePreferenceStore"> <name>prefStore1</name> </preferenceStore> <portlet class="oracle.portal.sample.v2.devguide.prefstore.GuestBookPortletDefinition"> <id>1</id> <name>GuestBook</name> <title>Guest Book Portlet</title> <shortTitle>Guest Book</shortTitle> <description>Demonstration of using a Preference Store to drive portlet content</description> <timeout>100</timeout> <timeoutMessage>Guest Book Portlet timed out</timeoutMessage> <renderer class="oracle.portal.provider.v2.render.RenderManager"> <showPage>/htdocs/prefstore/guest_book.jsp</showPage> <editPage>/htdocs/prefstore/store_comment.jsp</editPage> </renderer> </portlet> </provider>
PDK-Javaの移行とアップグレードを行うユーティリティの詳細は、『Oracle WebCenter Framework開発者ガイド』を参照してください。
OracleAS Recovery Managerでは、1つのホスト上のインスタンスの完全バックアップを実行して、元の動作環境が損なわれた場合にそれらのインスタンスを新しいホストにリストアする手順が自動化されています。
Loss of Host Automation（LOHA）によって、Oracle Application Server管理者が異なるホスト間でOracle Application Serverインスタンスを移行する場合に必要な作業が自動化されます。新しいホストは、同じオペレーティング・システムを実行する別のホストであっても、システムのイメージを再導入した後の同一ホストであってもかまいません。LOHAには、ホストが喪失した場合に、インスタンスの再インストールおよびアプリケーション・データの保存を行うことなく、元のインスタンスを新しい環境にリストアするためのソリューションが用意されています。
LOHAでは、すべての中間層インストールがサポートされており、新しいホスト名を元のホスト名と同じにすることも別の名前にすることもできます。ホスト名が異なる場合は、手動の作業が必要になります。
LOHAでは、新しいホストにすでに実行している別のOracle Application Serverインスタンスがない場合に、1つのホストから新しいホストにすべてのOracle Application Serverインスタンスを移動できます。インスタンスのサブセットについては、元のホストに残っているインスタンスとの依存関係がない場合に、これらのサブセットを新しいホストにリストアできます。複数のホストから単一のホストにインスタンスをリストアすることはできません。
LOHAを使用すると、同じホスト上にある他のインスタンスに影響することなく、破損したインスタンスをリカバリすることもできます。
この項の項目は次のとおりです。
Loss of Host Automationサービスは、OracleAS Recovery Managerの一部としてインストールされます。これは、次のディレクトリにインストールされます。
UNIXの場合:
ORACLE_HOME/backup_restore/loha
Windowsの場合:
ORACLE_HOME¥backup_restore¥loha
Loss of Host Automationサービスを使用するには、第16章「Oracle Application Server Recovery Manager」の説明に従って、OracleAS Recovery Managerを構成する必要があります。
Loss of Host Automationサービスには、次の前提条件があります。
-invPtrLocのインストーラ・コマンドライン・オプションを指定してインスタンスをインストールした場合のみ、config.inpファイルのorainst_loc_pathフィールドを変更する必要があります。oraInst.locの場所が標準以外である場合に、それを反映して変更する必要があります。
sc.exeを元のホストと新しいホストの両方にインストールする必要があります。Microsoft社によると、このユーティリティはNT Resource Kitの一部です。Windows XPの場合、このユーティリティはインストールの一部になっています。Windows 2000プラットフォームの場合、このユーティリティをインストールする必要があります。これが、実行パス内に存在することを確認します。
jar（Windows）またはtar（UNIX）を使用したノード・アーカイブの解凍が可能である必要があります。ご使用のシステムに独自のtarプログラムがある場合は、GNU tarのかわりにそのプログラムを使用します。
Loss of Host Automationサービスを有効化するには、元のホストの各インスタンスに対して次の作業を実行する必要があります。
インストールまたはアップグレードの後には、ノードのバックアップを実行する必要があります。次のコマンドを実行して、ノードの構成のバックアップを作成します。
UNIXの場合:
bkp_restore.sh -m configure
Windowsの場合:
bkp_restore.bat -m configure
ノードのバックアップの準備では、現在のホストに関する次の情報の調査が、Loss of Host Automationサービスによって行われます。
この処理では、Loss of Host Automationサービスによってインスタンスのバックアップも作成されます。
次のコマンドを実行して、ノードのバックアップを準備します。
UNIXの場合:
bkp_restore.sh -m node_backup -o prepare
Windowsの場合:
bkp_restore.bat -m node_backup -o prepare
この作業では、元のOracleホーム、oratab、セントラル・インベントリ、Windowsレジストリなどを含むインスタンスのアーカイブが作成されます。UNIXの場合、ルートからコマンドを実行する必要があります。次のコマンドを実行して、元のインスタンスのイメージのバックアップを作成します。
UNIXの場合:
bkp_restore.sh -m node_backup -o image_backup -P archive path
Windowsの場合:
bkp_restore.bat -m node_backup -o image_backup -P archive path
コマンドが完了すると、バックアップはarchive pathで指定されているディレクトリに格納されます。
この項で示すコマンドによって、ホストの損失後に新しいホストでノードがリストアされます。次の手順を実行する前に、第17.3.1項「Loss of Host Automation使用の準備」のすべての前提条件が満たされていることを確認します。
次の各コマンドを順序正しく実行する必要があります。
UNIXの場合、次のようにrootとしてログインします。
cd / tar -xvpf archive_name
Windowsの場合:
jar -xvf archive_name
rootとして実行する必要があります。UNIXの場合:
bkp_restore.sh -m node_restore -o sys_init
Windowsの場合:
bkp_restore.bat -m node_restore -o sys_init
root.shの実行によってデーモンの起動および停止スクリプトが設定され、Windowsの場合はWindowsサービスが作成されます。コマンドはUNIX上でrootとして実行する必要があります。UNIXの場合:
bkp_restore.sh -m node_restore -o inst_register
Windowsの場合:
bkp_restore.bat -m node_restore -o inst_register
opmnctl shutdownを実行して、再構成のプロセスに必要なポートがOPMNプロセスとEnterprise Managerプロセスで使用されていないことを確認します。WindowsにInfrastructureとMetadata Repositoryがインストールされている環境では、このコマンドを実行する前に手動でflashback_recovery_areaを作成する必要があります。このコマンドは、インスタンスの所有者として実行する必要があります。インスタンスのバックアップへのパスが有効である必要があります。 UNIXの場合:
bkp_restore.sh -m node_restore -o inst_reconfigure -t config_bkp_timestamp
Windowsの場合:
bkp_restore.bat -m node_restore -o inst_reconfigure -t config_bkp_timestamp
タイムスタンプ引数を指定しない場合、このコマンドによって使用可能なインスタンス・バックアップがすべて表示されます。この操作を正しく完了するには、他の必要なサービスがすべて、このインスタンスに属していない場合に稼動していることを確認します。
LOHAでは、新しいホストでのポート競合は検出されません。リストアするインスタンスで使用するTCPポートを使用する他のアプリケーションを実行しないことをお薦めします。ポート競合が発生した場合、この操作は失敗します。
Oracle_Home/backup_restore/config/config_misc_files.inp_<time_stamp>ファイルが存在し、既存のconfig_misc_files.inpファイルより新しい場合は、config_misc_files.inpファイルを、最新のconfig_misc_files.inp_<time_stamp>ファイルで上書きします。Oracle_Home/backup_restore/plugin_configディレクトリ内のコンポーネント・プラグイン・ファイルごとに、config_component_name_plugin.inpファイルのタイムスタンプより新しいタイムスタンプのファイルがあるかどうかを確認します。新しいタイムスタンプのファイルがある場合は、config_component_name_plugin.inpファイルを最新のタイムスタンプのファイルで上書きします。
Oracle Application Serverインスタンスの問題を解決するためにイメージのリストアが必要な場合、LOHAを使用してインスタンスをリカバリできます。次の手順を実行して、インスタンスをリカバリします。
このインスタンスがOracle Application Serverの他のインスタンスとなんらかの依存関係にある場合、他のインスタンスは稼動している必要があります。
|
 Copyright © 2002, 2007, Oracle. All Rights Reserved. |
|