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

前
 
次
 

2 作業開始前の予備知識

アップグレード方式を使用してEnterprise Manager Cloud Controlにアップグレードする前に、次の点を考慮してください。

サポートされているアップグレード・パス

次のアップグレード・パスがサポートされています。

表2-1 サポートされているアップグレード・パス

アップグレード前 アップグレード後

バンドル・パッチ1を未適用の12cリリース1 (12.1.0.1)

12cリリース2 (12.1.0.2)

バンドル・パッチ1を適用済の12cリリース1 (12.1.0.1)

12cリリース2 (12.1.0.2)

バンドル・パッチ1をデフォルトで組込み済の12cリリース1 (12.1.0.1)

12cリリース2 (12.1.0.2)

11gリリース1 (11.1.0.1)

12cリリース2 (12.1.0.2)

10gリリース5 (10.2.0.5)

12cリリース2 (12.1.0.2)

10gリリース4 (10.2.0.4)以下

最初に10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)にアップグレードしてから、12cリリース2 (12.1.0.2)にアップグレード

10gリリース1 (10.1)

最初に10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)にアップグレードしてから、12cリリース2 (12.1.0.2)にアップグレード


サポートされているアップグレード方式

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済または未適用]を直接Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)にアップグレードする場合、1システム・アップグレード方式のみがサポートされています。

Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からEnterprise Manager Cloud Control 12cリリース2 (12.1.0.2)にアップグレードする場合、3つすべてのアップグレード方式(1システム、2システム、異なるホスト上の1システム)がサポートされています。

アップグレードでサポートされているプラットフォーム

次のプラットフォームがサポートされています。

アップグレードの範囲

ここでは、アップグレード方式について説明します。

既存ポートの再使用

管理エージェントをアップグレードすると、旧リリースの管理エージェントで使用されていたポートは、アップグレード後の管理エージェントに引き継がれます。そのため、ファイアウォール設定には何も影響しません。

OMSをアップグレードすると、次のポートが割り当てられます。


注意:

コア・コンポーネント、ポートが選択される範囲、および割り当てられる空ポートの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』でインストールの基本に関する章を参照してください。

プラグインのアップグレード

この項の内容は次のとおりです。

12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのアップグレード

この項では、Oracle Management Agent 12cリリース1 (12.1.0.1)およびOracle Management Service 12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行して、プラグインをアップグレードする方法について説明します。

特に、次の項目について説明します。

Oracle Management Agent 12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのアップグレード

エージェントのアップグレード・コンソールを使用してOracle Management Agents 12cリリース1 (12.1.0.1)をアップグレードする際、旧リリースのすべてのプラグインはデフォルトでアップグレードされます。手動による操作は必要ありません。

Oracle Management Service 12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのアップグレード

Enterprise Manager Cloud Controlインストール・ウィザードを使用してOracle Management Service 12cリリース1 (12.1.0.1)をアップグレードする際、プラグインは次の状況に基づいて自動的にアップグレード、移行またはデプロイされます。

  • 新しいバージョンが存在する場合、プラグインはアップグレードされます。

  • 新しいバージョンが存在しない場合、プラグインは移行されます。

  • アップグレード対象のプラグインに新しい依存関係が存在する場合、プラグインはデプロイされます。

また、インストール・ウィザードでは「プラグイン・デプロイメント」画面を使用して、自動的にアップグレード、移行またはデプロイされるプラグイン以外にデプロイするオプション・プラグインを選択できます。

「プラグイン・デプロイメント」画面にリストされていないプラグインをインストールする場合は、次の手順に従います。

  • Oracle Technology Network (OTN)のEnterprise Managerダウンロード・ページからプラグインを手動でダウンロードし、アクセス可能な場所に保管します。

    http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

  • 次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。

    UNIXプラットフォームの場合:

    ./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

    Microsoft Windowsプラットフォームの場合:

    setup.exe -pluginLocation <absolute_path_to_plugin_software_location>

