プライマリ・コンテンツに移動
Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド
12cリリース5 (12.1.0.5)
B65086-18
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

4 Enterprise Manager Cloud Control 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 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 Management Service 12cリリース1 (12.1.0.1) [バンドル・パッチ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リリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)へのアップグレード手順は、Enterprise Managerドキュメント・ライブラリにあるそれぞれのリリースの『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

    http://docs.oracle.com/cd/E24628_01/index.htm

  • Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)がサポートされているOracle Management Agentのリリースは、12cリリース5 (12.1.0.5)、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)にアップグレードする前に、Enterprise Manager Cloud Controlコンソールにあるエージェント・アップグレード・コンソールを使用してOracle Management Agentを12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)に必ずアップグレードしてください。手順については、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

  • アップグレードを正常に完了するための追加の準備手順を実行するには、My Oracle Supportのノート1682332.1を参照してください。

  • アップグレード・プロセスを開始する前に、既知の問題のリストを確認するには、My Oracle Supportのノート2022505.1を参照してください。


警告:

旧リリース(10.2.0.5または11.1.0.1)からの2システム・アップグレードが進行中の間は、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)をアップグレードしないでください。アップグレードが進行中の間はステータスが保留中状態のスタンドアロン管理エージェントが存在する可能性があるため、アップグレードが完全に終わるまで待機します。

4.1 単一OMSまたは複数OMSの非HA環境でのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレード

表4-1に、単一OMSまたは複数OMSでHA (高可用性)以外の環境において、Enterprise Managerを12cリリース4 (12.1.0.4)にアップグレードする手順を示します。

アップグレード・プロセスを開始する前に、既知の問題のリストを確認するには、My Oracle Supportのノート2022505.1を参照してください。

表4-1 単一OMSの非HA環境でのEnterprise Manager Cloud Controlの12cリリース5 (12.1.0.5)へのアップグレード

手順番号 手順 プロシージャ

手順1

準備

(a)

1システム・アップグレード方式について学習します。

第2.1項

(b)

開始する前に理解しておく必要のある重要事項を確認します。

第3章

手順2

Oracle Management ServiceおよびOracle Management Repositoryのアップグレード

(a)

次の前提条件を満たします。

  • 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章で説明されているOracle Management Service関係の前提条件を満たします。

  • 12cリリース5 (12.1.0.5)へのアップグレードはアウトオブプレース・アップグレードであるため、ホストが、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載されている12cリリース5 (12.1.0.5)固有のハードウェア要件を満たしていることを確認します。ここで、ホストとは、アップグレードする現在のEnterprise Managerを実行しているホストを表します。

  • 第3.3項で示されている、サポートされているプラットフォームのみでアップグレードを行うようにします。

  • 管理リポジトリが格納されているデータベースを12cリリース1 (12.1.0.2)にアップグレードする場合、データベースをアップグレードする前に、必ずEnterprise Managerシステムをアップグレードしてください。

  • Enterprise Managerで使用されるポートが、1024以下の値に設定されていないことを確認します。この値以下に設定されている場合、アップグレードは失敗します。1024以下のポートは、一般にルート・ユーザー(スーパー・ユーザー)用に予約されています。このため、ポートは1024より大きくしてください。

  • OMS (ミドルウェア・ホームおよびインベントリ)、管理リポジトリおよびソフトウェア・ライブラリをバックアップします。アップグレードが失敗した場合、常にバックアップを使用してリストアできます。バックアップの手順は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

  • 電子メール通知を受信するために使用しているシステム既知のルール・セットのコピーを作成します(「類似作成」操作を使用します)。そうしないと、ルール・セットに対して作成された電子メール・サブスクリプションが失われることになります。

    コピーを作成するには、「設定」メニューから、「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール - すべてのエンタープライズ・ルール・ページの表で、コピーするシステム既存のルール・セットを選択します。次に、「アクション」メニューから、「ルール・セットの類似作成」を選択します。ルール・セットの類似作成ページで、必要な情報を指定して「保存」をクリックします。

  • 次のディレクトリの内容がすべてのOMSホストで同じであることを確認します。OMSホストによってプラグインの数またはリビジョンが異なる場合は、いずれかのpluginextract_with_revディレクトリから別のディレクトリにコピーして確実に一貫性を持たせます。

    <OMS_HOME>/sysman/install/pluginextract_with_rev

    たとえば、最初のOMSホストOMS_Host1に、次のリビジョンのプラグインがあるものとします。

    「oracle.sysman.emfa 12.1.0.1.0および12.1.0.2.0」「oracle.sysman.bda 12.1.0.1.0、12.1.0.2.0および12.1.0.3.0」「oracle.em.sidb 12.1.0.1.0および12.1.0.2.0」

    追加OMSホストOMS_Host2には、「oracle.sysman.emfa 12.1.0.1.0および12.1.0.2.0」「oracle.sysman.bda 12.1.0.3.0」「oracle.em.sehc 12.1.0.1.0」のプラグインがあるものとします。

    この場合、最初のOMSホストから追加OMSに「oracle.sysman.bda 12.1.0.1.0および12.1.0.2.0」「oracle.em.sidb 12.1.0.1.0および12.1.0.2.0」を、追加OMSホストから最初のOMSホストに「oracle.em.sehc 12.1.0.1.0」を確実にコピーします。これによって、両方のOMSホストのプラグインおよびそのリビジョンに一貫性が保たれます。

  • OMSに次のいずれかのカスタマイズを行った場合は、アップグレード・プロセスを開始する前にすべて削除してください。アップグレードが完了した後で、再びカスタマイズすることができます。

    • Weblogicでの追加データソース・パラメータの構成

    • 追加のサードパーティSSL証明書

    • Enterprise Managerログインのためのスマート・カード認証

