Enterprise Managerのバックアップとリカバリ

25 Enterprise Managerのバックアップとリカバリ

エコシステムのモニタリングおよび管理フレームワークと同様に、高可用性計画の重要な部分は、Enterprise Managerの定期的なバックアップを確実に行い、障害発生時のリストアを可能にすることです。

この章の構成は、次のとおりです。

デプロイメントのバックアップ

Enterprise Managerは単一のエンティティとして機能しますが、技術的には、次のソフトウェア・コンポーネントで構成される分散型の多層ソフトウェア・アーキテクチャで構築されています。

Oracle Management Services(OMS)
管理エージェント
管理リポジトリ
ソフトウェア・ライブラリ

各コンポーネントは、構成と機能がそれぞれ異なり、バックアップとリカバリに対して異なるアプローチを必要とします。このため、バックアップ戦略について、この章では層別に説明します。Enterprise Managerのアーキテクチャの概要は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する項を参照してください。

ソフトウェア・ライブラリのバックアップ

ソフトウェア・ライブラリは、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなどのEnterprise Managerソフトウェア・エンティティの集中メディア記憶域です。ソフトウェア・ライブラリはEnterprise Managerフレームワークの不可欠な部分であり、多くのEnterprise Manager機能が適切に機能するために必須です。ソフトウェア・ライブラリの記憶域の場所は、ファイルシステム・バックアップを使用して定期的にバックアップする必要があります。1時間から24時間の頻度でバックアップを実行することをお薦めします。

管理リポジトリのバックアップ

管理リポジトリは、管理エージェントにより収集されたすべての情報が保管される記憶域です。データベース・ジョブ、パッケージ、プロシージャ、ビュー、表領域などのオブジェクトから構成されます。これはOracle Databaseで構成されるため、管理リポジトリのバックアップおよびリカバリ戦略は、基本的にはOracle Databaseの戦略と同じになります。データベースのバックアップ・プロシージャは、十分に確立した標準であり、RMANバックアップ・ユーティリティを使用して実装でき、このユーティリティにはCloud Controlコンソールからアクセスできます。

管理リポジトリのバックアップ

管理リポジトリ・データベースの計画外の停止を回避するために、高可用性のベスト・プラクティスを使用することをお薦めします。このためには、次の標準のデータベース・バックアップ戦略を使用します。

データベースはarchivelogモードにします。リポジトリ・データベースをarchivelogモードで実行しないと、メディア障害後のリカバリ不能な状況でデータベースが脆弱なままになります。
Cloud Controlコンソールを介して推奨バックアップ戦略オプションを使用し、RMANによる通常のホット・バックアップを実行します。他のユーティリティ(例: DataGuardやRAC)も、一般的にHAレベル3または4で実装される包括的なHAおよびデータ保護の計画の一部として利用できます。様々なHAレベルの詳細は、「高可用性レベルの実装」を参照してください。

これらの戦略に従うと、全体バックアップが作成された後、以降は毎回増分バックアップが作成されます。増分の変更はベースラインにロールアップされ、新しい全体バックアップ・ベースラインが作成されます。

推奨バックアップ戦略を使用すると、Enterprise Managerのバックアップ実行機能も利用でき、ジョブはEnterprise Managerのジョブ・サブシステムを通じて自動的にスケジュールされます。これで、バックアップの履歴がレビューで使用可能になり、バックアップのステータスがリポジトリ・データベース・ターゲットのホームページで表示されます。このバックアップ・ジョブとアーカイブおよびフラッシュバック・テクノロジを併用すると、リポジトリのいずれかの部分が失われた場合のリストア・ポイントが得られます。このタイプのバックアップ処理およびアーカイブ・ログとオンライン・ログにより、リポジトリを最後に完了したトランザクションまでリカバリできます。

最後にリポジトリ・バックアップが行われた時期は、「リポジトリ詳細」セクションの「管理サービスとリポジトリの概要」ページで確認できます。

Enterprise Managerを使用したバックアップの構成方法の概要は、Oracle Database 2日でデータベース管理者の基本バックアップおよびリカバリのためのデータベースの構成を参照してください。データベースの高可用性に関する追加情報は、高可用性の概要を参照してください。

Oracle Management Serviceのバックアップ

Oracle Management Service(OMS)は管理エージェントを編成し、ターゲットを検出、モニターおよび管理し、収集された情報を将来の参照および分析のためリポジトリに格納します。OMSは、Enterprise Managerコンソール用のWebインタフェースもレンダリングします。

OMSのバックアップ

OMSは通常、ステートレスです。構成データの一部は、OMSファイルシステムに格納されます。

OMS構成のスナップショットは、emctl exportconfig omsコマンドを使用して取得できます。

$ <OMS_HOME>/bin/emctl exportconfig oms [-sysman_pwd <sysman password>]
[-dir <backup dir>] Specify directory to store backup file
[-keep_host] Specify this parameter if the OMS was installed using a virtual hostname (using
ORACLE_HOSTNAME=<virtual_hostname>)

exportconfigを実行すると、特定の時点のOMSのスナップショットが取得されるため、最新のOMS構成を定期的にバックアップできます。exportconfigは常に、WebLogic管理サーバーを実行するOMSで実行します。必要に応じて、最新のスナップショットを同一または別のホスト上のフレッシュOMSインストールにリストアできます。

OMSコンポーネントのバックアップ戦略は次のとおりです。

ソフトウェア・ホーム

Fusion Middlewareホーム、OMS Oracleホーム、Web層(OHS)Oracleホーム、および複数の管理プラグインOracleホームから構成されます。

