ヘッダーをスキップ
Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド
12cリリース4 (12.1.0.4)
B65086-14
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

4 Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース4 (12.1.0.4)へのアップグレードの開始

この章では、Enterprise Manager 12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)を12cリリース4 (12.1.0.4)にアップグレードするための高度なプロセスについて説明します。

この章の具体的な内容は次のとおりです。


注意:

  • Oracle Management Service 12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済または未適用]がある場合、最初にこれを12cリリース2 (12.1.0.2)または12cリリース3 (12.1.0.3)にアップグレードしてから、12cリリース4 (12.1.0.4)にアップグレードします。

    12cリリース2 (12.1.0.2)または12cリリース3 (12.1.0.3)へのアップグレード手順は、Enterprise Managerドキュメント・ライブラリにあるそれぞれのリリースの『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

    http://docs.oracle.com/cd/E24628_01/index.htm

  • Oracle Management Service 12cリリース2 (12.1.0.2)または12cリリース3 (12.1.0.3)と通信するOracle Management Agent 12cリリース1 (12.1.0.1)がある場合、Oracle Management Serviceを12cリリース4 (12.1.0.4)にアップグレードする前に、Enterprise Manager Cloud Control Consoleにあるエージェント・アップグレード・コンソールを使用してOracle Management Agent 12cリリース1 (12.1.0.1)を12cリリース2 (12.1.0.2)または12cリリース3 (12.1.0.3)にアップグレードすることを確認してください。

    これは、Oracle Management Service 12cリリース2 (12.1.0.2)または12cリリース3 (12.1.0.3)から12cリリース4 (12.1.0.4)へのアップグレードの前提条件です。

  • アップグレードを正常に完了するための追加の準備手順については、My Oracle Supportのノート1682332.1を参照してください。


警告:

旧リリース(10.2.0.5または11.1.0.1)からの2システム・アップグレードが進行中の間は、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)をアップグレードしないでください。アップグレードが進行中の間はステータスが保留中状態のスタンドアロン管理エージェントが存在する可能性があるため、アップグレードが完全に終わるまで待機します。

4.1 単一OMSまたは複数OMSの非HA環境でのEnterprise Manager Cloud Control 12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース4 (12.1.0.4)へのアップグレード


注意:

Enterprise Managerシステムのアップグレードを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を確認して2014年9月と10月および2015年1月にリリースされたプラグインについて学習し、このプラグイン・リリースに関する使用例を理解することをお薦めします。現在の要件に最適な使用例を確認し、この表の使用例に示される詳細な手順に従ってください。

表4-1に、単一OMSまたは複数OMSでHA (高可用性)以外の環境において、Enterprise Managerを12cリリース4 (12.1.0.4)にアップグレードする手順を示します。

表4-1 単一OMSの非HA環境でのEnterprise Manager Cloud Controlの12cリリース4 (12.1.0.4)へのアップグレード

手順番号 手順 プロシージャ

手順1

準備

(a)

1システム・アップグレード方式について学習します。

第2.1項

(b)

開始する前に理解しておく必要のある重要事項を確認します。

第3章

手順2

Oracle Management ServiceおよびOracle Management Repositoryのアップグレード

(a)