10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのアップグレード

アップグレードに必要なプラグインを識別するには、アップグレード前コンソールの「アップグレード前のステップ」セクションで、「ソフトウェアの管理」をクリックします。「ソフトウェアの管理」ページに、システムのアップグレードに必要なプラグインが表示されます。

「ソフトウェアの管理」ページには、既存システムにある古い管理エージェントにより監視されているターゲット、およびEnterprise Manager Cloud Controlの新しいプラグイン要件に基づいてプラグインがリストされます。既存のシステムを正常にアップグレードするには、このページにリストされているプラグインのみが必要です。

この項では、Oracle Management Agents 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)と、Oracle Management Service 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)のアップグレードと並行して、必要なプラグインをダウンロードしてインストール方法を説明します。この項の具体的な内容は次のとおりです。

Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのインストール

管理エージェントをアップグレードしながら、必要なプラグインをインストールするには、次の手順を実行します。

  1. 次のURLにアクセスします。

    http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

  2. 管理エージェント・ソフトウェアをアクセス可能な場所にダウンロードします。ソフトウェアZIPファイルのコンテンツを解凍しないでください。管理エージェント・ソフトウェアはプラットフォームごとに異なるので、インストールするプラットフォーム用のソフトウェアをコピーするようにしてください。

  3. 必要なプラグインをすべて同じ場所にダウンロードします。プラグインは汎用なので、すべてのプラットフォームに共通です。

    プラグインを使用してターゲットを監視するかどうかに関係なく、「ソフトウェアの管理」ページに必要なプラグインとしてリストされているプラグインを必ずすべてダウンロードします。ターゲットの監視に使用しないプラグインは不要と思われることがありますが、システムのアップグレードのときに必要になる場合があります。したがって、管理ソフトウェア・ページにリストされているプラグインはすべてダウンロードしてください。これらのプラグインは、管理リポジトリを含むデータベースをバックアップする前にダウンロードする必要があります。


    注意:

    また、これらのプラグインを<software_kit>/pluginsディレクトリからダウンロードすることもできますが、すべてのプラットフォームに対応した、最新のプラグインを常に入手できますので、OTNからのダウンロードをお薦めします。


    注意:

    必要なプラグインを識別するには、アップグレード前コンソールの「アップグレード前のステップ」セクションで、表から「ソフトウェアの管理」をクリックします。「ソフトウェアの管理」ページの「プラグイン・ソフトウェア」セクションで必要なプラグインを確認してください。

    プラグインを使用してターゲットを監視するかどうかに関係なく、「ソフトウェアの管理」ページに必要なプラグインとしてリストされているプラグインをすべてダウンロードします。ターゲットの監視に使用しないプラグインは不要と思われることがありますが、システムのアップグレードのときに必要になる場合があります。したがって、管理ソフトウェア・ページにリストされているプラグインはすべてダウンロードしてください。また、これらのプラグインは、管理リポジトリを含むデータベースをバックアップする前に必ずダウンロードしてください。


  4. アップグレード前コンソールの「ソフトウェアの管理」ページ(「アップグレード前のステップ」セクション)の「ソフトウェアの場所の指定」セクションで、プラグインの存在するディレクトリの絶対パスを入力し、「検証」をクリックして管理リポジトリにその場所を登録します。


参照:

プラグインの場所の登録および検証の詳細は、「ソフトウェアの管理」を参照してください。

Oracle Management Service 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのインストール

OMSのアップグレードと並行して必要なプラグインをインストールする場合は、Enterprise Manager Cloud Controlインストール・ウィザードを起動して、「プラグイン・デプロイメント」画面に進みます。この画面には、管理エージェントのアップグレード中にアップグレード前コンソール経由で登録した、必要なプラグインがすべてリストされます。必須プラグインはデフォルトで選択されています。


注意:

必要なプラグインの一部を登録しそこなった場合、アップグレードに進む前に、ウィザードからアップグレード前コンソールにアクセスして、そのプラグインを登録するように促すメッセージが表示されます。

この画面にリストされているプラグインに対応したソフトウェアがEnterprise Manager Cloud Controlソフトウェア・キット(DVD、またはダウンロードされたソフトウェア)から入手できることを確認してください。必要なプラグインに対応したソフトウェアが入手できない場合は、次の操作を実行します。

  • Oracle Technology Network (OTN)のEnterprise Managerダウンロード・ページからプラグインを手動でダウンロードし、アクセス可能な場所に保管します。

    http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

  • 次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。

    ./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Oracle Software Libraryの使用

Enterprise Managerのアップグレード後のOracle Software Library(ソフトウェア・ライブラリ)の状態は次のとおりです。

コネクタの使用

Enterprise Managerシステム全体のアップグレード後、従来のEnterprise Managerシステムで構成されたコネクタはEnterprise Manager Cloud Controlでも引き続き動作します。ただし、構成されていなかったものは機能しません。

PDP構成ファイルの更新

Enterprise Managerでは、特定のユーザーによる特定のコマンドの実行を管理者が制限できる、SUDOやPowerBrokerなどの権限委任プロバイダ(PDP)がサポートされています。このような制限的なPDP構成設定がある場合、一般的には構成ファイルでnmosudoの場所を入力する必要があります。管理エージェントでは、Enterprise Managerの信頼されたジョブの実行にnmosudoが使用されます。

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済または未適用]で、nmosudoはエージェント・インスタンス・ディレクトリに配置されました。たとえば、/u01/oracle/agent/agent_inst/bin/nmosudoです。

Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2) [バンドル・パッチ1を適用済または未適用]で、この場所は変更されました。現在、nmosudosbinディレクトリ、つまりエージェント・ベース・ディレクトリに存在します。たとえば、/u01/oracle/agent/sbin/nmosudoです。

したがって、Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)をインストール、またはこのリリースにアップグレードする際、nmosudoの新しい場所を更新するようにPDP構成ファイルを変更する必要があります。

たとえば、SUDOをPDPとして使用する場合、sudoの構成ファイルは一般的に/etc/sudoersにあります。このファイルで、次のエントリをnmosudoの新しい場所について更新します。

sudouser ALL : oracle /eminstall/basedir/sbin/nmosudo * 

通知、アラート、ジョブ、デプロイメント・プロシージャ実行、メトリック、EM CLIクライアント、Oracle Exadataターゲットの管理


注意:

この項は、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合のみ、適用されます。

この項は、Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)からアップグレードする場合は無視できます。


この項は、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする際に認識される、Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)の重要な変更について説明します。

特に、次の項目について説明します。

通知の管理

アップグレード後、すべての通知ルールおよびアラートは引き続きEnterprise Manager Cloud Controlで動作します。ただし、これらは強化されて、より規模が大きく新しい概念に組み込まれ、Enterprise Manager Cloud Controlでは、通知ルールインシデント・ルールセットアラートイベントと呼ばれるようになりました。

インシデント・ルールセットと、これを通知ルールにマップする方法の詳細、およびイベントと、これをアラートにマップする方法の詳細は、付録Bを参照してください。

アラートの管理

アップグレード中、旧リリースからのアラートは次のようにイベントとしてEnterprise Manager Cloud Controlに移行されます。1システム・アップグレード方式では、アラートは、管理リポジトリのアップグレード中に移行されます。2システム・アップグレード方式では、アラートは、管理リポジトリをリモート・ホストにバックアップしている間に移行されます。

この項の内容は次のとおりです。

アラートの移行