ソフトウェア・ホームは、パッチやパッチセットが適用される場合および更新が新しい自己更新機能により提供される場合に変わります。このため、ファイルシステムレベルのバックアップは、各パッチ/パッチセットの適用後、または自己更新による更新の適用後に作成する必要があります。Oracleインベントリ・ファイルとソフトウェア・ホームをバックアップし、opatch lsinventory –detailの出力を保存して、バックアップしたOracleホームに適用したパッチを特定しやすくしてください。

ノート:

ファイルシステムレベルのバックアップがない場合、ソフトウェア・ホームをInstalling Software Onlyインストール方法を使用して再インストールすることもできます。

重要: OMS Oracleホームの場所は、Cloud ControlデプロイメントのすべてのOMSインスタンスと同じにしてください。
インスタンス・ホーム

gc_instディレクトリには、WebLogic Server、OMSおよびWeb層の構成ファイルがあります。

インスタンス・ホームはemctl exportconfig omsコマンドを使用してバックアップできます。
管理サーバー

管理サーバーは、OMSインスタンスのドメイン全体を構成するための集中管理エンティティとして動作します。管理サーバーは、Cloud Controlデプロイメントにインストールされる最初のOMSの不可欠な要素であり、ソフトウェア・ホームとインスタンス・ホームを共有します。

管理サーバーは、emctl exportconfig omsコマンド(管理サーバーのある最初のOMSでのみ実行)により、インスタンス・ホームと同時にバックアップされます。

管理エージェントのバックアップ

管理エージェントは、モニター対象の各ホストにデプロイされている統合ソフトウェア・コンポーネントです。これらのホスト上で実行されているすべてのターゲットのモニタリング、中間層のOMSへのこのモニタリング情報の伝達、ホストおよびそのターゲットの管理およびメンテナンスを行います。

管理エージェントのバックアップ

管理エージェントのバックアップに関する特別な考慮事項はありません。ベスト・プラクティスとしては、管理エージェントの参照インストールを異なるプラットフォームに対して保持し、emd.propertiesファイルで実行済のカスタマイズと適用済のパッチが最新の状態に保たれるようにします。参照エージェント・インストールのインストールおよび保持には、Cloud Controlコンソールのデプロイメント・オプションを使用します。

管理エージェントが失われた場合、参照インストールからクローニングして再インストールする必要があります。

障害の発生したEnterprise Managerコンポーネントのリカバリ

Enterprise Managerのリカバリは、Enterprise Managerアーキテクチャの3つの基本的なコンポーネントのリストアを意味します。

管理リポジトリ
管理サービス
管理エージェント
ソフトウェア・ライブラリ

リポジトリのリカバリ

リポジトリ・データベースの停止時はCloud Controlは使用できないため、リポジトリ・データベースのリカバリはRMANを使用して実行する必要があります。次の2種類のリカバリを考慮する必要があります。

完全リカバリ: Enterprise Managerに関する特別な考慮事項はありません。
ポイント・イン・タイム/不完全リカバリ: リカバリされたリポジトリは、トランザクションの損失のため、エージェントと同期化されていない場合があります。この状況では、エージェントで使用できる最新の状態とリポジトリが同期化されないかぎり、一部のメトリックがCloud Controlで誤って表示される場合があります。

リポジトリの再同期化機能により、Enterprise Managerリポジトリを管理エージェントで使用可能な最新の状態と同期化するプロセスを自動化できます。

リポジトリを管理エージェントと再同期化するには、Enterprise Managerコマンドライン・ユーティリティ(emctl)のresync reposコマンドを使用します。

emctl resync repos -full -name "<descriptive name for the operation>"

このコマンドは、管理リポジトリをリストアした後、かつ、OMSを起動する前に、OMS Oracleホームから実行する必要があります。コマンドの発行後、すべてのOMSインスタンスを起動し、次の図に示すように、Enterprise Managerコンソールのリポジトリの再同期化ページからリポジトリの再同期化の進行状況をモニターします。

図25-1 「リポジトリの同期化」ページ

管理リポジトリのリカバリが完了するのは、再同期化ジョブがすべての管理エージェントで完了したときです。

障害発生時にデータベースを最新のトランザクションまでリカバリできるように、管理リポジトリ・データベースをarchivelogモードで実行することをお薦めします。データベースを最後のトランザクションまでリカバリできない場合は、リポジトリの同期化を使用して、最後のバックアップの作成時に存在していたターゲットのモニタリング機能をリストアできます。バックアップ後に行ったアクションは、自動的にはリカバリされません。リポジトリの同期化で自動的にリカバリされないアクションの例は次のとおりです。

インシデント・ルール
優先資格証明
グループ、サービス、システム
ジョブ/デプロイメント手順
カスタム・レポート
新しいエージェント

リカバリ・シナリオ

リポジトリ(または任意のデータベース)をリカバリする前提条件は、リポジトリの有効な一貫性バックアップがあることです。Enterprise Managerを使用してバックアップ・プロセスを自動化すると、リポジトリのリカバリが必要になった場合に備えて、通常の最新バックアップが常に用意されます。Recovery Manager(RMAN)は、Oracle Databaseのバックアップ、リストアおよびリカバリを行うユーティリティです。RMANのリカバリ・ジョブの構文は、安全な場所に保存する必要があります。これにより、Enterprise Managerリポジトリ・データベースの完全リカバリを実行できます。最も単純な形式では、構文は次のようになります。

run {
restore database;
recover database;
}

実際の構文は、環境によって長さや複雑さが異なります。構文をRMANのバックアップおよびリカバリ・ジョブから抽出する方法、またはRMANの一般的な使用方法は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

次の各シナリオでは、様々なリポジトリのリカバリ状況とそのリカバリ・ステップを示します。

同一ホスト上の完全リカバリ

リポジトリ・データベースはarchivelogモードで実行されています。最近のバックアップ、アーカイブ・ログ・ファイルおよびREDOログがあります。リカバリ・データベース・ディスクがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