次の前提条件を満たします。

  • 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章で説明されているOracle Management Service関係の前提条件を満たします。

  • 12cリリース4 (12.1.0.4)へのアップグレードはアウトオブプレース・アップグレードであるため、ホストが、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載されている12cリリース4 (12.1.0.4)固有のハードウェア要件を満たしていることを確認します。ここで、ホストとは、アップグレードする現在のEnterprise Managerを実行しているホストを表します。

  • 第3.3項で示されている、サポートされているプラットフォームのみでアップグレードを行うようにします。

  • Enterprise Managerで使用されるポートが、1024以下の値に設定されていないことを確認します。この値以下に設定されている場合、アップグレードは失敗します。1024以下のポートは、一般にルート・ユーザー(スーパー・ユーザー)用に予約されています。このため、ポートは1024より大きくしてください。

  • OMS (ミドルウェア・ホームおよびインベントリ)、管理リポジトリおよびソフトウェア・ライブラリをバックアップします。アップグレードが失敗した場合、常にバックアップを使用してリストアできます。バックアップの手順は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

  • 電子メール通知を受信するために使用しているシステム既知のルール・セットのコピーを作成します(「類似作成」操作を使用します)。そうしないと、ルール・セットに対して作成された電子メール・サブスクリプションが失われることになります。

    コピーを作成するには、「設定」メニューから、「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール - すべてのエンタープライズ・ルール・ページの表で、コピーするシステム既存のルール・セットを選択します。次に、「アクション」メニューから、「ルール・セットの類似作成」を選択します。ルール・セットの類似作成ページで、必要な情報を指定して「保存」をクリックします。

  • 次のディレクトリの内容がすべてのOMSホストで同じであることを確認します。OMSホストによってプラグインの数またはリビジョンが異なる場合は、いずれかのpluginextract_with_revディレクトリから別のディレクトリにコピーして確実に一貫性を持たせます。

    <OMS_HOME>/sysman/install/pluginextract_with_rev

    たとえば、最初のOMSホストOMS_Host1に、次のリビジョンのプラグインがあるものとします。

    「oracle.sysman.emfa 12.1.0.1.0および12.1.0.2.0」「oracle.sysman.bda 12.1.0.1.0、12.1.0.2.0および12.1.0.3.0」「oracle.em.sidb 12.1.0.1.0および12.1.0.2.0」

    追加OMSホストOMS_Host2には、「oracle.sysman.emfa 12.1.0.1.0および12.1.0.2.0」「oracle.sysman.bda 12.1.0.3.0」「oracle.em.sehc 12.1.0.1.0」のプラグインがあるものとします。

    この場合、最初のOMSホストから追加OMSに「oracle.sysman.bda 12.1.0.1.0および12.1.0.2.0」「oracle.em.sidb 12.1.0.1.0および12.1.0.2.0」を、追加OMSホストから最初のOMSホストに「oracle.em.sehc 12.1.0.1.0」を確実にコピーします。これによって、両方のOMSホストのプラグインおよびそのリビジョンに一貫性が保たれます。

  • OMSに次のいずれかのカスタマイズを行った場合は、アップグレード・プロセスを開始する前にすべてを削除してください。アップグレードが完了した後で、再びカスタマイズすることができます。

    • Weblogicでの追加データソース・パラメータの構成

    • 追加のサードパーティSSL証明書

    • Enterprise Managerログインのためのスマート・カード認証

(b)

アップグレードするEnterprise Manager Cloud Control 12cインストールにOracle BI Publisherがインストール済の場合は、WebLogic管理コンソールを使用してBIPという名前のBI Publisher管理対象サーバーを停止します。

Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)へのアップグレードの一部として、Oracle BI Publisher 11.1.1.7.0が自動的にミドルウェア・ホームにインストールされます。ただし、Oracle BI Publisherはデフォルトでインストールされますが、デフォルトでは構成または旧バージョンからのアップグレードは行われません。したがって、12cリリース4 (12.1.0.4)へのアップグレード後に手動でOracle BI Publisherを構成し、すべてのデータおよびレポートを古いBI Publisherホームから新しいホームへ移行する必要があります。手順は、手順4 (f)を参照してください。

(c)

未処理のデータベース・サービスのインスタンス作成リクエストがあるか確認します。進行中のリクエストがある場合は、完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。

これを行うには、次の手順を実行します。

  1. Cloud Controlで、「エンタープライズ」メニューから、「クラウド」、「セルフ・サービス・ポータル」の順に選択します。

  2. インフラストラクチャ・クラウド・セルフ・サービス・ポータル・ページで、ページ・タイトルのすぐ下で、「マイ・データベース」を選択してデータベース・リクエストのみを参照します。

  3. 「リクエスト」表で、進行中のリクエストについては完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。

    スケジュールされたリクエストを一時停止するには、リクエスト名をクリックします。「デプロイ」タブをクリックします。そこにリストされたデプロイメント・プロシージャをクリックして、一時停止します。

(d)

管理リポジトリ内の表でスナップショットが作成されていないことを確認します。

これを確認するには、管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行します。

select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER>

次に例を示します。

select master , log_table from all_mview_logs where log_owner='SYSMAN'

作成されたスナップショットが表にある場合、マスター表およびスナップショットの詳細が表示されます。次に例を示します。

SQL> master log_table

em-violations em$violation_log

スナップショットがある場合は、SYSMANユーザーとして次のコマンドを実行して削除します。

SQL> Drop snapshot log on <master>

次に例を示します。

