アップグレード方式を使用して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システム)がサポートされています。
次のプラットフォームがサポートされています。
当然のことですが、1システム・アップグレードでは、同一のホスト上でアップグレードを行うので、旧リリースのEnterprise Managerシステムと同じプラットフォーム上で作業する必要があります。
2システム・アップグレードは、旧リリースのEnterprise Managerシステムと同じプラットフォームで行うことが可能で、リモート・ホストから操作している場合は次のプラットフォームで行うこともできます。
Linux (32ビット)からLinux (64ビット) (またはこの逆方向、仮想環境でも同様)
HP PA-RISCからLinux (32ビット)またはLinux (64ビット) (またはこの逆方向)
HP-UX ItaniumからLinux (32ビット)またはLinux (64ビット) (またはこの逆方向)
異なるホストでの1システム・アップグレードは、旧リリースのEnterprise Managerシステムと同じプラットフォームで行うことが可能で、2システム・アップグレード方式と同様、リモート・ホストから操作している場合は次のプラットフォームで行うこともできます。
Linux (32ビット)からLinux (64ビット) (またはこの逆方向)、およびMicrosoft Windows (32ビット)からMicrosoft Windows (64ビット) (またはこの逆方向)。
Linux (32ビット)からLinux (64ビット) (またはこの逆方向、仮想環境でも同様)
Microsoft Windows (32ビット)からMicrosoft Windows (64ビット) (またはこの逆方向)
HP PA-RISCからLinux (32ビット)またはLinux (64ビット) (またはこの逆方向)
HP-UX ItaniumからLinux (32ビット)またはLinux (64ビット) (またはこの逆方向)
ここでは、アップグレード方式について説明します。
1システム・アップグレード方式、2システム・アップグレード方式、または異なるホストでの1システム・アップグレード方式のいずれかの使用を選択できます。ただし、選択した方式に関係なく、アップグレード操作は常にアウトオブプレース・アップグレードで、Oracle Management Service(OMS)およびOracle Management Agent(管理エージェント)は新しいOracleホームに表示されます。
古いホームと新しいホームを定期的にバックアップすることをお薦めします。
これらのアップグレード方式では、管理リポジトリが構成される既存のデータベースはアップグレードされません。
このようなデータベースをアップグレードするには、データベース・アップグレード・ツールを使用します。アップグレード・ツールの詳細は、次のURLにあるOracle Databaseドキュメント・ライブラリの『Oracle Databaseアップグレード・ガイド』を参照してください。
http://www.oracle.com/technetwork/indexes/documentation/index.html
Oracle Management Service 12cは、Oracle Management Agent 12cとのみ通信します。したがって、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)およびEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、最初に管理エージェントをアップグレードしてから、OMSをアップグレードしてください。
ただし、Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)をアップグレードする場合は、最初にOMSをアップグレードしてから、管理エージェントをアップグレードしてください。
管理エージェントは、そのプラットフォームに対応したOracle Management Agent 12cソフトウェアを入手できるかぎり、アップグレード可能です。
NFSマウントされたドライブにあるミドルウェア・ホームでEnterprise Manager Cloud Controlにアップグレードしてはいけません。NFSマウントされているドライブでアップグレードを行うと、Oracle HTTP Serverが頻繁に再起動するようになり、その結果、OMSにアクセスできなくなります。このような共有ドライブでアップグレードしなければならない場合は、必ず、OMSインスタンスのベース・ディレクトリ(gc_inst
)をNFSマウントされていない場所に作成してください。
使用している環境にJava Development Kit (JDK) 1.6 v24、およびOracle WebLogic Server 11gリリース1 (10.3.5)が存在しない場合、Enterprise Manager Cloud Controlインストール・ウィザードにより、これらがインストールされます。
Oracle WebLogic Server 11gリリース1 (10.3.5)が存在しない場合は、インストール・ウィザードにこのインストールを許可することをお薦めします。ただし、これを手動でインストールする必要がある場合は、必ずJDK 1.6 v24+(64ビット・プラットフォームには64ビット・バージョン、32ビット・プラットフォームには32ビット・バージョン)を使用してインストールしてください。
プラットフォーム・ベンダーのWebサイトから、使用しているプラットフォーム用のJDK 1.6 v24+をダウンロードします。
たとえば、Linuxプラットフォーム用のSUN JDK 1.6 v24+を次のOracle WebサイトのURLからダウンロードします。
http://www.oracle.com/technetwork/java/javase/downloads/index.html
すでにJDKを持っている場合は、<JDK_Location>/bin
ディレクトリに移動し、次のコマンドを実行して、バージョンを確認します。
"./java -fullversion"
それが32ビット・バージョンであるか、64ビット・バージョンであるかを確認するには、次のコマンドを実行します。
"file *"
Linux 64ビット・プラットフォームにOracle WebLogic Server 11gリリース1 (10.3.5)を手動でインストールする必要がある場合は、まず、使用しているプラットフォームに対応した64ビットJDKをインストールし、次にwls1035_generic.jar
ファイルをダウンロードし、これを使用してOracle WebLogic Serverをインストールします。
次に例を示します。
<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1035_generic.jar>
Linux 32ビット・プラットフォームにOracle WebLogic Server 11gリリース1 (10.3.5)を手動でインストールする必要がある場合は、wls1035_linux32.bin
ファイル、またはwls1035_generic.jar
ファイルをダウンロードして使用します。
次に例を示します。
<JDK home>/bin/java -jar <absolute_path _to_wls1035_generic.jar>
Oracle WebLogic Serverをインストールするときには、必ず、『Oracle® Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の指示に従ってください。このガイドは、次のURLにあるFusion Middlewareドキュメント・ライブラリから入手できます。
http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html
Oracle WebLogic Serverのインストールが標準インストールであることを保証する必要があります。また、カスタム・インストールの実行を選択した場合でも、カスタム・インストールを選択したコンポーネントが標準インストールに関連付けられているコンポーネントと同じであることを確認してください。
WebLogic Serverをインストールしているユーザーが、Enterprise Manager Cloud Controlをインストールしているユーザーと同一人物であることを確認する必要があります。
Enterprise Manager Cloud Controlインストール・ウィザード、またはユーザーによりインストールされるOracle WebLogic Server 11gリリース1 (10.3.5)がEnterprise Manager Cloud Control専用であることを確認する必要があります。ミドルウェア・ホームにその他のOracle Fusion Middleware製品をインストールしてはいけません。
ORACLE_COMMON
プロパティはEnterprise Manager Cloud ControlとOracle Fusion Middleware製品の両方で使用されるため、これらを同じミドルウェア・ホームに共存させることはできません。
管理エージェントをアップグレードすると、旧リリースの管理エージェントで使用されていたポートは、アップグレード後の管理エージェントに引き継がれます。そのため、ファイアウォール設定には何も影響しません。
OMSをアップグレードすると、次のポートが割り当てられます。
2システム・アップグレード方式では、Enterprise Manager Cloud Controlインストール・ウィザードにより、すべてのコア・コンポーネントにデフォルトのポートが割り当てられます。
12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)にアップグレードする場合は、旧リリースのすべてのコア・コンポーネントで使用されたポートが引き継がれます。
10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をアップグレードする場合は、旧リリースの次のコア・コンポーネントで使用されたポートが引き継がれます。残りのコア・コンポーネントには、Enterprise Manager Cloud Controlインストール・ウィザードで他の値が指定されないかぎり、デフォルトのポートが割り当てられます。
Enterprise ManagerアップロードHTTPポート
Enterprise ManagerアップロードHTTP SSLポート
Enterprise Managerセントラル・コンソールHTTPポート
Enterprise Managerセントラル・コンソールHTTP SSLポート
Oracle Management Agent
注意: コア・コンポーネント、ポートが選択される範囲、および割り当てられる空ポートの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』でインストールの基本に関する章を参照してください。 |
この項の内容は次のとおりです。
12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのアップグレード
10gリリース5 (10.2.0.5)または11gリリース1 (11.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 Service 12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのアップグレード
エージェントのアップグレード・コンソールを使用してOracle Management Agents 12cリリース1 (12.1.0.1)をアップグレードする際、旧リリースのすべてのプラグインはデフォルトでアップグレードされます。手動による操作は必要ありません。
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>
アップグレードに必要なプラグインを識別するには、アップグレード前コンソールの「アップグレード前のステップ」セクションで、「ソフトウェアの管理」をクリックします。「ソフトウェアの管理」ページに、システムのアップグレードに必要なプラグインが表示されます。
「ソフトウェアの管理」ページには、既存システムにある古い管理エージェントにより監視されているターゲット、および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)のアップグレードと並行して、必要なプラグインをダウンロードしてインストール方法を説明します。この項の具体的な内容は次のとおりです。
管理エージェントをアップグレードしながら、必要なプラグインをインストールするには、次の手順を実行します。
次のURLにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html
管理エージェント・ソフトウェアをアクセス可能な場所にダウンロードします。ソフトウェアZIPファイルのコンテンツを解凍しないでください。管理エージェント・ソフトウェアはプラットフォームごとに異なるので、インストールするプラットフォーム用のソフトウェアをコピーするようにしてください。
必要なプラグインをすべて同じ場所にダウンロードします。プラグインは汎用なので、すべてのプラットフォームに共通です。
プラグインを使用してターゲットを監視するかどうかに関係なく、「ソフトウェアの管理」ページに必要なプラグインとしてリストされているプラグインを必ずすべてダウンロードします。ターゲットの監視に使用しないプラグインは不要と思われることがありますが、システムのアップグレードのときに必要になる場合があります。したがって、管理ソフトウェア・ページにリストされているプラグインはすべてダウンロードしてください。これらのプラグインは、管理リポジトリを含むデータベースをバックアップする前にダウンロードする必要があります。
注意: また、これらのプラグインを<software_kit>/plugins ディレクトリからダウンロードすることもできますが、すべてのプラットフォームに対応した、最新のプラグインを常に入手できますので、OTNからのダウンロードをお薦めします。 |
注意: 必要なプラグインを識別するには、アップグレード前コンソールの「アップグレード前のステップ」セクションで、表から「ソフトウェアの管理」をクリックします。「ソフトウェアの管理」ページの「プラグイン・ソフトウェア」セクションで必要なプラグインを確認してください。プラグインを使用してターゲットを監視するかどうかに関係なく、「ソフトウェアの管理」ページに必要なプラグインとしてリストされているプラグインをすべてダウンロードします。ターゲットの監視に使用しないプラグインは不要と思われることがありますが、システムのアップグレードのときに必要になる場合があります。したがって、管理ソフトウェア・ページにリストされているプラグインはすべてダウンロードしてください。また、これらのプラグインは、管理リポジトリを含むデータベースをバックアップする前に必ずダウンロードしてください。 |
アップグレード前コンソールの「ソフトウェアの管理」ページ(「アップグレード前のステップ」セクション)の「ソフトウェアの場所の指定」セクションで、プラグインの存在するディレクトリの絶対パスを入力し、「検証」をクリックして管理リポジトリにその場所を登録します。
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>
Enterprise Managerのアップグレード後のOracle Software Library(ソフトウェア・ライブラリ)の状態は次のとおりです。
1システム・アップグレード方式では、Enterprise Managerをアップグレードすると同時にソフトウェア・ライブラリを使用できるようになります。使用できるようにするために、手作業で操作する必要はありません。
2システム・アップグレード方式では、Enterprise Managerをアップグレード後に再構成した場合のみ、ソフトウェア・ライブラリを使用できるようになります。
2システム・アップグレード方式のワークフロー、およびソフトウェア・ライブラリの再構成のタイミングについては、「2システム・アップグレード方式を使用したアップグレード」を参照してください。ソフトウェア・ライブラリの再構成の詳細は、「Oracleソフトウェア・ライブラリの再構成」を参照してください。
異なるホストでの1システム・アップグレード方式では、Enterprise Managerをアップグレードすると同時にソフトウェア・ライブラリを使用できるようになります。
Enterprise Managerシステム全体のアップグレード後、従来のEnterprise Managerシステムで構成されたコネクタはEnterprise Manager Cloud Controlでも引き続き動作します。ただし、構成されていなかったものは機能しません。
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を適用済または未適用]で、この場所は変更されました。現在、nmosudo
はsbin
ディレクトリ、つまりエージェント・ベース・ディレクトリに存在します。たとえば、/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 *
注意: この項は、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-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クライアントをすべて、12cリリース1にアップグレードして、これらがEnterprise Manager Cloud Controlで動作できるようにする必要があります。つまり、古いものを破棄して、新しいものをセットアップする必要があります。
新しいEM CLIクライアントの設定に関する詳細は、Cloud Controlコンソール内の「Enterprise Manager Command Line Interface Download」ページを参照してください。このページにアクセスするには、Cloud Controlで「設定」メニューから「プリファレンス」を選択し、「コマンドライン・インタフェース」を選択します。
使用している既存の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で手動で検出する必要があります。結果として、このターゲットに関連する履歴データはすべて消失します。
12cリリース1 (12.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードはアウトオブプレース・アップグレードであるため、旧リリースのEnterprise Managerシステムで構成されたWebLogic Serverで行われたカスタマイズはすべて、アップグレード・プロセスによって継承されません。アップグレードしたシステムで、カスタマイズを再実行する必要があります。