emctl stop oms -allを使用して、すべてのOMSインスタンスを停止します。
RMANを使用してデータベースをリカバリします。
すべてのOMSインスタンスでコマンドemctl start omsを使用してサイトを起動します。
サイトが完全に動作していることを確認します。

同一ホスト上の不完全リカバリ

リポジトリ・データベースはnoarchivelogモードで実行されています。全体オフライン・バックアップがあります。リカバリ・データベース・ディスクがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

emctl stop oms -allを使用して、OMSインスタンスを停止します。
RMANを使用してデータベースをリカバリします。
emctl resync repos -full -name "<resync name>"を使用して、OMS Oracleホームの1つからリポジトリの再同期化を開始します。
emctl start omsを使用して、OMSインスタンスを起動します。
Cloud Controlにログインします。「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。管理サービスとリポジトリ・ページが表示されます。
「OMSとリポジトリ」メニューから、「リポジトリの同期化」を選択します。
サイトが完全に動作していることを確認します。

別のホスト上の完全リカバリ

管理リポジトリ・データベースは、ホストAでarchivelogモードで実行中です。最近のバックアップ、アーカイブ・ログ・ファイルおよびREDOログがあります。リポジトリ・データベースがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

コマンドemctl stop omsを使用して、OMSインスタンスを停止します。
RMANを使用して、データベースを別のホスト(ホストB)上でリカバリします。
各OMSで次のコマンドを実行して、リポジトリの接続記述子を修正します。
```
$emctl config oms –store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman
```
次のコマンドを使用してOMSを停止します。

emctl stop oms -all
次のコマンドを使用してOMSインスタンスを起動します

emctl start oms。
次のコマンドをOMSから実行し、管理リポジトリ・データベース・ターゲットをホストB上で実行されているエージェントに再配置します。
```
$emctl config repos -host <hostB> -oh <OH of repository on hostB>  -conn_desc "<TNS connect descriptor>"
```
ノート:

このコマンドは、次の条件を満たしている場合にのみ、リポジトリ・データベースの再配置に使用できます。
- エージェントがこのマシン上ですでに実行されていること。
- ホストB上のデータベースが検出されていないこと。
次のコマンドをOMSから実行し、OMSおよびリポジトリ・ターゲットのモニタリング構成を変更します。
```
$emctl config emrep -conn_desc "<TNS connect descriptor>"
```
サイトが完全に動作していることを確認します。

別のホスト上の不完全リカバリ

管理リポジトリ・データベースは、ホストAでnoarchivelogモードで実行中です。全体オフライン・バックアップがあります。ホストAはハードウェア障害のために失われました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

emctl stop omsを使用して、OMSインスタンスを停止します。
RMANを使用して、データベースを別のホスト(ホストB)上でリカバリします。
資格証明ストアのリポジトリの接続記述子を修正します。
```
$emctl config oms –store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman
```
このコマンドはomsを停止して起動するよう求めます。
リポジトリの再同期化を開始します。

$emctl resync repos -full -name "<resync name>"

これは、OMS Oracleホームの1つから開始します。
コマンドemctl start omsを使用して、OMSを起動します。
コマンドを実行して、リポジトリ・データベース・ターゲットをホストBで実行されている管理エージェントに再配置します。

$emctl config repos -agent <agent on host B> -host <hostB> -oh <OH of repository on hostB> -conn_desc "<TNS connect descriptor>"
次のコマンドを実行し、OMSおよびリポジトリ・ターゲットのモニタリング構成を変更します。

emctl config emrep -conn_desc "<TNS connect descriptor>"
Cloud Controlにログインします。「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。
「OMSとリポジトリ」メニューから「リポジトリの同期化」を選択します。再同期化ジョブのステータスをモニターします。前述のエラーの修正後、失敗したジョブがあれば、そのジョブを再発行します。
サイトが完全に動作していることを確認します。

OMSのリカバリ

Oracle Management Serviceのインスタンスが失われた場合、OMSのリカバリは基本的に、ソフトウェア・ホームのリカバリ、インスタンス・ホームの構成、およびソフトウェア・ライブラリがEnterprise Managerと同じホストで構成されている場合はソフトウェア・ライブラリのリカバリという3つのステップで構成されます。

ソフトウェア・ホームのリカバリ

同じホストでリストアする場合、ソフトウェア・ホームをファイルシステム・バックアップからリストアできます。バックアップが存在しない場合、または別のホストへインストールする場合、ソフトウェア・ホームは、Cloud Controlソフトウェアのディストリビューションから「ソフトウェアのみインストール」オプションを使用して再構築できます。クラッシュ前に環境に存在したすべての管理プラグインを選択してインストールする必要があることに注意してください。

管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行して、インストール済のプラグインのリストを取得します。
```
SELECT epv.display_name, epv.plugin_id, epv.version, epv.rev_version,decode(su.aru_file, null, 'Media/External', 'https://updates.oracle.com/Orion/Services/download/'||aru_file||'?aru='||aru_id||chr(38)||'patch_file='||aru_file) URL
FROM em_plugin_version epv, em_current_deployed_plugin ecp, em_su_entities su
WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME')
AND ecp.dest_type='2'
AND epv.plugin_version_id = ecp.plugin_version_id
AND su.entity_id = epv.su_entity_id;
```
前述の問合せでは、プラグインのリストと、自己更新でダウンロードされた場合にはダウンロードするためのURLが返されます。プラグインがインストール・メディアにあるか、自己更新で取得できないサード・パーティのプラグインの場合、URLは"Media/Unknown"とマークされます。
追加のプラグイン(ある場合)を、ステップ1の問合せで返されたリストのURLからダウンロードして、1つのディレクトリに配置します。ファイル名の拡張子を.zipから.oparに変更します。
インストーラを起動して、ソフトウェア専用のオプションを選択し、ミドルウェアおよびOMS Oracleホームをインストールします。
必要なプラグインをインストールするには、PluginInstall.shスクリプト(OMS_HOME/sysman/install/PluginInstall.sh)を、ダウンロードしたプラグインの保存先ディレクトリへのパスを指定するPLUGIN_LOCATION=<プラグイン・ディレクトリへの絶対パス>を使用して、実行する必要があります。プラグインの選択を求められたら、必ずSQL問合せにリストされたプラグインと同じプラグインを選択してください。

