プライマリ・コンテンツに移動
Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド
13c リリース1
E70368-02
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

4 Enterprise Manager Cloud Control 13c リリース1へのアップグレードの前提条件

Enterprise Manager Cloud Control 12c リリース5 (12.1.0.5)、12c リリース4 (12.1.0.4)または12c リリース3 (12.1.0.3)を13c リリース1にアップグレードする前に、次の前提条件を満たします。

4.1 ハードウェア、ソフトウェアおよびプラットフォームの要件

必ず『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章に記載されたハードウェア要件を含め、すべての前提条件を満たします。

また、必ず第2.3項に記載されたサポートされているプラットフォームでのみアップグレードを実行します。

4.2 サポートされているデータベース・リリースの要件

既存のデータベースが13c リリース1に対して動作保証されているデータベースであることを確認します。動作保証されたデータベースのリストは、My Oracle Supportで入手できるEnterprise Manager動作保証マトリックスで確認できます。Enterprise Managerの動作保証マトリックスにアクセスするには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載されている手順に従います。

既存のデータベースが13c リリース1でサポートされているリリースではない場合は、サポートされているリリースにアップグレードしてから、OMSと管理リポジトリのアップグレードを開始してください。たとえば、12c リリース3 (12.1.0.3)からアップグレードする場合、データベースのリリースが古く、13c リリース1でサポートされていない可能性があります。この場合は、まずデータベースを13c リリース1でサポートされている最低限のデータベース・リリースにアップグレードしてから、Enterprise Managerシステムを13c リリース1にアップグレードします。

データベースをアップグレードする前に、必ずデータベースに接続されている旧リリースのOMSインスタンスを停止してください。データベースのアップグレード時に、リスナー・ポートを変更した場合は、次の手順に従います。

  1. 変更後のリスナー・ポートを使用してデータベース・アップグレードを完了します。

  2. 次のコマンドを実行して、データベースに接続されている旧リリースの最初のOMSの管理サーバーを起動します。

    emctl start oms -admin_only

  3. すべてのOMSインスタンスに対して次のコマンドを実行して、最初のOMSに加えて他のOMSインスタンスも変更後のリスナー・ポートで更新します。

    emctl config oms –store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman

    前述のコマンドを各OMSで実行すると、OMSを停止してから再起動して変更を反映するよう求められます。各OMSで、指示されたとおりに実行してください。いずれにせよ、13cへのアップグレードを開始する前に、すべて停止する必要があります。

  4. 13cへのEnterprise Managerシステム全体のアップグレードを続行します。

4.3 データベース・パッチの要件

必ずサポートされているデータベースに最新のPSUを適用します。

4.4 オプティマイザ適応機能の無効化の要件

必ず管理リポジトリを格納しているOracle Databaseでオプティマイザ適応機能(optimizer_adaptive_features=FALSE)を無効にします。次の手順を実行します。

  1. オプティマイザ適応機能を無効にするには、optimizer_adaptive_featuresパラメータをFALSEに設定します。そのためには、次のSQLコマンドを実行します。

    alter system set optimizer_adaptive_features=false scope=both

  2. データベースを再起動します。

  3. 変更が反映されていることを確認します。そのためには、次のSQLコマンドを実行します。

    show parameter adaptive;

    次の出力が表示されるはずです。

    NAME                          TYPE         VALUE
    ---------------------------------------------------------------------
    optimizer_adaptive_features   boolean      FALSE 
    

4.5 管理エージェントのパッチの要件

必ずIBM AIXオペレーティング・システムで実行されている管理エージェントに次のパッチを適用します。

  • パッチ19154291: Oracle Management Agent 12c リリース3 (12.1.0.3)の場合

  • パッチ20282974: Oracle Management Agent 12c リリース4 (12.1.0.4)の場合

4.6 ポートの要件

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

4.7 ルール・セットのバックアップの要件

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

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

4.8 カスタマイズの削除の要件

必ずOMSに対して実行した次のタイプのカスタマイズを削除します。アップグレードが完了した後で、再びカスタマイズすることができます。

  • Weblogic Serverで構成された追加のデータ・ソース・パラメータ。

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

4.9 Oracle BI Publisherによる12c リリース3 (12.1.0.3)の暫定的なアップグレードの要件

Oracle BI Publisherを12c リリース3 (12.1.0.3)で構成している場合、13c リリース1に直接アップグレードすることはできません。まず12c リリース4 (12.1.0.4)または12c リリース4 (12.1.0.5)にアップグレードしてから、13c リリース1にアップグレードする必要があります。Oracle BI Publisherを12cリリース3 (12.1.0.3)で構成していない場合は、13cリリース1に直接アップグレードできます。

4.10 Oracle BI Publisherの停止の要件

必ず以前のリリースにデプロイされているOracle BI Publisherを停止します。そのためには、次の方式のいずれかを使用します。

  • Enterprise Manager Cloud Control 12c リリース5 (12.1.0.5)または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管理対象サーバーを停止します。

