この章では、実行する必要があるインストール後のタスクについて説明します。特に、次の内容について説明します。
13cリリース3へのアップグレードはアウトオブプレース・アップグレードであるため、旧リリースのEnterprise Managerシステムで行われたカスタム構成、および旧リリースのEnterprise Managerシステムで構成されているWebLogic Serverで行われたカスタマイズはすべて、アップグレード・プロセスによって継承されません。アップグレードしたシステムで、カスタマイズを再実行する必要があります。
注意:
この項は、Oracle WebLogic Serverのカスタム証明書にのみ適用され、Enterprise Managerコンソールの証明書には適用されません。Enterprise Managerコンソールの証明書は、アップグレード時に自動的にコピーされます。
カスタム証明書がOracle WebLogic Server (管理サーバーおよび管理対象サーバー)に対して構成されていた場合、13c リリース3へのアップグレード後にそのカスタム証明書は引き継がれません。かわりに、Oracle WebLogic Serverはデモ証明書を使用して構成されます。そのため、アップグレード後にカスタム証明書を使用してOracle WebLogic Serverを再構成してください。次の手順を実行します。
最初のOMSのアップグレード後、エージェント・アップグレード・コンソールまたはEM CLIを使用した13cリリース3への中央エージェントまたはスタンドアロン管理エージェントのアップグレードの説明に従って、そのホストの中央エージェントをすぐにアップグレードすることをお薦めします。
ただし、そのホストの中央エージェントをアップグレードせずに追加OMSの13cリリース3へのアップグレードを続行した場合は、そのアップグレード済の追加OMSのバージョンを管理サービスページで確認します。これを実行するには、「設定」メニューから、「Cloud Controlの管理」、「管理サービス」の順に選択します。OMSバージョンを確認します。
まだアップグレードされたバージョンではなく古いバージョンが表示されている場合は、追加OMSホストの管理エージェントを再起動します。
ここでは、以下の項目について説明します。
遅延データ移行は、旧リリースの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ジョブの取消しまたは停止は、推奨されません。
警告:
DDMPジョブの実行中は、OMSまたは管理リポジトリを停止または再起動しないでください。
Oracle Exalogic Systemターゲットを必ずアップグレードしてください。
ジョブを正常に実行してOracle Exalogic Systemターゲットをアップグレードするには、12.1.0.3以上のバージョンのOracle Fusion Middlewareプラグインが含まれるように、これらのターゲットをモニタリングする管理エージェントが次のサポートされるリリースにすでにアップグレード済である必要があります。
Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)からのアップグレードで、12cリリース5 (12.1.0.5)へのアップグレード時にこの手順を実行していない場合は、ここで13cリリース2でこの手順を実行します。この場合、管理エージェントが13c リリース3、13c リリース2、13c リリース1、12c リリース5 (12.1.0.5)、または12c リリース4 (12.1.0.4)のいずれかであることを確認します。
Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)からのアップグレードで、12cリリース4 (12.1.0.4)へのアップグレード時にこの手順を実行していない場合は、ここで13cリリース2でこの手順を実行します。この場合、管理エージェントが13c リリース3、13c リリース2、13c リリース1、または12c リリース4 (12.1.0.4)のいずれかであることを確認します。
これらの1つ以上の管理エージェントをサポートされるこれらのリリースにまだアップグレードしていない場合、ジョブが失敗し、Oracle Exalogic Systemターゲットはアップグレードされません。このような状況で問題を解決するには、最初に対象の管理エージェントをアップグレードしてから、Oracle Exalogic Systemターゲットをアップグレードするためのこのジョブを再発行します。
Enterprise Managerシステム(フル・リリースまたは追加OMS)を完全にアップグレードした後で、古いOMSホームの削除を選択できます。手順は、古いOMSホームの削除を参照してください。
10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース4 (12.1.0.4)または12cリリース5 (12.1.0.5)にアップグレードした後、切り替えられなかった古い中央エージェントを削除することが理想的です。しかし、なんらかの理由で不要な中央エージェントをその時点で削除せず、12c リリース5 (12.1.0.5)から13c リリース3にアップグレードした場合、13c リリース3 Enterprise Manager Cloud Controlコンソールで、古くて不要な10gまたは11gの中央エージェントがアクティブ化保留中状態で表示され続けます。
そのような不要な中央エージェントがアクティブ化保留中状態で表示される場合、次の手順を実行して削除します。
アップグレードした管理リポジトリで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のOracleホームから、EM CLIクライアントにログインします。各OMSインストールでEM CLIクライアントをデフォルトで使用できるため、クライアントを個別にインストールする必要がありません。
$<ORACLE_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>
EM CLIを同期します。
$<ORACLE_HOME>/bin/emcli sync
不要な中央エージェントを削除します。ここで、agentName
は、削除する中央エージェントの名前です。
$<ORACLE_HOME>/bin/emcli delete_target -name=<agentName> -type=oracle_emd -delete_monitored_targets
たとえば、次のようになります。
$/u01/software/oracle/middleware/bin/emcli delete_target -name=example.com:4567 -type=oracle_emd -delete_monitored_targets
中央エージェントを削除すると、それらにモニターされているターゲットも削除されます。ただし、そのようなターゲットのモニターを続ける場合は、新しい13cリリースの管理エージェントをホストにインストールして、再度ターゲットの検出を初めからやり直します。
CDBおよびPDBで構成されたデータベースにSYSMANスキーマを移行する計画の場合、次の要件を満たしていることを確認します。
非CDBベースのデータベースへのアップグレード。データベース・アップグレード・プロセスの中で、非CDBベースのデータベースのキャラクタ・セットがCDBと同じであることを確認します。その後、アップグレード済の非CDBベースのデータベースからCDB内の新しいPDBへSYSMANスキーマを移行します。
更新済のデータベースの詳細で接続識別子を修正します。これを実行するには、各OMSインスタンスで次の手順を実行します。
OMSを停止します。
emctl stop oms
最初のOMS上で管理サーバーを起動します。環境内の他のすべてのOMSでこの指示に従っている場合は、この手順をスキップします。
emctl start oms -admin_only
管理リポジトリの接続識別子を変更します。
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 "<TNS_connect_descriptor>"
古いOMSに関連付けられているJVMターゲットがある場合は、WebLogicドメインをリフレッシュした後も、古いOMSに関連付けられているJVMターゲットがWebLogicドメインのホームページに引き続き表示されます。これは予測されている動作です。
履歴データの表示のためにこれを保持するか、削除することを選択できます。削除するには、孤立したJVMターゲットを右クリックして、「ターゲットの削除」を選択します。
Enterprise Managerシステムの停止時間を短縮するためのジョブ・タイプの更新の選択的なスキップの説明に従って特定のジョブ・タイプのアップグレードを選択してスキップまたは後回しにした場合は、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セッションを作成し、次のコマンドを実行します。
警告:
ジョブ・タイプPropagateTarget
およびExecLoaderCallbacks
はリストに含めないでください。
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;