SQL> Drop snapshot log on em-violations

(e)

Oracle Management Repositoryを格納しているOracle Databaseにログインまたはログオン・トリガー設定をしていないことを確認してください。

これを確認するには、データベースにログインして次の問合せを実行します。

  • ログイン・トリガーが設定されているかどうかを確認するには、次を実行します。

    SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';

    SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';

  • ログオフ・トリガーが設定されているかどうかを確認するには、次を実行します。

    SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';

    SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';

問合せ結果がゼロ以外の場合、または行が選択されない場合は、トリガーを手動で無効にします。アップグレード完了後に、これらを再度有効化できます。

このようなトリガーを無効化するには、次の問合せを実行します。

SQL> alter trigger <trigger_name> disable;

次に例を示します。

SQL> alter trigger EXPFIL_ALTEREXPTAB_MAINT disable;

(f)

ターゲットの削除操作の監査を有効にします。

  • 操作のリストを表示するには、次のコマンドを実行します。

    emcli show_operation_list

    削除操作には、ターゲットの削除、名前付き資格証明の削除、ロールの削除、ルールの削除、モニタリング・テンプレートの削除、ユーザーの削除などがあります。

  • 現在有効になっている削除操作を確認するには、次のコマンドを実行します。

    emcli show_audit_settings

  • ターゲットの削除操作がまで有効になっていない場合は、次のコマンドを実行して有効にします。

    emcli update_audit_settings

    -operations_to_enable="name_of_the_operations_to_enable._For_all_operations_use_ALL"

    -audit_switch="ENABLE

    -directory="db_directory_name' (エクスポート・サービスが監査データ・ファイルをアーカイブするOSディレクトリで構成する必要があります)

    -file_prefix="file_prefix" (エクスポート・サービスによって使用され、監査データを書き込む必要がありファイル名を作成します。デフォルト値はem_auditです。すべてのサイトで標準に応じて変更できます)

    -file_size="file_size (Bytes)" (各ファイル・サイズの最小値。このデフォルト値は5000000バイトです)

    -data_retention_period="data_retention_period (Days)" (Enterprise Managerリポジトリに監査データが格納される最大期間。デフォルト値は365日です)

    前述のパラメータは、保存期間後に、監査データを管理リポジトリからファイル・システムにアーカイブするために、アーカイブの場所を設定または構成するのに役に立ちます。すべてのサイトでこれを標準化します。

(g)

(クリティカルな必須手順)

データベースに次のパッチを適用します。My Oracle Supportにアクセスすると、これらのパッチを検索できます。手順については、そのパッチに関連付けられたReadMeファイルを参照してください。これらのパッチを適用しない場合、アップグレードが失敗し、この失敗は修正することができません。

Oracle Database 11リリース1 (11.1.0.7)の場合:

  • Unixプラットフォームでは、パッチ17082366 (パッチ・セット更新17)を適用します。その後、パッチ9577583およびパッチ8405205を適用します。

  • Microsoft Windows (32ビットおよび64ビット)プラットフォームでは、パッチ17363760 (パッチ54)を適用します。

Oracle Database 11gリリース2(11.2.0.1)の場合

  • Unixプラットフォームでは、パッチ12419378 (パッチ・セット更新6)を適用します。

  • Microsoft Windows (64ビット)プラットフォームでは、パッチ13423278 (パッチ16)を適用します。

Oracle Database 11gリリース2(11.2.0.2)の場合

  • Unixプラットフォームでは、パッチ11061801および9748749を適用します。

  • Microsoft Windows (32ビット)プラットフォームでは、パッチ11061801およびパッチ12429530を適用します。

  • Microsoft Windows (64ビット)プラットフォームでは、パッチ11061801およびパッチ12429531を適用します。

Oracle Database 11gリリース2(11.2.0.3)、10gリリース2 (10.2.0.5)の場合

UnixおよびMicrosoft Windowsプラットフォームでは、パッチ11061801を適用します。

注意: パッチ13496395の適用もお薦めします。どのデータベース・リリースにパッチを適用できるかの詳細は、パッチとともにパッケージ化されているReadMeを参照してください。

(h)

[複数OMSアップグレードの場合、最初のOMSアップグレードのみでこの手順を実行してください]

既存のOMSから既存の管理リポジトリにemkeyをコピーします。これを実行するには、アップグレードしようとしている古いOMSホームで次のコマンドを実行します。

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