4.11 データベース・サービス・インスタンス作成リクエストの確認の要件

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

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

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

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

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

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

4.12 リポジトリ表スナップショットの確認の要件

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

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

4.13 ログインおよびログオフ・トリガー設定の確認の要件

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;

4.14 ターゲットの削除操作の監査の要件

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

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

    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日です)

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

4.15 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. 特定した他のジョブ・タイプを除外します。

    そのためには、次の問合せを実行して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>');

4.16 EMKEYのコピーの要件

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

必ず既存のOMSから既存の管理リポジトリにemkeyをコピーします。これを実行するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

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

次に例を示します。

/u01/software/em12c/mw/oms/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

emkeyがコピーされているかどうかを確認するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

$<ORACLE_HOME>/bin/emctl status emkey

次に例を示します。

/u01/software/em12c/mw/oms/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".

4.17 証明書鍵の強度の要件

証明書鍵の強度が1024ビット以上であることを確認します。

11g リリース1以下の場合、証明書は鍵の強度512ビットで生成され、12c リリース4 (12.1.0.4)または12c リリース(12.1.0.5)へのアップグレード、それに続く13c リリース1へのアップグレードで引き継がれます。したがって、11g リリース1以下からアップグレードする場合、証明書は512ビットのままであり、最終的に様々な通信問題につながります。そのため、証明書鍵の強度は1024ビット以上であることを確認してください。

証明書鍵の強度を1024ビット以上に設定する手順は、My Oracle Supportのノート1611578.1を参照してください。

4.18 即時利用可能なメモリー設定のバックアップの要件

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

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

  1. これからアップグレードするOMSインスタンスのすべてで、次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

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

    次に例を示します。

    /u01/software/em12c/mw/oms2/bin/emctl set property -name 'JAVA_EM_MEM_ARGS' -value '-Xms256m -Xmx1740m'

  2. 次のコマンドを実行して、すべてのOMSインスタンスを再起動します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

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

    $<ORACLE_HOME>/bin/emctl start oms

    次に例を示します。

    /u01/software/em12c/mw/oms/bin/emctl stop oms -all

    /u01/software/em12c/mw/oms/bin/emctl start oms

4.19 前提条件チェックおよび環境の検証の要件

アップグレードを開始する前に、必ずEM前提条件キットを実行し、リポジトリ関連の前提条件をすべて満たします。

EM前提条件Kitを実行するには、次のコマンドを実行して表4-1に記載されているパラメータが含まれるレスポンス・ファイルを渡します。

./em13100_linux64.bin EMPREREQ_KIT=true EMPREREQKIT_PROPERTY_FILE=<absolute_path_to_reponse_file>

表4-1 EM前提条件Kitレスポンス・ファイルのパラメータ

パラメータ 説明

installerMode

emprereqkitを指定します。

connectString

次の書式でデータベースの詳細を指定します。

connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))

dbPassword

データベース・ユーザー・パスワードを指定します。

dbRole

sysdbaを指定します。

dbUser

SYSを指定します。

executionType

installを指定します。

logLoc

EM前提条件キットの実行ログを保存できるディレクトリへの絶対パスを指定します。デフォルトの場所は<prereqResultloc>/prerequisiteResults/log.です。

prereqResultLoc

前提条件チェックの結果(XMLファイル形式)を保存するディレクトリの絶対パスを指定します。

reposUser

SYSMANを指定します。

runPrerequisites

trueを指定します。


サンプル・レスポンス・ファイルの内容は次のとおりです。

installerMode=emprereqkit
connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=explsrvc)))
dbPassword=<password>
dbRole=sysdba
dbUser=SYS
executionType=install
logLoc=/u01/software/em13c/prerequisiteResults/log
prereqResultLoc=/u01/software/em13c/prerequisiteResults
reposUser=SYSMAN
runPrerequisites=true

4.20 OMSのバックアップの要件

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

4.21 OMSの停止の要件

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

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

  1. JVMDおよびADPエンジンを明示的に停止します。

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

    サイレント・モードで停止するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

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

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

    次に例を示します。

    /u01/software/em12c/mw/oms/bin/emctl extended oms jvmd stop -all

    /u01/software/em12c/mw/oms/bin/emctl extended oms adp stop –all

  2. これからアップグレードするOMSを停止して、これに接続されているその他のOMSインスタンスも停止します。これを行うには、次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

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

    次に例を示します。

    /u01/software/em12c/mw/oms/bin/emctl stop oms -all

4.22 管理エージェントの停止の要件

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

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

4.23 管理エージェント・プロキシの削除の要件

必ずスタンドアロン管理エージェント用に構成されているプロキシを削除します。そうしないと、スタンドアロン管理エージェントのアップグレードが失敗します。この要件はむしろ管理エージェントのアップグレードに対することで、OMSのアップグレードには影響しませんが、OMSのアップグレードを開始する前に、管理エージェント側のプロキシを削除することをお薦めします。