ノート:

すべての必要なプラグインがインストールされていない場合、リカバリは失敗します。

ソフトウェア専用モードの後で、クラッシュの前にインストールされたすべてのパッチを再度適用する必要があります。管理リポジトリが損傷していないと仮定した場合、リポジトリに対してSQLを実行する後処理スクリプトは、リポジトリにはそのようなパッチを適用済なので省略できます。

bitonlyモードでパッチを適用するには、次のコマンドを使用します。

$omspatcher apply -analyze -bitonly
$omspatcher apply -bitonly

前述のように、OMS Oracleホームの場所は修正されるため、変更できません。そのため、以前に使用された場所でOMS Oracleホームをリストアするようにします。

OMSの再作成

ソフトウェア・ホームをリカバリすると、インスタンス・ホームはリカバリ・モードでomscaコマンドを使用して再構築できます。

omsca recover –as –ms -nostart –backup_file <exportconfig file>

次の項で示すemctl exportconfigコマンドで生成されるエクスポート・ファイルを使用します。

OMSのリカバリ・シナリオ

次の各シナリオでは、OMSの様々なリカバリ状況とそのリカバリ・ステップを示します。

ノート:

OMSリカバリの前提条件は、最近の有効なOMS構成バックアップがあることです。OMS構成が変更されるたびに、emctl exportconfig omsコマンドを使用してOMSをバックアップすることをお薦めします。このコマンドは、WebLogic AdminServerを実行するプライマリOMSで実行する必要があります。

または、Enterprise Managerのジョブ・システムを使用して、このコマンドを定期的に実行できます。

次の各シナリオでは、ファイルシステムのバックアップ(使用可能な場合および同じホストへのリカバリの場合のみ)を使用、またはインストーラのソフトウェア専用オプションを使用したソフトウェア・ホームのリカバリについて示します。いずれの場合も、ベスト・プラクティスはファイルシステムのバックアップからではなく、omsca recoverコマンドを使用したインスタンス・ホーム(gc_inst)をリカバリすることです。これにより、インスタンス・ホームが有効で、最新であることが保証されます。

単一OMS、サーバー・ロード・バランサ(SLB)なし、OMSを同一ホスト上でリストア

サイトは単一OMSをホストします。SLBはありません。AdminServerを実行するプライマリAdminServerでemctl exportconfig omsコマンドを使用してOMS構成をバックアップしました。OMS Oracleホームが失われました。

解決方法:

障害の発生したOMSホストでクリーンアップを実行します。

次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。
```
ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9
```
ノート:

Middleware|gc_instを、自身のミドルウェアおよびインスタンスのホームと一致する文字列に変更します。

ソフトウェア専用インストール方法を使用してソフトウェア・ホームをリカバリしている場合、最初にCloud Controlソフトウェアのディストリビューション・インストーラを使用して既存のOracleホームを削除します。ソフトウェア・ホームが使用可能でなくなっている場合にも、失われたOracleホームのレコードをOracleインベントリから削除する必要があるので、これは必要です。

存在する場合、Middlewareおよびgc_instディレクトリを削除します。
ソフトウェア・ライブラリの場所にアクセスでき、有効であることを確認します。ソフトウェア・ライブラリがアクセス可能だが破損している場合、OMSCAリカバリに影響します。
ソフトウェア・ホームをリストアします。詳細は、「ソフトウェア・ホームのリカバリ」を参照してください。

ファイルシステム・バックアップからリストアしている場合、次のファイルを削除します。

OMS_HOME/sysman/config/emInstanceMapping.properties

また、存在する場合はリストアされた可能性のあるgc_instを削除します。
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
```
<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>
```
ノート:

渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。
ノート:

BIPが最初のOMSで構成された場合、次のポートも渡す必要があます。そうしないと、リカバリは失敗します。

次に例を示します。
```
<OMS_HOME>/bin/omsca recover -as -ms -nostart -backup_file /scratch/emga/opf_ADMIN_20191105_022311.bka -EM_BIP_PORT 9701 -EM_BIP_HTTPS_PORT 9803 -EM_BIP_OHS_PORT 9788 -EM_BIP_OHS_HTTPS_PORT 9851
```
OMSを開始します。
```
OMS_HOME/bin/emctl start oms
```
エージェントをリカバリします(必要な場合)。

管理エージェント・ソフトウェア・ホームがOMSソフトウェア・ホームとともにリカバリされた場合、管理エージェントとOMSの間の整合性を保証するために管理エージェント・インスタンス・ディレクトリを再作成する必要があります。
1. バックアップからリストアされた場合、agent_instディレクトリを削除します。
2. agentDeploy.shを使用してエージェントを構成します。
```
<AGENT_BASE_DIR>/core/13.4.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>
```
  管理エージェント構成が失敗した場合は、<AGENT_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.agent_<time_stamp>.logを参照してください。
3. OMSが管理エージェントをブロックすることがあります。次のコマンドを使用してエージェントをリポジトリと同期化します。
  
  <OMS_HOME>/bin/emcli resyncAgent -agent=<agent target name myhost.example.com:3872>