emkeyがコピーされているかどうか検証するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emctl status emkey

emkeyがコピーされている場合、次のメッセージが表示されます。

The EMKey  is configured properly, but is not secure.
Secure the EMKey by running "emctl config emkey -remove_from_repos".

(i)

OMSインスタンス用のデフォルトの即時実行可能なメモリー設定を変更している場合、変更を保持して、アップグレード時に失われないようにします。

変更を保持するには、次の手順を実行します。

  1. すべてのOMSインスタンス上で次のコマンドを実行します。

    $<OMS_HOME>/bin/emctl set property -name 'JAVA_EM_MEM_ARGS' -value '<java_memory_arguments>'

    次に例を示します。

    $<OMS_HOME>/bin/emctl set property -name 'JAVA_EM_MEM_ARGS' -value '-Xms256m -Xmx1740m'

  2. すべてのOMSインスタンスを再起動します。

    $<OMS_HOME>/bin/emctl stop oms -all

    $<OMS_HOME>/bin/emctl start oms

(j)

これからアップグレードするOMSを停止して、これに接続されているその他のOMSインスタンスも停止します。

重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、この手順をスキップします。第5.3.1項または第5.4.1項に記載されているように、ソフトウェア・バイナリをコピーした後でOMSインスタンスを停止できます。

  1. 前提条件として、JVMDおよびADPエンジンを明示的に停止します。

    • サイレント・モードでこれらを停止するには、次のコマンドを実行します。

      $<OMS_HOME>/bin/emctl extended oms jvmd stop -all

      $<OMS_HOME>/bin/emctl extended oms adp stop –all

    • グラフィック・モードでこれらを停止するには、WebLogicコンソールにアクセスし、JVMDおよびADP WebLogic管理対象サーバーを手動で停止します。

  2. 次に、これからアップグレードするOMSを停止し、これに接続されているその他のOMSインスタンスも停止します。

    $<OMS_HOME>/bin/emctl stop oms -all

(k)

管理エージェントがメトリック収集のために管理リポジトリに接続しないように、「管理サービスとリポジトリ」ターゲットを監視する管理エージェントを停止します。この管理エージェントを停止しないと、OMSアップグレードが失敗する可能性があります。

重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、この手順をスキップします。第5.3.1項または第5.4.1項に記載されているように、ソフトウェア・バイナリをコピーした後で管理エージェントを停止できます。

(l)

OMSと管理リポジトリをアップグレードします。グラフィック・モードとサイレント・モードのどちらでアップグレードするかを選択できます。ある時点でソフトウェア・バイナリをインストールし、後でグラフィック・モードまたはサイレント・モードでアップグレードすることも選択できます。

emkeyをコピーしていないことを示すエラー・メッセージが表示される場合は、次の手順を実行します。

  1. 古いOMSから古い管理リポジトリにemkeyをコピーします。これを実行するには、アップグレードしようとしている古いOMSホームから次のコマンドを実行します。

    $<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"<conndesc>"' -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

    次に例を示します。

    /u01/software/oracle/middleware/oms/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.mydomain.com)(PORT=1521)))(CONNECT_DATA=(SID=emrepos12)))"' -repos_user sysman -emkey_file /u01/software/oracle/middleware/oms/sysman/config/emkey.ora

    注意: ここで、管理リポジトリの詳細は、アップグレードしようとしている既存の管理リポジトリの詳細です。<OMS_HOME>は、アップグレードしようとしているOMSホームです。

  2. OMSおよび管理リポジトリのアップグレードを再試行します。

重要: 古いOMSをアップグレードした後すぐに、古いOMSとともにインストールされた管理エージェント(つまり中央エージェント)をアップグレードしてください。この管理エージェントをアップグレードするには、エージェント・アップグレード・コンソールを使用します。

第5.1項、第5.2項、第5.3項または第5.4項

手順3

Oracle Management Agentのアップグレード

(a)

管理エージェントのアップグレードを開始する前に理解しておく必要のある重要事項を確認します。

第6.2項

(b)

前提条件を満たします。

第6.3項

(c)

手順2 (k)で停止した管理エージェントを確実に再起動します。

(d)

管理エージェントをアップグレードします。