アラートの移行は次のように行われます。

  • すべてのオープン・アラートが移行されます。

    表2-2は、各種オープン・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。

  • 管理リポジトリのアップグレードまたはバックアップの180日前にクローズされたアラートはすべて、遅延データ移行プロセスの一部として移行されます。この180日という期間は管理者が変更できます。

    表2-3は、各種クローズド・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。また、クローズド・アラートに関連付けられているチケットがある場合、その情報はイベント移行の一部として取得されないことにも注意してください。

  • 管理リポジトリのアップグレード、またはバックアップから7日前以内に作成されたオープン状態のステートフル・アラート、およびステートレス・アラートはすべて移行されます。


注意:

2システム・アップグレード方式では、アラートが、管理リポジトリのバックアップ後にEnterprise Managerシステムの旧リリースで作成されていた場合、そのオープン・アラートは発生データ移行プロセスの一部として移行されます(表2-2参照)。また、可用性レコードはすべて、発生データ以降プロセスの一部として移行されます。

様々なタイプのオープン・アラートに対応したインシデントおよびイベントの作成

表2-2は、各種オープン・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。

表2-2 様々なタイプのオープン・アラート向けに作成されたインシデントおよびイベント

オープン・アラートのタイプ 作成されたインシデント イベント作成

クリティカル・アラート

はい

はい

警告アラート

いいえ

はい

チケット付きクリティカル・アラート

はい

はい(チケット付き)

チケット付き警告アラート

はい

はい(チケット付き)

通知保留付きの警告アラート

はい

はい

通知保留なしの警告アラート

いいえ

はい

確認付きクリティカル・アラート

はい

はい

確認付き警告アラート

はい

はい


様々なタイプのクローズド・アラートに対応したインシデントおよびイベントの作成

表2-3は、各種クローズド・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。また、クローズド・アラートに関連付けられているチケットがある場合、その情報はイベント移行の一部として取得されないことにも注意してください。

表2-3 様々なタイプのクローズド・アラート向けに作成されたインシデントおよびイベント

クローズド・アラートのタイプ 作成されたインシデント イベント作成

クリティカル・アラート

いいえ

はい

警告アラート

いいえ

はい

チケット付きクリティカル・アラート

いいえ

はい(チケットなし)

チケット付き警告アラート

いいえ

はい(チケットなし)

通知保留付きの警告アラート

いいえ

はい

通知保留なしの警告アラート

いいえ

はい

確認付きクリティカル・アラート

いいえ

はい

確認付き警告アラート

いいえ

はい


ジョブの管理

1システム・アップグレード方式では、ジョブは事実上、期待どおりに実行できます。停止時間内にはジョブは実行されず、停止時間中に実行されていたジョブはすべて、中断されるか、失敗します。また、スケジュール済のジョブはすべて、予定どおり継続されます。