管理エージェント・ソフトウェア・ホームがOMSとともにリカバリされず、引き続きエージェントをリカバリする必要がある場合、「同じポートを使用したエージェントの再インストール」の項の手順に従ってください。

ノート:

これは、エージェント・ソフトウェア・ホームのバックアップを含まない、ファイルシステムのリカバリが実行された場合にのみ必要になる可能性があります。OMSソフトウェア・ホームがソフトウェア専用インストール方法を使用してリカバリされた場合、このステップは必要ありません。ソフトウェア専用インストールではMiddlewareホームの下のエージェント・ソフトウェア・ホームにインストールされるからです。
サイトが完全に動作していることを確認します。

単一OMS、SLBなし、OMSを別のホスト上でリストア

サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。

解決方法:

ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。

ノート: 構成されている場合、すべてのBIP共有場所(sharedLoc)にアクセスできることも必要です。
ホストBにソフトウェア・ホームをリストアします。詳細は、「ソフトウェア・ホームのリカバリ」を参照してください。
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
```
<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>
```
ノート:

渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。
ノート:

BIPが最初のOMSで構成された場合、次のポートも渡す必要があます。そうしないと、リカバリは失敗します。

次に例を示します。
```
<OMS_HOME>/bin/omsca recover -as -ms -nostart -backup_file /scratch/emga/opf_ADMIN_20191105_022311.bka -EM_BIP_PORT 9701 -EM_BIP_HTTPS_PORT 9803 -EM_BIP_OHS_PORT 9788 -EM_BIP_OHS_HTTPS_PORT 9851
```
OMSを開始します。
```
<OMS_HOME>/bin/emctl start oms
```
エージェントはソフトウェア専用インストールの一部としてインストールされ、agentDeploy.shコマンドを使用して構成される必要があります。

エージェントを構成します。

<AGENT_BASE_DIR>/agent_13.4.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

管理エージェント構成が失敗した場合は、<AGENT_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.agent_<time_stamp>.logを参照してください。

次のコマンドを使用し、oracle_emrepターゲットを新しいOMSホストの管理エージェントに再配置します。
```
<OMS_HOME>/bin/emcli login –username=sysman
<OMS_HOME>/bin/emcli sync
<OMS_HOME>/bin/emctl config emrep -agent <agent on host "B", e.g myNewOMSHost.example.com:3872>
```
ノート:

emctl config emrep -agentを実行し、フラグ-ignore_timeskewを設定した場合、管理サービスとリポジトリ・ターゲットが新しいエージェントに移動されたときにモニター対象ターゲットの可用性が影響を受けてモニタリング・データが失われることがあります。
Cloud Controlコンソールで、Cloud ControlドメインのWebLogic Domainターゲットを再配置します。「モニタリング資格証明」に移動して管理ホストをホストBに更新します。「WebLogicドメインのリフレッシュ」を実行して新しいホストでドメインを再構成します。
重複したターゲットを、Enterprise Managerコンソールの「管理サービスとリポジトリ概要」ページで探します。「重複したターゲット」リンクをクリックして「重複したターゲット」ページにアクセスします。重複したターゲットのエラーを解決するには、重複したターゲットの名前を、競合が発生しているエージェントで変更する必要があります。重複したターゲットをエージェントAからエージェントBに再配置します。
すべての管理エージェントが指し示すOMSを変更してから、すべてのエージェントを再保護します。

新しいマシンでは、OMSをホストしていた以前のマシンとは異なるホスト名を使用するため、モニター対象の環境内のすべてのエージェントに、新しいOMSを検索する場所を指示する必要があります。各管理エージェントから、次のコマンドを実行します。
```
<AGENT_INST_DIR>/bin/emctl secure agent -emdWalletSrcUrl "http://hostB:<http_port>/em"
```
元のOMSが使用されなくなったと仮定し、「ターゲット」、「ホスト」ページの順に選択して「削除」をクリックすることで、ホスト・ターゲット(すべての残りのモニター対象ターゲットを含む)をCloud Controlから削除します。最初にすべての管理対象ターゲットを削除することを知らせるエラーが表示されます。それらのターゲットを削除してから、ホスト・ターゲットを正常に削除するステップを繰り返します。
サイトが完全に動作していることを確認します。

単一OMS、SLBなし、OMSをオリジナルのホスト名を使用して別のホスト上でリストア

サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。リカバリはホストBで実行されますが、ホスト名Aはそのまま使用されます。

解決方法:

ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。
ホストBにソフトウェア・ホームをリストアします。詳細は、「ソフトウェア・ホームのリカバリ」を参照してください。
ホストBもホスト名ホストAに反応するようにネットワーク構成を変更します。この構成方法の特別な手順については、本書では扱いません。ただし、いくつかの汎用的な構成方法を次に示します。

ホスト名ホストBとホスト名ホストAの両方のネットワーク・アドレスがホストBの物理IPに解決するようにDNSサーバーを変更します。

マルチホームのホストB。ホスト名Aが解決するIPアドレスに対するホストBに追加のIPを構成します。たとえば、ホストBで次のコマンドを実行します。
```
ifconfig eth0:1 <IP assigned to “Hostname A"> netmask <netmask>
/sbin/arping -q -U -c 3 -I eth0 <IP of HostA>
```
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
```
<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file> -AS_HOST <hostA> -EM_INSTANCE_HOST <hostA>
```
ノート:

渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。
OMSを開始します。
```
<OMS_HOME>/bin/emctl start oms
```
エージェントを構成します。

エージェントはソフトウェア専用インストールの一部としてインストールされ、agentDeploy.shコマンドを使用して構成される必要があります。
```
<AGENT_HOME>/core/13.4.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>
```
OMSが管理エージェントをブロックすることがあります。次のコマンドを使用してエージェントをリポジトリと同期化します。