(b)

アップグレードするEnterprise Manager Cloud Control 12cインストールにOracle BI Publisherがインストール済の場合は、次のいずれかを実行します。

  • Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)からアップグレードする場合は、BI Publisher Serverを実行しているインスタンスを含む、すべてのOMSインスタンスでemctl stop oms -allを実行します。

  • Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以下からアップグレードする場合は、WebLogic管理コンソールを使用してBIPという名前のプライマリBI Publisher管理対象サーバーを停止します。

Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)へのアップグレードの一環として、最新のバンドル・パッチを含むOracle BI Publisher 11.1.1.7.0が自動的にミドルウェア・ホームにインストールされます。ただし、Oracle BI Publisherはデフォルトでインストールされますが、デフォルトでは構成または旧バージョンからのアップグレードは行われません。したがって、12cリリース5 (12.1.0.5)へのアップグレード後に、Oracle BI Publisherを手動で構成する必要があります。また、この構成ステップでは、すべてのレポートが古いBI Publisherのホームから新しいホームに移行されます。手順は、手順4 (f)を参照してください。

(c)

未処理のデータベース・サービスのインスタンス作成リクエストがあるか確認します。進行中のリクエストがある場合は、完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。

これを行うには、次の手順を実行します。

  1. Cloud Controlで、「エンタープライズ」メニューから、「クラウド」、「セルフ・サービス・ポータル」の順に選択します。

  2. インフラストラクチャ・クラウド・セルフ・サービス・ポータル・ページで、ページ・タイトルのすぐ下で、「マイ・データベース」を選択してデータベース・リクエストのみを参照します。

  3. 「リクエスト」表で、進行中のリクエストについては完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。

    スケジュールされたリクエストを一時停止するには、リクエスト名をクリックします。「デプロイ」タブをクリックします。そこにリストされたデプロイメント・プロシージャをクリックして、一時停止します。

(d)

管理リポジトリ内の表でスナップショットが作成されていないことを確認します。

これを確認するには、管理リポジトリに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

(e)

Oracle Management Repositoryを格納しているOracle Databaseにログインまたはログオン・トリガー設定をしていないことを確認してください。

これを確認するには、データベースにログインして次の問合せを実行します。

  • ログイン・トリガーが設定されているかどうかを確認するには、次を実行します。

    SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';

    SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';

  • ログオフ・トリガーが設定されているかどうかを確認するには、次を実行します。

    SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';

    SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';

問合せ結果がゼロ以外の場合、または行が選択されない場合は、トリガーを手動で無効にします。アップグレード完了後に、これらを再度有効化できます。

このようなトリガーを無効化するには、次の問合せを実行します。

SQL> alter trigger <trigger_name> disable;

次に例を示します。

SQL> alter trigger EXPFIL_ALTEREXPTAB_MAINT disable;

(f)

