Oracle® Enterprise Manager

Cloud Controlアップグレード・ガイド

12cリリース5 (12.1.0.5)

B65086-18(原本部品番号:E22625-45)

2016年2月

Oracle Enterprise Manager Cloud Controlアップグレード・ガイド, 12cリリース5 (12.1.0.5)

B65086-18

Copyright © 2014, 2016, Oracle and/or its affiliates All rights reserved.

原本著者: Aravind Jayaraaman

原本協力著者: Pradeep Gopal、Namrata Bhakthavatsalam、Genevieve D'Souza

原本協力者: Enterprise Manager Cloud Control開発チーム、品質保証チーム、カスタマ・サポート・チームおよび製品管理チーム。

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracleおよびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このマニュアル改訂における最新情報

- 最新のリビジョンで反映された変更(公開済)

- 以前のリビジョンで反映された変更(アーカイブ済)

第I部 Enterprise Managerシステムのアップグレードの概要

1 この製品リリースにおける最新情報

2 Enterprise Managerシステムのアップグレードに提供されるアップグレード方式の概要

- 2.1 Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレード

- 2.1.1 Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の概要

- 2.1.2 Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード・ユーティリティの概要

- 2.1.2.1 Enterprise Manager Cloud Controlインストール・ウィザードの概要

- 2.1.2.2 エージェント・アップグレード・コンソールの概要

- 2.1.3 Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード方式の概要

- 2.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

- 2.2.1 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の概要

- 2.2.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の違い

- 2.2.3 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード・ユーティリティの概要

- 2.2.3.1 アップグレード前コンソールの概要

- 2.2.3.2 Enterprise Manager Cloud Controlインストール・ウィザードの概要

- 2.2.3.3 アップグレード後コンソールの概要

- 2.2.4 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード、2システム・アップグレードおよび異なるホストでの1システム・アップグレードのプロセスの概要

- 2.2.4.1 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード・プロセスの概要

- 2.2.4.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される2システム・アップグレード・プロセスの概要

- 2.2.4.3 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される、異なるホストでの1システム・アップグレード・プロセスの概要

3 Enterprise Managerシステムのアップグレードに関する予備知識

- 3.1 Enterprise ManagerシステムをアップグレードするためにサポートされているOMS環境

- 3.2 Enterprise Managerシステムのアップグレードでサポートされているアップグレード・パスおよびサポートされているアップグレード方式

- 3.3 Enterprise Managerシステムのアップグレードでサポートされているプラットフォーム

- 3.4 Enterprise Managerシステムのアップグレードに提供されるアップグレードの範囲

- 3.5 ADMP経由で移行されないリポジトリ・バックアップ後に変更またはカスタマイズされたデータ

- 3.6 アップグレード済Enterprise Managerシステムで使用されたポート

- 3.7 Enterprise Managerシステムアップグレード時のプラグインのアップグレード

- 3.7.1 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)へのアップグレードに並行したプラグインのアップグレード

- 3.7.1.1 Oracle Management Agent 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)、12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのアップグレード

- 3.7.1.2 Oracle Management Service 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)、12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのアップグレード

- 3.7.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのアップグレード

- 3.7.2.1 Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのインストール

- 3.7.2.2 Oracle Management Service 10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのインストール

- 3.8 Enterprise Managerシステムをアップグレードした後のOracle Software Libraryの状態

- 3.9 アップグレード済Enterprise Managerシステムでのコネクタ

- 3.10 Enterprise Managerシステムをアップグレードした後のPDP構成ファイルの更新

- 3.11 アップグレード済Enterprise Managerシステムでの通知、アラート、ジョブ、デプロイメント・プロシージャ実行、メトリック、EM CLIクライアントおよびOracle Exadataターゲット

- 3.11.1 アップグレード済Enterprise Managerシステムでの通知

- 3.11.2 アップグレード済Enterprise Managerシステムでのアラート

- 3.11.2.1 アップグレード済Enterprise Managerシステムに移行されるアラート

- 3.11.2.2 アップグレード済Enterprise Managerシステムで様々なタイプのオープン・アラートに対して作成されるインシデントとイベント

- 3.11.2.3 アップグレード済Enterprise Managerシステムで様々なタイプのクローズド・アラートに対して作成されるインシデントとイベント

- 3.11.3 アップグレード済Enterprise Managerシステムでのジョブ

- 3.11.4 アップグレード済Enterprise Managerシステムでのデプロイメント・プロシージャ

- 3.11.5 アップグレード済Enterprise Managerシステムで名前が変更されるメトリック

- 3.11.6 Enterprise Managerシステムをアップグレードした後のEM CLIクライアントのアップグレード

- 3.11.7 Enterprise Managerシステムをアップグレードした後のOracle Exadataターゲットのアップグレード

- 3.12 OMSおよび管理エージェント用に構成されたカスタム証明書のアップグレード済Enterprise Managerシステムでの再利用

- 3.13 Enterprise Managerシステムをアップグレードした後のデータベースのXML DB機能

- 3.14 Enterprise Managerシステムをアップグレードした後のOMSと管理エージェントの手動再起動

- 3.15 アップグレード済Enterprise Managerシステムのスタンバイ・データベースにOracle Data Guardが構成される場合の強制ロギングの有効化

第II部 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 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 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.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)へのアップグレード

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

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

5 Oracle Management ServiceおよびOracle Management Repository 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレード

- 5.1 OMSおよび管理リポジトリの12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレード(グラフィック・モード)

- 5.1.1 Enterprise Managerシステムのグラフィック・モード・インストール用の拡張インストーラ・オプション

- 5.1.2 Enterprise Managerシステムのグラフィック・モード・インストール用の拡張インストーラ・オプションの制限事項

- 5.1.3 12.1.0.4、12.1.0.3、12.1.0.2から12.1.0.5へのアップグレードの前の不要なスタンドアロン管理エージェントの削除

- 5.1.4 NFSマウントされたドライブからローカルのファイル・システムの場所へのロック・ファイルの移動

- 5.2 OMSおよび管理リポジトリの12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレード(サイレント・モード)

- 5.2.1 Enterprise Managerシステムのサイレント・モード・インストール用の拡張インストーラ・オプション

- 5.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストール(グラフィック・モードでソフトウェアのみの方法を使用)

- 5.3.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをすぐにインストール(グラフィック・モード)

- 5.3.2 allroot.shスクリプトの実行

- 5.3.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成(グラフィック・モード)

- 5.3.3.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)へのソフトウェアのみのアップグレードの拡張スクリプト・オプション

- 5.4 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストール(サイレント・モードでソフトウェアのみの方法を使用)

- 5.4.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(サイレント・モード)

- 5.4.1.1 サイレント・モードでEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストールするためのsoftware_only.rspレスポンス・ファイルの編集

- 5.4.2 allroot.shスクリプトの実行

- 5.4.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成(サイレント・モード)

6 Oracle Management Agentのアップグレード

- 6.1 12c管理エージェントのアップグレードの概要

- 6.2 12c管理エージェントのアップグレードを開始する前に

- 6.3 12c管理エージェントをアップグレードするための前提条件

- 6.4 12c管理エージェントのアップグレード

- 6.4.1 12c管理エージェントのアップグレード

- 6.4.1.1 エージェント・アップグレード・コンソールを使用した12c管理エージェントのアップグレード

- 6.4.1.2 EM CLIを使用した12c管理エージェントのアップグレード

- 6.4.2 12c管理エージェントのアップグレード用の追加パラメータ

- 6.4.3 アップグレードできない12c管理エージェントの表示

- 6.4.4 古い管理エージェントのアップグレード後クリーンアップの実行

- 6.4.4.1 エージェント・アップグレード・コンソールを使用した古い管理エージェントのアップグレード後クリーンアップの実行

- 6.4.4.2 EM CLIを使用した古い管理エージェントのアップグレード後クリーンアップの実行

- 6.4.5 12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

- 6.4.5.1 エージェント・アップグレード・コンソールを使用した12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

- 6.4.5.2 EM CLIを使用した12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

- 6.5 12c管理エージェントのアップグレード後

- 6.5.1 12c管理エージェントのアップグレードの確認

- 6.5.1.1 Enterprise Managerコンソールを使用した12c管理エージェントのアップグレードの確認

- 6.5.1.2 EM CLIを使用した12c管理エージェントのアップグレードの確認

- 6.5.2 中央エージェントのベース・ディレクトリのOracleミドルウェア・ホーム外への移動(12c中央エージェントのアップグレード後)

- 6.6 12c管理エージェントのアップグレードのトラブルシューティング

7 JVMDのアップグレードまたは再デプロイ

- 7.1 JVMDのアップグレード推奨事項について

- 7.2 JVMDのアップグレード・ワークフローについて

- 7.3 JVMDエンジンのアップグレードまたは再デプロイ

- 7.3.1 JVMDエンジンのアップグレード

- 7.3.1.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエンジンのアップグレード

- 7.3.1.2 ApmEngineSetup.plを使用したJVMDエンジンの手動でのアップグレード

- 7.3.2 JVMDエンジンの再デプロイ

- 7.4 JVMDエージェントのアップグレードまたは再デプロイ

- 7.4.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエージェントのアップグレードまたは再デプロイ

- 7.4.2 deploy_jvmdagent.plを使用したJVMDエージェントの手動でのアップグレードまたは再デプロイ

- 7.4.3 WebLogic管理コンソールを使用したJVMDエージェントの手動でのアップグレードまたは再デプロイ

- 7.5 JVMDのアップグレードまたは再デプロイの検証

8 ADPのアップグレードまたは再デプロイ

- 8.1 ADPのアップグレード推奨事項について

- 8.2 ADPのアップグレード・ワークフローについて

- 8.3 ADPエンジンのアップグレードまたは再デプロイ

- 8.3.1 ADPエンジンのアップグレード

- 8.3.1.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエンジンのアップグレード

- 8.3.1.2 ApmEngineSetup.plを使用したADPエンジンの手動でのアップグレード

- 8.3.2 ADPエンジンの再デプロイ

- 8.4 ADPエージェントのアップグレードまたは再デプロイ

- 8.4.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエージェントのアップグレードまたは再デプロイ

- 8.4.2 deploy_adpagent.plを使用したADPエージェントの手動でのアップグレードまたは再デプロイ

- 8.5 ADPのアップグレードまたは再デプロイ後の作業

第III部 Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

9 Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードの開始

- 9.1 1システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

- 9.2 2システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

- 9.3 異なるホストでの1システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース4 (12.1.0.5)へのアップグレード

10 Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードのアップグレード前要件への対応

- 10.1 アップグレード前コンソール・パッチの適用

- 10.2 新しいEnterprise Managerシステムのホストとポートの識別

- 10.3 DDMPジョブの自動実行の無効化

- 10.4 管理エージェント・ソフトウェアおよび関連プラグインの場所の管理と検証

- 10.5 Enterprise Managerシステムをアップグレードする前の既存データベースのクローニング(バックアップ)

- 10.6 Enterprise Managerシステムをアップグレードする前の環境の分析

- 10.6.1 インベントリが有効のOracle Management Agentの識別

- 10.6.2 インベントリが無効のOracle Management Agentの識別

- 10.6.3 Oracle Management Agentのアップグレード性のステータスの確認

- 10.6.4 ターゲットのアップグレード性のステータスの確認

- 10.6.5 問題のあるOracle Management Agentの識別

- 10.6.6 再構成が必要なOracle Management Agentの識別

- 10.6.7 Enterprise Manager 12cでサポートされないOracle Management Agentの特定

- 10.6.8 リポジトリ・バックアップ後にインストールされるOracle Management Agentの特定

- 10.6.9 破損したターゲットの特定

- 10.7 Enterprise Managerシステムをアップグレードするためのリポジトリ・バックアップの詳細指定

11 Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

- 11.1 Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイおよび構成

- 11.1.1 Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイと構成を開始する前に

- 11.1.2 Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイおよび構成

- 11.2 デプロイしたOracle Management Agent 12cリリース5 (12.1.0.5)の状態レポートの生成

- 11.3 デプロイしたOracle Management Agent 12cリリース5 (12.1.0.5)の状態レポートの検証とサインオフ

- 11.4 Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバー

- 11.4.1 Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバー

- 11.4.2 Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバーに関連する問題のトラブルシューティング

12 Oracle Management ServiceおよびOracle Management Repository 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

- 12.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(グラフィック・モード)

- 12.1.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式、グラフィック・モード)

- 12.1.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式、グラフィック・モード)

- 12.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(サイレント・モード)

- 12.2.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式、サイレント・モード)

- 12.2.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式、サイレント・モード)

- 12.3 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(ソフトウェアのみアップグレード方法の使用、グラフィック・モード)

- 12.3.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、グラフィック・モード)

- 12.3.1.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(1システム・アップグレード方式、グラフィック・モード)

- 12.3.1.2 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(1システム・アップグレード方式、グラフィック・モード)した後のallroot.shスクリプトの実行

- 12.3.1.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(1システム・アップグレード方式、グラフィック・モード)

- 12.3.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、グラフィック・モード)

- 12.3.2.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(2システム・アップグレード方式、グラフィック・モード)

- 12.3.2.2 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(2システム・アップグレード方式、グラフィック・モード)した後のallroot.shスクリプトの実行

- 12.3.2.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(2システム・アップグレード方式、グラフィック・モード)

- 12.4 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(ソフトウェアのみアップグレード方法の使用、サイレント・モード)

- 12.4.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、サイレント・モード)

- 12.4.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、サイレント・モード)

- 12.4.2.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(2システム・アップグレード方式、サイレント・モード)

- 12.4.2.2 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(2システム・アップグレード方式、サイレント・モード)した後のallroot.shスクリプトの実行

- 12.4.2.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(2システム・アップグレード方式、サイレント・モード)

- 12.5 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(異なるホストでの1システム・アップグレード方式)

- 12.6 複数OMS環境の10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

13 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードした後のアップグレード後タスクの実行

- 13.1 Enterprise Managerがインストールされているホストの確認

- 13.2 アップグレードした管理リポジトリへのリンクの作成

- 13.3 管理リポジトリがアップグレードされたデータベースの検出

- 13.4 ソフトウェア・ライブラリの再構成

- 13.5 エージェントのアップグレード・ステータスの確認

- 13.6 一般的なアップグレード後タスクの実行

- 13.6.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードした後の一般的なアップグレード後の手順の実行

- 13.6.2 Oracle WebLogic Serverへのパッチ適用

- 13.6.3 Oracle Exalogic Systemターゲットのアップグレード

- 13.6.4 追加OMSがアップグレードされる際の中央エージェントの再起動

- 13.6.5 OCMスケジューラの停止

- 13.6.6 不要なターゲットの削除

- 13.6.6.1 1システム・アップグレード後の不要なターゲットの削除

- 13.6.6.2 2システム・アップグレード後の不要なターゲットの削除

- 13.6.7 削除済ターゲットの古いコンプライアンス標準のクリーンアップ

- 13.6.8 インシデント・ルールの更新

- 13.6.8.1 インシデント・ルールの更新について

- 13.6.8.2 移動したメトリックのインシデント・ルールの更新

- 13.6.8.3 名前が変更されたメトリックのインシデント・ルールの更新

- 13.6.8.4 インシデント・ルールの削除

- 13.6.9 インシデント・ルール・セットの無効化

- 13.6.10 SOAターゲットのメトリック収集エラーの解決

- 13.6.11 Enterprise Managerアップグレード後のLinuxパッチ適用の有効化

- 13.6.11.1 ジョブを停止して資格証明をリセットした後でのすべてのアクティブなLinuxパッチ適用ジョブの再発行

- 13.6.11.2 ジョブを停止せずに資格証明をリセットした後でのすべてのアクティブなLinuxパッチ適用ジョブの再発行

- 13.6.12 コンソールURLの更新

- 13.6.13 カスタム構成の再実行

- 13.6.14 カスタム証明書を使用したOracle WebLogic Serverの再構成

- 13.6.15 追加OMSのアップグレード後の管理エージェントの再起動

- 13.6.16 前のリリースで無効になっていたコンプライアンス標準の有効化

- 13.6.17 Javaヒープ・メモリー引数の再設定

- 13.6.18 Enterprise Managerシステムのアップグレード前にスキップしたジョブ・タイプのアップグレードの有効化

- 13.7 遅延データ移行ジョブのステータスの追跡

- 13.7.1 遅延データ移行ジョブについて

- 13.7.2 遅延データ移行ジョブのステータスの追跡

- 13.8 発生データ移行ジョブのステータスの追跡

- 13.8.1 発生データ移行ジョブについて

- 13.8.2 発生データ移行ジョブのステータスの追跡

- 13.9 差分レポートの生成と表示

- 13.9.1 差分レポートについて

- 13.9.2 差分レポートの生成と表示

- 13.10 アップグレードしたEnterprise Managerシステム内の非アクティブ・ターゲットの表示

- 13.11 発生データ移行プロセスのサインオフ

- 13.12 移行プロセスと既存のアップグレード・モードのサインオフ

- 13.13 古い中央エージェントおよび関連付けられているターゲットの削除

- 13.13.1 10.2.0.5/11.1.0.1から12.1.0.5へのアップグレードの後の不要な中央エージェントの削除

- 13.13.2 12.1.0.2/12.1.0.3/12.1.0.4から12.1.0.5へのアップグレード後の不要な中央エージェントの削除

- 13.14 (オプション)削除された中央エージェントで監視されていたターゲットの監視

- 13.15 (オプション)古いOMSホームの削除

- 13.16 CDBおよびPDBで構成されたデータベースへのSYSMANスキーマの移行

- 13.17 外部ロールの作成オプションの有効化

第IV部 付録

A サイレント・モードでOracle Management ServiceおよびOracle Management Repositoryをアップグレードするためのレスポンス・ファイルの編集

B Enterprise Manager Cloud Controlの通知システムの概要

- B.1 イベント、インシデントおよびインシデント・ルールセットについて

- B.2 Enterprise Manager 12cでのインシデント・ルールセットへのアクセス

- B.3 Enterprise Manager 12cへのアップグレード後にインシデント・ルールセットに移行される通知ルール

- B.4 Enterprise Manager 12cへのアップグレード後の通知メソッドおよびアクション

C Enterprise Manager Cloud Controlのメトリック変更の概要

- C.1 Enterprise Manager Cloud ControlでのOracle SOA Infrastructureのメトリックに対する変更

- C.2 Enterprise Manager Cloud ControlでのOracle SOAコンポジットのメトリックに対する変更

- C.3 Enterprise Manager Cloud ControlでのOracle Service Busのメトリックに対する変更

- C.4 Enterprise Manager Cloud ControlでのOracle WebLogic Serverのメトリックに対する変更

- C.5 Enterprise Manager Cloud ControlでのJBoss Application Serverのメトリックに対する変更

- C.6 Enterprise Manager Cloud ControlでのSiebel Enterpriseのメトリックに対する変更

- C.7 Enterprise Manager Cloud ControlでのSiebelサーバーのメトリックに対する変更

- C.7.1 Siebelサーバーの優先資格証明の設定

- C.7.2 Siebelゲートウェイ・サーバーの優先資格証明の設定

- C.7.3 Siebelデータベース・リポジトリの優先資格証明の設定

D 2システム・アップグレード方式に対してEnterprise Managerで実行されないジョブの特定

- D.1 新しい、アップグレード後のEnterprise Managerシステムで実行されないジョブの特定

- D.2 既存のEnterprise Managerシステムで実行されないジョブの特定

E サーバー・ロード・バランサの構成設定の更新

F EM CLIを使用した優先資格証明の設定

G 中央エージェントのベース・ディレクトリのOracleミドルウェア・ホーム外への移動

H Oracle Management Agentの検索および追加

I Oracle Management Repositoryのバックアップ後のOracle Management Agentの保護

J Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリ

- J.1 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにソース・ホスト(Microsoft Windows 32ビット)で実行する手順

- J.2 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うために宛先ホスト(Microsoft Windows 64ビット)で実行する手順

- J.3 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うために実行する最終手順

- J.3.1 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにMicrosoft Windows 32ビット・ホストで実行する最終手順

- J.3.2 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにMicrosoft Windows 64ビット・ホストで実行する最終手順

- J.3.3 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリにおける問題のトラブルシューティング

K 古いOMSホームの削除

- K.1 グラフィック・モードでの古いOMSホームの削除

- K.2 サイレント・モードでの古いOMSホームの削除

L データベース・リンク・エラーを回避または解決するためのデータベース・ドメイン名の修正

- L.1 アップグレード・プロセス開始前のデータベース・リンク・エラーの回避

- L.2 アップグレード・プロセス進行中に発生するデータベース・リンク・エラーの解決

M Enterprise Managerシステムのアップグレードに関連するログ・ファイルの確認

索引

はじめに

『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』は、次のシステムをEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードする方法について説明します。

- Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)

- Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)

- Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)

- Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)

注意:
12cリリース1 (12.1.0.1)がある場合は、先に12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース5 (12.1.0.4)にアップグレードし、次に12cリリース5 (12.1.0.5)にアップグレードします。

対象読者

『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』は、既存の12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)、12cリリース2 (12.1.0.2)、11gリリース1 (11.1.0.1)または10gリリース5 (10.2.0.5) Enterprise Managerシステムをアップグレードするシステム管理者を対象にしています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs(聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Enterprise Manager Cloud Controlのドキュメント・ライブラリ内にある次の資料を参照してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』

- 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

前述のドキュメントおよびその他のOracleドキュメントの最新リリースについては、次のURLのOracle Technology Networkを確認してください。

http://www.oracle.com/technetwork/indexes/documentation/index.html

Enterprise Managerには詳細なオンライン・ヘルプも用意されています。Enterprise Managerには詳細なオンライン・ヘルプも用意されています。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このマニュアル改訂における最新情報

ソフトウェアの増分リリースまたはパッチ・セットのリリースに関するマニュアルの更新に加え、不具合の修正や、ユーザー、製品マネージャ、サポート・チームおよびその他の主なステークホルダーからの付加価値のあるフィードバックを反映するために、オラクル社では定期的にマニュアルの改訂を行っています。マニュアルの改訂ごとに、改訂番号が1つ増加し、Oracle Technology Network (OTN)で公開されます。

この章では、12c リリース5 (12.1.0.5)用に公開された最新のリビジョン(B65086-18)および『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』(このマニュアル)の以前のすべてのリビジョンで反映された変更を列挙しています。最新のリビジョン(B65086-18)とは12c リリース5 (12.1.0.5)用にOTNに公開されている現在のリビジョンであり、最新のリビジョンには以前のリビジョンで反映されたすべての変更が常に含まれていることに注意してください。

この章の具体的な内容は次のとおりです。

- 最新のリビジョンで反映された変更(公開済)

- 以前のリビジョンで反映された変更(アーカイブ済)

最新のリビジョンで反映された変更(公開済)

次は、OTNで公開されている最新のリビジョン(B65086-18)に反映されている変更です。

部、章または項番号

変更の説明

第6章の第6.2項
第6章の第6.6項

この項で言及するノートは、リリース12.1.0.5では参照されないため、後続の項が削除されました。
第6.2項 My Oracle Supportのノート1569883.1にある管理エージェントのアップグレード・チェックリストを参照してください

第6.6項 管理エージェントのトラブルシューティングの追加のヒントについては、My Oracle Supportのノート1569883.1を参照してください

以前のリビジョンで反映された変更(アーカイブ済)

次のセクションでは、以前のリビジョンで反映された変更について説明しています。これらのリビジョンはアーカイブされており、現在はOTNでは利用できません。

B65086-17に追加された変更点

部、章または項番号

変更の説明

第3章の第3.13項
第13章の第13.6.13項

次の項で説明した文章に誤りがあったためそれらの項を削除しました。実際はアップグレード後にカスタマイズが引き継がれます。
第3.13項「Enterprise Managerシステムをアップグレードした後のデプロイメント・プロシージャでのカスタマイズの再実行」

第13.6.13項「デプロイメント・プロシージャでのカスタマイズの再実行」

E22624-43に追加された変更点

部、章または項番号

変更の説明

第4.1項

誤ったコマンドshow_operation_listをshow_operations_listに修正しました。

はじめに

12cリリース1 (12.1.0.1)のアップグレードに関する注意事項を修正しました。

第3章

Oracle WebLogic Serverに関連するカスタマイズの再実行に関する項を削除しました。

E22624-42に追加された変更点

部、章または項番号

変更の説明

はじめに, 第4章

誤字脱字を修正しました。

第13.13.2項

項の導入部の段落を更新し、どのようなタイプの中央エージェントを削除する必要があるか、および削除する理由を説明しました。

E22624-41に追加された変更点

部、章または項番号

変更の説明

第4章

前提条件を更新しました。

第I部

Enterprise Managerシステムのアップグレードの概要

この部では、Enterprise ManagerシステムをアップグレードするためにOracleで用意されているアップグレードの方法を紹介し、既存のEnterprise Managerシステムをアップグレードする前に知っておく必要のある重要な事実について説明します。

特に、次の内容について説明します。

- 第1章「この製品リリースにおける最新情報」

- 第2章「Enterprise Managerシステムのアップグレードに提供されるアップグレード方式の概要」

- 第3章「Enterprise Managerシステムのアップグレードに関する予備知識」

1 この製品リリースにおける最新情報

表1-1は、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)に関連する様々な新機能のトピックについて、Oracle Technology Network (OTN)で公開されているドキュメントへのリンクをまとめたものです。これらのURLで提供されている情報を参照して、12cリリース5 (12.1.0.5)へのアップグレードが必要な理由を理解してください。

表1-1 12cリリース5 (12.1.0.5)の新機能

新機能のトピック

参照URL

12cリリース5 (12.1.0.5)の新機能

『Oracle Enterprise Manager Cloud Control概要』

http://docs.oracle.com/cd/E24628_01/doc.121/e25353/toc.htm

12cリリース5 (12.1.0.5)のインストール・プロセス、エージェント・デプロイメント・プロセスおよびアップグレード・プロセスの新機能

Oracle Technology Networkで公開されているドキュメント

http://www.oracle.com/technetwork/oem/install-upgrade/index.html

12cリリース5 (12.1.0.5)での重要な既知の問題

Oracle Enterprise Manager Cloud Controlリリース・ノート

http://docs.oracle.com/cd/E24628_01/nav/relnotes.htm

12cリリース5 (12.1.0.5)で修正された不具合について

以前のリリースで不具合を見つけ、これらが12cリリース5 (12.1.0.5)で修正されたかどうかを確認する場合は、Oracleサポートにサービス・リクエストを送信してください。

2 Enterprise Managerシステムのアップグレードに提供されるアップグレード方式の概要

Enterprise Managerは過去に何度もリリースされましたが、Enterprise Manager Cloud Controlはこれらのリリースすべてに大きな変更を加えた最新のリリースです。Enterprise Manager Grid Controlと呼ばれた旧リリースとは異なり、このリリースはEnterprise Manager Cloud Controlと呼ばれます。

Enterprise Manager Cloud Controlは、ユーザー・インタフェースが改良され、安定性、信頼性、パフォーマンスがより高められた、様々な新しい機能や強化された機能を提供します。さらに、Enterprise Manager Cloud ControlのコンソールからMy Oracle Supportへシームレスにアクセスし、サービス・リクエストの管理、パッチのデプロイ、ナレッジ・ベースの記事の確認を行うことができます。

この章では、既存の旧リリースのEnterprise Manager Grid ControlまたはEnterprise Manager Cloud Controlを12cリリース5 (12.1.0.5)にアップグレードする方法について説明します。

エンタープライズ全体にわたって様々な組合せでEnterprise Managerをデプロイする選択肢がある場合、環境全体をアップグレードすることは、特に様々なホストに配置された様々なレベル(層)のソフトウェアおよび構成のアップグレードを伴う場合、非常に複雑な作業になります。さらに、ゼロに近い停止時間で、または監視の欠如を最低限に抑えて環境をアップグレードするうえでの課題もあります。

このような課題を考慮して、要件を最も満たす方式を選択できる柔軟性を提供するアップグレード・オプションが用意されています。このアップグレード・オプションは、シームレスでエラーのないものにするためにアップグレード操作全体を簡略化することも目的としています。

この章では、用意されている各種のアップグレード方式の概要を示し、各方式で使用されるユーティリティと、既存のEnterprise Managerシステムをアップグレードするための各方式に従ったプロセス全体について説明します。この章の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレード

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

2.1 Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレード

この項の内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の概要

- Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード・ユーティリティの概要

- Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード方式の概要

注意:

- 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)に必ずアップグレードしてください。

注意:
Enterprise Manager Cloud Controlのこれまでのリリースの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

2.1.1 Enterprise Manager Cloud Control 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)から12cリリース5 (12.1.0.5)へのアップグレードには、1システム・アップグレード方式のみが提供されています。2システム・アップグレード方式はサポートされていません。

1システム・アップグレード方式は、同じホスト上のEnterprise Manager Cloud Controlをアップグレードします。同じホスト上のOracle Management Service (OMS)と既存データベース内のOracle Management Repository (管理リポジトリ)をアップグレードします。アップグレードが同じホスト上で行われるため、ある程度の停止時間が発生します。

このアップグレード方式で、Enterprise Managerシステムは単一インスタンス、または複数OMS環境の実装(エンタープライズの規模が大きい場合に必要)のいずれかになる場合があります。どちらの場合でも、新規OMSは同じホスト上の元のOMSをアップグレードしますが、ある時点でアクティブになるのは新規システムまたは元のシステムのいずれかのみです。

注意:
インストーラは既存の管理エージェントをアップグレードしません。OMSをアップグレードした後、エージェント・アップグレード・コンソールを使用して管理エージェントを個別にアップグレードする必要があります。エージェント・アップグレード・コンソールは、OMSをアップグレードした後にEnterprise Manager Cloud Controlコンソールに表示されるGUIメインのコンソールです。詳細は、2.1.2.2項を参照してください。

表2-1に、12cリリース全体でのOMSと管理エージェント間の互換性について示します。

表 2-1 12cリリースにおけるOMSと管理エージェントの互換性

Oracle Management Agent 12cリリース1 (12.1.0.1) + バンドル・パッチ1

(エージェントおよびそれらのパッチ適用済またはアップグレード済、あるいはバンドル・パッチ1とともにインストールされたプラグインを参照)

Oracle Management Agent 12cリリース2 (12.1.0.2)

Oracle Management Agent 12cリリース3 (12.1.0.3)

Oracle Management Agent 12cリリース4 (12.1.0.4)

Oracle Management Agent 12cリリース5 (12.1.0.5)

Oracle Management Service 12cリリース1 (12.1.0.1) + バンドル・パッチ1

はい

(バンドル・パッチ1を適用済および未適用の管理エージェントを含む)

いいえ

いいえ

いいえ

いいえ

Oracle Management Service 12cリリース2 (12.1.0.2)

はい

(バンドル・パッチ1を適用済および未適用の管理エージェントを含む)

はい

いいえ

いいえ

いいえ

Oracle Management Service 12cリリース3 (12.1.0.3)

はい

(2012年1月にリリースされた[バンドル・パッチ1を適用済]管理エージェントのみ)

はい

はい

いいえ

いいえ

Oracle Management Service 12cリリース4 (12.1.0.4)

いいえ

はい

はい

はい

いいえ

Oracle Management Service 12cリリース5 (12.1.0.5)

いいえ

はい

はい

はい

はい

2.1.2 Enterprise Manager Cloud Control 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)を12cリリース5 (12.1.0.5)にアップグレードする際に使用するユーティリティについて説明します。特に、次の項目について説明します。

- Enterprise Manager Cloud Controlインストール・ウィザードの概要

- エージェント・アップグレード・コンソールの概要

2.1.2.1 Enterprise Manager Cloud Controlインストール・ウィザードの概要

Enterprise Manager Cloud Controlインストール・ウィザードは、1システム・アップグレード方式の選択、および既存のOMSと管理リポジトリのアップグレードを可能にする主要なユーザー・インタフェースです。

提供される機能は次の図に明確に表されています。

2.1.2.2 エージェント・アップグレード・コンソールの概要

エージェント・アップグレード・コンソールは、Enterprise Manager Cloud Control 12cに組み込まれているグラフィカル・ユーザー・インタフェースです。このコンソールでは、Oracle Management Agentを1つ以上アップグレードできます。エージェント・アップグレード・コンソールにアクセスするには、「設定」メニューから、「Cloud Controlの管理」、「エージェントのアップグレード」の順に選択します。

注意:
エージェント・アップグレード・コンソールは、Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)および12cリリース2 (12.1.0.2)で使用できました。しかし、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)で使用可能なコンソールは、この項で説明する管理エージェントのリリースのみをアップグレードします。
12cリリース1 (12.1.0.1)のOracle Management Agentがある場合は、Oracle Management Serviceをアップグレードする前に、エージェント・アップグレード・コンソールを使用してOracle Management Agent 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)に必ずアップグレードしてください。その後、12cリリース5 (12.1.0.5)へアップグレードできます。

注意:
複数OMS環境ではすべてのOMSインスタンスがアップグレードされた後に、エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードできるようになります。

2.1.3 Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード方式の概要

次の図は、1システム・アップグレード方式を使用した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は、Oracle Management Agent 12c (12.1.0.5、12.1.0.4、12.1.0.3、12.1.0.2)とのみ通信します。したがって、旧リリースとは異なり、最初にOMSおよび管理リポジトリをアップグレードしてから、エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードする必要があります。エージェント・アップグレード・コンソールは、OMSをアップグレードした後にEnterprise Manager Cloud Controlコンソールに表示されるGUIメインのコンソールです。詳細は、2.1.2.2項を参照してください。

インストーラを使用してOMSおよび管理リポジトリをアップグレードする場合、デフォルトでインストーラが次の処理も実行します。

- インストーラで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。

- 指定するミドルウェア・ホームにまだインストールされていない場合は、Java Development Kit (JDK) 1.6.0.43.0およびOracle WebLogic Server 11gリリース1 (10.3.6)。

- Oracle Management Service 12 cリリース5 (12.1.0.5)。

- Oracle JRF 11gリリース(11.1.1.7.0) (oracle_commonディレクトリを含む)。

- Oracle Web Tier 11gリリース(11.1.1.7.0) (Oracle_WTディレクトリを含む)。

- Oracle_BI1ディレクトリを含むOracle BI Publisher 11g (11.1.1.7.0)。

注意:
Oracle BI Publisher 11g (11.1.1.7)はデフォルトでインストールされますが、構成はされません。インストール後にこれを構成するまたは旧バージョンからアップグレードするには、『Oracle Enterprise Manager Cloud Control管理者ガイド』の手順に従ってください。

- すでにデプロイされているプラグインをアップグレードするか引き継ぎます。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェアに新しいバージョンがある場合は、デプロイされているプラグインをアップグレードします。

- 次の場合は、デプロイされているプラグインをアップグレードせずに引き継ぎます。
(a) Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェアに新しいバージョンがない場合。

(b)デプロイされているプラグインがすでにEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェアでのバージョン以上である場合。

- アップグレード対象のプラグインに新しい依存関係が存在する場合またはリリースで導入された新しいデフォルト・プラグインがある場合は、新しいプラグインをデプロイします。

- 同じ管理サーバー構成詳細(同じ管理サーバー、同じポートなど)によって、新規のOracle WebLogicドメインとノード・マネージャを作成します。

- Oracle Management Service 12cに関連するすべての構成の詳細を格納する、Oracle Management Serviceインスタンス・ベース・ディレクトリ(gc_inst)をミドルウェア・ホーム外に作成します。
たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。

- 既存の認証済データベース自体の管理リポジトリをアップグレードします。

- 次の構成アシスタントを実行して、インストールまたはアップグレードされたコンポーネントを構成します。

- APMエンジンの停止

- 管理サーバーの停止

- プラグイン前提条件チェック

- リポジトリ・アップグレード

- MDSスキーマ構成

- OMS構成

- プラグイン・デプロイおよび構成

- Oracle Management Serviceの起動

- Oracle Configuration Managerリピータ構成

注意:
インストーラは、OMSとともにインストール済の既存の管理エージェントをアップグレードしません。エージェント・アップグレード・コンソールを使用して、(その他すべての管理エージェントとともに)アップグレードする必要があります。詳細は、2.1.2.2項を参照してください。

2.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

この項では、アップグレード方式の概要を示し、3つのアップグレード方式の違いを明示した後に、10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)を12cリリース5 (12.1.0.5)にアップグレードするために使用するユーティリティと、実行するプロセス全体について説明します。

この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の概要

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の違い

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード・ユーティリティの概要

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード、2システム・アップグレードおよび異なるホストでの1システム・アップグレードのプロセスの概要

注意:
10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)にアップグレードするための手順については、第I部を参照してください。

2.2.1 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の概要

10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)を12cリリース5 (12.1.0.5)にアップグレードするために、次のアップグレード方式が用意されています。

- 1システム・アップグレード方式: この方式では、旧リリースのEnterprise Managerを実行しているホストでEnterprise Manager Cloud Controlにアップグレードできます。この方式では、既存のデータベースのOracle Management Repository(管理リポジトリ)もアップグレードされます。アップグレードが同じホスト上で行われるため、ある程度の停止時間が発生します。
このアプローチは、Enterprise Managerシステムを旧システムと同じホストでアップグレードすること、そしてEnterprise Managerシステムが常に1つしか存在しないことを示しています。複数OMS環境のアップグレードについては、第12.6項を参照してください。

- 2システム・アップグレード方式: この方式では、既存のEnterprise Managerシステムを実行していないホストにEnterprise Manager Cloud Controlをインストールできます。
既存のデータベースの管理リポジトリはアップグレードされませんが、バックアップされたデータベースの管理リポジトリがアップグレードされるので、2つのEnterprise Managerシステムが存在できるようになります。新しいEnterprise Managerシステムは旧システムと共存するので、停止時間はまったく発生しないか、発生したとしてもほぼゼロです。

- 異なるホストでの1システム・アップグレード方式: この方式では、既存のEnterprise Managerを実行していないホストにEnterprise Manager Cloud Controlをインストールできます。
この方式は2システム・アップグレード方式と似ていますが、2システム・アップグレード方式とは異なり、既存のデータベース自体の管理リポジトリがアップグレードされます。Enterprise Managerシステムは常に1つしか存在しないため、ある程度の停止時間が発生します。

2.2.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード方式の違い

表2-2に、10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)を12cリリース5 (12.1.0.5)にアップグレードするために用意されている3つのアップグレード方式の違いを示します。この違いを理解して、個々の要件を最も満たす方式を選択してください。

表2-2 アップグレード方式の違い

1システムのアップグレード方式

2システムのアップグレード方式

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

OMSと管理リポジトリのアップグレードにのみ焦点を当てた従来の方式とは異なり、OMSおよび管理リポジトリをアップグレードする前に、管理エージェントの事前デプロイ操作とスイッチオーバーを行います。

フレッシュ・インストールと同様です。

影響は1システムのアップグレード方式と同じですが、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のホストが異なります。

ある程度の停止時間が必要です。

(基本的に、管理エージェントのスイッチオーバーを開始してからOMSをアップグレードするまで停止します)。

停止時間は必要最低限に抑えられるか、または停止時間は必要ありません。

ある程度の停止時間が必要です。

(基本的に、管理エージェントのスイッチオーバーを開始してからOMSをインストールするまで停止します)。

旧リリースのEnterprise Managerを実行しているホストでEnterprise Manager Cloud Controlにアップグレードします。

既存のEnterprise Managerシステムを実行していないホストにEnterprise Manager Cloud Controlをインストールします。

既存のEnterprise Managerを実行していないホストにEnterprise Manager Cloud Controlをインストールしますが、既存のデータベース自体の管理リポジトリをアップグレードします。

同一のホストでアップグレードされるため、ハードウェア・リソースを追加する必要はありません。

異なるホストにインストールされるため、ハードウェア・リソースの追加が必要です。

異なるホストにインストールされるため、ハードウェア・リソースの追加が必要です。

アップグレード後のEnterprise Managerシステムに構成情報をコピーして新しいシステムに引き継げるように、既存のEnterprise Managerシステムを停止する必要があります。

管理エージェントの旧リリースがすべて、新しくアップグレードされた環境にスイッチオーバーされるまで、既存のEnterprise Managerシステムは実行を継続できます。

新しいシステムに構成情報をコピーして新しいシステムに引き継げるように、既存のEnterprise Managerシステムを停止する必要があります。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをデプロイし、構成する必要があります。

OMSおよび管理リポジトリをアップグレードする前または後で、管理エージェントをデプロイし、構成することができます。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをデプロイし、構成する必要があります。

管理エージェントはインクリメンタルまたは段階的な方法、つまりグループでデプロイし、構成できます。

管理エージェントはインクリメンタルまたは段階的な方法、つまりグループでデプロイし、構成できます。

管理エージェントはインクリメンタルまたは段階的な方法、つまりグループでデプロイできます。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをスイッチオーバーする必要があります。

OMSおよび管理リポジトリをアップグレードした後で、管理エージェントをスイッチオーバーする必要があります。

OMSおよび管理リポジトリをアップグレードする前に、管理エージェントをスイッチオーバーする必要があります。

既存の認証済データベース自体の管理リポジトリをアップグレードします。

バックアップしたデータベースの管理リポジトリをアップグレードします。したがって、前提条件として、既存のOracle Databaseをバックアップする必要があります。

既存の認証済データベース自体の管理リポジトリをアップグレードします。

ポートやファイアウォールの設定を変更する必要はありません。アップグレード後の管理エージェントおよびOMSは、アップグレード前と同じポートを使用します。

ポートやファイアウォールの設定を一部変更する必要があります。アップグレード後の管理エージェントは、アップグレード前と同じポートを使用します。ただし、リモート・ホストにインストールされた管理エージェントとOMSは新しいポートを使用する可能性があります。

複数OMS環境では、サーバー・ロード・バランサ(SLB)を使用している場合、新しい管理エージェントとOMSのために同じSLBに新しいポートを開くか、またはまったく新規にSLBを構成することができます。

詳細は、第3.6項を参照してください。

ポートやファイアウォールの設定を一部変更する必要があります。アップグレード後の管理エージェントは、アップグレード前と同じポートを使用します。ただし、リモート・ホストにインストールされた管理エージェントとOMSは新しいポートを使用する可能性があります。

複数OMS環境では、サーバー・ロード・バランサ(SLB)を使用している場合、新しい管理エージェントとOMSのために同じSLBに新しいポートを開くか、またはまったく新規にSLBを構成することができます。

詳細は、第3.6項を参照してください。

デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。

デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。

デプロイメント・プロシージャはすべて、アップグレードの開始前に終了しておく必要があります。終了していない場合、スケジュール済のプロシージャがキャンセルされ、これらの再作成が必要になります。

実行中のジョブは、停止時間の開始時に中止されます。

実行中のジョブは、バックアップの開始後、既存のEnterprise Managerシステムで引き続き実行されます。Enterprise Manager Cloud Controlでは、これらのジョブは中止された、または失敗したように見えます。

実行中のジョブは、停止時間の開始時に中止されます。

スケジュール済のジョブは、猶予期間に余裕があれば、停止時間の終了後に実行されます。それ以外の場合は省略されます。

スケジュール済のジョブはバックアップ時間から、ターゲットの管理エージェントがEnterprise Manager Cloud Controlに移行されるまで、既存のEnterprise Managerシステムで実行されます。管理エージェントの移行後は、このジョブはEnterprise Manager Cloud Controlで実行されます。

スケジュール済のジョブは、猶予期間に余裕があれば、停止時間の終了後に実行されます。それ以外の場合は省略されます。

繰返しジョブは、停止時間後、次にスケジュールされた時刻に実行されます。繰返しジョブの時間が停止時間と重なる場合、その実行は省略されます。

繰返しジョブは、既存のEnterprise Manageシステムでのスケジュールに従って引き続き実行されます。管理エージェントの移行後、ジョブはEnterprise Manager Cloud Controlで実行されます。

繰返しジョブは、停止時間後、次にスケジュールされた時刻に実行されます。繰返しジョブの時間が停止時間と重なる場合、その実行は省略されます。

注意:
ジョブは既存のEnterprise Managerシステム、またはEnterprise Manager Cloud Controlで実行されます。両方のシステムで実行されることはありません。ジョブの本当の状態は、そのジョブが実際に実行されていたシステムでのみ確認できます。詳細は、付録Dを参照してください。また、すべてのターゲットで使用されるすべての管理エージェントを同時に移行しないかぎり、複数のターゲットを使用したジョブはどちらのシステムでも実行されません。

2.2.3 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供されるアップグレード・ユーティリティの概要

この項では、10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)を12cリリース5 (12.1.0.5)にアップグレードする際に使用するユーティリティについて説明します。これらのユーティリティでは、アップグレード方式の1つを選択し、アップグレード操作全体をシームレスに編成して、アップグレード後アクティビティも追跡できます。

特に、次の項目について説明します。

- アップグレード前コンソールの概要

- Enterprise Manager Cloud Controlインストール・ウィザードの概要

- アップグレード後コンソールの概要

2.2.3.1 アップグレード前コンソールの概要

アップグレード前コンソールは、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)を12cリリース5 (12.1.0.5)にアップグレードするための主要なユーザー・インタフェースとして機能し、開始点となります。

アップグレード前コンソールにより、適切なアップグレード方式の選択、Oracle Management Agent 12cソフトウェアの事前デプロイ、および管理エージェントの旧リリースから新たに事前デプロイされた管理エージェントへのスイッチオーバーができるようになります。

注意:
Oracle Management Service 12cは、Oracle Management Agent 12c (12.1.0.5、12.1.0.4、12.1.0.3、12.1.0.2)とのみ通信します。したがって、旧リリースとは異なり、既存のOMSをアップグレードする前に、まず、使用しているシステムの管理エージェントをアップグレードする必要があります。このため、アップグレード前コンソールからアップグレード・プロセスを開始することになります。

アップグレード前コンソールにアクセスするには、次を行います。

- (オプション) My Oracle Supportのノート822485.1に従って、OMSに最新のPSUパッチを適用します。My Oracle Supportにアクセスするには、次のURLにアクセスします。
https://support.oracle.com/

注意:
10gリリース5 (10.2.0.5)では、PSU 3 (9282397)以上が適用されていることを確認してください。11gリリース1 (11.1.0.1)では、PSU 1 (10065631)以上が適用されていることを確認してください。

- (必須) アップグレード前コンソール・パッチをすべてのOMSインスタンスに適用します。ダウンロードしてプラットフォームに適用する必要があるパッチの詳細は、次のURLにアクセスしてください。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

パッチのダウンロード後、このパッチに付属しているReadMeの指示に従って操作します。パッチを適用するには、必ず最新のOPatchリリースを使用してください。

パッチを適用した後、スーパー管理者権限でEnterprise Manager Grid Controlにログインし、「デプロイ」タブをクリックしてから「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

重要:

- アップグレード前コンソール・パッチはすべてのOMSインスタンスに適用する必要があります。

- パッチを適用するには、OMSを停止する必要があります。この結果、パッチ操作が完了するまで、使用しているEnterprise Managerシステムは停止します。また、パッチはすべてのOMSインスタンスに適用する必要があるため、停止時間はさらに増える可能性があります。

- パッチを適用しても、Enterprise Manager Grid Controlコンソールの「デプロイ」タブでEnterprise Manager 12cアップグレード・コンソールへのハイパーリンクが表示されない場合は、次の手順を実行します。

1. 次の場所からjsp_servletディレクトリを移動します。
$<OMS_INSTANCE_BASE>/user_user_projects/domains/GCDomain/generated_classes

ここで、<OMS_INSTANCE_BASE>はOMSインスタンスのベース・ディレクトリで、これのデフォルトはミドルウェア・ホーム外のgc_instです。たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。

2. OMSホームからOMSを停止します。
$<OMS_HOME>/bin/emctl stop oms

3. OMSホームからOMSを再開します。
$<OMS_HOME>/bin/emctl start oms

提供される機能は次の図に明確に表されています。

注意:
アップグレードに対応している旧リリースは、Oracle Management Agent 10gリリース2 (10.2.x.x.x)、Oracle Management Agent 11gリリース1 (11.1.0.1)、Oracle Management Service 10gリリース5 (10.2.0.5)、およびOracle Management Service 11gリリース1 (11.1.0.1)です。

2.2.3.2 Enterprise Manager Cloud Controlインストール・ウィザードの概要

Enterprise Manager Cloud Controlインストール・ウィザードは、実行するアップグレード方式の選択、および既存のOMSと管理リポジトリのアップグレードを可能にする主要なユーザー・インタフェースです。

提供される機能は次の図に明確に表されています。

2.2.3.3 アップグレード後コンソールの概要

アップグレード後コンソールは、発生データ移行ジョブや遅延データ移行ジョブを含むアップグレード後のアクティビティすべてを追跡するための主要なユーザー・インタフェースです。さらに、差分レポートを生成し、アップグレード後のEnterprise Managerシステムで現在アクティブでないターゲットのリストを表示することができます。

提供される機能は次の図に明確に表されています。

注意:
これらのジョブの詳細は、第13.7項、第13.8項、第13.9項、第13.10項および第13.11項を参照してください。

2.2.4 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード、2システム・アップグレードおよび異なるホストでの1システム・アップグレードのプロセスの概要

この項では、それぞれのアップグレード方式について、実行されるおおよそのフローまたはシーケンスについて説明します。特に、次の項目について説明します。

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード・プロセスの概要

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される2システム・アップグレード・プロセスの概要

- Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される、異なるホストでの1システム・アップグレード・プロセスの概要

2.2.4.1 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される1システム・アップグレード・プロセスの概要

次の図は、1システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。

アップグレード前コンソールを使用して、Oracle Management Agent 12cソフトウェアをデプロイし、古い管理エージェントから新たにデプロイされた管理エージェントへスイッチオーバーすることができます。デプロイとスイッチオーバーはどちらも管理エージェントのインストールとアップグレードを処理しますが、これらはまったく異なる操作であることがわかるでしょう。

注意:
最良の慣例として、スイッチオーバー操作を開始するかなり前に、デプロイ操作を完了しておくことをお薦めします。

デプロイ操作では管理エージェントのソフトウェア・バイナリがコピーされ、ホスト上でこれらの構成が行われますが、スイッチオーバー操作では古い管理エージェントが停止され、Enterprise Manager Cloud Controlで連携するように新しい管理エージェントが起動されます。

ソフトウェア・バイナリのコピーとホスト上での構成の間、既存のEnterprise Managerシステムが停止されないこと、または動作が妨げられないことを保証するために、これら2つの操作は区別され、異なるエンティティとして扱われます。一度コピーされ、構成されたソフトウェア・バイナリは、より迅速にスイッチオーバーできるようになります。これは、古い管理エージェントを停止し、新しい管理エージェントを起動するための時間しか、この操作にはかからないためです。

管理エージェントのスイッチオーバーが完了すれば、OMSと管理リポジトリをアップグレードできるようになります。

注意:
最良の慣例として、スイッチオーバー操作の完了後、ただちにすべてのOMSインスタンスをアップグレードすることもお薦めします。1システム・アップグレード方式での停止時間は、基本的に管理エージェントをスイッチオーバーしたときから、すべてのOMSインスタンスをアップグレードするときまで続くということに注意してください。したがって、アップグレード操作が遅れれば遅れるほど、停止時間が長くなります。この停止時間中、監視されるターゲットはなく、OMSインスタンスにアップロードされる監視データもありません。

インストーラを使用して、ホスト上のEnterprise Manager Cloud Controlをアップグレードする場合、インストーラはデフォルトで次の操作を実行します。

- インストーラで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。

- Oracle Management Service 12c。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0 (JDK)。

注意:
Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0は、既存のインストールの使用を指定しない場合にのみインストールされます。12cのインストール・プロセスを使用して、Enterprise Manager 12cとともに使用するJDKおよびOracle WebLogic Serverをインストールすることを強くお薦めします。
サポートされているバージョンまたはそれ以降に、これらがすでに存在する場合は自動的に検出され、インストール場所のミドルウェア・ホームが表示されます。この場合、このミドルウェア・ホームのパスを確認するだけですみます。

- Oracle JRF 11gリリース(11.1.1.7.0) (oracle_commonディレクトリを含む)と、Oracle Web Tier 11gリリース(11.1.1.7.0) (Oracle_WTディレクトリを含む)。

- Oracle_BI1ディレクトリを含むOracle BI Publisher 11g (11.1.1.7.0)。

注意:
Oracle BI Publisher 11g (11.1.1.7)はデフォルトでインストールされますが、構成はされません。インストール後にこれを構成するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』の手順に従ってください。

- プラグイン:

- Oracleデータベース管理プラグイン

- Oracle Fusion Middleware管理プラグイン

- Oracle My Oracle Support管理プラグイン

- Oracle Exadata管理プラグイン

- Oracle Cloud Frameworkプラグイン

- アップグレード前コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたその他のプラグイン(これらのプラグインがソフトウェア・キットに含まれている場合)

- アップグレードする旧リリースのEnterprise Managerシステムに応じて、Oracle WebLogicドメイン、管理サーバー、ノード・マネージャおよび管理対象サーバーを作成または再利用します。

- Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)からアップグレードする場合、デフォルトで次のものが作成されます。

- GCDomainと呼ばれるOracle WebLogicドメインは、Enterprise Manager Cloud Controlの構成中に自動的に作成されます。このWebLogicドメインでは、デフォルトのユーザー・アカウントweblogicが管理ユーザーとして使用されます。これは、必要に応じてインストーラで変更することもできます。

- Enterprise Manager Cloud Controlの構成中に、nodemanagerという名前のノード・マネージャ・ユーザー・アカウントが自動的に作成されます。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、同じ管理サーバー構成(同じ管理サーバー、同じポートなど)によって、新規のOracle WebLogicドメインとノード・マネージャが作成されます。

- ミドルウェア・ホーム外にOMSインスタンス・ベース・ディレクトリ(gc_inst)を作成し、OMSに関連するすべての構成情報を格納します。
たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。

- 既存の認証済データベース自体の管理リポジトリをアップグレードします。

- インストールまたはアップグレードされたコンポーネントを構成するために実行する構成アシスタントの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

注意:
インストーラにより、既存の管理エージェントがアップグレードされることはありません。これは管理エージェントがアップグレード前コンソールにより事前デプロイされているからです。

2.2.4.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される2システム・アップグレード・プロセスの概要

次の図は、2システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。

インストーラを使用してターゲット・ホストでEnterprise Manager Cloud Controlをインストールおよび構成する場合、デフォルトで次の処理が自動的に実行されます。

- インストーラで入力したミドルウェア・ホームの場所に次のコンポーネントをインストールします。

- Java Development Kit(JDK)1.6.0.43.0

- Oracle WebLogic Server 11gリリース1(10.3.6)

- Oracle Management Service 12c

- Oracle JRF 11gリリース(11.1.1.7.0) (oracle_commonディレクトリを含む)

- Oracle Web Tier 11gリリース(11.1.1.7.0) (Oracle_WTディレクトリを含む)

- Oracle_BI1ディレクトリを含むOracle BI Publisher 11g (11.1.1.7.0)。

注意:
Oracle BI Publisher 11g (11.1.1.7)はデフォルトでインストールされますが、構成はされません。インストール後にこれを構成するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』の手順に従ってください。

- Oracle Management Plug-Ins

- Oracleデータベース管理プラグイン

- Oracle Fusion Middleware管理プラグイン

- Oracle My Oracle Support管理プラグイン

- Oracle Exadata管理プラグイン

- Oracle Cloud Frameworkプラグイン

- アップグレード前コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたその他のプラグイン(これらのプラグインがソフトウェア・キットに含まれている場合)

注意:
Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0は、既存のインストールの使用を指定しない場合にのみインストールされます。12cのインストール・プロセスを使用して、Enterprise Manager 12cとともに使用するJDKおよびOracle WebLogic Serverをインストールすることを強くお薦めします。
サポートされているバージョンまたはそれ以降に、これらがすでに存在する場合は自動的に検出され、インストール場所のミドルウェア・ホームが表示されます。この場合、このミドルウェア・ホームのパスを確認するだけですみます。

- 指定したエージェント・ベース・ディレクトリ(ミドルウェア・ホーム外)にOracle Management Agent 12cをインストールします。

- GCDomainと呼ばれるOracle WebLogicドメインを作成します。このWebLogicドメインでは、デフォルトのユーザー・アカウントweblogicが管理ユーザーとして使用されます。これは、必要に応じてインストーラで変更することもできます。

- nodemanagerと呼ばれるノード・マネージャのユーザー・アカウントを作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

- Oracle Management Service 12cに関連するすべての構成の詳細を格納するために、ミドルウェア・ホーム外にOMSインスタンス・ベースの場所(gc_inst)を構成します。
たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。

- インストールまたはアップグレードされたコンポーネントを構成するために実行する構成アシスタントの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

- OMSを保護するために、内部的にパスワードを生成します。このパスワードはOMSコンフィギュレーション・アシスタントにより生成され、生成後、30日目で有効期限が切れます。
OMSコンフィギュレーション・アシスタント、またはプラグイン・デプロイおよびコンフィギュレーション・アシスタントに失敗した場合は、必ず30日以内に問題を解決してください。解決しなかった場合、エージェント・コンフィギュレーション・アシスタントの実行中に管理エージェントの保護でエラーが発生します。

30日以内に問題を解決できない場合、管理エージェント・ホームから次のコマンドを実行します。

$<AGENT_HOME>/sysman/install/agentDeploy.sh OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_upload_https_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password>

2.2.4.3 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに提供される、異なるホストでの1システム・アップグレード・プロセスの概要

次の図は、異なるホスト上で1システム・アップグレード方式を使用したアップグレードを選択したときに実行する必要のある手順のおおよそのフローまたはシーケンスを表しています。

図のように、この方式は1システム・アップグレード方式と2システム・アップグレード方式を組み合せたものです。1システム・アップグレード方式と同様、まず、管理エージェントの事前デプロイとスイッチオーバーからアップグレード・プロセスを開始します。その後、2システム・アップグレード方式のように、リモート・ホストにEnterprise Manager Cloud Controlをインストールします。ただし、Enterprise Managerの旧リリースで使用していた管理リポジトリをアップグレードしてから、旧リリースを廃止するという違いがあります。このため、一度に複数のEnterprise Managerシステムが存在することはありません。

リモート・ホストにEnterprise Manager Cloud Controlのソフトウェア・バイナリをインストールし、既存の管理リポジトリをアップグレードしてから、ソフトウェア・バイナリを構成すれば、インストールは完了です。

ソフトウェア・バイナリのインストール中に、インストーラは次の処理を実行します。

- Oracleホームを作成し、ミドルウェア・ホームの場所に次のコンポーネントをインストールします。

- Java Development Kit(JDK)1.6.0.43.0

- Oracle WebLogic Server 11gリリース1(10.3.6)

- Oracle Management Service 12c

- Oracle JRF 11gリリース(11.1.1.7.0) (oracle_commonディレクトリを含む)

- Oracle Web Tier 11gリリース(11.1.1.7.0) (Oracle_WTディレクトリを含む)

- Oracle_BI1ディレクトリを含むOracle BI Publisher 11g (11.1.1.7.0)。

注意:
Oracle BI Publisher 11g (11.1.1.7)はデフォルトでインストールされますが、構成はされません。インストール後にこれを構成するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』の手順に従ってください。

- Oracle Management Plug-Ins

- Oracleデータベース管理プラグイン

- Oracle Fusion Middleware管理プラグイン

- Oracle My Oracle Support管理プラグイン

- Oracle Exadata管理プラグイン

- Oracle Cloud Frameworkプラグイン

- アップグレード前コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたその他のプラグイン(これらのプラグインがソフトウェア・キットに含まれている場合)

- 指定したエージェント・ベース・ディレクトリ(ミドルウェア・ホーム外)にOracle Management Agent 12cをインストールします。

ソフトウェア・バイナリの構成中に、インストーラは次の処理を実行します。

- GCDomainと呼ばれるOracle WebLogicドメインを作成します。このWebLogicドメインでは、デフォルトのユーザー・アカウントweblogicが管理ユーザーとして使用されます。これは、必要に応じてインストーラで変更することもできます。

- nodemanagerと呼ばれるノード・マネージャのユーザー・アカウントを作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

- Oracle Management Service 12cに関連するすべての構成の詳細を格納するために、ミドルウェア・ホーム外にOracle Management Serviceインスタンス・ベースの場所(gc_inst)を構成します。
たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instとします。

- インストールまたはアップグレードされたコンポーネントを構成するために実行する構成アシスタントの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

3 Enterprise Managerシステムのアップグレードに関する予備知識

アップグレード方式を使用してEnterprise Manager Cloud Controlにアップグレードする前に、次の点を考慮してください。

- Enterprise ManagerシステムをアップグレードするためにサポートされているOMS環境

- Enterprise Managerシステムのアップグレードでサポートされているアップグレード・パスおよびサポートされているアップグレード方式

- Enterprise Managerシステムのアップグレードでサポートされているプラットフォーム

- Enterprise Managerシステムのアップグレードに提供されるアップグレードの範囲

- ADMP経由で移行されないリポジトリ・バックアップ後に変更またはカスタマイズされたデータ

- アップグレード済Enterprise Managerシステムで使用されたポート

- Enterprise Managerシステムアップグレード時のプラグインのアップグレード

- Enterprise Managerシステムをアップグレードした後のOracle Software Libraryの状態

- アップグレード済Enterprise Managerシステムでのコネクタ

- Enterprise Managerシステムをアップグレードした後のPDP構成ファイルの更新

- アップグレード済Enterprise Managerシステムでの通知、アラート、ジョブ、デプロイメント・プロシージャ実行、メトリック、EM CLIクライアントおよびOracle Exadataターゲット

- OMSおよび管理エージェント用に構成されたカスタム証明書のアップグレード済Enterprise Managerシステムでの再利用

- Enterprise Managerシステムをアップグレードした後のデータベースのXML DB機能

- Enterprise Managerシステムをアップグレードした後のOMSと管理エージェントの手動再起動

- アップグレード済Enterprise Managerシステムのスタンバイ・データベースにOracle Data Guardが構成される場合の強制ロギングの有効化

3.1 Enterprise ManagerシステムをアップグレードするためにサポートされているOMS環境

次のOMS環境のいずれかをアップグレードできます。

- 単一OMS環境: 単一OMS環境は、複数の管理エージェントで編成される1つのOMSを使用した環境です。通常、小さいデプロイメントです。

- 複数OMS環境: 複数OMS環境は、複数の管理エージェントで編成されるサーバー・ロード・バランサ(SLB)でモデレートされた2つ以上のOMSインスタンスを使用した環境です。通常、大きいデプロイメントです。

3.2 Enterprise Managerシステムのアップグレードでサポートされているアップグレード・パスおよびサポートされているアップグレード方式

表3-1に、サポートされているアップグレード・パス、およびそれぞれのアップグレード・パスでサポートされているアップグレード方式をリストします。

表3-1 Enterprise Managerシステムのアップグレードでサポートされているアップグレード・パスおよびサポートされているアップグレード方式

アップグレード元

アップグレード先

サポートされているアップグレード方式

12cリリース4 (12.1.0.4)

12cリリース5 (12.1.0.5)

1システム・アップグレード

12cリリース3プラグイン・アップグレード1 (12.1.0.3)

(2013年10月にリリースされたプラグインが含まれる12cリリース3 (12.1.0.3)ソフトウェア)

12cリリース5 (12.1.0.5)

1システム・アップグレード

12cリリース3 (12.1.0.3)

12cリリース5 (12.1.0.5)

1システム・アップグレード

12cリリース2プラグイン・アップデート1 (12.1.0.2)

(2013年2月にリリースされたプラグインが含まれる12cリリース2 (12.1.0.2)ソフトウェア)

12cリリース5 (12.1.0.5)

1システム・アップグレード

12cリリース2 (12.1.0.2)

12cリリース5 (12.1.0.5)

1システム・アップグレード

バンドル・パッチ1を適用済の12cリリース1 (12.1.0.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)にアップグレード。

なし

バンドル・パッチ1を含む(デフォルトで含まれる)12cリリース1 (12.1.0.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リリース1 (12.1.0.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)にアップグレード。

なし

11gリリース1 (11.1.0.1)

12cリリース5 (12.1.0.5)

- 1システム・アップグレード

- 2システム・アップグレード

- 異なるホストでの1システム・アップグレード

10gリリース5 (10.2.0.5)

12cリリース5 (12.1.0.5)

- 1システム・アップグレード

- 2システム・アップグレード

- 異なるホストでの1システム・アップグレード

10gリリース4 (10.2.0.4)以下

最初に10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)にアップグレードしてから、12cリリース5 (12.1.0.5)にアップグレード

なし

10gリリース1 (10.1)

最初に10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)にアップグレードしてから、12cリリース5 (12.1.0.5)にアップグレード

なし

3.3 Enterprise Managerシステムのアップグレードでサポートされているプラットフォーム

Enterprise Managerシステムのアップグレードでは次のプラットフォームがサポートされています。

- 当然のことですが、1システム・アップグレードでは、同一のホスト上でアップグレードを行うので、旧リリースのEnterprise Managerシステムと同じプラットフォーム上で作業する必要があります。

- 2システム・アップグレードおよび異なるホストでの1システム・アップグレードは、旧リリースのEnterprise Managerシステムと同じプラットフォーム、またはEnterprise Manager Cloud Control 12cがサポートされるすべてのプラットフォームで行うことが可能です。動作保証されているプラットフォームについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているEnterprise Managerの動作保証マトリックスを参照してください。

3.4 Enterprise Managerシステムのアップグレードに提供されるアップグレードの範囲

ここでは、アップグレード方式について説明します。

- 1システム・アップグレード方式、2システム・アップグレード方式、または異なるホストでの1システム・アップグレード方式のいずれかの使用を選択できます。ただし、選択した方式に関係なく、アップグレード操作は常にアウトオブプレース・アップグレードで、Oracle Management Service(OMS)およびOracle Management Agent(管理エージェント)は新しいOracleホームに表示されます。
古いホームと新しいホームを定期的にバックアップすることをお薦めします。

- 追加のOMSをアップグレードするには、常に1システム・アップグレード方式のみを使用するように選択します。

- これらのアップグレード方式では、管理リポジトリが構成される既存のデータベースはアップグレードされません。
このようなデータベースをアップグレードするには、データベース・アップグレード・ツールを使用します。アップグレード・ツールの詳細は、次の場所にあるOracle Databaseドキュメント・ライブラリの『Oracle Databaseアップグレード・ガイド』を参照してください。

http://www.oracle.com/technetwork/indexes/documentation/index.html

- Oracle Management Service 12cは、Oracle Management Agent 12cの次のリリースとのみ通信できます。

表 3-2 12cリリースにおけるOMSと管理エージェントの互換性

Oracle Management Agent 12cリリース1 (12.1.0.1) + バンドル・パッチ1

(エージェントおよびそれらのパッチ適用済またはアップグレード済、あるいはバンドル・パッチ1とともにインストールされたプラグインを参照)

Oracle Management Agent 12cリリース2 (12.1.0.2)

Oracle Management Agent 12cリリース3 (12.1.0.3)

Oracle Management Agent 12cリリース4 (12.1.0.4)

Oracle Management Agent 12cリリース5 (12.1.0.5)

Oracle Management Service 12cリリース1 (12.1.0.1) + バンドル・パッチ1

はい

(バンドル・パッチ1を適用済および未適用の管理エージェントを含む)

いいえ

いいえ

いいえ

いいえ

Oracle Management Service 12cリリース2 (12.1.0.2)

はい

(バンドル・パッチ1を適用済および未適用の管理エージェントを含む)

はい

いいえ

いいえ

いいえ

Oracle Management Service 12cリリース3 (12.1.0.3)

はい

(2012年1月にリリースされた[バンドル・パッチ1を適用済]管理エージェントのみ)

はい

はい

いいえ

いいえ

Oracle Management Service 12cリリース4 (12.1.0.4)

いいえ

はい

はい

はい

いいえ

Oracle Management Service 12cリリース5 (12.1.0.5)

いいえ

はい

はい

はい

はい

- すべてのプラットフォームの管理エージェントは、そのプラットフォームに対応したOracle Management Agent 12cソフトウェアを入手できるかぎり、アップグレード可能です。

- 使用している環境にJava Development Kit (JDK) 1.6.0.43.0およびOracle WebLogic Server 11gリリース1 (10.3.6)が存在しない場合、Enterprise Manager Cloud Controlインストール・ウィザードによって、これらがインストールされます。

- Oracle WebLogic Server 11gリリース1 (10.3.6)が存在しない場合は、インストール・ウィザードにこのインストールを許可することをお薦めします。ただし、これを手動でインストールする必要がある場合は、必ずJDK 1.6.0.43.0 (64ビット・プラットフォームには64ビット・バージョン、32ビット・プラットフォームには32ビット・バージョン)を使用してインストールしてください。

- プラットフォーム・ベンダーのWebサイトから、使用しているプラットフォーム用のJDK 1.6.0.43.0をダウンロードします。
たとえば、Linuxプラットフォーム用のSUN JDK 1.6.0.43.0を次のOracle WebサイトのURLからダウンロードします。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

- すでにJDKを持っている場合は、<JDK_Location>/binディレクトリに移動し、次のコマンドを実行して、バージョンを確認します。
"./java -fullversion"

それが32ビット・バージョンであるか、64ビット・バージョンであるかを確認するには、次のコマンドを実行します。

"file *"

- JROCKITはサポートされていません。

- Linux 64ビット・プラットフォームにOracle WebLogic Server 11gリリース1 (10.3.6)を手動でインストールする必要がある場合は、まず、使用しているプラットフォームに対応した64ビットJDKをインストールし、次にwls1036_generic.jarファイルをダウンロードし、これを使用してOracle WebLogic Serverをインストールします。
次に例を示します。

<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1036_generic.jar>

- Linux 32ビット・プラットフォームにOracle WebLogic Server 11gリリース1 (10.3.6)を手動でインストールする必要がある場合は、wls1036_linux32.binファイルまたはwls1036_generic.jarファイルをダウンロードして使用します。
次に例を示します。

<JDK home>/bin/java -jar <absolute_path _to_wls1036_generic.jar>

- Oracle WebLogic Serverをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に示されている手順に従う必要があります。このガイドは、次のURLにあるFusion Middlewareドキュメント・ライブラリから入手できます。
http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html

- Oracle WebLogic Serverのインストールが標準インストールであることを保証する必要があります。また、カスタム・インストールの実行を選択した場合でも、カスタム・インストールを選択したコンポーネントが標準インストールに関連付けられているコンポーネントと同じであることを確認してください。

- WebLogic Serverをインストールしているユーザーが、Enterprise Manager Cloud Controlをインストールしているユーザーと同一人物であることを確認する必要があります。

- Oracle WebLogic Serverのインストール後、インストール後の手順として、パッチ14482558、13349651および16080294を適用してください。これらのパッチなしでは、追加OMSのインストールが失敗します。ただし、これらのパッチは、Oracle WebLogic Serverを手動でインストールする場合のみ必須です。
これらのパッチの適用手順は、次のURLを参照してください。

http://docs.oracle.com/cd/E14759_01/doc.32/e14143/intro.htm#CHDCAJFC

Oracle WebLogic Serverのダウンロードおよびデモの詳細は、次のURLにアクセスしてください。

http://www.oracle.com/technology/products/weblogic/index.html

- Enterprise Manager Cloud Controlインストール・ウィザードまたはユーザーによってインストールされるOracle WebLogic Server 11gリリース1 (10.3.6)がEnterprise Manager Cloud Control専用であることを確認する必要があります。ミドルウェア・ホームにその他のOracle Fusion Middleware製品をインストールしてはいけません。
ORACLE_COMMONプロパティはEnterprise Manager Cloud ControlとOracle Fusion Middleware製品の両方で使用されるため、これらを同じミドルウェア・ホームに共存させることはできません。

3.5 ADMP経由で移行されないリポジトリ・バックアップ後に変更またはカスタマイズされたデータ

2システム・アップグレード方式を使用して10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリースX (12.1.0.X)にアップグレードした後に、発生データ移行と呼ばれるアップグレード後アクティビティを実行して、古い管理リポジトリに格納されているすべての発生データをアップグレード後の管理リポジトリに移行します。発生データは、ブラックアウト、アラート、イベント、メトリックなどの機能領域に関連しています。発生データ移行の詳細は、第13.8.1項を参照してください。

ただし、この発生データ移行プロセスでは、管理リポジトリのバックアップ後に実行された次の変更は、どれも移行されません。これらの変更がアップグレード後のEnterprise Managerシステムで必要な場合は、アップグレードにこれらの変更を再度手動で実行する必要があります。

- セキュリティ・データ(作成された新規ユーザー、変更されたパスワード)

- 作成、削除または発行されたジョブ

- カスタマイズされたデプロイメント・プロシージャ

- パッチ

- 追加または削除されたターゲット

- 作成、変更または削除されたレポート

- ソフトウェア・ライブラリの構成変更

- 作成、変更または削除されたテンプレート

- ユーザー定義メトリック

3.6 アップグレード済Enterprise Managerシステムで使用されたポート

管理エージェントをアップグレードすると、旧リリースの管理エージェントで使用されていたポートは、アップグレード後の管理エージェントに引き継がれます。そのため、ファイアウォール設定には何も影響しません。

OMSをアップグレードすると、次のポートが割り当てられます。

- 2システム・アップグレード方式では、インストーラで許可または指定した新しいポートは、すべてのコア・コンポーネントに割り当てられます。

- 1システム・アップグレード方式では、次の処理が行われます。

- 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)をアップグレードする場合は、旧リリースのすべてのコア・コンポーネントで使用されていたポートが引き継がれます。

- 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をアップグレードする場合は、旧リリースの次のコア・コンポーネントで使用されたポートが引き継がれます。その他のコア・コンポーネントには、インストーラで許可または指定した新しいポートが割り当てられます。

- Enterprise ManagerアップロードHTTPポート

- Enterprise ManagerアップロードHTTP SSLポート

- Enterprise Managerセントラル・コンソールHTTPポート

- Enterprise Managerセントラル・コンソールHTTP SSLポート

- Oracle Management Agent

- 異なるホストでの1システム・アップグレード方式では、OMSの構成時にレスポンス・ファイルに渡した新しいポートが、すべてのコア・コンポーネントに割り当てられます。

注意:
コア・コンポーネント、ポートが選択される範囲、および割り当てられる空ポートの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』でインストールの基本に関する章を参照してください。
ファイアウォールをOMS用に構成した場合に、ファイアウォールを通して利用可能にする必要のあるURLの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

3.7 Enterprise Managerシステムアップグレード時のプラグインのアップグレード

この項の内容は次のとおりです。

- 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 Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのアップグレード

3.7.1 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)へのアップグレードに並行したプラグインのアップグレード

この項では、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)へのアップグレードに並行したプラグインのアップグレード方法について説明します。

特に、次の項目について説明します。

- Oracle Management Agent 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リリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)、12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのアップグレード

3.7.1.1 Oracle Management Agent 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 Agent 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)を12cリリース5 (12.1.0.5)にアップグレードする際に、旧リリースのプラグインはすべてデフォルトでアップグレードされます。手動による操作は必要ありません。

3.7.1.2 Oracle Management Service 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 Cloud Controlインストール・ウィザードを使用してOracle Management Service 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)を12cリリース5 (12.1.0.5)にアップグレードする際に、プラグインは次の状況に基づいて自動的にアップグレード、移行またはデプロイされます。

- 新しいバージョンが存在する場合、プラグインはアップグレードされます。

- 新しいバージョンが存在しない場合、プラグインは移行されます。

- アップグレード対象のプラグインに新しい依存関係が存在する場合またはリリースで導入された新しいデフォルト・プラグインがある場合、プラグインがデプロイされます。

また、インストール・ウィザードでは「プラグインの選択」画面を使用して、自動的にアップグレード、移行またはデプロイされるプラグイン以外にデプロイするオプション・プラグインを選択できます。

「プラグインの選択」画面にリストされていないプラグインをインストールする場合は、次の手順に従います。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。
UNIXプラットフォームの場合:

./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Microsoft Windowsプラットフォームの場合:

setup.exe -pluginLocation <absolute_path_to_plugin_software_location>

3.7.2 Enterprise Manager Cloud Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのアップグレード

アップグレードに必要なプラグインを識別するには、アップグレード前コンソールの「アップグレード前のステップ」セクションで、「ソフトウェアの管理」をクリックします。「ソフトウェアの管理」ページに、システムのアップグレードに必要なプラグインが表示されます。

「ソフトウェアの管理」ページには、既存システムにある古い管理エージェントにより監視されているターゲット、およびEnterprise Manager Cloud Controlの新しいプラグイン要件に基づいてプラグインがリストされます。既存のシステムを正常にアップグレードするには、このページにリストされているプラグインのみが必要です。

この項では、Oracle Management Agents 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)および、Oracle Management Service 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)のアップグレードと並行して、必要なプラグインをダウンロードしてインストール方法を説明します。

この項の具体的な内容は次のとおりです。

- Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのインストール

- Oracle Management Service 10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのインストール

3.7.2.1 Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのインストール

管理エージェントをアップグレードしながら、必要なプラグインをインストールするには、次の手順を実行します。

1. 次のURLにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. 管理エージェント・ソフトウェアをアクセス可能な場所にダウンロードします。ソフトウェアZIPファイルのコンテンツを解凍しないでください。管理エージェント・ソフトウェアはプラットフォームごとに異なるので、インストールするプラットフォーム用のソフトウェアをコピーするようにしてください。

3. 必要なプラグインをすべて同じ場所にダウンロードします。プラグインは汎用なので、すべてのプラットフォームに共通です。
プラグインを使用してターゲットを監視するかどうかに関係なく、「ソフトウェアの管理」ページに必要なプラグインとしてリストされているプラグインを必ずすべてダウンロードします。ターゲットの監視に使用しないプラグインは不要と思われることがありますが、システムのアップグレードのときに必要になる場合があります。したがって、管理ソフトウェア・ページにリストされているプラグインはすべてダウンロードしてください。これらのプラグインは、管理リポジトリを含むデータベースをバックアップする前にダウンロードする必要があります。

注意:
また、これらのプラグインを<software_kit>/pluginsディレクトリからダウンロードすることもできますが、すべてのプラットフォームに対応した、最新のプラグインを常に入手できますので、OTNからのダウンロードをお薦めします。

注意:
必要なプラグインを識別するには、アップグレード前コンソールの「アップグレード前のステップ」セクションで、表から「ソフトウェアの管理」をクリックします。「ソフトウェアの管理」ページの「プラグイン・ソフトウェア」セクションで必要なプラグインを確認してください。

4. アップグレード前コンソールの「ソフトウェアの管理」ページ(「アップグレード前のステップ」セクション)の「ソフトウェアの場所の指定」セクションで、プラグインの存在するディレクトリの絶対パスを入力し、「検証」をクリックして管理リポジトリにその場所を登録します。

参照:
プラグインの場所の登録および検証の詳細は、第10.4項を参照してください。

3.7.2.2 Oracle Management Service 10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードに並行したプラグインのインストール

OMSのアップグレードと並行して必要なプラグインをインストールする場合は、Enterprise Manager Cloud Controlインストール・ウィザードを起動して、「プラグインの選択」画面に進みます。この画面には、管理エージェントのアップグレード中にアップグレード前コンソール経由で登録した、必要なプラグインがすべてリストされます。必須プラグインはデフォルトで選択されています。

注意:
必要なプラグインの一部を登録しそこなった場合、アップグレードに進む前に、ウィザードからアップグレード前コンソールにアクセスして、そのプラグインを登録するように促すメッセージが表示されます。

この画面にリストされているプラグインに対応したソフトウェアがEnterprise Manager Cloud Controlソフトウェア・キット(DVD、またはダウンロードされたソフトウェア)から入手できることを確認してください。必要なプラグインに対応したソフトウェアが入手できない場合は、次の操作を実行します。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。
UNIXプラットフォームの場合:

./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Microsoft Windowsプラットフォームの場合:

setup.exe -pluginLocation <absolute_path_to_plugin_software_location>

3.8 Enterprise Managerシステムをアップグレードした後のOracle Software Libraryの状態

(この項は、旧リリースのEnterprise Managerでソフトウェア・ライブラリが構成されていた場合にのみ適用されます)

Enterprise Managerのアップグレード後のOracle Software Library(ソフトウェア・ライブラリ)の状態は次のとおりです。

- 1システム・アップグレード方式では、Enterprise Managerをアップグレードすると同時にソフトウェア・ライブラリを使用できるようになります。使用できるようにするために、手作業で操作する必要はありません。

- 2システム・アップグレード方式では、Enterprise Managerをアップグレード後に再構成した場合のみ、ソフトウェア・ライブラリを使用できるようになります。
2システム・アップグレード方式のワークフロー、およびソフトウェア・ライブラリの再構成のタイミングについては、第9.2項を参照してください。ソフトウェア・ライブラリの再構成の詳細は、第13.4項を参照してください。

- 異なるホストでの1システム・アップグレード方式では、Enterprise Managerをアップグレードすると同時にソフトウェア・ライブラリを使用できるようになります。ただし、これは、古いEnterprise Managerシステムに構成されていたソフトウェア・ライブラリ・ファイル・システムの場所にあるすべてのファイルが、新しいホストから読取りおよび書込みアクセスが可能な場合にかぎられます。それ以外の場合は、アップグレードが失敗します。

3.9 アップグレード済Enterprise Managerシステムでのコネクタ

Enterprise Managerシステム全体のアップグレード後、従来のEnterprise Managerシステムで構成されたコネクタはEnterprise Manager Cloud Controlでも引き続き動作します。ただし、構成されていなかったものは機能しません。

3.10 Enterprise Managerシステムをアップグレードした後のPDP構成ファイルの更新

Enterprise Managerでは、特定のユーザーによる特定のコマンドの実行を管理者が制限できる、SUDOやPowerBrokerなどの権限委任プロバイダ(PDP)がサポートされています。このような制限的なPDP構成設定がある場合、一般的には構成ファイルでnmosudoの場所を入力する必要があります。管理エージェントでは、Enterprise Managerの信頼されたジョブの実行にnmosudoが使用されます。

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1) [バンドル・パッチ1を適用済または未適用]で、nmosudoはエージェント・インスタンス・ディレクトリに配置されました。たとえば、/u01/oracle/agent/agent_inst/bin/nmosudoです。

Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以上で、この場所は変更されました。現在、nmosudoはsbinディレクトリ、つまりエージェント・ベース・ディレクトリに存在します。たとえば、/u01/oracle/agent/sbin/nmosudoです。

したがって、12cリリース2 (12.1.0.2)以上をインストール、または12cリリース2 (12.1.0.2) [バンドル・パッチ1を適用済]からアップグレードする際に、nmosudoの新しい場所を更新するようにPDP構成ファイルを変更する必要があります。

たとえば、SUDOをPDPとして使用する場合、sudoの構成ファイルは一般的に/etc/sudoersにあります。このファイルで、次のエントリをnmosudoの新しい場所について更新します。

sudouser ALL : oracle /eminstall/basedir/sbin/nmosudo *

3.11 アップグレード済Enterprise Managerシステムでの通知、アラート、ジョブ、デプロイメント・プロシージャ実行、メトリック、EM CLIクライアントおよびOracle Exadataターゲット

注意:
この項は、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)から12cリリースX (12.1.0.X)にアップグレードする場合にのみ適用されます。
たとえば、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リリース内でアップグレードする場合は、この項を無視できます。

この項は、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする際に認識される、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)の重要な変更について説明します。

特に、次の項目について説明します。

- アップグレード済Enterprise Managerシステムでの通知

- アップグレード済Enterprise Managerシステムでのアラート

- アップグレード済Enterprise Managerシステムでのジョブ

- アップグレード済Enterprise Managerシステムでのデプロイメント・プロシージャ

- アップグレード済Enterprise Managerシステムで名前が変更されるメトリック

- Enterprise Managerシステムをアップグレードした後のEM CLIクライアントのアップグレード

- Enterprise Managerシステムをアップグレードした後のOracle Exadataターゲットのアップグレード

3.11.1 アップグレード済Enterprise Managerシステムでの通知

アップグレード時、システム既存のルール・セットが再登録され、その結果、それらに対して行われた電子メールのサブスクリプションは失われます。そのため、アップグレード・プロセスを開始する前に、システム既存のルール・セットのコピーを作成(類似作成アクションを使用)することをお薦めします。

アップグレード後、すべての通知ルールおよびアラートは引き続きEnterprise Manager Cloud Controlで動作します。ただし、これらは強化されて、より規模が大きく新しい概念に組み込まれ、Enterprise Manager Cloud Controlでは、通知ルールはインシデント・ルールセット、アラートはイベントと呼ばれるようになりました。

インシデント・ルールセットと、これを通知ルールにマップする方法の詳細、およびイベントと、これをアラートにマップする方法の詳細は、付録Bを参照してください。

3.11.2 アップグレード済Enterprise Managerシステムでのアラート

アップグレード中、旧リリースからのアラートは次のようにイベントとしてEnterprise Manager Cloud Controlに移行されます。1システム・アップグレード方式では、アラートは、管理リポジトリのアップグレード中に移行されます。2システム・アップグレード方式では、アラートは、管理リポジトリをリモート・ホストにバックアップしている間に移行されます。

この項の内容は次のとおりです。

- アップグレード済Enterprise Managerシステムに移行されるアラート

- アップグレード済Enterprise Managerシステムで様々なタイプのオープン・アラートに対して作成されるインシデントとイベント

- アップグレード済Enterprise Managerシステムで様々なタイプのクローズド・アラートに対して作成されるインシデントとイベント

3.11.2.1 アップグレード済Enterprise Managerシステムに移行されるアラート

アラートの移行は次のように行われます。

- すべてのオープン・アラートが移行されます。
表3-3は、各種オープン・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。

- 管理リポジトリのアップグレードまたはバックアップの180日前にクローズされたアラートはすべて、遅延データ移行プロセスの一部として移行されます。この180日という期間は管理者が変更できます。
表3-4は、各種クローズド・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。また、クローズド・アラートに関連付けられているチケットがある場合、その情報はイベント移行の一部として取得されないことにも注意してください。

- 管理リポジトリのアップグレード、またはバックアップから7日前以内に作成されたオープン状態のステートフル・アラート、およびステートレス・アラートはすべて移行されます。

注意:
2システム・アップグレード方式では、アラートが、管理リポジトリのバックアップ後にEnterprise Managerシステムの旧リリースで作成されていた場合、そのオープン・アラートは発生データ移行プロセスの一部として移行されます(表3-3を参照)。また、可用性レコードはすべて、発生データ以降プロセスの一部として移行されます。

3.11.2.2 アップグレード済Enterprise Managerシステムで様々なタイプのオープン・アラートに対して作成されるインシデントとイベント

表3-3は、各種オープン・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。

表3-3 様々なタイプのオープン・アラート向けに作成されたインシデントおよびイベント

オープン・アラートのタイプ

作成されたインシデント

イベント作成

クリティカル・アラート

はい

はい

警告アラート

いいえ

はい

チケット付きクリティカル・アラート

はい

はい(チケット付き)

チケット付き警告アラート

はい

はい(チケット付き)

通知保留付きの警告アラート

はい

はい

通知保留なしの警告アラート

いいえ

はい

確認付きクリティカル・アラート

はい

はい

確認付き警告アラート

はい

はい

3.11.2.3 アップグレード済Enterprise Managerシステムで様々なタイプのクローズド・アラートに対して作成されるインシデントとイベント

表3-4は、各種クローズド・アラートについて、インシデントとイベントがいつ、どのように作成されるかをまとめたものです。また、クローズド・アラートに関連付けられているチケットがある場合、その情報はイベント移行の一部として取得されないことにも注意してください。

表3-4 様々なタイプのクローズド・アラート向けに作成されたインシデントおよびイベント

クローズド・アラートのタイプ

作成されたインシデント

イベント作成

クリティカル・アラート

いいえ

はい

警告アラート

いいえ

はい

チケット付きクリティカル・アラート

いいえ

はい(チケットなし)

チケット付き警告アラート

いいえ

はい(チケットなし)

通知保留付きの警告アラート

いいえ

はい

通知保留なしの警告アラート

いいえ

はい

確認付きクリティカル・アラート

いいえ

はい

確認付き警告アラート

いいえ

はい

3.11.3 アップグレード済Enterprise Managerシステムでのジョブ

1システム・アップグレード方式では、ジョブは事実上、期待どおりに実行できます。停止時間内にはジョブは実行されず、停止時間中に実行されていたジョブはすべて、中断されるか、失敗します。また、スケジュール済のジョブはすべて、予定どおり継続されます。

2システム・アップグレード方式では、ジョブの実行方法に多少の制約と注意事項があります。まず、管理エージェントはどの時点でも、ある特定のEnterprise Managerシステムによってのみ監視されているため、ジョブは管理エージェントを監視しているシステム以外では実行できません。管理エージェントが移行されるまで、管理エージェントにより監視されているターゲットに対するジョブはすべて、従来のEnterprise Managerシステムで実行されます。これは、ジョブの真実の状態を知っているEnterprise Managerシステムは1つしかないことも意味します。いかなる場合でも、管理エージェントは一度に1つのシステムとしか通信できないため、実際の状態はEnterprise Managerシステムにしかわからないのです。

- 管理エージェントが移行されていない場合、将来のジョブは、従来のEnterprise Managerシステムではスケジュール済ジョブとして表示されますが、Enterprise Manager Cloud Controlでは管理エージェントが使用できないため一時停止されているジョブとして表示されます。

- バックアップ時に従来のEnterprise Managerシステムで実行されていたジョブは、Enterprise Manager Cloud Controlでは中止されるか、または失敗します。管理エージェントの移行が完了すれば、将来のジョブは、従来のEnterprise Managerシステムでは管理エージェントが使用できないため一時停止されているジョブとして表示されますが、Enterprise Manager Cloud Controlではスケジュール済ジョブとして表示されます。その後、従来のEnterprise Managerシステムから管理エージェントを削除すると、そのジョブも同様に削除されます。
停止時間がなくても従来のEnterprise Managerシステムをバックアップできる場合は、バックアップ時に実行されているジョブはそのまま継続されます。(バックアップに停止時間が必要である場合は、この停止時間のためにジョブは中止される可能性があります。)このようなジョブは、Enterprise Manager Cloud Controlには、中断されたジョブ、失敗したジョブ、または省略されたジョブとして表示されます。

- 繰返しジョブは、スケジュールに従って既存のEnterprise Manageシステムで引き続き実行されます。Enterprise Manager Cloud Controlでは、このようなジョブは中止された、失敗した、または省略されたように見えます。管理エージェントの移行後は、このようなジョブはEnterprise Manager Cloud Controlで実行されるようになります。従来のEnterprise Managerシステムでは、このようなジョブは、管理エージェントが使用できないという理由で一時停止されます。

- バックアップ後に従来のEnterprise Managerシステムで送信されたジョブは、Enterprise Manager Cloud Controlには表示されません。バックアップ後にEnterprise Manager Cloud Controlで送信されたジョブは、従来のEnterprise Managerシステムには表示されません。通常、ジョブは、そのときにターゲットを監視しているシステムでのみ作成されます。

- 管理エージェントまたはそのターゲットが移行される前に、古いEnterprise Managerシステムで作成されたジョブは、古いEnterprise Managerシステムで期待どおりに動作します。

- 繰返しジョブは管理エージェントが移行されるまで実行されます。移行された時点で、これらのジョブは管理エージェントが使用できないため一時停止されているジョブとしてスタックされます。

- ターゲットの移行後、従来のEnterprise Managerシステムでジョブを作成した場合、これらのジョブは管理エージェントが使用できないため一時停止されているジョブとしてスタックされたままになります。したがって、管理エージェントの移行後は、従来のEnterprise Managerシステムでジョブを作成しないでください。

- 管理エージェントがすでに移行されているターゲットのEnterprise Manager Cloud Controlで作成されたジョブは、通常どおりに振る舞い、期待どおりに動作します。

- ターゲットの管理エージェントが移行される前にEnterprise Manager Cloud Controlでジョブを作成することはできますが、管理エージェントが移行されるまで、これらのジョブは管理エージェントが使用できないための一時停止モードになります。
これは、従来のEnterprise Managerシステムで新しいジョブが作成され、ターゲットの移行後に使用するために、Enterprise Manager Cloud Controlでそのコピーが必要とされる場合に特に便利です。通常、これは繰返しジョブです。

- ジョブの予定時刻よりも前に管理エージェントが移行されている場合、このジョブはEnterprise Manager Cloud Controlで実行されます。

- ジョブの予定時刻後に管理エージェントが移行された場合、このジョブは省略されます。これにより、両方のシステムでの同一ジョブの実行が阻止されます。

- ジョブに繰返しスケジュールが設定されている場合、移行前のスケジュールはスキップされ、移行後はスケジュールどおり実行されます。

- 即時実行がスケジュール設定されたジョブはEnterprise Manager Cloud Controlでは実行されず、最終的には省略されます。したがって、移行されていないターゲットに即時実行が必要なジョブを作成しないでください。

- ターゲット1つにつき1ジョブずつ、複数回実行されるジョブの場合、あるターゲットでは一時停止され、別のターゲットでは実行される可能性があります。
管理エージェントAにより監視されているdbAと、管理エージェントBにより監視されているdBという2つのデータベースに対するジョブについて考えてみましょう。管理エージェントBのみを移行した場合、dbAの実行は一時停止されますが、dBは予定した時間が来たときに実行されます。これが繰返しジョブであった場合、dbAの実行は省略されます。管理エージェントAの移行が完了すると、両方とも通常どおり実行されるようになります。

この動作は、グループに送信されるジョブなど、多数のターゲットを持つジョブにとって重要です。従来のEnterprise Managerシステムにより監視されているターゲットに対する実行は、従来のEnterprise Managerシステムで行われますが、Enterprise Manager Cloud Controlにより監視されているターゲットに対する実行は、Enterprise Manager Cloud Controlで行われます。これに対応するもう片方のシステムでの実行は、一時停止、または省略されます。

- 多数のターゲットに対して1ジョブずつ、複数のターゲットで実行されるジョブは、すべてのターゲットで使用される管理エージェントを一括移行するまで、従来のEnterprise Managerシステムでも、Enterprise Manager Cloud Controlでも実行できません。一括移行に適した管理エージェントを判断するには、付録Dの説明に従ってSQL問合せを実行します。
かわりに、管理エージェントを1つずつ移行し、最後の管理エージェントの移行後、猶予期間に余裕があるか、または実行スケジュールがあれば、ジョブを実行することもできます。

3.11.4 アップグレード済Enterprise Managerシステムでのデプロイメント・プロシージャ

Enterprise Managerシステム全体のアップグレード後、10gリリース5 (10.2.0.5)または11gリリース1(11.1.0.1)のデプロイメント・プロシージャはいずれもアップグレード後のEnterprise Managerでは使用できません。以前のランタイム・データを参照する場合は、次のEM CLI動詞を使用してランタイム・データのすべてをXMLファイルとしてエクスポートする必要があります。

get_instance_data_xml

3.11.5 アップグレード済Enterprise Managerシステムで名前が変更されるメトリック

Oracle Fusion Middlewareターゲットに関連するメトリックの一部は、Enterprise Manager Cloud Controlで名前が変更されました。さらに、新しいメトリックもいくつか追加されています。メトリックが変更されているターゲットは次のとおりです。メトリックの変更に関する詳細は、付録Cを参照してください。

- Oracle SOA Infrastructure

- Oracle SOAコンポジット

- Oracle Service Bus

- Oracle WebLogic Server

- JBoss Application Server

- Siebelエンタープライズ

- Siebelサーバー

3.11.6 Enterprise Managerシステムをアップグレードした後のEM CLIクライアントのアップグレード

旧リリースの既存のEM CLIクライアントをすべて、12cリリース1にアップグレードして、これらがEnterprise Manager Cloud Controlで動作できるようにする必要があります。つまり、古いものを破棄して、新しいものをセットアップする必要があります。

新しいEM CLIクライアントの設定に関する詳細は、Cloud Controlコンソール内の「Enterprise Manager Command Line Interface Download」ページを参照してください。このページにアクセスするには、Cloud Controlで「設定」メニューから「プリファレンス」を選択し、「コマンドライン・インタフェース」を選択します。

3.11.7 Enterprise Managerシステムをアップグレードした後のOracle Exadataターゲットのアップグレード

使用している既存のEnterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)上のOracle Exadataターゲットは、デフォルトでアップグレードされません。これらはEnterprise Manager Cloud Controlで手動で検出する必要があります。結果として、このターゲットに関連する履歴データはすべて消失します。

3.12 OMSおよび管理エージェント用に構成されたカスタム証明書のアップグレード済Enterprise Managerシステムでの再利用

12cリリース5 (12.1.0.5)にアップグレードする際に、OMSのアップロードおよびコンソール・ポート用に構成されたすべてのカスタム証明書、および管理エージェント用に構成されたすべてのカスタム証明書が、以前のリリースから自動的に引き継がれ、アップグレードされたリリースに保持されます。これらのカスタム証明書のいずれについても、再構成は不要です。

3.13 Enterprise Managerシステムをアップグレードした後のデータベースのXML DB機能

管理リポジトリの構成を計画しているOracle Database上のXML DBなどの機能を有効化または無効化しても、Enterprise Managerは影響を受けません。したがって、Enterprise Managerはデータベースにあるいずれの機能にも依存しないため、それらを有効化または無効化できます。

3.14 Enterprise Managerシステムをアップグレードした後のOMSと管理エージェントの手動再起動

同じホスト上の管理リポジトリが格納されているOMSおよびOracle Databaseをインストールする場合、ホストを再起動する際に、OMS、および一緒にインストールされた管理エージェントは自動的に開始されません。それらを手動で開始する必要があります。

3.15 アップグレード済Enterprise Managerシステムのスタンバイ・データベースにOracle Data Guardが構成される場合の強制ロギングの有効化

スタンバイ・データベースでOracle Data Guardを構成する場合、次のコマンドを使用してデータベースへの強制ロギングを有効化します。

ALTER DATABASE force logging;

データベースへの強制ロギングを有効化しない場合、Enterprise Managerシステムをアップグレードする際にNOLOGGINGコマンドを使用すると、スタンバイ・データベースを破損する可能性があります。

第II部

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 Cloud Control 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)をEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードする方法について説明します。

この部は、次の章で構成されています。

- 第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)へのアップグレードの開始」

- 第5章「Oracle Management ServiceおよびOracle Management Repository 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレード」

- 第6章「Oracle Management Agentのアップグレード」

- 第7章「JVMDのアップグレードまたは再デプロイ」

- 第8章「ADPのアップグレードまたは再デプロイ」

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)にアップグレードするためのおおよそのプロセスを説明します。

この章の具体的な内容は次のとおりです。

- 単一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)へのアップグレード

- 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)へのアップグレード

注意:

- 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)にアップグレードする方法を示します。この項の具体的な内容は次のとおりです。

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

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

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管理者ガイド』の障害時リカバリに関する章を参照してください。

5 Oracle Management ServiceおよびOracle Management Repository 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から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 ServiceおよびOracle Management Repositoryをアップグレードする様々な方法について説明します。個々の要件を最も満たす方式を選択して、該当する項に示されている手順に従ってください。このアップグレードの手順は、複数OMS環境と同様に単一OMSにも適用されます。

この章の内容は次のとおりです。

- OMSおよび管理リポジトリの12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)へのアップグレード(グラフィック・モード)

- OMSおよび管理リポジトリの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 Cloud Control 12cリリース5 (12.1.0.5)のインストール(グラフィック・モードでソフトウェアのみの方法を使用)

- Enterprise Manager Cloud Control 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アップグレード・ガイド』を参照してください。

- 複数OMS環境をアップグレードしている場合、第5.3項または第5.4項に記載されているように、ソフトウェアのみのアップグレードの方式を利用することをお薦めします(この方式がOMSインスタンスの停止時間を最少とするため)。

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

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

注意:
Oracle Management Service (OMS)とともにインストールされたOracle Management Agent (管理エージェント)はデフォルトでアップグレードされません。エージェント・アップグレード・コンソールを使用して、(その他の管理エージェントとともに)アップグレードする必要があります。これは予測されている動作です。エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードする手順は、第6章を参照してください。

警告:

Enterprise Manager Cloud Control 12cを、SPARCシリーズのサーバー(T1000、T2000、T5xx0およびT3-*)にインストールしないでください。詳細は、My Oracle Supportのノート1590556.1を参照してください。

5.1 OMSおよび管理リポジトリの12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から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 ServiceおよびOracle Management Repositoryをグラフィック・モードでアップグレードするには、次の手順を実行します。

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

警告:

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

注意:
アップグレード中に、一部の管理エージェントがまだアクティブ化保留中状態である、もしくは遅延データ移行プロセス(DDMP)または発生データ移行プロセス(ADMP)が未完了であることを示すエラー・メッセージが表示される場合があります。これは、Enterprise Managerシステムで、旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)への2システム・アップグレードがまだ進行中であることを意味しています。
この問題を解決するには、DDMPおよびADMPジョブが完了し、すべての管理エージェントが旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーされるまで待機します。次に、12cリリース5 (12.1.0.5)へアップグレードします。

旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーしない管理エージェントがあることが確かな場合は、アップグレード・プロセスを開始する前に、第5.1.3項の説明に従って、そのような不要な管理エージェントを削除します。

注意:
アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

注意:
複数OMS環境をアップグレードしようとする場合、アップグレード・プロセスを常に、管理サーバーが動作している最初のOMSから開始してください(追加のOMSインスタンスからは開始しないでください)。
管理サーバーが実行されているOMSを特定するには、OMSホームで次のコマンドを実行して、出力に管理サーバーの詳細が表示されるかどうかを確認します。

$<OMS_HOME>/bin/emctl status oms -details

次のような出力が表示されます。

Oracle Enterprise Manager Cloud Control 12c
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : myhost.example.com
.
.
.
WLS Domain Information
Domain Name : GCDomain
Admin Server Host: myhost.example.com
.
.
.

1. 管理リポジトリ、OMS、インベントリ、ソフトウェア・ライブラリおよびEnterprise Managerの動作に不可欠なその他のコンポーネントをバックアップすることを強くお薦めします。これによって、アップグレードに失敗した場合に、元の内容に戻すことができます。
既存のOMSが実行されているホストで、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。

<Software_Location>/runInstaller [-invPtrLoc <absolute_path_to_oraInst.loc>]

このコマンドで、<Software_Location>はソフトウェア・キットを解凍した場所です。

注意:

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第5.1.1項を参照してください。

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- runInstallerまたはsetup.exeを起動したとき、Enterprise Manager Cloud Controlインストール・ウィザードが表示されない場合、/stageディレクトリへのアクセス権がない可能性があります。
インストール・ウィザードは、クラスパス変数をOPatch用に../stage/Components/として処理します。TEMP変数が/tmpに設定されているとき、インストール・ウィザードはopatchのJARファイルを/tmp/../stageディレクトリ(/stageと同様)で検索しようとします。しかし、ユーザーに/stageへの権限がないと、インストール・ウィザードはハングします。このような場合、/stageディレクトリへのアクセス権があるかどうかを確認します。アクセス権がない場合、TEMP変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

- IBM AIXでのアップグレード中に、ミドルウェア・ホームのJDKバージョンがサポートされているバージョンではないことを示すエラー・メッセージが表示された場合は、メッセージに記載されているサポートされているバージョンがインストールされていることを確認し、-skipJDKValidation引数を渡してインストーラを起動します。
次に例を示します。

./runInstaller -skipJDKValidation

- Microsoft Windowsでは、-invPtrLocはサポートされていません。

2. (オプション)「My Oracle Support」画面でMy Oracle Support資格証明を入力し、Oracle Configuration Managerを有効にします。Oracle Configuration Managerをここで有効にしない場合、手順(3)に進みます。
インストール・ウィザードを実行するホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Supportからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを指定するか、My Oracle SupportにアクセスするクライアントからこのURLへのプロキシ・アクセスを付与する必要があることを意味します。

3. 「次へ」をクリックします。

4. 「ソフトウェアの更新」画面で、最新のPSUパッチを含む、最新のソフトウェア更新を適用します。
ソフトウェア更新は、オフライン・モード(インターネット接続がない場合)またはオンライン・モード(インターネット接続がある場合)でダウンロードできます。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

5. 「次へ」をクリックします。

6. 「前提条件チェック」画面で、インストール・ウィザードによって実行された前提条件チェックのステータスを確認し、環境がアップグレード成功のためのすべての最小要件を満たしているかどうかを確認します。
インストール・ウィザードでは、この画面に達すると前提条件チェックが自動的に実行されます。必要なオペレーティング・システム・パッチ、オペレーティング・システム・パッケージなどがチェックされます。

前提条件チェックのステータスは、「警告」、「失敗」または「成功」のいずれかになります。

「警告」または「失敗」 ステータスになったチェックがある場合は、アップグレードを続行する前に問題を調査して修正してください。この画面では、前提条件が満たされなかった理由や解決方法を提供します。問題を修正した後、この画面に戻り、「再実行」をクリックして前提条件を再度チェックします。

7. 「次へ」をクリックします。

注意:
前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、「再実行」をクリックします。インストール・ウィザードによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストール・ウィザードがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

8. 「インストール・タイプ」画面で、「既存のEnterprise Managerシステムのアップグレード」を選択し、次に「1システムのアップグレード」を選択します。次に、アップグレードするOMSホームを選択します。

9. 「次へ」をクリックします。

10. 「インストールの詳細」画面で、次のようにします。

1. ミドルウェア・ホームを入力するか、検証します。

注意:

- 12cリリース5 (12.1.0.5)へのアップグレードはアウトオブプレース・アップグレードであるため、次のいずれかを実行する必要があります。

- インストーラがOracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を自動的にインストールできる新規のミドルウェア・ホームを入力します。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を事前インストールした新規のミドルウェア・ホームを入力します。ただし、このホームは、現在インストールしているEnterprise Managerシステム用の新しいミドルウェア・ホームであり、前に旧リリースのEnterprise Managerシステムに使用していたミドルウェア・ホームではない必要があります。

- Oracle WebLogic ServerおよびJDKをインストール済の場合は、サポートされているリリース(Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0)であることを確認してください。サポートされているリリースの場合は、インストーラによって検出され、インストール先のミドルウェア・ホームに表示されます。このミドルウェア・ホームへのパスを検証します。インストーラでは、Enterprise Managerがまだ構成されていないミドルウェア・ホームのみが検出され、表示されます。

- ここで入力または検証するミドルウェア・ホームがEnterprise Manager Cloud Controlのみに使用されていることを確認してください。他のOracle Fusion Middleware製品またはコンポーネントは、同じミドルウェア・ホームにインストールしないでください。

2. ホスト名を検証します。デフォルトでは、ホスト名は、既存の旧リリースのEnterprise Managerがインストールされていたホストの名前です。これは編集不可フィールドです。

11. 「次へ」をクリックします。

12. 「データベース接続の詳細」画面で、次のようにします。

- 選択したOMSの管理リポジトリが格納されているデータベースのSYSおよびSYSMANユーザー・アカウントのパスワードを入力します。

- 管理リポジトリがバックアップされていることを確認します(インストーラは、管理リポジトリがバックアップされているかどうかのみをチェックするため、OMS、インベントリ、ソフトウェア・ライブラリおよびEnterprise Managerの動作に不可欠なその他のコンポーネントをバックアップすることを強くお薦めします。これによって、アップグレードに失敗した場合に、元の内容に戻すことができます)。前提条件として、アップグレード・プロセスを開始する前に、管理リポジトリをバックアップする必要があります。まだバックアップを取っていない場合は、ただちに実行し、その後でインストーラに戻ってアップグレードを続行してください。

13. 「次へ」をクリックします。

注意:
プロビジョニング・アーカイブ・フレームワーク(PAF)の前提条件チェック・エラーが発生したら、インストーラを終了し、既存のEnterprise Managerシステムで実行中およびスケジュール済のすべてのデプロイメント・プロシージャを停止してから、インストーラをもう一度起動し、アップグレード・プロセスを再試行します。
実行およびスケジュールされているデプロイメント・プロシージャをすべて特定するには、次の問合せを実行して、そのデプロイメント・プロシージャのGUIDを書き留めます。

SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s, SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p WHERE p.procedure_guid = i.procedure_guid AND s.instance_guid = i.instance_guid AND s.state_type = 0 AND s.status in (0,1)

実行およびスケジュールされているデプロイメント・プロシージャを停止するには、次の問合せを実行して、前述のコマンドの出力から書き留めたGUIDを渡します。

emcli stop_instance -instance=<instance id from sql query>

注意:
この時点でデータベースで実行される様々な前提条件チェックの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

14. 「プラグイン・アップグレード」画面で、次の処理が自動的に行われるプラグインを確認します。

- 新しいバージョンが存在する場合にアップグレード

- 新しいバージョンが存在しない場合に移行

- アップグレード対象のプラグインに新しい依存関係が存在する場合またはリリースで導入された新しいデフォルト・プラグインがある場合は、デプロイ済。
ここで、新しいバージョンとは、インストールに使用するEnterprise Managerソフトウェア(DVDまたはダウンロードしたソフトウェア)で提供されているプラグインの新しいバージョンを指します。

重要:
次の画面に進む前に、関連するすべてのOMSインスタンスを停止します。
$<OMS_HOME>/bin/emctl stop oms -all

注意:

- 新しいバージョンが、使用するEnterprise Managerソフトウェアに存在しないが、Oracle Technology Network (OTN)には存在する場合、既存のプラグインをデフォルトで自動的に移行するかわりに、新しいバージョンをOTNから手動でダウンロードして既存のプラグインをアップグレードすることもできます。次の手順を実行します。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。
UNIXプラットフォームの場合:

./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Microsoft Windowsプラットフォームの場合:

setup.exe -pluginLocation <absolute_path_to_plugin_software_location>

プラグインの新しいバージョンが利用できるようになると、この画面にはそのプラグインが、自動的にアップグレードされるプラグインとしてリストされます。

- OMSまたは管理エージェントの一部にサポートされていないプラグインがあるというメッセージが表示された場合は、メッセージの説明に従ってプラグインをアップグレードし、OMSのアップグレードを再試行します。

15. 「次へ」をクリックします。

16. 「プラグインの選択」画面で、OMSのアップグレード中に自動的にアップグレードされるプラグイン以外にデプロイするオプション・プラグインを選択します。

注意:
この画面にリストされていないプラグインをインストールする場合は、次の手順に従います。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。
UNIXプラットフォームの場合:

./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Microsoft Windowsプラットフォームの場合:

setup.exe -pluginLocation <absolute_path_to_plugin_software_location>

17. 「次へ」をクリックします。

18. 「WebLogic Serverドメインの拡張」画面で次の作業を行って、アップグレードされたOMSに対する新規WebLogicドメインおよび新規OMSインスタンス・ベース・ディレクトリを作成します。

- 管理サーバーのホスト名およびそのポートと、WebLogicユーザー名を検証し、WebLogicユーザー・アカウント・パスワードを入力します。これは、新規WebLogicドメイン(GCDomain)を、アップグレードしている旧リリースのOMSで使用された管理サーバーと同じポートおよびホスト名で作成するために必要です。

注意:
追加のOMSをアップグレードする場合は、最初にアップグレードしたOMS用に構成したホスト名と管理サーバー・ポートを入力し、既存のWebLogic Serverユーザー・アカウントの資格証明を入力します。
ホスト名は、最初のOMSが実行されているホストの名前です。ポートを識別するには、次のファイルでパラメータAS_HTTPS_PORTに設定された値を確認します。

<OMS_INSTANCE_HOME>/em/EMGC_OMS<n>/emgc.properties

- 新規OMSインスタンス・ベース・ディレクトリ(gc_inst)への絶対パスを入力します。これは、アップグレードされたOMSに関連する構成情報を保存するために作成されます。このgc_instディレクトリは、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)の古いgc_instディレクトリであってはいけないため、新しいディレクトリの場所を入力します。古いgc_instディレクトリを入力すると、インストーラはディレクトリが空ではないという警告を表示します。
入力したパスがインスタンス・ベース・ディレクトリへの正しいパスであり、ミドルウェア・ホーム外で保持されていることを確認します。

たとえば、12.1.0.4のミドルウェア・ホームが/u01/app/Oracle/Middlewareで12.1.0.4のOMSインスタンス・ベース・ディレクトリが/u01/app/Oracle/gc_instだった場合、12.1.0.5へのアップグレード時にミドルウェア・ホームを/u01/app/Oracle/Middleware12104と入力した場合、OMSインスタンス・ベース・ディレクトリを/u01/app/Oracle/gc_inst12104と入力すると、ディレクトリ名もディレクトリの場所も一意となります。

注意:
NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

注意:
Oracle WebLogic Serverのパスワードまたはノード・マネージャのパスワードを変更する場合は、My Oracle Supportのノート1450798.1を参照してください。

19. 「次へ」をクリックします。

20. 「確認」画面で、アップグレードのために指定した詳細を確認します。

1. 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

2. 詳細を確認し問題がない場合、「インストール」をクリックしてアップグレード・プロセスを開始します。

21. 「インストールの進行状況」画面で、アップグレード操作の全体的な進行状況(パーセント)と各コンフィギュレーション・アシスタントのステータスを確認します。

注意:

- コンフィギュレーション・アシスタントが失敗すると、インストーラが停止し、失敗したコンフィギュレーション・アシスタントに関連する問題が解決するまで後続のコンフィギュレーション・アシスタントは実行されません。この場合は、問題を診断して解決してから、「インストールの進行状況」画面で「再試行」 をクリックし、失敗したコンフィギュレーション・アシスタントから再度実行します。
ただし、誤って「再試行」 をクリックする前にインストーラを終了してしまった場合は、この画面を開くためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.shスクリプトを起動し、サイレント・モードでコンフィギュレーション・アシスタントを再度実行してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗した場合、サービス・リクエストを発行してOracleサポートに連絡してください。

- 管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

- 第4.1項の手順2 (d)で説明するとおりに必要なデータベース・パッチを適用しなかったためにアップグレードに失敗した場合は、My Oracle Supportのノート1568107.1を参照して、ログ・ファイルでエラーを確認し、問題を解決してから処理を続行してください。

22. ソフトウェア・バイナリがコピーおよび構成されると、allroot.shスクリプトを実行するように求められます。別のウィンドウを開き、rootとしてログインし、これらのスクリプトを手動で実行します。
Microsoft Windowsオペレーティング・システム上でインストールしている場合、このスクリプトの実行は要求されません。

23. 「終了」画面に、Enterprise Managerのアップグレードに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、ウィザードを終了します。

24. 追加のOMSインスタンスがある場合、第5.1項(この項)で概説しているように、次の手順(1)から手順(23)に従って、それぞれのアップグレードを開始します。

25. すべてのOMSインスタンスのアップグレード後に、最初の、古いOMS (つまり、中央エージェント)でインストールされていたものを含む、管理エージェントをアップグレードします。詳細は、第6章を参照してください。

注意:
中央エージェントのアップグレード後に、古いOracleミドルウェア・ホームにあるアップグレードされた中央エージェントのエージェント・ベース・ディレクトリを見つけた場合、およびそれを古いOracleミドルウェア・ホーム外に移動する場合は、My Oracle Supportのノート1520010.1で説明される手順に従います。

26. Enterprise Managerシステムを完全にアップグレードした後に、Enterprise Manager Cloud Controlコンソールに一部の中央エージェントがアクティブ化保留中状態であると表示される場合は、第13.13.2項で説明する手順に従ってそれらを削除してください。

注意:
アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

注意:
古いOMSに関連付けられているJVMターゲットがある場合は、WebLogicドメインをリフレッシュした後も、古いOMSに関連付けられているJVMターゲットがWebLogicドメインのホームページに引き続き表示されます。これは予測されている動作です。
履歴データの表示のためにこれを保持するか、削除することを選択できます。削除するには、孤立したJVMターゲットを右クリックして、「ターゲットの削除」を選択します。

5.1.1 Enterprise Managerシステムのグラフィック・モード・インストール用の拡張インストーラ・オプション

インストーラのグラフィック・モードでの起動中に渡すことができる追加の拡張オプションの一部は、次のとおりです。

- (10.2.0.5をアップグレードする場合のみ適用可) 10gリリース5 (10.2.0.5)をアップグレードするときは、デフォルトでGCDomainという名前の新しいWebLogicドメインが作成されます。この名前を独自の名前で上書きするには、インストーラをWLS_DOMAIN_NAMEオプションとともに起動し、独自の名前を入力します。
たとえば、EMDomainというカスタム名を使用する場合、次のコマンドを実行してください。

./runInstaller WLS_DOMAIN_NAME=EMDomain

- デフォルトでは、デプロイメント・プロシージャに関連するソフトウェア・ライブラリのエンティティをコピーするためのプロビジョニング・アドバイザ・フレームワーク(PAF)ステージング・ディレクトリが作成されます。デフォルトでは、この場所はスクラッチ・パスの場所(/tmp)です。この場所はプロビジョニングのアクティビティにのみ使用されます。エンティティはデプロイメント・プロシージャ用にコピーされ、デプロイメント・プロシージャが終了すると削除されます。
この場所をカスタムの場所でオーバーライドするには、EM_STAGE_DIRオプションによってインストーラを呼出し、一意のカスタムの場所を入力します。

次に例を示します。

./runInstaller EM_STAGE_DIR=/home/john/software/oracle/pafdir

- アップグレード中に、ソフトウェア・キット(DVD、ダウンロードしたソフトウェア)に含まれていないプラグインをインストールするには、次の手順に従います。

1. 次のURLからプラグインを手動でダウンロードし、アクセス可能な場所に保管します。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. 次のオプションでインストーラを起動して、インストールするプラグインを使用できる場所を渡します。
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

ここには、ソフトウェア・キット(DVD、ダウンロードしたソフトウェア)で使用可能なプラグインや、このカスタムの場所で使用可能なプラグインの一覧が表示されます。インストールするものを選択できます。

- アップグレードが正常に終了すると、OMSおよび管理エージェントが自動的に起動されます。自動起動しないようにするには、インストーラをSTART_OMSおよびb_startAgentオプションとともに起動し、制御方法に応じてこれらのオプションをtrueまたはfalseに設定します。
たとえば、管理エージェントが自動的に起動しないようにするには、次のコマンドを実行します。

./runInstaller START_OMS=true b_startAgent=false

この拡張オプションに関する制限を理解するには、第5.1.2項を参照してください。

5.1.2 Enterprise Managerシステムのグラフィック・モード・インストール用の拡張インストーラ・オプションの制限事項

OMSと管理エージェントの自動起動方法を制御する拡張オプションとしてSTART_OMSとb_startAgentを使用する場合、管理エージェントおよびそれがインストールされたホストがCloud Controlコンソールでターゲットとして表示されないことがあります。

表5-1は、こうした拡張オプションの様々な組合せの一覧と、各組合せで従う対処方法を説明しています。

表5-1 拡張オプションと対処方法

拡張オプション

対処方法

START_OMS=false

b_startAgent=false

1. OMSを起動します。
$<OMS_HOME>/bin/emctl start oms

2. 管理エージェントを保護します。
$<AGENT_HOME>/bin/emctl secure agent

3. 管理エージェントを起動します。
$<AGENT_HOME>/bin/emctl start agent

4. ターゲットを追加します。
$<AGENT_HOME>/bin/emctl config agent addinternaltargets

5. ターゲットをアップロードします。
$<AGENT_HOME>/bin/emctl upload agent

6. $<OMS_HOME/binディレクトリのEM CLIツールを手動で構成します。これを行う方法は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。

START_OMS=true

b_startAgent=false

管理エージェントを起動します。

$<AGENT_HOME>/bin/emctl start agent

START_OMS=false

b_startAgent=true

1. OMSを起動します。
$<OMS_HOME>/bin/emctl start oms

2. 管理エージェントを保護します。
$<AGENT_HOME>/bin/emctl secure agent

3. ターゲットを追加します。
$<AGENT_HOME>/bin/emctl config agent addinternaltargets

4. ターゲットをアップロードします。
$<AGENT_HOME>/bin/emctl upload agent

5. $<OMS_HOME/binディレクトリのEM CLIツールを手動で構成します。これを行う方法は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。

5.1.3 12.1.0.4、12.1.0.3、12.1.0.2から12.1.0.5へのアップグレードの前の不要なスタンドアロン管理エージェントの削除

アップグレード中に、一部の管理エージェントがまだアクティブ化保留中状態である、もしくは遅延データ移行プロセス(DDMP)または発生データ移行プロセス(ADMP)が未完了であることを示すエラー・メッセージが表示される場合があります。これは、Enterprise Managerシステムで、旧リリース(10.2.0.5または11.1.0.1)から12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)への2システム・アップグレードがまだ進行中であることを意味しています。

この問題を解決するには、DDMPおよびADMPジョブが完了し、すべての管理エージェントが旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーされるまで待機します。次に、12cリリース5 (12.1.0.5)へアップグレードします。

旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーしない管理エージェントがあることが確かな場合は、アップグレード・プロセスを開始する前に、そのような不要な管理エージェントを削除します。

不要な管理エージェントを削除するには、次の手順を実行します。

1. アップグレード対象の管理リポジトリ(12.1.0.4、12.1.0.3または12.1.0.2リポジトリ)でSYSMANユーザーとして次の問合せを実行することによって、不要な管理エージェントを特定します。
select mt.target_name from sysman.mgmt_targets mt, sysman.em_current_availability eca, sysman.PRE_UPGC_AGT_STAT_MGMT puasm where mt.target_guid = eca.target_guid and eca.current_status = 4 and eca.current_sub_status = 1 and mt.target_type='oracle_emd'and puasm.target_guid = mt.target_guid and puasm.UPGRADE_STATUS != 'IGNORE_UPGRADE' and mt.emd_url not in (select emd_url from PRE_UPGC_TGT_SW where target_type='oracle_emrep') and mt.emd_url not in (select emd_url from mgmt_targets where target_name in(select value from mgmt_oms_parameters where name = 'HOST_NAME')) and mt.emd_url not in (select distinct emd_url from mgmt_targets where target_name like 'EnterpriseManager%home' or target_name like '%GCD omain_EMGC_OMS%')

2. 不要な管理エージェントを削除します。

1. アップグレードしたOMSホストで、OMSホームから、EM CLIクライアントにログインします。各OMSインストールでEM CLIクライアントをデフォルトで使用できるため、クライアントを個別にインストールする必要がありません。
$<OMS_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>

2. EM CLIを同期します。
$<OMS_HOME>/bin/emcli sync

3. 不要な管理エージェントを削除します。ここで、agentNameは、削除する管理エージェントの名前です。
$<OMS_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

3. 12cリリース5 (12.1.0.5)へのアップグレードを続行します。

注意:
もしなんらかの理由で不要な管理エージェントを削除できない場合は、アクティブ化保留中状態の管理エージェントを確認する健全性チェックを停止します。これによって、アップグレード・プロセスを警告なしで続行できます。健全性チェックを停止するには、12cリリース4 (12.1.0.4)、12cリリース1 (12.1.0.3)または12cリリース2 (12.1.0.2)の管理リポジトリで次の問合せを実行します。

MERGE INTO PRE_UPGC_MASTER_INFO DEST
USING dual
ON (DEST.property_name =  'ignore_upg_pending_activation_check')
WHEN MATCHED THEN
UPDATE SET DEST.property_value = 'TRUE'
WHEN NOT MATCHED THEN
INSERT (property_name, property_value) VALUES( 'ignore_upg_pending_ activation_check', 'TRUE' );

5.1.4 NFSマウントされたドライブからローカルのファイル・システムの場所へのロック・ファイルの移動

NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。これを行うには、httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。

1. OMSを停止します。
<OMS_HOME>/bin/emctl stop oms

2. 次のファイルを開きます。

注意:
このファイルを編集する前にバックアップを取ることをお薦めします。

<WEBTIER_INSTANCE_HOME>/config/OHS/ohs<#>/httpd.conf

次に例を示します。

/u01/Oracle/Middleware/gc_inst/WebTierIH1/config/OHS/ohs1/httpd.conf

3. モジュールmpm_prefork_moduleおよびmpm_worker_moduleに関連するセクションを検索します。これらの両方のセクションにおいて、LockFileパラメータに、Oracle HTTP Serverが自動的にhttp_lockファイルを作成できるローカル・ファイル・システム上の場所への絶対パスを指定します。指定した場所が存在していない場合は、これを最初に作成してからここでパスを指定します。

<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
AcceptMutex fcntl
LockFile uo1/em/ohs_locks
</IfModule>
....
<IfModule mpm_worker_module>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
AcceptMutex fcntl
LockFile uo1/em/ohs_locks
</IfModule>

たとえば/u01/emがローカル・ファイル・システム上の場所であるロケーション・パスuo1/em/ohs_locksを指定する場合、ディレクトリohs_locksがすでに存在していることを確認します。これが存在しない場合は、次の方法で作成してからhttpd.confファイルにこのパスを指定します。

mkdir –p /u01/em/ohs_locks

Oracle HTTP Serverは次のロック・ファイルを自動的に作成します。

uo1/em/ohs_locks/http_lock

4. 変更を保存します。

5. OMSを再起動します。
<OMS_HOME>/bin/emctl start oms

5.2 OMSおよび管理リポジトリの12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から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 ServiceおよびOracle Management Repositoryをサイレント・モードでアップグレードするには、次の手順を実行します。

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

警告:

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

注意:
アップグレード中に、一部の管理エージェントがまだアクティブ化保留中状態である、もしくは遅延データ移行プロセス(DDMP)または発生データ移行プロセス(ADMP)が未完了であることを示すエラー・メッセージが表示される場合があります。これは、Enterprise Managerシステムで、旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)への2システム・アップグレードがまだ進行中であることを意味しています。
この問題を解決するには、DDMPおよびADMPジョブが完了し、すべての管理エージェントが旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーされるまで待機します。次に、12cリリース5 (12.1.0.5)へアップグレードします。

旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーしない管理エージェントがあることが確かな場合は、アップグレード・プロセスを開始する前に、第5.1.3項の説明に従って、そのような不要な管理エージェントを削除します。

注意:
アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

注意:
複数OMS環境をアップグレードしようとする場合、アップグレード・プロセスを常に、管理サーバーが動作している最初のOMSから開始してください(追加のOMSインスタンスからは開始しないでください)。
管理サーバーが実行されているOMSを特定するには、OMSホームで次のコマンドを実行して、出力に管理サーバーの詳細が表示されるかどうかを確認します。

$<OMS_HOME>/bin/emctl status oms -details

次のような出力が表示されます。

Oracle Enterprise Manager Cloud Control 12c
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : myhost.example.com
.
.
.
WLS Domain Information
Domain Name : GCDomain
Admin Server Host: myhost.example.com
.
.
.

1. 次のレスポンス・ファイルをローカル・ホスト上のアクセス可能な場所にコピーします。
<Software_Location>/response/upgrade.rsp

このコマンドで、<Software_Location>はソフトウェア・キット(DVD、またはダウンロードしたソフトウェア)を解凍した場所です。

2. レスポンス・ファイルを編集し、付録Aに示された変数に適切な値を入力します。

3. インストーラを起動します。
./runInstaller -silent -responseFile <absolute_path>/upgrade.rsp

注意:

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第5.2.1項を参照してください。

- IBM AIXでのアップグレード中に、ミドルウェア・ホームのJDKバージョンがサポートされているバージョンではないことを示すエラー・メッセージが表示された場合は、メッセージに記載されているサポートされているバージョンがインストールされていることを確認し、-skipJDKValidation引数を渡してインストーラを起動します。
次に例を示します。

./runInstaller -skipJDKValidation

- 前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、インストールを再試行します。インストーラによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストーラがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

4. 追加のOMSインスタンスがある場合、第5.2項(この項)で説明しているように、次の手順(1)から手順(3)に従って、それぞれのアップグレードを開始します。

5. すべてのOMSインスタンスのアップグレード後に、最初の、古いOMS (つまり、中央エージェント)でインストールされていたものを含む、管理エージェントをアップグレードします。詳細は、第6章を参照してください。

注意:
中央エージェントのアップグレード後に、古いOracleミドルウェア・ホームにあるアップグレードされた中央エージェントのエージェント・ベース・ディレクトリを見つけた場合、およびそれを古いOracleミドルウェア・ホーム外に移動する場合は、My Oracle Supportのノート1520010.1で説明される手順に従います。

6. Enterprise Managerシステムを完全にアップグレードした後に、Enterprise Manager Cloud Controlコンソールに一部の中央エージェントがアクティブ化保留中状態であると表示される場合は、第13.13.2項で説明する手順に従ってそれらを削除してください。

注意:

- アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

- 管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

- 第4.1項の手順2 (d)で説明するとおりに必要なデータベース・パッチを適用しなかったためにアップグレードに失敗した場合は、My Oracle Supportのノート1568107.1を参照して、ログ・ファイルでエラーを確認し、問題を解決してから処理を続行してください。

注意:
(12.1.0.Xから12.1.0.5へのアップグレードのみに適用可)古いOMSに関連付けられているJVMターゲットがある場合は、WebLogicドメインをリフレッシュした後も、古いOMSに関連付けられているJVMターゲットがWebLogicドメインのホームページに引き続き表示されます。これは予測されている動作です。
履歴データの表示のためにこれを保持するか、削除することを選択できます。削除するには、孤立したJVMターゲットを右クリックして、「ターゲットの削除」を選択します。

5.2.1 Enterprise Managerシステムのサイレント・モード・インストール用の拡張インストーラ・オプション

インストーラのサイレント・モードでの起動中に渡すことができる追加の拡張オプションの一部は、次のとおりです。

- (10.2.0.5または11.1.0.1からの2システム・アップグレードのみに適用可) 複数のホスト名を持つホスト(仮想ホストなど)上でアップグレードする場合は、インストーラを起動しながら、ORACLE_HOSTNAME引数を使用して完全修飾ホスト名を渡します。
次に例を示します。

./runInstaller ORACLE_HOSTNAME=example.com -silent -responseFile <absolute_path>/upgrade.rsp

- インストールが正常に終了した後、OMSおよび管理エージェントは自動的に起動されます。自動起動しないようにするには、インストーラをSTART_OMSおよびb_startAgentオプションとともに起動し、制御方法に応じてこれらのオプションをtrueまたはfalseに設定します。
たとえば、管理エージェントが自動的に起動しないようにするには、次のコマンドを実行します。

./runInstaller START_OMS=true b_startAgent=false -silent -responseFile <absolute_path>/upgrade.rsp

この拡張オプションに関する制限を理解するには、第5.1.2項を参照してください。

5.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストール(グラフィック・モードでソフトウェアのみの方法を使用)

この項では、グラフィック・モードでEnterprise Manager 12c Cloud Controlのソフトウェア・バイナリのみをある時点でインストールしておき、後でアップグレードする方法について説明します。

このアップグレード方式は、OMSインスタンスの停止時間を最少にするため、複数OMS環境に最適です。この方式は、ソフトウェア・バイナリのコピー、root.shスクリプトの実行およびソフトウェア・バイナリの構成を主とする3つの部分で構成されます。OMSインスタンスを停止せずに、並行してすべてのOMSホスト上でソフトウェア・バイナリをコピーできます。これは時間の節約となるだけでなく、以前のリリースのOMSインスタンスの稼働および実行をこの時点で継続できます。ソフトウェア・バイナリがコピーされると、すべてのOMSインスタンスを停止し、ソフトウェア・バイナリを1つずつ構成してOMSインスタンスをアップグレードできます。したがって停止時間はソフトウェア・バイナリをホストへコピーするときからではなく、OMSインスタンスの構成開始時から開始されます。

この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをすぐにインストール(グラフィック・モード)

- allroot.shスクリプトの実行

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成(グラフィック・モード)

警告:

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

注意:
アップグレード中に、一部の管理エージェントがまだアクティブ化保留中状態である、もしくは遅延データ移行プロセス(DDMP)または発生データ移行プロセス(ADMP)が未完了であることを示すエラー・メッセージが表示される場合があります。これは、Enterprise Managerシステムで、旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)への2システム・アップグレードがまだ進行中であることを意味しています。
この問題を解決するには、DDMPおよびADMPジョブが完了し、すべての管理エージェントが旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーされるまで待機します。次に、12cリリース5 (12.1.0.5)へアップグレードします。

旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーしない管理エージェントがあることが確かな場合は、アップグレード・プロセスを開始する前に、第5.1.3項の説明に従って、そのような不要な管理エージェントを削除します。

注意:
アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

注意:
複数OMS環境をアップグレードしようとする場合、アップグレード・プロセスを常に、管理サーバーが動作している最初のOMSから開始してください(追加のOMSインスタンスからは開始しないでください)。
管理サーバーが実行されているOMSを特定するには、OMSホームで次のコマンドを実行して、出力に管理サーバーの詳細が表示されるかどうかを確認します。

$<OMS_HOME>/bin/emctl status oms -details

次のような出力が表示されます。

Oracle Enterprise Manager Cloud Control 12c
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : myhost.example.com
.
.
.
WLS Domain Information
Domain Name : GCDomain
Admin Server Host: myhost.example.com
.
.
.

5.3.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをすぐにインストール(グラフィック・モード)

Enterprise Manager Cloud Controlのソフトウェア・バイナリをインストールするには、次の手順を実行します。

1. 既存のOMSが実行されているホストで、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。
<Software_Location>/runInstaller [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- このコマンドで、<Software_Location>はソフトウェア・キットを解凍した場所です。

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- Microsoft Windowsでは、-invPtrLocはサポートされていません。

注意:
runInstallerまたはsetup.exeを起動したとき、Enterprise Manager Cloud Controlインストール・ウィザードが表示されない場合、/stageディレクトリへのアクセス権がない可能性があります。
インストール・ウィザードは、クラスパス変数をOPatch用に../stage/Components/として処理します。TEMP変数が/tmpに設定されているとき、インストール・ウィザードはopatchのJARファイルを/tmp/../stageディレクトリ(/stageと同様)で検索しようとします。しかし、ユーザーに/stageへの権限がないと、インストール・ウィザードはハングします。このような場合、/stageディレクトリへのアクセス権があるかどうかを確認します。アクセス権がない場合、TEMP変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

注意:
IBM AIXへのインストール中に、ミドルウェア・ホームで使用しているJDKバージョンがサポートされているバージョンではないことを示すエラー・メッセージが表示された場合は、メッセージに記載されているサポートされているバージョンがインストールされていることを確認し、-skipJDKValidation引数を渡してインストーラを起動します。
次に例を示します。

./runInstaller -skipJDKValidation

2. (オプション)「My Oracle Support」画面でMy Oracle Support資格証明を入力し、Oracle Configuration Managerを有効にします。Oracle Configuration Managerをここで有効にしない場合、手順(3)に進みます。
インストール・ウィザードを実行するホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Supportからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを指定するか、My Oracle SupportにアクセスするクライアントからこのURLへのプロキシ・アクセスを付与する必要があることを意味します。

3. 「次へ」をクリックします。

4. 「ソフトウェアの更新」画面で、最新のPSUパッチを含む、最新のソフトウェア更新を適用します。
ソフトウェア更新は、オフライン・モード(インターネット接続がない場合)またはオンライン・モード(インターネット接続がある場合)でダウンロードできます。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

5. 「次へ」をクリックします。

6. 「前提条件チェック」画面で、インストール・ウィザードによって実行された前提条件チェックのステータスを確認し、環境がアップグレード成功のためのすべての最小要件を満たしているかどうかを確認します。
インストール・ウィザードでは、この画面に達すると前提条件チェックが自動的に実行されます。必要なオペレーティング・システム・パッチ、オペレーティング・システム・パッケージなどがチェックされます。

前提条件チェックのステータスは、「警告」、「失敗」または「成功」のいずれかになります。

「警告」または「失敗」 ステータスになったチェックがある場合は、アップグレードを続行する前に問題を調査して修正してください。この画面では、前提条件が満たされなかった理由や解決方法を提供します。問題を修正した後、この画面に戻り、「再実行」をクリックして前提条件を再度チェックします。

7. 「次へ」をクリックします。

注意:
前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、「再実行」をクリックします。インストール・ウィザードによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストール・ウィザードがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

8. 「インストール・タイプ」画面で、「ソフトウェアのみインストール」を選択します。

9. 「次へ」をクリックします。

10. 「インストールの詳細」画面で、次のようにします。

1. ミドルウェア・ホームを入力するか、検証します。

注意:

- 12cリリース5 (12.1.0.5)へのアップグレードはアウトオブプレース・アップグレードであるため、次のいずれかを実行する必要があります。

- インストーラでOracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を自動的にインストールできる新しいミドルウェア・ホームを入力します。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を事前にインストールしておいた新しいミドルウェア・ホームを入力します。ただし、このホームは、現在インストールしているEnterprise Managerシステム用の新しいミドルウェア・ホームであり、前に旧リリースのEnterprise Managerシステムに使用していたミドルウェア・ホームではない必要があります。

- Oracle WebLogic ServerおよびJDKをインストール済の場合は、サポートされているリリース(Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0)であることを確認してください。サポートされているリリースの場合は、インストーラによって検出され、インストール先のミドルウェア・ホームに表示されます。このミドルウェア・ホームへのパスを検証します。インストーラでは、Enterprise Managerがまだ構成されていないミドルウェア・ホームのみが検出され、表示されます。

- ここで入力または検証するミドルウェア・ホームがEnterprise Manager Cloud Controlのみに使用されていることを確認してください。他のOracle Fusion Middleware製品またはコンポーネントは、同じミドルウェア・ホームにインストールしないでください。

2. 管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。たとえば、/oracle/agentです。この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

注意:
これは必須フィールドですが、OMSとともにインストールされた管理エージェントは必要ではなく、手順(15)の説明のようにアンインストールする必要があります。

3. ホスト名を検証します。デフォルトでは、ホスト名は、既存の旧リリースのEnterprise Managerがインストールされていたホストの名前です。これは編集不可フィールドです。

11. 「次へ」をクリックします。

12. 「確認」画面で、選択したインストール・タイプに指定した詳細を確認します。

- 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

- 詳細を確認し問題がない場合、「インストール」をクリックしてインストール・プロセスを開始します。

13. 「インストールの進行状況」画面で、インストールの全体的な進行状況(パーセント)を確認します。

14. 「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。

15. 管理エージェントと手順10 (b)で作成済のエージェント・ベース・ディレクトリを削除します。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
インストール済の管理エージェントと手順10 (b)で作成済のエージェント・ベース・ディレクトリはフレッシュ・インストールで必須ですが、エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードする場合は使用されません。エージェント・アップグレード・コンソールは、アウトオブプレース・アップグレードを実行し、アップグレード対象の管理エージェントごとに、既存のエージェント・ベース・ディレクトリに新しいエージェント・ホームを作成します。

たとえば、手順10 (b)で、エージェント・ベース・ディレクトリとして/software/oracle/agent12105を指定したとします。この場合でも、古いエージェント・ベース・ディレクトリが/software/oracle/middleware/agent_base/で、古いエージェント・ホームが/software/oracle/middleware/agent_base/core/12.1.0.4であれば、管理エージェントをアップグレードするエージェント・アップグレード・コンソールでは、手順10 (b)で作成されたエージェント・ベース・ディレクトリ/software/oracle/agent12105を使用しません。かわりに、新しいエージェント・ホーム/software/oracle/middleware/agent_base/core/12.1.0.5を既存のエージェント・ベース・ディレクトリ/software/oracle/middleware/agent_base/に作成します。手順10 (b)で指定されたエージェント・ベース・ディレクトリの必要性はなくなっているため、管理エージェントおよびエージェント・ベース・ディレクトリを手動で削除できます。

16. 追加のOMSインスタンスがある場合は、この項(第5.3.1項)で概説されている次の手順によって、追加のOMSホストにソフトウェア・バイナリのコピーも行います。

5.3.2 allroot.shスクリプトの実行

(UNIXのみ)ソフトウェア・バイナリをインストールした後、新しい端末でrootユーザーとしてログインし、OMSホームからallroot.shスクリプトを実行します。

$<OMS_HOME>/allroot.sh

追加のOMSインスタンスがある場合は、追加のOMSホストでもこのスクリプトを実行します。

注意:
この時点でこのスクリプトを実行する権限がない場合、ソフトウェア・バイナリの構成後にいつでも実行できますが、管理エージェントのアップグレードを開始する前に確実に実行してください。

5.3.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成(グラフィック・モード)

Enterprise Manager Cloud Controlのソフトウェア・バイナリを構成するには、次の手順に従います。

1. 次のスクリプトを実行してインストール・ウィザードを起動します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh[-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- Microsoft Windowsの場合は、ConfigureGC.batを実行します。

- 第5.3.1項の説明に従ってソフトウェア・バイナリをインストールし、引数-invPtrLocを渡した場合、ここでも同じ引数を渡します。

- スクリプトの起動時に渡すことができる追加の拡張オプションの詳細は、第5.3.3.1項を参照してください。

2. 「インストール・タイプ」画面で、次のようにします。

1. 「既存のEnterprise Managerシステムのアップグレード」を選択し、次に「1システムのアップグレード」を選択します。

2. アップグレードするOMSホームを選択します。

3. 「次へ」をクリックします。

4. 「データベース接続の詳細」画面で、次のようにします。

- 選択したOMSの管理リポジトリが格納されているデータベースのSYSおよびSYSMANユーザー・アカウントのパスワードを入力します。

- Oracle Management Repository(管理リポジトリ)をバックアップしたことを確認します。前提条件として、アップグレード・プロセスを開始する前に、管理リポジトリをバックアップする必要があります。まだバックアップを取っていない場合は、ただちに実行し、その後でインストーラに戻ってアップグレードを続行してください。

注意:
この時点でデータベースで実行される様々な前提条件チェックの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

5. 「次へ」をクリックします。

注意:
欠落しているプラグインに関するエラーが表示される場合は、次の操作を実行します。

1. 欠落しているプラグインのエラー・メッセージに表示されているとおりに、プラグイン・バージョンおよびプラグイン・アップデートに関するメモを取ります。エラー・メッセージに表示されたプラグインは、次の形式で示されます。
PluginID:PluginVersion:PluginUpdate

2. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

3. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

4. Download Plug-insセクションから、「プラグインがありません」エラー・メッセージに表示されているとおりに、同じプラグイン・バージョンと、同じかそれ以上のプラグイン・アップデートを手動でダウンロードします。プラグインをアクセス可能な場所に保管し、この場所はこれらの欠落したプラグインのためにのみ使用するようにしてください。

5. ConfigureGC.shスクリプトを次のように起動して、ダウンロードしたプラグインをインストールします。
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

次の手順に進む前に、欠落しているプラグインを必ずインストールしてください。

6. 「プラグイン・アップグレード」画面で、次の処理が自動的に行われるプラグインを確認します。

- 新しいバージョンが存在する場合にアップグレード

- 新しいバージョンが存在しない場合に移行

- アップグレード対象のプラグインに新しい依存関係が存在する場合またはリリースで導入された新しいデフォルト・プラグインがある場合は、デプロイ済。

ここで、新しいバージョンとは、インストールに使用するEnterprise Managerソフトウェア(DVDまたはダウンロードしたソフトウェア)で提供されているプラグインの新しいバージョンを指します。

注意:
次の画面に進む前に、関連するすべてのOMSインスタンスを停止します。
$<OMS_HOME>/bin/emctl stop oms -all

注意:

- 新しいバージョンが、使用するEnterprise Managerソフトウェアに存在しないがOTNには存在する場合、既存のプラグインをデフォルトで自動的に移行するかわりに、新しいバージョンをOTNから手動でダウンロードして既存のプラグインをアップグレードすることもできます。次の手順を実行します。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションを指定してインストーラを起動し、ダウンロードしたプラグインのある場所を渡します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

プラグインの新しいバージョンが利用できるようになると、この画面にはそのプラグインが、自動的にアップグレードされるプラグインとしてリストされます。

- OMSまたは管理エージェントの一部にサポートされていないプラグインがあるというメッセージが表示された場合は、メッセージの説明に従ってプラグインをアップグレードし、OMSのアップグレードを再試行します。

7. 「次へ」をクリックします。

8. 「プラグインの選択」画面で、OMSのアップグレード中に自動的にアップグレードされるプラグイン以外にデプロイするオプション・プラグインを選択します。

注意:
この画面にリストされていないその他のプラグインをインストールする場合は、次の手順に従います。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションを指定してインストーラを起動し、ダウンロードしたプラグインのある場所を渡します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

9. 「次へ」をクリックします。

10. 「WebLogic Serverドメインの拡張」画面で次の作業を行って、アップグレードされたOMSに対する新規WebLogicドメインおよび新規OMSインスタンス・ベース・ディレクトリを作成します。

- 管理サーバーのホスト名およびそのポートと、WebLogicユーザー名を検証し、WebLogicユーザー・アカウント・パスワードを入力します。これは、新規WebLogicドメイン(GCDomain)を、アップグレードしている旧リリースのOMSで使用された管理サーバーと同じポートおよびホスト名で作成するために必要です。

注意:
追加のOMSをアップグレードする場合は、最初にアップグレードしたOMS用に構成したホスト名と管理サーバー・ポートを入力し、既存のWebLogic Serverユーザー・アカウントの資格証明を入力します。
ホスト名は、最初のOMSが実行されているホストの名前です。ポートを識別するには、次のファイルでパラメータAS_HTTPS_PORTに設定された値を確認します。

<ORACLE_HOME>/gc_inst/em/EMGC_OMS<n>/emgc.properties

- 新規OMSインスタンス・ベース・ディレクトリ(gc_inst)への絶対パスを入力します。これは、アップグレードされたOMSに関連する構成情報を保存するために作成されます。このgc_instディレクトリは、12cリリース4 (12.1.0.4)の古いgc_instディレクトリであってはいけないため、新しいディレクトリの場所を入力します。古いgc_instディレクトリを入力すると、インストーラはディレクトリが空ではないという警告を表示します。
入力したパスがインスタンス・ベース・ディレクトリへの正しいパスであり、ミドルウェア・ホーム外で保持されていることを確認します。

たとえば、12.1.0.4のミドルウェア・ホームが/u01/app/Oracle/Middlewareで12.1.0.4のOMSインスタンス・ベース・ディレクトリが/u01/app/Oracle/gc_instだった場合、12.1.0.5へのアップグレード時にミドルウェア・ホームを/u01/app/Oracle/Middleware12105と入力した場合、OMSインスタンス・ベース・ディレクトリを/u01/app/Oracle/gc_inst12105と入力すると、ディレクトリ名もディレクトリの場所も一意となります。

注意:
NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

注意:
Oracle WebLogic Serverのパスワードまたはノード・マネージャのパスワードを変更する場合は、My Oracle Supportのノート1450798.1を参照してください。

11. 「次へ」をクリックします。

12. 「確認」画面で、選択したインストール・タイプに指定した詳細を確認します。

- 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

- 詳細を確認した後、問題がなければ、「構成」をクリックしてインストール・プロセスを開始します。

13. 「インストールの進行状況」画面で、インストールの全体的な進行状況(パーセント)を確認します。

注意:

- コンフィギュレーション・アシスタントが失敗すると、インストーラが停止し、失敗したコンフィギュレーション・アシスタントに関連する問題が解決するまで後続のコンフィギュレーション・アシスタントは実行されません。この場合は、問題を診断して解決してから、「インストールの進行状況」画面で「再試行」 をクリックし、失敗したコンフィギュレーション・アシスタントから再度実行します。
ただし、誤って「再試行」をクリックする前にインストーラを終了してしまった場合は、この画面を開くためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.shスクリプトを起動し、サイレント・モードでコンフィギュレーション・アシスタントを再度実行してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗した場合、サービス・リクエストを発行してOracleサポートに連絡してください。

- 管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

- 第4.1項の手順2 (d)で説明するとおりに必要なデータベース・パッチを適用しなかったためにアップグレードに失敗した場合は、My Oracle Supportのノート1568107.1を参照して、ログ・ファイルでエラーを確認し、問題を解決してから処理を続行してください。

14. 「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。

15. 追加のOMSインスタンスがある場合、この項(第5.3.3項)で概説する手順に従って、それぞれのアップグレードを開始します。

16. すべてのOMSインスタンスのアップグレード後に、最初の、古いOMS (つまり、中央エージェント)でインストールされていたものを含む、管理エージェントをアップグレードします。詳細は、第6章を参照してください。

注意:
中央エージェントのアップグレード後に、古いOracleミドルウェア・ホームにあるアップグレードされた中央エージェントのエージェント・ベース・ディレクトリを見つけた場合、およびそれを古いOracleミドルウェア・ホーム外に移動する場合は、My Oracle Supportのノート1520010.1で説明される手順に従います。

17. Enterprise Managerシステムを完全にアップグレードした後に、Enterprise Manager Cloud Controlコンソールに一部の中央エージェントがアクティブ化保留中状態であると表示される場合は、第13.13.2項で説明する手順に従ってそれらを削除してください。

注意:
アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

注意:
古いOMSに関連付けられているJVMエージェントがある場合は、WebLogicドメインをリフレッシュした後も、古いOMSに関連付けられているJVMエージェントがWebLogicドメインのホームページに引き続き表示されます。これは予測されている動作です。
履歴データの表示のためにこれを保持するか、削除することを選択できます。削除するには、孤立したJVMターゲットを右クリックして、「ターゲットの削除」を選択します。

5.3.3.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)へのソフトウェアのみのアップグレードの拡張スクリプト・オプション

configureGC.shの起動中に渡すことができる、追加の拡張オプションを次に示します。

- デフォルトでは、GCDomainがWebLogicドメインの作成に使用されるデフォルト名です。この名前を上書きし、独自のWebLogicドメイン名を使用するには、このスクリプトをWLS_DOMAIN_NAMEオプションとともに起動し、独自の名前を入力します。
たとえば、EMDomainというカスタム名を使用する場合、次のコマンドを実行してください。

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh WLS_DOMAIN_NAME=EMDomain

- 構成が正常に終了すると、OMSおよび管理エージェントが自動的に起動されます。自動的に起動しない場合、START_OMSおよびb_startAgentオプションを使用してスクリプトを起動し、制御する内容に応じてtrueまたはfalseに設定します。
たとえば、管理エージェントが自動的に起動しないようにするには、次のコマンドを実行します。

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh START_OMS=true b_startAgent=false

この拡張オプションに関する制限を理解するには、第5.1.2項を参照してください。

5.4 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストール(サイレント・モードでソフトウェアのみの方法を使用)

この項では、サイレント・モードでEnterprise Manager 12c Cloud Controlのソフトウェア・バイナリのみをある時点でインストールしておき、後でアップグレードする方法について説明します。

このアップグレード方式は、OMSインスタンスの停止時間を最少にするため、複数OMS環境に最適です。この方式は、ソフトウェア・バイナリのコピー、root.shスクリプトの実行およびソフトウェア・バイナリの構成を主とする3つの部分で構成されます。OMSインスタンスを停止せずに、並行してすべてのOMSホスト上でソフトウェア・バイナリをコピーできます。これは時間の節約となるだけでなく、以前のリリースのOMSインスタンスの稼働および実行をこの時点で継続できます。ソフトウェア・バイナリがコピーされると、すべてのOMSインスタンスを停止し、ソフトウェア・バイナリを1つずつ構成してOMSインスタンスをアップグレードできます。したがって停止時間はソフトウェア・バイナリをホストへコピーするときからではなく、OMSインスタンスの構成開始時から開始されます。

この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(サイレント・モード)

- allroot.shスクリプトの実行

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成(サイレント・モード)

警告:

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

注意:
アップグレード中に、一部の管理エージェントがまだアクティブ化保留中状態である、もしくは遅延データ移行プロセス(DDMP)または発生データ移行プロセス(ADMP)が未完了であることを示すエラー・メッセージが表示される場合があります。これは、Enterprise Managerシステムで、旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)への2システム・アップグレードがまだ進行中であることを意味しています。
この問題を解決するには、DDMPおよびADMPジョブが完了し、すべての管理エージェントが旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーされるまで待機します。次に、12cリリース5 (12.1.0.5)へアップグレードします。

旧リリースから12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)にスイッチオーバーしない管理エージェントがあることが確かな場合は、アップグレード・プロセスを開始する前に、第5.1.3項の説明に従って、そのような不要な管理エージェントを削除します。

注意:
アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

注意:
複数OMS環境をアップグレードしようとする場合、アップグレード・プロセスを常に、管理サーバーが動作している最初のOMSから開始してください(追加のOMSインスタンスからは開始しないでください)。
管理サーバーが実行されているOMSを特定するには、OMSホームで次のコマンドを実行して、出力に管理サーバーの詳細が表示されるかどうかを確認します。

$<OMS_HOME>/bin/emctl status oms -details

次のような出力が表示されます。

Oracle Enterprise Manager Cloud Control 12c
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : myhost.example.com
.
.
.
WLS Domain Information
Domain Name : GCDomain
Admin Server Host: myhost.example.com
.
.
.

5.4.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(サイレント・モード)

Enterprise Manager 12c Cloud Controlのソフトウェア・バイナリをインストールするには、次の手順を実行します。

1. 次のレスポンス・ファイルをローカル・ホスト上のアクセス可能な場所にコピーします。
<Software_Location>/response/software_only.rsp

このコマンドで、<Software_Location>はソフトウェア・キットを解凍した場所です。

2. レスポンス・ファイルを編集し、表5-2に示された変数に適切な値を指定します。

3. インストーラを起動します。
./runInstaller -silent -responseFile <absolute_path>/software_only.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第5.2.1項を参照してください。

- IBM AIXへのインストール中に、ミドルウェア・ホームで使用しているJDKバージョンがサポートされているバージョンではないことを示すエラー・メッセージが表示された場合は、メッセージに記載されているサポートされているバージョンがインストールされていることを確認し、-skipJDKValidation引数を渡してインストーラを起動します。
次に例を示します。

./runInstaller -skipJDKValidation

4. 管理エージェントと作成済のエージェント・ベース・ディレクトリを削除します。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。
インストール済の管理エージェントと作成済のエージェント・ベース・ディレクトリはフレッシュ・インストールで必須ですが、エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードする場合は使用されません。エージェント・アップグレード・コンソールは、アウトオブプレース・アップグレードを実行し、アップグレード対象の管理エージェントごとに、既存のエージェント・ベース・ディレクトリに新しいエージェント・ホームを作成します。

たとえば、レスポンス・ファイルで、エージェント・ベース・ディレクトリとして/software/oracle/agent12105を指定したとします。この場合でも、古いエージェント・ベース・ディレクトリが/software/oracle/middleware/agent_base/で、古いエージェント・ホームが/software/oracle/middleware/agent_base/core/12.1.0.4であれば、管理エージェントをアップグレードするエージェント・アップグレード・コンソールでは、レスポンス・ファイルを使用して作成されたエージェント・ベース・ディレクトリ/software/oracle/agent12105を使用しません。かわりに、新しいエージェント・ホーム/software/oracle/middleware/agent_base/core/12.1.0.5を既存のエージェント・ベース・ディレクトリ/software/oracle/middleware/agent_base/に作成します。手順10 (b)で指定されたエージェント・ベース・ディレクトリの必要性はなくなっているため、管理エージェントおよびエージェント・ベース・ディレクトリを手動で削除できます。

5. 追加のOMSインスタンスがある場合は、この項(第5.4.1項)で概説されている次の手順によって、追加のOMSホストにもソフトウェア・バイナリをコピーします。

5.4.1.1 サイレント・モードでEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストールするためのsoftware_only.rspレスポンス・ファイルの編集

表5-2は、Enterprise Manager Cloud Controlのソフトウェア・バイナリをインストールする際に、編集が必要な変数およびsoftware_only.rspレスポンス・ファイルでの編集方法を示しています。

表5-2 サイレント・モードでEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストールするためのsoftware_only.rspレスポンス・ファイルの編集

パラメータ

データ型

値に二重引用符が必要か？

説明

UNIX_GROUP_NAME

String

はい

(中央インベントリが存在しない場合にのみ必須)所属するUNIXグループの名前を入力します。

たとえば、"dba"などです。

INVENTORY_LOCATION

String

はい

(中央インベントリが存在しない場合にのみ必須)中央インベントリへの絶対パスを入力します。

たとえば、"/scratch/oracle/oraInventory"とします。

SECURITY_UPDATES_VIA_MYORACLESUPPORT

Boolean

はい

- セキュリティ更新をダウンロードしてインストールする場合は、TRUEを入力します。続いて、次の変数に二重引用符で囲った資格証明を入力します。
MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

- セキュリティ更新をダウンロードしてインストールする場合は、FALSEを入力します。

DECLINE_SECURITY_UPDATES

Boolean

いいえ

- セキュリティ更新を拒否する場合は、TRUEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにFALSEを入力する必要があります。

- セキュリティ更新を拒否しない場合は、FALSEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにTRUEを入力する必要があります。

INSTALL_UPDATES_SELECTION

String

はい

この変数はデフォルトで、インストール中にソフトウェア更新がインストールされないことを示す"skip"に設定されています。

- My Oracle Supportからソフトウェア更新をインストールする場合、この変数を"download"に設定します。続いて、次の変数に二重引用符で囲った資格証明を入力します。
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- ステージングされた場所からソフトウェア更新をインストールする場合、この変数を"staged"に設定します。続いて、STAGE_LOCATION変数には、ソフトウェア更新が含まれるUpdatesディレクトリまで含めた絶対パスを二重引用符で囲って入力します。
このオプションの場合、前提条件として、ソフトウェア更新がすでにダウンロードされている必要があります。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

ORACLE_MIDDLEWARE_HOME_LOCATION

String

はい

12cリリース5 (12.1.0.5)へのアップグレードはアウトオブプレース・アップグレードであるため、次のいずれかを実行する必要があります。

- インストーラでOracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を自動的にインストールできる新しいミドルウェア・ホームを入力します。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を事前にインストールしておいた新しいミドルウェア・ホームを入力します。ただし、このホームは、現在インストールしているEnterprise Managerシステム用の新しいミドルウェア・ホームであり、前に旧リリースのEnterprise Managerシステムに使用していたミドルウェア・ホームではない必要があります。

ミドルウェアの場所に、OMSおよび管理エージェントのOracleホームを作成するための書込み権限があることを確認してください。

注意: ここで入力するミドルウェア・ホームは、Enterprise Manager Cloud Controlのためにのみ使用するようにしてください。他のOracle Fusion Middleware製品またはコンポーネントは、同じミドルウェア・ホームにインストールしないでください。

AGENT_BASE_DIR

String

はい

管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。

たとえば、"u01/app/Oracle/agent"です。この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

ORACLE_HOSTNAME

(10.2.0.5または11.1.0.1の2システム・アップグレードのみに適用可)

String

はい

デフォルトでは、インストーラを起動しているホストの完全修飾名が想定されます。

- デフォルト値を受け入れる場合は、空白のままにしておきます。

- 異なるホスト名でインストールする場合は、別のホスト名を入力します。

FROM_LOCATION

適用なし

適用なし

このパラメータは無視してください。

DEINSTALL_LIST

適用なし

適用なし

このパラメータは無視してください。

REMOVE_HOMES

適用なし

適用なし

このパラメータは無視してください。

5.4.2 allroot.shスクリプトの実行

(UNIXのみ)ソフトウェア・バイナリをインストールした後、新しい端末でrootユーザーとしてログインし、OMSホームからallroot.shスクリプトを実行します。

$<OMS_HOME>/allroot.sh

追加のOMSインスタンスがある場合は、追加のOMSホストでもこのスクリプトを実行します。

注意:
この時点でこのスクリプトを実行する権限がない場合、ソフトウェア・バイナリの構成後にいつでも実行できますが、管理エージェントのアップグレードを開始する前に確実に実行してください。

5.4.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成(サイレント・モード)

Enterprise Manager Cloud Controlのソフトウェア・バイナリを構成するには、次の手順に従います。

1. Enterprise Manager Cloud Controlのソフトウェア・バイナリをコピーしたホストのアクセス可能な場所に次のレスポンス・ファイルをコピーします。
<Software_Location>/response/upgrade.rsp

このコマンドで、<Software_Location>はソフトウェア・キットを解凍した場所です。

2. レスポンス・ファイルを編集し、付録Aに示された変数に適切な値を入力します。

3. ConfigureGC.shスクリプトを起動して前のステップで編集したレスポンス・ファイルを渡し、ソフトウェア・バイナリを構成します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -silent -responseFile <absolute_path>/upgrade.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- 第5.4.1項の説明に従ってソフトウェア・バイナリをインストールし、引数-invPtrLocを渡した場合、ここでも同じ引数を渡します。

- スクリプトの起動時に渡すことができる追加の拡張オプションの詳細は、第5.3.3.1項を参照してください。

- 前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、インストールを再試行します。インストーラによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストーラがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
欠落しているプラグインに関するエラーが表示される場合は、次の操作を実行します。

1. 欠落しているプラグインのエラー・メッセージに表示されているとおりに、プラグイン・バージョンおよびプラグイン・アップデートに関するメモを取ります。エラー・メッセージに表示されたプラグインは、次の形式で示されます。
PluginID:PluginVersion:PluginUpdate

2. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

3. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

4. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

5. ConfigureGC.shスクリプトを次のように起動して、ダウンロードしたプラグインをインストールします。
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

4. 追加のOMSインスタンスがある場合、この項(第5.4.3項)で概説する次の手順に従って、それぞれのアップグレードを開始します。

5. すべてのOMSインスタンスのアップグレード後に、最初の、古いOMS (つまり、中央エージェント)でインストールされていたものを含む、管理エージェントをアップグレードします。詳細は、第6章を参照してください。

注意:
中央エージェントのアップグレード後に、古いOracleミドルウェア・ホームにあるアップグレードされた中央エージェントのエージェント・ベース・ディレクトリを見つけた場合、およびそれを古いOracleミドルウェア・ホーム外に移動する場合は、My Oracle Supportのノート1520010.1で説明される手順に従います。

6. Enterprise Managerシステムを完全にアップグレードした後に、Enterprise Manager Cloud Controlコンソールに一部の中央エージェントがアクティブ化保留中状態であると表示される場合は、第13.13.2項で説明する手順に従ってそれらを削除してください。

注意:

- アップグレード後に、不要な場合は古いOMSホームの削除を選択できます。手順については、付録Kを参照してください。

- 管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

- 第4.1項の手順2 (d)で説明するとおりに必要なデータベース・パッチを適用しなかったためにアップグレードに失敗した場合は、My Oracle Supportのノート1568107.1を参照して、ログ・ファイルでエラーを確認し、問題を解決してから処理を続行してください。

注意:
(12.1.0.Xから12.1.0.5へのアップグレードのみに適用可)古いOMSに関連付けられているJVMターゲットがある場合は、WebLogicドメインをリフレッシュした後も、古いOMSに関連付けられているJVMターゲットがWebLogicドメインのホームページに引き続き表示されます。これは予測されている動作です。
履歴データの表示のためにこれを保持するか、削除することを選択できます。削除するには、孤立したJVMターゲットを右クリックして、「ターゲットの削除」を選択します。

6 Oracle Management Agentのアップグレード

この章では、Enterprise Manager Cloud Control 12c Oracle Management Agent (管理エージェント)をアップグレードする方法について説明します。この章の内容は次のとおりです。

- 12c管理エージェントのアップグレードの概要

- 12c管理エージェントのアップグレードを開始する前に

- 12c管理エージェントをアップグレードするための前提条件

- 12c管理エージェントのアップグレード

- 12c管理エージェントのアップグレード後

- 12c管理エージェントのアップグレードのトラブルシューティング

6.1 12c管理エージェントのアップグレードの概要

Enterprise Manager Cloud Control 12cリリース4 (12.1.0.5)を使用してエンタープライズを管理している場合は、すべてのOracle Management Agent (管理エージェント)を12.1.0.5にアップグレードすることをお薦めします。

12cの管理エージェントをアップグレードするには、エージェント・アップグレード・コンソールの「エージェントのアップグレード」ページ(Enterprise Manager Cloud Controlコンソールの一部)を使用するか、EM CLIを使用できます。「エージェントのアップグレード」ページは単一ウィンドウ・ソリューションとして動作し、Oracle Software Library (ソフトウェア・ライブラリ)でソフトウェアを利用できる最新バージョンに、既存の管理エージェントを一括アップグレードします。

エージェント・アップグレード・コンソールは、「エージェントのアップグレード・タスク」タブと「エージェントのアップグレード後のタスク」タブで構成されます。「エージェントのアップグレード・タスク」タブは、12cの管理エージェントのアップグレード、アップグレードできない管理エージェントの表示、および管理エージェントのアップグレード・ジョブの概要の表示に使用できます。「エージェントのアップグレード後のタスク」タブは、アップグレードした12cの管理エージェントの古いディレクトリのクリーンアップおよび管理エージェントのクリーンアップ・ジョブの概要の表示に使用できます。エージェント・アップグレード・コンソールにアクセスするには、「設定」メニューから、「Cloud Controlの管理」を選択し、次に「エージェントのアップグレード」を選択します。

図6-1に、エージェント・アップグレード・コンソールを示します。

図6-1 エージェント・アップグレード・コンソール

管理エージェントのアップグレードにより、そのインストール・ベース・ディレクトリ構造は変更されます。12cリリース4 (12.1.0.4)の管理エージェントを12cリリース5 (12.1.0.5)にアップグレードした場合のインストール・ベース・ディレクトリ構造の例を次に示します。

アップグレード前

<agent_base_directory>
|_____sbin
|_____core
|_____12.1.0.4.0
|_____plugins
|_____agent_inst
|_____agentimage.properties
.
.
.

アップグレード後

<agent_base_directory>
|_____sbin
|_____backup_agtup
|_____core
|_____12.1.0.4.0
|_____12.1.0.5.0
|_____plugins
|_____agent_inst
|_____agentimage.properties
.
.
.

注意:

- 管理エージェントをアップグレードするとき、エージェントのベース・ディレクトリの場所は変更できません。

- 管理エージェントをアップグレードすると、管理エージェント・ホストにインストールされているすべてのプラグインも、その最新バージョンがOracle Software Library (ソフトウェア・ライブラリ)に存在するかぎり、デフォルトでアップグレードされます。プラグインの最新バージョンがソフトウェア・ライブラリに存在しない場合は、その旧バージョンが保持されます。

- (Microsoft Windowsホストの場合) 12.1.0.xの管理エージェントをアップグレードして、他の管理エージェントを同じホストにインストールする(別のOMSを示す)場合は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の説明のとおりに、管理エージェントのインストール時にs_agentSrvcNameパラメータを指定してください。

6.2 12c管理エージェントのアップグレードを開始する前に

12c管理エージェントをアップグレードする前に、次のことに注意する必要があります。

- Oracle Management Service (OMS)がバージョン12cリリース5 (12.1.0.5)の場合、エージェント・アップグレード・コンソールまたはEM CLIを使用してアップグレードできるのは、12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)の管理エージェントのみで、12cリリース1 (12.1.0.1)の管理エージェントはアップグレードできません。
12.1.0.5 OMSでサポートされる管理エージェントのバージョンの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 古いOracle Management Service (OMS)とともにインストールされた中央エージェントをアップグレードする必要があります。
OMSホストにインストールされている中央エージェントを含む管理エージェントは、OMSの12cリリース5 (12.1.0.5)へのアップグレード中に自動的にアップグレードされません。必ず、古いOMSを12.1.0.5にアップグレードした後すぐに、OMSホストにインストールされた中央エージェントをアップグレードしてください。

- 特権優先資格証明または非特権資格証明が設定されていない場合、または管理エージェント資格証明が認識されていない場合でも、エージェント・アップグレード・コンソールまたはEM CLIを使用して、管理エージェントをアップグレードできます。特権資格証明が要求されるのは、root.shアップグレード後スクリプトを実行する場合のみです。
root権限を持たないユーザーとして管理エージェントをアップグレードすると、または特権優先資格証明なしで管理エージェントをアップグレードすると、警告が表示されます。アップグレード時は、この警告を無視できます。後から、rootユーザーとして管理エージェント・ホストにログインして、$<AGENT_BASE_DIR>/core/12.1.0.5.0/root.shスクリプトを実行できます。

- 一部の状況では、アップグレードされたバージョンの管理エージェントが、デプロイされたバージョンのプラグインをサポートしていない場合があります。このような場合、アップグレードされたバージョンの管理エージェントでサポートされていないプラグインのアンデプロイ、またはアップグレードされた管理エージェントでサポートされているバージョンのプラグインのデプロイのどちらかを確実に行います。
プラグインのアンデプロイおよびデプロイ方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- Enterprise Manager Cloud Control 12cリリース4 (12.1.0.5)では、管理エージェント・ソフトウェアの特定のバージョンに適用する管理エージェントの個別パッチを保存でき、これらのパッチは、同じバージョンの新しい管理エージェントがデプロイされるたび、または古い管理エージェントをそのバージョンにアップグレードしたときに、ソフトウェアに自動的に適用されます。
これを行う方法の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

また、個別パッチをプラグインに適用して、カスタムのパッチが適用されたプラグインを作成でき、このカスタムのパッチが適用されたプラグインは、デプロイするすべての新しい管理エージェント、およびアップグレードするすべての古い管理エージェントにデプロイされます。

これを行う方法の詳細は、Oracle Enterprise Manager Cloud Control管理ガイドを参照してください。

- 管理エージェントをアップグレードする際に、Cygwin、PsExecまたは任意のSSH接続ツールは必要ありません。Enterprise Managerは管理エージェントとOMSの既存の接続チャネルを使用してアップグレードを実行するためです。

- 管理エージェントのアップグレード中には、カスタム・インベントリの場所を指定できません。アップグレードされた管理エージェントは、古い管理エージェントのインベントリの場所を使用します。

- クラスタにインストールされている管理エージェントまたは共有管理エージェントをアップグレード用に選択する場合、関係する一連の管理エージェント、つまりクラスタの別の管理エージェントまたは共有Oracleホームは自動的にアップグレード用に選択されます。

- 次のシナリオでは管理エージェントをアップグレードできません。

- 管理エージェントが稼働中および実行中ではない

- 管理エージェントがセキュアでない

- 管理エージェントが使用できない

- (OMSバージョンと同じバージョンの)新しい管理エージェント・ソフトウェアがOracle Software Library (ソフトウェア・ライブラリ)に存在しない

- 管理エージェントのOracleホーム・プロパティが見つからない

- すでに管理エージェントのアップグレードが進行中である

- カーネル・パッチまたはマッチ・バンドルの適用による下位リリースのSolarisのアップグレードと、実際のSolaris 5.10アップデート9イメージのインストールとは等価ではありません。Oracle Management Agent 12cリリース5 (12.1.0.5)は最低アップデート・バージョンのSolaris 5.10アップデート9に基づいてビルド、テストおよび動作保証されていたため、Oracle Management AgentをSolaris 5.10アップデート9にのみインストールし、パッチを使用してアップグレードした他のリリースにはインストールしないことをお薦めします。

6.3 12c管理エージェントをアップグレードするための前提条件

12c管理エージェントをアップグレードする前に、次の前提条件を満たす必要があります。

- OMSホストのプラットフォームとは異なるプラットフォームで実行中の管理エージェントをアップグレードする場合は、自己更新を使用して、そのプラットフォーム用の最新の管理エージェント・ソフトウェアをソフトウェア・ライブラリでダウンロードして適用してください。
自己更新にアクセスするには、「設定」メニューから、「拡張性」を選択し、「自己更新」を選択します。プラットフォーム用の最新の管理エージェントのソフトウェアがダウンロードされて適用されているかどうか確認するには、「エージェント・ソフトウェア」をクリックしてから、目的のプラットフォームの「バージョン」列および「ステータス」列を確認します。プラットフォームのソフトウェア・バージョンは、OMSバージョンと同じである必要があります。ステータスには「適用」と表示されている必要があります。

最新のソフトウェアがダウンロードされて適用されていない場合、ソフトウェアを選択してから「ダウンロード」をクリックしてダウンロードします。ソフトウェアのダウンロード後、「適用」をクリックしてソフトウェアを適用します。ソフトウェアがダウンロード済でまだ適用されていない場合、「適用」をクリックしてソフトウェアを適用します。

プラットフォーム用の最新の管理エージェントをダウンロードおよび適用するための自己更新の使用方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- アップグレードする管理エージェントが稼働し実行中であることを確認します。
管理エージェントが稼働中および実行中であるかどうかを確認するには、「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。目的の管理エージェントの「ステータス」列をチェックします。

管理エージェントが使用できない場合、管理エージェント名をクリックして、管理エージェント・ホームページに移動します。「エージェント使用不可」アイコンをクリックし、推奨アクションを実行します。

- アップグレードする管理エージェントがセキュアであることを確認します。
管理エージェントがセキュアかどうかを確認するには、「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。目的の管理エージェントの「セキュア・アップロード」列をチェックします。

管理エージェントがセキュアでない場合、「エージェント」メニューから、「セキュア」を選択して保護します。

また、次のコマンドを実行して、管理エージェントがセキュアかどうかを確認することもできます。

<EMSTATE>/bin/emctl status agent

<EMSTATE>は、管理エージェントのインスタンス・ディレクトリである<AGENT_BASE_DIRECTORY>/agent_instです。

管理エージェントがセキュアである場合、表示される管理エージェントのURLはHTTPS URLです。ただし、表示される管理エージェントのURLがHTTP URLの場合、次のコマンドを実行して、管理エージェントを保護します。

<EMSTATE>/bin/emctl secure agent

- アップグレードするすべての管理エージェントでOMSコレクションが実行されていることを確認します。
一部の管理エージェントでOMSコレクションが実行されていない場合、それらはアップグレードされません。これらの管理エージェントは、「アップグレード可能なエージェントがありません」ページに、Oracleホームのプロパティがありませんという理由とともに表示されます。このページにアクセスする方法の詳細は、第6.4.3項を参照してください。

アップグレードする管理エージェント上でOMSコレクションを実行するには、管理エージェントのホストから次のコマンドを実行します。

<EMSTATE>/bin/emctl control agent runCollection <TARGET_NAME>:oracle_home oracle_home_config

<EMSTATE>は、管理エージェントのインスタンス・ディレクトリである<AGENT_BASE_DIRECTORY>/agent_instです。

<TARGET_NAME>は、<EMSTATE>/sysman/emd/targets.xmlにあるターゲット・タイプoracle_homeの管理エージェント・ターゲットです。

- 古い管理エージェントが、管理エージェントのアップグレード・プロセス中に起動しないことを確認します。
停止時に管理サーバーを開始するスケジュールされた特定のcronジョブ、または構成された特定の通知マネージャがある場合があります。古い管理エージェントは、アップグレード・プロセスの一部として停止されます。この管理エージェントが起動されないことを確認します。

- インストール・ユーザーに、Oracleインベントリ内にあるすべてのファイルに対して読取り権限があり、Oracleインベントリ・ディレクトリに対して書込み権限があることを確認します。
Oracleインベントリ内にあるすべてのファイルに対する読取り権限を付与するには、インストール・ユーザーとして次のコマンドを実行します。

chmod -R +r $<INVENTORY_LOCATION>

Oracleインベントリ・ディレクトリに対する書込み権限を付与するには、インストール・ユーザーとして次のコマンドを実行します。

chmod +rw $<INVENTORY_LOCATION>

- 指定した一時ディレクトリ(つまりステージングの場所)と、アップグレード対象の管理エージェントのエージェント・ベース・ディレクトリが同じディスク上に存在する場合、そのディスクに少なくとも3GBの空きディスク領域があることを確認します。別のディスク上に存在する場合、一時ディレクトリに少なくとも2.1GBの空きディスク領域があり、エージェント・ベース・ディレクトリに少なくとも750MBの空きディスク領域があることを確認します。

6.4 12c管理エージェントのアップグレード

この項では、管理エージェントのアップグレードに必要な作業について説明します。内容は次のとおりです。

- 12c管理エージェントのアップグレード

- 12c管理エージェントのアップグレード用の追加パラメータ

- アップグレードできない12c管理エージェントの表示

- 古い管理エージェントのアップグレード後クリーンアップの実行

- 12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

6.4.1 12c管理エージェントのアップグレード

この項では、12.1.0.xの管理エージェントをアップグレードするために使用できる方法について説明します。内容は次のとおりです。

- エージェント・アップグレード・コンソールを使用した12c管理エージェントのアップグレード

- EM CLIを使用した12c管理エージェントのアップグレード

6.4.1.1 エージェント・アップグレード・コンソールを使用した12c管理エージェントのアップグレード

エージェント・アップグレード・コンソールを使用して、12.1.0.xの管理エージェントをアップグレードするには、次の手順に従います。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェントのアップグレード」を選択します。

2. 「ジョブ名」には、デフォルトのジョブ名をそのまま使用するか、一意のジョブ名を入力します。
一意のジョブ名により、エージェントのアップグレード・ステータス・ページで、アップグレード・ジョブを識別し、その実行の詳細を参照し、進行を追跡することができます。

ジョブ名は、最大長が64文字です。英数字および特殊文字を含めることができ、そのどちらからでも始めることができます。

3. 「追加」をクリックして、アップグレード対象の管理エージェントを選択します。
「アップグレード可能なエージェント」ウィンドウで、「エージェント」、「インストールされたバージョン」、「プラットフォーム」および「グループ」のフィールドを使用して、アップグレード対象の管理エージェントを検索します。

アップグレード対象の管理エージェントを選択します。「OK」をクリックします。

重要:

- このリリースでは、12cリリース2 (12.1.0.2)の管理エージェントを、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)にアップグレードすることはできません。12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)および12cリリース4 (12.1.0.4)の管理エージェントは、12cリリース5 (12.1.0.5)にのみアップグレードできます。

- 特定のグループに含まれる管理エージェントをアップグレード用に選択する場合、グループの別の管理エージェントはデフォルトでアップグレード用に選択されません。グループの別の管理エージェントをアップグレードする場合は、「アップグレード可能なエージェント」ウィンドウで選択する必要があります。

4. (オプション) アップグレード前スクリプトおよびアップグレード後スクリプトに、アップグレード前および後に実行するスクリプトの絶対パスをそれぞれ入力します。
たとえば、/scratch/software/oracle/configure.shなどです。

実行するスクリプトは、Oracle Management Service (OMS)ホスト(複数OMS環境では、すべてのOMSホスト)またはアップグレード用に選択したすべての管理エージェント・ホストの指定した場所に存在する必要があります。これらのスクリプトは、アップグレード用に選択した管理エージェント・ホストからアクセスできる、NFSマウントされた共有の場所に配置できます。

実行するスクリプトがOMSホストのみに存在し、アップグレード用に選択した管理エージェント・ホストには存在しない場合、OMSホストのスクリプトを選択します。

注意:

- セッションごとに、アップグレード前スクリプトを1つのみ、アップグレード後スクリプトを1つのみ指定できます。

- シェル・スクリプト(.sh)とバッチ・スクリプト(.bat)がサポートされています。UNIXプラットフォームにインストールされている管理エージェントをアップグレードする際はシェル・スクリプトのみを実行し、Microsoft Windowsプラットフォームにインストールされている管理エージェントをアップグレードする際はバッチ・スクリプトのみを実行してください。

- UNIXプラットフォームにインストールされている管理エージェントと、Microsoft Windowsプラットフォームにインストールされている管理エージェントを同じセッションでアップグレードする場合は、アップグレード前またはアップグレード後のスクリプトを指定しないようにしてください。これらの管理エージェントのアップグレードにアップグレード前またはアップグレード後のスクリプトを指定する場合、別のセッションの別のプラットフォームにインストールされている管理エージェントをアップグレードします。

5. (オプション)「追加パラメータ」で、アップグレードに使用する追加オプションを入力します。
たとえば、前提条件チェックの実行をスキップして、管理エージェントのアップグレードを直接実行するには、-ignorePrereqsを指定します。追加パラメータを複数指定する場合は、パラメータを空白で区切ります。

指定できるパラメータのリストは、第6.4.2項を参照してください。

6. 「ステージングの場所」で、デフォルトのステージングの場所をそのまま使用するか、カスタムの場所を入力します。
たとえば、/tmp/software/oracle/EMStageなどです。

管理エージェントのインストール・ユーザーに、入力するカスタムの場所への書込み権限があるようにします。入力するカスタムの場所は、共有の、NFSマウントされた場所でもかまいません。

注意:
管理エージェントのホスト・ユーザーに、カスタムの場所への書込み権限があるようにします。

ステージングの場所は、管理エージェントの一時アップグレード・ファイルを保存するために使用します。

7. 「送信」をクリックします。
「発行」をクリックすると、管理エージェントのアップグレード・ジョブが作成され、Enterprise Managerジョブ・システムに送信されます。そのジョブの「エージェントのアップグレード・ステータス」ページに自動的に移動し、そのページにジョブ手順の詳細が表示されます。

発行済のすべての管理エージェントのアップグレード・ジョブの概要を表示する、または特定の一連の管理エージェントのアップグレード・ジョブを検索して表示するには、エージェント・アップグレード・コンソールの「エージェントのアップグレード結果」ページを使用します。このページにアクセスするには、「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェントのアップグレード」を選択します。エージェント・アップグレード結果をクリックします。

管理エージェントのアップグレード・ジョブの「エージェントのアップグレード・ステータス」ページに戻るには、「エージェントのアップグレード結果」ページでジョブの名前をクリックします。

管理エージェントのアップグレード・プロセス中にエラーが発生する場合や、管理エージェントのアップグレードに失敗する場合は、第6.6項を参照してください。

8. root.shステップを省略したり、この手順が失敗する場合は、管理エージェント・ホストにrootユーザーとしてログインし、$<AGENT_BASE_DIR>/core/12.1.0.5.0/に移動して、ホスト上でroot.shスクリプトを手動で実行します。
root.shの実行後、第6.4.4項に記載されているとおり、古い管理エージェントをクリーンアップできます。

6.4.1.2 EM CLIを使用した12c管理エージェントのアップグレード

EM CLIを使用して、12.1.0.xの管理エージェントをアップグレードするには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

たとえば、/scratch/aime/Oracle/MW/oms/bin/emcli login -username=sysmanです。

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. アップグレード可能な管理エージェントのリストを取得するために、get_upgradable_agents verbを実行します。

$<OMS_HOME>/bin/emcli get_upgradable_agents
[-agents]
[-platforms]
[-versions]
[-groups]
[-output_file]

[ ]内のパラメータはオプションであることに注意してください。

たとえば、$<OMS_HOME>/bin/emcli get_upgradable_agents -agents="abc%,xyz.domain.com:1243" -platforms="Linux x86,Microsoft Windows x64 (64-bit)" -versions="12.1.0.4.0" -output_file="/scratch/agents_file.txt"とします。

-output_fileオプションを使用してアップグレード可能な管理エージェントのリストをファイルにコピーします。このファイルは、upgrade_agents verbの入力パラメータとして後で使用できます。

get_upgradable_agents verbの構文および使用方法の詳細を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli/help get_upgradable_agents

4. upgrade_agents verbを実行して、管理エージェントをアップグレードします。

$<OMS_HOME>/bin/emcli upgrade_agents
-agents | -input_file="agents_file:<absolute_location>" | -input_file="response_file:<absolute_location>"
[-validate_only]
[-pre_script_loc]
[-pre_script_on_oms]
[-post_script_loc]
[-post_script_on_oms]
[-job_name]
[-override_credential]
[-additional_parameters]
[-stage_location]

[ ]内のパラメータはオプションであることに注意してください。

-agentsまたは-input_file="agents_file:<file_name>"のいずれかを使用するか、レスポンス・ファイルにagentsを指定してから-input_file="response_file:<absolute_location>"を使用することによって、アップグレードするすべての管理エージェントを指定していることを確認します。

たとえば、$<OMS_HOME>/bin/emcli upgrade_agents -agents="abc%,xyz.domain.com:1243" -input_file="agents_file:/scratch/agents_file.txt" -input_file="response_file:/scratch/agent.rsp" -stage_location=/tmpとします。

-input_file="agents_file:<absolute_location>"オプションを使用して、アップグレードする管理エージェントのリストが含まれているファイルを指定します。-input_file="response_file:<absolute_location>"オプションを使用して、使用するすべてのアップグレード・パラメータが含まれているレスポンス・ファイルを指定します。レスポンス・ファイルには、次に示すとおり、パラメータが名前と値のペアで含まれています。

job_name=UPGRADE_AGENT
additional_parameters="-ignorePrereqs START_PRIORITY_LEVEL=98"

verbを使用して指定するパラメータは、レスポンス・ファイルで指定されているパラメータをオーバーライドします。

upgrade_agents verbの構文および使用方法の詳細を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli help upgrade_agents

管理エージェントのアップグレード・プロセス中にエラーが発生する場合や、管理エージェントのアップグレードに失敗する場合は、第6.6項を参照してください。

5. 発行済の管理エージェントのアップグレード・ジョブのステータスを表示するには、get_agent_upgrade_status verbを実行します。

$<OMS_HOME>/bin emcli get_agent_upgrade_status
[-agent]
[-job_name]
[-status]

[ ]内のパラメータはオプションであることに注意してください。

たとえば、$<OMS_HOME>/bin/emcli get_agent_upgrade_status -status="Running"では、進行中の管理エージェントのアップグレード・ジョブがすべて表示されます。

特定のアップグレード・ジョブの一部である特定の管理エージェントの詳細なジョブ手順のステータスは、get_agent_upgrade_status verbに-agentオプションのおよび-job_nameオプションを使用することで表示できます。

たとえば、$<OMS_HOME>/bin/emcli get_agent_upgrade_status -agent=abc.example.com:1243 -job_name=UPGRADE_AGT_13603とします。

特定の管理エージェントのアップグレード・ジョブが失敗した場合は、入力を確認して、upgrade_agents verbを再度実行します。verbの再試行時にカスタムのジョブ名を指定する(-job_nameパラメータを使用して)場合は、失敗したジョブの名前ではなく、一意のジョブ名を指定してください。管理エージェントのアップグレードのトラブルシューティングのヒントについては、第6.6項を参照してください。

get_agent_upgrade_status verbの構文および使用方法の詳細を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli/help get_agent_upgrade_status

6. root.shステップを省略したり、この手順が失敗する場合は、管理エージェント・ホストにrootユーザーとしてログインし、$<AGENT_BASE_DIR>/core/12.1.0.5.0/に移動して、ホスト上でroot.shスクリプトを手動で実行します。
root.shの実行後、第6.4.4項に記載されているとおり、古い管理エージェントをクリーンアップできます。

注意:
この項で説明したEM CLI verbの使用方法の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。

6.4.2 12c管理エージェントのアップグレード用の追加パラメータ

表6-1に、エージェント・アップグレード・コンソールまたはEM CLIを使用した12c管理エージェントのアップグレード中に使用できる追加パラメータを示します。空白をセパレータとして使用して、複数のパラメータを入力できます。

表6-1 12c管理エージェントのアップグレード用の追加パラメータのリスト

パラメータ

説明

-ignorePrereqs

前提条件チェックの実行をスキップします。

すでに前提条件を確認しており、アップグレードの残りのプロセスを実行するだけの場合は、このパラメータを指定します。

-debug

デバッグとエラーの解決に役立つデバッグ・メッセージをログに記録します。

START_PRIORITY_LEVEL

(Unixベースのホストのみ)

このパラメータを使用して、ホストの開始時の管理エージェント・サービスの優先度レベルを指定します。このパラメータは0から99の間の値を受け入れます。ただし、このパラメータには91から99の間の値を指定することをお薦めします。

たとえば、START_PRIORITY_LEVEL=95とします。

このパラメータを指定しない場合、デフォルトで98が設定されます。

重要: アップグレードするように選択した管理エージェントのインストール中にこのパラメータの値を指定した場合は、この管理エージェントのアップグレード時に同じ値を指定してください。

SHUT_PRIORITY_LEVEL

(Unixベースのホストのみ)

このパラメータを使用して、ホストの停止時の管理エージェント・サービスの優先度レベルを指定します。このパラメータは、0から99の間の値を受け入れます。

たとえば、SHUT_PRIORITY_LEVEL=25とします。

このパラメータを指定しない場合、デフォルトで19が設定されます。

重要: アップグレードするように選択した管理エージェントのインストール中にこのパラメータの値を指定した場合は、この管理エージェントのアップグレード時に同じ値を指定してください。

6.4.3 アップグレードできない12c管理エージェントの表示

エージェント・アップグレード・コンソールまたはEM CLIを使用して、特定の12c管理エージェントをアップグレードできないことがあります。表6-2にこの理由を示します。

表6-2 Oracle Management Agentをアップグレードできない理由

理由

説明および推奨アクション

最新のエージェント・ソフトウェアが存在しない

OMSバージョンの最新の管理エージェント・ソフトウェアがOracle Software Libraryで使用できません。

最新の管理エージェント・ソフトウェアが使用できない管理エージェントをアップグレードするには、まず自己更新コンソールを使用して最新のソフトウェアをダウンロードして適用してから、「エージェントのアップグレード」ページを使用する必要があります。

自己更新コンソールにアクセスするには、「設定」メニューから、「拡張性」を選択し、「自己更新」を選択します。最新の管理エージェントのソフトウェアをダウンロードするには、「エージェント・ソフトウェア」をクリックし、必要なソフトウェアを選択してから「ダウンロード」をクリックします。最新の管理エージェント・ソフトウェアをダウンロードおよび適用するための自己更新コンソールの使用方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

非セキュアなエージェント

管理エージェントがセキュアではありません。

セキュアではない管理エージェントをアップグレードするには、まず管理エージェントを保護してから、エージェントのアップグレード・ページを使用する必要があります。

管理エージェントを保護するには、「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。目的の管理エージェント名をクリックします。「エージェント」メニューから、「セキュア」をクリックします。

次のコマンドを実行して、管理エージェントを保護することもできます。

<EMSTATE>/bin/emctl secure agent

<EMSTATE>は、管理エージェントのインスタンス・ディレクトリである<AGENT_BASE_DIRECTORY>/agent_instです。

Oracleホームのプロパティがありません

管理エージェントのOracleホーム・プロパティが見つかりません。

このプロパティは、アップグレードする管理エージェントのプラットフォームの取得に必要です。共有エージェントのアップグレードでは、このプロパティは、共有エージェントとマスター・エージェント間の関係を維持するための重要な役割を果たします。さらに、パッチ適用などの不可欠な特定の管理エージェントのライフサイクル操作にも必要です。

Oracleホーム・プロパティが存在しない管理エージェントをアップグレードするには、最初に、管理エージェント上でOMSコレクションを実行します。管理エージェント上でOMSコレクションを実行するには、管理エージェントのホストから次のコマンドを実行します。

<EMSTATE>/bin/emctl control agent runCollection <TARGET_NAME>:oracle_home oracle_home_config

<EMSTATE>は、管理エージェントのインスタンス・ディレクトリである<AGENT_BASE_DIRECTORY>/agent_instです。

<TARGET_NAME>は、<EMSTATE>/sysman/emd/targets.xmlにあるターゲット・タイプoracle_homeの管理エージェント・ターゲットです。

エージェント使用不可

管理エージェントが使用できない、つまり、Oracle Management Service (OMS)が管理エージェントと通信できません。

管理エージェントが停止している場合、管理エージェントがOMSによってブロックされた場合、または管理エージェント・ホストが停止している場合は、一般的に管理エージェントは使用できません。ネットワークやその他の特定の問題が原因で、管理エージェントが使用できない可能性もあります。

使用できない管理エージェントをアップグレードするには、最初に、OMSと管理エージェント間の通信をリストアする必要があります。OMSと管理エージェント間の通信をリストアするには、「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。目的の管理エージェント名をクリックして、管理エージェント・ホームページに移動します。表示されたエラー・アイコンをクリックし、推奨アクションを実行します。

アクティブ化を保留中のエージェント

管理エージェントのリリースが12cリリース2 (12.1.0.2)以降ではありません。

エージェントのアップグレード・ページを使用して、10g、11gまたは12cリリース1 (12.1.0.1)の管理エージェントをアップグレードできません。これらの管理エージェントをアンインストールし、ホストに新規管理エージェントをインストールします。

管理エージェントのアンインストールの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。新規管理エージェントのインストールの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

アップグレードできないエージェント・ページを使用して、現在アップグレードできない一連の管理エージェントを検索および表示できます。これらの管理エージェントを検索および表示するには、次の手順に従います。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェントのアップグレード」を選択します。

2. アップグレードできないエージェントをクリックします。

3. 管理エージェントの検索に使用するパラメータの値を入力または選択します。管理エージェント名、バージョン、プラットフォームおよび管理エージェントをアップグレードできない理由を使用して、管理エージェントを検索できます。

4. 「一致」で「すべて」または「いずれか」を選択して、すべての検索パラメータと一致する結果またはいずれかの検索パラメータと一致する結果を検索します。

5. 「検索」をクリックします。

6.4.4 古い管理エージェントのアップグレード後クリーンアップの実行

12.1.0.xの管理エージェントをアップグレードすると、古いエージェント・ホーム、古いOracleホーム・ターゲットおよび古い管理エージェントのバックアップ・ディレクトリは残り、自動的に削除されません。アップグレード後のこれらのものを削除してディスク領域を解放するために、エージェント・アップグレード・コンソールまたはEM CLIを使用して、古い管理エージェントをクリーンアップできます。

重要:
正常にアップグレードされた管理エージェントに対してのみクリーンアップを実行してください。管理エージェントのアップグレードが成功したかどうかの確認については、第6.5.1項を参照してください。

この項では、アップグレード後に12.1.0.xの管理エージェントをクリーンアップするために使用できる方法について説明します。内容は次のとおりです。

- エージェント・アップグレード・コンソールを使用した古い管理エージェントのアップグレード後クリーンアップの実行

- EM CLIを使用した古い管理エージェントのアップグレード後クリーンアップの実行

6.4.4.1 エージェント・アップグレード・コンソールを使用した古い管理エージェントのアップグレード後クリーンアップの実行

エージェント・アップグレード・コンソールの「エージェントのクリーンアップ」ページを使用して、古い管理エージェントの古いディレクトリをクリーンアップするには、次の手順に従います。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェントのアップグレード」を選択します。

2. 「エージェントのアップグレード後のタスク」をクリックします。

3. デフォルトのクリーンアップ・ジョブ名を変更するには、「ジョブ名」に一意の名前を入力します。
一意のジョブ名により、クリーンアップ・ジョブを識別して、その実行の詳細を参照し、進行を追跡できます。

ジョブ名は、最大長が64文字です。英数字および特殊文字を含めることができ、そのどちらからでも始めることができます。

4. 「追加」をクリックして、クリーンアップ対象の管理エージェントを追加します。

5. クリーンアップ対象のエージェントウィンドウで、「エージェント」、「プラットフォーム」、「インストールされたバージョン」および「グループ」のフィールドを使用して、クリーンアップ対象の管理エージェントを検索します。

6. クリーンアップする管理エージェントを選択します。「OK」をクリックします。

7. 「送信」をクリックします。

6.4.4.2 EM CLIを使用した古い管理エージェントのアップグレード後クリーンアップの実行

EM CLIを使用して、古い管理エージェントの古いディレクトリをクリーンアップするには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

たとえば、/scratch/aime/Oracle/MW/oms/bin/emcli login -username=sysmanです。

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. クリーンアップを実行可能な管理エージェントのリストを取得するために、get_signoff_agents verbを実行します。

$<OMS_HOME>/bin/emcli get_signoff_agents
[-agents]
[-platforms]
[-versions]
[-groups]
[-output_file]

[ ]内のパラメータはオプションであることに注意してください。

たとえば、$<OMS_HOME>/bin/emcli get_signoff_agents -output_file="/scratch/signoff_agents_file.txt"とします。

-output_fileオプションを使用して、get_signoff_agents verbの出力をファイルにコピーし、このファイルは、signoff_agents verbの入力パラメータとして後で使用できます。

get_signoff_agents verbの構文および使用方法の詳細を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli help get_signoff_agents

4. signoff_agents verbを実行して、管理エージェントをクリーンアップします。

$<OMS_HOME>/bin/emcli/signoff_agents
-agents | -input_file="agents_file:<absolute_location>" | -input_file="response_file:<absolute_location>"
[-job_name]

[ ]内のパラメータはオプションであることに注意してください。

-agentsまたは-input_file="agents_file:<file_name>"のいずれかを使用するか、レスポンス・ファイルにagentsを指定してから-input_file="response_file:<absolute_location>"を使用することによって、クリーンアップするすべての管理エージェントを指定していることを確認します。

たとえば、$<OMS_HOME>/bin/emcli signoff_agents -agents="abc%,xyz.domain.com:1243" -input_file="agents_file:/scratch/signoff_agents_file.txt" -input_file="response_file:/scratch/agent.rsp" -job_name=CLEAN_UP_12103とします。

-input_file="agents_file:<absolute_location>"オプションを使用して、クリーンアップする管理エージェントのリストが含まれているファイルを指定します。-input_file="response_file:<absolute_location>"オプションを使用して、使用するすべてのパラメータが含まれているレスポンス・ファイルを指定します。レスポンス・ファイルには、次に示すとおり、パラメータが名前と値のペアで含まれています。

agents=abc%,xyz%
job_name=CLEAN_UP_AGT_121050

verbを使用して指定するパラメータは、レスポンス・ファイルで指定されているパラメータをオーバーライドします。

signoff_agents verbの構文および使用方法の詳細を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli help signoff_agents

注意:
この項で説明したEM CLI verbの使用方法の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。

6.4.5 12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

古いエージェント・ホーム、古いOracleホーム・ターゲットおよび古い管理エージェントのバックアップ・ディレクトリをアップグレード後に削除するには、「エージェントのクリーンアップ」ページまたはEM CLIを使用します。クリーンアップする管理エージェントを選択し、「エージェントのクリーンアップ」ページで「送信」をクリックするか、signoff_agents EM CLI verbを実行すると、管理エージェントのクリーンアップ・ジョブが作成され、Enterprise Managerジョブ・システムに送信されます。「エージェントのクリーンアップ結果」ページまたはget_signoff_status EM CLI verbを使用して、特定の一連の管理エージェントのクリーンアップ・ジョブを検索および表示できます。

この項では、特定の一連の管理エージェントのクリーンアップ・ジョブを表示するために使用できる方法について説明します。内容は次のとおりです。

- エージェント・アップグレード・コンソールを使用した12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

- EM CLIを使用した12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

6.4.5.1 エージェント・アップグレード・コンソールを使用した12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

エージェント・アップグレード・コンソールの「エージェントのクリーンアップ結果」ページを使用して、特定の一連の管理エージェントのクリーンアップ・ジョブを表示するには、次の手順に従います。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェントのアップグレード」を選択します。

2. 「エージェントのアップグレード後のタスク」をクリックします。

3. エージェントのクリーンアップ結果をクリックします。

4. 管理エージェント・クリーンアップ・ジョブの検索に使用するパラメータの値を入力または選択します。ジョブ名、クリーンアップに含まれていた管理エージェント、およびジョブのステータスを使用して、これらのジョブを検索できます。

5. 「一致」で「すべて」または「いずれか」を選択して、すべての検索パラメータと一致する結果またはいずれかの検索パラメータと一致する結果を検索します。

6. 「検索」をクリックします。

6.4.5.2 EM CLIを使用した12c管理エージェントのアップグレードのクリーンアップ・ジョブの表示

EM CLIを使用して、特定の一連の管理エージェントのクリーンアップ・ジョブを表示するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

たとえば、/scratch/aime/Oracle/MW/oms/bin/emcli login -username=sysmanです。

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. get_signoff_status verbを実行して、特定の一連の管理エージェントのクリーンアップ・ジョブを表示します。

$<OMS_HOME>/bin/emcli get_signoff_status
[-agent]
[-job_name]
[-status]

[ ]内のパラメータはオプションであることに注意してください。

たとえば、$<OMS_HOME>/bin/emcli get_signoff_status -status="Success"では、成功した管理エージェントのクリーンアップ・ジョブを表示します。

get_signoff_status verbの構文および使用方法の詳細を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli help get_signoff_status

注意:
この項で説明したEM CLI verbの使用方法の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。

6.5 12c管理エージェントのアップグレード後

この項では、管理エージェントのアップグレード後に実行できる様々なタスクについて説明します。内容は次のとおりです。

- 12c管理エージェントのアップグレードの確認

- 中央エージェントのベース・ディレクトリのOracleミドルウェア・ホーム外への移動(12c中央エージェントのアップグレード後)

6.5.1 12c管理エージェントのアップグレードの確認

この項では12c管理エージェントのアップグレードを検証する方法を説明します。内容は次のとおりです。

- Enterprise Managerコンソールを使用した12c管理エージェントのアップグレードの確認

- EM CLIを使用した12c管理エージェントのアップグレードの確認

6.5.1.1 Enterprise Managerコンソールを使用した12c管理エージェントのアップグレードの確認

管理エージェントのアップグレード後、次の方法に従って、Enterprise Managerコンソールを使用してアップグレードを検証します。

- 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェントのアップグレード」を選択します。エージェント・アップグレード結果をクリックします。管理エージェントをアップグレードするために作成したジョブが成功したことを確認します。

- 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。アップグレードを検証する管理エージェントの名前をクリックして、管理エージェントのバージョンを確認します。アップグレード後の管理エージェントのバージョンは、OMSバージョンと同じである必要があります。
また、「エージェント」ページで、管理エージェントが、ブロックされていたり、ブラックアウト中ではなく、稼働中であることを確認します。

- 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。アップグレードを検証する管理エージェントの名前をクリックします。「エージェント」メニューから、「構成」、「最新収集」の順に選択します。「構成プロパティ」タブで、古い管理エージェント・ホームを表示している構成プロパティがないことを確認します。

6.5.1.2 EM CLIを使用した12c管理エージェントのアップグレードの確認

管理エージェントのアップグレード後、次の方法に従って、EM CLIを使用してアップグレードを検証します。

- get_agent_upgrade_status verbを実行して、管理エージェントをアップグレードするために作成したジョブが成功したことを確認します。確認する方法の詳細は、第6.4.1.2項の手順5を参照してください。

- get_agent_properties verbを実行して、アップグレード後の管理エージェントのバージョンおよびその構成プロパティを確認します。

$<OMS_HOME>/bin/emcli get_agent_properties -format=csv -agent_name=<agent_host_name>:<agent_port>

たとえば、$<OMS_HOME>/bin/emcli get_agent_properties -format=csv -agent_name=abc.example.com:1872とします。

- get_targets verbを実行して、管理エージェントの状態を確認します(ブロックされていたり、ブラックアウト中ではなく、稼働中であることなど)。

$<OMS_HOME>/bin/emcli get_targets -format="name:csv" -targets=<agent_host_name>:<agent_port>:oracle_emd -alerts

たとえば、$<OMS_HOME>/bin/emcli get_targets -format="name:csv" -targets=abc.example.com:3872:oracle_emd -alertsとします。

6.5.2 中央エージェントのベース・ディレクトリのOracleミドルウェア・ホーム外への移動(12c中央エージェントのアップグレード後)

中央エージェントのアップグレード後に、アップグレードされた中央エージェントのエージェント・ベース・ディレクトリがOracleミドルウェア・ホームに存在し、これをOracleミドルウェア・ホーム外に移動する場合は、付録Gを参照してください。

重要:

- エージェント・ベース・ディレクトリの移動は、中央エージェントにのみ推奨されます。他の管理エージェントには推奨されません。

- エージェント・ベース・ディレクトリの移動は、Microsoft Windowsで実行されているホストではサポートされていません。

6.6 12c管理エージェントのアップグレードのトラブルシューティング

表6-3に、管理エージェントのアップグレード中に発生する可能性のある特定のエラーのトラブルシューティング方法について説明します。

表6-3 Oracle Management Agentのアップグレードのトラブルシューティング

問題

トラブルシューティングのヒント

「エージェントのアップグレード」ページで「送信」をクリックすると、管理エージェントのOracleホームの特権優先資格証明が設定されていないため、管理エージェントに対してroot.shを実行できなかったという内容のエラーが発生する。

次のいずれかの操作を実行します。

- アップグレードを継続するには、「OK」をクリックします。アップグレード後、rootユーザーとして管理エージェント・ホストにログインして、$<AGENT_BASE_DIR>/core/12.1.0.5.0/root.shスクリプトをホスト上で実行します。

- 「取消」をクリックしてアップグレードを取り消し、次の手順を実行します。

1. 管理エージェントのOracleホーム・ターゲットの優先資格証明を設定します。
この方法は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

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

管理エージェントのOracleホーム・ターゲットに特権優先資格証明を設定しない場合は、エラー・メッセージが表示されたら、「取消」をクリックして、次の手順を実行します。

1. 「優先資格証明のオーバーライド」を選択し、表示されたアイコンをクリックして新しい資格証明を作成します。作成する資格証明がroot資格証明ではない場合、「実行権限」に「sudo」または「PowerBroker」を選択し、「別名実行」にrootと入力します。

2. 管理エージェント・ホストで権限委任設定を構成します。

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

アップグレード後、root.shジョブ手順が失敗する場合は、管理エージェント・ホストにrootユーザーとしてログインし、$<AGENT_BASE_DIR>/core/12.1.0.5.0/root.shスクリプトを手動で実行します。

「エージェントのアップグレード」ページで「送信」をクリックすると、管理エージェント・ホストの権限委任設定が設定されていないため、管理エージェントに対してroot.shを実行できなかったという内容のエラーが発生する。

次のいずれかの操作を実行します。

- エラー・メッセージが表示された場合は、「OK」をクリックしてアップグレードを続行します。アップグレード後、rootユーザーとして管理エージェント・ホストにログインして、$<AGENT_BASE_DIR>/core/12.1.0.5.0/root.shスクリプトをホスト上で実行します。

- エラー・メッセージが表示された場合は、「取消」をクリックしてアップグレードを取り消し、次の手順を実行します。

1. 管理エージェント・ホストで権限委任設定を構成します。
これを行う方法の詳細は、Oracle Enterprise Managerライフサイクル管理者ガイドを参照してください。

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

アップグレード後、root.shジョブ手順が失敗する場合は、管理エージェント・ホストにrootユーザーとしてログインし、$<AGENT_BASE_DIR>/core/12.1.0.5.0/root.shスクリプトを手動で実行します。

「エージェントのアップグレード」ページで「送信」をクリックすると、管理エージェントのOracleホームの特権優先資格証明にrootとして実行が設定されていないため、管理エージェントに対してroot.shを実行できなかったという内容のエラーが発生する。

次のいずれかの操作を実行します。

- アップグレードを継続するには、「OK」をクリックします。アップグレード後、rootユーザーとして管理エージェント・ホストにログインして、$<AGENT_BASE_DIR>/core/12.1.0.5.0/root.shスクリプトをホスト上で実行します。

- 「取消」をクリックしてアップグレードを取り消し、次の手順を実行します。

1. 資格証明がroot権限を持つように、管理エージェントのOracleホーム・ターゲットの特権優先資格証明を編集します。これを行う方法の詳細は、Oracle Enterprise Managerライフサイクル管理者ガイドを参照してください。

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

アップグレード後、root.shジョブ手順が失敗する場合は、管理エージェント・ホストにrootユーザーとしてログインし、$<AGENT_BASE_DIR>/core/12.1.0.5.0/root.shスクリプトを手動で実行します。

「エージェントのアップグレード」ページで「送信」をクリックすると、エージェントのアップグレード手順が失敗する。

次の手順に従って問題を診断します。

1. 失敗した管理エージェントのアップグレード・ジョブ手順の出力ログを参照します。
エージェントのアップグレード・ページで管理エージェントのアップグレード・ジョブ手順の出力ログを参照するには、「エージェントのアップグレード結果」をクリックします。管理エージェントのアップグレード・ジョブの名前をクリックし、目的の管理エージェントを選択します。失敗したジョブ手順の名前をクリックします。

2. 次の場所で利用できる管理エージェントのデプロイメント・ログを参照します。

$<AGENT_BASE_DIRECTORY>/core/12.1.0.5.0/cfgtoollogs/agentDeploy/agentDeploy_<TIMESTAMP>.log

3. 次の場所で利用できるプラグイン・アップグレードの構成ログを参照します。

$<AGENT_BASE_DIRECTORY>/backup_agtup/backup_<TIMESTAMP>/agtNew/install/logs/agentplugindeploy_<TIMESTAMP>.log

ホスト・プラットフォーム用の32ビット管理エージェント・ソフトウェアがソフトウェア・ライブラリに存在しないために、管理エージェントをアップグレードできませんでした。

Oracle Enterprise Linux 4.x、Red Hat Enterprise Linux 4.x、およびSUSE Linux Enterprise 10 64ビットの各プラットフォームで実行される管理エージェントをアップグレードする際に、このエラーが発生する可能性があります。このエラーが発生した場合、「OK」をクリックします。「自己更新」コンソールを使用して、これらのプラットフォーム用の最新の32ビット管理エージェント・ソフトウェアをダウンロードして適用してから、管理エージェントをアップグレードします。

最新の管理エージェント・ソフトウェアをダウンロードおよび適用するための自己更新コンソールの使用方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

「エージェントのアップグレード・ステータス」ページまたは「エージェントのアップグレード結果」ページのリンクが機能しない。

次のログを表示することで問題を診断します。

- $<OMS_INSTANCE_HOME>/user_projects/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/*.out

- $<OMS_INSTANCE_HOME>/user_projects/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/*.log

管理エージェントのアップグレード・プロセスのジョブ手順がハングするか、複数回実行される。

次のログを表示することで問題を診断します。

$<OMS_INSTANCE_HOME>/em/EMGC_OMS1/sysman/log/*.trc

EM CLIログインまたは同期が失敗する。

次のログを表示することで問題を診断します。

$<NEW_AGENT_ORACLE_HOME>/EMGC_OMS1/sysman/emcli/setup/.emcli/*.log

アップグレード後の管理エージェントはブロックされています。

Oracle Support Serviceにリクエストを送信してください。管理エージェントの再同期化は行わないでください。

7 JVMDのアップグレードまたは再デプロイ

この章では、Java仮想マシン診断(JVMD)のアップグレードまたは再デプロイ方法について説明します。内容は次のとおりです。

- JVMDのアップグレード推奨事項について

- JVMDのアップグレード・ワークフローについて

- JVMDエンジンのアップグレードまたは再デプロイ

- JVMDエージェントのアップグレードまたは再デプロイ

- JVMDのアップグレードまたは再デプロイの検証

注意:
基本および拡張オプションによるJVMDエンジンおよびJVMDエージェントのデプロイの詳細は、
次のガイドを参照してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』

- 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

7.1 JVMDのアップグレード推奨事項について

最新のJVMD機能を取得し、それらを使用して企業内にデプロイされたJVMをモニターするために、JVMDのエンジンおよびエージェントを最新の使用可能なバージョンにアップグレードすることをお薦めします。Oracle Fusion Middlewareプラグイン用のEnterprise Managerをバージョン12.1.0.6にアップグレードする場合、デプロイ済JVMDエンジンは自動でアップグレードされません。この章で説明されている方式を使用してアップグレードする必要があります。

JVMDエージェントのバージョンがJVMDエンジン(レポート先)のバージョン以下である構成であればすべてサポートされます。たとえば、あるJVMDエンジンのバージョンが12.1.0.6の場合、JVMDエージェントのバージョンが12.1.0.6以下であれば、このJVMDエンジンにレポートすることが可能です。ただし、企業内のJVMDエージェントをバージョン12.1.0.6以上にアップグレードすることをお薦めします。

JVMDエンジンをアップグレードする場合、OMSホストにデプロイされているJVMDエンジンのアップグレードのみが可能であり、リモート・ホストにデプロイされているJVMDエンジンはアップグレードできません。リモート・ホストで最新バージョンのJVMDエンジンを取得するには、既存のバージョンを削除してから最新バージョンの新しいJVMDエンジンをデプロイします。

7.2JVMDのアップグレード・ワークフローについて

企業内にデプロイされたJVMDアプリケーションをアップグレードするには、次のプロセスを実行します。

1. JVMDエンジンをすべて手動で停止します。
JVMDエンジンを手動で停止するには、「設定」メニューから「ミドルウェア管理」、「アプリケーション・パフォーマンス管理」の順に選択します。停止させるJVMDエンジンの名前をクリックします。JVMDエンジンのターゲット・ホーム・ページで、「停止」をクリックします。

2. JVMDエンジンを最新バージョンにアップグレードします。
JVMDエンジンのアップグレード方法の詳細は、第7.3.1項を参照してください。

3. JVMDエージェントを最新バージョンにアップグレードします。
JVMDエージェントのアップグレード方法の詳細は、第7.4項を参照してください。

7.3 JVMDエンジンのアップグレードまたは再デプロイ

この項では、JVMDエンジンをアップグレードまたは再デプロイする方法について説明します。内容は次のとおりです。

- JVMDエンジンのアップグレード

- JVMDエンジンの再デプロイ

7.3.1 JVMDエンジンのアップグレード

この項では、JVMDエンジンをアップグレードする方法について説明します。内容は次のとおりです。

- 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエンジンのアップグレード

- ApmEngineSetup.plを使用したJVMDエンジンの手動でのアップグレード

7.3.1.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエンジンのアップグレード

「アプリケーション・パフォーマンス管理」ページを使用して、管理対象サーバー上にデプロイされているJVMDエンジンをアップグレードするには、次の手順に従います。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページで、「JVM診断エンジン」の横に表示されているアップグレード・アイコンをクリックします。

注意:
アップグレード・アイコンは、現在デプロイされているJVMDエンジン・ソフトウェアのバージョンと異なるソフトウェア・バージョンが使用可能である場合にのみ表示されます。

3. JVMDエンジンのアップグレード・ページで、アップグレードするJVMDエンジンを選択します。

4. 「ホスト資格証明」の値を指定します。これらの資格証明は、選択したJVMDエンジンがデプロイされているホストのホスト資格証明です。「適用」をクリックします。「適用」ボタンは「ホスト資格証明」セクションの右上にあります。表示するために、右にスクロールすることが必要な場合があります。

5. 「JVMDエンジンのアップグレード」ページで、アップグレードするJVMDエンジンをすべて選択し、そのそれぞれに対して「ホスト資格証明」の値を指定して適用します。

6. 「管理Weblogic資格証明」の値を指定します。これらの資格証明は、Enterprise Manager WebLogicドメインの管理サーバーの資格証明です。

7. 「アップグレード」をクリックします。
アップグレード時にエラーが発生した場合は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーション・ガイド』を参照してください。

7.3.1.2 ApmEngineSetup.plを使用したJVMDエンジンの手動でのアップグレード

ApmEngineSetup.plスクリプトを使用して、JVMDエンジンを手動でアップグレードできます。このスクリプトは次の方法で実行できます。

- インタラクティブ・モード: 対話式方法で入力の詳細の入力が求められます。

- サイレント・モード: プロパティ・ファイルを使用して入力の詳細のすべてを指定します。

ApmEngineSetup.plスクリプトを使用してJVMDエンジンを手動でアップグレードするには、次の手順に従います。

1. OMSホストの次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/deployment_scripts/engine/

2. README.txtファイルでApmEngineSetup.plスクリプトの使用についての情報を確認します。

3. ApmEngineSetup.plスクリプトを実行します。
ApmEngineSetup.plスクリプトをインタラクティブ・モードで実行する(入力の詳細を求められる)場合、次のコマンドを使用します。

perl ApmEngineSetup.pl

操作をupgradeとして、エンジン・タイプにJVMDを指定してください。

ApmEngineSetup.plスクリプトをサイレント・モードで実行する場合は、すべての入力の詳細をプロパティ・ファイルで指定してから、次のコマンドを使用します。

perl ApmEngineSetup.pl -silent -file <properties_file_name> -password <password>

<properties_file_name>は、JVMDエンジンおよび操作の詳細が指定されているプロパティ・ファイルの名前です。<password>WebLogicコンソール・パスワードです。

プロパティ・ファイルでの入力の詳細の指定方法を確認するには、サンプルのプロパティ・ファイルSAMPLE_engine.propertiesを表示します。

7.3.2 JVMDエンジンの再デプロイ

注意:
JVMDエンジンの再デプロイ・プロセスは、「アプリケーション・パフォーマンス管理」ページの「JVM診断エンジン」の横にアップグレード・アイコンが表示されないことを除けば、JVMDエンジンのアップグレード・プロセスとまったく同じです。再デプロイするJVMDエンジンを選択してから、「再デプロイ」をクリックして「JVMDエンジンの再デプロイ」ページにアクセスする必要があります。

管理対象サーバー上にデプロイされているJVMDエンジンを再デプロイするには、次の手順に従います。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページで単一のJVMDエンジンを再デプロイする場合、再デプロイするJVMDエンジンを選択して、「再デプロイ」をクリックします。
アプリケーション・パフォーマンス管理ページで複数のJVMDエンジンを再デプロイする場合、「JVM診断エンジン」ノードを選択して、「再デプロイ」をクリックします。

3. JVMDエンジンの再デプロイ・ページに、再デプロイするJVMDエンジンを選択します。

4. 再デプロイに選択したJVMDエンジンごとに、「ホスト資格証明」の値を指定します。これらの資格証明は、選択したJVMDエンジンがデプロイされているホストのホスト資格証明です。「適用」をクリックします。「適用」ボタンは「ホスト資格証明」セクションの右上にあります。表示するために、右にスクロールすることが必要な場合があります。

5. 「管理Weblogic資格証明」の値を指定します。これらの資格証明は、Enterprise Manager WebLogicドメインの管理サーバーの資格証明です。

6. 「再デプロイ」をクリックします。
再デプロイメント時にエラーが発生した場合は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

7.4 JVMDエージェントのアップグレードまたは再デプロイ

Cloud Controlには、単純なWebアプリケーション(.warファイル)であるJVMDエージェントのアップグレードおよび再デプロイを可能にするユーザー・インタフェースおよびPerlスクリプトが用意されています。このユーザー・インタフェースおよびPerlスクリプトにより、JVMDエージェントのアップグレードまたは再デプロイのプロセスを簡略化し、複数のJVMDエージェントを1回でアップグレードまたは再デプロイできるようになります。あるいは、WebLogic管理コンソールを使用して最新バージョンのJVMDエージェントをダウンロードしてデプロイすることもできます。

次のいずれかの方法を使用して、JVMDエージェントをアップグレードまたは再デプロイできます。

- 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエージェントのアップグレードまたは再デプロイ

- deploy_jvmdagent.plを使用したJVMDエージェントの手動でのアップグレードまたは再デプロイ

- WebLogic管理コンソールを使用したJVMDエージェントの手動でのアップグレードまたは再デプロイ

注意:
特定の管理対象サーバーにデプロイされているJVMDエージェントをアップグレードできるのは、使用可能なJVMDエージェント・バイナリのバージョンがデプロイされているJVMDエージェントのバージョンと異なる場合のみです。
たとえば、12.1.0.6のJVMDエージェントが管理対象サーバーにデプロイされ、12.1.0.8または別のバージョンのJVMDエージェント・バイナリが使用可能な場合、デプロイされている12.1.0.6のJVMDエージェントをアップグレードできます。しかし、バージョン12.1.0.6のJVMDエージェント・バイナリが唯一使用可能なバージョンであり、他のバージョンのバイナリは使用できない場合、管理対象サーバーにデプロイされている12.1.0.6のJVMDエージェントをアップグレードできません。

7.4.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエージェントのアップグレードまたは再デプロイ

「アプリケーション・パフォーマンス管理」ページを使用して、モニター対象のWebLogicドメインにあるJVMDエージェントをアップグレードまたは再デプロイするには、次の手順を実行します。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページの「アプリケーション・パフォーマンス管理エージェント」セクションで、「診断エージェントの管理」をクリックします。

3. 「操作」で、「アップグレード」を選択します。

注意:
または、この場所にアクセスするには、「アプリケーション・パフォーマンス管理」ページで「JVMDエージェント数」の横に表示されるアップグレード・アイコンをクリックします。このアイコンは、JVMDエージェント・ソフトウェアの現在のバージョンとは異なるソフトウェア・バージョンが使用可能である場合にのみ表示されます。

「表示」メニューから「すべてを開く」を選択した場合は、JVMDエージェントがデプロイされている管理対象サーバーすべてについて、ターゲット名、ターゲット・タイプ、ターゲット・ホスト、ターゲット・ステータス、プラットフォームなどを表示できます。

アップグレードまたは再デプロイするJVMDエージェントを選択します。「次へ」をクリックします。

4. 「ターゲットの資格証明」ページで、WebLogicドメインごとに「Oracle WebLogic管理サーバー・ホストの資格証明」および「Oracle WebLogicドメインの資格証明」の値を指定し、「適用」(表示するには右にスクロール)をクリックします。
Oracle WebLogic管理サーバー・ホストの資格証明は、選択したWebLogicドメインを監視している管理エージェントが実行されているホストのホスト資格証明です。Oracle WebLogicドメインの資格証明は、選択したWebLogicドメインの管理サーバーの資格証明です。

「次へ」をクリックします。

5. 「JVMDエージェント構成」ページで、WebLogicドメインごとに、前に選択したJVMDエンジンが自動的に適用されます。ただし、変更できます。そのためには、「使用可能なJVMDエンジン」から「JVMDエンジン」を選択して「適用」をクリックします。
選択したWebLogicドメインの管理対象サーバーにデプロイされているすべてのJVMDエージェントが、このJVMDエンジンに関連付けられます。または、複数のエンジンの場合、「その他」を選択してロード・バランサに接続できます。

「追加構成」セクションに「WebLogicホーム」および「ミドルウェア・ホーム」フィールドが表示されている場合、それらに値を指定します。「WebLogicホーム」および「ミドルウェア・ホーム」フィールドは、それらの値が内部的に取得できない場合に表示されます。

また、WebLogic管理サーバーがファイアウォール内または仮想ホスト上にある場合に、アプリケーションがデフォルトのホスト値を使用して接続できないことがあります。この場合は、追加情報を「追加構成」セクションに入力する必要がある場合があります。たとえば、WebLogic管理サーバーが仮想ホスト上にあり、アプリケーションがデフォルトのホスト値を使用して接続できない場合は、「追加構成」セクションにその仮想ホストのIPアドレスを入力する必要がある場合があります。

「次へ」をクリックします。

6. 確認ページですべての情報を確認し、「アップグレード」をクリックします。
「アップグレード」をクリックすると、「診断エージェントのデプロイメント・ステータス」ページが表示され、このページは、発行したジョブの進捗状況を監視するために使用できます。

アップグレード時または再デプロイメント時にエラーが発生した場合は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

7.4.2 deploy_jvmdagent.plを使用したJVMDエージェントの手動でのアップグレードまたは再デプロイ

deploy_jvmdagent.plスクリプトを使用して、JVMDエージェントを手動でアップグレードまたは再デプロイできます。このスクリプトをサイレント・モードでのみ実行できるため、プロパティ・ファイルを使用して入力の詳細のすべてを指定する必要があります。

deploy_jvmdagent.plを使用してJVMDエージェントを手動でアップグレードまたは再デプロイするには、次の手順に従います。

1. 最新バージョンのjavadiagnosticagent.earまたはjamagent.warがダウンロードされていることを確認します。
javadiagnosticagent.earまたはjamagent.warのダウンロード方法は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

2. OMSホストの次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/deployment_scripts/agent/jvmd/

3. deploy_jvmdagent.plスクリプトの使用方法について、README.txtファイルを表示します。

4. すべての入力をプロパティ・ファイルに指定してから、次のコマンドを使用します。
perl deploy_jvmdagent.pl [-appserver <server_type>] [-file <name_of_properties_file>]

例: perl deploy_jvmdagent.pl -appserver WLS -file wls_upgrade.properties.

deploy_jvmdagent.plでは、WebLogic ServerおよびGlassFishにデプロイされたJVMDエージェントのみをアップグレードまたは再デプロイできます。他のアプリケーション・サーバーにデプロイされたJVMDエージェントはアップグレードまたは再デプロイできません。-appserverパラメータは、(アップグレードまたは再デプロイしたい) JVMDエージェントがデプロイされているアプリケーション・サーバーを指定します。WebLogic管理対象サーバーにデプロイされているJVMDエージェントをアップグレードまたは再デプロイしている場合は、-appserverにWLSを指定します。GlassFishサーバーにデプロイされているJVMDエージェントをアップグレードまたは再デプロイしている場合は、-appserverにGFを指定します。-appserverパラメータを指定しない場合は、デフォルトで値WLSが割り当てられます。

-fileパラメータには、アップグレードまたはデプロイメント入力を含むプロパティ・ファイルの名前を指定します。このパラメータを指定せず-appserverにWLSを指定している場合、deploy_jvmdagent.plはスクリプトを含むフォルダ内でweblogic_deploy.propertiesという名前のプロパティ・ファイルを検索します。-fileパラメータを指定せず-appserverにGFを指定している場合、deploy_jvmdagent.plはスクリプトを含むフォルダ内でglassfish_deploy.propertiesという名前のプロパティ・ファイルを検索します。プロパティ・ファイルでの入力の詳細の指定方法を確認するには、サンプルのプロパティ・ファイルsample_weblogic_deploy.propertiesまたはsample_glassfish_deploy.propertiesを表示します。

7.4.3 WebLogic管理コンソールを使用したJVMDエージェントの手動でのアップグレードまたは再デプロイ

WebLogic管理コンソールを使用して必要なJVMDエージェントのバージョンを手動でダウンロードし、デプロイすることもできます。

7.5 JVMDのアップグレードまたは再デプロイの検証

JVMDエンジンまたはJVMDエージェントのアップグレードまたは再デプロイが終了したら、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の説明に従って、新しいバージョンのデプロイメントを検証します。

8 ADPのアップグレードまたは再デプロイ

この章では、アプリケーションの依存性とパフォーマンス(ADP)のアップグレードまたは再デプロイ方法について説明します。内容は次のとおりです。

- ADPのアップグレード推奨事項について

- ADPのアップグレード・ワークフローについて

- ADPエンジンのアップグレードまたは再デプロイ

- ADPエージェントのアップグレードまたは再デプロイ

- ADPのアップグレードまたは再デプロイ後の作業

注意:
基本および拡張オプションによるADPエンジンおよびADPエージェントのデプロイの詳細は、次のガイドを参照してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』

- 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

8.1 ADPのアップグレード推奨事項について

ADPエージェントのバージョンがADPエンジン(レポート先)のバージョン以下である構成であればすべてサポートされます。たとえば、あるADPエンジンのバージョンが12.1.0.8の場合、ADPエージェントのバージョンが12.1.0.8、12.1.0.7、12.1.0.6であれば、このADPエンジンにレポートすることが可能です。

ただし、企業内のADPエージェントをADPエージェントのバージョン・レベルか、このバージョン・レベルより1つ下のバージョンに保つことをお薦めします。たとえば、あるADPエンジンのバージョンが12.1.0.8の場合、このADPエンジンにレポートするADPエージェントのバージョンを12.1.0.8または12.1.0.7に保つことをお薦めします。

最新のADP機能を取得するために、ADPのエンジンおよびエージェントを最新の使用可能なバージョンにアップグレードすることをお薦めします。

8.2 ADPのアップグレード・ワークフローについて

企業内にデプロイされたADPアプリケーションをアップグレードするには、次のプロセスを実行します。

1. アップグレードするADPエンジンを手動で停止します。
ADPエンジンを手動で停止するには、「設定」メニューから「ミドルウェア管理」、「アプリケーション・パフォーマンス管理」の順に選択します。停止させるADPエンジンの名前をクリックします。ADPエンジンのターゲット・ホーム・ページで、「停止」をクリックします。

2. ADPエンジンを最新バージョンにアップグレードします。
ADPエンジンのアップグレード方法の詳細は、第8.3.1項を参照してください。

3. ADPエージェントを最新バージョンにアップグレードします。
ADPエージェントのアップグレード方法の詳細は、第8.4項を参照してください。

8.3 ADPエンジンのアップグレードまたは再デプロイ

この項では、ADPエンジンをアップグレードまたは再デプロイする方法について説明します。内容は次のとおりです。

- ADPエンジンのアップグレード

- ADPエンジンの再デプロイ

8.3.1 ADPエンジンのアップグレード

この項では、ADPエンジンをアップグレードする方法について説明します。内容は次のとおりです。

- 「アプリケーション・パフォーマンス管理」ページを使用したADPエンジンのアップグレード

- ApmEngineSetup.plを使用したADPエンジンの手動でのアップグレード

重要:

- Oracle Fusion Middlewareプラグイン用のEnterprise Managerをバージョン12.1.0.8にアップグレードする場合、デプロイ済ADPエンジンは自動でアップグレードされません。この項で説明されている方式を使用してアップグレードする必要があります。

- OMSホストにデプロイされているADPエンジンのアップグレードのみが可能であり、リモート・ホストにデプロイされているADPエンジンはアップグレードできません。
リモート・ホストで最新バージョンのADPエンジンを取得するには、既存のバージョンを削除してから最新バージョンの新しいADPエンジンをデプロイします。

8.3.1.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエンジンのアップグレード

「アプリケーション・パフォーマンス管理」ページを使用して、管理対象サーバー上にデプロイされているADPエンジンをアップグレードするには、次の手順に従います。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページで、「ADPエンジン」の横に表示されているアップグレード・アイコンをクリックします。

注意:
アップグレード・アイコンは、現在デプロイされているADPエンジン・ソフトウェアのバージョンと異なるソフトウェア・バージョンが使用可能である場合にのみ表示されます。

3. ADPエンジンのアップグレード・ページで、アップグレードするADPエンジンを選択します。

4. 「ホスト資格証明」の値を指定します。これらの資格証明は、選択したADPエンジンがデプロイされているホストのホスト資格証明です。「適用」をクリックします。

5. ADPエンジンのアップグレード・ページで複数のADPエンジンをアップグレードする場合、アップグレードするADPエンジンを選択し、そのそれぞれに対して「ホスト資格証明」の値を指定して適用します。

6. 「管理Weblogic資格証明」の値を指定します。これらの資格証明は、Enterprise Manager WebLogicドメインの管理サーバーの資格証明です。

7. 「アップグレード」をクリックします。
アップグレード時にエラーが発生した場合は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーション・ガイド』を参照してください。

8.3.1.2 ApmEngineSetup.plを使用したADPエンジンの手動でのアップグレード

ApmEngineSetup.plスクリプトを使用して、ADPエンジンを手動でアップグレードできます。このスクリプトは次の方法で実行できます。

- 対話型モード: 対話形式で詳細を入力するようにプロンプト表示されます。

- サイレント・モード: プロパティ・ファイルを使用してすべての入力の詳細を指定します。

ApmEngineSetup.plスクリプトを使用してADPエンジンを手動でアップグレードするには、次の手順に従います。

1. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/deploymentScripts/engine/

2. README.txtファイルでApmEngineSetup.plスクリプトの使用についての情報を確認します。

3. ApmEngineSetup.plスクリプトを実行します。
ApmEngineSetup.plスクリプトを対話型モードで、プロンプト表示に従って詳細を入力するには、次のコマンドを使用します。

perl ApmEngineSetup.pl

操作をupgradeとして、エンジン・タイプにADPを指定してください。

ApmEngineSetup.plスクリプトをサイレント・モードで実行するには、プロパティ・ファイルにすべての入力の詳細を指定し、次のコマンドを使用します。

perl ApmEngineSetup.pl -silent -file <properties_file_name> -password <password>

<properties_file_name>は、ADPエンジンおよび操作の詳細が記載されるプロパティ・ファイルの名前です。<password>は、WebLogicコンソールのパスワードです。

プロパティ・ファイルでの入力の詳細の指定方法を確認するには、サンプルのプロパティ・ファイルSAMPLE_engine.propertiesを表示します。

8.3.2 ADPエンジンの再デプロイ

管理対象サーバー上にデプロイされているADPエンジンを再デプロイするには、次の手順に従います。

注意:
ADPエンジンを再デプロイできるのは、ADPエンジン・バイナリの現在のバージョンがOracleソフトウェア・ライブラリで入手できる唯一のバージョンである場合のみです。上位バージョンまたは下位バージョンのバイナリが入手できる場合は、ADPエンジンを再デプロイできません。
たとえば、ADPエンジンの現在のバージョンが12.1.0.7であるのに、12.1.0.6や12.1.0.8などのバージョンのADPエンジン・バイナリをOracleソフトウェア・ライブラリで入手できる場合は、ADPエンジンを再デプロイできません。しかし、バージョン12.1.0.7のADPエンジン・バイナリのみがOracleソフトウェア・ライブラリで入手でき、他のバージョンは入手できない場合は、12.1.0.7 ADPエンジンを再デプロイできます。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページで単一のADPエンジンを再デプロイする場合、再デプロイするADPエンジンを選択して、「再デプロイ」をクリックします。
アプリケーション・パフォーマンス管理ページで複数のADPエンジンを再デプロイする場合、「ADPエンジン」ノードを選択して、「再デプロイ」をクリックします。

3. ADPエンジンの再デプロイ・ページに、再デプロイするADPエンジンを選択します。

4. 再デプロイに選択したADPエンジンごとに、「ホスト資格証明」の値を指定します。これらの資格証明は、選択したADPエンジンがデプロイされているホストのホスト資格証明です。「適用」をクリックします。

5. 「管理Weblogic資格証明」の値を指定します。これらの資格証明は、Enterprise Manager WebLogicドメインの管理サーバーの資格証明です。

6. 「再デプロイ」をクリックします。
再デプロイメント時にエラーが発生した場合は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

8.4 ADPエージェントのアップグレードまたは再デプロイ

この項では、ADPエージェントをアップグレードまたは再デプロイする方法について説明します。内容は次のとおりです。

- 「アプリケーション・パフォーマンス管理」ページを使用したADPエージェントのアップグレードまたは再デプロイ

- deploy_adpagent.plを使用したADPエージェントの手動でのアップグレードまたは再デプロイ

注意:
ADPエージェントを再デプロイできるのは、エージェント・バイナリの現在のバージョンがOracleソフトウェア・ライブラリで入手できる唯一のバージョンである場合のみです。上位バージョンまたは下位バージョンのエージェント・バイナリが入手できる場合は、ADPエージェントを再デプロイできません。
たとえば、ADPエージェントの現在のバージョンが12.1.0.7であるのに、12.1.0.6や12.1.0.8などのバージョンのADPエージェント・バイナリをOracleソフトウェア・ライブラリで入手できる場合は、ADPエージェントを再デプロイできません。しかし、バージョン12.1.0.7のADPエージェント・バイナリのみがOracleソフトウェア・ライブラリで入手でき、他のバージョンは入手できない場合は、12.1.0.7 ADPエージェントを再デプロイできます。

8.4.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエージェントのアップグレードまたは再デプロイ

「アプリケーション・パフォーマンス管理」ページを使用して、モニター対象のWebLogicドメインにあるADPエージェントをアップグレードまたは再デプロイするには、次の手順を実行します。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページの「アプリケーション・パフォーマンス管理エージェント」セクションで、「診断エージェントの管理」をクリックします。

3. 「操作」で、「アップグレード」を選択します。

注意:
または、この場所にアクセスするには、「アプリケーション・パフォーマンス管理」ページで「ADPエージェント数」の横に表示されるアップグレード・アイコンをクリックします。このアイコンは、ADPエージェント・ソフトウェアの現在のバージョンとは異なるソフトウェア・バージョンが使用可能である場合にのみ表示されます。

「表示」メニューから「すべてを開く」を選択した場合は、ADPエージェントがデプロイされている管理対象サーバーすべてについて、ターゲット名、ターゲット・タイプ、ターゲット・ホスト、ターゲット・ステータス、プラットフォームなどを表示できます。

アップグレードまたは再デプロイするADPエージェントを選択します。「次へ」をクリックします。

4. ターゲットの資格証明ページで、WebLogicドメインごとに「Oracle WebLogic管理サーバー・ホストの資格証明」および「Oracle WebLogicドメインの資格証明」の値を指定し、「適用」をクリックします。
Oracle WebLogic管理サーバー・ホストの資格証明は、選択したWebLogicドメインを監視している管理エージェントが実行されているホストのホスト資格証明です。Oracle WebLogicドメインの資格証明は、選択したWebLogicドメインの管理サーバーの資格証明です。

「次へ」をクリックします。

5. ADPエージェント構成ページで、WebLogicドメインごとに「使用可能なADPエンジン」でADPエンジンを選択し、「適用」をクリックします。選択したWebLogicドメインの管理対象サーバーにデプロイされているすべてのADPエージェントが、選択したADPエンジンに関連付けられます。
ADPエージェント・ソフトウェア用に別の場所を指定できます(これは、指定した管理サーバー・ホストの資格証明にデフォルトの場所に対する書込み権限がない場合に使用されます)。これを行うには、「エージェント・ディレクトリ」セクションで、「必要に応じて、デフォルトのADPエージェント・ディレクトリの場所を編集してください」を選択し、「エージェント・ディレクトリ」の値を指定します。

「追加構成」セクションに「WebLogicホーム」および「ミドルウェア・ホーム」フィールドが表示されている場合、それらに値を指定します。「WebLogicホーム」および「ミドルウェア・ホーム」フィールドは、それらの値が内部的に取得できない場合に表示されます。

また、WebLogic管理サーバーがファイアウォール内または仮想ホスト上にある場合に、アプリケーションがデフォルトのホスト値を使用して接続できないことがあります。この場合は、追加情報を「追加構成」セクションに入力する必要がある場合があります。たとえば、WebLogic管理サーバーが仮想ホスト上にあり、アプリケーションがデフォルトのホスト値を使用して接続できない場合は、「追加構成」セクションにその仮想ホストのIPアドレスを入力する必要がある場合があります。

「次へ」をクリックします。

6. Enterprise Manager OMS資格証明ページで、「Oracle Enterprise Manager WebLogic管理サーバー・ホストの資格証明」および「Oracle Enterprise Manager WebLogicドメインの資格証明」の値を指定します。
Oracle Enterprise Manager WebLogic管理サーバー・ホストの資格証明は、OMSホストのホスト資格証明です。Oracle Enterprise Manager WebLogicドメインの資格証明は、Enterprise Manager WebLogicドメインのドメイン資格証明です。

「次へ」をクリックします。

7. 確認ページですべての情報を確認し、「アップグレード」をクリックします。
「アップグレード」をクリックすると、「診断エージェントのデプロイメント・ステータス」ページが表示され、このページは、発行したジョブの進捗状況を監視するために使用できます。

アップグレード時または再デプロイメント時にエラーが発生した場合は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

8.4.2 deploy_adpagent.plを使用したADPエージェントの手動でのアップグレードまたは再デプロイ

deploy_adpagent.plスクリプトを使用して、ADPエージェントを手動でアップグレードまたは再デプロイできます。このスクリプトはサイレント・モードでのみ実行できます。つまり、プロパティ・ファイルを使用してすべての入力の詳細を指定する必要があります。

deploy_adpagent.plを使用してADPエージェントを手動でアップグレードまたは再デプロイするには、次の手順に従います。

1. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/deploymentScripts/agent/adp/

2. README.txtファイルでdeploy_adpagent.plスクリプトの使用についての情報を確認します。

3. すべての入力をプロパティ・ファイルに指定し、次のコマンドを使用します。
perl deploy_adpagent.pl <properties_file_name>

deploy_adpagent.plの実行時にプロパティ・ファイルの名前をパラメータとして渡さない場合は、このスクリプトがあるフォルダ内でadpagent.propertiesという名前のプロパティ・ファイルが検索されます。プロパティ・ファイルでの入力の詳細の指定方法を確認するには、サンプルのプロパティ・ファイルSAMPLE_adpagent.propertiesを表示します。

8.5 ADPのアップグレードまたは再デプロイ後の作業

ADPエンジンまたはADPエージェントのアップグレードまたは再デプロイが終了したら、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の説明に従って、新しいバージョンのデプロイメントを検証します。

第III部

Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

この部では、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)をEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードする方法について説明します。

この部は、次の章で構成されています。

- 第9章「Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードの開始」

- 第10章「Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードのアップグレード前要件への対応」

- 第11章「Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード」

- 第12章「Oracle Management ServiceおよびOracle Management Repository 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード」

- 第13章「Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードした後のアップグレード後タスクの実行」

9 Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードの開始

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

- 1システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

- 2システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

- 異なるホストでの1システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース4 (12.1.0.5)へのアップグレード

9.1 1システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

表9-1では、1システム・アップグレード方式を使用して、Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードするための手順について説明します。

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

手順番号

手順

プロシージャ

手順1

準備

(a)

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

第2.2項

(b)

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

第3章

手順2

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

(a)

すべてのOMSインスタンスにアップグレード前コンソール・パッチを適用し、アップグレード前コンソールにアクセスします。

第2.2.3.1項

(b)

次のソフトウェアを手動でダウンロードし、アクセス可能な場所にステージングします。

- Oracle Management Agent 12c

- 必要なプラグインすべて

第3.7.2.1項

(c)

手順2(b)で手動ダウンロードし、ステージングしたソフトウェアの場所に関する情報を提供します。

第10.4項

(d)

環境を分析して、有効および無効なインベントリを持つOracle Management Agent(管理エージェント)を識別し、これらのエージェントのアップグレード性をチェックして、問題のある管理エージェントを明らかにします。必要なソフトウェアが不足している場合、手順(b)と(c)を繰返します。

第10.6項

(e)

『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている管理エージェントをアップグレードするための前提条件を満たしてください。

手順3

Oracle Management Agentのアップグレード

(a)

Oracle Management Agent 12cのソフトウェア・バイナリをデプロイおよび構成します。

第11.1項

(b)

状態レポートを生成し、事前にデプロイした管理エージェントの準備状況を確認します。

第11.2項

(c)

ヘルス・チェック・レポートを検証およびサインオフします。

第11.3項

(d)

アップグレードしたEnterprise Manager Cloud Controlと通信できるように、古い管理エージェントから新しくデプロイされた管理エージェントにスイッチオーバーします。

注意: 多くのエージェントを使用している場合、Oracle Management Agentを一度に1セットずつアップグレードすることができます。この場合、試行ごとに手順3(a)から手順3(d)を繰り返すことができます。

第11.4項

手順4

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を実行しているホストを表します。

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

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている管理エージェント関連の前提条件を満たします。

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

- 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)

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

データベースに次のパッチを適用します。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を参照してください。

(d)

既存のEnterprise Managerシステムをアップグレードする前に、このシステムで実行およびスケジュールされているデプロイメント・プロシージャをすべて停止します。

これを確認するには、次の問合せを実行して、実行およびスケジュールされているデプロイメント・プロシージャのGUIDを書き留めます。

SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s, SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p WHERE p.procedure_guid = i.procedure_guid AND s.instance_guid = i.instance_guid AND s.state_type = 0 AND s.status in (0,1)

実行およびスケジュールされているデプロイメント・プロシージャを停止するには、次の問合せを実行して、前述のコマンドの出力から書き留めたGUIDを渡します。

emcli stop_instance -instance=<instance id from sql query>

(e)

(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ)

アップグレードの前に、次の手順を実行します。

1. JVMDまたはADP、あるいはその両方によって監視されているJVMおよびWebLogicドメインのインベントリを取ります。
デプロイされたJVMDエージェントのリストを表示するには、次の問合せを実行します。

select * from jam_jvm;

ADPに監視されているWebLogicドメインのリストを表示するには、ADPホーム・ページにアクセスします。Enterprise Managerコンソールで「ターゲット」メニューから「ミドルウェア」を選択します。「ミドルウェア」ページの「ミドルウェアの機能」メニューで、「アプリケーションの依存性とパフォーマンス」を選択します。

2. 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して(またはOracle WebLogic Scripting Toolを使用して)、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除します。

3. デプロイされたADPエンジンおよびJVMDエンジンからインベントリを取ります。WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)を使用して、ADPエンジンおよびJVMDエンジンをすべて停止します。
デプロイされたJVMDエンジンのリストを表示するには、次の問合せを実行します。

select * from jam_managers;

デプロイされたADPエンジンのリストを表示するには、次の問合せを実行します。

select * from ocamm_manager_configuration;

4. WebLogic管理コンソールを使用して、GCDomainからADP管理対象サーバーおよびJVMD管理対象サーバーをすべて削除します。

アップグレード後に、次の手順を実行します。

1. JVMD用のパージ・スクリプトを実行します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/

(b)ファイルjvmd.zipを解凍します。

(c) README.txtを表示します。

(d)スクリプトjvmd_monitoringupgrade11_12.sqlを実行します。

(e)Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のスレッド・スナップショットが存在する場合、スクリプトjvmd_traceupgrade11_12.sqlを実行します。

2. スキーマのアップグレード用に次のアップグレード・スクリプトを実行します。
<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/sql/ias/12.1.0.3/camm_product/camm_schema_upgrade.sql

(f)

既存の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".

(g)

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

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、最初に、次のコマンドを実行します。
$<OMS_HOME>/bin/emctl stop oms -all

- Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)からアップグレードする場合は、次のコマンドを実行します。
$<OMS_HOME>/opmn/bin/opmnctl stopall

(h)

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

(i)

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

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

1. 古い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

次に例を示します。

/u01/software/oracle/middleware/oms11g/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/oms11g/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からアップグレードすると、管理サーバーのパスワードを求められます。

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

単一OMS環境の場合は、次を参照してください。

- 第12.1.1項

- 第12.2.1項

- 第12.3.1項

- 第12.4.1項

複数OMS環境(追加のOMSインスタンスあり)の場合は、第12.6項を参照してください。

手順5

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

(a)

サーバー・ロード・バランサ(SLB)が構成されている場合、モニタの設定を変更します。

付録E

(b)

エージェントのアップグレード・ステータスを確認します。

第13.5項

(c)

一般的なアップグレード前のタスクを実行します。

第13.6項

(d)

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

第13.7項

(e)

エージェント移行プロセスをサインオフします。

第13.11項

(f)

アップグレード・プロセスをサインオフして、アップグレード・モードを終了します。

第13.12項

(g)

(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ)

1. 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除していない場合は、ここで実行します。

2. ad4jTargetターゲットをすべて削除します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/

(b)ファイルjvmd.zipを解凍します。

(c)スクリプトjvmd_targetupgrade11_12.sqlを実行します。

3. OCAMMマネージャ・ターゲットをすべて削除します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/ocamm/

(b)ファイルADPManager.zipを解凍します。

(c)スクリプトadp_targetupgrade11_12.sqlを実行します。

4. 新しいJVMDマネージャ、およびADPマネージャをデプロイします。

5. インベントリに基づいて、新しいJVMDエージェント、およびADPエージェントをデプロイします。

(h)

必要な場合は、Oracle BI Publisherを構成します。

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

(i)

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

第13.15項

9.2 2システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

表9-2では、2システム・アップグレード方式を使用して、Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードするための手順について説明します。

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

手順番号

手順

プロシージャ

手順1

準備

(a)

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

第2.2項

(b)

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

第3章

手順2

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

(a)

すべてのOMSインスタンスにアップグレード前コンソール・パッチを適用し、アップグレード前コンソールにアクセスします。

第2.2.3.1項

(b)

既存のOMSをアップグレードするホストの情報を指定します。

第10.2項

(c)

次のソフトウェアを手動でダウンロードし、アクセス可能な場所にステージングします。

- Oracle Management Agent 12c

- 必要なプラグインすべて

第3.7.2.1項

(d)

手順2(c)で手動ダウンロードし、ステージングしたソフトウェアの場所に関する情報を提供します。

第10.4項

(e)

環境を分析して、有効および無効なインベントリを持つOracle Management Agent(管理エージェント)を識別し、これらのエージェントのアップグレード性をチェックして、問題のある管理エージェントを明らかにします。必要なソフトウェアが不足している場合、手順2 (c)と2 (d)を繰り返します。

第10.6項

(f)

『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている管理エージェントをアップグレードするための前提条件を満たしてください。

手順3

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

注意: オプションで、Oracle Management ServiceおよびOracle Management Repositoryをアップグレードする前にOracle Management Agentのデプロイおよび構成を選択できます。この場合、手順3(a)から手順3(o)の前に、手順4(a)を実行します。

(a)

Enterprise Manager Cloud Controlをインストールする計画のあるリモート・ホストで、次の前提条件を満たします。

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

- ホストが、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている12cリリース5 (12.1.0.5)固有のハードウェア要件を満たしていることを確認してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているように、管理エージェント関連の前提条件を満たします。

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

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

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

(b)

既存のEnterprise Managerシステムをアップグレードする前に、このシステムで実行およびスケジュールされているデプロイメント・プロシージャをすべて停止します。

これを確認するには、次の問合せを実行して、実行およびスケジュールされているデプロイメント・プロシージャのGUIDを書き留めます。

SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s, SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p WHERE p.procedure_guid = i.procedure_guid AND s.instance_guid = i.instance_guid AND s.state_type = 0 AND s.status in (0,1)

実行およびスケジュールされているデプロイメント・プロシージャを停止するには、次の問合せを実行して、前述のコマンドの出力から書き留めたGUIDを渡します。

emcli stop_instance -instance=<instance id from sql query>

(c)

(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ)

アップグレードの前に、次の手順を実行します。

1. JVMDまたはADP、あるいはその両方によって監視されているJVMおよびWebLogicドメインのインベントリを取ります。
デプロイされたJVMDエージェントのリストを表示するには、次の問合せを実行します。

select * from jam_jvm;

ADPに監視されているWebLogicドメインのリストを表示するには、ADPホーム・ページにアクセスします。Enterprise Managerコンソールで「ターゲット」メニューから「ミドルウェア」を選択します。「ミドルウェア」ページの「ミドルウェアの機能」メニューで、「アプリケーションの依存性とパフォーマンス」を選択します。

2. 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して(またはOracle WebLogic Scripting Toolを使用して)、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除します。

3. デプロイされたADPエンジンおよびJVMDエンジンからインベントリを取ります。WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)を使用して、ADPエンジンおよびJVMDエンジンをすべて停止します。
デプロイされたJVMDエンジンのリストを表示するには、次の問合せを実行します。

select * from jam_managers;

デプロイされたADPエンジンのリストを表示するには、次の問合せを実行します。

select * from ocamm_manager_configuration;

4. WebLogic管理コンソールを使用して、GCDomainからADP管理対象サーバーおよびJVMD管理対象サーバーをすべて削除します。

アップグレード後に、次の手順を実行します。

1. JVMD用のパージ・スクリプトを実行します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/

(b)ファイルjvmd.zipを解凍します。

(c) README.txtを表示します。

(d)スクリプトjvmd_monitoringupgrade11_12.sqlを実行します。

(e)Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のスレッド・スナップショットが存在する場合、スクリプトjvmd_traceupgrade11_12.sqlを実行します。

2. スキーマのアップグレード用に次のアップグレード・スクリプトを実行します。
<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/sql/ias/12.1.0.3/camm_product/camm_schema_upgrade.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のインストール後、ソフトウェア・ライブラリの再構成には、これらのディレクトリをバックアップする場所が必要になります(手順5 (b)を参照)。

たとえば、ソフトウェア・ライブラリが/programs/swlibと/software/swlibで構成されていた場合は、構成済ディレクトリ1つにつき1つ、合計2つの異なるアーカイブを作成します。この場合、programs_swlib.zipおよびsoftware_swlib.zipをそれぞれ作成します。

(f)

RMANユーティリティを使用して、管理リポジトリの入っている既存のデータベースを、まったく新しいホスト、または既存のOMSが実行されているホストのいずれかにクローニング(またはバックアップ)します。

既存のOMSが実行されているホストへのリポジトリのクローニング(またはバックアップ)は、バックアップできるだけのスペースがある場合にのみ選択します。

次に、それをリストアして、構成されるリポジトリをアップグレードできるように、そこから新しいデータベース・インスタンスを作成します。

注意:

- データベースをクローニング(またはバックアップ)する前に、手順3 (b)の説明に従って、既存のEnterprise Managerシステムで実行およびスケジュールされているデプロイメント・プロシージャをすべて停止してください。

- RMANユーティリティを使用して、データベースをクローニング(またはバックアップ)することをお薦めします。

- アップグレードする前に、クローニング(またはバックアップ)した管理リポジトリのキャラクタ・セットが変更されていないことを確認してください。

- DBCAを使用してデータベースをクローニング(またはバックアップ)した場合、Enterprise Manager Cloud Controlをインストールする前に、MGMT_VIEWユーザー以外のすべてのユーザー・アカウントのロックを解除してください。

- Enterprise Managerコンソールで、DBクローニング機能を使用して、リポジトリをクローニング(またはバックアップ)しないでください。バックアップした場合、Enterprise Managerコンソールで検出されたクローン・データベースは表示されません。

- 夏時間ウィンドウが表示されている間はクローニング(またはバックアップ)しないでください。

- 管理リポジトリのクローン(またはバックアップ)を取る前に、ブロックされているすべての管理エージェントのブロックを解除することをお薦めします。

- 管理リポジトリのクローニング(またはバックアップ)後に既存のEnterprise Managerシステムに追加された管理エージェントまたはターゲットは、アップグレードされないため、アップグレードされたEnterprise Managerシステムに手動で追加する必要があります。アップグレードされたシステムに手動で追加する必要があるターゲットを特定するには、第13.9項の説明に従って差分レポートを参照してください。

- クローニング(またはバックアップ作成)後に、たとえば、メトリックのしきい値、ジョブの定義、テンプレートなどの構成変更は行わないでください。変更した場合、新しい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)

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

データベースに次のパッチを適用します。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を参照してください。

(i)

クローニング(またはバックアップ)した管理リポジトリのキャラクタ・セットが、元の管理リポジトリのキャラクタ・セットと同じであることを確認します。

異なる場合、次のエラー・メッセージが表示されます。

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'

キャラクタ・セットが同じでない場合は、同じにします。

(j)

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>]

(k)

管理リポジトリをクローニング(またはバックアップ)した日時を指定します。

注意: 管理リポジトリのクローニング(またはバックアップ)後に既存のEnterprise Managerシステムに追加された管理エージェントまたはターゲットは、アップグレードされないため、アップグレードされたEnterprise Managerシステムに手動で追加する必要があります。アップグレードされたシステムに手動で追加する必要があるターゲットを特定するには、第13.9項の説明に従って差分レポートを参照してください。

第10.7項

(l)

サーバー・ロード・バランサ(SLB)が構成されている場合、モニターの設定を構成し、SLBの準備をしておきます。

付録E

(m)

リモート・ホストにEnterprise Manager Cloud Controlをインストールし、手順3 (f)でクローニング(またはバックアップ)した、データベースの管理リポジトリをアップグレードします。グラフィック・モードとサイレント・モードのどちらでインストールするかを選択できます。ある時点でソフトウェア・バイナリをインストールし、後でグラフィック・モードまたはサイレント・モードでアップグレードすることも選択できます。

2システム・アップグレードを実行しているホストがアップグレード前コンソールに入力したホスト名と一致しないために、OMSをアップグレードできないことを示すエラー・メッセージが表示される場合、アップグレード前コンソールに移動して正しいホスト名を指定します。

(注意: OMSをアップグレードする前に管理エージェントをデプロイすることを選択した場合に、このエラーが表示されたときは、アップグレード前コンソールでエラーを修正してから、OMSのアップグレードの前に管理エージェントを再度デプロイします。)

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

11gリリース1 (11.1.0.1)の場合

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

次に例を示します。

/u01/software/oracle/middleware/oms11g/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/oms11g/sysman/config/emkey.ora

注意: ここで、管理リポジトリの詳細は、手順3 (f)でクローニング(またはバックアップ)したクローン管理リポジトリの詳細です。<OMS_HOME>は、アップグレードしようとしているOMSホームです。管理サーバーのパスワードを求められます。

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

10gリリース5 (10.2.0.5)の場合

1. 古いOMSから古い管理リポジトリにemkeyをコピーします。これを実行するには、アップグレードしようとしている古いOMSホームから次のコマンドを実行します。
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman password>]

2. 手順3 (f)の説明に従って管理リポジトリをクローニング(またはバックアップ)します。

3. 手順3 (g)の説明に従って、クローニング(またはバックアップ)した管理リポジトリで前提条件を満たします。

4. 手順3 (j)の説明どおりに古い管理リポジトリからemkeyを削除します。

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

(注意: OMSをアップグレードする前に管理エージェントをデプロイすることを選択している場合に、このエラーが表示されたときは、前述のコマンドを実行した後、必ずすべての管理エージェントを再度デプロイします。ただし、コマンドの実行後、管理エージェントの再デプロイの前に、インストーラを実行してemkeyに関するエラーが再度発生しないか確かめることをお薦めします。)

単一OMS環境の場合は、次を参照してください。

- 第12.1.2項

- 第12.2.2項

- 第12.3.2項

- 第12.4.2項

複数OMS環境(追加のOMSインスタンスあり)の場合は、第12.6項を参照してください。

(n)

データベース・ドメイン名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字が含まれている場合、スイッチオーバー操作のRun Presync手順が失敗し、次のエラーがemoms.trcトレース・ファイルに表示される可能性があります。たとえば、データベース・ドメイン名にハイフン(-)が含まれている場合に次の問題が発生します。

ORA-20000: Found exception Error Message :ORA-02083: database name has illegal character '-' Error Number ;-2083

この問題を回避するには、前提条件として、付録L.1に示されている手順に従ってください。データベース・ドメイン名にハイフンなどの無効な文字が含まれている場合は、修正します。

付録L

(o)

旧リリースの管理リポジトリをアップグレードした管理リポジトリにリンクします。

第13.2項

手順4

Oracle Management Agentのアップグレード

(a)

Oracle Management Agent 12cのソフトウェア・バイナリをデプロイおよび構成します。

注意: 管理エージェントのデプロイおよび構成後に、古い管理リポジトリで、たとえば、メトリックのしきい値、ジョブの定義、テンプレートなどの構成変更は行わないでください。変更した場合、新しい管理エージェントにスイッチオーバーするときにこれらの変更内容は継承されず、変更内容を転送する唯一の方法は、新しい管理エージェントを再構成することです。管理エージェントを再構成する方法の詳細は、第11.1.2項の手順(6)の注意を参照してください。

第11.1項

(b)

状態レポートを生成し、事前にデプロイした管理エージェントの準備状況を確認します。

第11.2項

(c)

ヘルス・チェック・レポートを検証およびサインオフします。

第11.3項

(d)

アップグレードしたEnterprise Manager Cloud Controlと通信できるように、古い管理エージェントから新しくデプロイされた管理エージェントにスイッチオーバーします。

注意: 多くのエージェントを使用している場合、Oracle Management Agentを一度に1セットずつアップグレードすることができます。この場合、試行ごとに手順4(a)から(d)を繰り返すことができます。

第11.4項

手順5

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

(a)

Enterprise Manager Cloud Controlをインストールしたホストを確認します。

第13.1項

(b)

(従来のEnterprise Managerでソフトウェア・ライブラリが構成されている場合のみ)

Enterprise Manager Cloud Controlでソフトウェア・ライブラリを再構築し、従来のEnterprise Managerシステム用に構成されたソフトウェア・ライブラリから独立させます。

第13.4項

(c)

中央エージェント[手順3 (m)の一部でインストールした新しいOMSとともにデフォルトでインストールされる管理エージェント]を保護します。

(d)

エージェントのアップグレード・ステータスを確認します。

第13.5項

(e)

一般的なアップグレード前のタスクを実行します。

第13.6項

(f)

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

第13.7項

(g)

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

第13.8項

(h)

Enterprise Managementシステムの旧リリースのアップグレード中に、このリリースに対して手動で行った構成およびセットアップ関係の変更をすべて明らかにするために、差分レポートを生成します。

第13.9項

(i)

アップグレード後のEnterprise Managerシステムで現在アクティブでないターゲットのリストを表示します。

第13.10項

(j)

エージェント移行プロセスをサインオフします。

第13.11項

(k)

アップグレード・プロセスをサインオフして、アップグレード・モードを終了します。

第13.12項

(l)

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

第13.13.1項

(m)

(オプション)削除された中央エージェントで監視されていたターゲットを監視します。

第13.14項

(n)

(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ)

1. 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagenthおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除していない場合は、ここで実行します。

2. ad4jTargetターゲットをすべて削除します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/

(b)ファイルjvmd.zipを解凍します。

(c)スクリプトjvmd_targetupgrade11_12.sqlを実行します。

3. OCAMMマネージャ・ターゲットをすべて削除します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/ocamm/

(b)ファイルADPManager.zipを解凍します。

(c)スクリプトadp_targetupgrade11_12.sqlを実行します。

4. 新しいJVMDマネージャ、およびADPマネージャをデプロイします。

5. インベントリに基づいて、新しいJVMDエージェント、およびADPエージェントをデプロイします。

(o)

必要な場合は、Oracle BI Publisherを構成します。

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

(p)

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

第13.15項

9.3 異なるホストでの1システム・アップグレード方式でのEnterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース4 (12.1.0.5)へのアップグレード

表9-3では、異なるホストでの1システム・アップグレード方式を使用して、Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードするための手順について説明します。

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

手順番号

手順

プロシージャ

手順1

準備

(a)

異なるホストでの1システム・アップグレード方式について学習します。

第2.2項

(b)

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

第3章

手順2

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

(a)

すべてのOMSインスタンスにアップグレード前コンソール・パッチを適用し、アップグレード前コンソールにアクセスします。

第2.2.3.1項

(b)

既存のOMSをアップグレードするホストの情報を指定します。

第10.2項

(c)

次のソフトウェアを手動でダウンロードし、アクセス可能な場所にステージングします。

- Oracle Management Agent 12c

- 必要なプラグインすべて

第3.7.2.1項

(d)

手順2(c)で手動ダウンロードし、ステージングしたソフトウェアの場所に関する情報を提供します。

第10.4項

(e)

環境を分析して、有効および無効なインベントリを持つOracle Management Agent(管理エージェント)を識別し、これらのエージェントのアップグレード性をチェックして、問題のある管理エージェントを明らかにします。必要なソフトウェアが不足している場合、手順(c)と(d)を繰返します。

第10.6項

(f)

『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている管理エージェントをアップグレードするための前提条件を満たしてください。

手順3

Oracle Management Agentのアップグレード

(a)

Oracle Management Agent 12cのソフトウェア・バイナリをデプロイおよび構成します。

第11.1項

(b)

状態レポートを生成し、事前にデプロイした管理エージェントの準備状況を確認します。

第11.2項

(c)

ヘルス・チェック・レポートを検証およびサインオフします。

第11.3項

(d)

アップグレードしたEnterprise Manager Cloud Controlと通信できるように、古い管理エージェントから新しくデプロイされた管理エージェントにスイッチオーバーします。

注意: 多くのエージェントを使用している場合、Oracle Management Agentを一度に1セットずつアップグレードすることができます。この場合、試行ごとに手順3(a)から手順3(d)を繰り返すことができます。

第11.4項

手順4

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

(a)

Enterprise Manager Cloud Controlをインストールする計画のあるリモート・ホストで、次の前提条件を満たします。

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

- ホストが、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている12cリリース5 (12.1.0.5)固有のハードウェア要件を満たしていることを確認してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているように、管理エージェント関連の前提条件を満たします。

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

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

- 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)

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

データベースに次のパッチを適用します。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を参照してください。

(d)

既存のEnterprise Managerシステムをアップグレードする前に、このシステムで実行およびスケジュールされているデプロイメント・プロシージャをすべて停止します。

これを確認するには、次の問合せを実行して、実行およびスケジュールされているデプロイメント・プロシージャのGUIDを書き留めます。

SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s, SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p WHERE p.procedure_guid = i.procedure_guid AND s.instance_guid = i.instance_guid AND s.state_type = 0 AND s.status in (0,1)

実行およびスケジュールされているデプロイメント・プロシージャを停止するには、次の問合せを実行して、前述のコマンドの出力から書き留めたGUIDを渡します。

emcli stop_instance -instance=<instance id from sql query>

(e)

(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ)

アップグレードの前に、次の手順を実行します。

1. JVMDまたはADP、あるいはその両方によって監視されているJVMおよびWebLogicドメインのインベントリを取ります。
デプロイされたJVMDエージェントのリストを表示するには、次の問合せを実行します。

select * from jam_jvm;

ADPに監視されているWebLogicドメインのリストを表示するには、ADPホーム・ページにアクセスします。Enterprise Managerコンソールで「ターゲット」メニューから「ミドルウェア」を選択します。「ミドルウェア」ページの「ミドルウェアの機能」メニューで、「アプリケーションの依存性とパフォーマンス」を選択します。

2. 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して(またはOracle WebLogic Scripting Toolを使用して)、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除します。

3. デプロイされたADPエンジンおよびJVMDエンジンからインベントリを取ります。WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)を使用して、ADPエンジンおよびJVMDエンジンをすべて停止します。
デプロイされたJVMDエンジンのリストを表示するには、次の問合せを実行します。

select * from jam_managers;

デプロイされたADPエンジンのリストを表示するには、次の問合せを実行します。

select * from ocamm_manager_configuration;

4. WebLogic管理コンソールを使用して、GCDomainからADP管理対象サーバーおよびJVMD管理対象サーバーをすべて削除します。

アップグレード後に、次の手順を実行します。

1. JVMD用のパージ・スクリプトを実行します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/

(b)ファイルjvmd.zipを解凍します。

(c) README.txtを表示します。

(d)スクリプトjvmd_monitoringupgrade11_12.sqlを実行します。

(e)Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のスレッド・スナップショットが存在する場合、スクリプトjvmd_traceupgrade11_12.sqlを実行します。

2. スキーマのアップグレード用に次のアップグレード・スクリプトを実行します。
<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/sql/ias/12.1.0.3/camm_product/camm_schema_upgrade.sql

(f)

既存の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".

(g)

サーバー・ロード・バランサ(SLB)が構成されている場合、モニターの設定を構成し、SLBの準備をしておきます。

付録E

(h)

従来のEnterprise Managerにより、NFSマウントされている共有ドライブにOracle Software Library(ソフトウェア・ライブラリ)が構成されている場合、Enterprise Manager Cloud Controlのインストールを計画しているリモート・ホストからこの共有ドライブにアクセスできることを確認します。

ただし、既存のEnterprise Managerの旧リリースが実行されているローカルのファイル・システムにソフトウェア・ライブラリが構成されている場合は、Enterprise Manager Cloud Controlのインストールを計画しているリモート・ホストの古いEnterprise Managerシステムで維持されていたソフトウェア・ライブラリと同じディレクトリ・パスに、このソフトウェア・ライブラリをコピーします。

(i)

リモート・ホストにEnterprise Manager Cloud Controlをインストールし、既存のデータベースで管理リポジトリをアップグレードします。

第12.5項

手順5

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

(a)

中央エージェント[手順4 (i)の一部でインストールした新しいOMSとともにデフォルトでインストールされる管理エージェント]を保護します。

(b)

エージェントのアップグレード・ステータスを確認します。

第13.5項

(c)

一般的なアップグレード前のタスクを実行します。

第13.6項

(d)

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

第13.7項

(e)

エージェント移行プロセスをサインオフします。

第13.11項

(f)

アップグレード・プロセスをサインオフして、アップグレード・モードを終了します。

第13.12項

(g)

不要な中央エージェントが削除されました。

第13.13.1項

(h)

(オプション)削除された中央エージェントで監視されていたターゲットを監視します。

第13.14項

(i)

(アプリケーションの依存性とパフォーマンス(ADP)またはJVM診断(JVMD)がインストールされている場合のみ)

1. 監視されているドメインそれぞれのWebLogic管理コンソールにログインし、jamagentおよびAcseraアプリケーション・デプロイメントを削除して、インベントリからJVMDアプリケーションおよびADPアプリケーションを削除していない場合は、ここで実行します。

2. ad4jTargetターゲットをすべて削除します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/jvmd/

(b)ファイルjvmd.zipを解凍します。

(c)スクリプトjvmd_targetupgrade11_12.sqlを実行します。

3. OCAMMマネージャ・ターゲットをすべて削除します。
(a)次の場所に移動します。

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.0/archives/ocamm/

(b)ファイルADPManager.zipを解凍します。

(c)スクリプトadp_targetupgrade11_12.sqlを実行します。

4. 新しいJVMDマネージャ、およびADPマネージャをデプロイします。

5. インベントリに基づいて、新しいJVMDエージェント、およびADPエージェントをデプロイします。

(j)

必要な場合は、Oracle BI Publisherを構成します。

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

(k)

(オプション)古いOMSホームを削除します。

第13.15項

10 Enterprise Manager Grid Control 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレードのアップグレード前要件への対応

この章では、アップグレード前に満たす必要がある要件について説明します。特に、次の内容について説明します。

- アップグレード前コンソール・パッチの適用

- 新しいEnterprise Managerシステムのホストとポートの識別

- DDMPジョブの自動実行の無効化

- 管理エージェント・ソフトウェアおよび関連プラグインの場所の管理と検証

- Enterprise Managerシステムをアップグレードする前の既存データベースのクローニング(バックアップ)

- Enterprise Managerシステムをアップグレードする前の環境の分析

- Enterprise Managerシステムをアップグレードするためのリポジトリ・バックアップの詳細指定

10.1 アップグレード前コンソール・パッチの適用

アップグレード前コンソール・パッチの適用手順については、第2.2.3.1項を参照してください。

10.2 新しいEnterprise Managerシステムのホストとポートの識別

注意:
次の手順は、2システム・アップグレード方式または異なるホストでの1システム・アップグレード方式を使用してアップグレードする場合にのみ実行してください。旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

Enterprise Manager Cloud Controlをインストールするホストの情報を識別および指定するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「アップグレード・タイプの選択」セクションで、次のいずれかを選択します。

- 手動で管理エージェントをインストールする場合でも停止時間をほとんど発生させずにEnterprise Managerシステムをアップグレードするには、2システムを選択します。

- 異なるホストの停止時間でEnterprise Managerシステムをアップグレードするには、異なるホストの1システムを選択します。

Enterprise Manager Grid Controlでページがリフレッシュされ、選択したアップグレード方式で実行する必要があるタスクのリストとともに表が表示されます。

4. 「アップグレード前のステップ」セクションの表から新しいEnterprise Managerシステムのホストおよびポートの識別をクリックします。

5. 新しいEnterprise Managerシステムのホストおよびポートの識別ページで、次の内容を入力します。

- Enterprise Manager Cloud Controlをインストールするホストの完全修飾名。たとえば、example.comです。

- Enterprise Manager Cloud Controlコンソールに割り当てる保護および非保護アップロード・ポート。たとえば、1768です。
複数OMS環境で、Oracle Management Service 12cをインストールするホストがサーバー・ロード・バランサ(SLB)で管理されている場合は、「Oracle Management Service 12cリリース5 (12.1.0.5.0)にサーバー・ロード・バランサ(SLB)を構成する場合にクリックします」を選択します。次に、SLBを実行しているホストの完全修飾名と、保護および非保護アップロード・ポートを入力します。

注意:

- 2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式の場合、ここで示されているホストは、既存のOMSを実行していないホストです。つまり、複数OMS環境では、新しい仮想ホスト名を使用する必要があり、この仮想ホスト名に対して新しいSLB構成を作成する必要があります。

- 必ず、ここで入力したホストにOracle Management Service 12cをインストールし、ここで入力したHTTPSおよびHTTPアップロード・ポートを使用してください。インストール・ウィザードの「ポート構成の詳細」画面で、Enterprise ManagerのアップロードHttp SSLポートにこのコンポーネントのHTTPSアップロード・ポート、Enterprise ManagerのアップロードHttpポートにこのコンポーネントのHTTPアップロード・ポートを入力します。
Oracle Management Service 12cをインストール済の場合は、OMSホームで入手可能なemgc.propertiesファイルからこれらの値を取得します。HTTPSアップロード・ポートには、パラメータEM_UPLOAD_HTTPS_PORTに割り当てられている値を、HTTPアップロード・ポートには、パラメータEM_UPLOAD_HTTP_PORTに割り当てられている値を探します。

- ここに保護および非保護アップロード・ポートを入力し、デプロイメントを開始したら、これらのポートを変更しないようにしてください。

6. アップグレード後のタスクの構成セクションで、次のオプションのいずれかを選択します。

- 自動DDMPジョブの無効化: DDMPジョブが自動的に実行されないようにする場合に選択します。このオプションは、1システム・アップグレード方式および異なるホストでの1システム・アップグレード方式に適用されます。
Enterprise Manager Cloud Controlへのアップグレード後にDDMPジョブを明示的に実行する場合は、第13.7.2項に記載されている手順(3)を実行します(つまり、各コンポーネントを選択して「開始」をクリックします)。

注意:
DDMPジョブを無効にすると、デフォルトではADMPジョブも無効になります。

- 自動ADMPジョブの無効化: ADMPジョブが自動的に実行されないようにする場合に選択します。このオプションは、1システム・アップグレード方式のみに適用されます。
Enterprise Manager Cloud Controlへのアップグレード後にDDMPジョブを明示的に実行する場合は、第13.8.2項に記載されている手順(3)を実行します。

7. 「保存」をクリックします。
Enterprise Manager Grid Controlで指定した情報が保存され、選択したアップグレード方式で実行するタスクのリストを表示する「アップグレード・コンソール」ページに戻ります。

10.3 DDMPジョブの自動実行の無効化

注意:
1システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

デフォルトでは、アップグレードの直後に、Enterprise Manager Cloud Controlによって遅延データ移行プロセス(DDMP)ジョブが自動的に実行されます。このジョブは、メトリック、構成などの履歴データを、旧リリースのEnterprise Managerに格納されているフォーマットからEnterprise Manager Cloud Controlと互換性のあるフォーマットに移行します。DDMPジョブの詳細は、第13.7.1項を参照してください。

Enterprise Managerシステムのサイズによって、このジョブは管理リポジトリ・リソースを大量に消費し、完了するまでの時間が長くなります。特に、1システム・アップグレード方式を使用してアップグレードする場合、アップグレード直後にすべての管理エージェントが起動されて稼働するため、リソース競合が発生する可能性があります。

このDDMPジョブを適切に制御するために、このジョブの自動実行を無効にすることもできます。無効にした場合、後でこのジョブをEnterprise Manager Cloud Controlコンソールの「アップグレード後のタスク」ページから明示的に実行する必要があります。

DDMPジョブの自動実行を無効にするには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「アップグレード・タイプの選択」セクションで、「1システム」を選択します。
Enterprise Manager Grid Controlでページがリフレッシュされ、選択したアップグレード方式で実行する必要があるタスクのリストとともに表が表示されます。

4. 「アップグレード前のステップ」セクションの表から、「アップグレード後のタスクの構成」をクリックします。

5. アップグレード後のタスクの構成ページで、「自動DDMPジョブの無効化」を選択します。

6. 「保存」をクリックします。
Enterprise Manager Grid Controlで指定した情報が保存され、選択したアップグレード方式で実行するタスクのリストを表示する「アップグレード・コンソール」ページに戻ります。

注意:
Enterprise Manager Cloud Controlへのアップグレード後にDDMPジョブを明示的に実行する場合は、第13.7.2項に記載されている手順(3)を実行します(つまり、各コンポーネントを選択して「開始」をクリックします)。

10.4 管理エージェント・ソフトウェアおよび関連プラグインの場所の管理と検証

注意:
旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

コア管理エージェント・ソフトウェアおよび関連する管理プラグインの場所についての情報を管理するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「アップグレード・タイプの選択」セクションで、次のいずれかを選択します。これらのアップグレード方式の詳細は、第2章を参照してください。

- 手動で管理エージェントをインストールする場合でも停止時間でEnterprise Managerシステムをアップグレードするには、「1システム」を選択します。

- 手動で管理エージェントをインストールする場合でも停止時間をほとんど発生させずにEnterprise Managerシステムをアップグレードするには、2システムを選択します。

- 異なるホストの停止時間でEnterprise Managerシステムをアップグレードするには、異なるホストの1システムを選択します。

Enterprise Manager Grid Controlでページがリフレッシュされ、選択したアップグレード方式で実行する必要があるタスクのリストとともに表が表示されます。

4. 「アップグレード前のステップ」セクションの表からソフトウェアの管理をクリックします。

5. ソフトウェアの管理ページのエージェントのアップグレード性およびターゲットのアップグレード性の円グラフで、それぞれの凡例のハイパーリンクをクリックして、アップグレードできる管理エージェントおよびターゲットと管理エージェント・ソフトウェアまたはプラグイン・ソフトウェアを使用できないためにアップグレードできない管理エージェントおよびターゲットを識別します。

6. 「ソフトウェアの場所の指定」セクションで、必要なプラットフォームのコア管理エージェント・ソフトウェアおよびプラグイン・ソフトウェアが存在するディレクトリへの絶対パスを入力します。
たとえば、/john/software/oracle/em/などです。

次に、「検証」をクリックして、場所をEnterprise Managerシステムに登録します。

注意:

- 入力する絶対パスは、管理エージェント・ソフトウェアおよびプラグイン・ソフトウェア両方を含むステージングの場所へのパスである必要があります。
管理エージェント・ソフトウェアおよびプラグインをダウンロードするには、次の手順を実行します。

(a)次のURLにアクセスします。

http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

(b)管理エージェント・ソフトウェアをアクセス可能な場所にダウンロードします。ソフトウェアZIPファイルのコンテンツを解凍しないでください。管理エージェント・ソフトウェアはプラットフォームごとに異なるので、インストールするプラットフォーム用のソフトウェアをコピーするようにしてください。

(c)必要なプラグインをすべて同じ場所にダウンロードします。プラグインは汎用なので、すべてのプラットフォームに共通です。

プラグインを使用してターゲットを監視するかどうかに関係なく、「ソフトウェアの管理」ページに必要なプラグインとしてリストされているプラグインを必ずすべてダウンロードします。ターゲットの監視に使用しないプラグインは不要と思われることがありますが、システムのアップグレードのときに必要になる場合があります。したがって、管理ソフトウェア・ページにリストされているプラグインはすべてダウンロードしてください。これらのプラグインは、管理リポジトリを含むデータベースをバックアップする前にダウンロードする必要があります。

- 指定したコアの管理エージェント・ソフトウェアおよびプラグイン・ソフトウェアに読取り権限があり、それらが存在する場所がアクセス可能で、読取りおよび書込み権限があることを確認します。

- 複数のOracle Management Service (OMSインスタンス)をインストールする場合、入力する場所がすべてのOMSインスタンスで書込み可能およびアクセス可能であることを確認します。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)でサポートされていない、旧リリースのEnterprise Managerにデプロイされたプラグイン・バージョンを保有している場合は、そのプラグインより高いバージョンのソフトウェアを、ダウンロード可能な場合でも指定しないでください。これによって、12cリリース5 (12.1.0.5)へのアップグレード中に、サポートされていないバージョンが確実に削除されます。アップグレード後、上位のバージョンをプラグイン・マネージャから直接デプロイできます。

- 管理エージェント・ソフトウェアおよびプラグイン・ソフトウェアの場所を登録した後、同じまたは異なる場所に後で追加のプラグインをダウンロードする場合、それらの最近ダウンロードしたプラグインの場所も登録します。

- 検証および登録プロセスの実行に時間がかかる場合があるので、「検証」をクリックした後、プロセスの終了をしばらく待機します。このプロセスが終了すると、この場所が正常に登録されたことを示すメッセージが表示されます。

注意:
Red Hat Enterprise Linux 4.x、Oracle Linux 4.x、またはSUSE Linux Enterprise 10などのプラットフォームにOracle Management Agent 12cをデプロイする場合、32ビット・バージョンの管理エージェント・ソフトウェアのみをデプロイするようにしてください。64ビット・バージョンはこれらのプラットフォームでサポートされていないため、デプロイしないでください。
ただし、32ビット・バージョンを使用しているにもかかわらず、「ソフトウェアの管理」ページでソフトウェアを検証中に、32ビット・バージョンがサポートされていないというエラーが表示される場合は、次の手順を実行して問題を解決します。

1. 古い管理リポジトリでSYSMANユーザーとして次のSQL問合せを実行します。この時点で管理リポジトリがまだアップグレードされていないことを確認します。
update PRE_UPGC_AGT_STAT_MGMT set PLATFORM_ID='46', PLATFORM_NAME='Linux x86-64' where OS_VERSION like '%Enterprise Linux%elease%4%' and PLATFORM_ID='226';

update PRE_UPGC_AGT_STAT_MGMT set PLATFORM_ID='46', PLATFORM_NAME='Linux x86-64' where OS_VERSION like '%SUSE%10%' and PLATFORM_ID='226';

commit;

2. 「ソフトウェアの管理」ページで、32ビット・バージョンの管理エージェント・ソフトウェアが利用可能な場所への絶対パスを入力し、「検証」をクリックします。

3. 「エージェントのアップグレード可能性」円グラフで、管理エージェントがアップグレード可能なターゲットとして表示されるかどうか確認します。

10.5 Enterprise Managerシステムをアップグレードする前の既存データベースのクローニング(バックアップ)

2システム・アップグレードを実行している場合は、管理リポジトリが格納されている既存のデータベースをクローニング(またはバックアップ)していることを確認します。手順については、第9.2項の表9-2の手順3 (f)を参照してください。

注意:
クローニングまたはバックアップされたOracle Database 11gリリース1 (11.1.0.7)または10gリリース2 (10.2.0.5)をMicrosoft Windows 32ビットからMicrosoft Windows 64ビットにリカバリする場合は、付録Jを参照してください。

10.6 Enterprise Managerシステムをアップグレードする前の環境の分析

この章では、既存のOracle Management Agent(管理エージェント)を分析し、アップグレードのために準備する方法について説明します。この章の具体的な内容は次のとおりです。

- インベントリが有効のOracle Management Agentの識別

- インベントリが無効のOracle Management Agentの識別

- Oracle Management Agentのアップグレード性のステータスの確認

- ターゲットのアップグレード性のステータスの確認

- 問題のあるOracle Management Agentの識別

- 再構成が必要なOracle Management Agentの識別

- Enterprise Manager 12cでサポートされないOracle Management Agentの特定

- リポジトリ・バックアップ後にインストールされるOracle Management Agentの特定

- 破損したターゲットの特定

注意:
旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

10.6.1 インベントリが有効のOracle Management Agentの識別

ホストにインストールされたOracle Management Agent(管理エージェント)を含む各Oracleソフトウェア製品は、中央インベントリ(oraInventory)に登録されます。各Oracleソフトウェア製品は、oraInventoryディレクトリに存在するinventory.xmlファイルにエントリを持ちます。中央インベントリに登録されている管理エージェントは、インベントリが有効の管理エージェントです。

インベントリが有効の管理エージェントを識別するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「エージェントのアップグレード・ステータス」セクションで、「インベントリが有効のエージェント」の表示数を参照します。
各管理エージェントをドリルダウンして詳細な情報を表示するには、数値をクリックします。

Enterprise Manager Grid Controlでは、管理エージェントが実行しているプラットフォーム、バージョン、古いおよび新しいOracleホームの場所、デプロイメント、構成、ヘルス・チェックおよびスイッチオーバー・ステータスなどの情報を提供する、「アップグレード・ステータス」ページが表示されます。

注意:

- ここで表示される数には、インベントリが無効の管理エージェントおよび数の特定後にインストールされた管理エージェントは含まれません。

- 無効なインベントリを持つ管理エージェントを考慮するには、まずこのような管理エージェントの問題を解決します。障害のある管理エージェントがないことを確認します。このような管理エージェントを識別し、問題を解決する方法の詳細は、第10.6.2項を参照してください。問題を解決した後、「エージェントとターゲットのリストのリフレッシュ」をクリックします。

- 数の特定後にインストールされた管理エージェントを考慮するには、「エージェントとターゲットのリストのリフレッシュ」をクリックしてリストをリフレッシュします。

10.6.2 インベントリが無効のOracle Management Agentの識別

ホストにインストールされた管理エージェントを含む各Oracleソフトウェア製品は、中央インベントリ(oraInventory)に登録されます。各Oracleソフトウェア製品は、oraInventoryディレクトリに存在するinventory.xmlファイルにエントリを持ちます。

ただし、管理エージェントのエントリが欠落または破損しているあるいは不完全であるか、不正な構文を使用している可能性があります。また、ホスト構成がリフレッシュされずに最新の構成が収集されなかった可能性もあります。このような理由で中央インベントリに登録されていない管理エージェントは、インベントリが無効の管理エージェントです。

インベントリが無効の管理エージェントは、アップグレード前コンソールに表示されないため、問題が解決するまでアップグレードできません。

無効なインベントリを使用した管理エージェントを識別するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「エージェントのアップグレード・ステータス」セクションで、無効なインベントリを使用したエージェントの表示数を参照します。
各管理エージェントをドリルダウンして詳細な情報を表示するには、数値をクリックします。

注意:
この問題を解決するには、次の手順を実行します。

1. inventory.xmlファイルのこれらの管理エージェントのエントリを確認します。
inventory.xmlファイルは、oraInventoryディレクトリ(中央インベントリ)にあります。oraInventoryディレクトリの場所は、サイレント・モードでのインストーラの起動時に渡すoraInst.locファイルに示されています。エントリに正しい構文が使用されていることを確認します。

2. 次のいずれかの手順でホスト構成をリフレッシュします。
(a) ホストのホームページに移動します。「構成」タブをクリックします。「構成」ページで、「リフレッシュ」をクリックします。

(b) 「デプロイ」ページに移動します。「構成」セクションで「ホスト構成のリフレッシュ」をクリックします。

ステップ2(a)またはステップ2(b)に失敗した場合、管理エージェント・ホームから次のコマンドを実行します。

$<AGENT_HOME>/bin/emctl control agent runCollection

3. アップグレード前コンソールのエージェント・リストをリフレッシュします。
アップグレード前コンソールに移動します。エージェントのアップグレード・ステータス・セクションでエージェントおよびターゲット・リストのリフレッシュをクリックします。

10.6.3 Oracle Management Agentのアップグレード性のステータスの確認

管理エージェントのアップグレード性のステータスを確認するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「アップグレード前のステップ」セクションの表からソフトウェアの管理をクリックします。

4. ソフトウェアの管理ページで、エージェントのアップグレード性の円グラフを表示します。円グラフは、次の情報を図で表示します。

- 完全にアップグレード可能 -- 管理エージェント・ソフトウェアおよびすべての関連付けられたターゲット固有の管理プラグイン・ソフトウェアを使用できるので完全にアップグレードできる管理エージェントの数。

- 欠落しているプラグイン・ソフトウェア - 管理エージェント・ソフトウェアおよび少数の関連付けられたターゲット固有の管理プラグイン・ソフトウェアのみを使用できるので部分的にアップグレードできる管理エージェントの数。一部の管理プラグイン・ソフトウェアがアップグレードしたEnterprise Managerシステムで欠落しているか、サポートされていません。

- 欠落しているエージェント・ソフトウェア - 管理エージェント・ソフトウェアを使用できないのでアップグレードできない管理エージェントの数。関連付けられたターゲット固有の管理プラグイン・ソフトウェアを使用できる場合がありますが、コア管理エージェント・ソフトウェアは使用できません。

- サポートされていません - Oracle Management Agent 12cが特定のプラットフォーム向けにリリースされていないのでアップグレードされたEnterprise Managerシステムでサポートされない管理エージェントの数。これらの管理エージェントで監視されるターゲットは、アップグレードしたEnterprise Managerシステムで監視できなくなります。

10.6.4 ターゲットのアップグレード性のステータスの確認

ターゲットのアップグレード性のステータスを確認するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページで、次のいずれかを実行します。

- 「その他のリンク」セクションで、ターゲットのアップグレード性のステータスをクリックします。
ターゲットのアップグレード性のステータス・ページで、検索機能を使用して、アップグレードしたEnterprise Managerシステムの監視の有無を指定できるターゲットを検索および識別します。

たとえば、アップグレードしたEnterprise Managerシステムで監視できないターゲットをリストするには、「アップグレード・ステータス」リストからアップグレード不可を選択します。同様に、監視できるターゲットをリストするには、「アップグレード可能」を選択します。

- 「アップグレード前のステップ」セクションの表からソフトウェアの管理をクリックします。
ソフトウェアの管理ページで、ターゲットのアップグレード性の円グラフを表示します。円グラフは、次の情報を図で表示します。

- アップグレード可能 - 管理エージェント・ソフトウェアおよび関連付けられたターゲット固有の管理プラグイン・ソフトウェアを使用できるのでアップグレードしたEnterprise Managerシステムで監視できるターゲットの数。

- 欠落しているエージェント/プラグイン・ソフトウェア - 管理エージェント・ソフトウェアまたは関連付けられた管理プラグイン・ソフトウェアが欠落しているのでアップグレードしたEnterprise Managerシステムで監視できないターゲットの数。

- サポートされていません: Oracle Management Agent 12cがターゲットを実行しているプラットフォーム向けにリリースされていないか、それらのターゲットの管理プラグインがアップグレード後のEnterprise Managerシステムでサポートされていないので、アップグレード後のEnterprise Managerシステムで監視できないターゲットの数。

- 動作保証されていないプラグイン・ソフトウェア - 管理プラグインが動作保証されていないので、アップグレードしたEnterprise Managerシステムで監視できないターゲットの数。

10.6.5 問題のあるOracle Management Agentの識別

欠落しているホスト・ターゲット、複数のホスト・ターゲットの関連付け、使用不可状態、無効なインベントリなどの技術的な問題のためにアップグレードできない管理エージェントが存在する場合があります。

このような問題のある管理エージェントを識別するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「その他のリンク」セクションで、問題のあるエージェントをクリックします。

4. 問題のあるエージェント・ページで、アップグレードできない管理エージェントを表示します。

- 特定の管理エージェントを検索するには、管理エージェントの名前を「エージェント」フィールドに入力し、「検索」をクリックします。

- 特定の技術的な理由に基づいて管理エージェントをフィルタ処理するには、「理由」リストから次の理由のいずれかを選択して、「検索」をクリックします。

- 欠落しているリポジトリ・インベントリ - 中央インベントリ(oraInventory)に登録されていない管理エージェントをリストします。

- 複数のホスト・ターゲット - 複数のホストに関連付けられているか、複数のホストを監視している管理エージェントをリストします。

- エージェント使用不可 - 停止している管理エージェントをリストします。

- 欠落しているホスト・ターゲット - ホストがEnterprise Manager Grid Controlコンソールで検出および監視されない管理エージェントをリストします。管理エージェント自体が監視される場合がありますが、なんらかの理由でホストが監視されない可能性があります。

- セントラル・エージェント - 2システム・アップグレードでアップグレードできない中央エージェント(最初のOMSでインストールされた管理エージェント)をリストします。

- すべて - 「理由」リストにリストされている1つ以上の問題が発生しているすべての管理エージェントをリストします。

10.6.6 再構成が必要なOracle Management Agentの識別

次のいずれかの理由により、管理エージェントの再構成が必要な場合があります。

- 管理エージェントのデプロイに使用したOMSホストおよびポートが、他の管理エージェントのデプロイに使用したOMSホストおよびポートと一致しない場合。

- この管理エージェントで監視する1つ以上のターゲットを削除したか、この管理エージェントで監視する新しいターゲットを追加した場合。この問題を解決するには、新しい構成が有効になるようにこの管理エージェントを再構成します。

- この管理エージェントとともにデプロイしたプラグインのバージョンが、他の管理エージェントとともにデプロイしたプラグインのバージョンと異なる場合。この問題を解決するには、この管理エージェントを正しいプラグインのバージョンとともに再度デプロイします。

再構成が必要な管理エージェントを識別するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「その他のリンク」セクションで、「再構成が必要なエージェント」をクリックします。

4. 「再構成が必要なエージェント」ページに、再構成が必要な管理エージェントが表示されます。表には、管理エージェントのリストのみでなく、次の再構成の理由も表示されます。

- OMSホストおよびポートの不一致
管理エージェントのデプロイに使用したOMSホストおよびポートが、他の管理エージェントのデプロイに使用したOMSホストおよびポートと一致しないことを示します。この問題を解決するには、「新規Enterprise Managerシステムのホストとポートの識別」ページにアクセスしてOMSホストおよびポートを修正し、この管理エージェントを再度デプロイします。

- ターゲットの削除または追加
この管理エージェントで監視する1つ以上のターゲットを削除したか、この管理エージェントで監視する新しいターゲットを追加したことを示します。この問題を解決するには、新しい構成が有効になるようにこの管理エージェントを再構成します。

- プラグイン・バージョンの不一致
この管理エージェントとともにデプロイしたプラグインのバージョンが、他の管理エージェントとともにデプロイしたプラグインのバージョンと異なることを示します。この問題を解決するには、この管理エージェントを正しいプラグインのバージョンとともに再度デプロイします。

10.6.7 Enterprise Manager 12cでサポートされないOracle Management Agentの特定

管理エージェントが実行されているプラットフォームに対してコア・エージェント・ソフトウェアがリリースされていない場合、これらの管理エージェントはEnterprise Manager 12cでサポートされません。技術的に言うと、これらのエージェントで監視されるターゲットは、アップグレードしたEnterprise Managerシステムで監視できなくなります。

Enterprise Manager 12cでサポートされない管理エージェントを特定するには、次の手順に従います。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「その他のリンク」セクションで、「Enterprise Manager 12cでサポートされていないエージェント」をクリックします。

4. 「Enterprise Manager 12cでサポートされていないエージェント」ページに、Enterprise Manager 12cでサポートされていない管理エージェントが表示されます。

10.6.8 リポジトリ・バックアップ後にインストールされるOracle Management Agentの特定

2システム・アップグレード方式を使用して管理エージェントをEnterprise Manager 12cにアップグレードする際、エージェントがリポジトリ・バックアップ後にインストールされる場合は、これらのエージェントはEnterprise Manager 12cシステムに移行できません。これらの12c管理エージェントを12cシステムからプッシュして、これらのターゲットを再検出する必要があります。

Enterprise Manager 12cでサポートされない管理エージェントを特定するには、次の手順に従います。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「その他のリンク」セクションで、リポジトリ・バックアップ後にインストールされるエージェントをクリックします。

4. リポジトリ・バックアップ後にインストールされるエージェントのページで、リポジトリ・バックアップ後にインストールされるエージェントを表示します。

10.6.9 破損したターゲットの特定

破損したターゲットは、Enterprise Manager 12cシステムからデプロイされた管理エージェントが、以前は古い管理エージェントで監視されていたターゲットを、監視する位置にないことを示しています。

破損したターゲットを特定するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「その他のリンク」セクションで、「破損したターゲット」をクリックします。

4. 「破損したターゲット」ページで、破損したターゲットのリストを表示します。この表は破損したターゲットをリストするだけでなく、破損したターゲットの理由、ターゲットのタイプ、エージェントの名前、プラグインの名前、およびプラットフォームも示します。

10.7 Enterprise Managerシステムをアップグレードするためのリポジトリ・バックアップの詳細指定

注意:
2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

Oracle Management Repositoryをバックアップした場合の情報を指定するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「アップグレード・タイプの選択」セクションで、2システムを選択します。これらのアップグレード方式の詳細は、第2章を参照してください。
Enterprise Manager Grid Controlでページがリフレッシュされ、選択したアップグレード方式で実行する必要があるタスクのリストとともに表が表示されます。

4. OMSおよびリポジトリ・アップグレード・ステップ・セクションの表からリポジトリ・バックアップ詳細の指定をクリックします。

5. リポジトリ・バックアップ詳細の指定ページで、Oracle Management Repositoryをバックアップした日時を指定します。

注意:
入力するバックアップ時間が、既存のManagement Repositoryが属するタイムゾーンに基づいていることを確認してください。
管理リポジトリが存在する地域のタイムゾーンとは異なるタイムゾーンにある時計でバックアップ時間を書き留める場合は、その管理リポジトリが属するタイムゾーンのタイム・スタンプに必ず変更してください。

たとえば、アメリカ/ニューヨークのタイムゾーンのタイム・スタンプ1999-12-01 11:00:00をアメリカ/ロサンゼルスのタイム・ゾーンに変換するには、次の問合せを実行します。この問合せの結果には、アメリカ/ロサンゼルスのタイム・ゾーンの時間が表示されます。

SELECT FROM_TZ(CAST(TO_DATE('1999-12-01 11:00:00', 'YYYY-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York') AT TIME ZONE 'America/Los_Angeles' "West Coast Time" FROM DUAL;

6. 「保存」をクリックします。

11 Oracle Management Agent 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

この章では、Oracle Management Agentをアップグレードする方法について説明します。特に、次の内容について説明します。

- Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイおよび構成

- デプロイしたOracle Management Agent 12cリリース5 (12.1.0.5)の状態レポートの生成

- デプロイしたOracle Management Agent 12cリリース5 (12.1.0.5)の状態レポートの検証とサインオフ

- Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバー

11.1 Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイおよび構成

この項の内容は次のとおりです。

- Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイと構成を開始する前に

- Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイおよび構成

11.1.1 Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイと構成を開始する前に

Oracle Management Agentをデプロイおよび構成する前に、次の点に留意してください。

- 問題のある管理エージェントに対しては、Oracle Management Agent 12cをデプロイおよび構成できません。問題のある管理エージェントを識別する方法の詳細は、第10.6.5項を参照してください。

- 完全にアップグレード可能な既存の管理エージェントに対してのみ、Oracle Management Agent 12cのデプロイおよび構成を行う必要があります。管理エージェントが完全にアップグレード可能かどうかを識別する方法の詳細は、第10.6.3項を参照してください。

- 2システム・アップグレードの場合は、Oracle Management Agent 12cをリモートOMSホストにデプロイしないでください。これは、Oracle Management Service 12cのインストール中に、Enterprise Managerインストーラによって自動的にインストールされます。

- 1システム・アップグレードの場合は、アップグレード前コンソールを使用して中央エージェント用のOracle Management Agent 12cをデプロイします。中央エージェントは、古いOMSとともにインストールされた管理エージェントです。
ただし、2システム・アップグレードおよび異なるホストでの1システム・アップグレードの場合、アップグレード前コンソールを使用してそのリモート・ホスト上にOracle Management Agent 12cを中央エージェントとしてデプロイしないでください。かわりに、Enterprise Manager Cloud Controlインストール・ウィザードを使用して、OMSとともに管理エージェントをインストールします。アップグレード前コンソールでは、中央エージェントは選択できますが、デプロイメントおよび構成ジョブに進むことはできません。ジョブの発行を試みると、選択した中央エージェントが検証され、アップグレードできない問題のあるエージェントとしてレポートされます。中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。

- ソフトウェア・バイナリをデプロイおよび構成するには管理エージェント資格証明が必要で、root.shスクリプトを実行するにはルート資格証明が必要です。これに関して、次のケースがサポートされています。

- ユースケース1: エージェント資格証明とルート資格証明を持っています。この場合、正常にデプロイおよび構成できます。

- ユースケース2: エージェント・ユーザー名とルート・ユーザー名は持っていますが、それぞれのパスワードは持っていません。ただし、環境にSUDOまたはPowerBrokerユーティリティがインストールされており、別のユーザーにスイッチオーバーできます。
この場合も、正常にデプロイおよび構成できます。環境にインストールされている内容に応じてSUDOまたはPowerBrokerを使用して、必要な権限を持つ別のユーザー・アカウントにスイッチオーバーできます。

- ユースケース3: エージェント資格証明は持っていますが、ルート資格証明は持っておらず、環境にSUDOまたはPowerBrokerユーティリティはありません。
この場合も、正常にデプロイおよび構成できます。エージェントのデプロイと構成ウィザードの「エージェント資格証明」セクションに、手順(10)および図11-1に示すように、エージェント資格証明を入力します。

図11-1 エージェント資格証明

次に、ウィザードの「オプションの詳細」ページの「ルート資格証明」セクションに、手順(16)および図11-2に示すように、任意のダミー・ユーザー名とパスワードを入力します。

図11-2 ルート資格証明

デプロイメントと構成を続行します。デプロイメントは成功しますが、root.shスクリプトは実行されない点に注意してください。ルート・パスワードが正しくないことおよびルート・スクリプトが実行されなかったことを示すメッセージが表示され、アップグレード・ジョブのいずれかの手順が失敗します。エラーを無視して続行します。

デプロイメント後、ルート資格証明を持つ管理者に連絡して、各管理エージェントでこのroot.shスクリプトを手動で実行するようリクエストします。

注意:
root.shスクリプトはデプロイメント後いつでも実行可能であり、必ずしもデプロイメント後すぐに実行する必要はありません。スクリプトが実行されなくてもアップグレード・プロセスは影響を受けず、ヘルス・チェック、サインオフ、スイッチオーバーの各操作は問題なく機能します。ただし、Enterprise Manager Cloud Controlを使用する前にスクリプトを実行することを強くお薦めします。そうしないと、管理エージェントでジョブを実行できず、nmoエラーが表示されます。

- Oracle Management Agent 12cをデプロイおよび構成する場合、古い管理エージェントとOMS間の既存の接続が使用されます。SSHは使用されません。

- 2システム・アップグレードで、管理リポジトリのバックアップ前に古い管理エージェントを保護(または非保護)モードで実行していた場合、新しい管理エージェントをデプロイおよび構成している間は、古い管理エージェントを必ず以前と同じモードで実行するようにしてください。管理リポジトリのバックアップ後に、管理エージェントを再保護しないでください。再保護した場合、リポジトリに保管されている構成と管理エージェントの実際の構成との不整合により、ヘルス・チェックの実行中にPingテストが失敗する可能性があります。gcagent.logにKEY_MISMATCHエラーが書き込まれます。このエラーの詳細およびこの問題を回避して管理エージェントを保護する方法については、付録Iを参照してください。

- 2システム・アップグレードでは、古い管理リポジトリのクローニング(またはバックアップの作成)後に、管理エージェントに対して構成変更を行わないでください。変更した場合は、管理エージェントを再デプロイおよび再構成する必要があります。管理エージェントのを再デプロイおよび再構成にもかかわらず、スイッチオーバー・プロセス中にエラーが発生する場合は、Enterprise Manager Grid Controlコンソール(旧EMコンソール)をログアウトしてからログインして、スイッチオーバー・プロセスを再試行します。

11.1.2 Oracle Management Agents 12cリリース5 (12.1.0.5)のデプロイおよび構成

Oracle Management Agent 12cをデプロイするには、次の手順を実行します。

注意:
旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「アップグレード・タイプの選択」セクションで、次のいずれかを選択します。これらのアップグレード方式の詳細は、第2章を参照してください。

- 手動で管理エージェントをインストールする場合でも停止時間でEnterprise Managerシステムをアップグレードするには、「1システム」を選択します。

- 手動で管理エージェントをインストールする場合でも停止時間をほとんど発生させずにEnterprise Managerシステムをアップグレードするには、2システムを選択します。

- 異なるホストの停止時間でEnterprise Managerシステムをアップグレードするには、異なるホストの1システムを選択します。

Enterprise Manager Grid Controlでページがリフレッシュされ、選択したアップグレード方式で実行する必要があるタスクのリストとともに表が表示されます。

4. 「アップグレード前のステップ」セクションで、エージェントのデプロイおよび構成をクリックします。

5. エージェントのデプロイおよび構成ページの「操作名」で、実行するデプロイメント操作の一意の名前を入力します。入力するカスタム名は直観的な名前にすることができ、必ずしもデフォルトの名前と同じフォーマットにする必要はありません。
たとえば、Deploy_Agents_Phase1_2015_7_23などです。

注意:
ここで入力する操作名は論理名のみで、実行する操作の詳細を保存するために使用されます。Oracle Management Agent 12cのソフトウェア・バイナリをデプロイした後、デプロイした管理エージェントの状態を確認するか、古い管理エージェントから新しくデプロイおよび構成した管理エージェントにスイッチオーバーする場合、操作名を使用して、この操作の一部として選択された管理エージェントを識別および追跡できます。

6. 「操作タイプの選択」セクションで、エージェントおよびプラグイン・ソフトウェアのデプロイおよびエージェントおよびプラグイン・ソフトウェアの構成を選択します。

注意:
管理エージェントのソフトウェア・バイナリをすでにデプロイしている場合、今すぐの構成のみを選択できます。この場合、エージェントおよびプラグイン・ソフトウェアの構成のみを選択します。

7. エージェントの検索セクションで、ソフトウェアをデプロイする既存の古い管理エージェントを検索および追加します。管理エージェントの検索および追加方法の詳細は、付録Hを参照してください。

注意:

- 管理エージェントのソフトウェア・バイナリをすでにデプロイし、この時点で構成のみを行っている場合、すでに手動でソフトウェアをデプロイしている管理エージェントを検索(または追加)および選択します。

- 共有エージェントを追加する場合は、この共有エージェントが通信するマスター・エージェントを追加する必要があります。また、すべての共有エージェントがこのマスター・エージェントと通信することを確認してください。

- 2システム・アップグレードおよび異なるホストでの1システム・アップグレードの場合、中央エージェントは選択肢としてリストされますが、選択してデプロイメントおよび構成ジョブの発行を試みると、選択した中央エージェントが検証され、問題のあるエージェントとしてレポートされます。そのため、それらはデプロイまたは構成できないため、結果としてスイッチオーバーできません。中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。

- この画面に戻ってデプロイ操作を再試行する場合、以前のデプロイ操作の一部として選択された管理エージェントが表示されます。これは予測されている動作です。それらのソフトウェア・バイナリの再デプロイまたはリストからの削除および新しい一連の管理エージェントの追加を選択できます。

8. 管理エージェントをリストする表で、各管理エージェントのインストールのベース・ディレクトリおよびインスタンス・ホーム・ディレクトリを入力します。

注意:

- ここで入力するインストールのベース・ディレクトリがミドルウェア・ホーム内にないことを確認します。

- インストールのベース・ディレクトリに少なくとも1GBの空きディスク領域があることを確認します。

- 管理エージェントのソフトウェア・バイナリをすでにデプロイし、この時点で構成のみを行っている場合、ソフトウェア・バイナリをデプロイした同じインストールのベース・ディレクトリおよびインスタンス・ホーム・ディレクトリを入力します。

- インストールしているユーザーがエージェント・ベース・ディレクトリを所有していることを確認します。インストールしているユーザーまたはrootユーザーがすべての親ディレクトリを所有していることを確認します。rootユーザーがrootディレクトリの所有者であることを確認します。また、これらのすべてのディレクトリにグループおよび他のユーザーに対する読取り権限と実行権限があることを確認します。
たとえば、エージェント・ベース・ディレクトリが/scratch/OracleHomes/agentで、インストールしているユーザーがoracleの場合、/scratch/OracleHomes/agentディレクトリはoracleが、scratchおよびOracleHomesディレクトリはoracleまたはrootユーザーが、ルート・ディレクトリ(/)はrootユーザーが所有している必要があります。また、ディレクトリ/, scratch,およびOracleHomesには読取り権限と実行権限があります。

必要に応じて、これらの追加のオプションを選択します。

- インストールのベース・ディレクトリおよびインスタンス・ホーム・ディレクトリのパスを管理エージェント間で同じにする場合、「すべてのエージェントに同じパスを使用」を選択して、表にリストされた最初の管理エージェントのインストールのベース・ディレクトリおよびインスタンス・ホーム・ディレクトリの絶対パスを一度だけ入力します。Enterprise Manager Grid Controlは、表にリストされた他の管理エージェントに同じパスを検討します。

注意:
ある管理エージェントに示されるインストールのベース・ディレクトリと表の別の管理エージェントに示されるインスタンス・ホーム・ディレクトリでは、「すべてのエージェントに同じパスを使用」を選択できません。最初の管理エージェントに指定されたパスのみ、表の他の管理エージェントの同じパスとみなされます。

- 指定されたエージェントのベース・ディレクトリまたはエージェントのインスタンス・ホーム・ディレクトリがすでに存在し上書きする場合、既存のディレクトリの上書きを選択します。通常、同じベース・ディレクトリのソフトウェア・バイナリの再デプロイの選択時にこのオプションを選択します。

- すべてのデプロイメントおよび構成関連の前提条件チェックを無視する場合は、「デプロイ前提条件の無視」を選択します。「デプロイ前提条件の無視」オプションを選択してエージェントをデプロイする前には、デプロイを確実に成功させるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているように、すべてのエージェント・インストール前提条件チェックを手動で実行する必要があります。

- 失敗したデプロイメントのすべてのトレースをクリーンアップするには、「失敗したデプロイメントのクリーンアップ」を選択します。これによって、すべてのファイル、ディレクトリおよび失敗したデプロイメントのログ・ファイルもクリーンアップされることに注意してください。そのため、すべてのデータが失われることを確認している場合にのみこのオプションを選択してください。

9. 管理エージェントの追加後、「選択」列から個別に選択します。

10. 管理リポジトリに格納されている優先資格証明をこのジョブに使用できるように、「エージェント資格証明」セクションで、デフォルトで選択されている「Oracleホーム優先資格証明を使用」を保持します。

注意:
Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用して、優先資格証明がEnterprise Managerシステムに登録されたことを確認します。詳細は、付録Fを参照してください。

これらの優先資格証明をオプションでオーバーライドできます。そのためには、「Oracleホーム優先資格証明のオーバーライド」を選択して、すべてのOracleホームで使用できる1セットの資格証明を入力します。

注意:
既存の、以前のリリースの管理エージェントに使用したものと同じ資格証明を必ず使用してください。

11. 「実行権限」セクションでは、デフォルトで「なし」が選択され、前のステップで指定した資格証明がこのジョブを実行する権限を持つとみなされます。
ただし、それらの資格証明にこのジョブを実行する権限がない場合およびこのために別のユーザーとしてスイッチオーバーする場合、使用する認証ユーティリティに応じて「SUDO」または「Power Broker」を選択して、ユーザー・アカウント名およびプロファイルを指定します。

12. (2システム・アップグレードのみに適用可) 「OMSホストとポート」セクションで、Oracle Management Service 12cをインストールするホストの名前およびセキュア・ポートを検証します。値を変更するには、「編集」をクリックします。

注意:
既存のOMSからOracle Management Service 12cにすでにアップグレードしている場合、ここで入力するポートがOMSのアップグレード時にインストーラで選択または指定したEnterprise ManagerアップロードHTTP SSLポートと一致していることを確認します。

13. 「次へ」をクリックします。

14. 管理エージェントのソフトウェア・バイナリをデプロイする前にスクリプトを実行する場合は、「オプションの詳細」ページの「事前デプロイ・オプション(オプション)」セクションで、「事前コマンド/スクリプトの実行」を選択します。
スクリプトを使用できる宛先ホストの場所への絶対パスを入力します。スクリプトを共有された場所にも配置できますが、スクリプトを実行する実行権限が必要になります。

注意:
デフォルトで、ステップ(10)で指定された資格証明がスクリプトの実行に使用されます。デフォルトで「なし」が選択され、資格証明がスクリプトを実行する権限を持つとみなされます。
ただし、それらの資格証明にスクリプトを実行する権限がない場合およびこのために別のユーザーとしてスイッチオーバーする場合、使用する認証ユーティリティに応じて「SUDO」または「Power Broker」を選択して、ユーザー・アカウント名およびプロファイルを指定します。

15. デプロイした管理エージェントを構成した後にスクリプトを実行する場合は、「構成後オプション(オプション)」セクションで、「事後コマンド/スクリプトの実行」を選択します。
スクリプトを使用できる宛先ホストの場所への絶対パスを入力します。スクリプトを共有された場所にも配置できますが、スクリプトを実行する実行権限が必要になります。

注意:
デフォルトで、ステップ(10)で指定された資格証明がスクリプトの実行に使用されます。デフォルトで「なし」が選択され、資格証明がスクリプトを実行する権限を持つとみなされます。
ただし、それらの資格証明にスクリプトを実行する権限がない場合およびこのために別のユーザーとしてスイッチオーバーする場合、使用する認証ユーティリティに応じて「SUDO」または「Power Broker」を選択して、ユーザー・アカウント名およびプロファイルを指定します。

16. (UNIXのみ) root資格証明セクションで、root.shスクリプトを実行するユーザー・アカウントの資格証明を入力します。

注意:
デフォルトで「なし」が選択され、資格証明がスクリプトを実行する権限を持つとみなされます。ただし、それらの資格証明にスクリプトを実行する権限がない場合およびこのために別のユーザーとしてスイッチオーバーする場合、保有する認証ユーティリティに応じて「SUDO」または「Power Broker」を選択して、ユーザー・アカウント名およびプロファイルを指定します。
root資格証明がない場合は、エージェント資格証明を入力します。この場合、root.shスクリプトは実行されませんが、デプロイは正常に行われます。必ず、デプロイ後にこのスクリプトを手動で実行してください。実行しないと、管理エージェントでジョブを実行することができません。

17. 「送信」をクリックします。

警告:

管理エージェントのデプロイおよび構成後に、たとえば、メトリックのしきい値、ジョブの定義、テンプレートなどの構成変更は行わないでください。変更した場合、新しいEnterprise Managerシステムにスイッチオーバーするときにこれらの変更内容は継承されず、変更内容を転送する唯一の方法は、新しい管理エージェントを再構成することです。それらを再構成するには、手順(6)の注意を参照してください。

注意:

- 操作を送信した後、次のエラーが表示される場合、古い管理エージェントのホームからroot.shを実行してから、この操作を再送信します。

ERROR: NMO not setuid-root (Unix-only)

- 次のエラーが表示される場合は、ステップ(10)で入力した資格証明を検証します。

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- デプロイメント操作が特定の時点で失敗した場合、管理エージェントの再構成のみ選択でき、ソフトウェア・バイナリの再コピーは選択できません。管理エージェントの再構成のみ実行するには、この手順の指示を繰り返して、ステップ(6)で「エージェントとプラグイン・ソフトウェアの構成」のみ選択していることを確認します。

- 操作が進行中でデプロイおよび構成されている管理エージェントがなんらかの理由で使用できない場合、「イベント時に一時停止」ステータスが表示される場合があります。管理エージェントが使用可能になると、ステータスが自動的に現在の状態に変更されます。これは予測されている動作です。

- ステップ(10)で入力した資格証明が正しくない場合、事前デプロイ・ジョブのroot.shスクリプトを実行するステップは失敗しますが、このジョブ自体は成功したと表示されます。このような場合は、正しいroot資格証明を使用して手動でroot.shスクリプトを実行してください。実行しないと、管理エージェントはNMOエラーを発生します。

- 問題がある場合は、付録Mに示されているログ・ファイルを参照してください。

11.2 デプロイしたOracle Management Agent 12cリリース5 (12.1.0.5)の状態レポートの生成

古い既存の管理エージェントから新しくデプロイおよび構成したOracle Management Agent 12cにスイッチオーバーする前に、デプロイメントの問題を事前に特定できるよう、デプロイした管理エージェントの状態および準備状況を確認するレポートを生成します。

正常にスイッチオーバーしてアップグレードしたEnterprise Managerシステムで適切に機能するすべての管理エージェントに対して、管理エージェントがアップグレードしたOracle Management Serviceに接続し、以前に監視したすべてのターゲットを監視して、以前に収集したすべてのメトリック詳細を収集できることを確認する必要があります。状態レポートを使用すると、これらの要件に関連する問題を識別でき、事前に解決できます。

注意:
旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

注意:
正常にデプロイおよび構成した管理エージェントの状態レポートのみ生成できます。

デプロイした管理エージェントの状態レポートを生成し、準備状況を確認するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「エージェントのアップグレード・ステータス」セクションの表からデプロイしたエージェントの状態レポートの生成をクリックします。

4. デプロイしたエージェントの状態レポートの生成ページの入力の指定セクションで、次の手順を実行します。

1. 実行するデプロイメント操作の一意の名前を入力します。入力するカスタム名は直観的な名前にすることができ、必ずしもデフォルトの名前と同じフォーマットにする必要はありません。
たとえば、CheckHealth_Agents_Phase1_2015_7_23などです。

注意:
ここで入力する操作名は論理名のみで、実行する操作の詳細を保存するために使用されます。デプロイした管理エージェントの状態を確認した後、古い管理エージェントから新しくデプロイおよび構成した管理エージェントにスイッチオーバーする場合、操作名を使用して、この操作の一部として選択された管理エージェントを識別および追跡できます。

2. 以前にデプロイした管理エージェントの準備状況の確認を実行する場合、「以前の操作からのエージェントのロード」の懐中電灯アイコンをクリックし、それらの管理エージェントのデプロイのために送信した操作を選択して、「実行」をクリックします。
Enterprise Manager Grid Controlで、選択した操作に関連付けられている管理エージェントのリストがエージェントの検索セクションの表に移入されます。

5. エージェントの検索セクションで、準備状況の確認を実行する管理エージェントを検索および追加します。

- ステップ4(a)に従って準備状況の操作名を指定した場合、すでにソフトウェアをデプロイしていて今すぐ状態を確認する既存の古い管理エージェントを検索(または追加)および選択します。管理エージェントの検索および追加方法の詳細は、付録Hを参照してください。

- ステップ4(b)に従ってデプロイメント操作を選択した場合、選択した操作に基づいて表示される管理エージェントを確認します。

6. 管理エージェントの追加後、「選択」列から個別に選択します。

7. 管理リポジトリに格納されている優先資格証明をこのジョブに使用できるように、「エージェント資格証明」セクションで、デフォルトで選択されている「Oracleホーム優先資格証明を使用」を保持します。

注意:
Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用して、優先資格証明がEnterprise Managerシステムに登録されたことを確認します。詳細は、付録Fを参照してください。

これらの優先資格証明をオプションでオーバーライドできます。そのためには、「Oracleホーム優先資格証明のオーバーライド」を選択して、すべてのOracleホームで使用できる1セットの資格証明を入力します。

注意:
既存の、以前のリリースの管理エージェントに使用したものと同じ資格証明を必ず使用してください。

8. 「送信」をクリックします。

注意:

- 操作を送信した後、次のエラーが表示される場合、古い管理エージェントのホームからroot.shを実行してから、この操作を再送信します。

ERROR: NMO not setuid-root (Unix-only)

- 次のエラーが表示される場合は、ステップ(10)で入力した資格証明を検証します。

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- 操作の進行中に、準備状態を確認している管理エージェントがなんらかの理由で使用できない場合、「イベント時に一時停止」ステータスが表示される場合があります。管理エージェントが使用可能になると、ステータスが自動的に現在の状態に変更されます。これは予測されている動作です。

- Enterprise Managerの旧リリースでSOAターゲットを監視していた場合は、状態レポートに、次のメトリックのメトリック収集エラーが表示される場合があります。

- SOAの上位SQL問合せ

- デハイドレーション・ストア表

この段階では、これらのエラーを無視して先に進むことができます。ただし、第13.6項の説明に従って、このターゲットのデータベース資格証明を必ず入力してください。

- 問題がある場合は、付録Mに示されているログ・ファイルを参照してください。

11.3 デプロイしたOracle Management Agent 12cリリース5 (12.1.0.5)の状態レポートの検証とサインオフ

古い既存の管理エージェントから新しくデプロイおよび構成したOracle Management Agent 12cにスイッチオーバーする前に、デプロイした管理エージェントの状態レポートを確認し、サインオフします。

正常にスイッチオーバーしてEnterprise Manager Cloud Controlで適切に機能するすべての管理エージェントに対して、管理エージェントがアップグレードしたOracle Management Service(OMS)に接続し、以前に監視したすべてのターゲットを監視して、以前に収集したすべてのメトリック詳細を収集できることを確認する必要があります。状態レポートを使用すると、これらの要件に関連する問題を識別でき、事前に解決できます。

注意:
旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

状態レポートを検証し、サインオフするには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページのエージェントのアップグレード・ステップ・セクションの表からデプロイしたエージェントの状態レポートのサインオフをクリックします。

4. デプロイしたエージェントの状態レポートのサインオフ・ページで、各管理エージェントの状態および準備状況の詳細を表示します。

- デプロイしたOracle Management Agent 12cがアップグレードしたOMSに接続できるかどうかを示す「Pingテスト」列を検証します。

注意:

1システム・アップグレード方式および異なるホストでの1システム・アップグレード方式の場合、「Pingテスト」列に、値「N/A」が表示されます。

2システム・アップグレードの場合は、「成功」または「失敗」が表示されます。ステータス「成功」はPingテストが成功したことを示し、ステータス「失敗」はテストが成功しなかったことを示します。いずれかの管理エージェントのステータスが「失敗」の場合は、次の操作を実行します。

- 「新規Enterprise Managerシステムのホストとポートの識別」ページで入力したOMSホスト名およびOMSポートを検証します。
または、次のファイルのREPOSITORY_URLパラメータを検証します。

<Agent_Instance_Home>/sysman/config/emd.properties

次に例を示します。

/u01/app/Oracle/agent/agent_inst/sysman/config/emd.properties

OMSのホスト名およびポートが正しい場合は、次のログ・ファイルにエラーが記録されていないか確認します。

<Agent_Instance_Home>/sysman/log/gcagent.log

次に例を示します。

/u01/app/Oracle/agent/agent_inst/sysman/log/gcagent.log

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』で説明されているように、ここでは、<Agent_Instance_Homeは12cエージェント・インスタンス・ディレクトリを指しています。

- いずれかの管理エージェントが非保護モードで、OMSをアップグレード済の場合は、アップグレード済のOMS (12c OMS)上で次のコマンドを実行し、ヘルス・チェック・レポートをもう一度生成した後、スイッチオーバーを行います。
$<OMS_HOME>/bin/emctl secure unlock -console

次に例を示します。

/u01/app/Oracle/Middleware/oms/bin/emctl secure unlock -console

$<OMS_HOME>/bin/emctl secure unlock -upload

次に例を示します。

/u01/app/Oracle/Middleware/oms/bin/emctl secure unlock -upload

注意:
2システム・アップグレード方式で、管理リポジトリのバックアップ前に古い管理エージェントを保護(または非保護)モードで実行していた場合、新しい管理エージェントをデプロイおよび構成している間は、古い管理エージェントを必ず以前と同じモードで実行するようにしてください。そうしない場合、リポジトリに保管されている構成と管理エージェントの実際の構成との不整合により、Pingテストが失敗する可能性があります。

- デプロイしたOracle Management Agent 12cが古い管理エージェントで監視されていたすべてのターゲットを監視できるかどうかを示す「破損したターゲット」列を検証します。列の数値は、アップグレードしたシステムで監視できないターゲットの数を示しています。
ゼロ以外の値が表示される場合、次のステップに従って詳細レポートを表示して、破損したターゲットのリストおよび破損の理由を表示します。

- デプロイおよび構成したOracle Management Agent 12cがアップグレードしたEnterprise Managerシステムですべてのメトリックを収集できるかどうかを示す「失敗したメトリック」列を検証します。列の数値は、問題のあるメトリックの数を示しています。
ゼロ以外の値が表示される場合、次のステップに従って詳細レポートを表示して、失敗したメトリックのリストおよび失敗の理由を表示します。

- 管理エージェントの状態レポートがサインオフされたかどうかを示すサインオフ・ユーザー列および「ユーザー検証済」列を検証します。これらの列に値が表示されない場合、ステップ(6)に従ってレポートを正規にサインオフします。

5. 詳細レポートを表示する場合、詳細レポートを表示する管理エージェントを選択して、詳細レポートの表示をクリックします。

6. レポートを確認した後、レポートの検証およびサインオフをクリックしてサインオフします。詳細レポートを表示した管理エージェントが選択されていることを確認します。

注意:

- 操作を送信した後、次のエラーが表示される場合、古い管理エージェントのホームからroot.shを実行してから、この操作を再送信します。

ERROR: NMO not setuid-root (Unix-only)

- 次のエラーが表示される場合は、ステップ(10)で入力した資格証明を検証します。

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- Enterprise Managerの旧リリースでSOAターゲットを監視していた場合は、状態レポートに、次のメトリックのメトリック収集エラーが表示される場合があります。

- SOAの上位SQL問合せ

- デハイドレーション・ストア表

この段階では、これらのエラーを無視して先に進むことができます。

11.4 Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバー

この項の内容は次のとおりです。

- Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバー

- Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバーに関連する問題のトラブルシューティング

11.4.1 Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバー

Enterprise Manager Cloud Controlと通信できるように、既存の以前のリリースのOracle Management Agent (管理エージェント)を新しくデプロイされた管理エージェントにスイッチオーバーするには、次の手順を実行します。

注意:
旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

注意:

- 2システム・アップグレード方式または異なるホストの1システム・アップグレード方式でアップグレードする場合は、スイッチオーバーにおいて、古い中央エージェント(つまり、古いOMSとともにインストールされている管理エージェント)を選択しないでください。
中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。

- エージェント構成がバックアップ後に変更された場合は、管理エージェントを再デプロイおよび再構成する必要があります。構成変更後にこの処理をすでに実行済にもかかわらず、スイッチオーバー・プロセス中にエラーが発生する場合は、Enterprise Manager Grid Controlコンソール(旧EMコンソール)をログアウトしてからログインして、スイッチオーバー・プロセスを再試行します。

- スイッチオーバー・ジョブを停止または取り消して、管理エージェントの同じセットに対してジョブをすぐに再発行しないでください。やむを得ず行う場合は、スイッチオーバー操作を再発行する前に、まずデータベースを再起動して、残っているすべてのプロセスをクリーンアップします。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページのエージェントのアップグレード・ステップ・セクションの表からエージェントの切替えをクリックします。

4. エージェントの切替えページの入力の指定セクションで、次の手順を実行します。

1. 実行するスイッチオーバー操作の一意の名前を入力します。入力するカスタム名は直観的な名前にすることができ、必ずしもデフォルトの名前と同じフォーマットにする必要はありません。
たとえば、Switch_Agents_Phase1_2015_7_23などです。

注意:
ここで入力する操作名は論理名のみで、実行する操作の詳細を保存するために使用されます。この操作を送信した後、ステータスを追跡する場合、操作名を使用できます。

2. 以前に準備状況の確認を実行した管理エージェントをスイッチオーバーする場合、以前の操作からのエージェントのロードの懐中電灯アイコンをクリックし、それらの管理エージェントの実行のために送信した操作を選択して、「実行」をクリックします。
Enterprise Manager Grid Controlで、選択した操作に関連付けられている管理エージェントのリストがエージェントの検索セクションの表に移入されます。

5. エージェントの検索セクションで、スイッチオーバーする管理エージェントを検索および追加します。

- ステップ4(a)に従ってスイッチオーバーの操作名を指定した場合、今すぐスイッチオーバーするデプロイした管理エージェントを検索(または追加)および選択します。管理エージェントの検索および追加方法の詳細は、付録Hを参照してください。

注意:
2システム・アップグレード方式または異なるホストの1システム・アップグレード方式でアップグレードする場合は、スイッチオーバーにおいて、古い中央エージェント(つまり、古いOMSとともにインストールされている管理エージェント)を選択しないでください。中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。

- ステップ4(b)に従って操作名を選択した場合、選択した操作に基づいて表示される管理エージェントを確認します。

6. 管理エージェントの追加後、「選択」列から個別に選択します。

7. 管理リポジトリに格納されている優先資格証明をこのジョブに使用できるように、「エージェント資格証明」セクションで、デフォルトで選択されている「Oracleホーム優先資格証明を使用」を保持します。

注意:
Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用して、優先資格証明がEnterprise Managerシステムに登録されたことを確認します。詳細は、付録Fを参照してください。

これらの優先資格証明をオプションでオーバーライドできます。そのためには、「Oracleホーム優先資格証明のオーバーライド」を選択して、すべてのOracleホームで使用できる1セットの資格証明を入力します。

注意:
既存の、以前のリリースの管理エージェントに使用したものと同じ資格証明を必ず使用してください。

8. 「送信」をクリックします。

注意:
スイッチオーバー操作に問題がある場合は、第11.4.2項に従って、トラブルシューティングします。その他の問題の場合は、付録Mに示されているログ・ファイルを参照してください。

9. (2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式にのみ適用)スイッチオーバー後、第13.13項の説明に従って、中央エージェントを削除します。
中央エージェントの削除後、削除した中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。

11.4.2 Oracle Management Agent 12cリリース5 (12.1.0.5)へのスイッチオーバーに関連する問題のトラブルシューティング

スイッチオーバー操作に関連する共通の問題および回避策を次に示します。

- 操作を送信した後、次のエラーが表示される場合、古い管理エージェントのホームからroot.shを実行してから、この操作を再送信します。

ERROR: NMO not setuid-root (Unix-only)

- 次のエラーが表示される場合は、第11.1項の手順(10)で入力した資格証明を検証します。

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- スイッチオーバー操作のRun Presync手順で障害が発生する場合は、次のエラーをemoms.trcトレース・ファイルで確認します。これは、データベース・ドメイン名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字が含まれている場合に発生する可能性があります。たとえば、データベース・ドメイン名にハイフン(-)が含まれている場合に次の問題が発生します。

ORA-20000: Found exception Error Message :ORA-02083: database name has illegal character '-' Error Number ;-2083

この問題を解決するには、付録L.2に示されている手順に従ってください。データベース・ドメイン名にハイフンなどの無効な文字が含まれている場合は、修正します。

- 操作が進行中でデプロイおよび構成されている管理エージェントがなんらかの理由で使用できない場合、「イベント時に一時停止」ステータスが表示される場合があります。管理エージェントが使用可能になると、ステータスが自動的に現在の状態に変更され、最終的にスイッチオーバーされます。これは予測されている動作です。

- 2システム・アップグレード方式では、選択したすべての古い管理エージェントがスイッチオーバーされ、アップグレードしたOMSと通信できるようにアップグレードした管理エージェントが起動します。

- 1システム・アップグレード方式で、管理エージェントをスイッチオーバーしないでOMSを誤ってアップグレードした場合は、まず古い管理エージェントを停止し、次に新しいエージェントを起動して、手動で管理エージェントをスイッチオーバーする必要があります。
(a)古い管理エージェントのホームを停止します。

$<AGENT_HOME>/bin/emctl stop agent

(b)デプロイしたOracle Management Agent 12cをインスタンス・ホームから起動します。

$<AGENT_INSTANCE_DIR>/bin/emctl start agent

- 管理エージェントのスイッチオーバー後もステータスが停止中と表示される場合には、手動で起動します。
$<AGENT_INSTANCE_DIR>/bin/emctl start agent

- デプロイした管理エージェントを新規Enterprise Managerシステムにスイッチオーバーする際、スイッチオーバー・ジョブがuploadAgent手順で失敗する場合があります。手順がそのエラーで失敗する場合は、次の作業を行います。

1. 管理エージェント・ホストで、次のコマンドを実行します。
cat /dev/null > access_log

2. 管理エージェント・インスタンス・ホームから、次のコマンドを実行し、アップロード操作が成功しているかどうか確認します。アップロード操作が成功するまでこのコマンドを繰り返します。
$<AGENT_INSTANCE_HOME>/bin/emctl upload agent

3. アップロード操作が成功したら、Enterprise Manager Grid Controlコンソールからアップグレード前コンソールにアクセスし、「エージェントのアップグレード処理」セクションで「エージェントの切替え」をクリックします。

4. 「エージェントの切替え」ページで、エラーが発生していた管理エージェントを選択して、スイッチオーバー・ジョブを再度発行します。

- その他の問題の場合は、付録Mに示されているログ・ファイルを参照してください。

12 Oracle Management ServiceおよびOracle Management Repository 10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

この章では、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)のOracle Management Service (OMS)およびOracle Management Repository (管理リポジトリ)をアップグレードする様々な方法について説明します。個々の要件を最も満たす方式を選択して、該当する項に示されている手順に従ってください。

この章の内容は次のとおりです。

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(グラフィック・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(サイレント・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(ソフトウェアのみアップグレード方法の使用、グラフィック・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(ソフトウェアのみアップグレード方法の使用、サイレント・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(異なるホストでの1システム・アップグレード方式)

- 複数OMS環境の10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

12.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(グラフィック・モード)

この項では、アップグレード方式の1つを使用して、グラフィック・モードで、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の既存のOMSおよび管理リポジトリを12cリリース5 (12.1.0.5)にアップグレードする方法について説明します。

特に、次の項目について説明します。

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式、グラフィック・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式、グラフィック・モード)

注意:
OMSとManagement Agentのエントリは、HPUNIX、HPia64、Solaris Sparcを除くすべてのUNIXプラットフォームの/etc/oragchomelistファイルにあります。HPUNIX、HPia64、Solaris Sparcの各プラットフォームでは、エントリは/var/opt/oracle/oragchomelistにあります。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

12.1.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式、グラフィック・モード)

注意:
1システム・アップグレード方式を使用してアップグレードする場合、Enterprise Manager Cloud Controlインストール・ウィザードでは、OMSがインストールされた新規の管理エージェントはインストールされず、既存の管理エージェントもアップグレードされません。管理エージェントは、アップグレード前コンソールを使用して事前にデプロイされます。これは予測されている動作です。

グラフィック・モードで1システム・アップグレード方式を使用して既存のOMSおよび管理リポジトリをアップグレードするには、次の手順を実行します。

1. 既存のOMSが実行されているホストで、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。
<Software_Location>/runInstaller

このコマンドで、<Software_Location>はソフトウェア・キットを解凍した場所です。

注意:

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第5.1.1項を参照してください。

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- runInstallerまたはsetup.exeを起動したとき、Enterprise Manager Cloud Controlインストール・ウィザードが表示されない場合、/stageディレクトリへのアクセス権がない可能性があります。
インストール・ウィザードは、クラスパス変数をOPatch用に../stage/Components/として処理します。TEMP変数が/tmpに設定されているとき、インストール・ウィザードはopatchのJARファイルを/tmp/../stageディレクトリ(/stageと同様)で検索しようとします。しかし、ユーザーに/stageへの権限がないと、インストール・ウィザードはハングします。このような場合、/stageディレクトリへのアクセス権があるかどうかを確認します。アクセス権がない場合、TEMP変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

- IBM AIXでのアップグレード中に、ミドルウェア・ホームのJDKバージョンがサポートされているバージョンではないことを示すエラー・メッセージが表示された場合は、メッセージに記載されているサポートされているバージョンがインストールされていることを確認し、-skipJDKValidation引数を渡してインストーラを起動します。
次に例を示します。

./runInstaller -skipJDKValidation

2. (オプション)「My Oracle Support」画面でMy Oracle Support資格証明を入力し、Oracle Configuration Managerを有効にします。Oracle Configuration Managerをここで有効にしない場合、手順(3)に進みます。
インストール・ウィザードを実行するホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Supportからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを指定するか、My Oracle SupportにアクセスするクライアントからこのURLへのプロキシ・アクセスを付与する必要があることを意味します。

3. 「次へ」をクリックします。

4. 「ソフトウェアの更新」画面で、最新のPSUパッチを含む、最新のソフトウェア更新を適用します。
ソフトウェア更新は、オフライン・モード(インターネット接続がない場合)またはオンライン・モード(インターネット接続がある場合)でダウンロードできます。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

5. 「次へ」をクリックします。

6. 「前提条件チェック」画面で、インストール・ウィザードによって実行された前提条件チェックのステータスを確認し、環境がアップグレード成功のためのすべての最小要件を満たしているかどうかを確認します。
インストール・ウィザードでは、この画面に達すると前提条件チェックが自動的に実行されます。必要なオペレーティング・システム・パッチ、オペレーティング・システム・パッケージなどがチェックされます。

前提条件チェックのステータスは、「警告」、「失敗」または「成功」のいずれかになります。

「警告」または「失敗」 ステータスになったチェックがある場合は、アップグレードを続行する前に問題を調査して修正してください。この画面では、前提条件が満たされなかった理由や解決方法を提供します。問題を修正した後、この画面に戻り、「再実行」をクリックして前提条件を再度チェックします。

7. 「次へ」をクリックします。

注意:
前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、「再実行」をクリックします。インストール・ウィザードによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストール・ウィザードがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

8. 「インストール・タイプ」画面で、「既存のEnterprise Managerシステムのアップグレード」を選択し、次に「1システムのアップグレード」を選択します。次に、アップグレードするOMSホームを選択します。

9. 「次へ」をクリックします。

10. 「インストールの詳細」画面で、次のようにします。

1. ミドルウェア・ホームを入力するか、検証します。

注意:

- Oracle WebLogic Server 11gリリース1(10.3.6)およびJava Development Kit 1.6.0.43.0がまだインストールされていない場合は、これらのインストール先にするディレクトリへの絶対パスを入力します。たとえば、/oracle/software/などです。入力するディレクトリにファイルやサブディレクトリが含まれていないことを確認してください。

- Oracle WebLogic ServerおよびJDKをインストール済の場合は、サポートされているリリース(Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0)であることを確認してください。サポートされているリリースの場合は、インストーラによって検出され、インストール先のミドルウェア・ホームに表示されます。このミドルウェア・ホームへのパスを検証します。インストーラでは、Enterprise Managerがまだ構成されていないミドルウェア・ホームのみが検出され、表示されます。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を手動でインストールする場合は、第3章で説明されているガイドラインに従ってください。

2. ホスト名を検証します。デフォルトでは、ホスト名は、既存の旧リリースのEnterprise Managerがインストールされていたホストの名前です。これは編集不可フィールドです。

11. 「次へ」をクリックします。

12. 「データベース接続の詳細」画面で、次のようにします。

- 選択したOMSの管理リポジトリが格納されているデータベースのSYSおよびSYSMANユーザー・アカウントのパスワードを入力します。

- Oracle Management Repository(管理リポジトリ)をバックアップしたことを確認します。前提条件として、アップグレード・プロセスを開始する前に、管理リポジトリをバックアップする必要があります。まだバックアップを取っていない場合は、ただちに実行し、その後、インストーラに戻ってアップグレードを続行してください。

注意:
この時点でデータベースで実行される様々な前提条件チェックの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

13. 「次へ」をクリックします。

注意:
プロビジョニング・アーカイブ・フレームワーク(PAF)の前提条件チェック・エラーが発生したら、インストーラを終了し、既存のEnterprise Managerシステムで実行中およびスケジュール済のすべてのデプロイメント・プロシージャを停止してから、インストーラをもう一度起動し、アップグレード・プロセスを再試行します。
実行およびスケジュールされているデプロイメント・プロシージャをすべて特定するには、次の問合せを実行して、そのデプロイメント・プロシージャのGUIDを書き留めます。

SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s, SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p WHERE p.procedure_guid = i.procedure_guid AND s.instance_guid = i.instance_guid AND s.state_type = 0 AND s.status in (0,1)

実行およびスケジュールされているデプロイメント・プロシージャを停止するには、次の問合せを実行して、前述のコマンドの出力から書き留めたGUIDを渡します。

emcli stop_instance -instance=<instance id from sql query>

14. 「プラグインの選択」画面で、OMSのアップグレード中に自動的にインストールされるプラグイン以外にデプロイするオプション・プラグインを選択します。

注意:
事前選択済の行には、アップグレード前コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたプラグインも含まれる場合があります。
ただし、事前選択済の行にインストール済のプラグインが含まれていない場合は、これらのプラグインがソフトウェア・キット(DVD、ダウンロードしたソフトウェア)に含まれていないことを意味しています。

この画面にリストされていないプラグインをインストールする場合は、次の手順に従います。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションを指定してインストーラを起動し、ダウンロードしたプラグインのある場所を渡します。
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)でサポートされていない、旧リリースのEnterprise Managerにデプロイされたプラグイン・バージョンを保有している場合があります。この場合は、インストーラを-pluginLocation引数で起動する際に、サポートされていないプラグインよりも上位のバージョンのソフトウェアを提供しないようにしてください。その上位バージョンがダウンロード可能な場合でも同様です。これによって、12cリリース5 (12.1.0.5)へのアップグレード中に、サポートされていないバージョンが確実に削除されます。アップグレード後、上位のバージョンをプラグイン・マネージャから直接デプロイできます。

15. 「次へ」をクリックします。

16. WebLogic Server構成の詳細を指定します。

- Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合は、「WebLogic Server構成の詳細」画面で、WebLogic Serverユーザー・アカウントおよびノード・マネージャ・ユーザー・アカウントの資格証明を入力し、OMSインスタンス・ベースの場所へのパスを検証します。

注意:

- パスワードはスペースを含めず8文字以上とします。先頭は文字とし、数字を1つ以上含めるようにしてください。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

デフォルトでは、WebLogicドメイン名はGCDomainで、ノード・マネージャ名はnodemanagerです。これらは編集できないフィールドです。インストーラはこの情報を使用して、Oracle WebLogicドメインおよびその他の関連コンポーネント(管理サーバー、管理対象サーバー、ノード・マネージャなど)を作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、管理サーバーのホスト名およびそのポートと、WebLogicユーザー名を検証し、WebLogicユーザー・アカウント・パスワードを入力します。これは、新規WebLogicドメイン(GCDomain)を、アップグレードしている旧リリースのOMSで使用された管理サーバーと同じポートおよびホスト名で作成するために必要です。

注意:
NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

- 10gリリース5(10.2.0.5)または11gリリース1(11.1.0.1)から追加のOMSをアップグレードする場合は、最初にアップグレードしたOMS用に構成したホスト名と管理サーバー・ポートを入力し、既存のWebLogic Serverユーザー・アカウントの資格証明を入力します。

注意:

- この画面に入力するパスワードは、インストーラによって確認されないため、正しいパスワードを入力してください。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

注意:
Oracle WebLogic Serverのパスワードまたはノード・マネージャのパスワードを変更する場合は、My Oracle Supportのノート1450798.1を参照してください。

17. 「次へ」をクリックします。

18. 「表領域の場所」画面で、JVM診断データ表領域のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所を検証します。必要な場合は、計画名を編集できます。編集する場合は、必ずファイル名まで含めたパスを指定してください。Enterprise Manager Cloud Controlでは、JVM診断およびアプリケーションの依存性とパフォーマンス(ADP)に関連する監視データを格納するために、このデータ・ファイルを必要とします。

注意:
この画面は、Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合にのみ表示されます。

19. 「次へ」をクリックします。

20. ポート構成の詳細を指定します。

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、古いOMSが使用していたポートがアップグレード後のOMSによって再利用されるため、「ポート構成の詳細」画面は表示されません。したがって、手順(22)に進みます。

- Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合は、「ポート構成の詳細」画面で各種コンポーネントが使用するポートをカスタマイズします。

注意:

- デフォルトでは、この画面にはすべてのコア・コンポーネントのデフォルト・ポートが表示されます。ただし、追加のOMSをアップグレードする場合は、最初のOMSに対して構成された管理サーバーが再利用されるため、この画面には管理サーバーのHTTP SSLポートは表示されません。

- この画面のすべてのポートが-1として表示される場合、インストーラがホスト上のポートをバインドできないことを示します。この問題を解決するには、インストーラを終了して、ホスト名とこのホストのIP構成を検証し(ホストのIPアドレスが別のホストで使用されていないことを確認)、インストーラを再起動して実行しなおします。

推奨されているポート範囲内または範囲外のカスタム・フリー・ポートを入力できます。

ポートが空いているかどうか確認するには、次のコマンドを実行します。

UNIXの場合:

netstat -anp | grep <port no>

Microsoft Windowsの場合:

netstat -an|findstr <port_no>

ただし、カスタム・ポートは1024より大きく、65535未満である必要があります。または、staticports.iniファイルにポートが事前定義済で、これらのポートを使用する場合、「staticports.iniファイルのインポート」をクリックしてファイルを選択します。

注意:
staticports.iniファイルがインストール中に渡される場合、staticports.iniファイルで定義されたポートがデフォルトで表示されます。ファイルが渡されない場合、推奨範囲から使用可能な最初のポートが表示されます。
staticports.iniファイルは次の場所にあります。

<Software_Extracted_Location>/response

21. 「次へ」をクリックします。

22. 「確認」画面で、アップグレードのために指定した詳細を確認します。

1. 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

2. 詳細を確認し問題がない場合、「インストール」をクリックしてアップグレード・プロセスを開始します。

23. 「インストールの進行状況」画面で、アップグレード操作の全体的な進行状況(パーセント)と各コンフィギュレーション・アシスタントのステータスを確認します。

注意:
OMSコンフィギュレーション・アシスタントが例外を伴って失敗した場合(特にEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からのアップグレード中)は、管理サーバーを停止して再試行してください。管理サーバーを停止するには、各OMSホストで次のコマンドを実行します。
$<OMS_HOME>/bin/emctl stop oms -all

注意:
コンフィギュレーション・アシスタントが失敗すると、インストーラが停止し、失敗したコンフィギュレーション・アシスタントに関連する問題が解決するまで後続のコンフィギュレーション・アシスタントは実行されません。この場合は、問題を診断して解決してから、「インストールの進行状況」画面で「再試行」 をクリックし、失敗したコンフィギュレーション・アシスタントから再度実行します。
ただし、誤って「再試行」 をクリックする前にインストーラを終了してしまった場合は、この画面を開くためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.shスクリプトを起動し、サイレント・モードでコンフィギュレーション・アシスタントを再度実行してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗した場合、サービス・リクエストを発行してOracleサポートに連絡してください。

24. ソフトウェア・バイナリがコピーおよび構成されると、allroot.shスクリプトを実行するように求められます。別のウィンドウを開き、rootとしてログインし、これらのスクリプトを手動で実行します。
Microsoft Windowsオペレーティング・システム上でインストールしている場合、このスクリプトの実行は要求されません。

25. 「終了」画面に、Enterprise Managerのアップグレードに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、ウィザードを終了します。

注意:
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

12.1.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式、グラフィック・モード)

注意:
2システム・アップグレード方式の場合、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストールに、クリーンな新規のホストを使用することをお薦めします。このため、ホストに管理エージェントがインストールされていないことを確認してください。
すでに管理エージェントが存在するホストにインストールする場合、2システム・アップグレード・プロセスの一部としてインストールされる新しい管理エージェントは、同じホストを再びターゲットとして登録することはできません。これは、既存の管理エージェントがすでにホストを古い管理リポジトリにターゲットとして登録している可能性があり、この管理リポジトリをクローニングして2システム・アップグレード・プロセスの一部としてアップグレードした場合、クローニングされた管理リポジトリをアップグレードした後でも、このホストのエントリが存在し続けるためです。このため、新しい管理エージェントがデータをアップロードする際に、このホストを再登録することはできません。

すでに管理エージェントがインストールされているホストを使用しなければならない場合は、まず既存の管理エージェントを削除し、この管理エージェントおよび管理エージェントによって監視されているターゲットの関連情報を管理リポジトリからクリーンアップします。その後、そのホストで2システム・アップグレードを開始します。既存の管理エージェントを削除およびクリーンアップする手順は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

管理エージェントがすでに存在するホストにEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)を間違ってインストールした場合は、第13.1項に示されている回避策に従ってください。

グラフィック・モードで2システム・アップグレード方式を使用して既存のOMSおよび管理リポジトリをアップグレードするには、次の手順を実行します。

1. Oracle Management Service 12cをインストールするホスト上で、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。
<Software_Location>/runInstaller [ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE=FALSE LOCK_ORACLE_MANAGEMENT_SERVICE=FALSE]

このコマンドで、<Software_Location>はソフトウェア・キットをダウンロードした場所です。

注意:

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第5.1.1項を参照してください。

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- インストーラを起動しているホストが、アップグレード前コンソールで入力したホストと一致することを確認します。
インストーラを起動していて、これとは異なるホスト上で、アップグレード前コンソールでホスト名を変更する場合は、次の手順に従います。

1. インストーラを終了します。

2. バックアップ・データベースを破棄します。

3. アップグレード前コンソールにアクセスします。
(a)「新規Enterprise Managerシステムのホストとポートの識別」ページで、ホスト名を変更します。詳細は、10.2項を参照してください。

(b)「エージェントのデプロイと構成」ページで、デプロイ済の管理エージェントを再構成します。詳細は、11.1項を参照してください。

重要: 「エージェントのデプロイと構成」ページの「操作タイプの選択」セクションで、「エージェントとプラグイン・ソフトウェアのデプロイ」が選択解除されていることを確認してください。

4. ここでデータベースの新しいバックアップを作成します。

5. インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

注意:
runInstallerまたはsetup.exeを起動したとき、Enterprise Manager Cloud Controlインストール・ウィザードが表示されない場合、/stageディレクトリへのアクセス権がない可能性があります。
インストール・ウィザードは、クラスパス変数をOPatch用に../stage/Components/として処理します。TEMP変数が/tmpに設定されているとき、インストール・ウィザードはopatchのJARファイルを/tmp/../stageディレクトリ(/stageと同様)で検索しようとします。しかし、ユーザーに/stageへの権限がないと、インストール・ウィザードはハングします。このような場合、/stageディレクトリへのアクセス権があるかどうかを確認します。アクセス権がない場合、TEMP変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

注意:
IBM AIXでのアップグレード中に、ミドルウェア・ホームのJDKバージョンがサポートされているバージョンではないことを示すエラー・メッセージが表示された場合は、メッセージに記載されているサポートされているバージョンがインストールされていることを確認し、-skipJDKValidation引数を渡してインストーラを起動します。
次に例を示します。

./runInstaller -skipJDKValidation

2. (オプション)「My Oracle Support」画面でMy Oracle Support資格証明を入力し、Oracle Configuration Managerを有効にします。Oracle Configuration Managerをここで有効にしない場合、手順(3)に進みます。
インストール・ウィザードを実行するホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Supportからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを指定するか、My Oracle SupportにアクセスするクライアントからこのURLへのプロキシ・アクセスを付与する必要があることを意味します。

3. 「次へ」をクリックします。

4. 「ソフトウェアの更新」画面で、最新のPSUパッチを含む、最新のソフトウェア更新を適用します。
ソフトウェア更新は、オフライン・モード(インターネット接続がない場合)またはオンライン・モード(インターネット接続がある場合)でダウンロードできます。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

5. 「次へ」をクリックします。
Enterprise Manager Cloud Controlが、UNIXオペレーティング・システムで実行中のホストにインストールする最初のOracle製品である場合、「Oracleインベントリ」画面が表示されます。詳細は手順(6)を参照してください。最初の製品ではない場合、「前提条件の確認」画面が表示されます。詳細は手順(8)を参照してください。

Enterprise Manager Cloud Controlが、Microsoft Windowsオペレーティング・システムで実行中のホストにインストールする最初のOracle製品である場合、「Oracleインベントリ」画面は表示されません。Microsoft Windowsでは、デフォルトのインベントリ・ディレクトリは次のようになります。

<system drive>\Program Files\Oracle\Inventory

6. 「Oracleインベントリ」画面で、次のようにします。このホストでの最初のOracle製品のインストールであると特定された場合のみ、この画面が表示されます。

1. インベントリ・ファイルおよびディレクトリを配置するディレクトリへのフルパスを入力します。

注意:

これがホスト上で最初のOracle製品である場合、デフォルトのセントラル・インベントリの場所は<home directory>/oraInventoryになります。ただし、すでにOracle製品がホスト上にある場合、中央インベントリの場所は、oraInst.locファイルで参照できます。oraInst.locファイルは、LinuxおよびAIXの場合/etcディレクトリに、Solaris、HP-UXおよびTru64の場合/var/opt/oracleディレクトリにあります。

2. Oracleインベントリ・ディレクトリを所有する適切なオペレーティング・システム・グループ名を選択します。選択するグループは、そのOracleインベントリ・ディレクトリに対する書込み権限を持っている必要があります。

7. 「次へ」をクリックします。

8. 「前提条件チェック」画面で、インストール・ウィザードによって実行された前提条件チェックのステータスを確認し、環境がアップグレード成功のためのすべての最小要件を満たしているかどうかを確認します。
インストール・ウィザードでは、この画面に達すると前提条件チェックが自動的に実行されます。必要なオペレーティング・システム・パッチ、オペレーティング・システム・パッケージなどがチェックされます。

前提条件チェックのステータスは、「警告」、「失敗」または「成功」のいずれかになります。

「警告」または「失敗」 ステータスになったチェックがある場合は、アップグレードを続行する前に問題を調査して修正してください。この画面では、前提条件が満たされなかった理由や解決方法を提供します。問題を修正した後、この画面に戻り、「再実行」をクリックして前提条件を再度チェックします。

9. 「次へ」をクリックします。

注意:
前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、「再実行」をクリックします。インストール・ウィザードによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストール・ウィザードがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

10. 「インストール・タイプ」画面で、「既存のEnterprise Managerシステムのアップグレード」を選択し、次に「2システムのアップグレード」を選択します。

11. 「次へ」をクリックします。

12. 「インストールの詳細」画面で、次のようにします。

1. OMSおよび他のコア・コンポーネントをインストールするミドルウェア・ホームを入力するか、検証します。

注意:

- Oracle WebLogic ServerとJava Development Kitがインストール済の場合、サポートされているリリース(Oracle WebLogic Server 11gリリース1 (10.3.6)とJDK 1.6.0.43.0)であることを確認してください。サポート対象のリリースがある場合、インストーラはそれらを自動的に検出して、インストールされているミドルウェア・ホームの絶対パスを表示します。この場合は、ミドルウェア・ホームを検証してください。場所が間違っている場合、正しい場所のパスを入力します。選択または入力するミドルウェア・ホームに、Oracleホームが1つもないことを確認してください。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJDK 1.6.0.43.0がない場合、Enterprise Managerシステムのインストール中にインストーラによってそれらが自動的にインストールされます。この場合、それらをインストールするディレクトリの絶対パスを入力します。たとえば、/oracle/software/などです。入力するディレクトリにファイルやサブディレクトリが含まれていないことを確認してください。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6 v24を手動でインストールする場合は、第3章で説明されているガイドラインに従ってください。

2. 管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。たとえば、/oracle/agentです。この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

3. OMSを構成するホストの名前を検証します。
ホストが仮想マシンを使用して構成されている場合は、ホスト名は完全修飾名または仮想ホスト名で表示されます。ORACLE_HOSTNAMEの値を指定してインストール・ウィザードを起動した場合、このフィールドにはその名前が事前に移入されます。

デフォルトのホスト名を使用するか、DNSで登録され、他のネットワーク・ホストからアクセス可能な完全修飾されたドメイン名を入力します。完全修飾ドメイン名を使用することをお薦めします。

注意:
ホスト名はローカルのOracle WebLogic ServerおよびOracle Management Serviceに使用されるため、ホスト名はローカル・ホストに解決する必要があります。このフィールドには、リモート・ホストやロード・バランサ仮想ホストを指定しないでください。IPアドレスを入力しないでください。名前にアンダースコアを使用しないでください。短縮名は許可されますが警告が表示されるため、かわりに完全修飾ドメイン名を入力することをお薦めします。

13. 「データベース接続の詳細」画面で、バックアップ・データベースが存在するホストの完全修飾名、そのリスナー・ポート、サービス名またはシステムID(SID)、SYSおよびSYSMANユーザー・アカウントのパスワードを入力します。

注意:
Oracle Real Application Cluster(Oracle RAC)のノードは仮想IP(vip)名で参照されます。service_nameパラメータは、connect_dataモードでシステム識別子(SID)のかわりに使用され、フェイルオーバーが有効になります。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

インストーラは、この情報を使用して、SYSMANスキーマがアップグレードされるバックアップ・データベースに接続します。SYSMANスキーマは、Enterprise Manager Cloud Controlの管理に使用されるリレーショナル・データのほとんどを保持しています。

注意:
この時点でデータベースで実行される様々な前提条件チェックの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

14. 「次へ」をクリックします。

注意:

- Oracle RACデータベースに接続していて、そのノードのいずれかの仮想IPアドレスを入力している場合、インストール・ウィザードで「接続文字列」ダイアログが表示され、クラスタの一部であるその他のノードの情報で接続文字列を更新するように求められます。接続文字列を更新して「OK」をクリックします。接続をテストするには、「接続テスト」をクリックします。

- Oracle Real Application Cluster(Oracle RAC)のノードは仮想IP(vip)名で参照されます。service_nameパラメータは、connect_dataモードでシステム識別子(SID)のかわりに使用され、フェイルオーバーが有効になります。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- プロビジョニング・アーカイブ・フレームワーク(PAF)の前提条件エラーが発生した場合は、次の操作を実行します。

- インストーラを終了し、バックアップ・データベース上で次のSQLコマンドを実行した後、インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

UPDATE MGMT_PAF_STATES
SET status = 6
WHERE state_type = 0
AND status IN (0, 1);

- インストーラを終了し、バックアップ・データベースを破棄して、既存のEnterprise Managerシステムで実行中およびスケジュール済のすべてのデプロイメント・プロシージャを停止します。ここでデータベースの新しいバックアップを作成し、インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

- なんらかの検証エラーが発生した場合は、次の操作を実行します。

1. インストーラを終了します。

2. バックアップ・データベースを破棄します。

3. アップグレード前コンソールで問題を解決します。

4. ここでデータベースの新しいバックアップを作成します。

5. インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

- MGMT_VIEWユーザー・アカウントのロック解除とパスワード変更を求める警告が表示された場合は、この警告を無視します(インストーラによって自動的にロック解除されます)。

15. 「プラグインの選択」画面で、Enterprise Managerシステムのインストール中にソフトウェア・キット(DVD、ダウンロード済ソフトウェア)からインストールするオプションのプラグインを選択します。
事前に選択されている行は、デフォルトでインストールされる必須プラグインです。インストールまたはアップグレードするオプションのプラグインを選択してください。

注意:
事前選択済の行には、アップグレード前コンソールを使用して、Oracle Management Agent 12cの事前デプロイ中にインストールしたプラグインも含まれる場合があります。
ただし、事前選択済の行にインストール済のプラグインが含まれていない場合は、これらのプラグインがソフトウェア・キット(DVD、ダウンロードしたソフトウェア)に含まれていないことを意味しています。

この画面にリストされていないプラグインをインストールする場合は、次の手順に従います。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションを指定してインストーラを起動し、ダウンロードしたプラグインのある場所を渡します。
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Enterprise Manager Cloud Control 12cリリース5 (12.1.05)でサポートされていない、旧リリースのEnterprise Managerにデプロイされたプラグイン・バージョンを保有している場合があります。この場合は、インストーラを-pluginLocation引数で起動する際に、サポートされていないプラグインよりも上位のバージョンのソフトウェアを提供しないようにしてください。その上位バージョンがダウンロード可能な場合でも同様です。これによって、12cリリース5 (12.1.0.5)へのアップグレード中に、サポートされていないバージョンが確実に削除されます。アップグレード後、上位のバージョンをプラグイン・マネージャから直接デプロイできます。

16. 「次へ」をクリックします。

17. 「WebLogic Server構成の詳細」画面で、WebLogic Serverユーザー・アカウントおよびノード・マネージャのユーザー・アカウントの資格証明を入力し、Oracle Management Serviceインスタンス・ベースの場所へのパスを検証します。

注意:

- パスワードはスペースを含めず8文字以上とします。先頭は文字とし、数字を1つ以上含めるようにしてください。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

デフォルトでは、WebLogicドメイン名はGCDomainで、ノード・マネージャ名はnodemanagerです。これらは編集できないフィールドです。インストーラはこの情報を使用して、Oracle WebLogicドメインおよびその他の関連コンポーネント(管理サーバー、管理対象サーバー、ノード・マネージャなど)を作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

18. 「次へ」をクリックします。

警告:

両方のデータベースでGLOBAL_NAMESパラメータに設定されている値を確認してください。

- GLOBAL_NAMESパラメータが両方のデータベースでFALSEに設定されている場合は、アップグレードが終了するまでこの値を変更せず、すべての管理エージェントがスイッチオーバーされることを確認します。

- GLOBAL_NAMESパラメータがTRUEに設定されているのがどちらか一方のデータベースのみの場合や、両方のデータベースのGLOBAL_NAMEパラメータの値が同一である場合は、新しいクローン・データベースで設定されたGLOBAL_NAMEパラメータの値を、古いデータベースで設定されたものとは異なる値に設定します。

19. 「古いリポジトリの詳細」画面で、接続文字列を検証し、古い管理リポジトリのSYSMANパスワードを入力します。
これらの詳細情報は、古い管理リポジトリへの接続、発生データのチェック、アップグレード後の管理リポジトリへの発生データの転送に使用されます。発生データとは、古い管理リポジトリのバックアップ作成時からアップグレードまでに、古い管理リポジトリにアップロードされたデータです。

注意:
通常、接続文字列は事前に移入されています。ただし、事前に移入されていない場合は、次の形式で入力してください。

- SIDの場合
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SID=<sid>)))

- サービス名の場合
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))

20. 「次へ」をクリックします。

21. 「表領域の場所」画面で、JVM診断データ表領域のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所を検証します。必要な場合は、計画名を編集できます。編集する場合は、必ずファイル名まで含めたパスを指定してください。Enterprise Manager Cloud Controlでは、JVM診断およびアプリケーションの依存性とパフォーマンス(ADP)に関連する監視データを格納するために、このデータ・ファイルを必要とします。

注意:
この画面は、Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合にのみ表示されます。

22. 「次へ」をクリックします。

23. 「ポート構成の詳細」画面で、各種コンポーネントが使用するポートをカスタマイズします。

- Enterprise ManagerアップロードHttpポートおよびEnterprise ManagerアップロードHttp SSLポートに入力するポートが、アップグレード前コンソールで入力した保護および非保護ポートと一致することを確認します。

注意:
この画面で入力するポートがアップグレード前コンソールで入力したポートとは異なっており、アップグレード前コンソールのポートを変更する場合は、次の操作を実行します。

1. インストーラを終了します。

2. バックアップ・データベースを破棄します。

3. アップグレード前コンソールでポートを変更します。

4. ここでデータベースの新しいバックアップを作成します。

5. インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

- 他のコンポーネントに対しては、推奨されているポート範囲内または範囲外のフリーのカスタム・ポートを入力できます。ただし、カスタム・ポートは1024より大きく、65535未満である必要があります。
ポートが空いているかどうか確認するには、次のコマンドを実行します。

UNIXの場合:

netstat -anp | grep <port no>

Microsoft Windowsの場合:

netstat -an|findstr <port_no>

- または、staticports.iniファイルにポートが事前定義済で、これらのポートを使用する場合、「staticports.iniファイルのインポート」をクリックしてファイルを選択します。

注意:
staticports.iniファイルがインストール中に渡される場合、staticports.iniファイルで定義されたポートがデフォルトで表示されます。ファイルが渡されない場合、推奨範囲から使用可能な最初のポートが表示されます。このファイルを渡す場合は、Enterprise ManagerアップロードHttpポートおよびEnterprise ManagerアップロードHttp SSLポートに入力するポートが、アップグレード前コンソールで入力した非保護および保護ポートと一致することを確認します。

注意:
この画面のすべてのポートが-1として表示される場合、インストーラがホスト上のポートをバインドできないことを示します。この問題を解決するには、インストーラを終了して、ホスト名とこのホストのIP構成を検証し(ホストのIPアドレスが別のホストで使用されていないことを確認)、インストーラを再起動して実行しなおします。

24. 「次へ」をクリックします。

25. 「確認」画面で、選択したインストール・タイプに指定した詳細を確認します。

- 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

- 詳細を確認し問題がない場合、「インストール」をクリックしてインストール・プロセスを開始します。

26. 「インストールの進行状況」画面で、インストールの全体的な進行(パーセント)とコンフィギュレーション・アシスタントのそれぞれのステータスを参照します。コンフィギュレーション・アシスタントは、Enterprise Manager Cloud Controlのインストール済コンポーネントを構成するために実行されます。

注意:
コンフィギュレーション・アシスタントが失敗すると、インストーラが停止し、失敗したコンフィギュレーション・アシスタントに関連する問題が解決するまで後続のコンフィギュレーション・アシスタントは実行されません。この場合は、問題を診断して解決してから、「インストールの進行状況」画面で「再試行」 をクリックし、失敗したコンフィギュレーション・アシスタントから再度実行します。
ただし、誤って「再試行」 をクリックする前にインストーラを終了してしまった場合は、この画面を開くためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.shスクリプトを起動し、サイレント・モードでコンフィギュレーション・アシスタントを再度実行してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗した場合、環境をクリーン・アップしてインストールを再実行してください。

27. ソフトウェア・バイナリのコピーおよび構成の後、allroot.shスクリプト、および今回がホストでの最初のOracle製品のインストールの場合oraInstRoot.shスクリプトを実行するように要求されます。別のウィンドウを開き、rootとしてログインし、これらのスクリプトを手動で実行します。
Microsoft Windowsオペレーティング・システム上でインストールしている場合、このスクリプトの実行は要求されません。

28. 「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。
このインストールの詳細は、OMSホームの次のファイルを参照してください。

$<OMS_HOME>/install/setupinfo.txt

注意:
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

12.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(サイレント・モード)

この項では、アップグレード方式の1つを使用して、サイレント・モードで10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の既存のOMSおよび管理リポジトリをアップグレードする方法について説明します。

特に、次の項目について説明します。

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式、サイレント・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式、サイレント・モード)

注意:
OMSとManagement Agentのエントリは、HPUNIX、HPia64、Solaris Sparcを除くすべてのUNIXプラットフォームの/etc/oragchomelistファイルにあります。HPUNIX、HPia64、Solaris Sparcの各プラットフォームでは、エントリは/var/opt/oracle/oragchomelistにあります。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

12.2.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式、サイレント・モード)

注意:
1システム・アップグレード方式を使用してアップグレードする場合、Enterprise Manager Cloud Controlインストール・ウィザードでは、OMSがインストールされた新規の管理エージェントはインストールされず、既存の管理エージェントもアップグレードされません。管理エージェントは、アップグレード前コンソールを使用して事前にデプロイされます。これは予測されている動作です。

サイレント・モードで1システム・アップグレード方式を使用して既存のOMSおよび管理リポジトリをアップグレードする方法は、第5.2項を参照してください。

12.2.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式、サイレント・モード)

注意:
2システム・アップグレード方式の場合、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストールに、クリーンな新規のホストを使用することをお薦めします。このため、ホストに管理エージェントがインストールされていないことを確認してください。
すでに管理エージェントが存在するホストにインストールする場合、2システム・アップグレード・プロセスの一部としてインストールされる新しい管理エージェントは、同じホストを再びターゲットとして登録することはできません。これは、既存の管理エージェントがすでにホストを古い管理リポジトリにターゲットとして登録している可能性があり、この管理リポジトリをクローニングして2システム・アップグレード・プロセスの一部としてアップグレードした場合、クローニングされた管理リポジトリをアップグレードした後でも、このホストのエントリが存在し続けるためです。このため、新しい管理エージェントがデータをアップロードする際に、このホストを再登録することはできません。

すでに管理エージェントがインストールされているホストを使用しなければならない場合は、まず既存の管理エージェントを削除し、この管理エージェントおよび管理エージェントによって監視されているターゲットの関連情報を管理リポジトリからクリーンアップします。その後、そのホストで2システム・アップグレードを開始します。既存の管理エージェントを削除およびクリーンアップする手順は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

管理エージェントがすでに存在するホストにEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)を間違ってインストールした場合は、第13.1項に示されている回避策に従ってください。

サイレント・モードで2システム・アップグレード方式を使用して既存のOMSおよび管理リポジトリをアップグレードするには、次の手順を実行します。

1. 次のレスポンス・ファイルをローカル・ホスト上のアクセス可能な場所にコピーします。
<Software_Location>/response/upgrade.rsp

このコマンドで、<Software_Location>はソフトウェア・キットをダウンロードした場所です。

2. レスポンス・ファイルを編集し、付録Aに示された変数に適切な値を入力します。

3. インストーラを起動します。
./runInstaller -silent -responseFile <absolute_path>/upgrade.rsp -staticPortsIniFile <absolute_path_to_staticports.ini_file> [-invPtrLoc <absolute_path_to_inventory_directory>] [ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE=FALSE LOCK_ORACLE_MANAGEMENT_SERVICE=FALSE]

注意:
インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第5.2.1項を参照してください。UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。また、-invPtrLocはMicrosoft Windowsではサポートされていないことにも注意してください。

注意:
IBM AIXでのアップグレード中に、ミドルウェア・ホームのJDKバージョンがサポートされているバージョンではないことを示すエラー・メッセージが表示された場合は、メッセージに記載されているサポートされているバージョンがインストールされていることを確認し、-skipJDKValidation引数を渡してインストーラを起動します。
次に例を示します。

./runInstaller -skipJDKValidation

注意:

- インストーラを起動しているホストが、アップグレード前コンソールで入力したホストと一致することを確認します。
インストーラを起動していて、これとは異なるホスト上で、アップグレード前コンソールでホスト名を変更する場合は、次の手順に従います。

1. インストーラを終了します。

2. バックアップ・データベースを破棄します。

3. アップグレード前コンソールにアクセスし、「新規Enterprise Managerシステムのホストとポートの識別」ページで、ホスト名を変更します。

4. ここでデータベースの新しいバックアップを作成します。

5. インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

この場合、OMSのアップグレード前にアップグレード前コンソールを通じてデプロイおよび構成済のすべての管理エージェントが、新しいホスト名で再構成されていることを確認する必要があります。

- staticports.iniファイルで、Enterprise ManagerアップロードHttpポートおよびEnterprise ManagerアップロードHttp SSLポートに入力するポートが、アップグレード前コンソールで入力した保護および非保護ポートと一致することを確認します。
かわりにアップグレード前コンソールでポートを変更する場合は、次の手順を実行します。

1. インストーラを終了します。

2. バックアップ・データベースを破棄します。

3. アップグレード前コンソールでポートを変更します。

4. ここでデータベースの新しいバックアップを作成します。

5. インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

注意:
前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、インストールを再試行します。インストーラによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストーラがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

12.3 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(ソフトウェアのみアップグレード方法の使用、グラフィック・モード)

この項では、グラフィック・モードでEnterprise Manager 12c Cloud Controlのソフトウェア・バイナリのみをある時点でインストールしておき、後でアップグレードする方法について説明します。

特に、次の項目について説明します。

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、グラフィック・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、グラフィック・モード)

注意:
OMSとManagement Agentのエントリは、HPUNIX、HPia64、Solaris Sparcを除くすべてのUNIXプラットフォームの/etc/oragchomelistファイルにあります。HPUNIX、HPia64、Solaris Sparcの各プラットフォームでは、エントリは/var/opt/oracle/oragchomelistにあります。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

12.3.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、グラフィック・モード)

この項では、1システム・アップグレード方式で、ソフトウェアのみモードでOMSおよび管理リポジトリをアップグレードする方法について説明します。この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(1システム・アップグレード方式、グラフィック・モード)

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(1システム・アップグレード方式、グラフィック・モード)した後のallroot.shスクリプトの実行

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(1システム・アップグレード方式、グラフィック・モード)

12.3.1.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(1システム・アップグレード方式、グラフィック・モード)

Enterprise Manager Cloud Controlのソフトウェア・バイナリをインストールするには、第5.3.1項を参照してください。

12.3.1.2 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(1システム・アップグレード方式、グラフィック・モード)した後のallroot.shスクリプトの実行

allroot.shスクリプトを実行する方法は、第5.3.2項を参照してください。

12.3.1.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(1システム・アップグレード方式、グラフィック・モード)

Enterprise Manager Cloud Controlのソフトウェア・バイナリを構成するには、次の手順に従います。

1. 次のスクリプトを実行してインストール・ウィザードを起動します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh[-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- 第12.3.1.1項の説明に従ってソフトウェア・バイナリをインストールし、引数-invPtrLocを渡した場合、ここでも同じ引数を渡します。

- スクリプトの起動時に渡すことができる追加の拡張オプションの詳細は、第5.3.3.1項を参照してください。

2. 「インストール・タイプ」画面で、次のようにします。

1. 「既存のEnterprise Managerシステムのアップグレード」を選択し、次に「1システムのアップグレード」を選択します。

2. アップグレードするOMSホームを選択します。

3. 「次へ」をクリックします。

4. 「データベース接続の詳細」画面で、次を実行します。

- 選択したOMSの管理リポジトリが格納されているデータベースのSYSおよびSYSMANユーザー・アカウントのパスワードを入力します。

- Oracle Management Repository(管理リポジトリ)をバックアップしたことを確認します。前提条件として、アップグレード・プロセスを開始する前に、管理リポジトリをバックアップする必要があります。まだバックアップを取っていない場合は、ただちに実行し、その後でインストーラに戻ってアップグレードを続行してください。

注意:
この時点でデータベースで実行される様々な前提条件チェックの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

5. 「次へ」をクリックします。

注意:
欠落しているプラグインに関するエラーが表示される場合は、次の操作を実行します。

1. 欠落しているプラグインのエラー・メッセージに表示されているとおりに、プラグイン・バージョンおよびプラグイン・アップデートに関するメモを取ります。エラー・メッセージに表示されたプラグインは、次の形式で示されます。
PluginID:PluginVersion:PluginUpdate

2. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

3. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

4. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

5. ConfigureGC.shスクリプトを次のように起動して、ダウンロードしたプラグインをインストールします。
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

次の手順に進む前に、欠落しているプラグインを必ずインストールしてください。

Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)でサポートされていない、旧リリースのEnterprise Managerにデプロイされたプラグイン・バージョンを保有している場合があります。この場合は、インストーラを-pluginLocation引数で起動する際に、サポートされていないプラグインよりも上位のバージョンのソフトウェアを提供しないようにしてください。その上位バージョンがダウンロード可能な場合でも同様です。これによって、12cリリース5 (12.1.0.5)へのアップグレード中に、サポートされていないバージョンが確実に削除されます。アップグレード後、上位のバージョンをプラグイン・マネージャから直接デプロイできます。

6. 「プラグインの選択」画面で、OMSのアップグレード中に自動的にアップグレードされるプラグイン以外にデプロイするオプション・プラグインを選択します。

注意:
この画面にリストされていないその他のプラグインをインストールする場合は、次の手順に従います。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションを指定してインストーラを起動し、ダウンロードしたプラグインのある場所を渡します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

7. 「次へ」をクリックします。

8. WebLogic Server構成の詳細を指定します。

- Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合は、「WebLogic Server構成の詳細」画面で、WebLogic Serverユーザー・アカウントおよびノード・マネージャ・ユーザー・アカウントの資格証明を入力し、OMSインスタンス・ベースの場所へのパスを検証します。

注意:

- パスワードはスペースを含めず8文字以上とします。先頭は文字とし、数字を1つ以上含めるようにしてください。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

デフォルトでは、WebLogicドメイン名はGCDomainで、ノード・マネージャ名はnodemanagerです。これらは編集できないフィールドです。インストーラはこの情報を使用して、Oracle WebLogicドメインおよびその他の関連コンポーネント(管理サーバー、管理対象サーバー、ノード・マネージャなど)を作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、管理サーバーのホスト名およびそのポートと、WebLogicユーザー名を検証し、WebLogicユーザー・アカウント・パスワードを入力します。これは、新規WebLogicドメイン(GCDomain)を、アップグレードしている旧リリースのOMSで使用された管理サーバーと同じポートおよびホスト名で作成するために必要です。

注意:
NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

- 10gリリース5(10.2.0.5)または11gリリース1(11.1.0.1)から追加のOMSをアップグレードする場合は、最初のOMS用に構成したホスト名と管理サーバー・ポートを入力し、既存のWebLogic Serverユーザー・アカウントの資格証明を入力します。

注意:

- この画面に入力するパスワードは、インストーラによって確認されないため、正しいパスワードを入力してください。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

注意:
Oracle WebLogic Serverのパスワードまたはノード・マネージャのパスワードを変更する場合は、My Oracle Supportのノート1450798.1を参照してください。

9. 「次へ」をクリックします。

10. 「表領域の場所」画面で、JVM診断データ表領域のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所を検証します。必要な場合は、計画名を編集できます。編集する場合は、必ずファイル名まで含めたパスを指定してください。Enterprise Manager Cloud Controlでは、JVM診断およびアプリケーションの依存性とパフォーマンス(ADP)に関連する監視データを格納するために、このデータ・ファイルを必要とします。

注意:
この画面は、Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合にのみ表示されます。

11. 「次へ」をクリックします。

12. 「ポート構成の詳細」画面で、各種コンポーネントが使用するポートをカスタマイズします。

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合は、古いOMSが使用していたポートがアップグレード後のOMSによって再利用されるため、「ポート構成の詳細」画面は表示されません。したがって、手順(14)に進みます。

- Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合は、「ポート構成の詳細」画面で各種コンポーネントが使用するポートをカスタマイズします。

注意:
この画面のすべてのポートが-1として表示される場合、インストーラがホスト上のポートをバインドできないことを示します。この問題を解決するには、インストーラを終了して、ホスト名とこのホストのIP構成を検証し(ホストのIPアドレスが別のホストで使用されていないことを確認)、インストーラを再起動して実行しなおします。

推奨されているポート範囲内または範囲外のカスタム・フリー・ポートを入力できます。

ポートが空いているかどうか確認するには、次のコマンドを実行します。

UNIXの場合:

netstat -anp | grep <port no>

Microsoft Windowsの場合:

netstat -an|findstr <port_no>

ただし、カスタム・ポートは1024より大きく、65535未満である必要があります。または、staticports.iniファイルにポートが事前定義済で、これらのポートを使用する場合、「staticports.iniファイルのインポート」をクリックしてファイルを選択します。

注意:
staticports.iniファイルがインストール中に渡される場合、staticports.iniファイルで定義されたポートがデフォルトで表示されます。ファイルが渡されない場合、推奨範囲から使用可能な最初のポートが表示されます。
staticports.iniファイルは次の場所にあります。

<Software_Extracted_Location>/response

13. 「次へ」をクリックします。

14. 「確認」画面で、選択したインストール・タイプに指定した詳細を確認します。

- 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

- 詳細を確認した後、問題がなければ、「構成」をクリックしてインストール・プロセスを開始します。

15. 「インストールの進行状況」画面で、インストールの全体的な進行状況(パーセント)を確認します。

注意:
コンフィギュレーション・アシスタントが失敗すると、インストーラが停止し、失敗したコンフィギュレーション・アシスタントに関連する問題が解決するまで後続のコンフィギュレーション・アシスタントは実行されません。この場合は、問題を診断して解決してから、「インストールの進行状況」画面で「再試行」 をクリックし、失敗したコンフィギュレーション・アシスタントから再度実行します。
ただし、誤って「再試行」をクリックする前にインストーラを終了してしまった場合は、この画面を開くためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.shスクリプトを起動し、サイレント・モードでコンフィギュレーション・アシスタントを再度実行してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗した場合、サービス・リクエストを発行してOracleサポートに連絡してください。

16. 「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。

注意:
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

12.3.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、グラフィック・モード)

この項では、2システム・アップグレード方式で、ソフトウェアのみモードでOMSおよび管理リポジトリをアップグレードする方法について説明します。この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(2システム・アップグレード方式、グラフィック・モード)

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(2システム・アップグレード方式、グラフィック・モード)した後のallroot.shスクリプトの実行

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(2システム・アップグレード方式、グラフィック・モード)

注意:
2システム・アップグレード方式の場合、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストールに、クリーンな新規のホストを使用することをお薦めします。このため、ホストに管理エージェントがインストールされていないことを確認してください。
すでに管理エージェントが存在するホストにインストールする場合、2システム・アップグレード・プロセスの一部としてインストールされる新しい管理エージェントは、同じホストを再びターゲットとして登録することはできません。これは、既存の管理エージェントがすでにホストを古い管理リポジトリにターゲットとして登録している可能性があり、この管理リポジトリをクローニングして2システム・アップグレード・プロセスの一部としてアップグレードした場合、クローニングされた管理リポジトリをアップグレードした後でも、このホストのエントリが存在し続けるためです。このため、新しい管理エージェントがデータをアップロードする際に、このホストを再登録することはできません。

すでに管理エージェントがインストールされているホストを使用しなければならない場合は、まず既存の管理エージェントを削除し、この管理エージェントおよび管理エージェントによって監視されているターゲットの関連情報を管理リポジトリからクリーンアップします。その後、そのホストで2システム・アップグレードを開始します。既存の管理エージェントを削除およびクリーンアップする手順は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

管理エージェントがすでに存在するホストにEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)を間違ってインストールした場合は、第13.1項に示されている回避策に従ってください。

12.3.2.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(2システム・アップグレード方式、グラフィック・モード)

ソフトウェア・バイナリをインストールするには、第5.3.1項で説明されている手順を実行します。

12.3.2.2 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(2システム・アップグレード方式、グラフィック・モード)した後のallroot.shスクリプトの実行

allroot.shスクリプトを実行する方法は、第5.3.2項を参照してください。

12.3.2.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(2システム・アップグレード方式、グラフィック・モード)

既存のEnterprise Managerシステムを構成およびアップグレードするには、次の手順を実行します。

1. 次のスクリプトを実行してインストール・ウィザードを起動します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh[-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- 第12.3.2.1項の説明に従ってソフトウェア・バイナリをインストールし、引数-invPtrLocを渡した場合、ここでも同じ引数を渡します。

- スクリプトの起動時に渡すことができる追加の拡張オプションの詳細は、第5.3.3.1項を参照してください。

2. 「インストール・タイプ」画面で、「既存のEnterprise Managerシステムのアップグレード」を選択し、次に「2システムのアップグレード」を選択します。

3. 「次へ」をクリックします。

4. 「データベース接続の詳細」画面で、バックアップ・データベースが存在するホストの完全修飾名、そのリスナー・ポート、サービス名またはシステムID(SID)、SYSおよびSYSMANユーザー・アカウントのパスワードを入力します。

注意:
Oracle Real Application Cluster(Oracle RAC)のノードは仮想IP(vip)名で参照されます。service_nameパラメータは、connect_dataモードでシステム識別子(SID)のかわりに使用され、フェイルオーバーが有効になります。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

インストーラは、この情報を使用して、SYSMANスキーマがアップグレードされるバックアップ・データベースに接続します。SYSMANスキーマは、Enterprise Manager Cloud Controlの管理に使用されるリレーショナル・データのほとんどを保持しています。

注意:
この時点でデータベースで実行される様々な前提条件チェックの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

5. 「次へ」をクリックします。

注意:

- Oracle RACデータベースに接続していて、そのノードのいずれかの仮想IPアドレスを入力している場合、インストール・ウィザードで「接続文字列」ダイアログが表示され、クラスタの一部であるその他のノードの情報で接続文字列を更新するように求められます。接続文字列を更新して「OK」をクリックします。接続をテストするには、「接続テスト」をクリックします。

- Oracle Real Application Cluster(Oracle RAC)のノードは仮想IP(vip)名で参照されます。service_nameパラメータは、connect_dataモードでシステム識別子(SID)のかわりに使用され、フェイルオーバーが有効になります。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- プロビジョニング・アーカイブ・フレームワーク(PAF)の前提条件エラーが発生した場合は、次の操作を実行します。

- インストーラを終了し、バックアップ・データベース上で次のSQLコマンドを実行した後、インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

UPDATE MGMT_PAF_STATES
SET status = 6
WHERE state_type = 0
AND status IN (0, 1);

- インストーラを終了し、バックアップ・データベースを破棄して、既存のEnterprise Managerシステムで実行中およびスケジュール済のすべてのデプロイメント・プロシージャを停止します。ここでデータベースの新しいバックアップを作成し、インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

- MGMT_VIEWユーザー・アカウントのロック解除とパスワード変更を求める警告が表示された場合は、この警告を無視します(インストーラによって自動的にロック解除されます)。

注意:
欠落しているプラグインに関するエラーが表示される場合は、次の操作を実行します。

1. 欠落しているプラグインのエラー・メッセージに表示されているとおりに、プラグイン・バージョンおよびプラグイン・アップデートに関するメモを取ります。エラー・メッセージに表示されたプラグインは、次の形式で示されます。
PluginID:PluginVersion:PluginUpdate

2. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

3. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

4. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

5. ConfigureGC.shスクリプトを次のように起動して、ダウンロードしたプラグインをインストールします。
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

次の手順に進む前に、欠落しているプラグインを必ずインストールしてください。

Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)でサポートされていない、旧リリースのEnterprise Managerにデプロイされたプラグイン・バージョンを保有している場合があります。この場合は、インストーラを-pluginLocation引数で起動する際に、サポートされていないプラグインよりも上位のバージョンのソフトウェアを提供しないようにしてください。その上位バージョンがダウンロード可能な場合でも同様です。これによって、12cリリース5 (12.1.0.5)へのアップグレード中に、サポートされていないバージョンが確実に削除されます。アップグレード後、上位のバージョンをプラグイン・マネージャから直接デプロイできます。

6. 「プラグインの選択」画面で、OMSのアップグレード中に自動的にアップグレードされるプラグイン以外にデプロイするオプション・プラグインを選択します。

注意:
この画面にリストされていないその他のプラグインをインストールする場合は、次の手順に従います。

1. OTNのEnterprise Managerダウンロード・ページからプラグインを手動でダウンロードし、アクセス可能な場所に保管します。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. 次のオプションを指定してインストーラを起動し、ダウンロードしたプラグインのある場所を渡します。
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

7. 「次へ」をクリックします。

8. 「WebLogic Server構成の詳細」画面で、WebLogic Serverユーザー・アカウントおよびノード・マネージャのユーザー・アカウントの資格証明を入力し、Oracle Management Serviceインスタンス・ベースの場所へのパスを検証します。

注意:

- パスワードはスペースを含めず8文字以上とします。先頭は文字とし、数字を1つ以上含めるようにしてください。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

デフォルトでは、WebLogicドメイン名はGCDomainで、ノード・マネージャ名はnodemanagerです。これらは編集できないフィールドです。インストーラはこの情報を使用して、Oracle WebLogicドメインおよびその他の関連コンポーネント(管理サーバー、管理対象サーバー、ノード・マネージャなど)を作成します。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

9. 「次へ」をクリックします。

警告:

両方のデータベースでGLOBAL_NAMESパラメータに設定されている値を確認してください。

- GLOBAL_NAMESパラメータが両方のデータベースでFALSEに設定されている場合は、アップグレードが終了するまでこの値を変更せず、すべての管理エージェントがスイッチオーバーされることを確認します。

- GLOBAL_NAMESパラメータがTRUEに設定されているのがどちらか一方のデータベースのみの場合や、両方のデータベースのGLOBAL_NAMEパラメータの値が同一である場合は、新しいクローン・データベースで設定されたGLOBAL_NAMEパラメータの値を、古いデータベースで設定されたものとは異なる値に設定します。

10. 「古いリポジトリの詳細」画面で、接続文字列を検証し、古い管理リポジトリのSYSMANパスワードを入力します。
これらの詳細情報は、古い管理リポジトリへの接続、発生データのチェック、アップグレード後の管理リポジトリへの発生データの転送に使用されます。発生データとは、古い管理リポジトリのバックアップ作成時からアップグレードまでに、古い管理リポジトリにアップロードされたデータです。

注意:
通常、接続文字列は事前に移入されています。ただし、事前に移入されていない場合は、次の形式で入力してください。

- SIDの場合
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SID=<sid>)))

- サービス名の場合
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))

11. 「次へ」をクリックします。

12. 「表領域の場所」画面で、JVM診断データ表領域のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所を検証します。必要な場合は、計画名を編集できます。編集する場合は、必ずファイル名まで含めたパスを指定してください。Enterprise Manager Cloud Controlでは、JVM診断およびアプリケーションの依存性とパフォーマンス(ADP)に関連する監視データを格納するために、このデータ・ファイルを必要とします。

注意:
この画面は、Enterprise Manager 10g Grid Controlリリース5(10.2.0.5)からアップグレードする場合にのみ表示されます。

13. 「次へ」をクリックします。

14. 「ポート構成の詳細」画面で、各種コンポーネントが使用するポートをカスタマイズします。

- Enterprise ManagerアップロードHttpポートおよびEnterprise ManagerアップロードHttp SSLポートに入力するポートが、アップグレード前コンソールで入力した保護および非保護ポートと一致することを確認します。

- 他のコンポーネントに対しては、推奨されているポート範囲内または範囲外のフリーのカスタム・ポートを入力できます。ただし、カスタム・ポートは1024より大きく、65535未満である必要があります。
ポートが空いているかどうか確認するには、次のコマンドを実行します。

UNIXの場合:

netstat -anp | grep <port no>

Microsoft Windowsの場合:

netstat -an|findstr <port_no>

- または、staticports.iniファイルにポートが事前定義済で、これらのポートを使用する場合、「staticports.iniファイルのインポート」をクリックしてファイルを選択します。

注意:
staticports.iniファイルがインストール中に渡される場合、staticports.iniファイルで定義されたポートがデフォルトで表示されます。ファイルが渡されない場合、推奨範囲から使用可能な最初のポートが表示されます。このファイルを渡す場合は、Enterprise ManagerアップロードHttpポートおよびEnterprise ManagerアップロードHttp SSLポートに入力するポートが、アップグレード前コンソールで入力した非保護および保護ポートと一致することを確認します。

15. 「次へ」をクリックします。

16. 「確認」画面で、選択したインストール・タイプに指定した詳細を確認します。

- 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

- 詳細を確認した後、問題がなければ、「構成」をクリックしてインストール・プロセスを開始します。

17. 「インストールの進行状況」画面で、インストールの全体的な進行状況(パーセント)を確認します。

注意:
コンフィギュレーション・アシスタントが失敗すると、インストーラが停止し、失敗したコンフィギュレーション・アシスタントに関連する問題が解決するまで後続のコンフィギュレーション・アシスタントは実行されません。この場合は、問題を診断して解決してから、「インストールの進行状況」画面で「再試行」 をクリックし、失敗したコンフィギュレーション・アシスタントから再度実行します。
ただし、誤って「再試行」をクリックする前にインストーラを終了してしまった場合は、この画面を開くためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.shスクリプトを起動し、サイレント・モードでコンフィギュレーション・アシスタントを再度実行してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗した場合、環境をクリーン・アップしてインストールを再実行してください。

18. 「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。

注意:
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

12.4 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(ソフトウェアのみアップグレード方法の使用、サイレント・モード)

この項では、サイレント・モードでEnterprise Manager 12c Cloud Controlのソフトウェア・バイナリのみをある時点でインストールしておき、後でアップグレードする方法について説明します。

この項の内容は次のとおりです。

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、サイレント・モード)

- OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、サイレント・モード)

注意:
OMSとManagement Agentのエントリは、HPUNIX、HPia64、Solaris Sparcを除くすべてのUNIXプラットフォームの/etc/oragchomelistファイルにあります。HPUNIX、HPia64、Solaris Sparcの各プラットフォームでは、エントリは/var/opt/oracle/oragchomelistにあります。

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

- OMSにサービス名が構成されている場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>

- OMSにサービス名が構成されていない場合は、次のコマンドを実行します。
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>

ここで、管理リポジトリの詳細は、既存のまたは古い管理リポジトリの詳細です。コマンドラインで明示的に指定していない場合は、管理サーバーのパスワードおよびリポジトリ・パスワードを求められます。

12.4.1 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(1システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、サイレント・モード)

1システム・アップグレード方式でソフトウェアのみモードを使用してアップグレードする方法は、第5.4項を参照してください。

注意:
Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)でサポートされていない、旧リリースのEnterprise Managerにデプロイされたプラグイン・バージョンを保有している場合があります。この場合は、インストーラを-pluginLocation引数で起動する際に、サポートされていないプラグインよりも上位のバージョンのソフトウェアを提供しないようにしてください。その上位バージョンがダウンロード可能な場合でも同様です。これによって、12cリリース5 (12.1.0.5)へのアップグレード中に、サポートされていないバージョンが確実に削除されます。アップグレード後、上位のバージョンをプラグイン・マネージャから直接デプロイできます。

12.4.2 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(2システム・アップグレード方式でソフトウェアのみアップグレード方法を使用、サイレント・モード)

この項では、2システム・アップグレード方式で、ソフトウェアのみモードでアップグレードする方法について説明します。この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(2システム・アップグレード方式、サイレント・モード)

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(2システム・アップグレード方式、サイレント・モード)した後のallroot.shスクリプトの実行

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(2システム・アップグレード方式、サイレント・モード)

注意:
2システム・アップグレード方式の場合、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストールに、クリーンな新規のホストを使用することをお薦めします。このため、ホストに管理エージェントがインストールされていないことを確認してください。
すでに管理エージェントが存在するホストにインストールする場合、2システム・アップグレード・プロセスの一部としてインストールされる新しい管理エージェントは、同じホストを再びターゲットとして登録することはできません。これは、既存の管理エージェントがすでにホストを古い管理リポジトリにターゲットとして登録している可能性があり、この管理リポジトリをクローニングして2システム・アップグレード・プロセスの一部としてアップグレードした場合、クローニングされた管理リポジトリをアップグレードした後でも、このホストのエントリが存在し続けるためです。このため、新しい管理エージェントがデータをアップロードする際に、このホストを再登録することはできません。

すでに管理エージェントがインストールされているホストを使用しなければならない場合は、まず既存の管理エージェントを削除し、この管理エージェントおよび管理エージェントによって監視されているターゲットの関連情報を管理リポジトリからクリーンアップします。その後、そのホストで2システム・アップグレードを開始します。既存の管理エージェントを削除およびクリーンアップする手順は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

管理エージェントがすでに存在するホストにEnterprise Manager Cloud Control 12cリリース5 (12.1.0.5)を間違ってインストールした場合は、第13.1項に示されている回避策に従ってください。

12.4.2.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリのインストール(2システム・アップグレード方式、サイレント・モード)

Enterprise Manager Cloud Controlのソフトウェア・バイナリをインストールするには、第5.4.1項で説明されている手順を実行します。

12.4.2.2 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリをインストール(2システム・アップグレード方式、サイレント・モード)した後のallroot.shスクリプトの実行

allroot.shスクリプトを実行する方法は、第5.4.2項を参照してください。

12.4.2.3 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)ソフトウェア・バイナリの構成とアップグレード(2システム・アップグレード方式、サイレント・モード)

Enterprise Manager Cloud Controlのソフトウェア・バイナリを構成するには、次の手順に従います。

1. 次のレスポンス・ファイルをローカル・ホスト上のアクセス可能な場所にコピーします。
<Software_Location>/response/upgrade.rsp

このコマンドで、<Software_Location>はソフトウェア・キットをダウンロードした場所です。

2. レスポンス・ファイルを編集し、付録Aに示された変数に適切な値を入力します。

3. ConfigureGC.shスクリプトを起動して前のステップで編集したレスポンス・ファイルを渡し、ソフトウェア・バイナリを構成します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -silent -responseFile <absolute_path>/upgrade.rsp -staticPortsIniFile <absolute_path_to_staticports.ini_file> [-invPtrLoc <absolute_path_to_inventory_directory>]

注意:

- 第12.4.2.1項の説明に従ってソフトウェア・バイナリをインストールし、引数-invPtrLocを渡した場合、ここでも同じ引数を渡します。

- スクリプトの起動時に渡すことができる追加の拡張オプションの詳細は、第5.3.3.1項を参照してください。

- staticports.iniファイルは、ソフトウェア・キット(DVD、ダウンロードしたソフトウェアなど)の次の場所に含まれています。
<software_kit>/response/staticports.ini

- staticports.iniファイルで、Enterprise ManagerアップロードHttpポートおよびEnterprise ManagerアップロードHttp SSLポートに入力するポートが、アップグレード前コンソールで入力した保護および非保護ポートと一致することを確認します。

注意:
前提条件チェックでパッケージがないことが示された場合は、必要なパッケージをインストールすることを確認し、インストールを再試行します。インストーラによって、パッケージ名とバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールすることを確認します。インストーラがこれらのパッケージを検証するために使用するロジックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
欠落しているプラグインに関するエラーが表示される場合は、次の操作を実行します。

1. 欠落しているプラグインのエラー・メッセージに表示されているとおりに、プラグイン・バージョンおよびプラグイン・アップデートに関するメモを取ります。エラー・メッセージに表示されたプラグインは、次の形式で示されます。
PluginID:PluginVersion:PluginUpdate

2. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

3. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

4. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

5. ConfigureGC.shスクリプトを次のように起動して、ダウンロードしたプラグインをインストールします。
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

注意:
なんらかの検証エラーが発生した場合は、次の操作を実行します。

1. バックアップ・データベースを破棄します。

2. アップグレード前コンソールで問題を解決します。

3. ここでデータベースの新しいバックアップを作成します。

4. インストーラをもう一度起動し、アップグレード・プロセスを再試行します。

注意:
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

12.5 OMSおよび管理リポジトリの10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード(異なるホストでの1システム・アップグレード方式)

異なるホストの1システム方式で10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の既存のOMSおよび管理リポジトリをアップグレードするには、次の手順を実行します。

1. リモート・ホスト上に、Enterprise Manager Cloud Controlのソフトウェア・バイナリのみをインストールします。

- グラフィック・モードでソフトウェア・バイナリのみをインストールする手順は、第12.3.1.1項を参照してください。

- サイレント・モードでソフトウェア・バイナリのみをインストールする手順は、第12.4.1項を参照してください。

第12.3.1.1項(グラフィック・モード)の手順(15)および第12.4.1項(サイレント・モード)の手順(4)では、管理エージェントの削除について説明します。ただし、異なるホストでの1システム・アップグレードの場合、管理エージェントを削除しないでください。異なるホストでの1システム・アップグレード中、Enterprise Managerコンポーネントを監視するために、OMSホストにインストールした管理エージェントが必要です。

注意:
このリモート・ホストは、既存の以前のEnterprise Managerリリースが実行されているホストとは別のホストにする必要があります。

2. プラグインをデプロイします。
$<OMS_HOME>/sysman/install/PluginInstall.sh

「プラグインの選択」画面で、インストールするオプション・プラグインを選択します。

画面には、前の手順でソフトウェア・バイナリのインストールに使用したソフトウェア・キット(DVD、ダウンロードされたソフトウェア)に含まれていたプラグインのみが表示されます。

この画面で事前に選択されている行は、デフォルトでインストールされる必須プラグインです。インストールまたはアップグレードするオプションのプラグインを選択してください。

注意:

- Microsoft Windowsの場合は、PluginInstall.batを実行します。

- ソフトウェア・キットに含まれていない一部のプラグインをインストールする場合は、次の手順に従います。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. 次のオプションでスクリプトを起動して、インストールするプラグインを使用できる場所を渡します。
$<OMS_HOME>/sysman/install/PluginInstall.sh -pluginLocation <absolute_path_to_plugin_software_location>

「プラグインの選択」画面には、ソフトウェア・キットに含まれていたプラグインや、このカスタムの場所に含まれるダウンロード済プラグインの一覧が表示されます。インストールするものを選択できます。

3. 既存の以前のEnterprise Managerリリースが実行されているホストで、OMSを停止します。そのために、OMSホームから次のコマンドを実行します。
$<OMS_HOME>/bin/emctl stop oms -all

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%OMS_HOME%\bin\emctl stop oms -all

4. 手順(1)でEnterprise Manager Cloud Controlのソフトウェア・バイナリをインストールしたリモート・ホストで、環境変数ORACLE_HOMEをOMSホームに、MW_HOMEをミドルウェア・ホームに設定します。

- bashターミナルで、次のコマンドを実行します。
export ORACLE_HOME=<absolute_path_to_oms_home>

export MW_HOME=<absolute_path_to_middleware_home>

- 他のターミナルでは、次のコマンドを実行します。
setenv ORACLE_HOME <absolute_path_to_oms_home>

setenv MW_HOME <absolute_path_to_middleware_home>

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
set ORACLE_HOME=<absolute_path_to_oms_home>

set MW_HOME=<absolute_path_to_middleware_home>

5. Oracle Management Repository (管理リポジトリ)のアップグレード準備が整っているかどうかを検証するために、管理リポジトリ関連の前提条件チェックを実行します。

1. 前提条件の結果を保存するためのディレクトリを作成します。
mkdir <prereq_result_location>

たとえば、UNIXプラットフォームでは次のコマンドを実行します。

mkdir $ORACLE_HOME/prerequisiteResults

注意:
Microsoft Windowsでの例:
mkdir %ORACLE_HOME%\prerequisiteResults

2. 前提条件チェックを実行します。
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerport)))(CONNECT_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -configurationType <MINI/SMALL/MEDIUM/LARGE> -runPrerequisites -reposUser SYSMAN

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLRootDir %ORACLE_HOME%\install\requisites\list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerport)))(CONNECT_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -configurationType <MINI/SMALL/MEDIUM/LARGE> -runPrerequisites -reposUser SYSMAN

次に例を示します。

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list -prereqResultLoc $ORACLE_HOME/prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -configurationType SMALL -runPrerequisites -reposUser SYSMAN

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLRootDir %ORACLE_HOME%\install\requisites\list -prereqResultLoc %ORACLE_HOME%\prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -configurationType SMALL -runPrerequisites -reposUser SYSMAN

注意:

- 引数-configurationTypeを渡さないと、デフォルトでデプロイメント・サイズMEDIUMが使用されます。デプロイメント・サイズ、実行されている前提条件チェック、設定されているデータベース・パラメータと、インストール後のデプロイメント・サイズの変更方法の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

- この手順の出力では、前提条件チェックが成功または失敗したことを確認できます。「成功」または「失敗」のステータスが表示されます。

6. 管理リポジトリ関連の前提条件チェックが失敗した場合は、自動修正処理を実行し、自動的に問題を修正します。
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerport)))(CONNECT_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runCorrectiveActions -reposUser SYSMAN

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLRootDir %ORACLE_HOME%\install\requisites\list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerport)))(CONNECT_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runCorrectiveActions -reposUser SYSMAN

次に例を示します。

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list -prereqResultLoc $ORACLE_HOME/prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runCorrectiveActions -reposUser SYSMAN

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLRootDir %ORACLE_HOME%\install\requisites\list -prereqResultLoc %ORACLE_HOME%\prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runCorrectiveActions -reposUser SYSMAN

注意:
この手順の出力では、修正作業がスクリプトで行われたかどうかを確認できます。修正作業がスクリプトで行われた場合は、ステータス「成功」が表示されます。それ以外の場合はステータス「NA」が表示されます。
手順(4)の出力で前提条件チェックのステータスが「失敗」で、手順(5)の出力で「NA」に変更された場合は、次の手順を実行します。

1. 次のファイルにアクセスします。
UNIXプラットフォームの場合:

$ORACLE_HOME/prerequisiteResults/log/LATEST/emprereqkit.out

Microsoft Windowsプラットフォームの場合:

%ORACLE_HOME%\prerequisiteResults\log\LATEST\emprereqkit.out

2. 成功および失敗したテストとそれに対応する修正作業を確認します。

3. 失敗したテストについては、手動で修正作業を行います。

7. 前提条件モードで、プラグイン・コンフィギュレーション・アシスタントを実行します。
$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action prereqCheck -plugins <list_of_plugins> -oldOracleHome <old_oms_home> -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>))),username=sysman"

注意:
<pluginslist>引数に示されるプラグインは、次のファイルに含まれています。
$ORACLE_HOME/sysman/install/plugins_installed.txt

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action prereqCheck -plugins <list_of_plugins> -oldOracleHome <old_oms_home> -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>))),username=sysman"

次に例を示します。

$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action prereqCheck -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome /net/example.com/software/oracle/oms10g -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview))),username=sysman"

注意:
このコマンドを実行しているリモート・ホストから、古いOMSホームにアクセス可能であることを確認してください。

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action prereqCheck -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome \\oldem\c$\EM\oms10g -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview))),username=sysman"

8. 管理リポジトリ関連のアップグレード前チェックを実行します。
$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager <REPOSITORY_HOST> <PORT> <REPOSITORY_SID> -doPurging yes -action preupgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager <REPOSITORY_HOST> <PORT> <REPOSITORY_SID> -doPurging yes -action preupgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

次に例を示します。

$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager example.com 1521 dbview -doPurging yes -action preupgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\sysman\admin\emdrep\bin>RepManager example.com 1521 dbview -doPurging yes -action preupgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

9. 管理リポジトリをアップグレードします。
$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -action upgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

前述のコマンドが失敗した場合は、次のコマンドを実行します。

$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -resume retry -checkpointLocation $ORACLE_HOME/sysman/log/schemamanager -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -action upgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

前述のコマンドが失敗した場合は、次のコマンドを実行します。

%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -resume retry -checkpointLocation $ORACLE_HOME/sysman/log/schemamanager -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

次に例を示します。

$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<example.com> )(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -action upgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -action upgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

10. 手順(5)で自動的に実行された修正処理を元に戻します。
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runPostCorrectiveActions -reposUser SYSMAN

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLRootDir %ORACLE_HOME%\install\requisites\list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runPostCorrectiveActions -reposUser SYSMAN

次に例を示します。

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list -prereqResultLoc $ORACLE_HOME/prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runPostCorrectiveActions -reposUser SYSMAN

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLRootDir %ORACLE_HOME%\install\requisites\list -prereqResultLoc %ORACLE_HOME%\prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runPostCorrectiveActions -reposUser SYSMAN

11. 環境変数JAVA_HOMEをJDKの場所を設定します。
UNIXプラットフォームの場合:

setenv JAVA_HOME <MIDDLEWARE_HOME>/jdk16/jdk

次に例を示します。

setenv JAVA_HOME /u01/oracle/middleware/jdk16/jdk

Microsoft Windowsプラットフォームの場合:

set JAVA_HOME=<MIDDLEWARE_HOME>\jdk16\jdk

次に例を示します。

set JAVA_HOME=C:\Oracle\Middlware\jdk16\jdk

注意:
JDKを別の場所にインストール済の場合は、その場所の絶対パスを指定します。JDK 1.6.0.43.0 (64ビット・プラットフォームの場合は64ビット・バージョン、32ビット・プラットフォームの場合は32ビット・バージョン)であることも確認します。

12. 管理リポジトリにMDSスキーマを作成します。
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/sysman/admin/emdrep/bin/mdsschemamanager.pl -action=-createRepository -connectString=<REPOSITORY_HOST>:<PORT>:<REPOSITORY_SID> -dbUser=SYS -dbPassword=<db_password> -mdsPassword=<new_mds_user_password> -mwHome=$MW_HOME

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\sysman\admin\emdrep\bin\mdsschemamanager.pl -action=-createRepository -connectString=<REPOSITORY_HOST>:<PORT>:<REPOSITORY_SID> -dbUser=SYS -dbPassword=<db_password> -mdsPassword=<new_mds_user_password> -mwHome=%MW_HOME%

次に例を示します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/sysman/admin/emdrep/bin/mdsschemamanager.pl -action=-createRepository -connectString=example.com:1521:dbview -dbUser=SYS -dbPassword=dbpass -mdsPassword=mdspass -mwHome=$MW_HOME

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\sysman\admin\emdrep\bin\mdsschemamanager.pl -action=-createRepository -connectString=example.com:1521:dbview -dbUser=SYS -dbPassword=dbpass -mdsPassword=mdspass -mwHome=%MW_HOME%

13. 管理リポジトリにOPSスキーマを作成します。
$ORACLE_HOME/sysman/admin/emdrep/bin/SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -schemaPrefix sysman -schemaPassword <sysman_user_password> -component opss

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\sysman\admin\emdrep\bin\SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -schemaPrefix sysman -schemaPassword <sysman_user_password> -component opss

次に例を示します。

$ORACLE_HOME/sysman/admin/emdrep/bin/SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -schemaPrefix sysman -schemaPassword sysmanpass -component opss

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\sysman\admin\emdrep\bin\SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -schemaPrefix sysman -schemaPassword sysmanpass -component opss

14. OMSを構成します。
$ORACLE_HOME/bin/omsca NEW -lock_console -lock_upload -CONFIGURE_REPEATER true -nostart [-RESPONSE_FILE <absolute_location_to_response_file>]

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\bin\omsca NEW -lock_console -lock_upload -CONFIGURE_REPEATER true -nostart [-RESPONSE_FILE <absolute_location_to_response_file>]

注意:
引数-RESPONSE_FILE <absolute_location_to_response_file>はオプションです。

レスポンス・ファイルには次の変数が含まれている必要があります。

-AS_HOST=<hostname>
-AS_USERNAME=<admin serverr username>
-AS_HTTPS_PORT=<admin server https port>
-MSPORT=<managed server http port>
-MS_HTTPS_PORT=<managed server https port>
-EM_INSTANCE_HOME=<MW_HOME/gc_inst by default>
-EM_NODEMGR_PORT=<node manager https port>
-WEBTIER_ORACLE_HOME=<MW_HOME/Oracle_WT>
-REP_USER=SYSMAN
-REP_CONN_STR=<connection string>
-NM_USER=<node manager username>
-EM_DOMAIN_NAME=<domain name>
-EM_INSTANCE_HOST=<hostname where the instance home will reside>
-EM_UPLOAD_PORT=<upload http port>
-EM_UPLOAD_HTTPS_PORT=<upload https port>
-EM_CONSOLE_PORT=<console http port>
-EM_CONSOLE_HTTPS_PORT=<console https port>

UNIXのレスポンス・ファイル形式の例は次のとおりです。

-AS_HOST=example.com
-AS_USERNAME=weblogic
-AS_HTTPS_PORT=7101
-MSPORT=7201
-MS_HTTPS_PORT=7301
-EM_INSTANCE_HOME=/home/john/oracle/em/middleware/gc_inst
-EM_NODEMGR_PORT=7401
-WEBTIER_ORACLE_HOME=/home/john/oracle/em/middleware/Oracle_WT
-REP_USER=SYSMAN
-REP_CONN_STR=(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=1521)))(CONNECT_DATA\=(SID\=dbview)))
-NM_USER=nodemanager
-EM_DOMAIN_NAME=GCDomain
-EM_INSTANCE_HOST=example.com
-EM_UPLOAD_PORT=4889
-EM_UPLOAD_HTTPS_PORT=1159
-EM_CONSOLE_PORT=7788
-EM_CONSOLE_HTTPS_PORT=7799

Microsoft Windowsのレスポンス・ファイル形式の例は次のとおりです。

-AS_HOST=example.com
-AS_USERNAME=weblogic
-AS_HTTPS_PORT=7101
-MSPORT=7201
-MS_HTTPS_PORT=7301
-EM_INSTANCE_HOME=C\:\\Oracle\\Middleware\\gc_inst
-EM_NODEMGR_PORT=7401
-WEBTIER_ORACLE_HOME=C\:\\Oracle\\Middleware\\Oracle_WT
-REP_USER=SYSMAN
-REP_CONN_STR=(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=1521)))(CONNECT_DATA\=(SID\=dbview)))
-NM_USER=nodemanager
-EM_DOMAIN_NAME=GCDomain
-EM_INSTANCE_HOST=example.com
-EM_UPLOAD_PORT=4889
-EM_UPLOAD_HTTPS_PORT=1159
-EM_CONSOLE_PORT=7788
-EM_CONSOLE_HTTPS_PORT=7799

15. プラグインを構成します。
$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action deploy -plugins <pluginlist> -oldOracleHome <old_oms_home> -installMode gcupgrade

注意:
<pluginslist>引数に示されるプラグインは、次のファイルに含まれています。
$ORACLE_HOME/sysman/install/plugins_installed.txt

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action deploy -plugins "<pluginlist>" -oldOracleHome <old_oms_home> -installMode gcupgrade

次に例を示します。

$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action deploy -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome /net/example.com/software/oracle/middleware/oms11g -installMode gcupgrade

注意:
このコマンドを実行しているリモート・ホストから、古いOMSホームにアクセス可能であることを確認してください。

注意:
Microsoft Windowsでの例:
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action deploy -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome \\comp1\c$\EM\oms10g -installMode gcupgrade

16. プラグイン・インベントリを古い表から新しいプラグイン・ライフサイクル・アプリケーション(PLA)インベントリ表に移行します。

1. OMS古いまたは新しいOMSのいずれかからSYSMANユーザーとして、アップグレードした管理リポジトリにログインします。
古いOMSからの場合

古いOMSからログインするには、次の手順を実行します。

- $DB_HOME\binディレクトリに移動します。

たとえば(UNIX)、/scratch/aime/DB/db/binです。たとえば(Microsoft Windows)、C:\DB\db\binです。

- 次のコマンドを実行しますが、ここでHOSTは管理リポジトリが存在する場所です。

sqlplus sysman/<password _for_sysman_user>@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<REPOSITORY_SID>)))"

次に例を示します。

sqlplus sysman/mypwd@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=dbview)))"

新規OMSからの場合

新しいOMSからログインするには、次の手順を実行します。

- $MW_HOME\oms\binディレクトリに移動します。

- 次を実行します。

sqlplus sysman/<password _for_sysman_user>@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<REPOSITORY_SID>)))"

次に例を示します。

sqlplus sysman/mypwd@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=dbview)))"

2. 次のSQL問合せを実行します。

SET SERVEROUTPUT ON SIZE 100000
DECLARE
PLUGIN_BITS_TYPE     CONSTANT NUMBER := 1;
DISCOVERY_BITS_TYPE    CONSTANT NUMBER := 2;
AGENT_DEST_TYPE      CONSTANT NUMBER := 3;
err_num NUMBER;
err_msg VARCHAR2(100);

BEGIN
FOR rec in ( select plugin_id, plugin_version, target_guid, plugin_home,  plugin_type from PRE_UPGC_DEP_PLUGINS )
LOOP

BEGIN

IF rec.plugin_type = 'discoveryplugin' THEN
EM_PLUGIN_INVENTORY.add_to_plugin_inventory(rec.plugin_id, rec.plugin_version, DISCOVERY_BITS_TYPE, AGENT_DEST_TYPE, rec.target_guid, rec.plugin_home);
ELSE
EM_PLUGIN_INVENTORY.add_to_plugin_inventory(rec.plugin_id, rec.plugin_version, PLUGIN_BITS_TYPE, AGENT_DEST_TYPE, rec.target_guid, rec.plugin_home);
END IF;

EXCEPTION
WHEN DUP_VAL_ON_INDEX THEN
-- ALTER SESSION CLOSE DATABASE LINK PREUPGTO_NG_LINK;
DBMS_OUTPUT.PUT_LINE('Records already exists.');
WHEN OTHERS THEN
-- ALTER SESSION CLOSE DATABASE LINK PREUPGTO_NG_LINK;
err_num := SQLCODE;
err_msg := SUBSTR(SQLERRM, 1, 100);
DBMS_OUTPUT.PUT_LINE('Found exception Error Message :' || err_msg || ' Error Number ;' || err_num);

END;

END LOOP;
commit;
END;

/

17. OMSを起動します。
$ORACLE_HOME/bin/emctl start oms

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\bin\emctl start oms

18. 手順(1)でソフトウェア・バイナリをインストール中に、セキュリティ・アップデートの構成を選択した場合は、Oracle Configure Manager(OCM)を構成します。
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/sysman/install/RunOMSOCMConfig.pl $ORACLE_HOME $ORACLE_HOME/perl/bin/perl

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\sysman\install\RunOMSOCMConfig.pl %ORACLE_HOME% %ORACLE_HOME%\perl\bin\perl

19. 管理エージェントを構成します。そのために、管理エージェント・ホームから次のコマンドを実行します。
$ORACLE_HOME/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> OMS_HOST=<oms_host> EM_UPLOAD_PORT=<secure_oms_upload_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password> -configOnly

注意:
Microsoft Windowsの場合は、次のコマンドを実行します。
%ORACLE_HOME%\sysman\install\agentDeploy.bat AGENT_BASE_DIR=<absolute_path_to_agentbasedir> OMS_HOST=<oms_host> EM_UPLOAD_PORT=<secure_oms_upload_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password> -configOnly

次に例を示します。

/u01/app/Oracle/agent/core/12.1.0.5.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=/u01/app/Oracle/agent OMS_HOST=example.com EM_UPLOAD_PORT=1159 AGENT_REGISTRATION_PASSWORD=2bornot2b -configOnly

注意:
引数EM_UPLOAD_PORTには、保護(HTTPS)アップロード・ポート番号を入力してください。

注意:
Microsoft Windowsでの例:
C:\Oracle\agent\core\12.1.0.5.0\sysman\install\agentDeploy.bat AGENT_BASE_DIR=C:\Oracle\agent OMS_HOST=example.com EM_UPLOAD_PORT=1159 AGENT_REGISTRATION_PASSWORD=2bornot2b -configOnly

注意:
管理リポジトリのアップグレードがschemamanagerログの次のエラーで失敗した場合は、データベースを再起動して、アップグレードを再度試みます。
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL

12.6 複数OMS環境の10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)へのアップグレード

複数のOMSインスタンスがある10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)のEnterprise Manager Systemをアップグレードするには、次の手順を実行します。

1. 最初のOMSをアップグレードします。このガイドの第12.1項、第12.2項、第12.3項または第12.4項で説明されているいずれのアップグレード方式も使用できます。

注意:
アップグレード・プロセスは常に、追加のOMSインスタンスではなく、管理サーバーが実行されている最初のOMSで開始してください。
管理サーバーが実行されているOMSを特定するには、OMSホームで次のコマンドを実行して、出力に管理サーバーの詳細が表示されるかどうかを確認します。

$<OMS_HOME>/bin/emctl status oms -details

次のような出力が表示されます。

Oracle Enterprise Manager Cloud Control 12c
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : myhost.example.com
.
.
.
WLS Domain Information
Domain Name : GCDomain
Admin Server Host: myhost.example.com
.
.
.

2. システムの最初のOMSをアップグレードした後、次の手順を実行します。

- 2システム・アップグレード方式で最初のOMSをアップグレードした場合、旧リリースの追加のOMSを実行している他のすべてのホストに対して、Enterprise Manager Cloud Controlコンソールに用意されている管理サービスの追加デプロイメント・プロシージャを使用し、新しいOracle Management Service 12cをインストールします。
管理サービスの追加デプロイメント・プロシージャを使用して追加のOMSをインストールする方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 1システム・アップグレード方式で最初のOMSをアップグレードした場合、旧リリースの追加のOMSを実行している他のすべてのホストに対して、Enterprise Manager Cloud Controlインストール・ウィザードを起動し、「インストール・タイプ」画面で、「既存のEnterprise Managerシステムのアップグレード」を選択し、次に「1システムのアップグレード」を選択します。次に、アップグレードするOMSホームを選択します。

13 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードした後のアップグレード後タスクの実行

この章では、実行する必要があるインストール後のタスクについて説明します。特に、次の内容について説明します。

- Enterprise Managerがインストールされているホストの確認

- アップグレードした管理リポジトリへのリンクの作成

- 管理リポジトリがアップグレードされたデータベースの検出

- ソフトウェア・ライブラリの再構成

- エージェントのアップグレード・ステータスの確認

- 一般的なアップグレード後タスクの実行

- 遅延データ移行ジョブのステータスの追跡

- 見越データ移行ジョブのステータスの追跡

- 差分レポートの生成と表示

- アップグレードしたEnterprise Managerシステム内の非アクティブ・ターゲットの表示

- 発生データ移行プロセスのサインオフ

- 移行プロセスと既存のアップグレード・モードのサインオフ

- 古い中央エージェントおよび関連付けられているターゲットの削除

- (オプション)削除された中央エージェントで監視されていたターゲットの監視

- (オプション) 古いOMSホームの削除

- CDBおよびPDBで構成されたデータベースへのSYSMANスキーマの移行

- 外部ロール・オプションの有効化および作成

13.1 Enterprise Managerがインストールされているホストの確認

注意:
2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。

2システム・アップグレード方式の場合、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)のインストールに、クリーンな新規のホストを使用することをお薦めします。新規ホストにインストールされていることを確認します。

それには、「管理サービスとリポジトリ」ページでページ・タイトルの横にある情報アイコンをクリックします。表示された「ターゲット情報」リージョン(図13-1を参照)でホスト名を確認して、新しい12cのOMSをインストールしたホストが示されていることを確認します。さらに、ページ右上隅の「ターゲット名の検索」テキスト・ボックスのすぐ下にも同じホスト名が表示されていることを確認します(図13-1を参照)。

図13-1 ホストの確認

ホスト名が一致し、そのホスト名が新しい12cのOMSをインストールしたホストである場合は、新規ホストにインストールしたことの確認になります。

どちらかに別のホスト名が示される場合は、すでに管理エージェントが存在するホストにインストールしたことの確認になります。このような場合は、次の手順に従います。

1. すでに存在する管理エージェントを削除します。この管理エージェントおよびこれによって監視されているターゲットに関連する情報を、管理リポジトリからクリーンアップまたは削除します。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

2. 2システム・アップグレードの一部として新しい12c OMSとともにインストールされた新しい管理エージェントに、ホストをターゲットとして追加します。
これを行うには、新しい管理エージェント・ホームから次のコマンドを実行します。

$<AGENT_HOME>/bin/emctl config agent addInternaltargets

3. ホストがターゲットとしてEnterprise Manager Cloud Controlコンソールに追加されていることを確認します。それには、管理エージェントのホームページで、「監視」セクションの「監視ターゲット」タブにホストが表示されていることを確認します。

4. 古いOMSホストとともにインストールされた管理エージェントによって監視されている「管理サービスとリポジトリ」ターゲットを、2システム・アップグレードの一部として新しい12c OMSとともにインストールされた新しい管理エージェントに再配置します。
それには、SYSMANとしてログインし、EM CLIがインストールされている任意のホストで次のコマンドを実行します。

emcli relocate_targets -src_agent="<agent_installed_with_old_OMS>" -dest_agent="<new_agent_installed_with_new_12c_OMS>" -target_name="Management Services and Repository" -target_type=oracle_emrep -copy_from_src

5. 新しい、アップグレードされた管理リポジトリの接続記述子および資格証明を、「管理サービスとリポジトリ」ターゲットの監視構成設定として設定します。
それには、「管理サービスとリポジトリ」ホームページで、「OMSとリポジトリ」メニューから「ターゲット設定」、「監視構成」の順に選択します。「監視構成」ページで、新しい、アップグレードされた管理リポジトリの接続記述子と資格証明を入力します。「OK」をクリックします。

13.2 アップグレードした管理リポジトリへのリンクの作成

注意:
2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

2システム・アップグレード方式を使用してEnterprise Managerシステムをアップグレードするための前提条件として、既存のデータベースを最初にクローニング(またはバックアップ)して、それに構成するOracle Management Repository (管理リポジトリ)をアップグレードする必要があります。これは、アップグレードした管理リポジトリと旧リリースの管理リポジトリが共存していることを確認するためです。

ただし、バックアップしたデータベースの管理リポジトリをアップグレードした後、2つのリポジトリを相互にリンクしてアップグレードしたリポジトリの操作を古いリポジトリから直接実行できるように、管理リポジトリを旧リリースの管理リポジトリにリンクします。

警告:

両方のデータベースでGLOBAL_NAMESパラメータに設定されている値を確認してください。

- GLOBAL_NAMESパラメータが両方のデータベースでFALSEに設定されている場合は、アップグレードが終了するまでこの値を変更せず、すべての管理エージェントがスイッチオーバーされることを確認します。

- GLOBAL_NAMESパラメータがTRUEに設定されているのがどちらか一方のデータベースのみの場合や、両方のデータベースのGLOBAL_NAMEパラメータの値が同一である場合は、新しいクローン・データベースで設定されたGLOBAL_NAMEパラメータの値を、古いデータベースで設定されたものとは異なる値に設定します。

旧リリースのリポジトリをアップグレードしたリポジトリにリンクするには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページの「アップグレード・タイプの選択」セクションで、2システムを選択します。これらのアップグレード方式の詳細は、第2章を参照してください。
Enterprise Manager Grid Controlでページがリフレッシュされ、選択したアップグレード方式で実行する必要があるタスクのリストとともに表が表示されます。

4. OMSアップグレード・ステップ・セクションの表からアップグレードしたリポジトリへのリンクの作成をクリックします。

5. アップグレードしたOracle Management Repositoryリンクの作成ページのリポジトリ・リンクの詳細セクションで、次の手順を実行します。

1. 接続文字列を入力して、Enterprise Manager Cloud Controlで使用されるアップグレード後の管理リポジトリに接続します。

注意:
emgc.propertiesファイルのEM_REPOS_CONNECTDESCRIPTORパラメータの値として設定された接続文字列を確認します。このファイルは、OMSインスタンス・ベース・ディレクトリ(gc_inst)にあります。接続文字列としてこの値を入力する場合、必要であればすべての円記号(\)および空白を削除します。
たとえば、emgc.propertiesファイルの値は次のようになります。

(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=1521)))(CONNECT_DATA\=(SID\=emrep)))

接続文字列としてこの値を入力する場合、次のようになります。

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=emrep)))

SIDではなくサービス名を使用して接続する場合は、構文内のSIDをSERVICE_NAMEに置き換えます。

2. Enterprise Manager Cloud Controlで使用されるアップグレード後の管理リポジトリのSYSMANパスワードを入力します。

3. 古い管理リポジトリのSYSパスワードを入力します。

6. DBリンクの作成をクリックします。

注意:
すでにこれらの詳細を指定して2つのリポジトリをリンクしている場合に、接続記述子またはSYSMANパスワードを更新するには、「DBリンクの再作成」をクリックします。

13.3 管理リポジトリがアップグレードされたデータベースの検出

注意:
2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。

2システム・アップグレードの完了後、Enterprise Manager Cloud Controlコンソールでデータベースを監視できるように、管理リポジトリをアップグレードしたデータベースを手動で検出します。

手順については、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

13.4 ソフトウェア・ライブラリの再構成

注意:
2システム・アップグレード方式を使用してアップグレードする場合のみ、次の手順を実行します。

アップグレードしたソフトウェア・ライブラリを2システムのアップグレードで再構成するには:

注意:

- アップグレード後のEnterprise Manager 12cが同じホストで起動する1システム・アップグレードでは、アップグレードしたソフトウェア・ライブラリがシステムの起動時に有効になるため、再構成の必要はありません。
アップグレード後のEnterprise Manager 12cが異なるホストで起動する1システムのアップグレードの場合は、ソフトウェア・ライブラリ用に古い既存のEnterprise Managerシステムで構成されたすべての場所に、新しいホストからアクセスできる必要があります。

- 2システム・アップグレード、および異なるホストでの1システム・アップグレードの一部において、古い既存のEnterprise Managerシステムで構成された場所がローカル・ファイル・システム・パスの場合は、第9.1項で説明されている手順に従ってください。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリがアップグレードされた場合は、「ソフトウェア・ライブラリ」ホーム・ページに次の通知が表示されます。
ソフトウェア・ライブラリが最近アップグレードされましたが、まだ再構成されていません。ソフトウェア・ライブラリが使用可能になるのは、再構成を実行した後です。再構成プロセスを開始するには、「アップグレード後の再構成」をクリックしてください。

「アップグレード後の再構成」をクリックして、ソフトウェア・ライブラリを再構成します。

3. ソフトウェア・ライブラリの「場所の再構成」ページで、古い既存のEnterprise Managerシステムで構成された場所に対応する、構成対象の新しいファイル・システムの場所を入力します。

古いEnterprise Managerシステム用に構成された場所のアーカイブを、新しいファイル・システムの対応する場所に解凍する必要があります。また、新しい場所、およびそこにあるアーカイブされていないすべてのファイルとディレクトリは、12c OMSプロセス所有者に読取り/書込み権限があることを確認してください。

例:

古い既存のEnterprise Managerシステムで、ソフトウェア・ライブラリが次のファイル・システムの場所を使用するように構成されていると仮定します。

/shared/swlib1
/shared/swlib2

図13-2 2システムの再構成

アップグレード後、「場所の再構成」ページに次のように表示されます。

migrated1, /shared/swlib1
migrated2, /shared/swlib2

migrated1およびmigrated2は、アップグレードされた場所に自動的に割り当てられた名前です。

注意:
新しい場所ではOMS共有ファイル・システム記憶域の場所のみが再構成されるため、これらの新しい場所がNFSマウントされた共有の場所またはOCFS2の共有の場所であることを確認する必要があります。

さらに、既存の場所ごとにファイル・システムの代替パスを指定する必要があります。次に例を示します。

migrated1, /shared/swlib1, /vol/newswlib1
migrated2, /shared/swlib2, /vol/newswlib2

この構成を確認する前に、対応する構成済ソフトウェア・ライブラリ・ディレクトリのバックアップが、アーカイブされていない状態で新しい場所にあること、つまり、バックアップ作成時の/shared/swlib1と同じ内容が/vol/newswlib1 に含まれ、/shared/swlib2と同じ内容が/vol/newswlib2に含まれていることを確認する必要があります。

1. 「検証」をクリックして検証ジョブを発行し、移行されるエンティティの完全な検証チェックを実行します。必ず、このジョブが完了するまで追跡してください。検証エラーが発生した場合は、ジョブ・ステップに表示されます。一般的な検証エラーの一部を次に示します。
- 再構成用に指定された新しい場所が存在しません。

- 再構成用に指定された新しい場所は、OMSプロセス所有者に読取り/書込み権限がありません。

- 古いEnterprise Managerのソフトウェア・ライブラリで構成済の場所の内容が、再構成用に指定された対応する新しい場所にリストアされていません。

2. 検証が成功したら、「確認」をクリックしてソフトウェア・ライブラリを再構成します。SwlibUpgradeLocationsで始まる発行されるジョブが正常に完了するまで追跡した上で、パッチ適用やプロビジョニングのタスクを開始する必要があります。

13.5 エージェントのアップグレード・ステータスの確認

注意:
旧リリースのEnterprise Manager Grid Controlコンソールで、次の手順を実行します。

エージェントのアップグレード操作のステータスを確認するには、次の手順を実行します。

1. Grid Controlで「デプロイ」をクリックします。

2. デプロイ・ページの「アップグレード」セクションで、「Enterprise Manager 12cアップグレード・コンソール」をクリックします。

3. 「アップグレード・コンソール」ページで、次のことを行います。

- マクロ・レベルの詳細は、「エージェントのアップグレード・ステータス」セクションで次の表示数を参照します。

- 成功、正常にアップグレードした管理エージェントを識別します。

- 失敗、アップグレードに失敗した管理エージェントを識別します。

- 進行中、現在アップグレードしている管理エージェントを識別します。

- 開始されていません、まだアップグレードされていない管理エージェントを識別します。

- サポートされていません: Oracle Management Agent 12cが特定のプラットフォーム向けにリリースされていないためにアップグレード後のEnterprise Managerシステムでサポートされない管理エージェントを識別します。
ドリルダウンして詳細を表示するには、数値をクリックします。Enterprise Manager Grid Controlで情報を提供するエージェントのアップグレード・ステータス・ページが表示されます。

- ミクロレベルでの詳細は、「その他のリンク」セクションでエージェントのアップグレード・ステータスをクリックします。
エージェントのアップグレード・ステータス・ページで、次の操作を実行します。

- 要件に従ってリストをフィルタ処理して目的のアップグレード操作のみ表示するには、検索機能を使用します。
たとえば、失敗したデプロイメント操作のみ表示するには、「操作タイプ」リストから「デプロイ」、「操作のステータス」リストから「失敗」を選択して、「検索」をクリックします。

注意:
操作タイプは、デプロイ、構成、ヘルス・チェック、アップグレード、スイッチオーバーなどの特定のエージェント・アップグレード・ステップに発行されたジョブを参照します。操作名は、これらのジョブの発行時に指定した操作名を参照します。これらの各操作には、開始されていません、進行中、成功、サポートされていません、失敗、現行レポートの検証などのステータスを使用できます。

- エージェント・ソフトウェアをデプロイするには、表から1つ以上の管理エージェントを選択して、エージェントのデプロイおよび構成をクリックします。

注意:
問題のある管理エージェントに対しては、Oracle Management Agent 12cをデプロイおよび構成できません。問題のある管理エージェントを識別する方法の詳細は、第10.6.5項を参照してください。
また、完全にアップグレード可能か、欠落しているプラグインでアップグレード可能な既存の管理エージェントに対してのみ、Oracle Management Agent 12cをデプロイおよび構成できます。管理エージェントのアップグレード可能性ステータスの識別方法は、第10.6.3項を参照してください。

- デプロイする管理エージェントの状態および準備状況を確認するには、1つ以上の管理エージェントを選択して、エージェントの準備状況の確認をクリックします。

- 準備状況チェックの詳細を表示するには、1つ以上の管理エージェントを選択して「ヘルス・チェック・レポートの表示と確認」をクリックします。
エージェントの準備状況の確認詳細ページで、レポートを1つずつ確認します。レポートを検証したことを確認する場合、管理エージェントを選択して、レポートの検証およびサインオフをクリックします。準備状況の確認詳細を表示する場合、管理エージェントを選択して、詳細レポートの表示をクリックします。

- エージェントをスイッチオーバーするには、正常にデプロイ、構成およびヘルス・チェックされた1つ以上の管理エージェントを選択して、エージェントの切替えをクリックします。

13.6 一般的なアップグレード後タスクの実行

この項では、Enterprise Manager Cloud Controlへのアップグレード後に実行する必要があるアップグレード後の手順を説明します。この項では特に、次のアップグレード後の手順について説明します。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードした後の一般的なアップグレード後の手順の実行

- Oracle WebLogic Serverへのパッチ適用

- Oracle Exalogic Systemターゲットのアップグレード

- 追加OMSがアップグレードされる際の中央エージェントの再起動

- OCMスケジューラの停止

- 不要なターゲットの削除

- 削除済ターゲットの古いコンプライアンス標準のクリーンアップ

- インシデント・ルールの更新

- インシデント・ルール・セットの無効化

- SOAターゲットのメトリック収集エラーの解決

- Enterprise Managerアップグレード後のLinuxパッチ適用の有効化

- コンソールURLの更新

- カスタム構成の再実行

- カスタム証明書を使用したOracle WebLogic Serverの再構成

- 追加OMSのアップグレード後の管理エージェントの再起動

- 前のリリースで無効になっていたコンプライアンス標準の有効化

- Javaヒープ・メモリー引数の再設定

- Enterprise Managerシステムのアップグレード前にスキップしたジョブ・タイプのアップグレードの有効化

13.6.1 Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)にアップグレードした後の一般的なアップグレード後の手順の実行

次の一般的なアップグレード後のタスクを実行します。

1. 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の新しいEnterprise Managerシステムのインストール方法に関する章で概説されているアップグレード後の手順を実行します。

2. 健全性チェックとして、すべてのデータベース・パラメータがアップグレード操作を始める前に存在していた元の値に再設定されていることを、特にjob_queue_processesパラメータについて、確認します。

3. (1システム・アップグレード方式のみ)「管理サービスとリポジトリ」ターゲットを監視する管理エージェントを開始します。管理エージェントがメトリック収集のために管理リポジトリに接続しないように、2システム・アップグレードを開始する前に管理エージェントを停止します。アップグレード後に、確実に開始してください。

13.6.2 Oracle WebLogic Serverへのパッチ適用

Enterprise Managerシステムをアップグレードしているときに、サポートされているバージョンのOracle WebLogic Server (インストーラを起動する前にインストール済)をすでに含むミドルウェア・ホームの場所をインストーラで指定した場合は、そのOracle WebLogic Serverに必ずパッチ14482558、13349651および16080294を適用してください。これらのパッチなしでは、追加OMSのインストールが失敗します。

これらのパッチは、自分自身でインストールしたOracle WebLogic Serverを使用している場合にのみ必須です。空のミドルウェア・ホームの場所を指定した場合で、アップグレードの実行時にインストーラでOracle WebLogic Serverをインストールする場合は必須ではありません。

また、WebLogic Server PSU 10.3.6.8にはパフォーマンスおよびセキュリティに関する複数の修正が含まれているため、これも適用します。

13.6.3 Oracle Exalogic Systemターゲットのアップグレード

注意:
この項は、10gリリース5 (10.2.0.5)からのアップグレードには適用されません。

Oracle Exalogic Systemターゲットを必ずアップグレードしてください。

1. これを実行するには、「エンタープライズ」メニューから「ジョブ」を選択し、「ライブラリ」を選択します。

2. 「ジョブ・ライブラリ」ページで、ジョブ名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リリース4 (12.1.0.4)からのアップグレードで、12cリリース4 (12.1.0.4)へのアップグレード時にこの手順を実行していない場合は、ここで12cリリース5 (12.1.0.5)でこの手順を実行します。この場合、管理エージェントが12cリリース5 (12.1.0.5)、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のいずれかであることを確認します。

- Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)からのアップグレードで、12cリリース3 (12.1.0.3)へのアップグレード時にこの手順を実行していない場合は、ここで12cリリース5 (12.1.0.5)でこの手順を実行します。この場合、管理エージェントが12cリリース5 (12.1.0.5)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のいずれかであることを確認します。

- Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)からのアップグレードで、12cリリース2 (12.1.0.2)へのアップグレード時にこの手順を実行していない場合は、ここで12cリリース5 (12.1.0.5)でこの手順を実行します。この場合、管理エージェントが12cリリース5 (12.1.0.5)または12cリリース2 (12.1.0.2)のいずれかであることを確認します。

- 11gリリース1 (11.1.0.1)から12cリリース5 (12.1.0.5)にアップグレードした場合、管理エージェントは12cリリース5 (12.1.0.5)である必要があります。

これらの1つ以上の管理エージェントをサポートされるこれらのリリースにまだアップグレードしていない場合、ジョブが失敗し、Oracle Exalogic Systemターゲットはアップグレードされません。このような状況で問題を解決するには、最初に対象の管理エージェントをアップグレードしてから、Oracle Exalogic Systemターゲットをアップグレードするためのこのジョブを再発行します。

13.6.4 追加OMSがアップグレードされる際の中央エージェントの再起動

10gリリース5 (10.2.0.5)の追加OMSを、1システム・アップグレード方式を使用して12cリリース5 (12.1.0.5)にアップグレードした後、/EMGC_GCDomain/GCDomainで始まるターゲットが停止しているように表示される場合があります。

/EMGC_GCDomain/GCDomain/EMGC_OMS2
/EMGC_GCDomain/GCDomain/EMGC_OMS2/emgc
/EMGC_GCDomain/GCDomain/EMGC_OMS2/empbs
/EMGC_GCDomain/GCDomain/EMGC_OMS2/OCMRepeater
/EMGC_GCDomain/GCDomain/EMGC_OMS2/oracle.security.apm(11.1.1.3.0)

この問題を解決するには、まず追加OMSホスト上の管理エージェントが稼働していることを確認し、Enterprise Manager Cloud ControlコンソールでWeblogicドメインをリフレッシュしてから、追加OMSホスト上の管理エージェントを再起動します。

13.6.5 OCMスケジューラの停止

アップグレードしたEnterprise ManagerシステムにOCMがインストールされている場合は、次の手順を実行します。

- Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)からアップグレードした場合は、次の手順を実行します。

1. 環境変数ORACLE_HOMEをアップグレードされたOMSホームに設定します。

- bashターミナルで、次のコマンドを実行します。
export ORACLE_HOME=<absolute_path_to_oms_home>

- 他のターミナルでは、次のコマンドを実行します。
setenv ORACLE_HOME <absolute_path_to_oms_home>

2. OCMスケジューラを停止します。
$ORACLE_HOME/ccr/bin/emCCR stop

注意:
Oracle Management AgentにOCMスケジューラがインストールされている場合は、管理エージェントのホームでもこれらの手順を繰り返します。その場合は、手順(1)に従って環境変数ORACLE_HOMEを管理エージェントのホームに設定し、そのホームから手順(2)を実行します。

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードした場合は、次の手順を実行します。

1. 環境変数ORACLE_CONFIG_HOMEをOMSインスタンス・ホームに設定します。

- bashターミナルで、次のコマンドを実行します。
export ORACLE_CONFIG_HOME=<absolute_path_to_gc_inst>

- 他のターミナルでは、次のコマンドを実行します。
setenv ORACLE_CONFIG_HOME <absolute_path_to_gc_inst>

2. 環境変数ORACLE_HOMEをOMSホームに設定します。
setenv ORACLE_HOME <absolute_path_to_oms_home>

3. OCMスケジューラを停止します。
$ORACLE_HOME/ccr/bin/emCCR stop

注意:
Oracle Management AgentにOCMスケジューラがインストールされている場合は、管理エージェントのホームでもこれらの手順を繰り返します。その場合は、手順(1)をスキップし、手順(2)に従って環境変数ORACLE_HOMEを管理エージェントのホームに設定し、そのホームから手順(3)を実行します。

13.6.6 不要なターゲットの削除

旧リリースのEnterprise Managerを監視するために作成されたターゲットは、自動的に削除されません。これらのターゲットには、通知ルール、メトリックしきい値設定、コンプライアンス標準設定、ジョブなどが作成されている可能性があり、それらをEnterprise Manager Cloud Controlの新しいOracle WebLogic Serverのターゲットにコピーすることが必要になる場合があるためです。それらをコピーした後、これらのターゲットを手動で削除します。

この項では、これらの不要なターゲットを削除する方法について説明します。この項の具体的な内容は次のとおりです。

- 1システム・アップグレード後の不要なターゲットの削除

- 2システム・アップグレード後の不要なターゲットの削除

13.6.6.1 1システム・アップグレード後の不要なターゲットの削除

- Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)からのアップグレード後には、削除する不要なターゲットはありません。この場合、この項を無視できます。

- Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)のアップグレード後には、次のターゲットは自動的に削除されません。これらを手動で削除する必要があります。

- EM Webサイト

- EM Webサイト・システム

- Microsoft Operations Managerコネクタ・ターゲット(generic_mom_managed_host)

- 古い各OMSの次のターゲット。これらを削除するには、古い各OMSの最上位のOracle Application Serverターゲットを削除します。

- Oracle Application Server

- OC4J

- Oracle HTTP Server

- Web Cache

- Enterprise Manager 11g Grid Controlリリース1 (11.1.0.1)のアップグレード後には、次のターゲットは自動的に削除されません。これらを手動で削除する必要があります。

- EM Webサイト

- EM Webサイト・システム

- Microsoft Operations Managerコネクタ・ターゲット(generic_mom_managed_host)

- 古い各OMSの次のターゲット。これらを手動で削除するには、最上位のファーム・ターゲットsecFarm_GCDomainを削除します。

- Oracle Fusion Middlewareファーム

- Oracle WebLogicドメイン

- アプリケーション・デプロイメント

- メタデータ・リポジトリ

注意:
1システム・アップグレード方式でEnterprise Managerをアップグレードした後、これらのターゲットが稼働しているように表示される場合があります。このステータスはfalseです。いずれの場合も、このステータスの問題を解決しようとしないでください。これらのターゲットはEnterprise Manager Cloud Controlで不要になったため、手動で削除してください。

13.6.6.2 2システム・アップグレード後の不要なターゲットの削除

- 次のターゲットを手動で削除します。

- EM Webサイト

- EM Webサイト・システム

- Microsoft Operations Managerコネクタ・ターゲット(generic_mom_managed_host)

- 2システム・アップグレードの一部として中央エージェントおよびその監視ターゲットは自動的に削除されるため、古い中央エージェントを手動で削除する必要はありません。
自動的に削除されたターゲットの監視を継続する場合は、そのホストにOracle Management Agent 12cをインストールします。手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

13.6.7 削除済ターゲットの古いコンプライアンス標準のクリーンアップ

ユーザー定義コンプライアンス標準に関連付けられたターゲットをEnterprise Manager Cloud Controlコンソールから(またはEM CLIから)削除する場合、ターゲットはEnterprise Managerシステムから削除されますが、ユーザー定義コンプライアンス標準は完全には削除されません。これは、後にこのコンプライアンス標準を編集しようとする際に問題になります。この問題を回避するには、Enterprise Managerシステムのアップグレード後に、削除済ターゲットのすべての古いコンプライアンス関連データを手動で削除します。

削除済ターゲットに古いコンプライアンス関連のデータがあるかどうかを確認するには、SYSMANとして管理リポジトリで次のSQL問合せを手動で実行します。問合せの結果が1以上の場合、古いデータを手動で削除します。

select count(*) from em_cs_tgt_assoc_txf_req where root_target_guid not in (select target_guid from mgmt_targets);

削除済ターゲットのすべての古いコンプライアンス関連データを手動で削除するには、次の手順を実行します。

1. 管理リポジトリを格納しているデータベースにSYSMANユーザーとしてログインします。

2. My Oracle Supportノート1643222.1にアップロードされている次のクリーンアップ・スクリプトを実行します。
SQL>@cleanup_stale_data.sql

3. 次のSQL問合せを手動で実行し、結果がゼロになることを確認します。
SQL> select count(*) from sysman.em_cs_tgt_assoc_txf_req where root_target_guid not in (select target_guid from mgmt_targets);

13.6.8 インシデント・ルールの更新

アップグレード時には、旧リリースのEnterprise Managerで作成された「通知ルール」が、最初に「通知ルール」で定義されたターゲットに作用する、対応するインシデント・ルールセットに自動的に移行されます。 インシデント・ルールセットの詳細は、付録Bを参照してください。

ただし、Enterprise Manager Cloud Controlでターゲット・タイプ・モデリングが変更されている場合は、手動でルールを調整する必要があります。この項では、ルールセットを手動で調整する方法を説明します。

この項の具体的な内容は次のとおりです。

- インシデント・ルールの更新について

- 移動したメトリックのインシデント・ルールの更新

- 名前が変更されたメトリックのインシデント・ルールの更新

- インシデント・ルールの削除

13.6.8.1 インシデント・ルールの更新について

旧リリースのEnterprise Managerでは、「OMSとリポジトリ」が、環境内のすべてのOMSインスタンスに対して定義される共通のターゲット・タイプでした。また、異なるOMSインスタンスに対して収集されたメトリックは、この共通のターゲット・タイプ内に表示されていました。

しかし、Enterprise Manager Cloud Controlでは、ターゲット・タイプ「OMSとリポジトリ」に加えて、環境内の各OMSインスタンスを表す新しいターゲット・タイプ、「Oracle Management Service」が導入されました。これにより、環境内に5つのOMSインスタンスがある場合は、ターゲット・タイプ「OMSとリポジトリ」が1つ、およびターゲット・タイプ「Oracle Management Service」のインスタンスが5つ(OMSごとに1つ)表示されます。

ターゲット・タイプ「OMSとリポジトリ」では、環境内のすべてのOMSインスタンスに共通するメトリックが取得されるのに対して、ターゲット・タイプ「Oracle Management Service」では、各OMSに固有のメトリックが取得されます。

表13-1に、メトリックのリスト、新しいターゲット・タイプ「Oracle Management Service」の導入のために行われた変更、および変更に対して実行する必要があるアクションを示します。

表13-1 メトリックに対する変更および必要な更新

変更タイプ

変更の説明

影響を受けるメトリック

必要なアクション

保持

一部のメトリックは、同じターゲット・タイプ(「OMSとリポジトリ」)用に保持されています。

保持されているメトリックは次のとおりです。

- 実行待機中の収集

- DBMSジョブ無効スケジュール

- DBMSジョブ処理時間(最近1時間の割合)

- DBMSジョブの稼働/停止

- デキュー・ステータス

- エンキュー・ステータス

- ジョブ・ステップ・バックログ

- 通知の稼働/停止

- アクティブなエージェントの数

- ロード保留中のファイル全体 - エージェント

- 過去1時間にローダーによって処理された全行数

- エージェントの再起動数

- ターゲットの追加率(過去1時間)

- ユーザーの追加率(過去1時間)

変更する必要はありません。

移動

一部のメトリックは、個別のターゲット・タイプ(「Oracle Management Service」)に移動しました。

移動したメトリックは次のとおりです。

- ローダー・スループット(行/秒)

- 最近1時間のローダー・ランタイム合計(秒)

- 管理サービスのステータス

- ジョブ・ディスパッチャ処理時間(最近1時間の割合)

- サービス・ステータス

- リポジトリ・セッション数
[注意: このメトリックは、子ターゲット「OMSコンソール」および「OMSプラットフォーム」の下に移動しました]

異なるターゲット・タイプに移動したメトリックに対応する、新しいインシデント・ルールを設定します。

第13.6.8.2項を参照してください

名前の変更

一部のメトリックは、わかりやすい名前に変更されました。

名前が変更されたメトリックは次のとおりです。

- 1メソッド当たりの平均通知配信時間(ミリ秒) [変更後の名前は「平均通知時間(秒)」]

- 通知待機 [変更後の名前は「保留通知数」]

名前が変更されたメトリックに設定されているインシデント・ルールを更新します。

第13.6.8.3項を参照してください

廃止

一部のメトリックは、Enterprise Manager Cloud Controlでサポートされないため、廃止されました。

廃止されたメトリックは次のとおりです。

- 重複したターゲット数

- 通知処理時間(最近1時間の割合)

- ロード保留中のファイル全体 - ローダー

- 通知待機
(注意: これは、名前が変更された「通知待機」メトリックとは異なります。名前が変更された方にはオブジェクトがありますが、これにはオブジェクトはありません。)

廃止されたメトリックをインシデント・ルールから削除します。

第13.6.8.4項を参照してください

13.6.8.2 移動したメトリックのインシデント・ルールの更新

移動したメトリックに設定されているインシデント・ルールをEnterprise Manager Cloud Controlの個別のターゲット・タイプ「Oracle Management Service」に更新するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「インシデント」 を選択して「インシデント・ルール」をクリックします。

2. 「インシデント・ルール」ページで、Oracle Management Service(OMS)用に作成されたインシデント・ルールを選択し、「編集」をクリックします。

3. 「ルール・セットの編集」ページの「ルール」タブで、移動したメトリックに作用するイベント・ルールを選択し、「編集」をクリックします。
選択したインシデント・ルール・セットのインシデント・ルールを編集できる、Enterprise Managerのルールの編集ウィザードが表示されます。

4. ルールの編集ウィザードで、次の手順を実行します。

1. 「イベントの選択」ページで、表13-1の2行目にリストされているメトリックを選択し、「削除」をクリックします。

2. 「次へ」をクリックします。

3. 「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。

4. 「確認」ページで「続行」をクリックします。

5. 「保存」をクリックします。
Enterprise Managerの「インシデント・ルール」ページが表示されます。

6. 「インシデント・ルール」ページで「ルール・セットの作成」をクリックします。

7. 「ルール・セットの作成」ページで、ルール・セットの一意の名前を入力します。

8. 「ターゲット」タブで、「すべてのターゲットのタイプ」→「Oracle Management Service」を選択します。

9. 「ルール」タブで「作成」をクリックします。

10. 「作成するルールのタイプを選択」ダイアログで、「イベント・ルール」を選択して「続行」をクリックします。
新しいインシデント・ルール・セットを作成できる、Enterprise Mangerの新規ルールの作成ウィザードが表示されます。

11. 新規ルールの作成ウィザードで、次の手順を実行します。

1. 「イベントの選択」ページで、「イベント・タイプ」リストから「メトリック・アラート」を選択します。

注意:
メトリック「管理サービスのステータス」に対して、「イベント・タイプ」リストから「ターゲット可用性」を選択します。

2. 「特定のメトリック・アラート」を選択して「追加」をクリックします。

3. 「特定のメトリック・アラートを選択」ダイアログで、次の手順を実行します。

1. 「検索」リージョンの「ターゲット・タイプ」リストから「Oracle Management Service」を選択し、「検索」をクリックします。

2. 表13-1の2行目にリストされている移動したメトリックを、表から選択します。

3. 「重大度と修正処理のステータス」 リージョンの「重大度」リストから、適切な重大度レベルを選択します。

4. 「OK」をクリックします。

4. 「次へ」をクリックします。

5. 「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。

6. 「確認」ページで「続行」をクリックします。

12. 「保存」をクリックします。
Enterprise Managerの「インシデント・ルール」ページが表示されます。

注意:
OMS用に作成されている他のすべてのインシデント・ルールに対して、この手順を繰り返します。

13.6.8.3 名前が変更されたメトリックのインシデント・ルールの更新

Enterprise Manager Cloud Controlで名前が変更されたメトリックに対して設定されているインシデント・ルールを更新するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「インシデント」 を選択して「インシデント・ルール」をクリックします。

2. 「インシデント・ルール」ページで、Oracle Management Service(OMS)用に作成されたインシデント・ルールを選択し、「編集」をクリックします。

3. 「ルール・セットの編集」ページの「ルール」タブで、名前が変更されたメトリックに作用するイベント・ルールを選択し、「編集」をクリックします。
選択したインシデント・ルール・セットのインシデント・ルールを編集できる、Enterprise Managerのルールの編集ウィザードが表示されます。

4. ルールの編集ウィザードで、次の手順を実行します。

1. 「イベントの選択」ページで、表13-1の3行目にリストされているメトリックを選択し、「削除」をクリックします。

2. 「追加」をクリックします。

3. 「特定のメトリック・アラートを選択」ダイアログで、次の手順を実行します。

1. 「検索」リージョンの「ターゲット・タイプ」リストから「OMSとリポジトリ」を選択し、「検索」をクリックします。

2. 表13-1の3行目にリストされている、名前が変更されたメトリックを、表から選択します。

3. 「重大度と修正処理のステータス」 リージョンの「重大度」リストから、適切な重大度レベルを選択します。

4. 「OK」をクリックします。

4. 「次へ」をクリックします。

5. 「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。

6. 「確認」ページで「続行」をクリックします。

注意:
OMS用に作成されている他のすべてのインシデント・ルールに対して、この手順を繰り返します。

13.6.8.4 インシデント・ルールの削除

廃止されたメトリックをインシデント・ルールから削除するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「インシデント」 を選択して「インシデント・ルール」をクリックします。

2. 「インシデント・ルール」ページで、Oracle Management Service(OMS)用に作成されたインシデント・ルールを選択し、「編集」をクリックします。

3. 「ルール・セットの編集」ページの「ルール」タブで、メトリック・アラート・イベント・ルールを選択して「編集」をクリックします。
選択したインシデント・ルール・セットのインシデント・ルールを編集できる、Enterprise Managerのルールの編集ウィザードが表示されます。

4. ルールの編集ウィザードで、次の手順を実行します。

1. 「イベントの選択」ページで、表13-1の最後の行にリストされているメトリックを選択し、「削除」をクリックします。

2. 「次へ」をクリックします。

3. 「アクションの追加」ページおよび「名前と説明の指定」ページで、何も変更せずに「次へ」をクリックします。

4. 「確認」ページで「続行」をクリックします。

注意:
OMS用に作成されている他のすべてのインシデント・ルールに対して、この手順を繰り返します。

13.6.9 インシデント・ルール・セットの無効化

2システム・アップグレード方式でアップグレードした場合は、デフォルトのインシデント・ルール・セットを無効にします。これらを無効にしない場合、すべてのクリティカルなメトリック・アラートに対してインシデントが自動的に作成されます。

デフォルトのインシデント・ルール・セットを無効にするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「インシデント」、「インシデント・ルール」の順に選択します。

2. 「インシデント・ルール - すべてのエンタープライズ・ルール」ページで表を下にスクロールし、「すべてのターゲットのインシデント管理ルールセット」を開きます。

3. 無効にするルール・セットの行を選択します。

4. 「アクション」メニューから「無効化」をクリックします。

5. ポップアップ・ウィンドウで「OK」をクリックします。

6. 無効にするルール・セットごとに、手順(3)から(5)を繰り返します。

7. すべてのルール・セットを無効にした後、表の「有効」列に「いいえ」と表示され、その横に警告アイコンがあることを確認してください。

13.6.10 SOAターゲットのメトリック収集エラーの解決

旧リリースのEnterprise ManagerでSOAターゲットを監視していた場合は、第11.2項の説明に従って生成した状態レポートに、メトリック「SOAの上位SQL問合せ」および「デハイドレーション・ストア表」に対するメトリック収集エラーが表示されていた可能性があります。

この問題を解決するには、SOAターゲットの「監視構成」ページにアクセスしてデータベース資格証明を入力します。

13.6.11 Enterprise Managerアップグレード後のLinuxパッチ適用の有効化

注意:
この項は、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からEnterprise Manager Cloud Control 12cにアップグレードする場合にのみ適用されます。

前のリリースでタイプがDownloadLatestPkgsまたはUpdateHostPackagesのジョブをスケジュールしていた場合は、12cリリース5 (12.1.0.5)にアップグレードした後で、資格証明がないためにそれらのジョブが失敗します。このため、この問題を解決するには、次のいずれかの方法を実行します。

- ジョブを停止して資格証明をリセットした後でのすべてのアクティブなLinuxパッチ適用ジョブの再発行

- ジョブを停止せずに資格証明をリセットした後でのすべてのアクティブなLinuxパッチ適用ジョブの再発行

13.6.11.1 ジョブを停止して資格証明をリセットした後でのすべてのアクティブなLinuxパッチ適用ジョブの再発行

アップグレードの後で、アップグレード前に発行されていたすべてのアクティブなLinuxパッチ適用ジョブを停止し、それらの資格証明をリセットしてから、同じターゲットでジョブを再発行する必要があります。これを行うには、次の項の手順に従います。

- DownloadLatestPackagesジョブを停止して資格証明をリセットした後でのジョブの再発行

- UpdateHostPackagesジョブを停止して資格証明をリセットした後でのジョブの再発行

注意:
アクティブなLinuxパッチ適用ジョブを停止したくない場合は、第13.6.11.2項を参照してください。

13.6.11.1.1 DownloadLatestPackagesジョブを停止して資格証明をリセットした後でのジョブの再発行

すべてのDownloadLatestPackagesジョブを停止して再発行するには、次の手順に従います。

1. 次の手順で、アップグレード前にスケジュールされたアクティブ・ジョブを停止します。

1. 「エンタープライズ」メニューから「ジョブ」→「アクティビティ」を選択します。「ジョブ・アクティビティ」ページが表示されます。

2. 「ジョブ・アクティビティ」ページで「拡張検索」リンクをクリックします。

3. 「拡張検索」オプションで、「ジョブ・タイプ」に対してDownloadLatestPkgs、「ターゲット・タイプ」に対して「ホスト」、「ステータス」に対して「アクティブ」、「スケジュール開始」に対して「すべて」を選択し、「実行」をクリックします。

4. 拡張検索結果で、表にリストされている各ジョブを選択し、「停止」をクリックします。

2. アクティブなDownloadLatestPkgsジョブが停止された各ホスト・ターゲットに対して、新しいDownloadLatestPkgsジョブを次のように再発行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」→「Linuxパッチ適用」を選択します。「パッチ適用設定」ページが表示されます。

2. 「パッチ適用設定」ページで「RPMリポジトリの設定」をクリックします。

3. 「RPMリポジトリの設定」ページでホスト・ターゲットを選択し、このホスト・ターゲットの「通常ホスト資格証明」および「特権ホスト資格証明」を設定します。

4. 「適用」をクリックして新しいジョブを発行します。

13.6.11.1.2 UpdateHostPackagesジョブを停止して資格証明をリセットした後でのジョブの再発行

すべてのUpdateHostPackagesジョブを停止して再発行するには、次の手順に従います。

1. 次の手順で、アップグレード前にスケジュールされたアクティブ・ジョブを停止します。

1. 「エンタープライズ」メニューから「ジョブ」→「アクティビティ」を選択します。「ジョブ・アクティビティ」ページが表示されます。

2. 「ジョブ・アクティビティ」ページで「拡張検索」リンクをクリックします。

3. 「拡張検索」オプションで、「ジョブ・タイプ」に対してUpdateHostPackages、「ターゲット・タイプ」に対して「ジョブが発行されたすべてのターゲット・タイプ」、「ステータス」に対して「アクティブ」、「スケジュール開始」に対して「すべて」を選択し、「実行」をクリックします。

4. 拡張検索結果で、表にリストされている各ジョブを選択し、「停止」をクリックします。

2. アクティブなUpdateHostPackagesジョブが停止された各グループ・ターゲットに対して、新しいUpdateHostPackagesジョブを次のように再発行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」→「Linuxパッチ適用」を選択します。

2. 「パッチ適用設定」ページで「グループの設定」をクリックします。「グループの設定」ページが表示されます。

3. 「グループの設定」ページで、アクティブなUpdateHostPackagesジョブを停止したグループを選択して「編集」をクリックします。グループの編集ウィザードが表示されます。

4. 「グループの編集: プロパティ」ページで「次へ」をクリックします。

5. 「グループの編集: パッケージ・リポジトリ」ページで「次へ」をクリックします。

6. 「グループの編集: 資格証明」ページで、Host Preferred Credentialsまたは「優先資格証明のオーバーライド」を使用して、「通常ホスト資格証明」および「特権ホスト資格証明」を指定します。「次へ」をクリックします。

注意:
このステップを編集する前に、ホスト優先資格証明がすでに設定されていること、または適切な名前付き資格証明がすでに作成されていることを確認してください。まだ行われていない場合は、「設定」メニューから「セキュリティ」→「名前付き資格証明」を選択して名前付き資格証明または「優先資格証明」を作成し、Linuxパッチ適用グループに含まれるホスト・ターゲットの優先資格証明を設定します。

7. 「グループの編集: 確認」ページで「終了」をクリックして、新しいジョブを発行します。

13.6.11.2 ジョブを停止せずに資格証明をリセットした後でのすべてのアクティブなLinuxパッチ適用ジョブの再発行

アップグレードの後で、アップグレード前に発行されていたすべてのアクティブなLinuxパッチ適用ジョブの資格証明をリセットしてから、それらのジョブを再発行する必要があります。次の手順を実行します。

1. 「エンタープライズ」メニューから「ジョブ」、「アクティビティ」の順に選択します。

2. 「ジョブ・アクティビティ」ページで「拡張検索」をクリックします。

3. 「拡張検索」リージョンの「名前」フィールドにジョブ名PACKAGES UPDATE%を入力し、「ジョブ・タイプ」リストで「UpdateHostPackages」を選択します。「実行」をクリックします。

4. 検索結果表でジョブを選択し、「編集」をクリックします。

5. 'UpdateHostPackages'ジョブの編集ページの「資格証明」タブをクリックします。

6. 「資格証明」タブで必要な資格証明を設定します。

7. 「送信」をクリックします。

8. ジョブ・タイプDownloadLatestPkgsのDOWNLOADLATESTPKGS%という名前のジョブについて、手順(3)から手順(7)を繰り返します。

13.6.12 コンソールURLの更新

アップグレードしたOMSにサーバー・ロード・バランサ(SLB)が構成されている複数OMS環境の場合、「管理サービスとリポジトリ」ページのコンソールURLを更新してください。ここで入力したコンソールURLは、Enterprise Managerから送信される電子メールで、Enterprise Manager Cloud Controlコンソールに戻るリンクを作成するために使用されます。

コンソールURLを更新するには、次の手順に従います。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。

2. 「概要」セクションの「管理サービスとリポジトリ」ページで、「コンソールURL」ラベルで「編集」をクリックして、URLをSLB URLに変更します。
たとえば、http://www.example.com, https://www.example.com:4443にします。

注意:
コンソールURLを/emで終わらせないでください。

3. Enterprise Managerから送信される電子メールに更新したコンソールURLが正しく表示されるかどうかを確認します。

13.6.13 カスタム構成の再実行

12cリリース5 (12.1.0.5)へのアップグレードはアウトオブプレース・アップグレードであるため、旧リリースのEnterprise Managerシステムで行われたカスタム構成と、旧リリースのEnterprise Managerシステムで構成されたWebLogic Serverで行われたカスタマイズはすべて、アップグレード・プロセスによって継承されません。アップグレードしたシステムで、カスタマイズを再実行する必要があります。たとえば、emd.propertiesファイルのLDAP構成は継承されないため、アップグレード後にemd.propertiesファイルで再構成する必要があります。

13.6.14 カスタム証明書を使用したOracle WebLogic Serverの再構成

注意:

- この項は、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 WebLogic Serverのカスタム証明書にのみ適用され、Enterprise Managerコンソールの証明書には適用されません。Enterprise Managerコンソールの証明書は、アップグレード時に自動的にコピーされます。

12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のOracle WebLogic Server (管理サーバーおよび管理対象サーバー)にカスタム証明書が構成されていた場合、12cリリース5 (12.1.0.5)へのアップグレード後にそのカスタム証明書は引き継がれません。かわりに、Oracle WebLogic Serverはデモ証明書を使用して構成されます。そのため、アップグレード後にカスタム証明書を使用してOracle WebLogic Serverを再構成してください。次の手順を実行します。

1. すべてのOMSインスタンス上で次のコマンドを実行します。このコマンドおよび渡すことのできるオプションの詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドを参照してください。
$<OMS_Home>/bin/emctl secure wls <options>

2. すべてのOMSインスタンスを停止します。
$<OMS_Home>/bin/emctl stop oms -all

3. すべてのOMSインスタンスを開始します。
$<OMS_Home>/bin/emctl start oms

13.6.15 追加OMSのアップグレード後の管理エージェントの再起動

第4章で説明されているように、最初のOMSを12cリリースX (12.1.0.X)から12cリリース5 (12.1.0.5)にアップグレードした後、そのホストの中央エージェントを即座にアップグレードすることを強くお薦めします。

ただし、そのホストの中央エージェントをアップグレードせずに追加OMSの12cリリースX (12.1.0.X)から12cリリース5 (12.1.0.5)へのアップグレードを続行した場合は、そのアップグレード済の追加OMSのバージョンを管理サービス・ページで確認します。これを実行するには、「設定」メニューから、「Cloud Controlの管理」、「管理サービス」の順に選択します。OMSバージョンを確認します。

まだアップグレードされたバージョンではなく古いバージョンが表示されている場合は、追加OMSホストの管理エージェントを再起動します。

13.6.16 前のリリースで無効になっていたコンプライアンス標準の有効化

12cリリース5 (12.1.0.5)にアップグレードすると、前のリリースで無効になっていたコンプライアンス標準が、12cリリース5 (12.1.0.5)では自動的に有効になります。これらのコンプライアンス標準を無効にしておく必要がある場合は、アップグレードした後で12cリリース5 (12.1.0.5)のターゲットごとに手動で無効化します。次の手順を実行します。

1. 「エンタープライズ」メニューから「コンプライアンス」、「ライブラリ」の順に選択します。

2. 「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準」タブをクリックします。

3. 「コンプライアンス標準」タブでコンプライアンス標準を選択し、「ターゲットの関連付け」をクリックします。

4. 「コンプライアンス標準ターゲット・アソシエーション」ページでターゲットを選択し、「編集」をクリックします。

5. 「コンプライアンス標準のターゲット設定」ページにおいて、左側のツリー・ビューでルール・ノードを選択し、右側のパネルの「コンプライアンス標準ルールの評価ステータス」リストで「無効」を選択します。「OK」をクリックします。

6. 「コンプライアンス標準ターゲット・アソシエーション」ページで「OK」をクリックします。

13.6.17 Javaヒープ・メモリー引数の再設定

12cリリース5 (12.1.0.5)にアップグレードすると、Javaヒープ・メモリーの引数がデフォルト値に自動的に設定されるため、旧リリースのEnterprise Manager Cloud Controlで引数に対して行われたカスタマイズはすべてアップグレード後のOMSまで存続しません。Javaメモリーの引数を手動でカスタム値にリセットする必要があります。

たとえば、旧WebLogic Server構成ファイルでヒープ・サイズを8GBにカスタマイズしていた場合、12cリリース5 (12.1.0.5)にアップグレードすると、ヒープ・サイズはデフォルト値の4GBにリセットされます。したがって、アップグレード後手順として、ヒープ・サイズをカスタム値の8GBに手動でリセットする必要があります。

12cリリース3 (12.1.0.3)および12cリリース2 (12.1.0.2)では、JAVA_EM_MEM_ARGS引数がサポートされていましたが、この引数はOMSのメモリー設定だけでなく、Oracle BI PublisherなどのEnterprise Manager Cloud Controlと統合されている他のコンポーネントのメモリー設定も変更しました。この引数は、12cリリース4 (12.1.0.4)以上ではサポートされなくなっています。

12cリリース4 (12.1.0.4)以上では、次のJavaヒープ・メモリーの引数がサポートされています。

- OMS_HEAP_MIN

- OMS_HEAP_MAX

- OMS_PERMGEN_MIN

- OMS_PERMGEN_MAX

12cリリース5 (12.1.0.5)へのアップグレード後に前述のJavaヒープ・メモリーの引数をリセットするには、次の手順を実行します。

1. OMSの引数に設定されている現在の値をチェックします。
emctl get property -name <argument_name>

次に例を示します。

emctl get property -name OMS_HEAP_MAX

2. 次のように値を再設定します。
emctl set property -name <argument_name> -value <value_followed_by_G_or_M>

次に例を示します。

emctl set property -name OMS_HEAP_MAX -value 8192M

3. OMSを停止します。
emctl stop oms-all

4. OMSを起動します。
emctl start oms

5. 次の手順のいずれかの変更を確認します。

- OMSベース・インスタンスのホーム・ディレクトリ(gc_inst)のemgc.propertiesファイルにアクセスし、再設定する引数の値をチェックします。

- 次のコマンドを実行して、再設定した引数の値をチェックします。
ps -aef | grep weblogic.Server | grep EMGC_OMS1

13.6.18 Enterprise Managerシステムのアップグレード前にスキップしたジョブ・タイプのアップグレードの有効化

表4-1の手順2 (j)の説明に従って特定のジョブ・タイプのアップグレードを選択してスキップまたは後回しにした場合は、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;

13.7 遅延データ移行ジョブのステータスの追跡

この項の内容は次のとおりです。

- 遅延データ移行ジョブについて

- 遅延データ移行ジョブのステータスの追跡

13.7.1 遅延データ移行ジョブについて

遅延データ移行は、旧リリースの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ジョブが即時実行されないようにする場合は、第10.3項および第10.2項(手順6)を参照してください。

- 実行中のDDMPジョブの取消しまたは停止は、推奨されません。

警告:

DDMPジョブの実行中は、OMSまたは管理リポジトリを停止または再起動しないでください。

13.7.2 遅延データ移行ジョブのステータスの追跡

アップグレード後に、遅延データ移行ジョブのステータスをチェックします。特に、FLATアソシエーション構築タスクが正常に完了していることを確認します。

遅延データ移行ジョブのステータスを追跡するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。

2. アップグレード後のタスク・ページで、「遅延データ移行」タブをクリックします。
このタブには、データ移行ジョブのリスト、およびジョブのステータス、開始日時、終了日時が表示されます。

3. このタブでは次の処理が可能です。

- コンポーネントに対してデータ移行ジョブを開始するには、コンポーネントを選択して「開始」をクリックします。デフォルトでは、ジョブはただちに開始されます。この動作は変更できません。

- 失敗したジョブを再実行するには、ステータス・アイコンをクリックして「ジョブ実行」ページにアクセスします。「ジョブ実行」ページで「編集」をクリックします。<JobName>ジョブの編集ページで、「発行」をクリックしてジョブを再実行します。

- 表の列の表示/非表示を切り替えるには、「表示」リストから適切なオプションを選択します。

- 画面から表をデタッチするには、「デタッチ」をクリックします。

13.8 発生データ移行ジョブのステータスの追跡

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。

この項の内容は次のとおりです。

- 発生データ移行ジョブについて

- 見越データ移行ジョブのステータスの追跡

13.8.1 発生データ移行ジョブについて

発生データ移行は、旧リリースのOracle Management Repository(管理リポジトリ)に格納されている発生データをアップグレード後の管理リポジトリに移行する、アップグレード後アクティビティの1つです。発生データは、ブラックアウト、アラート、イベント、メトリックなどの機能領域に関連しています。

注意:
発生データ移行プロセスでは、管理リポジトリのバックアップ後に実行された次の変更は、どれも移行されません。これらの変更がアップグレード後のEnterprise Managerシステムで必要な場合は、アップグレードにこれらの変更を再度手動で実行する必要があります。

- セキュリティ・データ(作成された新規ユーザー、変更されたパスワード)

- 作成、削除または発行されたジョブ

- カスタマイズされたデプロイメント・プロシージャ

- パッチ

- 追加または削除されたターゲット

- 作成、変更または削除されたレポート

- ソフトウェア・ライブラリの構成変更

- 作成、変更または削除されたテンプレート

- ユーザー定義メトリック

第13.9項に記載されている差分レポートを確認して、ADMPプロセスを介して移行されないすべての変更と手動での移行が必要な変更を確認してください。

この移行アクティビティは基本的に、旧リリースのOracle Management Agent (管理エージェント)がOracle Management Agent 12cにスイッチオーバーされた直後、特に2システム・アップグレード方式の場合に、バックグラウンドで実行されるEnterprise Managerのジョブです。

アップグレード・プロセスの一部として、旧リリースのOracle Management AgentをOracle Management Agent 12cにスイッチオーバーするとき、新しい管理エージェントはEnterprise Manager Cloud Controlとの通信を開始し、アップグレード後のOracle Management Repository(管理リポジトリ)へのデータのアップロードを開始します。

1システム・アップグレード方式の場合、Enterprise Managerシステムの全体がアップグレードされるため、管理エージェントはすべて任意の時点でスイッチオーバーされます。この方式では、旧リリースの管理エージェントがアップグレード後の管理エージェントと共存できないため、一度スイッチオーバーすると、アップグレード後の管理エージェントは1つの管理リポジトリ、つまりアップグレード後のリポジトリにしかデータをアップロードしません。したがって、発生データには対応しないことになります。

これに対して、2システム・アップグレード方式の場合には、管理エージェントへの段階的なスイッチオーバーを選択できます。一方の管理エージェント・セットをスイッチオーバーすると、それらのホストおよびターゲットに関するデータがアップグレード後の管理リポジトリにアップロードされ始めますが、もう一方の管理エージェント・セットはまだスイッチオーバーされていないため、それらのホストおよびターゲットに関するデータは引き続き古い管理リポジトリにアップロードされます。したがって、一部の管理エージェントのみがスイッチオーバーされた場合には、旧リリースの管理エージェントとアップグレード後の管理エージェントが共存することになり、そのような状況では、データは新しい管理リポジトリと同時に古い管理リポジトリにもアップロードされます。ただし、常に1つの管理エージェントのみが1つのホストを表すため、この共存は、同じホストに2つの管理エージェントがあるという意味ではありません。ホストを監視する旧リリースの管理エージェントが、別のホストを監視するアップグレード後の管理エージェントと共存することのみを意味します。

次のフェーズで次のセットの管理エージェントをスイッチオーバーすると、アップグレード後の管理リポジトリにデータをアップロードしますが、スイッチオーバー以前に古い管理リポジトリにアップロードされていたデータも、古い管理リポジトリに残されます。このデータを発生データと呼び、古い管理リポジトリから新しい管理リポジトリへ発生データを移行するプロセスを発生データ移行プロセスと呼びます。

注意:
発生データ移行ジョブではECM履歴データが移行されますが、次の例外があります。

- Enterprise Managerシステムに含まれなくなったターゲットにECM履歴データが関連付けられている場合、そのターゲットのECM履歴データはEnterprise Manager Cloud Controlに移行されません。

- Oracle WebLogic Serverターゲットでは、WebLogic構成データは移行されません。この構成データは、Enterprise Manager Cloud Controlで大幅に変更されています。

- 現在、データ移行プロセスの一部としてサマリー数が計算され、ECMサマリー・リージョンに表示されます。移行されるデータのサマリー数は、過去7日分のみ計算されます。

以前表示されたキー値が表示されなくなったり、キー値として新しい値が表示されても、これは予期される動作です。旧リリースで一部のスナップショットにメターデータの変更があったため、キー値が変更されています。メタデータからメタデータ・キーが削除された場合、移行されたデータベースにデータは存在しますが、それらの値はEnterprise Manager Cloud Controlではキー列として表示されなくなります。既存の列が現時点でキー列としてフラグ付けされた場合、それらの列は新たに収集されたデータに対してのみ、キー列として表示され始めます。キー列またはキー以外の列として追加された新しい列の場合、データは、新たに収集されるデータのみに対して表示されるようになります。

注意:

- デフォルトでADMPジョブが即時実行されないようにする場合は、第10.2項(手順6)を参照してください。

- ADMPプロセス中に、データベース・リンク関連の設定を変更しないでください。変更した場合、ADMPプロセスがそのデータベース・リンクの使用に失敗します。

- ADMPはDBMS_SCHEDULERを使用するため、DBMS_SCHEDULERを使用してジョブを発行するために、すべてのスケジューラ関連の設定が(サーバーで)有効になっていることを確認してください。
確認するには、次の問合せを実行します。

select value from dba_scheduler_global_attribute where attribute_name='SCHEDULER_DISABLED'

この問合せでTRUEが返される場合は、次の問合せを実行します。

exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED','FALSE');

13.8.2 発生データ移行ジョブのステータスの追跡

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。

発生データ移行ジョブのステータスを追跡するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。

2. アップグレード後のタスク・ページで、「発生データ移行」タブをクリックします。
発生データ移行ページに、Enterprise Managerシステムで使用可能なすべてのターゲットに関連する発生データ移行ジョブについての情報が表示されます。デフォルトでは、各ターゲットに対して、発生データ移行ジョブによってECM履歴詳細およびメトリック詳細が移行されます。

3. このタブでは次の処理が可能です。

- すべてのターゲットに対して移行されるデータを制御するには、「発生データ移行の実行対象」リストから次のオプションのいずれかを選択します。

- ECMの履歴の移行: ECM履歴詳細のみを移行します。

- メトリック・データの移行: メトリック詳細のみを移行します。

- すべてのコンポーネント: ECM履歴詳細およびメトリック詳細を移行します。

- 各種のデータを表示するには、ターゲットの表示リストから、次のオプションからいずれかを選択します。

- すべて: Enterprise Managerシステムのすべてのターゲットについて、すべての発生データ移行ジョブを表示します。

- アクティブ: 失敗した、または現在実行中の発生データ移行ジョブを表示します。

- 履歴: 成功した発生データ移行ジョブを表示します。

- 未開始: まだ開始されていない発生データ移行ジョブを表示します。

- 失敗したジョブを再試行するには、ジョブが失敗したターゲットを選択し、「再試行」をクリックします。

- 実行中のジョブを停止するには、ジョブを停止するターゲットを選択して「停止」をクリックします。

13.9 差分レポートの生成と表示

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。

この項の内容は次のとおりです。

- 差分レポートについて

- 差分レポートの生成と表示

13.9.1 差分レポートについて

差分レポートには、2システム・アップグレード方式を使用して旧リリースのEnterprise ManagerをEnterprise Manager Cloud Controlにアップグレードしたときに手動で行われた、構成または設定関係の変更に関する情報が表示されます。

2システム・アップグレード方式では、アップグレード操作が終了するまで、旧リリースのEnterprise ManagerがEnterprise Manager Cloud Controlと共存します。一部の本番環境では、データ量が多いためにアップグレード操作の完了に長く時間がかかる場合があるので、その間に旧リリースの機能領域に変更を加えることができます。

たとえば、追加のソフトウェア・ライブラリ・エンティティ、新規ジョブ、新規デプロイメント・プロシージャなどを追加するとします。

このような変更は、アップグレード後のシステムが旧リリースと同一になるようにEnterprise Manager Cloud Controlに対して実行する必要があります。差分レポートには、Enterprise Manager Cloud Controlでこのような変更を元に戻すことができるように、変更内容のサマリーが示されます。

13.9.2 差分レポートの生成と表示

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。

注意:
差分レポートに表示されるすべての変更は、古いEnterprise Managerシステムから新しいシステムへのアップグレード・プロセスでは移行されないため、それらを手動で移行する必要があります。差分レポートの使用中に、データベース・リンク関連の設定を変更しないでください。

差分レポートを生成および表示するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。

2. アップグレード後のタスク・ページで、「差分レポート」タブをクリックします。
「差分レポート」ページには、様々なコンポーネントに対して過去に生成されたレポートがリストされます。ただし、初めてこのページを表示する際には、レポートは表示されません。

3. このページで、次の処理が可能です。

- 各コンポーネントに対するレポートを生成するには、レポートの再生成をクリックします。

注意:
レポートの再生成をクリックすると、「ステータス」列のステータスが「進行中」に変わります。ステータスが「完了」に変わるまで、ページの手動リフレッシュを続けます。

- 特定のコンポーネントのレポートを表示するには、表からコンポーネント(行)を選択し、レポートの表示をクリックします。

- レポートをリフレッシュして、コンポーネントに関連する最新の変更を表示するには、表からコンポーネント(行)を選択し、レポートの再生成をクリックします。

- 表の列の表示/非表示を切り替えたり、表の列を並べ替えるには、「表示」リストから適切なオプションを選択します。

- 画面から表をデタッチするには、「デタッチ」をクリックします。

13.10 アップグレードしたEnterprise Managerシステム内の非アクティブ・ターゲットの表示

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)の2システム・アップグレードのみに適用可能です。

既存のEnterprise Managerシステムで使用できるターゲットがアップグレード後のEnterprise Managerシステムでアクティブ(監視対象)になるためには、そのターゲットを監視しているOracle Management Agentが、Oracle Management Agent 12cを使用してアップグレード後のEnterprise Managerシステムにスイッチオーバーされている必要があります。

アップグレード後のEnterprise Managerシステムで現在アクティブでないターゲットのリストを表示するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。

2. 「アップグレード後のタスク」ページで「アクティブ化を保留中のターゲット」タブをクリックします。

3. このタブに、非アクティブ・ターゲットのリストが表示されます。
目的のターゲットを検索するには、キーワード、もしくはターゲット名(またはターゲット・タイプ)の一部を、「ターゲット名」列(または「ターゲット・タイプ」列)のすぐ上にある検索テキスト・ボックスに入力します。

または、「検索の絞込み」ペイン内のリンクをクリックして表をフィルタ処理し、目的のターゲットをリスト表示できます。

注意:
このような非アクティブ・ターゲットをアクティブ・ターゲットに変換するには、既存のEnterprise Managerシステムでこれらのターゲットを監視している管理エージェントを、アップグレード後のEnterprise Managerシステムに切り替えます。管理エージェントをスイッチオーバーする方法の詳細は、第11.4項を参照してください。

13.11 発生データ移行プロセスのサインオフ

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)に対する、1システム・アップグレード、2システム・アップグレード、および異なるホスト上の1システム・アップグレードのみに適用可能です。

Oracle Management Agent (管理エージェント)を新規Enterprise Managerシステムにスイッチオーバーした後、前のリリースの管理エージェントをアンインストールできます。管理エージェントを手動でアンインストールするかわりに、管理エージェントごとに発生データ移行プロセス(ADMP)を正規にサインオフし、アップグレード後のコンソールによって管理エージェントを自動的にアンインストールすることができます。

注意:
サインオフ・プロセスでは、すべての資格証明が管理エージェント上でファイル・システム関連の操作を実行するように設定する必要があるため、必要なすべての資格証明が設定されていることを確認してください。

管理エージェントごとにADMPプロセスをサインオフするには、次の手順に従います。

1. Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。

2. アップグレード後のタスク・ページで、サインオフ・タブをクリックします。
デフォルトでは、すべての管理エージェントがサインオフ・ステータスとは関係なく、このページにリストされます。

3. このページで、ADMPプロセスをサインオフしたか、まだサインオフしていない管理エージェントを検索します。
(i) 「検索基準」リストから適切なオプションを選択します。

(ii) 「エージェント」フィールドで、管理エージェントの名前を入力します。特定のサインオフ・ステータスを持つすべての管理エージェントを検索する場合、このフィールドは空白のままでかまいません。また、名前の一部を入力し、ワイルドカードを使用して同じ名前を持つ管理エージェントを検索することもできます。

(iii) 「検索」をクリックします。

4. 正規にサインオフする管理エージェントを選択します。1回ですべての管理エージェントを選択するには、「すべて選択」を有効にします。

注意:
「マスター・エージェント」を選択してサインオフする場合、すべての共有エージェントがサインオフして初めてサインオフしてください。サインオフしていない場合、これらの共有エージェントを選択して、マスター・エージェントとともにサインオフします。

5. 「エージェントのサインオフ」をクリックします。

6. 選択した管理エージェントが実行されていたホストにアクセスするための資格証明を指定します。

7. 「送信」をクリックします。

注意:
サインオフすると、選択された管理エージェントが自動的にアンインストールおよび削除されるため、リカバリできません。そのため、サインオフする前に、管理エージェントを正常にスイッチオーバーし、それらが適切に機能し、ターゲットが新しいEnterprise Managerシステムで正常に監視されていることを確認します。

13.12 移行プロセスと既存のアップグレード・モードのサインオフ

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)に対する、1システム・アップグレード、2システム・アップグレード、および異なるホスト上の1システム・アップグレードのみに適用可能です。

遅延データ移行プロセス(DDMP)、管理エージェントのスイッチオーバー、発生データ移行プロセス(ADMP)、差分レポートで集計される手動データ移行の後に、正規に移行プロセスをサインオフし、アップグレード・モードを終了します。

警告:

サインオフは、アップグレード・プロセスの最後の手順である必要があります。これが終了すると、すべてのアップグレード関連のプロセスおよびリソースがクリーンアップされるため、すべてのADMPジョブまたはDDMPジョブの実行や、差分レポートを生成することはできません。

移行プロセスをサインオフして、正規にアップグレード・モードを終了するには、次の手順に従います:

1. Cloud Controlで、「設定」メニューから、「Cloud Controlの管理」を選択し、「アップグレード後のタスク」をクリックします。

2. アップグレード後のタスク・ページで、サインオフ・タブをクリックします。

3. このページで、「移行のサインオフ」を選択して、「実行」をクリックします。このオプションは、表の下の左下部にあります。

4. (2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式にのみ適用)アップグレード・モードの終了後、第13.13項の説明に従って、古い中央エージェントを削除します。
中央エージェントの削除後、削除した中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。

13.13 古い中央エージェントおよび関連付けられているターゲットの削除

この項では、古い中央エージェントおよびそれに関連付けられているターゲットを削除するための手順について説明します。

- 10.2.0.5/11.1.0.1から12.1.0.5へのアップグレードの後の不要な中央エージェントの削除

- 12.1.0.2/12.1.0.3/12.1.0.4から12.1.0.5へのアップグレード後の不要な中央エージェントの削除

13.13.1 10.2.0.5/11.1.0.1から12.1.0.5へのアップグレードの後の不要な中央エージェントの削除

注意:
この項は、10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)での、2システム・アップグレードおよび異なるホストでの1システム・アップグレードにのみ適用されます。

2システム・アップグレード方式または異なるホストでの1システム・アップグレード方式を使用して、10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をアップグレードした場合、スイッチオーバーされなかった古い中央エージェントを削除します。この中央エージェントは必要ありません。

注意:
アップグレード前コンソールで、中央エージェントは選択肢としてリストされますが、選択してデプロイメントおよび構成ジョブの発行を試みると、選択した中央エージェントが検証され、問題のあるエージェンとしてレポートされます。そのため、それらはデプロイまたは構成できないため、結果としてスイッチオーバーできません。これらの中央エージェントは不要になったため、削除する必要があります。

古い中央エージェントおよび関連付けられているターゲットを削除するには、次の手順に従います。

1. 前提条件として、第13.1項に記載されているとおり、Enterprise Manager Cloud Controlがインストールされているホストを検証します。

2. アップグレードした管理リポジトリ(12.1.0.5のリポジトリ)で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 IN (SELECT emd_url FROM mgmt_targets WHERE target_type = 'host' AND target_name IN (SELECT value FROM mgmt_oms_parameters WHERE name = 'HOST_NAME')) 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

3. 特定した、古い中央エージェントを削除します。

1. 新しいEnterprise Manager Cloud Controlをインストールしたリモート・ホストで、OMSホームから、EM CLIクライアントにログインします。各OMSインストールでEM CLIクライアントをデフォルトで使用できるため、クライアントを個別にインストールする必要がありません。
$<OMS_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>

2. EM CLIを同期します。
$<OMS_HOME>/bin/emcli sync

3. 中央エージェントを削除します。ここで、agentNameは、削除する中央エージェントの名前です。
$<OMS_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

4. (オプション)中央エージェントの削除後、削除した中央エージェントで監視されていたターゲットを引き続き監視する場合は、第13.14項で説明されている手順に従います。

13.13.2 12.1.0.2/12.1.0.3/12.1.0.4から12.1.0.5へのアップグレード後の不要な中央エージェントの削除

注意:
この項は、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)からの1システム・アップグレードにのみ適用されます。

10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)から12cリリース2 (12.1.0.2)、12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)にアップグレードした後、一般的には、第13.13.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)へアップグレードした場合、12.1.0.5 Enterprise Manager Cloud Control Consoleに、古い不要な10gまたは11gの中央エージェントがアクティブ化保留中状態で引き続き表示されます。

そのような不要な中央エージェントがアクティブ化保留中状態で表示される場合、次の手順を実行して削除します。

1. 前提条件として、第13.1項に記載されているとおり、Enterprise Manager Cloud Controlがインストールまたはアップグレードされているホストを検証します。

2. アップグレードした管理リポジトリ(12.1.0.5のリポジトリ)で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

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

1. アップグレードしたOMSホストで、OMSホームから、EM CLIクライアントにログインします。各OMSインストールでEM CLIクライアントをデフォルトで使用できるため、クライアントを個別にインストールする必要がありません。
$<OMS_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>

2. EM CLIを同期します。
$<OMS_HOME>/bin/emcli sync

3. 不要な中央エージェントを削除します。ここで、agentNameは、削除する中央エージェントの名前です。
$<OMS_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

13.14 (オプション)削除された中央エージェントで監視されていたターゲットの監視

注意:
この項は、Enterprise Managerシステムの10gリリース5 (10.2.0.5)および11gリリース1 (11.1.0.1)での、2システム・アップグレードおよび異なるホストでの1システム・アップグレードにのみ適用されます。

2システム・アップグレード方式または異なるホストでの1システム・アップグレード方式を使用して、10gリリース5 (10.2.0.5)または11gリリース1 (11.1.0.1)をアップグレードした場合、第13.13項の説明に従って、不要な古い中央エージェントを削除する必要があります。この中央エージェントの削除後、削除した中央エージェントで監視されていたターゲットを引き続き監視する場合は、次の手順に従います。

1. 古い中央エージェント・ホスト上で、新規OMSからホスト・ターゲットの追加ウィザードを使用して新規のOracle Management Agent 12cをインストールします。

2. そのホストで実行中のすべてのターゲットを検出し、新規OMSで監視できるようにします。

13.15 (オプション)古いOMSホームの削除

Enterprise Managerシステムを完全にアップグレードした後に、古いOMSホームを削除する場合は、次の手順に従います。

- 12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)にアップグレードした場合は、完全リリースまたは追加OMSのいずれの場合も、付録Kで概説されている手順に従います。

- 11gリリース1 (11.1.0.1)から12cリリース4 (12.1.0.4)へアップグレードした場合は、完全リリースまたは追加OMSのいずれの場合も、『Oracle Enterprise Manager Grid Controlアドバンスト・インストレーションおよび構成ガイド』で説明されている手順に従います。

- 10gリリース5 (10.2.0.5)から12cリリース4 (12.1.0.4)にアップグレードした場合は、完全リリースまたは追加OMSのいずれの場合も、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』で説明されている手順に従います。

13.16 CDBおよびPDBで構成されたデータベースへのSYSMANスキーマの移行

CDBおよびPDBで構成されたデータベースにSYSMANスキーマを移行する計画の場合、次の要件を満たしていることを確認します。

1. 非CDBベースのデータベースへのアップグレード。データベース・アップグレード・プロセスの中で、非CDBベースのデータベースのキャラクタ・セットがCDBと同じであることを確認します。その後、アップグレード済の非CDBベースのデータベースからCDB内の新しいPDBへSYSMANスキーマを移行します。

2. 更新済のデータベースの詳細で接続識別子を修正します。これを実行するには、各OMSインスタンスで次の手順を実行します。

1. すべてのOMSインスタンスを停止します。
emctl stop oms-all

2. 最初のOMS上で管理サーバーを起動します。
emctl start oms -admin-only

3. 各OMSインスタンスで、管理リポジトリの接続識別子を修正します。
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)))"

4. すべてのOMSインスタンスを停止して起動します。
emctl stop oms-all

emctl start oms

5. OMSの監視構成および管理リポジトリのターゲットを修正します。
emctl config emrep -conn_desc

13.17 外部ロールの作成オプションの有効化

外部ロールの作成オプションを有効にし、新しいロールの作成中に使用するには、外部認証関連のプロパティをOMSに設定します。これを行うには、次のコマンドを実行します。Enterprise Managerがシングル・サインオン(SSO)で認証されている場合は、LDAPではなく、値SSOがoracle.sysman.emSDK.sec.DirectoryAuthenticationTypeプロパティに設定します。

OMS_HOME/bin>emctl set property -name "oracle.sysman.core.security.auth.is_external_authentication_enabled" -value "true"

OMS_HOME/bin>emctl set property -name "oracle.sysman.emSDK.sec.DirectoryAuthenticationType" -value "LDAP"

詳細は、My Oracle Support Note 1902075.1を参照してください。

第IV部

付録

この部は、次の付録で構成されています。

- 付録A「サイレント・モードでOracle Management ServiceおよびOracle Management Repositoryをアップグレードするためのレスポンス・ファイルの編集」

- 付録B「Enterprise Manager Cloud Controlの通知システムの概要」

- 付録C「Enterprise Manager Cloud Controlのメトリック変更の概要」

- 付録D「2システム・アップグレード方式に対してEnterprise Managerで実行されないジョブの特定」

- 付録E「サーバー・ロード・バランサの構成設定の更新」

- 付録F「EM CLIを使用した優先資格証明の設定」

- 付録H「Oracle Management Agentの検索および追加」

- 付録I「Oracle Management Repositoryのバックアップ後のOracle Management Agentの保護」

- 付録J「Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリ」

- 付録K「古いOMSホームの削除」

- 付録M「Enterprise Managerシステムのアップグレードに関連するログ・ファイルの確認」

A サイレント・モードでOracle Management ServiceおよびOracle Management Repositoryをアップグレードするためのレスポンス・ファイルの編集

表A-1は、サイレント・モードでOMSおよび管理リポジトリをアップグレードする際に、更新が必要な変数およびupgrade.rspレスポンス・ファイルでの更新方法を示しています。

表A-1 サイレント・モードでのOMSアップグレードのためのupgrade.rspファイルのパラメータの編集

パラメータ名

適用可能なアップグレード方式

データ型

値に二重引用符が必要か？

説明

UNIX_GROUP_NAME

通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

String

はい

(中央インベントリが存在しない場合にのみ必須)所属するUNIXグループの名前を入力します。

たとえば、"dba"などです。

INVENTORY_LOCATION

通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

String

はい

(中央インベントリが存在しない場合にのみ必須)中央インベントリへの絶対パスを入力します。

たとえば、"/scratch/oracle/oraInventory"とします。

SECURITY_UPDATES_VIA_MYORACLESUPPORT

通常アップグレードのすべてのアップグレード方式に適用できます。

ソフトウェアのみのアップグレードには適用できません。そのため、このアップグレード方式では、このパラメータはコメント・アウトします。

Boolean

はい

- セキュリティ更新をダウンロードしてインストールする場合は、TRUEを入力します。続いて、次の変数に二重引用符で囲った資格証明を入力します。
MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

- セキュリティ更新をダウンロードしてインストールする場合は、FALSEを入力します。

DECLINE_SECURITY_UPDATES

通常アップグレードのすべてのアップグレード方式に適用できます。

ソフトウェアのみのアップグレードには適用できません。そのため、このアップグレード方式では、このパラメータはコメント・アウトします。

Boolean

いいえ

- セキュリティ更新を拒否する場合は、TRUEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにFALSEを入力する必要があります。

- セキュリティ更新を拒否しない場合は、FALSEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにTRUEを入力する必要があります。

INSTALL_UPDATES_SELECTION

通常アップグレードのすべてのアップグレード方式に適用できます。

ソフトウェアのみのアップグレードには適用できません。そのため、このアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

この変数はデフォルトで、インストール中にソフトウェア更新がインストールされないことを示す"skip"に設定されています。

- My Oracle Supportからソフトウェア更新をインストールする場合、この変数を"download"に設定します。続いて、次の変数に二重引用符で囲った資格証明を入力します。
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- ステージングされた場所からソフトウェア更新をインストールする場合、この変数を"staged"に設定します。続いて、STAGE_LOCATION変数には、ソフトウェア更新が含まれるUpdatesディレクトリまで含めた絶対パスを二重引用符で囲って入力します。
このオプションの場合、前提条件として、ソフトウェア更新がすでにダウンロードされている必要があります。手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

ORACLE_MIDDLEWARE_HOME_LOCATION

通常アップグレードのすべてのアップグレード方式に適用できます。

ソフトウェアのみのアップグレードには適用できません。そのため、このアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

12cリリース5 (12.1.0.5)へのアップグレードはアウトオブプレース・アップグレードであるため、次のいずれかを実行する必要があります。

- インストーラがOracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を自動的にインストールできる新規のミドルウェア・ホームを入力します。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0を事前インストールした新規のミドルウェア・ホームを入力します。ただし、これが、以前のリリースのEnterprise Managerシステムに使用していたミドルウェア・ホームではなく、現在インストールしているEnterprise Managerシステムのための新規のミドルウェア・ホームであることを確認します。

ミドルウェアの場所に書込み権限があることを確認します。

注意: ここで入力するミドルウェア・ホームは、Enterprise Manager Cloud Controlのためにのみ使用するようにしてください。他のOracle Fusion Middleware製品またはコンポーネントは、同じミドルウェア・ホームにインストールしないでください。

ORACLE_INSTANCE_HOME_LOCATION

通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

String

はい

デフォルトでは、gc_instがすべてのOMS関連構成ファイルを格納するためのOMSインスタンス・ベース・ディレクトリとしてみなされ、デフォルトでミドルウェア・ホーム外に作成されます。

- デフォルトの場所およびディレクトリの名前を受け入れる場合は、変数を空白のままにします。

- カスタムの場所およびカスタム・ディレクトリ名を使用する場合は、カスタム・ディレクトリ名までのカスタムの場所の絶対パスを入力します。

重要: NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をこのNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイル・システムの場所にマップします。手順については、第5.1.4項を参照してください。

OLD_BASE_DIR

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式のみに適用できます。

2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式には適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

アップグレードするOMSのベース・ディレクトリを入力します。10gリリース5 (10.2.0.5)からのアップグレード中の場合、これは古いOMSベース・ディレクトリとなります。11gリリース1 (11.1.0.1)からのアップグレード中または12cシリーズ内でのアップグレード中の場合、これはミドルウェア・ホームとなります。

ORACLE_HOSTNAME

通常アップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみに適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。ソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式には適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

デフォルトでは、インストーラを起動しているホストの完全修飾名が想定されます。

- デフォルト値を受け入れる場合は、空白のままにしておきます。

- 異なるホスト名でインストールする場合は、別のホスト名を入力します。

ONE_SYSTEM

通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

Boolean

いいえ

デフォルトでは、この変数はTRUEに設定され、これは1システム・アップグレードを実行していることを示します。

- 1システム・アップグレードを実際に実行している場合は、この値を保持します。

- 2システム・アップグレードを実行している場合は、FALSEに設定します。

AGENT_BASE_DIR

通常アップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみに適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。ソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式には適用できません。追加OMSのアップグレードにも適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。

たとえば、u01/app/software/agentです。この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

OLD_DATABASE_CONNECTION_DESCRIPTION

通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみに適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。追加OMSのアップグレードにも適用できません。そのため、このアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

デフォルトでは、アップグレード前コンソールで入力した旧管理リポジトリの接続文字列が想定されます。ただし、まだ入力していない場合は、次の形式でここに入力できます。

- SIDを使用して接続するには、接続文字列を次の形式で入力します。
"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SID=<sid>)))"

次に例を示します。

"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=emrep)))"

- サービス名を使用して接続するには、接続文字列を次の形式で入力します。
"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))"

次に例を示します。

"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=emrep)))"

この接続文字列は、古い管理リポジトリへの接続、発生データのチェック、アップグレード後の管理リポジトリへの発生データの転送に使用されます。発生データとは、古い管理リポジトリのバックアップ作成時からアップグレードまでに、古い管理リポジトリにアップロードされたデータです。

重要: 両方のデータベースでGLOBAL_NAMESパラメータに設定されている値を確認してください。

- GLOBAL_NAMESパラメータが両方のデータベースでFALSEに設定されている場合は、アップグレードが終了するまでこの値を変更せず、すべての管理エージェントがスイッチオーバーされることを確認します。

- GLOBAL_NAMESパラメータがTRUEに設定されているのがどちらか一方のデータベースのみの場合や、両方のデータベースのGLOBAL_NAMEパラメータの値が同一である場合は、新しいクローン・データベースで設定されたGLOBAL_NAMEパラメータの値を、古いデータベースで設定されたものとは異なる値に設定します。

OLD_DATABASE_SYSMAN_PASSWORD

通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみに適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。追加OMSのアップグレードにも適用できません。そのため、このアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

古い管理リポジトリのSYSMANパスワードを入力します。

このパスワードは、アップグレード前コンソールまたは以前の変数に入力された接続文字列の使用による古い管理リポジトリへの接続や、発生データのチェック、アップグレード後の管理リポジトリへの発生データの転送に使用されます。発生データとは、古い管理リポジトリのバックアップ作成時からアップグレードまでに、古い管理リポジトリにアップロードされたデータです。

WLS_ADMIN_SERVER_USERNAME

10.2.0.5の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式に適用できます。10.2.0.5および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式に適用できます。

12.1.0.4、12.1.0.3、12.1.0.2および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。追加OMSのアップグレードには適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

デフォルトでは、weblogicは、Oracle WebLogicドメインに作成されているデフォルトのユーザー・アカウントに割り当てられた名前です。

- デフォルト名を受け入れる場合は、この変数を空白のままにしておきます。

- カスタム名を使用する場合は、任意の名前を入力します。

WLS_ADMIN_SERVER_PASSWORD

10.2.0.5の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式に適用できます。10.2.0.5および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式に適用できます。

12.1.0.4、12.1.0.3、12.1.0.2および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。追加OMSのアップグレードには適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

WebLogicユーザー・アカウントのパスワードを入力します。

パスワードはスペースを含めず8文字以上とします。先頭は文字とし、数字を1つ以上含めるようにしてください。

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

10.2.0.5の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式に適用できます。10.2.0.5および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式に適用できます。

12.1.0.4、12.1.0.3、12.1.0.2および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。追加OMSのアップグレードには適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

WebLogicユーザー・アカウントのパスワードを確認します。

NODE_MANAGER_PASSWORD

10.2.0.5の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式に適用できます。10.2.0.5および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式に適用できます。

12.1.0.4、12.1.0.3、12.1.0.2および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。追加OMSのアップグレードには適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

デフォルトでは、nodemanagerは、ノード・マネージャに作成されているデフォルトのユーザー・アカウントに割り当てられた名前です。このノード・マネージャのユーザー・アカウントのパスワードを入力します。

パスワードはスペースを含めず8文字以上とします。先頭は文字とし、数字を1つ以上含めるようにしてください。

NODE_MANAGER_CONFIRM_PASSWORD

10.2.0.5の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式に適用できます。10.2.0.5および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式に適用できます。

12.1.0.4、12.1.0.3、12.1.0.2および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。追加OMSのアップグレードには適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

ノード・マネージャのユーザー・アカウントのパスワードを確認します。

WLS_ADMIN_SERVER_PASSWORD

12.1.0.4、12.1.0.3、12.1.0.2および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式に適用できます。12.1.0.4、12.1.0.3、12.1.0.2、11.1.0.1および10.2.0.5の追加OMSのアップグレードに適用できます。

10.2.0.5の通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。10.2.0.5および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式には適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

Enterprise Managerの旧システム用に作成したWebLogicユーザー・アカウントのパスワードを入力します。

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

10.2.0.5の通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

12.1.0.4、12.1.0.2、12.1.0.3および11.1.0.1の通常アップグレードおよびソフトウェアのみのアップグレードのどのアップグレード方式にも適用できません。そのため、これらのアップグレード方式では、このパラメータはコメント・アウトします。

String

はい

アップグレード中に、JVM関連の監視データをすべて格納するためのJVM診断データ表領域という追加の表領域が作成されます。この表領域のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所への絶対パスを指定します。必ずファイル名まで含めたパスを入力してください。

たとえば、"/home/john/oradata/mgmt_deepdive.dbf"とします。

DATABASE_HOSTNAME

通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみに適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。そのため、この方式では、このパラメータはコメント・アウトします。

String

はい

既存のデータベースが常駐するホストの完全修飾名を入力します。

たとえば、"example.com"です。

Oracle RAC Databaseに接続する場合、ノードに仮想ホスト名が含まれていれば、ノードの1つの仮想ホスト名を入力します。

この仮想ホスト名のみで構成された接続文字列を使用してデータベースへの接続が確立され、インストールは正常に終了します。

ただし、クラスタ内の他のノードを使用して接続文字列を更新する場合は、インストールの終了後に、次の手順を実行します。

1. 次のファイルを開きます。
<OMS_Instance_Home>/em/EMGC_OMS#/emgc.properties

2. 変数EM_RESPOS_CONNECTDESCRIPTORに対して他のノードを入力します。

LISTENER_PORT

通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみに適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。そのため、この方式では、このパラメータはコメント・アウトします。

String

はい

既存のデータベースに接続するためのリスナー・ポートを入力します。

たとえば、"1532"です。

SERVICENAME_OR_SID

通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみに適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式には適用できません。そのため、この方式では、このパラメータはコメント・アウトします。

String

はい

既存のデータベースのサービス名またはシステムID (SID)を入力します。

たとえば、"orcl"などです。

SYS_PASSWORD

通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

String

はい

SYSユーザー・アカウントのパスワードを入力します。

SYSMAN_PASSWORD

通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

String

はい

SYSMANユーザー・アカウントのパスワードを入力します。

REPOSITORY_BACKUP_DONE

通常アップグレードおよびソフトウェアのみのアップグレードの1システム・アップグレード方式に適用できます。

通常アップグレードおよびソフトウェアのみのアップグレードの2システム・アップグレード方式および異なるホストでの1システム・アップグレード方式のみには適用できません。

Boolean

いいえ

前提条件として、Enterprise Managerシステムのアップグレードを開始する前に、管理リポジトリをバックアップする必要があります。すでにバックアップを作成済の場合はこのパラメータをTRUEに設定します。まだ作成していない場合は、FALSEに設定します。

PLUGIN_SELECTION

通常アップグレードおよびソフトウェアのみのアップグレードのすべてのアップグレード方式に適用できます。

Stringリスト

はい

(二重引用符で囲ったプラグイン名のカンマ区切りリスト)

デフォルトでは、Oracle Database Management Plug-In、Oracle Fusion Middleware Management Plug-In、Oracle My Oracle Support Management Plug-In、Oracle Exadata Management Plug-In、Oracle Cloud Framework Plug-Inなどの必須プラグインは、Enterprise Managerをアップグレードするときに自動的にインストールされます。

ただし、ソフトウェア・キット(DVDまたはダウンロードされたソフトウェア)で利用できる他のオプションのプラグインをインストールする場合、この変数にそれらのプラグインの名前を入力します。プラグインは、Disk1/pluginsディレクトリにあります。

次に例を示します。

12.1.0.2.0_oracle.sysman.empa_2000_0.oparおよび12.1.0.2.0_oracle.sysman.vt_2000_0.oparをインストールする場合は、プラグインIDを次の方法で入力します。

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

ソフトウェア・キットで利用できないプラグインをインストールする場合、次の手順を実行します。

1. Oracle Technology Network (OTN)で次のEnterprise Managerダウンロード・ページにアクセスします。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. アップグレード・パスのソフトウェア・バイナリおよびプラグインの一覧を示しているセクションを展開します。

3. Download Plug-insセクションから、手動でプラグインをダウンロードし、アクセス可能な場所に保存します。

4. ダウンロードしたプラグインの名前でこの変数(PLUGIN_SELECTION)を更新します。

5. 次のオプションでインストーラを起動して、プラグインをダウンロードした場所を渡します。
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)でサポートされていない、旧リリースのEnterprise Managerにデプロイされたプラグイン・バージョンを保有している場合があります。この場合は、インストーラを-pluginLocation引数で起動する際に、サポートされていないプラグインよりも上位のバージョンのソフトウェアを提供しないようにしてください。その上位バージョンがダウンロード可能な場合でも同様です。これによって、12cリリース5 (12.1.0.5)へのアップグレード中に、サポートされていないバージョンが確実に削除されます。アップグレード後、上位のバージョンをプラグイン・マネージャから直接デプロイできます。

B Enterprise Manager Cloud Controlの通知システムの概要

注意:
この付録は、Enterprise Manager 10g Grid Controlリリース5 (10.2.0.5)またはEnterprise Manager 11g Grid Controlリリース1 (11.1.0.1)からアップグレードする場合のみ、適用されます。

Enterprise Manager Cloud Control以前の通知システムでは、ターゲットの可用性ステータスの変更、メトリック・アラート、およびジョブ実行ステータスの変更が管理者に通知されていました。管理者への通知以外にも、アラートがトリガーされるとオペレーティング・システム・コマンド(スクリプトを含む)やPL/SQLプロシージャを実行するなどのアクションが実行されていました。

この付録では、Enterprise Manager Cloud Controlで大幅に変更された通知システムの内容を説明します。特に、次の内容について説明します。

- イベント、インシデントおよびインシデント・ルールセットについて

- Enterprise Manager 12cでのインシデント・ルールセットへのアクセス

- Enterprise Manager 12cへのアップグレード後にインシデント・ルールセットに移行される通知ルール

- Enterprise Manager 12cへのアップグレード後の通知メソッドおよびアクション

B.1 イベント、インシデントおよびインシデント・ルールセットについて

旧リリースのEnterprise Managerの通知システムは、通知ルール(通知を送信する必要がある状況および必要なアクションを示す、事前定義済のルールまたは条件のセット)を使用して動作していました。

Enterprise Manager Cloud Controlでは、この通知ルールの概念が拡張され、 インシデント・ルールセットと呼ばれる、大規模で新しい概念に組み込まれています。

インシデント・ルールセットを理解するには、イベントおよびインシデントの概念を理解しておく必要があります。

- イベントは、管理する環境での重要な発生事象です。ターゲットの可用性ステータスの変更、メトリック・アラート、およびジョブ実行ステータスの変更などは、Enterprise Managerで検出されるイベント・タイプの例です。ユーザーは、これらのイベントに関する通知を受け取ることで、必要に応じて対応し、根本的な問題を解決できる可能性があります。イベントの概念を形式化することで、このEnterprise Managerの監視機能は、メトリック評価エラーやコンプライアンス標準違反などの、重要になりうるエンタープライズの追加の発生事象にまで拡張されます。

- インシデントは、依存するITサービスの潜在的な中断または実際の中断を指す可能性があり、管理者またはチームが注意を払う必要がある、関連イベントのサブセットです。そのようなイベントに対してインシデントを作成し、さらに管理者に割り当てて完了まで追跡することが可能です。

インシデント・ルールセットは通常、一連のターゲットに対して操作を実行する一連のルールで、適切な担当者に通知し、イベント、インシデントおよび問題に対して適切なアクションを実行するための個別のルールが含まれます。

ルールでは、インシデントを作成できるほか、イベントに対する操作を実行して通知を送信できます。また、特定のインシデントに対して操作を実行できるため、自動割当て、優先度付け、さらには時間ベースの条件によるエスカレートが可能です。

インシデント・ルールセットは、さらにエンタープライズ・ルールセットとプライベート・ルールセットに分類されます。

- エンタープライズ・ルールセットは、1人以上のユーザーへの通知、 拡張通知メソッドを使用した通知の送信、外部チケッティング・システムでのチケット作成、インシデントの作成および更新などの、エンタープライズ・レベルの動作を自動化して実施するために使用されます。これらのルールセットを作成できるのは、「エンタープライズ・ルール・セットの作成」権限を持つ管理者のみです。

- プライベート・ルールセットは、特定の変更に関して管理者が自分に電子メールを送信するのに役立ちます。これらは管理者によって作成され、ルールセットの所有者に電子メールを送信する場合のみ使用できます。

すべてのインシデント・ルールセットは、ルールセットの所有者およびスーパー管理者が編集できます。また、所有者は、他のユーザーをエンタープライズ・ルールセットの共同作成者に指定できます。これにより、ルールセットの共同管理が可能になります。

注意:
イベント、インシデントおよびインシデント・ルールセットの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

B.2 Enterprise Manager 12cでのインシデント・ルールセットへのアクセス

すべてのインシデント・ルールセットを表示するには、Enterprise Manager Cloud Controlで、「設定」メニューから「インシデント」→「インシデント・ルール」を選択します。図B-1にインシデント・ルールセットのページを示します。

図B-1 インシデント・ルールセットの表示

B.3 Enterprise Manager 12cへのアップグレード後にインシデント・ルールセットに移行される通知ルール

アップグレード時には、旧リリースのEnterprise Managerで作成された通知ルールが、最初に通知ルールで定義されたターゲットに作用する、対応するインシデント・ルールセットに自動的に移行されます。

エンタープライズ・ルールセットに移行される通知ルールは、次のとおりです。

- ルールの作成者ではない所有者に電子メールを送信する通知ルール

- 拡張通知メソッドを起動する通知ルール

プライベート・ルールセットに移行される通知ルールは、次のとおりです。

- アクションを伴わない通知ルール

- ルールを作成した所有者に電子メールを送信する通知ルール

古い通知ルールで定義された可能性がある3つの基準(可用性、メトリック、ジョブ)は、適切なイベントに対して操作を実行する3つの個別のルールに、それぞれ移行されます。通知ルール・レベルで定義されたアクションは、これらの各ルールにコピーされます。

1つの例外として、Enterprise Manager Cloud Controlではポリシー違反の概念は取り消されており、ポリシー固有のすべての基準は無視されるため、ポリシーのみに対して操作を実行するルールは移行されません。

旧リリースのEnterprise Managerで作成された通知ルールの所有者は、 Enterprise Manager Cloud Controlでは、対応するインシデント・ルールセットの所有者になります。これらの所有者は、エンタープライズ・ルールセットおよびプライベート・ルールセットを編集できます。また、すべての管理者は、プライベート・ルールセットを作成して自分に電子メールを送信できます。

将来的には、スーパー管理者が「エンタープライズ・ルール・セットの作成」リソース権限を付与して、エンタープライズ・ルールセットを作成できる管理者を指定する必要があります。

注意:
Enterprise Manager Cloud Controlでターゲット・タイプ・モデリングが変更されている場合は、第13.6.8項の説明に従って手動でルールを調整する必要があります。

B.4 Enterprise Manager 12cへのアップグレード後の通知メソッドおよびアクション

旧リリースのEnterprise Managerで定義された通知メソッドおよびアクションは、引き続きEnterprise Manager Cloud Controlでも機能し、これらの元の通知メソッドへの入力は、Enterprise Manager Cloud Controlでは下位互換性があります。そのため、OSコマンドまたはPL/SQLの通知メソッドでメトリック・アラートに対して操作を実行していた場合は、アップグレード後も引き続き同じ入力を受け取ります。ただし、Enterprise Manager Cloud Controlで作成したすべての新しい通知メソッドは、新しいイベントおよびインシデント・モデルに基づいて入力を受け入れます。

注意:
12cより前のバージョンで作成したOSコマンド、およびPL/SQLおよびSNMPトラップ通知メソッドは、「通知メソッド」ページで「イベント互換」が「いいえ」に設定されます。このページアクセスするには、「設定」メニューから、「通知」、「通知メソッド」の順に選択します。

注意:
旧リリースのEnterprise Managerで作成した通知メソッドを、新しいイベント・モデルに対して操作を実行するEnterprise Manager Cloud Control固有の新しい通知メソッドに置き換えることを強くお薦めします。Enterprise Manager Cloud Controlの次のメジャー・リリースでは、古い通知メソッドは機能しなくなります。手順については、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

C Enterprise Manager Cloud Controlのメトリック変更の概要

この付録では、次のターゲットのメトリックに対する変更について説明します。

- Enterprise Manager Cloud ControlでのOracle SOA Infrastructureのメトリックに対する変更

- Enterprise Manager Cloud ControlでのOracle SOAコンポジットのメトリックに対する変更

- Enterprise Manager Cloud ControlでのOracle Service Busのメトリックに対する変更

- Enterprise Manager Cloud ControlでのOracle WebLogic Serverのメトリックに対する変更

- Enterprise Manager Cloud ControlでのJBoss Application Serverのメトリックに対する変更

- Enterprise Manager Cloud ControlでのSiebel Enterpriseのメトリックに対する変更

- Enterprise Manager Cloud ControlでのSiebelサーバーのメトリックに対する変更

C.1 Enterprise Manager Cloud ControlでのOracle SOA Infrastructureのメトリックに対する変更

Oracle SOA Infrastructure関連のメトリックに対する変更は、次のとおりです。

- 古いメトリック「SOAインフラストラクチャ - サービス・エンジン詳細メトリック」は、履歴データを表示するために「すべてのメトリック」ページに表示されます。ただし、このメトリックに対する新たな収集は行われません。

- 現在は、新しいメトリック「SOAインフラストラクチャ - サービス・エンジン詳細メトリック」がターゲット・コンポーネント・タイプ「SOAインフラストラクチャ・エンジン」の下に移動しています。

- また、次のメトリックが導入されました。

- SOAの上位SQL問合せ

- デハイドレーション・ストア表

- アップグレード前コンソールでは、状態レポートの生成時に、新しいメトリックに対するメトリック収集エラーが表示される場合があります。それらのエラーを無視して続行して構いません。ただし、第13章の説明に従って、このターゲットのデータベース資格証明を必ず入力してください。

C.2 Enterprise Manager Cloud ControlでのOracle SOAコンポジットのメトリックに対する変更

Oracle SOAコンポジット関連のメトリックに対する変更は、次のとおりです。

- 古いメトリック「SOAコンポジット - コンポーネント詳細メトリック」および「SOAコンポジット - サービス/参照詳細メトリック」は、履歴データを表示するために「すべてのメトリック」ページに表示されます。ただし、このメトリックに対する新たな収集は行われません。

- 現在は、新しいメトリック「SOAコンポジット - コンポーネント詳細メトリック」がターゲット・コンポーネント・タイプ「SOAコンポジット・コンポーネント」の下に移動しています。

- 新しいメトリック「SOAコンポジット - サービス/参照詳細メトリック」は現在、次のメトリックに分割されています。

- ターゲット・コンポーネント・タイプ「SOAコンポジット・サービス」の下に表示される「SOAコンポジット・サービス・メトリック」 。

- ターゲット・コンポーネント・タイプ「SOAコンポジット参照」の下に表示される「SOAコンポジット参照メトリック」 。

C.3 Enterprise Manager Cloud ControlでのOracle Service Busのメトリックに対する変更

- 古いメトリック「OSBサービス・メトリック」は、履歴データを表示するために「すべてのメトリック」ページに表示されます。ただし、このメトリックに対する新たな収集は行われません。

- 新しいメトリック「OSBサービス・メトリック」は現在、次のメトリックに分割されています。

- ターゲット・コンポーネント・タイプ「OSBプロキシ・サービス」の下に表示される「OSBプロキシ・サービス・メトリック」 。

- ターゲット・コンポーネント・タイプ「OSBビジネス・サービス」の下に表示される「OSBビジネス・サービス・メトリック」 。

C.4 Enterprise Manager Cloud ControlでのOracle WebLogic Serverのメトリックに対する変更

- 次の構成メトリックは、Oracle WebLogic Serverターゲットではなく、J2EEアプリケーション・ターゲットに対して収集されます。

- 一般

- Webサービス

- Webサービス・ポート

- JRF Webサービス

- JRF Webサービス・ポート

- JRF Webサービス操作

- JRF Webサービス・ポリシー参照

- Webモジュール

- EJBモジュール

- 次の構成メトリックは、Oracle WebLogic Serverバージョン7、8および9以上で使用できます。

- 一般

- Webモジュール

- EJBモジュール

- 次の構成メトリックは、Oracle WebLogic Serverバージョン9以上で使用できます。

- Webサービス

- Webサービス・ポート

- 構成メトリック「JDBCデータソース」は、現在、すべてのOracle WebLogic Serverターゲットで使用できます。

- JDBCマルチ・データソースのデータは、これまでメトリック「JDBCデータソース」によって収集されていました。現在は、メトリック「JDBCマルチ・データソース」によって収集されます。

- JDBC接続プールのデータは、これまでメトリック「JDBC接続プール」によって収集されていました。しかし、このメトリックは使用できなくなりました。このメトリックによって収集されたすべてのデータは、現在、メトリック「JDBCデータソース」に移動しています。

これらは構成メトリックであるため、「すべてのメトリック」ページには表示されません。かわりに、J2EEアプリケーションの「最新収集」ページに表示されます。

C.5 Enterprise Manager Cloud ControlでのJBoss Application Serverのメトリックに対する変更

旧リリースのEnterprise Managerでは、JBoss Application Serverの監視用に、エージェント・ホームの次のファイルにリストされている一部のJARファイルが必要でした。

$<AGENT_HOME>/sysman/config/classpath.lst

このファイルへの移入は検出時に実行され、JARファイルの場所を適用してそのクラスパスに追加するために、管理エージェントの再起動が必要でした。

Enterprise Manager Cloud Controlでは、動的クラスローダーによって検出後にターゲット固有のクラスパスがロードされるため、classpath.lstファイルは使用されません。そのため、管理エージェントの再起動は必要ありません。

このターゲット・メタデータには、新しいターゲット・インスタンス・プロパティ「ライブラリ・パス」が追加されています。このプロパティは、ローカルとリモートの監視(ローカルまたはリモートのエージェントによって監視されるターゲット)を区別するために、監視ロジックに必要です。

ローカル監視の場合、このプロパティはnullです。

リモート監視の場合、このプロパティは、検出時に指定した(JBossの検出および監視に必要なJARファイルが含まれている)ライブラリ・パスの場所に設定されます。

アップグレード時には、このエラーを無視してください。

アップグレード後、監視対象ターゲットのステータスは停止中と表示され、メトリックは収集されません。そのため、ターゲットの「監視構成」ページで「ライブラリ・パス」インスタンス・プロパティを設定します。これは、JARファイルの場所に設定してください。

C.6 Enterprise Manager Cloud ControlでのSiebel Enterpriseのメトリックに対する変更

Siebel Enterpriseターゲットに使用できるすべてのメトリックは、Enterprise Manager Cloud Controlの「Siebelゲートウェイ」ターゲットに移動しました。そのため、ECMメトリックを表示するには、「Siebelゲートウェイ」ターゲットにアクセスしてください。

C.7 Enterprise Manager Cloud ControlでのSiebelサーバーのメトリックに対する変更

旧リリースのEnterprise Managerでは、SARMレポート、イベント・ログ、サーバー・プロセス制御およびワークフロー・プロセスに対して、SiebelサーバーおよびSiebelゲートウェイ・サーバーが実行されているホストの優先資格証明の設定のみが必要でした。一方、Enterprise Manager Cloud Controlでは、これらの機能に対して、ホスト資格証明以外の複数の資格証明も設定する必要があります。この項では、それぞれのSiebelターゲット・タイプについて設定する必要がある、様々な資格証明について説明します。

この項の内容は次のとおりです。

- Siebelサーバーの優先資格証明の設定

- Siebelゲートウェイ・サーバーの優先資格証明の設定

- Siebelデータベース・リポジトリの優先資格証明の設定

C.7.1 Siebelサーバーの優先資格証明の設定

Siebelサーバーに対して、次の資格証明を設定します。

ホスト: 優先資格証明

設定方法: Cloud Controlで、「設定」メニューから「セキュリティ」 を選択して「優先資格証明」をクリックします。「優先資格証明」ページで、「ホスト」を選択して「優先資格証明の管理」をクリックします。「ホストの優先資格証明」ページで、Siebelサーバーが実行されるホストのオペレーティング・システム資格証明を設定します。

Siebelサーバーのホスト資格証明

設定方法: Cloud Controlで、「設定」メニューから「セキュリティ」 を選択して「優先資格証明」をクリックします。「優先資格証明」ページで、「Siebelサーバー」を選択して「優先資格証明の管理」をクリックします。「Siebelサーバーの優先資格証明」ページの「ターゲット優先資格証明」セクションで、資格証明セット「ホスト資格証明」を選択し、「設定」をクリックして、Siebelサーバーが実行されるホストのオペレーティング・システム資格証明を設定します。

Siebelサーバーのサーバー・マネージャ資格証明

設定方法: Cloud Controlで、「設定」メニューから「セキュリティ」 を選択して「優先資格証明」をクリックします。「優先資格証明」ページで、「Siebelサーバー」を選択して「優先資格証明の管理」をクリックします。「Siebelサーバーの優先資格証明」ページの「ターゲット優先資格証明」セクションで、資格証明セット「サーバー・マネージャ資格証明」を選択し、「設定」をクリックしてサーバー・マネージャ資格証明を設定します。

C.7.2 Siebelゲートウェイ・サーバーの優先資格証明の設定

Siebelゲートウェイ・サーバーに対して、次の資格証明を設定します。

ホスト: 優先資格証明

設定方法: Cloud Controlで、「設定」メニューから「セキュリティ」 を選択して「優先資格証明」をクリックします。「優先資格証明」ページで、「ホスト」を選択して「優先資格証明の管理」をクリックします。「ホストの優先資格証明」ページで、Siebelゲートウェイ・サーバーが実行されるホストのオペレーティング・システム資格証明を設定します。

Siebelゲートウェイ・サーバーのホスト資格証明

設定方法: Cloud Controlで、「設定」メニューから「セキュリティ」 を選択して「優先資格証明」をクリックします。「優先資格証明」ページで、「Siebelゲートウェイ・サーバー」を選択して「優先資格証明の管理」をクリックします。「Siebelゲートウェイ・サーバーの優先資格証明」ページの「ターゲット優先資格証明」セクションで、資格証明セット「ホスト資格証明」を選択し、「設定」をクリックして、Siebelゲートウェイ・サーバーが実行されるホストのオペレーティング・システム資格証明を設定します。

Siebelゲートウェイ・サーバーのサーバー・マネージャ資格証明

設定方法: Cloud Controlで、「設定」メニューから「セキュリティ」 を選択して「優先資格証明」をクリックします。「優先資格証明」ページで、「Siebelゲートウェイ・サーバー」を選択して「優先資格証明の管理」をクリックします。「Siebelゲートウェイ・サーバーの優先資格証明」ページの「ターゲット優先資格証明」セクションで、資格証明セット「優先資格証明の管理」を選択し、「設定」をクリックしてサーバー・マネージャ資格証明を設定します。

C.7.3 Siebelデータベース・リポジトリの優先資格証明の設定

Siebelデータベース・リポジトリに対して、Siebel DBStoreの資格証明を設定します。

設定方法: Cloud Controlで、「設定」メニューから「セキュリティ」 を選択して「優先資格証明」をクリックします。「優先資格証明」ページで、「Siebelデータベース・リポジトリ」を選択して「優先資格証明の管理」をクリックします。「Siebelデータベース・リポジトリの優先資格証明」ページの「ターゲット優先資格証明」セクションで、資格証明セット「Siebel DBStoreの資格証明」を選択し、「設定」をクリックして資格証明を設定します。

D 2システム・アップグレード方式に対してEnterprise Managerで実行されないジョブの特定

この付録では、既存のEnterprise Managerシステムおよびアップグレード後のEnterprise Managerシステムで実行されないジョブの特定方法を説明します。

- 新しい、アップグレード後のEnterprise Managerシステムで実行されないジョブの特定

- 既存のEnterprise Managerシステムで実行されないジョブの特定

D.1 新しい、アップグレード後のEnterprise Managerシステムで実行されないジョブの特定

次のSQL問合せは、対象のターゲットについて特定のOracle Management Agentが移行されている場合でも、現在、実行を妨げられているジョブの特定に役立ちます。問合せをEnterprise Manager Cloud Controlで実行します。問合せの最後に、移行が必要なOracle Management Agentのリストの提供に使用できる変更のための、オプションの問合せがあります。

アップグレード済または新規のEnterprise Managerシステムで実行しないジョブを識別する必要性の詳細は、第3章「Enterprise Manager Systemのアップグレードに関する予備知識」を参照してください。

SET TRIMSPOOL ON
SET VERIFY   OFF
SET LINESIZE  80
SET PAGESIZE 500

PROMPT ======================
PROMPT Valid on "new" 12.1 EM
PROMPT ======================
PROMPT List jobs that will not be run on either system
PROMPT due to a partially migrated target list
PROMPT ======================

WITH
-- list of migrated targets
migrated_targets AS
(
SELECT   target_guid
FROM     EM_CURRENT_AVAILABILITY
WHERE    current_status     = 4 -- G_STATUS_UNREACHABLE
AND      current_sub_status = 1 -- G_SUB_STATUS_UNMIGRATED
),
-- list of job related migrated targets
migrate_job_targets AS
(
SELECT   job_id, execution_id, target_guid
FROM     MGMT$JOB_EXECUTION_HISTORY JOIN
migrated_targets           USING(target_guid)
WHERE    STATE_CYCLE NOT IN ('FINISHED', 'RUNNING')
),
-- list of jobs against the migrate job targets
effected_jobs AS
(
SELECT  count(1) migrated_target_count, job_id, execution_id
FROM    migrate_job_targets
GROUP BY job_id, execution_id
),
-- list of jobs with some unmigrated targets and some migrate targets
partly_migrated_jobs AS
(
SELECT je.job_id,
je.execution_id,
je.job_name,
je.job_owner,
je.job_type,
je.target_name,
je.target_type,
je.target_guid
FROM   MGMT$JOB_EXECUTION_HISTORY je,
effected_jobs              ej
WHERE  je.job_id       = ej.job_id
AND    je.execution_id = ej.execution_id
AND    target_guid     NOT IN
( SELECT target_guid
FROM   migrate_job_targets
)
)
-- list jobs, targets and agents
SELECT job_name, target_name, target_type
FROM   partly_migrated_jobs
ORDER BY job_name, target_type, target_name;

/*
Could change the last select to
SELECT DISTINCT job_name, job_owner
or
SELECT DISTINCT target_guid

to get the distinct list of jobs or target guids.

or
SELECT DISTINCT emd_url
FROM   partly_migrated_jobs JOIN
MGMT_TARGETS         USING (target_guid)

to get the distinct list of agents
*/

D.2 既存のEnterprise Managerシステムで実行されないジョブの特定

次のSQL問合せは、対象のターゲットについて特定のOracle Management Agentが移行されている場合でも、現在、実行を妨げられているジョブの特定に役立ちます。問合せをEnterprise Manager Cloud Controlで実行します。問合せの最後に、移行が必要なOracle Management Agentのリストの提供に使用できる変更のための、オプションの問合せがあります。

既存のEnterprise Managerシステムで実行しないジョブを識別する必要性の詳細は、第3章「Enterprise Manager Systemのアップグレードに関する予備知識」を参照してください。

SET TRIMSPOOL ON
SET VERIFY   OFF
SET LINESIZE  80
SET PAGESIZE 500

PROMPT ======================
PROMPT Valid on "original" EM
PROMPT ======================
PROMPT List jobs that will not be run on either system
PROMPT due to a partially migrated target list
PROMPT ======================
PROMPT Enter a quoted, comma separated list of agent guids about to be
migrated
PROMPT OR any quoted character to list currently stuck jobs
PROMPT ======================

WITH
-- list of targets the user is about to migrate
migrating_targets AS
(
SELECT   target_name, target_type, target_guid
FROM     MGMT_TARGETS t
WHERE    t.emd_url IN ( SELECT emd_url
FROM   MGMT_TARGETS
WHERE  target_guid IN (&p_agent_guid_list)
AND    target_type = 'oracle_emd') --MGMT_GLOBAL.G_AGENT_TARGET_TYPE )
),
-- list of already migrated targets
migrated_targets AS
(
SELECT   target_name, target_type, target_guid
FROM     PRE_UPGC_TGT_SW
WHERE    STATUS  =  'AVAILABLE'
-- NOTE: neither system will monitor targets <> 'AVAILABLE'
--       How to treat them here?
--       For now, treat them as unmigrated
AND      emd_url IN ( SELECT emd_url
FROM   PRE_UPGC_AGT_STAT_MGMT JOIN
MGMT_TARGETS           USING(target_guid)
WHERE  SWITCH_STATUS='STATUS_SUCCESS'
OR     SWITCH_STATUS='STATUS_IN_PROGRESS')
),
-- list of job related targets (either migrating or already migrated)
migrate_job_targets AS
(
SELECT   -- use DISTINCT to cover target overlap case
DISTINCT job_id, execution_id, target_guid
FROM     MGMT$JOB_EXECUTION_HISTORY JOIN
( SELECT target_guid FROM migrating_targets
UNION ALL
SELECT target_guid FROM migrated_targets
) USING(target_guid)
WHERE    status  NOT IN ('Error',
'Failed',
'Succeeded',
'Skipped',
'Stopped')
),
-- list of jobs against the migrate job targets
effected_jobs AS
(
SELECT  count(1) migrated_target_count, job_id, execution_id
FROM    migrate_job_targets
GROUP BY job_id, execution_id
),
-- list of jobs with some unmigrated targets and some migrate targets
partly_migrated_jobs AS
(
SELECT je.job_id,
je.execution_id,
je.job_name,
je.job_owner,
je.job_type,
je.target_name,
je.target_type,
je.target_guid
FROM   MGMT$JOB_EXECUTION_HISTORY je,
effected_jobs              ej
WHERE  je.job_id       = ej.job_id
AND    je.execution_id = ej.execution_id
AND    target_guid     NOT IN
( SELECT target_guid
FROM   migrate_job_targets
)
)
-- list jobs, targets and agents
SELECT job_name, target_name, target_type
FROM   partly_migrated_jobs
ORDER BY job_name, target_type, target_name;

/*
Could change the last select to
SELECT DISTINCT job_name, job_owner
or
SELECT DISTINCT target_guid

to get the distinct list of jobs or target guids.

or
SELECT DISTINCT emd_url
FROM   partly_migrated_jobs JOIN
MGMT_TARGETS         USING (target_guid)

to get the distinct list of agents
*/

/*
to test already migrated target part, do
update PRE_UPGC_AGT_STAT_MGMT set SWITCH_STATUS ='STATUS_SUCCESS' where target_guid = (select target_guid from mgmt_targets where target_type = 'oracle_emd' and emd_url = (select emd_url from mgmt_targets where target_name = 'db.example.com'));

but DO NOT COMMIT
rollback when done.
*/

E サーバー・ロード・バランサの構成設定の更新

サーバー・ロード・バランサ(SLB)が構成されている場合は、表E-1に記載されている変更をモニターに対して行います。

注意:
関連付ける必要があるHTTPSおよびHTTPポートは、次のコマンドを実行して見つけることができます。
$<OMS_HOME>/bin/emctl status oms -details

表E-1 SLBモニターのSLB固有の構成変更

モニター名

構成

関連付けの対象

タイプ

間隔

タイムアウト

送信文字列

受信文字列

mon_emcc_secure_upload<https_port>

https

60

181

GET /empbs/upload

Http Receiver Servlet active!

ホストA:<https_upload_port>

ホストB:<https_upload_port>

mon_emcc_unsecure_agent_reg<http_port> (オプション)

http

60

181

GET /empbs/genwallet

GenWallet Servlet activated

ホストA:<http_upload_port>

ホストB:<http_upload_port>

mon_emcc_secure_console<https_console_port>

https

5

16

GET /em/consoleStatus.jsp

Enterprise Manager Console is UP

ホストA:<https_upload_port> ホストB:<https_upload_port>

mon_emcc_unsecure_console<http_console_port> (オプション)

http

5

16

GET /em/consoleStatus.jsp

Enterprise Manager Console is UP

ホストA:<http_upload_port>

ホストB:<http_upload_port>

注意:
一部のロード・バランサでは、リテラル\r\nを使用して送信文字列に明示的に追加するには、<CR><LF>文字が必要です。これはベンダー固有です。詳細は、SLBのドキュメントを参照してください。

F EM CLIを使用した優先資格証明の設定

エージェント資格証明を指定する場合、Enterprise Managerシステムに登録された優先資格証明の入力を選択できます。ただし、資格証明がEM CLIを使用して登録されたことを確認します。

- 一度の1つのホストの優先資格証明を登録するには、管理エージェントを実行しているホストで次のコマンドを実行します。
emcli set_credential -target_type=host -target_name="<host_name>" -credential_set=OHCreds -column="OHUsername:<em_job_user>;OHPassword:<em_job_pwd>" -oracle_homes="<agent_home>"

次に例を示します。

emcli set_credential -target_type=host -target_name="example.com" -credential_set=OHCreds -column="OHUsername:myuser;OHPassword:2bornot2b" -oracle_homes="/home/john/programs/EM/agent10g"

- 一度にすべてのホストのデフォルトの優先資格証明を登録するには、管理エージェントを実行しているホストのいずれかで次のコマンドを実行します。ユーザーがすべてのホストの共有ユーザーであることを確認します。
emcli set_credential -target_type=host -credential_set=OHCreds -column="OHUsername:<em_job_user>;OHPassword:<em_job_pwd>" -oracle_homes="<agent_home>"

次に例を示します。

emcli set_credential -target_type=host -credential_set=OHCreds -column="OHUsername:myuser;OHPassword:2bornot2b"

注意:
これらのコマンドを実行するには、ホストにEM CLIクライアントをインストールする必要があります。EM CLIを使用していない場合は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』の説明に従ってインストールしてください。

G 中央エージェントのベース・ディレクトリのOracleミドルウェア・ホーム外への移動

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)および12cリリース2 (12.1.0.2)では、中央エージェントのエージェント・ベース・ディレクトリはデフォルトでOracle Middleware Home (ミドルウェア・ホーム)内に保持されます。中央エージェントとは、デフォルトで最初のOracle Management Service (OMS)とともにデプロイされるOracle Management Agentです。

しかし、Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以上では、エージェント・ベース・ディレクトリをミドルウェア・ホーム内に保持することもできますが、ミドルウェア・ホーム外に保持することを強くお薦めします。各12cのアップグレードはアウトオブプレース・アップグレードであるため、アップグレード後のリリース用に新しいミドルウェア・ホームが作成されます。エージェント・ベース・ディレクトリをミドルウェア・ホーム外に保持すると、旧リリースのミドルウェア・ホームに依存しなくなるため、旧リリースのミドルウェア・ホームが必要ない場合は簡単に削除できます。

したがって、新しい12cリリース3 (12.1.0.3)、12cリリース4 (12.1.0.4)または12cリリース5 (12.1.0.5)のOMSをインストールした場合、作成された中央エージェント・ベース・ディレクトリはデフォルトで(ミドルウェア・ホーム内に保持することを選択しなければ)ミドルウェア・ホーム外にあります。同様に、新しくインストールされた12cリリース3 (12.1.0.3)または12cリリース4 (12.1.0.4)のOMSから12cリリース4 (12.1.0.4)または12cリリース5 (12.1.0.5)にそれぞれアップグレードした場合、アップグレードされたエージェント・ベース・ディレクトリはデフォルトで(旧リリースのミドルウェア・ホーム内に保持することを選択しなければ)ミドルウェア・ホーム外にあります。

しかし、12cリリース1 (12.1.0.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)にアップグレードした場合、中央エージェント・ベース・ディレクトリは(ミドルウェア・ホーム外にまだ移行されていなければ)依然としてミドルウェア・ホーム内にあります。中央エージェント・ベース・ディレクトリは、必要に応じて、ミドルウェア外の場所に移行することもできます。

中央エージェント・ベース・ディレクトリをOracleミドルウェア・ホーム外に移動できるのは1回のみであることに注意してください。中央エージェント・ベース・ディレクトリがミドルウェア・ホームの外に移動されると、以降のアップグレード後にも同じ場所に存在し続けます。

中央エージェントが(12.1.0.1から) 12.1.0.2、または(12.1.0.1または12.1.0.2から) 12.1.0.3へアップグレードされている場合で、中央エージェント・ベース・ディレクトリをOracleミドルウェア・ホーム外に移動しようとする場合は、My Oracle Supportのノート1520010.1で概説されている手順に従ってください。

12.1.0.5または12.1.0.4の中央エージェント(当初はリリース12.1.0.1だったものが12.1.0.2または12.1.0.3にアップグレードされ、再度12.1.0.4または12.1.0.5にそれぞれアップグレードされたもの)のエージェント・ベース・ディレクトリをミドルウェア・ホーム外の場所に移動しようとする場合、次の手順に従います。

重要:

- エージェント・ベース・ディレクトリの移動は、中央エージェントにのみ推奨されます。他の管理エージェントには推奨されません。

- エージェント・ベース・ディレクトリの移動は、Microsoft Windowsで実行されているホストではサポートされていません。

1. 次のスクリプトを実行します。

<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/create_plugin_list.pl -instancehome <AGENT_INSTANCE_HOME>

<AGENT_HOME>は現在の中央エージェントのOracleホームを表し、<AGENT_INSTANCE_HOME>は現在の中央エージェントのインスタンス・ホームを表します。

2. agentimage.propertiesファイルを編集し、SBIN_MODIFIED_VERSIONパラメータを12.1.0.5.0に設定します。
<AGENT_BASE_DIRECTORY>/agentimage.properties

3. 次のスクリプトを実行します。

<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/ConvertToStandalone.pl -instanceHome <AGENT_INSTANCE_HOME> -newAgentBaseDir <AGENT_BASE_DIRECTORY>

<AGENT_HOME>は現在の中央エージェントのOracleホームを、<AGENT_INSTANCE_HOME>は新しい中央エージェントのインスタンス・ホームを、<AGENT_BASE_DIRECTORY>は中央エージェント・ベース・ディレクトリの移行先となる場所をそれぞれ表します。

移行が成功したかどうかを確認するには、Cloud Controlコンソールに切り替えて次の手順を実行します。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。中央エージェントのターゲットを選択します。「管理エージェント」ホームページの「サマリー」セクションで、Oracleホームのパスおよびエージェントの状態ディレクトリのパスを確認します。これらのパスの両方が新しい場所を示していることを確認します。

2. 中央エージェントによって監視されているターゲットのホームページにアクセスします。これらのターゲットのステータスをチェックします。これらが稼働し実行中であることを確認します。

H Oracle Management Agentの検索および追加

エージェントのデプロイおよび構成ページ、デプロイしたエージェントの状態レポートの生成ページおよびエージェントの切替えページのOracle Management Agent(管理エージェント)を検索および追加するには、次の手順を実行します。

- 管理エージェントを検索するには、検索する管理エージェントのプラットフォームおよびバージョンを「プラットフォーム」リストおよび「バージョン」リストからそれぞれ選択します。次に「検索」をクリックします。
また、管理エージェントの名前を把握している場合、「エージェント」に名前を入力して、「検索」をクリックします。Enterprise Manager Grid Controlで管理エージェントの論理グループを作成している場合に、そのグループの管理エージェントをリストするには、「グループ」リストからそのグループの名前を選択して「検索」をクリックします。

- 検索結果は使用している環境で検出される管理エージェントのリストになります。一部の管理エージェントのソフトウェアを今すぐデプロイしない場合、それらの管理エージェントを選択して、「削除」をクリックします。

- 検索結果に探している管理エージェントがリストされていない場合は、「追加」をクリックして、必要な管理エージェントを手動で追加します。

- 追加した管理エージェントが、複数のグループ(Enterprise Managerグループ)、システム(Enterprise Managerシステム)または管理エージェント・クラスタの一部である場合や、複数の共有管理エージェントに関連付けられている場合があります。
この場合、すべてのグループおよびクラスタとともに関連付けられた共有されている管理エージェントを選択および追加するには、関連エージェントの追加をクリックします。

注意:
共有エージェントを追加する場合は、その通信先となるマスター・エージェント、およびこのマスター・エージェントと通信するすべての共有エージェントを必ず追加してください。

I Oracle Management Repositoryのバックアップ後のOracle Management Agentの保護

第11.1項の説明に従ってOracle Management Agent 12c (管理エージェント)をデプロイおよび構成する前に、古い管理エージェントを管理リポジトリのバックアップ前と同じモードのままにする必要があります。つまり、管理リポジトリのバックアップ前に古い管理エージェントを保護(または非保護)モードで実行していた場合、新しい管理エージェントをデプロイおよび構成している間は、古い管理エージェントを以前と同じモードで実行する必要があります。

管理リポジトリのバックアップ後に、管理エージェントを再保護しないでください。再保護した場合、リポジトリに保管されている構成と管理エージェントの実際の構成との不整合により、ヘルス・チェックの実行中にPingテストが失敗する可能性があります。gcagent.logファイルに次のKEY_MISMATCHエラーが書き込まれます。

gcagent.log:2011-09-28 05:41:46,192 [82:B5BF5C12:GC.Executor.1 (Ping OMS)] WARN - Received response status KEY_MISMATCH
gcagent.log:2011-09-28 05:42:16,231 [89:D485F18E:GC.Executor.5 (Ping OMS)] WARN - Received response status KEY_MISMATCH
gcagent.log:2011-09-28 05:42:29,232 [1:3305B9] WARN - Received response status KEY_MISMATCH

なんらかの理由で管理エージェントを再保護する場合は、次の手順を実行します。

1. 古い管理リポジトリに対して次のSQL問合せを実行し、ヘルス・チェックを無効にします。

BEGIN PRE_UPG_UTL.set_param('bypass_hc', '1'); END;
/
commit;

2. 第11.4項の説明に従って、管理エージェントをスイッチオーバーします。

3. 新しい管理エージェントを保護します。
$<AGENT_INSTANCE_DIR>/bin/emctl secure agent

4. 新しい管理エージェントを起動します。
$<AGENT_INSTANCE_DIR>/bin/emctl start agent

5. ヘルス・チェックを有効にします。

BEGIN PRE_UPG_UTL.set_param('bypass_hc', '0'); END;
/
commit;

J Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリ

この付録では、バックアップされたOracle Database 11gリリース1 (11.1.0.7)または10gリリース2 (10.2.0.5)をMicrosoft Windows 32ビットからMicrosoft Windows 64ビットにリカバリする方法を説明します。この付録は次のノートを基準にしています。

How To Change Oracle 11g Wordsize from 32-bit to 64-bit [ID 548978.1]

リポジトリのリカバリの詳細は、「How To Change Oracle 11g Wordsize from 32-bit to 64-bit [ID 548978.1]」を参照してください。

win32のolapデータの場合は、第J.2項の手順(21)の最後でノート[ID 386990.1]に示されている手順に従ってください。

この付録の内容は次のとおりです。

- Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにソース・ホスト(Microsoft Windows 32ビット)で実行する手順

- Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うために宛先ホスト(Microsoft Windows 64ビット)で実行する手順

- Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うために実行する最終手順

J.1 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにソース・ホスト(Microsoft Windows 32ビット)で実行する手順

バックアップされたOracle Database 11gリリース1 (11.1.0.7)または10gリリース2 (10.2.0.5)をMicrosoft Windows 32ビットからMicrosoft Windows 64ビットにリカバリするには、ソース・ホストで次の手順を実行します。

1. データベース・ホーム<DB_HOME>\bin\sqlplus /NOLOGにアクセスします。

2. 次のコマンドを実行します。
SQL> CONNECT / AS SYSDBA :

注意:
Oracle Database 10gリリース2 (10.2.0.5)を使用している場合:

- <DB HOME>/admin/<SID>/udumpにアクセスし、このバックアップをローカル・システムに作成します。

- 次のコマンドを実行します。
<OMS_HOME>\bin>

emctl config emkey -copy_to_repos -sysman_pwd <sysman_password>

次に例を示します。

C:\Oracle\Middleware\oms\BIN>emctl config emkey -copy_to_repos -sysman_pwd Welcome1

3. 次のコマンドを実行します。

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

注意:

- Oracle Database 10gリリース2 (10.2.0.5)を使用している場合、トレース・ファイルは<DB HOME>/admin/<SID>/udumpに生成されます。ファイルを、バックアップした<DB HOME>/admin/<SID>/udumpと比較します。新規のトレース・ファイルがいくつか見つかります。新しいトレース・ファイルの1つに、Microsoft Windows 64ビットの宛先ホストで後に実行する手順が含まれています。

- Oracle Database 11gリリース1 (11.1.0.7)データベースを使用している場合、コマンドによって新規の<sid>_ora_XX.trcファイルが<DB_BASE>\diag\rdbms\<SID>\<SID>\trace\<sid>_ora_xx.trc内に作成されます。次に例を示します。
C:\DB\diag\rdbms\orcl\orcl\traceorcl_ora_3832.trc

このファイルは宛先ホストでの制御ファイルの作成に使用できます。

このファイルは<DB_BASE>\diag\rdbms\<SID>\<SID>\trace\alert_<Sid>.logによって特定できます。

生成されたトレース・ファイルの詳細は、最後の数行に移動してください。

次に、アップグレードのための手順に従ったコンソールに移動します。「リポジトリ・バックアップ詳細の指定」を選択してから、特定したばかりのトレース・ファイルの作成日時を指定します。

4. データベースの全体オフライン・バックアップを実行します(オプション)。

5. 次のコマンドを実行します:
SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

J.2 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うために宛先ホスト(Microsoft Windows 64ビット)で実行する手順

Oracle Database 11gリリース1 (11.1.0.7)または10gリリース2 (10.2.0.5)をMicrosoft Windows 32ビットからMicrosoft Windows 64ビットにリカバリするには、宛先ホストで次の手順を実行します。

1. コンピュータ上で、Oracle Databaseソフトウェアのソフトウェアのみのインストールを実行します。

注意:
インストールするデータベースは、Microsoft Windows 32ビットのソース・ホストのデータベースと同じパスであることを確認します。これによってリカバリの速度が向上します。

2. Microsoft Windows 32ビットのソース・ホストから<DB_Base>\oradataディレクトリ全体をMicrosoft Windows 64ビットの宛先ホストの<DB_Base>\ディレクトリにコピーします。

3. 次のコマンドを実行します。
<DB_HOME>\bin\oradim -new -sid <SID> -maxusers <no. of users> -startmode auto -pfile <DB_HOME>\database\init<SID>.ora

For example:

C:\DB\db\BIN>oradim.exe -new -sid orcl -maxusers 3 -startmode auto -pfile C:\DB\db\database\initorcl.ora

注意:

- Oracle Database 10gリリース2 (10.2.0.5)では、MAXUSERSは動作しない場合があります。

- ここでエラーが表示される場合があります。このエラーは無視しても問題ありません。ただし、インスタンスが作成されることを確認してください。また、init<SID>.oraはここで作成されません。

4. Microsoft Windows 32ビットのソース・ホストから<DB_Base>\adminディレクトリ全体をMicrosoft Windows 64ビットの宛先ホストの<DB_Base>\ディレクトリにコピーします。

5. Microsoft Windows 32ビットのソース・ホストから<DB_Base>\fast_recovery_areaディレクトリ全体をMicrosoft Windows 64ビットの宛先ホストの<DB_Base>\ディレクトリにコピーします。

6. Microsoft Windows 32ビットのソース・ホストから<DBHOME>\database\*.*ファイルをMicrosoft Windows 64ビットの宛先ホストの<DBHOME>\database\ディレクトリにコピーします。

注意:
Oracle Database 10gリリース2 (10.2.0.5)を使用している場合は、win32から<DB_HOME>\dbs\SPFILE<SID>.ORAをwin64の同じ場所にコピーします。このファイルの例は次のとおりです。
C:\DB\db\dbs\SPFILEORCL.ORA

7. 次の環境変数を設定します。

- set ORACLE_HOME=<DB_home>

- set ORACLE_SID=<SID>

8. DB_HOME\rdbms\adminディレクトリにアクセスします。

注意:
この中でsqlplusを見つけられない場合は、<DB_HOME>\binに移動します。

9. 次のコマンドを実行します。
sqlplus /NOLOG

10. /as sysdbaに接続します。

11. 次のコマンドを実行します。
SQL> create pfile from spfile;

注意:

- Oracle Database 10gリリース5 (10.2.0.5)を使用している場合、次のコマンドを実行します。
create pfile='<DB_HOME>\database\init<SID>.ora' from SPFILE='<DB_HOME>\dbs\SPFILE<SID>.ORA';

For example:
create pfile='C:\DB\db\database\initorcl.ora' from SPFILE='C:\DB\db\dbs\SPFILEORCL.ORA';

- Oracle Database 11gリリース1 (11.1.0.7)を使用している場合、次のコマンドを実行します。
create pfile='<DB_HOME>\database\init<SID>.ora' from SPFILE='<DB_HOME>\database\SPFILE<SID>.ORA';

For example:
create pfile='C:\DB\db\database\initorcl.ora' from SPFILE='C:\DB\db\database\SPFILEORCL.ORA';

12. <DB_HOME>\database\init<SID>.oraを、_SYSTEM_TRIG_ENABLED=FALSEを追加して編集します。

13. 次のコマンドを実行します。
SQL> create spfile from pfile

spfileが同じディレクトリ内で作成されます。

14. 次のコマンドを実行します。
SQL> startup nomount

インスタンスがnomountとして起動します。

注意:
次のような失敗メッセージを受け取る場合があります。
ORA-00119: invalid specification for system parameter LOCAL_LISTENER

ORA-00132: syntax error or unresolved network name '<listener name>'

これを修正するには、pfile, spfile;の編集が必要な可能性があります。

pfileおよびspfileを編集するには、'<DB_HOME>\database\init<SID>.ora'を開いて次の行を削除します。

LOCAL_LISTENER

続いて、次のコマンドを実行します。

Sql> create spfile from pfile

15. 第J.1項の手順(3)に示されているファイル<sid>_ora_xx.trcに移動します。このファイルで、手順(15)、手順(16)および手順(17)を実行します。参考のため、これらの手順の例を次に示します。

SQL > CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 'C:\DB\ORADATA\ORCL\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,
GROUP 2 'C:\DB\ORADATA\ORCL\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,
GROUP 3 'C:\DB\ORADATA\ORCL\REDO03.LOG'  SIZE 50M BLOCKSIZE 512
DATAFILE
'C:\DB\ORADATA\ORCL\SYSTEM01.DBF',
'C:\DB\ORADATA\ORCL\SYSAUX01.DBF',
'C:\DB\ORADATA\ORCL\UNDOTBS01.DBF',
'C:\DB\ORADATA\ORCL\USERS01.DBF',
'C:\DB\ORADATA\ORCL\MGMT_ECM_DEPOT1.DBF',
'C:\DB\ORADATA\ORCL\MGMT.DBF',
'C:\DB\ORADATA\ORCL\mgmt_deepdive.dbf'
CHARACTER SET WE8MSWIN1252;

注意:
ここでエラーが表示された場合は、次のコマンドを実行します。
SQL> RECOVER DATABASE;

16. 次のコマンドを実行します。
SQL>ALTER DATABASE OPEN;

17. 次のコマンドを実行します。
SQL>ALTER TABLESPACE TEMP ADD TEMPFILE 'C:\DB\ORADATA\ORCL\TEMP01.DBF' SIZE 20971520 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

このコマンドは一時表領域を更新します。

18. 次のコマンドを実行します。
SQL> SHUTDOWN IMMEDIATE;

19. 次のコマンドを実行します。
SQL> startup upgrade;

20. 次のコマンドを実行します。
SQL> SPOOL mig32-64.log;

21. 次のコマンドを実行します。

SQL> SET ECHO ON;

22. 次のコマンドを実行します。
SQL> @utlirp.sql;

注意:
sqlplusを<DB_HOME>\bin\から使用している場合、次のコマンドを実行します。
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlirp.sql

または

SQL> @ ?/RDBMS/ADMIN?utlirp.sql

23. 次のコマンドを実行します。
SQL> spool off;

24. 次のコマンドを実行します。
SQL> shutdown immediate;

25. 次のコマンドを実行します。
SQL> startup

26. 次のスクリプトを実行します。スクリプトを実行するには、SQL>プロンプトに貼り付けて[Enter]を押します。

begin
update obj$ set status=5 where obj#=(select obj# from obj$,javasnm$
where owner#=0 and type#=29 and short(+)=name and
nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
commit;
declare
cursor C1 is select
'DROP JAVA DATA "' || u.name || '"."' || o.name || '"'
from obj$ o,user$ u where o.type#=56 and u.user#=o.owner#;

ddl_statement varchar2(200);
iterations number;
previous_iterations number;
loop_count number;
my_err     number;
begin
previous_iterations := 10000000;
loop
-- To make sure we eventually stop, pick a max number of iterations
select count(*) into iterations from obj$ where type#=56;
exit when iterations=0 or iterations >= previous_iterations;
previous_iterations := iterations;
loop_count := 0;
open C1;
loop
begin
fetch C1 into ddl_statement;
exit when C1%NOTFOUND or loop_count > iterations;
exception when others then
my_err := sqlcode;
if my_err = -1555 then -- snapshot too old, re-execute fetch query
exit;
else
raise;
end if;
end;
initjvmaux.exec(ddl_statement);
loop_count := loop_count + 1;
end loop;
close C1;
end loop;
end;
commit;
initjvmaux.drp('delete from java$policy$shared$table');
update obj$ set status=1 where obj#=(select obj# from obj$,javasnm$
where owner#=0 and type#=29 and short(+)=name and
nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
commit;
end;
/
create or replace java system;
/

27. 次のコマンドを実行します。
SQL> @utlrp.sql

注意:
sqlplusを<DB_HOME>\bin\から使用している場合、次のコマンドを実行します。
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlrp.sql

または

SQL> @ ?/RDBMS/ADMIN?utlrp.sql

成功した場合、手順(28)に進みます。それ以外でエラーが発生した場合、次を実行します。

1. 次のコマンドを実行します。
SQL> alter system reset "_system_trig_enabled" scope = spfile;

エラーが表示された場合は無視して次の手順に進みます。

2. 次のコマンドを実行してolapを削除します。
SQL> @?/olap/admin/catnoamd.sql

注意:
見つからないファイルに関連するエラーが、個々のファイルについて表示される場合は、次のコマンドを使用します。
SQL>@C:\DB\db\olap\admin\<filename>.sql;

ただし、エラーが発生した場合でも続行できます。

SQL> @?/olap/admin/catnoaps.sql

SQL> @?/olap/admin/olapidrp.plb

3. 次のコマンドを実行してolapを追加します。
SQL> connect SYS as SYSDBA

SQL> spool olap.log

SQL> @?/olap/admin/olap.sql SYSAUX TEMP;

4. 次のコマンドを再入力します。
SQl> @utlrp.sql

注意:
sqlplusを<DB_HOME>\bin\から使用している場合、次のコマンドを実行します。
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlrp.sql

または

SQL> @ ?/RDBMS/ADMIN?utlrp.sql

5. 次の確認作業を行います(オプション)。
- 無効なOLAPSYSオブジェクトについて、次のコマンドを実行します。

SQL> select owner, object_name, object_type, status from dba_objects where status = 'INVALID' and OWNER = 'OLAPSYS' ;

- DBA_REGISTRY内のOLAPコンポーネントについて、次のコマンドを実行します。

SQL> column comp_name format a35

SQL> SELECT comp_name, status, substr(version,1,10) as version from dba_registry;

SQL> Spool Off

28. 手順11でinit<SID>.oraの行_SYSTEM_TRIG_ENABLED=FALSEを削除して、次のコマンドを実行します。

SQL> ALTER SYSTEM RESET "_system_trig_enabled" SCOPE=SPFILE sid='*';

commit;

shutdown immediate;

startup;

J.3 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うために実行する最終手順

プロセスを完了するには、次の作業を行います。

- Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにMicrosoft Windows 32ビット・ホストで実行する最終手順

- Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにMicrosoft Windows 64ビット・ホストで実行する最終手順

- Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリにおける問題のトラブルシューティング

J.3.1 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにMicrosoft Windows 32ビット・ホストで実行する最終手順

Microsoft Windows 32ビットのソース・ホストで、次を実行します。

1. <DB_HOME>\binにアクセスします。
sqlplus "/as sysdba"

SQL>startup;

2. 次のコマンドを実行します。
<OMS_HOME>\bin>emctl config emkey -remove_from_repos

次に例を示します。

C:\Oracle\Middleware\oms\BIN>emctl config emkey -remove_from_repos

3. <DB_HOME>\binにアクセスします。
sqlplus "/as sysdba"

shutdown immediate;

startup;

J.3.2 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリを行うためにMicrosoft Windows 64ビット・ホストで実行する最終手順

Microsoft Windows 64ビットの宛先ホストで、次を実行します。

1. 次のコマンドを実行してリスナーを起動します。
<DB_HOME>\bin\listener.exe start

あるいは、次のコマンドを実行してリスナーを起動することもできます。

<DB_HOME>\bin\netca

この作業はリカバリの前または後に実行できます。

2. リスナーが起動しない場合、次のコマンドを<SID>とともに実行します。
<DB_HOME>\bin\sqlplus "/as sysdba"

SQL>alter system register;

SQL>commit;

SQL>shutdown immediate;

SQL>startup;

J.3.3 Oracle Database 11.1.0.7または10.2.0.5のMicrosoft Windows 32ビット・ホストからMicrosoft Windows 64ビット・ホストへのリカバリにおける問題のトラブルシューティング

まだ問題が発生する場合は、次の手順を実行します。

注意:
これらの手順はデータベース10.2.0.5でテストされています。

1. 次のコマンドを実行します。
<DB_HOME>\BIN\orapwd file=<DB_HOME>\database\PWDorcl.ora password=<enter_password> entries=30 FORCE=Y

2. tnsnames.oraでエンティティの追加が必要になる場合があります。エンティティの例は次のとおりです。

ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = host.example.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl.example.com)
)
)

Where, orcl is the SID.

3. 次のコマンドを実行して、データベースをSQLPlusからバウンスします。
<DB_HOME>\bin\sqlplus "/as sysdba"

SQL>shutdown immediate;

SQL>startup;

4. 次のコマンドを実行してリスナーをバウンスします。
<DB_HOME>\bin\listener.exe stop

<DB_HOME>\bin\listener.exe start

<DB_HOME>\bin\listener.exe status (to be repeated till you see the service name)

K 古いOMSホームの削除

この章では、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)から12cリリース5 (12.1.0.5)にアップグレードした後に、古いOMSホームを削除する方法について説明します。この章の具体的な内容は次のとおりです。

- グラフィック・モードでの古いOMSホームの削除

- サイレント・モードでの古いOMSホームの削除

K.1 グラフィック・モードでの古いOMSホームの削除

グラフィック・モードで古いOMSホームを削除するには、次の手順を実行します。

重要:

1. この手順に示されている順序でコンポーネントを削除してください。そうでない場合、インストール・ウィザードにエラーが表示されます。

2. 古いミドルウェア・ホームにある管理エージェントは削除しないでください。
この管理エージェント(つまり中央エージェント)のエージェント・ベース・ディレクトリの古いOracleミドルウェア・ホーム外への移動については、My Oracle Supportノート1520010.1を参照してください。

1. 次のコマンドを実行して、OMSホームからインストーラを起動します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall [-removeAllFiles -invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- ソフトウェアをダウンロードしたディレクトリからインストーラを起動することもできます。たとえば、<software_location>/となります。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- runInstaller -helpを実行すると、オプション-nowarningonremovefilesがリストに表示されます。このオプションは現在サポートされていないため、使用しても無効になります。

注意:
runInstallerまたはsetup.exeを起動する際、Enterprise Manager Cloud Controlインストール・ウィザードが表示されない場合は、/stage(Enterprise ManagerソフトウェアのDisk1ディレクトリ内のサブディレクトリ)への、読取りおよび書込みアクセス権がない可能性があります。
インストール・ウィザードは、クラスパス変数をOPatch用に../stage/Components/として処理します。TEMP変数が/tmpに設定されているとき、インストール・ウィザードはopatchのJARファイルを/tmp/../stageディレクトリ(/stageと同様)で検索しようとします。しかし、ユーザーに/stageへの読取りおよび書込み権限がないと、インストール・ウィザードはハングします。このような場合、/stageディレクトリへの読取りおよび書込みアクセス権があるかどうかを確認します。アクセス権がない場合は、TEMP変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

2. 「インベントリ」画面でOMS関連のプラグイン・ホームのみを選択し、「削除」をクリックします。

注意:
OMS関連プラグインのホームのみを選択し、他のエージェント関連プラグインは選択しないでください。

3. 「インベントリ」画面でJava Development Kit (JDK)ホームを選択し、「削除」をクリックします。

注意:
Enterprise Managerシステムのインストール時にインストール・ウィザードによってJDKがインストールされた場合のみ、JDKを削除します。そのようなリポジトリがない場合は、この手順をスキップできます。

注意:
JDKの削除後、インストーラを終了しないでください。間違ってインストーラを終了した場合は、次の手順を実行してください。

1. JDK 1.6.0.43.0を手動でダウンロードし、OMSホストにインストールします。このサポートされているバージョンをすでに所有している場合、それを再利用できます。

2. インストーラを再度起動し、JDKが存在する場所への絶対パスを渡します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -jreLoc <JDK_HOME> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

4. 「インベントリ」画面でOracle WebTierホームを選択し、「削除」をクリックします。

5. 「インベントリ」画面で、次のものを選択して「削除」をクリックします。

- OMSホーム

- Oracle共通ディレクトリ

注意:
BI Publisherが以前のバージョンのEnterprise Managerにインストールされている場合は、BI Publisher Oracleホーム(Oracle_BI1)も選択します。

6. 「インベントリ」画面で「閉じる」をクリックして、ウィザードを終了します。

K.2 サイレント・モードでの古いOMSホームの削除

サイレント・モードで古いOMSホームを削除するには、次の手順を実行します。

重要:

1. この手順に示されている順序でコンポーネントを削除してください。そうでない場合、インストール・ウィザードにエラーが表示されます。

2. 古いミドルウェア・ホームにある管理エージェントは削除しないでください。
この管理エージェント(つまり中央エージェント)のエージェント・ベース・ディレクトリの古いOracleミドルウェア・ホーム外への移動については、My Oracle Supportノート1520010.1を参照してください。

1. プラグイン・ホームを削除します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_oms_plug-in_home}" ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles -invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- ソフトウェアをダウンロードしたディレクトリからインストーラを起動することもできます。たとえば、<software_location>/となります。
ここからインストーラを起動した場合、-removeAllFilesを渡さないでください。

- runInstaller -helpを実行すると、オプション-nowarningonremovefilesがリストに表示されます。このオプションは現在サポートされていないため、使用しても無効になります。

- 複数のプラグインを削除する場合は、プラグイン・ホームをカンマで区切って入力してください。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

次に例を示します。

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/plugins/oracle.sysman.ssa.oms.plugin_12.1.0.2.0}" ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

2. Java Development Kit (JDK)ホームを削除します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_jdk_home}" ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/jdk16}" ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

注意:
Enterprise Managerシステムのインストール時にインストール・ウィザードによってJDKがインストールされた場合のみ、JDKを削除します。そのようなリポジトリがない場合は、この手順をスキップできます。

3. JDK 1.6.0.43.0を手動でダウンロードし、OMSホストにインストールします。このサポートされているバージョンをすでに所有している場合、それを再利用できます。
インストーラにはJDKへの依存性があるため、JDKを再インストールする必要があります。新しいJDKは、以前あった場所と必ずしも同じでなくても、OMSホスト上の任意の場所にインストールできます。ただし、インストーラを起動してJDKをインストールした場所を示す際に、-jreLocパラメータ(次の手順で説明します)を必ず渡してください。

4. Oracle WebTierホームを削除します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_web_tier}" -jreLoc <JDK_HOME> ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/Oracle_WT}" -jreLoc </home/oracle/jdk> ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

5. OMSおよびOracle共通ディレクトリを削除します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_oms_oracle_home_and_common_directory_and_bip_home_to_be_deinstalled}" -jreLoc <JDK_HOME> ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:
引数REMOVE_HOMESでは、カンマで区切られた複数のパスを指定できます。

たとえばこのシナリオでは、BI Publisherがインストールされていて、これを今から削除しようとしています。

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/oms,/home/oracle/middleware/oracle_common,/home/oracle/middleware/Oracle_BI1}" -jreLoc </home/oracle/jdk> ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

L データベース・リンク・エラーを回避または解決するためのデータベース・ドメイン名の修正

データベース・ドメイン名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字が含まれている場合、スイッチオーバー操作のRun Presync手順が失敗し、次のエラーがemoms.trcトレース・ファイルに表示される可能性があります。たとえば、データベース・ドメイン名にハイフン(-)が含まれている場合に次の問題が発生します。

ORA-20000: Found exception Error Message :ORA-02083: database name has illegal character '-' Error Number ;-2083

この付録では、まだアップグレードを開始していない場合のこのエラーの回避方法、およびアップグレードを開始している場合や「アップグレードされたOracle Management Repositoryリンクの作成」ページにエラーが表示される場合のこのエラーを回避するための方法について説明します。

この項の具体的な内容は次のとおりです。

- 「アップグレード・プロセス開始前のデータベース・リンク・エラーの回避」

- 「アップグレード・プロセス進行中に発生するデータベース・リンク・エラーの解決」

L.1 アップグレード・プロセス開始前のデータベース・リンク・エラーの回避

データベース・リンクの問題を回避するには、前提条件として、次の手順に従います。

1. 新旧両方の管理リポジトリで、SYSユーザーとして次のSQLコマンドを実行します。

1. ドメイン名を確認します。
show parameters db_domain;

2. ドメイン名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、ドメイン名を変更します。
alter system set db_domain='<domain_name_with_illegal_char_replaced_with_legal_char>' scope=spfile sid='*';

3. サービス名を確認します。
show parameters service_names;

4. サービス名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、サービス名を変更します。
alter system set service_names='service_name_with_illegal_char_replaced_with_legal_char' scope=both sid='*';

5. グローバル名を確認します。
select * from global_name;

6. グローバル名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、グローバル名を変更します。
alter database rename GLOBAL_NAME to "global_name_with_illegal_char_replaced_with_legal_char";

2. 次のファイルのSERVICE_NAME値を変更または修正したサービス名で更新します。
$<DB_HOME>/network/admin/listener.ora

$<DB_HOME>/network/admin/tnsnames.ora

3. 新旧両方のOMSで、次の手順を実行します。

1. OMSの接続識別子を確認します。
$<OMS_HOME>/bin/emctl config oms -list_repos_details

2. 接続識別子のサービス名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、接続識別子を変更します。
$<OMS_HOME>/bin/emctl config oms -store_repos_details -repos_conndesc '(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = example.com)(PORT = 1521)))(CONNECT_DATA = (SERVICE_NAME = service_name_with_illegal_char_replaced_with_legal_char)))' -repos_user sysman

3. OMSを再起動します。
$<OMS_HOME>/bin/emctl stop oms -all

$<OMS_HOME>/bin/emctl start oms

4. データベースを再起動します。
SQL>shutdown immediate;

SQL>start the database

L.2 アップグレード・プロセス進行中に発生するデータベース・リンク・エラーの解決

アップグレード前コンソールの「アップグレード済リポジトリへのリンクの作成」ページにエラーが表示される場合にデータベース・リンクの問題を解決するには、次のコマンドをSYSユーザーとして実行します。

1. データベース・リンクを削除します。

- データベース・リンクが古いリポジトリにすでに作成されている場合は、次のコマンドを実行します。
drop public database link PREUPGTO_NG_LINK;

- データベース・リンクが新しいリポジトリにすでに作成されている場合は、次のコマンドを実行します。
drop public database link PREUPG_EMREPO_LINK;

2. 新旧両方の管理リポジトリで、SYSユーザーとして次のSQLコマンドを実行します。

1. ドメイン名を確認します。
show parameters db_domain;

2. ドメイン名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、ドメイン名を変更します。
alter system set db_domain='domain_name_with_illegal_char_replaced_with_legal_char' scope=spfile sid='*';

3. サービス名を確認します。
show parameters service_names;

4. サービス名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、サービス名を変更します。
alter system set service_names='service_name_with_illegal_char_replaced_with_legal_char' scope=both sid='*';

5. グローバル名を確認します。
select * from global_name;

6. グローバル名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、グローバル名を変更します。
alter database rename GLOBAL_NAME to "global_name_with_illegal_char_replaced_with_legal_char";

3. 次のファイルのSERVICE_NAME値を変更または修正したサービス名で更新します。
$<DB_HOME>/network/admin/listener.ora

$<DB_HOME>/network/admin/tnsnames.ora

4. 新旧両方のOMSで、次の手順を実行します。

1. OMSの接続識別子を確認します。
11gおよび12cのOMSでは、次のコマンドを実行します。

$<OMS_HOME>/bin/emctl config oms -list_repos_details

10gのOMSでは、emoms.propertiesファイルを開きます。

2. 接続識別子のサービス名にA-Z (文字)、0-9 (数値)、_ (アンダースコア)、# (ハッシュ)、$ (ドル)、. (ピリオド)または@ (単価)以外の文字(たとえば、-(ハイフン)など)が含まれている場合は、接続識別子を変更します。
11gおよび12cのOMSでは、次のコマンドを実行します。

$<OMS_HOME>/bin/emctl config oms -store_repos_details -repos_conndesc '(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = example.com)(PORT = 1521)))(CONNECT_DATA = (SERVICE_NAME = service_name_with_illegal_char_replaced_with_legal_char)))' -repos_user sysman

10gのOMSでは、emoms.propertiesファイルの接続識別子を直接編集して、ファイルを保存します。

3. OMSを再起動します。
$<OMS_HOME>/bin/emctl stop oms -all

$<OMS_HOME>/bin/emctl start oms

5. データベースを再起動します。
SQL>shutdown immediate;

SQL>start the database

6. アップグレード前コンソールの「アップグレード済リポジトリへのリンクの作成」ページで、データベース・リンクを作成または再作成します。詳細は、13.2項を参照してください。

7. 新しい管理リポジトリにデータベース・リンクを作成します。

1. グローバル名のパラメータを確認します。
show parameters global_names;

global_namesがFALSEに設定されている場合は、データベース・リンク名PREUPG_EMREPO_LINKを使用します。TRUEに設定されている場合は、データベース・リンク名<value_of_"select * from global_name"_from_the_old_Management_Repository>を使用します。

データベース・リンクを使用するために、次のコマンドを実行します。

CREATE PUBLIC DATABASE LINK <db_link_name> CONNECT TO SYSMAN IDENTIFIED BY welcome1 using '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=orcl)))';

2. 新しい管理リポジトリ内のデータベース・リンク名を更新します。
UPDATE sysman.MGMT_UPGRADEUTIL_PROPS SET property_value='<db_link_name>' WHERE property_name = 'PREUPG_EMREPO_DBLINK_NAME'

8. 新旧両方の管理リポジトリのデータベース・リンクを確認します。

- 古い管理リポジトリで次のSQLコマンドを実行します。
DECLARE

l_count number;

begin

select count(*) into l_count from mgmt_targets@PREUPGTO_NG_LINK;

end;

/

- 新しい管理リポジトリで次のSQLコマンドを実行します。
DECLARE

l_count number;

begin

select count(*) into l_count from mgmt_targets@<db_link_name>;

end;

/

M Enterprise Managerシステムのアップグレードに関連するログ・ファイルの確認

表M-1に、様々なアップグレード操作で確認するログ・ファイルを示します。

表M-1 様々なアップグレード操作で確認するログ・ファイル

アップグレード操作

コンソール名

参照先のログ・ファイル

エージェントのヘルス・チェックおよび起動

アップグレード前コンソール [1]

12c管理エージェントの次の場所にあるgcagent.logファイルを確認します。

$<AGENT_INSTANCE_DIR>/sysman/log/gcagent.log

エージェントのデプロイメントおよび構成

アップグレード前コンソール

12c管理エージェントの次の場所にあるログ・ファイルを確認します。

- $<AGENT_BASE_DIR>/core/<version>/cfgtoollogs/agentDeploy/

- $<AGENT_BASE_DIR>/core/<version>/cfgtoollogs/cfgfw/

ジョブ

(エージェントのデプロイメントおよび構成ジョブ、ヘルス・チェック・ジョブ、スイッチオーバー・ジョブ)

アップグレード前コンソール

ジョブ出力ログを確認します。次の手順を実行します。

1. 「ジョブ」ページに移動します。

2. ジョブ名を検索します。

3. ジョブ名をクリックしてから各手順名をクリックして、各手順の出力ログを表示します。

プラグイン・デプロイメント(エージェント・アップグレード・コンソールを使用して管理エージェントをアップグレードする際)

エージェント・アップグレード・コンソール

プラグイン・デプロイメントの問題をトラブルシュートするには、12c管理エージェントの次の場所にあるログ・ファイルを確認します。

$<AGENT_INSTANCE_DIR>/install/logs/

Pingテスト

アップグレード前コンソール

12c管理エージェントの次の場所にあるgcagent.logファイルを確認します。

$<AGENT_INSTANCE_DIR>/sysman/log/gcagent.log

脚注 1 アップグレード前コンソールとは、実質的には旧リリースのEnterprise ManagerからアクセスするEnterprise Manager 12cアップグレード・コンソールです。

索引
A  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  V  W

数字

1システムのアップグレード方式

割り当てられるデフォルト・ポート, 3.6

グラフィック・モード, 12.1.1

サイレント・モード, 12.2.1

ソフトウェアのみをインストール

グラフィック・モード, 12.3.1, 12.3.2, 12.4.1, 12.4.2

概要, 2.2.1 プロセス, 9.1, 9.3 Oracleソフトウェア・ライブラリの使用, 3.8 異なるホストでの1システムのアップグレード方式

グラフィック・モード, 12.5

概要, 2.2.1

Oracleソフトウェア・ライブラリの使用, 3.8

2システムのアップグレード方式

割り当てられるデフォルト・ポート, 3.6

グラフィック・モード, 12.1.2

サイレント・モード, 12.2.2

プロセス, 9.2

A

発生データ, 13.8.1

発生データ移行, 13.8.1

発生データ移行ジョブ

ECM履歴データの移行, 13.8.1

概要, 13.8.1

追跡, 13.8.2

アラート, 3.11.1, 3.11.2

クローズド・アラート, 3.11.2.1

インシデントおよびイベントの作成, 3.11.2.3

移行メソッド, 3.11.2.1 オープン・アラート

インシデントおよびイベントの作成, 3.11.2.2

移行, 3.11.2.1

allroot.shスクリプト, 5.1, 12.1.1 アプリケーションの依存性とパフォーマンス, 9.1, 9.2, 9.3, 9.3

C

中央インベントリ, 10.6.1

コマンド

Enterprise Managerのコマンド

GUIモードでの削除, K.1, K.1

サイレント・モードでの削除, K.2

コンフィギュレーション・アシスタント, 2.1.3, 2.2.4.1, 2.2.4.2, 2.2.4.3 コネクタ, 3.9 重要なデータの移行, 13.7.1

D

データ・フォーマットの移行, 13.7.1

データベース

データベースのバックアップ, 9.2

DBCAのバックアップ, 9.2

リポジトリ・バックアップの詳細の指定, 10.7

データベースのアップグレード, 3.4 遅延データ移行ジョブ

遅延データ移行, 13.7.1

概要, 13.7.1

追跡, 13.7.2

操作をデプロイ, 2.2.4.1 デプロイメント・プロシージャ, 2.2.2, 2.2.2, 2.2.2, 9.1, 9.2, 9.3 宛先ホスト, J 差分レポート

生成と表示, 13.9.2

概要, 13.9.1

停止時間

ダウンタイムをゼロまたは最小限, 2.2.2

程度, 2.2.2

ある程度の停止時間, 2.2.2

E

EM CLI, F

EM CLIクライアント, 3.11.6

EM_UPLOAD_HTTP_PORTパラメータ, 10.2

EM_UPLOAD_HTTPS_PORTパラメータ, 10.2

emgc.propertiesファイル, 10.2

emkey, 4.1, 9.2

コピー

OMSのアップグレード前, 9.1, 9.3

OMSのアップグレード前, 9.2

エラーの処理, 9.1, 9.2 リポジトリからのemkeyの削除, 9.2 emkeyがコピーされているかどうかの検証, 9.3 emkeyがコピーされているかどうかの検証, 9.1, 9.2 Enterprise Manager Cloud Control

アップグレード前コンソールへのアクセス, 2.2.3.1

削除

サイレント・モード, K.2

インストール・ウィザード, 2.1.2.1, 2.2.3.2 アップグレード後コンソール, 2.2.3.3 アップグレード後の手順, 13.6 アップグレード前コンソール, 2.2.3.1 アップグレードでサポートされているプラットフォーム, 3.3 サポートされているアップグレード・パス, 3.2 アップグレード方式, 2.2.1 アップグレード範囲, 3.4 アップグレード・ユーティリティ, 2.2.3 複数OMS環境のアップグレード, 12.6 Enterprise Manager Cloud Controlインストール・ウィザード, 2.1.2.1, 2.2.3.2 エンタープライズ・ルールセット, B.1 イベント, 3.11.1, B.1

概要, B.1

F

失敗したジョブ, 3.11.3

ファイアウォールの設定, 2.2.2, 2.2.2, 2.2.2, 3.6

G

gc_instディレクトリ, 2.2.4.1

GCDomain, 2.2.4.1

H

状態レポート, 11.2

生成, 11.2

サインオフ, 11.3

検証, 11.3

I

アップグレードのホストの識別, 10.2

非アクティブ・ターゲット, 13.10

インシデント・ルール・セット

ルール・セットの削除, 13.6.9

インシデント・ルール, 13.6.8

削除, 13.6.8.4

概要, 13.6.8.1

移動したメトリックの更新, 13.6.8.2

名前が変更されたメトリックの更新, 13.6.8.3

インシデント・ルールセット, 3.11.1, 13.6.8, B.1

アクセス, B.2

分類, B.1

通知ルールの移行, B.3

インシデント・ルールセット, B.1 インシデント, B.1

概要, B.1

インシデントおよびイベント, 3.11.2.2 インストール・ベース・ディレクトリ, 11.1.2, 11.1.2 inventory.xmlファイル, 10.6.1, 10.6.2, 10.6.2

J

Java Development Kit, 2.2.4.1

デフォルトのバージョン, 2.2.4.2, 2.2.4.3

インストールされているデフォルトのバージョン, 3.4

手動ダウンロード, 3.4

JDK, 2.2.4.1 ジョブ

1システム・アップグレード方式, 3.11.3

2システム・アップグレード方式, 3.11.3

中止されるジョブ, 3.11.3

多数のターゲットに対するジョブ, 3.11.3

管理, 3.11.3

繰返しジョブ, 2.2.2, 2.2.2, 2.2.2, 3.11.3, 3.11.3

実行, 2.2.2, 2.2.2, 2.2.2

スケジュール済のジョブ, 2.2.2, 2.2.2, 2.2.2, 3.11.3

一時停止されているジョブ, 3.11.3

JROCKIT, 3.4 JVM診断, 9.1, 9.2, 9.3, 9.3

L

Linuxパッチ適用, 13.6.11

ロック済アカウント

ロック済アカウントの使用, 11.1.2

ロック済アカウント

Power Broker, 11.1.2

SUDO, 11.1.2

M

管理対象サーバー, 2.2.4.1

管理リポジトリ

アップグレードしたリポジトリへのリンクの作成, 13.2

ソフトウェアの管理, 10.4 マスター・エージェント, 11.1.2 メトリック変更, C メトリック収集エラー, 11.2, 13.6.10 メトリック

変更, 13.6.8.1

収集メトリック, 3.11.5

廃止, 13.6.8.1

移動, 13.6.8.1

名前の変更, 13.6.8.1

名前が変更されたメトリック, 3.11.5

保持, 13.6.8.1

移行アクティビティ, 13.7.1, 13.8.1 最低限の監視の欠如, 2 欠落しているエージェントまたはプラグイン・ソフトウェア, 10.6.4 複数OMS環境, 10.2, 12.6

N

ゼロに近い停止時間, 2

ノード・マネージャ, 2.2.4.1

サポートされていない, 10.6.3, 10.6.4

通知, 3.11.1

通知メソッド, B.4

通知ルール, 3.11.1, 13.6.8, B.1

通知, B

O

不要なターゲット, 13.6.6

OCMスケジューラ, 13.6.5

操作名, 11.1.2

Oracle JRF, 2.2.4.3

Oracle Management Agent

エージェントのアップグレード性, 10.4

環境の分析, 10.6

エージェントのアップグレード可能性ステータスの確認, 10.6.3

構成, 11.1

デプロイ, 11.1

状態レポートの生成, 11.2

手動でのダウンロード, 10.4

問題のあるエージェント, 10.6.5

再構成, 11.1.2

ターゲットのアップグレード性, 10.4

アップグレード性, 10.6.3

アップグレード・ステータス, 13.5

アップグレード

プラグインのインストール, 3.7.2.1

インベントリが無効, 10.6.2 インベントリが有効, 10.6.1 Oracle Management Repository

アップグレード

グラフィック・モード, 12.1

Oracle Management Service

ソフトウェアのみをインストール

グラフィック・モード, 12.3

サイレント・モード, 12.4

OMSインスタンスの停止, 5.1 OMSの停止, 5.3.3 アップグレード

グラフィック・モード, 12.1

サイレント・モード, 12.2

プラグインのインストール, 3.7.2.2

Oracleソフトウェア・ライブラリ, 3.8

ソフトウェア・ライブラリのバックアップ, 9.2

アクセス可能なNFSマウントされたドライブ, 9.3

ソフトウェア・ライブラリを再構成, 9.2

ライブラリの使用

1システム・アップグレード方式, 3.8

異なるホストの1システム・アップグレード方式, 3.8

2システム・アップグレード方式, 3.8

Oracleソフトウェア・ライブラリの「場所の再構成」ページ, 13.4 Oracle Web Tier, 2.2.4.1, 2.2.4.3 Oracle WebLogicドメイン, 2.2.4.1 Oracle WebLogic Server, 2.2.4.2, 2.2.4.3

インストールされているデフォルトのバージョン, 2.2.4.1, 3.4

手動でのインストール, 3.4, 3.4, 3.4

標準インストール, 3.4

oracle_commonディレクトリ, 2.2.4.1, 2.2.4.2, 2.2.4.3 ORACLE_COMMONプロパティ, 3.4 Oracle_WTディレクトリ, 2.2.4.1, 2.2.4.2, 2.2.4.3 oraInst.locファイル, 10.6.2 アウトオブプレース・アップグレード, 3.4

P

円グラフ, 10.4

ping, 11.3

Pingテスト, 11.1.1, 11.3

プラグイン

必要なプラグインをダウンロード, 3.7.2.1, 10.4

必要なプラグインを特定, 3.7.2

デフォルトでインストールされている, 2.2.4.2, 2.2.4.3

インストール, 3.7

Oracle Management Agentのアップグレードに並行してインストールする, 3.7.2.1

OMSのアップグレード中にインストールする, 3.7.2.2

手動でのダウンロード, 5.1.1

手動でのインストール, 5.1.1

プラグインの選択, 12.1.2, 12.5

ポート

割り当てられるデフォルト・ポート, 3.6

HTTPアップロード・ポート, 10.2

HTTPSアップロード・ポート, 10.2

既存ポートの再使用, 3.6

保護, 10.2, 10.2

非保護, 10.2, 10.2

アップグレード後の再構成, 13.4 構成後オプション, 11.1.2 アップグレード後アクティビティ, 13.8.1 アップグレード後コンソール, 2.2.3.3 アップグレード後の手順

インシデント・ルール・セットの無効化, 13.6.9

Linuxパッチ適用の有効化, 13.6.11

概要, 13.6.1

メトリック収集エラーの解決, 13.6.10

OCMスケジューラの停止, 13.6.5

アップグレード後のタスク, 13.6 Power Broker, 11.1.2 事前デプロイ・オプション, 11.1.2 優先資格証明, 11.1.2, F

デフォルトで選択, 11.1.2

優先資格証明のオーバーライド, 11.1.2

登録

デフォルトの資格証明として, F

優先資格証明として, F

EMCLIを使用して登録, 11.1.2 アップグレード前コンソール

パッチの適用, 9.1, 9.2, 9.3

プライベート・ルールセット, B.1 問題のあるエージェント, 10.6.5 プロセス

1システム・アップグレード方式, 9.1, 9.3

2システム・アップグレード方式, 9.2

プロセス

1システム・アップグレード, 2.2.4.1, 2.2.4.1

異なるホストの1システム・アップグレード, 2.2.4.3

2システム・アップグレード, 2.2.4.2

R

準備状況の確認, 11.2

ソフトウェア・ライブラリの検証エラーの再構成, 13.4

Oracleソフトウェア・ライブラリの再構成, 13.4

確認の手順, 13.4

検証の手順, 13.4

データベースのリカバリ

宛先ホスト, J.2

ソース・ホスト, J

登録, 10.4 リポジトリ・バックアップの詳細, 10.7 root.shスクリプト, 11.1.2, 11.1.2

S

保護ポート, 10.2

OMSの保護, 2.2.4.2

サーバー・ロード・バランサ

構成の更新, E

サーバー・ロード・バランサ, 9.3 共有エージェント, 11.1.2 発生データ移行ジョブのサインオフ, 13.11 省略したジョブ, 3.11.3 SOAターゲット, 11.2, 11.3 ソフトウェア・ライブラリ

Oracleソフトウェア・ライブラリを参照, 3.8

ソフトウェアの場所

検証, 10.4

ステージングの場所, 10.4 ステータス保留中状態, 4, 5.1, 5.2, 5.3, 5.4 SUDO, 11.1.2 サポートされているアップグレード・パス, 3.2 イベント時に一時停止, 11.1.2, 11.2 スイッチオーバーの操作, 2.2.4.1 スイッチオーバー

状態レポートの生成, 11.2

状態レポートのサインオフ, 11.3

スイッチオーバー, 11.4

状態レポートの検証, 11.3

システムのアップグレード方式

Oracleソフトウェア・ライブラリの使用, 3.8

T

追加されるターゲット・タイプ, 13.6.8.1

ターゲット

アップグレード可能性ステータスの確認, 10.6.4

アップグレード性, 10.6.4

2システム・アップグレード

Oracleソフトウェア・ライブラリの再構成, 13.4

2システムの再構成, 13.4

U

非保護アップロード・ポート, 10.2

アップグレード

グラフィック・モードで1システム・アップグレード, 12.1.1

サイレント・モードで1システム・アップグレード, 12.2.1

グラフィック・モードで異なるホストの1システム・アップグレード, 12.5

グラフィック・モードで2システム・アップグレード, 12.1.2

サイレント・モードで2システム・アップグレード, 12.2.2

エージェントのアップグレード・ステータス, 13.5

ソフトウェアのみをインストール

グラフィック・モードで1システム・アップグレード, 12.3.1

サイレント・モードで1システム・アップグレード, 12.4.1

グラフィック・モードで2システム・アップグレード, 12.3.2

サイレント・モードで2システム・アップグレード, 12.4.2

「エージェントのアップグレード」ページ, 6.1

アップグレードできないエージェント, 6.4.3

アップグレード方式, 2.2.1

1システム・アップグレード方式, 2.2.1

異なるホストの1システム・アップグレード方式, 2.2.1

異なるホストの1システム・アップグレード・プロセス, 2.2.4.3

2システム・アップグレード方式, 2.2.1

2システム・アップグレード・プロセス, 2.2.4.2

違い, 2.2.2

概要, 2.2.1

アップグレード・オプション, 2 アップグレード範囲, 3.4 upgrade.rspファイル, 5.2 12c管理エージェントのアップグレード

追加パラメータ, 6.4.2

アップグレード後のタスク, 6.5.1

手順, 6.4

アップグレード・ジョブのステータスと進捗状況, 6.5.1

ユーザー・アカウント

SYS, 5.1, 12.1.1

SYSMAN, 5.1, 12.1.1

V

インベントリが有効, 10.6.1

W

欠落しているエージェント・ソフトウェア, 10.6.3

欠落しているプラグイン, 10.6.3

WLS_DOMAIN_NAMEオプション, 5.1.1

wls1036_generic.jarファイル, 3.4

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。