2システム・アップグレード方式では、ジョブの実行方法に多少の制約と注意事項があります。まず、管理エージェントはどの時点でも、ある特定のEnterprise Managerシステムによってのみ監視されているため、ジョブは管理エージェントを監視しているシステム以外では実行できません。管理エージェントが移行されるまで、管理エージェントにより監視されているターゲットに対するジョブはすべて、従来のEnterprise Managerシステムで実行されます。これは、ジョブの真実の状態を知っているEnterprise Managerシステムは1つしかないことも意味します。いかなる場合でも、管理エージェントは一度に1つのシステムとしか通信できないため、実際の状態はEnterprise Managerシステムにしかわからないのです。

  • 管理エージェントが移行されていない場合、将来のジョブは、従来のEnterprise Managerシステムではスケジュール済ジョブとして表示されますが、Enterprise Manager Cloud Controlでは管理エージェントが使用できないため一時停止されているジョブとして表示されます。

  • バックアップ時に従来のEnterprise Managerシステムで実行されていたジョブは、Enterprise Manager Cloud Controlでは中止されるか、または失敗します。管理エージェントの移行が完了すれば、将来のジョブは、従来のEnterprise Managerシステムでは管理エージェントが使用できないため一時停止されているジョブとして表示されますが、Enterprise Manager Cloud Controlではスケジュール済ジョブとして表示されます。その後、従来のEnterprise Managerシステムから管理エージェントを削除すると、そのジョブも同様に削除されます。

    停止時間がなくても従来のEnterprise Managerシステムをバックアップできる場合は、バックアップ時に実行されているジョブはそのまま継続されます。(バックアップに停止時間が必要である場合は、この停止時間のためにジョブは中止される可能性があります。)このようなジョブは、Enterprise Manager Cloud Controlには、中断されたジョブ、失敗したジョブ、または省略されたジョブとして表示されます。

  • 繰返しジョブは、スケジュールに従って既存のEnterprise Manageシステムで引き続き実行されます。Enterprise Manager Cloud Controlでは、このようなジョブは中止された、失敗した、または省略されたように見えます。管理エージェントの移行後は、このようなジョブはEnterprise Manager Cloud Controlで実行されるようになります。従来のEnterprise Managerシステムでは、このようなジョブは、管理エージェントが使用できないという理由で一時停止されます。

  • バックアップ後に従来のEnterprise Managerシステムで送信されたジョブは、Enterprise Manager Cloud Controlには表示されません。バックアップ後にEnterprise Manager Cloud Controlで送信されたジョブは、従来のEnterprise Managerシステムには表示されません。通常、ジョブは、そのときにターゲットを監視しているシステムでのみ作成されます。

    • ターゲットの管理エージェントが移行される前に、従来のEnterprise Managerシステムで作成されたジョブは、従来のEnterprise Managerシステムでは期待どおりに動作します。

    • 繰返しジョブは管理エージェントが移行されるまで実行されます。移行された時点で、これらのジョブは管理エージェントが使用できないため一時停止されているジョブとしてスタックされます。

    • ターゲットの移行後、従来のEnterprise Managerシステムでジョブを作成した場合、これらのジョブは管理エージェントが使用できないため一時停止されているジョブとしてスタックされたままになります。したがって、管理エージェントの移行後は、従来のEnterprise Managerシステムでジョブを作成しないでください。

    • 管理エージェントがすでに移行されているターゲットのEnterprise Manager Cloud Controlで作成されたジョブは、通常どおりに振る舞い、期待どおりに動作します。

    • ターゲットの管理エージェントが移行される前にEnterprise Manager Cloud Controlでジョブを作成することはできますが、管理エージェントが移行されるまで、これらのジョブは管理エージェントが使用できないための一時停止モードになります。

      これは、従来のEnterprise Managerシステムで新しいジョブが作成され、ターゲットの移行後に使用するために、Enterprise Manager Cloud Controlでそのコピーが必要とされる場合に特に便利です。通常、これは繰返しジョブです。

      • ジョブの予定時刻よりも前に管理エージェントが移行されている場合、このジョブはEnterprise Manager Cloud Controlで実行されます。

      • ジョブの予定時刻後に管理エージェントが移行された場合、このジョブは省略されます。これにより、両方のシステムでの同一ジョブの実行が阻止されます。

      • ジョブに繰返しスケジュールが設定されている場合、移行前のスケジュールはスキップされ、移行後はスケジュールどおり実行されます。

      • 即時実行がスケジュール設定されたジョブはEnterprise Manager Cloud Controlでは実行されず、最終的には省略されます。したがって、移行されていないターゲットに即時実行が必要なジョブを作成しないでください。

  • ターゲット1つにつき1ジョブずつ、複数回実行されるジョブの場合、あるターゲットでは一時停止され、別のターゲットでは実行される可能性があります。

    管理エージェントAにより監視されているdbAと、管理エージェントBにより監視されているdBという2つのデータベースに対するジョブについて考えてみましょう。管理エージェントBのみを移行した場合、dbAの実行は一時停止されますが、dBは予定した時間が来たときに実行されます。これが繰返しジョブであった場合、dbAの実行は省略されます。管理エージェントAの移行が完了すると、両方とも通常どおり実行されるようになります。

    この動作は、グループに送信されるジョブなど、多数のターゲットを持つジョブにとって重要です。従来のEnterprise Managerシステムにより監視されているターゲットに対する実行は、従来のEnterprise Managerシステムで行われますが、Enterprise Manager Cloud Controlにより監視されているターゲットに対する実行は、Enterprise Manager Cloud Controlで行われます。これに対応するもう片方のシステムでの実行は、一時停止、または省略されます。

  • 多数のターゲットに対して1ジョブずつ、複数のターゲットで実行されるジョブは、すべてのターゲットで使用される管理エージェントを一括移行するまで、従来のEnterprise Managerシステムでも、Enterprise Manager Cloud Controlでも実行できません。一括移行に適した管理エージェントを判断するには、付録Dの説明に従ってSQL問合せを実行します。

    かわりに、管理エージェントを1つずつ移行し、最後の管理エージェントの移行後、猶予期間に余裕があるか、または実行スケジュールがあれば、ジョブを実行することもできます。