重要: 古いOMSをアップグレードした後すぐに、古いOMSとともにインストールされた管理エージェント(つまり中央エージェント)をアップグレードしてください。この管理エージェントをアップグレードするには、エージェント・アップグレード・コンソールを使用します。

第6.4項

手順4

アップグレード後のタスクの実行

(a)

アップグレード後のタスクを実行します。

第12.6.1項

(b)

カスタム証明書を使用してOracle WebLogic Serverを再構成します。

第12.6.15項

(c)

遅延データ移行ジョブのステータスを追跡します。

第12.7.2項

(d)

不要な中央エージェントを削除します。

第12.13.2項

(e)

アプリケーションの依存性とパフォーマンス(ADP)・エンジンと、JVM診断(JVMD)エンジンをアップグレードします。

第7章

(f)

Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)へのアップグレードの一部として、Oracle BI Publisher 11.1.1.7.0が自動的にインストールされます。したがって、Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)を含むミドルウェア・ホームには、いずれのバージョンのOracle BI Publisherのソフトウェアのみをインストールしないでください。ただし、Oracle BI Publisherはデフォルトでインストールされますが、デフォルトでは構成または旧バージョンからのアップグレードは行われません。

  • 旧リリースにOracle BI Publisherがない場合は、新しくインストールされたものを構成します。

  • すでに旧リリースにOracle BI Publisherがある場合は、旧リリースをアップグレードし、すべてのデータおよびレポートを古いBI Publisherホームから新しいホームへ移行します。

新しくインストールされたOracle BI Publisherを構成するには、『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』を参照してください。

Oracle BI Publisherをアップグレードしてレポートを移行するには、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

(g)

古いOMSホームを削除します。

第12.15項

4.2 HA環境(プライマリ・サイトおよびスタンバイ・サイト)でのEnterprise Manager Cloud Control 12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース4 (12.1.0.4)へのアップグレード

この項では、HA (高可用性)環境で、プライマリおよびスタンバイEnterprise Managerサイトを12cリリース4 (12.1.0.4)にアップグレードする方法を示します。この項の具体的な内容は次のとおりです。


注意:

Enterprise Managerシステムのアップグレードを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を確認して2014年9月と10月および2015年1月にリリースされたプラグインについて学習し、このプラグイン・リリースに関する使用例を理解することをお薦めします。現在の要件に最適な使用例を確認し、この表の使用例に示される詳細な手順に従ってください。

4.2.1 記憶域レプリケーションを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

表4-2では、記憶域レプリケーションを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレードする手順を説明しています。


注意:

この手順の一部としてスタンバイOMSを削除する必要はありません。

表4-2 記憶域レプリケーションを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

手順番号 手順 プロシージャ

手順1

プライマリOMSのアップグレード

プライマリEnterprise Managerサイト、OMSおよび管理エージェントの両方をアップグレードします。

アップグレード・プロセス時にプライマリOMSが停止するため、停止時間が発生します。

第4.1項

手順2

スタンバイ・ストレージ・サーバー上の新しいミドルウェア・ホームの検証

新しいミドルウェア・ホームもスタンバイ・ストレージ・サーバーにレプリケートされていることを確認するために、システム管理者に連絡をします。

4.2.2 スタンバイWebLogicドメインを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

表4-3では、スタンバイWebLogicドメインを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレードする手順を説明しています。

表4-3 スタンバイWebLogicドメインを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

手順番号 手順 プロシージャ

手順1

スタンバイOMSの削除

(a)

すべての追加スタンバイOMSインスタンスを削除します。

追加のすべてのスタンバイOMSインスタンスを削除するには、Oracle Enterprise Managerアドバンスト・インストレーションおよび構成に関するガイドの追加のスタンバイOMSインスタンスの削除に関する項を参照してください。

(b)

最初のスタンバイOMSを削除します。

最初のスタンバイOMSを削除するには、Oracle Enterprise Managerアドバンスト・インストレーションおよび構成に関するガイドの最初のスタンバイOMSの削除に関する項を参照してください。

手順2

プライマリOMSのアップグレード

プライマリEnterprise Managerサイト、OMSおよび管理エージェントの両方をアップグレードします。

第4.1項

手順3

スタンバイOMSの再デプロイ

スタンバイWebLogicドメインを使用してスタンバイOMS環境を再作成します。

スタンバイWebLogicドメインを使用してスタンバイOMS環境を再作成するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』の障害時リカバリに関する章を参照してください。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引