| Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド 12cリリース5 (12.1.0.5) B65086-18 |
|
 前 |
 次 |
この章では、実行する必要があるインストール後のタスクについて説明します。特に、次の内容について説明します。
|
注意: 2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。 |
2システム・アップグレード方式の場合、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストールに、クリーンな新規のホストを使用することをお薦めします。新規ホストにインストールされていることを確認します。
それには、「管理サービスとリポジトリ」ページでページ・タイトルの横にある情報アイコンをクリックします。表示された「ターゲット情報」リージョン(図13-1を参照)でホスト名を確認して、新しい12cのOMSをインストールしたホストが示されていることを確認します。さらに、ページ右上隅の「ターゲット名の検索」テキスト・ボックスのすぐ下にも同じホスト名が表示されていることを確認します(図13-1を参照)。
ホスト名が一致し、そのホスト名が新しい12cのOMSをインストールしたホストである場合は、新規ホストにインストールしたことの確認になります。
どちらかに別のホスト名が示される場合は、すでに管理エージェントが存在するホストにインストールしたことの確認になります。このような場合は、次の手順に従います。
すでに存在する管理エージェントを削除します。この管理エージェントおよびこれによって監視されているターゲットに関連する情報を、管理リポジトリからクリーンアップまたは削除します。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
2システム・アップグレードの一部として新しい12c OMSとともにインストールされた新しい管理エージェントに、ホストをターゲットとして追加します。
これを行うには、新しい管理エージェント・ホームから次のコマンドを実行します。
$<AGENT_HOME>/bin/emctl config agent addInternaltargets
ホストがターゲットとしてEnterprise Manager Cloud Controlコンソールに追加されていることを確認します。それには、管理エージェントのホームページで、「監視」セクションの「監視ターゲット」タブにホストが表示されていることを確認します。
古いOMSホストとともにインストールされた管理エージェントによって監視されている「管理サービスとリポジトリ」ターゲットを、2システム・アップグレードの一部として新しい12c OMSとともにインストールされた新しい管理エージェントに再配置します。
それには、SYSMANとしてログインし、EM CLIがインストールされている任意のホストで次のコマンドを実行します。
emcli relocate_targets -src_agent="<agent_installed_with_old_OMS>" -dest_agent="<new_agent_installed_with_new_12c_OMS>" -target_name="Management Services and Repository" -target_type=oracle_emrep -copy_from_src
新しい、アップグレードされた管理リポジトリの接続記述子および資格証明を、「管理サービスとリポジトリ」ターゲットの監視構成設定として設定します。
それには、「管理サービスとリポジトリ」ホームページで、「OMSとリポジトリ」メニューから「ターゲット設定」、「監視構成」の順に選択します。「監視構成」ページで、新しい、アップグレードされた管理リポジトリの接続記述子と資格証明を入力します。「OK」をクリックします。
|
注意: 2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。 |
2システム・アップグレード方式を使用してEnterprise Managerシステムをアップグレードするための前提条件として、既存のデータベースを最初にクローニング(またはバックアップ)して、それに構成するOracle Management Repository (管理リポジトリ)をアップグレードする必要があります。これは、アップグレードした管理リポジトリと旧リリースの管理リポジトリが共存していることを確認するためです。
ただし、バックアップしたデータベースの管理リポジトリをアップグレードした後、2つのリポジトリを相互にリンクしてアップグレードしたリポジトリの操作を古いリポジトリから直接実行できるように、管理リポジトリを旧リリースの管理リポジトリにリンクします。
|
警告: 両方のデータベースでGLOBAL_NAMESパラメータに設定されている値を確認してください。
|
旧リリースのリポジトリをアップグレードしたリポジトリにリンクするには、次の手順を実行します。
Grid Controlで「デプロイ」をクリックします。
デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。
「アップグレード・コンソール」ページの「アップグレード・タイプの選択」セクションで、2システムを選択します。これらのアップグレード方式の詳細は、第2章を参照してください。
Enterprise Manager Grid Controlでページがリフレッシュされ、選択したアップグレード方式で実行する必要があるタスクのリストとともに表が表示されます。
OMSアップグレード・ステップ・セクションの表からアップグレードしたリポジトリへのリンクの作成をクリックします。
アップグレードしたOracle Management Repositoryリンクの作成ページのリポジトリ・リンクの詳細セクションで、次の手順を実行します。
接続文字列を入力して、Enterprise Manager Cloud Controlで使用されるアップグレード後の管理リポジトリに接続します。
|
注意: emgc.propertiesファイルのEM_REPOS_CONNECTDESCRIPTORパラメータの値として設定された接続文字列を確認します。このファイルは、OMSインスタンス・ベース・ディレクトリ(gc_inst)にあります。接続文字列としてこの値を入力する場合、必要であればすべての円記号(\)および空白を削除します。
たとえば、
接続文字列としてこの値を入力する場合、次のようになります。
SIDではなくサービス名を使用して接続する場合は、構文内の |
Enterprise Manager Cloud Controlで使用されるアップグレード後の管理リポジトリのSYSMANパスワードを入力します。
古い管理リポジトリのSYSパスワードを入力します。
DBリンクの作成をクリックします。
|
注意: すでにこれらの詳細を指定して2つのリポジトリをリンクしている場合に、接続記述子またはSYSMANパスワードを更新するには、「DBリンクの再作成」をクリックします。 |
|
注意: 2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。 |
2システム・アップグレードの完了後、Enterprise Manager Cloud Controlコンソールでデータベースを監視できるように、管理リポジトリをアップグレードしたデータベースを手動で検出します。
手順については、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
|
注意: 2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。 |
アップグレードしたソフトウェア・ライブラリを2システムのアップグレードで再構成するには:
|
注意:
|
Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。
ソフトウェア・ライブラリがアップグレードされた場合は、「ソフトウェア・ライブラリ」ホーム・ページに次の通知が表示されます。
ソフトウェア・ライブラリが最近アップグレードされましたが、まだ再構成されていません。ソフトウェア・ライブラリが使用可能になるのは、再構成を実行した後です。再構成プロセスを開始するには、「アップグレード後の再構成」をクリックしてください。
「アップグレード後の再構成」をクリックして、ソフトウェア・ライブラリを再構成します。
ソフトウェア・ライブラリの「場所の再構成」ページで、古い既存のEnterprise Managerシステムで構成された場所に対応する、構成対象の新しいファイル・システムの場所を入力します。
古いEnterprise Managerシステム用に構成された場所のアーカイブを、新しいファイル・システムの対応する場所に解凍する必要があります。また、新しい場所、およびそこにあるアーカイブされていないすべてのファイルとディレクトリは、12c OMSプロセス所有者に読取り/書込み権限があることを確認してください。
例:
古い既存のEnterprise Managerシステムで、ソフトウェア・ライブラリが次のファイル・システムの場所を使用するように構成されていると仮定します。
/shared/swlib1 /shared/swlib2
アップグレード後、「場所の再構成」ページに次のように表示されます。
migrated1, /shared/swlib1 migrated2, /shared/swlib2
migrated1およびmigrated2は、アップグレードされた場所に自動的に割り当てられた名前です。
|
注意: 新しい場所ではOMS共有ファイル・システム記憶域の場所のみが再構成されるため、これらの新しい場所がNFSマウントされた共有の場所またはOCFS2の共有の場所であることを確認する必要があります。 |
さらに、既存の場所ごとにファイル・システムの代替パスを指定する必要があります。次に例を示します。
migrated1, /shared/swlib1, /vol/newswlib1 migrated2, /shared/swlib2, /vol/newswlib2
この構成を確認する前に、対応する構成済ソフトウェア・ライブラリ・ディレクトリのバックアップが、アーカイブされていない状態で新しい場所にあること、つまり、バックアップ作成時の/shared/swlib1と同じ内容が/vol/newswlib1 に含まれ、/shared/swlib2と同じ内容が/vol/newswlib2に含まれていることを確認する必要があります。
「検証」をクリックして検証ジョブを発行し、移行されるエンティティの完全な検証チェックを実行します。必ず、このジョブが完了するまで追跡してください。検証エラーが発生した場合は、ジョブ・ステップに表示されます。一般的な検証エラーの一部を次に示します。
- 再構成用に指定された新しい場所が存在しません。
- 再構成用に指定された新しい場所は、OMSプロセス所有者に読取り/書込み権限がありません。
- 古いEnterprise Managerのソフトウェア・ライブラリで構成済の場所の内容が、再構成用に指定された対応する新しい場所にリストアされていません。
検証が成功したら、「確認」をクリックしてソフトウェア・ライブラリを再構成します。SwlibUpgradeLocationsで始まる発行されるジョブが正常に完了するまで追跡した上で、パッチ適用やプロビジョニングのタスクを開始する必要があります。
|
注意: 旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。 |
エージェントのアップグレード操作のステータスを確認するには、次の手順を実行します。
Grid Controlで「デプロイ」をクリックします。
デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。
「アップグレード・コンソール」ページで、次のことを行います。
マクロ・レベルの詳細は、「エージェントのアップグレード・ステータス」セクションで次の表示数を参照します。
成功、正常にアップグレードした管理エージェントを識別します。
失敗、アップグレードに失敗した管理エージェントを識別します。
進行中、現在アップグレードしている管理エージェントを識別します。
開始されていません、まだアップグレードされていない管理エージェントを識別します。
サポートされていません: Oracle Management Agent 12cが特定のプラットフォーム向けにリリースされていないためにアップグレード後のEnterprise Managerシステムでサポートされない管理エージェントを識別します。
ドリルダウンして詳細を表示するには、数値をクリックします。Enterprise Manager Grid Controlで情報を提供するエージェントのアップグレード・ステータス・ページが表示されます。
ミクロレベルでの詳細は、「その他のリンク」セクションでエージェントのアップグレード・ステータスをクリックします。
エージェントのアップグレード・ステータス・ページで、次の操作を実行します。
要件に従ってリストをフィルタ処理して目的のアップグレード操作のみ表示するには、検索機能を使用します。
たとえば、失敗したデプロイメント操作のみ表示するには、「操作タイプ」リストから「デプロイ」、「操作のステータス」リストから「失敗」を選択して、「検索」をクリックします。
|
注意: 操作タイプは、デプロイ、構成、ヘルス・チェック、アップグレード、スイッチオーバーなどの特定のエージェント・アップグレード・ステップに発行されたジョブを参照します。操作名は、これらのジョブの発行時に指定した操作名を参照します。これらの各操作には、開始されていません、進行中、成功、サポートされていません、失敗、現行レポートの検証などのステータスを使用できます。 |
エージェント・ソフトウェアをデプロイするには、表から1つ以上の管理エージェントを選択して、エージェントのデプロイおよび構成をクリックします。
デプロイする管理エージェントの状態および準備状況を確認するには、1つ以上の管理エージェントを選択して、エージェントの準備状況の確認をクリックします。
準備状況チェックの詳細を表示するには、1つ以上の管理エージェントを選択して「ヘルス・チェック・レポートの表示と確認」をクリックします。
エージェントの準備状況の確認詳細ページで、レポートを1つずつ確認します。レポートを検証したことを確認する場合、管理エージェントを選択して、レポートの検証およびサインオフをクリックします。準備状況の確認詳細を表示する場合、管理エージェントを選択して、詳細レポートの表示をクリックします。
エージェントをスイッチオーバーするには、正常にデプロイ、構成およびヘルス・チェックされた1つ以上の管理エージェントを選択して、エージェントの切替えをクリックします。
この項では、Enterprise Manager Cloud Controlへのアップグレード後に実行する必要があるアップグレード後の手順を説明します。この項では特に、次のアップグレード後の手順について説明します。
次の一般的なアップグレード後のタスクを実行します。
『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の新しいEnterprise Managerシステムのインストール方法に関する章で概説されているアップグレード後の手順を実行します。
健全性チェックとして、すべてのデータベース・パラメータがアップグレード操作を始める前に存在していた元の値に再設定されていることを、特にjob_queue_processesパラメータについて、確認します。
(1システム・アップグレード方式のみ)「管理サービスとリポジトリ」ターゲットを監視する管理エージェントを開始します。管理エージェントがメトリック収集のために管理リポジトリに接続しないように、2システム・アップグレードを開始する前に管理エージェントを停止します。アップグレード後に、確実に開始してください。
Enterprise Managerシステムをアップグレードしているときに、サポートされているバージョンのOracle WebLogic Server (インストーラを起動する前にインストール済)をすでに含むミドルウェア・ホームの場所をインストーラで指定した場合は、そのOracle WebLogic Serverに必ずパッチ14482558、13349651および16080294を適用してください。これらのパッチなしでは、追加OMSのインストールが失敗します。
これらのパッチは、自分自身でインストールしたOracle WebLogic Serverを使用している場合にのみ必須です。空のミドルウェア・ホームの場所を指定した場合で、アップグレードの実行時にインストーラでOracle WebLogic Serverをインストールする場合は必須ではありません。
また、WebLogic Server PSU 10.3.6.8にはパフォーマンスおよびセキュリティに関する複数の修正が含まれているため、これも適用します。
|
注意: この項は、10gリリース5 (10.2.0.5)からのアップグレードには適用されません。 |
Oracle Exalogic Systemターゲットを必ずアップグレードしてください。
これを実行するには、「エンタープライズ」メニューから「ジョブ」を選択し、「ライブラリ」を選択します。
「ジョブ・ライブラリ」ページで、ジョブ名UPGRADE EXALOGIC SYSTEMS TO FUSION MIDDLEWARE 12.1.0.3.0 MODELを選択し、「送信」をクリックします。
ジョブを正常に実行してOracle Exalogic Systemターゲットをアップグレードするには、12.1.0.3以上のバージョンのOracle Fusion Middlewareプラグインが含まれるように、これらのターゲットを監視する管理エージェントが次のサポートされるリリースにすでにアップグレード済である必要があります。
Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)からのアップグレードで、12cリリース4 (12.1.0.4)へのアップグレード時にこの手順を実行していない場合は、ここで12cリリース5 (12.1.0.5)でこの手順を実行します。この場合、管理エージェントが12cリリース5 (12.1.0.5)、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のいずれかであることを確認します。
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)からのアップグレードで、12cリリース3 (12.1.0.3)へのアップグレード時にこの手順を実行していない場合は、ここで12cリリース5 (12.1.0.5)でこの手順を実行します。この場合、管理エージェントが12cリリース5 (12.1.0.5)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のいずれかであることを確認します。
Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)からのアップグレードで、12cリリース2 (12.1.0.2)へのアップグレード時にこの手順を実行していない場合は、ここで12cリリース5 (12.1.0.5)でこの手順を実行します。この場合、管理エージェントが12cリリース5 (12.1.0.5)または12cリリース2 (12.1.0.2)のいずれかであることを確認します。
11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)にアップグレードした場合、管理エージェントは12cリリース5 (12.1.0.5)である必要があります。
これらの1つ以上の管理エージェントをサポートされるこれらのリリースにまだアップグレードしていない場合、ジョブが失敗し、Oracle Exalogic Systemターゲットはアップグレードされません。このような状況で問題を解決するには、最初に対象の管理エージェントをアップグレードしてから、Oracle Exalogic Systemターゲットをアップグレードするためのこのジョブを再発行します。
10gリリース5 (10.2.0.5)の追加OMSを、1システム・アップグレード方式を使用して12cリリース5 (12.1.0.5)にアップグレードした後、/EMGC_GCDomain/GCDomainで始まるターゲットが停止しているように表示される場合があります。
/EMGC_GCDomain/GCDomain/EMGC_OMS2 /EMGC_GCDomain/GCDomain/EMGC_OMS2/emgc /EMGC_GCDomain/GCDomain/EMGC_OMS2/empbs /EMGC_GCDomain/GCDomain/EMGC_OMS2/OCMRepeater /EMGC_GCDomain/GCDomain/EMGC_OMS2/oracle.security.apm(11.1.1.3.0)
この問題を解決するには、まず追加OMSホスト上の管理エージェントが稼働していることを確認し、Enterprise Manager Cloud ControlコンソールでWeblogicドメインをリフレッシュしてから、追加OMSホスト上の管理エージェントを再起動します。
アップグレードしたEnterprise ManagerシステムにOCMがインストールされている場合は、次の手順を実行します。
Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)からアップグレードした場合は、次の手順を実行します。
環境変数ORACLE_HOMEをアップグレードされたOMSホームに設定します。
bashターミナルで、次のコマンドを実行します。
export ORACLE_HOME=<absolute_path_to_oms_home>
他のターミナルでは、次のコマンドを実行します。
setenv ORACLE_HOME <absolute_path_to_oms_home>
OCMスケジューラを停止します。
$ORACLE_HOME/ccr/bin/emCCR stop
|
注意: Oracle Management AgentにOCMスケジューラがインストールされている場合は、管理エージェントのホームでもこれらの手順を繰り返します。その場合は、手順(1)に従って環境変数ORACLE_HOMEを管理エージェントのホームに設定し、そのホームから手順(2)を実行します。 |
Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードした場合は、次の手順を実行します。
環境変数ORACLE_CONFIG_HOMEをOMSインスタンス・ホームに設定します。
bashターミナルで、次のコマンドを実行します。
export ORACLE_CONFIG_HOME=<absolute_path_to_gc_inst>
他のターミナルでは、次のコマンドを実行します。
setenv ORACLE_CONFIG_HOME <absolute_path_to_gc_inst>
環境変数ORACLE_HOMEをOMSホームに設定します。
setenv ORACLE_HOME <absolute_path_to_oms_home>
OCMスケジューラを停止します。
$ORACLE_HOME/ccr/bin/emCCR stop
|
注意: Oracle Management AgentにOCMスケジューラがインストールされている場合は、管理エージェントのホームでもこれらの手順を繰り返します。その場合は、手順(1)をスキップし、手順(2)に従って環境変数ORACLE_HOMEを管理エージェントのホームに設定し、そのホームから手順(3)を実行します。 |
旧リリースのEnterprise Managerを監視するために作成されたターゲットは、自動的に削除されません。これらのターゲットには、通知ルール、メトリックしきい値設定、コンプライアンス標準設定、ジョブなどが作成されている可能性があり、それらをEnterprise Manager Cloud Controlの新しいOracle WebLogic Serverのターゲットにコピーすることが必要になる場合があるためです。それらをコピーした後、これらのターゲットを手動で削除します。
この項では、これらの不要なターゲットを削除する方法について説明します。この項の具体的な内容は次のとおりです。
Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)からのアップグレード後には、削除する不要なターゲットはありません。この場合、この項を無視できます。
Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)のアップグレード後には、次のターゲットは自動的に削除されません。これらを手動で削除する必要があります。
EM Webサイト
EM Webサイト・システム
Microsoft Operations Managerコネクタ・ターゲット(generic_mom_managed_host)
古い各OMSの次のターゲット。これらを削除するには、古い各OMSの最上位のOracle Application Serverターゲットを削除します。
Oracle Application Server
OC4J
Oracle HTTP Server
Web Cache
Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のアップグレード後には、次のターゲットは自動的に削除されません。これらを手動で削除する必要があります。
EM Webサイト
EM Webサイト・システム
Microsoft Operations Managerコネクタ・ターゲット(generic_mom_managed_host)
古い各OMSの次のターゲット。これらを手動で削除するには、最上位のファーム・ターゲットsecFarm_GCDomainを削除します。
Oracle Fusion Middlewareファーム
Oracle WebLogicドメイン
アプリケーション・デプロイメント
メタデータ・リポジトリ
|
注意: 1システム・アップグレード方式でEnterprise Managerをアップグレードした後、これらのターゲットが稼働しているように表示される場合があります。このステータスはfalseです。いずれの場合も、このステータスの問題を解決しようとしないでください。これらのターゲットはEnterprise Manager Cloud Controlで不要になったため、手動で削除してください。 |
次のターゲットを手動で削除します。
EM Webサイト
EM Webサイト・システム
Microsoft Operations Managerコネクタ・ターゲット(generic_mom_managed_host)
2システム・アップグレードの一部として中央エージェントおよびその監視ターゲットは自動的に削除されるため、古い中央エージェントを手動で削除する必要はありません。
自動的に削除されたターゲットの監視を継続する場合は、そのホストにOracle Management Agent 12cをインストールします。手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。
ユーザー定義コンプライアンス標準に関連付けられたターゲットをEnterprise Manager Cloud Controlコンソールから(またはEM CLIから)削除する場合、ターゲットはEnterprise Managerシステムから削除されますが、ユーザー定義コンプライアンス標準は完全には削除されません。これは、後にこのコンプライアンス標準を編集しようとする際に問題になります。この問題を回避するには、Enterprise Managerシステムのアップグレード後に、削除済ターゲットのすべての古いコンプライアンス関連データを手動で削除します。
削除済ターゲットに古いコンプライアンス関連のデータがあるかどうかを確認するには、SYSMANとして管理リポジトリで次のSQL問合せを手動で実行します。問合せの結果が1以上の場合、古いデータを手動で削除します。
select count(*) from em_cs_tgt_assoc_txf_req where root_target_guid not in (select target_guid from mgmt_targets);
削除済ターゲットのすべての古いコンプライアンス関連データを手動で削除するには、次の手順を実行します。
管理リポジトリを格納しているデータベースにSYSMANユーザーとしてログインします。
My Oracle Supportノート1643222.1にアップロードされている次のクリーンアップ・スクリプトを実行します。
SQL>@cleanup_stale_data.sql
次のSQL問合せを手動で実行し、結果がゼロになることを確認します。
SQL> select count(*) from sysman.em_cs_tgt_assoc_txf_req where root_target_guid not in (select target_guid from mgmt_targets);
アップグレード時には、旧リリースのEnterprise Managerで作成された「通知ルール」が、最初に「通知ルール」で定義されたターゲットに作用する、対応するインシデント・ルールセットに自動的に移行されます。 インシデント・ルールセットの詳細は、付録Bを参照してください。
ただし、Enterprise Manager Cloud Controlでターゲット・タイプ・モデリングが変更されている場合は、手動でルールを調整する必要があります。この項では、ルールセットを手動で調整する方法を説明します。
この項の具体的な内容は次のとおりです。
旧リリースのEnterprise Managerでは、「OMSとリポジトリ」が、環境内のすべてのOMSインスタンスに対して定義される共通のターゲット・タイプでした。また、異なるOMSインスタンスに対して収集されたメトリックは、この共通のターゲット・タイプ内に表示されていました。
しかし、Enterprise Manager Cloud Controlでは、ターゲット・タイプ「OMSとリポジトリ」に加えて、環境内の各OMSインスタンスを表す新しいターゲット・タイプ、「Oracle Management Service」が導入されました。これにより、環境内に5つのOMSインスタンスがある場合は、ターゲット・タイプ「OMSとリポジトリ」が1つ、およびターゲット・タイプ「Oracle Management Service」のインスタンスが5つ(OMSごとに1つ)表示されます。
ターゲット・タイプ「OMSとリポジトリ」では、環境内のすべてのOMSインスタンスに共通するメトリックが取得されるのに対して、ターゲット・タイプ「Oracle Management Service」では、各OMSに固有のメトリックが取得されます。
表13-1に、メトリックのリスト、新しいターゲット・タイプ「Oracle Management Service」の導入のために行われた変更、および変更に対して実行する必要があるアクションを示します。
表13-1 メトリックに対する変更および必要な更新
| 変更タイプ | 変更の説明 | 影響を受けるメトリック | 必要なアクション |
|---|---|---|---|
|
一部のメトリックは、同じターゲット・タイプ(「OMSとリポジトリ」)用に保持されています。 |
保持されているメトリックは次のとおりです。
|
変更する必要はありません。 |
|
|
一部のメトリックは、個別のターゲット・タイプ(「Oracle Management Service」)に移動しました。 |
移動したメトリックは次のとおりです。
|
異なるターゲット・タイプに移動したメトリックに対応する、新しいインシデント・ルールを設定します。 第13.6.8.2項を参照してください |
|
|
一部のメトリックは、わかりやすい名前に変更されました。 |
名前が変更されたメトリックは次のとおりです。
|
名前が変更されたメトリックに設定されているインシデント・ルールを更新します。 第13.6.8.3項を参照してください |
|
|
一部のメトリックは、Enterprise Manager Cloud Controlでサポートされないため、廃止されました。 |
廃止されたメトリックは次のとおりです。
|
廃止されたメトリックをインシデント・ルールから削除します。 第13.6.8.4項を参照してください |
移動したメトリックに設定されているインシデント・ルールをEnterprise Manager Cloud Controlの個別のターゲット・タイプ「Oracle Management Service」に更新するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから「インシデント」 を選択して「インシデント・ルール」をクリックします。
「インシデント・ルール」ページで、Oracle Management Service(OMS)用に作成されたインシデント・ルールを選択し、「編集」をクリックします。
「ルール・セットの編集」ページの「ルール」タブで、移動したメトリックに作用するイベント・ルールを選択し、「編集」をクリックします。
選択したインシデント・ルール・セットのインシデント・ルールを編集できる、Enterprise Managerのルールの編集ウィザードが表示されます。
ルールの編集ウィザードで、次の手順を実行します。
「イベントの選択」ページで、表13-1の2行目にリストされているメトリックを選択し、「削除」をクリックします。
「次へ」をクリックします。
「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。
「確認」ページで「続行」をクリックします。
「保存」をクリックします。
Enterprise Managerの「インシデント・ルール」ページが表示されます。
「インシデント・ルール」ページで「ルール・セットの作成」をクリックします。
「ルール・セットの作成」ページで、ルール・セットの一意の名前を入力します。
「ターゲット」タブで、「すべてのターゲットのタイプ」→「Oracle Management Service」を選択します。
「ルール」タブで「作成」をクリックします。
「作成するルールのタイプを選択」ダイアログで、「イベント・ルール」を選択して「続行」をクリックします。
新しいインシデント・ルール・セットを作成できる、Enterprise Mangerの新規ルールの作成ウィザードが表示されます。
新規ルールの作成ウィザードで、次の手順を実行します。
「イベントの選択」ページで、「イベント・タイプ」リストから「メトリック・アラート」を選択します。
|
注意: メトリック「管理サービスのステータス」に対して、「イベント・タイプ」リストから「ターゲット可用性」を選択します。 |
「特定のメトリック・アラート」を選択して「追加」をクリックします。
「特定のメトリック・アラートを選択」ダイアログで、次の手順を実行します。
「検索」リージョンの「ターゲット・タイプ」リストから「Oracle Management Service」を選択し、「検索」をクリックします。
表13-1の2行目にリストされている移動したメトリックを、表から選択します。
「重大度と修正処理のステータス」 リージョンの「重大度」リストから、適切な重大度レベルを選択します。
「OK」をクリックします。
「次へ」をクリックします。
「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。
「確認」ページで「続行」をクリックします。
「保存」をクリックします。
Enterprise Managerの「インシデント・ルール」ページが表示されます。
|
注意: OMS用に作成されている他のすべてのインシデント・ルールに対して、この手順を繰り返します。 |
Enterprise Manager Cloud Controlで名前が変更されたメトリックに対して設定されているインシデント・ルールを更新するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから「インシデント」 を選択して「インシデント・ルール」をクリックします。
「インシデント・ルール」ページで、Oracle Management Service(OMS)用に作成されたインシデント・ルールを選択し、「編集」をクリックします。
「ルール・セットの編集」ページの「ルール」タブで、名前が変更されたメトリックに作用するイベント・ルールを選択し、「編集」をクリックします。
選択したインシデント・ルール・セットのインシデント・ルールを編集できる、Enterprise Managerのルールの編集ウィザードが表示されます。
ルールの編集ウィザードで、次の手順を実行します。
「イベントの選択」ページで、表13-1の3行目にリストされているメトリックを選択し、「削除」をクリックします。
「追加」をクリックします。
「特定のメトリック・アラートを選択」ダイアログで、次の手順を実行します。
「検索」リージョンの「ターゲット・タイプ」リストから「OMSとリポジトリ」を選択し、「検索」をクリックします。
表13-1の3行目にリストされている、名前が変更されたメトリックを、表から選択します。
「重大度と修正処理のステータス」 リージョンの「重大度」リストから、適切な重大度レベルを選択します。
「OK」をクリックします。
「次へ」をクリックします。
「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。
「確認」ページで「続行」をクリックします。
|
注意: OMS用に作成されている他のすべてのインシデント・ルールに対して、この手順を繰り返します。 |
廃止されたメトリックをインシデント・ルールから削除するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから「インシデント」 を選択して「インシデント・ルール」をクリックします。
「インシデント・ルール」ページで、Oracle Management Service(OMS)用に作成されたインシデント・ルールを選択し、「編集」をクリックします。
「ルール・セットの編集」ページの「ルール」タブで、メトリック・アラート・イベント・ルールを選択して「編集」をクリックします。
選択したインシデント・ルール・セットのインシデント・ルールを編集できる、Enterprise Managerのルールの編集ウィザードが表示されます。
ルールの編集ウィザードで、次の手順を実行します。
「イベントの選択」ページで、表13-1の最後の行にリストされているメトリックを選択し、「削除」をクリックします。
「次へ」をクリックします。
「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。
「確認」ページで「続行」をクリックします。
|
注意: OMS用に作成されている他のすべてのインシデント・ルールに対して、この手順を繰り返します。 |
2システム・アップグレード方式でアップグレードした場合は、デフォルトのインシデント・ルール・セットを無効にします。これらを無効にしない場合、すべてのクリティカルなメトリック・アラートに対してインシデントが自動的に作成されます。
デフォルトのインシデント・ルール・セットを無効にするには、次の手順を実行します。
Cloud Controlで、「設定」メニューから「インシデント」、「インシデント・ルール」の順に選択します。
「インシデント・ルール - すべてのエンタープライズ・ルール」ページで表を下にスクロールし、「すべてのターゲットのインシデント管理ルールセット」を開きます。
無効にするルール・セットの行を選択します。
「アクション」メニューから「無効化」をクリックします。
ポップアップ・ウィンドウで「OK」をクリックします。
無効にするルール・セットごとに、手順(3)から(5)を繰り返します。
すべてのルール・セットを無効にした後、表の「有効」列に「いいえ」と表示され、その横に警告アイコンがあることを確認してください。
旧リリースのEnterprise ManagerでSOAターゲットを監視していた場合は、第11.2項の説明に従って生成した状態レポートに、メトリック「SOAの上位SQL問合せ」および「デハイドレーション・ストア表」に対するメトリック収集エラーが表示されていた可能性があります。
この問題を解決するには、SOAターゲットの「監視構成」ページにアクセスしてデータベース資格証明を入力します。
|
注意: この項は、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にアップグレードする場合にのみ適用されます。 |
前のリリースでタイプがDownloadLatestPkgsまたはUpdateHostPackagesのジョブをスケジュールしていた場合は、12cリリース5 (12.1.0.5)にアップグレードした後で、資格証明がないためにそれらのジョブが失敗します。このため、この問題を解決するには、次のいずれかの方法を実行します。
アップグレードの後で、アップグレード前に発行されていたすべてのアクティブなLinuxパッチ適用ジョブを停止し、それらの資格証明をリセットしてから、同じターゲットでジョブを再発行する必要があります。これを行うには、次の項の手順に従います。
すべてのDownloadLatestPackagesジョブを停止して再発行するには、次の手順に従います。
次の手順で、アップグレード前にスケジュールされたアクティブ・ジョブを停止します。
「エンタープライズ」メニューから「ジョブ」→「アクティビティ」を選択します。「ジョブ・アクティビティ」ページが表示されます。
「ジョブ・アクティビティ」ページで「拡張検索」リンクをクリックします。
「拡張検索」オプションで、「ジョブ・タイプ」に対してDownloadLatestPkgs、「ターゲット・タイプ」に対して「ホスト」、「ステータス」に対して「アクティブ」、「スケジュール開始」に対して「すべて」を選択し、「実行」をクリックします。
拡張検索結果で、表にリストされている各ジョブを選択し、「停止」をクリックします。
アクティブなDownloadLatestPkgsジョブが停止された各ホスト・ターゲットに対して、新しいDownloadLatestPkgsジョブを次のように再発行します。
「設定」メニューから、「プロビジョニングとパッチ適用」→「Linuxパッチ適用」を選択します。「パッチ適用設定」ページが表示されます。
「パッチ適用設定」ページで「RPMリポジトリの設定」をクリックします。
「RPMリポジトリの設定」ページでホスト・ターゲットを選択し、このホスト・ターゲットの「通常ホスト資格証明」および「特権ホスト資格証明」を設定します。
「適用」をクリックして新しいジョブを発行します。
すべてのUpdateHostPackagesジョブを停止して再発行するには、次の手順に従います。
次の手順で、アップグレード前にスケジュールされたアクティブ・ジョブを停止します。
「エンタープライズ」メニューから「ジョブ」→「アクティビティ」を選択します。「ジョブ・アクティビティ」ページが表示されます。
「ジョブ・アクティビティ」ページで「拡張検索」リンクをクリックします。
「拡張検索」オプションで、「ジョブ・タイプ」に対してUpdateHostPackages、「ターゲット・タイプ」に対して「ジョブが発行されたすべてのターゲット・タイプ」、「ステータス」に対して「アクティブ」、「スケジュール開始」に対して「すべて」を選択し、「実行」をクリックします。
拡張検索結果で、表にリストされている各ジョブを選択し、「停止」をクリックします。
アクティブなUpdateHostPackagesジョブが停止された各グループ・ターゲットに対して、新しいUpdateHostPackagesジョブを次のように再発行します。
「設定」メニューから、「プロビジョニングとパッチ適用」→「Linuxパッチ適用」を選択します。
「パッチ適用設定」ページで「グループの設定」をクリックします。「グループの設定」ページが表示されます。
「グループの設定」ページで、アクティブなUpdateHostPackagesジョブを停止したグループを選択して「編集」をクリックします。グループの編集ウィザードが表示されます。
「グループの編集: プロパティ」ページで「次へ」をクリックします。
「グループの編集: パッケージ・リポジトリ」ページで「次へ」をクリックします。
「グループの編集: 資格証明」ページで、Host Preferred Credentialsまたは「優先資格証明のオーバーライド」を使用して、「通常ホスト資格証明」および「特権ホスト資格証明」を指定します。「次へ」をクリックします。
|
注意: このステップを編集する前に、ホスト優先資格証明がすでに設定されていること、または適切な名前付き資格証明がすでに作成されていることを確認してください。まだ行われていない場合は、「設定」メニューから「セキュリティ」→「名前付き資格証明」を選択して名前付き資格証明または「優先資格証明」を作成し、Linuxパッチ適用グループに含まれるホスト・ターゲットの優先資格証明を設定します。 |
「グループの編集: 確認」ページで「終了」をクリックして、新しいジョブを発行します。
アップグレードの後で、アップグレード前に発行されていたすべてのアクティブなLinuxパッチ適用ジョブの資格証明をリセットしてから、それらのジョブを再発行する必要があります。次の手順を実行します。
「エンタープライズ」メニューから「ジョブ」、「アクティビティ」の順に選択します。
「ジョブ・アクティビティ」ページで「拡張検索」をクリックします。
「拡張検索」リージョンの「名前」フィールドにジョブ名PACKAGES UPDATE%を入力し、「ジョブ・タイプ」リストで「UpdateHostPackages」を選択します。「実行」をクリックします。
検索結果表でジョブを選択し、「編集」をクリックします。
'UpdateHostPackages'ジョブの編集ページの「資格証明」タブをクリックします。
「資格証明」タブで必要な資格証明を設定します。
「送信」をクリックします。
ジョブ・タイプDownloadLatestPkgsのDOWNLOADLATESTPKGS%という名前のジョブについて、手順(3)から手順(7)を繰り返します。
アップグレードしたOMSにサーバー・ロード・バランサ(SLB)が構成されている複数OMS環境の場合、「管理サービスとリポジトリ」ページのコンソールURLを更新してください。ここで入力したコンソールURLは、Enterprise Managerから送信される電子メールで、Enterprise Manager Cloud Controlコンソールに戻るリンクを作成するために使用されます。
コンソールURLを更新するには、次の手順に従います。
「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。
「概要」セクションの「管理サービスとリポジトリ」ページで、「コンソールURL」ラベルで「編集」をクリックして、URLをSLB URLに変更します。
たとえば、http://www.example.com, https://www.example.com:4443にします。
|
注意: コンソールURLを/emで終わらせないでください。 |
Enterprise Managerから送信される電子メールに更新したコンソールURLが正しく表示されるかどうかを確認します。
12cリリース5 (12.1.0.5)へのアップグレードはアウトオブプレース・アップグレードであるため、旧リリースのEnterprise Managerシステムで行われたカスタム構成と、旧リリースのEnterprise Managerシステムで構成されたWebLogic Serverで行われたカスタマイズはすべて、アップグレード・プロセスによって継承されません。アップグレードしたシステムで、カスタマイズを再実行する必要があります。たとえば、emd.propertiesファイルのLDAP構成は継承されないため、アップグレード後にemd.propertiesファイルで再構成する必要があります。
|
注意:
|
12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のOracle WebLogic Server (管理サーバーおよび管理対象サーバー)にカスタム証明書が構成されていた場合、12cリリース5 (12.1.0.5)へのアップグレード後にそのカスタム証明書は引き継がれません。かわりに、Oracle WebLogic Serverはデモ証明書を使用して構成されます。そのため、アップグレード後にカスタム証明書を使用してOracle WebLogic Serverを再構成してください。次の手順を実行します。
すべてのOMSインスタンス上で次のコマンドを実行します。このコマンドおよび渡すことのできるオプションの詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドを参照してください。
$<OMS_Home>/bin/emctl secure wls <options>
すべてのOMSインスタンスを停止します。
$<OMS_Home>/bin/emctl stop oms -all
すべてのOMSインスタンスを開始します。
$<OMS_Home>/bin/emctl start oms
第4章で説明されているように、最初のOMSを12cリリースX (12.1.0.X)から12cリリース5 (12.1.0.5)にアップグレードした後、そのホストの中央エージェントを即座にアップグレードすることを強くお薦めします。
ただし、そのホストの中央エージェントをアップグレードせずに追加OMSの12cリリースX (12.1.0.X)から12cリリース5 (12.1.0.5)へのアップグレードを続行した場合は、そのアップグレード済の追加OMSのバージョンを管理サービス・ページで確認します。これを実行するには、「設定」メニューから、「Cloud Controlの管理」、「管理サービス」の順に選択します。OMSバージョンを確認します。
まだアップグレードされたバージョンではなく古いバージョンが表示されている場合は、追加OMSホストの管理エージェントを再起動します。
12cリリース5 (12.1.0.5)にアップグレードすると、前のリリースで無効になっていたコンプライアンス標準が、12cリリース5 (12.1.0.5)では自動的に有効になります。これらのコンプライアンス標準を無効にしておく必要がある場合は、アップグレードした後で12cリリース5 (12.1.0.5)のターゲットごとに手動で無効化します。次の手順を実行します。
「エンタープライズ」メニューから「コンプライアンス」、「ライブラリ」の順に選択します。
「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準」タブをクリックします。
「コンプライアンス標準」タブでコンプライアンス標準を選択し、「ターゲットの関連付け」をクリックします。
「コンプライアンス標準ターゲット・アソシエーション」ページでターゲットを選択し、「編集」をクリックします。
「コンプライアンス標準のターゲット設定」ページにおいて、左側のツリー・ビューでルール・ノードを選択し、右側のパネルの「コンプライアンス標準ルールの評価ステータス」リストで「無効」を選択します。「OK」をクリックします。
「コンプライアンス標準ターゲット・アソシエーション」ページで「OK」をクリックします。
12cリリース5 (12.1.0.5)にアップグレードすると、Javaヒープ・メモリーの引数がデフォルト値に自動的に設定されるため、旧リリースのEnterprise Manager Cloud Controlで引数に対して行われたカスタマイズはすべてアップグレード後のOMSまで存続しません。Javaメモリーの引数を手動でカスタム値にリセットする必要があります。
たとえば、旧WebLogic Server構成ファイルでヒープ・サイズを8GBにカスタマイズしていた場合、12cリリース5 (12.1.0.5)にアップグレードすると、ヒープ・サイズはデフォルト値の4GBにリセットされます。したがって、アップグレード後手順として、ヒープ・サイズをカスタム値の8GBに手動でリセットする必要があります。
12cリリース3 (12.1.0.3)および12cリリース2 (12.1.0.2)では、JAVA_EM_MEM_ARGS引数がサポートされていましたが、この引数はOMSのメモリー設定だけでなく、Oracle BI PublisherなどのEnterprise Manager Cloud Controlと統合されている他のコンポーネントのメモリー設定も変更しました。この引数は、12cリリース4 (12.1.0.4)以上ではサポートされなくなっています。
12cリリース4 (12.1.0.4)以上では、次のJavaヒープ・メモリーの引数がサポートされています。
OMS_HEAP_MIN
OMS_HEAP_MAX
OMS_PERMGEN_MIN
OMS_PERMGEN_MAX
12cリリース5 (12.1.0.5)へのアップグレード後に前述のJavaヒープ・メモリーの引数をリセットするには、次の手順を実行します。
OMSの引数に設定されている現在の値をチェックします。
emctl get property -name <argument_name>
次に例を示します。
emctl get property -name OMS_HEAP_MAX
次のように値を再設定します。
emctl set property -name <argument_name> -value <value_followed_by_G_or_M>
次に例を示します。
emctl set property -name OMS_HEAP_MAX -value 8192M
OMSを停止します。
emctl stop oms-all
OMSを起動します。
emctl start oms
次の手順のいずれかの変更を確認します。
OMSベース・インスタンスのホーム・ディレクトリ(gc_inst)のemgc.propertiesファイルにアクセスし、再設定する引数の値をチェックします。
次のコマンドを実行して、再設定した引数の値をチェックします。
ps -aef | grep weblogic.Server | grep EMGC_OMS1
表4-1の手順2 (j)の説明に従って特定のジョブ・タイプのアップグレードを選択してスキップまたは後回しにした場合は、Enterprise Managerシステムのアップグレード後にMGMT_PARAMETERS表に挿入した値を必ず消去します。
そのためには、SYSMANユーザーとしてOracle Management Repositoryを格納しているデータベースにログインし、次の問合せを実行します。
DELETE FROM MGMT_PARAMETERS WHERE parameter_name LIKE 'mgmt_job_skip_job_type_upg%');
COMMIT;
また、SYSMANユーザーとしてOracle Management Repositoryに対するSQLPlusセッションを作成し、次のコマンドを実行します。
|
警告: ジョブ・タイプ |
BEGIN
FOR c IN (SELECT job_type_id
FROM MGMT_JOB_TYPE_MAX_VERSIONS
WHERE job_type IN ('<job type 1>', '<job type 2>', ...))
LOOP
MGMT_JOB_ENGINE.reschedule_on_new_jobtype_ver(c.job_type_id);
COMMIT;
END LOOP;
END;
この項の内容は次のとおりです。
遅延データ移行は、旧リリースのEnterprise Managerに格納されているデータのフォーマットを、アップグレード後のEnterprise Managerシステムと互換性のあるフォーマットに移行する、アップグレード後アクティビティの1つです。この移行アクティビティは基本的に、Oracle Management Repositoryのアップグレード時に発行されるEnterprise Managerのジョブであり、アップグレード後のEnterprise Managerシステムが機能し始めるときバックグラウンドで実行するようにスケジュールされます。
Enterprise Manager Cloud Controlに格納されているデータのフォーマットは、旧リリースのEnterprise Managerに格納されていたデータのフォーマットと異なります。
そのため、旧リリースのEnterprise ManagerからEnterprise Manager Cloud Controlにアップグレードするときは、データ・フォーマットが、Enterprise Manager Cloud Controlと互換性のあるフォーマットに自動的に変換または移行されます。
ただし、データ・フォーマットの移行にかかる時間は、旧リリースのEnterprise Managerで使用できるデータの大きさによって異なります。したがって、大量のデータがある場合には移行に長時間かかるため、アップグレード・プロセスが完了するまでの時間も長くなります。アップグレード・プロセスが完了するまで、1システム・アップグレード方式(ローカル・ホスト上でも、別のリモート・ホスト上でも)を使用する場合は特に、既存のEnterprise Managerシステムは使用できなくなる可能性があります。
この点を考慮してオラクル社は、別々の2段階でデータ・フォーマットを移行するようにアップグレード・プロセスを調整しました。
第1フェーズでは、Enterprise Managerシステムを停止してアップグレードし、短い停止時間で新しいシステムが動作を開始できるように、Enterprise Manager Cloud Controlの機能に必要な最も重要なデータを短時間のうちに移行します。この時点では一部の履歴データしか利用できませんが、アップグレード後のEnterprise Managerシステムでターゲットの監視を開始し、アップグレード後のOracle Management Agentによって生成される新しいアラートを確認することができます。
第2フェーズでは、アップグレード後のEnterprise Managerシステムが動作を開始した後で、残りのデータを移行します。
Enterprise Manager Cloud Controlの動作開始後、第2フェーズでフォーマットが移行されるデータを遅延データと呼び、この旧フォーマットから新フォーマットへの移行プロセスを遅延データ移行と呼びます。
|
警告: DDMPジョブの実行中は、OMSまたは管理リポジトリを停止または再起動しないでください。 |
アップグレード後に、遅延データ移行ジョブのステータスをチェックします。特に、FLATアソシエーション構築タスクが正常に完了していることを確認します。
遅延データ移行ジョブのステータスを追跡するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。
アップグレード後のタスク・ページで、「遅延データ移行」タブをクリックします。
このタブには、データ移行ジョブのリスト、およびジョブのステータス、開始日時、終了日時が表示されます。
このタブでは次の処理が可能です。
コンポーネントに対してデータ移行ジョブを開始するには、コンポーネントを選択して「開始」をクリックします。デフォルトでは、ジョブはただちに開始されます。この動作は変更できません。
失敗したジョブを再実行するには、ステータス・アイコンをクリックして「ジョブ実行」ページにアクセスします。「ジョブ実行」ページで「編集」をクリックします。<JobName>ジョブの編集ページで、「発行」をクリックしてジョブを再実行します。
表の列の表示/非表示を切り替えるには、「表示」リストから適切なオプションを選択します。
画面から表をデタッチするには、「デタッチ」をクリックします。
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。 |
この項の内容は次のとおりです。
発生データ移行は、旧リリースのOracle Management Repository(管理リポジトリ)に格納されている発生データをアップグレード後の管理リポジトリに移行する、アップグレード後アクティビティの1つです。発生データは、ブラックアウト、アラート、イベント、メトリックなどの機能領域に関連しています。
|
注意: 発生データ移行プロセスでは、管理リポジトリのバックアップ後に実行された次の変更は、どれも移行されません。これらの変更がアップグレード後のEnterprise Managerシステムで必要な場合は、アップグレードにこれらの変更を再度手動で実行する必要があります。
第13.9項に記載されている差分レポートを確認して、ADMPプロセスを介して移行されないすべての変更と手動での移行が必要な変更を確認してください。 |
この移行アクティビティは基本的に、旧リリースのOracle Management Agent (管理エージェント)がOracle Management Agent 12cにスイッチオーバーされた直後、特に2システム・アップグレード方式の場合に、バックグラウンドで実行されるEnterprise Managerのジョブです。
アップグレード・プロセスの一部として、旧リリースのOracle Management AgentをOracle Management Agent 12cにスイッチオーバーするとき、新しい管理エージェントはEnterprise Manager Cloud Controlとの通信を開始し、アップグレード後のOracle Management Repository(管理リポジトリ)へのデータのアップロードを開始します。
1システム・アップグレード方式の場合、Enterprise Managerシステムの全体がアップグレードされるため、管理エージェントはすべて任意の時点でスイッチオーバーされます。この方式では、旧リリースの管理エージェントがアップグレード後の管理エージェントと共存できないため、一度スイッチオーバーすると、アップグレード後の管理エージェントは1つの管理リポジトリ、つまりアップグレード後のリポジトリにしかデータをアップロードしません。したがって、発生データには対応しないことになります。
これに対して、2システム・アップグレード方式の場合には、管理エージェントへの段階的なスイッチオーバーを選択できます。一方の管理エージェント・セットをスイッチオーバーすると、それらのホストおよびターゲットに関するデータがアップグレード後の管理リポジトリにアップロードされ始めますが、もう一方の管理エージェント・セットはまだスイッチオーバーされていないため、それらのホストおよびターゲットに関するデータは引き続き古い管理リポジトリにアップロードされます。したがって、一部の管理エージェントのみがスイッチオーバーされた場合には、旧リリースの管理エージェントとアップグレード後の管理エージェントが共存することになり、そのような状況では、データは新しい管理リポジトリと同時に古い管理リポジトリにもアップロードされます。ただし、常に1つの管理エージェントのみが1つのホストを表すため、この共存は、同じホストに2つの管理エージェントがあるという意味ではありません。ホストを監視する旧リリースの管理エージェントが、別のホストを監視するアップグレード後の管理エージェントと共存することのみを意味します。
次のフェーズで次のセットの管理エージェントをスイッチオーバーすると、アップグレード後の管理リポジトリにデータをアップロードしますが、スイッチオーバー以前に古い管理リポジトリにアップロードされていたデータも、古い管理リポジトリに残されます。このデータを発生データと呼び、古い管理リポジトリから新しい管理リポジトリへ発生データを移行するプロセスを発生データ移行プロセスと呼びます。
|
注意:
|
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。 |
発生データ移行ジョブのステータスを追跡するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。
アップグレード後のタスク・ページで、「発生データ移行」タブをクリックします。
発生データ移行ページに、Enterprise Managerシステムで使用可能なすべてのターゲットに関連する発生データ移行ジョブについての情報が表示されます。デフォルトでは、各ターゲットに対して、発生データ移行ジョブによってECM履歴詳細およびメトリック詳細が移行されます。
このタブでは次の処理が可能です。
すべてのターゲットに対して移行されるデータを制御するには、「発生データ移行の実行対象」リストから次のオプションのいずれかを選択します。
ECMの履歴の移行: ECM履歴詳細のみを移行します。
メトリック・データの移行: メトリック詳細のみを移行します。
すべてのコンポーネント: ECM履歴詳細およびメトリック詳細を移行します。
各種のデータを表示するには、ターゲットの表示リストから、次のオプションからいずれかを選択します。
すべて: Enterprise Managerシステムのすべてのターゲットについて、すべての発生データ移行ジョブを表示します。
アクティブ: 失敗した、または現在実行中の発生データ移行ジョブを表示します。
履歴: 成功した発生データ移行ジョブを表示します。
未開始: まだ開始されていない発生データ移行ジョブを表示します。
失敗したジョブを再試行するには、ジョブが失敗したターゲットを選択し、「再試行」をクリックします。
実行中のジョブを停止するには、ジョブを停止するターゲットを選択して「停止」をクリックします。
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。 |
この項の内容は次のとおりです。
差分レポートには、2システム・アップグレード方式を使用して旧リリースのEnterprise ManagerをEnterprise Manager Cloud Controlにアップグレードしたときに手動で行われた、構成または設定関係の変更に関する情報が表示されます。
2システム・アップグレード方式では、アップグレード操作が終了するまで、旧リリースのEnterprise ManagerがEnterprise Manager Cloud Controlと共存します。一部の本番環境では、データ量が多いためにアップグレード操作の完了に長く時間がかかる場合があるので、その間に旧リリースの機能領域に変更を加えることができます。
たとえば、追加のソフトウェア・ライブラリ・エンティティ、新規ジョブ、新規デプロイメント・プロシージャなどを追加するとします。
このような変更は、アップグレード後のシステムが旧リリースと同一になるようにEnterprise Manager Cloud Controlに対して実行する必要があります。差分レポートには、Enterprise Manager Cloud Controlでこのような変更を元に戻すことができるように、変更内容のサマリーが示されます。
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。 |
|
注意: 差分レポートに表示されるすべての変更は、古いEnterprise Managerシステムから新しいシステムへのアップグレード・プロセスでは移行されないため、それらを手動で移行する必要があります。差分レポートの使用中に、データベース・リンク関連の設定を変更しないでください。 |
差分レポートを生成および表示するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。
アップグレード後のタスク・ページで、「差分レポート」タブをクリックします。
「差分レポート」ページには、様々なコンポーネントに対して過去に生成されたレポートがリストされます。ただし、初めてこのページを表示する際には、レポートは表示されません。
このページで、次の処理が可能です。
各コンポーネントに対するレポートを生成するには、レポートの再生成をクリックします。
|
注意: レポートの再生成をクリックすると、「ステータス」列のステータスが「進行中」に変わります。ステータスが「完了」に変わるまで、ページの手動リフレッシュを続けます。 |
特定のコンポーネントのレポートを表示するには、表からコンポーネント(行)を選択し、レポートの表示をクリックします。
レポートをリフレッシュして、コンポーネントに関連する最新の変更を表示するには、表からコンポーネント(行)を選択し、レポートの再生成をクリックします。
表の列の表示/非表示を切り替えたり、表の列を並べ替えるには、「表示」リストから適切なオプションを選択します。
画面から表をデタッチするには、「デタッチ」をクリックします。
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。 |
既存のEnterprise Managerシステムで使用できるターゲットがアップグレード後のEnterprise Managerシステムでアクティブ(監視対象)になるためには、そのターゲットを監視しているOracle Management Agentが、Oracle Management Agent 12cを使用してアップグレード後のEnterprise Managerシステムにスイッチオーバーされている必要があります。
アップグレード後のEnterprise Managerシステムで現在アクティブでないターゲットのリストを表示するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。
「アップグレード後のタスク」ページで「アクティブ化を保留中のターゲット」タブをクリックします。
このタブに、非アクティブ・ターゲットのリストが表示されます。
目的のターゲットを検索するには、キーワード、もしくはターゲット名(またはターゲット・タイプ)の一部を、「ターゲット名」列(または「ターゲット・タイプ」列)のすぐ上にある検索テキスト・ボックスに入力します。
または、「検索の絞込み」ペイン内のリンクをクリックして表をフィルタ処理し、目的のターゲットをリスト表示できます。
|
注意: このような非アクティブ・ターゲットをアクティブ・ターゲットに変換するには、既存のEnterprise Managerシステムでこれらのターゲットを監視している管理エージェントを、アップグレード後のEnterprise Managerシステムに切り替えます。管理エージェントをスイッチオーバーする方法の詳細は、第11.4項を参照してください。 |
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)に対する、1システム・アップグレード、2システム・アップグレード、および異なるホスト上の1システム・アップグレードのみに適用可能です。 |
Oracle Management Agent (管理エージェント)を新規Enterprise Managerシステムにスイッチオーバーした後、前のリリースの管理エージェントをアンインストールできます。管理エージェントを手動でアンインストールするかわりに、管理エージェントごとに発生データ移行プロセス(ADMP)を正規にサインオフし、アップグレード後のコンソールによって管理エージェントを自動的にアンインストールすることができます。
|
注意: サインオフ・プロセスでは、すべての資格証明が管理エージェント上でファイル・システム関連の操作を実行するように設定する必要があるため、必要なすべての資格証明が設定されていることを確認してください。 |
管理エージェントごとにADMPプロセスをサインオフするには、次の手順に従います。
Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。
アップグレード後のタスク・ページで、サインオフ・タブをクリックします。
デフォルトでは、すべての管理エージェントがサインオフ・ステータスとは関係なく、このページにリストされます。
このページで、ADMPプロセスをサインオフしたか、まだサインオフしていない管理エージェントを検索します。
(i) 「検索基準」リストから適切なオプションを選択します。
(ii) 「エージェント」フィールドで、管理エージェントの名前を入力します。特定のサインオフ・ステータスを持つすべての管理エージェントを検索する場合、このフィールドは空白のままでかまいません。また、名前の一部を入力し、ワイルドカードを使用して同じ名前を持つ管理エージェントを検索することもできます。
(iii) 「検索」をクリックします。
正規にサインオフする管理エージェントを選択します。1回ですべての管理エージェントを選択するには、「すべて選択」を有効にします。
|
注意: 「マスター・エージェント」を選択してサインオフする場合、すべての共有エージェントがサインオフして初めてサインオフしてください。サインオフしていない場合、これらの共有エージェントを選択して、マスター・エージェントとともにサインオフします。 |
「エージェントのサインオフ」をクリックします。
選択した管理エージェントが実行されていたホストにアクセスするための資格証明を指定します。
「送信」をクリックします。
|
注意: サインオフすると、選択された管理エージェントが自動的にアンインストールおよび削除されるため、リカバリできません。そのため、サインオフする前に、管理エージェントを正常にスイッチオーバーし、それらが適切に機能し、ターゲットが新しいEnterprise Managerシステムで正常に監視されていることを確認します。 |
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)に対する、1システム・アップグレード、2システム・アップグレード、および異なるホスト上の1システム・アップグレードのみに適用可能です。 |
遅延データ移行プロセス(DDMP)、管理エージェントのスイッチオーバー、発生データ移行プロセス(ADMP)、差分レポートで集計される手動データ移行の後に、正規に移行プロセスをサインオフし、アップグレード・モードを終了します。
|
警告: サインオフは、アップグレード・プロセスの最後の手順である必要があります。これが終了すると、すべてのアップグレード関連のプロセスおよびリソースがクリーンアップされるため、すべてのADMPジョブまたはDDMPジョブの実行や、差分レポートを生成することはできません。 |
移行プロセスをサインオフして、正規にアップグレード・モードを終了するには、次の手順に従います:
Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。
アップグレード後のタスク・ページで、サインオフ・タブをクリックします。
このページで、「移行のサインオフ」を選択して、「実行」をクリックします。このオプションは、表の下の左下部にあります。
(2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式にのみ適用)アップグレード・モードの終了後、第13.13項の説明に従って、古い中央エージェントを削除します。
中央エージェントの削除後、削除した中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。
この項では、古い中央エージェントおよびそれに関連付けられているターゲットを削除するための手順について説明します。
|
注意: この項は、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)での、2システム・アップグレードおよび異なるホストでの1システム・アップグレードにのみ適用されます。 |
2システム・アップグレード方式または異なるホストでの1システム・アップグレード方式を使用して、10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をアップグレードした場合、スイッチオーバーされなかった古い中央エージェントを削除します。この中央エージェントは必要ありません。
|
注意: アップグレード前コンソールで、中央エージェントは選択肢としてリストされますが、選択してデプロイメントおよび構成ジョブの発行を試みると、選択した中央エージェントが検証され、問題のあるエージェンとしてレポートされます。そのため、それらはデプロイまたは構成できないため、結果としてスイッチオーバーできません。これらの中央エージェントは不要になったため、削除する必要があります。 |
古い中央エージェントおよび関連付けられているターゲットを削除するには、次の手順に従います。
前提条件として、第13.1項に記載されているとおり、Enterprise Manager Cloud Controlがインストールされているホストを検証します。
アップグレードした管理リポジトリ(12.1.0.5のリポジトリ)でSYSMANユーザーとして次の問合せを実行することによって、中央エージェントを特定します。問合せによって中央エージェントおよびそれらに監視されるターゲットがレポートされますが、中央エージェント名のみを書き留めます。中央エージェントを削除すると、それらに監視されているターゲットも削除されます。
SELECT ag.target_name agent_name, t.target_name target_name, t.target_type target_type FROM sysman.mgmt_targets ag, sysman.em_current_availability eca, sysman.PRE_UPGC_AGT_STAT_MGMT puasm, sysman.mgmt_targets t WHERE ag.target_guid = eca.target_guid AND eca.current_status = 4 AND eca.current_sub_status = 1 AND ag.target_type='oracle_emd' AND puasm.target_guid = ag.target_guid AND puasm.UPGRADE_STATUS !='IGNORE_UPGRADE' AND ag.emd_url IN (SELECT emd_url FROM mgmt_targets WHERE target_type = 'host' AND target_name IN (SELECT value FROM mgmt_oms_parameters WHERE name = 'HOST_NAME')) AND ag.emd_url NOT IN (SELECT emd_url FROM sysman.mgmt_targets WHERE target_type='oracle_emrep') AND t.emd_url = ag.emd_url ORDER BY ag.target_name, t.target_type, t.target_name
特定した、古い中央エージェントを削除します。
新しいEnterprise Manager Cloud Controlをインストールしたリモート・ホストで、OMSホームから、EM CLIクライアントにログインします。各OMSインストールでEM CLIクライアントをデフォルトで使用できるため、クライアントを個別にインストールする必要がありません。
$<OMS_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>
EM CLIを同期します。
$<OMS_HOME>/bin/emcli sync
中央エージェントを削除します。ここで、agentNameは、削除する中央エージェントの名前です。
$<OMS_HOME>/bin/emcli delete_target -name=<agentName> -type=oracle_emd -delete_monitored_targets
次に例を示します。
$/u01/software/oracle/middleware/oms/bin/emcli delete_target -name=example.com:4567 -type=oracle_emd -delete_monitored_targets
(オプション)中央エージェントの削除後、削除した中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。
|
注意: この項は、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)からの1システム・アップグレードにのみ適用されます。 |
10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)にアップグレードした後、一般的には、第13.13.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)へアップグレードした場合、12.1.0.5 Enterprise Manager Cloud Control Consoleに、古い不要な10gまたは11gの中央エージェントがアクティブ化保留中状態で引き続き表示されます。
そのような不要な中央エージェントがアクティブ化保留中状態で表示される場合、次の手順を実行して削除します。
前提条件として、第13.1項に記載されているとおり、Enterprise Manager Cloud Controlがインストールまたはアップグレードされているホストを検証します。
アップグレードした管理リポジトリ(12.1.0.5のリポジトリ)でSYSMANユーザーとして次の問合せを実行することによって、削除する不要な中央エージェントを特定します。問合せによって中央エージェントおよびそれらに監視されるターゲットがレポートされますが、中央エージェント名のみを書き留めます。中央エージェントを削除すると、それらに監視されているターゲットも削除されます。
SELECT ag.target_name agent_name, t.target_name target_name, t.target_type target_type FROM sysman.mgmt_targets ag, sysman.em_current_availability eca, sysman.PRE_UPGC_AGT_STAT_MGMT puasm, sysman.mgmt_targets t WHERE ag.target_guid = eca.target_guid AND eca.current_status = 4 AND eca.current_sub_status = 1 AND ag.target_type='oracle_emd' AND puasm.target_guid = ag.target_guid AND puasm.UPGRADE_STATUS !='IGNORE_UPGRADE' AND ag.emd_url NOT IN (SELECT emd_url FROM sysman.mgmt_targets WHERE target_type='oracle_emrep') AND t.emd_url = ag.emd_url ORDER BY ag.target_name, t.target_type, t.target_name
不要な中央エージェントを削除します。
アップグレードしたOMSホストで、OMSホームから、EM CLIクライアントにログインします。各OMSインストールでEM CLIクライアントをデフォルトで使用できるため、クライアントを個別にインストールする必要がありません。
$<OMS_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>
EM CLIを同期します。
$<OMS_HOME>/bin/emcli sync
不要な中央エージェントを削除します。ここで、agentNameは、削除する中央エージェントの名前です。
$<OMS_HOME>/bin/emcli delete_target -name=<agentName> -type=oracle_emd -delete_monitored_targets
次に例を示します。
$/u01/software/oracle/middleware/oms/bin/emcli delete_target -name=example.com:4567 -type=oracle_emd -delete_monitored_targets
|
注意: この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)での、2システム・アップグレードおよび異なるホストでの1システム・アップグレードにのみ適用されます。 |
2システム・アップグレード方式または異なるホストでの1システム・アップグレード方式を使用して、10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をアップグレードした場合、第13.13項の説明に従って、不要な古い中央エージェントを削除する必要があります。この中央エージェントの削除後、削除した中央エージェントで監視されていたターゲットを引き続き監視する場合は、次の手順に従います。
古い中央エージェント・ホスト上で、新規OMSからホスト・ターゲットの追加ウィザードを使用して新規のOracle Management Agent 12cをインストールします。
そのホストで実行中のすべてのターゲットを検出し、新規OMSで監視できるようにします。
Enterprise Managerシステムを完全にアップグレードした後に、古いOMSホームを削除する場合は、次の手順に従います。
12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)にアップグレードした場合は、完全リリースまたは追加OMSのいずれの場合も、付録Kで概説されている手順に従います。
11gリリース1 (11.1.0.1)から12cリリース4 (12.1.0.4)へアップグレードした場合は、完全リリースまたは追加OMSのいずれの場合も、『Oracle Enterprise Manager Grid Controlアドバンスト・インストレーションおよび構成ガイド』で説明されている手順に従います。
10gリリース5 (10.2.0.5)から12cリリース4 (12.1.0.4)にアップグレードした場合は、完全リリースまたは追加OMSのいずれの場合も、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』で説明されている手順に従います。
CDBおよびPDBで構成されたデータベースにSYSMANスキーマを移行する計画の場合、次の要件を満たしていることを確認します。
非CDBベースのデータベースへのアップグレード。データベース・アップグレード・プロセスの中で、非CDBベースのデータベースのキャラクタ・セットがCDBと同じであることを確認します。その後、アップグレード済の非CDBベースのデータベースからCDB内の新しいPDBへSYSMANスキーマを移行します。
更新済のデータベースの詳細で接続識別子を修正します。これを実行するには、各OMSインスタンスで次の手順を実行します。
すべてのOMSインスタンスを停止します。
emctl stop oms-all
最初のOMS上で管理サーバーを起動します。
emctl start oms -admin-only
各OMSインスタンスで、管理リポジトリの接続識別子を修正します。
emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<service_name>)))"
次に例を示します。
emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.example.com)(PORT=1522))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=pdb2.example.com)))"
すべてのOMSインスタンスを停止して起動します。
emctl stop oms-all
emctl start oms
OMSの監視構成および管理リポジトリのターゲットを修正します。
emctl config emrep -conn_desc
外部ロールの作成オプションを有効にし、新しいロールの作成中に使用するには、外部認証関連のプロパティをOMSに設定します。これを行うには、次のコマンドを実行します。Enterprise Managerがシングル・サインオン(SSO)で認証されている場合は、LDAPではなく、値SSOがoracle.sysman.emSDK.sec.DirectoryAuthenticationTypeプロパティに設定します。
OMS_HOME/bin>emctl set property -name "oracle.sysman.core.security.auth.is_external_authentication_enabled" -value "true"
OMS_HOME/bin>emctl set property -name "oracle.sysman.emSDK.sec.DirectoryAuthenticationType" -value "LDAP"
詳細は、My Oracle Support Note 1902075.1を参照してください。
