7 使用の開始

この章では、様々なアップグレード方式を使用して、Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をEnterprise Manager Cloud Control 12cリリース2 (12.1.0.2)にアップグレードするための高度なプロセスについて説明します。この章では特に、次のことについて説明します。

• 1システム・アップグレード方式を使用したアップグレード

• 2システム・アップグレード方式を使用したアップグレード

• 異なるホストでの1システム方式を使用したアップグレード

1システム・アップグレード方式を使用したアップグレード

表7-1に、1システム・アップグレード方式でEnterprise Manager Grid ControlをEnterprise Manager Cloud Control 12cリリース2 (12.1.0.2)にアップグレードする手順を示します。

表7-1 1システム・アップグレード方式を使用したEnterprise Manager Grid Controlのアップグレード

手順番号	手順	プロシージャ
手順1	準備
(a)	1システム・アップグレード方式について学習します。	10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレード
(b)	開始する前に理解しておく必要のある重要事項を確認します。	第2章
手順2	アップグレード前のタスクの実行
(a)	すべてのOMSインスタンスにアップグレード前コンソール・パッチを適用し、アップグレード前コンソールにアクセスします。	アップグレード前コンソール
(b)	次のソフトウェアを手動でダウンロードし、アクセス可能な場所にステージングします。 Oracle Management Agent 12c 必要なプラグインすべて	Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのインストール
(c)	手順2(b)で手動ダウンロードし、ステージングしたソフトウェアの場所に関する情報を提供します。	ソフトウェアの管理
(d)	環境を分析して、有効および無効なインベントリを持つOracle Management Agent(管理エージェント)を識別し、これらのエージェントのアップグレード性をチェックして、問題のある管理エージェントを明らかにします。必要なソフトウェアが不足している場合、手順(b)と(c)を繰返します。	環境の分析
(e)	管理エージェントをアップグレードするための前提条件を満たします。	付録E
手順3	Oracle Management Agentのアップグレード
(a)	Oracle Management Agent 12cのソフトウェア・バイナリをデプロイおよび構成します。	Oracle Management Agentのデプロイおよび構成
(b)	状態レポートを生成し、事前にデプロイした管理エージェントの準備状況を確認します。	デプロイしたOracle Management Agentの状態レポートの生成
(c)	ヘルス・チェック・レポートを検証およびサインオフします。	デプロイしたOracle Management Agentの状態レポートの検証およびサインオフ
(d)	従来の管理エージェントから新しくデプロイされた管理エージェントにスイッチオーバーします。これにより、Enterprise Manager Cloud Controlと通信できるようになります。 注意: 多くのエージェントを使用している場合、Oracle Management Agentを一度に1セットずつアップグレードすることができます。この場合、試行ごとに手順3(a)から手順3(d)を繰り返すことができます。	Oracle Management Agent 12cへのスイッチオーバー
(e)	サーバー・ロード・バランサ(SLB)が構成されている場合、モニタの設定を変更します。	付録F
手順4	Oracle Management ServiceおよびOracle Management Repositoryのアップグレード
(a)	次の前提条件を満たします。 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章で説明されているOracle Management Service関係の前提条件を満たします。 付録Eで説明されている管理エージェント関連の前提条件を満たします。 「アップグレードでサポートされているプラットフォーム」で示されている、サポートされているプラットフォームのみでアップグレードを行うようにします。 Enterprise Managerで使用されるポートが、1024以下の値に設定されていないことを確認します。この値以下に設定されている場合、アップグレードは失敗します。1024以下のポートは、一般にルート・ユーザー(スーパー・ユーザー)用に予約されています。このため、ポートは1024より大きくしてください。 OMS、管理リポジトリ、およびソフトウェア・ライブラリをバックアップします。アップグレードが失敗した場合、常にバックアップを使用してリストアできます。 バックアップの手順は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
(b)	管理リポジトリで、次の前提条件を満たします。 MGMT_CONNECTOR_CONFIG表にNULL行がないことを確認します。これを確認するには、次のSQL問合せを実行します。 select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null; 通常、このコマンドは1行も返しません。行が返された場合は、次のSQL問合せを実行して表をクリーニングします。 delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL; commit; 管理リポジトリにカスタム作成のマテリアライズド・ビューがないことを確認します。これを確認するには、次のSQL問合せを実行します。通常、このコマンドは1行も返しません。行が返された場合は、Oracleサポートに連絡してください。 select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER> 作成されたスナップショットが表にないことを確認します。これを確認するには、管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行します。 select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER> 次に例を示します。 select master , log_table from all_mview_logs where log_owner='SYSMAN' 作成されたスナップショットが表にある場合、マスター表およびスナップショットの詳細が表示されます。次に例を示します。 SQL> master log_table em-violations em$violation_log スナップショットがある場合は、SYSMANユーザーとして次のコマンドを実行して削除します。 SQL> Drop snapshot log on <master> 次に例を示します。 SQL> Drop snapshot log on em-violations
(c)	既存のEnterprise Managerシステムをアップグレードする前に、このシステムで実行およびスケジュールされているデプロイ手順をすべて停止します。
(d)	(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ) JVMDまたはADP、もしくはこの両方により監視されているJVMおよびWebLogicドメインのインベントリを取ります。 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除します。 ADPマネージャ、およびJVMDマネージャをすべて停止します。 WebLogic管理コンソールを使用して、GCDomainからADP管理対象サーバーおよびJVMD管理対象サーバーをすべて削除します。 JVMD用のパージ・スクリプトを実行します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/ (b)ファイルjvmd.zipを解凍します。 (c)スクリプトjvmd_monitoringupgrade11_12.sqlを実行します。 (d)Enterprise Manager 11g Grid Controlリリース1 (11.l.0.1)のスレッド・スナップショットが存在する場合、スクリプトjvmd_traceupgrade11_12.sqlを実行します。
(e)	既存のOMSからemkeyを、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のいずれの場合でも、既存の管理リポジトリにコピーします。これを実行するには、アップグレードしようとしている古いOMSホームで次のコマンドを実行します。次のコマンドは両方のリリースで適用可能です。 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>] 注意: 次のコマンドがEnterprise Manager 11g Grid Control (11.1.0.1)で実行される際、管理パスワードを求められます。 emkeyがコピーされているかどうか検証するには、次のコマンドを実行します。 <OMS_HOME>/bin/emctl status emkey emkeyがコピーされている場合、次のメッセージが表示されます。 The EMKey is configured properly, but is not secure. Secure the EMKey by running "emctl config emkey -remove_from_repos".
(f)	これからアップグレードするOMSを停止します。また、これに接続されているその他のOMSインスタンスも停止します。 グラフィック・モードでアップグレードする場合は、「グラフィック・モードで1システム・アップグレード方式でアップグレード」の手順(12)の説明に従って、後からOMSを停止できます。 ソフトウェアのみをインストールし、後からグラフィカル・モードでアップグレードする場合は、「構成およびアップグレード」の手順(4)に従って後からOMSを停止できます。 サイレント・モードでアップグレードする場合は、OMSをただちに停止します。 Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、まずアップグレードする最初のOMSでこのコマンドを実行します。このコマンドはOMSのみを停止し、管理サーバーやその関連コンポーネントは停止しません。管理サーバーおよびその他の関連コンポーネントは、WebLogic Server資格証明を検証できるように、実行中である必要があります。 $<OMS_HOME>/bin/emctl stop oms 次に、その他すべての追加OMSインスタンスで、次のコマンドを実行します。このコマンドは、アップグレードを正常に終了するため停止する必要がある、OMSおよびその他のコンポーネント(ノード・マネージャなど)を停止します。 $<OMS_HOME>/bin/emctl stop oms -all Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合は、OMSホームから次のコマンドを実行します。 $<OMS_HOME>/opmn/bin/opmnctl stopall
(g)	管理エージェントがメトリック収集のために管理リポジトリに接続しないように、「管理サービスとリポジトリ」ターゲットを監視する管理エージェントを停止します。この管理エージェントを停止しないと、OMSアップグレードが失敗する可能性があります。
(h)	OMSと管理リポジトリをアップグレードします。グラフィック・モードとサイレント・モードのどちらでアップグレードするかを選択できます。ある時点でソフトウェア・バイナリをインストールし、後でグラフィック・モードまたはサイレント・モードでアップグレードすることも選択できます。 emkeyをコピーしていないことを示すエラー・メッセージが表示される場合は、次の手順を実行します。 古いOMSから古い管理リポジトリにemkeyをコピーします。これを実行するには、アップグレードしようとしている古いOMSホームから次のコマンドを実行します。 11gリリース1 (11.1.0.1)の場合 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc <conndesc> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora 10gリリース5 (10.2.0.5)の場合 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman password>] 注意: ここで、管理リポジトリの詳細は、アップグレードしようとしている既存の管理リポジトリの詳細です。<OMS_HOME>は、アップグレードしようとしているOMSホームです。11.1.0.1からアップグレードすると、管理サーバーのパスワードを求められます。 OMSおよび管理リポジトリのアップグレードを再試行します。	単一OMS環境の場合は、「グラフィック・モードで1システム・アップグレード方式でアップグレード」、「サイレント・モードで1システム・アップグレード方式でアップグレード」、「グラフィック・モードでの1システム・アップグレード方式でのソフトウェアのみモードのアップグレード」、または「サイレント・モードでの1システム・アップグレード方式でのソフトウェアのみモードのアップグレード」を参照してください。 複数OMS環境(追加のOMSインスタンスあり)の場合は、「複数OMS環境のアップグレード」を参照してください。
手順5	アップグレード後のタスクの実行
(a)	一般的なアップグレード前のタスクを実行します。	一般的なアップグレード後タスクの実行
(b)	遅延データ移行ジョブのステータスを追跡します。	遅延データ移行ジョブのステータスの追跡
(c)	エージェント移行プロセスをサインオフします。	エージェント移行プロセスのサインオフ
(d)	OMSに関連付けられているメトリックのインシデント・ルールを更新します。	インシデント・ルールの更新
(e)	(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ) 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除していない場合は、ここで実行します。 ad4jTargetターゲットをすべて削除します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/ (b)ファイルjvmd.zipを解凍します。 (c)スクリプトjvmd_targetupgrade11_12.sqlを実行します。 OCAMMマネージャ・ターゲットをすべて削除します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/ (b)ファイルADPManager.zipを解凍します。 (c)スクリプトadp_targetupgrade11_12.sqlを実行します。 新しいJVMDマネージャ、およびADPマネージャをデプロイします。 インベントリに基づいて、新しいJVMDエージェント、およびADPエージェントをデプロイします。