デプロイメント・プロシージャ実行の管理

Enterprise Managerシステム全体のアップグレード後、以前のデプロイメント・プロシージャ実行はいずれもアップグレード後のEnterprise Managerでは使用できません。以前のランタイム・データを参照する場合は、次のEM CLI動詞を使用してランタイム・データのすべてをXMLファイルとしてエクスポートする必要があります。

get_instance_data_xml

メトリックの収集

Oracle Fusion Middlewareターゲットに関連するメトリックの一部は、Enterprise Manager Cloud Controlで名前が変更されました。さらに、新しいメトリックもいくつか追加されています。メトリックが変更されているターゲットは次のとおりです。メトリックの変更に関する詳細は、付録Cを参照してください。

  • Oracle SOA Infrastructure

  • Oracle SOAコンポジット

  • Oracle Service Bus

  • Oracle WebLogic Server

  • JBoss Application Server

  • Siebelエンタープライズ

  • Siebelサーバー


警告:

通常、構成変更は行わないでください(管理エージェントのデプロイおよび構成後にメトリックのしきい値を変更するなど)。変更した場合、新規管理エージェントにスイッチオーバーするときに変更内容は継承されません。変更内容を転送する唯一の方法は、新規管理エージェントを再構成することです。

管理エージェントのデプロイおよび構成については、「Oracle Management Agentのデプロイおよび構成」を参照してください。管理エージェントのスイッチオーバーの詳細は、「Oracle Management Agent 12cへのスイッチオーバー」を参照してください。管理エージェントの再構成の詳細は、「Oracle Management Agentのデプロイおよび構成」の手順(6)を参照してください。


EM CLIクライアントのアップグレード

旧リリースの既存のEM CLIクライアントをすべて、12cリリース1にアップグレードして、これらがEnterprise Manager Cloud Controlで動作できるようにする必要があります。つまり、古いものを破棄して、新しいものをセットアップする必要があります。

新しいEM CLIクライアントの設定に関する詳細は、Cloud Controlコンソール内の「Enterprise Manager Command Line Interface Download」ページを参照してください。このページにアクセスするには、Cloud Controlで「設定」メニューから「プリファレンス」を選択し、「コマンドライン・インタフェース」を選択します。

Oracle Exadataターゲットのアップグレード

使用している既存のEnterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)上のOracle Exadataターゲットは、デフォルトでアップグレードされません。これらはEnterprise Manager Cloud Controlで手動で検出する必要があります。結果として、このターゲットに関連する履歴データはすべて消失します。

Oracle WebLogic Serverでのカスタマイズの再実行

12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードはアウトオブプレース・アップグレードであるため、旧リリースのEnterprise Managerシステムで構成されたWebLogic Serverで行われたカスタマイズはすべて、アップグレード・プロセスによって継承されません。アップグレードしたシステムで、カスタマイズを再実行する必要があります。