この章では、実行する必要があるインストール後のタスクについて説明します。特に、次の内容について説明します。
13c リリース1へのアップグレードはアウトオブプレース・アップグレードであるため、旧リリースのEnterprise Managerシステムで行われたカスタム構成、および旧リリースのEnterprise Managerシステムで構成されているWebLogic Serverで行われたカスタマイズはすべて、アップグレード・プロセスによって引き継がれません。アップグレードしたシステムで、カスタマイズを再実行する必要があります。
注意: この項は、Oracle WebLogic Serverのカスタム証明書にのみ適用され、Enterprise Managerコンソールの証明書には適用されません。Enterprise Managerコンソールの証明書は、アップグレード時に自動的にコピーされます。 |
カスタム証明書がOracle WebLogic Server (管理サーバーおよび管理対象サーバー)に対して構成されていた場合、13c リリース1へのアップグレード後にそのカスタム証明書は引き継がれません。かわりに、Oracle WebLogic Serverはデモ証明書を使用して構成されます。そのため、アップグレード後にカスタム証明書を使用してOracle WebLogic Serverを再構成してください。次の手順を実行します。
すべてのOMSインスタンス上で次のコマンドを実行します。このコマンドおよび渡すことのできるオプションの詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドを参照してください。
$<ORACLE_HOME>/bin/emctl secure wls <options>
すべてのOMSインスタンスを停止します。
$<ORACLE_HOME>/bin/emctl stop oms -all
すべてのOMSインスタンスを開始します。
$<ORACLE_HOME>/bin/emctl start oms
最初のOMSのアップグレード後、第6.2項の説明に従って、そのホストの中央エージェントをすぐにアップグレードすることを強くお薦めします。
ただし、そのホストの中央エージェントをアップグレードせずに追加OMSの13c リリース1へのアップグレードを続行した場合は、そのアップグレード済の追加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または管理リポジトリを停止または再起動しないでください。 |
アップグレード後に、遅延データ移行ジョブのステータスをチェックします。特に、FLATアソシエーション構築タスクが正常に完了していることを確認します。
遅延データ移行ジョブのステータスを追跡するには、次の手順を実行します。
Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。
アップグレード後のタスク・ページで、「遅延データ移行」タブをクリックします。
このタブには、データ移行ジョブのリスト、およびジョブのステータス、開始日時、終了日時が表示されます。
このタブでは次の処理が可能です。
コンポーネントに対してデータ移行ジョブを開始するには、コンポーネントを選択して「開始」をクリックします。デフォルトでは、ジョブはただちに開始されます。この動作は変更できません。
失敗したジョブを再実行するには、ステータス・アイコンをクリックして「ジョブ実行」ページにアクセスします。「ジョブ実行」ページで「編集」をクリックします。<JobName>ジョブの編集ページで、「発行」をクリックしてジョブを再実行します。
表の列の表示/非表示を切り替えるには、「表示」リストから適切なオプションを選択します。
画面から表をデタッチするには、「デタッチ」をクリックします。
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 リリース5 (12.1.0.5)からのアップグレードで、12c リリース5 (12.1.0.5)へのアップグレード時にこの手順を実行していない場合は、ここで13c リリース1でこの手順を実行します。この場合、管理エージェントが13c リリース1、12c リリース5 (12.1.0.5)、12c リリース4 (12.1.0.4)または12c リリース3 (12.1.0.3)のいずれかであることを確認します。
Enterprise Manager Cloud Control 12c リリース4 (12.1.0.4)からのアップグレードで、12c リリース4 (12.1.0.4)へのアップグレード時にこの手順を実行していない場合は、ここで13c リリース1でこの手順を実行します。この場合、管理エージェントが13c リリース1、12c リリース4 (12.1.0.4)または12c リリース3 (12.1.0.3)のいずれかであることを確認します。
これらの1つ以上の管理エージェントをサポートされるこれらのリリースにまだアップグレードしていない場合、ジョブが失敗し、Oracle Exalogic Systemターゲットはアップグレードされません。このような状況で問題を解決するには、最初に対象の管理エージェントをアップグレードしてから、Oracle Exalogic Systemターゲットをアップグレードするためのこのジョブを再発行します。
Enterprise Managerシステム(フル・リリースまたは追加OMS)を完全にアップグレードした後で、古いOMSホームの削除を選択できます。手順については、「付録D」を参照してください。
10g リリース5 (10.2.0.5)または11g リリース1 (11.1.0.1)から12c リリース3 (12.1.0.3)、12c リリース4 (12.1.0.4)または12c リリース5 (12.1.0.5)にアップグレードした後、切り替えられなかった古い中央エージェントを削除することが理想的です。しかし、なんらかの理由で不要な中央エージェントをその時点で削除せず、12c リリース3 (12.1.0.3)、12c リリース4 (12.1.0.4)または12c リリース5 (12.1.0.5)から13c リリース1にアップグレードした場合、13c リリース1 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/oms/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ターゲットを右クリックして、「ターゲットの削除」を選択します。
第4.15項の説明に従って特定のジョブ・タイプのアップグレードを選択してスキップまたは後回しにした場合は、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;