<OMS_HOME>/bin/emcli resyncAgent -agent=<agent target name myhost.example.com:3872>
サイトが完全に動作していることを確認します。

複数OMS、サーバー・ロード・バランサ、プライマリOMSを同一ホスト上でリカバリ

サイトは複数のOMSインスタンスをホストします。すべてのOMSインスタンスの前にサーバー・ロード・バランサがあります。WebLogic AdminServerを実行するプライマリOMSでemctl exportconfig omsコマンドを使用してOMS構成をバックアップしました。プライマリOMSが失われました。

解決方法:

障害の発生したOMSホストでクリーンアップを実行します。

次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。
```
ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9
```
ノート:

Middleware|gc_instを、自身のミドルウェアおよびインスタンスのホームと一致する文字列に変更します。

ソフトウェア専用インストール方法を使用してソフトウェア・ホームをリカバリしている場合、最初にCloud Controlソフトウェアのディストリビューション・インストーラを使用して既存のOracleホームを削除します。ソフトウェア・ホームが使用可能でなくなっている場合にも、失われたOracleホームのレコードをOracleインベントリから削除する必要があるので、これは必要です。

存在する場合、Middlewareおよびgc_instディレクトリを削除します。
ソフトウェア・ライブラリの場所にアクセスできることを確認します。
ソフトウェア・ホームをリストアします。詳細は、「ソフトウェア・ホームのリカバリ」を参照してください。

ファイルシステム・バックアップからリストアしている場合、次のファイルを削除します。

<OMS_HOME>/sysman/config/emInstanceMapping.properties
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
```
<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>
```
ノート:

渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。
OMSを開始します。
```
<OMS_HOME>/bin/emctl start oms
```
管理エージェントのリカバリ

管理エージェント・ソフトウェア・ホームがOMSソフトウェア・ホームとともにリカバリされた場合(おそらくはプライマリOMSインストール・リカバリで、agentおよびagent_instディレクトリが一般的なMiddlewareホームの下にある場合)、管理エージェントとOMS間の整合性を保証するために、管理エージェント・インスタンス・ディレクトリを再作成する必要があります。
1. バックアップからリストアされた場合、agent_instディレクトリを削除します。
2. agentDeploy.shを使用して、次のように管理エージェントを構成します。
```
<AGENT_HOME>/core/13.4.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>
```
3. OMSが管理エージェントをブロックすることがあります。次のコマンドを使用してエージェントをリポジトリと同期化します。
  
  <OMS_HOME>/bin/emcli resyncAgent -agent=<agent target name e.g. myhost.example.com:3872>
管理エージェント・ソフトウェア・ホームがOMSとともにリカバリされず、引き続き管理エージェントをリカバリする必要がある場合、「同じポートを使用したエージェントの再インストール」の項の手順に従ってください。

ノート:

これは、管理エージェント・ソフトウェア・ホームのバックアップを含まない、ファイルシステムのリカバリが実行された場合にのみ必要になる可能性があります。OMSソフトウェア・ホームがソフトウェア専用インストール方法を使用してリカバリされた場合は、Middlewareホームの下の管理エージェント・ソフトウェア・ホームにインストールされるため、このステップは必要ありません。
サイトが完全に動作していることを確認します。

複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ

サイトは複数のOMSインスタンスをホストします。OMSインスタンスの前にサーバー・ロード・バランサがあります。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAのプライマリOMSが失われたため、ホストBでリカバリする必要があります。

必要ならば、障害の発生したOMSホストでクリーンアップを実行します。

次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。
```
ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9
```
ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。
ホストBにソフトウェア・ホームをリストアします。詳細は、「ソフトウェア・ホームのリカバリ」を参照してください。
以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。
```
<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>
```
ノート:

渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。
OMSを開始します。
```
<OMS_HOME>/bin/emctl start oms
```
管理エージェントを構成します。

エージェントはソフトウェア専用インストールの一部としてインストールされ、agentDeploy.shコマンドを使用して構成される必要があります。
```
<AGENT_BASE_DIR>/agent_13.4.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>
```
失敗したエージェントにデフォルト以外のプラグインが以前デプロイされていた場合、エージェントのリカバリ後にそれらを再デプロイする必要があります。これは、リカバリしているエージェントに失敗の前から存在したプラグインに関連し(OMS/リポジトリ・ターゲットには関連しません)、また、OMSエージェントが偶然モニタリングしていた追加ターゲットの任意のプラグインに関連することに注意してください。プラグインを再デプロイするには、次のコマンドを実行します(config emrepの一部としてではなく、また手動でもない)。

emcli relocate_targets
追加の管理サービスがある場合は、現在ホストBで実行中の管理サーバーに再登録する必要があります。管理サービスを再登録するには、追加のOMSのそれぞれで次のコマンドを実行します。

<OMS-HOME>/bin/emctl enroll oms -as_host <new Admin Server host, i.e. host B> -as_port <admin server port>
新しいOMSをSLB仮想サーバー・プールに追加して古いOMSを削除します。
次のコマンドを使用し、oracle_emrepターゲットを新しいOMSホストの管理エージェントに再配置します。
```
<OMS_HOME>/bin/emcli sync
<OMS_HOME>/bin/emctl config emrep -agent <agent on host "B", e.g myNewOMSHost.example.com:3872>
```
ノート:

emctl config emrep -agentを実行し、フラグ-ignore_timeskewを設定した場合、管理サービスとリポジトリ・ターゲットが新しいエージェントに移動されたときにモニター対象ターゲットの可用性が影響を受けてモニタリング・データが失われることがあります。
Cloud Controlコンソールで、Cloud ControlドメインのWebLogic Domainターゲットを再配置します。「モニタリング資格証明」に移動して管理ホストをホストBに更新します。「WebLogicドメインのリフレッシュ」を実行して新しいホストでドメインを再構成します。
重複したターゲットを、Enterprise Managerコンソールの「管理サービスとリポジトリ概要」ページで探します。「重複したターゲット」リンクをクリックして「重複したターゲット」ページにアクセスします。重複したターゲットのエラーを解決するには、競合している管理エージェントで重複しているターゲットの名前を変更する必要があります。重複したターゲットを管理エージェントAから管理エージェントBに再配置します。
元のOMSが使用されなくなったと仮定し、「ターゲット」、「ホスト」ページの順に選択して「削除」をクリックすることで、ホスト・ターゲット(すべての残りのモニター対象ターゲットを含む)をCloud Controlから削除します。最初にすべての管理対象ターゲットを削除することを知らせるエラーが表示されます。それらのターゲットを削除してから、ホスト・ターゲットを正常に削除するステップを繰り返します。
システム内の他のすべてのOMSは、次のコマンドを使用して、新しくリカバリされたOMSに再登録する必要があります。
```
emctl enroll oms -as_host <new OMS host> -as_port <port #, default 7101> 
```
サイトが完全に動作していることを確認します。

複数OMS、SLB構成済、追加OMSが同一または別のホスト上でリカバリ

OMSインスタンスがSLBの前にある、複数OMSサイト。OMS構成は最初のOMSでemctl exportconfig omsコマンドを使用してバックアップされました。追加のOMSが失われたため、同一または別のホストでリカバリする必要があります。

同じホストにリカバリされている場合、障害の発生したOMSのクリーンアップが実行されたことを確認します。

次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。
```
ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9
```
Cloud Controlソフトウェアのディストリビューション・インストーラを使用して、最初に既存のOracleホームを削除します。ソフトウェア・ホームが使用可能でなくなっている場合にも、失われたOracleホームのレコードをOracleインベントリから削除する必要があるので、これは必要です。

存在する場合、Middlewareおよびgc_instディレクトリを削除します。
共有ソフトウェア・ライブラリの場所がアクセスできることを確認します。
必要なホスト(場合によって同じまたは異なる)に管理エージェントをインストールします。
追加のOracle Management Serviceをインストールする手順については、サイレント・モードでの追加のOracle Management Serviceのインストールを参照してください。
サイトが完全に動作していることを確認します。

ソフトウェア・ライブラリのリカバリ

ソフトウェア・ライブラリが失われた場合、使用可能な最後のバックアップからリストアする必要があります。バックアップをリストアした後、不足しているエンティティを検証および再インポートするために次のコマンドを実行する必要があります。

emcli verify_swlib - このコマンドは、ソフトウェア・ライブラリの記憶域の場所へのアクセシビリティを検証し、エンティティにファイルシステムのファイルがない場合には報告します。
emcli reimport_swlib_metadata - このコマンドは、製品とともに出荷されたオラクル社提供のすべてのエンティティを再インポートします。最新のバックアップがある場合、これは必要ありません。emcli verify_swlibコマンドによって、Oracle所有エンティティのファイルがファイルシステムからなくなっていることが報告された場合、emcli reimport_swlib_metadataを実行します。
emcli verify_updates - このコマンドは、自己更新によってダウンロードされたエンティティがソフトウェア・ライブラリからなくなっているかどうかを検証します。不足している各エンティティについて、ソフトウェア・ライブラリに再インポートする手順もコマンドによって表示されます。

管理エージェントのリカバリ

管理エージェントが失われた場合、参照インストールからクローニングして再インストールする必要があります。通常、参照インストールからのクローニングは、カスタマイズおよびパッチの追跡および再適用が不要なため、管理エージェント・インストールをリカバリする最速の方法です。同一ポートを使用して管理エージェントを再インストールする場合は、注意が必要です。Enterprise Managerの管理エージェントの再同期化機能を使用すると、再インストールされた管理エージェントを、管理リポジトリに存在するターゲット情報を使用して再構成できます。

クローン・オプションを使用することでエージェントを再インストールしていない場合は、新しいエージェントをインストールした後にパッチを再適用する必要があります。

ノート:

管理エージェントの再同期化は、Enterprise Managerのスーパー管理者のみが実行できます。

同一ポートを使用して管理エージェントを再インストールする場合、OMSは、再インストールであることを検出し、以前に行われたカスタマイズが再インストールされる管理エージェント内の自動検出ターゲットによって上書きされるのを防ぐため、管理エージェントを一時的にブロックします。

ノート:

これは、ブロックされた管理エージェントからのすべてのハートビートまたはアップロード・リクエストをOMSが拒否している状態です。このため、ブロックされたエージェントは、アラートまたはメトリック・データをOMSにアップロードできません。ただし、ブロックされた管理エージェントは、モニタリング・データの収集は続行します。

エージェントは、複数ある条件のいずれかが原因でブロックされることがあります。これらを次に示します。

Enterprise Managerが、エージェントがバックアップからリストアされたことを検出しました。
エージェント上のプラグインが、管理リポジトリの記録と一致しません。
ユーザーが手動でエージェントをブロックしました。

最初の2つの条件では、エージェントの状態をクリアし管理リポジトリからプラグインをプッシュして、エージェントのブロックを解除するために、エージェントの再同期化が必要になります。

emcli resyncAgent <agent target name>コマンドを使用すると、管理エージェントのホームページで管理エージェントを再同期化およびブロック解除できます。再同期化は、管理リポジトリから管理エージェントにすべてのターゲットをプッシュして、エージェントのブロックを解除します。

管理エージェントのリカバリ・シナリオ

次の各シナリオでは、様々な管理エージェントのリカバリ状況とそのリカバリ・ステップを示します。管理エージェントの再同期化機能では、再インストールした管理エージェントは、クラッシュした、前の管理エージェントと同じポートを使用する必要があります。