ターゲットの削除操作の監査を有効にします。

  • 操作のリストを表示するには、次のコマンドを実行します。

    emcli show_operations_list

    削除操作には、ターゲットの削除、名前付き資格証明の削除、ロールの削除、ルールの削除、モニタリング・テンプレートの削除、ユーザーの削除などがあります。

  • 現在有効になっている削除操作を確認するには、次のコマンドを実行します。

    emcli show_audit_settings

  • ターゲットの削除操作がまで有効になっていない場合は、次のコマンドを実行して有効にします。

    emcli update_audit_settings

    -operations_to_enable="name_of_the_operations_to_enable._For_all_operations_use_ALL"

    -audit_switch="ENABLE

    -directory="db_directory_name' (エクスポート・サービスが監査データ・ファイルをアーカイブするOSディレクトリで構成する必要があります)

    -file_prefix="file_prefix" (エクスポート・サービスによって使用され、監査データを書き込む必要がありファイル名を作成します。デフォルト値はem_auditです。すべてのサイトで標準に応じて変更できます)

    -file_size="file_size (Bytes)" (各ファイル・サイズの最小値。このデフォルト値は5000000バイトです)

    -data_retention_period="data_retention_period (Days)" (Enterprise Managerリポジトリに監査データが格納される最大期間。デフォルト値は365日です)

    前述のパラメータは、保存期間後に、監査データを管理リポジトリからファイル・システムにアーカイブするために、アーカイブの場所を設定または構成するのに役に立ちます。すべてのサイトでこれを標準化します。

(g)

(クリティカルな必須手順)

データベースに次のパッチを適用します。My Oracle Supportにアクセスすると、これらのパッチを検索できます。手順については、そのパッチに関連付けられたReadMeファイルを参照してください。これらのパッチを適用しない場合、アップグレードが失敗し、この失敗は修正することができません。

Oracle Database 11リリース1 (11.1.0.7)の場合:

  • Unixプラットフォームでは、パッチ17082366 (パッチ・セット更新17)を適用します。その後、パッチ9577583およびパッチ8405205を適用します。

  • Microsoft Windows (32ビットおよび64ビット)プラットフォームでは、パッチ17363760 (パッチ54)を適用します。

Oracle Database 11gリリース2(11.2.0.1)の場合

  • Unixプラットフォームでは、パッチ12419378 (パッチ・セット更新6)を適用します。

  • Microsoft Windows (64ビット)プラットフォームでは、パッチ13423278 (パッチ16)を適用します。

Oracle Database 11gリリース2(11.2.0.2)の場合

  • Unixプラットフォームでは、パッチ11061801および9748749を適用します。

  • Microsoft Windows (32ビット)プラットフォームでは、パッチ11061801およびパッチ12429530を適用します。

  • Microsoft Windows (64ビット)プラットフォームでは、パッチ11061801およびパッチ12429531を適用します。

Oracle Database 11gリリース2(11.2.0.3)、10gリリース2 (10.2.0.5)の場合

UnixおよびMicrosoft Windowsプラットフォームでは、パッチ11061801を適用します。

Oracle Database 11gリリース2 (11.2.0.4)および12cリリース1 (12.1.0.2)の場合

このリリースに必要なパッチはありません。

注意: パッチ13496395の適用もお薦めします。どのデータベース・リリースにパッチを適用できるかの詳細は、パッチとともにパッケージ化されているReadMeを参照してください。

(h)

[複数OMSアップグレードの場合、最初のOMSアップグレードのみでこの手順を実行してください]

既存のOMSから既存の管理リポジトリにemkeyをコピーします。これを実行するには、アップグレードしようとしている古いOMSホームで次のコマンドを実行します。

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

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".

(i)

OMSインスタンス用のデフォルトの即時実行可能なメモリー設定を変更している場合、変更を保持して、アップグレード時に失われないようにします。

変更を保持するには、次の手順を実行します。

  1. すべてのOMSインスタンス上で次のコマンドを実行します。

    $<OMS_HOME>/bin/emctl set property -name 'JAVA_EM_MEM_ARGS' -value '<java_memory_arguments>'

    次に例を示します。

    $<OMS_HOME>/bin/emctl set property -name 'JAVA_EM_MEM_ARGS' -value '-Xms256m -Xmx1740m'

  2. すべてのOMSインスタンスを再起動します。

    $<OMS_HOME>/bin/emctl stop oms -all

    $<OMS_HOME>/bin/emctl start oms

(j)

Enterprise Managerシステムの停止時間を短縮するために、ジョブ・タイプの更新をいくつか選択してスキップします。

Enterprise Managerシステムのアップグレード中に、ジョブ・タイプが登録されます。ジョブ・タイプ登録プロセスの一環として、ジョブ・タイプに対応するアクティブな実行がすべて新しく登録されたバージョンのジョブ・タイプに自動的にアップグレードされます。このジョブ・タイプ・アップグレード・プロセスは、キューされた実行および待機中の実行すべてについてスキップされ、これによりEnterprise Managerシステムの停止時間全体が短縮されます。ただし、場合によってはEnterprise Managerシステムでかなりのバックログが発生し、このようなバックログがアップグレードの開始前に解消されないと、Enterprise Managerシステムの停止時間がずっと長くなることがあります。この問題を回避するには、停止時間の終了を待ってアップグレードされるように、特定のジョブ・タイプのアップグレードを選択してスキップまたは後回しにすることができます。