2システム・アップグレード方式を使用したアップグレード

表7-2に、2システム・アップグレード方式でEnterprise Manager Grid ControlをEnterprise Manager Cloud Control 12cリリース2 (12.1.0.2)にアップグレードする手順を示します。

表7-2 2システム・アップグレード方式を使用したEnterprise Manager Grid Controlのアップグレード

手順番号	手順	プロシージャ
手順1	準備
(a)	2システム・アップグレード方式について学習します。	10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレード
(b)	開始する前に理解しておく必要のある重要事項を確認します。	第2章
手順2	アップグレード前のタスクの実行
(a)	すべてのOMSインスタンスにアップグレード前コンソール・パッチを適用し、アップグレード前コンソールにアクセスします。	アップグレード前コンソール
(b)	既存のOMSをアップグレードするホストの情報を指定します。	Enterprise Manager Cloud Controlのホストの識別
(c)	次のソフトウェアを手動でダウンロードし、アクセス可能な場所にステージングします。 Oracle Management Agent 12c 必要なプラグインすべて	Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのインストール
(d)	手順2(c)で手動ダウンロードし、ステージングしたソフトウェアの場所に関する情報を提供します。	ソフトウェアの管理
(e)	環境を分析して、有効および無効なインベントリを持つOracle Management Agent(管理エージェント)を識別し、これらのエージェントのアップグレード性をチェックして、問題のある管理エージェントを明らかにします。必要なソフトウェアが不足している場合、手順(c)と(d)を繰返します。	環境の分析
(f)	管理エージェントをアップグレードするための前提条件を満たします。	付録E
手順3	Oracle Management ServiceおよびOracle Management Repositoryのアップグレード 注意: オプションで、Oracle Management ServiceおよびOracle Management Repositoryをアップグレードする前にOracle Management Agentのデプロイおよび構成を選択できます。この場合、ステップ3(a)から(l)の前に、ステップ4(a)を実行します。
(a)	Enterprise Manager Cloud Controlをインストールする計画のあるリモート・ホストで、次の前提条件を満たします。 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章で説明されているOracle Management Service関係の前提条件を満たします。 付録Eで説明されている管理エージェント関連の前提条件を満たします。 「アップグレードでサポートされているプラットフォーム」で示されている、サポートされているプラットフォームのみでアップグレードを行うようにします。 Enterprise Managerで使用されるポートが、1024以下の値に設定されていないことを確認します。この値以下に設定されている場合、アップグレードは失敗します。1024以下のポートは、一般にルート・ユーザー(スーパー・ユーザー)用に予約されています。このため、ポートは1024より大きくしてください。
(b)	既存のEnterprise Managerシステムをアップグレードする前に、このシステムで実行およびスケジュールされているデプロイ手順をすべて停止します。
(c)	(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ) JVMDまたはADP、もしくはこの両方により監視されているJVMおよびWebLogicドメインのインベントリを取ります。 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除します。 ADPマネージャ、およびJVMDマネージャをすべて停止します。 WebLogic管理コンソールを使用して、GCDomainからADP管理対象サーバーおよびJVMD管理対象サーバーをすべて削除します。 JVMD用のパージ・スクリプトを実行します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/ (b)ファイルjvmd.zipを解凍します。 (c)スクリプトjvmd_monitoringupgrade11_12.sqlを実行します。 (d)Enterprise Manager 11g Grid Controlリリース1 (11.l.0.1)のスレッド・スナップショットが存在する場合、スクリプトjvmd_traceupgrade11_12.sqlを実行します。
(d)	既存のOMSからemkeyを、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のいずれの場合でも、管理リポジトリのバックアップを作成する前に、既存の管理リポジトリにコピーします。これを実行するには、アップグレードしようとしている古いOMSホームで次のコマンドを実行します。次のコマンドは両方のリリースで適用可能です。 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>] 注意: 次のコマンドがEnterprise Manager 11g Grid Control (11.1.0.1)で実行される際、管理パスワードを求められます。 emkeyがコピーされているかどうか検証するには、次のコマンドを実行します。 <OMS_HOME>/bin/emctl status emkey emkeyがコピーされている場合、次のメッセージが表示されます。 The EMKey is configured properly, but is not secure. Secure the EMKey by running "emctl config emkey -remove_from_repos".
(e)	(従来のEnterprise ManagerシステムでOracle Software Libraryが構成されている場合のみ) Oracle Software Library(ソフトウェア・ライブラリ)を構成した場合、構成済ソフトウェア・ライブラリのディレクトリをそれぞれ、Enterprise Manager Cloud Controlをインストールする予定のリモート・ホストからアクセスできる場所にバックアップします。 Enterprise Manager Cloud Controlのインストール後、ソフトウェア・ライブラリの再構成には、これらのディレクトリをバックアップする場所が必要になります(手順3(l)を参照)。 たとえば、ソフトウェア・ライブラリが/programs/swlibと/software/swlibで構成されていた場合は、構成済ディレクトリ1つにつき1つ、合計2つの異なるアーカイブを作成します。この場合、programs_swlib.zipおよびsoftware_swlib.zipをそれぞれ作成します。
(f)	RMANユーティリティを使用して、管理リポジトリの入っている既存のデータベースを、まったく新しいホスト、または既存のOMSが実行されているホストにバックアップします。 既存のOMSが実行されているホストへのリポジトリのバックアップは、バックアップできるだけのスペースがある場合のみ選択します。 次に、構成されるリポジトリをアップグレードできるように、そこから新しいデータベース・インスタンスを作成します。 注意: - データベースをバックアップする前に、既存のEnterprise Managerシステムで実行されているデプロイ・プロシージャ、およびスケジュールされているデプロイ・プロシージャをすべて必ず停止してください。 - RMANユーティリティを使用して、データベースをバックアップすることをお薦めします。 - DBCAを使用してデータベースをバックアップした場合、Enterprise Manager Cloud Controlをインストールする前に、MGMT_VIEWユーザー以外のユーザー・アカウントをすべてアンロックしてください。 - Enterprise Managerコンソールで、DBクローニング機能を使用して、リポジトリをバックアップしてはいけません。バックアップした場合、Enterprise Managerコンソールで検出されたクローン・データベースは表示されません。 - 夏時間ウィンドウに存在する間はバックアップしないでください。 - 管理リポジトリのパックアップ後に既存のEnterprise Managerシステムに追加された管理エージェントまたはターゲットは、アップグレードされません。また、アップグレードされたEnterprise Managerシステムに手動で追加する必要もありません。アップグレードされたシステムに手動で追加する必要があるターゲットを特定するには、次の項の説明に従って差分レポートを参照してください。「差分レポートの生成と表示」。
(g)	バックアップした管理リポジトリで、次の前提条件を満たします。 MGMT_CONNECTOR_CONFIG表にNULL行がないことを確認します。これを確認するには、次のSQL問合せを実行します。 select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null; 通常、このコマンドは1行も返しません。行が返された場合は、次のSQL問合せを実行して表をクリーニングします。 delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL; commit; 管理リポジトリにカスタム作成のマテリアライズド・ビューがないことを確認します。これを確認するには、次のSQL問合せを実行します。通常、このコマンドは1行も返しません。行が返された場合は、Oracleサポートに連絡してください。 select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER> 作成されたスナップショットが表にないことを確認します。これを確認するには、管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行します。 select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER> 次に例を示します。 select master , log_table from all_mview_logs where log_owner='SYSMAN' 作成されたスナップショットが表にある場合、マスター表およびスナップショットの詳細が表示されます。次に例を示します。 SQL> master log_table em-violations em$violation_log スナップショットがある場合は、SYSMANユーザーとして次のコマンドを実行して削除します。 SQL> Drop snapshot log on <master> 次に例を示します。 SQL> Drop snapshot log on em-violations
(h)	バックアップした管理リポジトリのキャラクタ・セットが、元の管理リポジトリのキャラクタ・セットと同じであることを確認します。 異なる場合、次のエラー・メッセージが表示されます。 ERROR emschema.wpxegn6m8wkg - ERROR:ORA-06502: PL/SQL: numeric or value error: character to number conversion error ORA-06512: at "SYSMAN.EM_CRYPTO", line 62 ORA-06512: at "SYSMAN.EM_CRYPTO", line 229 ORA-06512: at line 1 ORA-06512: at line 24 キャラクタ・セットが同じであることを確認するには、管理リポジトリで次の問合せを実行します。 select * from nls_database_parameters where parameter like '%CHARACTERSET' キャラクタ・セットが同じでない場合は、同じにします。
(i)	Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のいずれの場合でも、古いOMSホームから次のコマンドを実行して、古い管理リポジトリからemkeyを削除します。 $<OMS_HOME>/bin/emctl config emkey -remove_from_repos [-sysman_pwd <pwd>]
(j)	管理リポジトリをバックアップした日時を指定します。 注意: 管理リポジトリのパックアップ後に既存のEnterprise Managerシステムに追加された管理エージェントまたはターゲットは、アップグレードされません。また、アップグレードされたEnterprise Managerシステムに手動で追加する必要もありません。アップグレードされたシステムに手動で追加する必要があるターゲットを特定するには、次の項の説明に従って差分レポートを参照してください。「差分レポートの生成と表示」。	リポジトリ・バックアップの詳細の指定
(k)	リモート・ホストにEnterprise Manager Cloud Controlをインストールし、手順3(f)でバックアップしたデータベースで管理リポジトリをアップグレードします。グラフィック・モードとサイレント・モードのどちらでインストールするかを選択できます。ある時点でソフトウェア・バイナリをインストールし、後でグラフィック・モードまたはサイレント・モードでアップグレードすることも選択できます。 2システム・アップグレードを実行しているホストがアップグレード前コンソールに入力したホスト名と一致しないために、OMSをアップグレードできないことを示すエラー・メッセージが表示される場合、アップグレード前コンソールに移動して正しいホスト名を指定します。 (注意: OMSをアップグレードする前に管理エージェントをデプロイすることを選択している場合に、このエラーが表示されたときは、アップグレード前コンソールでエラーを修正してから、OMSのアップグレードの前に管理エージェントを再度デプロイします。) emkeyをコピーしていないことを示すエラー・メッセージが表示される場合は、次の手順を実行します。 11gリリース1 (11.1.0.1)の場合 emkeyを古いOMSから、手順3 (f)でバックアップしたクローン管理リポジトリにコピーします。これを実行するには、アップグレードしようとしている古いOMSホームから次のコマンドを実行します。 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc <conndesc> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora 注意: ここで、管理リポジトリの詳細は、手順3 (f)でバックアップしたクローン管理リポジトリの詳細です。<OMS_HOME>は、アップグレードしようとしているOMSホームです。管理サーバーのパスワードを求められます。 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman password>] OMSおよび管理リポジトリのアップグレードを再試行します。 10gリリース5 (10.2.0.5)の場合 古いOMSから古い管理リポジトリにemkeyをコピーします。これを実行するには、アップグレードしようとしている古いOMSホームから次のコマンドを実行します。 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman password>] 手順3 (f)の説明どおりに管理リポジトリをバックアップします。 手順3 (g)の説明どおりにバックアップした管理リポジトリで前提条件を満たします。 手順3 (i)の説明どおりに古い管理リポジトリからemkeyを削除します。 OMSおよび管理リポジトリのアップグレードを再試行します。 (注意: OMSをアップグレードする前に管理エージェントをデプロイすることを選択している場合に、このエラーが表示されたときは、前述のコマンドを実行した後、必ずすべての管理エージェントを再度デプロイします。ただし、コマンドの実行後、管理エージェントの再デプロイの前に、インストーラを実行してemkeyに関するエラーが再度発生しないか確かめることをお薦めします。)	単一OMS環境の場合は、「グラフィック・モードで2システム・アップグレード方式でアップグレード」、「サイレント・モードで2システム・アップグレード方式でアップグレード」、「グラフィック・モードでの2システム・アップグレード方式でのソフトウェアのみモードのアップグレード」、または「サイレント・モードでの2システム・アップグレード方式でのソフトウェアのみモードのアップグレード」を参照してください。 複数OMS環境(追加のOMSインスタンスあり)の場合は、「複数OMS環境のアップグレード」を参照してください。
(l)	旧リリースの管理リポジトリをアップグレードした管理リポジトリにリンクします。	アップグレードしたOracle Management Repositoryへのリンクの作成
(m)	(従来のEnterprise Managerでソフトウェア・ライブラリが構成されている場合のみ) Enterprise Manager Cloud Controlでソフトウェア・ライブラリを再構築し、従来のEnterprise Managerシステム用に構成されたソフトウェア・ライブラリから独立させます。	Oracleソフトウェア・ライブラリの再構成
手順4	Oracle Management Agentのアップグレード
(a)	Oracle Management Agent 12cのソフトウェア・バイナリをデプロイおよび構成します。	Oracle Management Agentのデプロイおよび構成
(b)	状態レポートを生成し、事前にデプロイした管理エージェントの準備状況を確認します。	デプロイしたOracle Management Agentの状態レポートの生成
(c)	ヘルス・チェック・レポートを検証およびサインオフします。	デプロイしたOracle Management Agentの状態レポートの検証およびサインオフ
(d)	従来の管理エージェントから新しくデプロイされた管理エージェントにスイッチオーバーします。これにより、Enterprise Manager Cloud Controlと通信できるようになります。 注意: 多くのエージェントを使用している場合、Oracle Management Agentを一度に1セットずつアップグレードすることができます。この場合、試行ごとに手順4(a)から(d)を繰り返すことができます。	Oracle Management Agent 12cへのスイッチオーバー
手順5	アップグレード後のタスクの実行
(a)	エージェントのアップグレード・ステータスを確認します。	エージェントのアップグレード・ステータスの確認
(b)	一般的なアップグレード前のタスクを実行します。	一般的なアップグレード後タスクの実行
(c)	遅延データ移行ジョブのステータスを追跡します。	遅延データ移行ジョブのステータスの追跡
(d)	見越データ移行ジョブのステータスを追跡します。	見越データ移行ジョブのステータスの追跡
(e)	Enterprise Managementシステムの旧リリースのアップグレード中に、このリリースに対して手動で行った構成およびセットアップ関係の変更をすべて明らかにするために、差分レポートを生成します。	差分レポートの生成と表示
(f)	アップグレード後のEnterprise Managerシステムで現在アクティブでないターゲットのリストを表示します。	アップグレードしたEnterprise Managerシステム内の非アクティブ・ターゲットの表示
(g)	エージェント移行プロセスをサインオフします。	エージェント移行プロセスのサインオフ
(h)	OMSに関連付けられているメトリックのインシデント・ルールを更新します。	インシデント・ルールの更新
(i)	(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ) 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除していない場合は、ここで実行します。 ad4jTargetターゲットをすべて削除します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/ (b)ファイルjvmd.zipを解凍します。 (c)スクリプトjvmd_targetupgrade11_12.sqlを実行します。 OCAMMマネージャ・ターゲットをすべて削除します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/ (b)ファイルADPManager.zipを解凍します。 (c)スクリプトadp_targetupgrade11_12.sqlを実行します。 新しいJVMDマネージャ、およびADPマネージャをデプロイします。 インベントリに基づいて、新しいJVMDエージェント、およびADPエージェントをデプロイします。

