| Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド 12cリリース5 (12.1.0.5) B65086-18 |
|
 前 |
 次 |
アップグレード方式を使用してEnterprise Manager Cloud Controlにアップグレードする前に、次の点を考慮してください。
Enterprise Managerシステムのアップグレードでサポートされているアップグレード・パスおよびサポートされているアップグレード方式
Enterprise Managerシステムをアップグレードした後のOracle Software Libraryの状態
OMSおよび管理エージェント用に構成されたカスタム証明書のアップグレード済Enterprise Managerシステムでの再利用
アップグレード済Enterprise Managerシステムのスタンバイ・データベースにOracle Data Guardが構成される場合の強制ロギングの有効化
次のOMS環境のいずれかをアップグレードできます。
単一OMS環境: 単一OMS環境は、複数の管理エージェントで編成される1つのOMSを使用した環境です。通常、小さいデプロイメントです。
複数OMS環境: 複数OMS環境は、複数の管理エージェントで編成されるサーバー・ロード・バランサ(SLB)でモデレートされた2つ以上のOMSインスタンスを使用した環境です。通常、大きいデプロイメントです。
表3-1に、サポートされているアップグレード・パス、およびそれぞれのアップグレード・パスでサポートされているアップグレード方式をリストします。
表3-1 Enterprise Managerシステムのアップグレードでサポートされているアップグレード・パスおよびサポートされているアップグレード方式
| アップグレード元 | アップグレード先 | サポートされているアップグレード方式 |
|---|---|---|
|
12cリリース4 (12.1.0.4) |
12cリリース5 (12.1.0.5) |
1システム・アップグレード |
|
12cリリース3プラグイン・アップグレード1 (12.1.0.3) (2013年10月にリリースされたプラグインが含まれる12cリリース3 (12.1.0.3)ソフトウェア) |
12cリリース5 (12.1.0.5) |
1システム・アップグレード |
|
12cリリース3 (12.1.0.3) |
12cリリース5 (12.1.0.5) |
1システム・アップグレード |
|
12cリリース2プラグイン・アップデート1 (12.1.0.2) (2013年2月にリリースされたプラグインが含まれる12cリリース2 (12.1.0.2)ソフトウェア) |
12cリリース5 (12.1.0.5) |
1システム・アップグレード |
|
12cリリース2 (12.1.0.2) |
12cリリース5 (12.1.0.5) |
1システム・アップグレード |
|
バンドル・パッチ1を適用済の12cリリース1 (12.1.0.1) |
最初に12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)にアップグレードしてから、12cリリース5 (12.1.0.5)にアップグレード。 |
なし |
|
バンドル・パッチ1を含む(デフォルトで含まれる)12cリリース1 (12.1.0.1) |
最初に12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)にアップグレードしてから、12cリリース5 (12.1.0.5)にアップグレード。 |
なし |
|
12cリリース1 (12.1.0.1) (基本リリース) |
最初に12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)にアップグレードしてから、12cリリース5 (12.1.0.5)にアップグレード。 |
なし |
|
11gリリース1 (11.1.0.1) |
12cリリース5 (12.1.0.5) |
|
|
10gリリース5 (10.2.0.5) |
12cリリース5 (12.1.0.5) |
|
|
10gリリース4 (10.2.0.4)以下 |
最初に10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)にアップグレードしてから、12cリリース5 (12.1.0.5)にアップグレード |
なし |
|
10gリリース1 (10.1) |
最初に10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)にアップグレードしてから、12cリリース5 (12.1.0.5)にアップグレード |
なし |
Enterprise Managerシステムのアップグレードでは次のプラットフォームがサポートされています。
当然のことですが、1システム・アップグレードでは、同一のホスト上でアップグレードを行うので、旧リリースのEnterprise Managerシステムと同じプラットフォーム上で作業する必要があります。
2システム・アップグレードおよび異なるホストでの1システム・アップグレードは、旧リリースのEnterprise Managerシステムと同じプラットフォーム、またはEnterprise Manager Cloud Control 12cがサポートされるすべてのプラットフォームで行うことが可能です。動作保証されているプラットフォームについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているEnterprise Managerの動作保証マトリックスを参照してください。
ここでは、アップグレード方式について説明します。
1システム・アップグレード方式、2システム・アップグレード方式、または異なるホストでの1システム・アップグレード方式のいずれかの使用を選択できます。ただし、選択した方式に関係なく、アップグレード操作は常にアウトオブプレース・アップグレードで、Oracle Management Service(OMS)およびOracle Management Agent(管理エージェント)は新しいOracleホームに表示されます。
古いホームと新しいホームを定期的にバックアップすることをお薦めします。
追加のOMSをアップグレードするには、常に1システム・アップグレード方式のみを使用するように選択します。
これらのアップグレード方式では、管理リポジトリが構成される既存のデータベースはアップグレードされません。
このようなデータベースをアップグレードするには、データベース・アップグレード・ツールを使用します。アップグレード・ツールの詳細は、次の場所にあるOracle Databaseドキュメント・ライブラリの『Oracle Databaseアップグレード・ガイド』を参照してください。
http://www.oracle.com/technetwork/indexes/documentation/index.html
Oracle Management Service 12cは、Oracle Management Agent 12cの次のリリースとのみ通信できます。
表 3-2 12cリリースにおけるOMSと管理エージェントの互換性
|
Oracle Management Agent 12cリリース1 (12.1.0.1) + バンドル・パッチ1 (エージェントおよびそれらのパッチ適用済またはアップグレード済、あるいはバンドル・パッチ1とともにインストールされたプラグインを参照) |
Oracle Management Agent 12cリリース2 (12.1.0.2) |
Oracle Management Agent 12cリリース3 (12.1.0.3) |
Oracle Management Agent 12cリリース4 (12.1.0.4) |
Oracle Management Agent 12cリリース5 (12.1.0.5) |
|
|
Oracle Management Service 12cリリース1 (12.1.0.1) + バンドル・パッチ1 |
はい (バンドル・パッチ1を適用済および未適用の管理エージェントを含む) |
いいえ |
いいえ |
いいえ |
いいえ |
|
Oracle Management Service 12cリリース2 (12.1.0.2) |
はい (バンドル・パッチ1を適用済および未適用の管理エージェントを含む) |
はい |
いいえ |
いいえ |
いいえ |
|
Oracle Management Service 12cリリース3 (12.1.0.3) |
はい (2012年1月にリリースされた[バンドル・パッチ1を適用済]管理エージェントのみ) |
はい |
はい |
いいえ |
いいえ |
|
Oracle Management Service 12cリリース4 (12.1.0.4) |
いいえ |
はい |
はい |
はい |
いいえ |
|
Oracle Management Service 12cリリース5 (12.1.0.5) |
いいえ |
はい |
はい |
はい |
はい |
すべてのプラットフォームの管理エージェントは、そのプラットフォームに対応したOracle Management Agent 12cソフトウェアを入手できるかぎり、アップグレード可能です。
使用している環境にJava Development Kit (JDK) 1.6.0.43.0およびOracle WebLogic Server 11gリリース1 (10.3.6)が存在しない場合、Enterprise Manager Cloud Controlインストール・ウィザードによって、これらがインストールされます。
Oracle WebLogic Server 11gリリース1 (10.3.6)が存在しない場合は、インストール・ウィザードにこのインストールを許可することをお薦めします。ただし、これを手動でインストールする必要がある場合は、必ずJDK 1.6.0.43.0 (64ビット・プラットフォームには64ビット・バージョン、32ビット・プラットフォームには32ビット・バージョン)を使用してインストールしてください。
プラットフォーム・ベンダーのWebサイトから、使用しているプラットフォーム用のJDK 1.6.0.43.0をダウンロードします。
たとえば、Linuxプラットフォーム用のSUN JDK 1.6.0.43.0を次の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.6)を手動でインストールする必要がある場合は、まず、使用しているプラットフォームに対応した64ビットJDKをインストールし、次にwls1036_generic.jarファイルをダウンロードし、これを使用してOracle WebLogic Serverをインストールします。
次に例を示します。
<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1036_generic.jar>
Linux 32ビット・プラットフォームにOracle WebLogic Server 11gリリース1 (10.3.6)を手動でインストールする必要がある場合は、wls1036_linux32.binファイルまたはwls1036_generic.jarファイルをダウンロードして使用します。
次に例を示します。
<JDK home>/bin/java -jar <absolute_path _to_wls1036_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をインストールしているユーザーと同一人物であることを確認する必要があります。
Oracle WebLogic Serverのインストール後、インストール後の手順として、パッチ14482558、13349651および16080294を適用してください。これらのパッチなしでは、追加OMSのインストールが失敗します。ただし、これらのパッチは、Oracle WebLogic Serverを手動でインストールする場合のみ必須です。
これらのパッチの適用手順は、次のURLを参照してください。
http://docs.oracle.com/cd/E14759_01/doc.32/e14143/intro.htm#CHDCAJFC
Oracle WebLogic Serverのダウンロードおよびデモの詳細は、次のURLにアクセスしてください。
http://www.oracle.com/technology/products/weblogic/index.html
Enterprise Manager Cloud Controlインストール・ウィザードまたはユーザーによってインストールされるOracle WebLogic Server 11gリリース1 (10.3.6)がEnterprise Manager Cloud Control専用であることを確認する必要があります。ミドルウェア・ホームにその他のOracle Fusion Middleware製品をインストールしてはいけません。
ORACLE_COMMONプロパティはEnterprise Manager Cloud ControlとOracle Fusion Middleware製品の両方で使用されるため、これらを同じミドルウェア・ホームに共存させることはできません。
2システム・アップグレード方式を使用して10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリースX (12.1.0.X)にアップグレードした後に、発生データ移行と呼ばれるアップグレード後アクティビティを実行して、古い管理リポジトリに格納されているすべての発生データをアップグレード後の管理リポジトリに移行します。発生データは、ブラックアウト、アラート、イベント、メトリックなどの機能領域に関連しています。発生データ移行の詳細は、第13.8.1項を参照してください。
ただし、この発生データ移行プロセスでは、管理リポジトリのバックアップ後に実行された次の変更は、どれも移行されません。これらの変更がアップグレード後のEnterprise Managerシステムで必要な場合は、アップグレードにこれらの変更を再度手動で実行する必要があります。
セキュリティ・データ(作成された新規ユーザー、変更されたパスワード)
作成、削除または発行されたジョブ
カスタマイズされたデプロイメント・プロシージャ
パッチ
追加または削除されたターゲット
作成、変更または削除されたレポート
ソフトウェア・ライブラリの構成変更
作成、変更または削除されたテンプレート
ユーザー定義メトリック
管理エージェントをアップグレードすると、旧リリースの管理エージェントで使用されていたポートは、アップグレード後の管理エージェントに引き継がれます。そのため、ファイアウォール設定には何も影響しません。
OMSをアップグレードすると、次のポートが割り当てられます。
2システム・アップグレード方式では、インストーラで許可または指定した新しいポートは、すべてのコア・コンポーネントに割り当てられます。
12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)をアップグレードする場合は、旧リリースのすべてのコア・コンポーネントで使用されていたポートが引き継がれます。
10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をアップグレードする場合は、旧リリースの次のコア・コンポーネントで使用されたポートが引き継がれます。その他のコア・コンポーネントには、インストーラで許可または指定した新しいポートが割り当てられます。
Enterprise ManagerアップロードHTTPポート
Enterprise ManagerアップロードHTTP SSLポート
Enterprise Managerセントラル・コンソールHTTPポート
Enterprise Managerセントラル・コンソールHTTP SSLポート
Oracle Management Agent
異なるホストでの1システム・アップグレード方式では、OMSの構成時にレスポンス・ファイルに渡した新しいポートが、すべてのコア・コンポーネントに割り当てられます。
|
注意: コア・コンポーネント、ポートが選択される範囲、および割り当てられる空ポートの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』でインストールの基本に関する章を参照してください。ファイアウォールをOMS用に構成した場合に、ファイアウォールを通して利用可能にする必要のあるURLの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。 |
この項の内容は次のとおりです。
この項では、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のOracle Management AgentおよびOracle Management Serviceから12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのアップグレード方法について説明します。
特に、次の項目について説明します。
エージェント・アップグレード・コンソールを使用してOracle Management Agent 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)を12cリリース5 (12.1.0.5)にアップグレードする際に、旧リリースのプラグインはすべてデフォルトでアップグレードされます。手動による操作は必要ありません。
Enterprise Manager Cloud Controlインストール・ウィザードを使用してOracle Management Service 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)を12cリリース5 (12.1.0.5)にアップグレードする際に、プラグインは次の状況に基づいて自動的にアップグレード、移行またはデプロイされます。
新しいバージョンが存在する場合、プラグインはアップグレードされます。
新しいバージョンが存在しない場合、プラグインは移行されます。
アップグレード対象のプラグインに新しい依存関係が存在する場合またはリリースで導入された新しいデフォルト・プラグインがある場合、プラグインがデプロイされます。
また、インストール・ウィザードでは「プラグインの選択」画面を使用して、自動的にアップグレード、移行またはデプロイされるプラグイン以外にデプロイするオプション・プラグインを選択できます。
「プラグインの選択」画面にリストされていないプラグインをインストールする場合は、次の手順に従います。
Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html
アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。
Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。
次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。
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
アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。
Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。
次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。
UNIXプラットフォームの場合:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>
Microsoft Windowsプラットフォームの場合:
setup.exe -pluginLocation <absolute_path_to_plugin_software_location>
(この項は、旧リリースのEnterprise Managerでソフトウェア・ライブラリが構成されていた場合にのみ適用されます)
Enterprise Managerのアップグレード後のOracle Software Library(ソフトウェア・ライブラリ)の状態は次のとおりです。
1システム・アップグレード方式では、Enterprise Managerをアップグレードすると同時にソフトウェア・ライブラリを使用できるようになります。使用できるようにするために、手作業で操作する必要はありません。
2システム・アップグレード方式では、Enterprise Managerをアップグレード後に再構成した場合のみ、ソフトウェア・ライブラリを使用できるようになります。
2システム・アップグレード方式のワークフロー、およびソフトウェア・ライブラリの再構成のタイミングについては、第9.2項を参照してください。ソフトウェア・ライブラリの再構成の詳細は、第13.4項を参照してください。
異なるホストでの1システム・アップグレード方式では、Enterprise Managerをアップグレードすると同時にソフトウェア・ライブラリを使用できるようになります。ただし、これは、古い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)以上で、この場所は変更されました。現在、nmosudoはsbinディレクトリ、つまりエージェント・ベース・ディレクトリに存在します。たとえば、/u01/oracle/agent/sbin/nmosudoです。
したがって、12cリリース2 (12.1.0.2)以上をインストール、または12cリリース2 (12.1.0.2) [バンドル・パッチ1を適用済]からアップグレードする際に、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)から12cリリースX (12.1.0.X)にアップグレードする場合にのみ適用されます。たとえば、12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)など、12cリリース内でアップグレードする場合は、この項を無視できます。 |
この項は、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リリース5 (12.1.0.5)の重要な変更について説明します。
特に、次の項目について説明します。
アップグレード時、システム既存のルール・セットが再登録され、その結果、それらに対して行われた電子メールのサブスクリプションは失われます。そのため、アップグレード・プロセスを開始する前に、システム既存のルール・セットのコピーを作成(類似作成アクションを使用)することをお薦めします。
アップグレード後、すべての通知ルールおよびアラートは引き続きEnterprise Manager Cloud Controlで動作します。ただし、これらは強化されて、より規模が大きく新しい概念に組み込まれ、Enterprise Manager Cloud Controlでは、通知ルールはインシデント・ルールセット、アラートはイベントと呼ばれるようになりました。
インシデント・ルールセットと、これを通知ルールにマップする方法の詳細、およびイベントと、これをアラートにマップする方法の詳細は、付録Bを参照してください。
アップグレード中、旧リリースからのアラートは次のようにイベントとしてEnterprise Manager Cloud Controlに移行されます。1システム・アップグレード方式では、アラートは、管理リポジトリのアップグレード中に移行されます。2システム・アップグレード方式では、アラートは、管理リポジトリをリモート・ホストにバックアップしている間に移行されます。
この項の内容は次のとおりです。
アップグレード済Enterprise Managerシステムで様々なタイプのオープン・アラートに対して作成されるインシデントとイベント
アップグレード済Enterprise Managerシステムで様々なタイプのクローズド・アラートに対して作成されるインシデントとイベント
表3-3は、各種オープン・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。
管理リポジトリのアップグレードまたはバックアップの180日前にクローズされたアラートはすべて、遅延データ移行プロセスの一部として移行されます。この180日という期間は管理者が変更できます。
表3-4は、各種クローズド・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。また、クローズド・アラートに関連付けられているチケットがある場合、その情報はイベント移行の一部として取得されないことにも注意してください。
管理リポジトリのアップグレード、またはバックアップから7日前以内に作成されたオープン状態のステートフル・アラート、およびステートレス・アラートはすべて移行されます。
|
注意: 2システム・アップグレード方式では、アラートが、管理リポジトリのバックアップ後にEnterprise Managerシステムの旧リリースで作成されていた場合、そのオープン・アラートは発生データ移行プロセスの一部として移行されます(表3-3を参照)。また、可用性レコードはすべて、発生データ以降プロセスの一部として移行されます。 |
表3-3は、各種オープン・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。
表3-4は、各種クローズド・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。また、クローズド・アラートに関連付けられているチケットがある場合、その情報はイベント移行の一部として取得されないことにも注意してください。
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システム全体のアップグレード後、10gリリース5 (10.2.0.5)または11gリリース1(11.1.0.1)のデプロイメント・プロシージャはいずれもアップグレード後の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サーバー
旧リリースの既存の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リリース5 (12.1.0.5)にアップグレードする際に、OMSのアップロードおよびコンソール・ポート用に構成されたすべてのカスタム証明書、および管理エージェント用に構成されたすべてのカスタム証明書が、以前のリリースから自動的に引き継がれ、アップグレードされたリリースに保持されます。これらのカスタム証明書のいずれについても、再構成は不要です。
管理リポジトリの構成を計画しているOracle Database上のXML DBなどの機能を有効化または無効化しても、Enterprise Managerは影響を受けません。したがって、Enterprise Managerはデータベースにあるいずれの機能にも依存しないため、それらを有効化または無効化できます。
同じホスト上の管理リポジトリが格納されているOMSおよびOracle Databaseをインストールする場合、ホストを再起動する際に、OMS、および一緒にインストールされた管理エージェントは自動的に開始されません。それらを手動で開始する必要があります。
スタンバイ・データベースでOracle Data Guardを構成する場合、次のコマンドを使用してデータベースへの強制ロギングを有効化します。
ALTER DATABASE force logging;
データベースへの強制ロギングを有効化しない場合、Enterprise Managerシステムをアップグレードする際にNOLOGGINGコマンドを使用すると、スタンバイ・データベースを破損する可能性があります。