ジョブ・タイプがアップグレードされないようにスキップまたは後回しにするには、次の手順を実行します。

  1. 停止時間中のアップグレードから除外するジョブ・タイプを特定します。

    そのためには、SYSMANユーザーとしてOracle Management Repositoryを格納しているデータベースにログインし、次の問合せを実行します。特に、アクティブな実行を多数保有するジョブ・タイプを探します。

    SELECT job_type, COUNT(1) as n_execs

    FROM MGMT_JOB_EXEC_SUMMARY

    JOIN MGMT_JOB_TYPE_INFO USING (job_type_id)

    WHERE status NOT IN (3,4,5,8,18,19,23)

    GROUP BY job_type

    HAVING COUNT(1) > 5000

    ORDER BY COUNT(1) DESC;

  2. ジョブ・タイプPropagateTargetおよびExecLoaderCallbacksを除外します。

    INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('mgmt_job_skip_job_type_upg.1', 'PropagateTarget');

    INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('mgmt_job_skip_job_type_upg.2', 'ExecLoaderCallbacks');

    COMMIT;

  3. 最初の手順で特定した他のジョブ・タイプを除外します。

    そのためには、次の問合せを実行してMGMT_PARAMETERS表からジョブ・タイプを除外します。除外するジョブ・タイプごとに、INSERT文を1つ実行する必要があります。たとえば、除外するジョブ・タイプが3つある場合、INSERT文を3回実行しますが、それぞれに除外するジョブ・タイプを指定します。

    INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('mgmt_job_skip_job_type_upg.1', '<job type>');

(k)

これからアップグレードするOMSを停止して、これに接続されているその他のOMSインスタンスも停止します。

重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、この手順をスキップします。第5.3.1項または第5.4.1項に記載されているように、ソフトウェア・バイナリをコピーした後でOMSインスタンスを停止できます。

  1. 前提条件として、JVMDおよびADPエンジンを明示的に停止します。

    • サイレント・モードでこれらを停止するには、次のコマンドを実行します。

      $<OMS_HOME>/bin/emctl extended oms jvmd stop -all

      $<OMS_HOME>/bin/emctl extended oms adp stop –all

    • グラフィック・モードでこれらを停止するには、WebLogicコンソールにアクセスし、JVMDおよびADP WebLogic管理対象サーバーを手動で停止します。

  2. 次に、これからアップグレードするOMSを停止し、これに接続されているその他のOMSインスタンスも停止します。

    $<OMS_HOME>/bin/emctl stop oms -all

(l)

管理エージェントがメトリック収集のために管理リポジトリに接続しないように、「管理サービスとリポジトリ」ターゲットを監視する管理エージェントを停止します。この管理エージェントを停止しないと、OMSアップグレードが失敗する可能性があります。

重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、この手順をスキップします。第5.3.1項または第5.4.1項に記載されているように、ソフトウェア・バイナリをコピーした後で管理エージェントを停止できます。

(m)

OMSと管理リポジトリをアップグレードします。グラフィック・モードとサイレント・モードのどちらでアップグレードするかを選択できます。ある時点でソフトウェア・バイナリをインストールし、後でグラフィック・モードまたはサイレント・モードでアップグレードすることも選択できます。

emkeyをコピーしていないことを示すエラー・メッセージが表示される場合は、次の手順を実行します。

  1. 古いOMSから古い管理リポジトリにemkeyをコピーします。これを実行するには、アップグレードしようとしている古い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

    次に例を示します。

    /u01/software/oracle/middleware/oms/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.mydomain.com)(PORT=1521)))(CONNECT_DATA=(SID=emrepos12)))"' -repos_user sysman -emkey_file /u01/software/oracle/middleware/oms/sysman/config/emkey.ora

    注意: ここで、管理リポジトリの詳細は、アップグレードしようとしている既存の管理リポジトリの詳細です。<OMS_HOME>は、アップグレードしようとしているOMSホームです。

  2. OMSおよび管理リポジトリのアップグレードを再試行します。

重要: 古いOMSをアップグレードした後すぐに、古いOMSとともにインストールされた管理エージェント(つまり中央エージェント)をアップグレードしてください。この管理エージェントをアップグレードするには、エージェント・アップグレード・コンソールを使用します。

第5.1項、第5.2項、第5.3項または第5.4項

手順3

Oracle Management Agentのアップグレード