異なるホストでの1システム方式を使用したアップグレード

表7-3に、異なるホストでの1システム・アップグレード方式でEnterprise Manager Grid ControlをEnterprise Manager Cloud Control 12cリリース2 (12.1.0.2)にアップグレードする手順を示します。

表7-3 異なるホストでの1システム・アップグレード方式を使用したEnterprise Manager Grid Controlのアップグレード

手順番号	手順	プロシージャ
手順1	準備
(a)	異なるホストでの1システム・アップグレード方式について学習します。	10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレード
(b)	開始する前に理解しておく必要のある重要事項を確認します。	第2章
手順2	アップグレード前のタスクの実行
(a)	すべてのOMSインスタンスにアップグレード前コンソール・パッチを適用し、アップグレード前コンソールにアクセスします。	アップグレード前コンソール
(b)	既存のOMSをアップグレードするホストの情報を指定します。	Enterprise Manager Cloud Controlのホストの識別
(c)	次のソフトウェアを手動でダウンロードし、アクセス可能な場所にステージングします。 Oracle Management Agent 12c 必要なプラグインすべて	Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)へのアップグレードに並行したプラグインのインストール
(d)	手順2(c)で手動ダウンロードし、ステージングしたソフトウェアの場所に関する情報を提供します。	ソフトウェアの管理
(e)	環境を分析して、有効および無効なインベントリを持つOracle Management Agent(管理エージェント)を識別し、これらのエージェントのアップグレード性をチェックして、問題のある管理エージェントを明らかにします。必要なソフトウェアが不足している場合、手順(c)と(d)を繰返します。	環境の分析
(f)	管理エージェントをアップグレードするための前提条件を満たします。	付録E
手順3	Oracle Management Agentのアップグレード
(a)	Oracle Management Agent 12cのソフトウェア・バイナリをデプロイおよび構成します。	Oracle Management Agentのデプロイおよび構成
(b)	状態レポートを生成し、事前にデプロイした管理エージェントの準備状況を確認します。	デプロイしたOracle Management Agentの状態レポートの生成
(c)	ヘルス・チェック・レポートを検証およびサインオフします。	デプロイしたOracle Management Agentの状態レポートの検証およびサインオフ
(d)	従来の管理エージェントから新しくデプロイされた管理エージェントにスイッチオーバーします。これにより、Enterprise Manager Cloud Controlと通信できるようになります。 注意: 多くのエージェントを使用している場合、Oracle Management Agentを一度に1セットずつアップグレードすることができます。この場合、試行ごとに手順3(a)から手順3(d)を繰り返すことができます。	Oracle Management Agent 12cへのスイッチオーバー
手順4	Oracle Management ServiceおよびOracle Management Repositoryのアップグレード
(a)	Enterprise Manager Cloud Controlをインストールする計画のあるリモート・ホストで、次の前提条件を満たします。 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章で説明されているOracle Management Service関係の前提条件を満たします。 付録Eで説明されている管理エージェント関連の前提条件を満たします。 「アップグレードでサポートされているプラットフォーム」で示されている、サポートされているプラットフォームのみでアップグレードを行うようにします。 Enterprise Managerで使用されるポートが、1024以下の値に設定されていないことを確認します。この値以下に設定されている場合、アップグレードは失敗します。1024以下のポートは、一般にルート・ユーザー(スーパー・ユーザー)用に予約されています。このため、ポートは1024より大きくしてください。 OMS、管理リポジトリ、およびソフトウェア・ライブラリをバックアップします。アップグレードが失敗した場合、常にバックアップを使用してリストアできます。 バックアップの手順は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。 Enterprise Managerシステムのデプロイメント・サイズ(小、中または大)を特定し、使用するデプロイメント・サイズの必要に応じてデータベース・パラメータを調整することをお薦めします。デプロイメント・サイズの特定とこれらのデータベース・パラメータの設定の手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。 Enterprise Managerインストール・ウィザードを使用してOMSおよび管理リポジトリをアップグレードする際、EM前提条件キットが自動的に実行され、データベース・パラメータがデプロイメント・サイズの必要に応じて設定されているか検証されます。最適な値に設定されていない場合、EM前提条件キットではその前提条件チェックに対して警告が表示されます。この警告に気付かない場合や、気付いていてもなんらかの理由で無視することを選択する可能性がありますが、これによってアップグレード時間は急増します。したがって、使用するデプロイメント・サイズの必要に応じてデータベース・パラメータを事前に設定することをお薦めします。
(b)	管理リポジトリで、次の前提条件を満たします。 MGMT_CONNECTOR_CONFIG表にNULL行がないことを確認します。これを確認するには、次のSQL問合せを実行します。 select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null; 通常、このコマンドは1行も返しません。行が返された場合は、次のSQL問合せを実行して表をクリーニングします。 delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL; commit; 管理リポジトリにカスタム作成のマテリアライズド・ビューがないことを確認します。これを確認するには、次のSQL問合せを実行します。通常、このコマンドは1行も返しません。行が返された場合は、Oracleサポートに連絡してください。 select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER> 作成されたスナップショットが表にないことを確認します。これを確認するには、管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行します。 select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER> 次に例を示します。 select master , log_table from all_mview_logs where log_owner='SYSMAN' 作成されたスナップショットが表にある場合、マスター表およびスナップショットの詳細が表示されます。次に例を示します。 SQL> master log_table em-violations em$violation_log スナップショットがある場合は、SYSMANユーザーとして次のコマンドを実行して削除します。 SQL> Drop snapshot log on <master> 次に例を示します。 SQL> Drop snapshot log on em-violations
(c)	既存のEnterprise Managerシステムをアップグレードする前に、このシステムで実行およびスケジュールされているデプロイ手順をすべて停止します。
(d)	(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ) JVMDまたはADP、もしくはこの両方により監視されているJVMおよびWebLogicドメインのインベントリを取ります。 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除します。 ADPマネージャ、およびJVMDマネージャをすべて停止します。 WebLogic管理コンソールを使用して、GCDomainからADP管理対象サーバーおよびJVMD管理対象サーバーをすべて削除します。 JVMD用のパージ・スクリプトを実行します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/ (b)ファイルjvmd.zipを解凍します。 (c)スクリプトjvmd_monitoringupgrade11_12.sqlを実行します。 (d)Enterprise Manager 11g Grid Controlリリース1 (11.l.0.1)のスレッド・スナップショットが存在する場合、スクリプトjvmd_traceupgrade11_12.sqlを実行します。
(e)	既存のOMSからemkeyを、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のいずれの場合でも、既存の管理リポジトリにコピーします。これを実行するには、アップグレードしようとしている古いOMSホームで次のコマンドを実行します。次のコマンドは両方のリリースで適用可能です。 $<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>] 注意: 次のコマンドがEnterprise Manager 11g Grid Control (11.1.0.1)で実行される際、管理パスワードを求められます。 emkeyがコピーされているかどうか検証するには、次のコマンドを実行します。 <OMS_HOME>/bin/emctl status emkey emkeyがコピーされている場合、次のメッセージが表示されます。 The EMKey is configured properly, but is not secure. Secure the EMKey by running "emctl config emkey -remove_from_repos".
(f)	サーバー・ロード・バランサ(SLB)が構成されている場合、モニタの設定を変更します。	付録F
(g)	従来のEnterprise Managerにより、NFSマウントされている共有ドライブにOracle Software Library(ソフトウェア・ライブラリ)が構成されている場合、Enterprise Manager Cloud Controlのインストールを計画しているリモート・ホストからこの共有ドライブにアクセスできることを確認します。 ただし、既存のEnterprise Managerの旧リリースが実行されているローカル・システムにソフトウェア・ライブラリが構成されている場合は、このソフトウェア・ライブラリを、Enterprise Manager Cloud Controlのインストールを計画しているリモート・ホストで、従来のEnterprise Managementシステムに維持されているソフトウェア・ライブラリと同じディレクトリ・パスにコピーします。
(h)	リモート・ホストにEnterprise Manager Cloud Controlをインストールし、既存のデータベースで管理リポジトリをアップグレードします。	異なるホストの1システム方式でのOMSおよび管理リポジトリのアップグレード
手順5	アップグレード後のタスクの実行
(a)	エージェントのアップグレード・ステータスを確認します。	エージェントのアップグレード・ステータスの確認
(b)	一般的なアップグレード前のタスクを実行します。	一般的なアップグレード後タスクの実行
(c)	遅延データ移行ジョブのステータスを追跡します。	遅延データ移行ジョブのステータスの追跡
(d)	エージェント移行プロセスをサインオフします。	エージェント移行プロセスのサインオフ
(e)	OMSに関連付けられているメトリックのインシデント・ルールを更新します。	インシデント・ルールの更新
(f)	(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ) 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除していない場合は、ここで実行します。 ad4jTargetターゲットをすべて削除します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/ (b)ファイルjvmd.zipを解凍します。 (c)スクリプトjvmd_targetupgrade11_12.sqlを実行します。 OCAMMマネージャ・ターゲットをすべて削除します。 (a)次の場所に移動します。 <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/ (b)ファイルADPManager.zipを解凍します。 (c)スクリプトadp_targetupgrade11_12.sqlを実行します。 新しいJVMDマネージャ、およびADPマネージャをデプロイします。 インベントリに基づいて、新しいJVMDエージェント、およびADPエージェントをデプロイします。