ノート:

管理エージェントの再同期化は、Enterprise Managerのスーパー管理者のみが実行できます。

同じポートを使用した管理エージェントの再インストール

管理エージェントは複数のターゲットをモニタリングしています。エージェント・インストールが失われました。

Oracle Universal Installerを使用して、エージェントのOracleホームを削除します。

ノート:

このステップはインベントリをクリーンアップするために必要です。
新しい管理エージェントをインストールするか管理エージェントのクローニング・オプションを使用して、Enterprise Manager経由で管理エージェントを再インストールします。クラッシュしたエージェントが使用していたものと同じポートを指定します。インストールの場所は、以前のインストールと同じである必要があります。

OMSによって、管理エージェントが再インストールされたことが検出され、管理エージェントがブロックされます。
次のコマンドを使用して、管理エージェントの再同期化を開始します。

emcli resyncAgent -agent="Agent Host:Port"

管理リポジトリのすべてのターゲットが新しい管理エージェントにプッシュされます。エージェントはバックログ・ファイルのクリアを指示されるため、クリア状態にします。エージェントは非ブロック化されます。
ユーザー定義メトリックのスクリプトの場所が変更された場合は、ユーザー定義メトリックを再構成します。
次のemctlコマンドを使用して、管理エージェントが操作可能で、すべてのターゲット構成がリストアされたことを確認します。
```
emctl status agent 
emctl upload agent 
```
エラーがなく、バックログにXMLファイルがないことを確認します。

ファイルシステム・バックアップからの管理エージェントのリストア

単一の管理エージェントが複数のターゲットをモニタリングしています。エージェントOracleホームのファイルシステム・バックアップがあります。エージェント・インストールが失われました。

管理エージェントをファイルシステム・バックアップからリストアして、管理エージェントを起動します。

OMSによって、管理エージェントがバックアップからリストアされたことが検出され、管理エージェントがブロックされます。
次のコマンドを使用して、管理エージェントの再同期化を開始します。

emcli resyncAgent -agent="Agent Host:Port"

管理リポジトリのすべてのターゲットが新しい管理エージェントにプッシュされます。エージェントはバックログ・ファイルのクリアを指示されるため、クリア状態にします。管理エージェントはブロック解除されます。
次のemctlコマンドを使用して、管理エージェントが機能しており、すべてのターゲット構成がリストアされたことを確認します。
```
emctl status agent
emctl upload agent 
```
エラーがなく、バックログにXMLファイルがないことを確認します。

OMSと管理リポジトリの同時障害からのリカバリ

OMSと管理リポジトリの両方に障害が同時に発生した場合は、両方のリカバリを同一または別のホスト上で行う必要があるかどうか、複数のOMSインスタンスの前にSLBがあるかどうかなどの要因に応じて、リカバリ状況がより複雑になります。一般に、このタイプの複合障害のリカバリでは、前述の該当するリカバリ・シナリオで説明されているステップに従い、まず管理リポジトリを、次にOMSインスタンスをリカバリします。次の各シナリオでは、OMSと管理リポジトリの2つの障害と、それに必要なリカバリ・ステップを示します。

縮小構成: 管理リポジトリの不完全リカバリ、同じホスト上のプライマリOMS

管理リポジトリおよびプライマリOMSは同じホスト(ホストA)にインストールされています。管理リポジトリ・データベースは、ホストAでnoarchivelogモードで実行中です。全体コールド・バックアップがあります。最新のOMSバックアップ・ファイルがあります(emctl exportconfig oms)。管理リポジトリ、OMSおよび管理エージェントのクラッシュ。

「同一ホスト上の不完全リカバリ」に示す管理リポジトリのリカバリ手順に従いますが、次の点が異なります。

OMS Oracleホームが使用できず、リストアした管理リポジトリに対してOMSを起動する前に管理リポジトリの再同期化を開始する必要があるため、PL/SQLブロックで「resync」を発行します。SQLplusを使用して管理リポジトリにSYSMANでログインし、次のコマンドを実行します。
```
begin emd_maintenance.full_repository_resync('<resync name>'); end;
```
「単一OMS、サーバー・ロード・バランサ(SLB)なし、OMSを同一ホスト上でリストア」に示すOMSリカバリ手順に従います。
サイトが完全に動作していることを確認します。

分散構成: 別のホスト上の管理リポジトリの不完全リカバリ、プライマリOMSおよび追加OMS、SLB構成済

管理リポジトリ、プライマリOMSおよび追加OMSはすべて、異なるホスト上にあります。管理リポジトリ・データベースは、ホストAでnoarchivelogモードで実行中でした。最新のバックアップのOMSバックアップ・ファイルがあります(emctl exportconfig oms)。データベースの全体コールド・バックアップがあります。3つのホストすべてが失われました。

「同一ホスト上の不完全リカバリ」に示す管理リポジトリのリカバリ手順に従いますが、次の点が異なります。

OMS Oracleホームが使用できず、リストアした管理リポジトリに対してOMSを起動する前に管理リポジトリの再同期化を開始する必要があるため、PL/SQLブロックで「resync」を発行します。SQLplusを使用して管理リポジトリにSYSMANでログインし、次のコマンドを実行します。
```
begin emd_maintenance.full_repository_resync('resync name'); end;
```
「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示すOMSリカバリ手順に従います。次の例外があります。

バックアップ・ファイルにある管理リポジトリ接続記述をオーバーライドするには、追加のomscaパラメータを渡します。
```
-REPOS_CONN_STR <restored repos descriptor>
```
「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示す他のパラメータとともにこのパラメータを追加する必要があります。
「複数OMS、SLB構成済、追加OMSを同一または別のホスト上でリカバリ」に示すOMSリカバリ手順に従います。
サイトが完全に動作していることを確認します。