(a)

管理エージェントのアップグレードを開始する前に理解しておく必要のある重要事項を確認します。

第6.2項

(b)

前提条件を満たします。

第6.3項

(c)

手順2 (l)で停止した管理エージェントを確実に再起動します。

(d)

管理エージェントをアップグレードします。

重要: 古いOMSをアップグレードした後すぐに、古いOMSとともにインストールされた管理エージェント(つまり中央エージェント)をアップグレードしてください。この管理エージェントをアップグレードするには、エージェント・アップグレード・コンソールを使用します。

第6.4項

手順4

アップグレード後のタスクの実行

(a)

アップグレード後のタスクを実行します。

第13.6.1項

(b)

カスタム証明書を使用してOracle WebLogic Serverを再構成します。

第13.6.14項

(c)

遅延データ移行ジョブのステータスを追跡します。

第13.7.2項

(d)

不要な中央エージェントを削除します。

第13.13.2項

(e)

アプリケーションの依存性とパフォーマンス(ADP)・エンジンと、JVM診断(JVMD)エンジンをアップグレードします。

第7章

(f)

Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)へのアップグレードの一環として、最新のパッチ・セットを含むOracle BI Publisher 11.1.1.7.0が自動的にインストールされます。したがって、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)を含むミドルウェア・ホームには、いずれのバージョンのOracle BI Publisherのソフトウェアのみをインストールしないでください。ただし、Oracle BI Publisherはデフォルトでインストールされますが、デフォルトでは構成または旧バージョンからのアップグレードは行われません。

  • 旧リリースにOracle BI Publisherがない場合は、新しくインストールされたものを構成します。

  • すでに旧リリースにOracle BI Publisherがある場合は、configureBIP -upgradeコマンドを使用して旧リリースをアップグレードします。アップグレードの一環として、旧Oracle BI Publisherのレポートはすべてアップグレード後のOracle BI Publisherに移行されます。

新しくインストールされたOracle BI Publisherを構成するには、『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』を参照してください。

Oracle BI Publisherをアップグレードしてレポートを移行するには、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

(g)

古いOMSホームを削除します。

第13.15項

4.2 HA環境(プライマリ・サイトおよびスタンバイ・サイト)でのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレード

この項では、HA (高可用性)環境で、プライマリおよびスタンバイEnterprise Managerサイトを12cリリース5 (12.1.0.5)にアップグレードする方法を示します。この項の具体的な内容は次のとおりです。

4.2.1 記憶域レプリケーションを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

表4-2では、記憶域レプリケーションを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレードする手順を説明しています。


注意:

この手順の一部としてスタンバイOMSを削除する必要はありません。

表4-2 記憶域レプリケーションを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

手順番号 手順 プロシージャ

手順1

プライマリOMSのアップグレード

プライマリEnterprise Managerサイト、OMSおよび管理エージェントの両方をアップグレードします。

アップグレード・プロセス時にプライマリOMSが停止するため、停止時間が発生します。

第4.1項

手順2

スタンバイ・ストレージ・サーバー上の新しいミドルウェア・ホームの検証

新しいミドルウェア・ホームもスタンバイ・ストレージ・サーバーにレプリケートされていることを確認するために、システム管理者に連絡をします。

4.2.2 スタンバイWebLogicドメインを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

表4-3では、スタンバイWebLogicドメインを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレードする手順を説明しています。

表4-3 スタンバイWebLogicドメインを使用してスタンバイOMSが作成される際に、プライマリおよびスタンバイOMSインスタンスをアップグレード

手順番号 手順 プロシージャ

手順1

スタンバイOMSの削除

(a)

すべての追加スタンバイOMSインスタンスを削除します。

追加のすべてのスタンバイOMSインスタンスを削除するには、Oracle Enterprise Managerアドバンスト・インストレーションおよび構成に関するガイドの追加のスタンバイOMSインスタンスの削除に関する項を参照してください。

(b)

最初のスタンバイOMSを削除します。

最初のスタンバイOMSを削除するには、Oracle Enterprise Managerアドバンスト・インストレーションおよび構成に関するガイドの最初のスタンバイOMSの削除に関する項を参照してください。

手順2

プライマリOMSのアップグレード

プライマリEnterprise Managerサイト、OMSおよび管理エージェントの両方をアップグレードします。

第4.1項

手順3

スタンバイOMSの再デプロイ

スタンバイWebLogicドメインを使用してスタンバイOMS環境を再作成します。

スタンバイWebLogicドメインを使用してスタンバイOMS環境を再作成するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』の障害時リカバリに関する章を参照してください。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引