Oracle Enterprise Manager

Cloud Controlアドバンスト・インストレーションおよび構成ガイド

12cリリース4 (12.1.0.4)

B65085-14(原本部品番号:E24089-42)

2015年8月

Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド, 12cリリース4 (12.1.0.4)

B65085-14

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

原本著者: Aravind Jayaraaman

原本協力著者:  Dennis Lee、Pradeep Gopal、Genevieve D'Souza、Namrata Bhakthavatsalam、Leo Cloutier、Thom Chumley

原本協力者: 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部 概要

1 ソフトウェアの入手

- 1.1 Enterprise Manager Cloud Controlの利用可能なリリース

- 1.2 Enterprise Manager Cloud Controlソフトウェアの入手

- 1.2.1 DVDからEnterprise Manager Cloud Controlソフトウェアにアクセスする方法

- 1.2.1.1 DVDからソフトウェアへのアクセス

- 1.2.1.2 DVDのマウント・ポイントの設定

- 1.2.2 Oracle Technology Networkからソフトウェアを入手する方法

- 1.2.2.1 Enterprise Manager Cloud Controlソフトウェアのダウンロード

- 1.2.2.2 Enterprise Manager Zipファイルのファイル・サイズの確認

- 1.2.2.3 Enterprise Manager Zipファイルの内容の抽出

- 1.2.2.4 Enterprise Manager Cloud Controlソフトウェア・リリースの説明の確認

- 1.2.2.5 プラットフォーム情報の確認

- 1.3 Oracle Management Agentソフトウェアの入手

2 基本の理解

- 2.1 Enterprise Manager Cloud Controlインストールの基本の理解

- 2.1.1 Enterprise Manager Cloud Controlにより提供される異なるインストール・モードとは

- 2.1.2 Enterprise Manager Cloud Controlインストール・ウィザードとは

- 2.1.3 Enterprise Manager Cloud Controlインストール・ウィザードにより提供されるインストール・タイプとは

- 2.1.3.1 Enterprise Managerシステムの新規作成

- 2.1.3.2 既存のEnterprise Managerシステムのアップグレード

- 2.1.3.3 ソフトウェアのみインストール

- 2.1.4 Oracle Configuration Managerとは

- 2.1.4.1 手動による構成情報の収集およびアップロード

- 2.1.4.2 Enterprise Manager Cloud Controlインストール後のOracle Configuration Managerの有効化

- 2.1.5 Enterprise Manager Cloud Controlソフトウェア更新とは

- 2.1.5.1 ソフトウェア更新とは

- 2.1.5.2 ソフトウェア更新機能の動作方法

- 2.1.5.3 ダウンロードおよび適用するソフトウェアの更新のタイプ

- 2.1.5.4 ソフトウェア更新によって修正された不具合の確認方法

- 2.1.5.5 Oracle Management Repositoryが事前構成されたデータベースでもソフトウェア更新が自動的に適用されるか

- 2.1.5.6 ソフトウェア更新のダウンロード方法

- 2.1.5.7 インストールまたはアップグレード後にこれらのパッチをダウンロードおよび適用できるかどうか

- 2.1.5.8 適用されているパッチを識別する方法

- 2.1.6 詳細構成のEnterprise Manager Cloud Controlのデプロイメント・サイズとは

- 2.1.7 ホスト・ターゲットの追加ウィザードとは

- 2.1.8 プラグインとは

- 2.1.9 管理サービスの追加デプロイメント・プロシージャとは

- 2.1.10 インストールに使用されるポート

- 2.1.10.1 Enterprise Manager Cloud Controlインストールに使用されるデフォルト・ポート

- 2.1.10.2 ポートが空いているかどうかを確認する方法

- 2.1.10.3 Enterprise Manager Cloud Controlのインストール中およびインストール後のポートのカスタマイズ方法

- 2.1.10.4 Enterprise Manager Cloud Controlポートのカスタマイズ中の注意事項

- 2.1.11 Oracle Management Repositoryの構成中に作成されるデータ・ファイル

- 2.1.12 Oracle Management Repositoryの構成中に作成されるデータ・ファイルの削除方法

- 2.1.13 Enterprise Managerのグローバリゼーション・サポート

- 2.2 Enterprise ManagerのインストールにおけるOracle WebLogic Server要件の理解

- 2.2.1 Oracle WebLogic Serverがインストールされているかどうかを確認する方法

- 2.2.2 Oracle WebLogic Serverクラスタがサポートされているか

- 2.2.3 Oracle WebLogic Serverがすでに存在する場合、既存のドメインが使用されるか

- 2.2.4 Oracle WebLogic Serverの資格証明が必要な場合と理由

- 2.2.5 ノード・マネージャの資格証明が必要な場合と理由

- 2.2.6 Enterprise Managerのインストール後に管理サーバー・ポートを見付ける方法

- 2.2.7 管理サーバーが実行されているかどうかを確認する方法

- 2.2.8 管理サーバーの起動方法

- 2.3 インストール・ディレクトリの理解

- 2.3.1 Oracleインベントリ・ディレクトリとは

- 2.3.2 Oracleミドルウェア・ホームとは

- 2.3.3 Oracle Management Serviceインスタンス・ベースの場所とは

- 2.3.4 Oracleホームとは

- 2.3.5 エージェント・ベース・ディレクトリとは

- 2.3.6 エージェント・インスタンス・ディレクトリとは

- 2.3.7 /TMPまたはC:\Tempディレクトリの用途とは

- 2.4 コンフィギュレーション・アシスタントの理解

- 2.4.1 コンフィギュレーション・アシスタントとは

- 2.4.2 インストール・ウィザードにより実行されるコンフィギュレーション・アシスタント

- 2.4.2.1 Enterprise Managerの新規インストールで実行されるコンフィギュレーション・アシスタント

- 2.4.2.2 既存のEnterprise Managerのアップグレードで実行されるコンフィギュレーション・アシスタント

- 2.4.2.3 追加のOracle Management Serviceのアップグレードで実行されるコンフィギュレーション・アシスタント

- 2.4.3 コンフィギュレーション・アシスタントが失敗した場合の処理

- 2.5 Enterprise Manager Cloud Controlをインストールする前の前提条件チェックの理解

- 2.5.1 デフォルトで実行される前提条件チェック

- 2.5.2 スタンドアロン・モードで前提条件チェックを実行する方法

- 2.6 Enterprise Manager Cloud Controlの制限事項の理解

- 2.6.1 ライセンスのないコンポーネントにアクセスできるか

- 2.6.2 DHCP対応のマシンに関連する制限事項

- 2.7 起動スクリプトの理解

- 2.7.1 起動スクリプトの格納場所

- 2.7.2 起動スクリプトの呼出し対象

- 2.7.3 起動スクリプトによるOMSまたは管理エージェントの起動を停止する方法

- 2.7.4 起動スクリプトによってリモート・ホストのOMSまたは管理エージェントを起動できるかどうか

- 2.7.5 管理エージェントが起動または停止するときに起動スクリプトが従う管理エージェント・サービスの優先順位レベルを変更できるかどうか

- 2.8 その他の概念の理解

- 2.8.1 ホスト・リスト・ファイルとは

- 2.8.2 インストール・プロセス中に実行されるスクリプト

第II部 Enterprise Managerシステムのインストール

3 サイレント・モードでのEnterprise Managerのインストール

- 3.1 サイレント・モードでのEnterprise Managerのインストールの概要

- 3.2 サイレント・モードでのEnterprise Managerのインストールを開始する前に

- 3.3 サイレント・モードでEnterprise Managerをインストールするための前提条件

- 3.4 サイレント・モードでのEnterprise Managerのインストール

- 3.4.1 サイレント・モードでのEnterprise Managerのインストール

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

- 3.4.3 サイレント・モードでEnterprise Managerシステムをインストールするためにサポートされている拡張オプションに関する制限事項

- 3.4.4 サイレント・モードでEnterprise Managerをインストールするためのnew_install.rspレスポンス・ファイルの編集

- 3.5 サイレント・モードでEnterprise Managerシステムをインストールした後のインストール後のタスクの実行

4 ソフトウェアのみの方法を使用したEnterprise Managerのインストール

- 4.1 ソフトウェアのみの方法を使用したEnterprise Managerのインストールの概要

- 4.2 ソフトウェアのみの方法を使用したEnterprise Managerのインストールを開始する前に

- 4.3 ソフトウェアのみの方法を使用してEnterprise Managerをインストールするための前提条件

- 4.4 ソフトウェアのみの方法を使用したEnterprise Managerのインストール

- 4.4.1 グラフィック・モードでのソフトウェアのみの方法を使用したEnterprise Managerのインストール

- 4.4.1.1 Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリのインストール(グラフィック・モード)

- 4.4.1.1.1 グラフィック・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアのインストール中の拡張インストーラ・オプションの使用

- 4.4.1.2 rootスクリプトの実行

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

- 4.4.1.3.1 グラフィック・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアの構成中の拡張スクリプト・オプションの使用

- 4.4.1.4 グラフィック・モードでのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリの構成後の構成後タスクの実行

- 4.4.2 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Managerのインストール

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

- 4.4.2.1.1 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアをインストールするためのsoftware_only.rspレスポンス・ファイルの編集

- 4.4.2.2 rootスクリプトの実行

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

- 4.4.2.3.1 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアを構成するためのnew_install.rspレスポンス・ファイルの編集

- 4.4.2.4 サイレント・モードでのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリの構成後の構成後タスクの実行

第III部 追加のOracle Management Agentのインストール

5 サイレント・モードでの追加のOracle Management Serviceのインストール

第IV部 Oracle Management Agentのインストール

6 サイレント・モードでのOracle Management Agentのインストール

- 6.1 サイレント・モードでの管理エージェントのインストールの概要

- 6.2 サイレント・モードでの管理エージェントのインストールを開始する前に

- 6.3 サイレント・モードでOracle Management Agentをインストールするための前提条件

- 6.4 サイレント・モードでの管理エージェントのインストール

- 6.4.1 AgentPullスクリプトを使用した管理エージェントのインストール

- 6.4.1.1 管理エージェント・ソフトウェアの取得

- 6.4.1.2 AgentPullスクリプトを使用した管理エージェントのインストール

- 6.4.2 agentDeployスクリプトを使用した管理エージェントのインストール

- 6.4.2.1 リモートの宛先ホストからのEM CLIの使用

- 6.4.2.2 OMSホストからのEM CLIの使用

- 6.4.3 RPMファイルを使用した管理エージェントのインストール

- 6.4.3.1 管理エージェント・ソフトウェアを取得し、OMSホストにRPMファイルをダウンロードします

- 6.4.3.2 RPMファイルを宛先ホストへ転送します

- 6.4.3.3 RPMファイルを使用して管理エージェントをインストールします

- 6.4.4 仮想ホストへの管理エージェントのインストール

- 6.4.5 AgentPullスクリプトを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

- 6.4.6 agentDeployスクリプトを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

- 6.4.7 RPMファイルを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

- 6.4.8 AgentPullスクリプトでサポートされているオプション

- 6.4.9 agentDeployスクリプトでサポートされているオプション

- 6.4.10 ダウンロードした管理エージェント・ソフトウェアの内容について

- 6.4.11 管理エージェントRPMファイルの内容について

- 6.5 サイレント・モードでの管理エージェントのインストール後

7 Oracle Management Agentのクローニング

- 7.1 管理エージェントのクローニングの概要

- 7.2 管理エージェントのクローニングを開始する前に

- 7.3 管理エージェントをクローニングするための前提条件

- 7.4 管理エージェントのクローニング

- 7.4.1 グラフィック・モードでの管理エージェントのクローニング

- 7.4.1.1 ホスト・ターゲットの追加ウィザードを使用した管理エージェントのクローニング

- 7.4.1.2 ホスト・リスト・ファイルの形式

- 7.4.1.3 グラフィック・モードでの管理エージェントのクローニングでサポートされる追加パラメータ

- 7.4.2 サイレント・モードでの管理エージェントのクローニング

- 7.5 管理エージェントのクローニング後

8 共有エージェントのインストール

- 8.1 共有エージェントのインストールの概要

- 8.2 共有エージェントのインストールを開始する前に

- 8.3 共有エージェントをインストールするための前提条件

- 8.4 共有エージェントのインストール

- 8.4.1 「ホスト・ターゲットの追加」ウィザードを使用した共有エージェントのインストール

- 8.4.2 「ホスト・ターゲットの追加」ウィザードを使用した共有エージェントのインストールでサポートされる追加パラメータ

- 8.4.3 サイレント・モードでの共有エージェントのインストール

- 8.4.4 サイレント・モードで共有エージェントをインストールするためのレスポンス・ファイル・パラメータ

- 8.5 共有エージェントのインストール後

9 Oracle Management Agentソフトウェアを今すぐインストールして後で構成

- 9.1 管理エージェントをインストールして後で構成する概要

- 9.2 管理エージェントのインストールを開始する前に

- 9.3 管理エージェントをインストールするための前提条件

- 9.4 管理エージェントのソフトウェア・バイナリのみのインストール

- 9.5 管理エージェントのソフトウェア・バイナリの構成

- 9.6 管理エージェントのインストール後

第V部 拡張インストールおよび構成

10 Enterprise Managerのファイアウォールの構成

- 10.1 Enterprise Managerの使用中のファイアウォール構成の考慮について

- 10.2 Enterprise Managerコンポーネントが使用するデフォルト・ポート

- 10.3 Enterprise Managerのファイアウォール構成について

- 10.4 WebブラウザとEnterprise Managerコンソールの間のファイアウォールについて

- 10.5 ファイアウォールで保護されたホスト上の管理エージェントの構成について

- 10.6 プロキシ・サーバーを使用するための管理エージェントの構成

- 10.7 OMSと管理エージェントの通信を許可するファイアウォールの構成について

- 10.8 ファイアウォールで保護されたホスト上のOMSの構成について

- 10.9 管理エージェントとの通信にプロキシ・サーバーを使用するためのOMSの構成

- 10.10 管理エージェントがデータをOMSにアップロードできるファイアウォールの構成について

- 10.11 My Oracle SupportにアクセスするためのOMSの有効化について

- 10.12 dontProxyforプロパティについて

- 10.13 OMSと管理リポジトリの間のファイアウォールについて

- 10.14 Enterprise Managerと管理対象データベース・ターゲットの間のファイアウォールについて

- 10.15 複数のOMSインスタンスでのファイアウォールの使用について

- 10.16 Oracleビーコンに対するICMPおよびUDP通信を可能にするためのファイアウォールの構成について

- 10.17 ファイアウォールでのICMPエコー・リクエストの有効化について

11 Enterprise Managerデプロイメントのサイジング

- 11.1 Enterprise Manager Cloud Controlのサイジング

- 11.1.1 サイジング・ガイドラインの概要

- 11.1.1.1 ハードウェア情報

- 11.1.1.2 サイジングの仕様

- 11.1.1.3 アップグレードされたインストールのサイジング

- 11.1.1.4 最小ハードウェア要件

- 11.1.1.5 ネットワーク・トポロジの考慮事項

- 11.1.2 ソフトウェア構成

- 11.1.2.1 評価構成

- 11.1.2.2 小規模の構成

- 11.1.2.3 中規模の構成

- 11.1.2.4 大規模の構成

- 11.1.2.5 リポジトリ表領域のサイジング

- 11.1.3 追加構成

- 11.1.3.1 大規模な同時UI負荷

- 11.1.3.2 大規模なジョブ・システム負荷

- 11.1.3.3 大規模なリポジトリ側の可用性負荷(リリース12.1.0.3以上)

- 11.1.3.4 多数のエージェント(リリース12.1.0.3)

- 11.1.3.5 OMSプロパティの変更

- 11.1.3.6 データベース設定の変更

- 11.1.3.7 BI Publisherの構成

- 11.2 Enterprise Manager Cloud Controlのパフォーマンス最適化の方法

- 11.2.1 手順1: 最初のプラットフォームのCloud Controlデプロイの選択

- 11.2.2 手順2: サイトのバイタル・サインの定期的な評価

- 11.2.3 手順3: DBAおよびEnterprise Managerタスクを使用したボトルネックの排除

- 11.2.3.1 月に1回のオフライン・タスク

- 11.2.4 手順4: チューニングによるボトルネックの排除

- 11.2.4.1 高いCPU使用率

- 11.2.4.2 ローダーのバイタル・サイン

- 11.2.4.3 ロールアップのバイタル・サイン

- 11.2.4.4 ロールアップ・プロセス

- 11.2.4.5 ジョブ、通知およびアラートのバイタル・サイン

- 11.2.4.6 I/Oのバイタル・サイン

- 11.2.4.7 Oracle Enterprise Managerの「パフォーマンス」ページ

- 11.2.4.8 中間層OMSサーバーの最適な数の決定

- 11.2.5 手順5: サイジング要件を計画するための将来的な直線外挿

- 11.2.6 問合せの結果に関する予防措置を使用したパフォーマンスの向上

- 11.3 Fusion Middlewareの監視に対するリポジトリとサイジングの要件の概要

- 11.3.1 ADP監視

- 11.3.2 JVMD監視

12 拡張インストール・オプションを使用したADPのインストール

- 12.1 アプリケーションの依存性とパフォーマンスのアークテクチャの概要

- 12.2 アプリケーションの依存性とパフォーマンスのインストールを開始する前に

- 12.3 アプリケーションの依存性とパフォーマンスをインストールするための前提条件

- 12.4 高度なインストール・オプションを使用したアプリケーションの依存性とパフォーマンスのインストール

- 12.4.1 ApmEngineSetup.plを使用したADPエンジンの手動でのデプロイ

- 12.4.2 deploy_adpagent.plを使用したADPエージェントの手動でのデプロイ

- 12.5 アプリケーションの依存性とパフォーマンスのインストール後

- 12.5.1 ADPエンジンおよびADPエージェントのインストールの検証

- 12.5.2 セキュアな接続のためのOracle SOA Suiteの構成(ADPのインストール後)

- 12.5.3 セキュアな接続のためのOracle WebLogic ServerまたはOracle WebLogic Portal (WLP)の構成(ADPのインストール後)

- 12.5.4 ADPエンジンのキーストアへの証明書のインポート

- 12.5.5 WebLogicがWindowsサービスとしてインストールされる場合のADPエージェントの構成

13 拡張インストール・オプションを使用したJVMDのインストール

- 13.1 JVMDアーキテクチャの概要

- 13.2 JVMDのインストールを開始する前に

- 13.3 JVMDをインストールするための前提条件

- 13.4 拡張インストール・オプションを使用したJVMDのインストール

- 13.4.1 ApmEngineSetup.plを使用したJVMDエンジンの手動でのデプロイ

- 13.4.2 JVMDエージェントのデプロイ

- 13.4.2.1 javadiagnosticagent.earまたはjamagent.warをダウンロードおよびデプロイした手動でのJVMDエージェントのデプロイ

- 13.4.2.2 deploy_jvmdagent.plを使用したJVMDエージェントの手動でのデプロイ

- 13.4.2.3 高可用性を実現するJVMDエージェントのデプロイ

- 13.4.2.4 JVMDデータベース・エージェントのデプロイ

- 13.4.2.5 JVMDエージェントをJVMDエンジン・セキュア・ポートに接続したセキュアな通信の確認

- 13.5 JVMDのインストール後

14 Enterprise ManagerでのBI Publisherの構成

- 14.1 概要

- 14.1.1 制限事項

- 14.2 BI Publisherの構成およびEnterprise Manager 12cとの統合

- 14.2.1 Enterprise Managerおよび必要なインフラストラクチャのインストール

- 14.2.1.1 configureBIPスクリプトを使用したBI PublisherとEnterprise Managerの統合

- 14.3 Enterprise Managerリリース4 (12.1.0.4)でデプロイされたBI Publisherを構成

- 14.4 12.1.0.4ミドルウェア・ホームで以前のBI Publisherホームから新BI PublisherへとBI Publisherの構成をアップグレード

- 14.5 BI PublisherとEnterprise Managerの統合の確認

- 14.6 Enterprise Manager管理者に対するBI Publisherへのアクセスの許可

- 14.6.1 Enterprise Manager認証セキュリティ・モデル

- 14.6.2 BI Publisherセキュリティ・モデル

- 14.6.3 BI Publisherの権限

- 14.6.4 BI PublisherのOPSSアプリケーション・ロール

- 14.6.5 BI Publisher機能へのアクセス認証とアクセス制限

- 14.7 BI Publisher機能へのアクセス制限

- 14.7.1 wlstを使用したリポジトリベースの認証モードによるEnterprise Manager管理者へのBI Publisher OPSSアプリケーション・ロールの付与

- 14.7.2 OPSSへの変更の伝播時間

- 14.8 基礎となるLDAP認証セキュリティ環境でのEnterprise Manager管理者に対するBI Publisherへのアクセスの許可

- 14.8.1 BI PublisherのOPSSアプリケーション・ロールに対するLDAPグループのマッピング

- 14.9 Secure Socket Layer (SSL)証明書を使用したBI Publisherの保護

- 14.10 BI Publisherの管理

- 14.11 BI Publisher構成後の構成後処理手順

- 14.12 EMBIP*ロール: フォルダおよびカタログ・オブジェクトへのアクセス権の付与

- 14.13 Enterprise Managerリポジトリへのアクセス

- 14.14 トラブルシューティング

- 14.14.1 configureBIPの再実行

- 14.14.2 BI Publisherログ・ファイルの場所

- 14.14.2.1 configureBIPログ・ファイル

- 14.14.2.2 Enterprise Manager BI PublisherツリーおよびEM CLIログ・ファイルの出力

- 14.14.2.3 BI Publisherランタイム

- 14.14.3 その他のトラブルシューティング

- 14.14.4 Enterprise Managerが提供するすべてのBI Publisherレポートの再デプロイ

- 14.14.5 BI Publisherのデバッグの有効化

- 14.14.5.1 BI Publisherのデバッグの有効化

- 14.14.5.2 BI Publisherのデバッグの無効化

- 14.15 Enterprise Managerの管理 - BI Publisherの接続資格証明

- 14.16 BI Publisherサーバーの管理

- 14.17 BI Publisherの使用

- 14.18 Enterprise Manager 12.1.0.4とともにインストールされなかったBI Publisherの削除

15 「コンソール限定モード」でのOMSの稼働

第VI部 Enterprise Managerの高可用性の構成

16 高可用性ソリューション

- 16.1 高可用性の最新情報

- 16.2 高可用性の定義

- 16.2.1 高可用性のレベル

- 16.3 可用性レベルの比較

- 16.4 高可用性レベルの実装

17 Enterprise Managerの高可用性

- 17.1 エージェントの高可用性

- 17.1.1 ブート時の起動および障害時の再起動を自動的に行う管理エージェントの構成

- 17.1.2 管理エージェントの再起動の構成

- 17.1.3 冗長記憶域への管理エージェント・ソフトウェアのインストール

- 17.2 リポジトリの高可用性

- 17.2.1 リポジトリの高可用性に関する一般的なベスト・プラクティス

- 17.2.2 管理リポジトリに対するRACの構成

- 17.3 Oracle Management Serviceの高可用性

- 17.3.1 別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSを構成するためのベスト・プラクティス

- 17.3.1.1 概要および要件

- 17.3.1.2 ORACLE_BASEでのOMSインストール・ベース・ディレクトリの作成

- 17.3.1.3 別名ホスト名の構成

- 17.3.1.4 OMSインストール・ベース・ディレクトリに配置されたOracleインベントリの構成

- 17.3.1.5 すべてのノードでのソフトウェア所有者とグループの同一構成

- 17.3.1.6 すべてのノードで同様に構成にするタイムゾーンの選択

- 17.3.1.7 インストールおよび構成

- 17.3.2 仮想ホスト名を使用したHAフェイルオーバーのアクティブ/パッシブ環境でのCloud Control OMSの構成

- 17.3.2.1 概要および要件

- 17.3.2.2 インストールおよび構成

- 17.3.2.3 仮想ホスト名/仮想IPアドレスの設定

- 17.3.2.4 共有記憶域の設定

- 17.3.2.5 環境の設定

- 17.3.2.6 オペレーティング・システムIDの同期化

- 17.3.2.7 共有インベントリの設定

- 17.3.2.8 ソフトウェアのインストール

- 17.3.2.9 サービスの起動

- 17.3.3 追加の管理サービスのインストール

- 17.3.4 サーバー・ロード・バランサ(SLB)の内側への複数の管理サービスの構成

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

- 17.3.4.2 ロード・バランサの構成

- 17.3.4.2.1 SLB側の設定

- 17.3.4.2.2 Enterprise Manager側の設定

- 17.3.4.2.3 Enterprise ManagerおよびSLB (リリース12.1.0.2以降)のSSLの構成

18 Enterprise Manager障害時リカバリ

- 18.1 障害時リカバリの概要とトポロジ

- 18.2 設計上の考慮事項

- 18.2.1 ネットワークに関する考慮事項

- 18.2.1.1 ホスト名の計画

- 18.2.1.2 ロード・バランサに関する考慮事項

- 18.2.1.3 アプリケーションの仮想ホスト名に関する考慮事項

- 18.2.2 記憶域に関する考慮事項

- 18.2.3 データベースに関する考慮事項

- 18.2.3.1 11gリリース2よりも前のOracle Databaseに関する考慮事項

- 18.2.3.2 11gリリース2以降のOracle Databaseに関する考慮事項

- 18.2.4 開始ポイント

- 18.2.4.1 プライマリ・サイトがすでに作成されており、スタンバイ・サイトが計画中です

- 18.2.4.2 プライマリ・サイトがすでに作成されており、スタンバイ・サイトが非推奨の"スタンバイWLSドメイン"メソッドを使用してすでに作成されています。

- 18.2.4.3 インストールが存在せず、プライマリおよびスタンバイの両方のサイトが計画中です

- 18.3 管理リポジトリの障害時リカバリの設定

- 18.3.1 管理リポジトリのためのスタンバイ・データベースの構成

- 18.4 OMS、BI Publisher共有記憶域およびソフトウェア・ライブラリの障害時リカバリの設定

- 18.4.1 管理サービスの障害時リカバリ

- 18.4.2 スタンバイOMSホストの監視

- 18.4.3 ソフトウェア・ライブラリ障害時リカバリ

- 18.4.4 BI Publisherの共有記憶域の障害時リカバリ

- 18.4.5 共有記憶域への既存のサイトの移行

- 18.5 スイッチオーバーおよびフェイルオーバー操作の実行

- 18.5.1 スイッチオーバーの手順

- 18.5.2 フェイルオーバー手順

- 18.6 スタンバイ・サイトのプライマリとの同期の維持

- 18.7 ACFSレプリケーションが可能な障害時リカバリ・ソリューション

19 Enterprise Managerのバックアップとリカバリ

- 19.1 デプロイメントのバックアップ

- 19.2 ソフトウェア・ライブラリのバックアップ

- 19.3 リポジトリ・バックアップの管理

- 19.4 Oracle Management Serviceのバックアップ

- 19.5 エージェント・バックアップの管理

- 19.6 障害の発生したEnterprise Managerコンポーネントのリカバリ

- 19.6.1 リポジトリのリカバリ

- 19.6.2 リカバリ・シナリオ

- 19.6.2.1 同一ホスト上の完全リカバリ

- 19.6.2.2 同一ホスト上の不完全リカバリ

- 19.6.2.3 別のホスト上の完全リカバリ

- 19.6.2.4 別のホスト上の不完全リカバリ

- 19.6.3 OMSのリカバリ

- 19.6.3.1 ソフトウェア・ホームのリカバリ

- 19.6.3.2 OMSの再作成

- 19.6.4 OMSのリカバリ・シナリオ

- 19.6.4.1 単一OMS、サーバー・ロード・バランサ(SLB)なし、OMSを同一ホスト上でリストア

- 19.6.4.2 単一OMS、SLBなし、OMSを別のホスト上でリストア

- 19.6.4.3 単一OMS、SLBなし、OMSをオリジナルのホスト名を使用して別のホスト上でリストア

- 19.6.4.4 複数OMS、サーバー・ロード・バランサ、プライマリOMSを同一ホスト上でリカバリ

- 19.6.4.5 複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ

- 19.6.4.6 複数OMS、SLB構成済、追加OMSが同一または別のホスト上でリカバリ

- 19.6.5 ソフトウェア・ライブラリのリカバリ

- 19.6.6 管理エージェントのリカバリ

- 19.6.7 管理エージェントのリカバリ・シナリオ

- 19.6.7.1 同じポートを使用した管理エージェントの再インストール

- 19.6.7.2 ファイルシステム・バックアップからの管理エージェントのリストア

- 19.7 OMSと管理リポジトリの同時障害からのリカバリ

- 19.7.1 縮小構成: 管理リポジトリの不完全リカバリ、同じホスト上のプライマリOMS

- 19.7.2 分散構成: 別のホスト上の管理リポジトリの不完全リカバリ、プライマリOMSおよび追加OMS、SLB構成済

20 複数のBI Publisherサーバーの実行

- 20.1 BI Publisher複数サーバー環境の概要

- 20.2 共有ストレージ・デバイスを使用するためのBI Publisherの再構成

- 20.3 セカンダリBI Publisherサーバーの追加

- 20.3.1 パスA - 「OMSの追加」プロビジョニング・ジョブを使用したセカンダリBI Publisherサーバーの自動での構成

- 20.3.1.1 プライマリBI Publisherサーバーの構成

- 20.3.1.2 共有記憶域を使用するためのBI Publisherの再構成

- 20.3.1.3 追加OMSシステムの追加とセカンダリBI Publisherサーバーの自動での構成

- 20.3.2 パスB: 追加OMSシステムの追加後のセカンダリBI Publisherサーバーの構成

- 20.3.2.1 プライマリBI Publisherサーバーの構成

- 20.3.2.2 共有記憶域を使用するためのBI Publisherの再構成

- 20.3.2.3 セカンダリBI Publisherサーバーの構成

- 20.4 追加OMSシステムでセカンダリBI Publisherサーバーが正しく動作することの確認

- 20.5 セカンダリBI Publisherサーバーの詳細の確認

第VII部 削除

21 Enterprise Managerの削除(単一および複数OMS環境)

- 21.1 Enterprise Managerの削除

- 21.1.1 OMSのみを削除し管理リポジトリを保持するための前提条件

- 21.1.2 Enterprise Managerシステム全体を削除するための前提条件

- 21.1.3 Enterprise Managerを削除するための手順

- 21.1.3.1 グラフィック・モードでのEnterprise Managerの削除

- 21.1.3.2 サイレント・モードでのEnterprise Managerの削除

- 21.1.4 Enterprise Managerの削除後

- 21.2 OMSからのプラグインのみの削除またはアンデプロイ

- 21.3 管理リポジトリからのOMSエントリの削除

22 Oracle Management Agentの削除

- 22.1 Oracle Management Agentの削除

- 22.1.1 Oracle Management Agentを削除するための前提条件

- 22.1.2 Oracle Management Agentを削除するための手順

- 22.1.2.1 AgentDeinstall.plスクリプトを使用したOracle Management Agentの削除(推奨)

- 22.1.2.2 インストール・ウィザードをグラフィカル・モードで使用したOracle Management Agentの削除

- 22.1.2.3 インストール・ウィザードをサイレント・モードで使用したOracle Management Agentの削除

- 22.1.2.4 共有エージェントの削除

- 22.1.2.5 RPMファイルを使用してインストールしたOracle Management Agentの削除

- 22.1.3 Oracle Management Agentの削除後

- 22.2 Oracle Management Agentからのプラグインのみの削除またはアンデプロイ

23 ADPとJVMDの削除

- 23.1 ADPの削除

- 23.1.1 ADPエンジンの削除

- 23.1.1.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエンジンの削除

- 23.1.1.2 ADPエンジンの手動での削除

- 23.1.1.3 ApmEngineSetup.plを使用したADPエンジンの手動での削除

- 23.1.2 ADPエージェントの削除

- 23.1.2.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエージェントの削除

- 23.1.2.2 ADPエージェントの手動での削除

- 23.2 JVMDの削除

- 23.2.1 JVMDエンジンの削除

- 23.2.1.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエンジンの削除

- 23.2.1.2 JVMDエンジンの手動での削除

- 23.2.1.3 ApmEngineSetup.plを使用したJVMDエンジンの手動での削除

- 23.2.2 JVMDエージェントの削除

- 23.2.2.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエージェントの削除

- 23.2.2.2 JVMDエージェントの手動での削除

24 スタンバイOracle Management Serviceの削除

- 24.1 追加のスタンバイOMSインスタンスの削除

- 24.2 最初のスタンバイOMSの削除

第VIII部 付録

A Enterprise Managerのディレクトリ構造の理解

- A.1 Oracle Enterprise Manager Cloud Control 12cとともにインストールされるEnterprise Managerのディレクトリの理解

- A.1.1 Oracle Management Serviceホーム・ディレクトリについて

- A.1.2 Oracle Management Agentホーム(AGENT_HOME)ディレクトリについて

- A.1.3 Business Intelligence Publisherホーム・ディレクトリについて

- A.1.4 Oracle Management Serviceホーム内の重要なディレクトリの要約

- A.2 管理サービスとともにインストールされるEnterprise Managerのディレクトリの理解

- A.3 管理エージェントとともにインストールされるEnterprise Managerのディレクトリの理解

- A.3.1 Oracle Management Agentホーム内の重要なディレクトリの要約

- A.3.2 WindowsのOracle Management Agentディレクトリ構造の理解

- A.4 emctlコマンド使用時のエージェント・インスタンス・ホームの識別

B インストールおよび構成ログ・ファイルの概要

- B.1 Enterprise Manager Cloud Controlのインストール・ログ

- B.1.1 インストール・ログ

- B.1.2 構成ログ

- B.1.2.1 一般的な構成ログ

- B.1.2.2 リポジトリ構成ログ

- B.1.2.2.1 SYSMANスキーマ操作ログ

- B.1.2.2.2 EMPrereqKitログ

- B.1.2.2.3 MDSスキーマ操作ログ

- B.1.2.3 セキュア・ログ

- B.1.2.4 Oracle Management Serviceログ

- B.2 ホストの追加ログ・ファイル

- B.2.1 初期化ログ

- B.2.2 アプリケーション前提条件ログ

- B.2.3 システム前提条件ログ

- B.2.4 エージェントのインストール・ログ

- B.2.5 ホストの追加のその他のログ

- B.3 手動の管理エージェント・インストール・ログ

- B.4 追加のOMSインストール・ログ

C Oracle Management Agentの別のOracle Management Serviceへのリダイレクト

- C.1 管理エージェントを別のOMSにリダイレクトするための前提条件

- C.2 別のOMSへの管理エージェントのリダイレクト

D Oracle Management Agentのデプロイまたはアップグレード中のパッチの適用

- D.1 管理エージェント・パッチのOMSホストへの保存

- D.2 管理エージェントのデプロイまたはアップグレード後のパッチ適用の検証

E RepManagerユーティリティの使用

- E.1 RepManagerユーティリティの概要

- E.2 RepManagerユーティリティでサポートされる操作およびコマンド

F Oracle Harvesterを使用したOCMデータの収集

- F.1 Oracle Harvester

- F.1.1 Oracle Harvesterの特徴

- F.1.2 Oracle HarvesterとOCM

- F.1.3 Enterprise Managerリリース12.1のサポート

- F.1.4 Enterprise ManagerでのCSIの表示

- F.1.5 Enterprise ManagerからのHarvesterターゲット・ライフサイクル・プロパティ

- F.1.6 ハーベスタ・ジョブ・ステータス・メトリック

- F.1.7 Oracle Harvesterでサポートされているターゲット

- F.1.8 My Oracle Supportで使用できない構成データ

- F.2 Oracle Configuration Managerの構成

- F.3 MOSおよびOCMの追加情報

- F.4 構成データ収集ツールのトラブルシューティング

- F.4.1 state/upload/externalディレクトリが存在しない場合にOracle Harvesterによる収集が失敗する

- F.4.2 Oracle Configuration Managerが実行されない

- F.4.3 My Oracle Supportで使用できない構成データ

- F.4.4 Oracle Harvesterによってターゲットのサブセットのみが収集される

G Enterprise Managerのアクセシビリティ機能の有効化

- G.1 Enterprise Managerのアクセシビリティ・モードの有効化

- G.2 uix-config.xmlフラグの設定

- G.3 web.xmlファイルの構成

- G.4 スクリーン・リーダーのサポートが有効になっていることの確認

H アクティブおよびパッシブ環境でのフェイルオーバーのターゲットの構成

- H.1 アクティブおよびパッシブ環境でのターゲットの再配置

- H.2 インストールおよび構成

- H.2.1 前提条件

- H.2.2 構成手順

- H.2.2.1 ターゲットの検出

- H.2.2.2 プラグインのデプロイ

- H.3 フェイルオーバー・プロシージャ

- H.4 フェイルバック手順

- H.5 EM CLI relocate_targetsのパラメータ

- H.6 再配置スクリプト

- H.6.1 再配置スクリプトの例

I スタンバイWebLogicドメインを使用するスタンバイOMS

- I.1 スタンバイ・サイトでのスタンバイ管理サービスの構成

- I.1.1 最初のスタンバイ管理サービスのインストール

- I.1.2 最初のスタンバイ管理サービスのインストール(Oracle Installer、ソフトウェア専用モード)

- I.1.3 追加のスタンバイ管理サービスのインストール

- I.1.4 追加のスタンバイ管理サービスのインストール(Oracle Installer、ソフトウェア専用モード)

- I.1.5 インストールの検証と設定の完了

- I.1.5.1 スタンバイ・サイトの同期の維持

- I.2 スイッチオーバー操作とフェイルオーバー操作の管理

- I.2.1 スイッチオーバー

- I.2.2 フェイルオーバー

J トラブルシューティング

- J.1 コンフィギュレーション・アシスタント障害のトラブルシューティング

- J.1.1 プラグイン前提条件チェック・コンフィギュレーション・アシスタント

- J.1.1.1 ログ・ファイル

- J.1.1.2 回避手順

- J.1.2 リポジトリ・コンフィギュレーション・アシスタント

- J.1.2.1 ログ・ファイル

- J.1.2.2 回避手順

- J.1.3 リポジトリ即時使用可能コンフィギュレーション・アシスタント

- J.1.3.1 ログ・ファイル

- J.1.3.2 回避手順

- J.1.4 MDSスキーマ・コンフィギュレーション・アシスタント

- J.1.4.1 ログ・ファイル

- J.1.4.2 回避手順

- J.1.5 OMSコンフィギュレーション・アシスタント

- J.1.5.1 ログ・ファイル

- J.1.5.2 回避手順

- J.1.6 プラグインのデプロイおよびコンフィギュレーション・アシスタント

- J.1.6.1 ログ・ファイル

- J.1.6.2 回避手順

- J.1.7 Oracle Management Serviceの起動コンフィギュレーション・アシスタント

- J.1.7.1 ログ・ファイル

- J.1.7.2 回避手順

- J.1.8 プラグイン・インベントリの移行コンフィギュレーション・アシスタント

- J.1.8.1 ログ・ファイル

- J.1.8.2 回避手順

- J.1.9 Oracle Configuration Managerリピーター・コンフィギュレーション・アシスタント

- J.1.9.1 ログ・ファイル

- J.1.9.2 回避手順

- J.1.10 OMSのOCM構成コンフィギュレーション・アシスタント

- J.1.10.1 ログ・ファイル

- J.1.10.2 回避手順

- J.1.11 エージェント・コンフィギュレーション・アシスタント

- J.1.11.1 ログ・ファイル

- J.1.11.2 回避手順

- J.1.12 エージェント・アップグレード・コンフィギュレーション・アシスタント

- J.1.12.1 ログ・ファイル

- J.1.12.2 回避手順

- J.1.13 リポジトリ・アップグレード・コンフィギュレーション・アシスタント

- J.1.13.1 ログ・ファイル

- J.1.13.2 回避手順

- J.1.14 APMエンジン・コンフィギュレーション・アシスタントの停止

- J.1.14.1 ログ・ファイル

- J.1.14.2 回避手順

- J.1.15 管理サーバー・コンフィギュレーション・アシスタントの停止

- J.1.15.1 ログ・ファイル

- J.1.15.2 回避手順

- J.2 ADPとJVMD障害のトラブルシューティング

- J.2.1 ADPエンジン名の競合

- J.2.1.1 エラー

- J.2.1.2 回避手順

- J.2.2 ADPエージェント・デプロイメントの失敗

- J.2.2.1 エラー

- J.2.2.2 回避手順

- J.2.3 WebLogic Server 12.1.2でのADPエージェント・デプロイメントの失敗

- J.2.3.1 エラー

- J.2.3.2 回避手順

- J.2.4 JVMDエージェント・デプロイメントの失敗

- J.2.4.1 エラー

- J.2.4.2 回避手順

- J.2.5 エージェント・デプロイメント中のSSLハンドシェイクの失敗

- J.2.5.1 エラー

- J.2.5.2 回避手順

- J.2.6 ADPエージェントのZipまたはJavadiagnosticagent.earのコピーの失敗

- J.2.6.1 エラー

- J.2.6.2 回避手順

- J.2.7 JVMプール作成の失敗

- J.2.7.1 エラー

- J.2.7.2 トラブルシューティングのヒント

- J.3 パッケージに関する問題のトラブルシューティング

- J.4 削除の失敗のトラブルシューティング

- J.5 管理エージェント・インストール失敗のトラブルシューティング

索引

はじめに

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を拡張したものです。

『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』では、Enterprise Manager Cloud Controlの使用開始を支援する基本的なインストール手順が説明されていますが、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』では、より複雑な環境へのEnterprise Manager Cloud Controlコンポーネントのインストールおよび構成に役立つ、拡張インストール手順が説明されています。

ここでは、次のトピックについて説明します。

- 対象読者

- このドキュメントの目的

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

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』は、Enterprise Manager Cloud Controlコンポーネントを複雑な環境にインストールするシステム管理者を対象にしています。

このドキュメントの目的

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』では、次の手順について説明しています。

- グラフィック・モードでの次のようなインストール:

- Enterprise Manager Cloud Controlソフトウェアのみをインストールして後で構成

- 共有Oracleホームを使用するOracle Management Agent

- 拡張インストール・オプションを使用したアプリケーションの依存性とパフォーマンス(ADP)

- 拡張インストール・オプションを使用したJVM診断(JVMD)

- サイレント・モードでの次のようなインストール:

- Enterprise Manager Cloud Control

- Enterprise Manager Cloud Controlソフトウェアのみをインストールして後で構成

- 追加のOracle Management Service

- Oracle Management Agent

- Oracle Management Agentソフトウェアのみをインストールして後で構成

- 共有Oracleホームを使用するOracle Management Agent

- グラフィック・モードおよびサイレント・モードでのOracle Management Agentのクローニング

- 拡張インストール・タスク(ファイアウォールの構成、Enterprise Managerデプロイメントのサイジング、BI Publisherの統合など)の構成

- グラフィック・モードおよびサイレント・モードでのEnterprise Manager Cloud ControlおよびOracle Management Agentの削除

『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』では、次の手順については説明していません。これらの手順については、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明しています。

- グラフィック・モードでのEnterprise Manager Cloud Controlのインストール

- グラフィック・モードでの追加のOracle Management Serviceのインストール

- グラフィック・モードでのOracle Management Agentのインストール

- デフォルトのインストール・オプションを使用したJVM診断およびアプリケーションの依存性とパフォーマンスのインストール

また、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』では、既存のEnterprise Managerシステムのアップグレード手順については説明していません。アップグレード手順については、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』で説明しています。

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

オラクル社のアクセシビリティについての詳細情報は、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 Enterprise Manager Cloud Control管理者ガイド』

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

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

Enterprise Managerには詳細なオンライン・ヘルプも用意されています。Grid Controlの各ページの右上にある「ヘルプ」をクリックすると、オンライン・ヘルプ・ウィンドウが表示されます。

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

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

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

この章では、最新のリビジョン(B65085-14)および『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』(本マニュアル)の以前のすべてのリビジョンで反映された変更を列挙しています。最新のリビジョン(B65085-14)とはOTNに公開されている現在のリビジョンであり、最新のリビジョンには以前のリビジョンで反映されたすべての変更が常に含まれていることに留意してください。

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

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

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

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

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

部、章または項番号

変更内容の説明

10.3項、10.17項

ファイアウォール内でのICMP (0)エコー・リプライおよびICMP (8)エコー・リクエストの許可について説明します。

Solaris x86-64 5.12への参照を削除。

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

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

E24089-41で反映された変更

部、章または項番号

変更内容の説明

6.2項

Unixベースの特定のオペレーティング・システムで実行されるホストに管理エージェントをインストールする場合、事前にそのホストにパッチ20802003を適用する必要があるという説明が追加されました。

E24089-40で反映された変更

部、章または項番号

変更内容の説明

6.2項、7.2項、8.2項

Solaris 5.10 Update 9へのインストールに関する説明が追加されました。

E24089-39で反映された変更

部、章または項番号

変更内容の説明

3.2項、4.2項

インストールの開始前に高可用性および障害時リカバリの詳細を確認することに関する説明が追加されました。

E24089-38で反映された変更

部、章または項番号

変更内容の説明

第2.1.5.5項

インストール中に指定するデータベースの詳細がOracleにより提供されるデータベース・テンプレートを使用して事前構成されたOracle Management Repositoryがすでに含まれているデータベース・インスタンスで構成される場合にソフトウェア更新を自動的に適用できない点を強調するためにこの項が導入されました。

第2.1.5.7項

事前構成されたOracle Management Repositoryがすでに存在するデータベースに対して、自動更新がそのようなデータベースで動作しないためにソフトウェア更新を手動でダウンロードして適用する必要があることを強調するために注意を追加しました。

第6.2項、第6.4項

Oracle Linux 7 (64ビット)またはRed Hat Enterprise Linux 7 (64ビット)で実行されているホストに管理エージェントをインストールする前にデプロイする必要があるパッチを示す点を追加しました。

E24089-37で反映された変更

部、章または項番号

変更内容の説明

第20.3項

BI Publisherサーバーを追加する場合のクリティカルの要件を指定する注意。

E24089-36で反映された変更

部、章または項番号

変更内容の説明

第18.4.5項

シンボリック・リンクが追加のOMSインストールでサポートされないことを明確化しました。

いくつかの他の項および章

テークホルダーから推奨されたマイナーな変更を反映しました。

B65085-12で反映された変更

部、章または項番号

変更内容の説明

第5章

手順(7)と手順(12)を追加しました。他のいくつかの手順にも、追加のOMSが別名ホスト名にインストールされる場合に実行する必要があることを追加しています。

E24089-34に追加された変更内容

部、章または項番号

変更内容の説明

第2章

HAおよび非HA環境へのOMSインストールの場合に、中央インベントリを保持する場所および方法を明確にするための注意を追加。

表6-1、表7-1および表8-1

中央インベントリが共有の場所に存在可能であることを示しているリスト項目(中央インベントリの不可欠な要件の一部)を削除。中央インベントリは、スタンドアロン、集中、共有、またはクローニングされた管理エージェント用の共有場所には存在できません。

第22章

ホストから管理エージェントを削除してから同じホストに新しい管理エージェントをインストールする際に、ターゲットの履歴情報の消失を回避する方法についての注意を追加。

第18章

ACFSレプリケーションを使用して障害時リカバリ・ソリューションを実装する手順を追加。

付録I、第19章

例の訂正および手順の軽微な変更。

E24089-33で反映された変更

部、章または項番号

変更内容の説明

第10章

以前のリビジョンに記載されていた、第10章の追加構成タスクの実行に関する説明を削除(この章の内容が他のマニュアルにも記載されていたため)。

E24089-32で反映された変更

部、章または項番号

変更内容の説明

第7.2項

中央エージェントをソース管理エージェントとしてクローニングに使用しないことに関する情報を追加。

E24089-30で反映された変更

部、章または項番号

変更内容の説明

第I部

本リリースではこの箇所を新規に追加。以前、この部はEnterprise Managerの管理ガイドに含まれていましたが、現在はこのガイドに統合されています。

第6.4項

OMSホストがMicrosoft Windowsで実行しており、OMSソフトウェアがC:\以外のドライブにインストールされていた場合に、SCRATCH_PATH変数を設定することに関する情報を追加。

第I部

スタート・ガイド

この部では、Enterprise Manager Cloud Controlソフトウェアを入手する方法と、Enterprise Manager Cloud Controlの使用を開始する前に知っておく必要のあるいくつかの重要な概念について説明します。この部は、次の章で構成されています。

- 第1章「ソフトウェアの入手」

- 第2章「基本の理解」

1 ソフトウェアの入手

この章では、Enterprise Manager Cloud ControlソフトウェアおよびOracle Management Agentソフトウェアを入手する方法について説明します。この章の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Controlの利用可能なリリース

- Enterprise Manager Cloud Controlソフトウェアの入手

- Oracle Management Agentソフトウェアの入手

1.1 Enterprise Manager Cloud Controlの利用可能なリリース

表1-1に、これまでにリリースされたEnterprise Manager Cloud Controlを示します。

表1-1 Enterprise Manager Cloud Controlのリリース

リリース番号

リリース・タイプ

リリース日

実装方法

説明

(推奨)

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

パッチ・セット3

2014年5月

- 12cリリース4 (12.1.0.4)の新規インストール

- 12cリリース3 (12.1.0.3) ((12.1.0.3)または(12.1.0.3)プラグイン・アップデート1のいずれか)からのアップグレード

- 12cリリース2 (12.1.0.2) ((12.1.0.2)または(12.1.0.2)プラグイン・アップデート1のいずれか)からのアップグレード

- 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)からのアップグレード

複数の不具合修正、拡張機能、新機能が含まれているパッチ・セット。

Oracle Enterprise Manager Cloud Control 12cリリース3プラグイン・アップデート1 (12.1.0.3)

プラグイン・アップデート1

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

2013年10月

- 12cリリース3 (12.1.0.3)の新規インストール

- 12cリリース2 (12.1.0.2) ((12.1.0.2)パッチ・セット1または(12.1.0.2)プラグイン・アップデート1)からのアップグレード

- 12cリリース1 (12.1.0.1) (バンドル・パッチ1適用済のみ)からのアップグレード

- 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)からのアップグレード

2013年10月にリリースされた新規プラグインおよび更新済プラグイン・バージョンで更新された12cリリース3 (12.1.0.3)のソフトウェア・バイナリが含まれます。

ただし、12cリリース3 (12.1.0.3)のソフトウェア・バイナリは、変更されておらず、2013年10月にリリースされた新規プラグインおよび更新済プラグイン・バージョンへの統合以外は行われていません。管理エージェントのソフトウェア・バイナリも変更されていません。これは、基本的にリリースであり、パッチ・セットやパッチではありません。

このリリースに統合されているプラグインの一覧を確認するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド12cリリース3 (12.1.0.3)』の「スタート・ガイド」の章のこのリリースに統合されているプラグインのリストに関する項を参照してください。このガイドは、次のURLのEnterprise Managerドキュメント・ライブラリから入手できます。

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

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

パッチ・セット2

2013年6月

- 12cリリース3 (12.1.0.3)の新規インストール

- 12cリリース2 (12.1.0.2) ((12.1.0.2)または(12.1.0.2)プラグイン・アップデート1のいずれか)からのアップグレード

- 12cリリース1 (12.1.0.1) (バンドル・パッチ1適用済のみ)からのアップグレード

- 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)からのアップグレード

複数の不具合修正、拡張機能、新機能が含まれているパッチ・セット。

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

プラグイン・アップデート1

(2013年2月にリリースされたプラグインが含まれるEnterprise Manager Cloud Control 12cリリース2 (12.1.0.2))

2013年2月

- 12cリリース2 (12.1.0.2)の新規インストール

- 12cリリース1 (12.1.0.1) (バンドル・パッチ1を適用または未適用)からのアップグレード

- 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)からのアップグレード

2013年2月にリリースされた新規プラグインおよび更新済プラグイン・バージョンで更新された12cリリース2 (12.1.0.2)のソフトウェア・バイナリが含まれます。

ただし、12cリリース2 (12.1.0.2)のソフトウェア・バイナリは変更されておらず、2013年2月にリリースされた新規プラグインおよび更新済プラグイン・バージョンへの統合以外は行われていません。管理エージェントのソフトウェア・バイナリも変更されていません。これは、基本的にリリースであり、パッチ・セットやパッチではありません。

このリリースに統合されているプラグインの一覧を確認するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド 12c リリース2 (12.1.0.2)』の「スタート・ガイド」の章のこのリリースに統合されているプラグインのリストに関する項を参照してください。このガイドは、次のURLのEnterprise Managerドキュメント・ライブラリから入手できます。

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

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

パッチ・セット1

2012年8月

- 12cリリース2 (12.1.0.2)の新規インストール

- 12cリリース1 (12.1.0.1) (バンドル・パッチ1を適用または未適用)からのアップグレード

- 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)からのアップグレード

複数の不具合修正、拡張機能、新機能が含まれているパッチ・セット。

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)

バンドル・パッチ1

2012年1月

- バンドル・パッチ1を含む12cリリース1 (12.1.0.1)の新規インストール

- 基本リリース(12cリリース1 (12.1.0.1))へのパッチ適用

- 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)からのアップグレード

複数の不具合修正および移植されたプラットフォームのサポートを含むバンドル・パッチ。

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)

基本リリース

2011年10月

- 12cリリース1 (12.1.0.1)の新規インストール

- 10gリリース5 (10.2.0.5)、11gリリース1 (11.1.0.1)からのアップグレード

12cの最初のリリース。

注意:
これらのリリースおよびサポートしているプラットフォームの詳細は、Enterprise Manager Cloud Controlの動作保証マトリックスにアクセスしてください。このマトリックスにアクセスする手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

1.2 Enterprise Manager Cloud Controlソフトウェアの入手

Enterprise Manager Cloud Controlソフトウェアは、製品DVDまたはOracle Technology Network (OTN) Webサイトから入手できます。この項では、これらのソースとその入手方法について説明します。

- DVDからEnterprise Manager Cloud Controlソフトウェアにアクセスする方法

- Oracle Technology Networkからソフトウェアを入手する方法

1.2.1 DVDからEnterprise Manager Cloud Controlソフトウェアにアクセスする方法

Enterprise Manager Cloud Controlソフトウェアは、オラクル社のサービス統括責任者または販売代理店を通して入手可能な製品DVDから取得できます。このソフトウェアは、オペレーティング・システムに応じて1枚または複数のDVDに収録されています。

内容は次のとおりです。

- DVDからソフトウェアへのアクセス

- DVDのマウント・ポイントの設定

1.2.1.1 DVDからソフトウェアへのアクセス

ソフトウェアが1枚のDVDに収録されている場合は、そのDVDをDVDドライブに挿入し、手動でEnterprise Manager Cloud Controlインストール・ウィザードを実行します。

ソフトウェアが複数のDVDに収録されている場合は、アーカイブされているソフトウェアを各DVDからローカル・ディスク内にコピーします。アーカイブされている各ファイルの内容を同じ場所に抽出します。Enterprise Manager Cloud Controlインストール・ウィザードを起動します。

たとえば、12cリリース4 (12.1.0.4)では、主に次のLinux x86およびx86_64用の3枚のDVDを配布しています。

- DVD1。em12104_linux_disk1of3.zipという名前のZIPファイルが含まれています。

- DVD2。em12104_linux_disk2of3.zipという名前のZIPファイルが含まれています。

- DVD3。em12104_linux_disk3of3.zipという名前のZIPファイルが含まれています。

この場合、3枚のZIPファイルをローカル・ディスク内(/tempなど)にコピーし、その内容を同じ場所に抽出します。内容を別の場所に抽出すると、インストールに失敗します。

$ cp -r em12104_linux_disk1of3.zip /temp

$ cp -r em12104_linux_disk2of3.zip /temp

$ cp -r em12104_linux_disk3of3.zip /temp

$ cd /temp

$ unzip em12104_linux_disk1of3.zip

$ unzip em12104_linux_disk2of3.zip

$ unzip em12104_linux_disk3of3.zip

注意:
Enterprise Manager Cloud Controlインストール・ウィザードの詳細は、第2.1.2項を参照してください。

1.2.1.2 DVDのマウント・ポイントの設定

共有DVDドライブからDVDにアクセスする場合、DVDドライブのマウント・ポイントを設定します。

ほとんどのLinuxオペレーティング・システムでは、DVDをDVDドライブに挿入するとディスクが自動的にマウントされます。ただし、一部のLinuxオペレーティング・システムでは、ディスクを手動でマウントする必要があることがあります。ディスクが自動的にマウントされるかどうかを確認し、自動的にマウントされない場合はディスクを手動でマウントするには、次の手順を実行します。

1. DVDをディスク・ドライブに挿入します。

2. ディスクが自動的にマウントされるかどうかを確認するには、次のコマンドを実行します。

- Red Hat Enterprise Linuxの場合:
# ls /mnt/cdrom

- SUSE Linux Enterprise Serverの場合:
# ls /media/cdrom

3. 手順(2)のコマンドによりディスクの内容が表示されない場合は、次のコマンドを実行します。

- Red Hat Enterprise Linuxの場合:
# mount -t nfs <host name>:/mnt/<full path to the dvdrom>

- SUSE Linux Enterprise Serverの場合:
# mount -t nfs <host name>:/media/<full path to the dvdrom>

ほとんどのAIXオペレーティング・システムでは、DVDをDVDドライブに挿入するとディスクが自動的にマウントされます。ただし、一部のAIXオペレーティング・システムでは、ディスクを手動でマウントする必要があることがあります。ディスクが自動的にマウントされず、手動でマウントする場合、次の手順に従います。

1. 次のコマンドを実行して、ユーザーをrootユーザーに切り替えます。
$ su -root

2. ディスクをドライブに挿入します。

注意:
必要に応じて、次のコマンドを入力して、現在マウントされているディスクを取り出し、ドライブから取り除きます。
# /usr/sbin/umount /<SD_DVD>

3. 次のコマンドを入力します。
# /usr/sbin/mount -rv cdrfs /dev/cd0 /SD_DVD

このコマンド例の/SD_DVDはディスク・マウント・ポイント・ディレクトリで、/dev/cd0はディスク・デバイスのデバイス名です。

4. ディスクの場所を指定するように要求されたら、ディスク・マウント・ポイント・ディレクトリのパスを指定します。たとえば、/SD_DVDのように指定します。

1.2.2 Oracle Technology Networkからソフトウェアを入手する方法

Enterprise Manager Cloud Controlソフトウェアは、OTNから入手できます。OTNで入手可能なソフトウェアは、Info-ZIPの移植性の高いZIPユーティリティを使用してアーカイブされています。ソフトウェアは、ZIPファイルに収録されています。ソフトウェアをダウンロードした後、ファイルを抽出するためにUNZIPユーティリティが必要になります。

内容は次のとおりです。

- Enterprise Manager Cloud Controlソフトウェアのダウンロード

- Enterprise Manager Zipファイルのファイル・サイズの確認

- Enterprise Manager Zipファイルの内容の抽出

- Enterprise Manager Cloud Controlソフトウェア・リリースの説明の確認

- プラットフォーム情報の確認

1.2.2.1 Enterprise Manager Cloud Controlソフトウェアのダウンロード

OTNからEnterprise Manager Cloud Controlソフトウェアをダウンロードするには、次のURLにアクセスします。

http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html

ソフトウェアは、ZIPファイルに収録されています。ZIPファイルをローカル・ディスク上の共通の場所にダウンロードします。

1.2.2.2 Enterprise Manager Zipファイルのファイル・サイズの確認

ZIPファイルのダウンロード後、次の手順を実行します。

1. cksumコマンドをZIPファイルに対して実行し、ダウンロードしたソフトウェアのファイル・チェックサムが、OTNで表示されているファイル・チェックサムと同じであるかどうかを確認します。
たとえば、12cリリース4 (12.1.0.4)には、次のZIPファイルの形式がリリースされています。

em12104_<platform>_diskNofM.zip (<value> bytes) (cksum - <value>)

ここでは、<platform>はオペレーティング・システム、NはZIPファイル番号、MはダウンロードできるZIPファイルの総数を指しています。たとえば、em12104_linux_disk1of3.zip、em12104_linux_disk2of3.zip、em12104_linux_disk3of3.zipなどです。

(cksum - <value>)の値が、確認する必要のあるファイル・チェックサムです。最初のZIPファイルのチェックサムを確認するには、次のコマンドを実行します。

$ cksum em12_<platform>_diskNofM.zip

次に例を示します。

$ cksum em12_linux_disk1of3.zip

2. ZIPファイルの内容を、1つのディレクトリに展開します。このディレクトリに移動して、次のファイルがあることを確認します。

[a@adcxxxxxxx Disk1]$ ls
install  libskgxn  plugins            response      stage   WT.zip
jdk      oms       runInstaller       wls                  bipruntime

1.2.2.3 Enterprise Manager Zipファイルの内容の抽出

アーカイブは適切なプラットフォーム上で解凍する必要があります。たとえば、Linux x86オペレーティング・システム用のソフトウェアをダウンロードする場合は、Linux x86オペレーティング・システムでファイルを解凍する必要があります。Microsoft Windowsコンピュータでファイルを解凍してから、ステージ領域をLinuxコンピュータに移動すると、ステージング領域のファイルが破損します。これは、Linuxファイル名の大/小文字の区別または許可ビットがMicrosoft Windowsでは保持されないためです。

1つのZIPファイルをダウンロードした場合は、その内容を抽出し、手動でEnterprise Manager Cloud Controlインストール・ウィザードを実行します。

注意:
Enterprise Manager Cloud Controlインストール・ウィザードの詳細は、第2.1.2項を参照してください。

複数のZIPファイルを共通の場所にダウンロードした場合は、すべてのZIPファイルの内容を同じ場所に抽出し、手動でEnterprise Manager Cloud Controlインストール・ウィザードを実行します。

警告:

内容を別の場所に抽出すると、インストールに失敗します。

ヒント:
ファイルをDVDに格納する場合は、まずZIPファイルの内容を抽出し、次に抽出したファイルをDVDにコピーします。ZIPファイルをコピーすると、製品をインストールするためにそのZIPファイルの内容を解凍する必要があるので、コピーしないでください。

1.2.2.4 Enterprise Manager Cloud Controlソフトウェア・リリースの説明の確認

最新バージョンをダウンロードしたことを確認するため、ソフトウェア・リリースの詳細を確認します。

1. ソフトウェアのZIPファイルの内容を抽出してから、次の場所に移動し、ソフトウェア・リリースの説明を含むプロパティ・ファイルにアクセスします。
Disk1/install/em/release.properties

2. 最新のソフトウェアであることを保証する次の説明を確認します。
リリース:Oracle Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)

1.2.2.5 プラットフォーム情報の確認

ZIPファイルの内容を抽出した後、次のファイルにアクセスして、プラットフォーム情報を確認します。ここで、<Software_Location>は、DVDマウント・ポイントか、またはZIPファイルの内容を抽出したローカル・ディスク上の場所です。

<Software_Location>/stage/shiphomeproperties.xml

32ビットEnterprise Manager Cloud Controlソフトウェア(Enterprise Manager Grid ControlとOracle Management Agentの両方)は、32ビット・ハードウェア上で実行されている32ビット・オペレーティング・システムにのみインストールできます。同様に、64ビットEnterprise Managerソフトウェアは、64ビット・ハードウェア上で実行されている64ビット・オペレーティング・システムにのみインストールできます。

32ビット・ソフトウェアを64ビット・プラットフォームに、また64ビット・ソフトウェアを32ビット・オペレーティング・システムにインストールしないでください。インストールは先に進みますが、最終的に失敗します。したがって、必ず正しいプラットフォームに正しいソフトウェアをダウンロードして使用してください。

shiphomeproperties.xmlファイルには、次のようなプラットフォーム情報が含まれます。

<?xml version="1.0" standalone="yes" ?>
<ORACLEHOME_INFO>
<ARU_PLATFORM_INFO>
<ARU_ID>46</ARU_ID>
<ARU_ID_DESCRIPTION>Linux x86</ARU_ID_DESCRIPTION>
</ARU_PLATFORM_INFO>
</ORACLEHOME_INFO>

プラットフォーム情報は、<ARU_ID_DESCRIPTION>構文で表示されています。表1-2に、この構文で指定されるプラットフォーム名を一覧表示し、その名前が32ビット・ソフトウェアか64ビット・ソフトウェアのどちらを表すかを示します。

表1-2 プラットフォーム情報の確認

プラットフォーム名

ARU_ID_DESCRIPTIONで指定されたプラットフォーム

32ビット/64ビット

Linux x86

Linux x86

32ビット

Microsoft Windows (32ビット)

Win 32

32ビット

Microsoft Windows (64-bit AMD64)

win 64

64ビット

Microsoft Windows (64-bit IA)

Windows Itanium

64ビット

Solaris Operating System (SPARC 64ビット)

Solaris

64ビット

HPUX PA-RISC (64ビット)

HPUNIX

64ビット

AIX

AIX

64ビット

HP_IA64

HPI

64ビット

Linux x86-64

Linux AMD

64ビット

linux_ia64

Linux Itanium

64ビット

IBM PowerベースのLinux

Linux PPC

64ビット

linux_zseries64

zLinux

64ビット

HP Tru64 UNIX

Decunix

64ビット

Solaris Operating System (x86-64)

Solaris AMD64

64ビット

Solaris Operating System (x86)

Solaris AMD32

32ビット

1.3 Oracle Management Agentソフトウェアの入手

Oracle Management Agent (管理エージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントの1つであるため、そのソフトウェアはEnterprise Manager Cloud Controlソフトウェアの一部です。Enterprise Manager Cloud Controlをインストールすると、インストール・ウィザードにより自動的に管理エージェントがインストールされます。

追加の管理エージェントは、Enterprise Manager Cloud Controlコンソール(Cloud Controlコンソール)に組み込まれたホスト・ターゲットの追加ウィザードを使用すればインストールできます。ウィザードでは、OMSホームにすでに存在する管理エージェント・ソフトウェアを使用します。

ただし、OMSホームにすでに存在する管理エージェント・ソフトウェアは常に、OMSが実行されているバージョンおよびプラットフォーム用のものです。たとえば、OMSがOracle Management Service 12cであり、Linuxプラットフォーム上で実行されている場合、この場所に存在する管理エージェント・ソフトウェアもLinuxプラットフォーム用のものです。

OMSが稼働しているプラットフォームとは別のプラットフォーム用の管理エージェントをインストールする場合、Cloud Controlコンソールに組み込まれている自己更新コンソールを使用して、必ずそのソフトウェアをダウンロードしてください。

自己更新の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。ソフトウェアのダウンロード手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のCloud Controlの更新に関する章を参照してください。

注意:
12cリリースX (12.1.0.X)用の管理エージェント・ソフトウェアはOTNでは入手できないため、自己更新コンソールを使用することがこのソフトウェアをダウンロードする唯一の方法になります。

2 基本の理解

この章では、Enterprise Manager Cloud Controlの主要な概念を示し、操作を進める前に知っておく必要のあるインストールの重要な側面について説明します。

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

- Enterprise Manager Cloud Controlインストールの基本の理解

- Enterprise ManagerのインストールにおけるOracle WebLogic Server要件の理解

- インストール・ディレクトリの理解

- コンフィギュレーション・アシスタントの理解

- Enterprise Manager Cloud Controlをインストールする前の前提条件チェックの理解

- Enterprise Manager Cloud Controlの制限事項の理解

- 起動スクリプトの理解

- その他の概念の理解

2.1 Enterprise Manager Cloud Controlインストールの基本の理解

この項では、インストール・プロセスの基本的な側面について説明します。この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Controlにより提供される異なるインストール・モードとは

- Enterprise Manager Cloud Controlインストール・ウィザードとは

- Enterprise Manager Cloud Controlインストール・ウィザードにより提供されるインストール・タイプとは

- Oracle Configuration Managerとは

- Enterprise Manager Cloud Controlソフトウェア更新とは

- 詳細構成のEnterprise Manager Cloud Controlのデプロイメント・サイズとは

- ホスト・ターゲットの追加ウィザードとは

- プラグインとは

- 管理サービスの追加デプロイメント・プロシージャとは

- インストールに使用されるポート

- Oracle Management Repositoryの構成中に作成されるデータ・ファイル

- Oracle Management Repositoryの構成中に作成されるデータ・ファイルの削除方法

- Enterprise Managerのグローバリゼーション・サポート

2.1.1 Enterprise Manager Cloud Controlにより提供される異なるインストール・モードとは

Enterprise Manager Cloud Controlまたはそのコア・コンポーネントは、インタラクティブなグラフィック・モードまたはサイレント・モードのいずれかでインストールできます。

グラフィック・モード

グラフィック・モードは、Javaベースのインストール・ウィザードや、Enterprise Manager Cloud Controlコンソールに組み込まれてEnterprise Manager Cloud Controlコンソールからアクセスするブラウザベースのアプリケーションを使用するGUI方式です。インストール・プロセス全体がガイドされ、インストールの詳細は質問画面を使用して取得されるため、この方式は初めてインストールする場合に最適です。

サイレント・モード

サイレント方式では、Oracle提供のレスポンス・ファイルを使用して、インストールに必要なすべての情報が取得されます。この方式のほうが簡単で時間もかかりませんが、インストール・ウィザードの質問画面を使用しなくてもレスポンス・ファイルにインストールの詳細を指定できるだけのインストール・プロセスに関する知識が必要となります。

このいずれのモードでも、ソフトウェアのみのインストールを実行できます。ソフトウェアのみのインストールは、インストールを構成せずにEnterprise Manager Cloud Controlまたは管理エージェントのソフトウェア・バイナリのみをインストールする方式です。この方法は、ソフトウェアをインストールして構成は後で行う場合に適しています。

2.1.2 Enterprise Manager Cloud Controlインストール・ウィザードとは

Enterprise Manager Cloud Controlインストール・ウィザードは、Enterprise Manager Cloud Controlをグラフィック・モードでインストールまたはアップグレードするのに役立つJavaベースのウィザードです。初めてEnterprise Manager Cloud Controlまたはそのコア・コンポーネントをインストールする場合は、このインストール・ウィザードを使用することを強くお薦めします。

注意:
UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

図2-1は、インストール・ウィザードの主要な要素を示しています。

図2-1 Enterprise Manager Cloud Controlインストール・ウィザード

2.1.3 Enterprise Manager Cloud Controlインストール・ウィザードにより提供されるインストール・タイプとは

Enterprise Manager Cloud Controlインストール・ウィザードには、次のインストール・タイプがあります。

- Enterprise Managerシステムの新規作成

- 既存のEnterprise Managerシステムのアップグレード

- ソフトウェアのみインストール

2.1.3.1 Enterprise Managerシステムの新規作成

このインストール・タイプでは、新規のEnterprise Manager Cloud Controlシステムを単純構成または詳細構成のいずれかの設定でインストールできます。単純および詳細インストール・タイプについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

単純および詳細インストール・タイプのインストール内容は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
Enterprise Manager Cloud Controlを評価またはデモ目的のためにインストールする場合は、簡易インストール・タイプを使用してください。

2.1.3.2 既存のEnterprise Managerシステムのアップグレード

このインストール・タイプを使用すると、次のソフトウェアをEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)にアップグレードできます。

- Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3) [(12.1.0.3)または(12.1.0.3)プラグイン・アップデート1]

- Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2) [(12.1.0.2)または(12.1.0.2)プラグイン・アップデート1]

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

- Enterprise Manager 10g Grid Controlリリース5 (10.2.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リリース 3 (12.1.0.3)または12cリリース2 (12.1.0.2)をアップグレードする場合は、1システムのアップグレードのアプローチのみ選択できます。

- 1システムのアップグレード: 旧リリースのEnterprise Managerを実行しているホストでEnterprise Manager Cloud Controlにアップグレードできます。既存のOracleデータベース自体の管理リポジトリもアップグレードされます。アップグレードが同じホスト上で行われるため、ある程度の停止時間が発生します。

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

注意:
これらのアップグレード・オプションの詳細は、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

2.1.3.3 ソフトウェアのみインストール

このインストール・タイプでは、ある時点でEnterprise Manager Cloud Controlのソフトウェア・バイナリのみをインストールし、後から構成できます。

このアプローチを使用すれば、インストール・プロセスをインストール・フェーズと構成フェーズの2つフェーズに大別できます。当然のことながら、インストール・フェーズは、バイナリのコピーのみなので、構成フェーズに比べて時間はかかりません。

インストール・フェーズでインストールされる内容および構成フェーズで構成される内容の詳細は、第4.1項を参照してください。

2.1.4 Oracle Configuration Managerとは

Enterprise Manager Cloud Controlとともに、Oracle Configuration Managerを有効化することを選択できます。あるいは、Enterprise Manager Cloud Controlをインストールした後に有効化することもできます。

Oracle Configuration Managerでは、自動的に一定の間隔で環境から構成情報を収集し、Oracleリポジトリにアップロードします。これにより、Oracleは環境に関する最新情報を維持し、セキュリティの脆弱性を識別し、サポートの問題を迅速に診断し、ソリューションの一貫性を高めることができます。

ただし、送信時に問題が発生した場合の連絡先となる現地担当者名を除き、企業や個人の情報が収集およびアップロードされることはありません。オラクル社は、収集されたすべての情報が機密事項として厳密に保護され、いかなる場合にも第三者と共有されないことを保証しています。

構成情報が自動的に収集されてMy Oracle Supportにアップロードされるように、インストール・ウィザードの実行に使用するホストをインターネットに接続することをお薦めします。

インストール・ウィザードの実行に使用するホストがインターネットに接続されている場合は、インストール・ウィザードの「My Oracle Supportの詳細」画面で、My Oracle Supportユーザー名(または電子メール・アドレス)およびパスワードを入力します。

あるいは、電子メール・アドレスのみを入力し、その他のフィールドは空白のままにしておきます。インストールの完了後、手動で構成情報を収集してMy Oracle Supportにアップロードします。構成情報を手動で収集してアップロードする方法の詳細は、第2.1.4.1項に示された手順を参照してください。

Enterprise Manager Cloud Controlのインストール後、Oracle Configuration Managerを有効にする場合は、第2.1.4.2項を参照してください。

2.1.4.1 手動による構成情報の収集およびアップロード

構成情報を手動で収集するには、次の手順を実行します。

1. OMSホームに移動し、次のコマンドを実行します。
$<OMS_HOME>/ccr/bin/emCCR collect

Oracle Configuration Manager 10.2.7以上の場合、収集された構成情報は/ccr/hosts/state/upload/ocmconfig.jarファイルに格納されます。それより下位のバージョンのOracle Configuration Managerでは、収集された構成情報は/ccr/state/upload/ocmconfig.jarファイルに格納されます。次回に同じコマンドを実行すると、ocmconfig.jarファイルは新しいデータで上書きされます。したがって、ocmconfig.jarファイルは常に1つしか存在しません。

2. ocmconfig.jarファイルをMy Oracle Supportのサービス・リクエストにアップロードします。

3. 管理エージェント・ホームから、手順(1)および手順(2)を繰り返します。

2.1.4.2 Enterprise Manager Cloud Controlインストール後のOracle Configuration Managerの有効化

後でOracle Configuration Managerを有効にするには、次を実行します。

1. 環境変数ORACLE_CONFIG_HOMEをOracle Management Serviceインスタンス・ベース・ディレクトリに設定します。Oracle Management Serviceインスタンス・ベースは、OMSの構成ファイルが作成されるディレクトリです。

- bash端末で、次のコマンドを実行します。
export ORACLE_CONFIG_HOME=<absolute_path_to_gc_inst>

- 他の端末で、次のコマンドを実行します。
setenv ORACLE_CONFIG_HOME <absolute_path_to_gc_inst>

注意:
Oracle Management Serviceインスタンス・ベース・ディレクトリの詳細は、第2.3.3項を参照してください。

2. OMSホームから、次のコマンドを実行します。
$<OMS_HOME>/ccr/bin/setupCCR

2.1.5 Enterprise Manager Cloud Controlソフトウェア更新とは

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

- ソフトウェア更新とは

- ソフトウェア更新機能の動作方法

- ダウンロードおよび適用するソフトウェアの更新のタイプ

- ソフトウェア更新によって修正された不具合の確認方法

- Oracle Management Repositoryが事前構成されたデータベースでもソフトウェア更新が自動的に適用されるか

- ソフトウェア更新のダウンロード方法

- インストールまたはアップグレード後にこれらのパッチをダウンロードおよび適用できるかどうか

- 適用されているパッチを識別する方法

2.1.5.1 ソフトウェア更新とは

ソフトウェア更新は、Enterprise Manager Cloud Controlインストール・ウィザードに組み込まれた機能です。この機能は、インストーラの「ソフトウェアの更新」画面に表示され、これによりEnterprise Manager Cloud Controlのインストールまたはアップグレード中に最新の推奨パッチを自動的にダウンロードしてデプロイできます。

この方法では、オラクル社によってリリースされるパッチの手動チェックを継続する必要はありません。正常なインストールおよびアップグレードのためにインストーラによって必要とされるすべてのパッチが、My Oracle Supportで検出されてダウンロードされ、インストールまたはアップグレード中に適用されるため、既知の問題や潜在的な失敗が減少します。

注意:
「ソフトウェア更新」画面から入手可能なパッチは、My Oracle Supportからではなく「ソフトウェア更新」画面からのみダウンロードする必要があります。

2.1.5.2 ソフトウェア更新機能の動作方法

ソフトウェア更新機能によってMy Oracle Supportに接続され、基本的にpatch.xml.というファイルで構成されるパッチが最初にダウンロードされます。インストーラによってpatch.xmlファイルが解析され、updatesというディレクトリが作成されて、必要なすべての更新がダウンロードされます。updatesディレクトリには次のサブディレクトリが含まれます。

- updates/agent
セントラル・エージェント(OMSとともにインストールされる管理エージェント)にのみ関連するパッチが含まれます。

- updates/oms
OMSに関連するパッチが含まれます。

- updates/metadata
サブディレクトリが含まれており、その中に、ダウンロードする必要があるすべての更新と、それらを適用する必要があるOracleホームを決定するpatch.xmlがあります。

注意:
すべてのソフトウェア更新は、My Oracle Supportからでなく、インストーラの「ソフトウェアの更新」画面でのみダウンロードおよび適用される必要があります。

2.1.5.3 ダウンロードおよび適用するソフトウェアの更新のタイプ

この機能を使用して適用できる更新の異なるタイプは、次のとおりです。

- OUI/Opatchの更新
最新のOUI/Opatchバージョンまたはその更新が含まれます。新しいバージョンのインストーラがダウンロードされると、OUIは再起動され、最新のバージョンがダウンロードされた場所から実行されます。

- 前提条件の更新
Enterprise Manager Cloud Controlのリリース後にレポートされた問題に対応してリリースされた新しい前提条件チェック関連の更新が含まれます。これにより、OUIでは、常に前提条件チェックの最新セットが実行されるため、インストールまたはアップグレード作業がよりスムーズに進みます。

- EMインストーラの更新
OUIの問題を修正する更新が含まれます(基本的には、その適用後にOUIの自動再起動が発生する可能性の高いJavaコードの変更です)。

- 個別パッチの更新
DSTパッチ、パフォーマンス関連パッチなどのパッチが含まれます。これらは、自動的に検出、ダウンロードおよび適用されます。

- パッチ・セット更新
バグの修正、既存の機能の強化、また時には新しい機能の導入を行う複数のパッチ更新を含みます。

2.1.5.4 ソフトウェア更新によって修正された不具合の確認方法

「ソフトウェアの更新」画面からダウンロードしたソフトウェア更新によって修正された不具合または問題を確認するには、My Oracle Supportのノート1099123.1を参照してください。

2.1.5.5 Oracle Management Repositoryが事前構成されたデータベースでもソフトウェア更新が自動的に適用されるか

インストール中に、Oracle Management Repositoryを構成できるデータベースの詳細を求められます。Oracleにより提供されるデータベース・テンプレートを使用して事前構成されたOracle Management Repositoryがすでに存在するデータベースの詳細を提供する場合、選択されたソフトウェア更新は自動的に適用されません。その場合、インストール後にデータベースのソフトウェア更新を手動でダウンロードして適用する必要があります。

2.1.5.6 ソフトウェア更新のダウンロード方法

次のいずれかの方法でソフトウェア更新をダウンロードできます。

- ユーザーによるダウンロード(オフライン・モード): Enterprise Managerをインストールするホストに、My Oracle Supportに接続するインターネット接続がない場合に、このオプションを使用します。
ソフトウェア更新をダウンロードするには、次の手順に従います。

注意:
ソフトウェア更新は、インストーラを使用してダウンロードおよび適用してください。My Oracle Supportから直接ダウンロードしないでください。

1. インターネットが接続されているホスト上で、次の方法で-downloadUpdates引数を指定して、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。この引数を使用すると、ソフトウェア更新のダウンロード専用にインストール・ウィザードが起動されます。このコマンドは、既存のOMSホームやデータベース・ホームからではなく、ダウンロードしたEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェアの場所から実行してください。
<EM_12.1.0.4_Software_Extracted_Location/Disk1>./runInstaller -downloadUpdates

注意:

- Microsoft Windowsの場合は、setup.exe -downloadUpdatesを実行します。

- これらの更新は必ず、インストーラを起動して製品をインストールするホストと同じオペレーティング・システム上で実行する(インターネット接続のある)別のホストにダウンロードしてください。たとえば、Linux上にインストールする場合には、これらの更新をダウンロードするインターネット接続のあるホストもLinux上で実行していることを確認してください。同様に、Microsoft Windowsにインストールする場合には、必ずMicrosoft Windowsで実行する別のホストにパッチをダウンロードしてください。

Enterprise Manager Cloud Controlインストール・ウィザードでは2つの画面のみが表示され、そのタイトルが左のメニューに表示されます。

2. 「ソフトウェアの更新」画面で、My Oracle Supportのアカウント・ユーザー名とパスワードを入力し、「更新の検索」をクリックします。インストール・ウィザードによって、「更新をダウンロード中」ダイアログが表示され、/tmp/OraInstall<timestamp>/updatesにソフトウェア更新がダウンロードされます。「次へ」をクリックします。
インストール・ウィザードが再起動し、この時点ですべての画面が表示され、そのタイトルが左のメニューに表示されます。インストール・ウィザードは、OMSをインストールするためでなく、ソウフトウェア更新をダウンロードするためにこのホストで起動したため、ここで終了します。

3. OMSをインストールするホストにupdatesディレクトリ全体をコピーします。

注意:
ディレクトリのコピー元のホストと、ディレクトリのコピー先のホストは同じオペレーティング・システム上で実行していることを確認してください。たとえば、Linuxホスト上のディレクトリに更新をダウンロードした場合、その更新は必ず製品をインストールする別のLinuxホストにコピーしてください。異なるオペレーティング・システム間でディレクトリをコピーすることは、インストールについてはお薦めしません。

4. OMSをインストールするホストで、インストール・ウィザードを起動します。

- グラフィック・モード: インストール・ウィザードの「ソフトウェアの更新」画面で、「更新の検索」を選択し、「ローカル・ディレクトリ」を選択します。更新をコピーした場所を入力し、「更新の検索」をクリックします。コンピュータを検索して場所を選択するには、「参照」をクリックします。
たとえば、updatesディレクトリ全体を/u01/home/em/にコピーした場合、/u01/home/em/updatesを選択または入力します。

検索結果がパッチ番号とそれらの詳細とともに表示されたら、パッチ番号をクリックして、そのパッチに関連付けられたReadMeを表示します。それ以外の場合は、「次へ」をクリックします。すべてのパッチは、Enterprise Managerシステムのインストールまたはアップグレード中に、インストーラによって自動的に適用されます。

- サイレント・モード: 「staged」に設定されたINSTALL_UPDATES_SELECTIONパラメータおよび更新を入手可能な場所の絶対パスに設定されたSTAGE_LOCATIONパラメータとともに、レスポンス・ファイルを渡すインストーラを起動します。

注意:
プロキシ・サーバーの設定がある場合には、引数-showProxyを渡してインストール・ウィザードを起動します。たとえばグラフィック・モードで起動する場合、次のようにして起動します。
<Software_Location>/runInstaller -showProxy

- インストール・ウィザードによる自動ダウンロード(オンライン・モード): Enterprise Manager Cloud Controlインストール・ウィザードを使用してMy Oracle Supportに自動的に接続するインターネット接続がある場合、このオプションを使用します。
インターネットが接続されているホスト上で、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。

- グラフィック・モード: インストール・ウィザードの「ソフトウェアの更新」画面で、「更新の検索」を選択し、「My Oracle Support」を選択します。My Oracle Supportのアカウント・ユーザー名とパスワードを入力し、「更新の検索」をクリックします。
検索結果がパッチ番号とそれらの詳細とともに表示されたら、パッチ番号をクリックして、そのパッチに関連付けられたReadMeを表示します。それ以外の場合は、「次へ」をクリックします。すべてのパッチは、Enterprise Managerシステムのインストールまたはアップグレード中に、インストーラによって自動的に適用されます。

- サイレント・モード: 「download」に設定されたINSTALL_UPDATES_SELECTIONパラメータおよびMy Oracle Support資格証明に設定されたMYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATESおよびMYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATESパラメータとともに、レスポンス・ファイルを渡すインストーラを起動します。

2.1.5.7 インストールまたはアップグレード後にこれらのパッチをダウンロードおよび適用できるかどうか

理想的には、ソフトウェア更新は、Enterprise Managerシステムのインストールまたはアップグレード時にのみダウンロードして適用する必要があります。ソフトウェア更新は、インストールまたはアップグレード・プロセスに関する問題を修正するため、Enterprise Managerシステムのインストールまたはアップグレード時に必要になります。

例外は、Oracleにより提供されるデータベース・テンプレートを使用して事前構成されたOracle Management Repositoryがすでに存在するデータベースの詳細を提供する場合のみです。その場合、インストール後にデータベースの更新を手動でダウンロードして適用する必要があります。

2.1.5.8 適用されているパッチを識別する方法

適用されているパッチを識別するには、OMSホームまたは管理エージェント・ホームから次のコマンドを実行します。このコマンドの出力に、すべての適用済パッチがリストされます。

<ORACLE_HOME>/OPatch/opatch lsinventory

2.1.6 詳細構成のEnterprise Manager Cloud Controlのデプロイメント・サイズとは

Enterprise Manager Cloud Controlを詳細構成設定(詳細インストール・タイプ)でインストールする場合、デプロイメント・サイズを選択するオプションが用意されています。このオプションは、グラフィック・モード(Enterprise Manager Cloud Controlのインストール・ウィザード)およびサイレント・モード(レスポンス・ファイル)の両方にあります。

デプロイメント・サイズでは、基本的に、監視予定のターゲット数、予定している管理エージェント数および予定している同時ユーザー・セッション数を指定します。

表2-1に、各デプロイメント・サイズを示します。

表2-1 デプロイメント・サイズ

デプロイメント・サイズ

ターゲット数

管理エージェント数

同時ユーザー・セッション数

小

最大999

最大99

最大10

中

1000から9999

100から999

10から24

大

10,000以上

1000以上

25から50

注意:
接続しているデータベースが、オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリで作成されたデータベース・インスタンスの場合、この画面で選択したデプロイメント・サイズが、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているように、必ずSQLスクリプトを実行したデプロイメント・サイズと一致するようにしてください。そうでない場合には、エラーが発生します。
以前にSQLスクリプトを実行したデプロイメント・サイズとは異なるデプロイメント・サイズを選択する場合、次のいずれかを行います。

- インストーラを最小化し、選択するデプロイメント・サイズのSQLスクリプトを実行してから、この画面に戻り、必要とするデプロイメント・サイズを選択します。各デプロイメント・サイズに対して実行するSQLスクリプトについて理解するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 選択したデプロイメント・サイズをこの画面で選択し、「次へ」をクリックします。エラーが発生した場合には、データベースのパラメータを手動で修正し、この画面に戻ってインストールを続けます。

前提条件チェックは選択内容に関係なく実行されますが、様々なパラメータに設定される値は、選択内容に応じてチェックされます。これらのデプロイメント・サイズおよびそれぞれに設定されているデータベース・パラメータの詳細は、第11章を参照してください。

特定のデプロイメント・サイズを指定してEnterprise Manager Cloud Controlをインストールした後で、ターゲット数、管理エージェント数または同時ユーザー・セッション数を増減することも可能です。ただし、選択したデプロイメント・サイズに適していないレベルまで数量を増やすと、パフォーマンスが低下する可能性があります。そのような場合は、第11章の説明に従い、必要なデプロイメント・サイズに合せてデータベース・パラメータを変更することをお薦めします。

2.1.7 ホスト・ターゲットの追加ウィザードとは

ホスト・ターゲットの追加ウィザード(図2-2)は、Cloud Controlコンソールからアクセスできる、GUIが豊富なアプリケーションで、管理対象外ホストにOracle Management Agentをインストールし、これらをEnterprise Managerシステムの管理対象ホストに変換するために使用されます。

ホスト・ターゲットの追加ウィザードを使用して、次を実行できます。

- 新規管理エージェントのインストール

- 十分にテスト済で事前にパッチが適用されている実行中の既存の管理エージェントのクローニング

- 一元的に共有される既存の管理エージェントから管理エージェントをインストール

図2-2 ホスト・ターゲットの追加ウィザード

ホスト・ターゲットの追加ウィザードは単一の管理エージェントをリモートでインストールするのに使用できますが、このウィザードは、管理エージェントの一括デプロイ、特に、異なるプラットフォームのホストに異なるリリースの管理エージェントを一括デプロイするのに最も適しています。このウィザードには、管理エージェントをインストールするホストを選択できる柔軟性があります。この方法は、1回の操作で複数のホストに管理エージェントをインストールする場合に便利です。

2.1.8 プラグインとは

プラグインは、既存のEnterprise Manager Cloud Controlデプロイにプラグインされて、Enterprise Managerのターゲット管理またはその他の垂直方向の機能を拡張できるモジュールです。

上位レベルで、プラグインにはOMSインスタンスおよび管理エージェントの監視および検出のアーカイブが含まれます。アーカイブには、JavaおよびSQLコード、そしてメタデータが含まれます。

詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

2.1.9 管理サービスの追加デプロイメント・プロシージャとは

デプロイメント・プロシージャは、階層構造になった一連のプロビジョニングまたはパッチ適用のステップを含むプロシージャであり、各ステップには一連の他のステップが含まれることもあります。つまり、特定のライフサイクル管理アクティビティに対して実行する必要があるすべてのタスクのワークフローは、デプロイメント・プロシージャでカプセル化されます。

Enterprise Manager Cloud Controlにはデプロイメント・プロシージャがあり、これらはすべてCloud Controlコンソールからアクセスできます。Enterprise Manager Cloud Controlのインストールのコンテキストに含まれるデプロイメント・プロシージャの1つが、管理サービスの追加デプロイメント・プロシージャです。

管理サービスの追加デプロイメント・プロシージャ(図2-3)は、AdminServerホストで実行中の既存のOMSを使用して追加のOMSのインストールを可能にすることにより、高可用性の要件を満たすのに役立ちます。

図2-3 管理サービスの追加デプロイメント・プロシージャ

簡単に言えば、管理サービスの追加デプロイメント・プロシージャにより、使用環境に追加のOMSインスタンスをインストールできます。デプロイメント・プロシージャにより既存のOMSのクローンが作成され、その構成が接続先ホストにレプリケートされます。

Enterprise Managerの旧リリースでは、このインストール・タイプはEnterprise Managerインストール・ウィザードで提供されました。しかし、Enterprise Manager Cloud Controlリリースの場合、このインストール・タイプはデプロイメント・プロシージャとして提供されます。

デプロイメント・プロシージャの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の追加管理サービスの追加に関する章を参照してください。

2.1.10 インストールに使用されるポート

この項では、Enterprise Manager Cloud Controlのインストール時に使用されるデフォルト・ポートについて説明します。この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Controlインストールに使用されるデフォルト・ポート

- ポートが空いているかどうかを確認する方法

- Enterprise Manager Cloud Controlのインストール中およびインストール後のポートのカスタマイズ方法

- Enterprise Manager Cloud Controlポートのカスタマイズ中の注意事項

2.1.10.1 Enterprise Manager Cloud Controlインストールに使用されるデフォルト・ポート

インストールに使用されるデフォルト・ポートを次に示します。

- Enterprise Manager Cloud Control

アップロード・ポート

コンソール・ポート

HTTPポート

4889
4889が使用できない場合は、4889から4898の範囲で使用可能な最初の空きポートが選択されます。

7788から7798の範囲で使用可能な最初の空きポートが選択されます。

HTTPSポート

1159
1159が使用できない場合、4899から4908の範囲で使用可能な最初の空きポートが選択されます。

7799から7809の範囲で使用可能な最初の空きポートが選択されます。

- Oracle Management Agent
管理エージェント用のデフォルトのアップロード・ポートは、3872です。HTTPとHTTPSの両方に同じポートが使用されます。3872が使用できない場合、1830から1849の範囲で使用可能な最初の空きポートが選択されます。

- 管理サーバー
管理サーバーのデフォルトのHTTPポートは7001です。

管理サーバー用のデフォルトのHTTPSポートは、7101です。7101が使用できない場合、7101から7200の範囲で使用可能な最初の空きポートが選択されます。

- ノード・マネージャ
ノード・マネージャ用のデフォルトのHTTPSポートは、7401です。7401が使用できない場合、7401から7500の範囲で使用可能な最初の空きポートが選択されます。

- 管理対象サーバー
管理対象サーバー用のデフォルトのHTTPポートは、7201です。7201が使用できない場合、7201から7300の範囲で使用可能な最初の空きポートが選択されます。

管理対象サーバー用のデフォルトのHTTPSポートは、7301です。7301が使用できない場合、7301から7400の範囲で使用可能な最初の空きポートが選択されます。

- Oracle Management Repository
Oracle Management Repositoryのデフォルトのポートは1521です。

- JVM診断管理対象サーバー
JVM診断管理対象サーバーのデフォルトのHTTPポートは3800です。

JVM診断管理対象サーバーのデフォルトのHTTPSポートは3801です。

- アプリケーションの依存性とパフォーマンスのRMIレジストリ
アプリケーションの依存性とパフォーマンスのRMIレジストリのデフォルトのポートは51099です。

- アプリケーションの依存性とパフォーマンスのJavaプロバイダ
アプリケーションの依存性とパフォーマンスのJavaプロバイダのデフォルトのポートは5503です。

- アプリケーションの依存性とパフォーマンスのリモート・サービス・コントローラ
アプリケーションの依存性とパフォーマンス・リモート・サービス・コントローラのデフォルトのポートは55000です。

- Real User Experience Insight
Real User Experience InsightのデフォルトのHTTPSポートは443です。

- Oracle BI Publisher
Oracle BI PublisherのデフォルトのHTTPポートは9701です。9701が使用できない場合、9701から9800の範囲で使用可能な最初の空きポートが選択されます。

Oracle BI PublisherのデフォルトのHTTPSポートは9801です。9801が使用できない場合、9701から9900の範囲で使用可能な最初の空きポートが選択されます。

注意:
Oracle BI Publisher 11g (11.1.1.7)はデフォルトでインストールされますが、構成されません。インストール後に構成するには、『Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の手順に従ってください。

2.1.10.2 ポートが空いているかどうかを確認する方法

ポートが空いているかどうかを確認するには、次のコマンドを実行します。

- UNIXの場合:
netstat -an | grep <port no>

- Microsoft Windowsの場合:
netstat -an|findstr <port_no>

2.1.10.3 Enterprise Manager Cloud Controlのインストール中およびインストール後のポートのカスタマイズ方法

Enterprise Manager Cloud Controlには、デフォルト・ポートのかわりにカスタム・ポートを使用できる柔軟性が備わっています。

Enterprise Manager Cloud Controlインストール時のポートのカスタマイズ

警告:

どのポートも1024以下の値に設定しないでください。1024までのポートは、通常、ルート・ユーザー(スーパーユーザー)用に予約されています。そのため、カスタマイズするポートは、必ず1024より大きい値に設定してください。

- グラフィック・モードで(Enterprise Manager Cloud Controlインストール・ウィザードを使用して) Enterprise Manager Cloud Controlをインストールする場合(拡張インストール)、「ポート構成の詳細」画面を使用してカスタム・ポートを入力できます。すでにカスタム・ポートがキャプチャされているstaticports.iniファイルをインポートすることもできます。

- サイレント・モードでEnterprise Manager Cloud Controlをインストールする場合、つまり第I部で説明されているインストール手順を使用する場合は、適切なカスタム・ポートを指定してstaticports.iniファイルを更新します。
staticports.iniファイルは、ソフトウェア・キット(DVD、ダウンロードされたソフトウェアなど)の次の場所にあります。

<software_kit>/response/staticports.ini

Enterprise Manager Cloud Controlインストール後のHTTP/HTTPSコンソール・ポートおよびアップロード・ポートのカスタマイズ

警告:

どのポートも1024以下の値に設定しないでください。1024までのポートは、通常、ルート・ユーザー(スーパーユーザー)用に予約されています。そのため、カスタマイズするポートは、必ず1024より大きい値に設定してください。

Enterprise Manager Cloud Controlをインストールした後で、HTTP/HTTPSコンソール・ポートおよびアップロード・ポートを変更する場合は、次の手順を実行します。

1. OMSを停止します。
$<OMS_HOME>/bin/emctl stop oms -all

2. 表2-2の説明に従って、emomsプロパティのHTTPおよびHTTPSポートを更新します。パラメータ(<http_upload_new>、<https_upload_new>、<http_console_new>および<https_console_new>)の値を指定します。

表2-2 EMOMSプロパティのHTTPおよびHTTPSポートの更新

ポート/プロパティ・タイプ

実行するコマンド

HTTPアップロード・ポート

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.ConsoleServerPort -value <http_upload_new>

HTTPSアップロード・ポート

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.ConsoleServerHTTPSPort -value <https_upload_new>

HTTPコンソール・ポート

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.EMConsoleServerPort -value <http_console_new>

HTTPSコンソール・ポート

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.EMConsoleServerHTTPSPort -value <https_console_new>

3. 次のファイルをバックアップします。
$<OMS_INSTANCE_HOME>/emgc.properties

ファイルのバックアップ後、元のemgc.propertiesファイルを開き、次のパラメータに新しいポート番号を指定します。

EM_UPLOAD_HTTP_PORT=<http_upload_new>
EM_UPLOAD_HTTPS_PORT=<https_upload_new>
EM_CONSOLE_HTTP_PORT=<http_console_new>
EM_CONSOLE_HTTPS_PORT=<https_console_new>

4. 次の場所にあるhttpd.conf、ssl.confおよびhttpd_em.confファイルをバックアップします。
$<WEBTIER_INSTANCE_HOME>/config/OHS/ohs#/

ファイルのバックアップ後、元のファイルを開き、新しいポート番号を指定します。

- httpd.confファイルのListenディレクティブのセクションで、<http_console_orig>を<http_console_new>に置き換えます。

- ssl.confファイルのListenおよびVirtual Hostディレクティブ・セクションで、<https_console_orig>を<https_console_new>に置き換えます。

- httpd_em.confファイルのListenおよびVirtualHostディレクティブ・セクションで、<http_upload_orig>を<http_upload_new>に、<https_upload_orig>を<https_upload_new>に、それぞれ置き換えます。

5. OMSを起動して、ステータスを確認します。
$<OMS_HOME>/bin/emctl start oms

$<OMS_HOME>/bin/emctl status oms -details

6. OMSにサーバー・ロード・バランサ(SLB)が構成済の場合は、SLBプールやモニターなどのポートを更新します。

7. OMSがSSOまたはOAMを使用するように構成されている場合は、SSOまたはOAM構成を再実行します。

8. 次のファイルをバックアップします。
$<AGENT_INSTANCE_HOME>/sysman/config/emd.properties

注意:
OMSと通信しているすべての管理エージェントのemd.propertiesファイルをバックアップします。

ファイルのバックアップ後、元のemd.propertiesファイルを開き、REPOSITORY_URLに記載されているURLを確認します。URLがHTTPS URLの場合は、ポート番号を<https_upload_new>に変更します。URLがHTTP URLの場合は、ポート番号を<http_upload_new>に変更します。

9. 変更したポートを使用するように設定されたEM CLIインスタンスがある場合は、そのインスタンスを再度設定します。これを行うには、EM CLIの各インスタンスからemcli setupまたはemcli statusコマンドを実行し、表示されたEM URLをメモします。
そのポート番号を変更した場合は、次のコマンドを実行します。

emcli setup -url=http(s)://<host>:<new_port#>/em -dir=<dir>....

10. コンソール・ポートの変更後、EMコンソール・サービスのURLを、新しいポート番号で更新する必要があります。ただし、それがSLBのURLで、OMSのURLではない場合、この手順をスキップできます。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. 「ターゲット名の検索」テキスト・ボックスで、EM Console Serviceと入力し検索アイコンをクリックします。

3. 検索結果の表で、EM Console Serviceをクリックします。

4. 「EM Console Service」ページで、「EM Service」メニューから「管理」を選択し、「サービス・テストとビーコン」を選択します。

5. 「サービス・テストとビーコン」ページの「サービス・テスト」表から、「EM Consoleサービス・テスト」を選択して「編集」をクリックします。

6. 「サービス・テストの編集」での操作: 「EM Consoleサービス・テスト」ページの「トランザクション」セクションにある「ステップ」表で、「アクセスのためのログイン」ページを選択します。

7. 「ステップの編集」での操作: 「アクセスのためのログイン」ページの、「リクエスト」セクションの「URL」テキスト・ボックスでURLのポートを変更します。

8. 「続行」をクリックします。

9. 「OK」をクリックします。

10. 「セキュリティ構成」ページで「はい」をクリックします。

2.1.10.4 Enterprise Manager Cloud Controlポートのカスタマイズ中の注意事項

staticports.iniファイル内にエラーがあると、インストール・ウィザードで警告が表示されずにデフォルト・ポートが使用されるため、このファイルを更新するときは細心の注意を払ってください。したがって、staticports.iniファイルの更新前に、次の点を確認してください。

- どのポートも1024以下の値に設定しないでください。1024までのポートは、通常、ルート・ユーザー(スーパーユーザー)用に予約されています。そのため、カスタマイズするポートは、必ず1024より大きい値に設定してください。

- ポートがコンポーネントまたは他のアプリケーションによってすでに使用されている場合は、staticports.iniファイル内にそのポート(使用中のポート)を入力しないでください。そうした場合、関連の構成アシスタントも失敗します。

- 複数のコンポーネントに同じポートを入力した場合、インストールでは前提条件チェック・フェーズの後にエラーが表示されます。インストールを続行する前に、このエラーを修正する必要があります。

- staticports.iniファイル内に構文エラーがある場合(等記号(=)文字が欠落している行がある場合)、インストール・ウィザードではその行が無視されます。このような行で指定されたコンポーネントには、インストール・ウィザードによりデフォルト・ポートが割り当てられます。インストール・ウィザードでは、構文エラーのある行に対する警告は表示されません。

- コンポーネント名のスペルを間違えた場合、インストール・ウィザードではそのコンポーネントにデフォルト・ポートが割り当てられます。ファイル内のコンポーネントの名前の大文字/小文字は区別されます。インストール・ウィザードでは、認識されない名前を含む行に対する警告は表示されません。

- ポート番号に数字以外の値を指定した場合、インストール・ウィザードではその行が無視され、コンポーネントにデフォルトのポート番号が割り当てられます。これは警告の表示なしに行われます。

- コマンドラインでパラメータのスペルを間違えた場合、インストール・ウィザードでは警告が表示されません。そのまま続行され、すべてのコンポーネントにデフォルトのポートが割り当てられます。

- コマンドラインでstaticports.iniファイルの相対パス(たとえば、./staticports.ini)を入力すると、インストール・ウィザードではそのファイルが見つかりません。警告が表示されずにそのまま続行され、すべてのコンポーネントにデフォルトのポートが割り当てられます。staticports.iniファイルのフルパスを入力する必要があります。

2.1.11 Oracle Management Repositoryの構成中に作成されるデータ・ファイル

Oracle Management Repositoryの構成中に作成されるデータ・ファイルを次に示します。

mgmt.dbf

監視対象のターゲット、それらのメトリックなどの情報を格納します。

mgmt_ecm_depot1.dbf

監視対象ターゲットから収集される構成情報を格納します。

mgmt_deepdive.dbf

JVM診断およびアプリケーションの依存性パフォーマンス(ADP)関連の監視データを格納します。

2.1.12 Oracle Management Repositoryの構成中に作成されるデータ・ファイルの削除方法

データ・ファイルを削除するには、SYSMAN/MDSスキーマを削除する必要があります。それには、OMSホームから次のコマンドを実行します。

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action drop -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_home> -oracleHome <oms_home>

注意:

- Microsoft Windowsの場合は、RepManager.batを起動してください。

- 10gリリース2 (10.2.x.x)の管理リポジトリに属するスキーマを削除する場合は、次の引数を指定せずにコマンドを実行します。
-mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <OMS_HOME>

スキーマを削除した後、データベース・ファイルmgmt.dbfおよびmgmt_ecm_depot1.dbfを手動で削除します。

SYSとして次のコマンドを実行すると、これらのファイルを見つけられます。

SELECT FILE_NAME FROM DBA_DATA_FILES WHERE UPPER (TABLESPACE_NAME) LIKE 'MGMT%';

表2-3は、RepManagerの様々なバージョンでサポートされる-actionオプションを示しています。

表2-3 RepManagerでの-action dropallおよび-action dropコマンドのサポート

RepManagerのバージョン

サポートされるコマンド

12cリリース4 (12.1.0.4)

-action drop

このコマンドは、SYSMAN、SYSMAN_MDS、SYSMAN_APM、SYSMAN_OPSS、SYSMAN_ROおよびSYSMAN_BIPLATFORMを削除します。

12cリリース1 (12.1.0.1)、12cリリース2 (12.1.0.2)および12cリリース3 (12.1.0.3)

- -action dropall

- -action drop

これらのコマンドは、SYSMAN、SYSMAN_MDS、SYSMAN_APM、SYSMAN_OPSSおよびSYSMAN_ROを削除します。

11gリリース1 (11.1.0.1)

- -action dropall
このコマンドはSYSMANおよびSYSMAN_MDSのみを削除します。

- -action drop
このコマンドはSYSMANのみを削除します。

10gリリース5 (10.2.0.5)

-action drop

このコマンドはSYSMANのみを削除します。

2.1.13 Enterprise Managerのグローバリゼーション・サポート

Enterprise Manager Cloud Controlは、次の言語に翻訳されています。

- ポルトガル語(ブラジル)

- 中国語(簡体字および繁体字)

- フランス語

- ドイツ語

- イタリア語

- 日本語

- 韓国語

- スペイン語

使用しているWebブラウザに設定されている優先言語が、Enterprise Manager Cloud Controlコンソールで使用される言語になります。

オペレーティング・システムに設定されている言語またはロケールが、Enterprise Manager Cloud Controlインストール・ウィザードで使用される言語になります。

2.2 Enterprise ManagerのインストールにおけるOracle WebLogic Server要件の理解

Enterprise Manager Cloud Controlには、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 Cloud Controlのインストール時に、インストール・ウィザードにより自動的にインストールされます。

この項では、Enterprise Manager Cloud Controlをインストールする前に知っておく必要のある、Oracle WebLogic Serverに関連する重要な側面について説明します。

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

- Oracle WebLogic Serverがインストールされているかどうかを確認する方法

- Oracle WebLogic Serverクラスタがサポートされているか

- Oracle WebLogic Serverがすでに存在する場合、既存のドメインが使用されるか

- Oracle WebLogic Serverの資格証明が必要な場合と理由

- ノード・マネージャの資格証明が必要な場合と理由

- Enterprise Managerのインストール後に管理サーバー・ポートを見つける方法

- 管理サーバーが実行されているかどうかを確認する方法

- 管理サーバーの起動方法

2.2.1 Oracle WebLogic Serverがインストールされているかどうかを確認する方法

Oracle WebLogic Serverがインストールされているかどうかを確認するには、Oracleミドルウェア・ホームで次のファイルを確認します。

$<MW_HOME>/logs/log.txt

log.txtファイルの出力例を次に示します。

release 10.3.6.0 [Added]
|_____Common Infrastructure Engineering 7.1.0.0 [Added]
|    |_____Uninstall [Added]
|    |_____Patch Client [Added]
|    |_____Patch Attachment Facility [Added]
|    |_____Clone Facility [Added]
|_____WebLogic Server 10.3.6.0 [Added]
|    |_____Core Application Server [Added]
|    |_____Administration Console [Added]
|    |_____Configuration Wizard and Upgrade Framework [Added]
|    |_____Web 2.0 HTTP Pub-Sub Server [Added]
|    |_____WebLogic SCA [Added]
|    |_____WebLogic JDBC Drivers [Added]
|    |_____Third Party JDBC Drivers [Added]
|    |_____WebLogic Server Clients [Added]
|    |_____WebLogic Web Server Plugins [Added]
|    |_____UDDI and Xquery Support [Added]
|    |_____Server Examples [Added]
|    |_____Evaluation Database [Added]
|    |_____Workshop Code Completion Support [Added]
|_____Oracle Configuration Manager 10.3.3.1 [Added]
|    |_____Data Collector [Added]
|_____Oracle Coherence 3.6.0.3 [Not Installed]
|_____Coherence Product Files [Not Installed]
|_____Coherence Examples [Not Installed]

2.2.2 Oracle WebLogic Serverクラスタがサポートされているか

Oracle WebLogic Serverクラスタは複数のOracle WebLogic Serverで構成され、それぞれが同時に実行されて互いに連携して動作することで、スケーラビリティと信頼性を高めています。1つのクラスタは、1つのOracle WebLogic Serverインスタンスと考えられます。クラスタを構成する各サーバー・インスタンスは同じホスト上で実行することも、別々のホストに配置することもできます。

Enterprise Manager Cloud ControlはOracle WebLogic Serverクラスタにインストールできますが、クラスタ構成を利用することはできません。

2.2.3 Oracle WebLogic Serverがすでに存在する場合、既存のドメインが使用されるか

Oracle WebLogic Serverがすでに存在する場合、既存のドメインは使用されません。かわりに、Enterprise Manager Cloud Controlインストール・ウィザードにより新規ドメインが作成され、Enterprise Manager Cloud Controlソフトウェアがそれにデプロイされます。

2.2.4 Oracle WebLogic Serverの資格証明が必要な場合と理由

Enterprise Manager Cloud Controlをインストールまたはアップグレードするときには、Oracle WebLogic Serverの資格証明(ユーザー名とパスワード)を入力するように要求されます。資格証明は、WebLogicドメインおよびその他の関連コンポーネント(管理サーバー、管理対象サーバー、ノード・マネージャなど)を作成するために使用されます。

WebLogicユーザー名は、WebLogicドメイン用の管理ユーザーとして使用されるデフォルト・ユーザー名です。デフォルトのユーザー名は、weblogicです。また、WebLogicパスワードは、このデフォルトの管理ユーザー・アカウントのパスワードです。

2.2.5 ノード・マネージャの資格証明が必要な場合と理由

Enterprise Manager Cloud Controlをインストールまたはアップグレードするときには、デフォルトのノード・マネージャ・ユーザー・アカウントのパスワード、nodemanagerを入力するよう要求されます。パスワードは、ノード・マネージャの構成に使用されます。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

注意:
Microsoft Windowsでは、ノード・マネージャ・サービスは作成されません。これは予測されている動作です。

2.2.6 Enterprise Managerのインストール後に管理サーバー・ポートを見付ける方法

管理サーバー・ポートを見つけるには、emgc.propertiesファイルのAS_HTTPS_PORTパラメータに設定された値を表示します。このファイルは、Oracle Management Serviceインスタンス・ベースの場所にあります。

次に例を示します。

/DATA/oracle/gc_inst/em/EMGC_OMS1/emgc.properties

2.2.7 管理サーバーが実行されているかどうかを確認する方法

追加のOMSをインストールするには、第1のOMSで使用されている管理サーバーが実行されている必要があります。管理サーバーが実行されているかどうかを確認するには、次のURLを使用して管理サーバー・コンソールにアクセスします。

https://host:port/console

ここで、hostとportは、emgc.propertiesファイルで、パラメータのEM_INSTANCE_HOSTとAS_HTTPS_PORTにそれぞれ指定されている値です。このプロパティ・ファイルは、第1のOMSのOracle Management Serviceインスタンス・ベースの場所にあります。

次に例を示します。

/DATA/oracle/gc_inst/em/EMGC_OMS1/emgc.properties

2.2.8 管理サーバーの起動方法

次のコマンドを実行して管理サーバーを起動できます。このコマンドは基本的にはOMSを起動するために使用するものですが、そのOMSが実行されている管理サーバーも起動します。このため、OMSがすでに実行されていることがわかっていても、このコマンドを実行してください。

emctl start oms

2.3 インストール・ディレクトリの理解

この項では、Enterprise Manager Cloud Controlまたはそのコア・コンポーネントのインストール時に入力する必要のあるインストール・ディレクトリについて説明します。この項の具体的な内容は次のとおりです。

- Oracleインベントリ・ディレクトリとは

- Oracleミドルウェア・ホームとは

- Oracle Management Serviceインスタンス・ベースの場所とは

- Oracleホームとは

- エージェント・ベース・ディレクトリとは

- エージェント・ベース・ディレクトリとは

- /TMPまたはC:\Tempディレクトリの用途とは

2.3.1 Oracleインベントリ・ディレクトリとは

Enterprise Manager Cloud Controlが、インストールする初めてのOracle製品である場合、Enterprise Manager Cloud Controlのインストール・ウィザードで、インベントリ・ディレクトリ(oraInventoryディレクトリとも呼ばれる)を入力するように要求されます。

インストール・ウィザードにより、このインベントリ・ディレクトリを使用して、ホスト上にすべてのインストーラ・ファイルおよびディレクトリが配置されます。インベントリ・データを格納するためのサブディレクトリがOracle製品ごとに自動的に設定されます。

oraInventoryディレクトリは、次の2つの方法で入力できます。

- インストール・ウィザードを使用してEnterprise Manager Cloud Controlをインストールするときに、「Oracleインベントリ」画面でoraInventoryディレクトリを入力できます。この画面でディレクトリを入力するときは、oraInventoryディレクトリを所有する適切なオペレーティング・システム・グループ名も選択する必要があります。oraInventoryディレクトリに対する書込み権限があるグループを選択する必要があります。

- インストール・ウィザードを使用せずにサイレント・モードでEnterprise Manager Cloud Controlをインストールするときに、-invPtrLocパラメータを使用してoraInventoryディレクトリを入力できます。このパラメータでは、インベントリ・ポインタ・ファイル(oraInst.loc)のある場所のパスが考慮されます。ただし、このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。
次に例を示します。

./runInstaller -invPtrLoc /scratch/OracleHomes/oraInst.loc

注意:

- 通常のHA以外の環境では、中央インベントリ(oraInventory)を共有または非共有の場所に設定可能です。共有場所を使用する場合、ホストごとに1つの共有場所が保持されているようにし、2つのホストが同じ共有場所を更新しないようにします。1つのインベントリ・ファイルは1つのホストの専用であり、他のホストによって編集されたり共有されたりはできません。/etc/oraInst.locファイルを使用するときは、そこに指定されたインベントリの場所が、そのような場所を指していないことを確認します。2つ以上のホスト間に共通する共有場所を構成した場合は、非共有の場所に切り替えます。

- 記憶域レプリケーションおよび仮想ホスト名を使用してプライマリおよびスタンバイの障害時リカバリ・サイトを備えている、通常のHA環境の場合、仮想ホスト名を使用する共有記憶域にインストールされたソフトウェア用の中央インベントリ(oraInventory)は、プライマリ・サイトのOMSホストとスタンバイ・サイトのOMSホストの間に共通の共有場所に存在する必要があります。ソフトウェアのメンテナンス作業のためにアクティブなサイトからoraInventoryにアクセス可能とするために、この共有場所はレプリケートされた記憶域に設定する必要があります。

ホストにOracle製品がすでにインストールされている場合、インストール・ウィザードは、そのOracle製品のインストール中に作成された既存のoraInventoryディレクトリを使用します。そのディレクトリへの書込み権限を持っていることを確認します。これを行うには、他のOracle製品をインストールしたオペレーティング・システム・ユーザーと同じユーザーとしてインストーラを実行します。

注意:
oraInventoryディレクトリは、インストール・ディレクトリとは異なります。インストール・ディレクトリの詳細は、第2.3.2項を参照してください。

2.3.2 Oracleミドルウェア・ホームとは

Enterprise Manager Cloud Controlをインストールまたはアップグレードするときには、Oracleミドルウェア・ホームを入力する必要があります。

Oracleミドルウェア・ホーム(ミドルウェア・ホーム)は、Oracle WebLogic Serverホーム、Java Development Kit、Web層インスタンス・ファイル、1つ以上のOracleホーム、OMSインスタンス・ベース・ディレクトリおよびその他の関連ファイルが含まれる親ディレクトリです。OMSおよびプラグインは、ここにデプロイされます。

次に例を示します。

/u01/app/Oracle/Middleware

Enterprise Manager Cloud Controlをインストールまたはアップグレードする場合、次のようになります。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0が使用環境にすでにインストールされている場合、インストーラが自動的に検出して、これらがインストールされているミドルウェア・ホームの絶対パスを表示します。
この場合、デフォルトで検出され表示されるミドルウェア・ホームを検証します。場所が正しくない場合、正しい場所のパスを入力します。

入力したパスが、UNIXプラットフォームの場合は70文字、Microsoft Windowsプラットフォームの場合は25文字を超えていないことを確認してください。また、指定するディレクトリに書込み権限があり、ファイルまたはサブディレクトリが存在しないことを確認してください。

たとえば、15文字のみを含むミドルウェア・ホームのパスC:\Oracle\MW\EMは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0が使用環境にまだインストールされていない場合、Enterprise Manager Cloud Controlのインストール時に、インストール・ウィザードにより自動的にインストールされます。
この場合、インストールする新しいミドルウェア・ホームへの絶対パスを入力します。

入力したパスが、UNIXプラットフォームの場合は70文字、Microsoft Windowsプラットフォームの場合は25文字を超えていないことを確認してください。また、入力するディレクトリに書込み権限があり、ファイルまたはサブディレクトリが存在しないことを確認してください。2システムのアップグレードの場合も、旧リリースのEnterprise Managerシステムに使用していた古いミドルウェア・ホーム・ディレクトリではなく、新しいミドルウェア・ホームの場所を入力します。

たとえば、15文字のみを含むミドルウェア・ホームのパスC:\Oracle\MW\EMは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

注意:
Oracleミドルウェア・ホームは、OMSまたは管理エージェントのOracleホームとは異なります。Oracleホームの詳細は、第2.3.4項「Oracleホームとは」を参照してください。

2.3.3 Oracle Management Serviceインスタンス・ベースの場所とは

Enterprise Manager Cloud Controlをインストールするときには、Oracle Management Serviceインスタンス・ベースの場所を入力する必要があります。

Oracle Management Serviceインスタンス・ベースの場所は、OMSの構成ファイルが格納されているミドルウェア・ホーム外のディレクトリ(gc_inst)です。

インストール・ウィザードでは、組込みアルゴリズムを使用してこの場所が特定され、ユーザーが検証できるようにその場所が表示されます。ミドルウェア・ホームが/u01/app/Oracle/Middleware/であれば、Oracle Management Serviceインスタンス・ベースの場所はデフォルトで次のようになります。

/u01/app/Oracle/gc_inst

デフォルトの場所を受け入れるか、または書込み権限のある別の場所を指定できます。

注意:
Oracleミドルウェア・ホームの詳細は、第2.3.2項を参照してください。

2.3.4 Oracleホームとは

Oracle HomeまたはOracleホームは、OMS、管理エージェントおよびプラグインがインストールされているディレクトリです。表2-4は、デフォルトのOracleホームが作成される場所を示しています。

表2-4 OMS、管理プラグインのOracleホーム

コンポーネント

デフォルトのOracleホーム

場所の例

Oracle Management Service

$<MIDDLEWARE_HOME>/oms

/u01/app/Oracle/Middleware/oms

Oracle管理エージェント

$<AGENT_BASE_DIR>/core/12.1.0.4.0

/u01/app/Oracle/agent/core/12.1.0.4.0

プラグイン(OMS固有のプラグイン)

$<MIDDLEWARE_HOME>/plugins/<pluginID_Version>

/u01/app/Oracle/software/plugins/oracle.sysman.db.agent.plugin_12.1.0.4.0

プラグイン(エージェント固有のプラグイン)

$<AGENT_BASE_DIR>/plugins

/u01/app/Oracle/agent/plugins

注意:
OracleホームはOraInventoryとは異なります。OraInventoryディレクトリの詳細は、第2.3.1項を参照してください。

2.3.5 エージェント・ベース・ディレクトリとは

ホスト・ターゲットの追加ウィザードを使用してEnterprise Manager Cloud Controlおよびスタンドアロンの管理エージェントをインストールする際、インストール・ベース・ディレクトリ(基本的にはエージェント・ベース・ディレクトリ)の入力を求められます。

エージェント・ベース・ディレクトリは、Oracleミドルウェア・ホーム外のディレクトリで、管理エージェント・ホームが作成されます。

たとえば、エージェント・ベース・ディレクトリが/u01/app/Oracle/agentの場合、管理エージェント・ホームは/u01/app/Oracle/agent/core/12.1.0.4.0のように作成されます。

2.3.6 エージェント・インスタンス・ディレクトリとは

エージェント・インスタンス・ディレクトリは、管理エージェント関連のすべての構成ファイルを格納するために作成されるディレクトリ(agent_inst)です。

エージェント・インスタンス・ディレクトリは、エージェント・ベース・ディレクトリ内に作成されます。

たとえば、エージェント・ベース・ディレクトリが/u01/app/Oracle/agentの場合、デフォルトでは、エージェント・インスタンス・ディレクトリは次のようになります。

/u01/app/Oracle/agent/agent_inst

2.3.7 /TMPまたはC:\Tempディレクトリの用途とは

Enterprise Manager Cloud Controlのインストール・ウィザードを起動すると、自動的にいくつかの実行可能ファイルおよびリンク・ファイルがホスト上の一時ディレクトリにコピーされます。

たとえば、UNIXホストでは/tmpディレクトリが、Microsoft WindowsホストではC:\Tempがデフォルトで使用されます。

定期的に実行される他の多数のプロセスとともにcronジョブを実行するようにホストが設定されている場合、これらのジョブによってデフォルトの一時ディレクトリのクリーンアップが試行されます。このため、一部のファイルが削除され、インストール・ウィザードは失敗します。

ホストで自動的に実行されて一時ディレクトリをクリーンアップするcronジョブまたはプロセスがある場合は、必ず、TMPまたはTEMP環境変数をデフォルトの場所とは別の場所に設定してください。デフォルト以外の場所を設定する場合は必ず、ハード・ドライブ上のセキュアな場所、つまりクリーンアップ・ジョブが実行されない場所に設定してください。また、この代替ディレクトリへの書込み権限を持っていることも確認してください。

これは、インストーラを実行してEnterprise Manager Cloud Controlインストール・ウィザードを起動する前に行う必要があります。(UNIXオペレーティング・システムの場合はrunInstallerを起動し、Microsoft Windowsの場合はsetup.exeを起動します。)

注意:
一時ディレクトリの代替場所の指定は必須ではありません。/tmpディレクトリをクリーンアップするcronジョブがコンピュータ上に設定されている場合のみ、指定する必要があります。

2.4 コンフィギュレーション・アシスタントの理解

この項では、インストール・ウィザードで実行されるインストール後のアクティビティについて説明します。この項の具体的な内容は次のとおりです。

- コンフィギュレーション・アシスタントとは

- インストール・ウィザードにより実行されるコンフィギュレーション・アシスタント

- コンフィギュレーション・アシスタントが失敗した場合の処理

2.4.1 コンフィギュレーション・アシスタントとは

Enterprise Manager Cloud ControlをGUIモード(インストール・ウィザードを使用)またはサイレント・モード(レスポンス・ファイルを使用)のいずれかでインストールまたはアップグレードするとき、インストール・プロセスの終了時に一連の構成アシスタントが実行されて、インストールまたはアップグレード済のコンポーネントが構成されます。これらのコンフィギュレーション・アシスタントを使用してすべてのコンポーネントを構成して初めて、インストールまたはアップグレード・プロセスは完了します。

注意:
Enterprise Managerのソフトウェアのみのインストールを実行する場合でも、ConfigureGC.shスクリプトを実行してインストールを構成するときには、コンフィギュレーション・アシスタントが内部で実行されます。(Microsoft Windowsの場合は、ConfigureGC.batスクリプトを実行)。

2.4.2 インストール・ウィザードにより実行されるコンフィギュレーション・アシスタント

この項では、インストール・タイプごとにインストール・ウィザードが実行するコンフィギュレーション・アシスタントを示しています。

- Enterprise Managerの新規インストールで実行されるコンフィギュレーション・アシスタント

- 既存のEnterprise Managerのアップグレードで実行されるコンフィギュレーション・アシスタント

- 追加のOracle Management Serviceのアップグレードで実行されるコンフィギュレーション・アシスタント

2.4.2.1 Enterprise Managerの新規インストールで実行されるコンフィギュレーション・アシスタント

Enterprise Managerの新規インストール(つまり、インストール・ウィザードで「Enterprise Managerシステムの新規作成」を選択した場合)で実行されるコンフィギュレーション・アシスタントを次に示します。

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

- リポジトリ構成

注意:
オラクル社提供のデータベース・テンプレートを使用し、事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、リポジトリ・コンフィギュレーションのかわりに、リポジトリ即時使用可能コンフィギュレーションが実行されます。

- MDSスキーマ構成

注意:
オラクル社提供のデータベース・テンプレートを使用し、事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、MDAスキーマ構成は実行されません。

- OMS構成

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

- Oracle Management Serviceの起動

- Oracle Configuration Managerリピータ構成

- エージェント・コンフィギュレーション・アシスタント

2.4.2.2 既存のEnterprise Managerのアップグレードで実行されるコンフィギュレーション・アシスタント

既存のEnterprise Managerのアップグレード(つまり、インストール・ウィザードで「既存のEnterprise Managerシステムのアップグレード」を選択した場合)で実行されるコンフィギュレーション・アシスタントを次に示します。

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

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

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

- MDSスキーマ構成

- OMS構成

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

- Oracle Management Serviceの起動

- Oracle Configuration Managerリピータ構成

- プラグイン・インベントリの移行(12cリリースX (12.1.0.X)から12cリリースX (12.1.0.X)へのアップグレードでは実行しません)

また、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のアップグレードでは、次が実行されます。

- APMエンジンの停止

- 管理サーバーの停止(10gリリース5 (10.2.0.5)から12cリリースX (12.1.0.X)へのアップグレードでは実行しません)

注意:
管理エージェントは、アップグレード前コンソールで事前デプロイされるか(10.2.0.5または11.1の管理エージェントの場合)、またはエージェント・アップグレード・コンソール(12.1.0.3および12.1.0.2の管理エージェントの場合)を使用してアップグレードされるので、このアップグレードの対象外となるため、エージェント・コンフィギュレーション・アシスタントは実行されません。

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

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

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

- MDSスキーマ構成

- OMS構成

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

- Oracle Management Serviceの起動

- Oracle Configuration Managerリピータ構成

- エージェント・コンフィギュレーション・アシスタント

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

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

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

- MDSスキーマ構成

- OMS構成

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

- プラグイン・インベントリ移行

- Oracle Management Serviceの起動

- Oracle Configuration Managerリピータ構成

- エージェント・コンフィギュレーション・アシスタント

2.4.2.3 追加のOracle Management Serviceのアップグレードで実行されるコンフィギュレーション・アシスタント

追加OMSインスタンスは、1システムのアップグレード方式のみを使用してアップグレードされます。追加OMSのアップグレード(つまり、インストール・ウィザードで「既存のEnterprise Managerシステムのアップグレード」を選択し、追加OMSを選択した場合)で実行されるコンフィギュレーション・アシスタントを次に示します。

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

- OMS構成

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

- Oracle Management Serviceの起動

- Oracle Configuration Managerリピータ構成

また、12cリリース3 (12.1.0.3)または12cリリース2 (12.1.0.2)のアップグレードでは、次が実行されます。

- APMエンジンの停止

- 管理サーバーの停止(10gリリース5 (10.2.0.5)から12cリリースX (12.1.0.X)へのアップグレードでは実行しません)

注意:
管理エージェントは、アップグレード前コンソールで事前デプロイされるか(10.2.0.5または11.1の管理エージェントの場合)、またはエージェント・アップグレード・コンソール(12.1.0.3および12.1.0.2の管理エージェントの場合)を使用してアップグレードされるので、このアップグレードの対象外となるため、エージェント・コンフィギュレーション・アシスタントは実行されません。

2.4.3 コンフィギュレーション・アシスタントが失敗した場合の処理

オプションのコンフィギュレーション・アシスタントが失敗した場合、インストール・ウィザードではその失敗は無視され、自動的に次のコンフィギュレーション・アシスタントが実行されます。ただし、必須のコンフィギュレーション・アシスタントが失敗した場合は、インストール・プロセスが停止します。この場合、問題を解決して、構成アシスタントを戻す必要があります。

コンフィギュレーション・アシスタントが失敗したときに調べるログ・ファイルと、問題を解決するために取る処置の詳細は、付録Jを参照してください。

2.5 Enterprise Manager Cloud Controlをインストールする前の前提条件チェックの理解

インストール・ウィザードを使用してEnterprise Manager Cloud Controlをインストールするたびに、一連の前提条件チェックが実行され、環境がインストール成功のための最小要件を満たしているかどうかが確認されます。インストール・ウィザードによって、必要なオペレーティング・システム・パッチ、オペレーティング・システム・パッケージ、カーネル・パラメータを含む様々な要素が確認されます。

次の各項で、これらの前提条件チェックについて説明します。この項の具体的な内容は次のとおりです。

- デフォルトで実行される前提条件チェック

- スタンドアロン・モードで前提条件チェックを実行する方法

2.5.1 デフォルトで実行される前提条件チェック

異なるインストール・タイプ(Enterprise Managerシステムの新規作成および既存のEnterprise Managerシステムのアップグレード)で実行されるデフォルトの前提条件チェックは、次のとおりです。

- インストールが動作保証済のオペレーティング・システムで実行されているかどうかを確認するための前提条件チェック。

- すべての動作保証済パッケージおよびライブラリがインストールされているかどうかを確認するための前提条件チェック。

- glibcパッケージがインストールされているかどうかを確認するための前提条件チェック。(管理エージェントのインストールには適用されません。)

- tempディレクトリに十分なディスク領域があるかどうかを確認するための前提条件チェック。(管理エージェントのインストールには適用されません。)

- インベントリ・ディレクトリに十分なディスク領域があるかどうかを確認するための前提条件チェック。

- インベントリ・ディレクトリに書込み権限があるかどうかを確認するための前提条件チェック。(OMSのインストールには適用されません。)

- ソフトウェアが現在のオペレーティング・システムと互換性があるかどうかを確認するための前提条件チェック。

- 十分な物理メモリーがあるかどうかを確認するための前提条件チェック。

- 必須のulimit値を確認するための前提条件チェック。(管理エージェントのインストールには適用されません。)

- ホスト名を確認するための前提条件チェック。

- LD_ASSUME_KERNEL環境変数が設定されているかどうかを確認するための前提条件チェック。(管理エージェントのインストールには適用されません。)

- 適切なタイムゾーンが設定されているかどうかを確認するための前提条件チェック。

- 4GBのスワップ領域があるかどうかを確認するための前提条件チェック。(管理エージェントのインストールには適用されません。)

- http_proxy環境変数が設定されているかどうかを確認するための前提条件チェック。設定されないことが理想です。

2.5.2 スタンドアロン・モードで前提条件チェックを実行する方法

インストール・ウィザードの起動前に、スタンドアロン・モードで前提条件チェックを実行できます。これにより、インストールの失敗の原因となる問題を特定して解決できます。

警告:

Oracle製品がインストールされていないホストで、前提条件チェックをスタンドアロン・モードで実行すると、中央インベントリのハード・ディスク容量をチェックする前提条件チェックが失敗します。ホスト上にOracle製品がインストールされていないため、これは予測された失敗です。この失敗は無視して、実際のインストールを続行できます。

表2-5に、スタンドアロン・モードで前提条件チェックを実行するために実行する必要のあるコマンドを示します。

表2-5 スタンドアロン・モードでの前提条件チェックの実行

インストール・タイプ

コマンド

- Enterprise Managerシステムの新規作成

- 既存のEnterprise Managerシステムのアップグレード

- ソフトウェアのみのインストール

<Software_Location>/install/runInstaller -prereqchecker PREREQ_CONFIG_LOCATION=<Software_Location>/stage/prereq -entryPoint "oracle.sysman.top.oms_Core" -prereqLogLoc <absolute_path_to_log_location> -silent -waitForCompletion

注意:
Microsoft Windowsの場合、/runInstallerをsetup.exeで置き換えてください。また、表2-5のコマンドに示されている<Software_Location>は、Enterprise Managerソフトウェアが含まれている場所です。たとえば、DVDなどです。Oracle Technology Network (OTN)からソフトウェアをダウンロードした場合は、そのダウンロード場所の絶対パスを入力します。

2.6 Enterprise Manager Cloud Controlの制限事項の理解

この項では、Enterprise Manager Cloud Controlの使用時に直面する可能性のある制限事項について説明します。この項の具体的な内容は次のとおりです。

- ライセンスのないコンポーネントにアクセスできるか

- DHCP対応のマシンに関連する制限事項

2.6.1 ライセンスのないコンポーネントにアクセスできるか

メディア・パック内のインストール・メディアには多数のOracleコンポーネントが含まれていますが、使用できるのは、ライセンスを購入したコンポーネントのみです。Oracleサポート・サービスは、ライセンスを購入していないコンポーネントのサポートは提供しません。

詳細は、次のURLでEnterprise Managerドキュメント・ライブラリにアクセスし、Oracle Enterprise Managerライセンス情報ガイドを参照してください。

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

2.6.2 DHCP対応のマシンに関連する制限事項

DHCP対応のコンピュータではOMSを実行しないでください。Enterprise Manager Cloud Controlコンポーネントが正常に機能するために、ネットワーク上で割り当てられている静的なホスト名またはIPアドレスを使用することを強くお薦めします。

詳細は、次のURLにあるMy Oracle Supportノート428665.1を参照してください。

https://support.oracle.com/

2.7 起動スクリプトの理解

Enterprise Manager Cloud Controlでは、デフォルトで、OMSおよび管理エージェントのすべてのインストールにgcstartupという起動スクリプトが付属します。起動スクリプトによって、ホストが再起動するたびに、OMSおよび管理エージェントが自動的に起動されることが保証されるため、ユーザーは手動による作業から解放されます。

2.7.1 起動スクリプトの格納場所

起動スクリプトは、OMSホストおよび管理エージェント・ホストの次の場所に存在します。

/etc/init.d/gcstartup

2.7.2 起動スクリプトの呼出し対象

OMSホストでは、起動スクリプトによって次のファイルが呼び出され、ホストの再起動時にOMSが起動されます。

$<OMS_HOME>/install/unix/scripts/omsstup

同様に、管理エージェント・ホストでは、起動スクリプトによって次のファイルが呼び出され、ホストの再起動時に管理エージェントが起動されます。

$<AGENT_HOME>/install/unix/scripts/agentstup

2.7.3 起動スクリプトによるOMSまたは管理エージェントの起動を停止する方法

ホストの再起動時に起動スクリプトでOMSおよび管理エージェントを起動しない場合、それぞれのホストからomsstupファイルとagentstupファイルを削除します。

あるいは、ファイル名を/etc/oragchomelistから/etc/oragchomelist_bakに変更することもできます。

2.7.4 起動スクリプトによってリモート・ホストのOMSまたは管理エージェントを起動できるかどうか

起動スクリプトは、OMSまたは管理エージェントがインストールされているホストに固有です。したがって、起動スクリプトでリモート・ホストのOMSまたは管理エージェントを起動することはできません。

2.7.5 管理エージェントが起動または停止するときに起動スクリプトが従う管理エージェント・サービスの優先順位レベルを変更できるかどうか

管理エージェント・サービスの優先順位レベルを変更できるのは、管理エージェントのインストール時またはインストール後です。

ホスト・ターゲットの追加ウィザードを使用して管理エージェントのインストール時に管理エージェント・サービスの優先順位レベルを変更するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す追加のパラメータSTART_PRIORITY_LEVELおよびSHUT_PRIORITY_LEVELを使用します。agentDeployスクリプトを使用して管理エージェントのインストール時に管理エージェント・サービスの優先順位レベルを変更するには、表6-3に示すSTART_PRIORITY_LEVELおよびSHUT_PRIORITY_LEVELレスポンス・ファイル・パラメータを使用します。

管理エージェントのインストール後に管理エージェント・サービスの優先順位レベルを変更するには、次の手順を実行します。

1. /etc/rc.dディレクトリに移動します。/etcにrc.dディレクトリがない場合は、/sbin/rc.dに移動します。

2. /etc/rc.dまたは/sbin/rc.dディレクトリにあるすべてのgcstartupファイルを削除します。これらのファイルを検索するには、次のコマンドを実行します。
find . -name "*gcstartup"

3. $<ORACLE_HOME>/install/unix/scripts/gcroot.shファイルのSTART_PRIORITY_LEVELおよびSHUT_PRIORITY_LEVELパラメータを編集します。
これらのパラメータの詳細は、表6-3を参照してください。

4. 管理エージェント・ホームから、次のroot.shスクリプトを実行します。
$<ORACLE_HOME>/root.sh

たとえば、/etc/rc.dに移動した後に実行するfind . -name "*gcstartup"コマンドの出力は、次のようになります。

./rc5.d/K19gcstartup
./rc5.d/S98gcstartup
./rc5.d/S98lockgcstartup
./rc5.d/K19unlockgcstartup
./rc3.d/K19gcstartup
./rc3.d/S98gcstartup
./rc3.d/S98lockgcstartup
./rc3.d/K19unlockgcstartup
./rc2.d/K19gcstartup
./rc2.d/S98gcstartup
./rc2.d/S98lockgcstartup
./rc2.d/K19unlockgcstartup
./init.d/unlockgcstartup
./init.d/gcstartup
./init.d/lockgcstartup

このように出力されたら、./rc5.d、./rc3.d、./rc2.dおよび./init.dディレクトリにあるすべてのgcstartupファイルを削除し、/tmp/agent/core/12.1.0.4.0/install/unix/scripts/gcroot.shファイルにあるSTART_PRIORITY_LEVELおよびSHUT_PRIORITY_LEVELパラメータを編集して(ORACLE_HOMEが/tmp/agent/core/12.1.0.4.0/の場合)、root.shを実行します。

2.8 その他の概念の理解

この項では、Enterprise Manager Cloud Controlのインストールに関連するその他の概念について説明します。この項の具体的な内容は次のとおりです。

- ホスト・リスト・ファイルとは

- インストール・プロセス中に実行されるスクリプト

2.8.1 ホスト・リスト・ファイルとは

ホスト・ターゲットの追加ウィザードを使用している場合、Oracle Management Agentをインストールするホストを、ホスト名またはIPアドレスを入力するか、ホストのリストを含む外部ファイルを選択するかのいずれかの方法で入力できます。

外部ファイルを選択する場合、そのファイルにホスト名のみが含まれているか、またはホスト名の後にプラットフォーム名が続いているかを確認してください。

ホスト名のみが含まれている外部ファイルの例は次のとおりです。

host1.example.com
host2.example.com

ホスト名とプラットフォーム名が含まれている外部ファイルの例は次のとおりです。

host1.example.com linux
host2.example.com aix

2.8.2 インストール・プロセス中に実行されるスクリプト

Enterprise Manager Cloud Controlまたは管理エージェントのインストール中またはインストール後に少なくとも1回、rootユーザーとしてログインして、oraInstRoot.sh、allroot.shまたはroot.shを実行するように要求されます。rootユーザーとしてログインする必要がある理由は、スクリプトにより/etcディレクトリ内のファイルが編集され、ローカルのbinディレクトリ(デフォルトでは/usr/local/bin)内にファイルが作成されます。

インストールが終わるたびに、中央インベントリ(oraInventory)ディレクトリを特定するためのチェックが実行されます。中央インベントリ・ディレクトリは、Oracle製品が初めてホストにインストールされると、インストール・ウィザードによって自動的に作成されるディレクトリです。

注意:

- 通常のHA以外の環境では、中央インベントリ(oraInventory)を共有または非共有の場所に設定可能です。共有場所を使用する場合、ホストごとに1つの共有場所が保持されているようにし、2つのホストが同じ共有場所を更新しないようにします。1つのインベントリ・ファイルは1つのホストの専用であり、他のホストによって編集されたり共有されたりはできません。/etc/oraInst.locファイルを使用するときは、そこに指定されたインベントリの場所が、そのような場所を指していないことを確認します。2つ以上のホスト間に共通する共有場所を構成した場合は、非共有の場所に切り替えます。

- 記憶域レプリケーションおよび仮想ホスト名を使用してプライマリおよびスタンバイの障害時リカバリ・サイトを備えている、通常のHA環境の場合、仮想ホスト名を使用する共有記憶域にインストールされたソフトウェア用の中央インベントリ(oraInventory)は、プライマリ・サイトのOMSホストとスタンバイ・サイトのOMSホストの間に共通の共有場所に存在する必要があります。ソフトウェアのメンテナンス作業のためにアクティブなサイトからoraInventoryにアクセス可能とするために、この共有場所はレプリケートされた記憶域に設定する必要があります。

- ホストにOracle製品をまだインストールしていない場合は、中央インベントリからoraInstRoot.shスクリプトを実行します。
$Home/oraInventory/oraInstRoot.sh

oraInstRoot.shスクリプトが実行されると、oraInst.locファイルが作成されます。oraInst.locファイルには、中央インベントリの場所が含まれています。

- ただし、ホスト上にOracle製品がすでに存在する場合は、OMSホームからallroot.shスクリプトを実行します。
<OMS_HOME>/allroot.sh

第II部

Enterprise Managerシステムのインストール

この部では、Enterprise Manager Cloud Controlをインストールする各種の方法について説明します。この部は、次の章で構成されています。

- 第3章「サイレント・モードでのEnterprise Managerのインストール」

- 第4章「ソフトウェアのみの方法を使用したEnterprise Managerのインストール」

3 サイレント・モードでのEnterprise Managerのインストール

この章では、動作保証済の既存のOracle Databaseを使用して、サイレント・モードでEnterprise Manager Cloud Controlをインストールする方法について説明します。この項の具体的な内容は次のとおりです。

- サイレント・モードでのEnterprise Managerのインストールの概要

- サイレント・モードでのEnterprise Managerのインストールを開始する前に

- サイレント・モードでEnterprise Managerをインストールするための前提条件

- サイレント・モードでのEnterprise Managerのインストール

- サイレント・モードでEnterprise Managerシステムをインストールした後のインストール後のタスクの実行

注意:
OCFS2やACFSを含むすべての汎用ファイルシステムに、Enterprise Manager Cloud Control 12cのソフトウェア・バイナリおよびOMSインスタンス・ホーム・ファイル(gc_inst内の構成ファイル)を格納できます。ただし、OCFSは汎用ファイルシステムとみなさないため、このような用途での使用は考慮されていません。

警告:

Enterprise Manager Cloud Control 12cを、SPARCシリーズのサーバー(T1000、T2000、T5xx0およびT3-*)にインストールしないでください。詳細は、My Oracle Supportのノート1590556.1を参照してください。

3.1 サイレント・モードでのEnterprise Managerのインストールの概要

Enterprise Managerのインストール方法に慣れていて、インストール・ウィザードの質問画面を表示しないでインストールする場合、サイレント・モードのインストールが最適なオプションです。

サイレント・モードでは、正常にインストールを完了する必要があるすべての情報を取得するレスポンス・ファイルを使用します。他のホストのインストールに移動および再利用できる単一のファイルにインストール詳細が一度だけ取得されるため、時間と労力が節約されます。

ただし、グラフィック・モードまたはサイレント・モードでEnterprise Managerをインストールしているかどうかに関係なく、インストール・プロセス、インストールされたコンポーネントおよび構成プロセスは同じです。そのため、サイレント・モードのEnterprise Managerのインストールは、提供される単なるオプションになります。

インストールされるコンポーネント、実行されるコンフィギュレーション・アシスタントおよびインストール後のディレクトリ構造の表示方法を理解するには、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章を参照してください。

3.2 サイレント・モードでのEnterprise Managerのインストールを開始する前に

開始する前に、次のことに注意してください。

- Enterprise Manager Cloud Controlソフトウェアが最新であることを確認します。
最新のソフトウェアをダウンロードするには、次のURLにアクセスします。

http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html

最新のソフトウェアのダウンロードの詳細は、第1.2.2項を参照してください。

- Enterprise Manager Cloud Controlソフトウェアをダウンロードして実行するディレクトリの名前に空白文字が含まれていないことを確認します。たとえば、EM Softwareという名前のディレクトリの場合、2つの語の間に空白文字が含まれているため、このディレクトリからはソフトウェアをダウンロードしないでください。

- 単一ホストのレスポンス・ファイルを使用してインストール・ウィザードを起動するローカルのサーバーにのみ、Enterprise Manager Cloud Controlをインストールできます。リモート・ホストにはインストールできません。

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

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

表 3-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 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_HOMEおよびORACLE_SID環境変数は設定しないでください。OracleディレクトリがPATHに表示されていないことを確認する必要があります。

- Enterprise Manager Cloud Controlインストール・ウィザードはJava Development Kit (JDK) 1.6.0.43.0およびOracle WebLogic Server 11gリリース1 (10.3.6)をインストールしますが、既存のインストールの使用を指定しない場合のみです。Enterprise Manager 12cと使用するためにJDKおよびOracle WebLogic Serverをインストールするには、12cのインストール・プロセスを使用することを強くお薦めします。

- 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をダウンロードしてください。
たとえば、次のOracle WebサイトのURLからLinuxプラットフォーム用のSUN JDK 1.6.0.43.0をダウンロードします。

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

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

32ビットJDKまたは64ビットJDKかどうかを確認するには、次のコマンドを実行します。

"file *"

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

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

<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インストレーション・ガイド』に示されている手順に従う必要があります。このガイドは、次の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および16888501を適用します。これらのパッチを適用していないと、追加のOMSのインストールが失敗します。
これらのパッチを適用する手順については、次のURLを参照してください。

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

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

- symlinkにインストールしないでください。このような場所にインストールすると、パッチ適用やスケール・アウトなどのライフ・サイクル操作に影響が及ぶ場合があります。

- オプションで、オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスを作成できます。これを行うには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。このようなデータベース・インスタンスは、簡易インストールと拡張インストールで使用できます。
ただし、データベース・テンプレートは詳細インストールに使用できますが、基本的には簡易インストール用に設計されています。このため、詳細インストール(通常は小、中または大のデプロイメント・サイズを選択)を実行中に、このようなデータベースの詳細を指定すると、選択したデプロイメント・サイズに合せるにはデータベース・パラメータを変更する必要があることを示すメッセージが表示されます。メッセージを確認して続行します。インストール・ウィザードによって自動的にデータベース・パラメータが必要な値に設定されます。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイルシステムの場所にマップします。手順については、第3.5項を参照してください。

- 管理リポジトリの構成を予定しているOracle Database上のXML DBなどの機能を有効または無効にしても、Enterprise Managerには影響されません。したがって、Enterprise Managerはデータベース内の任意の機能に依存していないため、それらを有効または無効にできます。

- オプションで、管理リポジトリのデプロイに関する構成ガイドラインに従って、管理データの安全性、信頼性および可用性を確保するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- デフォルトでは、レスポンス・ファイル内のINSTALL_UPDATES_SELECTION変数が"skip"に設定されているため、インストール中にソフトウェア更新を適用することはできません。インストール中にソフトウェア更新を適用する必要がある場合は、表3-3の説明に従ってこの変数を変更します。

- Oracleでは、Oracleライフタイム・サポート・ポリシーに基づき、製品のバグ修正を提供しています。製品ライセンスの有効期限が切れると、Oracleによって提供されるバグ修正のサポートも終了します。詳細は、次のURLで入手可能なOracleライフタイム・サポート・ポリシーを参照してください。
http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

Enterprise Manager Cloud Controlインストールのサポート可能性および動作保証の組合せを決定する場合、Enterprise Manager Cloud Controlのフレームワーク・コンポーネントおよびEnterprise Manager Cloud Controlで監視されるターゲットを考慮する必要があります。Extended Supportライセンスを購入する必要なくコード修正を入手するには、Cloud Controlコンポーネントとターゲットを最新の動作保証済バージョンに常に更新しておくことをお薦めします。

- HPUNIX、HPia64、Solaris Sparc以外のすべてのUNIXプラットフォームの/etc/oragchomelistファイルのOMSおよび管理エージェント・エントリを見つけることができます。
HPUNIX、HPia64、Solaris Sparcプラットフォームでは、エントリが/var/opt/oracle/oragchomelistにあります。

- 前提条件として、管理リポジトリを構成するためのOracle Databaseがすでに存在する必要があります。このデータベースの自動メモリー管理(AMM)機能は有効でもかまいません。

- 高可用性構成または障害時リカバリ構成でインストールする場合、または将来的にこれらの構成に変換する場合は、第16章、第17章、第18章を確認してよく理解してから、このインストールに進んでください。
前述の各章の情報を確認したら、インストールを高可用性または障害時リカバリに対して準備するために、第17章に示されたベスト・プラクティス(特に17.3.1項の情報)に従ってください。

- ロケール固有のデータは、<OMS_Oracle_Home>/nls/dataディレクトリに格納されます。環境変数ORA_NLS10を<OMS_Oracle_Home>/nls/dataに設定するか、まったく設定しないことを強くお薦めします。

- OMSと管理リポジトリを格納するOracle Databaseとを同じホストにインストールした場合、ホストを再起動するときに、それとともにインストールされたOMSおよび管理エージェントは自動的に起動しません。これらは手動で起動する必要があります。

- Security-Enhanced Linux (SELinux)では、オプションの施行がサポートされています。

3.3 サイレント・モードでEnterprise Managerをインストールするための前提条件

Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章に示されている前提条件を満たしてください。

3.4 サイレント・モードでのEnterprise Managerのインストール

内容は次のとおりです。

- サイレント・モードでのEnterprise Managerのインストール

- サイレント・モードでEnterprise Managerシステムをインストールするためにサポートされている拡張インストーラ・オプション

- サイレント・モードでEnterprise Managerシステムをインストールするためにサポートされている拡張オプションに関する制限事項

- サイレント・モードでEnterprise Managerをインストールするためのnew_install.rspレスポンス・ファイルの編集

注意:
Enterprise Managerシステムのインストールを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を確認して2014年9月と10月および2015年1月にリリースされたプラグインを学習し、このプラグイン・リリースに関するユースケースを理解することをお薦めします。現在の要件に最適な事例を確認し、表の使用例に示される詳細な手順に従ってください。

3.4.1 サイレント・モードでのEnterprise Managerのインストール

サイレント・モードで完全なEnterprise Managerシステムをインストールするには、次の手順を実行します。

注意:
インストーラを起動する前にEM前提条件キットを実行し、リポジトリの前提条件をすべて満たしていることをあらかじめ確認することをお薦めします。手動で実行していない場合でも、製品のインストール中はインストーラによってバックグラウンドで実行されています。ただし、事前に手動で実行すると、インストールまたはアップグレード・プロセスを開始できる前に、管理リポジトリが設定されます。キットの詳細とその実行方法、実行される前提条件チェックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。
ただし、オラクル社提供のデータベース・テンプレートを使用して事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、EM前提条件キットの起動中に次のパラメータを渡します。

-componentVariables repository:EXECUTE_CHECKS_NOSEED_DB_FOUND:false

1. 次のレスポンス・ファイルをローカル・ホスト上のアクセス可能な場所にコピーします。
<Software_Location>/response/new_install.rsp

このコマンドの<Software_Location>は、DVDの場所またはソフトウェア・キットをダウンロードした場所です。

2. レスポンス・ファイルを編集し、表3-3に示された変数に適切な値を指定します。

3. インストーラを起動します。(Unixでは、必ず作成したoinstallグループに属するユーザーとしてインストーラを起動します。オペレーティング・システム・グループおよびユーザーの作成の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。)

- これがホストにインストールする最初のOracle製品である場合は、次のコマンドを実行します。
./runInstaller -silent -responseFile <absolute_path>/new_install.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

- 最初のOracle製品でない場合は、次のコマンドを実行します。
./runInstaller -silent -responseFile <absolute_path>/new_install.rsp

注意:

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- Enterprise Manager Cloud Controlソフトウェアをダウンロードして実行するディレクトリの名前に空白文字が含まれていないことを確認します。たとえば、EM Softwareという名前のディレクトリの場合、2つの語の間に空白文字が含まれているため、このディレクトリからはソフトウェアをダウンロードしないでください。

- runInstallerまたはsetup.exeを起動したときに、Enterprise Manager Cloud Controlインストール・ウィザードが表示されない場合は、ユーザーに/stage (Enterprise ManagerソフトウェアのDisk1ディレクトリにあるサブディレクトリ)への読取り/書込みアクセス権限がない可能性があります。
インストール・ウィザードは、クラスパス変数をOPatch用に../stage/Components/として処理します。TEMP変数が/tmpに設定されているとき、インストール・ウィザードはopatchのJARファイルを/tmp/../stageディレクトリ(/stageと同様)で検索しようとします。しかし、ユーザーに/stageへの読取り/書込み権限がないと、インストール・ウィザードはハングします。このような場合、/stageディレクトリへの読取り/書込みアクセス権があるかどうかを確認します。ない場合、TEMP変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

- オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合、選択したデプロイメント・サイズに合せるにはデータベース・パラメータを変更する必要があることを示すメッセージが表示されます。これは、テンプレートは基本的に簡易インストール用に設計され、データベース・パラメータは簡易インストールの要件に応じて設定されているためです。詳細インストールに使用する場合は、パラメータを別の値に設定する必要があります。メッセージを確認して続行します。インストール・ウィザードによって、自動的にパラメータが必要な値に設定されます。

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第3.4.2項を参照してください。

注意:

- 前提条件チェックがパッケージが不足していることを示して失敗した場合は、必要なパッケージをインストールしてインストールを再試行してください。インストーラによってパッケージ名およびバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールしてください。インストーラがこれらのパッケージの検証に使用するロジックを理解するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- リポジトリ関連の前提条件チェックに失敗した場合、手動でチェックを実行してください。手順は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEM前提条件キットに関する付録を参照してください。

- コンフィギュレーション・アシスタントに失敗した場合、インストーラが停止し、後続のコンフィギュレーション・アシスタントは実行されません。問題を解決して、コンフィギュレーション・アシスタントを再試行してください。詳細は、付録Jを参照してください。

3.4.2 サイレント・モードでEnterprise Managerシステムをインストールするためにサポートされている拡張インストーラ・オプション

インストーラの起動中に渡すことができる追加の拡張オプションの一部は、次のとおりです。

- デフォルトでは、デプロイメント・プロシージャに関連するソフトウェア・ライブラリ・エンティティをコピーするためにプロビジョニング・アドバイザ・フレームワーク(PAF)ステージング・ディレクトリが作成されます。デフォルトでは、この場所はスクラッチ・パスの場所(/tmp)です。この場所はプロビジョニングのアクティビティにのみ使用されます。エンティティはデプロイメント・プロシージャ用にコピーされ、デプロイメント・プロシージャが終了すると削除されます。
カスタムの場所でこの場所をオーバーライドする場合、EM_STAGE_DIRオプションを使用してインストーラを起動し、一意のカスタムの場所を入力します。

次に例を示します。

./runInstaller EM_STAGE_DIR=/home/john/software/oracle/pafdir -silent -responseFile <absolute_path>/new_install.rsp

- インストールが正常に終了すると、OMSおよび管理エージェントが自動的に起動されます。自動的に起動しない場合、START_OMSおよびb_startAgentオプションを使用してインストーラを起動し、制御する内容に応じてtrueまたはfalseに設定します。
たとえば、管理エージェントを自動的に起動しない場合、次のコマンドを実行します。

./runInstaller START_OMS=true b_startAgent=false -silent -responseFile <absolute_path>/new_install.rsp

この拡張オプションに関連する制限を理解するには、第3.4.3項を参照してください。

3.4.3 サイレント・モードでEnterprise Managerシステムをインストールするためにサポートされている拡張オプションに関する制限事項

拡張オプションとしてSTART_OMSおよびb_startAgentを使用してOMSおよび管理エージェントを自動的に起動する方法を制御する場合、管理エージェントおよび管理エージェントがインストールされたホストは、Cloud Controlコンソールのターゲットとして表示されないことがあります。

表3-2は、こうした拡張オプションの様々な組合せの一覧と、各組合せで従う対処方法を説明しています。

表3-2 拡張オプションおよび回避策

拡張オプション

回避策

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

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

3.4.4 サイレント・モードでEnterprise Managerをインストールするためのnew_install.rspレスポンス・ファイルの編集

表3-3は、編集する必要がある変数およびサイレント・モードでEnterprise Manager Cloud Controlをインストールするためのnew_install.rspレスポンス・ファイルでの編集方法を示しています。

表3-3 Enterprise Managerシステムをインストールするためのレスポンス・ファイルの編集

パラメータ

データ型

値に二重引用符が必要かどうか

説明

UNIX_GROUP_NAME

文字列

はい

(中央インベントリが存在しない場合にのみ必須)所属するUNIXグループの名前を入力します。

たとえば、"dba"などです。

注意: このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

INVENTORY_LOCATION

文字列

はい

(中央インベントリが存在しない場合にのみ必須)中央インベントリへの絶対パスを入力します。デフォルトのインベントリ・ディレクトリに対して読取り、書込み権限および実行権限があることを確認します。

たとえば、"/scratch/oracle/oraInventory"などです。

注意: このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

SECURITY_UPDATES_VIA_MYORACLESUPPORT

ブール

いいえ

- セキュリティ更新をダウンロードしてインストールする場合は、TRUEを入力します。続いて、次の変数に資格証明を二重引用符で囲んで入力します。
MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

- セキュリティ更新をダウンロードしてインストールする場合は、FALSEを入力します。

DECLINE_SECURITY_UPDATES

ブール

いいえ

- セキュリティ更新を拒否する場合は、TRUEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにFalseを入力する必要があります。

- セキュリティ更新を拒否しない場合は、FALSEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにTRUEを入力する必要があります。

INSTALL_UPDATES_SELECTION

文字列

はい

この変数はデフォルトで、インストール中にソフトウェア更新がインストールされないことを示す"skip"に設定されています。

- My Oracle Supportからソフトウェア更新をインストールする場合、この変数を"download"に設定します。続いて、次のパラメータに資格証明を二重引用符で囲んで入力します。
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- ステージングされた場所からソフトウェア更新をインストールする場合、この変数を"staged"に設定します。続いてSTAGE_LOCATIONパラメータには、ソフトウェア更新が含まれるUpdatesディレクトリまで含めた絶対パスを二重引用符で囲んで入力します。

PROXY_USER

文字列

はい

プロキシ・サーバーにアクセスするために使用できるユーザー名を入力します。

注意: SECURITY_UPDATES_VIA_MYORACLESUPPORT変数をTRUEに設定しているか、INSTALL_UPDATES_SELECTION変数を"download"に設定している場合およびインターネット接続でプロキシ経由の接続が必要な場合のみ適用されます。

PROXY_PWD

文字列

はい

プロキシ・サーバーにアクセスするために使用できるパスワードを入力します。

注意: SECURITY_UPDATES_VIA_MYORACLESUPPORT変数をTRUEに設定しているか、INSTALL_UPDATES_SELECTIONパラメータを"download"に設定している場合およびインターネット接続でプロキシ経由の接続が必要な場合のみ適用されます。

PROXY_HOST

文字列

はい

プロキシ・ホストの名前を入力します。

注意: SECURITY_UPDATES_VIA_MYORACLESUPPORT変数をTRUEに設定しているか、INSTALL_UPDATES_SELECTIONパラメータを"download"に設定している場合およびインターネット接続でプロキシ経由の接続が必要な場合のみ適用されます。

PROXY_PORT

文字列

はい

プロキシ・サーバーで使用されるポートを入力します。

注意: SECURITY_UPDATES_VIA_MYORACLESUPPORT変数をTRUEに設定しているか、INSTALL_UPDATES_SELECTIONパラメータを"download"に設定している場合およびインターネット接続でプロキシ経由の接続が必要な場合のみ適用されます。

ORACLE_MIDDLEWARE_HOME_LOCATION

文字列

はい

インストーラでOracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0.をインストールする場所を入力します。

たとえば、"/u01/app/Oracle/Middleware"などです。

ミドルウェアの場所に書込み権限があることを確認します。

すでに手動でインストールしている場合、インストールした場所を入力します。また、Oracle WebLogic Serverにパッチ14482558、13349651、16080294および16888501を適用していることを確認してください。これらのパッチを適用していないと、追加のOMSのインストールが失敗します。

これらのパッチを適用する手順については、次のURLを参照してください。

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

Oracleミドルウェア・ホームの詳細は、第2.3.2項を参照してください。

注意: ミドルウェア・ホームのパスの文字数が、Unixプラットフォームでは70文字、Microsoft Windowsプラットフォームでは25文字を超えていないことを確認してください。

たとえば、15文字のみを含むミドルウェア・ホームのパスC:\Oracle\MW\EMは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

ORACLE_HOSTNAME

文字列

はい

DNSに登録されており、他のネットワーク・ホストからアクセスできる完全修飾ドメイン名を入力します。または、このサイトのすべてのOMSインスタンスについて/etc/hostsファイルに定義されている別名ホスト名を入力します。

ホスト名はローカルのOracle WebLogic ServerおよびOracle Management Serviceに使用されるため、ホスト名はローカル・ホストに対して解決する必要があります。このフィールドには、リモート・ホストやロード・バランサ仮想ホストを指定しないでください。IPアドレスは入力しないでください。名前にアンダースコアを使用しないでください。省略名は可能ですが、警告が表示されます。このため、かわりに完全修飾ドメイン名を入力することをお薦めします。

ホスト名を指定しない場合、インストール・ウィザードは自動的に検出したホスト名をそのホストの名前として使用して続行します。

AGENT_BASE_DIR

文字列

はい

管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。

たとえば、"/oracle/agent"です。

この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

注意: (Microsoft Windowsのみ)エージェント・ベース・ディレクトリのパスの文字数が、25文字を超えていないことを確認してください。たとえば、16文字のみを含むエージェント・ベース・ディレクトリのパスC:\Oracle\Agent\は、使用できます。ただし、25を超える文字を含むC:\Oracle\ManagementAgent\12c\newは、使用できません。

WLS_ADMIN_SERVER_USERNAME

文字列

はい

デフォルトでは、weblogicは、Oracle WebLogicドメインに作成されているデフォルトのユーザー・アカウントに割り当てられた名前です。デフォルトの名前を受け入れる場合は、この変数をスキップします。ただし、カスタム名を使用する場合は、任意の名前を入力します。

WLS_ADMIN_SERVER_PASSWORD

文字列

はい

WebLogicユーザー・アカウントのパスワードを入力します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

文字列

はい

WebLogicユーザー・アカウントのパスワードを確認します。

NODE_MANAGER_PASSWORD

文字列

はい

デフォルトでは、nodemanagerは、ノード・マネージャに作成されているデフォルトのユーザー・アカウントに割り当てられた名前です。このノード・マネージャのユーザー・アカウントのパスワードを入力します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

NODE_MANAGER_CONFIRM_PASSWORD

文字列

はい

ノード・マネージャのユーザー・アカウントのパスワードを確認します。

ORACLE_INSTANCE_HOME_LOCATION

文字列

はい

デフォルトでは、gc_instがすべてのOMS関連構成ファイルを格納するためのOMSインスタンス・ベース・ディレクトリとしてみなされます。ミドルウェア・ホーム外の場所のこのディレクトリ名への絶対パスを入力します。

この場所の詳細は、第2.3.3項を参照してください。

注意: NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。手順については、第3.5項を参照してください。

CONFIGURE_ORACLE_SOFTWARE_LIBRARY

ブール

いいえ

インストール時にソフトウェア・ライブラリを構成するには、このパラメータをTRUEに設定します。それ以外の場合には、FALSEに設定します。

インストール時に構成しない場合でも、インストールは成功し、後ほどEnterprise Manager Cloud Controlコンソールからいつでも構成できます。ただし、インストーラによって自動的に構成が行われ、時間と労力を省くことができるため、インストール時にソフトウェア・ライブラリ構成することをお薦めします。

SOFTWARE_LIBRARY_LOCATION

文字列

はい

CONFIGURE_ORACLE_SOFTWARE_LIBRARYをTRUEに設定した場合、ソフトウェア・ライブラリを構成できるOMSホスト上に、一意のディレクトリ名となる絶対パスを入力します。入力する場所はOMSホスト上にマウントされた場所で、ミドルウェア・ホーム外であることを確認してください。また、OMSプロセスの所有者にその場所に対する読取り/書込みアクセス権があることも確認してください。マウントされた場所で構成を行うと、追加のOMSインスタンスのインストール時に役立ちます(インスタンスが、同じOMS共有ファイルシステムの記憶域の場所への読取り/書込みアクセス権を必要とするため)。

DATABASE_HOSTNAME

文字列

はい

既存のデータベースが常駐するホストの完全修飾名を入力します。ホスト名にアンダースコアがないことを確認します。

たとえば、"example.com"です。

オラクル社提供のdデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスをすでに作成している場合は、そのデータベース・インスタンスの詳細を指定します。

Oracle RAC Databaseに接続する場合、ノードに仮想ホスト名が含まれていれば、ノードの1つの仮想ホスト名を指定します。

この仮想ホスト名のみで構成された接続文字列を使用してデータベースへの接続が確立され、インストールは正常に終了します。

ただし、クラスタの他のノードの接続文字列を更新する場合、インストール後に次のコマンドを実行します。

$<OMS_HOME>/bin/emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))" -repos_user sysman

単一クライアント・アクセス名(SCAN)リスナーを使用するようOracle RACデータベース11.2以上が構成されている場合、SCANリスナーを使用した接続文字列を入力できます。

注意: オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、SYSMAN_PASSWORDパラメータに入力したSYSMANパスワードで自動的にリセットされます。

LISTENER_PORT

文字列

はい

既存のデータベースに接続するためのリスナー・ポートを入力します。

たとえば、"1521"です。

SERVICENAME_OR_SID

文字列

はい

既存のデータベースのサービス名またはシステムID (SID)を入力します。

たとえば、"orcl"などです。

SYS_PASSWORD

文字列

はい

SYSユーザー・アカウントのパスワードを入力します。

SYSMAN_PASSWORD

文字列

はい

SYSMANユーザー・アカウントを作成するパスワードを入力します。このパスワードは、SYSMANユーザー(管理リポジトリ・スキーマのプライマリ所有者)を作成する場合に使用します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、このパラメータに入力したSYSMANパスワードで自動的にリセットされます。

SYSMAN_CONFIRM_PASSWORD

文字列

はい

SYSMANユーザー・アカウントのパスワードを確認します。

DEPLOYMENT_SIZE

文字列

はい

次のいずれかの値を設定して、監視予定のターゲットの数、予定している管理エージェント数および予定している同時ユーザー・セッション数を示します。

- SMALL監視対象ターゲット数: 最大999、管理エージェント数: 最大99、同時ユーザー・セッション数: 最大10

- MEDIUM監視対象ターゲット数: 約1000から9999、管理エージェント数: 約100から999、同時ユーザー・セッション数: 約10から24

- LARGE監視対象ターゲット数: 10,000以上、管理エージェント数: 1000以上、同時ユーザー・セッション数: 約25から50

たとえば、"MEDIUM"です。

前提条件チェックは選択内容に関係なく実行されますが、様々なパラメータに設定される値は、選択内容に応じてチェックされます。

デプロイメント・サイズはインストール後に変更することも可能です。デプロイメント・サイズ、実行する前提条件チェック、設定するデータベース・パラメータ、およびインストール後にデプロイメント・サイズを変更する方法の詳細は、第2.1.6項を参照してください。

注意:

接続しているデータベースが、オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリで作成されたデータベース・インスタンスの場合、ここで選択したデプロイメント・サイズが、データベース・インスタンスの作成中にOracle Database Configuration Assistant (DBCA)の手順2/12「データベース・テンプレート」画面で選択したデプロイメント・サイズと一致するようにしてください。

DBCAを使用したデータベース・インスタンスの作成中に選択したデプロイメント・サイズとは異なるデプロイメント・サイズを選択する場合、次のいずれかを行います。

- 希望のデプロイメント・サイズのテンプレートで別のデータベース・インスタンスを作成し、このレスポンス・ファイルに戻り、同じデプロイメント・サイズをこのパラメータに設定します。オラクル社提供のテンプレートでデータベース・インスタンスを作成する手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 作成したデータベース・インスタンスにおいて、ここで設定するデプロイメント・サイズをレスポンス・ファイルでサポートするように、パラメータを修正します。オラクル社提供のSQL文を使用して自動的にデータベース・パラメータを修正するにはには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

MANAGEMENT_TABLESPACE_LOCATION

文字列

はい

管理表領域用のデータ・ファイル(mgmt.dbf)を格納できる場所の絶対パスを入力します。指定したパスには、ファイル名までを含めます。

次に例を示します。

- データベースがファイルシステム上にある場合、パスは"/u01/oracle/prod/oradata/mgmt.dbf"のようになります。

- データベースが自動ストレージ管理(ASM)上にある場合、パスは"+DATA/oemrsp01d/datafile/mgmt.dbf"のようになります。ここで、disk_group1はASM上に作成されるディスクグループで、prodはサービスID (SID)です。

- データベースがRAWデバイス上にある場合、パスは"</dev/raw1>/prod/oradata/mgmt.dbf"のようになります。ここで、/dev/raw1はRAWデバイスで、prodはSIDです。

Enterprise Manager Cloud Controlでは、監視対象ターゲットやそのメトリックなどに関する情報を格納するためにこのデータ・ファイルが必要です。基本的に、構成データ、ソフトウェア・ライブラリ・データおよび監査データ以外の情報はすべてこのデータ・ファイルに格納されます。

CONFIGURATION_DATA_TABLESPACE_LOCATION

文字列

はい

構成データ表領域用のデータ・ファイル(mgmt_ecm_depot1.dbf)を格納できる場所の絶対パスを入力します。指定したパスには、ファイル名までを含めます。

たとえば、"/home/john/oradata/mgmt_ecm_depot1.dbf"などです。

Enterprise Manager Cloud Controlでは、監視対象ターゲットから収集された構成情報を格納するためにこのデータ・ファイルが必要です。

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

文字列

はい

JVM診断データ表領域のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所の絶対パスを入力します。指定したパスには、ファイル名までを含めます。

たとえば、"/home/john/oradata/mgmt_deepdive.dbf"などです。

Enterprise Manager Cloud Controlでは、JVM診断およびアプリケーション依存性とパフォーマンス(ADP)に関連する監視データを格納するために、このデータ・ファイルが必要です。

AGENT_REGISTRATION_PASSWORD

文字列

はい

OMSと管理エージェントの間の通信を保護するには、パスワードを入力します。管理エージェントを保護するためのパスワードと同じ登録パスワードを入力する必要があります。

AGENT_REGISTRATION_CONFIRM_PASSWORD

文字列

はい

エージェント登録パスワードを確認します。

STATIC_PORTS_FILE

文字列

はい

デフォルトでは、第2.1.10項で説明されているポートが適用されます。デフォルトのポートを受け入れる場合は、このフィールドを空白のままにしておきます。

カスタム・ポートを使用する場合、インストールに使用されるカスタム・ポートをリストしているstaticports.iniファイルの絶対パスを入力します。

PLUGIN_SELECTION

文字列リスト

はい

(プラグイン名のカンマで区切ったリスト、プラグイン名は二重引用符で囲む必要があります)

Oracle Database管理プラグイン、Oracle Fusion Middleware管理プラグイン、My Oracle Support管理プラグイン、Oracle Exadata管理プラグインなどの必須のプラグインがEnterprise Managerシステムに自動的にインストールされます。

ただし、ソフトウェア・キット(DVDまたはダウンロードしたソフトウェア)に含まれているその他のオプションのプラグインをインストールする場合は、この変数にプラグインのIDを入力します。

次に例を示します。

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

ソフトウェア・キットで利用できないプラグインをインストールする場合、次の手順を実行します。

1. OTNのEnterprise Managerダウンロード・ページからプラグインを手動でダウンロードして、アクセス可能な場所に格納します。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. ダウンロードしたプラグインの名前でこの変数(PLUGIN_SELECTION)を更新します。

3. 次のオプションでインストーラを起動して、プラグインをダウンロードした場所を渡します。
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

3.5 サイレント・モードでEnterprise Managerシステムをインストールした後のインストール後のタスクの実行

Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章に示されているインストール後の手順を実行します。

4 ソフトウェアのみの方法を使用したEnterprise Managerのインストール

この章では、Enterprise Manager Cloud Controlのソフトウェア・バイナリのみインストールして、後でインストールを構成する方法について説明します。この章の具体的な内容は次のとおりです。

- ソフトウェアのみの方法を使用したEnterprise Managerのインストールの概要

- ソフトウェアのみの方法を使用したEnterprise Managerのインストールを開始する前に

- ソフトウェアのみの方法を使用してEnterprise Managerをインストールするための前提条件

- ソフトウェアのみの方法を使用したEnterprise Managerのインストール

注意:
OCFS2やACFSを含むすべての汎用ファイル・システムに、Enterprise Manager Cloud Control 12cのソフトウェア・バイナリおよびOMSインスタンス・ホーム・ファイル(gc_inst内の構成ファイル)を格納できます。ただし、OCFSは汎用ファイルシステムとみなさないため、このような用途での使用は考慮されていません。

警告:

Enterprise Manager Cloud Control 12cを、SPARCシリーズのサーバー(T1000、T2000、T5xx0およびT3-*)にインストールしないでください。詳細は、My Oracle Supportのノート1590556.1を参照してください。

4.1 ソフトウェアのみの方法を使用したEnterprise Managerのインストールの概要

Enterprise Manager Cloud Controlのソフトウェア・バイナリのみインストールして、既存の動作保証済Oracle Databaseで動作するよう後で構成できます。この方式では、インストール・プロセスを主にインストール・フェーズと構成フェーズの2つのフェーズに分割できます。当然のことながら、インストール・フェーズは、バイナリのコピーのみなので、構成フェーズに比べて時間はかかりません。この方式により、時間と優先度に従ってインストールを計画できます。

インストール・フェーズの実行中、インストーラを起動してOracleホームを作成し、ミドルウェア・ホームに次のコンポーネントをインストールします。

- Java Development Kit(JDK)1.6.0.43.0

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

- Oracle Management Service 12c

- Oracle Management Agent 12c

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

注意:
Oracle BI Publisher 11g (11.1.1.7)はデフォルトでインストールされますが、構成されません。インストール後に構成するには、『Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の手順に従ってください。

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

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

注意:

- Java Development Kit (JDK) 1.6.0.43.0およびOracle WebLogic Server 11gリリース1 (10.3.6)は、既存のインストールの使用を指定しない場合にのみインストールされます。Enterprise Manager 12cと使用するためにJDKおよびOracle WebLogic Serverをインストールするには、12cのインストール・プロセスを使用することを強くお薦めします。

- Oracle WebLogic Server 11gリリース1 (10.3.6)を手動でインストールする場合、第4.2項に示されているガイドラインに従います。

構成フェーズの実行中、構成スクリプトを起動して、次の手順を実行します。

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

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

注意:
Microsoft Windowsでは、ノード・マネージャ・サービスは作成されません。これは予測されている動作です。

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

- 既存の動作保証済Oracle DatabaseのOracle Management Repositoryを構成します。

- 次のプラグインをデプロイおよび構成します。

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

- Oracle Fusion Middleware管理プラグイン

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

- Oracle Exadata管理プラグイン

- Oracle Cloud Frameworkプラグイン

注意:
前述の必須のプラグイン以外に、ソフトウェア・キットで利用できる他のプラグインをオプションでインストールできます。オプションのプラグインを選択してインストールできる画面がインストーラで用意されています。ただし、ソフトウェア・キットで利用できない一部のプラグインをインストールする場合、第4.4.1.3.1項の追加プラグインのインストールに関する点を参照してください。

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

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

- リポジトリ構成

注意:
オラクル社提供のデータベース・テンプレートを使用し、事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、リポジトリ・コンフィギュレーション・アシスタントのかわりに、リポジトリ即時使用可能コンフィギュレーション・アシスタントが実行されます。

- MDSスキーマ構成

- OMS構成

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

- Oracle Management Serviceの起動

- Oracle Configuration Managerリピータ構成

- エージェント・コンフィギュレーション・アシスタント

4.2 ソフトウェアのみの方法を使用したEnterprise Managerのインストールを開始する前に

開始する前に、次のことに注意してください。

- Enterprise Manager Cloud Controlソフトウェアが最新であることを確認します。
最新のソフトウェアをダウンロードするには、次のURLにアクセスします。

http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html

最新のソフトウェアのダウンロードの詳細は、第1.2.2項を参照してください。

- Enterprise Manager Cloud Controlソフトウェアをダウンロードして実行するディレクトリの名前に空白文字が含まれていないことを確認します。たとえば、EM Softwareという名前のディレクトリの場合、2つの語の間に空白文字が含まれているため、このディレクトリからはソフトウェアをダウンロードしないでください。

- ウィザードが起動されるローカルのサーバーの単一ホストにのみ、インストール・ウィザードを使用してEnterprise Manager Cloud Controlをインストールできます。リモート・ホストにはインストールできません。

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

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

表 4-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 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_HOMEおよびORACLE_SID環境変数は設定しないでください。OracleディレクトリがPATHに表示されていないことを確認する必要があります。

- symlinkにインストールしないでください。このような場所にインストールすると、パッチ適用やスケール・アウトなどのライフ・サイクル操作に影響が及ぶ場合があります。

- Enterprise Manager Cloud Controlインストール・ウィザードはJava Development Kit (JDK) 1.6.0.43.0およびOracle WebLogic Server 11gリリース1 (10.3.6)をインストールしますが、既存のインストールの使用を指定しない場合のみです。Enterprise Manager 12cと使用するためにJDKおよびOracle WebLogic Serverをインストールするには、12cのインストール・プロセスを使用することを強くお薦めします。

- (グラフィック・モードのみ)DISPLAY環境変数を設定する必要があります。

- bash端末で、次のコマンドを実行します。
export DISPLAY=<hostname>:<vnc port>.0

たとえば、export DISPLAY=example.com:1.0です。

- 他の端末で、次のコマンドを実行します。
setenv DISPLAY <hostname>:1.0

たとえば、setenv DISPLAY example.com:1.0です。

- 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をダウンロードしてください。
たとえば、次のOracle WebサイトのURLからLinuxプラットフォーム用のSUN JDK 1.6.0.43.0をダウンロードします。

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

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

32ビットJDKまたは64ビットJDKかどうかを確認するには、次のコマンドを実行します。

"file *"

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

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

<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インストレーション・ガイド』に示されている手順に従う必要があります。このガイドは、次の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および16888501を適用します。これらのパッチを適用していないと、追加のOMSのインストールが失敗します。
これらのパッチを適用する手順については、次のURLを参照してください。

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

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

- オプションで、オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスを作成できます。これを行うには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。
ただし、データベース・テンプレートは詳細インストールに使用できますが、基本的には簡易インストール用に設計されています。このため、詳細インストール(通常は小、中または大のデプロイメント・サイズを選択)を実行中に、このようなデータベースの詳細を指定すると、選択したデプロイメント・サイズに合せるにはデータベース・パラメータを変更する必要があることを示すメッセージが表示されます。メッセージを確認して続行します。インストール・ウィザードによって自動的にデータベース・パラメータが必要な値に設定されます。

- 高可用性または障害時リカバリ構成でインストールしているか、将来これらの構成に変換する場合、このインストールを続ける前に、第16章、第17章、第18章の内容を確認してその理解を深めてください。
前述の各章の情報を確認したら、第17章に記載されているベスト・プラクティス、特に第17.3.1項の情報に従い、高可用性または障害時リカバリ用としてインストールを最適な状態で準備できるようにしてください。

- 管理リポジトリの構成を予定しているOracle Database上のXML DBなどの機能を有効または無効にしても、Enterprise Managerには影響されません。したがって、Enterprise Managerはデータベース内の任意の機能に依存していないため、それらを有効または無効にできます。

- オプションで、管理リポジトリのデプロイに関する構成ガイドラインに従って、管理データの安全性、信頼性および可用性を確保するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- (サイレント・モードのみ)デフォルトでは、レスポンス・ファイル内のINSTALL_UPDATES_SELECTION変数が"skip"に設定されているため、インストール中にソフトウェア更新を適用することはできません。インストール中にソフトウェア更新を適用する必要がある場合は、第4.4.2.1.1項の説明に従ってこの変数を変更します。

- NFSマウントされたドライブにインストール中で、OMSインスタンス・ベース・ディレクトリ(gc_inst)をNFSマウントされたドライブに作成している場合、インストール後に、ロック・ファイルをNFSマウントされたドライブからローカルのファイル・システムの場所に移動します。httpd.confファイルのロック・ファイルの場所を変更し、ローカルのファイルシステムの場所にマップします。手順は、採用したアプローチに応じて第4.4.1.4項または第4.4.2.4項を参照してください。

- デフォルトでは、第2.1.10項に示されているアップロード・ポートおよびコンソール・ポートが使用されます。

- Oracleでは、Oracleライフタイム・サポート・ポリシーに基づき、製品のバグ修正を提供しています。製品ライセンスの有効期限が切れると、Oracleによって提供されるバグ修正のサポートも終了します。詳細は、次のURLで入手可能なOracleライフタイム・サポート・ポリシーを参照してください。
http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

Enterprise Manager Cloud Controlインストールのサポート可能性および動作保証の組合せを決定する場合、Enterprise Manager Cloud Controlのフレームワーク・コンポーネントおよびEnterprise Manager Cloud Controlで監視されるターゲットを考慮する必要があります。Extended Supportライセンスを購入する必要なくコード修正を入手するには、Cloud Controlコンポーネントとターゲットを最新の動作保証済バージョンに常に更新しておくことをお薦めします。

- HPUNIX、HPia64、Solaris Sparc以外のすべてのUNIXプラットフォームの/etc/oragchomelistファイルのOMSおよび管理エージェント・エントリを見つけることができます。
HPUNIX、HPia64、Solaris Sparcプラットフォームでは、エントリが/var/opt/oracle/oragchomelistにあります。

- 前提条件として、管理リポジトリを構成するためのOracle Databaseがすでに存在する必要があります。このデータベースの自動メモリー管理(AMM)機能は有効でもかまいません。

- ロケール固有のデータは、<OMS_Oracle_Home>/nls/dataディレクトリに格納されます。環境変数ORA_NLS10を<OMS_Oracle_Home>/nls/dataに設定するか、まったく設定しないことを強くお薦めします。

- OMSと管理リポジトリを格納するOracle Databaseとを同じホストにインストールした場合、ホストを再起動するときに、それとともにインストールされたOMSおよび管理エージェントは自動的に起動しません。これらは手動で起動する必要があります。

4.3 ソフトウェアのみの方法を使用してEnterprise Managerをインストールするための前提条件

Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章に示されている前提条件を満たしてください。

4.4 ソフトウェアのみの方法を使用したEnterprise Managerのインストール

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

- グラフィック・モードでのソフトウェアのみの方法を使用したEnterprise Managerのインストール

- サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Managerのインストール

4.4.1 グラフィック・モードでのソフトウェアのみの方法を使用したEnterprise Managerのインストール

この項では、グラフィック・モードでEnterprise Manager Cloud Controlのソフトウェア・バイナリのみインストールして、後でインストールを構成する方法について説明します。この項の具体的な内容は次のとおりです。

- Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリのインストール(グラフィック・モード)

- rootスクリプトの実行

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

- グラフィック・モードでのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリの構成後の構成後タスクの実行

注意:
Enterprise Managerシステムのインストールを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を確認して2014年9月と10月および2015年1月にリリースされたプラグインを学習し、このプラグイン・リリースに関するユースケースを理解することをお薦めします。現在の要件に最適な事例を確認し、表の使用例に示される詳細な手順に従ってください。

4.4.1.1 Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリのインストール(グラフィック・モード)

グラフィック・モードでEnterprise Manager Cloud Controlのソフトウェア・バイナリのみをインストールするには、次の手順を実行します。

注意:
インストーラを起動する前にEM前提条件キットを実行し、リポジトリの前提条件をすべて満たしていることをあらかじめ確認することをお薦めします。手動で実行していない場合でも、製品のインストール中はインストーラによってバックグラウンドで実行されています。ただし、事前に手動で実行すると、インストールまたはアップグレード・プロセスを開始できる前に、管理リポジトリが設定されます。キットの詳細とその実行方法、キットで実行される前提条件チェックについては、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。
ただし、オラクル社提供のデータベース・テンプレートを使用して事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、EM前提条件キットの起動中に次のパラメータを渡します。

-componentVariables repository:EXECUTE_CHECKS_NOSEED_DB_FOUND:false

1. Enterprise Manager Cloud Controlインストール・ウィザードの起動
インストーラを起動します。(Unixでは、必ず作成したoinstallグループに属するユーザーとしてインストーラを起動します。オペレーティング・システム・グループおよびユーザーの作成の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。)

<Software_Location>/runInstaller [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- このコマンドの<Software_Location>は、DVDまたはソフトウェア・キットをダウンロードした場所を指しています。

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第4.4.1.1.1項を参照してください。

注意:
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. (オプション)「My Oracle Supportの詳細」に入力します。

「My Oracle Supportの詳細」画面で、My Oracle Support資格証明を入力し、Oracle Configuration Managerを有効にします。Oracle Configuration Managerをここで有効にしない場合、手順(3)に進みます。

インストール・ウィザードを実行しているホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。

注意:
手動で構成情報を収集およびMy Oracle Supportにアップロードする方法の詳細は、第2.1.4.1項を参照してください。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Supportからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを指定するか、My Oracle SupportにアクセスするクライアントからこのURLへのプロキシ・アクセスを付与する必要があることを意味します。

3. 「次へ」をクリックします。

4. (推奨)ソフトウェア更新をインストールします。

「ソフトウェアの更新」画面で、「更新の検索」を選択し、次のいずれかのオプションを選択して最新のソフトウェア更新を適用します。

- インターネットに接続されていないホストで、オフラインモードでアップデートをダウンロードし、インストールの実行中にこれらを適用する場合は、ローカル・ディレクトリを選択します。

- インターネットに接続されているホストで、インストーラを介してMy Oracle Supportに直接接続してオンライン・モードでアップデートをダウンロードし、インストールの実行中にこれらを適用する場合は、My Oracle Supportを選択します。

これらのオプションの詳細、およびこれらのオプションを使用したソフトウェア更新のダウンロードと適用の手順は、第2.1.5.6項を参照してください。

注意:
この「ソフトウェアの更新」画面は、組込みの機能であるソフトウェア更新を使用して、Enterprise Manager Cloud Controlのインストールまたはアップグレード中に最新の推奨パッチを自動的にダウンロードしてデプロイできます。この方法では、オラクル社によってリリースされるパッチの手動チェックを継続する必要はありません。正常なインストールおよびアップグレードのためにインストーラによって必要とされるすべてのパッチが、My Oracle Supportで検出されてダウンロードされ、インストールまたはアップグレード中に適用されるため、既知の問題や潜在的な失敗が減少します。インストールの進行中にこの機能を使用してソフトウェア更新を適用することを強くお薦めします。詳細は、2.1.5.1項を参照してください。

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インベントリ」画面で、次のようにします。このホストでの最初のOracle製品のインストールであると特定された場合のみ、この画面が表示されます。

1. インベントリ・ファイルおよびディレクトリを配置するディレクトリへのフルパスを入力します。

注意:

- これがホスト上で最初のOracle製品である場合、デフォルトのセントラル・インベントリの場所は<home directory>/oraInventoryになります。ただし、すでにOracle製品がホスト上にある場合、中央インベントリの場所は、oraInst.locファイルで参照できます。oraInst.locファイルは、LinuxおよびAIXの場合/etcディレクトリに、Solaris、HP-UXおよびTru64の場合/var/opt/oracleディレクトリにあります。

- デフォルトのインベントリ・ディレクトリに対して読取り、書込み権限および実行権限があることを確認します。必要な権限がない場合、インストーラを終了してからINVENTORY_LOCATIONパラメータでこのインストーラを再起動し、別のインベントリの場所への絶対パスを渡します。
次に例を示します。

<Software_Location>/runInstaller INVENTORY_LOCATION=<absolute_path_to_inventory_directory>

または、-invPtrLocパラメータでインストーラを起動し、別のインベントリの場所を含むoraInst.locファイルに絶対パスを渡します。

次に例を示します。

<Software_Location>/runInstaller -invPtrLoc <absolute_path_to_oraInst.loc>

ただし、これらのパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされないことに注意してください。

2. Oracleインベントリ・ディレクトリを所有する適切なオペレーティング・システム・グループ名を選択します。選択するグループは、そのOracleインベントリ・ディレクトリに対する書込み権限を持っている必要があります。

7. 「次へ」をクリックします。

8. 前提条件の確認

「前提条件チェック」画面で、インストール・ウィザードで実行される前提条件チェックのステータスを確認し、インストールが成功するすべての最小要件を満たしている環境かどうかを確認します。

インストール・ウィザードでは、この画面に達すると前提条件チェックが自動的に実行されます。必要なオペレーティング・システム・パッチ、オペレーティング・システム・パッケージなどがチェックされます。

前提条件チェックのステータスは、「警告」、「失敗」または「成功」のいずれかになります。

- 一部のチェックで「警告」ステータスまたは「失敗」ステータスになった場合は、インストールを続行する前に、問題を調査して修正してください。前提条件を満たさなかった理由と解決方法の詳細が画面に表示されます。問題を修正した後、この画面に戻り、「再実行」をクリックして前提条件を再度チェックします。

- ただし、先に進む前に、すべてのパッケージ要件を満たすか、修正する必要があります。そうしないと、インストールに失敗する場合があります。

9. 「次へ」をクリックします。

注意:
前提条件チェックがパッケージが不足していることを示して失敗した場合は、必要なパッケージをインストールして、「再実行」をクリックしてください。インストール・ウィザードによってパッケージ名およびバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールしてください。インストール・ウィザードがこれらのパッケージの検証に使用するロジックを理解するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

10. インストール・タイプの選択

「インストール・タイプ」画面で、「ソフトウェアのみインストール」を選択します。

11. 「次へ」をクリックします。

12. 「インストールの詳細」の入力
「インストールの詳細」画面で、次のようにします。

1. OMSおよび他のコア・コンポーネントをインストールするミドルウェア・ホームを入力するか、検証します。

注意:

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0がすでに使用環境にインストールされている場合は、インストーラがそれらを自動的に検出し、それらがインストールされているミドルウェア・ホームへの絶対パスを表示します。この場合、デフォルトで検出および表示されるミドルウェア・ホームの場所を検証します。場所が正しくない場合、正しい場所のパスを入力します。選択または入力するミドルウェア・ホームの場所が、Oracleホームのないミドルウェア・ホームの場所であることを確認してください。
また、Oracle WebLogic Serverにパッチ14482558、13349651、16080294および16888501を適用していることを確認してください。これらのパッチを適用していないと、追加のOMSのインストールが失敗します。

これらのパッチを適用する手順については、次の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

- Oracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0が使用環境にまだインストールされていない場合、Enterprise Managerシステムのインストール中にインストーラが自動的にインストールします。この場合、それらをインストールするディレクトリの絶対パスを入力します。たとえば、/oracle/software/などです。入力するディレクトリにファイルまたはサブディレクトリが含まれていないことを確認してください。

- ミドルウェア・ホームのパスの文字数が、Unixプラットフォームでは70文字、Microsoft Windowsプラットフォームでは25文字を超えていないことを確認してください。
たとえば、15文字のみを含むミドルウェア・ホームのパスC:\Oracle\MW\EMは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

2. 管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、エージェント・ベース・ディレクトリは/u01/app/Oracle/agent12cと指定できます。
この場所が空で、書込み権限があることを確認してください。また、常に、ミドルウェア・ホーム外で管理されるようにしてください。

注意:
ミドルウェア・ホームのパスの文字数が、Unixプラットフォームでは70文字、Microsoft Windowsプラットフォームでは25文字を超えていないことを確認してください。
たとえば、15文字のみを含むミドルウェア・ホームのパスC:\Oracle\MW\EMは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

3. OMSを構成するホストの名前を確認します。
ホストが仮想マシンを使用して構成されている場合は、ホスト名は完全修飾名または仮想ホスト名で表示されます。ORACLE_HOSTNAMEの値を指定してインストール・ウィザードを起動した場合、このフィールドにはその名前が事前に移入されます。

デフォルトのホスト名を受け入れます。あるいは、DNSに登録されており、他のネットワーク・ホストからアクセスできる完全修飾ドメイン名を入力するか、このサイトのすべてのOMSインスタンスについて/etc/hostsファイルに定義されている別名ホスト名を入力します。

注意:
ホスト名はローカルのOracle WebLogic ServerおよびOracle Management Serviceに使用されるため、ホスト名はローカル・ホストに対して解決する必要があります。このフィールドには、リモート・ホストやロード・バランサ仮想ホストを指定しないでください。IPアドレスは入力しないでください。名前にアンダースコアを使用しないでください。省略名は可能ですが、警告が表示されます。このため、かわりに完全修飾ドメイン名を入力することをお薦めします。

13. 「次へ」をクリックします。

14. 確認およびインストール
「確認」画面で、選択したインストール・タイプに指定した詳細を確認します。

- 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

- 詳細を確認し問題がない場合、「インストール」をクリックしてインストール・プロセスを開始します。

15. 進行状況の追跡
「インストールの進行状況」画面で、インストール全体の進行状況(パーセント表示)を確認します。

16. インストールの終了
「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。

4.4.1.1.1 グラフィック・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアのインストール中の拡張インストーラ・オプションの使用

インストーラの起動中に渡すことができる追加の拡張オプションの一部は、次のとおりです。

- WebLogicドメインの作成に使用されるデフォルト名は、GCDomainです。これをオーバーライドしてカスタムのWebLogicドメイン名を使用するには、WLS_DOMAIN_NAMEオプションでインストール・ウィザードを呼び出し、一意のカスタム名を入力します。

注意:
第4.4.1.3項の説明に従って、ソフトウェア・バイナリを構成するためにConfigureGC.shを起動する場合でも、必ずWLS_DOMAIN_NAMEオプションを使用してください。

たとえば、カスタム名EMDomainを使用する場合、次のコマンドを実行します。

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh WLS_DOMAIN_NAME=EMDomain

- 中央インベントリを設定する場合、-invPtrLocパラメータを渡します。このパラメータでは、インベントリ・ポインタ・ファイル(oraInst.loc)のある場所のパスが考慮されます。ただし、このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。
次に例を示します。

./runInstaller -invPtrLoc /scratch/OracleHomes/oraInst.loc -silent -responseFile <absolute_path_response_file>

- ソフトウェア・バイナリをインストールした後、バイナリを構成します。構成が正常に終了すると、デフォルトで、OMSおよび管理エージェントが自動的に起動されます。自動的に起動しないようにするには、START_OMSおよびb_startAgentオプションを使用し、制御する内容に応じてtrueまたはfalseに設定して、インストール・ウィザードを起動します。

注意:
第4.4.1.3項の説明に従って、ソフトウェア・バイナリを構成するためにConfigureGC.shを起動する場合でも、必ずSTART_OMSおよびb_startAgentオプションを使用してください。

たとえば、管理エージェントを自動的に起動しない場合、次のコマンドを実行します。

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh START_OMS=true b_startAgent=false

この拡張オプションに関連する制限を理解するには、第3.4.3項を参照してください。

4.4.1.2 rootスクリプトの実行

(UNIXのみ) Enterprise Manager Cloud Controlのソフトウェア・バイナリをインストールした後、新しい端末でrootユーザーとしてログインし、次のスクリプトを実行します。

- これがホストにインストールした最初のOracle製品である場合、oraInstroot.shスクリプトを、管理エージェントのホームで使用可能なoraInst.locファイルで指定されたインベントリの場所から実行します。
たとえば、oraInst.locファイルで指定されたインベントリの場所が$HOME/oraInventoryである場合、次のコマンドを実行します。

$HOME/oraInventory/oraInstRoot.sh

注意:
自身がrootユーザーではない場合、SUDOを使用して、rootユーザーに変更してください。たとえば、次のようなコマンドを実行します。
/usr/local/bin/sudo $HOME/oraInventory/oraInstRoot.sh

- OMSホームからallroot.shスクリプトを実行します。
$<OMS_HOME>/allroot.sh

注意:
自身がrootユーザーではない場合、SUDOを使用して、rootユーザーに変更してください。たとえば、次のようなコマンドを実行します。
/usr/local/bin/sudo $<OMS_HOME>/allroot.sh

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

Enterprise Manager Cloud Controlを構成するには、次の手順に従います。

1. Enterprise Manager Cloud Controlインストール・ウィザードの起動
インストール・ウィザードを起動します。(Unixでは、必ず作成したoinstallグループに属するユーザーとしてインストール・ウィザードを起動します。オペレーティング・システム・グループおよびユーザーの作成の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。)

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- 第4.4.1.1項の説明に従ってソフトウェア・バイナリをインストールし、引数-invPtrLocを渡した場合、ここでも同じ引数を渡します。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- スクリプトの起動時に渡すことができる追加の拡張オプションの詳細は、第4.4.1.3.1項を参照してください。

- ソフトウェアのみのインストールを構成する唯一の方法は、ConfigureGC.sh (Microsoft Windowsの場合はConfigureGC.bat)スクリプトを実行することです。コンフィギュレーション・アシスタントを個々に実行して、ソフトウェアのみのインストールを構成しないでください。なんらかの理由で個々のコンフィギュレーション・アシスタントを実行してインストールを構成する必要がある場合、Oracleサポートにご連絡ください。

- ConfigureGC.sh (Microsoft Windowsの場合はConfigureGC.bat)スクリプトを使用してソフトウェアのみのインストール(Oracleホーム)を構成済の場合、スクリプトまたは各コンフィギュレーション・アシスタントを使用して再構成しないでください。

2. インストール・タイプの選択

インストール・ウィザードの「インストール・タイプ」画面で、「Enterprise Managerシステムの新規作成」を選択します。

3. 「次へ」をクリックします。

4. プラグインのデプロイ

「プラグイン・デプロイメント」画面で、Enterprise Managerシステムのインストール中にソフトウェア・キット(DVD、ダウンロード済ソフトウェア)からインストールするオプションのプラグインを選択します。

事前に選択されている行は、デフォルトでインストールされる必須プラグインです。インストールするオプションを選択します。

注意:
インストール中にソフトウェア・キットで利用できないプラグインをインストールする場合、第4.4.1.1.1項の追加プラグインのインストールに関する点を参照してください。

5. 「次へ」をクリックします。

6. WebLogic Server構成の詳細の入力

「WebLogic Server構成の詳細」画面で、WebLogic Serverのユーザー・アカウントおよびノード・マネージャのユーザー・アカウントの資格証明を入力して、Oracle Management Serviceインスタンス・ベースの場所のパスを検証します。Oracle Management Serviceインスタンス・ベースの場所は、ミドルウェア・ホーム外の場所であることを確認してください。

注意:
パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

注意:
Oracle Management Serviceインスタンス・ベースの場所は、ミドルウェア・ホーム外の場所であることを確認してください。

デフォルトでは、WebLogicドメイン名がGCDomain、ノード・マネージャ名がnodemanagerです。これらは編集できないフィールドです。インストーラは、Oracle WebLogicドメインおよびその他の関連コンポーネント(管理サーバー、管理対象サーバー、ノード・マネージャなど)を作成するためにこの情報を使用します。

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

注意:
Microsoft Windowsでは、ノード・マネージャ・サービスは作成されません。これは予測されている動作です。

デフォルトでは、Oracle Management Serviceインスタンス・ベースの場所はgc_instで、OMSに関連するすべての構成の詳細を格納するためにミドルウェア・ホーム外に作成されます。

7. 「次へ」をクリックします。

8. データベース接続の詳細の入力

「データベース接続の詳細」画面で、次のようにします。

1. 管理リポジトリの作成が必要な、既存の動作保証済データベースの詳細を指定します。オラクル社提供のdデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスをすでに作成している場合は、そのデータベース・インスタンスの詳細を指定します。
インストーラは、この情報を使用して既存のデータベースに接続し、SYSMANスキーマおよびプラグイン・スキーマを作成します。事前構成済の管理リポジトリをすでに持つデータベースの詳細を指定する場合、インストーラはプラグイン・スキーマのみを作成します。

注意:

- オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスを作成する詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS(管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、(手順10で説明されているように)「リポジトリ構成の詳細」画面に入力したSYSMANパスワードで自動的にリセットされます。

- データベースが、動作保証マトリックスにリストされている動作保証済データベースであることを確認するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の説明に従って、動作保証マトリックスにアクセスしてください。

- 指定したデータベースにすでに構成済のEnterprise Managerスキーマがあることが警告により示された場合、必ず最初にこれらのスキーマを削除し、これらのスキーマを作成したEnterprise Managerソフトウェアを削除してから、インストーラに戻り新しいインストールに進みます。スキーマの削除およびソフトウェアの削除の手順は、第21章を参照してください。

- 設定されるすべてのデータベース初期化パラメータおよび実行されるすべての前提条件チェックの詳細、ならびに前提条件チェックに失敗した場合に前提条件チェックを手動で実行する手順については、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEM前提条件キットに関する付録を参照してください。

- Oracle Real Application Cluster(Oracle RAC)のノードは仮想IP(vip)名で参照されます。service_nameパラメータは、connect_dataモードでシステム識別子(SID)のかわりに使用され、フェイルオーバーが有効になります。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

2. 「デプロイメント・サイズ」・リストからデプロイメント・サイズを選択し、監視予定のターゲットの数、予定している管理エージェント数および予定している同時ユーザー・セッション数を指定します。
前提条件チェックは選択内容に関係なく実行されますが、様々なパラメータに設定される値は、選択内容に応じてチェックされます。

デプロイメント・サイズ、実行する前提条件チェック、設定するデータベース・パラメータ、およびインストール後にデプロイメント・サイズを変更する方法の詳細は、第2.1.6項を参照してください。

表4-2は、各デプロイメント・サイズを示しています。

表4-2 デプロイメント・サイズ

デプロイメント・サイズ

ターゲット数

管理エージェント数

同時ユーザー・セッション数

小

最大999

最大99

最大10

中

1000から9999

100から999

10から24

大

10,000以上

1000以上

25から50

9. 「次へ」をクリックします。

注意:
接続しているデータベースが、オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリで作成されたデータベース・インスタンスの場合、この画面で選択したデプロイメント・サイズが、データベース・インスタンスの作成中にOracle Database Configuration Assistant (DBCA)の手順2/12「データベース・テンプレート」画面で選択したデプロイメント・サイズと一致するようにしてください。
DBCAを使用したデータベース・インスタンスの作成中に選択したデプロイメント・サイズとは異なるデプロイメント・サイズを選択する場合、次のいずれかを行います。

- 選択したデプロイメント・サイズをこの画面で選択し、「次へ」をクリックします。エラーが発生した場合には、データベースのパラメータを修正し、この画面に戻ってインストールを続けます。オラクル社提供のSQLスクリプトを使用して自動的にパラメータを修正するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- インストーラを最小化し、希望のデプロイメント・サイズのテンプレートで別のデータベース・インスタンスを作成し、この画面に戻り、一致するデプロイメント・サイズを選択します。手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:

Oracle RACデータベースに接続していて、そのノードのいずれかの仮想ホスト名を入力している場合、インストール・ウィザードで「接続文字列」ダイアログが表示され、クラスタの一部であるその他のノードの情報で接続文字列を更新するように求められます。接続文字列を更新して「OK」をクリックします。接続をテストする場合は、「接続テスト」をクリックします。

単一クライアント・アクセス名(SCAN)リスナーを使用するようOracle RACデータベース11.2以上が構成されている場合、SCANリスナーを使用した接続文字列を入力できます。

Oracle Real Application Cluster(Oracle RAC)のノードは仮想IP(vip)名で参照されます。service_nameパラメータは、connect_dataモードでシステム識別子(SID)のかわりに使用され、フェイルオーバーが有効になります。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

注意:
Database Controlがすでに構成されたOracle Databaseへ接続するときは、構成の解除を求めるエラー・メッセージが表示されます。Database Controlリポジトリ、Database ControlアプリケーションおよびDatabase Controlの中央エージェントを構成解除したことを確認します。手順は、My Oracle Supportノート278100.1の第A.5項を参照してください。

10. 「Enterprise Manager構成詳細」に入力します。

「リポジトリ構成の詳細」画面で、次のようにします。

1. 「SYSMANパスワード」で、SYSMANユーザー・アカウントを作成するためのパスワードを入力します。SYSMANユーザー・アカウントは、Enterprise Manager Cloud Controlの管理に使用されるほとんどのリレーショナル・データを保持するSYSMANスキーマを作成するために使用されます。また、SYSMANは、Enterprise Manager Cloud Controlのスーパー管理者です。

注意:

- パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

- オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、この画面に入力したSYSMANパスワードで自動的にリセットされます。

2. 「登録パスワード」で、Enterprise Managerシステムを結合する新しい管理エージェントを登録するパスワードを入力します。

注意:
パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

3. 「管理表領域」には、管理表領域のデータ・ファイル(mgmt.dbf)を格納できる場所の絶対パスを入力します。インストーラはこの情報を使用して、監視対象のターゲットのデータ、メトリックなどを格納します。指定したパスには、ファイル名までを含めます。
たとえば、/u01/oracle/prod/oradata/mgmt.dbfなどです。

データベースがOracle Automatic Storage Management (Oracle ASM)上にある場合、パスは+<disk_group>/<sid>/<subdir_path_if_any>/<datafilename>.dbfのようになります。

たとえば、+DATA/oemrsp01d/datafile/mgmt.dbfなどです。

4. 「構成データ表領域」には、構成データ表領域のデータ・ファイル(mgmt_ecm_depot1_.dbf)を格納できる場所の絶対パスを入力します。これは、監視対象ターゲットから収集される構成情報の格納に必要です。指定したパスには、ファイル名までを含めます。
たとえば、/u01/oracle/prod/oradata/mgmt_ecm_depot1.dbfのようになります。

データベースがOracle Automatic Storage Management (Oracle ASM)上にある場合、パスは+<disk_group>/<sid>/<subdir_path_if_any>/<datafilename>.dbfのようになります。

たとえば、+DATA/oemrsp01d/datafile/mgmt_ecm_depot1.dbfなどです。

5. 「JVM診断データ表領域」には、JVM診断データ表領域のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所の絶対パスを入力します。指定したパスには、ファイル名までを含めます。Enterprise Manager Cloud Controlでは、JVM診断およびアプリケーション依存性とパフォーマンス(ADP)に関連する監視データを格納するために、このデータ・ファイルが必要です。
たとえば、/u01/oracle/prod/oradata/mgmt_deepdive.dbfのようになります。

データベースがOracle Automatic Storage Management (Oracle ASM)上にある場合、パスは+<disk_group>/<sid>/<subdir_path_if_any>/<datafilename>.dbfのようになります。

たとえば、+DATA/oemrsp01d/datafile/mgmt_deepdive.dbfなどです。

6. Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を構成するときは、「Oracleソフトウェア・ライブラリの構成」を選択します。ソフトウェア・ライブラリを構成できるOMSホスト上に、一意のディレクトリ名となる絶対パスを入力します。
デフォルトでは、構成される記憶域の場所は、OMS共有ファイルシステムの場所であるため、入力する場所がOMSホストにマウントされた場所であること、およびミドルウェア・ホーム外の場所であることを確認してください。また、OMSプロセスの所有者にその場所に対する読取り/書込みアクセス権があることも確認してください。マウントされた場所で構成を行うと、追加のOMSインスタンスのインストール時に役立ちます(インスタンスが、同じOMS共有ファイルシステムの記憶域の場所への読取り/書込みアクセス権を必要とするため)。

注意:

- ソフトウェア・ライブラリはミドルウェア・ホーム外に保持することをお薦めします。たとえば、ミドルウェア・ホームが/u01/software/oracle/middlewareの場合、ソフトウェア・ライブラリは/u01/software/oracleに保持できます。

- 追加のOMSインスタンスをインストールする場合に同じ場所を使用できるように、OMSホストにマウントされた場所を入力することを強くお薦めします。ただし、マウントされた場所を指定できない場合、またはテスト環境でインストールをテストし、マウントされた場所を指定しない場合には、ローカル・ファイルシステムの場所を指定できます。この場合、インストル後に、必ずマウントされた場所に移行してください。
ソフトウェア・ライブラリの記憶域の場所の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。OMSエージェント・ファイルシステムの記憶域の場所への移行の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- Microsoft Windowsでは、マウントされた場所を指定できない場合、製品のインストール時にローカル・ファイルシステムの場所を入力し、後でOMSエージェント・ファイルシステムの記憶域の場所に移行します。OMSエージェント・ファイルシステムの記憶域の場所は、Microsoft Windowsで推奨の記憶域タイプです。
ソフトウェア・ライブラリの記憶域の場所の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。OMSエージェント・ファイルシステムの記憶域の場所への移行の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- インストール時のソフトウェア・ライブラリの構成はオプションです。このオプションを選択せずに、これを構成しなくても、インストールは成功します。Enterprise Manager Cloud Controlコンソールから、後でソフトウェア・ライブラリを構成するオプションが常にあります。ただし、インストーラによって自動的に構成が行われるため、時間と労力を省くことができるように、インストール時にこのオプションを選択し、ソフトウェア・ライブラリを構成することを強くお薦めします。

- ソフトウェア・ライブラリを構成すると、ソフトウェア・ライブラリ・コンソールで場所の詳細を表示できます。ソフトウェア・ライブラリ・コンソールにアクセスするには、Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

11. 「次へ」をクリックします。

12. ポートのカスタマイズ

「ポート構成の詳細」画面で、様々なコンポーネントに使用されるポートをカスタマイズします。

Oracleによって推奨されるポート範囲の内部または外部にある空きカスタム・ポートを入力できます。

ポートが空いているかどうかを確認するには、次のコマンドを実行します。

- 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. 進行状況の追跡
「インストールの進行状況」画面で、インストール全体の進行状況(パーセント表示)を確認します。

注意:

- コンフィギュレーション・アシスタントに失敗した場合、インストーラが停止し、後続のコンフィギュレーション・アシスタントは実行されません。問題を解決して、コンフィギュレーション・アシスタントを再試行してください。詳細は、付録Jを参照してください。

- 「再試行」をクリックする前に誤ってインストーラを終了した場合、同じ画面を表示するためにインストーラを再起動するのではなく、OMSホームからrunConfig.shスクリプトを呼び出して、サイレント・モードでコンフィギュレーション・アシスタントを再実行してください。Microsoft Windowsプラットフォームの場合、runConfig.batスクリプトを起動します。
$<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スクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

16. インストールの終了
「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。

4.4.1.3.1 グラフィック・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアの構成中の拡張スクリプト・オプションの使用

configureGC.sh (Microsoft Windowsの場合はconfigureGC.bat)スクリプトの起動中に渡すことができる、追加の拡張オプションを次に示します。

- WebLogicドメインの作成に使用されるデフォルト名は、GCDomainです。これをオーバーライドしてカスタムWebLogicドメイン名を使用するには、WLS_DOMAIN_NAMEオプションを使用してスクリプトを起動して、一意のカスタム名を入力します。

注意:
第4.4.1.1項の説明に従って、ソフトウェア・バイナリをインストールするためにインストール・ウィザードを起動した場合でも、必ずWLS_DOMAIN_NAMEオプションを使用してください。

たとえば、カスタム名EMDomainを使用する場合、次のコマンドを実行します。

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh WLS_DOMAIN_NAME=EMDomain

- ソフトウェア・キットに含まれていない一部のプラグインをインストールする場合は、次の手順に従います。

1. OTNのEnterprise Managerダウンロード・ページからプラグインを手動でダウンロードして、アクセス可能な場所に格納します。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. 次のオプションを指定してConfigureGC.sh (Microsoft Windowsの場合はConfigureGC.bat)スクリプトを起動し、インストールするプラグインがある場所を渡します。
./ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

インストール・ウィザードの「プラグイン・デプロイメント」画面には、ソフトウェア・キットで使用できるプラグインおよびこのカスタムの場所で使用できるプラグインのリストが表示されます。インストールするものを選択できます。

- 構成が正常に終了すると、OMSおよび管理エージェントが自動的に起動されます。自動的に起動しないようにするには、START_OMSおよびb_startAgentオプションを使用し、制御する内容に応じてtrueまたはfalseに設定して、スクリプトを起動します。

注意:
第4.4.1.1項の説明に従って、ソフトウェア・バイナリをインストールするためにインストール・ウィザードを起動した場合でも、必ずSTART_OMSおよびb_startAgentオプションを使用してください。

たとえば、管理エージェントを自動的に起動しない場合、次のコマンドを実行します。

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh START_OMS=true b_startAgent=false

この拡張オプションに関連する制限を理解するには、第3.4.3項を参照してください。

4.4.1.4 グラフィック・モードでのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリの構成後の構成後タスクの実行

Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章に示されているインストール後の手順を実行します。

4.4.2 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Managerのインストール

この項では、サイレント・モードでEnterprise Manager Cloud Controlのソフトウェア・バイナリのみインストールして、後でインストールを構成する方法について説明します。この項の具体的な内容は次のとおりです。

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

- rootスクリプトの実行

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

- サイレント・モードでのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリの構成後の構成後タスクの実行

注意:
Enterprise Managerシステムのインストールを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を確認して2014年9月と10月および2015年1月にリリースされたプラグインを学習し、このプラグイン・リリースに関するユースケースを理解することをお薦めします。現在の要件に最適な事例を確認し、表の使用例に示される詳細な手順に従ってください。

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

サイレント・モードでEnterprise Manager Cloud Controlのソフトウェア・バイナリのみをインストールするには、次の手順を実行します。

注意:
インストーラを起動する前にEM前提条件キットを実行し、リポジトリの前提条件をすべて満たしていることをあらかじめ確認することをお薦めします。手動で実行していない場合でも、製品のインストール中はインストーラによってバックグラウンドで実行されています。ただし、事前に手動で実行すると、インストールまたはアップグレード・プロセスを開始できる前に、管理リポジトリが設定されます。キットの詳細とその実行方法、キットで実行される前提条件チェックについては、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。
ただし、オラクル社提供のデータベース・テンプレートを使用して事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、EM前提条件キットの起動中に次のパラメータを渡します。

-componentVariables repository:EXECUTE_CHECKS_NOSEED_DB_FOUND:false

1. 次のレスポンス・ファイルをローカル・ホスト上のアクセス可能な場所にコピーします。
<Software_Location>/response/software_only.rsp

このコマンドの<Software_Location>は、DVDまたはソフトウェア・キットをダウンロードした場所を指しています。

2. レスポンス・ファイルを編集し、表4-3に示された変数に適切な値を指定します。

3. インストーラを起動します。(Unixでは、必ず作成したoinstallグループに属するユーザーとしてインストーラを起動します。オペレーティング・システム・グループおよびユーザーの作成の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。)

- これがホストにインストールする最初のOracle製品である場合は、次のコマンドを実行します。
./runInstaller -silent -responseFile <absolute_path>/software_only.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

- 最初のOracle製品でない場合は、次のコマンドを実行します。
./runInstaller -silent -responseFile <absolute_path>/software_only.rsp

注意:

- UNIXプラットフォームでインストール・ウィザードを起動するには、runInstallerを起動します。Microsoft Windowsプラットフォームで起動するには、setup.exeを起動します。

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第3.4.2項を参照してください。

注意:
runInstallerまたはsetup.exeを起動したときに、Enterprise Manager Cloud Controlインストール・ウィザードが表示されない場合は、ユーザーに/stage (Enterprise ManagerソフトウェアのDisk1ディレクトリにあるサブディレクトリ)への読取り/書込みアクセス権限がない可能性があります。
インストール・ウィザードは、クラスパス変数をOPatch用に../stage/Components/として処理します。TEMP変数が/tmpに設定されているとき、インストール・ウィザードはopatchのJARファイルを/tmp/../stageディレクトリ(/stageと同様)で検索しようとします。しかし、ユーザーに/stageへの読取り/書込み権限がないと、インストール・ウィザードはハングします。このような場合、/stageディレクトリへの読取り/書込みアクセス権があるかどうかを確認します。ない場合、TEMP変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

4.4.2.1.1 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアをインストールするためのsoftware_only.rspレスポンス・ファイルの編集

i

表4-3は、編集する必要がある変数およびソフトウェア・バイナリをインストールするためのsoftware_only.rspレスポンス・ファイルでの編集方法を示しています。

表4-3 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアをインストールするためのsoftware_only.rspレスポンス・ファイルの編集

パラメータ

データ型

値に二重引用符が必要かどうか

説明

UNIX_GROUP_NAME

文字列

はい

(中央インベントリが存在しない場合にのみ必須)所属するUNIXグループの名前を入力します。

たとえば、"dba"などです。

注意: このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

INVENTORY_LOCATION

文字列

はい

(中央インベントリが存在しない場合にのみ必須)中央インベントリへの絶対パスを入力します。デフォルトのインベントリ・ディレクトリに対して読取り、書込み権限および実行権限があることを確認します。

たとえば、"/scratch/oracle/oraInventory"などです。

注意: このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

SECURITY_UPDATES_VIA_MYORACLESUPPORT

ブール

いいえ

- セキュリティ更新をダウンロードしてインストールする場合は、TRUEを入力します。続いて、次の変数に資格証明を二重引用符で囲んで入力します。
MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

- セキュリティ更新をダウンロードしてインストールする場合は、FALSEを入力します。

DECLINE_SECURITY_UPDATES

ブール

いいえ

- セキュリティ更新を拒否する場合は、TRUEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにFalseを入力する必要があります。

- セキュリティ更新を拒否しない場合は、FALSEを入力します。この場合、SECURITY_UPDATES_VIA_MYORACLESUPPORTにTRUEを入力する必要があります。

INSTALL_UPDATES_SELECTION

文字列

はい

この変数はデフォルトで、インストール中にソフトウェア更新がインストールされないことを示す"skip"に設定されています。

- My Oracle Supportからソフトウェア更新をインストールする場合、この変数を"download"に設定します。続いて、次のパラメータに資格証明を二重引用符で囲んで入力します。
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- ステージングされた場所からソフトウェア更新をインストールする場合、この変数を"staged"に設定します。続いてSTAGE_LOCATIONパラメータには、ソフトウェア更新が含まれるUpdatesディレクトリまで含めた絶対パスを二重引用符で囲んで入力します。

ORACLE_MIDDLEWARE_HOME_LOCATION

文字列

はい

インストーラでOracle WebLogic Server 11gリリース1 (10.3.6)およびJava Development Kit 1.6.0.43.0.をインストールする場所を入力します。

たとえば、"/u01/app/Oracle/Middleware"などです。

ミドルウェアの場所に書込み権限があり、OMSホームを作成できることを確認します。

すでに手動でインストールしている場合、インストールした場所を入力します。また、パッチ14482558、13349651、16080294および16888501を適用していることを確認してください。これらのパッチを適用していないと、追加のOMSのインストールが失敗します。

これらのパッチを適用する手順については、次のURLを参照してください。

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

Oracleミドルウェア・ホームの詳細は、第2.3.2項を参照してください。

注意: ここで入力するミドルウェア・ホームは、Enterprise Manager Cloud Controlのためにのみ使用するようにしてください。他のOracle Fusion Middleware製品またはコンポーネントは、同じミドルウェア・ホームにインストールしないでください。

注意: ミドルウェア・ホームのパスの文字数が、Unixプラットフォームでは70文字、Microsoft Windowsプラットフォームでは25文字を超えていないことを確認してください。

たとえば、15文字のみを含むミドルウェア・ホームのパスC:\Oracle\MW\EMは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

AGENT_BASE_DIR

文字列

はい

管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。

たとえば、"/oracle/agent"です。

この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

注意: (Microsoft Windowsのみ)エージェント・ベース・ディレクトリのパスの文字数が、25文字を超えていないことを確認してください。たとえば、16文字のみを含むエージェント・ベース・ディレクトリのパスC:\Oracle\Agent\は、使用できます。ただし、25を超える文字を含むC:\Oracle\ManagementAgent\12c\newは、使用できません。

ORACLE_HOSTNAME

文字列

はい

DNSに登録されており、他のネットワーク・ホストからアクセスできる完全修飾ドメイン名を入力します。または、このサイトのすべてのOMSインスタンスについて/etc/hostsファイルに定義されている別名ホスト名を入力します。

ホスト名はローカルのOracle WebLogic ServerおよびOracle Management Serviceに使用されるため、ホスト名はローカル・ホストに対して解決する必要があります。このフィールドには、リモート・ホストやロード・バランサ仮想ホストを指定しないでください。IPアドレスは入力しないでください。名前にアンダースコアを使用しないでください。省略名は可能ですが、警告が表示されます。このため、かわりに完全修飾ドメイン名を入力することをお薦めします。

ホスト名を指定しない場合、インストール・ウィザードは自動的に検出したホスト名をそのホストの名前として使用して続行します。

4.4.2.2 rootスクリプトの実行

(UNIXのみ) Enterprise Manager Cloud Controlのソフトウェア・バイナリをインストールした後、新しい端末でrootユーザーとしてログインし、次のスクリプトを実行します。

- これがホストにインストールした最初のOracle製品である場合、oraInstroot.shスクリプトを、管理エージェントのホームで使用可能なoraInst.locファイルで指定されたインベントリの場所から実行します。
たとえば、oraInst.locファイルで指定されたインベントリの場所が$HOME/oraInventoryである場合、次のコマンドを実行します。

$HOME/oraInventory/oraInstRoot.sh

注意:
自身がrootユーザーではない場合、SUDOを使用して、rootユーザーに変更してください。たとえば、次のようなコマンドを実行します。
/usr/local/bin/sudo $HOME/oraInventory/oraInstRoot.sh

- OMSホームからallroot.shスクリプトを実行します。
$<OMS_HOME>/allroot.sh

注意:
自身がrootユーザーではない場合、SUDOを使用して、rootユーザーに変更してください。たとえば、次のようなコマンドを実行します。
/usr/local/bin/sudo $<OMS_HOME>/allroot.sh

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

Enterprise Manager Cloud Controlのソフトウェア・バイナリを構成するには、次の手順に従います。

1. Enterprise Manager Cloud Controlのソフトウェア・バイナリをコピーしたホストのアクセス可能な場所に次のレスポンス・ファイルをコピーします。
<Software_Location>/response/new_install.rsp

このコマンドの<Software_Location>は、DVDまたはソフトウェア・キットをダウンロードした場所を指しています。

2. レスポンス・ファイルを編集し、表4-4に示された変数に適切な値を指定します。

3. ConfigureGC.sh (Microsoft Windowsの場合はConfigureGC.bat)スクリプトを起動し、前の手順で編集したレスポンス・ファイルを渡して、ソフトウェア・バイナリを構成します。
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -silent -responseFile <absolute_path>/new_install.rsp [-invPtrLoc <absolute_path_to_inventory_directory>]

注意:

- 第4.4.2.1項の説明に従ってソフトウェア・バイナリをインストールし、引数-invPtrLocを渡した場合、ここでも同じ引数を渡します。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- スクリプトの起動時に渡すことができる追加の拡張オプションの詳細は、第4.4.1.3.1項を参照してください。

- ソフトウェアのみのインストールを構成する唯一の方法は、ConfigureGC.sh (Microsoft Windowsの場合はConfigureGC.bat)スクリプトを実行することです。コンフィギュレーション・アシスタントを個々に実行して、ソフトウェアのみのインストールを構成しないでください。なんらかの理由で個々のコンフィギュレーション・アシスタントを実行してインストールを構成する必要がある場合、Oracleサポートにご連絡ください。

- ConfigureGC.sh (Microsoft Windowsの場合はConfigureGC.bat)スクリプトを使用してソフトウェアのみのインストール(Oracleホーム)を構成済の場合、スクリプトまたは各コンフィギュレーション・アシスタントを使用して再構成しないでください。

- オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合、選択したデプロイメント・サイズに合せるにはデータベース・パラメータを変更する必要があることを示すメッセージが表示されます。これは、テンプレートは基本的に簡易インストール用に設計され、データベース・パラメータは簡易インストールの要件に応じて設定されているためです。詳細インストールに使用する場合は、パラメータを別の値に設定する必要があります。メッセージを確認して続行します。インストール・ウィザードによって、自動的にパラメータが必要な値に設定されます。

注意:

- 前提条件チェックがパッケージが不足していることを示して失敗した場合は、必要なパッケージをインストールしてインストールを再試行してください。インストーラによってパッケージ名およびバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールしてください。インストーラがこれらのパッケージの検証に使用するロジックを理解するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- リポジトリ関連の前提条件チェックに失敗した場合、手動でチェックを実行してください。手順は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEM前提条件キットに関する付録を参照してください。

- コンフィギュレーション・アシスタントに失敗した場合、インストーラが停止し、後続のコンフィギュレーション・アシスタントは実行されません。問題を解決してコンフィギュレーション・アシスタントを再実行してください。詳細は、付録Jを参照してください。

4.4.2.3.1 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアを構成するためのnew_install.rspレスポンス・ファイルの編集

表4-4は、編集する必要がある変数およびソフトウェア・バイナリを構成するためのnew_install.rspファイルでの編集方法を示しています。

表4-4 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Manager 12cリリース4 (12.1.0.4)ソフトウェアを構成するためのnew_install.rspレスポンス・ファイルの編集

パラメータ

データ型

値に二重引用符が必要かどうか

説明

WLS_ADMIN_SERVER_USERNAME

文字列

はい

デフォルトでは、weblogicは、Oracle WebLogicドメインに作成されているデフォルトのユーザー・アカウントに割り当てられた名前です。デフォルトの名前を受け入れる場合は、空白のままにしておきます。ただし、カスタム名を使用する場合は、任意の名前を入力します。

WLS_ADMIN_SERVER_PASSWORD

文字列

はい

WebLogicユーザー・アカウントのパスワードを入力します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

文字列

はい

WebLogicユーザー・アカウントのパスワードを確認します。

NODE_MANAGER_PASSWORD

文字列

はい

デフォルトでは、nodemanagerは、ノード・マネージャに作成されているデフォルトのユーザー・アカウントに割り当てられた名前です。このノード・マネージャのユーザー・アカウントのパスワードを入力します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

NODE_MANAGER_CONFIRM_PASSWORD

文字列

はい

ノード・マネージャのユーザー・アカウントのパスワードを確認します。

ORACLE_INSTANCE_HOME_LOCATION

文字列

はい

デフォルトでは、gc_instがすべてのOMS関連構成ファイルを格納するためのOMSインスタンス・ベース・ディレクトリとしてみなされます。ミドルウェア・ホーム外の場所のこのディレクトリ名への絶対パスを入力します。

この場所の詳細は、第2.3.3項を参照してください。

CONFIGURE_ORACLE_SOFTWARE_LIBRARY

ブール

いいえ

インストール時にソフトウェア・ライブラリを構成するには、このパラメータをTRUEに設定します。それ以外の場合には、FALSEに設定します。

インストール時に構成しない場合でも、インストールは成功し、後ほどEnterprise Manager Cloud Controlコンソールからいつでも構成できます。ただし、インストーラによって自動的に構成が行われ、時間と労力を省くことができるため、インストール時にソフトウェア・ライブラリ構成することをお薦めします。

SOFTWARE_LIBRARY_LOCATION

文字列

はい

CONFIGURE_ORACLE_SOFTWARE_LIBRARYをTRUEに設定した場合、ソフトウェア・ライブラリを構成できるOMSホスト上に、一意のディレクトリ名となる絶対パスを入力します。入力する場所はOMSホスト上にマウントされた場所で、ミドルウェア・ホーム外であることを確認してください。また、OMSプロセスの所有者にその場所に対する読取り/書込みアクセス権があることも確認してください。マウントされた場所で構成を行うと、追加のOMSインスタンスのインストール時に役立ちます(インスタンスが、同じOMS共有ファイルシステムの記憶域の場所への読取り/書込みアクセス権を必要とするため)。

DATABASE_HOSTNAME

文字列

はい

既存のデータベースが常駐するホストの完全修飾名を入力します。ホスト名にアンダースコアがないことを確認します。

たとえば、"example.com"です。

オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスを作成している場合は、そのデータベース・インスタンスの詳細を指定します。

Oracle RAC Databaseに接続する場合、ノードに仮想ホスト名が含まれていれば、ノードの1つの仮想ホスト名を指定します。

この仮想ホスト名のみで構成された接続文字列を使用してデータベースへの接続が確立され、インストールは正常に終了します。

ただし、クラスタの他のノードの接続文字列を更新する場合、インストール後に次のコマンドを実行します。

$<OMS_HOME>/bin/emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))" -repos_user sysman

単一クライアント・アクセス名(SCAN)リスナーを使用するようOracle RACデータベース11.2以上が構成されている場合、SCANリスナーを使用した接続文字列を入力できます。

注意: オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、SYSMAN_PASSWORDパラメータに入力したSYSMANパスワードで自動的にリセットされます。

LISTENER_PORT

文字列

はい

既存のデータベースに接続するためのリスナー・ポートを入力します。

たとえば、"1521"です。

SERVICENAME_OR_SID

文字列

はい

既存のデータベースのサービス名またはシステムID (SID)を入力します。

たとえば、"orcl"などです。

SYS_PASSWORD

文字列

はい

SYSユーザー・アカウントのパスワードを入力します。

SYSMAN_PASSWORD

文字列

はい

SYSMANユーザー・アカウントを作成するパスワードを入力します。このパスワードは、SYSMANユーザー(管理リポジトリ・スキーマのプライマリ所有者)を作成する場合に使用します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

注意: オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、この画面に入力したSYSMANパスワードで自動的にリセットされます。

SYSMAN_CONFIRM_PASSWORD

文字列

はい

SYSMANユーザー・アカウントのパスワードを確認します。

DEPLOYMENT_SIZE

文字列

はい

次のいずれかの値を設定して、監視予定のターゲットの数、予定している管理エージェント数および予定している同時ユーザー・セッション数を示します。

- SMALL監視対象ターゲット数: 最大999、管理エージェント数: 最大99、同時ユーザー・セッション数: 最大10

- MEDIUM監視対象ターゲット数: 約1000から9999、管理エージェント数: 約100から999、同時ユーザー・セッション数: 約10から24

- LARGE監視対象ターゲット数: 10,000以上、管理エージェント数: 1000以上、同時ユーザー・セッション数: 約25から50

たとえば、"MEDIUM"です。

接続しているデータベースが、オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリで作成されたデータベース・インスタンスの場合、ここで選択したデプロイメント・サイズが、データベース・インスタンスの作成中にOracle Database Configuration Assistant (DBCA)の手順2/12「データベース・テンプレート」画面で選択したデプロイメント・サイズと一致するようにしてください。

DBCAを使用したデータベース・インスタンスの作成中に選択したデプロイメント・サイズとは異なるデプロイメント・サイズを選択する場合、次のいずれかを行います。

- 希望のデプロイメント・サイズのテンプレートで別のデータベース・インスタンスを作成し、このレスポンス・ファイルに戻り、同じデプロイメント・サイズをこのパラメータに設定します。オラクル社提供のテンプレートでデータベース・インスタンスを作成する手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 作成したデータベース・インスタンスにおいて、ここで設定するデプロイメント・サイズをレスポンス・ファイルでサポートするように、パラメータを修正します。オラクル社提供のSQL文を使用して自動的にデータベース・パラメータを修正するにはには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

MANAGEMENT_TABLESPACE_LOCATION

文字列

はい

管理表領域用のデータ・ファイル(mgmt.dbf)を格納できる場所の絶対パスを入力します。指定したパスには、ファイル名までを含めます。

次に例を示します。

- データベースがファイルシステム上にある場合、パスは"/u01/oracle/prod/oradata/mgmt.dbf"のようになります。

- データベースが自動ストレージ管理(ASM)上にある場合、パスは"+<disk_group1>/prod/oradata/mgmt.dbf"のようになります。ここで、disk_group1はASM上に作成されるディスクグループで、prodはサービスID (SID)です。

- データベースがRAWデバイス上にある場合、パスは"</dev/raw1>/prod/oradata/mgmt.dbf"のようになります。ここで、/dev/raw1はRAWデバイスで、prodはSIDです。

Enterprise Manager Cloud Controlでは、監視対象ターゲットやそのメトリックなどに関する情報を格納するためにこのデータ・ファイルが必要です。基本的に、構成データ、ソフトウェア・ライブラリ・データおよび監査データ以外の情報はすべてこのデータ・ファイルに格納されます。

CONFIGURATION_DATA_TABLESPACE_LOCATION

文字列

はい

構成データ表領域用のデータ・ファイル(mgmt_ecm_depot1.dbf)を格納できる場所の絶対パスを入力します。指定したパスには、ファイル名までを含めます。

たとえば、"/home/john/oradata/mgmt_ecm_depot1.dbf"などです。

Enterprise Manager Cloud Controlでは、監視対象ターゲットから収集された構成情報を格納するためにこのデータ・ファイルが必要です。

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

文字列

はい

JVM診断データ表領域用のデータ・ファイル(mgmt_deepdive.dbf)を格納できる場所の絶対パスを入力します。指定したパスには、ファイル名までを含めます。

たとえば、"/home/john/oradata/mgmt_deepdive.dbf"などです。

Enterprise Manager Cloud Controlでは、JVM診断およびアプリケーション依存性とパフォーマンス(ADP)に関連する監視データを格納するために、このデータ・ファイルが必要です。

AGENT_REGISTRATION_PASSWORD

文字列

はい

OMSと管理エージェントの間の通信を保護するには、パスワードを入力します。管理エージェントを保護するためのパスワードと同じ登録パスワードを入力する必要があります。

AGENT_REGISTRATION_CONFIRM_PASSWORD

文字列

はい

エージェント登録パスワードを確認します。

STATIC_PORTS_FILE

文字列

はい

デフォルトでは、第2.1.10項で説明されているポートが適用されます。デフォルトのポートを受け入れる場合は、このフィールドを空白のままにしておきます。

カスタム・ポートを使用する場合、インストールに使用されるカスタム・ポートをリストしているstaticports.iniファイルの絶対パスを入力します。

PLUGIN_SELECTION

Oracle Database管理プラグイン、Oracle Fusion Middleware管理プラグイン、My Oracle Support管理プラグイン、Oracle Exadata管理プラグインなどの必須のプラグインがEnterprise Managerシステムに自動的にインストールされます。

ただし、ソフトウェア・キット(DVDまたはダウンロードしたソフトウェア)に含まれているその他のオプションのプラグインをインストールする場合は、この変数にプラグインのIDを入力します。

次に例を示します。

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

ソフトウェア・キットで利用できないプラグインをインストールする場合、次の手順を実行します。

1. OTNのEnterprise Managerダウンロード・ページからプラグインを手動でダウンロードして、アクセス可能な場所に格納します。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. ダウンロードしたプラグインの名前でこの変数(PLUGIN_SELECTION)を更新します。

3. 次のオプションでインストーラを起動して、プラグインをダウンロードした場所を渡します。
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

4.4.2.4 サイレント・モードでのEnterprise Manager Cloud Control 12cリリース4 (12.1.0.4)ソフトウェア・バイナリの構成後の構成後タスクの実行

Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章に示されているインストール後の手順を実行します。

第III部

追加のOracle Management Serviceのインストール

この部は、次の章で構成されています。

- 第5章「サイレント・モードでの追加のOracle Management Serviceのインストール」

5 サイレント・モードでの追加のOracle Management Serviceのインストール

管理サービスの追加デプロイメント・プロシージャを使用して、追加のOracle Management Service (OMS)をインストールすることをお薦めします。管理サービスの追加デプロイメント・プロシージャでは、豊富なGUIを使用してインタラクティブに追加OMSをインストールできます。手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

ただし、環境にセキュリティ制限または監査要件がある場合、またはインストール用にネットワーク越しにOracle資格証明を使用してログインできない場合、次の手順に従って、サイレント(非インタラクティブ)モードで追加のOMSを手動でインストールします。

警告:

Enterprise Manager Cloud Control 12cを、SPARCシリーズのサーバー(T1000、T2000、T5xx0およびT3-*)にインストールしないでください。詳細は、My Oracle Supportのノート1590556.1を参照してください。

注意:
Enterprise Managerシステムのインストールを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を確認して2014年9月と10月および2015年1月にリリースされたプラグインを学習し、このプラグイン・リリースに関するユースケースを理解することをお薦めします。現在の要件に最適な事例を確認し、表の使用例に示される詳細な手順に従ってください。

1. Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)が、Oracle Enterprise Manager Cloud Controlで用意されているメインOMS上に構成されている場合、次のことを実行します。

- Unixプラットフォームの場合: 追加OMSのインストールを予定しているリモート・ホストから、ソフトウェア・ライブラリの読取り/書込みアクセスが可能であることを確認します。

- Microsoft Windowsプラットフォームの場合: ソフトウェア・ライブラリを共有またはマウントするオプションがない場合には、ソフトウェア・ライブラリをメインのソースOMSホストから追加のOMSをインストールする予定の宛先ホストにコピーします。

この手順では、わかりやすいように、Enterprise Manager Cloud Controlとともに提供されるOMSを第1のOMSと呼び、インストールする追加のOMSを追加OMSと呼びます。

2. リモート・ホストで、第4.4.1項の説明に従って、追加のOMSのソフトウェアのみのインストールを行います。

注意:

- 第1のOMSのインストールに使用したユーザーと同じユーザーとしてソフトウェア・バイナリをインストールしてください。ソフトウェア・ライブラリ・ファイルにアクセス可能である必要があります。

- 必ず第1のOMSと同じミドルウェアの場所にソフトウェア・バイナリをインストールします。

- ソフトウェアのみのインストールの最後に、インストーラでプロンプト表示されるようにConfigureGC.sh (Unixプラットフォームの場合)またはConfigureGC.batスクリプト(Microsoft Windows場合)を実行しないでください。そのファイルは、フレッシュ・インストールを行っている場合にのみ実行する必要があります。

3. プラグインをデプロイします。

- GUIモードの場合(インストーラ画面使用)
次の場所からPluginInstall.shスクリプトを起動します。

$<OMS_HOME>/sysman/install/PluginInstall.sh

「プラグイン・デプロイメント」画面で、インストールするオプションのプラグインを選択します。

画面には、前の手順(ソフトウェア・バイナリをインストールする手順)で使用したソフトウェア・キット(DVD、ダウンロード済ソフトウェア)に含まれるプラグインのみが表示されます。

この画面で事前に選択されている行は、デフォルトでインストールされる必須プラグインです。インストールするオプションを選択します。

- サイレント・モードの場合(コマンドライン):
次の場所からPluginInstall.shスクリプトを起動します。

$<OMS_HOME>/sysman/install/PluginInstall.sh -silent PLUGIN_SELECTION="{PLUGIN_ID1,PLUGIN_ID2}"

次に例を示します。

$<OMS_HOME>/sysman/install/PluginInstall.sh -silent PLUGIN_SELECTION="{oracle.sysman.emfa,oracle.sysman.vt}"

注意:

- Microsoft Windowsの場合は、PluginInstall.batを実行します。

- 必ずソースOMS (または第1のOMS)と同じプラグイン・セットを選択してください。
ソースOMS (または第1のOMS)にインストールされているプラグインを特定するには、次の手順を実行します。

1. 管理リポジトリに接続し、次のSQL問合せを実行して、インストールされているプラグインのリストを取得します。
SELECT epv.plugin_id, epv.version, epv.rev_version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id

2. インストールされている追加プラグインをメモします。

- ソースOMS (または第1のOMS)にインストールされている追加プラグインをインストールするか、バイナリのインストールに使用したソフトウェア・キットにない追加プラグインをインストールするには、次の手順を実行します。

1. OTNのEnterprise Managerダウンロード・ページからプラグインを手動でダウンロードして、アクセス可能な場所に格納します。
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. 次のオプションでスクリプトを起動して、インストールするプラグインを使用できる場所を渡します。
GUIモードの場合(インストーラ画面使用):

$<OMS_HOME>/sysman/install/PluginInstall.sh -pluginLocation <absolute_path_to_plugin_software_location>

「プラグイン・デプロイメント」画面には、ソフトウェア・キットに含まれていたプラグインおよびこのカスタムの場所にあるダウンロード済のプラグインのリストが表示されます。インストールするものを選択できます。

サイレント・モードの場合(コマンドライン):

$<OMS_HOME>/sysman/install/PluginInstall.sh -silent PLUGIN_SELECTION="{PLUGIN_ID1,PLUGIN_ID2}"-pluginLocation <absolute_path_to_plugin_software_location>

4. 追加OMSに対し、第1のOMSに適用したパッチをすべて適用し、2つのOMSインスタンスが同一で同期が保たれるようにします。パッチには、Enterprise Managerシステム、ソフトウェア・ライブラリ、OMSファイルおよび管理リポジトリなどを変更したパッチも含まれます。
第1のOMSに対して適用したパッチを特定するには、プラットフォーム・ホームから次のコマンドを実行します。

$<Platform Home>/OPatch/opatchauto lspatches

このコマンドでは、インストールされたパッチとOracleホームの関係が表示されます。インストールされたパッチを、My Oracle Supportサイト(https://support.oracle.com/)上のパッチの.zipファイルにマップします。ファイルをダウンロードし、追加のOMS上でアーカイブを解凍します。ファイルシステムまたは共有領域でパッチがすでに使用可能であれば、それらのパッチを再使用して他のOMSに適用します。

注意:
プラットフォームおよびプラグイン・ホームにインストールされたパッチの詳細を参照するには、コマンド$ORACLE_HOME/OPatch/opatch lsinventory -details -oh <desired home path>を実行します。

パッチを適用するには、次のコマンドを実行します。

- 各システム・パッチに対して、次を実行します。
<Platform Home>/OPatch/opatchauto apply <patch location> -bitonly -oh <Platform Home> -invPtrLoc <Platform Home>/oraInst.loc

<Platform Home>/OPatch/opatchauto commit -id 17513525 -oh <Platform Home> -invPtrLoc <Platform Home>/oraInst.loc

注意:
パッチに<system patch location>/bundle.xmlファイルがある場合、それはシステム・パッチです。システム・パッチのIDは、最上位ディレクトリのパッチID番号です。このIDは<System patch location>/bundle.xmlファイルでも参照できます。たとえば、<system_patch_bundle_xml type_version="2.0" bundle_type="ENGSYSTEM" patch_abstract="sample System Patch description" patch_id="1111115">は、パッチIDが1111115であることを明示しています。

- プラットフォーム・ホームの特定の各個別パッチに対して、次を実行します。
<Platform Home>/OPatch/opatch napply <one-off location> -oh <Platform Home> -invPtrLoc <Platform Home>/oraInst.loc

5. 第1のOMSから構成の詳細をエクスポートします。これを行うには、第1のOMSのOracleホームから次のコマンドを実行し、構成の詳細をファイルとしてエクスポートできる場所を渡します。
$<OMS_HOME>/bin/emctl exportconfig oms -dir <absolute_path_to_directory>

6. エクスポートされた構成の詳細ファイルを第1のOMSのホストから追加OMSのホストにコピーします。

7. 別名ホスト名を使用して追加のOMSをインストールする場合は、ORACLE_HOSTNAME環境変数に別名ホスト名を設定します。

8. 追加OMSに構成の詳細をリカバリします。これを行うには、追加OMSのOracleホームから次のコマンドを実行します。
$<OMS_HOME>/bin/omsca recover -ms -backup_file <absolute_path_to_the_file_copied_in_step4> [-AS_HTTPS_PORT <port> -MSPORT <port> -MS_HTTPS_PORT <port> -EM_NODEMGR_PORT <port> -EM_UPLOAD_PORT <port> -EM_UPLOAD_HTTPS_PORT <port> -EM_CONSOLE_PORT <port> -EM_CONSOLE_HTTPS_PORT <port> -config_home <absolute_path_to_instance_dir> -EM_INSTANCE_HOST <second_oms_host_name>] -EM_BIP_PORT <port> -EM_BIP_HTTPS_PORT <port>

次に例を示します。

$<OMS_HOME>/bin/omsca recover -ms -backup_file /opt/oracle/product/backup/opf_ADMIN_20120504_031016.bka -AS_HTTPS_PORT 7101 -MSPORT 7202 -MS_HTTPS_PORT 7301 -EM_NODEMGR_PORT 7403 -EM_UPLOAD_PORT 4889 -EM_UPLOAD_HTTPS_PORT 4900 -EM_CONSOLE_PORT 7788 -EM_CONSOLE_HTTPS_PORT 7799 -config_home /opt/oracle/product/omsmdw/gc_inst -EM_BIP_PORT 9701 -EM_BIP_HTTPS_PORT 9702 -EM_INSTANCE_HOST example.com

注意:
別名ホスト名を使用して追加のOMSをインストールする場合は、このサイトのすべてのOMSインスタンスについて/etc/hostsファイルに定義されている別名ホスト名を、EM_INSTANCE_HOSTパラメータに設定します。

9. (管理エージェントがまだホストにない場合にのみ適用) OMSホームから次のコマンドを実行し、追加OMSホスト上で管理エージェントを構成します。
$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<middleware_home>/agent OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_port> AGENT_REGISTRATION_PASSWORD=<password> -configOnly

注意:

- サーバー・ロード・バランサ(SLB)が構成済の場合は、SLBのホスト名およびポート番号を、OMS_HOSTパラメータとEM_UPLOAD_PORTパラメータに直接入力します。SLBが構成されない場合は、最初のOMSホスト名とセキュアなアップロード・ポートをOMS_HOSTパラメータとEM_UPLOAD_PORTパラメータに入力します。

- 別名ホスト名を使用して追加のOMSをインストールする場合は、ORACLE_HOSTNAME=<alias host name>パラメータをコマンドに追加し、このサイトのすべてのOMSインスタンスについて/etc/hostsファイルに定義されている別名ホスト名をそのパラメータに設定します。

10. 必要なプラグインを管理エージェントにデプロイします。
プラグインのデプロイの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』のプラグインの管理の章にある、Oracle Management Agentへのプラグインのデプロイに関する説明を参照してください。

11. 手順8に従って管理エージェントを構成した追加OMSホストで、信頼できる証明書をインポートします。パスワードを要求されたら、welcomeと入力します。
$<AGENT_HOME>/bin/emctl secure add_trust_cert_to_jks

12. 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のインストール後のタスクに関する項に記載されている該当する手順を確認して実行します。

13. Oracle WebLogic Serverターゲットを手動で検出します。

1. 第1のOMSと追加OMSの両方のインスタンスが稼働していることを確認します。

2. Cloud Controlコンソールで「ターゲット」メニューから「すべてのターゲット」を選択します。

3. 「すべてのターゲット」ページで/EMGC_GCDomain/GCDomain/を検索しクリックします。

4. EMGC_GCDomainホームページで「WebLogicドメイン」メニューから「WebLogicドメインのリフレッシュ」を選択します。

5. 「WebLogicドメインのリフレッシュ」ページで、「ターゲットの追加/更新」をクリックし、ウィザードの指示する手順に従います。
Enterprise Manager Cloud ControlでWebLogicドメインがリフレッシュされ、追加OMSホスト上の2つ目の管理対象サーバーが検出されます。

他のターゲットの検出の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの追加」を参照してください。

共有Oracleソフトウェア・ライブラリとサーバー・ロード・バランサの構成の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

第IV部

Oracle Management Agentのインストール

この部では、Oracle Management Agentをインストールする各種の方法について説明します。この部は、次の章で構成されています。

- 第6章「サイレント・モードでのOracle Management Agentのインストール」

- 第7章「Oracle Management Agentのクローニング」

- 第8章「共有エージェントのインストール」

- 第9章「Oracle Management Agentソフトウェアを今すぐインストールして後で構成」

6 サイレント・モードでのOracle Management Agentのインストール

この章では、Oracle Management Agent (管理エージェント)をサイレント・モードでインストールする方法について説明します。この章の具体的な内容は次のとおりです。

- サイレント・モードでの管理エージェントのインストールの概要

- サイレント・モードでの管理エージェントのインストールを開始する前に

- サイレント・モードでOracle Management Agentをインストールするための前提条件

- サイレント・モードでの管理エージェントのインストール

- サイレント・モードでの管理エージェントのインストール後

6.1 サイレント・モードでの管理エージェントのインストールの概要

サイレント・モードの管理エージェントのインストールは、ホスト・ターゲットの追加ウィザードを使用してインストールする場合の代替方法です。ホスト・ターゲットの追加ウィザードでは、GUIが豊富な質問画面を使用して、すべてのインストール詳細を指定する必要がありますが、サイレント・モードでは、レスポンス・ファイルを使用してインストール詳細を指定し、デプロイメント・スクリプトを使用して管理エージェントをホストにインストールする必要があります。

サイレント・モードのインストールは、ホスト・ターゲットの追加ウィザードを使用せずに、宛先ホスト自体から宛先ホストに追加の管理エージェントをインストールする場合に役立ちます。

管理エージェントをサイレント・モードでインストールするには、次の方法を使用します。

AgentPullスクリプトの使用

この方法では、管理エージェントをインストールするためにスクリプトを実行する前に、EM CLIを使用して管理エージェント・ソフトウェアをリモートの宛先ホストにダウンロードする必要がありません。この方法では、数個の追加パラメータのみをサポートしており、基本的な管理エージェントのインストールに適しています。

agentDeployスクリプトの使用

この方法では、管理エージェントをインストールするためにスクリプトを実行する前に、EM CLIを使用して管理エージェント・ソフトウェアをリモートの宛先ホストにダウンロードする必要があります。OMSホストから、またはリモートの宛先ホストからのいずれかのEM CLIの使用を選択できます。OMSホストからのEM CLIの使用を選択した場合、管理エージェントをインストールするスクリプトを実行する前に、ダウンロード済の管理エージェント・ソフトウェアをリモートの宛先ホストに転送する必要があります。この方法では、数多くの追加パラメータをサポートしており、カスマイズされた管理エージェントのインストールに適しています。

RPMファイルの使用

この方法では、OMSホスト上のEM CLIを使用して.rpmファイルを取得し、このファイルをリモートの宛先ホストに転送してから、このファイルを実行して管理エージェントをインストールします。.rpmファイルを使用すると、ベア・メタル・ホストのオペレーティング・システムのプロビジョニング中に管理エージェントをインストールすることもできます。詳細は、Oracle Enterprise Managerのソフトウェアとサーバーのプロビジョニングとパッチ適用についての管理者ガイド を参照してください。このガイドは、次の場所のEnterprise Managerドキュメント・ライブラリから入手できます。

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

注意:

- 管理エージェント.rpmファイルは、Linux x86およびLinux x86-64プラットフォーム用のみのEM CLIを使用して取得できます。

- Enterprise Manager 12c (12.1.0.x)では、Oracle Technology Network (OTN)から管理エージェント.rpmファイルをダウンロードして管理エージェントをインストールすることは、サポートされていません。

インストールが完了すると、エージェント・ベース・ディレクトリに次のデフォルトの内容が含まれています。

<agent_base_directory>
|_____core
|_____12.1.0.4.0
|_____plugins
|_____plugins.txt
|_____plugins.txt.status
|_____agent_inst
|_____sbin
|_____agentimage.properties

注意:

- 既存の管理エージェントを新しいOracle Management Service (OMS)に再指定できます。この方法の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の付録「Oracle Management Agentの別のOracle Management Serviceへのリダイレクト」を参照してください。
既存の管理エージェントを新しいOMSに対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

- (Microsoft Windowsホストの場合) 12.1.0.x管理エージェントをアップグレードし、異なるOMSを指定する別の管理エージェントを同じホストにインストールする場合、第6.4.6項に示すとおり、管理エージェントのインストール中にs_agentSrvcNameパラメータを指定してください。

6.2 サイレント・モードでの管理エージェントのインストールを開始する前に

サイレント・モードで管理エージェントをインストールする前に、次の点に留意してください。

- サイレント・モードでは、一度に1つのホストにのみ管理エージェントをインストールできます。このため、この方式は少数のホストに管理エージェントをインストールする場合に使用してください。

- 管理エージェントをインストールするホストのプラットフォーム用の管理エージェントソフトウェアは、自己更新を使用してダウンロードおよび適用する必要があります。OMSホスト・プラットフォーム用の管理エージェント・ソフトウェアのみが、デフォルトでダウンロードおよび適用されます。管理エージェント・ソフトウェアには、インストールに必要なコア・バイナリ、編集して渡されるレスポンス・ファイルおよびagentDeploy.sh (Microsoft Windowsの場合はagentDeploy.bat)スクリプトが含まれます。
自己更新を使用してプラットフォーム用の管理エージェント・ソフトウェアをダウンロードおよび適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 次のいずれかのプラットフォームで実行されているホストに管理エージェントをインストールする場合、事前にOMSホームにパッチ20802003をデプロイする必要があります。

- Oracle Linux 7 (64-bit)

- Red Hat Enterprise Linux 7 (64-bit)

- SUSE Linux Enterprise Server 12 (64-bit)

パッチのデプロイ方法に関する詳細は、『Oracle Enterprise Manager Lifecycle Management管理者ガイド』を参照してください。

- Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4.0)では、管理エージェント・ソフトウェアの特定のバージョンに適用する管理エージェント個別パッチは、同じバージョンの新しい管理エージェントがデプロイされるとき、または古い管理エージェントがそのバージョンにアップグレードされるときに常にこれらのパッチが自動的にソフトウェアに割り当てられるように、保存しておくことができます。
この方法の詳細は、付録Dを参照してください。

また、プラグインに個別パッチを適用し、カスタムのパッチ適用プラグインを作成して、デプロイするすべての新規管理エージェントおよびアップグレードするすべての旧管理エージェントにこのカスタムのパッチ適用プラグインがデプロイされるようにできます。

この方法の詳細は、『Oracle Enterprise Manager Cloud Control管理ガイド』を参照してください。

- Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4)からは、AgentPull.sh (Microsoft WindowsではAgentPull.bat)スクリプトを使用した管理エージェントのパラレル・デプロイメントがサポートされています。これにより、AgentPull.shスクリプトまたはAgentPull.batスクリプトを使用して、管理エージェントを複数のホストに同時に(パラレル方式で)デプロイできるようになります。

- 管理エージェントをサイレント・モードでMicrosoft Windowsホストにインストールする場合には、他のコマンド・プロンプトではなく必ずデフォルトのコマンド・プロンプトcmd.exeから、AgentPull.batスクリプトまたはagentDeploy.batスクリプトを実行します。

- インストール・プロセスの一部としてインストール前スクリプトまたはインストール後スクリプトを実行できません。これらは、インストル前またはインストール後に手動で実行できます。

- デフォルトでは、サイレント・モードで管理エージェントをインストールすると、次のタイプのプラグインのみが構成されます。

- 管理エージェント・ソフトウェアがデプロイされているOMSで構成されたすべての検出プラグイン

- Oracleホームの検出プラグイン

- Oracleホームの監視プラグイン

- カーネル・パッチまたはパッチ・バンドルを適用してSolarisの下位リリースをアップグレードすることと、実際のSolaris 5.10 Update 9イメージをインストールすることは同じではありません。Oracle Management Agent 12cリリース4 (12.1.0.4)はSolaris 5.10 Update 9の最小更新版で構築され、テストおよび動作認証されているため、Oracle Management Agentは、パッチを使用してアップグレードした他のリリースではなくSolaris 5.10 Update 9にインストールすることをお薦めします。

6.3 サイレント・モードでOracle Management Agentをインストールするための前提条件

サイレント・モードで管理エージェントをインストールする前に、次の前提条件を満たしていることを確認してください。

表6-1 サイレント・モードでOracle Management Agentをインストールするための前提条件

要件

説明

ハードウェアの要件

ハード・ディスク領域および物理メモリー要件を満たしていることを確認します。詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章を参照してください。

オペレーティング・システム要件

管理エージェントは、「My Oracle Support」のEnterprise Managerの動作保証マトリックスに記載された動作保証済のオペレーティング・システムにのみインストールしてください。

Enterprise Managerの動作保証マトリックスにアクセスするには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明している手順を実行します。

今後のサポート対象プラットフォームの詳細は、My Oracle Supportのノート793512.1を参照してください。

ファイルシステム要件

宛先ホストにマウントされたファイルシステムでバッファに入れられた書込みが許可されないことを確認します。

ファイル記述子要件

- ユーザー・プロセスの上限が13312以上に設定されていることを確認します。
現在の設定値を確認するには、次のコマンドを実行します。

ulimit -u

現在の値が13312以上でない場合は、13312以上に設定するようにシステム管理者に連絡してください。

- ファイル記述子のソフト・リミットを最小の4096に、ハード・リミットを16384以下に設定していることを確認します。
現在の設定値を確認するには、次のコマンドを実行します。

ソフト・リミットの場合:

/bin/sh -c "ulimit -n"

ハード・リミットの場合:

/bin/sh -c "ulimit -Hn"

現在の値が4096未満の場合、rootユーザーとして、次のエントリで/etc/security/limits.confファイルを更新してください。

<UID> soft nofile 4096

<UID> hard nofile 16384

パッケージの要件

すべてのオペレーティング・システム固有のパッケージをインストールしていることを確認します。詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのパッケージ要件に関する章を参照してください。

.rpmファイルを使用して管理エージェントをインストールする場合、rpm-buildパッケージがホストにインストールされていることを確認します。確認するには、次のコマンドを実行します。

rpm -qa | grep rpm-build

cURLユーティリティの要件

(AgentPullスクリプトを使用してインストールする場合のみ)

宛先ホストにcURLユーティリティがインストールされていることを確認します。

cURLユーティリティは次のURLからダウンロードできます。

http://curl.haxx.se/dlwiz/?type=bin

注意:宛先ホストがMicrosoft Windows上で実行されている場合は、cURLをc:\にインストールすることをお薦めします。

ZIPおよびUNZIPユーティリティの要件

ZIPユーティリティおよびUNZIPユーティリティが宛先ホストにあることを確認してください。

ZIPユーティリティは、バージョン3.0 2008ビルド以上である必要があります。

UNZIPユーティリティは、バージョン6.0以降である必要があります。

ユーザーおよびオペレーティング・システム・グループの要件

管理エージェントのインストール先のホストに適切なユーザーおよびオペレーティング・システム・グループが作成されていることを確認します。

詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのオペレーティング・システム・グループおよびユーザーの作成に関する章を参照してください。

注意: OMSインストールのオペレーティング・システム・ユーザー・アカウントを使用した管理エージェントのインストールに対するポリシーが企業にある場合は、異なるオペレーティング・システム・ユーザー・アカウントを使用して管理エージェントをインストールできます。ただし、使用するユーザー・アカウントおよびOMSインストールのユーザー・アカウントが同じプライマリ・グループに属していることを確認します。

/etc/hostsファイル要件

ホストの/etc/hostsファイルでIPアドレス、完全修飾名および短縮名が次の形式で使用されていることを確認します。

172.16.0.0 example.com mypc

タイムゾーン要件

ホストのタイムゾーンが正しく設定されていることを確認します。ホストのタイムゾーンを確認するには、次のコマンドを実行します。

echo $TZ

表示されたタイムゾーンが正しくない場合は、agentDeploy.shまたはagentDeploy.batスクリプトを実行する前に、次のコマンドを実行して正しいタイムゾーンを設定します。

- Kornシェルの場合:
TZ=<value>

export TZ

- BourneシェルまたはBashシェルの場合:
export TZ=<value>

- Cシェルの場合:
setenv TZ <value>

たとえば、Bashシェルで、タイムゾーンをAmerica/New_Yorkに設定するには、次のコマンドを実行します。

export TZ='America/New_York'

Microsoft Windowsで稼働する宛先ホストにタイムゾーンを設定するには、「スタート」メニューから、「コントロール パネル」を選択します。「日付と時刻」をクリックし、「タイムゾーン」タブを選択します。表示されたドロップダウン・リストからタイムゾーンを選択します。

使用できるタイムゾーンの一覧を確認するには、中央エージェント(OMSホストにインストールされた管理エージェント)の<AGENT_HOME>/sysman/adminディレクトリにあるsupportedtzs.lstファイルにアクセスします。

注意: 管理エージェントのインストール中に間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、管理エージェントのインストール後、ホストで正しいタイムゾーンを設定する必要があります。インストール後のタイムゾーンの設定の詳細は、第6.5項を参照してください。

PATH環境変数要件

(AgentPullスクリプトを使用してインストールする場合のみ)

zipおよびunzipの場所がPATH環境変数に含まれていることを確認します。

たとえば、zipおよびunzipが/usr/binにある場合は、/usr/binがPATH環境変数に含まれている必要があります。

パス検証の要件

すべてのコマンドの場所へのパスを検証します。詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のコマンドの場所の検証に関する付録を参照してください。

CLASSPATH環境変数の要件

CLASSPATH環境変数の設定を解除します。インストールの完了後、常にこの変数を元の値にリセットできます。

ポート要件

第2.1.10.1項で説明されているデフォルトのポートを使用できることを確認します。

一時ディレクトリの領域要件

実行可能ファイルがコピーされる一時ディレクトリに、400MBの領域が割り当てられていることを確認します。

デフォルトでは、環境変数TMPまたはTEMPに設定されている一時ディレクトリの場所が適用されます。両方が設定されている場合、TEMPが適用されます。いずれも設定されていない場合、UNIXホストは/tmp、Microsoft Windowsホストはc:\Tempとしてデフォルト値が適用されます。

/var/tmp要件

(.rpmファイルを使用してインストールする場合のみ)

/var/tmpディレクトリに700MB以上の空き領域があることを確認します。

/usr/lib/oracle要件

(.rpmファイルを使用してインストールする場合のみ)

/usr/lib/oracleディレクトリが存在し、2GB以上の空き領域があることを確認します。ない場合には作成し、それに対する書込み権限がインストール・ユーザーにあることを確認します。

エージェント・ベース・ディレクトリの要件

次の点を確認してください。

- エージェント・ベース・ディレクトリが空で、1GB以上の空き領域がある。

- ディレクトリ名に空白が含まれていない。

- インストール・ユーザーはエージェント・ベース・ディレクトリを所有します。エージェント・ベース・ディレクトリおよびその親ディレクトリには、インストール・ユーザーに対する読取り、書込みおよび実行権限があります。インストール・ユーザーまたはrootユーザーはエージェント・ベース・ディレクトリのすべての親ディレクトリを所有し、その親ディレクトリにはインストール・ユーザー・グループおよびその他のすべてのユーザーに対する読取りおよび実行権限があることを確認します。また、rootユーザーがルート・ディレクトリを所有することを確認します。
たとえば、エージェント・ベース・ディレクトリが/scratch/OracleHomes/agentで、インストール・ユーザーがoracleの場合、/scratch/OracleHomes/agentディレクトリはoracleが、scratchおよびOracleHomesディレクトリはoracleまたはrootユーザーが、ルート・ディレクトリ(/)はrootユーザーが所有している必要があります。

- エージェント・ベース・ディレクトリがマウントされている場合、setuidオプションがオンになってマウントされている。

エージェント・インスタンス・ホームの要件

(agentDeployスクリプトを使用してインストールする場合のみ)

レスポンス・ファイルで指定するエージェント・インスタンス・ホームの場所が空であることを確認します。

権限要件

- エージェント・インスタンス・ホームに対する書込み権限を持っていることを確認します。

- 一時ディレクトリに対する書込み権限を持っていることを確認します。

インストール・ユーザーの要件

中央インベントリ所有者と管理エージェントをインストールするユーザーが異なる場合、両者が同じグループに属し、インベントリ・ディレクトリに対して読取りおよび書込み権限があることを確認します。

たとえば、インベントリ所有者がabcで、管理エージェントをインストールするユーザーがxyzの場合、abcとxyzが同じグループに属し、双方が中央インベントリに対する読取りおよび書込みアクセスを持っていることを確認してください。

中央インベントリ(oraInventory)要件

- すべての宛先ホストにおいて、中央インベントリに100MBの領域が割り当てられていることを確認します。

- すべての宛先ホスト上のoraInventoryに対して読取り権限、書込み権限および実行権限があることを確認します。
宛先ホストのデフォルトのインベントリ(通常、/etc/oraInst.locファイルに示されている場所)にこれらの権限がない場合、表6-6の説明に従ってINVENTORY_LOCATIONまたは-invPtrLoc引数を使用してかわりのインベントリの場所のパスを入力してください。これらのパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされないことに注意してください。

エージェント・ユーザー・アカウント権限

(AgentPullまたはagentDeployスクリプトを使用してインストールする場合のみ)

(Microsoft Windowsの場合) Microsoft Windowsベースのオペレーティング・システム上に管理エージェントをインストールする場合、エージェント・ユーザー・アカウントに次を実行する権限があることを確認します。

- オペレーティング・システムの一部として機能

- プロセスのメモリー割当ての調整

- プロセス・レベル・トークンの置換え

- バッチ ジョブとしてログオン

エージェント・ユーザーにこれらの権限があることを確認するには、次の手順を実行します。

1. 「ローカル セキュリティ ポリシー」を起動します。
「スタート」 メニューから「設定」をクリックし、「コントロール パネル」を選択します。「コントロール パネル」ウィンドウから「管理ツール」を選択し、「管理ツール」ウィンドウから「ローカル セキュリティ ポリシー」を選択します。

2. 「ローカル セキュリティ ポリシー」ウィンドウで、ツリー構造から「ローカル ポリシー」を開き、「ユーザー権利の割り当て」を開きます。

cmd.exeの権限

(AgentPullまたはagentDeployスクリプトを使用してインストールする場合のみ)

(Microsoft Windowsの場合)Microsoft Windowsベースのオペレーティング・システム上に管理エージェントをインストールする場合、バッチ・ジョブを実行するユーザー・アカウントにCmd.exeプログラムの読取り権限および実行権限を付与していることを確認します。これはMicrosoftからの制約事項です。

この制約事項、および権限を付与する方法の詳細は、次のMicrosoft WebサイトへのURLにアクセスしてください。

http://support.microsoft.com/kb/867466/en-us

ランタイム・ライブラリ・ファイル要件

(Microsoft Windowsの場合) Microsoft Windowsベースのオペレーティング・システム上に管理エージェントをインストールする場合、Msvcp71.dllおよびMsvcr71.dllランタイム・ライブラリ・ファイルがc:\windows\system32にあることを確認します。

6.4 サイレント・モードでの管理エージェントのインストール

この項では、サイレント・モードでの管理エージェントのインストールに必要な操作について説明します。内容は次のとおりです。

- AgentPullスクリプトを使用した管理エージェントのインストール

- agentDeployスクリプトを使用した管理エージェントのインストール

- RPMファイルを使用した管理エージェントのインストール

- 仮想ホストへの管理エージェントのインストール

- AgentPullスクリプトを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

- agentDeployスクリプトを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

- RPMファイルを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

- AgentPullスクリプトでサポートされているオプション

- agentDeployスクリプトでサポートされているオプション

- ダウンロードした管理エージェント・ソフトウェアの内容について

重要:

- OMSホストがMicrosoft Windowsで稼働していて、OMSソフトウェアがC:\以外のドライブにインストールされている場合は、$OMS_HOME\oui\prov\resources\ssPaths_msplats.propertiesのSCRATCH_PATH変数を更新します。
たとえば、OMSソフトウェアがD:\にインストールされている場合は、SCRATCH_PATH変数をD:\tmpadaに更新してください。

- 次のいずれかのプラットフォームで実行されているホストに管理エージェントをインストール場合は、OMSホームにパッチ20802003をデプロイする必要があります。

- Oracle Linux 7 (64-bit)

- Red Hat Enterprise Linux 7 (64-bit)

- SUSE Linux Enterprise Server 12 (64-bit)

パッチのデプロイ方法に関する詳細は、『Oracle Enterprise Manager Lifecycle Management管理者ガイド』を参照してください。

6.4.1 AgentPullスクリプトを使用した管理エージェントのインストール

AgentPullスクリプトを使用して管理エージェントをインストールするには、次の手順を実行します。

1. 管理エージェント・ソフトウェアを取得します。

2. AgentPullスクリプトを使用して管理エージェントをインストールします。

重要:
AgentPullスクリプトを使用して管理エージェントをインストールする場合、管理エージェント・ソフトウェアを宛先ホストにダウンロードする必要がありません。この処理は、AgentPullスクリプトにより自動的に行われます。

6.4.1.1 管理エージェント・ソフトウェアの取得

1. 宛先ホストがUNIX上で実行されている場合は、ホストから次のURLにアクセスします。
https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage

宛先ホストがMicrosoft Windows上で実行されている場合は、ホストから次のURLにアクセスします。

https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage?script=bat

ファイルをAgentPull.sh (Microsoft Windowsの場合はAgentPull.bat)として一時ディレクトリ、たとえば/tmp (Microsoft Windowsの場合はc:\temp)に保存します。

注意:
AgentPull.shスクリプトは、次のコマンドを使用して取得することもできます。
curl "https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage" --insecure -o AgentPull.sh

このコマンドを使用するには、表6-1の説明に従ってcURLユーティリティがインストールされていることを確認します。

2. (UNIXオペレーティング・システムのみ)次のコマンドを実行して、AgentPull.shスクリプトに実行権限を付与します。
chmod +x <absolute_path_to_AgentPull.sh>

たとえば、コマンドchmod +x /tmp/AgentPull.shを実行します。

3. 管理エージェント・ソフトウェアがOMSホストで使用できるプラットフォームを特定します。-showPlatformsオプションを指定して、AgentPull.sh (Microsoft Windowsの場合はAgentPull.bat)スクリプトを実行すると、管理エージェント・ソフトウェアがOMSホストで使用できるプラットフォームが表示されます。
<absolute_path_to_AgentPull.sh> -showPlatforms

次に、コマンドの出力例を示します。

Platforms Version
Linux x86-64 12.1.0.4.0
Microsoft Windows x64 (64-bit) 12.1.0.4.0
IBM AIX on POWER Systems (64-bit) 12.1.0.4.0

管理エージェントをインストールするプラットフォームの出力が示されている場合、次の手順に進みます。それ以外の場合は、自己更新を使用して、必要なプラットフォーム用の管理エージェント・ソフトウェアを取得および適用します。

自己更新を使用してプラットフォーム用の管理エージェント・ソフトウェアを取得および適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
Oracle Enterprise Linux 4.x 64ビット・プラットフォーム、Red Hat Enterprise Linux 4.x 64ビット・プラットフォームまたはSUSE Linux Enterprise 10 64ビット・プラットフォーム上で動作するホストに管理エージェントをインストールする場合には、プラットフォーム用の32ビット・バージョンの管理エージェント・ソフトウェアをソフトウェア・ライブラリで入手可能であることを確認してください。

6.4.1.2 AgentPullスクリプトを使用した管理エージェントのインストール

1. 宛先ホストがUNIX上で、OMSホストがMicrosoft Windows上で実行されている場合は、次のコマンドを実行します。
dos2unix <absolute_path_to_AgentPull.sh>

たとえば、コマンドdos2unix /tmp/AgentPull.shを実行します。

2. 表6-2の説明に従ってパラメータを指定して、レスポンス・ファイルを(宛先ホスト上の任意の場所に)作成します。レスポンス・ファイルにagent.rspという名前を付けていないことを確認してください。
サンプル・レスポンス・ファイルagent.properties.の内容は次のとおりです。

LOGIN_USER=sysman
LOGIN_PASSWORD=welcome
PLATFORM="Linux x86-64"
AGENT_REGISTRATION_PASSWORD=wel246come

スクリプトが特定のレスポンス・ファイル・パラメータを無視するようにするには、パラメータの前に「#」を指定します。たとえば、#VERSIONです。

3. RSPFILE_LOCおよびAGENT_BASE_DIRパラメータを指定して、AgentPull.sh (Microsoft Windowsの場合はAgentPull.bat)を実行します。
<absolute_path_to_AgentPull.sh> RSPFILE_LOC=<absolute_path_to_responsefile> AGENT_BASE_DIR=<absolute_path_to_agentbasedir>

たとえば、次のようなコマンドを実行します。

/tmp/AgentPull.sh RSPFILE_LOC=/tmp/agent.properties AGENT_BASE_DIR=/scratch/agent

AgentPull.sh (およびAgentPull.bat)スクリプトは、(管理エージェント・ソフトウェアはダウンロードしても、管理エージェントはデプロイしない)-download_onlyのような特定のオプションをサポートしています。表6-5に、サポートされているオプションを示します。

AgentPull.batを使用して管理エージェントをMicrosoft Windowsホストにインストールする場合には、他のコマンド・プロンプトではなく必ずデフォルトのコマンド・プロンプトcmd.exeから、AgentPull.batを実行してください。

管理エージェントのインストールが失敗した場合、管理エージェントのインストール・ログを見て問題を診断してください。これらのログの場所の詳細は、第B.3項を参照してください。

6.4.2 agentDeployスクリプトを使用した管理エージェントのインストール

管理エージェントは、agentDeploy.shスクリプトまたはagentDeploy.batスクリプトを使用して、次の方法でインストールできます。

- リモートの宛先ホストからのEM CLIの使用

- OMSホストからのEM CLIの使用

6.4.2.1 リモートの宛先ホストからのEM CLIの使用

agentDeployスクリプトと宛先ホストからのEM CLIを使用して管理エージェントをインストールするには、次の手順を実行します。

1. 管理エージェント・ソフトウェアを取得し、EM CLIを使用して宛先ホストにこれをダウンロードします。

1. 宛先ホストにEM CLIを設定します。
OMSを実行していないホストにEM CLIを設定する方法の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』の「コマンドライン・インタフェースの概要およびインストール」の章を参照してください。

2. 宛先ホスト上のEM CLIインストール位置から、EM CLIにログインします。
<emcli_install_location>/emcli login -username=<username>

次に例を示します。

<emcli_install_location>/emcli login -username=sysman

パスワードを求められたら、指定します。

注意:
EM CLIログイン・ユーザーにADD_TARGET権限があることを確認してください。

3. EM CLIを同期します。
<emcli_install_location>/emcli sync

4. 管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なプラットフォームを特定します。
<emcli_install_location>/emcli get_supported_platforms

このコマンドは、管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なすべてのプラットフォームをリストします。次に、コマンドの出力例を示します。

---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = HP-UX PA-RISC (64-bit)
---------------------------------------------------

管理エージェントをインストールするプラットフォームの出力が示されている場合、次の手順に進みます。それ以外の場合は、自己更新を使用して、必要なプラットフォーム用の管理エージェント・ソフトウェアを取得および適用します。

自己更新を使用してプラットフォーム用の管理エージェント・ソフトウェアを取得および適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
Oracle Enterprise Linux 4.x 64ビット・プラットフォーム、Red Hat Enterprise Linux 4.x 64ビット・プラットフォームまたはSUSE Linux Enterprise 10 64ビット・プラットフォーム上で動作するホストに管理エージェントをインストールする場合には、プラットフォーム用の32ビット・バージョンの管理エージェント・ソフトウェアをソフトウェア・ライブラリで入手可能であることを確認してください。

5. ソフトウェア・ライブラリから宛先ホストの一時ディレクトリに管理エージェント・ソフトウェアをダウンロードします。
<emcli_install_location>/emcli get_agentimage -destination=<download_directory> -platform="<platform>" -version=<version>

次に例を示します。

./emcli get_agentimage -destination=/tmp/agentImage -platform="Linux x86-64" -version=12.1.0.4.0

重要:
get_agentimage EM CLI動詞を使用して宛先ホストとは異なるプラットフォーム用の管理エージェント・ソフトウェアをダウンロードする場合、ZIPユーティリティの場所にZIP_LOC環境変数を設定する必要があります。たとえば、ZIPユーティリティが/usr/bin/zipにある場合、ZIP_LOC=usr/bin/zipと設定します。
また、ZIPユーティリティはバージョン3.0 2008ビルド以上であることを確認してください。

get_agentimage EM CLI動詞を使用してOMSホスト・プラットフォームとは異なるプラットフォーム用の管理エージェント・ソフトウェアをダウンロードする場合、OMSホストのZIPユーティリティの場所$OMS_HOME/bin/zipにZIP_LOC環境変数を設定する必要があります。

注意:
コマンドでは、次のことに注意してください。

- -destinationは、管理エージェント・ソフトウェアをダウンロードする宛先ホストのディレクトリです。この場所への書込み権限を持っていることを確認します。

- -platformは、ソフトウェアをダウンロードするプラットフォームで、ソフトウェアがソフトウェア・ライブラリで入手可能な以前の手順で示されたプラットフォームのいずれかと一致する必要があります。

- -versionは、ダウンロードする管理エージェント・ソフトウェアのバージョンで、オプションの引数です。この引数を渡さない場合、デフォルトのバージョンはOMSバージョンになります。

このコマンドは、入力した宛先ディレクトリにコア管理エージェント・ソフトウェアをダウンロードします。たとえば、Linux x86-64の場合、12.1.0.4.0_AgentCore_226.zipファイルが表示されます。このコア・ソフトウェアの内容の詳細は、第6.4.10項を参照してください。

2. agentDeployスクリプトを使用して管理エージェントをインストールします。

1. 宛先ホストで、UNZIPユーティリティを使用して、ZIPファイルの内容を抽出します。
unzip <software_zip_file_location> -d <software_extract_location>

次に例を示します。

unzip /tmp/agentImage/12.1.0.4.0_AgentCore_226.zip -d /tmp/agtImg

2. 表6-3の説明に従って、agent.rspレスポンス・ファイルを編集します。
<software_extract_location>/agent.rsp

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

OMS_HOST=example.com
EM_UPLOAD_PORT=14511
AGENT_REGISTRATION_PASSWORD=abc123
AGENT_PORT=1832

スクリプトが特定のレスポンス・ファイル・パラメータを無視するようにするには、パラメータの前に「#」を指定します。たとえば、#AGENT_PORTのように指定します。

3. デプロイメント・スクリプトを起動して、レスポンス・ファイルを渡します。
<software_extract_location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<software_extract_location>/agent.rsp

宛先ホストとOMSホストの間にプロキシが設定される場合、プロパティ・ファイルにREPOSITORY_PROXYHOSTパラメータおよびREPOSITORY_PROXYPORTパラメータを指定し、agentDeploy.shを実行して宛先ホストに管理エージェントをインストールするときにPROPERTIES_FILEパラメータを指定する必要があります。

<software_extract_location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile> PROPERTIES_FILE=<absolute_path_to_properties_file>

たとえば、/tmp/agtImg/agentDeploy.sh AGENT_BASE_DIR=/scratch/agent12c RESPONSE_FILE=/tmp/agtImg/agent.rsp PROPERTIES_FILE=/tmp/agent.propertiesなどです。

使用するプロパティ・ファイルは次の形式である必要があります。

REPOSITORY_PROXYHOST=<proxy_host_name>
REPOSITORY_PROXYPORT=<proxy_port>

注意:

- レスポンス・ファイルを渡すかわりに、デプロイメント・スクリプトの起動中にレスポンス・ファイルのパラメータを明示的に渡すことができます。
必須のレスポンス・ファイル・パラメータは、OMS_HOST、EM_UPLOAD_PORTおよびAGENT_REGISTRATION_PASSWORDです。

次に例を示します。

/tmp/agtImg/agentDeploy.sh AGENT_BASE_DIR=/scratch/agent12c OMS_HOST=example.com EM_UPLOAD_PORT=14511 AGENT_REGISTRATION_PASSWORD=2bornot2b

- デプロイメント・スクリプトの起動中に引数を渡す場合、二重引用符でこれらの値を指定する必要はありません。ただし、レスポンス・ファイルで使用する場合、二重引用符で値を囲む必要があります(引数b_startAgentを除く)。

- エージェント・ベース・ディレクトリおよびレスポンス・ファイル(またはインストール詳細の個別の必須引数)を渡す以外に、デプロイメント・スクリプトでサポートされている他のオプションも渡すことができます。詳細は、6.4.9項を参照してください。

- agentDeploy.batを使用して管理エージェントをMicrosoft Windowsホストにインストールする場合には、他のコマンド・プロンプトではなく必ずデフォルトのコマンド・プロンプトcmd.exeから、agentDeploy.batを実行してください。

4. インストール後にルート・スクリプトを実行します。詳細は、第6.5項を参照してください。

管理エージェントを物理ホストにインストールし、その物理ホスト上にインストールされた仮想ホストに別の管理エージェントをインストールする場合に、両方の管理エージェントが通信用に同じポートを使用するようにするには、次の手順を実行します。

1. 物理ホストに管理エージェントをインストールします。管理エージェントを停止します。

2. 仮想ホストに管理エージェントをインストールします。管理エージェントを停止します。

3. $<AGENT_HOME>/sysman/config/emd.propertiesファイルで、AgentListenOnAllNICs=falseと設定します。この手順は、必ず両方の管理エージェントに対して実行します。

4. 両方の管理エージェントを起動します。

管理エージェントのインストールが失敗した場合、管理エージェントのインストール・ログを見て問題を診断してください。これらのログの場所の詳細は、第B.3項を参照してください。

6.4.2.2 OMSホストからのEM CLIの使用

agentDeployスクリプトとOMSホストからのEM CLIを使用して管理エージェントをインストールするには、次の手順を実行します。

1. 管理エージェント・ソフトウェアを取得し、EM CLIを使用してOMSホストにこれをダウンロードします。

1. OMSホストで、OMSホームからEM CLIにログインします。各OMSインストールでEM CLIをデフォルトで使用できるため、クライアントをOMSホストに個別でインストールする必要はありません。
$<OMS_HOME>/bin/emcli login -username=<username>

次に例を示します。

$<OMS_HOME>/bin/emcli login -username=sysman

パスワードを求められたら、指定します。

注意:

- EM CLIログイン・ユーザーにADD_TARGET権限があることを確認してください。

- 複数のOMS設定にロード・バランサを構成済の場合は、ロード・バランサ・ホストではなく、必ずいずれかのローカルOMSホストでEM CLIコマンドを実行してください。

- 複数のOMS設定にロード・バランサを構成済で、EM CLIのsetupコマンドを使用する場合は、ロード・バランサ・ホストとポートではなく、必ずOMSホストとポートをパラメータとして渡してください。
たとえば、emcli setup -url=https://<OMS_HOST>:<OMS_PORT>/em -user=sysman -password=sysmanです。

2. EM CLIを同期します。
$<OMS_HOME>/bin/emcli sync

3. 管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なプラットフォームを特定します。
$<OMS_HOME>/bin/emcli get_supported_platforms

このコマンドは、管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なすべてのプラットフォームをリストします。次に、コマンドの出力例を示します。

---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = HP-UX PA-RISC (64-bit)
---------------------------------------------------

管理エージェントをインストールするプラットフォームの出力が示されている場合、次の手順に進みます。それ以外の場合は、自己更新を使用して、必要なプラットフォーム用の管理エージェント・ソフトウェアを取得および適用します。

自己更新を使用してプラットフォーム用の管理エージェント・ソフトウェアを取得および適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
Oracle Enterprise Linux 4.x 64ビット・プラットフォーム、Red Hat Enterprise Linux 4.x 64ビット・プラットフォームまたはSUSE Linux Enterprise 10 64ビット・プラットフォーム上で動作するホストに管理エージェントをインストールする場合には、プラットフォーム用の32ビット・バージョンの管理エージェント・ソフトウェアをソフトウェア・ライブラリで入手可能であることを確認してください。

4. ソフトウェア・ライブラリからOMSホストの一時ディレクトリに管理エージェント・ソフトウェアをダウンロードします。
$<OMS_HOME>/bin/emcli get_agentimage -destination=<download_directory> -platform="<platform>" -version=<version>

次に例を示します。

./emcli get_agentimage -destination=/tmp -platform="Linux x86-64" -version=12.1.0.4.0

重要:
get_agentimage EM CLI動詞を使用してOMSホスト・プラットフォームとは異なるプラットフォーム用の管理エージェント・ソフトウェアをダウンロードする場合、OMSホストのZIPユーティリティの場所$OMS_HOME/bin/zipにZIP_LOC環境変数を設定する必要があります。
get_agentimage EM CLI動詞を使用して宛先ホストとは異なるプラットフォーム用の管理エージェント・ソフトウェアをダウンロードする場合、ZIPユーティリティの場所にZIP_LOC環境変数を設定する必要があります。たとえば、ZIPユーティリティが/usr/bin/zipにある場合、ZIP_LOC=usr/bin/zipと設定します。

また、ZIPユーティリティはバージョン3.0 2008ビルド以上であることを確認してください。

注意:
コマンドでは、次のことに注意してください。

- -destinationは、管理エージェント・ソフトウェアをダウンロードするOMSホストのディレクトリです。この場所への書込み権限を持っていることを確認します。
宛先ディレクトリの名前に2つ以上の用語が空白で区切られている場合は、二重引用符でディレクトリ名を囲んでください。

たとえば、宛先ディレクトリの名前が/tmp/linux agentimageの場合、-destination="/tmp/linux agentimage"のように値を入力します。

- -platformは、ソフトウェアをダウンロードするプラットフォームで、ソフトウェアがソフトウェア・ライブラリで入手可能な以前の手順で示されたプラットフォームのいずれかと一致する必要があります。

- -versionは、ダウンロードする管理エージェント・ソフトウェアのバージョンで、オプションの引数です。この引数を渡さない場合、デフォルトのバージョンはOMSバージョンになります。

このコマンドは、入力した宛先ディレクトリにコア管理エージェント・ソフトウェアをダウンロードします。たとえば、Linux x86-64の場合、12.1.0.4.0_AgentCore_226.zipファイルが表示されます。このコア・ソフトウェアの内容の詳細は、第6.4.10項を参照してください。

2. 管理エージェント・ソフトウェアを宛先ホストに転送します。
ダウンロードしたZIPファイルを管理エージェントをインストールする宛先ホストの一時ディレクトリ(/tmp)に転送します。ファイルの転送には、任意のファイル転送ユーティリティを使用できます。

3. agentDeployスクリプトを使用して管理エージェントをインストールします。
第6.4.2.1項で説明した手順2に従って、管理エージェントをインストールします。

6.4.3 RPMファイルを使用した管理エージェントのインストール

.rpmファイルを使用して管理エージェントをインストールするには、次の手順を実行します。

1. 管理エージェント・ソフトウェアを取得し、OMSホストにRPMファイルをダウンロードします。

2. RPMファイルを宛先ホストへ転送します。

3. RPMファイルを使用して管理エージェントをインストールします。

6.4.3.1 管理エージェント・ソフトウェアを取得し、OMSホストにRPMファイルをダウンロードします

1. OMSホストで、OMSホームからEM CLIにログインします。各OMSインストールでEM CLIをデフォルトで使用できるため、クライアントをOMSホストに個別でインストールする必要はありません。
$<OMS_HOME>/bin/emcli login -username=<username>

次に例を示します。

$<OMS_HOME>/bin/emcli login -username=sysman

パスワードを求められたら、指定します。

注意:
EM CLIログイン・ユーザーにADD_TARGET権限があることを確認してください。

2. EM CLIを同期します。
$<OMS_HOME>/bin/emcli sync

3. 管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なプラットフォームを特定します。
$<OMS_HOME>/bin/emcli get_supported_platforms

このコマンドは、管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なすべてのプラットフォームをリストします。次に、コマンドの出力例を示します。

---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 12.1.0.4.0
Platform Name = HP-UX PA-RISC (64-bit)
---------------------------------------------------

管理エージェントをインストールするプラットフォームの出力が示されている場合、次の手順に進みます。それ以外の場合は、自己更新を使用して、必要なプラットフォーム用の管理エージェント・ソフトウェアを取得および適用します。

自己更新を使用してプラットフォーム用の管理エージェント・ソフトウェアを取得および適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
Oracle Enterprise Linux 4.x 64ビット・プラットフォーム、Red Hat Enterprise Linux 4.x 64ビット・プラットフォームまたはSUSE Linux Enterprise 10 64ビット・プラットフォーム上で動作するホストに管理エージェントをインストールする場合には、プラットフォーム用の32ビット・バージョンの管理エージェント・ソフトウェアをソフトウェア・ライブラリで入手可能であることを確認してください。

4. ソフトウェア・ライブラリからOMSホストの一時ディレクトリに管理エージェントの.rpmファイルをダウンロードします。
$<OMS_HOME>/bin/emcli get_agentimage_rpm -destination=<download_directory> -platform="<platform>" -version=<version>

次に例を示します。

./emcli get_agentimage_rpm -destination=/tmp/agentRPM -platform="Linux x86-64" -version=12.1.0.4.0

コマンドでは、次のことに注意してください。

- -destinationは、.rpmファイルをダウンロードするOMSホストのディレクトリです。この場所への書込み権限を持っていることを確認します。

- -platformは、.rpmファイルをダウンロードするプラットフォームで、ソフトウェアをOMSホストで使用できる以前の手順で示されたプラットフォームのいずれかと一致する必要があります。

- -versionは、.rpmファイルをダウンロードする管理エージェントのバージョンで、オプションの引数です。この引数を渡さない場合、デフォルトのバージョンはOMSバージョンになります。

このコマンドは、入力した宛先ディレクトリにコア管理エージェントの.rpmファイルをダウンロードします。たとえば、oracle-agt-12.1.0.4.0-1.0.i386.rpmなどです。

また、このコマンドは、OMSホームに含まれる管理エージェント・ソフトウェア、パッチおよびプラグインを取得します。管理エージェントのパッチをOMSホームに保存して、管理エージェントがデプロイされたときに常に適用されるようにする方法については、第D.1項を参照してください。

6.4.3.2 RPMファイルを宛先ホストへ転送します

1. ダウンロードした.rpmファイルを管理エージェントをインストールする宛先ホストの一時ディレクトリ(/tmp)に転送します。ファイルの転送には、任意のファイル転送ユーティリティを使用できます。

6.4.3.3 RPMファイルを使用して管理エージェントをインストールします

1. 宛先ホストで、rootユーザーとして.rpmファイルをインストールして、管理エージェントをインストールします。
rpm -ivh <download_directory>/<rpm_file>

次に例を示します。

rpm -ivh /tmp/oracle-agt-12.1.0.4.0-1.0.i386.rpm

注意:
コマンドの出力内容は次のとおりです。

Preparing... ########################################### [100%]
Running the prereq
1:oracle-agt ########################################### [100%]
Follow the below steps to complete the agent rpm installation:
1. Edit the properties file: /usr/lib/oracle/agent/agent.properties with the correct values
2. Execute the command /etc/init.d/oracle-agt RESPONSE_FILE=<location_to_agent.properties>

.rpmファイルを使用して管理エージェントをインストールしたとき、デフォルトのエージェント・ベース・ディレクトリの場所は/usr/lib/oracle/agentです。カスタム・エージェント・ベース・ディレクトリの場所を使用して管理エージェントをインストールするには、rootユーザーとして次のコマンドを実行します。

rpm -ivh --relocate /usr/lib/oracle/agent=<custom_agent_base_directory_location> <download_directory>/<rpm_file>

次に例を示します。

rpm -ivh --relocate /usr/lib/oracle/agent=/scratch/aime/agent tmp/agent_rpm/oracle-agt-12.1.0.4.0-1.0.i386.rpm

.rpmファイルを使用して管理エージェントをインストールしたとき、インベントリの場所は常に<agent_base_directory>/oraInventoryです。デフォルトのエージェント・ベース・ディレクトリの場所は/usr/lib/oracle/agentであるため、デフォルトのインベントリの場所は/usr/lib/oracle/agent/oraInventoryになります。(--relocateオプションを使用して)カスタム・エージェント・ベース・ディレクトリの場所に管理エージェントをインストールすることを選択した場合、たとえば/oem/agentであれば、インベントリの場所は/oem/agent/oraInventoryになります。

2. 表6-4の説明に従って、agent.propertiesファイルを編集します。ファイルは次の場所にあります。
/usr/lib/oracle/agent/agent.properties

3. 次のコマンドを実行して、インストールを完了します。
/etc/init.d/oracle-agt RESPONSE_FILE=<location_to_agent.properties>

管理エージェントのインストールが失敗した場合、管理エージェントのインストール・ログを見て問題を診断してください。これらのログの場所の詳細は、第B.3項を参照してください。

6.4.4 仮想ホストへの管理エージェントのインストール

仮想ホストに管理エージェントをインストールするには、次の手順を実行します。

1. 第6.4.2.1項または第6.4.2.2項に説明されている手順に従ってください。agentDeploy.shまたはagentDeploy.batスクリプトを起動する場合は、必ずORACLE_HOSTNAMEパラメータを指定してください。
たとえば、<software_extract_location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_response_file> ORACLE_HOSTNAME=<name_of_virtual_host>などです。

ORACLE_HOSTNAMEパラメータの詳細は、表6-3を参照してください。

2. 仮想ホストが仮想ネットワーク・インタフェース・コントローラ(NIC)に関連付けられている場合、$<AGENT_HOME>/sysman/config/emd.propertiesファイルにAgentListenOnAllNICs=falseを設定して、次のコマンドを実行します。
$<AGENT_HOME>/bin/emctl reload

6.4.5 AgentPullスクリプトを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

表6-2は、AgentPullスクリプトを使用して管理エージェントをインストールする際、レスポンス・ファイルに含める必要のある必須パラメータと、含めることができるオプションのパラメータを示しています。

表6-2 AgentPullスクリプトを使用してOracle Management Agentをインストールするためのレスポンス・ファイルの作成

パラメータ

説明

LOGIN_USER

(必須) Enterprise Managerコンソールのログイン・ユーザー名を入力します。

たとえば、LOGIN_USER=sysmanです。

LOGIN_PASSWORD

(必須) Enterprise Managerコンソールのログイン・パスワードを入力します。

たとえば、LOGIN_PASSWORD=welcome1です。

PLATFORM

(必須)管理エージェント・ソフトウェアをダウンロードするプラットフォームを入力します。

たとえば、PLATFORM="Linux x86-64"です。

注意: パラメータの値は" "で囲む必要があります。

AGENT_REGISTRATION_PASSWORD

(必須)Enterprise Managerシステムを結合する新しい管理エージェントを登録するパスワードを入力します。

デフォルトで、OMSと管理エージェント間の通信は保護およびロックされます。Enterprise Managerシステムに追加する新しい管理エージェントは、事前に認証を受ける必要があります。ここで入力するパスワードは、新しい管理エージェントを認証するために使用されます。

たとえば、AGENT_REGISTRATION_PASSWORD=Wel456comeです。

VERSION

(オプション)ダウンロードする管理エージェント・ソフトウェアのバージョンを入力します。

たとえば、VERSION=12.1.0.4.0です。

このパラメータを指定しないと、OMSのバージョンが割り当てられます。

CURL_PATH

(Microsoft Windowsのホストのみ)

(オプション)インストールされたcURLユーティリティの絶対パスを入力します。

たとえば、CURL_PATH=c:\Program Files\curlです。

このパラメータを追加しないと、値c:\が割り当てられます。

OMS_HOST

(オプション) OMSホスト名を入力します。

たとえば、OMS_HOST=example.comです。

EM_UPLOAD_PORT

(オプション) OMSと通信するためのアップロード・ポート(HTTPまたはHTTPS)を入力します。

たとえば、EM_UPLOAD_PORT=14511です。

AGENT_INSTANCE_HOME

(オプション)すべての管理エージェント関連の構成ファイルを格納できる宛先ホストのディレクトリの場所を入力します。このパラメータには、次のいずれかを実行できます。

- 空白のままにしておきます。
この場合、デフォルトでは、agent_instというインスタンス・ディレクトリがエージェント・インストール・ベース・ディレクトリに作成されます。

たとえば、インストール・ベース・ディレクトリが/john/oracle/の場合、デフォルトのインスタンス・ディレクトリは/john/oracle/agent_instです。

- カスタム・ディレクトリの絶対パスを入力します。
カスタムの場所を入力できますが、インスタンス・ベース・ディレクトリ内にインスタンス・ディレクトリを保持することをお薦めします。

たとえば、AGENT_INSTANCE_HOME=/john/oracle/instance_dir/inst_mydirです。

AGENT_PORT

(オプション)管理エージェント・プロセスを起動する空きポートを入力します。HTTPとHTTPSの両方に同じポートが使用されます。

たとえば、AGENT_PORT=1832です。

値を入力しない場合、3872または1830から1849の間の空きポートが適用されます。

b_startAgent

(オプション)管理エージェントをインストールして構成した後に自動的に起動する場合、TRUEを入力します。それ以外の場合はFALSEを入力します。

たとえば、b_startAgent=TRUEなどです。

このパラメータを追加しないと、デフォルトでTRUEが設定されます。

ORACLE_HOSTNAME

(オプション)管理エージェントをインストールするホストの完全修飾ドメイン名を入力します。

たとえば、ORACLE_HOSTNAME=example.comです。

このパラメータを追加しないと、デフォルトで物理ホスト名が設定されます。

ALLOW_IPADDRESS

(オプション)ORACLE_HOSTNAMEにIPアドレスを指定する場合にはTRUEを入力します。ALLOW_IPADDRESSがFALSEに設定された場合には、管理エージェントのインストール中にORACLE_HOSTNAMEにIPアドレスを指定すると、前提条件チェックは失敗します。

たとえば、ALLOW_IPADDRESS=TRUEなどです。

このパラメータを追加しないと、デフォルトでFALSEが設定されます。

START_PRIORITY_LEVEL

(UNIXベースのホストのみ)

(オプション) このパラメータは、ホスト起動時の管理エージェント・サービスの優先度を指定する場合に使用します。このパラメータは、0から99の間の値を受け付けます。ただし、このパラメータには91から99の間の値を指定することをお薦めします。

たとえば、START_PRIORITY_LEVEL=95などです。

このパラメータを追加しないと、デフォルトで98が設定されます。

SHUT_PRIORITY_LEVEL

(UNIXベースのホストのみ)

(オプション)このパラメータは、ホスト停止時の管理エージェント・サービスの優先度を指定する場合に使用します。このパラメータは0から99の間の値を受け付けます。

たとえば、SHUT_PRIORITY_LEVEL=25などです。

このパラメータを追加しないと、デフォルトで19が設定されます。

PROPERTIES_FILE

(オプション)プロパティ・ファイルの絶対位置を指定する場合にこのパラメータを使用します。

たとえば、PROPERTIES_FILE=/tmp/agent.propertiesなどです。

プロパティ・ファイルで管理エージェントのデプロイメントに使用するパラメータを指定します。プロパティ・ファイルで指定できるパラメータのリストは、$<AGENT_INSTANCE_HOME>/sysman/config/emd.propertiesにあります。プロパティ・ファイルでは、たとえば次のように名前と値のペアでパラメータを指定する必要があります。

REPOSITORY_PROXYHOST=abc.example.com

REPOSITORY_PROXYPORT=1532

プロパティ・ファイルでは、空白の入ったパラメータ値はサポートしていません。特定のパラメータの値に空白があった場合には、管理エージェントのデプロイ後に次のコマンドを実行します。

$<AGENT_INSTANCE_HOME>/bin/emctl setproperty agent -name <parameter_name> -value <parameter_value>

s_agentHomeName

(オプション)管理エージェント用に作成された表示するOracleホームの名前を入力します。

たとえば、s_agentHomeName=agent12cR2です。

このパラメータを追加しないと、デフォルトでagent12cnが設定されます(nはホストに最初にインストールされた管理エージェントの場合は1、2番目にインストールされた管理エージェントの場合は2)。

注意: 入力する名前は英数字のみで128文字以下としてください。

s_agentSrvcName

(Microsoft Windowsのホストのみ)

(オプション)カスタマイズされた管理エージェント・サービス名を入力します。

たとえば、s_agentSrvcName=agentsrvc1などです。

このパラメータを追加しないと、デフォルトでOracle+<oracle_home_name>+Agentが設定されます。

注意: (Microsoft Windowsホストの場合) ホストにインストールされた12.1.0.x管理エージェントをアップグレードし、異なるOMSを指定する別の管理エージェントを同じホストにインストールする場合、管理エージェントのインストール中にs_agentSrvcNameパラメータを指定してください。

6.4.6 agentDeployスクリプトを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

表6-3は、agentDeployスクリプトを使用して管理エージェントをインストールする際、レスポンス・ファイルに含める必要のある必須パラメータと、含めることができるオプションのパラメータを示しています。

表6-3 agentDeployスクリプトを使用してOracle Management Agentをインストールするためのレスポンス・ファイルの作成

パラメータ

説明

OMS_HOST

(必須) OMSホスト名を入力します。

たとえば、OMS_HOST=example.comです。

EM_UPLOAD_PORT

(必須) OMSと通信するためのアップロード・ポート(HTTPまたはHTTPS)を入力します。

たとえば、EM_UPLOAD_PORT=14511です。

AGENT_REGISTRATION_PASSWORD

(必須)Enterprise Managerシステムを結合する新しい管理エージェントを登録するパスワードを入力します。

デフォルトで、OMSと管理エージェント間の通信は保護およびロックされます。Enterprise Managerシステムに追加する新しい管理エージェントは、事前に認証を受ける必要があります。ここで入力するパスワードは、新しい管理エージェントを認証するために使用されます。

たとえば、AGENT_REGISTRATION_PASSWORD=Wel456comeです。

AGENT_INSTANCE_HOME

(オプション)すべての管理エージェント関連の構成ファイルを格納できる宛先ホストのディレクトリの場所を入力します。このパラメータには、次のいずれかを実行できます。

- 空白のままにしておきます。
この場合、デフォルトでは、agent_instというインスタンス・ディレクトリがエージェント・インストール・ベース・ディレクトリに作成されます。

たとえば、インストール・ベース・ディレクトリが/john/oracle/の場合、デフォルトのインスタンス・ディレクトリは/john/oracle/agent_instです。

- カスタム・ディレクトリの絶対パスを入力します。
カスタムの場所を入力できますが、インスタンス・ベース・ディレクトリ内にインスタンス・ディレクトリを保持することをお薦めします。

たとえば、AGENT_INSTANCE_HOME=/john/oracle/instance_dir/inst_mydirです。

AGENT_PORT

(オプション)管理エージェント・プロセスを起動する空きポートを入力します。HTTPとHTTPSの両方に同じポートが使用されます。

たとえば、AGENT_PORT=1832です。

値を入力しない場合、3872または1830から1849の間の空きポートが適用されます。

b_startAgent

(オプション)管理エージェントをインストールして構成した後に自動的に起動する場合、TRUEを入力します。それ以外の場合はFALSEを入力します。

たとえば、b_startAgent=TRUEなどです。

このパラメータを追加しないと、デフォルトでTRUEが設定されます。

ORACLE_HOSTNAME

(オプション)管理エージェントをインストールするホストの完全修飾ドメイン名を入力します。

たとえば、ORACLE_HOSTNAME=example.comです。

このパラメータを追加しないと、デフォルトで物理ホスト名が設定されます。

ALLOW_IPADDRESS

(オプション)ORACLE_HOSTNAMEにIPアドレスを指定する場合にはTRUEを入力します。ALLOW_IPADDRESSがFALSEに設定された場合には、管理エージェントのインストール中にORACLE_HOSTNAMEにIPアドレスを指定すると、前提条件チェックは失敗します。

たとえば、ALLOW_IPADDRESS=TRUEなどです。

このパラメータを追加しないと、デフォルトでFALSEが設定されます。

START_PRIORITY_LEVEL

(UNIXベースのホストのみ)

(オプション) このパラメータは、ホスト起動時の管理エージェント・サービスの優先度を指定する場合に使用します。このパラメータは、0から99の間の値を受け付けます。ただし、このパラメータには91から99の間の値を指定することをお薦めします。

たとえば、START_PRIORITY_LEVEL=95などです。

このパラメータを追加しないと、デフォルトで98が設定されます。

SHUT_PRIORITY_LEVEL

(UNIXベースのホストのみ)

(オプション)このパラメータは、ホスト停止時の管理エージェント・サービスの優先度を指定する場合に使用します。このパラメータは0から99の間の値を受け付けます。

たとえば、SHUT_PRIORITY_LEVEL=25などです。

このパラメータを追加しないと、デフォルトで19が設定されます。

PROPERTIES_FILE

(オプション)プロパティ・ファイルの絶対位置を指定する場合にこのパラメータを使用します。

たとえば、PROPERTIES_FILE=/tmp/agent.propertiesなどです。

プロパティ・ファイルで管理エージェントのデプロイメントに使用するパラメータを指定します。プロパティ・ファイルで指定できるパラメータのリストは、$<AGENT_INSTANCE_HOME>/sysman/config/emd.propertiesにあります。プロパティ・ファイルでは、たとえば次のように名前と値のペアでパラメータを指定する必要があります。

REPOSITORY_PROXYHOST=abc.example.com

REPOSITORY_PROXYPORT=1532

プロパティ・ファイルでは、空白の入ったパラメータ値はサポートしていません。特定のパラメータの値に空白があった場合には、管理エージェントのデプロイ後に次のコマンドを実行します。

$<AGENT_INSTANCE_HOME>/bin/emctl setproperty agent -name <parameter_name> -value <parameter_value>

s_agentHomeName

(オプション)管理エージェント用に作成された表示するOracleホームの名前を入力します。

たとえば、s_agentHomeName=agent12cR2です。

このパラメータを追加しないと、デフォルトでagent12cnが設定されます(nはホストに最初にインストールされた管理エージェントの場合は1、2番目にインストールされた管理エージェントの場合は2)。

注意: 入力する名前は英数字のみで128文字以下としてください。

s_agentSrvcName

(Microsoft Windowsのホストのみ)

(オプション)カスタマイズされた管理エージェント・サービス名を入力します。

たとえば、s_agentSrvcName=agentsrvc1などです。

このパラメータを追加しないと、デフォルトでOracle+<oracle_home_name>+Agentが設定されます。

注意: (Microsoft Windowsホストの場合) ホストにインストールされた12.1.0.x管理エージェントをアップグレードし、異なるOMSを指定する別の管理エージェントを同じホストにインストールする場合、管理エージェントのインストール中にs_agentSrvcNameパラメータを指定してください。

6.4.7 RPMファイルを使用したサイレント・モードで管理エージェントをインストールするためのレスポンス・ファイル・パラメータ

表6-4は、.rpmファイルを使用して管理エージェントをインストールする際、レスポンス・ファイルに含める必要のある必須パラメータと、含めることができるオプションのパラメータを示しています。

表6-4 RPMファイルを使用してOracle Management Agentをインストールするためのレスポンス・ファイルの作成

パラメータ

説明

OMS_HOST

(必須)接続先のOMSのホスト名を入力します。

たとえば、OMS_HOST=example.comです。

OMS_PORT

(必須)アップロード・ポート(HTTPまたはHTTPS)を入力して、OMSと通信します。

たとえば、OMS_PORT=1835です。

AGENT_REGISTRATION_PASSWORD

(必須)Enterprise Managerシステムを結合する新しい管理エージェントを登録するパスワードを入力します。

デフォルトで、OMSと管理エージェント間の通信は保護およびロックされます。Enterprise Managerシステムに追加する新しい管理エージェントは、事前に認証を受ける必要があります。ここで入力するパスワードは、新しい管理エージェントを認証するために使用されます。

たとえば、AGENT_REGISTRATION_PASSWORD=Wel456comeです。

AGENT_USERNAME

(必須)管理エージェントをインストールするユーザー名を入力します。

たとえば、AGENT_USERNAME=oracleなどです。

AGENT_GROUP

(必須)管理エージェント・ユーザーが属す必要があるグループを入力します。

たとえば、AGENT_GROUP=dbaなどです。

AGENT_PORT

(オプション)管理エージェント・プロセスに使用するポートを入力します。

たとえば、AGENT_PORT=1832です。

値を入力しない場合、3872または1830から1849の間の空きポートが適用されます。

ORACLE_HOSTNAME

(仮想ホストのみ)管理エージェントをインストールする仮想ホスト名を入力します。

たとえば、ORACLE_HOSTNAME=example.comです。

6.4.8 AgentPullスクリプトでサポートされているオプション

表6-5は、AgentPull.shスクリプトでサポートされるオプションを示しています。Microsoft Windowsでは、これらのオプションはAgentPull.batファイルで利用できます。

表6-5 AgentPull.sh/AgentPull.batでサポートされるオプションの理解

オプション

説明

-download_only

管理エージェント・ソフトウェアのダウンロードのみを実行します。管理エージェントはデプロイしません。

-showPlatforms

管理エージェント・ソフトウェアがOMSホストで使用できるプラットフォームを表示します。管理エージェントはインストールしません。

-help

コマンドライン・ヘルプを表示して、AgentPull.shスクリプトの使用方法を説明します。

6.4.9 agentDeployスクリプトでサポートされているオプション

表6-6は、agentDeploy.shスクリプトでサポートされるオプションを示しています。Microsoft Windowsでは、これらのオプションはagentDeploy.batファイルで利用できます。

表6-6 agentDeploy.sh/agentDeploy.batでサポートされるオプションの理解

オプション

説明

-prereqOnly

前提条件チェックのみを実行します。実際に管理エージェントをインストールしないでください。

使用している環境が正常な管理エージェントのインストールのすべての前提条件チェックを満たしているかどうかを確認する場合、このオプションが便利です。

-ignorePrereqs

前提条件チェックの実行をスキップします。すでに-prereqOnlyオプションを使用して前提条件を確認し、ソフトウェア・バイナリをインストールするだけの場合に使用してください。

INVENTORY_LOCATION

中央インベントリ(oraInventory)の絶対パスを入力します。

たとえば、INVENTORY_LOCATION=$HOME/oraInventoryなどです。

重要:

- このオプションはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- 他のOracle製品がリモート・ホストにインストールされておらず、セントラル・インベントリ・ポインタ/var/opt/oracle/oraInst.loc (SolarisおよびHP-UXプラットフォーム用)または/etc/oraInst.loc (他のUNIXプラットフォーム用)が存在しない場合のみ、このオプションは使用できます。

- このオプションを使用する場合は、-invPtrLocオプションを使用しないでください。

-invPtrLoc

中央インベントリ(oraInventory)の場所を含むインベントリ・ファイルの絶対パスを入力します。

たとえば、-invPtrLoc /tmp/oraInst.locなどです。

重要:

- このオプションはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- 他のOracle製品がリモート・ホストにすでにインストールされており、セントラル・インベントリ・ポインタ/var/opt/oracle/oraInst.loc (SolarisおよびHP-UXプラットフォーム用)または/etc/oraInst.loc (他のUNIXプラットフォーム用)が存在していても、このオプションは使用できます。

- このオプションを使用する場合は、INVENTORY_LOCATIONオプションを使用しないでください。

-help

コマンドライン・ヘルプを表示して、デプロイメント・スクリプトの使用方法を説明します。

-debug

エラーのデバッグおよび解決に役立つ詳細なデバッグ・メッセージを記録します。

-ignoreUnzip

管理エージェント・ソフトウェアのソフトウェア・バイナリの抽出をスキップします。バイナリを再コピーしないで使用できるバイナリを構成するだけの場合に使用してください。

-softwareOnly

ソフトウェア・バイナリのみをインストールして、インストールを構成しません。管理エージェントのソフトウェアのみのインストールを実行する場合に使用してください。詳細は、第9章を参照してください。

注意: ZIPファイルを使用してクローニングしている場合、このオプションは適用されません。

-configOnly

ソフトウェア・バイナリを構成して、ソフトウェア・バイナリをインストールしません。構成のみがコピーされたソフトウェア・バイナリに実行されるため、-softwareOnlyオプションを使用してソフトウェアのみのインストールを実行した場合に使用してください。詳細は、第9章を参照してください。

注意: ZIPファイルを使用してクローニングしている場合、このオプションは適用されません。

-forceConfigure

OMSを使用できない場合でも、強制的に管理エージェントを構成します。OMSをインストールする前に管理エージェントをインストールし、渡すレスポンス・ファイルのパラメータOMS_HOSTおよびEM_UPLOAD_PORTにそれぞれ示されている同じホストおよびポートに後でOMSをインストールする場合のみ、このオプションを使用してください。

このオプションを渡す場合、-configOnly,、-softwareOnlyおよび-prereqOnlyを渡さないでください。

注意: このオプションを渡すと、HTTP (保護されていない)通信を使用するために管理エージェントが構成されます。管理エージェントおよびOMS間のセキュアなHTTPS通信を確立するため、OMSが使用可能になった後に管理エージェントを手動で保護する必要があります。

6.4.10 ダウンロードした管理エージェント・ソフトウェアの内容について

表6-7は、agentDeployスクリプトを使用して管理エージェントをインストールする前にダウンロードするコア管理エージェント・ソフトウェアの内容を示しています。

表6-7 ダウンロードした管理エージェント・ソフトウェアの内容

ファイル

説明

12.1.0.3.0_PluginsOneoffs_<platform id>.zip

OMSとともにインストールされたすべての検出プラグイン、Oracleホームの検出プラグインおよびOracleホームの監視プラグインを含むプラグインZIPファイル。

agentcoreimage.zip

コア・エージェント・ビットおよびエージェントsetuidバイナリを含むアーカイブ済ZIPファイル。

agentDeploy.sh/agentDeploy.bat

管理エージェントをデプロイするために使用されるスクリプト。

unzip

ZIPファイルのアーカイブを解除するために使用されるユーティリティ。

agentimage.properties

バージョンやプラットフォームIDなどを取得するために使用されるプロパティ・ファイル。

agent.rsp

管理エージェントをインストールするために編集して渡すレスポンス・ファイル。

6.4.11 管理エージェントRPMファイルの内容について

.rpmファイルを使用して管理エージェントをインストールする場合、ダウンロードした.rpmファイルには、エージェント・ベース・ディレクトリが含まれます。このエージェント・ベース・ディレクトリの内容を表6-8に示します。

表6-8 RPMファイルに存在するエージェント・ベース・ディレクトリの内容

要素

説明

core/12.1.0.4.0

管理エージェント・ソフトウェアが含まれます。

sbin

管理エージェント・バイナリが含まれます。

plugins.txt

管理エージェントにデプロイされるプラグインを指定するレスポンス・ファイル。

plugins

プラグイン・ソフトウェアが含まれます。

agentimage.properties

バージョンやプラットフォームIDなどを取得するために使用されるプロパティ・ファイル。

agent.properties

管理エージェントをインストールするために編集して渡すレスポンス・ファイル。

oracle-agt

管理エージェント構成スクリプト。

6.5 サイレント・モードでの管理エージェントのインストール後

管理エージェントのインストール後、次の手順を実行します。

1. (UNIXオペレーティング・システムのみ)rootユーザーとして次のスクリプトを手動で実行します。

- これがホストにインストールした最初のOracle製品である場合、orainstRoot.shスクリプトを、管理エージェント・ホームで使用可能なoraInst.locファイルで指定されたインベントリの場所から実行します。この場所は、agentDeployスクリプトを-configOnlyオプションとともに実行する際にも表示されます。
たとえば、指定されたインベントリの場所が$HOME/oraInventoryの場合、次のコマンドを実行します。

$HOME/oraInventory/orainstRoot.sh

- 管理エージェント・ホームから、次のroot.shスクリプトを実行します。
$<AGENT_HOME>/root.sh

注意:
.rpmファイルを使用して管理エージェントをインストールする場合は、orainstRoot.shおよびroot.shスクリプトを実行する必要はありません。

2. インストールを確認します。

1. 管理エージェント・ホームに移動して次のコマンドを実行すると、管理エージェントが動作していることを確認するメッセージが表示されます。
$<AGENT_INSTANCE_HOME>/bin/emctl status agent

2. 管理エージェント・ホームに移動して次のコマンドを実行すると、EMDアップロードが正常に完了したことを確認するメッセージが表示されます。
$<AGENT_INSTANCE_HOME>/bin/emctl upload agent

3. $<AGENT_BASE_DIRECTORY>/plugins.txtに一覧されたすべてのプラグインが正常にインストールされたかどうか確認します。これを行うには、次のコマンドを実行します。
$<AGENT_INSTANCE_HOME>/bin/emctl listplugins agent -type all

4. 間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、次のコマンドを実行して表示される手順に従います。
$<AGENT_INSTANCE_HOME>/bin/emctl resetTZ agent

5. デフォルトでは、ホストおよび管理エージェントは、監視のためにEnterprise Manager Cloud Controlコンソールに自動的に追加されます。ただし、そのホストで実行中のターゲットは、自動的に検出および監視されません。
その他のターゲットを監視するには、そのターゲットを、「自動検出の結果」ページ、「ターゲットの手動追加」ページまたは監視するターゲットに提供されている検出ウィザードを使用して、Enterprise Manager Cloud Controlに追加する必要があります。

Enterprise Manager Cloud Control,のターゲットの検出の詳細は、Oracle Enterprise Manager Cloud Controlの管理者ガイドのターゲットの追加に関する章を参照してください。

注意:

- 12c (12.1.0.x)管理エージェントが頻繁にハングする、またはSolaris 9uxおよび10uxオペレーティング・システムで応答しない場合、My Oracle SupportのドキュメントID 1427773.1を参照してください。

- Microsoft Windowsホストでの管理エージェントのデプロイ場所(管理エージェントのOracleホーム)を調べるには、<INVENTORY_LOCATION>\inventory.xmlにアクセスして、HOME NAME="agent12c2"を検索します。LOCパラメータの値が管理エージェントのOracleホームです。
たとえば、C:\Program Files\Oracle\inventory.xmlの次の行では、D:\agent12cr4\core\12.1.0.4.0が管理エージェントのOracleホームです。

<HOME NAME="agent12c2" LOC="D:\agent12cr4\core\12.1.0.4.0" TYPE="O" IDX="10">

- 既存の管理エージェントを新しいOracle Management Service (OMS)に再指定できます。この方法の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の付録「Oracle Management Agentの別のOracle Management Serviceへのリダイレクト」を参照してください。
既存の管理エージェントを新しいOMSに対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

7 Oracle Management Agentのクローニング

この章では、Cloud Controlコンソールまたはサイレント・モードを使用した既存のOracle Management Agent(管理エージェント)をクローニングする方法について説明します。この章の具体的な内容は次のとおりです。

- 管理エージェントのクローニングの概要

- 管理エージェントのクローニングを開始する前に

- 管理エージェントをクローニングするための前提条件

- 管理エージェントのクローニング

- 管理エージェントのクローニング後

7.1 管理エージェントのクローニングの概要

Oracle Management Agent (管理エージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントの1つで、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換できます。管理エージェントはプラグインと連携することにより、管理対象ホスト上で実行されているターゲットを監視します。

したがって、ホスト上で実行されているターゲットを監視するには、Oracle Management Agentをインストールして最初にこの管理対象外ホストを管理対象ホストに変換してから、監視を開始するためにそのホストで実行中のターゲットを手動で検出する必要があります。

ただし、他のインストール・タイプを使用してインストールする管理エージェントは常に、以前に実行したカスタマイズ構成や実行されている他の管理エージェントに適用した個別パッチのない、新規インストールです。

十分にテストされ、事前にパッチが適用されて実行中の既存の管理エージェントと同一の追加管理エージェントをインストールする場合は、既存のインスタンスをクローニングするのが適切なオプションです。これにより、フレッシュ・インストールにパッチを何度も適用し、最新の状態にするためにかかる時間と労力が節約されます。

グラフィック・モードまたはサイレント・モードで既存の管理エージェントをクローニングできます。

- グラフィック・モードで、Enterprise Manager Cloud Controlコンソールからアクセスできるホスト・ターゲットの追加ウィザードを使用します。このウィザードを使用すると、クローニングするソース管理エージェントを選択し、クローニングを行うリモート・ホストを1つ以上識別できます。
ウィザードは最初にソース管理エージェント・イメージをOracle Management Service (OMS)が実行されているホストにコピーしてから、コピーしたイメージを宛先ホストに転送します。ウィザードは単一の管理エージェントをリモートでクローニングするのに使用できますが、管理エージェントの一括デプロイ、特に、異なるプラットフォームのホストに異なるリリースの管理エージェントを一括デプロイするのに最も適しています。

- サイレント・モードで、転送する圧縮ファイル(ZIP)を使用します。ZIP形式では、既存の管理エージェントのOracleホームを圧縮して宛先ホストに転送するので、質問画面でパラメータや値を指定しなくてもすべての構成設定および適用済の個別パッチを保持できるため、はるかに簡単です。
管理エージェントをサイレント・モードでクローニングすると、クローニングされた管理エージェントをデプロイするすべてのプラットフォームに異なる圧縮ファイルを作成する必要があります。そのため、異なるプラットフォームのホストで管理エージェントの大規模デプロイを行う場合はこの方法は適していません。これは、同じプラットフォームのホストで管理エージェントをデプロイする場合の簡単かつ効率的な方法です。

管理エージェントのインストール後、ターゲットを監視するには、そのターゲットを、「自動検出の結果」ページ、「ターゲットの手動追加」ページまたは監視するターゲット用に提供されている検出ウィザードを使用して、Enterprise Manager Cloud Controlに追加する必要があります。

Enterprise Manager Cloud Control,のターゲットの検出の詳細は、Oracle Enterprise Manager Cloud Controlの管理者ガイドのターゲットの追加に関する章を参照してください。

インストールが完了すると、エージェント・ベース・ディレクトリに次のデフォルトの内容が含まれています。

<agent_base_directory>
|_____core
|_____12.1.0.4.0
|_____plugins
|_____plugins.txt
|_____plugins.txt.status
|_____agent_inst
|_____sbin
|_____agentimage.properties

注意:
既存の管理エージェントを新しいOracle Management Service (OMS)に再指定できます。この方法の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の付録「Oracle Management Agentの別のOracle Management Serviceへのリダイレクト」を参照してください。
既存の管理エージェントを新しいOMSに対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

7.2 管理エージェントのクローニングを開始する前に

Oracle Management Agentのクローニングを開始する前に、次の点に留意してください。

- (グラフィック・モードのみ)ホスト・ターゲットの追加ウィザードでは、既存のOracle Management Agentをクローニングすることにより、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換します。

- Oracle Management Agent 12cは、Oracle Management Service 12cとのみ通信し、以前のリリースのEnterprise Managerとは通信しません。
特定バージョンのOracle Management Agent 12cと特定バージョンのOracle Management Service 12c間の互換性の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- (グラフィック・モードのみ)ホスト・ターゲットの追加ウィザードを使用すると、(管理エージェントをクローニングしている)ソース・ホストおよび宛先ホストを同じオペレーティング・システムで実行している場合のみクローニングできます。そのため、異なるプラットフォームで実行しているホストがある場合、プラットフォームごとに1つのデプロイメント・セッションを持つ必要があります。

- 中央エージェント(OMSホストにインストールされた管理エージェント)をソース管理エージェントとして使用しないでください。

- クローニング中、ソース管理エージェントは停止しません。

- (グラフィック・モードのみ)共通のマウント済ドライブを複数のホストが共有している場合、管理エージェントのインストールは2つの異なるフェーズに分けられます。

1. 最初に、ホスト・ターゲットの追加ウィザードのデプロイメント・タイプ「既存のエージェントのクローニング」を選択して、管理エージェントをドライブを共有しているホストにクローニングします。この章に示されている手順に従います。

2. 次に、ホスト・ターゲットの追加ウィザードのデプロイメント・タイプ「共有エージェントへのホストの追加」を選択して、共有されているマウント済ドライブにアクセスできる他のすべてのホストに管理エージェントをインストールします。(ここでは、前の手順でインストールした管理エージェントを選択します。)詳細は、第8章に示されている手順に従ってください。

- 共有クラスタ上でのクローニングはサポートされていません。複数のノードでOracle RACクラスタを使用している場合、管理エージェントを各ノードに個別にクローニングする必要があります。つまり、ホスト・ターゲットの追加ウィザードでは、宛先ホストとして各ノードを明示的に追加する必要があります。

- (グラフィック・モードのみ)ホスト・ターゲットの追加ウィザードでは、SSHを使用して、管理エージェントをインストールするリモート・ホストとOracle Management Service (OMS)間の接続を確立します。

- (グラフィック・モードのみ)管理エージェントのデプロイ用としてサポートされているのは、OpenSSHによって提供されているSSH1 (SSHバージョン1)およびSSH2 (SSHバージョン2)プロトコルのみです。

- (グラフィック・モードのみ)ホスト・ターゲットの追加ウィザードは、管理者がこの操作用に特定の名前で登録した一連の資格証明をユーザーが使用できる名前付き資格証明をサポートします。オペレータは、管理者によって保存および格納される名前付き資格証明のみ選択でき、関連付けられている実際のユーザー名およびパスワードを確認しないため、パスワードのセキュリティの追加レイヤーを確保できます。
選択する名前付き資格証明にクローニングする権限がない場合、別のユーザー(ロックされたユーザー・アカウント)として実行するため、名前付き資格証明を設定できます。この場合、ウィザードはユーザーが選択する名前付き資格証明を使用してホストにログインしますが、ユーザーが設定するロックされたユーザー・アカウントを使用してクローニングします。

たとえば、User_A (リモート・ログイン・アクセスのできるユーザー・アカウント)という名前付き資格証明を作成し、必要な権限を持つUser_X (no direct loginが設定される管理エージェント・インストール・ユーザー・アカウント)として実行するように設定できます。この場合、ウィザードはUser_Aとしてホストにログインしますが、名前付き資格証明で指定されている権限委任設定(sudoまたはPowerBroker)を使用し、User_Xとしてインストールします。

- (グラフィック・モードのみ)名前付き資格証明では、SSH公開鍵認証およびパスワードベースの認証がサポートされています。そのため、パスワードを公開することなく、既存のSSH公開鍵認証を使用できます。
名前付き資格証明にSSH公開鍵認証を設定する手順は次のとおりです。

注意:
すでに名前付き資格証明にSSH公開鍵認証を設定しており、SSH鍵がすでに作成されている場合には、次の手順3で説明するようにSSH鍵をEnterprise Managerにアップロードします。

1. OMSホームの次の場所に移動します。
$<OMS_HOME>/oui/prov/resources/scripts

次に例を示します。

/home/software/em/middleware/oms/oui/prov/resources/scripts

2. OMSホストがOracle Solarisで稼働する場合は、sshUserSetup.shスクリプトを編集し、次のように変更します。
"SunOS") SSH="/usr/local/bin/ssh" SSH_KEYGEN="/usr/local/bin/ssh-keygen"

変更後

"SunOS") SSH="/usr/bin/ssh" SSH_KEYGEN="/usr/bin/ssh-keygen"

3. OMSホストがUNIXベースのオペレーティング・システムで稼働している場合、sshUserSetup.shスクリプトをOMSホストでOMSユーザーとして実行し、管理エージェントのインストール・ユーザー名とターゲット・ホストの完全修飾名を渡します。
sshUserSetup.sh -setup -user <agent_install_user_name> -hosts <target_hosts>

次のSSH鍵が作成されます。

$HOME/.ssh/id_rsa
$HOME/.ssh/id_rsa_pub

ここで、$HOMEはOMSインストール・ユーザーのホーム・ディレクトリです。

OMSホストがMicrosoft Windowsで稼働している場合、OMSホストにCygwinをインストールし(『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載)、次のスクリプトをOMSホストでOMSユーザーとして実行し、管理エージェントのインストール・ユーザー名とターゲット・ホストの完全修飾名を渡します。

sshUserSetupNT.sh -setup -user <agent_install_user_name> -hosts <target_hosts>

4. SSH鍵をEnterprise Managerにアップロードします。
「設定」メニューから、「セキュリティ」、「名前付き資格証明」の順に選択します。「作成」をクリックします。「資格証明名」には資格証明の名前を指定し、「資格証明のタイプ」には「SSHキー資格証明」を選択し、「有効範囲」には「グローバル」を選択します。「グローバル」オプションを選択しないと、「ホスト・ターゲットの追加」ウィザードを使用して管理エージェントをインストールするためにSSH名前付き資格証明を使用できません。

手順3で作成された秘密SSH鍵のうち1つをアップロードするには、「資格証明プロパティ」セクションで「秘密鍵のアップロード」フィールドの値として秘密SSH鍵の場所を指定します。「保存」をクリックします。

手順3で作成された公開SSH鍵のうち1つをアップロードするには、「資格証明プロパティ」セクションで「公開鍵のアップロード」フィールドの値として公開SSH鍵の場所を指定します。「保存」をクリックします。

図 7-1はSSH鍵をEnterprise Managerにアップロードする方法を示しています。

図 7-1 SSH鍵のEnterprise Managerへのアップロード

名前付き資格証明に対してSSH公開鍵認証をすでに設定している場合、ホスト・ターゲットの追加ウィザードを使用した管理エージェントのインストールの間に名前付き資格証明を使用できます。

- デフォルトで、ホスト・ターゲットの追加ウィザードでは、クローニング対象の管理エージェントで構成されたすべてのプラグインを構成します。

- サポート・ワークベンチ(インシデント)・メトリックを適切に実行するには、Oracle WebLogic Serverのアラート・ログ・ディレクトリに読取り権限が必要です。また、このOracle WebLogic Serverターゲットを監視している管理エージェントがOracle WebLogic Serverと同じホストで実行されていることも確認する必要があります。

- カーネル・パッチまたはパッチ・バンドルを適用してSolarisの下位リリースをアップグレードすることと、実際のSolaris 5.10 Update 9イメージをインストールすることは同じではありません。Oracle Management Agent 12cリリース4 (12.1.0.4)はSolaris 5.10 Update 9の最小更新版で構築され、テストおよび動作認証されているため、Oracle Management Agentは、パッチを使用してアップグレードした他のリリースではなくSolaris 5.10 Update 9にインストールすることをお薦めします。

7.3 管理エージェントをクローニングするための前提条件

管理エージェントをクローニングする前に、次の前提条件を満たしていることを確認してください。

表7-1 Oracle Management Agentをクローニングするための前提条件

要件

説明

ハードウェアの要件

ハード・ディスク領域および物理メモリー要件を満たしていることを確認します。詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章を参照してください。

ソフトウェアの要件

(グラフィック・モードのみ)

(Microsoft Windowsの場合) Cygwin 1.7が宛先ホストにインストールされていることを確認します。詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のCygwinのインストールに関する章を参照してください。

注意: Microsoft Windows Server 2008およびMicrosoft Windows Vistaでcygwin.batを実行する際は、必ず管理者モードで起動してください。これを行うには、cygwin.batファイルを右クリックし、「管理者として実行」を選択します。

オペレーティング・システム要件

管理エージェントは、「My Oracle Support」のEnterprise Managerの動作保証マトリックスに記載された動作保証済のオペレーティング・システムにのみインストールしてください。

Enterprise Managerの動作保証マトリックスにアクセスするには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明している手順を実行します。

今後のサポート対象プラットフォームの詳細は、My Oracle Supportのノート793512.1を参照してください。

注意: Oracle Solaris 10を使用する場合、アップデート9以上がインストールされていることを確認します。インストールされているかどうかを確認するには、次のコマンドを実行します。

cat /etc/release

次のような出力が表示されます。ここで、s10s_u6は、アップデート6 (インストールがサポートされていない更新レベル)がインストールされていることを示します。

Solaris 10 10/08 s10s_u6wos_07b SPARC

ファイルシステム要件

宛先ホストにマウントされたファイルシステムでバッファに入れられた書込みが許可されないことを確認します。

ファイル記述子要件

- ユーザー・プロセスの上限が13312以上に設定されていることを確認します。
現在の設定値を確認するには、次のコマンドを実行します。

ulimit -u

現在の値が13312以上でない場合は、13312以上に設定するようにシステム管理者に連絡してください。

- ファイル記述子のソフト・リミットを最小の4096に、ハード・リミットを16384以下に設定していることを確認します。
現在の設定値を確認するには、次のコマンドを実行します。

ソフト・リミットの場合:

/bin/sh -c "ulimit -n"

ハード・リミットの場合:

/bin/sh -c "ulimit -Hn"

現在の値が4096未満の場合、rootユーザーとして、次のエントリで/etc/security/limits.confファイルを更新してください。

<UID> soft nofile 4096

<UID> hard nofile 16384

パッケージ要件

すべてのオペレーティング・システム固有のパッケージをインストールしていることを確認します。詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのパッケージ要件に関する章を参照してください。

ユーザーおよびオペレーティング・システム・グループの要件

管理エージェントのインストール先のホストに適切なユーザーおよびオペレーティング・システム・グループが作成されていることを確認します。

詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのオペレーティング・システム・グループおよびユーザーの作成に関する章を参照してください。

注意: OMSインストールのオペレーティング・システム・ユーザー・アカウントを使用した管理エージェントのインストールに対するポリシーが企業にある場合は、異なるオペレーティング・システム・ユーザー・アカウントを使用して管理エージェントをインストールできます。ただし、使用するユーザー・アカウントおよびOMSインストールのユーザー・アカウントが同じプライマリ・グループに属していることを確認します。

/etc/hostsファイル要件

ホストの/etc/hostsファイルでIPアドレス、完全修飾名および短縮名が次の形式で使用されていることを確認します。

172.16.0.0 example.com mypc

宛先ホストの要件

宛先ホストにOMSを実行しているホストからアクセスできることを確認します。

宛先ホストとOMSが実行されているホストが別のネットワーク・ドメインに属している場合、宛先ホストの/etc/hostsファイルを更新して、そのホストのIPアドレス、完全修飾名および短縮名を含む1行を追加していることを確認します。

たとえば、完全修飾ホスト名がexample.comで、短縮名がmypcの場合は、/etc/hostsファイル内に次の行を追加します。

172.16.0.0 example.com mypc

宛先ホストの資格証明の要件

(グラフィック・モードのみ)

同じオペレーティング・システムを実行しているすべての宛先ホストに同じ資格証明セットが使用されていることを確認します。たとえば、Linuxオペレーティング・システムを実行しているすべての宛先ホストに同じ資格証明セットを使用する必要があります。

ウィザードは、同じユーザー・アカウントを使用して、管理エージェントをインストールします。同じオペレーティング・システムを実行しているホストで異なる資格証明を使用している場合、2つの異なるデプロイメント・セッションを使用します。

接続先ホストのタイムゾーン要件

(グラフィック・モードのみ)

接続先ホストのタイムゾーンが正しく設定されていることを確認します。接続先ホストのタイムゾーンを確認するには、OMSホストにログインし、次のコマンドを実行します。

ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

タイムゾーンが正しく表示されない場合、接続先ホストにログインし、次の手順を実行します。

1. 次のコマンドを実行して、接続先ホストにタイムゾーンを設定します。

- Kornシェルの場合:
TZ=<value>

export TZ

- BourneシェルまたはBashシェルの場合:
export TZ=<value>

- Cシェルの場合:
setenv TZ <value>

たとえば、Bashシェルで、タイムゾーンをAmerica/New_Yorkに設定するには、次のコマンドを実行します。

export TZ='America/New_York'

Microsoft Windowsで稼働する宛先ホストにタイムゾーンを設定するには、「スタート」メニューから、「コントロール パネル」を選択します。「日付と時刻」をクリックし、「タイムゾーン」タブを選択します。表示されたドロップダウン・リストからタイムゾーンを選択します。

使用できるタイムゾーンの一覧を確認するには、中央エージェント(OMSホストにインストールされた管理エージェント)の<AGENT_HOME>/sysman/adminディレクトリにあるsupportedtzs.lstファイルにアクセスします。

2. SSHデーモンを再起動します。
接続先ホストがUNIXベースのオペレーティング・システムで実行されている場合、次のコマンドを実行します。

sudo /etc/init.d/sshd restart

接続先ホストがMicrosoft Windowsのオペレーティング・システムで実行されている場合、次のコマンドを実行します。

cygrunsrv -E sshd

cygrunsrv -S sshd

3. OMSホストにログインして次のコマンドを実行し、SSHサーバーがTZ環境変数にアクセスできるかどうかを確認します。
ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

注意: クローニングを実行中に間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、管理エージェントのクローニング後、宛先ホストで正しいタイムゾーンを設定する必要があります。クローニング後のタイムゾーンの設定の詳細は、第7.5項を参照してください。

タイムゾーン要件

(サイレント・モードのみ)

ホストのタイムゾーンが正しく設定されていることを確認します。ホストのタイムゾーンを確認するには、次のコマンドを実行します。

echo $TZ

表示されたタイムゾーンが正しくない場合は、agentDeploy.shまたはagentDeploy.batスクリプトを実行する前に、次のコマンドを実行して正しいタイムゾーンを設定します。

- Kornシェルの場合:
TZ=<value>

export TZ

- BourneシェルまたはBashシェルの場合:
export TZ=<value>

- Cシェルの場合:
setenv TZ <value>

たとえば、Bashシェルで、タイムゾーンをAmerica/New_Yorkに設定するには、次のコマンドを実行します。

export TZ='America/New_York'

Microsoft Windowsで稼働する宛先ホストにタイムゾーンを設定するには、「スタート」メニューから、「コントロール パネル」を選択します。「日付と時刻」をクリックし、「タイムゾーン」タブを選択します。表示されたドロップダウン・リストからタイムゾーンを選択します。

使用できるタイムゾーンの一覧を確認するには、中央エージェント(OMSホストにインストールされた管理エージェント)の<AGENT_HOME>/sysman/adminディレクトリにあるsupportedtzs.lstファイルにアクセスします。

注意:

- Microsoft Windows Server 2003で稼働するホストに管理エージェントをインストールするときに、アジア/コルカタ・タイムゾーンを使用してエラーが発生する場合には、My Oracle Supportノート1530571.1を参照してください。

- クローニングを実行中に間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、管理エージェントのクローニング後、ホストで正しいタイムゾーンを設定する必要があります。クローニング後のタイムゾーンの設定の詳細は、第7.5項を参照してください。

注意: クローニングを実行中に間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、管理エージェントのクローニング後、ホストで正しいタイムゾーンを設定する必要があります。クローニング後のタイムゾーンの設定の詳細は、第7.5項を参照してください。

sudo/pbrun/sesu/su SSH要件

(グラフィック・モードのみ)

(UNIXの場合のみ)

使用している権限委任ツールで、SSH経由のリモート・コマンドの実行に擬似端末が必要な場合は、必ず$<OMS_HOME>/sysman/prov/agentpush/agentpush.propertiesファイルのoracle.sysman.prov.agentpush.enablePtyプロパティをtrueに設定してください。pbrun、sesu、suなどの権限委任ツールの多くは、デフォルトで、リモート・コマンドの実行に擬似端末を必要とします。

注意: 権限委任ツールにsudoを使用している場合、oracle.sysman.prov.agentpush.enablePtyプロパティをtrueに設定しないときは、次のいずれかを実行します。

- /etc/sudoersファイルにDefaults visiblepwを含めるか、「インストールの詳細」ページの「権限委任設定」で、sudoコマンドを-Sオプション付きで入力します。
「インストールの詳細」ページへアクセスする方法の詳細は、第7.4.1項を参照してください。

- /etc/sudoersファイル内のDefaults requirettyをコメント化します。

sudo/pbrun/sesu/suの要件(Rootユーザーの場合)

(グラフィック・モードのみ)

(UNIXの場合のみ)

- インストール・ユーザーにidコマンドおよびagentdeployroot.shスクリプトをrootとして実行する権限があることを確認します。権限委任ツールの構成ファイルで権限を付与します。
たとえば、権限委任ツールにsudoを使用している場合は、/etc/sudoersファイルに次の内容を追加して、必要な権限を付与します。

<install_user> ALL=(root) /usr/bin/id, <agent_home>/*/agentdeployroot.sh

たとえば、oracle ALL=(root) /usr/bin/id, /home/oracle/agentibd/*/agentdeployroot.shなどです。

ここで、oracleはインストール・ユーザーで、/home/oracle/agentibdは管理エージェント・ホーム(つまり、エージェント・ベース・ディレクトリ)です。

- 管理エージェントのインストールには、/etc/sudoersファイルに次のエントリは不要です。ただし、このエントリは、Enterprise Managerでプロビジョニングとパッチ適用を実行するために必要です。したがって、管理エージェントをインストールする前にこのエントリを削除する場合、管理エージェントのインストール後に、このエントリを戻してください。
Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、リリース3 (12.1.0.3)またはリリース4 (12.1.0.4)の場合:

(root) /<AGENT_BASE_DIRECTORY>/sbin/nmosudo

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1) [バンドル・パッチ1]の場合:

(root) /<AGENT_INSTANCE_DIRECTORY>/bin/nmosudo

sudo/pbrun/sesu/suの要件(ロックされたアカウント・ユーザーの場合)

(グラフィック・モードのみ)

(UNIXの場合のみ)

インストール・ユーザーに/bin/shをロックされたアカウント・ユーザーとして実行する権限があることを確認します。権限委任ツールの構成ファイルで権限を付与します。

たとえば、権限委任ツールにsudoを使用している場合は、/etc/sudoersファイルに次の内容を追加して、必要な権限を付与します。

login_user1 ALL=(oracle) /bin/sh

ここで、login_user1はSSHログイン・ユーザー、oracleはロックされたアカウント・ユーザーおよびインストール・ユーザーです。

ロックされたアカウント・ユーザーとして/bin/shを実行する権限をインストール・ユーザーに付与する場合は、oracle.sysman.prov.agentpush.pdpShellOutEnabledプロパティをfalseに設定し、id、chmod、cp、mkdir、rm、tar、emctl、agentDeploy.sh、runInstallerおよびunzipをロックされたアカウント・ユーザーとして実行する権限がインストール・ユーザーにあることを確認します。権限委任ツールの構成ファイルで権限を付与します。

たとえば、権限委任ツールにsudoを使用している場合は、/etc/sudoersファイルに次の内容を追加して、必要な権限を付与します。

login_user1 ALL=(oracle) /usr/bin/id, /bin/chmod, /bin/cp, /bin/mkdir, /bin/rm, /bin/tar, /home/oracle/agentibd/agent_inst/bin/emctl, /home/oracle/agentibd/*/agentDeploy.sh, /home/oracle/agentibd/*/prereq_stage/core/12.1.0.4.0/oui/bin/runInstaller, /home/oracle/agentibd/*/unzip, /home/oracle/agentibd/*/unzipTmp/unzip

ここで、login_user1はSSHログイン・ユーザー、oracleはロックされたアカウント・ユーザーおよびインストール・ユーザー、および/home/oracle/agentibdはエージェント・ベース・ディレクトリです。

権限要件

- 指定するエージェント・ベース・ディレクトリが空で、書込み権限があることを確認します。

- インスタンス・ディレクトリが空で、書込み権限があることを確認します。

PATH環境変数要件

(グラフィック・モードのみ)

宛先ホスト上で、次の内容を確認します。

- (Microsoft Windowsの場合) PATH環境変数内でCygwinソフトウェアの場所が他のソフトウェアの場所よりも前に指定されていることを確認します。最初のエントリであることを確認した後、SSHデーモン(sshd)を再起動します。

- (UNIXの場合)宛先ホストで、PATH環境変数内にSCPバイナリ(/usr/bin/scpなど)が存在することを確認します。

パス検証の要件

すべてのコマンドの場所へのパスを検証します。詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのコマンド場所の検証に関する付録を参照してください。

CLASSPATH環境変数の要件

CLASSPATH環境変数の設定を解除します。インストールの完了後、常にこの変数を元の値にリセットできます。

一時ディレクトリの領域要件

実行可能ファイルがコピーされる一時ディレクトリに、400MBの領域が割り当てられていることを確認します。

デフォルトでは、環境変数TMPまたはTEMPに設定されている一時ディレクトリの場所が適用されます。両方が設定されている場合、TEMPが適用されます。いずれも設定されていない場合、UNIXホストは/tmp、Microsoft Windowsホストはc:\Tempとしてデフォルト値が適用されます。

エージェント・ベース・ディレクトリの要件

エージェント・ベース・ディレクトリが空で、1GB以上の空き領域があることを確認します。

ディレクトリ名に空白が含まれていないことを確認します。

インストール・ユーザーはエージェント・ベース・ディレクトリを所有します。エージェント・ベース・ディレクトリおよびその親ディレクトリには、インストール・ユーザーに対する読取り、書込みおよび実行権限があります。インストール・ユーザーまたはrootユーザーはエージェント・ベース・ディレクトリのすべての親ディレクトリを所有し、その親ディレクトリにはインストール・ユーザー・グループおよびその他のすべてのユーザーに対する読取りおよび実行権限があることを確認します。また、rootユーザーがルート・ディレクトリを所有することを確認します。

たとえば、エージェント・ベース・ディレクトリが/scratch/OracleHomes/agentで、インストール・ユーザーがoracleの場合、/scratch/OracleHomes/agentディレクトリはoracleが、scratchおよびOracleHomesディレクトリはoracleまたはrootユーザーが、ルート・ディレクトリ(/)はrootユーザーが所有している必要があります。

エージェントのベース・ディレクトリがマウントされている場合、setuidがオンになってマウントされていることを確認します。

デフォルトのSSHポートの要件

(グラフィック・モードのみ)

SSHデーモンがすべての宛先ホストのデフォルト・ポート(22)で実行されていることを確認します。UNIXホストのSSHポートを確認するには、次のコマンドを実行します。

netstat -anp | grep -i sshd

たとえば、コマンドからの出力は次のようになります。

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3188/sshd

この出力は、SSHデーモンがポート22で実行中であることを示します。

また、UNIXホストでは、次のコマンドを実行してSSHポートを検証できます。

cat /etc/ssh/sshd_config

Microsoft Windowsでは、SSHポートの値はC:\cygwin\etc\sshd_configファイルにあります。

デフォルト以外(22以外)のSSHポートを使用している場合は、次のファイル内のSSH_PORTプロパティを更新します。

$<OMS_HOME>/oui/prov/resources/Paths.properties

ソフトウェア可用性の要件

(グラフィック・モードのみ)

既存の管理エージェントをクローニングする場合

使用している環境でOracle Management Agent 12cがすでに実行されていることを確認します。実行されているプラットフォームが、クローニングの宛先ホストのプラットフォームと同じであることを確認します。

共有Oracleホームを使用して管理エージェントをインストールする場合

マウント済の共有場所にマスター・エージェントとしてすでにOracle Management Agent 12cがインストールされていることを確認します。

インストール・ベース・ディレクトリの要件

(グラフィック・モードのみ)

「インストールのベース・ディレクトリ」フィールドに指定するエージェント・ベース・ディレクトリが空であり、書込み権限を持っていることを確認します。

ジョブ・システム要件

クローニングするソース管理エージェントでジョブ・システムが有効になっていることを確認します。

インストール・ユーザーの要件

中央インベントリ所有者と管理エージェントをインストールするユーザーが異なる場合、両者が同じグループに属していることを確認します。

また、インベントリ所有者と所有者が属するグループに中央インベントリに対する読取りおよび書込み権限があることも確認します。

たとえば、インベントリ所有者がabcで、管理エージェントをインストールするユーザーがxyzの場合、abcとxyzが同じグループに属し、双方が中央インベントリに対する読取りおよび書込みアクセスを持っていることを確認してください。

中央インベントリ(oraInventory)の要件

- すべての宛先ホストにおいて、中央インベントリに100MBの領域が割り当てられていることを確認します。

- すべての宛先ホスト上のoraInventoryに対して読取り権限、書込み権限および実行権限があることを確認します。宛先ホスト上のデフォルト・インベントリ(通常は/etc/oraInst.loc)に対してこれらの権限がない場合、「ホスト・ターゲットの追加」ウィザードの「追加パラメータ」フィールドのいずれかのオプションを使用して、別のインベントリの場所のパスを指定してください。ただし、これらのパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。
INVENTORY_LOCATION=<absolute_path_to_inventory_directory>

-invPtrLoc <absolute_path_to_oraInst.loc>

ポート要件

第2.1.10.1項で説明されているデフォルトのポートを使用できることを確認します。

エージェント・ユーザー・アカウント権限

(Microsoft Windowsのみ)

(Microsoft Windowsの場合) Microsoft Windowsベースのオペレーティング・システム上に管理エージェントをインストールする場合、エージェント・ユーザー・アカウントに次を実行する権限があることを確認します。

- オペレーティング・システムの一部として機能

- プロセスのメモリー割当ての調整

- プロセス・レベル・トークンの置換え

- バッチ ジョブとしてログオン

エージェント・ユーザーにこれらの権限があることを確認するには、次の手順を実行します。

1. 「ローカル セキュリティ ポリシー」を起動します。
「スタート」 メニューから「設定」をクリックし、「コントロール パネル」を選択します。「コントロール パネル」ウィンドウから「管理ツール」を選択し、「管理ツール」ウィンドウから「ローカル セキュリティ ポリシー」を選択します。

2. 「ローカル セキュリティ ポリシー」ウィンドウで、ツリー構造から「ローカル ポリシー」を開き、「ユーザー権利の割り当て」を開きます。

cmd.exeの権限

(Microsoft Windowsの場合)Microsoft Windowsベースのオペレーティング・システム上に管理エージェントをインストールする場合、バッチ・ジョブを実行するユーザー・アカウントにCmd.exeプログラムの読取り権限および実行権限を付与していることを確認します。これはMicrosoftからの制約事項です。

この制約事項、および権限を付与する方法の詳細は、次のMicrosoft WebサイトへのURLにアクセスしてください。

http://support.microsoft.com/kb/867466/en-us

ランタイム・ライブラリ・ファイル要件

(Microsoft Windowsの場合) Microsoft Windowsベースのオペレーティング・システム上に管理エージェントをインストールする場合、Msvcp71.dllおよびMsvcr71.dllランタイム・ライブラリ・ファイルがc:\windows\system32にあることを確認します。

インストール前/インストール後スクリプトの要件

(グラフィック・モードのみ)

インストールとともに実行するインストール前スクリプトとインストール後スクリプトがOMSホスト、宛先ホストまたは宛先ホストにアクセスできる共有場所で使用可能であることを確認します。

ブラウザ要件

- 「My Oracle Support」のEnterprise Managerの動作保証マトリックスに記載されている動作保証済のブラウザを必ず使用してください。
Enterprise Managerの動作保証マトリックスにアクセスするには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明している手順を実行します。

- Microsoft Internet Explorer 8または9を使用する場合、次の手順を実行します。

- 互換表示モードを無効にします。これを行うには、Microsoft Internet Explorerの「ツール」メニューの「互換表示」をクリックして、有効な場合は無効にします。また、「互換表示設定」をクリックして、Enterprise Manager Cloud ControlコンソールURLを登録解除します。

- XMLHTTPを有効にします。これを行うには、「ツール」メニューから「インターネット オプション」をクリックします。「詳細設定」タブをクリックして、「セキュリティ」見出しの「ネイティブ XMLHTTP サポートを有効にする」を選択して有効にします。

7.4 管理エージェントのクローニング

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

- グラフィック・モードでの管理エージェントのクローニング

- サイレント・モードでの管理エージェントのクローニング

重要:
OMSホストがMicrosoft Windowsで稼働していて、OMSソフトウェアがC:\以外のドライブにインストールされている場合は、$OMS_HOME\oui\prov\resources\ssPaths_msplats.propertiesのSCRATCH_PATH変数を更新します。
たとえば、OMSソフトウェアがD:\にインストールされている場合は、SCRATCH_PATH変数をD:\tmpadaに更新してください。

7.4.1 グラフィック・モードでの管理エージェントのクローニング

この項では、Cloud Controlコンソールを使用して管理エージェントをクローニングする方法について説明します。内容は次のとおりです。

- ホスト・ターゲットの追加ウィザードを使用した管理エージェントのクローニング

- ホスト・リスト・ファイルの形式

- グラフィック・モードでの管理エージェントのクローニングでサポートされる追加パラメータ

7.4.1.1 ホスト・ターゲットの追加ウィザードを使用した管理エージェントのクローニング

ホスト・ターゲットの追加ウィザードを使用してグラフィック・モードで管理エージェントをクローニングするには、次の手順に従います。

1. Cloud Controlで、次のいずれかの操作を行います。

- 「設定」メニューから、「ターゲットの追加」を選択し、「自動検出の結果」をクリックします。「自動検出の結果」ページで、Enterprise Manager Cloud Controlで監視するホストを選択し、「昇格」をクリックします。

Enterprise Manager Cloud Controlにホストの追加ウィザードが表示され、既存の管理エージェントをクローニングするオプションが選択できるようになります。

- 「設定」メニューから、「ターゲットの追加」を選択し、「ターゲットの手動追加」をクリックします。「ターゲットの手動追加」ページで、「ホスト・ターゲットの追加」を選択し、「ホストの追加」をクリックします。

Enterprise Manager Cloud Controlにホストの追加ウィザードが表示され、既存の管理エージェントをクローニングするオプションが選択できるようになります。

2. ホストとプラットフォーム・ページで、次を実行します。

1. このセッションに割り当てられたデフォルトの名前のままにするか、選択した一意の名前を入力します。入力するカスタム名は直観的な名前にすることができ、必ずしもデフォルトの名前と同じフォーマットにする必要はありません。例: add_host_operation_1
一意のデプロイメント・アクティビティ名によって、このデプロイメント・セッションで指定されたクローニング詳細を保存し、新規セッションですべての詳細を入力しなおすことなく、将来再利用できます。

2. 「追加」をクリックし、管理エージェントをクローニングするホストの完全修飾名およびプラットフォームを選択します。

注意:

- ホストの完全修飾ドメイン名を入力することをお薦めします。監視のため、Enterprise Manager Cloud Controlは、ここで入力した正確な名前でホストおよび管理エージェントを追加します。

- 行当たり入力するホスト名は1つのみにする必要があります。複数のホスト名をカンマで区切って入力することはサポートされていません。

- 入力するホスト名にアンダースコアがないことを確認する必要があります。

または、「ファイルからロード」をクリックしてファイルに格納されたホスト名を追加するか、「検出されたホストから追加」をクリックしてEnterprise Managerで検出されたホストのリストからホスト名を追加できます。ホスト名エントリをホスト・ファイルに表示する方法の詳細は、第7.4.1.2項を参照してください。

注意:
「検出されたホストの追加」をクリックして検出されたホストのリストからホストを追加すると、ホストのプラットフォームが自動的に検出されて表示されます。自動検出で受信したヒントおよびOMSホストのプラットフォームを含む要素の組合せを使用して、プラットフォーム名が検出されます。このデフォルトのプラットフォーム名は提案なので、次の手順に進む前にプラットフォームの詳細を確認することを強くお薦めします。

ソース・ホストおよび宛先ホストが同じプラットフォームで稼働している場合のみクローニングできるため、表の最初の行の最初のホストのプラットフォームを設定し、「プラットフォーム」リストから、「すべてのホストで同一」を選択します。これにより、最初のホストに選択したプラットフォーム名が表の残りのホストにも設定されます。

注意:
OMSホストが稼働しているプラットフォームとは別のプラットフォームに管理エージェントをクローニングする場合、そのプラットフォーム用の管理エージェント・ソフトウェアがOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)で入手可能なことを確認してください。必要なプラットフォーム用の管理エージェント・ソフトウェアがソフトウェア・ライブラリから入手できない場合は、自己更新コンソールを使用してソフトウェアを取得および適用してください。
自己更新コンソールにアクセスするには、「設定」メニューから、「拡張性」を選択し、「自己更新」を選択します。最新の管理エージェントのソフトウェアを入手するには、「エージェント・ソフトウェア」をクリックし、必要なソフトウェアを選択してから「ダウンロード」をクリックします。

自己更新コンソールを使用してプラットフォーム用の管理エージェント・ソフトウェアを取得および適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

3. 「次へ」をクリックします。

3. 「インストールの詳細」ページで、次のようにします。

1. 「デプロイメント・タイプ」セクションで、既存のエージェントのクローニングを選択します。「ターゲットの選択」で、懐中電灯アイコンをクリックして、クローニングする管理エージェントを選択します。

注意:

- 中央エージェント(OMSホストにインストールされた管理エージェント)をソース管理エージェントとして使用しないでください。

- 共通の済ドライブを複数のホストが共有している場合、管理エージェントのインストールは2つの異なるフェーズに分けられます。

1. ホスト・ターゲットの追加ウィザードで、デプロイメント・タイプ「既存のエージェントのクローニング」を選択し、ドライブが共有されているホストに管理エージェントをクローニングします。

2. ホスト・ターゲットの追加ウィザードで、デプロイメント・タイプ「共有エージェントへのホストの追加」を選択し、共有されているマウント済ドライブにアクセスできる他のすべてのホストに管理エージェントをインストールします。(ここでは、前の手順でマスター・エージェントまたは共有エージェントとしてクローニングした管理エージェントを選択します。)

図7-2は、この手順を示しています。

図7-2 管理エージェントのクローニング

2. 表から、共通のプラットフォーム名でグループ化されたホストを示す最初の行を選択します。

3. 「インストールの詳細」セクションで、ステップ3 (b)で選択したホストに共通するインストールの詳細を指定します。「インストールのベース・ディレクトリ」に、管理エージェントのソフトウェア・バイナリ、セキュリティ・ファイルおよびインベントリ・ファイルをコピーするエージェント・ベース・ディレクトリへの絶対パスを入力します。
たとえば、/usr/home/software/oracle/agentHomeなどです。

入力したパスが存在しない場合は、指定されたパスにディレクトリが作成され、管理エージェントのソフトウェア・バイナリ、セキュリティ・ファイルおよびインベントリ・ファイルがその場所にコピーされます。

注意:
インストールのベース・ディレクトリは、基本的にはエージェント・ベース・ディレクトリです。指定するディレクトリが空であることを確認します。以前に実行したデプロイメント・セッションがなんらかの理由で失敗した場合、インストール・ベース・ディレクトリにADATMP_<timestamp>サブディレクトリがある可能性があります。この場合、サブディレクトリを削除してデプロイメント・セッションを新たに開始するか、失敗したセッションを「ホスト・ステータスの追加」ページから再試行します。

4. 「インスタンス・ディレクトリ」で、デフォルトのインスタンス・ディレクトリの場所のままにするか、すべての管理エージェント関連の構成ファイルを格納できるディレクトリを選択し、そこへの絶対パスを入力します。
たとえば、/usr/home/software/oracle/agentHome/agent_instなどです。

カスタムの場所を入力する場合、そのディレクトリに書込み権限があることを確認してください。インストールのベース・ディレクトリ内のインスタンス・ディレクトリを保持することをお薦めします。

入力したパスが存在しない場合は、指定されたパスにディレクトリが作成され、管理エージェントに関連するすべての構成ファイルがその場所にコピーされます。

5. 「名前付き資格証明」リストから、資格証明がOMSとリモート・ホスト間のSSH接続を設定し、各リモート・ホストに管理エージェントをインストールするのに使用できる適切なプロファイルを選択します。

注意:

- 資格証明プロファイルがない場合、または資格証明プロファイルはあるが「名前付き資格証明」リストで見つからない場合、このリストに対するプラス・アイコンをクリックします。名前付き資格証明の新規作成ウィンドウに、資格証明を入力し、適切なプロファイル名で格納して、管理エージェントのインストールに選択および使用できるようにします。また、作成している名前付き資格証明から、インストールの実行権限を持つ別のユーザーに切り替えるには、実行権限を設定します。

- このリストに対するプラス・アイコンが無効な場合、資格証明があるプロファイルを作成する権限がありません。この場合、管理者に連絡して、新規プロファイルの作成権限を付与してもらうようリクエストするか、プロファイルを作成してもらい、「名前付き資格証明」リストにプロファイルを表示するアクセス権を付与してもらうようリクエストします。

- OMSとリモート・ホスト間のSSH公開キー認証を手動で設定している場合、ユーザー・アカウントのパスワードがない可能性があります。この場合、仮パスワードを使用して、名前付き資格証明を作成します。パスワード・フィールドは空のままにしないでください。

6. 「権限委任設定」で、rootスクリプトの実行に使用する権限委任設定を検証します。デフォルトでは、Enterprise Manager Cloud Controlで構成されている権限委任設定に設定されます。
たとえば、「権限委任設定」フィールドには、次のいずれかを指定できます。

/usr/bin/sudo -u %RUNAS% %COMMAND%
/usr/bin/sudo -u -S %RUNAS% %COMMAND% (if a pseudo terminal is required for remote command execution via SSH)
/usr/bin/sesu - %RUNAS% -c "%COMMAND%"
/usr/bin/pbrun %PROFILE% -u %RUNAS% %COMMAND%
/usr/bin/su - %RUNAS% -c "%COMMAND%"

「権限委任設定」フィールドを空白のままにしておくと、ウィザードではrootスクリプトが実行されないため、インストール後に手動で実行する必要があります。手動による実行の詳細は、第7.5項を参照してください。

この設定は、選択した名前付き証明の「別名実行」属性で設定されたユーザーとしてのインストールの実行にも使用されます(この名前付き資格証明の作成時にユーザーを設定している場合)。

注意:
権限委任設定での%RUNAS%は、ルート・スクリプトを実行するルート・ユーザー、および名前付き資格証明の「別名実行」属性で設定された、インストールを実行するユーザーとしての権限を持ちます。

7. 「ポート」で、管理エージェントの通信用に割り当てられたデフォルトのポート(3872)のままにするか、選択したポートを入力します。
入力するカスタム・ポートはビジー状態ではない必要があります。不明な場合、このフィールドを空白にしておくことができます。Enterprise Manager Cloud Controlによって、1830 - 1849の範囲から最初の使用可能な空きポートが自動的に割り当てられます。

8. (オプション)「オプションの詳細」セクションで、実行するインストール前スクリプトおよびインストール後スクリプトを使用できるアクセス可能な場所への絶対パスを入力します。インストール前スクリプトまたはインストール後スクリプトを1つのみ指定できることに注意してください。
スクリプトをrootとして実行するには、「Rootとして実行」を選択します。管理エージェントをインストールするホスト上ではなく、OMSが実行されているホスト上にスクリプトがある場合、「OMSのスクリプト」を選択します。この場合、スクリプトはOMSホストから接続先ホストにコピーされてから、接続先ホストで実行されます。

9. (オプション)「追加パラメータ」で、インストール時に渡す追加パラメータの空白区切りのリストを入力します。サポートされている追加パラメータの完全なリストは、表7-2を参照してください。
たとえば、インベントリ・ポインタの場所ファイルを指定する場合、-invPtrLocの後ろにファイルの場所への絶対パスを入力します。このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされないことに注意してください。

10. 表にある他のすべての行に対して、ステップ3 (b)からステップ3 (i)までを繰り返します。

11. 「次へ」をクリックします。

4. 確認ページで、指定した詳細を確認し、詳細に問題がない場合、「エージェントのデプロイ」をクリックして、管理エージェントをクローニングします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

「エージェントのデプロイ」をクリックして、デプロイメント・セッションを送信すると、「ホスト・ステータスの追加」ページが自動的に表示され、デプロイメント・セッションの進行を監視できます。

注意:
「ホスト・ステータスの追加」ページで、ソース・エージェント・イメージのコピーに失敗しましたというエラー・メッセージが表示されている場合、OMSホームの次のログ・ファイルを参照してください。
$<OMS_HOME>/sysman/prov/agentpush/<timestampdir>/applogs/deployfwk.log

通常、このエラーは、クローニングしているソース管理エージェントでジョブ・システムが有効になっていない場合に発生します。ジョブ・システムが有効になっていることを確認してください。

7.4.1.2 ホスト・リスト・ファイルの形式

ホスト・ターゲットの追加ウィザードで、 「ファイルからロード」をクリックして、ファイルにリストされているホストを追加します。ただし、選択するファイルが次のいずれかの形式であることを確認します。

- ホスト名のみ。
例 :

host1.example.com

host2.example.com

- ホスト名にプラットフォーム名が続く。
例 :

host1.example.com linux_x64

host2.example.com aix

サポートされているプラットフォーム名は、linux_x64、linux、solaris、hpunix、hpi、linux64_zseries、aix、linux_ppc64、windows_x64、solaris_x64、win32です。

7.4.1.3 グラフィック・モードでの管理エージェントのクローニングでサポートされる追加パラメータ

表7-2は、グラフィック・モードでの管理エージェントのクローニングでサポートされる追加パラメータを示しています。

表7-2 サポートされる追加パラメータ

パラメータ

説明

INVENTORY_LOCATION

中央インベントリ(oraInventory)の絶対パスを入力します。

たとえば、INVENTORY_LOCATION=$HOME/oraInventoryなどです。

重要:

- このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- 他のOracle製品がリモート・ホストにインストールされておらず、セントラル・インベントリ・ポインタ/var/opt/oracle/oraInst.loc (SolarisおよびHP-UXプラットフォーム用)または/etc/oraInst.loc (他のUNIXプラットフォーム用)が存在しない場合のみ、このパラメータは使用できます。

- このパラメータを使用する場合は、-invPtrLocパラメータは使用しないでください。

-invPtrLoc

中央インベントリ(oraInventory)の場所を含むインベントリ・ファイルの絶対パスを入力します。

たとえば、-invPtrLoc /tmp/oraInst.locなどです。

重要:

- このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- 他のOracle製品がリモート・ホストにすでにインストールされており、セントラル・インベントリ・ポインタ/var/opt/oracle/oraInst.loc (SolarisおよびHP-UXプラットフォーム用)または/etc/oraInst.loc (他のUNIXプラットフォーム用)が存在していても、このパラメータは使用できます。

- このパラメータを使用する場合は、INVENTORY_LOCATIONパラメータを使用していないことを確認してください。

s_agentSrvcName

(Microsoft Windowsのみ)管理エージェント・サービスのカスタム名を入力します。

Microsoft Windowsのサービスとして各管理エージェントが表示され、各管理エージェントにデフォルトのサービス名が使用されます。識別するためにカスタム名を割り当てる場合、このパラメータを使用します。

たとえば、s_agentSrvcName=agentsrvc1などです。

注意: Microsoft Windowsホストにインストールされている12cリリース1 (12.1.0.2)またはリリース2 (12.1.0.3)の管理エージェントを12cリリース3 (12.1.0.4)にアップグレードし、同じホスト上に別の管理エージェントをインストールし、異なるOMSにレポートするには、必ずs_agentSrvcNameパラメータを指定してください。

EM_STAGE_DIR

一時的なプロビジョニング・アドバイザ・フレームワーク(PAF)・ステージング・ディレクトリとして作成できるカスタムの場所の絶対パスを入力します。

デフォルトでは、管理エージェントをインストールするたびに、デプロイメント・プロシージャに関連するソフトウェア・ライブラリ・エンティティをコピーするためにPAFステージング・ディレクトリが作成されます。デフォルトでは、この場所はスクラッチ・パスの場所(/tmp)です。この場所はプロビジョニングのアクティビティにのみ使用されます。エンティティはデプロイメント・プロシージャ用にコピーされ、デプロイメント・プロシージャが終了すると削除されます。

この場所をカスタムの場所でオーバーライドする場合、このオプションを渡して、カスタムの場所を入力できます。

次に例を示します。

EM_STAGE_DIR=/home/john/software/oracle/pafdir

b_startAgent=false

管理エージェントをインストールして構成した後に自動的に起動しないようにするには、このパラメータを指定します。

このパラメータを指定しないと、管理エージェントはインストールして構成した後に自動的に起動します。

b_secureAgent=false

インストールした後に管理エージェントを保護しない場合は、このパラメータを指定します。

このパラメータを指定する場合は、EM_UPLOAD_PORTパラメータを使用して、OMS HTTPポートも必ず指定してください。

たとえば、b_secureAgent=false EM_UPLOAD_PORT=4899などです。

このパラメータを指定しないと、管理エージェントはインストールした後に自動的に保護されます。

7.4.2 サイレント・モードでの管理エージェントのクローニング

管理エージェントを手動でクローニングするには、次の手順に従います。

重要:
中央エージェント(OMSホストにインストールされた管理エージェント)をソース管理エージェントとして使用しないでください。

1. 表7-3の説明に従って、必要な環境変数を設定します。

表7-3 サイレント・モードでクローニングするための環境変数の設定

AGENT_BASE_DIR

クローニングする管理エージェントのインストール・ベース・ディレクトリに設定します。

- bash端末で、次のコマンドを実行します。
export AGENT_BASE_DIR=<absolute_path_to_agent_install_base_dir>

次に例を示します。

export AGENT_BASE_DIR=/u01/app/Oracle/software/agent

- 他の端末で、次のコマンドを実行します。
setenv AGENT_BASE_DIR <absolute_path_to_agent_install_base_dir>

次に例を示します。

setenv AGENT_BASE_DIR /u01/app/Oracle/software/agent

AGENT_HOME

管理エージェントのOracleホームに設定します。

次に例を示します。

/u01/app/Oracle/software/agent/core/12.1.0.4.0

- bash端末で、次のコマンドを実行します。
export AGENT_HOME=<absolute_path_to_agent_home>

次に例を示します。

export AGENT_HOME=/u01/app/Oracle/software/agent/core/12.1.0.4.0

- 他の端末で、次のコマンドを実行します。
setenv AGENT_HOME <absolute_path_to_agent_home>

次に例を示します。

setenv AGENT_HOME /u01/app/Oracle/software/agent/core/12.1.0.4.0

T_WORK

/tmp/clone_workに設定します。

- bash端末で、次のコマンドを実行します。
export T_WORK=/tmp/clone_work

- 他の端末で、次のコマンドを実行します。
setenv T_WORK /tmp/clone_work

2. エージェント・ベース・ディレクトリに移動します。
cd $AGENT_BASE_DIR

3. 管理エージェントのOracleホームからcreate_plugin_list.plスクリプトを実行します。
$AGENT_HOME/perl/bin/perl $AGENT_HOME/sysman/install/create_plugin_list.pl -instancehome <AGENT_INSTANCE_HOME>

4. エージェント・ベース・ディレクトリにあるディレクトリおよびファイルを圧縮し、一時ディレクトリにZIPファイルを作成します(環境変数T_WORKで指定)。
zip -r $T_WORK/agentcoreimage.zip core sbin plugins plugins.txt agentimage.properties

5. 一時ディレクトリに移動します(環境変数T_WORKで指定)。
cd $T_WORK

6. agentDeploy.shを一時ディレクトリにコピーします。
cp $AGENT_HOME/sysman/install/agentDeploy.sh .

7. UNZIPユーティリティを一時ディレクトリにコピーします。
cp $AGENT_HOME/bin/unzip

8. agentimage.propertiesを一時ディレクトリにコピーします。
cp $AGENT_BASE_DIR/agentimage.properties

9. 転送されるすべての内容を含む最終的なZIPファイルを一時ディレクトリに作成します。
zip -r agent.zip $T_WORK/*

10. ファイル転送ユーティリティ(たとえば、FTPなど)を使用して、宛先ホストのインストール・ベース・ディレクトリにZIPファイルを転送します。

11. 宛先ホストの一時ディレクトリにZIPファイルの内容を解凍します(以降の手順でこの一時ディレクトリは<extracted_location>として示します)。

12. 表6-3の説明に従って、同じディレクトリにagent.rspというレスポンス・ファイルを作成します。

注意:
作成するレスポンス・ファイルには任意の名前が付けられ、必ずしもagent.rspである必要はありません。わかりやすくするため、この章ではagent.rspという名前を使用します。また、レスポンス・ファイルを作成するかわりに、デプロイメント・スクリプトの起動中に個別の引数で値を渡すことができます。ただし、レスポンス・ファイルを作成して情報を取得することをお薦めします。

13. デプロイメント・スクリプトを起動して、レスポンス・ファイルを渡します。
<extracted_location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_clone_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile>

注意:

- レスポンス・ファイルを作成するかわりに個別の引数で値を渡す場合、次のように必須引数の一部を使用して、デプロイメント・スクリプトを起動します。
<extracted_location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> OMS_HOST=<oms_hostname> EM_UPLOAD_PORT=<em_upload_port> AGENT_REGISTRATION_PASSWORD=<password>

- エージェント・ベース・ディレクトリおよびレスポンス・ファイル(またはインストール詳細の個別の必須引数)を渡す以外に、デプロイメント・スクリプトでサポートされている他のオプションも渡すことができます。詳細は、6.4.9項を参照してください。

- ソース管理エージェントがホスト・ターゲットの追加ウィザードを使用してインストールされた場合、デプロイメント・スクリプトを起動する間、b_startAgent=trueおよびb_secureAgent=trueパラメータを指定してください。

7.5 管理エージェントのクローニング後

管理エージェントのクローニング後、次の手順を実行します。

1. (グラフィック・モードのみ)「ホスト・ステータスの追加」ページのインストールを確認します。デプロイ操作のフェーズである初期化、リモートの前提条件チェックおよびエージェント・デプロイに行われた進行状況を確認します。

注意:
ホスト・ターゲットの追加ウィザードで、「エージェントのデプロイ」をクリックして、1つ以上の管理エージェントをインストールすると、ホスト・ステータスの追加ページが自動的に表示されます。
詳細を表示するか、すべてのデプロイメント・セッションの進行状況を追跡する場合、「設定」メニューから「ターゲットの追加」を選択して、「ターゲットの手動追加」をクリックします。「ターゲットの手動追加」ページで、「ホスト・ターゲットの追加」を選択し、「ホスト結果の追加」をクリックします。

特定のフェーズが失敗したか警告とともに終了した場合、エージェント・デプロイ詳細セクションの各フェーズに指定された詳細を確認し、次のうちの1つを実行します。

- 警告または失敗を無視し、必要な場合、セッションを続行します。

- チェックを正常にクリアしたリモート・ホストのみで管理エージェントのデプロイを続行することを選択し、警告または失敗のステータスを持つホストは無視できます。これを行うには、「続行」をクリックして、「失敗したホストは無視して続行」を選択します。

- 警告または失敗のステータスを持つホストを含むすべてのホストで、管理エージェントのデプロイを続行することを選択できます。これを行うには、「続行」をクリックして、「すべてのホストで続行」を選択します。

- エラーの説明を慎重に確認し、原因を理解し、Oracle推奨のアクションを実行することで、問題を解決します。

- インストール詳細が同じである管理エージェントのデプロイを再試行することを選択できます。これを行うには、「再試行」をクリックして、「同じ入力を使用して再試行」を選択します。

- インストール詳細が変更された管理エージェントのデプロイを再試行することを選択できます。これを行うには、「再試行」をクリックして、「入力を更新して再試行」を選択します。

注意:
ソース・エージェント・イメージのコピーに失敗しましたというエラー・メッセージが表示されている場合、OMSホームの次のログ・ファイルを参照してください。
$<OMS_HOME>/sysman/prov/agentpush/<timestampdir>/applogs/deployfwk.log

通常、このエラーは、クローニングしているソース管理エージェントでジョブ・システムが有効になっていない場合に発生します。ジョブ・システムが有効になっていることを確認してください。

2. 第6.5項の説明に従って、インストール後の手順を実行します。

注意:

- Oracle Management Agent 12c (12.1.0.x)が頻繁にハングする、またはSolaris 9uxおよび10uxオペレーティング・システムで応答しない場合、My Oracle SupportのドキュメントID 1427773.1を参照してください。

- 既存の管理エージェントを新しいOracle Management Service (OMS)に再指定できます。この方法の詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の付録「Oracle Management Agentの別のOracle Management Serviceへのリダイレクト」を参照してください。
既存の管理エージェントを新しいOMSに対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

8 共有エージェントのインストール

この章では、NFSマウント済のドライブにインストールされている既存のOracle Management Agent (管理エージェント)の中央の共有Oracleホームの場所を利用して共有エージェントをインストールする方法について説明します。

- 共有エージェントのインストールの概要

- 共有エージェントのインストールを開始する前に

- 共有エージェントをインストールするための前提条件

- 共有エージェントのインストール

- 共有エージェントのインストール後

8.1 共有エージェントのインストールの概要

共有エージェントは、既存の管理エージェントのバイナリを使用して、リモート・ホストにインストールされる管理エージェントです。ここでは、ソフトウェア・バイナリを共有する管理エージェントはマスター・エージェントと呼ばれ、リモート・ホスト上でインスタンス・ディレクトリとともに構成される管理エージェントは共有エージェントまたはNFSエージェントと呼ばれます。

この機能を使用すると、ごく限られたリソースを利用して複数の管理エージェントを容易にインストールでき、ライフサイクル操作を簡単に行うことができます。たとえば、マスター・エージェントにパッチを適用すると、そのすべての共有エージェントが更新されます。

この操作は、管理エージェントがすでにインストールされているマウント済ドライブを共有するホストに追加の管理エージェントをインストールすることで活用できます。この操作では、マウント済ドライブにある共有のOracleホームのソフトウェア・バイナリを使用し、リモート・ホストを管理エージェントが管理するように構成します。そのため、NFSの可視性を利用してリモート・ホストのハード・ディスク領域を節約できます。

グラフィック・モードまたはサイレント・モードで共有エージェントをインストールできます。グラフィック・モードで、Enterprise Manager Cloud Controlコンソールからアクセスできるホスト・ターゲットの追加ウィザードを使用します。サイレント・モードで、AgentNFS.plスクリプトを使用します。

ウィザードおよびスクリプトでは、共有Oracleホームからソフトウェア・バイナリを使用し、各宛先ホスト上にemd.properties、targets.xml、ログ・ファイルなどの構成ファイルを格納するためのインスタンス・ディレクトリを構成します。

注意:

- 共有エージェントは、Exalogicシステムにインストールできます。

- Microsoft Windows上で稼働しているホストへの共有エージェントのインストールはサポートされていません。

- ホスト・ターゲットの追加ウィザードとは異なり、AgentNFS.plスクリプトは宛先ホストからのみ実行する必要があり、任意の時点で1つの管理エージェントのみインストールできます。このため、少数の管理エージェントのみをインストールする場合は、AgentNFS.plスクリプトを使用してください。

8.2 共有エージェントのインストールを開始する前に

共有エージェントをインストールする前に、次の点に留意してください。

- 共有エージェントをインストールする場合、構成ファイルを格納するために宛先ホストのインスタンス・ディレクトリを構成するだけで、実際に管理エージェントをインストールしません。ただし、ホストにインストールされた共有エージェントは、管理エージェントとまったく同じように動作し、管理エージェントのすべての機能および性能を備えています。

- 宛先ホストおよびインストールされた共有エージェントのみ、Enterprise Managerシステムで自動的に検出および監視されます。宛先ホストで実行されているターゲットは、Enterprise Managerシステムに自動的に検出および追加されません。

- (マスター・エージェントを実行している)ソース・ホストおよび宛先ホストは、同じオペレーティング・システムで実行する必要があります。

- マスター・エージェントおよび共有エージェントは、同じユーザー・アカウントでインストールする必要があります。

- (グラフィック・モードのみ)ホスト・ターゲットの追加ウィザードでは、SSHを使用して、管理エージェントをインストールするリモート・ホストとOracle Management Service (OMS)間の接続を確立します。

- (グラフィック・モードのみ)管理エージェントのデプロイ用としてサポートされているのは、OpenSSHによって提供されているSSH1 (SSHバージョン1)およびSSH2 (SSHバージョン2)プロトコルのみです。

- (グラフィック・モードのみ)ホスト・ターゲットの追加ウィザードは、管理者がこの操作用に特定の名前で登録した一連の資格証明をユーザーが使用できる名前付き資格証明をサポートしています。オペレータは、管理者によって保存および格納される名前付き資格証明のみ選択でき、関連付けられている実際のユーザー名およびパスワードを確認しないため、パスワードのセキュリティの追加レイヤーを確保できます。
選択する名前付き資格証明にインストールを実行する権限がない場合、別のユーザー(ロックされたユーザー・アカウント)として実行するため、名前付き資格証明を設定できます。この場合、ウィザードはユーザーが選択する名前付き資格証明を使用してホストにログインしますが、ユーザーが設定するロックされたユーザー・アカウントを使用してインストールします。

たとえば、User_A (リモート・ログイン・アクセスのできるユーザー・アカウント)という名前付き資格証明を作成し、必要な権限を持つUser_X (no direct loginが設定される管理エージェント・インストール・ユーザー・アカウント)として実行するように設定できます。この場合、ウィザードはUser_Aとしてホストにログインしますが、名前付き資格証明で指定されている権限委任設定(sudoまたはPowerBroker)を使用し、User_Xとしてインストールします。

- (グラフィック・モードのみ)名前付き資格証明では、SSH公開鍵認証およびパスワードベースの認証がサポートされています。そのため、パスワードを公開することなく、既存のSSH公開鍵認証を使用できます。
名前付き資格証明にSSH公開鍵認証を設定する手順は次のとおりです。

注意:
すでに名前付き資格証明にSSH公開鍵認証を設定しており、SSH鍵がすでに作成されている場合には、次の手順3で説明するようにSSH鍵をEnterprise Managerにアップロードします。

1. OMSホームの次の場所に移動します。
$<OMS_HOME>/oui/prov/resources/scripts

次に例を示します。

/home/software/em/middleware/oms/oui/prov/resources/scripts

2. OMSホストがOracle Solarisで稼働する場合は、sshUserSetup.shスクリプトを編集し、次のように変更します。
"SunOS") SSH="/usr/local/bin/ssh" SSH_KEYGEN="/usr/local/bin/ssh-keygen"

変更後

"SunOS") SSH="/usr/bin/ssh" SSH_KEYGEN="/usr/bin/ssh-keygen"

3. OMSホストがUNIXベースのオペレーティング・システムで稼働している場合、sshUserSetup.shスクリプトをOMSホストでOMSユーザーとして実行し、管理エージェントのインストール・ユーザー名とターゲット・ホストの完全修飾名を渡します。
sshUserSetup.sh -setup -user <agent_install_user_name> -hosts <target_hosts>

次のSSH鍵が作成されます。

$HOME/.ssh/id_rsa
$HOME/.ssh/id_rsa_pub

ここで、$HOMEはOMSインストール・ユーザーのホーム・ディレクトリです。

OMSホストがMicrosoft Windowsで稼働している場合、OMSホストにCygwinをインストールし(『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載)、次のスクリプトをOMSホストでOMSユーザーとして実行し、管理エージェントのインストール・ユーザー名とターゲット・ホストの完全修飾名を渡します。

sshUserSetupNT.sh -setup -user <agent_install_user_name> -hosts <target_hosts>

4. SSH鍵をEnterprise Managerにアップロードします。
「設定」メニューから、「セキュリティ」、「名前付き資格証明」の順に選択します。「作成」をクリックします。「資格証明名」には資格証明の名前を指定し、「資格証明のタイプ」には「SSHキー資格証明」を選択し、「有効範囲」には「グローバル」を選択します。「グローバル」オプションを選択しないと、「ホスト・ターゲットの追加」ウィザードを使用して管理エージェントをインストールするためにSSH名前付き資格証明を使用できません。

手順3で作成された秘密SSH鍵のうち1つをアップロードするには、「資格証明プロパティ」セクションで「秘密鍵のアップロード」フィールドの値として秘密SSH鍵の場所を指定します。「保存」をクリックします。

手順3で作成された公開SSH鍵のうち1つをアップロードするには、「資格証明プロパティ」セクションで「公開鍵のアップロード」フィールドの値として公開SSH鍵の場所を指定します。「保存」をクリックします。

図 8-1はSSH鍵をEnterprise Managerにアップロードする方法を示しています。

図8-1 SSH鍵のEnterprise Managerへのアップロード

名前付き資格証明に対してSSH公開鍵認証をすでに設定している場合、ホスト・ターゲットの追加ウィザードを使用した管理エージェントのインストールの間に名前付き資格証明を使用できます。

- デフォルトでは、次のタイプのプラグインが共有エージェントで構成されます。

- 管理エージェント・ソフトウェアがデプロイされているOMSで構成されたすべての検出プラグイン

- Oracleホームの検出プラグイン

- Oracleホームの監視プラグイン

- マスター・エージェントにデプロイされたすべての追加プラグイン

- カーネル・パッチまたはパッチ・バンドルを適用してSolarisの下位リリースをアップグレードすることと、実際のSolaris 5.10 Update 9イメージをインストールすることは同じではありません。Oracle Management Agent 12cリリース4 (12.1.0.4)はSolaris 5.10 Update 9の最小更新版で構築され、テストおよび動作認証されているため、Oracle Management Agentは、パッチを使用してアップグレードした他のリリースではなくSolaris 5.10 Update 9にインストールすることをお薦めします。

8.3 共有エージェントをインストールするための前提条件

共有エージェントをインストールする前に、次の前提条件を満たしていることを確認してください。

表8-1 共有エージェントをインストールするための前提条件

要件

説明

ハードウェアの要件

ハード・ディスク領域および物理メモリー要件を満たしていることを確認します。詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章を参照してください。

宛先ホストのディスク領域要件

マスター・エージェント・ホストに1GB以上の空きハード・ディスク領域、共有エージェント・ホストに2MB以上の空きハード・ディスク領域があることを確認します。

オペレーティング・システム要件

管理エージェントは、「My Oracle Support」のEnterprise Managerの動作保証マトリックスに記載された動作保証済のオペレーティング・システムにのみインストールしてください。

Microsoft Windowsプラットフォーム上で実行するマスター・エージェントを使用して共有エージェントをインストールすることはできません。Microsoft Windowsプラットフォームでは、共有エージェントはサポートされていません。

Enterprise Managerの動作保証マトリックスにアクセスするには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明している手順を実行します。

今後のサポート対象プラットフォームの詳細は、My Oracle Supportのノート793512.1を参照してください。

注意: Oracle Solaris 10を使用する場合、アップデート9以上がインストールされていることを確認します。インストールされているかどうかを確認するには、次のコマンドを実行します。

cat /etc/release

次のような出力が表示されます。ここで、s10s_u6は、アップデート6 (インストールがサポートされていない更新レベル)がインストールされていることを示します。

Solaris 10 10/08 s10s_u6wos_07b SPARC

ファイルシステム要件

宛先ホストにマウントされたファイルシステムでバッファに入れられた書込みが許可されないことを確認します。

ファイル記述子要件

- ユーザー・プロセスの上限が13312以上に設定されていることを確認します。
現在の設定値を確認するには、次のコマンドを実行します。

ulimit -u

現在の値が13312以上でない場合は、13312以上に設定するようにシステム管理者に連絡してください。

- ファイル記述子のソフト・リミットを最小の4096に、ハード・リミットを16384以下に設定していることを確認します。
現在の設定値を確認するには、次のコマンドを実行します。

ソフト・リミットの場合:

/bin/sh -c "ulimit -n"

ハード・リミットの場合:

/bin/sh -c "ulimit -Hn"

現在の値が4096未満の場合、rootユーザーとして、次のエントリで/etc/security/limits.confファイルを更新してください。

<UID> soft nofile 4096

<UID> hard nofile 16384

パッケージ要件

すべてのオペレーティング・システム固有のパッケージをインストールしていることを確認します。詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのパッケージ要件に関する章を参照してください。

ユーザーおよびオペレーティング・システム・グループの要件

管理エージェントのインストール先のホストに適切なユーザーおよびオペレーティング・システム・グループが作成されていることを確認します。

詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのオペレーティング・システム・グループおよびユーザーの作成に関する章を参照してください。

注意: OMSインストールのオペレーティング・システム・ユーザー・アカウントを使用した管理エージェントのインストールに対するポリシーが企業にある場合は、異なるオペレーティング・システム・ユーザー・アカウントを使用して管理エージェントをインストールできます。ただし、使用するユーザー・アカウントおよびOMSインストールのユーザー・アカウントが同じプライマリ・グループに属していることを確認します。

ソフトウェア可用性の要件

マウント済の共有場所にマスター・エージェントとしてすでにOracle Management Agent 12cがインストールされていることを確認します。

管理エージェントのインストール方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

ソフトウェアのマウント要件

1つ以上の共有エージェント・ホストに、マウント位置への読取り/書込み権限があることを確認します。読取り/書込み権限のある共有エージェント・ホストに管理エージェント・ソフトウェアをマウントするには、次のコマンドを実行します。

mount -t nfs -o rw <master_agent_host_name>:<agent_base_dir_of_master_agent> <agent_base_dir_of_shared_agent>

たとえば、次のようなコマンドを実行します。

mount -t nfs -o rw abc.oracle.com:/scratch/agent /scratch/agent

読取り専用権限のある共有エージェント・ホストに管理エージェント・ソフトウェアをマウントするには、次のコマンドを実行します。

mount -t nfs -o ro <master_agent_host_name>:<agent_base_dir_of_master_agent> <agent_base_dir_of_shared_agent>

たとえば、次のようなコマンドを実行します。

mount -t nfs -o ro abc.oracle.com:/scratch/agent /scratch/agent

注意: 管理エージェント・ソフトウェアを共有エージェント・ホストにマウントする前に、ディレクトリがマスター・エージェント・ホスト上のエージェント・ベース・ディレクトリと同じパスを持つように、共有エージェント・ホストにエージェント・ベース・ディレクトリを作成していることを確認してください。

/etc/hostsファイル要件

ホストの/etc/hostsファイルでIPアドレス、完全修飾名および短縮名が次の形式で使用されていることを確認します。

172.16.0.0 example.com mypc

宛先ホストのアクセス権要件

宛先ホストにOMSを実行しているホストからアクセスできることを確認します。

宛先ホストとOMSが実行されているホストが別のネットワーク・ドメインに属している場合、宛先ホストの/etc/hostsファイルを更新して、そのホストのIPアドレス、完全修飾名および短縮名を含む1行を追加していることを確認します。

たとえば、完全修飾ホスト名がexample.comで、短縮名がmypcの場合は、/etc/hostsファイル内に次の行を追加します。

172.16.0.0 example.com mypc

宛先ホストの資格証明の要件

(グラフィック・モードのみ)

同じオペレーティング・システムを実行しているすべての宛先ホストに同じ資格証明セットが使用されていることを確認します。たとえば、Linuxオペレーティング・システムを実行しているすべての宛先ホストに同じ資格証明セットを使用する必要があります。

ウィザードは、同じユーザー・アカウントを使用して、管理エージェントをインストールします。同じオペレーティング・システムを実行しているホストで異なる資格証明を使用している場合、2つの異なるデプロイメント・セッションを使用します。

接続先ホストのタイムゾーン要件

(グラフィック・モードのみ)

接続先ホストのタイムゾーンが正しく設定されていることを確認します。接続先ホストのタイムゾーンを確認するには、OMSホストにログインし、次のコマンドを実行します。

ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

タイムゾーンが正しく表示されない場合、接続先ホストにログインし、次の手順を実行します。

1. 次のコマンドを実行して、接続先ホストにタイムゾーンを設定します。

- Kornシェルの場合:
TZ=<value>

export TZ

- BourneシェルまたはBashシェルの場合:
export TZ=<value>

- Cシェルの場合:
setenv TZ <value>

たとえば、Bashシェルで、タイムゾーンをAmerica/New_Yorkに設定するには、次のコマンドを実行します。

export TZ='America/New_York'

使用できるタイムゾーンの一覧を確認するには、中央エージェント(OMSホストにインストールされた管理エージェント)の<AGENT_HOME>/sysman/adminディレクトリにあるsupportedtzs.lstファイルにアクセスします。

2. SSHデーモンを再起動します。
接続先ホストがUNIXベースのオペレーティング・システムで実行されている場合、次のコマンドを実行します。

sudo /etc/init.d/sshd restart

接続先ホストがMicrosoft Windowsのオペレーティング・システムで実行されている場合、次のコマンドを実行します。

cygrunsrv -E sshd

cygrunsrv -S sshd

3. OMSホストにログインして次のコマンドを実行し、SSHサーバーがTZ環境変数にアクセスできるかどうかを確認します。
ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

注意: 管理エージェントのインストール中に間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、管理エージェントのインストール後、接続先ホストで正しいタイムゾーンを設定する必要があります。インストール後のタイムゾーンの設定の詳細は、第8.5項を参照してください。

タイムゾーン要件

(サイレント・モードのみ)

ホストのタイムゾーンが正しく設定されていることを確認します。ホストのタイムゾーンを確認するには、次のコマンドを実行します。

echo $TZ

表示されたタイムゾーンが正しくない場合は、agentDeploy.shまたはagentDeploy.batスクリプトを実行する前に、次のコマンドを実行して正しいタイムゾーンを設定します。

- Kornシェルの場合:
TZ=<value>

export TZ

- BourneシェルまたはBashシェルの場合:
export TZ=<value>

- Cシェルの場合:
setenv TZ <value>

たとえば、Bashシェルで、タイムゾーンをAmerica/New_Yorkに設定するには、次のコマンドを実行します。

export TZ='America/New_York'

使用できるタイムゾーンの一覧を確認するには、中央エージェント(OMSホストにインストールされた管理エージェント)の<AGENT_HOME>/sysman/adminディレクトリにあるsupportedtzs.lstファイルにアクセスします。

注意: 管理エージェントのインストール中に間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、管理エージェントのインストール後、ホストで正しいタイムゾーンを設定する必要があります。インストール後のタイムゾーンの設定の詳細は、第8.5項を参照してください。

sudo/pbrun/sesu/su SSH要件

(グラフィック・モードのみ)

使用している権限委任ツールで、SSH経由のリモート・コマンドの実行に擬似端末が必要な場合は、必ず$<OMS_HOME>/sysman/prov/agentpush/agentpush.propertiesファイルのoracle.sysman.prov.agentpush.enablePtyプロパティをtrueに設定してください。pbrun、sesu、suなどの権限委任ツールの多くは、デフォルトで、リモート・コマンドの実行に擬似端末を必要とします。

注意: 権限委任ツールにsudoを使用している場合、oracle.sysman.prov.agentpush.enablePtyプロパティをtrueに設定しないときは、次のいずれかを実行します。

- /etc/sudoersファイルにDefaults visiblepwを含めるか、「インストールの詳細」ページの「権限委任設定」で、sudoコマンドを-Sオプション付きで入力します。
「インストールの詳細」ページへアクセスする方法の詳細は、第8.4.1項を参照してください。

- /etc/sudoersファイル内のDefaults requirettyをコメント化します。

sudo/pbrun/sesu/suの要件(Rootユーザーの場合)

(グラフィック・モードのみ)

- インストール・ユーザーにidコマンドおよびagentdeployroot.shスクリプトをrootとして実行する権限があることを確認します。権限委任ツールの構成ファイルで権限を付与します。
たとえば、権限委任ツールにsudoを使用している場合は、/etc/sudoersファイルに次の内容を追加して、必要な権限を付与します。

<install_user> ALL=(root) /usr/bin/id, <agent_home>/*/agentdeployroot.sh

たとえば、oracle ALL=(root) /usr/bin/id, /u01/app/oracle/admin/shared/agent_home/*/agentdeployroot.shなどです。

ここで、oracleはインストールするユーザーで、/u01/app/oracle/admin/shared/agent_homeは共有エージェントのホームです。

- 管理エージェントのインストールには、/etc/sudoersファイルに次のエントリは不要です。ただし、このエントリは、Enterprise Managerでプロビジョニングとパッチ適用を実行するために必要です。したがって、管理エージェントをインストールする前にこのエントリを削除する場合、管理エージェントのインストール後に、このエントリを戻してください。
Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、リリース3 (12.1.0.3)、リリース4 (12.1.0.4)の場合:

(root) /<AGENT_BASE_DIRECTORY>/sbin/nmosudo

Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1) [バンドル・パッチ1]の場合:

(root) /<AGENT_INSTANCE_DIRECTORY>/bin/nmosudo

sudo/pbrun/sesu/suの要件(ロックされたアカウント・ユーザーの場合)

(グラフィック・モードのみ)

インストール・ユーザーに/bin/shをロックされたアカウント・ユーザーとして実行する権限があることを確認します。権限委任ツールの構成ファイルで権限を付与します。

たとえば、権限委任ツールにsudoを使用している場合は、/etc/sudoersファイルに次の内容を追加して、必要な権限を付与します。

login_user1 ALL=(oracle) /bin/sh

ここで、login_user1はSSHログイン・ユーザー、oracleはロックされたアカウント・ユーザーおよびインストール・ユーザーです。

ロックされたアカウント・ユーザーとして/bin/shを起動する権限をインストール・ユーザーに付与したくない場合は、oracle.sysman.prov.agentpush.pdpShellOutEnabledプロパティをfalseに設定し、インストール・ユーザーにはロックされたアカウント・ユーザーとしてid、chmod、cp、mkdir、rm、tar、emctl、perl、runInstallerおよびunzipを起動する権限があることを確認します。権限委任ツールの構成ファイルで権限を付与します。

たとえば、権限委任ツールにsudoを使用している場合は、/etc/sudoersファイルに次の内容を追加して、必要な権限を付与します。

login_user1 ALL=(oracle) /usr/bin/id, /bin/chmod, /bin/cp, /bin/mkdir, /bin/rm, /bin/tar, /home/oracle/agentinst/bin/emctl, /home/oracle/agentibd/core/12.1.0.4.0/perl/bin/perl, /home/oracle/agentibd/core/12.1.0.4.0/oui/bin/runInstaller, /home/oracle/agentibd/core/12.1.0.4.0/bin/unzip

ここで、login_user1はSSHログイン・ユーザー、oracleはロックされたアカウントおよびインストール・ユーザー、/home/oracle/agentinstは共有エージェントのエージェント・インスタンス・ディレクトリ、/home/oracle/agentibdはエージェント・ベース・ディレクトリです。

一時ディレクトリの領域要件

実行可能ファイルがコピーされる一時ディレクトリに、400MBの領域が割り当てられていることを確認します。

デフォルトでは、環境変数TMPまたはTEMPに設定されている一時ディレクトリの場所が適用されます。両方が設定されている場合、TEMPが適用されます。いずれも設定されていない場合、UNIXホストは/tmp、Microsoft Windowsホストはc:\Tempとしてデフォルト値が適用されます。

インスタンス・ディレクトリの要件

指定する共有エージェントのインスタンス・ディレクトリ(共有エージェント構成ファイルを保存するディレクトリ)は、空でありインストール・ユーザーに対する書込み権限があることを確認します。また、親ディレクトリにもインストール・ユーザーに対する書込み権限があることを確認します。

共有Oracleホームの要件

マスター・エージェント・ホームが、共有エージェントをインストールする宛先ホストからアクセス可能であることを確認します。setuidが有効な状態でマスター・エージェント・ホームがマウントされていることを確認します。

パス検証の要件

(グラフィック・モードのみ)

すべてのコマンドの場所へのパスを検証します。詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのコマンド場所の検証に関する付録を参照してください。

CLASSPATH環境変数の要件

CLASSPATH環境変数に割り当てられた値に空白文字が含まれている場合は、必ずその設定を解除してください。インストールの完了後、常にこの環境変数を元の値にリセットできます。

デフォルトのSSHポートの要件

(グラフィック・モードのみ)

SSHデーモンがすべての宛先ホストのデフォルト・ポート(22)で実行されていることを確認します。UNIXホストのSSHポートを確認するには、次のコマンドを実行します。

netstat -anp | grep -i sshd

たとえば、コマンドからの出力は次のようになります。

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3188/sshd

この出力は、SSHデーモンがポート22で実行中であることを示します。

また、UNIXホストでは、次のコマンドを実行してSSHポートを検証できます。

cat /etc/ssh/sshd_config

Microsoft Windowsでは、SSHポートの値はC:\cygwin\etc\sshd_configファイルにあります。

デフォルト以外(22以外)のSSHポートを使用している場合は、次のファイル内のSSH_PORTプロパティを更新します。

$<OMS_HOME>/oui/prov/resources/Paths.properties

ポート要件

第2.1.10.1項で説明されているデフォルトのポートを使用できることを確認します。

インストール・ユーザーの要件

- マスター・エージェントおよび共有エージェントは、同じユーザー・アカウントでインストールする必要があります。

- 中央インベントリ所有者と管理エージェントをインストールするユーザーが異なる場合、両者が同じグループに属していることを確認します。

- インベントリ所有者と所有者が属するグループが、インベントリ・ディレクトリに対する読取り権限と書込み権限を持つことを確認します。
たとえば、インベントリ所有者がabcで、管理エージェントをインストールするユーザーがxyzの場合、abcとxyzが同じグループに属し、双方が中央インベントリに対する読取りおよび書込みアクセスを持っていることを確認してください。

中央インベントリ(oraInventory)の要件

- すべての宛先ホストにおいて、中央インベントリに100MBの領域が割り当てられていることを確認します。

- 共有エージェントは、<MASTER_AGENT_BASE DIR>/core/12.1.0.4.0/ディレクトリ内にあるoraInst.locファイルに記述されているインベントリの場所を使用します。共有エージェント・ユーザーに、このディレクトリへの読取り/書込みアクセス権があることを確認します。

インストール前/インストール後スクリプトの要件

(グラフィック・モードのみ)

インストールとともに実行するインストール前スクリプトとインストール後スクリプトがOMSホスト、宛先ホストまたは宛先ホストにアクセスできる共有場所で使用可能であることを確認します。

ブラウザ要件

(グラフィック・モードのみ)

- 「My Oracle Support」のEnterprise Managerの動作保証マトリックスに記載されている動作保証済のブラウザを必ず使用してください。
Enterprise Managerの動作保証マトリックスにアクセスするには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明している手順を実行します。

- Microsoft Internet Explorer 8または9を使用する場合、次の手順を実行します。

- 互換表示モードを無効にします。これを行うには、Microsoft Internet Explorerの「ツール」メニューの「互換表示」をクリックして、有効な場合は無効にします。また、「互換表示設定」をクリックして、Enterprise Manager Cloud ControlコンソールURLを登録解除します。

- XMLHTTPを有効にします。これを行うには、「ツール」メニューから「インターネット オプション」をクリックします。「詳細設定」タブをクリックして、「セキュリティ」見出しの「ネイティブ XMLHTTP サポートを有効にする」を選択して有効にします。

8.4 共有エージェントのインストール

この項では、「ホスト・ターゲットの追加」ウィザードおよびサイレント・モードを使用して共有エージェントをインストールする方法について説明します。この項の内容は次のとおりです。

- 「ホスト・ターゲットの追加」ウィザードを使用した共有エージェントのインストール

- 「ホスト・ターゲットの追加」ウィザードを使用した共有エージェントのインストールでサポートされる追加パラメータ

- サイレント・モードでの共有エージェントのインストール

- サイレント・モードで共有エージェントをインストールするためのレスポンス・ファイル・パラメータ

重要:
OMSホストがMicrosoft Windowsで稼働していて、OMSソフトウェアがC:\以外のドライブにインストールされている場合は、$OMS_HOME\oui\prov\resources\ssPaths_msplats.propertiesのSCRATCH_PATH変数を更新します。
たとえば、OMSソフトウェアがD:\にインストールされている場合は、SCRATCH_PATH変数をD:\tmpadaに更新してください。

8.4.1 「ホスト・ターゲットの追加」ウィザードを使用した共有エージェントのインストール

「ホスト・ターゲットの追加」ウィザードを使用してグラフィック・モードで共有エージェントをインストールするには、次の手順に従います。

1. Cloud Controlで、次のいずれかの操作を行います。

- 「設定」メニューから、「ターゲットの追加」を選択し、「自動検出結果」をクリックします。「自動検出の結果」ページで、Enterprise Manager Cloud Controlで監視するホストを選択し、「昇格」をクリックします。

- 「設定」メニューから、「ターゲットの追加」を選択し、「ターゲットの手動追加」をクリックします。「ターゲットの手動追加」ページで、「ホスト・ターゲットの追加」を選択し、「ホストの追加」をクリックします。

2. ホストとプラットフォーム・ページで、次を実行します。

1. このセッションに割り当てられたデフォルトの名前のままにするか、選択した一意の名前を入力します。入力するカスタム名は直観的な名前にすることができ、必ずしもデフォルトの名前と同じフォーマットにする必要はありません。例: add_host_operation_1
一意のデプロイメント・アクティビティ名によって、このデプロイメント・セッションで指定されたインストール詳細を保存し、新規セッションですべての詳細を入力しなおすことなく、将来再利用できます。

2. 「追加」をクリックし、管理エージェントをインストールするホストの完全修飾名およびプラットフォームを選択します。

注意:

- ホストの完全修飾ドメイン名を入力することをお薦めします。監視のため、Enterprise Manager Cloud Controlは、ここで入力した正確な名前でホストおよび管理エージェントを追加します。

- 行当たり入力するホスト名は1つのみにする必要があります。複数のホスト名をカンマで区切って入力することはサポートされていません。

- 入力するホスト名にアンダースコアがないことを確認する必要があります。

または、「ファイルからロード」をクリックしてファイルに格納されたホスト名を追加するか、「検出されたホストから追加」をクリックしてEnterprise Managerで検出されたホストのリストからホスト名を追加できます。ホスト名エントリをホスト・ファイルに表示する方法の詳細は、第7.4.1.2項を参照してください。

注意:
「検出されたホストの追加」をクリックして検出されたホストのリストからホストを追加すると、ホストのプラットフォームが自動的に検出されて表示されます。自動検出で受信したヒントおよびOMSホストのプラットフォームを含む要素の組合せを使用して、プラットフォーム名が検出されます。このデフォルトのプラットフォーム名は提案なので、次の手順に進む前にプラットフォームの詳細を確認することを強くお薦めします。

ソース・ホストおよび宛先ホストが同じプラットフォームで稼働している場合のみ共有エージェントをインストールできるため、表の最初の行の最初のホストのプラットフォームを設定し、「プラットフォーム」リストから、「すべてのホストで同一」を選択します。これにより、最初のホストに選択したプラットフォーム名が表の残りのホストにも設定されます。

注意:
OMSホスト・プラットフォームとは別のプラットフォーム上で稼働しているホストに管理エージェントをインストールする場合、そのプラットフォーム用の管理エージェント・ソフトウェアがOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)で入手可能なことを確認してください。必要なプラットフォーム用の管理エージェント・ソフトウェアがソフトウェア・ライブラリから入手できない場合は、自己更新コンソールを使用してソフトウェアを取得および適用してください。
自己更新コンソールにアクセスするには、「設定」メニューから、「拡張性」を選択し、「自己更新」を選択します。最新の管理エージェントのソフトウェアを入手するには、「エージェント・ソフトウェア」をクリックし、必要なソフトウェアを選択してから「ダウンロード」をクリックします。

自己更新コンソールを使用してプラットフォーム用の管理エージェント・ソフトウェアを取得および適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

3. 「次へ」をクリックします。

3. 「インストールの詳細」ページで、次のようにします。

1. 「デプロイメント・タイプ」セクションで、「共有エージェントへのホストの追加」を選択します。「ターゲットの選択」で、懐中電灯アイコンをクリックして、共有およびマウントする管理エージェントを選択します。この場所は、すべてのリモート・ホストで認識できる必要があります。
図8-2は、この手順を示しています。

図8-2 共有エージェントのインストール

2. 表から、共通のプラットフォーム名でグループ化されたホストを示す最初の行を選択します。

3. 「インストールの詳細」セクションで、ステップ3 (b)で選択したホストに共通するインストールの詳細を指定します。Oracleホームの場合、共有管理エージェント・ホームの場所を検証または入力します。管理エージェント・ホームが共有の場所にあり、すべての宛先ホストからアクセスできることを確認してください。

4. 「インスタンス・ディレクトリ」に、すべての管理エージェント関連の構成ファイルを格納できる、共有エージェント・ホスト上のディレクトリへの絶対パスを入力します。このディレクトリには書込み権限があることを確認してください。
たとえば、/usr/home/software/oracle/agentHome/agent_instなどです。

入力したパスが存在しない場合は、指定されたパスにディレクトリが作成され、管理エージェントに関連するすべての構成ファイルがその場所にコピーされます。

5. 「名前付き資格証明」リストから、資格証明がOMSとリモート・ホスト間のSSH接続を設定し、各リモート・ホストに管理エージェントをインストールするのに使用できる適切なプロファイルを選択します。

注意:

- 資格証明プロファイルがない場合、または資格証明プロファイルはあるが「名前付き資格証明」リストで見つからない場合、このリストに対するプラス・アイコンをクリックします。名前付き資格証明の新規作成ウィンドウに、資格証明を入力し、適切なプロファイル名で格納して、管理エージェントのインストールに選択および使用できるようにします。また、作成している名前付き資格証明から、インストールの実行権限を持つ別のユーザーに切り替えるには、実行権限を設定します。

- このリストに対するプラス・アイコンが無効な場合、資格証明があるプロファイルを作成する権限がありません。この場合、管理者に連絡して、新規プロファイルの作成権限を付与してもらうようリクエストするか、プロファイルを作成してもらい、「名前付き資格証明」リストにプロファイルを表示するアクセス権を付与してもらうようリクエストします。

- OMSとリモート・ホスト間のSSH公開キー認証を手動で設定している場合、ユーザー・アカウントのパスワードがない可能性があります。この場合、仮パスワードを使用して、名前付き資格証明を作成します。パスワード・フィールドは空のままにしないでください。

6. 「権限委任設定」で、rootスクリプトの実行に使用する権限委任設定を検証します。デフォルトでは、Enterprise Manager Cloud Controlで構成されている権限委任設定に設定されます。
たとえば、「権限委任設定」フィールドには、次のいずれかを指定できます。

/usr/bin/sudo -u %RUNAS% %COMMAND%
/usr/bin/sudo -u -S %RUNAS% %COMMAND% (if a pseudo terminal is required for remote command execution via SSH)
/usr/bin/sesu - %RUNAS% -c "%COMMAND%"
/usr/bin/pbrun %PROFILE% -u %RUNAS% %COMMAND%
/usr/bin/su - %RUNAS% -c "%COMMAND%"

「権限委任設定」フィールドを空白のままにしておくと、ウィザードではrootスクリプトが実行されないため、インストール後に手動で実行する必要があります。手動による実行の詳細は、第8.5項を参照してください。

この設定は、選択した名前付き証明の「別名実行」属性で設定されたユーザーとしてのインストールの実行にも使用されます(この名前付き資格証明の作成時にユーザーを設定している場合)。

注意:
権限委任設定での%RUNAS%は、ルート・スクリプトを実行するルート・ユーザー、および名前付き資格証明の「別名実行」属性で設定された、インストールを実行するユーザーとしての権限を持ちます。

7. 「ポート」で、管理エージェントの通信用に割り当てられたデフォルトのポート(3872)のままにするか、選択したポートを入力します。
入力するカスタム・ポートはビジー状態ではない必要があります。不明な場合、空白にしておくことができます。Enterprise Manager Cloud Controlによって、1830 - 1849の範囲から最初の使用可能な空きポートが自動的に割り当てられます。

8. (オプション)「オプションの詳細」セクションで、実行するインストール前スクリプトおよびインストール後スクリプトを使用できるアクセス可能な場所への絶対パスを入力します。インストール前スクリプトまたはインストール後スクリプトを1つのみ指定できることに注意してください。
スクリプトをrootとして実行するには、「Rootとして実行」を選択します。管理エージェントをインストールするホスト上ではなく、OMSが実行されているホスト上にスクリプトがある場合、「OMSのスクリプト」を選択します。この場合、スクリプトはOMSホストから接続先ホストにコピーされてから、接続先ホストで実行されます。

9. (オプション)「追加パラメータ」で、インストール時に渡す追加パラメータの空白区切りのリストを入力します。サポートされている追加パラメータの完全なリストは、表8-2を参照してください。
たとえば、インベントリ・ポインタの場所ファイルを指定する場合、-invPtrLocの後ろにファイルの場所への絶対パスを入力します。ただし、このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

10. 表にある他のすべての行に対して、ステップ3 (b)からステップ3 (h)までを繰り返します。

11. 「次へ」をクリックします。

4. 確認ページで、指定した詳細を確認し、詳細に問題がない場合、「エージェントのデプロイ」をクリックして、管理エージェントをインストールします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

「エージェントのデプロイ」をクリックして、デプロイメント・セッションを送信すると、「ホスト・ステータスの追加」ページが自動的に表示され、デプロイメント・セッションの進行を監視できます。

注意:
共有エージェントをインストールした後に宛先ホストを再起動しても共有エージェントが自動的に起動しない場合は、元の権限でマウントをリストアして共有エージェントを手動で起動します。

8.4.2 「ホスト・ターゲットの追加」ウィザードを使用した共有エージェントのインストールでサポートされる追加パラメータ

表8-2は、グラフィック・モードでの共有エージェントのインストールでサポートされる追加パラメータを示しています。

表8-2 サポートされている追加パラメータ

パラメータ

説明

EM_STAGE_DIR

一時的なプロビジョニング・アドバイザ・フレームワーク(PAF)・ステージング・ディレクトリとして作成できるカスタムの場所の絶対パスを入力します。

デフォルトでは、管理エージェントをインストールするたびに、デプロイメント・プロシージャに関連するソフトウェア・ライブラリ・エンティティをコピーするためにPAFステージング・ディレクトリが作成されます。デフォルトでは、この場所はスクラッチ・パスの場所(/tmp)です。この場所はプロビジョニングのアクティビティにのみ使用されます。エンティティはデプロイメント・プロシージャ用にコピーされ、デプロイメント・プロシージャが終了すると削除されます。

この場所をカスタムの場所でオーバーライドする場合、このオプションを渡して、カスタムの場所を入力できます。

次に例を示します。

EM_STAGE_DIR=/home/john/software/oracle/pafdir

b_startAgent=false

管理エージェントをインストールして構成した後に自動的に起動しないようにするには、このパラメータを指定します。

このパラメータを指定しないと、管理エージェントはインストールして構成した後に自動的に起動します。

b_secureAgent=false

インストールした後に管理エージェントを保護しない場合は、このパラメータを指定します。

このパラメータを指定する場合は、EM_UPLOAD_PORTパラメータを使用して、OMS HTTPポートも必ず指定してください。

たとえば、b_secureAgent=false EM_UPLOAD_PORT=4899などです。

このパラメータを指定しないと、管理エージェントはインストールした後に自動的に保護されます。

8.4.3 サイレント・モードでの共有エージェントのインストール

サイレント・モードで共有エージェントをインストールするには、次の手順に従います。

マスター・エージェント・ホストの場合

1. マスター・エージェント・ホストからcreate_plugin_list.plスクリプトを実行します。
$AGENT_HOME/perl/bin/perl $AGENT_HOME/sysman/install/create_plugin_list.pl -instancehome <AGENT_INSTANCE_HOME>

共有エージェント・ホストの場合

1. 表8-3の説明に従って、AgentNFS.rspというレスポンス・ファイルを作成します。

注意:
作成するレスポンス・ファイルには任意の名前が付けられ、必ずしもAgentNFS.rspである必要はありません。わかりやすくするため、この章ではAgentNFS.rspという名前を使用します。また、レスポンス・ファイルを作成するかわりに、スクリプトの起動中に引数を明示的に渡すことができます。ただし、レスポンス・ファイルを作成して情報を取得することをお薦めします。

2. 共有エージェント・ホストからスクリプトを起動して、レスポンス・ファイルを渡します。
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/AgentNFS.pl -responseFile <absolute_path_to_response_file>

次に例を示します。

/scratch/agent_base_dir/core/12.1.0.4.0/perl/bin/perl /scratch/agent_base_dir/core/12.1.0.4.0/sysman/install/AgentNFS.pl -responseFile /home/john/AgentNFS.rsp

<AGENT_HOME>は共有の場所であり、すべての宛先ホストからアクセスできることを確認してください。

注意:

- レスポンス・ファイルを作成するかわりに、スクリプトの起動中にすべての引数を明示的に渡すことができます。この場合、次の方法でスクリプトを起動します。
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/AgentNFS.pl AGENT_INSTANCE_HOME=<absolute_path_to_instance_dir> ORACLE_HOME=<absolute_path_to_master_agent_oracle_home> <parameter1>=<value1> <parameter2>=<value2> <parameter3>=<value3>...

次に例を示します。

/scratch/agent_base_dir/core/12.1.0.4.0/perl/bin/perl /scratch/agent_base_dir/core/12.1.0.4.0/sysman/install/AgentNFS.pl AGENT_INSTANCE_HOME=/<local_location>/agent_inst ORACLE_HOME=/scratch/agent_base_dir/core/12.1.0.4.0 AGENT_PORT=1832 AGENT_REGISTRATION_PASSWORD=welcome b_startAgent=TRUE

AGENT_INSTANCE_HOMEを指定するときに、指定した場所がホストに対してローカルで、他のホストから再使用されないことを確認します。

- ホスト・ターゲットの追加ウィザードを使用してマスター・エージェントがインストールされた場合、次の引数および値が渡されていることを確認します。
AGENT_REGISTRATION_PASSWORD=<password>

b_startAgent=TRUE

- デフォルトで<AGENT_HOME>がマスター・エージェントの場所<AGENT_HOME>/oraInst.locが適用されているため、-invPtrLoc引数を渡さないでください。インベントリ・ファイルが指すOracle Inventoryディレクトリが共有場所にないことも確認します。

- 共有エージェントをインストールした後に宛先ホストを再起動しても共有エージェントが自動的に起動しない場合は、元の権限でマウントをリストアして共有エージェントを手動で起動します。

3. root.shスクリプトの実行を求められた場合、共有エージェントのインスタンス・ディレクトリから実行します。
<AGENT_INSTANCE_HOME>/root.sh

自身がrootユーザーではない場合、SUDOを使用して、rootユーザーに変更してください。たとえば、次のようなコマンドを実行します。

/usr/local/bin/sudo /scratch/OracleHomes/agent_inst/root.sh

4. 共有エージェントをインストールするその他のホストに対し、手順(2)から(4)を繰り返します。

8.4.4 サイレント・モードで共有エージェントをインストールするためのレスポンス・ファイル・パラメータ

サイレント・モードで共有エージェントをインストールするには、AgentNFS.plスクリプトを起動して、すべての必要な情報を取得するレスポンス・ファイルを渡す必要があります。表8-3は、レスポンス・ファイルに含む必要がある様々なパラメータを示しています。

表8-3 AgentNFS.plスクリプトを使用してOracle Management Agentをインストールするためのレスポンス・ファイルの作成

パラメータ

説明

ORACLE_HOME

宛先ホストで共有および表示されるマスター・エージェント・ホームの絶対パスを指定します。

たとえば、/scratch/agent_base_dir/core/12.1.0.4.0などです。

AGENT_PORT

(オプション)共有エージェント・プロセスを起動するポートを入力します。1830から1849の間の空きポートを入力できます。HTTPとHTTPSの両方に同じポートが使用されます。

たとえば、1832です。

AGENT_INSTANCE_HOME

すべての管理エージェント関連の構成ファイルを格納する宛先ホストの場所の絶対パスを指定します。

たとえば、/<local_location>/agent_instなどです。

この場所がホストに対してローカルで、他のホストから再使用されないことを確認します。

AGENT_REGISTRATION_PASSWORD

Enterprise Managerシステムを結合する新しい管理エージェントを登録するパスワードを入力します。

デフォルトで、OMSと管理エージェント間の通信は保護およびロックされます。Enterprise Managerシステムに追加する新しい管理エージェントは、事前に認証を受ける必要があります。ここで入力するパスワードは、新しい管理エージェントを認証するために使用されます。

たとえば、Wel456comeなどです。

注意: ホスト・ターゲットの追加ウィザードを使用してマスター・エージェントがインストールされた場合、このパラメータを渡す必要があります。

b_startAgent

インストールして構成した後に共有エージェントを自動的に起動するため、TRUEに設定します。

注意: ホスト・ターゲットの追加ウィザードを使用してマスター・エージェントがインストールされた場合、このパラメータを渡す必要があります。

ORACLE_HOSTNAME

(オプション) (仮想ホストへのインストールのみ)共有エージェントをインストールしている仮想ホスト名を指定します。

ALLOW_IPADDRESS

(オプション)ORACLE_HOSTNAMEにIPアドレスを指定する場合にはTRUEを入力します。ALLOW_IPADDRESSがFALSEに設定された場合には、管理エージェントのインストール中にORACLE_HOSTNAMEにIPアドレスを指定すると、前提条件チェックは失敗します。

たとえば、ALLOW_IPADDRESS=TRUEなどです。

このパラメータを追加しないと、デフォルトでFALSEが設定されます。

START_PRIORITY_LEVEL

(UNIXベースのホストのみ)

(オプション) このパラメータは、ホスト起動時の管理エージェント・サービスの優先度を指定する場合に使用します。このパラメータは、0から99の間の値を受け付けます。ただし、このパラメータには91から99の間の値を指定することをお薦めします。

たとえば、START_PRIORITY_LEVEL=95などです。

このパラメータを追加しないと、デフォルトで98が設定されます。

SHUT_PRIORITY_LEVEL

(UNIXベースのホストのみ)

(オプション)このパラメータは、ホスト停止時の管理エージェント・サービスの優先度を指定する場合に使用します。このパラメータは0から99の間の値を受け付けます。

たとえば、SHUT_PRIORITY_LEVEL=25などです。

このパラメータを追加しないと、デフォルトで19が設定されます。

PROPERTIES_FILE

(オプション)プロパティ・ファイルの絶対位置を指定する場合にこのパラメータを使用します。

たとえば、PROPERTIES_FILE=/tmp/agent.propertiesなどです。

プロパティ・ファイルで管理エージェントのデプロイメントに使用するパラメータを指定します。プロパティ・ファイルで指定できるパラメータのリストは、$<AGENT_INSTANCE_HOME>/sysman/config/emd.propertiesにあります。プロパティ・ファイルでは、たとえば次のように名前と値のペアでパラメータを指定する必要があります。

REPOSITORY_PROXYHOST=abc.example.com

REPOSITORY_PROXYPORT=1532

プロパティ・ファイルでは、空白の入ったパラメータ値はサポートしていません。特定のパラメータの値に空白があった場合には、管理エージェントのデプロイ後に次のコマンドを実行します。

$<AGENT_INSTANCE_HOME>/bin/emctl setproperty agent -name <parameter_name> -value <parameter_value>

8.5 共有エージェントのインストール後

共有エージェントをインストールした後は、次の手順を実行します。

1. (グラフィック・モードのみ)「ホスト・ステータスの追加」ページのインストールを確認します。デプロイ操作のフェーズである初期化、リモートの前提条件チェックおよびエージェント・デプロイに行われた進行状況を確認します。

注意:
ホスト・ターゲットの追加ウィザードで、「エージェントのデプロイ」をクリックして、1つ以上の管理エージェントをインストールすると、ホスト・ステータスの追加ページが自動的に表示されます。
詳細を表示するか、すべてのデプロイメント・セッションの進行状況を追跡する場合、「設定」メニューから「ターゲットの追加」を選択して、「ターゲットの手動追加」をクリックします。「ターゲットの手動追加」ページで、「ホスト・ターゲットの追加」を選択し、「ホスト結果の追加」をクリックします。

特定のフェーズが失敗したか警告とともに終了した場合、エージェント・デプロイ詳細セクションの各フェーズに指定された詳細を確認し、次のうちの1つを実行します。

- 警告または失敗を無視し、必要な場合、セッションを続行します。

- チェックを正常にクリアしたリモート・ホストのみで管理エージェントのデプロイを続行することを選択し、警告または失敗のステータスを持つホストは無視できます。これを行うには、「続行」をクリックして、「失敗したホストは無視して続行」を選択します。

- 警告または失敗のステータスを持つホストを含むすべてのホストで、管理エージェントのデプロイを続行することを選択できます。これを行うには、「続行」をクリックして、「すべてのホストで続行」を選択します。

- エラーの説明を慎重に確認し、原因を理解し、Oracle推奨のアクションを実行することで、問題を解決します。

- インストール詳細が同じである管理エージェントのデプロイを再試行することを選択できます。これを行うには、「再試行」をクリックして、「同じ入力を使用して再試行」を選択します。

- インストール詳細が変更された管理エージェントのデプロイを再試行することを選択できます。これを行うには、「再試行」をクリックして、「入力を更新して再試行」を選択します。

2. インストールを確認します。

1. 共有エージェントのインスタンス・ホームに移動して次のコマンドを実行すると、管理エージェントが動作していることを確認するメッセージが表示されます。
$<AGENT_INSTANCE_HOME>/bin/emctl status agent

2. 共有エージェント・ホームに移動して次のコマンドを実行すると、EMDアップロードが正常に完了したことを確認するメッセージが表示されます。
$<AGENT_INSTANCE_HOME>/bin/emctl upload agent

3. (グラフィック・モードのみ)制限付き権限委任プロバイダ(PDP)の構成設定がある場合は、PDP構成ファイルにnmosudoの場所を入力します。
Enterprise Managerでは、SUDOおよびPowerBrokerなどのPDPをサポートしているため、管理者は特定のユーザーが特定のコマンドを実行できないように制限できます。

Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)、リリース3 (12.1.0.3)およびリリース4 (12.1.0.4)では、nmosudoはエージェント・ベース・ディレクトリ内のsbinディレクトリに格納されています。たとえば、<AGENT_BASE_DIRECTORY>/sbin/nmosudoなどです。Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)(バンドル・パッチ1あり/なし)では、nmosudoはエージェント・インスタンス・ディレクトリに格納されています。たとえば、<AGENT_INSTANCE_DIRECTORY>/bin/nmosudoなどです。

このため、12.1.0.4管理エージェントをインストールする場合は、nmosudoの新しい場所を更新するようにPDP構成ファイルを変更する必要があります。

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

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

4. (UNIXオペレーティング・システムのみ)rootユーザーとして次のスクリプトを手動で実行します。

- これがホストにインストールした最初のOracle製品である場合、orainstRoot.shスクリプトを、共有エージェント・ホームで使用可能なoraInst.locファイルで指定されたインベントリの場所から実行します。
たとえば、oraInst.locファイルで指定されたインベントリの場所が$HOME/oraInventoryである場合、次のコマンドを実行します。

$HOME/oraInventory/orainstRoot.sh

- 共有エージェントのホームからroot.shスクリプトを実行します。
$<AGENT_HOME>/root.sh

5. 間違ったタイムゾーンの設定に関する前提条件チェックの警告を無視した場合、次のコマンドを実行して表示される手順に従います。
$<AGENT_INSTANCE_HOME>/bin/emctl resetTZ agent

6. デフォルトでは、ホストおよび共有エージェントは、監視のためにEnterprise Manager Cloud Controlコンソールに自動的に追加されます。ただし、そのホストで実行中のターゲットは、自動的に検出および監視されません。
その他のターゲットを監視するには、そのターゲットを、「自動検出の結果」ページ、「ターゲットの手動追加」ページまたは監視するターゲットに提供されている検出ウィザードを使用して、Enterprise Manager Cloud Controlに追加する必要があります。

ホスト・ターゲットおよびoracle_emdターゲットを共有エージェントに追加するには、次のコマンドを実行します。

$<SHARED_AGENT_HOME>/bin/emctl config agent addinternaltargets

Enterprise Manager Cloud Control,のターゲットの検出の詳細は、Oracle Enterprise Manager Cloud Controlの管理者ガイドのターゲットの追加に関する章を参照してください。

注意:
Oracle Management Agent 12c (12.1.0.x)が頻繁にハングする、またはSolaris 9uxおよび10uxオペレーティング・システムで応答しない場合、My Oracle SupportのドキュメントID 1427773.1を参照してください。

9 Oracle Management Agentソフトウェアを今すぐインストールして後で構成

この章では、Oracle Management Agent (管理エージェント)のソフトウェア・バイナリのみインストールして、後でインストールを構成する方法について説明します。この章の具体的な内容は次のとおりです。

- 管理エージェントをインストールして後で構成する概要

- 管理エージェントのインストールを開始する前に

- 管理エージェントをインストールするための前提条件

- 管理エージェントのソフトウェア・バイナリのみのインストール

- 管理エージェントのソフトウェア・バイナリの構成

- 管理エージェントのインストール後

9.1 管理エージェントをインストールして後で構成する概要

管理エージェントのソフトウェア・バイナリのみインストールして、関連付けられたOracle Management Service (OMS)で動作するよう後で構成できます。この方式では、インストール・プロセスを主にインストール・フェーズと構成フェーズの2つのフェーズに分割できます。

インストール・フェーズの実行中に、-softwareOnly引数を渡すagentDeploy.shスクリプトを起動して、ソフトウェア・バイナリをコピーして管理エージェントのOracleホームを作成します。構成フェーズの実行中に、-configOnlyを渡す同じスクリプトを起動して、ソフトウェア・バイナリを構成します。

当然、インストール・フェーズはバイナリのコピーだけなので、インストール・フェーズは構成フェーズと比較して実行時間が大幅に少なくなります。このため、時間と優先度に従ってインストールを計画できます。

注意:
このインストール・タイプは、サイレント・モードでのみ使用できます。

注意:
既存の管理エージェントを新しいOracle Management Service (OMS)に対して再指定する場合、まず、管理エージェントとプラグインを削除し、新しいOMSを使用して管理エージェントとプラグインを再デプロイします。これは通常、テスト環境のEnterprise Manager Cloud Controlシステムから本番環境のEnterprise Manager Cloud Controlシステムに移行する場合に行われます。
既存の管理エージェントを新しいOMSに対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

9.2 管理エージェントのインストールを開始する前に

管理エージェントをインストールする前に、第6.2項に示されている点を確認してください。

9.3 管理エージェントをインストールするための前提条件

管理エージェントをインストールする前に、第6.3項で説明されている前提条件を満たしていることを確認してください。

9.4 管理エージェントのソフトウェア・バイナリのみのインストール

サイレント・モードで管理エージェントのソフトウェア・バイナリのみをインストールするには、第6.4.2項に記載されている手順のいずれかに従います。デプロイメント・スクリプトを起動する場合、必ず-softwareOnlyオプションを渡します。

<Software_Extracted_Location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile> -softwareOnly

たとえば、/tmp/agtImg/agentDeploy.sh AGENT_BASE_DIR=/scratch/agent12c RESPONSE_FILE=/tmp/agtImg/agent.rsp -softwareOnlyなどです。

管理エージェントが正常にインストールされると、それを伝えるメッセージがコマンドラインに表示されます。

注意:
-forceConfigureオプションを渡さないでください。

9.5 管理エージェントのソフトウェア・バイナリの構成

サイレント・モードで管理エージェントのソフトウェア・バイナリを構成するには、管理エージェント・ホームから次のオプションを使用して、デプロイメント・スクリプトを起動します。

$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile> -configOnly

たとえば、$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=/scratch/agent12c RESPONSE_FILE=/tmp/agtImg/agent.rsp -configOnlyなどです。

管理エージェントが正常にインストールされると、それを伝えるメッセージがコマンドラインに表示されます。

注意:

- ここで渡すレスポンス・ファイルは、第9.4項で渡されたレスポンス・ファイルと同じです。

- -forceConfigureオプションを渡さないでください。

9.6 管理エージェントのインストール後

管理エージェントのインストール後は、第6.5項に示されている手順に従ってください。

第V部

拡張インストールおよび構成

この部では、Enterprise Manager Cloud Controlのインストールおよび製品の使用開始後に実行可能な拡張インストールおよび構成タスクについて説明します。

この部は、次の章で構成されています。

- 第10章「Enterprise Managerのファイアウォールの構成」

- 第11章「Enterprise Managerデプロイメントのサイジング」

- 第12章「拡張インストール・オプションを使用したADPのインストール」

- 第13章「拡張インストール・オプションを使用したJVMDのインストール」

- 第14章「Enterprise ManagerでのBI Publisherの構成」

10 Enterprise Managerのファイアウォールの構成

ファイアウォールは、各ネットワーク・パケットを調べ適切な処理を決定することでネットワーク通信量を制限し、それによって、企業の情報技術(IT)インフラストラクチャを保護します。

ファイアウォールの構成には通常、ファイアウォールの片側(インターネットなど)に有効なポートの制限が含まれます。HTTPなど、特定のポートを通過できる通信の種類を限定するように設定することもできます。クライアントが制限付きポート(セキュリティ・ルールの対象外のポート)に接続を試行したり、不適切なプロトコルを使用すると、クライアントは即座にファイアウォールによって切断されます。特定のサーバーへのユーザー・アクセスを制限するために、ファイアウォールを企業のイントラネット内で使用することもできます。

Oracle Enterprise Managerコンポーネントはエンタープライズ全体の異なるホストにデプロイできます。これらのホストはファイアウォールによって分割されます。この章では、Enterprise Managerコンポーネント間の通信を可能にするファイアウォールの構成方法について説明します。

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

- Enterprise Managerの使用中のファイアウォール構成の考慮について

- Enterprise Managerコンポーネントが使用するデフォルト・ポート

- Enterprise Managerのファイアウォール構成について

- WebブラウザとEnterprise Managerコンソールの間のファイアウォールについて

- ファイアウォールで保護されたホスト上の管理エージェントの構成について

- プロキシ・サーバーを使用するための管理エージェントの構成

- OMSと管理エージェントの通信を許可するファイアウォールの構成について

- ファイアウォールで保護されたホスト上のOMSの構成について

- 管理エージェントとの通信にプロキシ・サーバーを使用するためのOMSの構成

- 管理エージェントがデータをOMSにアップロードできるファイアウォールの構成について

- My Oracle SupportにアクセスするためのOMSの有効化について

- dontProxyforプロパティについて

- OMSと管理リポジトリの間のファイアウォールについて

- Enterprise Managerと管理対象データベース・ターゲットの間のファイアウォールについて

- 複数のOMSインスタンスでのファイアウォールの使用について

- Oracleビーコンに対するICMPおよびUDP通信を可能にするためのファイアウォールの構成について

- ファイアウォールでのICMPエコー・リクエストの有効化について

10.1 Enterprise Managerの使用中のファイアウォール構成の考慮について

ファイアウォールの構成はEnterprise Managerのデプロイの最後に行います。ファイアウォールを構成する前に、Enterprise Managerコンソールにログインできることと、Oracle Management Agent (管理エージェント)が稼働中でターゲットを監視していることを確認してください。

ファイアウォールがすでにインストールされている環境でEnterprise Managerをデプロイする場合は、インストールおよび構成プロセスを終了してEnterprise Managerにログインできることと、管理エージェントが稼働中でターゲットを監視していることを確認できるまで、全通信に対するデフォルトのEnterprise Manager通信ポートを開いておきます。

Enterprise Managerのデフォルトの通信ポートは、インストール時に割り当てられます。デフォルトのポートを変更する場合は、必ずファイアウォール構成時の新規のポート割当てを使用してください。

Oracle Management Service (OMS)のEnterprise Manager Framework Securityを有効にしている場合、その構成プロセスの最終ステップは、管理エージェントからのアップロードをセキュアなチャネルのみに限定することです。そのステップを終了する前に、管理エージェントと管理リポジトリの間でHTTPおよびHTTPS通信の両方が可能となるようにファイアウォールを構成し、Enterprise Managerにログインできることとデータがリポジトリにアップロード中であることを確認するテストを行います。

両方のプロトコルが有効な状態でOMSと管理エージェントが通信できることを確認した後、セキュア・モードへの移行を終了し、必要に応じてファイアウォール構成を変更します。ファイアウォールを段階的に構成していくと、構成上の問題をより簡単に解決できます。

10.2 Enterprise Managerコンポーネントが使用するデフォルト・ポート

Enterprise Managerコンポーネントが使用するポートを理解するには、第2.1.10項を参照してください。

10.3 Enterprise Managerのファイアウォール構成について

Enterprise Managerをファイアウォール保護環境下で動作するように設定する際の主な作業は、可能な場合はプロキシ・サーバーを利用すること、必要なポートのみをセキュアな通信で使用可能にすること、およびビジネスの運営に必要なデータのみがファイアウォールを通過するようにすることです。

図10-1に、ファイアウォールを使用するEnterprise Manager環境のトポロジ、および使用可能なデフォルトのポートを示します。

図10-1 ファイアウォール・ポートの要件(デフォルト)

上の図で使用している表記規則は次のとおりです。

表10-1 図で使用されている表記規則

規則

説明

C

コールを行う実体。

*

Enterprise Managerは、Enterprise Managerの設定範囲内の使用可能な最初のポートをデフォルトとして使用します。

**

Enterprise Managerは、使用可能な最初のポートをデフォルトとして使用します。

***

データベース・リスナー・ポート。

注意:

- 矢印は、ポートの方向を示しています。

- ポート1159、4898-4989では、1159がデフォルトです。このポートを使用できない場合は、Oracle Management Serviceによって指定範囲内(4889から4897)の検索が行われます。

- ファイアウォールによって分割された2つのターゲット・ホスト間でクローニングを行うには、それらのエージェントがエージェント・ポートで通信する必要があります。開始管理エージェントがコールを行います。

- ファイアウォール内でICMP (0)エコー・リプライおよびICMP (8)エコー・リクエストを許可します。

10.4 WebブラウザとEnterprise Managerコンソールの間のファイアウォールについて

WebブラウザからEnterprise Managerコンソールへの接続は、Oracle HTTP Serverで使用されるデフォルト・ポート経由で実行されます。

たとえば、Oracle HTTP Serverのデフォルトの保護されていないポートは、通常、ポート7788です。次のURLおよびポートを使用してEnterprise Managerコンソールにアクセスする場合、Enterprise Managerコンソールでポート7788を経由してHTTP通信を受信できるように、ファイアウォールを構成する必要があります。

http://omshost.example.com:7788/em

一方、Oracle HTTP Serverのセキュリティを有効にしている場合は、サーバーのデフォルトのセキュア・ポートを使用する場合がほとんどであり、これは通常、ポート7799です。次のURLおよびポートを使用してEnterprise Managerコンソールにアクセスする場合、Enterprise Managerコンソールでポート7799を経由してHTTPS通信を受信できるように、ファイアウォールを構成する必要があります。

https://omshost.example.com:7799/em

10.5 ファイアウォールで保護されたホスト上の管理エージェントの構成について

管理エージェントがファイアウォールで保護されたホスト上にインストールされ、OMSがファイアウォールの反対側にある場合は、次の作業を実行する必要があります。

- 第10.6項で説明するとおり、OMSへのアップロードにプロキシ・サーバーを使用するように管理エージェントを構成します。

- 管理エージェント・ポートのOMSからHTTP通信を受信できるようにファイアウォールを構成します。Enterprise Manager Framework Securityが有効化されているかどうかにかかわらず、デフォルトのポートは3872です。通信を受信できるのは、管理エージェントに対応するポートがファイアウォールで開かれている場合のみです。

図10-2には、管理エージェントがファイアウォールで保護されている場合に設定する必要がある接続が示されています。

図10-2 管理エージェントがファイアウォール内にある場合の構成タスク

10.6 プロキシ・サーバーを使用するための管理エージェントの構成

ファイアウォール外のOMSとの通信にプロキシ・サーバーを使用するように、またはファイアウォール外のターゲットを管理するように管理エージェントを構成できます。次の手順を実行します。

1. 「設定」メニューから「エージェント」を選択します。

2. 「管理エージェント」表の「名前」列で、構成するエージェントをクリックします。管理エージェントのターゲット・ホームページが開きます。

3. 「エージェント」メニューから「プロパティ」を選択します。

4. プルダウン・メニューから「拡張プロパティ」を選択します。

5. REPOSITORY_PROXYHOSTおよびREPOSITORY_PROXYPORTプロパティの正しい値を指定します。

6. 「適用」をクリックします(変更はAGENT_HOME/sysman/config/emd.propertiesファイルに保存されます)。

注意:
プロキシ・パスワードは、管理エージェントを再起動する際に暗号化されます。

10.7 OMSと管理エージェントの通信を許可するファイアウォールの構成について

環境内の管理エージェントが管理対象ホストからOMSへデータをアップロードする一方で、OMSは管理エージェントと通信を行う必要もあります。このため、管理エージェントがファイアウォールで保護されている場合、OMSが管理エージェント・ポート上のファイアウォールを介して管理エージェントに接続できるようにします。

デフォルトでは、Enterprise Managerのインストール時にポート3872が管理エージェントに割り当てられます。ただし、そのポートが使用中の場合は別のポート番号が割り当てられる可能性があります。

管理エージェントに割り当てるポート番号を決定した後、そのポートでHTTPまたはHTTPS (Enterprise Manager Framework Securityが有効か無効かによって変わる)通信を受信できるようにファイアウォールを構成する必要があります。

10.8 ファイアウォールで保護されたホスト上のOMSの構成について

OMSがファイアウォールで保護されたホスト上にインストールされ、管理データを提供する管理エージェントがファイアウォールの反対側にある場合は、次の作業を実行する必要があります。

- 第10.9項で説明するとおり、管理エージェントと通信するプロキシ・サーバーを使用するOMSの構成。

- 管理リポジトリ・アップロード・ポートの管理エージェントからHTTP通信を受信できるようにファイアウォールを構成します。
Enterprise Manager Framework Securityを有効にしている場合、アップロードURLではポート1159がデフォルトで使用されます。このポートを使用できない場合、Enterprise Managerでは、4899から4908の範囲内で使用可能な最初のポートがデフォルトとして使用されます。Enterprise Manager Framework Securityを有効にしていない場合、アップロード・ポートは4889から4897の範囲内で使用可能な最初のポートになります。

図10-3には、管理エージェントがファイアウォールで保護されている場合に設定する必要がある接続が示されています。

図10-3 管理サービスがファイアウォール内にある場合の構成タスク

10.9 管理エージェントとの通信にプロキシ・サーバーを使用するためのOMSの構成

この項では、ファイアウォール外の管理エージェントとの通信にプロキシ・サーバーを使用するようにOMSを構成する方法について説明します。

プロキシ・サーバーを使用するためにOMSを構成するには、次のようにします。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

注意:
エージェントのプロキシ設定ページでは、管理エージェントからOMSではなく、OMSから管理エージェントへのみの通信に使用できるプロキシ・サーバーを構成できます。構成するプロキシ・サーバーは、OMSとすべての管理エージェント間の通信に使用されます。

2. 「手動プロキシ構成」を選択します。

3. Specify values for 「プロトコル」、「プロキシ・サーバーのホスト」、「ポート」および「プロキシを使用しないドメイン」の値を指定します。指定したプロキシ・サーバーがセキュリティ・レルムまたはログイン資格証明(あるいはその両方)を使用して構成されている場合、「レルム」、「ユーザー名」および「パスワード」に値を指定します。

4. 「テストURL」セクションで、「URL」に管理エージェントのURLを指定し、「テスト」をクリックして、指定した管理エージェントとOMSが指定したプロキシ・サーバーを使用して通信できるかどうかをテストします。

5. 接続が成功した場合、「適用」をクリックしてプロキシ設定をリポジトリに保存します。

6. OMSを再起動します。複数OMSの設定を使用している場合、すべてのOMSを再起動します。
Unixベースのプラットフォームで稼働するOMSを再起動するには、次のコマンドを実行します。

<OMS_HOME>/bin/emctl stop oms
<OMS_HOME>/bin/emctl start oms

Microsoft Windowsのプラットフォームで稼働するOMSを再起動するには、次の手順を実行します。

1. 「マイ コンピュータ」を右クリックし、「管理」を選択します。

2. 「コンピュータの管理」ウィンドウの左側のペインで、「サービスとアプリケーション」を展開し、「サービス」を選択します。

3. 「OracleManagementServer_EMGC_OMS*」サービスを選択し、再起動ボタンをクリックします。

10.10 管理エージェントがデータをOMSにアップロードできるファイアウォールの構成について

環境内の管理エージェントが管理対象ホスト上の管理エージェントへ接続する必要がある一方で、OMSが管理エージェントからのアップロードされたデータを受信できる必要もあります。OMSがファイアウォールの内側にある場合、管理エージェントがアップロード・ポート上でデータをアップロードできるようにファイアウォールを構成する必要があります。

デフォルトでは、Enterprise Managerのインストール時にポート4889がリポジトリのアップロード・ポートとして割り当てられます。ただし、そのポートが使用中の場合は別のポート番号が割り当てられます。

また、Enterprise Manager Framework Securityを有効にすると、アップロード・ポートは自動的にセキュアな1159 HTTPSポートに変更されます。

管理者はインストール後にアップロード・ポートを変更することもできます。

OMSのアップロード・ポートに割り当てるポート番号を決定した後、そのポートでHTTPまたはHTTPS (Enterprise Manager Framework Securityが有効か無効かによって変わる)通信を受信できるようにファイアウォールを構成する必要があります。

10.11 My Oracle SupportにアクセスするためのOMSの有効化について

環境内でインターネットへのオンライン・アクセスが厳しく禁止されていないかぎり、My Oracle SupportにアクセスできるようにOMSを有効にしてください。このアクセスは、更新やパッチなどのダウンロードに必要です。

最低限、次のURLはファイアウォールを通過できるようにしてください。

- aru-akam.oracle.com

- ccr.oracle.com

- login.oracle.com

- support.oracle.com

- updates.oracle.com

これらのURLへの接続に、デフォルトのポート(HTTP接続の場合はポート80、HTTPS接続の場合はポート443)が使用されることを確認します。

10.12 dontProxyforプロパティについて

プロキシ・サーバーを使用するためにOMSまたは管理エージェントを構成する際、プロキシが使用されない特定のURLドメインを指定するdontProxyForプロパティの目的を理解することが重要です。

たとえば、次のような状況を想定します。

- 企業のファイアウォール内のホスト上にOMSおよびいくつかの管理エージェントをインストールしています。これらのホストは、内部のドメイン.example.comおよび.example.us.com内にあります。

- ファイアウォール外のホスト上にいくつかの追加管理エージェントをインストールしています。これらのホストは.example.ukドメイン内にインストールされています。

- My Oracle Support上の重要なソフトウェア・パッチを自動的にチェックするようにEnterprise Managerを構成しています。

このケースでは、プロキシ・サーバーを使用せずに、OMSを直接ファイアウォール内の管理エージェントに接続します。その一方で、ファイアウォール外の管理エージェントおよびMy Oracle Supportサイト(次のURLを参照)には、プロキシ・サーバーを使用してOMSを接続します。

http://support.oracle.com

次のプロパティを指定すると、OMSはファイアウォール内の管理エージェントへの接続にプロキシ・サーバーを使用しません。My Oracle Supportおよびファイアウォール外の管理エージェントへの接続は、プロキシ・サーバーを経由して行われます。

proxyHost=proxy42.example.com
proxyHost=80
dontProxyFor=.example.com, .example.us.com

10.13 OMSと管理リポジトリの間のファイアウォールについて

OMSと管理リポジトリの間のセキュアな接続はOracle Advanced Securityの機能を使用して実行されます。このため、OMSと管理リポジトリがファイアウォールで分割されている場合は、Oracle Netのファイアウォール・プロキシをOMSがリポジトリにアクセスできるように構成する必要があります。また、このファイアウォールにタイムアウトを構成した場合は、データベース側でSQLNET.EXPIRE_TIMEパラメータをDead Connection Detection (DCD)用に調整し、このパラメータ($ORACLE_HOME/network/admin/sqlnet.oraにある)をファイアウォールに構成したタイムアウトの値より小さい値に設定してください。

10.14 Enterprise Managerと管理対象データベース・ターゲットの間のファイアウォールについて

Enterprise Managerコンソールを使用してデータベースを管理する場合、特定の監視および管理タスクを実行するには、Enterprise Managerコンソールからデータベースにログインする必要があります。ファイアウォールの反対側のデータベースにログインする場合は、Oracle Netのファイアウォール・プロキシ・アクセスを使用できるようにファイアウォールを構成する必要があります。

特に、管理対象データベースで管理アクティビティを実行する場合は、OMSがOracleリスナー・ポート経由でデータベースと通信するようにファイアウォールが構成されている必要があります。

リスナー・ポートは、Enterprise Managerコンソールのリスナー・ホームページを参照して取得できます。

10.15 複数のOMSインスタンスでのファイアウォールの使用について

Enterprise Managerでは、共通の管理リポジトリと通信する複数のOMSインスタンスの使用がサポートされています。たとえば、複数のOMSを使用すると、E-Businessエンタープライズの成長に伴い集中管理機能を拡大していく場合のロード・バランシングに役立ちます。

ファイアウォールで保護された環境で複数のOMSインスタンスをデプロイするときは、次のことに注意してください。

- 各管理エージェントは、1つのOMSにデータをアップロードするように構成されています。このため、管理エージェントとそのOMSの間にファイアウォールがある場合、管理エージェントがアップロードURLを使用してOMSにデータをアップロードできるように、ファイアウォールを構成する必要があります。

関連項目:
第10.5項「ファイアウォールで保護されたホスト上の管理エージェントの構成について」
第10.8項「ファイアウォールで保護されたホスト上のOMSの構成について」

- また、管理エージェントの可用性のチェックのため、各OMSがエンタープライズ内のあらゆる管理エージェントに接続できるようにします。このため、デプロイする各OMSがHTTPまたはHTTPS経由でエンタープライズ内のあらゆる管理エージェントと通信できるように、ファイアウォールを構成する必要があります。
そうでない場合、特定の管理エージェントへアクセスしないOMSは、管理エージェントが実行中かどうかについて正しくない情報をレポートする可能性があります。

関連項目:
Enterprise Managerによるホストおよび管理エージェントの可用性の決定方法の詳細は、Enterprise Managerオンライン・ヘルプの可用性に関する項

10.16 Oracleビーコンに対するICMPおよびUDP通信を可能にするためのファイアウォールの構成について

Oracleビーコンにより、アプリケーションのパフォーマンス可用性およびパフォーマンス監視が提供されます。これらは、Enterprise Managerのアプリケーション・サービス・レベル管理機能の一部になります。

関連項目:
Enterprise Managerオンライン・ヘルプのアプリケーション・サービス・レベル管理に関する項

Enterprise Managerでは、業界標準のInternet Control Message Protocol (ICMP)およびユーザー・データグラム・プロトコル(UDP)を使用して、Oracleビーコンと監視対象のネットワーク・コンポーネントの間のデータ転送を行います。Webアプリケーション・コンポーネントとそのコンポーネントを監視するために使用しているビーコンが、ファイアウォールによって分割される場合があります。このようなケースでは、ICMP通信、UDP通信およびHTTP通信ができるようにファイアウォールを構成する必要があります。

10.17 ファイアウォールでのICMPエコー・リクエストの有効化について

OMSは、Internet Control Message Protocol (ICMP)エコー・リクエストを使用してターゲット・ホスト・マシンのステータスを確認します。ICMPエコー・リクエストがファイアウォールによりブロックされると、ホスト・マシンが停止しているように見えます。

環境内のマシンのステータスを判別するには、ファイアウォールでICMPエコー・リクエストを有効にする必要があります。ICMPエコー・リクエストが有効になっている場合、OMSからpingコマンドを発行して、マシンのステータスを確認できます。

必ず、ファイアウォール内でICMP (0)エコー・リプライおよびICMP (8)エコー・リクエストを許可してください。

11 Enterprise Managerデプロイメントのサイジング

Oracle Enterprise Manager Cloud Control 12cリリース12.1.0.4には、1つのEnterprise Manager実装において何百ものユーザー、何千ものシステムとサービスの規模を拡大および縮小する機能があります。

この章では、Oracle Enterprise Managerアプリケーションを使用する上で最適なパフォーマンスを得るための手法について説明します。また、大規模環境でのキャパシティ・プランニング、サイジング、Enterprise Managerのパフォーマンスの最大化にも役立ちます。ルーチン・ハウスキーピングを続け、パフォーマンスの監視を定期的に行うことで、将来的なサイジングの要件を正確に見積もるために必要なデータが得られます。Enterprise Manager Cloud Controlのバイタル・サインに対する適切なベースライン値を認識し、ベースラインに対して妥当な警告とクリティカルのしきい値を設定することで、Enterprise Managerによる監視が可能になります。

サイジングは、Enterprise Managerのパフォーマンスを左右する重要な要素です。Enterprise Managerデプロイメントのサイズ設定が不十分であると、Enterprise Manager全体のメリットが損われてしまいます。Enterprise Manager Oracle Management Service (OMS)および管理リポジトリ層に必要なリソースは、監視対象ターゲットの数に基づいて大きく変化します。Enterprise Managerインフラストラクチャのサイジングでは他にも考慮すべき点がたくさんありますが、次のガイドラインは、OMSおよび管理リポジトリ層のハードウェア・リソースの最小要件と初期構成設定を決定する際に従うことのできる簡単な手順を示しています。

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

- Enterprise Manager Cloud Controlのサイジング

- Enterprise Manager Cloud Controlのパフォーマンス最適化の方法

- Fusion Middlewareの監視に対するリポジトリとサイジングの要件の概要

11.1 Enterprise Manager Cloud Controlのサイジング

Oracle Enterprise Managerは、可用性および拡張性に優れたデプロイメント・トポロジを備えています。この章では、Oracle Enterprise Managerデプロイメントの最初のキャパシティ・プランニングに役立つ、サイジングおよびチューニングの基本的な推奨事項について説明します。この章では、Oracle Enterprise Managerのコンポーネントおよびシステムの基本的な内容が理解されていることを前提としています。Oracle Enterprise Managerの詳細は、
http://docs.oracle.com/cd/E24628_01/doc.121/e25353/overview.htmで入手できます。この情報はサイトのサイジングの起点となります。サイトごとに独自の特性があるので、必要に応じて監視やチューニングを行う必要があります。

サイジングは、Enterprise Managerのパフォーマンスを左右する重要な要素です。Enterprise Managerデプロイメントのサイズ設定が不十分であると、ユーザーが苛立ちを感じ、Enterprise Manager全体のメリットが損われてしまいます。Enterprise ManagerのOMSおよびリポジトリ層に必要なリソースは、監視対象ターゲットの数によって大きく異なります。Enterprise Managerインフラストラクチャのサイジングでは他にも考慮すべき点がたくさんありますが、次のガイドラインは、OMSおよびリポジトリ層のハードウェア・リソースの最小要件と初期構成設定を決定する際に従うことのできる簡単な手順を示しています。

11.1.1 サイジング・ガイドラインの概要

次の各項では、サイジング・ガイドラインの概要を説明します。

11.1.1.1 ハードウェア情報

この章で説明しているサイジング・ガイドラインは、次のハードウェアおよびオペレーティング・システムの組合せで仮想環境を実行し、取得したものです。

- ハードウェア: オラクル社のSun Fire X4170 M2

- ハイパーバイザー: Linux Oracle Virtual Server (64ビット)

- 仮想マシンのオペレーティング・システム: Oracle Enterprise Linux (64ビット)

仮想環境では、Oracle Virtual Server (OVS)ホストとそこで実行されている仮想マシンとの間にCPUの1対1マッピングが設定されていました。OVSサーバーには、メモリーをスワップせずにすべての仮想マシンをサポートできる十分なRAMが搭載されていました。

この情報は、Oracle Enterprise Linux (64ビット)環境に基づいています。他のプラットフォームで実行する場合は、同様のハードウェア・パフォーマンスに基づいて、サイジング情報を換算する必要があります。換算にはシングル・スレッドのパフォーマンスを使用します。処理能力のベンチマーク上は総合的なマシン性能が同じであっても、24個の低速コアを持つマシンで実行する場合と12個の高速コアを持つマシンで実行する場合とでは等しくなりません。シングル・スレッドのパフォーマンスは、適正なEnterprises Managerユーザー・インタフェースのレスポンス時間を計る上で重要です。

11.1.1.2 サイジングの仕様

Oracle Enterprise Managerのサイジング・ガイドラインは、4つのサイズ(評価、小、中、大)に分かれています。表11-1に、各サイズの定義を示します。

表11-1 Oracle Enterprise Managerサイトのサイズ

サイズ

エージェント数

ターゲット数

同時ユーザー・セッション数

評価

< 10

< 100

<3

小

< 100

< 1000

<10

中

>= 100, < 1000

>= 1000, < 10,000

>= 10, < 25

大

>= 1000

>= 10,000

>= 25, <= 50*

大規模なユーザー負荷については、第11.1.3.1項「大規模な同時UI負荷」を参照してください。

評価の構成は本番環境には適していません。試行およびテスト環境のみに適しています。

11.1.1.3 アップグレードされたインストールのサイジング

Enterprise Managerの以前のリリースからEnterprise Manager 12cにアップグレードする場合、SYSMANユーザーとして次の問合せを実行し、表1で使用するための管理エージェントおよびターゲット数を取得できます。

- エージェント数: select count(*) from mgmt_targets where target_type = &rsquor;oracle_emd'

- ターゲット数: select count(*) from mgmt_targets where target_type != &rsquor;oracle_emd'

11.1.1.4 最小ハードウェア要件

表11-2に、4つの構成の最小ハードウェア要件を示します。

表11-2 Oracle Enterprise Managerの最小ハードウェア要件

サイズ

OMSマシン数*

OMS当たりのコア数

OMS当たりのメモリー(GB)

OMS当たりの記憶域(GB)

データベース・マシン数*

データベース・マシン当たりのコア数

データベース・マシン当たりのメモリー(GB)

評価

1

2

4

18

-

-

-

小

1

2

6

18

1

2

6

中

2

4

8

18

2 (Oracle RAC)

4

8

大

2

4

8

4

16

8

18

18

2 (Oracle RAC)

2 (Oracle RAC)

8

8

16

16

*OMSインスタンスおよびデータベース・インスタンスは、評価サイズを除き、同じ場所に配置できません。

表11-3 Oracle Enterprise Managerの最小記憶域要件

サイズ

MGMT_TABLESPACE (GB)

MGMT_ECM_DEPOT_TS (GB)

TEMP

ARCHIVE LOG AREA (GB)

評価

15

1

3

アーカイブ・ログ・オフ

小

50

1

10

25

中

200

4

20

100

大

300

8

40

150

11.1.1.5 ネットワーク・トポロジの考慮事項

Enterprise Manager Cloud Controlをデプロイする際、各層間のネットワーク・パフォーマンスを第一に考慮する必要があります。Enterprise Manager Cloud Controlでは、各アプリケーション層間のネットワークの異常、障害および故障に対するトレランスが、エラー・トレランスおよびエラー・リカバリによって保証されています。特に管理エージェントは、Enterprise Manager全体のパフォーマンスに大きな影響を与えることなく、パフォーマンスや信頼性の低い、管理サービスへのネットワーク・リンクを処理できます。ネットワークの問題が原因で起こる1つの管理エージェント・データの遅延に関するかぎり、その影響はEnterprise Manager Cloud Controlのシステムワイドなレベルではほとんど気づかない程度のものです。

ただし、管理サービスと管理リポジトリの間のネットワーク待機時間については、わずかに増えるのみでその影響は大きくなります。Enterprise Manager Cloud Controlの実装では、管理サービスと管理リポジトリの間のネットワーク・リンクの品質が十分でない場合に、重大なパフォーマンス問題が発生することがわかっています。

管理サービスのホストとリポジトリのホストは、相互に近接した場所に配置します。理想的には、2つの間のラウンドトリップ・ネットワーク待機時間が1ミリ秒未満になるようにする必要があります。

11.1.2 ソフトウェア構成

次の各項では、評価、小規模、中規模、大規模の各構成について説明します。

11.1.2.1 評価構成

評価の構成は簡易インストール・オプションを選択してインストールする必要があります。インストールは適切な値を使用して構成する必要があります。

最小OMS設定

Oracle Management Service (OMS)のヒープ・サイズを800MBに設定する必要があります。

最小リポジトリ・データベース設定

表11-4に、評価の構成で推奨される最小リポジトリ・データベース設定を示します。

表11-4 評価の構成の最小データベース設定

パラメータ

最小値

プロセス

300

memory_target

700MB

REDOログ・ファイルのサイズ

50MB

shared_pool_size

450MB

session_cached_cursors

remove

11.1.2.2 小規模の構成

小規模の構成は、Oracle Enterprise Managerのインストーラによって要求される最小要件に基づきます。

最小OMS設定

追加設定は不要です。

最小データベース設定

表11-5に、推奨される最小データベース設定を示します。

表11-5 小規模サイトの最小データベース設定

パラメータ

最小値

*sga_targetおよびpga_aggregate_targetのかわりに、3GBのmemory_targetを使用できます。

processes

300

pga_aggregate_target*

1024MB

sga_target*

2GB

REDOログ・ファイルのサイズ

300MB

shared_pool_size

600MB

db_securefile

PERMITTED

11.1.2.3 中規模の構成

中規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。

最小OMS設定

Oracle Management Service (OMS)のヒープ・サイズを4096MBに設定する必要があります。

最小リポジトリ・データベース設定

表11-6に、中規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表11-6 中規模サイトの最小データベース設定

パラメータ

最小値

*sga_targetおよびpga_aggregate_targetのかわりに、5.25GBのmemory_targetを使用できます。

processes

600

pga_aggregate_target*

1280MB

sga_target*

4GB

REDOログ・ファイルのサイズ

600MB

shared_pool_size

600MB

db_securefile

PERMITTED

11.1.2.4 大規模の構成

大規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。

最小OMS設定

表11-7に、大規模の構成で推奨される最小OMS設定を示します。

表11-7 大規模サイトの最小OMS設定

OMS数

ヒープ・サイズの最小値

2

8192MB

4

4096MB

最小リポジトリ・データベース設定

表11-8に、大規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表11-8 大規模サイトの最小データベース設定

パラメータ

最小値

*sga_targetおよびpga_aggregate_targetのかわりに、7.5GBのmemory_targetを使用できます。

processes

1000

pga_aggregate_target*

1536MB

sga_target*

6GB

REDOログ・ファイルのサイズ

1000MB

shared_pool_size

600MB

db_securefile

PERMITTED

11.1.2.5 リポジトリ表領域のサイジング

表11-9は、管理リポジトリに必要な最小記憶域要件を示しています。

表11-9 管理リポジトリ記憶域の合計

デプロイ・サイズ

最小表領域サイズ*

SYSTEM**

MGMT_TABLESPACE

MGMT_ECM_DEPOT_TS

MGMT_AD4J_TS

TEMP

*これらはあくまで最小値であり、大まかな指針を示すのみです。MGMT_TABLESPACEの実際のサイズは、ターゲット・タイプの分布、ユーザー・カスタマイズやその他の要因の違いによって、デプロイメントごとに大きく異なります。これらの表領域は、領域制約の問題が軽減されるよう、デフォルトではAUTOEXTENDがONで定義されています。RAWファイルシステムでは、領域制約の問題を回避できるよう最小サイズより大きい値を使用することをお薦めします。
**SYSTEMおよびTEMPの各表領域のサイズは、Enterprise Managerのみが使用するリポジトリ用の最小値です。Enterprise Managerが他のアプリケーションとリポジトリ・データベースを共有している場合、これらの最小値は小さすぎる場合があります。
注意: 表領域の管理の制御を強化する場合は、TABLESPACE FULLアラートを設定するか、データベースの拡張を許可してAUTOEXTEND機能によるアラートを無効にします。したがって、TABLESPACE FULLアラートの制御を強化するには、自動拡張を無効にします。

小

600MB

50GB

1GB

100MB

10GB

中

600MB

200GB

4GB

200MB

20GB

大

600MB

300GB

4GBよりも大きい

400MB

40GB

11.1.3 追加構成

Enterprise Managerのインストールでは、個々のシステム負荷が大きいと、追加のチューニング設定が必要になる場合があります。追加設定を次に示します。

11.1.3.1 大規模な同時UI負荷

OMSごとに50を超える同時ユーザーが予想される場合は、次の設定を表11-10のとおり修正する必要があります。

表11-10 大規模な同時UI負荷の追加設定

プロセス

パラメータ

値

設定対象

OMS

-Djbo.recyclethreshold

同時ユーザー数/OMS数

OMS別

OMS

-Djbo.ampool.maxavailablesize

同時ユーザー数/OMS数

OMS別

OMS

ヒープ・サイズ

50ユーザー増加するたびに4GB追加

OMS別

データベース

sga_target

50ユーザー増加するたびに1GB追加

インスタンス別

ユーザー負荷が高くなるほど、必要なハードウェア容量が増加します。50同時ユーザーごとに、データベース・ホストとOMSホストの両方に2コアを追加します。

例: エージェント数1500、ターゲット数15,000、同時ユーザー数150のサイトでは、表11-11に示した設定変更が最小限必要です(2 OMSの大規模な構成に基づく)。

表11-11 2 OMS構成の大規模な同時UI負荷の追加設定の例

プロセス

パラメータ

値

計算

OMS

-Djbo.recyclethreshold

75 (OMSごとに設定)

150ユーザー/2 OMS

OMS

-Djbo.ampool.maxavailablesize

75 (OMSごとに設定)

150ユーザー/2 OMS

OMS

ヒープ・サイズ

12GB (OMSごとに設定)

8GB (標準的な大規模設定) + ((150ユーザー - 50大規模なユーザー負荷のデフォルト)/2 OMS)* (4GB/50ユーザー)

データベース

sga_target

8GB

6GB (標準的な大規模設定) + (150ユーザー - 50大規模なユーザー負荷のデフォルト)* (1GB/50ユーザー)

表11-12に、追加ハードウェアの最小要件を示します。

表11-12 2 OMS構成の大規模な同時UI負荷の最小追加ハードウェアの例

層

パラメータ

値

計算

OMS

CPUコア数

24 (すべてのOMSホスト間の合計)

8コア * 2 OMS (大規模なコア数のデフォルト) + (150ユーザー - 50大規模なユーザー負荷のデフォルト) *(2コア * 2 OMS)/50ユーザー)

データベース

CPUコア数

24 (すべてのデータベース・ホスト間の合計)

8コア * 2 OMS (大規模なコア数のデフォルト) + (150ユーザー - 50大規模なユーザー負荷のデフォルト) *(2コア * 2 OMS/50ユーザー)

この構成を実行できるようにするには、各マシンの物理メモリーも増設する必要があります。

パラメータ-Djbo.recyclethreshold、-Djbo.ampool.maxavailablesizeおよびHeap Sizeの値は変更できます。これらの値はデフォルトでは次のように設定されています。

- Djbo.recyclethresholdは50に設定されています。

- Djbo.ampool.maxavailablesizeは50に設定されています。

- Heap Sizeは-Xms1024m -Xmx1740mに設定されています。

次の場所にあるstartEMServer.shファイルでこれらのパラメータの値を設定できます。

gc_inst/user_projects/domains/GCDomain/bin

-Djbo.recyclethresholdおよび-Djbo.ampool.maxavailablesizeパラメータについては、次の最初のセクションを2つ目のセクションに追加できます。

JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.security.egd=file:///dev/./urandom -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugWebAppSecurity=true -Dweblogic.SSL.LoginTimeoutMillis=300000 -Dj
ps.auth.debug=true -Xbootclasspath/p:/u01/EM12/oms/sysman/jlib/diagpatch_bug11725986.jar -Djdkpatchlog=/u01/EM12/oms/sysman/log/diagpatch_bug11725986.log -Doracle.apm.home=/u01/EM12/oms/apm/ -DAPM_
HELP_FILENAME=oesohwconfig.xml -Djava.util.logging.config.file=/tmp/logging.txt"

JAVA_OPTIONS="${JAVA_OPTIONS} -Djbo.recyclethreshold=100 -Djbo.ampool.maxavailablesize=5 -Djava.security.egd=file:///dev/./urandom -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugWebAppSecurity=true -Dweblogic.SSL.LoginTimeoutMillis=300000 -Djps.auth.debug=true -Xbootclasspath/p:/u01/EM12/oms/sysman/jlib/diagpatch_bug11725986.jar -Djdkpatchlog=/u01/EM12/oms/sysman/log/diagpatch_bug11725986.log -Doracle.apm.home=/u01/EM12/oms/apm/ -DAPM_HELP_FILENAME=oesohwconfig.xml -Djava.util.logging.config.file=/tmp/logging.txt"

リリース12.1.0.3以降の場合、第11.1.3.5項のChanging Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold (JAVA_EM_ARGS)のポイントを参照してください。

同じファイルで、次のセクションのヒープ・サイズ設定を変更できます。

USER_MEM_ARGS="-Xms1024m -Xmx1740m -XX:MaxPermSize=1024M -XX:-DoEscapeAnalysis -XX:+UseCodeCacheFlushing -XX:CompileThreshold=8000 -XX:PermSize=128m"

注意:
Xms値を変更することはお薦めしません。

11.1.3.2 大規模なジョブ・システム負荷

ジョブ・システムに長期間バックログがある場合、またはバックログを速く処理する場合、次のパラメータにemctl set propertyコマンドを設定できます。

表11-13 大規模なジョブ・システムのバックログ設定

パラメータ

値

oracle.sysman.core.jobs.shortPoolSize

50

oracle.sysman.core.jobs.longPoolSize

24

oracle.sysman.core.jobs.longSystemPoolSize

20

oracle.sysman.core.jobs.systemPoolSize

50

oracle.sysman.core.conn.maxConnForJobWorkers

144*

*この設定はOMSサーバーの144のデータベースに設定するプロセスの増加が必要な場合があります。

これらの設定は、より多くの負荷をサポートできる十分なデータベース・リソースがあることを前提としています。これらのパラメータは2 OMSノードのある大規模な構成で必要となる場合があります。

11.1.3.3 大規模なリポジトリ側の可用性負荷(リリース12.1.0.3以上)

多くのターゲットにはEnterprise Manager (サービス、クラスタなど)のリポジトリ側の可用性があります。デフォルトでは、Enterprise Mangerはこれらの可用性を2つのプロセスを使用して計算します。ほとんどのインストールでは、これで十分です。可能性の計算に平均2分以上要する場合、さらにプロセスを追加できます。この計算のパフォーマンスを追跡するには、次のSQL文を実行する必要があります。

select status, actual_start_date, run_duration
from dba_scheduler_job_run_details
where owner='SYSMAN'
and job_name='EM_REPOS_SEV_EVAL'
and job_subname IS NULL
and actual_start_date > sysdate-1/24
order by actual_start_date;

これは、過去1時間のジョブの実行時間を追跡します。データベースに十分な空きリソースがあり、計算が常に2分以上要する場合、SYSMANとして次のコマンドを実行して、さらにプロセスを追加できます。

begin
em_severity_repos.set_parallel_parametrization(1, <total number of processes>); commit;
end;
/

この変更は動的で、次のジョブの反復では新しいプロセス数を使用します。現在の設定を決定するには、次のSQL文を実行します。

select parameter_value from em_sysavail_parameters  where parameter_name = 'NUM_CHUNKS'

プロセスの総数は計算に要する時間が平均で2分未満となるまで、1つずつ増加します。プロセスの増加ごとに、リポジトリのリソース使用量は次の増加の前に再評価されます。

11.1.3.4 多数のエージェント(リリース12.1.0.3)

Enterprise Managerデフォルトの即時使用可能な設定には、OMSごとに2つのpingレコーダ・スレッドがあります。この設定はOMSごとに2000のエージェントを処理できます。サイトがOMSes * 2000以上のエージェントを処理する必要がある場合や、スレッドCPUパフォーマンスごとのデータベースが遅い場合は、OMSごとのpingレコーダ・スレッドを増やすことができます。次のパラメータが使用できます。

oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads

この値はデフォルトでOMSごとに2となっています。内部テストで、適切に調整された状況下においては、1000エージェントごとに1つのpingスレッドで十分であることが示されています。新しい値を使用するには、各OMSを再起動する必要があります。

11.1.3.5 OMSプロパティの変更

次の項では、この章でお薦めするOMS設定の変更例を説明します。たとえばジョブ・バックログ増加時に、OMSプロパティ設定の変更が必要となる可能性があります。例で示す値は、使用している構成に適した値に置き換える必要があります。次の手順に従って、OMSプロパティを変更します。

ヒープ・サイズの変更

Memory Argsの次のプロパティ名の値は、デフォルト値を上書きするために設定できます。

OMS_HEAP_MIN
OMS_HEAP_MAX
OMS_PERMGEN_MIN
OMS_PERMGEN_MAX

次の表に、これらのパラメータとその説明、デフォルト値、使用時の推奨事項、注意事項、警告または既知の問題を示します。

名前

説明

デフォルト

推奨事項

注意、警告または問題

OMS_HEAP_MIN (-Xms)

–Xmsの変更は実際は必要ありません。インストール後のデフォルト値のままにする必要があります。大規模な設定が時間の経過とともに非常に大きくなった場合、ユーザーやシステム管理者は、–Xmxの値を増やすタイミングでこの値を増やす場合があります。

32/64ビット:
小規模: 256M

中規模: 256M

大規模: 256M

IBM JVMの場合、appサイズにかかわらず、次の設定を使用します。

32ビット: 1024M

64ビット: 1740M

「デフォルト」の項と同じ。
これらはインストール後のデフォルト値であるため、推奨される設定です。

該当なし

OMS_HEAP_MAX (-Xmx)

ターゲットはEnterprise Managerの初回インストール/設定後に追加されるため、古い世代で予期しないメモリー不足エラーが発生しないように、HEAPサイズを増やすことをお薦めします。

32ビット:
小/中/大規模: 1524M

64ビット:

小規模: 1740M

中規模: 4096M

大規模: 8192M

IBM JVMの場合、appサイズにかかわらず、ヒープの最大値はありません。

「デフォルト」の項と同じ。
これらはインストール後のデフォルト値であるため、推奨される設定です。

常にメモリーの使用量が多かったために一定の期間でスループットが低下した場合は、これらのすべてのパラメータを変更する必要があります。パラメータを操作しているユーザー(sysadminを推奨)は、制限事項/警告を把握しておく必要があります。

OMS_PERMGEN_MIN (-XX:PermSize)

–XXの変更: PermSizeは必須ではありません。インストール後のデフォルト値のままにする必要があります。

32/64ビット:
小規模: 128M

中規模: 128M

大規模: 128M

IBM JVMの場合、appサイズにかかわらず、次の設定を使用します。

32ビット: 128M

64ビット: 128M

「デフォルト」の項と同じ。
これらはインストール後のデフォルト値であるため、推奨される設定です。

該当なし

OMS_PERMGEN_MAX (-XX:MaxPermSize)

大規模構成では、OMSコンテナでのアクティビティが多すぎると、多数のクラスローダーおよび&rsquor;Class'オブジェクトが作成され、PermGenが一杯になり、その結果メモリー不足エラーが発生します。

32ビット:
小/中/大規模: 612M

64ビット:

小規模: 612M

中規模: 768M

大規模: 768M

IBM JVMの場合、appサイズにかかわらず、次の設定を使用します。

32ビット: 612M

64ビット: 612M

「デフォルト」の項と同じ。
これらはインストール後のデフォルト値であるため、推奨される設定です。

該当なし

次のコマンドを使用して、これらのプロパティの値を設定します。

emctl set property –name <property_name> -value <number_followed_by_G_or_M>

次に例を示します。

emctl set property –name OMS_PERMGEN_MAX –value 1024M

次のコマンドを使用して、プロパティ名を取得します。

emctl get property –name <property_name>

JBO Argsの次のプロパティ名の値は、デフォルト値を上書きするために設定できます。

- JBO_MIN_POOL_SIZE - この制限を超えると、アクティブでない時間がjbo.ampool.maxinactiveageの値を超えるアプリケーション・モジュールはアプリケーション・プールでタイムアウトします。

- JBO_POOL_TTL - アプリケーション・モジュール・インスタンスが存続するアプリケーション・モジュール・プールの時間を指定します。

- JBO_LAZY_LOAD - コンポーネントの遅延ロードの有無を指定します。

- JBO_MAX_CURSORS - ビジネス・コンポーネントで開くことのできるカーソルの最大数です。カーソル数がこの数値に近づくと、フレームワークでは空のJDBC文がクリーンアップされます。

- JBO_RECYC_THRESHOLD - アプリケーション・モジュール・プールで使用されるリサイクルしきい値。

- JBO_MAX_POOL_SIZE - この制限を超えると、jbo.ampool.maxinactiveageの値に達していなくても、アクティブでない時間の最も長いアプリケーション・モジュールがアプリケーション・プールでタイムアウトします。

次のコマンドを使用して、これらのプロパティの値を設定します。

emctl set property –name <property_name> -value <property_value>

次に例を示します。

emctl set property –name JBO_MAX_POOL_SIZE –value 5

次のコマンドを使用して、プロパティ名を取得します。

emctl get property –name <property_name>

プロパティ値の変更後、各OMSで次のコマンドを使用してOMSを再起動する必要があります。

emctl stop oms -all
emctl start oms

shortPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.shortPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.shortPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name ”oracle.sysman.core.jobs.shortPoolSize”

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name ”oracle.sysman.core.jobs.shortPoolSize”

プロパティ値の変更後、各OMSで&rsquor;emctl stop oms -all; emctl start oms'を使用してOMSおよびノード・マネージャを再起動する必要があります。デフォルト値は25です。

longPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.longPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.longPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name ”oracle.sysman.core.jobs.longPoolSize”

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name ”oracle.sysman.core.jobs.longPoolSize”

プロパティ値の変更後、各OMSで&rsquor;emctl stop oms; emctl start oms'を使用してOMSを再起動する必要があります。デフォルト値は12です。

longSystemPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.longSystemPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.longSystemPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name ”oracle.sysman.core.jobs.longSystemPoolSize”

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name ”oracle.sysman.core.jobs.longSystemPoolSize”

プロパティ値の変更後、各OMSで&rsquor;emctl stop oms; emctl start oms'を使用してOMSを再起動する必要があります。デフォルト値は10です。

systemPoolSizeの変更

OMSプロパティ(oracle.sysman.core.jobs.systemPoolSize)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.jobs.systemPoolSize -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name ”oracle.sysman.core.jobs.systemPoolSize”

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name ”oracle.sysman.core.jobs.systemPoolSize”

プロパティ値の変更後、各OMSで&rsquor;emctl stop oms; emctl start oms'を使用してOMSを再起動する必要があります。デフォルト値は25です。

maxConnForJobWorkersの変更

OMSプロパティ(oracle.sysman.core.conn.maxConnForJobWorkers)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name oracle.sysman.core.conn.maxConnForJobWorkers -value 200

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name ”oracle.sysman.core.conn.maxConnForJobWorkers”

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name ”oracle.sysman.core.conn.maxConnForJobWorkers”

プロパティ値の変更後、各OMSで&rsquor;emctl stop oms; emctl start oms'を使用してOMSを再起動する必要があります。デフォルト値は25です。

Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold (JAVA_EM_ARGS)の変更

OMSプロパティ(Djbo.ampool.maxavailablesizeおよびDjbo.recyclethreshold)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

$ emctl set property -name JAVA_EM_ARGS -value "-Djbo.ampool.maxavailablesize=500 -Djbo.recyclethreshold=500"

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

$ emctl get property -name "JAVA_EM_ARGS"

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

$ emctl delete property -name "JAVA_EM_ARGS"

プロパティ値の変更後、各OMSで&rsquor;emctl stop oms -all; emctl start oms'を使用してOMSを再起動する必要があります。

omsAgentComm.ping.heartbeatPingRecorderThreadsの変更

OMSプロパティ(oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads)を変更するには、次の推奨事項に従います。

プロパティを設定するには、次のコマンドを入力してください。

emctl set property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads -value 5

デフォルトからの変更後、プロパティを取得するには次のコマンドを入力してください。

emctl get property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads

元の設定に戻すためにプロパティを削除するには、次のコマンドを入力してください。

emctl delete property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads

プロパティ値の変更後、各OMSで&rsquor;emctl stop oms; emctl start oms'を使用してOMSを再起動する必要があります。

11.1.3.6 データベース設定の変更

事前構成済のリポジトリ用にデータベース・テンプレートをダウンロードしている場合、適切なSQLスクリプトを実行してデータベース・パラメータを推奨設定に調整できます。次の表に実行する必要のあるスクリプトを示します。

サイズ

スクリプト

小

set_repo_param_11.2.0.3_Database_SQL_for_EM12_1_0_4_Small_deployment.sql

中

set_repo_param_11.2.0.3_Database_SQL_for_EM12_1_0_4_Medium_deployment.sql

大

set_repo_param_11.2.0.3_Database_SQL_for_EM12_1_0_4_Large_deployment.sql

前述のスクリプトがMEMORY_TARGET/ SGA_TARGET/ PGA_AGGREGATE_TARGETを調整しないようにするために、これらのパラメータは手動で変更する必要があります。

11.1.3.7 BI Publisherの構成

インストールしたBI Publisher(11.1.1.7.0)とEnterprise Managerリリース12c Cloud Controlの構成を予定している場合、前述のホストのメモリー要件に1.5GBを加えてください。

11.2 Enterprise Manager Cloud Controlのパフォーマンス最適化の方法

拡大/縮小時に容量を正確に予測するために必要なのは、各Enterprise Manager Cloud Controlデプロイメントからの実際のメトリック傾向情報です。この情報と大まかな初期ホスト・システム・サイズの設定、チューニングとメンテナンスの繰返しの実行を組み合せることが、Enterprise Manager Cloud Controlデプロイメントの容量を予測する最も効果的な方法になります。また、デプロイメントのパフォーマンスを最適に保つことにも役立ちます。

Enterprise Manager Cloud Controlのサイジング手法の実施手順は、次のとおりです。

1. まだEnterprise Manager Cloud Controlをインストールしていない場合は、表11-1に示すように、大まかな初期ホスト構成を選択します。

2. 定期的にサイトのバイタル・サインを評価します(後述)。

3. DBAおよびEnterprise Manager管理のルーチン・ハウスキーピングを使用してボトルネックを排除します。

4. チューニングを使用してボトルネックを排除します。

5. 今後に向けた直線外挿を行うことにより、将来のサイジング要件を計画します。

手順1は、各デプロイにつき1回行うのみで済みます。手順2、3および4は、Enterprise Manager Cloud Controlサイトを拡大する計画があるかどうかにかかわらず、デプロイが存続しているかぎり定期的に行う必要があります。これらの手順は、Enterprise Manager Cloud Controlサイトのサイズや処理負荷にかかわらず、効率的なEnterprise Manager Cloud Controlサイトにとって不可欠です。手順5に進むには、手順2、3および4を完了しておく必要があります。これは非常に重要です。手順5が必要となるのは、監視対象ターゲットの数を増やしてデプロイ・サイズを拡大しようとする場合のみです。ただし、これらの傾向を定期的に評価することは、デプロイに行われた他の変更を評価するうえでも役立ちます。

11.2.1 手順1: 最初のプラットフォームのCloud Controlデプロイの選択

最初のプラットフォームのCloud Controlデプロイの選択については、第11.1.1項「サイジング・ガイドラインの概要」を参照してください。

11.2.2 手順2: サイトのバイタル・サインの定期的な評価

これが、5つの中で最も重要な手順です。Enterprise Manager Cloud Controlサイトのバイタル・サインの傾向や大きな変動をある程度監視および理解しておかないと、サイトのパフォーマンスが重大なリスクに晒されることになります。監視対象ターゲットはそれぞれ、関連付けられた管理エージェントを介して、ロードおよび集計のためにデータを管理リポジトリに送信します。これは、他のエンタープライズ・アプリケーションと同レベルの管理およびメンテナンスを必要とする大量のアクティビティになります。

Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。パフォーマンスが許容可能なときのバイタル・サインの現実的なベースラインを設定する必要があります。ベースラインを設定した後は、Oracle Enterprise Manager Cloud Controlの組込み機能を使用して、警告およびクリティカルのしきい値を設定できます。これにより、Enterprise Managerサイトに重大な変更があった場合は自動的に通知されます。次の表に、2つのサイトにおけるEnterprise Manager Cloud Controlのバイタル・サインのポイント・イン・タイム・スナップショットを示します。

モジュール

メトリック

EMサイト1

EMサイト2

サイト

emsite1

emsite2

ターゲットの数

データベース・ターゲット

192(45は起動されていない)

1218(634は起動されていない)

ホスト・ターゲット

833(12は起動されていない)

1042(236は起動されていない)

ターゲット合計

2580(306は起動されていない)

12293(6668は起動されていない)

全体的ステータス

過去10分間の全体的バックオフ・リクエスト

0

500

ジョブ統計

現在のジョブ・ステップbacklogJobをクリアする推定時間

0.1

7804

イベント統計

保留中のイベント数

2

4000

管理サービス・ホスト統計

平均のCPU割合(ホスト1)

9(emhost01)

13(emhost01)

平均のCPU割合(ホスト2)

6(emhost02)

17(emhost02)

平均のCPU割合(ホスト3)

該当なし

38(em6003)

平均のCPU割合(ホスト4)

該当なし

12(em6004)

ホスト当たりのコア数

2 X 2.8(Xeon)

4 X 2.4(Xeon)

ホスト当たりのメモリー(GB)

8

8

管理リポジトリ・ホスト統計

平均のCPU割合(ホスト1)

12(db01rac)

64 (em6001rac)

平均のCPU割合(ホスト2)

14 (db02rac)

78 (em6002rac)

ホスト当たりのCPUコア数

4

8

メモリー・ターゲット(GB)

5.25

7.5

ホスト当たりのメモリー(GB)

8

16

管理リポジトリ・サイズの合計(GB)

56

98

Oracle RACインターコネクト・トラフィック(MB/秒)

1

4

管理サーバー・トラフィック(MB/秒)

4

4

管理リポジトリI/Oの合計(MB/秒)

6

27

1秒当たりのEnterprise Manager UIページのレスポンス

ホームページ

3

6

すべてのホスト・ページ

3

30+

すべてのデータベース・ページ

6

30+

データベースのホームページ

2

2

ホストのホームページ

2

2

この2つのEnterprise Managerサイトのパフォーマンスは対極的です。

EMサイト1は、バックオフ・リクエストがほとんどなく、極めて正常に動作しています。また、ジョブおよびイベントのバックログが極めて低くなっています。OMSホストと管理リポジトリ・サーバー・ホストのCPU使用率は両方とも低い値です。最も重要なのは、UIページのレスポンス時間が非常に優れていることです。つまり、サイト1では最小限の労力で多くの処理が行われています。構成、チューニングおよびメンテナンスが適切に行われたOracle Enterprise Manager Cloud Controlサイトは、このような状態になります。

これに対し、EMサイト2には問題があります。このサイトには、かなりの量のバックオフがあり、ジョブおよびイベントのバックログも相当あります。最も大きな問題は、ユーザー・インタフェース・ページのレスポンス時間です。サイト2にボトルネックが存在するのは明らかです。複数のボトルネックがある可能性があります。

これらのバイタル・サインはすべて、Enterprise Managerインタフェースから取得できます。ほとんどの値は各ホストの「すべてのメトリック」ページまたはOMSの「すべてのメトリック」ページに表示されます。警告およびクリティカルのアラートにしきい値を割り当て、これらのバイタル・サインの傾向を一定期間観察することで、良好なパフォーマンスを維持し、将来のリソース要件を予測できます。次のようにして、これらのバイタル・サインの監視を計画してください。

- 前出の表に示された、Enterprise Manager Cloud Controlサイトが良好に動作しているときのバイタル・サイン値のベースラインを測定します。

- これらのベースライン値に基づいて妥当なしきい値および通知を設定し、正常な値から大きく逸脱した場合には自動的に通知されるようにします。このとき、サイトのしきい値を何度か繰返して微調整する必要があることがあります。受け取る通知が多すぎても役に立ちません。

- 1日(最低でも1週間)に1回、グラフで7日間にわたるこれらの値の傾向を監視します。これにより、近い将来に起こりうる問題を発見し、将来のリソース要件の計画を立てることができます。

次の手順で、バイタル・サインの値が設定済しきい値の範囲にない場合に行う操作を示します。また、ルーチン・ハウスキーピングを通してサイトのパフォーマンスを維持する方法についても説明します。

11.2.3 手順3: DBAおよびEnterprise Managerタスクを使用したボトルネックの排除

Enterprise Manager Cloud Controlサイトの動作を良好に保つために、ルーチン・ハウスキーピングが役立つことを覚えておくことが重要です。次に、ハウスキーピングのタスクとその適切な実行間隔を示します。

11.2.3.1 月に1回のオフライン・タスク

Enterprise Manager管理者は、Enterprise Managerリポジトリのセグメントの状態に関する推奨事項として、データベース内蔵のセグメント・アドバイザを監視する必要があります。セグメント・アドバイザは、どのセグメントを再構築/再編成する必要があるかを管理者に知らせ、その実行のためのコマンドを提供します。

セグメント・アドバイザと、システム状態に関連する問題の詳細は、My Oracle Supportナレッジ・ベースのノート242736.1および314112.1を参照してください。

11.2.4 手順4: チューニングによるボトルネックの排除

Enterprise Manager Cloud Controlアプリケーションのパフォーマンスのボトルネックの代表的な原因を次に(頻度の高い順に)示します。

1. ハウスキーピングを実行していない(パフォーマンス問題の最大の原因)

2. ハードウェアまたはソフトウェアが適切に構成されていない

3. ハードウェア・リソースの枯渇

バイタル・サインが日常的に設定済しきい値の範囲外にある場合、または一定期間そのような傾向を示している場合は、2つの領域に対処する必要があります。まず、前述したすべてのハウスキーピングが最近行われていることを確認します。2番目に、Enterprise Manager Cloud Controlアプリケーションのリソース使用率に注意する必要があります。前出の表に列記したバイタル・サインは、Enterprise Manager Cloud Controlのリソース使用率およびスループットのキー・ポイントを反映しています。次の各項で、重要なバイタル・サインのいくつかを説明し、ベースライン値に基づいて設定されたしきい値を超えたバイタル・サインに対処するために使用可能なオプションを示します。

11.2.4.1 高いCPU使用率

サイトのパフォーマンスを評価するように求められ、高いCPU使用率に気づいた場合、どのリソースがどの場所で使用されているかを判断するために、いくつか手順を実行する必要があります。

1. Enterprise Managerホストのホームページの「プロセス」画面を使用して、CPUのしきい値を超えた管理サービス・ホストまたは管理リポジトリ・ホストで最も多くのCPUを消費しているプロセスを判別します。

2. Enterprise Managerが最も多くのCPUを消費していることが明確になった場合は、Enterprise Managerを使用して、最も多くのCPUを消費しているアクティビティを特定します。これは通常、管理サービスの処理のほとんどが実行される管理リポジトリ・ホスト上に存在します。管理リポジトリが過剰にリソースを使用していると考えられる場合、一般的に次の点を調べる必要があります。

1. 管理リポジトリの「データベース・パフォーマンス」ページにリストされた「使用中のCPU」データベース・リソースをクリックして、管理リポジトリで最も多くCPUを使用しているSQLを調べます。

2. 管理リポジトリの「データベース・パフォーマンス」ページの「データベース・ロック」で、競合問題がないか確認します。

3. 管理リポジトリのデータベース上のSQL監視に、リソースを消費するSQLがないか確認します。

パフォーマンスのボトルネックの兆候として最も多いのは、高いCPU使用率です。通常は、管理リポジトリが最も多くCPUを消費しており、管理リポジトリを重点的に調べる必要があります。ハードウェア・リソースの制約が特になく、適切に構成およびメンテナンスが行われた管理リポジトリ・ホスト・システムの場合、CPU使用率の合計は平均して約40%以下になります。OMSホスト・システムのCPU使用率の合計は、平均して約20%以下である必要があります。平均値がこのように比較的低い場合は、アクティビティの急な増加にも十分に対応できます。アクティビティの急な増加を許容することで、ページ・パフォーマンスを長期間にわたって安定させることができます。Enterprise Manager Cloud Controlサイトのインタフェース・ページのレスポンスが良好(約3秒)で、大きなバックログが存在しない場合、CPUの使用率が推奨値を超えていても、大幅な上昇傾向にあると考えられる場合を除き、対処する必要はありません。

管理リポジトリのCPU使用率が高い場合、その根本的な原因を確認するために、前述の手順3.bおよび手順3.cを行うことをお薦めします。これにより、管理リポジトリの「パフォーマンス」ページから、処理で最も多くCPUを消費しているSQLを確認することができます。この方法は、いくつかの実際のサイトで使用され、成功しています。

Intelベースのホスト上でEnterprise Managerを実行している場合は、Enterprise Manager Cloud Control管理サービスと管理リポジトリの両方が、デプロイ先のホスト上で有効になっているハイパースレッディング(HT)のメリットを得られます。HTはIntelプロセッサの特定の最新モデルの機能であり、一定量のCPU命令のパラレルな実行を可能にするものです。これによって、システム上で物理的に使用可能なCPUの数は倍増します。HTを使用した場合、HTが使用可能になっていない同じシステムに比べて、CPU処理能力が約1.5倍になることがテストで実証されています。これにより、大幅にシステム・パフォーマンスを向上させることができます。管理サービスと管理リポジトリはどちらも複数のプロセスを同時に実行することが多いため、HTを使用するメリットは非常に大きくなります。

11.2.4.2 ローダーのバイタル・サイン

ローダーのバイタル・サインは、すべてのEnterprise Managerエージェントからシステムに絶えず送り込まれるデータの正確な量を示します。ここで最も重要な項目は、「過去1時間に返信されたエージェント数」メトリックです。このメトリックは、各管理サービスの「すべてのメトリック」ページにあります。これは過去1時間にデータのロードを遅延するように指示されたエージェントの数です。ロードの遅延を指示されるエージェントがないことが理想ですが、ある程度の遅延ロードは正常です。この値がデプロイされたエージェント数の2パーセントを超え、増え続ける場合には、対処する必要があります。

ローダー・スレッドの数はデフォルトで常にOMSごとに20に設定されます。OMSにローダー・スレッドを追加すると、全体のホストCPU使用率が高くなります。この値は、サイトの必要性に応じて変更できます。

リポジトリに使用可能なリソースが十分にない場合、ローダー・スレッドを追加すると収穫逓減が起こります。ローダー・スレッドの追加時に、使用可能なリポジトリ・リソースがある場合には、「過去1時間に返信されたエージェント数」メトリックが減ります。改善が見られない場合には、他のチューニングまたはハウスキーピングの機会を探る必要があります。

ローダー・スレッドをさらに追加するには、次の構成パラメータを変更できます。

oracle.sysman.core.gcloader.max_recv_thread

デフォルト値は20です。これはOMSごとの設定です。

「エンタープライズ」メニューから、「レポート」を選択した後、「情報パブリッシャ・レポート」を選択すると、「ローダー」レポートにアクセスできます。レポートのタイトルは「ローダー統計」です。レポート名をクリックすると、Enterprise Managerは、ローダーのパフォーマンスの詳細を表示する事前定義済のレポートを実行します。

11.2.4.3 ロールアップのバイタル・サイン

ロールアップ・プロセスは、Enterprise Manager Cloud Controlの集計メカニズムです。ロールアップの2つのバイタル・サインは、行/秒と実行時間の割合です。ロールアップでは大量のデータ行が処理されるため、管理リポジトリのバッファ・キャッシュ領域を最も多く消費する傾向があります。このため、ロールアップのバイタル・サインを調べることで、バッファ・キャッシュ・サイズの拡大により効果が得られるかどうかを判断できます。

ロールアップの行/秒は、1秒間に処理または集計されて格納された行の正確な数を示します。バッファ・キャッシュのサイズが適切で、I/Oの速度も妥当なサイトでは、通常この値は1秒当たり約2,000行(+/- 500)です。この値が一定期間下降傾向を示している場合、将来的に問題が発生する可能性がありますが、実行時間の割合が100未満であれば、そのサイトは問題ないと考えられます。

ロールアップの実行時間の割合が上昇傾向にある(またはベースラインを超えている)場合、管理リポジトリのバッファ・キャッシュをまだ最大値に設定していなければ、バッファ・キャッシュ設定値を大きくすると効果があることがあります。通常は、バッファ・キャッシュを大きくするメリットがある場合には、管理リポジトリ・ホストのリソース使用率およびスループットが全体的に向上します。ローダー統計は多少改善されます。ホストのCPU使用率は低下し、I/Oは減少します。改善が最も顕著なのは、ロールアップ統計です。ロールアップの行/秒と実行時間の割合の両方で明らかな改善が見られます。これらのバイタル・サインのいずれにも改善が見られない場合、バッファ・キャッシュを以前のサイズに戻してもかまいません。古いバッファ・キャッシュ・ヒット率は、誤解を招く場合があります。バッファ・キャッシュが非常に小さいためにEnterprise Manager Cloud Controlのパフォーマンスが低下している場合に、バッファ・キャッシュ・ヒット率の値が高くなることがテストで観察されています。バッファ・キャッシュを大きくしてもCloud Controlのパフォーマンスが改善されない場合もあります。通常、これはアプリケーションの他の場所でリソース制約や競合があるためです。「高いCPU使用率」の項に示された手順を使用して、競合の場所を特定することを検討してください。また、Cloud Controlでは、データベース自体からバッファ・キャッシュのサイズ設定に関するアドバイスを提供します。これは、データベースの「メモリー・パラメータ」ページで使用可能です。

バッファ・キャッシュの拡大を検討する際には、オペレーティング・システムにEnterprise Manager Cloud Controlのパフォーマンスの改善に役立つメカニズムが存在する可能性があることに注意してください。たとえば、Red Hat Linuxで使用可能なlarge memoryオプションがその一例です。Linux OS Red Hat Advanced Server(tm) 2.1(RHAS)には、big pagesという機能があります。RHAS 2.1では、bigpagesは大きな共有メモリー・セグメントの事前割当てに使用できる起動パラメータです。この機能を大きな管理リポジトリSGAとあわせて使用することで、Cloud Controlアプリケーション全体のパフォーマンスを大幅に向上させることができます。Red Hat Enterprise Linux(tm) 3からは、big pages機能はhuge pagesと呼ばれる新機能にかわり、起動パラメータは必要なくなりました。

11.2.4.4 ロールアップ・プロセス

ロールアップ・プロセスには、ロールアップ参加インスタンスという概念が導入されています。ロールアップ処理は、すべての参加インスタンス間で分散されます。参加するEMROLLUPグループに候補インスタンスを追加するには、パラメータinstance_groupsをインスタンス・レベルで次のように設定する必要があります。

- ノード1の場合、instance_groupパラメータにEMROLLUP_1を追加します。
ノード2の場合、instance_groupパラメータにEMROLLUP_2を追加します。

- PQおよびPWパラレル処理モードを導入しています。

- PQはパラレル問合せ/パラレルdmlモードです。このモードでは、各参加インスタンスに、指定された並列度を利用する1つのワーカーが設定されています。

- PWはパラレル・ワーカー・モードです。このモードでは、各参加インスタンスに、指定されたパラレル・レベルに等しい数のワーカー・ジョブがあります。

- すべての参加Oracle RACインスタンスのワークロードを次のように分散します。

- 各参加インスタンスには、同じ数のターゲットが割り当てられます。参加インスタンス数が(n)でワークロードの合計が(tl)の場合、各インスタンスには(tl/n)が割り当てられます。

- 参加インスタンスの各ワーカーには、該当インスタンスのワークロードの同じ数のターゲットが割り当てられます。インスタンス当たりのターゲット数が(il)でワーカー数が(w)の場合、各ワーカーには(il/w)が割り当てられます。

- 負荷はワーカーごとにバッチに分割され、ロールアップSQLの実行回数を制御します。バッチ当たりの行数は、ワーカーに割り当てられた行の総数をバッチ回数で除算したものになります。

ロールアップ処理時のガイドラインとして次の推奨事項を使用します。

- パラレル・ワーカー(PW)・モードを使用し、参加するEMROLLUP_xxインスタンス・グループを利用します。

- パラレル・ワーカー・モードの使用をお薦めします。

- より多くのワーカー間で作業を分割すると、収穫逓減ルールが適用されるまでパフォーマンスとスケーラビリティが向上します。これは、各Oracle RACモードで使用可能なCPUの数によって異なります。このテスト・ケースでは、レスポンス時間、マシンのCPUとIO使用率との兼合いから、10のワーカーによる実行が最適な構成でした。

- 適切なバッチ・サイズを設定することが重要です(推奨は10)。メインSQL (EMD_1HOUR_ROLLUPと呼ばれる)の実行回数と各実行に必要なソート領域との兼合いから、バッチ回数10回が最適な実行でした。

- バッチ回数を10に設定して開始してください。バッチ回数はデータ分散に基づいて変更できます。

前述の推奨事項によって次の結果が得られます。(前述の再設計されたコードで)マルチインスタンス・パラレル・ワーカー(8 PW)・モードを使用すると、2つの参加Oracle RACインスタンスの利用時にパフォーマンスは9から13倍改善されます。

MGMT_METRICS_1HOURのロールアップ行数(百万単位)

時間(分)

ワーカー

バッチ・サイズ

29.5

30

8

1

9.4

5

8

10

** テスト全体では、15779の明確なTARGET_GUIDがありました。
**テストによって、MGMT_METRICS_1HOURで“29.5百万”の新しいロールアップ行が生成されました。

実行**

行/ワーカー

バッチ/ワーカー

行/バッチ

時間(分)

8PW/1インスタンス

3945

3945

1

40

8PW/2インスタンス

1973

1973

1

30

11.2.4.5 ジョブ、通知およびアラートのバイタル・サイン

ジョブ、通知およびアラートは、Enterprise Manager Cloud Controlサイトの管理サービスの処理効率を示します。これらの値がよくない傾向を示している場合、通常はアプリケーションの他の場所に競合があります。これらの値の有効な使用方法は、複数のOMSを使用して実行した場合のメリットを測定することです。各OMSにはジョブ・ディスパッチャが1つずつあります。OMSインスタンスを追加しても、必ずしもこれらの値が改善されるわけではありません。一般に、アプリケーションにリソース競合問題が存在していなければ、OMSインスタンスを追加することでCloud Controlの全体のスループットが改善します。その改善の程度を測定するには、ジョブ、通知およびアラートのバイタル・サインが役立ちます。

11.2.4.6 I/Oのバイタル・サイン

Enterprise Manager Cloud Controlデプロイにおける様々なチャネルのI/Oスループットを監視することは、良好なパフォーマンスを実現するうえで不可欠です。少なくとも次の3つの異なるI/Oチャネルに対して、ベースラインおよびアラートのしきい値を定義する必要があります。

- 管理リポジトリ・インスタンスからそのデータファイルへのディスクI/O

- OMSと管理リポジトリの間のネットワークI/O

- Oracle RACインターコネクト(ネットワーク) I/O (Oracle RACシステムの場合のみ)

これらのチャネルそれぞれについて、最大スループットおよび持続的スループットI/O機能を理解しておく必要があります。この情報および設定したベースライン値から、Cloud Controlで警告およびクリティカルのアラートの妥当なしきい値を導き出すことができます。しきい値を設定した後は、サイトでこれらのしきい値に近づいた場合に、自動的に通知されます。Cloud Controlのサイト管理者でも、サイトでこれらのI/Oチャネルが処理できる内容を知らなかったり、誤解していることがあります。このような場合、Enterprise Manager Cloud Controlがこれらのチャネルに過度な処理をさせることになり、それによってサイトのパフォーマンスは低下します。このような状況では、多くのバイタル・サインがその影響でよくない値を示します。

管理リポジトリが関連しているかどうかを調べるには、Cloud Controlを使用して「データベース・パフォーマンス」ページを確認します。管理リポジトリの「パフォーマンス」ページで、最大消費時間を示す待機グラフをクリックします。このグラフから、実際に待機しているSQLコードまたはセッションにドリルダウンできます。これは、ボトルネックの原因となっている箇所を理解するために役立ちます。

確認するもう1つの領域は、バックアップや別のアプリケーション、複雑なSQL問合せや複数のデカルト積などを使用してデータ・マイニングをしている社員がいる場合など、Enterprise Manager Cloud Control以外のソースからの予期しないI/Oロードです。

リポジトリI/Oの合計に関連する問題は、2つの要因により発生します。1つ目は、定期的にハウスキーピングが行われていないことです。Cloud Controlセグメントの一部が過度に断片化されるため、深刻なI/Oドレインが発生することがあります。2つ目に、適切にチューニングされていないSQL文がサイトのI/O帯域幅の大部分を消費している可能性もあります。Cloud Controlの多くのバイタル・サインの急な悪化は、ほとんどがこの2つの主要な問題によって起こります。また、ハウスキーピングが適切に行われていないために、管理リポジトリの割当てサイズが大幅に増加することもあります。

これを活用した重要な機能の1つが、非同期I/Oです。非同期I/Oを有効化すると、Cloud Controlアプリケーションの全体のパフォーマンスが大幅に向上する可能性があります。Sun Solaris(tm)およびLinuxオペレーティング・システムにはこの機能が搭載されていますが、デフォルトでは無効になっていることがあります。Microsoft Windows(tm)オペレーティング・システムでは、デフォルトで非同期I/Oが使用されます。管理リポジトリ・ホストおよび管理サービス・ホストに対して、このオペレーティング・システム機能を有効化しておくことをお薦めします。

Enterprise Manager Cloud Controlリポジトリ・データベースのストレージには、自動ストレージ管理(ASM)をお薦めします。

11.2.4.7 Oracle Enterprise Managerの「パフォーマンス」ページ

他のパフォーマンス低下はないが、Enterprise Managerのユーザー・インタフェース・ページが遅いことがあります。ページの遅れの一般的な原因は、Enterprise Managerハウスキーピングの領域が見落とされていることにあります。Enterprise Managerのページ・パフォーマンスの監視における最初の項目は、Enterprise Managerビーコンの使用です。これらの機能は、Enterprise Manager以外のWebアプリケーションに対しても有用です。

ビーコンは、軽量なページ・パフォーマンス監視ターゲットとなるように設計されています。管理エージェント上でビーコン・ターゲットを定義した後は、そのビーコンを使用してUIパフォーマンス・トランザクションを定義できます。これらのトランザクションは、手動で一度実行する一連のUIページ・ヒットです。それ以降は、ビーコンは指定された間隔でUIトランザクションを自動的に繰り返します。ビーコン・トランザクションが実行されるたびに、Enterprise Managerはそのパフォーマンスを計算し、履歴目的で格納します。また、ページ・パフォーマンスが指定したしきい値を下回ったときにアラートを生成することもできます。

Enterprise Managerビーコンを構成する場合、まず、このプロセスで指定したホームページを監視する1つの事前定義済トランザクションから開始します。その後は、いくつでも必要な数のトランザクションを追加できます。ネットワーク上の異なるポイントから同じWebアプリケーションに対する追加のビーコンを設定して、WANの遅延がアプリケーション・パフォーマンスに与える影響を測定することもできます。Enterprise Manager Cloud Controlにより監視されるすべてのWebアプリケーションに対して、これと同じ機能が使用可能です。

パフォーマンスが悪いUIページが示された後は、Enterprise Manager Cloud Controlのページ・パフォーマンス監視の2つ目の項目に進みます。Cloud Controlにおけるこのエンドツーエンド(E2E)監視機能は、ページの処理時間をその基本単位に分解できるように設計されています。これにより、ページ・パフォーマンスを高めるためにメンテナンスが必要となる時期を特定できます。Cloud ControlにおけるE2E監視を使用すると、1つのページ・ヒットのクライアント側とサーバー側の両方の処理を分解できます。

「中間層パフォーマンス」セクションの次のページには、そのページの層別の処理時間が示されます。「処理時間ブレークダウン」という円グラフの最大の区分(上のJDBC時間)をクリックすると、SQLの詳細が表示されます。SQL文をクリックすると、そのSQL文の実行について一定期間のパフォーマンスが表示されます。

「JDBC」ページに、システムでページ時間の実行の大部分が消費されているSQLコールが表示されます。このSQLコールは、個別のDML文の場合もあれば、PL/SQLプロシージャ・コールの場合もあります。個別のSQL文の場合、その文によりアクセスされるセグメント(表およびその索引)を調べて、そのハウスキーピング(再作成および再編成)の必要の有無を判断する必要があります。PL/SQLプロシージャ・コールの場合は、管理リポジトリ内のプロシージャのソース・コードを参照して、そのコールによりアクセスされる表および関連する索引を特定する必要があるため、もう少し複雑になります。

セグメントを特定した後、OMSを停止した状態で、必要な文の再作成および再編成を実行できます。これにより、ページ・パフォーマンスは大幅に向上します。オープン・アラート、システム・エラーおよびメトリック・エラーの数が多すぎる場合など、再作成と再編成のみではページ・パフォーマンスが改善されないこともあります。このようなコールを改善するには、(たとえば、クリーンアップや削除を行って)これらの問題の数を減らすしかありません。これらの数を減らした後は、セグメントの再作成および再編成を実行して、パフォーマンスを最適化する必要があります。これらのシナリオは第11.2.3項で説明されています。最新状態が維持されていれば、UIページ・パフォーマンスをそれほど頻繁に分析する必要はありません。

Enterprise ManagerコンソールからSQLプロシージャのパフォーマンスを監視する場合の新機能の詳細は、Enterprise Managerの管理ガイドのEnterprise Managerの保守に関する章を参照してください。

11.2.4.8 中間層OMSサーバーの最適な数の決定

中間層OMSサーバーの最適な数を決定することは、重要なタスクです。追加のOMSインスタンスの導入について、根拠のある、理にかなった、納得できる決定を下すには、様々な点を考慮する必要があります。監視対象ターゲットの数は最初に検討する項目の1つですが、決定に及ぼす影響は、通常大きくありません。

このタスクの一環として、次の点について検討し、確認する必要があります。

- 使用されるジョブの自動化とスケジューリングのボリューム

- コンソールで同時に作業する管理者の数

- エージェントとOMSサーバーとの間のネットワーク帯域幅とチャネルの堅牢性

- トリガーされる違反と通知の数

- OMSサーバーが使用するIOシステムの速度と安定性

情報に基づいた決定をするには、各カテゴリを詳細に調べることが重要です。単にOMSサーバーを追加したり、同一ホストにCPUやメモリーを増設しても、パフォーマンスの向上に変化が見られない場合があります。現在稼働しているOMSインスタンスを使用して、現在のOMSのパフォーマンスについて実際の統計を収集し、現在または今後のデプロイメントに必要なOMSサーバーの数を計算します。Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。

11.2.5 手順5: サイジング要件を計画するための将来的な直線外挿

将来のストレージ要件を決定することは、バイタル・サインの傾向の有効利用のよい例です。Cloud Controlには、一定期間におけるターゲット合計数および一定期間における管理リポジトリ・サイズという2つのグラフが組み込まれています。

両グラフとも、管理サービスの「すべてのメトリック」ページに表示されます。2つのグラフの間に相関関係があることは明らかです。両方の曲線に当てはまる直線は、ほぼ同じ増加率を表します。Enterprise Manager Cloud Controlに監視対象のターゲットを追加した後、31日間は管理リポジトリの拡大が見られますが、これは、管理リポジトリの領域を消費するターゲットに関するデータのほとんどが、管理リポジトリで完全に表されるには約31日必要なためです。次の1年間は、そのターゲットについては少しずつ拡大を続けますが、これは、最大レベルのデータ集計ではデフォルトの最長データ保存時間が1年であるためです。これは、最初の31日間に比べると、重要ではありません。

ターゲットの追加を停止すると、グラフは約31日間横ばいになります。グラフが横ばいになると、追加したターゲット数と、管理リポジトリ内で使用される追加領域の大きさの間に相関関係が現れます。Enterprise Manager Cloud Controlデプロイ・プロセスの早い段階からこれらの値を追跡することで、サイトの記憶容量を積極的に管理できます。この履歴は非常に重要なツールです。

CPU使用率とターゲット合計の間にも同様の種類の相関関係を作成して、それらの要件を判断できます。CPU使用率の場合、ターゲットを追加すると、横ばい状態がより早く見られます。ターゲットの追加後は、直近の増加率を超えるほどCPUコストが一定期間にわたって大幅に増加することはなくなります。新規メトリックの追加または収集の増加にかかわらず、新しい監視を既存のターゲットに適用すると、たいていはCPU使用率が増加します。

11.2.6 問合せの結果に関する予防措置を使用したパフォーマンスの向上

「すべてのターゲット」ページでは、問合せから返される行の数を制限して、大量のデータによってパフォーマンスが低下したり、OMS内のリソースが過度に消費されることを防ぐ予防措置がEnterprise Managerによってとられています。デフォルトでは、制限は2000に設定されていますが、Enterprise Manager管理者は次のコマンドを使用して制限を変更できます。

emctl set property -name oracle.sysman.core.uifwk.maxRows -value 2000

値に0を指定すると、予防措置が解除され、すべての行がフェッチされます。新しい値はただちに有効になり、OMSの再起動は必要ありません。値が0未満の場合、デフォルト値(2000)がかわりに使用されます。制限がないことを指示する方法は、値を0に設定することのみです。

問合せから返される結果が多すぎ、この制限が有効な場合、次のメッセージが結果表の下に表示されます。

「この検索結果の表は2000ターゲットに制限されています。「検索の絞込み」または「ターゲット名の検索」を使用して、結果を絞り込んでください。この制限を変更する方法は、チューニング・ガイドを参照してください。」

同様の動作(とメッセージ)は、Enterprise Manager内の他の大きな表にも当てはまります。同一のOMSプロパティ(oracle.sysman.core.uifwk.maxRows)でそれらすべての最大限度を一度に制御できます。これは、以前のリリースのEnterprise Managerの動作と一致し(かつ、既存のプロパティを再利用し)ます。

11.3 Fusion Middlewareの監視に対するリポジトリとサイジングの要件の概要

Fusion Middlewareターゲットは、他のEnterprise Managerターゲットと似ています。したがって、Enterprise Managerターゲットに当てはまるリポジトリまたはサイジングのガイドラインは、Fusion Middlewareターゲットにも当てはまります。

Fusion Middleware検出での懸案事項の1つは、検出、作成および監視されるターゲットが多すぎる場合があるということです。これによって、OMSインスタンス、リポジトリおよびターゲットの負荷が増します。ターゲットが非常に多い場合、ターゲットの検出後、ターゲットとそのメトリックをすべて確認することをお薦めします。

ユーザーは、要件に基づいて、監視するターゲットとメトリック、およびターゲットの監視に必要な頻度を最終決定します。

検出後、Fusion Middleware/ADP/JVMD監視を一定期間(数日、可能であれば数週間)実行し、データベースのサイズとオペレーティング・システムのファイルシステムの増加(ADPの場合、ADPマネージャは最低10GBのディスク領域が必要)の監視を、増加が一定になるまで続けます。その後、これらの様々な機能に関連付けられている様々なパラメータを詳細に調整できます。

バージョン12cのEnterprise Managerでは、ADPとJVMDの両方でEnterprise Managerリポジトリがリポジトリとして使用されます。データは、MGMT_AD4J_TS表領域に格納されます。

11.3.1 ADP監視

ADP監視を利用する場合、次の情報を使用してください。

- ADPマネージャのリソース要件
70Kの管理対象エンティティを管理する際、管理対象エンティティの数が非常に多い場合、それに応じてリソースを割り当てる必要があります。

リソース

量

物理メモリー

2GB

最小ディスク領域

10GB

- ADPデータ要件
各JVMの各エンティティを監視するには、MGMT_AD4J_TS表領域で8MB使用可能である必要があります。

- ADPデータ保存ポリシー
ADPには、パフォーマンス・データの集計(または圧縮)に対する高度なマルチ階層ロジックがあります。この機能により、プレゼンテーションのデータを問い合せる場合や、新規パフォーマンス・メトリックを挿入する場合に、内部データ・リポジトリとの相互通信のパフォーマンスを最適化できます。

より長期のデータを格納するユーザーはAcsera.propertiesの次のセクションを確認してください。

#########################
# Production setting
# NOTE: use Model.GlobalSamplingRateSecs to configure Metric.Grain.0
#########################
Metric.Grain.0 0s
Metric.TableInterval.0 = 4h
Metric.DataLife.0 = 2d

Metric.Grain.1 = 3m
Metric.TableInterval.1 =1d
Metric.DataLife.1 = 8d

#Metric.Grain.2 = 30m
#Metric.TableInterval.2 = 7d
#Metric.DataLife.2 = 420d

Metric.*.2プロパティの最後の3行のコメントを解除します。

11.3.2 JVMD監視

JVMD監視を利用する場合、次の情報を使用してください。

- JVMDマネージャのリソース要件
200から300のjvmを管理する場合、JVMDマネージャで1GBの物理メモリーを必要とします。JVMDマネージャでは、監視データを各プールのTEMP領域にキャッシュし、高い頻度でデータベースにフラッシュします。通常、マネージャが監視するプールの数と各プールから収集されるデータの量に応じて、これらの一時キャッシュ・ファイルのサイズ要件は異なりますが、各プールについて数MBを超えることはあまりありません。これが懸案事項である場合、TEMP領域をそのように割り当てます。

- JVMDデータ要件
OOB設定の各JVMを監視するには、MGMT_AD4J_TS表領域で50から100MB使用可能である必要があります。

- JVMの診断履歴データとその保存ポリシー
履歴データは、3つのサマリー・レベル(0、1および2)で使用可能です。

- サマリー・レベル0 - 指定されたプール・ポーリング間隔(デフォルトは2秒)で取得されるサンプル生データです。「パフォーマンス診断」ページで1時間以内のデータを表示すると、サマリー・レベル0のデータが表示されます。レベル0のデータは24時間保持され、その後パージされます。これは「コンソール設定」ページを使用して変更できますが、値を大きくする前に、リポジトリが、大量のデータを処理できるよう適切にチューニングされていることを確認します。

- サマリー・レベル1 - 集計されたデータです。1時間超5時間未満のデータを表示する場合、それはサマリー・レベル1のデータです。デフォルトの集計時間は、90秒です。この値は、「コンソール設定」ページを使用して変更できます。レベル1のデータは20日間保持され、その後パージされます。

- サマリー・レベル2 - さらに集計されたデータです。5時間超経過したデータを表示する場合、それはサマリー・レベル2のデータです。このデータは60分ごとに集計されます。レベル2のデータは400日間保持され、その後パージされます。

MGMT_AD4J_TS表領域の使用方法に大きく影響するJVMDの機能は2つあります。

- JVMDヒープ・ダンプ
ヒープの分析には、大量の表領域リソースが必要です。ロードするヒープ・ダンプ・ファイルのサイズの5倍の空き領域が表領域にあることが推奨されます。ロード・スクリプトを実行する前にヒープ・ダンプ・ファイルが用意され、そのサイズがわかるため、データベースにロードする前に、ダンプを収めるのに十分な領域があることを確認します。

- スレッド・トレース
これらはヒープより1桁小さいですが、コンソールでトレースを開始すると、データベースにデフォルトで自動的にロードされます。これらのトレースのサイズは、トレース時のアクティブ・スレッドの数、トレースの期間およびトレースのサンプル間隔に応じて大きく異なります。通常は、各々100MB未満ですが、これらを手動で大量に使用すると、データベースがすぐにいっぱいになります。また、これらは手動の場合にのみ作成されるため、トレースを開始する前に、トレースを収めるのに十分な領域があることを確認します。

12 拡張インストール・オプションを使用したADPのインストール

この章では、高度なインストール・オプションを使用してEnterprise Manager Cloud Control環境にアプリケーションの依存性とパフォーマンス(ADP)をインストールする方法について説明します。

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

- アプリケーションの依存性とパフォーマンスのアークテクチャの概要

- アプリケーションの依存性とパフォーマンスのインストールを開始する前に

- アプリケーションの依存性とパフォーマンスをインストールするための前提条件

- 高度なインストール・オプションを使用したアプリケーションの依存性とパフォーマンスのインストール

- アプリケーションの依存性とパフォーマンスのインストール後

12.1 アプリケーションの依存性とパフォーマンスのアークテクチャの概要

アプリケーションの依存性とパフォーマンス(ADP)は、Java EE、SOAおよびポータル・アプリケーションの分析を可能にするEnterprise Manager Cloud Controlの重要な機能の1つです。アプリケーション・スキーマ・モデル(Oracleインテリジェント・プラットフォームの中核)内の様々なアプリケーションのビルディング・ブロック間の複雑な関係を取得します。このようなアプリケーションを効果的に管理するために、企業は、ビジネス機能、関連付けられているインターコネクト・コンポーネントおよび基礎となるランタイム環境の間の複雑な関係をまず理解する必要があります。明確かつ正確な理解を可能とするために、IT組織では、異機種環境にまたがる総体的なサービス指向ビューが必要になります。

アプリケーション・スキーマに格納されるインサイトを使用してADPで実現できるアプリケーション・サービス管理(ASM)環境では、そのまま使用できるものを自己カスタマイズして、変化に応じて発展し、専門技術者の関与を最小限に抑えて、異機種環境における全体的なサービス指向のビューを提供します。

ADPは複数階層の完全に分散された構成可能なアーキテクチャを基盤として、企業のデプロイにおけるニーズの変化に対応する拡張性と柔軟性を提供します。

図12-1 ADPのアーキテクチャ

ADPエンジンはADP ASMシステムのコア分析エンジンです。ADPエンジンはすべてのADP Javaエージェントからの要約済データによって、複雑な数学的モデリングや統計的計算をリアルタイムで実行します。ADPエンジンはバックアップとともに構成して、より高いレベルの可用性を実現できます。

ADP Javaエージェントは、ADP ASMシステムのデータ・コレクタです。ADP Javaエージェントはすべての管理アプリケーション・サーバーにデプロイされ、パフォーマンス管理の収集、コンテキスト関係の追跡、データの要約などの一連のタスクを最小限のオーバーヘッドでリアルタイムに実行します。

12.2 アプリケーションの依存性とパフォーマンスのインストールを開始する前に

ADPエンジンまたはADPエージェントをインストールする前に、『Oracle Enterprise Manager基本インストレーション・ガイド』の概要説明を確認してください。

12.3 アプリケーションの依存性とパフォーマンスをインストールするための前提条件

ADPエンジンまたはADPエージェントをインストールする前に、『Oracle Enterprise Manager基本インストレーション・ガイド』で説明されている前提条件を満たしていることを確認してください。

12.4 高度なインストール・オプションを使用したアプリケーションの依存性とパフォーマンスのインストール

この項では、スクリプトを使用してADPを手動でインストールする方法について説明します。次が含まれています。

- ApmEngineSetup.plを使用したADPエンジンの手動でのデプロイ

- deploy_adpagent.plを使用したADPエージェントの手動でのデプロイ

12.4.1 ApmEngineSetup.plを使用したADPエンジンの手動でのデプロイ

ApmEngineSetup.plスクリプトを使用して、ADPエンジンを手動でデプロイできます。このスクリプトは次の方法で実行できます。

- 対話型モード: 対話形式で詳細を入力するようにプロンプト表示されます。

- サイレント・モード: プロパティ・ファイルを使用してすべての入力の詳細を指定します。

重要:
ApmEngineSetup.plスクリプトを使用して、リモート・ホストではなく、OMSを実行しているホストにのみADPエンジンをデプロイできます。

ApmEngineSetup.plスクリプトを使用してADPエンジンを手動でデプロイするには、次の手順に従います。

1. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.6.0/archives/jvmd/deployment_Scripts/engine/

2. README.txtファイルでApmEngineSetup.plスクリプトの使用についての情報を確認します。

3. ApmEngineSetup.plスクリプトを実行します。
ApmEngineSetup.plスクリプトを対話型モードで、プロンプト表示に従って詳細を入力するには、次のコマンドを使用します。

perl ApmEngineSetup.pl

必ず、操作をdeployとし、エンジン・タイプをADPとして指定します。

ApmEngineSetup.plスクリプトをサイレント・モードで実行するには、プロパティ・ファイルにすべての入力の詳細を指定し、次のコマンドを使用します。

perl ApmEngineSetup.pl -silent -file <properties_file_name> -password <password>

<properties_file_name>は、ADPエンジンおよび操作の詳細が記載されるプロパティ・ファイルの名前です。<password>は、WebLogicコンソールのパスワードです。

入力の詳細をプロパティ・ファイルに指定する方法は、サンプルのプロパティ・ファイルSAMPLE_engine.propertiesをご覧ください。

12.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.6.0/archives/jvmd/deployment_Scripts/agent/adp/

2. README.txtファイルでdeploy_adpagent.plスクリプトの使用についての情報を確認します。

3. すべての入力をプロパティ・ファイルに指定し、次のコマンドを使用します。
perl deploy_adpagent.pl <properties_file_name>

deploy_adpagent.plの実行時にプロパティ・ファイルの名前をパラメータとして渡さない場合、deploy_adpagent.plは、同じフォルダ内でadpagent.propertiesという名前のプロパティ・ファイルを検索します。入力の詳細をプロパティ・ファイルに指定する方法は、サンプルのプロパティ・ファイルSAMPLE_adpagent.propertiesをご覧ください。

12.5 アプリケーションの依存性とパフォーマンスのインストール後

この項では、ADPエンジンおよびADPエージェントのインストール後に実行できるタスクを説明します。内容は次のとおりです。

- ADPエンジンおよびADPエージェントのインストールの検証

- セキュアな接続のためのOracle SOA Suiteの構成(ADPのインストール後)

- セキュアな接続のためのOracle WebLogic ServerまたはOracle WebLogic Portal (WLP)の構成(ADPのインストール後)

- ADPエンジンのキーストアへの証明書のインポート

- WebLogicがWindowsサービスとしてインストールされる場合のADPエージェントの構成

12.5.1 ADPエンジンおよびADPエージェントのインストールの検証

ADPエンジンおよびADPエージェントのインストールの検証の詳細は、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。

12.5.2 セキュアな接続のためのOracle SOA Suiteの構成(ADPのインストール後)

Oracle SOA Suiteは、RMIS(RMI over SSL)接続をサポートするように構成できます。このケースでは、このセキュア接続を使用するようにADPを構成できます。このようにADPを構成するには、次の手順を実行します。

1. Oracle SOA Suiteのインストールで、ORACLE_HOME/j2ee/<instance>/config/rmi.xmlを参照し、<ssl-config>要素の場所を特定して、キーストア属性のパスを識別します。

2. 指定されたキーストア・ファイルを、ADPエンジンのconfigディレクトリ(例: em10/config)にコピーします。

3. このキーストア・ファイルをインポートするには、第12.5.4項の手順に従ってください。

12.5.3 セキュアな接続のためのOracle WebLogic ServerまたはOracle WebLogic Portal (WLP)の構成(ADPのインストール後)

t3sを使用した接続を処理するようにOracle WebLogic Server 10.0を構成するには、キーストア・ファイルの場所をコンソールから更新する必要があります。これを実行するには、次の手順に従います。

1. WebLogic Server管理コンソールにログインして、「環境サーバー」のリストからADPで管理するサーバーを選択します。

2. サーバー・リストからサーバーを選択します。

3. 「キーストア」タブを選択し、「ロードおよび編集」をクリックしてキーストアを更新します。

4. 次のプロパティでキーストアおよびトラストストアのファイル・パスを識別します。
アイデンティティ

カスタムIDキーストア

トラスト

カスタム信頼キーストア: トラスト・ファイルの場所

5. ADPを使用して管理する追加のサーバー・インスタンスに対して手順2から4を繰り返します。

6. 指定されたキーストアおよびトラストストアのファイルをADPエンジンにコピーします。

7. BEA_HOME/license.beaを、ADPエンジンのconfigディレクトリ(例: em11g/config)にコピーします。

8. キーストア・ファイルおよびトラストストア・ファイルをインポートするには、第12.5.4項の手順に従ってください。

9. Acsera.propertiesファイルで次のプロパティを検索し、次のように設定します。

weblogic.security.TrustKeyStore=CustomTrust
weblogic.security.CustomTrustKeyStoreFileName=AcseraManagerTrust.jks
weblogic.security.CustomTrustKeyStorePassPhrase=acseramanager

12.5.4 ADPエンジンのキーストアへの証明書のインポート

キーストアまたはトラストストアからエントリをインポートするには、次の手順を実行して、ServerStoreFile.jksをアプリケーション・サーバーのキーストアまたはトラストストアに置き換えます。この手順は通常、キーストアについて1回、トラストストアについて1回の合計2回、実行する必要があります。

1. サーバーからキーストア/トラストストアのファイルのキー別名をリスト表示します。

keytool -list -keystore ServerStoreFile.jks –storepass DemoIdentityKeyStorePassPhrase

Output:

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry:

demoidentity, Wed Nov 19 13:34:56 PST 2008, keyEntry, Certificate fingerprint
(MD5): 36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A

2. キー・エントリを中間ファイルにエクスポートします。

keytool -export -alias demoidentity -keystore ServerStoreFile.jks -storepass
DemoIdentityKeyStorePassPhrase -file demo103

Output:

Certificate stored in file <demo103>

3. キーをADPストア・ファイル(ADPエンジンのconfigディレクトリにあるAcseraManagerKey.jks またはAcseraManagerTrust.jksのいずれか)にインポートします。

keytool -import -alias demoidentity1 -keystore AcseraManagerKey.jks
-storepass acseramanager -file demo103

Output:

Owner: CN=b91, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
Issuer: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
Serial number: 510fb3d4b2872e3a093d436fcbe9b24b
Valid from: Tue Nov 18 13:34:47 PST 2008 until: Sun Nov 19 13:34:47 PST 2023
Certificate fingerprints:
MD5:  36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A
SHA1: BB:85:6D:4C:0B:4A:92:63:CA:5E:E9:A8:54:42:80:2D:0D:BE:7C:91
Trust this certificate? [no]:  yes
Certificate was added to keystore

4. キーが正常にインポートされたことを確認します。

keytool -list -keystore AcseraManagerKey.jks -storepass acseramanager

Output:

Keystore type: jks
Keystore provider: SUN

Your keystore contains 3 entries:

demoidentity1, Wed Apr 01 13:03:21 PST 2009, trustedCertEntry,Certificate fingerprint (MD5): 36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A
demoidentity, Fri Mar 13 15:15:06 PST 2009, trustedCertEntry,Certificate fingerprint (MD5): 0B:11:02:B5:44:0D:2A:CC:7F:C5:30:5C:1A:C9:A1:6C
mykey, Thu May 19 16:57:36 PDT 2005, keyEntry,Certificate fingerprint (MD5): 5D:B0:EC:28:14:33:26:1F:44:F5:BE:DD:A8:50:15:9D

5. 手順1でリストされたキー・エントリごとに手順2から4を繰り返します。

6. Acsera.propertiesファイルで次のプロパティを検索し、次のように設定します。

weblogic.security.TrustKeyStore=CustomTrust
weblogic.security.CustomTrustKeyStoreFileName=AcseraManagerTrust.jks
weblogic.security.CustomTrustKeyStorePassPhrase=acseramanager

現在、バンドルされたSun HotSpot JDKとともにADPを実行する場合、セキュアな接続用にPKCS12タイプのキーストアまたはトラストストアでADPを構成することはできません。IBM JDKには、PKCS12キーストアまたはトラストストア(WebSphere 6.1のデフォルトのkey.p12、trust.p12ストアなど)による動作を可能にする組込みの拡張機能があります。また、WebSphere 6.1には、プロパティcom.ibm.ssl.enableSignerExchangePrompt=trueで有効化される自動機能があり、クライアントはセキュアなWebSphereポートに接続して、サーバーの署名者証明書を自動的にダウンロードしたり、クライアントのトラストストアを更新したりできます。ただし、この自動機能は、ADPをIBM JDKとともに実行する場合にのみ使用できます(現在は未対応)。このため、WebSphere 6.1でセキュアな接続を行うには、前述の手順に従う必要があります。

12.5.5 WebLogicがWindowsサービスとしてインストールされる場合のADPエージェントの構成

監視されたWebLogic ServerがWindowsサービスとしてインストールされている場合、ADPエージェントをデプロイするための自動起動の変更は、WebLogic起動を制御するレジストリ・エントリに手動で適用する必要があります。

変更が必要なパラメータはWindowsレジストリ・キーにあります。

HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\$ServiceName\Parameters

ユーザーは次に、ファイルをADPエンジンで調査します。

deploy/agent/bea9/bin/agentoptions.bat (WebLogic 9.x以上の場合)

このファイルを検査し、この実行の実質的結果をレジストリ内のパラメータとして解決します。

13 拡張インストール・オプションを使用したJVMDのインストール

この章では、Enterprise Manager Cloud Control環境でJVM診断(JVMD)を手動でインストールする方法について説明します。

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

- JVMDアーキテクチャの概要

- JVMDのインストールを開始する前に

- JVMDをインストールするための前提条件

- 拡張インストール・オプションを使用したJVMDのインストール

- JVMDのインストール後

13.1 JVMDアーキテクチャの概要

JVM診断は、Oracle Enterprise Manager Cloud Controlに統合されています。これにより、管理者は本番環境でのJavaアプリケーションのパフォーマンスの問題を診断できます。問題を再現する必要性がなくなることにより、こうした問題解決に必要な時間が短縮されるため、アプリケーションの可用性とパフォーマンスが向上されます。JVMDを使用すると、管理者は、パフォーマンスの問題をテスト環境または開発環境で再現することなく、本番環境で問題の根本原因を特定できます。

次の図に、JVMDのアーキテクチャを示します。

図13-1 JVMDアーキテクチャ

JVMDエンジンは、JVMD監視システムのコア分析エンジンです。JVMDエンジンは、OMSからの要求に応じてJVMDエージェントからランタイム・データを収集し、そのデータをリポジトリに保存します。複数のJVMDエンジンを構成できます。

JVMDエージェントは、ターゲットJVMのデータ・コレクタです。JVMDエージェントは管理アプリケーション・サーバーにデプロイされ、JVMスレッド、スタック、ヒープおよびCPU使用率などに関するJVM監視データを最小限のオーバーヘッドでリアルタイムに収集します。

JVMDエンジンは、WebLogic ServerのEnterprise JavaBeans (EJB)テクノロジとして実行されます。JVMDエージェントは、ターゲットJVM (本番環境のWebLogic Serverを実行するJVM)にデプロイされます。リアルタイムのデータを収集し、JVM診断エンジンに転送します。このデータは管理リポジトリに保存され、収集された情報はEnterprise Manager Cloud Controlコンソールに監視情報として表示されます。JVMDエンジンとJVMDエージェント間の通信は、セキュア(SSL)または非セキュアのどちらかになります。

13.2 JVMDのインストールを開始する前に

JVMDエンジンまたはJVMDエージェントをインストールする前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の概要説明を確認してください。

13.3 JVMDをインストールするための前提条件

JVMDエンジンまたはJVMDエージェントをインストールする前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている前提条件を満たしていることを確認してください。

13.4 拡張インストール・オプションを使用したJVMDのインストール

この項では、JVMDエンジンとJVMDエージェントを手動でデプロイする方法を説明します。内容は次のとおりです。

- ApmEngineSetup.plを使用したJVMDエンジンの手動でのデプロイ

- JVMDエージェントのデプロイ

13.4.1 ApmEngineSetup.plを使用したJVMDエンジンの手動でのデプロイ

ApmEngineSetup.plスクリプトを使用して、JVMDエンジンを手動でデプロイできます。このスクリプトは次の方法で実行できます。

- 対話型モード: 対話形式で詳細を入力するようにプロンプト表示されます。

- サイレント・モード: プロパティ・ファイルを使用してすべての入力の詳細を指定します。

重要:
ApmEngineSetup.plスクリプトを使用して、リモート・ホストではなく、OMSを実行しているホストにのみJVMDエンジンをデプロイできます。

ApmEngineSetup.plスクリプトを使用してJVMDエンジンを手動でデプロイするには、次の手順に従います。

1. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.6.0/archives/jvmd/deployment_Scripts/engine/

2. README.txtファイルでApmEngineSetup.plスクリプトの使用についての情報を確認します。

3. ApmEngineSetup.plスクリプトを実行します。
ApmEngineSetup.plスクリプトを対話型モードで、プロンプト表示に従って詳細を入力するには、次のコマンドを使用します。

perl ApmEngineSetup.pl

必ず、操作をdeployとし、エンジン・タイプをJVMDとして指定します。

ApmEngineSetup.plスクリプトをサイレント・モードで実行するには、プロパティ・ファイルにすべての入力の詳細を指定し、次のコマンドを使用します。

perl ApmEngineSetup.pl -silent -file <properties_file_name> -password <password>

<properties_file_name>は、JVMDエンジンおよび操作の詳細が記載されるプロパティ・ファイルの名前です。<password>は、WebLogicコンソールのパスワードです。

入力の詳細をプロパティ・ファイルに指定する方法は、サンプルのプロパティ・ファイルSAMPLE_engine.propertiesをご覧ください。

13.4.2 JVMDエージェントのデプロイ

この項では、JVMDエージェントを手動でデプロイする方法について説明します。内容は次のとおりです。

- javadiagnosticagent.earまたはjamagent.warをダウンロードおよびデプロイした手動でのJVMDエージェントのデプロイ

- deploy_jvmdagent.plを使用したJVMDエージェントの手動でのデプロイ

- 高可用性を実現するJVMDエージェントのデプロイ

- JVMDデータベース・エージェントのデプロイ

- JVMDエージェントをJVMDエンジン・セキュア・ポートに接続したセキュアな通信の確認

13.4.2.1 javadiagnosticagent.earまたはjamagent.warをダウンロードおよびデプロイした手動でのJVMDエージェントのデプロイ

JVMDエージェントを手動でデプロイするには、次の手順を実行します。

1. javadiagnosticagent.earまたはjamagent.warをダウンロードします。

注意:
Oracle WebLogic ServerにJVMDエージェントをデプロイするには、javadiagnosticagent.earを使用することをお薦めします。Oracle WebLogic Server以外のアプリケーション・サーバーにJVMDエージェントをデプロイするには、jamagent.warを使用してください。

Cloud Controlを使用したjavadiagnosticagent.earまたはjamagent.warのダウンロード

Cloud Controlを使用してjavadiagnosticagent.earまたはjamagent.warをダウンロードするには、次の手順に従います。

1. Cloud Controlの「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. 「アプリケーション・パフォーマンス管理」ページで「JVM診断エンジン」を選択します。

3. 「構成」をクリックします。「JVM診断の設定」ページが表示されます。

4. 「JVM診断の設定」ページで「JVMおよびプール」をクリックし、「ダウンロード」をクリックします。「JVM診断コンポーネントのダウンロード」ダイアログ・ボックスが表示されます。

5. 「JVMDコンポーネント」メニューから、javadiagnosticagent.earをダウンロードするために、「MDAを備えたJVMDエージェント(Weblogicのみ)」を選択し、「OK」をクリックします。jamagent.warをダウンロードするには、「JVMDコンポーネント」メニューから「JVMDエージェント」を選択し、「OK」をクリックします。「JVM診断エージェントWeb xmlパラメータ」ダイアログ・ボックスが表示されます。

6. 「使用可能なエンジン」メニューで、リストからオプションを選択し、「ダウンロード」をクリックします。
セキュアではない接続を使用して、JVMDエージェントがJVMDエンジンに接続するようにするには、HTTP URLを選択します。

セキュアな接続を使用して、JVMDエージェントがJVMDエンジンに接続するようにするには、HTTPS URLを選択します。

ロード・バランサを介して、JVMDエージェントがJVMDエンジンに接続するようにするには、「カスタム」を選択します。JVMDエージェントを接続する必要のあるホスト名およびポートを指定します。

次に例を示します。

HTTP: http://slc01.us.example.com:3800

HTTPS: https://slc01.us.example.com:3801 (セキュアな接続)

7. 「ダウンロード」をクリックして、javadiagnosticagent.earまたはjamagent.warをダウンロードします。

javadiagnosticagent.earを使用したjamagent.warのダウンロード

javadiagnosticagent.earを使用してjamagent.warをダウンロードするには、次の手順に従います。

1. 次の場所にjavadiagnosticagent.earファイルをダウンロードします。
<middleware_home>/oms/jvmd

javadiagnosticagent.earファイルは次の場所からダウンロードできます。

<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.6.0/archives/jvmd/javadiagnosticagent.ear

2. 次のコマンドを実行して、javadiagnosticagent.earを抽出します。
jar -xvf javadiagnosticagent.ear

抽出されたjavadiagnosticagent.earファイルには、jamagent.warが含まれます。

3. 次のコマンドを実行して、jamagent.warを抽出します。
jar -xvf jamagent.war

4. WEB-INF/web.xmlに移動します。

5. jamconshostおよびjamconsportパラメータの値を更新するようにweb.xmlファイルを編集します(jamconshostはJVMDエンジンがデプロイされるホストのIPで、jamconsportは同じホストのポートを示しています)。

注意:
選択されたJVMDエンジンに対するセキュアな通信をできるようにするには、web.xmlファイルに次の変更を行います。
jamsecureCommunication = 1

次に例を示します。

<init-param>
<param-name>jamconshost</param-name>
<param-value>slc01axn</param-value>
<description>Jam console host - demolnx.auptyma.com</description>
</init-param>
<init-param>
<param-name>jamconsport</param-name>
<param-value>3800</param-value>
<description>Jam console port</description>
</init-param>

注意:
JVMDエンジンがデプロイされると、IPとポートがJVMDデプロイメント・ページに<Machine Name:Port Number>のように表示されます。

6. 次のコマンドを実行してjamagent.warファイルを再アセンブルします。
jar -cMvf jamagent.war META-INF WEB-INF jamagent oracle

これで、更新されたjamagent.warファイルのデプロイメントの準備ができました。

デプロイメント中にエラーが発生した場合は、第J.2項を参照してください。

2. JVMDエージェントの手動でのデプロイ
WebLogic ServerへのJVMDエージェントのデプロイ

JVMDエージェントをWebLogic管理対象サーバーに手動でデプロイするには、次の手順を実行します。

1. jvmd.zipファイルにあるデプロイメント・プロファイルsample_jvmdagent_deploy.propertiesのコピーを作成します。javadiagnosticagent.earファイルの場所、WebLogicドメイン名およびサーバー情報を更新します。プロファイルをjvmdagent_deploy.propertiesとして保存します。
パラメータの詳細は、jvmd.zipファイルのcustomprovフォルダにあるREADME.txtファイルを参照してください。

2. jvmd.zipファイルのcustomprovフォルダにあるperlのスクリプトを実行して、指定されたすべてのサーバーにJVMDエージェントをデプロイします。
perl deploy_jvmdagent.pl

注意:
デプロイメント・プロファイルjvmdagent_deploy.propertiesとperlスクリプトが同じフォルダにあることを確認します。

GlassFishへのJVMDエージェントのデプロイ

JVMDエージェントをGlassFishサーバーに手動でデプロイするには、次の手順を実行します。

1. GlassFish管理コンソールにログインします。

2. 「共通タスク」セクションで、「アプリケーション」をクリックします。

3. 「デプロイ済みアプリケーション」セクションで、「デプロイ」をクリックします。

4. 「場所」には、「サーバーにアップロードされるパッケージ・ファイル」を選択し、jamagent.warのあるローカル・ホスト上の場所を指定します。

5. 「選択したターゲット」に、jamagent.warをデプロイするサーバーを追加します。

6. 「OK」をクリックします。

JBossへのJVMDエージェントのデプロイ

JVMDエージェントをJBossに手動でデプロイするには、次の手順を実行します。

1. JBoss管理コンソールにログインします。

2. 「アプリケーション」で「Webアプリケーション(WAR)」をクリックします。

3. 「新しいリソースを追加」をクリックします。

4. ローカル・ホストにあるjamagent.warへの絶対パスを入力します。

5. 「展開済をデプロイ」および「ファーム済をデプロイ」の両方に対して「いいえ」を選択します。

6. 「続行」をクリックします。

JVMDエージェントをJBossに手動でデプロイするには、次の手順も可能です。

1. 次の場所にjamagent.warを転送します。
<JBOSS_HOME>/server/all/deploy

2. アプリケーション・サーバーを再起動します。

TomcatへのJVMDエージェントのデプロイ

JVMDエージェントをTomcatに手動でデプロイするには、次の手順を実行します。

1. 次の場所にjamagent.warを転送します。
$CATALINA_BASE/webapps

2. アプリケーション・サーバーを再起動します。
Tomcatの最新版では、$CATALINA_BASE/conf/server.xmlにおいてautoDeployフラグがtrueに設定されている場合、アプリケーション・サーバーを再起動する必要はありません。Tomcatは実行時にjamagent.warを選択します。

WebsphereへのJVMDエージェントのデプロイ

JVMDエージェントをWebsphereに手動でデプロイするには、次の手順を実行します。

1. WebSphere管理コンソールにログインします。

2. 「アプリケーション」を展開し、「新規アプリケーション」をクリックします。

3. 新規エンタープライズ・アプリケーションをクリックします。

4. 「新規アプリケーションへのパス」で「ローカル・ファイルシステム」を選択し、jamagent.warがあるローカル・ホスト上の場所を指定します。

5. jamagent.warのコンテキスト・ルートを指定します。

6. 構成を保存します。

7. アプリケーションを起動します。

OC4JへのJVMDエージェントのデプロイ

JVMDエージェントをOC4Jに手動でデプロイするには、次の手順を実行します。

1. OC4J管理コンソールにログインします。

2. 「アプリケーション」をクリックします。

3. 「デプロイ」をクリックします。

4. 「アーカイブはローカル・ホストに存在します」を選択します。「アーカイブの場所」で、jamagent.warがあるローカル・ホスト上の場所を指定します。「次へ」をクリックします。

5. 「アプリケーション名」にjamagentと入力します。「コンテキスト・ルート」には/jamagentと入力します。

6. 「デプロイ」をクリックします。

スタンドアロンJVMへのJVMDエージェントのデプロイ

JVMDエージェントは、web.xmlから入力を読み取るか、コマンドラインから入力を指定することによって、スタンドアロンJVMにデプロイできます。

すべての入力がweb.xmlから読み取られるようにして、JVMDエージェントをスタンドアロンJVMにデプロイするには、コマンドラインから次のコマンドを実行します。

java -cp <absolute_path_to_jamagent.war> jamagent.jamrun <java_class_with_a_main_method>

すべての入力をコマンドラインで指定することによって、JVMDエージェントをスタンドアロンJVMにデプロイするには、コマンドラインから次のコマンドを実行します。

java -cp <absolute_path_to_jamagent.war> jamagent.jamrun <java_class_with_a_main_method> jamconshost=<jvmd_engine_host> jamconsport=<jvmd_engine_listen_port> jamjvmid=<unique_jvmd_identifier> jamtimeout=<timeout_period_in_seconds> jamloglevel=<jvmd_agent_log_level>

注意:
jamagent.warがIBM Java Development Kit (JDK)を使用して実行する場合、ログに次の警告が表示されることがあります。

******can_tag_objects capability is not set.Copy library libjamcapability to another directory and restart Java with argument "-agentpath:<absolute_path_to_libjamcapability.so>" ******

この警告を解決するには、libjamcapability.soライブラリを含めて、IBM JVMを再起動します。

/scratch/IBM/WebSphere/AppServer/java/bin/java -agentpath:/scratch/libjamcapability.so -cp /scratch/jamagent.war jamagent.jamrun MyFirstProgram

13.4.2.2 deploy_jvmdagent.plを使用したJVMDエージェントの手動でのデプロイ

deploy_jvmdagent.plスクリプトを使用して、JVMDエージェントを手動でデプロイできます。このスクリプトはサイレント・モードでのみ実行できます。つまり、プロパティ・ファイルを使用してすべての入力の詳細を指定する必要があります。

deploy_jvmdagent.plを使用してJVMDエージェントを手動でデプロイするには、次の手順を実行します。

1. 最新バージョンのjavadiagnosticagent.earまたはjamagent.warがダウンロードされていることを確認します。
javadiagnosticagent.earまたはjamagent.warのダウンロード方法の詳細は、第13.4.2.1項の手順1を参照してください。

2. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.6.0/archives/jvmd/deployment_Scripts/agent/jvmd/

3. README.txtファイルでdeploy_jvmdagent.plスクリプトの使用方法の情報を確認します。

4. すべての入力をプロパティ・ファイルに指定し、次のコマンドを使用します。
perl deploy_jvmdagent.pl [-appserver <server_type>] [-file <name_of_properties_file>]

例: perl deploy_jvmdagent.pl -appserver WLS -file wls_deploy.properties

deploy_jvmdagent.plを使用するJVMDエージェントは、WebLogic ServerおよびGlassFishのみでサポートされており、他のアプリケーション・サーバーではサポートされていません。-appserverパラメータには、JVMDエージェントをデプロイするアプリケーション・サーバーを指定します。JVMDエージェントをWebLogic管理対象サーバーにデプロイしている場合は、-appserverにWLSを指定します。JVMDエージェントをGlassFishサーバーにデプロイしている場合は、-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をご覧ください。

13.4.2.3 高可用性を実現するJVMDエージェントのデプロイ

セットアップで複数のJVMDエンジンをデプロイし、それらに対してロード・バランサを構成している場合、JVMDエージェントを個々のJVMDエンジンのいずれかではなくロード・バランサに接続するようにしてデプロイできます。こうすることでJVMDエージェントの可用性を高め、フェイルオーバー・メカニズムが作成されます。つまり、特定のJVMDエンジンがダウンしても、JVMDエージェントはアクティブを保持できます。

アプリケーション・パフォーマンス管理ページを使用するか手動で高可用性を実現するJVMDエージェントをデプロイできます。

アプリケーション・パフォーマンス管理ページを使用した高可用性を実現するJVMDエージェントのデプロイ

アプリケーション・パフォーマンス管理ページを使用して高可用性を実現するJVMDエージェントをデプロイするには、次の手順を実行します。

1. 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載の手順に従って、JVMDエージェントをデプロイします。

2. JVMDエージェント構成ページの「使用可能なJVMDエンジン」で、「その他」を選択します。ロード・バランサのホスト名とポートを指定します。
「次へ」をクリックします。

3. 確認ページですべての情報を確認し、「デプロイ」をクリックします。

注意:
デフォルトでは、JVMDエージェントはHTTPを使用してロード・バランサに接続します。HTTPSを使用してJVMDエージェントをロード・バランサに接続するには、第13.4.2.1項の手順2で説明するとおり、JVMDエージェントを手動でデプロイする必要があります。

高可用性を実現するJVMDエージェントの手動でのデプロイ

高可用性を実現するJVMDエージェントを手動でデプロイするには、次の手順を実行します。

1. 第13.4.2.1項の手順1に記載の手順に従って、javadiagnosticagent.earまたはjamagent.warをダウンロードします。

2. JVM診断エージェントのweb.xmlパラメータ・ダイアログ・ボックスが表示された場合、「使用可能なエンジン」メニューから「カスタム」を選択します。ロード・バランサのホスト名とポートを指定します。
「ダウンロード」をクリックします。

3. 第13.4.2.1項の手順2で説明したとおりJVMDエージェントをデプロイします。

注意:
デフォルトでは、JVMDエージェントはHTTPを使用してロード・バランサに接続します。HTTPSを使用してJVMDエージェントをロード・バランサに接続するには、第13.4.2.5項で説明するとおり、証明書を使用する必要があります。使用する証明書の共通名は、ロード・バランサのホスト名と一致するようにしてください。

13.4.2.4 JVMDデータベース・エージェントのデプロイ

JVMDデータベース・エージェントをデプロイするには、Cloud ControlからJVMDエージェントをダウンロードします。JVMDエージェントはJVMDデータベース・エージェントとしても機能します。JVMDエージェントがダウンロードされ、Oracle Databaseと同じホストにデプロイされた場合、JVMDデータベース・エージェントは別途必要ありません。JVMDエージェント自体がデータベースとJVMDエンジンとを統合します。ただし、JVMDエージェントとデータベースが別のホストにある場合、データベース固有の情報を収集してJVMDエンジンに収集したデータを送信するJVMDデータベース・エージェントが必要です。

注意:
JVMDデータベース・エージェントは、JVMDエージェントがサポートされるプラットフォーム(Windows以外)でサポートされます。JVMDデータベース・エージェントの実行には、Java 1.4.X以上が必要です。

JVMDデータベース・エージェントをダウンロードおよびデプロイするには、次の手順を実行します。

1. 第13.4.2.1項の手順1に示された手順に従い、Cloud Controlを使用してjamagent.warファイルをダウンロードします。

2. JVMDデータベース・エージェントを起動するには、次のコマンドを実行します。

$JAVA_HOME/bin/java -Xms126M -Xmx512M -cp ./jamagent.war jamagent.Dbagent jamconshost=<Host on which engine is running> jamconsport=<Port of the server on which JVMD Engine is installed>

For Example: /usr/local/packages/jdk14/bin/java -Xms126M -Xmx512M -cp ./jamagent.war jamagent.Dbagent jamconshost=adc2190661.us.example.com jamconsport=3900

注意:
エラー・メッセージ「TIMEOUT from console JAM Agent: Error receiving data from console」が表示される場合、オプションjamconsretr = 5を使用してJVMDデータベース・エージェントを再起動します。

13.4.2.5 JVMDエージェントをJVMDエンジン・セキュア・ポートに接続したセキュアな通信の確認

JVMDエンジンとのセキュアな通信を保証するためには、JVMDエージェントは、JVMDエンジンのデプロイ先の管理対象サーバーの証明書が追加されるキーストアにアクセスできる必要があります。Enterprise Manager Cloud Controlドメイン(JVMDエンジン管理対象サーバーが作成されるEMGCのドメイン)のキーストアは、同じように使用できます。

JVMDエンジンおよびJVMDエージェントを同じホストで実行している場合、JVMDエージェントはEMGCドメインおよびデフォルトのキーストアにアクセスできます。この場合、セキュアな通信を確実にするために次の手順に従ってください。

1. キーストアの場所を特定します。通常は、次の場所から入手できます。
<WEBLOGIC_HOME>/server/lib/DemoTrust.jks

WEBLOGIC_HOMEはWebLogic Serverソフトウェアのインストール・ディレクトリを参照しています。

2. WebLogic Server管理コンソールにログインします。

3. 「環境」メニューから、「サーバー」を選択します。

4. JVMDエージェントをデプロイする管理対象サーバーを選択して、「サーバーの起動」タブを選択します。

5. 「引数」に次の引数を指定します。
-Djavax.net.debug=ssl -Djavax.net.ssl.trustStore=<location_of_DemoTrust.jks> -Djavax.net.ssl.trustStorePassword=<DemoTrust.jks_KeyStore_password>

注意:
DemoTrust.jksキーストアのデフォルトのパスワードは、DemoTrustKeyStorePassPhraseです。

6. 管理対象サーバーを再起動します。

JVMDエンジンおよびJVMDエージェントを異なるホストで実行している場合(ほとんどの環境の場合)、SSL証明書をJVMDエンジン管理対象サーバーからダウンロードして、JVMDエージェントをデプロイするターゲットの管理対象サーバーの新規または既存のキーストアに追加する必要があります。これにより、JVMDエージェントは証明書にアクセスして、JVMDエンジンのセキュアなポートと通信できます。これを実行するには、次の手順に従います。

1. 次の手順に従って、JVMDエンジンの管理対象サーバーの証明書をダウンロードします。

1. ブラウザを使用して、次のURLにアクセスします。
https://<jamconshost>:<jamconsport(secure)>

2. 「ツール」メニューから、「オプション」を選択します。

3. 「拡張」タブを選択して、「暗号化」タブを選択します。

4. 「証明書の表示」をクリックします。

5. 「サーバー」タブを選択して、<jamconshost>:<jamconsport(secure)>証明書を検索し選択します。「エクスポート」をクリックします。

6. 証明書をJVMDCert.crtとして保存します。

2. 既存のキーストアに証明書を追加するか(例: DemoTrust.jk)、新しいキーストアを作成して(例: keystore.jks)証明書に追加します。これを行うには、次のコマンドを実行します。
keytool -import -trustcacerts -alias root -file JVMDCert.crt -keystore <name_of_existing_or_new_KeyStore>

-keystoreパラメータに既存のキーストア名を指定する場合、キーストアのパスワードの入力を求められます。-keystoreパラメータに新しいキーストアの名前を指定する場合、新しいキーストアが作成されデフォルトのパスワードはchangeitになります。

3. WebLogic Server管理コンソールにログインします。

4. 「環境」メニューから、「サーバー」を選択します。

5. JVMDエージェントをデプロイする管理対象サーバーを選択して、「サーバーの起動」タブを選択します。

6. 「引数」に次の引数を指定します。
-Djavax.net.debug=ssl -Djavax.net.ssl.trustStore=<location_of_KeyStore> -Djavax.net.ssl.trustStorePassword=<KeyStore_password>

注意:
DemoTrust.jksキーストアのデフォルトのパスワードは、DemoTrustKeyStorePassPhraseです。

7. 管理対象サーバーを再起動します。

注意:
SunまたはJRockit Java仮想マシン(JVM)で実行されているWebLogic管理対象サーバーがHTTPSを使用して外部リソースに接続しようとすると、次の例外が発生する場合があります。
java.lang.ClassCastException: weblogic.net.http.SOAPHttpsURLConnection

HTTP APIではSun実装を使用するかわりに基礎となるWebLogic実装を使用するため、この例外が発生します。この例外を回避するには、ランタイム引数を使用して次のフラグを設定します。

-DUseSunHttpHandler=true

13.5 JVMDのインストール後

JVMDエンジンまたはJVMDエージェントをインストールした後、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の概要説明の手順を実行します。

14 Enterprise ManagerでのBI Publisherの構成

Oracle Business Intelligence (BI) Publisherは、高度にフォーマットされたあらゆるドキュメントを作成、管理および配布するためのオラクル社の主要レポート・ツールです。BI Publisherは、Enterprise Manager Cloud Control 12cに標準で付属しています。

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

- 概要

- BI Publisherの構成およびEnterprise Manager 12cとの統合

- Enterprise Managerリリース4 (12.1.0.4)でデプロイされたBI Publisherを構成

- 12.1.0.4ミドルウェア・ホームで以前のBI Publisherホームから新BI PublisherへとBI Publisherの構成をアップグレード

- BI PublisherとEnterprise Managerの統合の確認

- Enterprise Manager管理者に対するBI Publisherへのアクセスの許可

- BI Publisher機能へのアクセス制限

- 基礎となるLDAP認証セキュリティ環境でのEnterprise Manager管理者に対するBI Publisherへのアクセスの許可

- Secure Socket Layer (SSL)証明書を使用したBI Publisherの保護

- BI Publisherの管理

- BI Publisher構成後の構成後処理手順

- EMBIP*ロール: フォルダおよびカタログ・オブジェクトへのアクセス権の付与

- Enterprise Managerリポジトリへのアクセス

- トラブルシューティング

- Enterprise Managerの管理 - BI Publisherの接続資格証明

- BI Publisherサーバーの管理

- BI Publisherの使用

- Enterprise Manager 12.1.0.4とともにインストールされなかったBI Publisherの削除

14.1 概要

Enterprise Manager 12cリリース4 (12.1.0.4)以降、Enterprise Managerとともに、BI Publisherバイナリがデフォルトでインストールされるようになりました。BI Publisherの構成は、configureBIPスクリプトを使用して実行します。configureBIPスクリプトによって次の操作が実行されます。

- BI Publisherスキーマを、Enterprise Managerリポジトリ・データベースにインストールします。

- BI Publisherを、Enterprise Managerと同じWebLogicサーバー・ドメインに統合します。

注意:
BI Enterprise Edition (BIEE)のソフトウェアのみのインストールを実行する必要はありません。Enterprise Managerを含むMiddlewareホームには、BIEEのどのバージョンもインストールしないでください。

このプロセスは、BIPという名前のプライマリBI Publisherサーバーを構成します。プライマリBI Publisherサーバーの名前は常にBIPになります。

- ページ区切りおよびヘッダー/フッターを使用した、高度にフォーマットされた業務用レポート。

- PDF、Excel、PowerPoint、WordおよびHTMLの各レポート形式。

- Enterprise Managerリポジトリに対する独自のカスタム・レポートの開発(読取り専用のリポジトリ・アクセス)。

- Enterprise Managerセキュリティとの統合。

- Enterprise Managerの各管理者に対する異なるレベルのBI Publisher機能の付与。

- 電子メールやFTPなど、BI Publisherのスケジュール機能の使用および配信メカニズムの使用。

注意:
情報パブリッシャ(IP)レポート作成フレームワークは、Enterprise Manager 12c Cloud Controlで引き続きサポートされますが、Enterprise Manager 12cリリース1 (12.1.0.1)では非推奨になりました。今後はIPフレームワークを使用したレポート開発は行われません。

14.1.1 制限事項

レポートとデータ・ソースを使用する場合は、次の制限事項が適用されます。

- 即時使用可能なレポートは編集できません。

- 即時使用可能なレポートをコピーする場合、そのコピーが将来の製品リリースでも使用できる保証はありません。

14.2 BI Publisherの構成およびEnterprise Manager 12cとの統合

次の手順は、BI PublisherとEnterprise Managerの両方に精通していることを前提としています。Enterprise Managerの詳細は、『Oracle Enterprise Manager基本インストレーション・ガイド』および『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』を参照してください。

追加情報:
BI Publisher記憶域の構成方法の詳細は、Enterprise Manager管理者ガイドのBI Publisherの高可用性に関する説明を参照してください。
BI Publisherレポートの開発方法の詳細は、『Oracle® Fusion Middleware Oracle Business Intelligence Publisherレポート・デザイナーズ・ガイド』を参照してください。

14.2.1 Enterprise Managerおよび必要なインフラストラクチャのインストール

BI Publisherに必要なリソースをサポートするには、1つ目のOMSシステム(BI Publisherが最初にインストールされ、最終的に構成される場所)に、Enterprise Managerの要件に加えて次の追加要件が必要です。

- 最小で+1.5GBのRAM、最良のパフォーマンスを実現するには4から5GBのRAMを推奨します。

- Enterprise Manager 12cリリース4 (12.1.0.4)以降、BI Publisherのフットプリントが大幅に削減されたため、ディスク領域の特定の要件はなくなりました。

追加のリソース要件については、次のサポート・ノートを参照してください。

10gまたは11gの本番環境でBI Publisher Enterpriseを実行するために必要なサーバーの数を決定する方法(ドキュメントID 948841.1)

14.2.1.1 configureBIPスクリプトを使用したBI PublisherとEnterprise Managerの統合

BI PublisherとEnterprise Managerを統合するには、ドメイン構成を変更する必要があります。ただし、最初にEnterprise Managerの高可用性に関するドキュメントで説明する標準の手順を使用して、次のコマンドによってEnterprise Managerをバックアップする必要があります。

emctl exportconfig oms [-sysman_pwd <sysman password>]
[-dir <backup dir>]     Specify directory to store backup file
[-oms_only]             Specify OMS-only backup on Admin Server host
[-keep_host]            Specify to backup hostname if no slb defined
(Use this option only if recovery will be done
on machine that responds to this hostname)

重要:
configureBIPスクリプトは、Oracleミドルウェア・ホームを所有しているオペレーティング・システム・ユーザーとして実行する必要があります。
configureBIPをUNIXスーパーユーザー(root)として実行しないでください。

configureBIPの実行には、2つのシナリオがあります。

- シナリオ1: Enterprise Managerリリース4 (12.1.0.4)でのBI Publisherの新規の構成
次のいずれかの条件を満たす場合は、新規の構成を使用します。

- 初めてEnterprise Manager 12cをインストールする。Enterprise Manager 12cの以前のバージョンはインストールしていない。

- 以前のバージョンのEnterprise Manager 12cからEnterprise Manager 12cリリース4 (12.1.0.4)にアップグレードするが、過去に適切なバージョンのBI Publisherのインストールと、以前のバージョンのEnterprise Manager 12cとの統合は行っていない。

- シナリオ2: Enterprise Manager 12cリリース4 (12.1.0.4)のBI Publisherの構成を、Enterprise Manager 12cの以前のインストールからEnterprise Managerリリース4 (12.1.0.4)にアップグレードします。
次の条件の両方に該当する場合は、アップグレード構成モードでconfigureBIPスクリプトを使用します。

- 以前のリリースであるEnterprise Manager 12cリリース2 (12.1.0.2)またはEnterprise Manager 12cリリース3 (12.1.0.3)から、Enterprise Manager 12cリリース4 (12.1.0.4)にアップグレード済である。

- Enterprise Manager 12cの以前のインストールが適切なバージョンのBI Publisherと統合されている。

configureBIPスクリプトを操作するには、次の資格証明が必要です。

- SYSDBA権限を持つOracleアカウント(通常はSYSアカウント)

- このアカウントのデータベース・パスワード

- WebLogic管理サーバーのパスワード

重要:
新しい12.1.0.4 Enterprise ManagerインストールからconfigureBIPを実行していることを確認します。

操作を続行する前に、前述の資格証明を必ず収集してください。

configureBIPの標準モードおよびアップグレード・モードの両方を次の2つの項で詳しく説明します。configureBIPスクリプトは、インストール・シナリオに適したモードで操作してください。

14.3 Enterprise Managerリリース4 (12.1.0.4)でデプロイされたBI Publisherを構成

Enterprise Managerリリース4 (12.1.0.4)でBI Publisherの新規の構成を実行するには、次の手順を実行します。このスクリプトは、次の2つの重要な機能を実行します。

- ステップ1 - コマンドの呼出しと資格証明の収集

- ステップ2 - SYSMAN_BIPLATFORMという名前のBI Publisherデータベース・スキーマの作成。これは、Oracleリポジトリ作成ユーティリティ(RCU)を使用して実現します。

- ステップ3 - Enterprise Managerを含むWebLogicドメインの拡張によるBI Publisherの包含と、BI Publisherの構成

ステップ1: コマンドの呼出しと資格証明の収集

1. (Enterprise Manager 12cリリース4 (12.1.0.4)の現行インストールの) OMSインスタンスのORACLE_HOME/oms/binディレクトリから、コマンドラインでconfigureBIPスクリプトを実行します。次に例を示します。

cd /oracle/middleware/oms/bin
configureBIP

2. 必要な資格証明の入力が要求されます。

3. 標準モードの場合は、スクリプトによってリポジトリ作成ユーティリティ(RCU)が実行され、BI Publisherのデータベース・スキーマが作成されます。

4. BI Publisher管理対象サーバーで使用するポート(1つは非SSLポート、もう1つはSSLポート)の2つの値を入力するように要求されます。Enterprise Manager 12cリリース4 (12.1.0.4)の場合、これらのポートの値を両方とも提供する必要があります。

5. 次にドメインの拡張操作が実行されます。

6. BI Publisherを含むEnterprise Managerは、configureBIPを実行する前に、以前と同じロック・モードに設定されます。これを行うにはコマンド"emctl secure {lock | unlock}を実行します。

7. Enterprise Managerが停止および起動されます。

8. Enterprise Manager提供のBI Publisherレポートが、新しくインストールされたBI Publisher Webアプリケーションにデプロイされます。

9. Enterprise Manager WebLogicドメイン・ターゲットがリフレッシュされて、新しく追加されたBI Publisherターゲットが含まれるようになります。

10. emctl exportconfig omsを使用してEnterprise Managerのバックアップを実行します。
このバックアップは、em/sysman/backupサブディレクトリ下の、インスタンス・ホーム・ディレクトリに格納されます。configureBIPスクリプトの実行中に作成されたバックアップは、configureBIP実行後の、このディレクトリの最新ファイルになります。

ステップ2: リポジトリ構成ユーティリティ(RCU)の実行

BI Publisherを初めてインストールすると、RCUを使用してスキーマが作成されます。次のような出力が表示されるはずです。

Creating SYSMAN_BIPPLATFORM Schema in EM Repository Database

Configuring BI Publisher in Oracle Home located in /oracle/middleware/Oracle_BI1 ...
Processing command line ....
Repository Creation Utility - Checking Prerequisites
Checking Global Prerequisites
Repository Creation Utility - Checking Prerequisites
Checking Component Prerequisites
Repository Creation Utility - Creating Tablespaces
Validating and Creating Tablespaces
Repository Creation Utility - Create
Repository Create in progress.
Percent Complete: 0
Percent Complete: 10
Percent Complete: 30
Percent Complete: 50
Percent Complete: 50
Percent Complete: 100
Repository Creation Utility: Create - Completion Summary
Database details:
Connect Descriptor                      : (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=em.example.com)(PORT=15044)))(CONNECT_DATA=(SID=emsid)))
Connected As                    : sys
Prefix for (prefixable) Schema Owners : SYSMAN
RCU Logfile                     : /oracle/middleware/oms/cfgtoollogs/bip/emBIPLATFORM.log
Component schemas created:
Component                       Status  Logfile
Business Intelligence Platform          Success /oracle/middleware/oms/cfgtoollogs/bip/biplatform.log

Repository Creation Utility - Create : Operation Completed

Successfully created SYSMAN_BIPLATFORM schema...

ステップ3: WebLogicドメインの構成

このステップの実行が成功すると、次のような画面出力が表示されます。

Configuring BI Publisher in Oracle Home located in /oracle/work/middleware/Oracle_BI1 ...
Extending domain with BI Publisher. This operations can take some time. Do not interrupt this command while it is running...
Locking Enterprise Manager ...
OMS Console is locked. Access the console over HTTPS ports.
Restart OMS.
Restarting Enterprise Manager ...
Stopping Enterprise Manager, this can take some time  ...
Starting Enterprise Manager. This operation can take some time. Do not interrupt this command while it is running.
OMS Started Successfully
BI Publisher server named :BIP: running at https://em.example.com:9702/xmlpserver.
Registering BI Publisher with Enterprise Manager and deploying reports...
Performing automatic backup of Enterprise Manager.
Successfully backed up Enterprise Manager.
Successfully setup BI Publisher with Enterprise Manager

14.4 12.1.0.4ミドルウェア・ホームで以前のBI Publisherホームから新BI PublisherへとBI Publisherの構成をアップグレード

重要:
アップグレードの前に、BI Publisherサーバーを停止します。Enterprise Managerのアップグレード・プロセスを開始する前までに、WLSコンソールを使用してBI Publisherサーバー・プロセスを停止しておく必要があります。これを実行していない場合は、手動でシステム・コマンドを使用してBI Publisherサーバー・プロセスを正常に停止する必要があります。たとえば、UNIXでは、killコマンドを(-9引数を指定せずに)使用します。

Enterprise Managerリリース4 (12.1.0.4)でBI Publisherのアップグレード構成を実行するには、次の手順を実行します。このスクリプトは、次の2つの重要な機能を実行します。

- ステップ1 - コマンドの呼出しと資格証明の収集

- ステップ2 - SYSMAN_BIPLATFORMという名前のBI Publisherデータベース・スキーマのアップグレード。これは、Oracleパッチ・セット・アシスタント(PSA)を使用して実現します。

- ステップ3 - Enterprise Managerを含むWebLogicドメインの拡張によるBI Publisherの包含と、BI Publisherの構成

(Enterprise Manager 12cリリース4 (12.1.0.4)の現行インストールの) OMSインスタンスのORACLE_HOME/binディレクトリから、-upgradeコマンドライン引数を使用してconfigureBIPスクリプトを実行します。次に例を示します。

cd /oracle/middleware/oms/bin
configureBIP -upgrade

オプション: スクリプトで、次に示す手順6(レポートと特定の構成データの移行)を実行しない場合は、オプションのコマンドライン引数を指定できます。その場合は、次の構文を使用してconfigureBIPを実行します。

configureBIP -upgrade -nomigrate

1. 必要な資格証明の入力が要求されます。

2. スクリプトは、以前のEnterprise Manager 12cインストールのドメインへの完全ディレクトリ・パスを求めます。このインストールにはBI Publisherのレポート定義と特定の構成データがすでに含まれています。

3. ここではBI Publisherの以前のリリースからアップグレードしているので、スクリプトによってパッチ・セット・アシスタント(PSA)の手順が実行され、BI Publisherのデータベース・スキーマがアップグレードされます。

4. BI Publisher管理対象サーバーで使用するポートの、2つの必要な値を入力するように要求されます。1つは非SSLポート、もう1つはSSLポートです。

5. 次にドメインの拡張と新しいBI Publisherの構成が実行されます。この手順ではBI Publisher管理対象サーバーは起動されません。

6. 必要に応じて、以前のリリースのEnterprise Manager 12cにインストールされていたBI Publisherの以前のインストールから、レポートと特定の構成データが移行されます。

7. 次にBI Publisher管理対象サーバーが起動されます。

8. BI Publisherを含むEnterprise Managerは、configureBIPを実行する前に、以前と同じロック・モードに設定されます。これを行うにはコマンド"emctl secure {lock | unlock}を実行します。

9. Enterprise Managerが、BI Publisherを含めて、停止および起動されます。

10. Enterprise Manager提供のBI Publisherレポートが、新しくインストールされたBI Publisher Webアプリケーションにデプロイされます。

11. Enterprise Manager WebLogicドメイン・ターゲットがリフレッシュされて、新しく追加されたBI Publisherターゲットが含まれるようになります。

12. Enterprise Manager提供のBI Publisherレポートが、新しくインストールされたBI Publisher Webアプリケーションにデプロイされます。

13. 最後の手順では、emctl exportconfig omsコマンドを使用してEnterprise Managerのバックアップを実行します。

注意:
Enterprise Manager 12cリリース4 (12.1.0.4)でBI Publisher 11.1.1.6.0にアップグレードすると、既存のBI Publisherスキーマは以前のバージョンから11.1.1.7.0にアップグレードされます。つまり、アップグレードの実行時に、既存のBI PublisherスケジュールはすべてBI Publisherの新しいインストールに引き継がれます。

ステップ1 - コマンドの呼出しと資格証明の収集

ステップ1により、次の出力が生成されます。

Configuring BI Publisher Version "11.1.1.7.0" to work with Enterprise Manager
Logging started at /oracle/work/middleware/oms/cfgtoollogs/bip/bipca_20140227144257.log.
This command is meant to be run from Oracle Enterprise Manager Cloud Control 12c Release 4. Please confirm? (Y|N):y
Before this command is run, a backup of Enterprise Manager should be performed using the :emctl exportconfig oms: command. Have you made a valid backup of Enterprise Manager (yes/no) [no] ? yes
Enter sysdba user name (sys):
Enter sysdba user password:
Enter Administration Server user password:
Enter the fully qualified path to the domain you are upgrading from: /oracle/EM12cR3/gc_inst/user_projects/domains/GCDomain
Upgrading from a prior release of BI Publisher With a file-system repository Located at: //oracle/EM12cR3/gc_inst/user_projects/domain/GCDomain
Configuring BI Publisher in Oracle Home located in /oracle/work/middleware/Oracle_BI1 ...

ステップ2 - BI Publisherデータベース・スキーマのアップグレード

このスキーマの名前はSYSMAN_BIPLATFORMです。この操作は、Oracleパッチ・セット・アシスタント(PSA)を使用して実行されます。

パッチ・セット・アシスタントが起動して、BI Publisherスキーマがアップグレードされます。次のような出力が生成されます。

EM 12c BIPLATFORMversion 11.1.1.6.0  schema detected. Begin upgrade process to version 11.1.1.7.0
Begin to execute Oracle Fusion Middleware Patch Set Assistant (PSA) ...
PSA returns with status: 0
Successfully upgraded SYSMAN_BIPLATFORM schema...

ステップ3 - Enterprise Managerを含むWebLogicドメインの拡張によるBI Publisherの包含と、BI Publisherの構成

このスクリプトの処理が成功すると、次のような画面出力が生成されます。

Enter an integer between 9701 and 49152 for the BI Publisher HTTP server port. (9701):
Enter an integer between 9713 and 49152 for the BI Publisher HTTPS server port. (9702)):
Extending domain with BI Publisher. This operations can take some time. Do not interrupt this command while it is running...
Migrating BI Publisher Filesystem repository from "/ /oracle/EM12cR3/user_projects/domains/GCDomain/config/bipublisher/repository" to "/oracle/gc_inst/user_projects/domains/GCDomain/config/bipublisher/repository"...
Starting the Upgraded BI Publisher Managed Server...
Locking Enterprise Manager ...
OMS Console is locked. Access the console over HTTPS ports.
Restart OMS.
Restarting Enterprise Manager ...
Stopping Enterprise Manager, this can take some time  ...
Starting Enterprise Manager. This operation can take some time. Do not interrupt this command while it is running.
OMS Started Successfully
BI Publisher server named :BIP: running at https://slc03sag.example.com:9702/xmlpserver.
Registering BI Publisher with Enterprise Manager and deploying reports...
Performing automatic backup of Enterprise Manager.
Successfully backed up Enterprise Manager.
Successfully setup BI Publisher with Enterprise Manager

14.5 BI PublisherとEnterprise Managerの統合の確認

注意:
高可用性環境で(サーバー・ロード・バランサ(SLB)の背後で) Enterprise Managerを実行している場合は、次の点に注意してください。

- 最初のBI PublisherサーバーがプライマリOMSシステムで構成された場合、サーバー・ロード・バランサの背後にある他のすべてのEnterprise ManagerシステムでBI Publisherを構成する必要があります。

- Enterprise Managerシステムに動作中のOMSがある場合、および対応するBI Publisherサーバーが構成されていない場合や動作していない場合、Enterprise ManagerからのBI Publisherのレポートの実行が失敗することがあります。この場合、追加のEnterprise ManagerシステムでBI Publisherを構成してください。BI Publisherがすでに追加のシステムで構成されている場合は、Enterprise Managerコマンドライン・ユーティリティ(EMCTL)を使用して起動します。

- 複数のBI Publisherサーバーの構成の詳細は、第20章「複数のBI Publisherサーバーの実行」を参照してください。

新規の構成モードとアップグレード構成モードのいずれでも検証を実行できます。

1. スーパー管理者としてEnterprise Managerにログインします。

2. 「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。
BI PublisherとEnterprise Managerが統合される前に、次のような「BI Publisherレポート」ページが表示されます。

3. BI Publisherの構成後、次の図のように、Enterprise Manager提供のすべてのBI Publisherレポートを表示したツリー・リストが表示されます。

この図は、プラグインがすべてインストールされた後のレポート・リストを示しています。レポート・リストは、インストールされたプラグインの数によってサイズが異なります。

4. 提供されているEnterprise Managerサンプル・レポートをクリックし、「指定したタイプのターゲット」を選択します。

5. Enterprise Manager資格証明を使用してBI Publisherにログインします。

6. 画面にはサンプルのレポートが表示されます。PDFレポート生成や電子メール配信など、BI Publisherのすべての機能を使用できます。

14.6 Enterprise Manager管理者に対するBI Publisherへのアクセスの許可

BI Publisherは、WebLogicを介して、Enterprise Manager用に構成されているセキュリティ・モデルを共有します。セキュリティ・モデルは、BI Publisherへのアクセス認証と、BI Publisherの様々な機能へのアクセス権限の設定という2つの目的で使用します。次の項目を後述の各項で説明します。

- Enterprise Manager認証セキュリティ・モデル

- BI Publisherセキュリティ・モデル

- BI Publisherの権限

- BI PublisherのOPSSアプリケーション・ロール

- BI Publisher機能へのアクセス認証とアクセス制限

14.6.1 Enterprise Manager認証セキュリティ・モデル

統合すると、BI PublisherレポートがEnterprise Managerのセキュリティ・モデルに準拠します。Enterprise Managerは、Oracle® Enterprise Managerセキュリティ・ガイドで定義されている、様々なセキュリティ・モデルをサポートします。

Enterprise Manager 12cがサポートしているセキュリティ・モデルの概要は次のとおりです。

1. リポジトリベースの認証

2. エンタープライズ・ユーザー・セキュリティベース(EUS)の認証

3. Oracle Access Manager(OAM) SSO

4. Oracle Single Sign-On(OSSO)ベースの認証

5. LDAP認証オプション: Oracle Internet DirectoryおよびMicrosoft Active Directory

14.6.2 BI Publisherセキュリティ・モデル

BI Publisherは、Enterprise Managerと統合されると、Enterprise Managerと同じセキュリティ・モデルを共有します。

セキュリティ・モデル1: リポジトリベースの認証(認証にOracle Databaseを使用)。

セキュリティ・モデル2: エンタープライズ・ユーザー・セキュリティ認証(EUS) (認証にOracle Databaseを使用)。このセキュリティ構成では、Oracle Databaseが認証をLDAPサーバーに委任します。ただし、このLDAPサーバーにWebLogicが直接アクセスすることはなく、そのためBI PublisherはLDAPサーバーに直接アクセスしません。

残り3つのセキュリティ・モデルでは、WebLogicが直接アクセスする、基礎となるLDAPサーバーを使用してユーザーを認証します。

このドキュメントでは、BI Publisherセキュリティ・モデルを次の2つのカテゴリのいずれかに分類します。

1. リポジトリベースの認証

2. 基礎となるLDAPベースの認証

注意:
BI Publisherのセキュリティ・モデルが基礎となるLDAPベースの認証を使用するように構成されている場合、BI Publisher固有の構成を追加する必要はありません。たとえば、BI Publisherの「管理」画面にアクセスしてセキュリティ・モデルをLDAPに変更する必要はありません。Enterprise ManagerとBI Publisherは、同じWebLogicドメインで構成されているため、自動的に同じセキュリティおよび認証メカニズムを共有します。

重要:
Enterprise Managerが以前にLDAPサーバーまたはSSOサーバーを使用するように構成されていた場合、このLDAPまたはSSOの構成手順を繰り返す必要があります。これは、必要なBI Publisher構成の詳細を組み込むために必要です。

BI Publisherレポートに適用される主なセキュリティ属性は次のとおりです。

- BI Publisherの権限

- BI PublisherのOPSSアプリケーション・ロール

これらの各セキュリティ属性の詳細を次の各項で説明します。

14.6.3 BI Publisherの権限

Enterprise Managerには、オラクル社提供の特定のBI Publisherカタログ・オブジェクトが付属しています。これらのカタログ・オブジェクトは次の要素で構成されています。

- フォルダ

- レポート(レイアウト定義および変換)

- データ・モデル(Enterprise Managerリポジトリに対するSQL問合せ)

- サブテンプレート(すべてのレポート出力の各ページの上部に表示される標準のEnterprise Managerヘッダー)

これらのカタログ・オブジェクトは、BI PublisherがインストールされてEnterprise Managerに統合されると作成されます。これらは、「Enterprise Manager Cloud Control」フォルダにあります。これらのカタログ・オブジェクトは、次に説明するロール/グループを組み合せた特定の権限で作成され、目的のセキュリティ・モデルを達成します。

14.6.4 BI PublisherのOPSSアプリケーション・ロール

ドメイン・ポリシー・ストア(OPSS)を使用すると、BI Publisherカタログのオブジェクトに対するEnterprise Manager管理者のアクセス権や、BI Publisherの「管理」ボタンへの条件付きアクセス権を制御できます。

OPSSは、システムおよびアプリケーションに固有のポリシーのリポジトリです。OPSSの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。ドメインには、そのドメインにデプロイしたすべてのアプリケーションで使用できるすべてのポリシー(および資格証明)を格納するストアが1つあります。Enterprise ManagerとBI Publisherはいずれも同じドメイン内にある個別アプリケーションなので、Enterprise Manager管理者がBI Publisherにアクセスして使用するには、BI Publisher固有のOPSSアプリケーション・ロールが付与されている必要があります。

BI Publisherがインストールされると、OPSSアプリケーション・ロールが4つ作成されます。これら4つのOPSSアプリケーション・ロールは、「Enterprise Manager Cloud Control」フォルダにあるBI Publisherカタログ・オブジェクトの権限と組み合され、次の各項に示すルールを達成します。また、基礎となるLDAP認証セキュリティ・モデルを使用すると、これらのOPSSアプリケーション・ロールにLDAPグループをマップできます。

リポジトリベースの認証セキュリティ・モデルでは、BI Publisherに対するEnterprise Manager管理者のアクセス権を制御するためだけに、ドメイン・ポリシー・ストア(OPSS)が使用されます。

14.6.5 BI Publisher機能へのアクセス認証とアクセス制限

次にOPSSアプリケーション・ロールを示し、Enterprise Managerに付属のBI Publisherカタログ・オブジェクトに配置される効果的なセキュリティ・モデルについて説明します。

- なし - BI Publisherロールを持たないEnterprise Manager管理者は、BI Publisherがサポートしている任意の配信チャネルを介して(ただし、構成済でBI Publisherのシステム管理者がアクセス可能であること) BI Publisherレポートにアクセスできます。たとえば、構成済であれば、すべてのユーザーがBI PublisherレポートをBI Publisherのスケジュール機能および電子メール配信メカニズムを介して受信できます。

- EMBIPViewer - このBI Publisherロールを持つEnterprise Manager管理者は、電子メールを受信できるだけでなく、Enterprise Manager提供のBI Publisherレポートを表示することもできます。

- EMBIPScheduler - このBI Publisherロールを持つEnterprise Manager管理者は、電子メールを受信できますが、EMBIPViewerロールも持つ場合は、Enterprise Manager提供のBI Publisherレポートをスケジュール設定できます。

- EMBIPAuthor - このBI Publisherロールを持つEnterprise Manager管理者は、電子メールの受信やEnterprise Manager提供のBI Publisherレポートの表示が可能で、新しいレポートを各自のプライベート・フォルダに作成できます。また、Enterprise Manager提供のBI Publisherレポートを個人フォルダにコピーして、カスタマイズすることも可能です。

- EMBIPAdministrator(スーパーユーザー) - このBI Publisherロールを持つEnterprise Manager管理者は、BI Publisherへの完全なアクセス権があります。

次の図は、前述のロールの階層を示したものです。

注意:
BI Publisherの「管理」ボタンへのアクセス権は、OPSSアプリケーション・ロールを介して付与されます。このボタンは、BI Publisherで詳細構成(電子メール・サーバーの設定など)を実行する場合に使用します。

Enterprise Managerのスーパー管理者

リポジトリベースの認証セキュリティ・モデルを使用すると、Enterprise Managerのすべてのスーパー管理者にOPSSアプリケーション・ロールEMBIPAdministratorが自動的に付与され、BI Publisherを設定できるようになります。

基礎となるLDAP認証セキュリティ・モデルを使用すると、Enterprise Managerのスーパー管理者にBI PublisherへのEMBIPAdministratorアクセス権限は自動的に付与されません。基礎となるLDAPベース認証セキュリティ・モデル環境で、Enterprise Manager管理者にBI Publisherへのアクセスを許可する詳細は、16.x項を参照してください。

14.7 BI Publisher機能へのアクセス制限

前の項で説明した4つのOPSSアプリケーション・ロールの付与は、使用しているBI Publisherセキュリティ・モデルによって若干異なります。確認のため、BI Publisherがサポートしている2つのセキュリティ・モデルを次に示します。

- リポジトリベースの認証

- 基礎となるLDAPベースの認証

14.7.1 wlstを使用したリポジトリベースの認証モードによるEnterprise Manager管理者へのBI Publisher OPSSアプリケーション・ロールの付与

EM CLIコマンドを使用して、Enterprise Manager管理者に1つ以上のOPSSアプリケーション・ロールを付与します。次の使用例は、EM CLIを使用して、JERRYおよびLESLIEという名前のEnterprise Manager管理者に表示および作成のアクセス権を付与する方法を示しています。

注意:
エンタープライズ・ユーザー・セキュリティ(EUS)はユーザーの認証にLDAPサーバーを使用しますが、これはデータベースによって厳密に処理されます。そのため、この項の説明はEUSを使用する場合にも適用されます。

スクリプトを実行する手順は次のとおりです。

1. Enterprise ManagerのEM CLIからEnterprise Managerに接続します

2. emcli grant_bipublisher_rolesを実行して、Enterprise ManagerユーザーにBI Publisherのアクセス権を付与します。

セッションの例

$ emcli login -username=sysman
Enter password :
Login successful
$ emcli sync
Synchronized successfully
$ emcli grant_bipublisher_roles  -roles="EMBIPViewer;EMBIPAuthor" -users="JERRY;LELSIE"
EMBIPViewer role successfully granted to JERRY
EMBIPViewer role successfully granted to LESLIE
EMBIPAuthor role successfully granted to JERRY
EMBIPAuthor role successfully granted to LESLIE

BI Publisherレポートへの表示アクセス権の取消し

次のセッション例では、ユーザーJERRYからBI Publisherレポートの表示アクセス権を取り消します。

$ emcli login -username=sysman
Enter password :
Login successful
$ emcli sync
Synchronized successfully
$ emcli revoke_bipublisher_roles -roles="EMBIPViewer" -users=JERRY
EMBIPViewer role successfully revoked from JERRY

14.7.2 OPSSへの変更の伝播時間

Enterprise Manager管理者のBI Publisherアクセス権限(EMBIPViewer、EMBIPAdministrator、EMBIPScheduler、EMBIPAuthor)を変更する場合、スーパー管理者は、変更内容がOPSSに伝播して有効になるまで15分以上待機する必要があります。変更内容は、管理者が次にBI Publisherにログインした時点で有効になります。

14.8 基礎となるLDAP認証セキュリティ環境でのEnterprise Manager管理者に対するBI Publisherへのアクセスの許可

Enterprise ManagerとBI Publisherは個別のアプリケーションです。基礎となるLDAPベースの認証モデル(エンタープライズ・ユーザー・セキュリティ(EUS)を除く)を使用すると、外部LDAPサーバーに定義されたLDAPグループもBI Publisherへのアクセス権を管理するために使用できます。これらのLDAPグループごとに、BI Publisherへのアクセス権のレベルを変えることができます。これにより、1つ以上のLDAPグループのメンバーとしてLDAPユーザーを追加できるようになり、BI Publisherの適切な機能がそのユーザーに公開されます。これらのLDAPグループは、作成するか既存のものを使用する必要があり、「Enterprise Manager Cloud Control」フォルダのカタログ・オブジェクトの権限で調整されます。

注意:
この項の説明は、エンタープライズ・ユーザー・セキュリティ(EUS)を使用するようにEnterprise Managerを構成している場合には適用されません。第14.7.1項「wlstを使用したリポジトリベースの認証モードによるEnterprise Manager管理者へのBI Publisher OPSSアプリケーション・ロールの付与」を参照してください。

注意:
BI PublisherとEnterprise Managerは同じWebLogicドメイン内で構成されるため、BI Publisherアプリケーションで特別なLDAP構成を実行する必要はありません。LDAPの構成は、次の手順で十分です。

基礎となるLDAPベースの認証セキュリティ・モデルでは、次の手順を実行する必要があります。

- LDAPサーバーの管理者は、任意の名前を付けた4つの外部グループを使用する必要があります。これらのグループは階層的にグループ化する必要があります。既存のグループを使用するか、新しいグループを作成できます。

重要:
グループ名はすべて大文字にする必要があります。

グループ名の例:

- EMBIPADMINISTRATOR

- EMBIPVIEWER

- EMBIPSCHEDULER

- EMBIPAUTHOR

- LDAPサーバーの管理者は、前述の階層図に示した必要な階層構造を実現するために、次のような変更を加える必要があります。前述のLDAPグループ名を例に説明します。
EMBIPADMINISTRATORをEMBIPAUTHORのメンバーに設定

EMBIPADMINISTRATORをEMBIPSCHEDULERのメンバーに設定

EMBIPAUTHORをEMBIPVIEWERのメンバーに設定

注意:
LDAPでは、用語と概念が逆に見えて混乱する場合があります。たとえば、EMBIPAUTHORSグループにEMBIPADMINISTRATORSグループのメンバーを作成する場合などです。

BI Publisherおよびそのカタログ・オブジェクトへのアクセス権を付与するには、LDAPサーバーの管理者が、それぞれのLDAPユーザーを前述の1つ以上のLDAPグループのメンバーにする必要があります。

14.8.1 BI PublisherのOPSSアプリケーション・ロールに対するLDAPグループのマッピング

前述のOPSSアプリケーション・ロールに4つのLDAPグループをマップするには、EM CLIを使用してLDAPグループをマップする必要があります。

注意:
Enterprise Manager 12cに対するBI Publisherの以前のインストールから、Enterprise Manager 12cリリース4 (12.1.0.4)に対するBI Publisher 11.1.1.7.0にアップグレードして、LDAPグループの名前が変更されていない場合、以前のOPSSアプリケーション権限が新しいインストールに継承されるため、この手順は不要です。

セッションの例

emcli grant_bipublisher_roles -roles="EMBIPViewer" -external_role="EMBIPVIEWER"
EMBIPViewer successfully granted to EMBIPVIEWER
emcli grant_bipublisher_roles -roles="EMBIPAuthor" -external_role="EMBIPAUTHOR"
EMBIPAuthor successfully granted to EMBIPAUTHOR
emcli grant_bipublisher_roles -roles="EMBIPScheduler" -external_role="EMBIPSCHEDULER"
EMBIPScheduler successfully granted to EMBIPSCHEDULER
emcli grant_bipublisher_roles -roles="EMBIPAdministrator" -external_role="EMBIPADMINISTRATOR"
EMBIPAdministator successfully granted to EMBIPADMINISTRATOR

14.9 Secure Socket Layer (SSL)証明書を使用したBI Publisherの保護

BI WebLogic Serverには、デフォルト・アイデンティティ・キーストア(DemoIdentity.jks)とデフォルト信頼キーストア(DemoTrust.jks)が構成されています。また、WebLogic Serverは、JDKのcacertsファイルのCA証明書を信頼します。このデフォルトのキーストア構成は、テストや開発を目的とする場合に適しています。ただし、これらのキーストアは本番環境では使用しないでください。

Enterprise Managerが以前に、emctl secure wlsコマンドを使用してSSL証明書で保護されていた場合、BI Publisherを構成した後でこのコマンドを再発行する必要があります。このコマンドの使用方法の詳細は、Enterprise Managerの管理者ガイドを参照してください。

14.10 BI Publisherの管理

BI Publisherの設定の構成手順については、BI Publisherのマニュアルを参照してください。

共通の管理タスク:

- サーバー・プロパティ(電子メール・サーバーなど)の構成

- レポート配信チャネル(FTPなど)の構成

14.11 BI Publisher構成後の構成後処理手順

プラグイン固有のレポートのインストール

Enterprise Managerに表示されるBI Publisherのいくつかのレポートは、特定のプラグインに属しています。これらのレポートを使用するには、これらのプラグインをインストールする必要があります。プラグインは、Enterprise Manager 12cで動作するようにBI Publisherを構成する前または後にインストールできます。Enterprise Managerプラグインは様々なメカニズムを使用してインストールできます。これらのメカニズムはすべて、プラグインの一部であるBI Publisherレポートのインストールをサポートしています。

注意:
インストールの詳細は、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。

BI Publisherを構成する前にEnterprise Managerのプラグインがインストールされていた場合、これらの新しいBI PublisherレポートをEnterprise ManagerからBI Publisherにデプロイする必要があります。これには、次のコマンドを使用できます。

emcli deploy_bipublisher_reports

このコマンドの完全な使用方法と例を参照するには、次を実行します。

emcli help deploy_bipublisher_reports

14.12 EMBIP*ロール: フォルダおよびカタログ・オブジェクトへのアクセス権の付与

デフォルトでは、付属のセキュリティ・モデル(第14.6.5項で説明)が「Enterprise Manager Cloud Control」フォルダ内のBI Publisherカタログ・オブジェクトに適用されます。これは、このフォルダ内に存在するカタログ・モデルがデフォルト設定の権限で設定されるためです。第14.6.3項を参照してください。このフォルダの外部にあるBI Publisherカタログ・オブジェクトには、これらと同じ権限は自動的に含まれません。たとえば、BI Publisherには「サンプル」という名前の共有フォルダに多くのレポートが用意されています。このフォルダへのアクセス権をEMBIPAdministrator以外のEnterprise Manager/BI Publisherユーザーに付与することが望ましい場合は、BI Publisherスーパー管理者(EMBIPAdministrator)がこのフォルダの権限を変更する必要があります。この操作を実行するには、「サンプル」フォルダを選択し、タスク・バーの左下隅の「権限」を選択します。次に、4つの権限(EMBIPAdministrator、EMBIPViewer、EMBIPAuthor、EMBIPScheduler)を追加し、その権限に適切なアクセス権(たとえば、EMBIPViewerにはレポートの表示アクセス権やオンライン実行アクセス権など)を付与する必要があります。管理者は、付属のEnterprise Managerレポート(指定したタイプのターゲットなど)のいずれかに基づいて、付与する適切な権限をモデル化できます。

EMBIPAuthorのOPSSアプリケーション・ロールを持つ各ユーザーは、それぞれのプライベート・フォルダにレポートを作成できます。これらのレポートを他のユーザーが使用することはできません。

注意:
共有フォルダの「Enterprise Manager Cloud Control」には、Enterprise Manager提供のBI Publisherレポートが含まれ、そのために予約されています。カスタム開発されたレポートはこのフォルダ階層に追加できません。Enterprise Managerに付属のデフォルトのセキュリティ・モデルでは特にこれが禁止されています。

注意:
Enterprise Managerの「BI Publisher Enterpriseレポート」メニュー(「エンタープライズ」メニュー→「レポート」→「BI Publisher Enterpriseレポート」を選択)に表示されるのは、「Enterprise Manager Cloud Control」フォルダ内のレポートのみです。

BI Publisher管理者(EMBIPAdministrator)が「Enterprise Manager Cloud Control」フォルダの外部に新しい共有フォルダを作成したい場合、この操作が可能です。これらのレポートは、Enterprise Managerの「BI Publisher Enterpriseレポート」メニューには表示されませんが、前述のように、適切な権限が付与されている場合は、他のEnterprise Manager管理者にも表示されます。

14.13 Enterprise Managerリポジトリへのアクセス

すべてのBI Publisherレポートには、Enterprise Managerリポジトリへの読取り専用アクセス権が付与されます。このアクセスは、EMREPOSという名前のBI Publisherデータ・ソースを経由します。このアクセスは、Enterprise ManagerユーザーMGMT_VIEW (Enterprise Manager公開のMGMT$データベース・ビューへの読取りアクセス権を持つ特別な内部Enterprise Managerユーザー)を経由します。また、レポートの実行時に、レポートを実行しているユーザーのターゲット・レベルのセキュリティにさらに制限されます。たとえば、ユーザーJOEにhostabcおよびdatabase3へのターゲット・レベルのアクセス権がある場合、ユーザーJOEがBI Publisherレポート(任意のレポート)を実行すると、これら2つのターゲットに関連付けられているターゲット・レベルのデータしか表示できません。

14.14 トラブルシューティング

次の各項では、Enterprise Manager/BI Publisherの統合で問題が発生した場合に使用できる一般的な方法を説明します。

14.14.1 configureBIPの再実行

新規のBI Publisher構成中またはBI Publisher構成アップグレードの実行中に、configureBIPの再実行が必要になることがあります。configureBIPコマンドを実行する前に、次のコマンドを使用してBI Publisherを停止します。

emctl stop oms -bip_only

14.14.2 BI Publisherログ・ファイルの場所

次のログ・ファイルを使用すると、問題の発生時点までトレースできます。

14.14.2.1 configureBIPログ・ファイル

場所: ORACLE_HOME(oms)/cfgtoollogs/bip/*

- データベースでのBI Publisherスキーマの作成/アップグレード

- "emBIPLATFORM.log

- "emBIPLATFORMcreate_<date>.log

- "biplatform.log

- "emBIPLATFORMcreate.err

- BI Publisherが統合されたEnterprise Managerドメインの拡張

- "bipca_<date>.log

14.14.2.2 Enterprise Manager BI PublisherツリーおよびEM CLIログ・ファイルの出力

emoms.trc

emoms.log

ログ・ファイル内で「BIP」(すべて大文字)を検索すると、BI Publisher統合に固有のメッセージが見つかります。

14.14.2.3 BI Publisherランタイム

場所: ドメイン・ホーム。たとえば、gc_inst/user_projects/domains/GCDomainなどです。

- servers/BIP/logs/*

- servers/BIP/logs/bipublisher.log

14.14.3 その他のトラブルシューティング

BI Publisherは正常に実行できるが、BI PublisherをEnterprise Managerに登録できない場合は、次を実行すると登録を再試行できます。

emcli login -username=<admin username> -password=<admin password>
emcli sync
emcli setup_bipublisher -proto=http[s] -host=<bip_host> -port=<bip_port>
-uri=xmlpserver

14.14.4 Enterprise Managerが提供するすべてのBI Publisherレポートの再デプロイ

BI Publisherをインストールし、Enterprise Managerで動作するように構成した後でプラグインをインストールすると、次のコマンドを使用して、プラグインに含まれているBI PublisherレポートをEnterprise ManagerのインストールからBI Publisherにデプロイできます。

emcli login –username=sysman
Password: <pw>
emcli sync
emcli deploy_bipublisher_reports –force

この手順は、BI Publisherのレポートが破損した場合のリストアにも使用できます。

14.14.5 BI Publisherのデバッグの有効化

BI Publisherをトラブルシューティングするとき、問題を解決するためにBI Publisherの詳しいデバッグ情報が必要なケースがあります。WebLogic Scripting Tool (WLST)を使用してBIPデバッグを有効化できます。デバッグを有効化すると、前に説明した標準の場所(bipublisher.logなど)に詳しい診断とエラーの情報が送信されます。プライマリBI Publisherサーバーのデバッグを有効化する手順を次に説明します。

注意:
次のコマンド例で、BIPはプライマリBI Publisherサーバーの名前です。デバッグを必要とするBI Publisherサーバーが複数ある場合、BIPを個々のサーバー名(BIP2またはBIP3など)で置き換えます。

BI Publisherのデバッグが終了したら、必ずデバッグを無効にしてください。

14.14.5.1 BI Publisherのデバッグの有効化

1. WLSTを実行する前に、WebLogic Serverがデモンストレーション用の信頼キーストアのCA証明書を信頼するようにWLST環境プロパティを設定します。
Linux sh/bash:

export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=DemoTrust"

Linux csh/tcsh:

setenv WLST_PROPERTIES "-Dweblogic.security.TrustKeyStore=DemoTrust"

Windows:

set WLST_PROPERTIES=-Dweblogic.security.TrustKeyStore=DemoTrust

2. WLSTに接続します。
Linux:

$MW_HOME/oracle_common/common/bin/wlst.sh

Windows:

%MW_HOME%\oracle_common\common\bin\wlst.cmd

3. 次のWLSTセッション例に示すコマンドを実行して、デバッグを有効化します。

...
...
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> connect('weblogic','<pw>','t3s://host:port')
...
...
Successfully connected to Admin Server 'EMGC_ADMINSERVER' that belongs to domain 'GCDomain'.
wls:/GCDomain/serverConfig> setLogLevel(target='BIP',logger='oracle.xdo',level='TRACE:32')
wls:/GCDomain/serverConfig> getLogLevel(logger='oracle.xdo',target='BIP')
TRACE:32
wls:/GCDomain/serverConfig> exit()

14.14.5.2 BI Publisherのデバッグの無効化

BI Publisherのデバッグが終了したら、ログ・レベルをデフォルト設定に戻す必要があります。

1. WLSTに接続します。

2. 次のWLSTセッション例に示すコマンドを実行して、デバッグを無効化します。

wls:/offline> connect('weblogic','<pw>','t3s://host:port')
...
...
Successfully connected to Admin Server 'EMGC_ADMINSERVER' that belongs to domain 'GCDomain'.
wls:/GCDomain/serverConfig> setLogLevel(target='BIP',logger='oracle.xdo',level=' 'WARNING:1')
wls:/GCDomain/serverConfig> getLogLevel(logger='oracle.xdo',target='BIP')
'WARNING:1'

14.15 Enterprise Managerの管理 - BI Publisherの接続資格証明

Enterprise ManagerからBI Publisherにアクセスする場合、レポート定義を取得、表示および管理するために2つの製品間に直接接続が必要です。たとえば、「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。次の図に示すようなEnterprise Manager Cloud Control共有フォルダ内のBI Publisherレポートを示すツリー・ビューが表示されます。

configureBIPスクリプトを実行してEnterprise Managerと統合するようBI Publisherを初めて構成すると、必要な資格証明を持つ専用のWebLogicユーザーがインストールや構成を行うためだけに自動的に作成されます。Enterprise Manager 12c Cloud Controlリリース12.1.0.1以上、これらの資格証明をEMCTLコマンドconfig omsを使用して構成できます。

動詞の構文

emctl config oms -store_embipws_creds [-admin_pwd <weblogic_pwd>] [-embipws_user <new_embipws_username>] [-embipws_pwd <new_embipws_pwd>]

config omsコマンドを使用すると、インストールされているBI Publisher WebサーバーへのアクセスにEnterprise Managerで使用されるパスワードを変更できます。必要に応じてユーザー名も変更できます。config omsコマンドの実行には、WebLogic管理ユーザーのパスワードが必要です。

注意1 - config omsコマンドでは、Enterprise ManagerとBI Publisherの接続に必要なユーザーの資格証明のみ変更します。Enterprise ManagerとBI Publisherの接続の資格証明は、ユーザーによってこれ以外に使用される資格証明と一致する必要があります。たとえば、Enterprise Managerユーザー(データベース認証)、LDAPユーザー、WebLogic Serverユーザーなどです。対応するアプリケーションやコンソールを使用して、インストールされている資格証明ストア内でユーザーの作成や管理を行います。

注意2: このコマンドは、BI Publisherがインストールされている場合にのみ使用できます。

注意3: EMGC_OMSnnnnやBIPnnnnなどの管理対象サーバーを再起動する必要はありません。

WebLogicでサポートされる有効な資格証明は、そのユーザーがEMBIPAdministrators権限も持つ(OPSSまたはLDAP内のいずれか)場合に使用できます。

例: (LDAP資格証明ストアをベースとする)シングル・サインオン(SSO)を使用するようEnterprise Managerを構成したとします。次の手順で、資格証明の更新プロセスを示します。

1. LDAPユーザーを作成します。たとえば、EM_BIP_INTERNAL_USERを作成し、このLDAPユーザーにXYZ123などのパスワードを割り当てます。

2. EM_BIP_INTERNAL_USERをEMBIPADMINISTRATORS LDAPグループのメンバーにします。LDAPグループおよびEnterprise ManagerとBI Publisherの統合の詳細は、第14.8項「基礎となるLDAP認証セキュリティ環境でのEnterprise Manager管理者に対するBI Publisherへのアクセスの許可」を参照してください。

3. EMCTL config omsコマンドを実行します。

emctl config oms -store_embipws_creds -embipws_user EM_BIP_INTERNAL_USER
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
Enter Admin User's Password: <pw>
Enter new password that Enterprise Manager will use to connect to BI Publisher: XYZ123
Successfully updated credentials used by Enterprise Manager to connect to BI Publisher.

EM_BIP_INTERNAL_USERのパスワードを後でLDAPサーバーで変更する場合、-store_embipws_credsオプションを使用してconfig omsコマンドを実行し、このLDAPユーザーのパスワードを変更できます。次の例では、パスワードはABC123に変更されます。

emctl config oms -store_embipws_creds
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
Enter Admin User's Password: <pw>
Enter new password that Enterprise Manager will use to connect to BI Publisher : ABC123
Successfully updated credentials used by Enterprise Manager to connect to BI Publisher.

14.16 BI Publisherサーバーの管理

BI Publisherは、OMSおよびAdminServerを含む同じWebLogicドメインで個別の管理対象サーバーとして動作します。BI Publisherの構成後は、Enterprise Managerのemctlコマンドを使用してBI Publisherを管理することもできます。

使用例:

emctl start oms
Starts the Oracle Application Server components required
to run the Management Service application.
Specifically, this command starts the Oracle HTTP Server,
Oracle Management Service, BI Publisher server and
applications associated with it.

emctl start oms -bip_only
Starts just the BI publisher server.

emctl stop oms [-all] [-force]
Stops Oracle Management Service.
-all :  Additionally Stops BI publisher server and
Admin server
-force : kills the process instead of gracefull shutdown
(not recommended)

emctl stop oms -bip_only [-force]
Stops BI Publisher server only
-force : kills the process instead of gracefull shutdown
(not recommended)

emctl status oms
Displays a message indicating whether Oracle Management
Service and BI Publisher are running.

emctl status oms -bip_only
Displays a message indicating whether BI Publisher is
running.

emctl status oms -details [-sysman_pwd <pwd>]
Displays status of Oracle Management Service. It displays
detailed information which includes :
1) Http and Https upload port for Console and Pbs. and
respective URL.
2) Instance Home Location
3) Oracle Management Service Log directory
4) Software Load Balancer
5) Administration Server machine, port and URL
6) Oracle BI Publisher details
-sysman_pwd : Enterprise Manager SYSMAN Password. If not
provided, you will be prompted for this

14.17 BI Publisherの使用

BI Publisherの使用に関する包括的な情報は、BI Publisherドキュメント・ライブラリを参照してください。

http://www.oracle.com/technetwork/middleware/bi-publisher/documentation/index.html

14.18 Enterprise Manager 12.1.0.4とともにインストールされなかったBI Publisherの削除

重要: Enterprise Manager 12.1.0.4のインストールが完了するまで、この項の手順を開始しないでください。

この章の手順に従ってBI PublisherをEnterprise Manager (12.1.0.2または12.1.0.3)の以前のリリースから12.1.0.4にアップグレードし、Enterprise Managerの以前のリリースにBI Publisher 11.1.1.6も含まれている場合、BI Publisher Oracle Homeの以前のインストールをOMSホームの以前のインストールとともに安全に削除できます。ベスト・プラクティスとしては、以前のBI Publisher Oracleホームと関連するOracleホームも削除することをお薦めします(膨大な量のディスク・スペースを使用するため)。

以前のEnterprise Managerソフトウェアを削除するタイミングおよび様々な削除方法など、Enterprise Managerのアップグレードの詳細は、『Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

15 「コンソール限定モード」でのOMSの稼働

Oracle Management Service (OMS)は、主にコンソール・サービスとバックグラウンド・サービスの2つのタイプのサービスを実行するように設計されています。コンソール・サービスはEnterprise Manager用のGUI豊富なコンソールの表示に必要とされ、バックグラウンド・サービスは重要なジョブ、アップロード操作およびビジネス・ロジックの実行で必要とされます。

図15-1は、コンソール・サービスとバックグラウンド・サービスの両方が実行しているOMSの機能を示しています。

図15-1 コンソール・サービスおよびバックグラウンド・サービスを備えたOMSの機能

複数OMS環境では、ユーザー・インタフェース(UI)操作専用のOMSを備えるか、またはSSA OMSでバックグラウンド・サービスを実行しないようにするために(プライベートまたはパブリック・クラウド環境での外部接続OMS)、バックグラウンド・サービスを停止し、UIサービスのみを実行できます。そのため、OMSを純粋なコンソール限定モードにできます。その場合、管理エージェントはバックグラウンド・サービスとUIサービスの両方が実行している他のOMSインスタンスにデータをアップロードします。ただし、バックグラウンド・サービスを停止したり、リモートの場所にデプロイされるOMSのUIサービスのみを実行することはできないことに注意してください。

注意:

- 追加のOMSインスタンスのみがコンソール限定モードで実行でき、管理サーバーとホストを共有するOMSインスタンスは実行できません。

- 同じ場所にある追加のOMSインスタンスのみがコンソール限定モードで実行でき、リモートの場所にある追加のOMSインスタンスは実行できません。たとえば、USに4つ、Australiaに1つのOMSインスタンスがある場合、AustraliaのOMSはコンソール限定モードで実行できません。

OMSをコンソール限定モードで実行するには、次の手順を実行します。

1. 次のコマンドを使用して、OMSを停止します。
$emctl stop oms

2. 次のコマンドを使用して、起動モードをコンソール専用に設定します。
$emctl config oms -set_startup_mode console_only

3. 次のコマンドを使用してOMSを起動します。
$emctl start oms

OMSインスタンスを標準モードに戻すには、次のコマンドを実行し、OMSを再起動します。

$emctl config oms -set_startup_mode normal

第VI部

Enterprise Managerの高可用性の構成

この部では、Oracle Enterprise Managerインストールを保護できるEnterprise Manager高可用性のベスト・プラクティスおよび戦略について説明します。

- 高可用性ソリューション

- Enterprise Managerの高可用性

- Enterprise Manager障害時リカバリ

- Enterprise Managerのバックアップとリカバリ

- 複数のBI Publisherサーバーの実行

16 高可用性ソリューション

高可用性システムは、実質的に今日のすべてのビジネスの成功に欠かせないものです。それと同時に、これらのミッションクリティカルなシステムを監視する管理インフラストラクチャの可用性が高いことも重要です。Enterprise Manager Cloud Controlのアーキテクチャでは、スケーラビリティと可用性の確保が徹底的に図られています。ビジネスをサポートする資産管理に集中する一方で、ビジネスのサービス・レベル合意を満たすように設計されています。

高可用性のCloud Controlを構成する場合の目的は、システムの各コンポーネントと管理データのフローを保護することです。これは、ホストや管理サービスの障害などのパフォーマンスまたは可用性の問題が起きた場合に備えるためです。

最大可用性アーキテクチャ(MAA)では、Enterprise Managerの各コンポーネントの障害を防ぐことにより、高可用性のEnterprise Managerの実装を実現します。

各種Enterprise Managerコンポーネントの障害による影響は次のとおりです。

- 管理エージェントの障害、または管理エージェントと管理サービス間の通信障害
エージェントによって監視されるターゲットが、Enterprise Managerによって監視されなくなります。

- 管理サービスの障害
Enterprise Managerが停止します。

- 管理リポジトリの障害
Enterprise Managerが停止します。

- ソフトウェア・ライブラリの障害
Enterprise Manager操作の一部が使用不可になります。これらの操作には、自己更新、およびエージェント・デプロイメントを含むプロビジョニングとパッチ適用の操作が含まれます。

全体として、Enterprise Managerのどのコンポーネントに障害が発生した場合も、サービスが大きく中断する可能性があります。したがって、高可用性アーキテクチャを使用して各コンポーネントを強化することが必須になります。

注意:
BI Publisherの高可用性の設定方法については、第20章「複数のBI Publisherサーバーの実行」を参照してください。

16.1 高可用性の最新情報

技術は急速に変化し、高可用性の実装がOracle Enterprise Managerの範囲を超えて拡張しているため、オラクル社の高可用性ソリューションとサードパーティとの統合(F5またはサードパーティ・クラスタウェアなど)に関する最新情報については、次のリソースを定期的に確認する必要があります。

- 次のOracle Maximum Availability ArchitectureのWebサイトを参照してください。
HTTP://www.oracle.com/goto/maa

- Enterprise Manager 12cフレームワークおよびインフラストラクチャに関するWebサイト
HTTP://www.oracle.com/technetwork/oem/frmwrk-infra-496656.html

16.2 高可用性の定義

Oracle Enterprise Managerの柔軟性の高い分散アーキテクチャにより、広範囲のデプロイメント構成が可能になるため、ビジネスの監視ニーズと管理ニーズを満たすだけでなく、ビジネス・ニーズの指示に従った拡張が可能になります。

このため、Enterprise Managerの高可用性を単一の実装として範囲を狭めて定義することはできませんが、使用可能なリソース、Oracleのテクノロジ、およびITインフラストラクチャへの投資を保護するベスト・プラクティスに基づく保護レベルの範囲で定義できます。Enterprise Managerのデプロイメントおよびビジネス・ニーズに応じて、ビジネスの維持に必要な高可用性のレベルを実装できます。Enterprise Managerの高可用性は、4つのレベルに分類できます。各レベルは、これまでの、拡大する実装コストや複雑さだけでなく、徐々に増加する可用性のレベルに基づきます。

16.2.1 高可用性のレベル

高可用性ソリューションの各レベルは、ビジネス要件と使用可能なITリソースで左右されます。しかし、このレベルは、使用可能な様々なオプションを示すのに便利な、可能なデプロイメントのサブセットを表していることに注意することが重要です。IT組織は、いずれかのレベルに正確に一致する必要のない、独自の構成をデプロイする可能性があります。

次の表に、Oracle Enterprise Managerインストールの4つの高可用性レベルの例を、一般的なリソース要件とともにまとめています。

表16-1 Enterprise Managerの高可用性レベル

レベル

説明

最小ノード数

推奨ノード数

ロード・バランサの要件

レベル1

OMSおよびリポジトリ・データベース。それぞれが固有のホストにフェイルオーバーなしで存在する。

1

2

なし

レベル2

共有記憶域にVIPベースのフェイルオーバーありでインストールされているOMS。データベースはローカルのData Guardを使用している。

2

4

なし

レベル3

OMSはアクティブ/アクティブ構成。データベースはRACとローカルのData Guardを使用している。

3

5

ローカル・ロード・バランサ

レベル4

アクティブ/アクティブ構成のプライマリ・サイトのOMS。リポジトリOracle RACを使用してデプロイされている。

スタンバイ・サイトに重複したハードウェアがデプロイされている。

OMSおよびソフトウェア・ライブラリのDRは、プライマリおよびスタンバイ・サイト間の記憶域レプリケーションを使用している。

データベースDRはOracle Data Guardを使用している。

注意: レベル4はMAAベスト・プラクティスで、最も費用効率が高く、シンプルなアーキテクチャで、最も高い可用性を達成します。

4

8

必須: サイトごとのローカル・ロード・バランサ。

オプション: グローバル・ロード・バランサ

16.3 可用性レベルの比較

次の表で、各HAレベルの保護レベルと復旧時間を比較します。

表16-2 保護の高可用性レベル

レベル

OMSホスト障害

OMSストレージ障害

データベース・ホスト障害

データベース・ストレージ障害

サイト障害/障害復旧

レベル1

いいえ

いいえ

いいえ

いいえ

いいえ

レベル2

はい

いいえ

はい

はい

いいえ

レベル3

はい

はい

はい

はい

いいえ

レベル4

はい

はい

はい

はい

はい

表16-3 高可用性レベルの復旧時間

レベル

ノード障害

ローカル・ストレージ障害

サイト障害

費用

レベル1

数時間から数日

数時間から数日

数時間から数日

$

レベル2

数分

数時間から数日

数時間から数日

$$

レベル3

停止なし

数分

数時間から数日

$$$

レベル4

停止なし

数分

数分

$$$$

この表に示されていない1つの基準はスケーラビリティです。レベル3と4には、ビジネス・ニーズの拡大に応じてEnterprise Managerのインストールを拡大する機能があります。RACデータベースとして実行しているリポジトリは、RACクラスタに新しいノードを追加することで容易に拡張できるので、OMSサーバーを追加するだけで、管理サービス層を拡大することができます。

スタンバイ・デプロイメントへのフェイルオーバー時にパフォーマンスを平準化する必要がある場合は、ローカル・スタンバイ・データベース、またはスタンバイRACデータベースおよびスタンバイOMSサーバーを含むレベル4スタンバイ・サイトのいずれであっても、デプロイメントのサイズが両方のサイトで対称的であることが重要です。これは特に、プライマリまたはセカンダリ・サイトで長時間アクティブに実行する計画フェイルオーバー・ルーチンを実行する場合に当てはまります。たとえば、一部の金融機関では、操作手順の一部としてこれを義務付けています。

プライマリ・サイトの損失時に生存性が必要な場合、レベル4のアーキテクチャで稼働する必要があります。

16.4 高可用性レベルの実装

エンタープライズに対し高可用性要件を決定したら、環境に適したいずれかの高可用性レベルの実装を開始する準備ができました。次の情報ロードマップを使用して、各レベルの実装手順を参照します。

レベル

情報を探す場所

レベル1

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

レベル2

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

- 仮想ホスト名を使用したHAフェイルオーバーのアクティブ/パッシブ環境でのCloud Control OMSの構成

- 管理リポジトリのためのスタンバイ・データベースの構成

レベル3

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

- Oracle Management Serviceの高可用性

- ロード・バランサの構成

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

- 追加の管理サービスのインストール

- 管理リポジトリのためのスタンバイ・データベースの構成

レベル4

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

- 管理リポジトリのためのスタンバイ・データベースの構成

- 管理サービスの障害時リカバリ

17 Enterprise Managerの高可用性

この章では、各Cloud Controlコンポーネントのインストールおよび構成に関するベスト・プラクティスについて説明し、次の項目を含みます。

- エージェントの高可用性

- リポジトリの高可用性

- Oracle Management Serviceの高可用性

17.1 エージェントの高可用性

次の各項では、管理エージェントのインストールおよび構成に関するベスト・プラクティスについて説明します。

17.1.1 ブート時の起動および障害時の再起動を自動的に行う管理エージェントの構成

管理エージェントは手動で起動されます。管理対象ホスト上の重要なリソースが確実に監視されるように、ホストの起動時に管理エージェントが自動的に起動することが重要です。そのためには、あらゆるオペレーティング・システムのメカニズムを使用して、管理エージェントが自動的に開始するようにします。たとえば、UNIXシステムでは起動時に管理エージェントを呼び出すエントリをUNIXの/etc/init.dに配置することにより、またはWindowsサービスを自動的に開始するように設定することにより、これを行います。

17.1.2 管理エージェントの再起動の構成

管理エージェントを起動すると、ウォッチドッグ・プロセスは管理エージェントを監視し、障害が発生した場合にエージェントの再起動を試みます。ウォッチドッグの動作は、管理エージェント・プロセスの開始前に設定される環境変数で制御します。この動作を制御する環境変数は次のとおりです。ここで説明するテストはすべて、デフォルトの設定で行われました。

- EM_MAX_RETRIES - ウォッチドッグがEM_RETRY_WINDOW内で管理エージェントの再起動を試行する最大回数。デフォルトでは、管理エージェントを3回再起動します。

- EM_RETRY_WINDOW - EM_MAX_RETRIES環境変数と一緒に使用される時間間隔(秒単位)。管理エージェントを再起動するかどうかを判断します。デフォルトは600秒です。

ウォッチドッグが、EM_RETRY_WINDOW期間内でEM_MAX_RETRIESの回数を超えた管理エージェントの再起動が必要であることを検出すると、管理エージェントは再起動されません。

17.1.3 冗長記憶域への管理エージェント・ソフトウェアのインストール

管理エージェントは、エージェントの状態ディレクトリのローカル・ファイルを使用して、その構成と中間状態、および収集された情報を保持します。

これらのファイルが管理リポジトリにアップロードされる前に損失または破損した場合、監視データの損失や、管理リポジトリにアップロードされていない保留中のアラートが発生します。

このような損失を防ぐために、冗長記憶域でエージェントの状態ディレクトリを構成します。エージェントの状態ディレクトリは、コマンド$AGENT_HOME/agent_inst/bin/emctl getemhomeを入力するか、Cloud Controlコンソールのエージェントのホームページで確認できます。

17.2 リポジトリの高可用性

次の項では、リポジトリ構成に関するベスト・プラクティスについて説明します。

17.2.1 リポジトリの高可用性に関する一般的なベスト・プラクティス

Enterprise Managerをインストールする前に、管理リポジトリの設定に使用されるデータベースを準備する必要があります。Database Configuration Assistant (DBCA)を使用してデータベースをインストールし、Oracleインストールのすべてのベスト・プラクティスを継承することを確認します。

- 基本となるストレージ・テクノロジとして「自動ストレージ管理(ASM)」を選択します。

- ARCHIVELOGモードの有効化

- ブロック・チェックサムの有効化

- REDOログ・ファイルのサイズおよびグループの適切な構成

- フラッシュ・リカバリ領域の使用

- フラッシュバック・データベースの有効化

- ファスト・スタート・フォルト・リカバリを使用したインスタンス・リカバリ時間の制御

- データベース・ブロック・チェックの有効化

- DISK_ASYNCH_IOの設定

管理リポジトリへの適用が必要な高可用性の推奨事項については、MAAアドバイザを使用します。MAAアドバイザにアクセスするには、リポジトリ・データベースのホームページで「可用性」→「MAAアドバイザ」の順に選択します。

管理リポジトリをホストするデータベースが必要な可用性を実現するように構成するための、これらのベスト・プラクティスおよび他のベスト・プラクティスの詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

17.2.2 管理リポジトリに対するRACの構成

管理リポジトリがReal Application Cluster(RAC)データベースの場合、適切な接続文字列を使用して管理サービスを構成する必要があります。SCAN接続文字列で、リポジトリ層でのノードの追加または削除後に、リポジトリ接続記述子の再構成が必要にならないようにすることを推奨します。接続文字列では常に、SID_NAMEではなくSERVICE_NAMEが使用されるようにします。

詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

次の例に、データベース・バージョンが11gリリース2より前である場合のリポジトリの接続文字列を示します。

(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))

次の例に、データベース・バージョンが11gリリース2以上である場合のリポジトリの接続文字列を示します。

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary-cluster-scan.example.com)(PORT=1521))(CON
NECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=PDB.example.com)))

リポジトリ接続記述子は、管理サービスからemctlコマンドを実行して構成します。複数の管理サービスを構成した場合、このコマンドは各管理サービスで実行される必要があります。

emctl config oms -store_repos_details -repos_conndesc '(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))' -repos_user sysman

リポジトリ接続記述子を更新した後、任意のOMSから次のコマンドを実行して、管理サービスとリポジトリ・ターゲットに使用される監視構成に同じ変更を加えます。

emctl config emrep -conn_desc <repository_connect descriptor as above>

17.3 Oracle Management Serviceの高可用性

次の各項では、OMSの高可用性の構成について説明します。

OMSの高可用性を実現するには、まず、少なくとも1つのOMSを常に使用可能な状態にします。リカバリ時間目標(RTO)によって異なりますが、アクティブ/アクティブ構成では、少なくとも1つの追加OMSを追加することで、ノードの損失に伴う停止時間なしにこれを実現することができます。または、プライマリ・サーバーで障害が発生したときに別のサーバーの同じアドレスでOMSが実行できるようにすることで、アクティブ/パッシブ構成ではノードの損失に伴う停止時間が短縮します。高可用性を実現するアーキテクチャに関するオプションの詳細は、第16章「高可用性ソリューション」を参照してください。

障害時リカバリを含む、さらに高度な可用性レベルに将来移行できるように、環境を最適に準備するために実行できる手順がいくつもあります。これらは、高可用性を得るために選択した方法や、インストール時に最初に選択した可用性レベルには関係ありません。これらの手順の詳細は、「別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSを構成するためのベスト・プラクティス」を参照してください。

OMSの高可用性を保証するには、Enterprise Managerによって管理される環境のサイズと範囲およびEnterprise Managerの使用方法の規模と複雑さ(管理者の数や利用される機能の種類など)に対応できるように十分な数のOMSも必要です。可用性を構成および監視する方法や、運用状況に基づいて必要なOMS数を決定する方法の詳細は、My Oracle Supportノート1940179.1の『EM運用の考慮事項およびトラブルシューティングに関するホワイトペーパー・マスター索引』を参照してください。

環境の十分なキャパシティを保証するため、またはパッシブOMSへのフェイルオーバーに伴う停止時間を防ぐために、環境に複数のアクティブなOMSが必要な場合は、サーバー・ロード・バランサ(SLB)が必要です。SLBは、管理エージェントと管理者が一連のOMSサーバーと通信するための1つのアドレスを提供し、どのOMSが使用可能かを識別するためにOMSを監視して、使用可能なOMSに通信をルーティングします。

SLBの実装にはコストがかかる場合があります。環境の1つのOMSで処理要件に対処できる場合、さらにOMSのアクティブ/パッシブ・フェイルオーバーに伴う停止時間がRTO要件を満たす場合は、高可用性を提供するためにSLBは必要ありません。「仮想ホスト名を使用したHAフェイルオーバーのアクティブ/パッシブ環境でのCloud Control OMSの構成」の手順は、仮想IPアドレスと共有記憶域を使用して高可用性を構成する方法の例を示しています。

環境のRTOまたは処理ニーズに対処するために、1つ以上のOMSを追加する必要がある場合は、「追加の管理サービスのインストール」を参照してください。OMSを追加した場合は、SLBに対して複数のOMSの構成方法を確認するために、「サーバー・ロード・バランサ(SLB)の内側への複数の管理サービスの構成」を参照してください。

17.3.1 別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSを構成するためのベスト・プラクティス

この項では、別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSをインストールする、Cloud Control管理者のためのベスト・プラクティスを説明します。将来、障害時リカバリが必要になった場合、これらのベスト・プラクティスによって実装に必要な手順が少なくなります。これらのベスト・プラクティスは、すべてのMAA高可用性レベルのインストールに対応します。最高のMAA高可用性レベルのニーズを考慮してスタンドアロンOMSをインストールすると、最大限の柔軟性が得られ、将来的にさらに上のMAA高可用性レベルに簡単に移行することができます。

17.3.1.1 概要および要件

Cloud Control OMSインストールが、別名ホスト名と記憶域レプリケーションを使用する障害時リカバリをサポートするためには、次のインストール条件を満たす必要があります。

- ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリが、スタンバイ・サイトにレプリケートできる記憶域レプリケーションにインストールされている必要があります。

- OMSのインストールは、OMSのプライマリ・サイト・ホストおよびスタンバイ・サイト・ホストと同じ別名ホスト名が維持されるような方法で実行する必要があります。別名ホスト名を使用してソフトウェアを構成すると、プライマリ・サイトまたはスタンバイ・サイトどちらのOMSホストでも変更なしで同じバイナリと構成を使用できます。

- ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースが、スタンバイ・サイトにレプリケートできる記憶域に、Oracleインベントリの場所を使用してインストールされる必要があります。

- ソフトウェア所有者とタイムゾーンのパラメータを、該当のOracle Management Service(OMS)をホストするすべてのノードで同じにする必要があります。

- ミドルウェア、インスタンス、OMSエージェントおよびOracleインベントリ・ディレクトリへのパスは、このOMSをホストするすべてのノードで同じである必要があります。

17.3.1.2 ORACLE_BASEでのOMSインストール・ベース・ディレクトリの作成

障害時リカバリをサポートするには、ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリが、スタンバイ・サイトにレプリケートできる記憶域にインストールされている必要があります。これらのそれぞれのディレクトリは、従来はORACLE_BASEの直下に配置されました。OMSを一度インストールすると、ディレクトリ・パスを変更することはできません。このようにディレクトリそれぞれがORACLE_BASEの直下にあるインストールをレプリケートされた記憶域に後から移行すると、インストール済ソフトウェアの元のディレクトリ・パスを維持するためにORACLE_BASEをレプリケートされた記憶域に再配置する必要が生じ、そのパスの下にローカルにインストールされているソフトウェアをアンインストールしてから別のローカル・ストレージ・ディレクトリに再インストールしなければならなくなるなど、複雑になることがあります。

記憶域を将来移行する際の柔軟性を最大限にするためには、1つのディレクトリをORACLE_BASEの下に作成して、すべてのOMSソフトウェア(ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリなど)のベース・ディレクトリとして使用します。たとえば、ORACLE_BASEが/u01/app/oracleの場合は、新しいOMSインストールのベース・ディレクトリを/u01/app/oracle/OMSのように作成します。このディレクトリは、レプリケートされた記憶域のマウント・ポイントになります。ソフトウェアをこのディレクトリにローカルにインストールした場合、このディレクトリをレプリケートされた記憶域の1つのマウント・ポイントにすることができ、単純な移行が可能になります。OMSのインストール時にディレクトリの場所を指定または確認する際に、ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリがこのディレクトリの下にインストールされるように確認します。

17.3.1.3 別名ホスト名の構成

障害時リカバリをサポートするには、プライマリ・サイトのホストとスタンバイ・サイトのホストが、OMSインストールで使用されているのと同じホスト名で稼働できることが必要です。これは、別名ホスト名を使用して実現できます。

第18章「ホスト名の計画」のガイダンスを使用して、インストールで使用する別名ホスト名を構成します。オプション2: この項に示された両方のサイトの別名ホスト名は、最大の柔軟性を実現できるため、新しくインストールする際のベスト・プラクティスとして推奨されます。

オプション2を実施するには、OMSをインストールするときに、ORACLE_HOSTNAME=<ALIAS_HOST_NAME>パラメータを指定するか、OUIインストールの「ホスト名」フィールドに別名ホスト名を指定します。たとえば、runInstallerコマンドラインに次のパラメータを含めます。

ORACLE_HOSTNAME=oms1.example.com

17.3.1.4 OMSインストール・ベース・ディレクトリに配置されたOracleインベントリの構成

障害時リカバリをサポートするには、レプリケートされた記憶域を使用するプライマリ・サイトのホストとスタンバイ・サイトのホストによって1つのOMSインストールを共有します。レプリケートされた記憶域にはアクティブなOMSのみがマウントされます。場合によっては、プライマリ・サイトまたはスタンバイ・サイトのいずれかがアクティブ・サイトになっているときに、ソフトウェア保守アクティビティを実行する必要があります。そのような場合に、インストールの詳細を含むOracleインベントリを両方の場所から使用できることが重要です。

ローカルOracleインベントリからレプリケートされた記憶域のOracleインベントリへOMSインストールを移動するための手動移行アクティビティを実行せずにすむように、OracleインベントリをOMSインストール・ベース・ディレクトリに作成します。

次の手順を実行して、OMSインストール・ベース・ディレクトリ内に配置したインベントリを設定するようにインストーラを準備します。

1. OMSインストール・ベース・ディレクトリを作成します。

2. Oracleインベントリ・ディレクトリを新しいOMSインストール・ベース・ディレクトリ内に作成します。
$ cd <OMS installation base directory>

$ mkdir oraInventory

3. oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なOracleインベントリ・ディレクトリのパス情報が含まれます。
$ cd oraInventory

$ vi oraInst.loc

Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。次に例を示します。

inventory_loc=/u01/app/oracle/OMS/oraInventory

inst_group=oinstall

OMSをインストールする際に、-invPtrloc <oraInst.loc file with path>パラメータを次のようにrunInstallerコマンドラインに指定して、OracleインベントリをOMSインストール・ベース・ディレクトリに指定します。

-invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc

インストーラによって、指定の場所にインベントリが作成されます。このOMSおよびOMSエージェントのすべてのインストール、パッチ適用およびアップグレード・アクティビティにこのインベントリを使用します。

17.3.1.5 すべてのノードでのソフトウェア所有者とグループの同一構成

プライマリ・サイトに複数のOMSをインストールする際に、同じソフトウェア所有者とグループを使用するように、障害時リカバリに対応するために、スタンバイ・サイトのOMSホストでもソフトウェア所有者とグループを同じように構成する必要があります。プライマリ・サイトのために選択した所有者名およびIDとグループ名およびIDを、スタンバイ・サイトでも使用できるようにしてください。

ソフトウェア所有者のユーザーとグループの構成がすべてのOMSノードで同一であることを確認するには、次の例のようにidコマンドを実行します。

$ id -a

uid=550(oracle) gid=50(oinstall) groups=501(dba)

17.3.1.6 すべてのノードで同様に構成にするタイムゾーンの選択

プライマリ・サイトに複数のOMSをインストールする際に、同じタイムゾーンを使用するように、障害時リカバリに対応するために、スタンバイ・サイトのOMSホストでもタイムゾーンを同じように構成する必要があります。両方のサイトで使用できるタイムゾーンを選択して、すべてのOMSホストでタイムゾーンが同一になるようにします。

17.3.1.7 インストールおよび構成

次に、この項で説明したベスト・プラクティスを促進するインストール手順の概要を示します。必要な前提条件やインストール後の追加の作業など、インストール手順の詳細は、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。

NFSがマウントされたボリュームをインストールに使用する場合、マウント・コマンドでrsizeとwsizeを指定してI/O問題の発生を防止します。

次に例を示します。

nas.example.com:/export/share1 /u01/app/oracle/OMS nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noacl,vers=3,timeo=600 0 0

注意:
その他の重要なNFS関連の要件は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のNFSマウント・ポイントの場所の要件に関する項を参照してください。

ソフトウェアをインストールする場合は次の手順を参照してください。

1. ORACLE_BASEにOMSインストール・ベース・ディレクトリを作成します。レプリケートされた記憶域にここでインストールする場合は、レプリケートされた記憶域をこのディレクトリにマウントしてください。

2. 各OMSホストにインストールするすべてのOMSの別名ホスト名を構成します。

3. すべてのホストで同じ定義になるようにソフトウェア所有者とグループを構成します。

4. すべてのホストで同じ設定になるようにタイムゾーンを構成します。

5. 『Enterprise Manager基本インストレーション・ガイド』のEnterprise Managerシステムのインストールに関する項を参照して、詳しい準備とインストールの手順に従います。インストール・プロセスでは次の情報を指定します。

1. ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースがOMSインストール・ベース・ディレクトリ内に配置されるように確認します。

2. インベントリの場所のファイルとOMSの別名ホスト名を指定します。これらは、コマンドラインに次の例のように指定できます。
$ runInstaller -invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=oms1.example.com

Enterprise ManagerのrunInstaller UIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。

6. 引き続きインストールの残りの手順を実行します。

17.3.2 仮想ホスト名を使用したHAフェイルオーバーのアクティブ/パッシブ環境でのCloud Control OMSの構成

この項では、コールド・フェイルオーバー・クラスタ(CFC)環境でEnterprise Manager Cloud Controlを構成するCloud Control管理者向けの一般的な情報を提供します。

17.3.2.1 概要および要件

Cloud Controlが別のホストにフェイルオーバーするには、次の条件を満たす必要があります。

- インストールは、仮想ホスト名と関連する一意のIPアドレスを使用して行います。

- バイナリおよびgc_instディレクトリを保持する共有ディスクやボリュームにインストールします。

- 稼働中のノードにインベントリの場所をフェイルオーバーします。

- ソフトウェア所有者とタイムゾーンのパラメータは、該当のOracle Management Service(OMS)をホストするクラスタ・メンバーのすべてのノードで同じにします。

17.3.2.2 インストールおよび構成

クラスタ・メンバーの物理ホスト名を仮想ホスト名でオーバーライドするには、パラメータORACLE_HOSTNAMEを使用してソフトウェアをインストールする必要があります。

コマンドライン・パラメータ-invPtrLocを使用して、共有インベントリの場所のファイルを指し示すようにソフトウェアをインストールする必要があります。このファイルには、共有インベントリの場所のパスがあります。

NFSがマウントされたボリュームをインストールに使用する場合、マウント・コマンドでrsizeとwsizeを指定してI/O問題の発生を防止します。

次に例を示します。

nas.example.com:/export/share1 /u01/app/share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0

注意:
共有フェイルオーバー・ボリュームについては、フェイルオーバー後にアクティブなホストにマウントできる非共有フェイルオーバー・ボリュームにも当てはまります。

17.3.2.3 仮想ホスト名/仮想IPアドレスの設定

仮想ホスト名と仮想IPアドレスを設定するには、クラスタウェアで設定できるようにするか、Oracleサービスのインストールおよび起動前にユーザー自身が手動で設定します。仮想ホスト名は静的にして、ネットワークで常に解決できるようにします。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteなどの標準のTCPツールを使用してホスト名を検証できます。次のコマンドを使用して検証します。

nslookup <virtual hostname>

このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。

nslookup <virtual IP>

このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。

必ずクラスタのすべてのノードでこれらのコマンドを実行し、正しい情報が返されることを検証します。

17.3.2.4 共有記憶域の設定

共有記憶域は、使用しているクラスタウェアで管理するか、あるいは、NFSなどの共有ファイルシステム(FS)ボリューム(OCFS V1などのサポート対象外のタイプを除く)を使用できます。

注意:
OCFS V1のみ、サポート対象外です。OCFSの他のすべてのバージョンがサポートされます。

OHSディレクトリが共有記憶域上にある場合、ローカル・ディスクを指し示すようにhttpd.confファイルのLockFileディレクティブを変更する必要があります。変更しない場合、ロック問題が発生する可能性があります。

17.3.2.5 環境の設定

一部のバージョンのオペレーティング・システムでは、12cをインストールする前に特定のオペレーティング・システム・パッチを適用する必要があります。ユーザーが12cソフトウェアをインストールして使用するには、十分なカーネル・リソースも使用できるようにしておく必要があります。詳細は、オペレーティング・システムのインストール・ガイドを参照してください。インストーラを起動する前に、特定の環境変数を検証する必要があります。各変数は、クラスタに参加するすべてのマシンにソフトウェアをインストールしているアカウントに対して同一に設定する必要があります。

- OS変数TZ
タイムゾーン設定。インストール前にこの変数の設定を解除してください。

- PERL変数
PERLライブラリの不正なセットへの関連付けが行われないように、PERL5LIBなどの変数の設定も解除してください。

17.3.2.6 オペレーティング・システムIDの同期化

ソフトウェア所有者のユーザーとグループは、クラスタのすべてのノードで同一に定義する必要があります。これは次のidコマンドを使用して検証できます。

$ id -a

uid=550(oracle) gid=50(oinstall) groups=501(dba)

17.3.2.7 共有インベントリの設定

次の手順で共有インベントリを設定します。

1. 新しいORACLE_HOMEディレクトリを作成します。

2. 新しいORACLE_HOMEにOracleインベントリ・ディレクトリを作成します。
$ cd <shared oracle home>

$ mkdir oraInventory

3. oraInst.locファイルを作成します。このファイルには、Universal Installerで必要なOracleインベントリ・ディレクトリのパス情報が含まれます。
vi oraInst.loc

Oracleインベントリ・ディレクトリのパス情報を入力し、ソフトウェア所有者のグループをoinstallユーザーとして指定します。次に例を示します。

inventory_loc=/app/oracle/share1/oraInventory

inst_group=oinstall

17.3.2.8 ソフトウェアのインストール

ソフトウェアをインストールする場合は次の手順を参照してください。

1. ソフトウェア・バイナリの両方のノードで共有ディスクの場所を作成します。

2. インベントリの場所のファイルoraInst.loc(この場合はORACLE_BASEの下)を指し示し、仮想グループのホスト名を指定します。次に例を示します。
$ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.example.com -debug

Enterprise ManagerのrunInstaller UIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。

3. Oracle Management Serviceをクラスタ・メンバーのHost1にインストールします。

4. 引き続きインストールの残りの手順を通常どおりに実行します。

5. 完了したら、ファイルoraInst.locおよびoratabをすべてのクラスタ・メンバー・ホスト(Host2、Host3など)の/etcにコピーします。

17.3.2.9 サービスの起動

サービスは必ず正しい順序で起動してください。次の順序で行います。

1. アクティブなノードでIPアドレスを設定します。

2. TNSリスナー(同じフェイルオーバー・グループに含まれる場合)を起動します。

3. データベース(同じフェイルオーバー・グループに含まれる場合)を起動します。

4. emctl start omsを使用してCloud Controlを起動します。

5. 機能をテストします。

フェイルオーバーの場合は、「スイッチオーバーおよびフェイルオーバー操作の実行」を参照してください。

17.3.3 追加の管理サービスのインストール

追加の管理サービスをインストールするには次の2つの方法があります。

- Oracle Management Serviceの追加デプロイメント・プロシージャの使用(推奨)。デプロイメント・プロシージャの使用の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のOracle Management Serviceの追加に関する章を参照してください。

- サイレント・モードでの追加のOracle Management Serviceのインストール(代替策)。サイレント・モードでのインストールの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のサイレント・モードでの追加のOMSのインストールに関する説明を参照してください。

17.3.4 サーバー・ロード・バランサ(SLB)の内側への複数の管理サービスの構成

次の各項では、サーバー・ロード・バランサを使用してアクティブ/アクティブ構成でOMSの高可用性を構成する方法について説明します。

17.3.4.1 ソフトウェア・ライブラリの構成

ソフトウェア・ライブラリの場所は、すべてのアクティブな管理サービスからアクセスできる必要があります。ソフトウェア・ライブラリがインストール中に構成されない場合、Enterprise Managerコンソールを使用してインストール後に構成する必要があります。

1. Enterprise Managerのホームページで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。

2. 「プロビジョニング」サブタブをクリックします。

3. 「プロビジョニング」ページで「管理」サブタブをクリックします。

4. 「ソフトウェア・ライブラリ構成」セクションで「追加」をクリックして、「ソフトウェア・ライブラリのディレクトリの場所」を、管理サービス・ホストからアクセス可能な共有記憶域に設定します。

17.3.4.2 ロード・バランサの構成

この項では、使用可能な管理サービスにエージェントとブラウザのトラフィックを分散するサーバー・ロード・バランサ(SLB)を設定するためのガイドラインについて説明します。

サーバー・ロード・バランサの要件

SLBの背後にアクティブ/アクティブ構成でOMSを構成するために、SLBは次の要件を満たす必要があります。

- SLBは複数の仮想サーバー・ポートをサポートする必要があります。
構成によっては、SLBで最大5ポートが必要になる場合があります(セキュア・アップロード、エージェント登録、セキュア・コンソール、非保護コンソール、BI Publisher)。

- 永続性のサポート。
ブラウザとOMS間のHTTPおよびHTTPSトラフィックには永続性が必要です。

- アプリケーションの監視のサポート。
SLBはOMSの状態の監視と、障害の検知が可能である必要があるので、リクエストが使用できないOMSに転送されることはありません。

SLBの構成には次の2つの手順があります。

1. SLBを構成します。

2. 管理サービスで必要な変更の追加

17.3.4.2.1 SLB側の設定

次の表を参考にしてCloud Control管理サービスでSLBを設定します。

表17-1 管理サービスのポート

Cloud Controlサービス

TCPポート

モニター名

永続性

プール名

ロード・バランシング

仮想サーバー名

仮想サーバー・ポート

セキュア・アップロード

1159

mon_gcsu4900

なし

pool_gcsu4900

ラウンド・ロビン

vs_gcsu4900

1159

エージェント登録

4889

mon_gcar4889

有効なCookie挿入

pool_gcar4889

ラウンド・ロビン

vs_gcar4889

4889

セキュア・コンソール

7799

mon_gcsc7799

ソースIP

pool_gcsc7799

ラウンド・ロビン

vs_gcsc443

443

非保護コンソール(オプション)

7788

mon_gcuc7788

ソースIP

pool_gcuc7788

ラウンド・ロビン

vs_gcuc80

80

SLBにパッケージされている管理ツールを使用します。サンプル構成が付属しています。この例では、表33-1に示すデフォルトのポートを使用してホストAおよびホストBで2つの管理サービスが実行していると仮定します。

1. プールの作成
プールは、ロード・バランシング方法を使用して特定のTCPポートでトラフィックを受信するためにグループ化された一連のサーバーです。各プールには、永続性の定義の独自の特性と、使用されるロード・バランシング・アルゴリズムがあります。

表17-2 プール

プール名

使用方法

メンバー

永続性

ロード・バランシング

pool_gcsu4900

セキュア・アップロード

ホストA: 4900 ホストB: 4900

なし

ラウンド・ロビン

pool_gcar4889

エージェント登録

ホストA: 4889 ホストB: 4889

アクティブなcookie挿入、有効期限は60分

ラウンド・ロビン

pool_gcsc7799

保護されたコンソールへのアクセス

ホストA: 7799 ホストB: 7799

ソースIP、有効期限は60分

ラウンド・ロビン

pool_gcuc7788(オプション)

非保護コンソールへのアクセス

ホストA: 7788 ホストB: 7788

ソースIP、有効期限は60分

ラウンド・ロビン

2. 仮想サーバーの作成
仮想サーバー(仮想IPアドレスとポート番号を含む)は、クライアントのアドレス可能なホスト名またはIPアドレスであり、これによって、クライアントはロード・バランシング・プールのメンバーを利用できます。仮想サーバーがリクエストを受信すると、選択したロード・バランシング方法に基づいてそのリクエストをプールのメンバーに誘導します。

表17-3 仮想サーバー

仮想サーバー名

使用方法

仮想サーバー・ポート

プール

vs_gcsu4900

セキュア・アップロード

4900

pool_gcsu4900

vs_gcar4889

エージェント登録

4889

pool_gcar4889

vs_gcsc443

保護されたコンソールへのアクセス

443

pool_gcsc7799

vs_gcuc80(オプション)

非保護コンソールへのアクセス

80

pool_gcuc7788

3. モニターの作成
モニターは、プール・メンバーの動作状況を検証する場合に使用されます。モニターは、ロード・バランシング・プールのメンバーであるノード上の接続やサービスを検証します。これは、規定の間隔でサービスのステータスを断続的に確認するように設計されます。確認するサービスが指定時間内に応答しない場合、ロード・バランサはプールから自動的にそのサービスを取り出し、プールの他のメンバーを選択します。ノードやサービスが再度使用可能になると、モニターはその状況を検出し、プールから自動的にアクセス可能なメンバーがトラフィックを処理できます。

表17-4 モニター

モニター名

構成

関連ホスト

mon_gcsu4900

タイプ: https

間隔: 60

タイムアウト: 181

送信文字列: GET /empbs/upload

受信文字列: Http Receiver Servlet active!

ホストA: 4900 ホストB: 4900

mon_gcar4889

タイプ: http

間隔: 60

タイムアウト: 181

送信文字列: GET /empbs/genwallet

受信文字列: GenWallet Servlet activated

ホストA: 4889 ホストB: 4889

mon_gcsc7799

タイプ: https

間隔: 5

タイムアウト: 16

送信文字列: GET /em/consoleStatus.jsp

受信文字列: Enterprise Manager Console is UP

ホストA: 7799 ホストB: 7799

mon_gcuc7788(オプション)

タイプ: http

間隔: 5

タイムアウト: 16

送信文字列: GET /em/consoleStatus.jsp

受信文字列: Enterprise Manager Console is UP

ホストA: 7788 ホストB: 7788

mon_gcscbip7799

タイプ: https

間隔: 5

タイムアウト: 16

送信文字列: GET /xmlpserver/services

受信文字列: getDocumentData

ホストA: 7799 ホストB: 7799

mon_gcucbip7788

タイプ: https

間隔: 5

タイムアウト: 16

送信文字列: GET /xmlpserver/services

受信文字列: getDocumentData

ホストA: 7799 ホストB: 7799

注意:
一部のロード・バランサでは、リテラル\r\nを使用して送信文字列に明示的に追加するには、<CR><LF>文字が必要です。これはベンダー固有です。詳細は、SLBのドキュメントを参照してください。

17.3.4.2.2 Enterprise Manager側の設定

次の手順を実行してください。

1. Oracle Management Serviceの再保護
デフォルトでは、管理サービス側証明書のサービス名は、管理サービス・ホストの名前を使用します。管理エージェントは、ロード・バランサ経由でOracle Management Serviceと通信する場合、この証明書を受け入れません。次のコマンドを実行して、各管理サービスで証明書を再生成する必要があります。

emctl secure oms
-host slb.example.com
-secure_port 4900
-slb_port 4900
-slb_console_port 443
-console
[-lock]  [-lock_console]

出力例:

Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
Securing OMS... Started.
Enter Enterprise Manager Root (SYSMAN) Password :
Enter Agent Registration Password :
Securing OMS... Successful
Restart OMS

2. すべての管理エージェントを再保護します。
SLB設定の前にインストールされた管理エージェント(管理サービス・インストールに付属する管理エージェントなど)は、管理サービスに直接アップロードしています。これらの管理エージェントは、SLBの設定後にアップロードできません。これらの管理エージェントを再保護してSLBにアップロードするには、各管理エージェントで次のコマンドを実行します。

emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em

17.3.4.2.3 Enterprise ManagerおよびSLB (リリース12.1.0.2以降)のSSLの構成

SLBを構成してサード・パーティ/カスタムSSL証明書を使用する場合、エージェント、SLBおよびOMSの間の信頼関係を維持するためにCA証明書が適切に構成されていることを確認する必要があります。具体的には、次の内容を実行する必要があります。

- SLBのCA証明書をOMSトラスト・ストアにインポートします。

- Enterprise Manager CA証明書をSLBのトラスト・ストアにコピーします。

Enterprise Managerは、カスタム証明書ではなくデフォルトのEnterprise Manager証明書を使用します。エージェントがSLBを介してOMSに情報を正常にアップロードするため、カスタムの信頼できる証明書をOMSおよびエージェントのトラスト・ストアにコピー/インポートする必要があります。次の手順は、SLBがサード・パーティ/カスタムSSL証明書で構成される場合に12c OMSおよびエージェントを保護するために使用されるプロセスを示しています。

SLBで使用されるSSL証明書の確認

次の手順を実行して、SLBがOMSと別の証明書を使用しているかどうかを確認します。

1. URLで使用されている証明書チェーンを確認するには、次のコマンドを実行します。
<OMS_HOME>/bin>./emctl secdiag openurl -url <HTTPS URL>

SLB URLで使用されている証明書を確認するには、次のコマンドを実行します。

<OMS_HOME>/bin>./emctl secdiag openurl -url https://<SLB Hostname>:<HTTPS Upload port>/empbs/upload

OMS URLで使用されている証明書を確認するには、次のコマンドを実行します。

<OMS_HOME>/bin>./emctl secdiag openurl -url https://<OMS Hostname>:<HTTPS Upload port>/empbs/upload

2. デフォルトのEnterprise Manager自己署名証明書がSLBで使用される場合、両方のコマンドの出力は次のように表示されます。
発行者 : CN=<OMS Hostname>, C=US, ST=CA, L=<OMS Hostname>のEnterpriseManager, OU=<OMS Hostname>のEnterpriseManager, O=<OMS Hostname>のEnterpriseManager

3. カスタムまたは自己署名SSL証明書がSLBで使用される場合、SLB名で実行されるコマンドの出力が次に示されている詳細を提供します。
発行者 : CN=Entrust Certification Authority - L1C, OU="(c) 2014 Entrust, Inc.", OU=www.entrust.net/rpa is incorporated by reference, O="Entrust, Inc.", C=US

この例では、SLBは信頼できる証明書としてOMSにインポートする必要があるカスタム証明書(CN=Entrust Certification Authority - L1C, OU="(c) 2014 Entrust, Inc.")を使用しています。

4. OpenSSLがOSで使用できる場合、次のコマンドを実行してCNの値も確認できます。
$openssl s_client -connect <HOSTNAME>:<PORT>

OMSおよびエージェントのトラスト・ストアへのSLBのSSL証明書のインポート

1. base64形式のSLB証明書をcustomca.txtという名前のテキスト・ファイルにエクスポートします。

2. OMSを保護します。
cd <OMS_HOME>/bin>

./emctl secure oms -host <SLB Host name> -secure_port <HTTPS Upload Port> -slb_port <SLB upload Port> -slb_console_port <SLB Console port> -console -trust_certs_loc <path to customca.txt>

注意:
emctl secure omsコマンドを使用してSLBの背後のすべてのOMSを保護する必要があります。
OMSのCA証明書は<EM_INSTANCE_HOME>/em/EMGC_OMS1/sysman/config/b64LocalCertificate.txtファイルに存在し、SLBのSSLトラスト・ストアにコピーする必要があります。

3. すべてのOMSを再起動します。
cd <OMS_HOME>/bin

emctl stop oms -all

emctl start oms

4. このEnterprise Manager設定を指すすべてのエージェントを保護します。
cd <AGENT_HOME>/bin

./emctl secure agent –emdWalletSrcUrl <SLB Upload URL>

18 Enterprise Manager障害時リカバリ

この章で説明する高可用性ソリューションは、通常、コンポーネントの障害やシステムレベルの問題などからEnterprise Managerを保護しますが、自然災害、火災、停電、排気、広範囲の妨害行為によるデータ・センターの壊滅的な障害などの大規模な故障からEnterprise Managerを保護することも必要です。

Enterprise Managerの最大可用性アーキテクチャには、プライマリ管理インフラストラクチャが災害による被害を受けた場合、セカンダリ・データ・センターが管理インフラストラクチャを引き継ぐことができるリモート・フェイルオーバー・アーキテクチャのデプロイが含まれます。

注意:
OMS障害時リカバリはEnterprise Managerのバージョンによって異なります。
Cloud Control 12.1.0.2以前 - スタンバイWebLogicドメインを使用するスタンバイOMSを使用する必要があります。詳細は、付録I「スタンバイWebLogicドメインを使用するスタンバイOMS」を参照してください

Cloud Control 12.1.0.3以降 - この章で説明する、記憶域レプリケーションを使用するスタンバイOMSの使用をお薦めします。

BI Publisherサーバーの構成は、Cloud Control 12.1.0.4以降のリリースに対応するスタンバイWeblogicドメインを使用するスタンバイOMSではサポートされていません。

記憶域レプリケーションを使用するスタンバイOMSの利点は、次のとおりです。

- OMSパッチおよびアップグレードは1つのサイトで実行するだけで済みます。

- プラグインは1つのサイトで管理するだけで済みます。

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

- 障害時リカバリの概要とトポロジ

- 設計上の考慮事項

- 管理リポジトリの障害時リカバリの設定

- OMS、BI Publisher共有記憶域およびソフトウェア・ライブラリの障害時リカバリの設定

- スイッチオーバーおよびフェイルオーバー操作の実行

- スタンバイ・サイトのプライマリとの同期の維持

- ACFSレプリケーションが可能な障害時リカバリ・ソリューション

18.1 障害時リカバリの概要とトポロジ

Cloud Controlデプロイメントに対する障害時リカバリ・ソリューションには、OMS、ソフトウェア・ライブラリおよびリポジトリのコンポーネントのスタンバイ・サイトへのレプリケーションが含まれます。このソリューションは、前の章で説明した高可用性ソリューションと組み合せて、Cloud Controlの可用性の中断を最小限に抑えながら、コンポーネントの障害からサイト全体の停止までの多岐にわたる障害を確実にリカバリできるようにします。

前の章で説明した高可用性設計と、この章で説明する障害時リカバリ・ソリューションとを組み合せた、Enterprise Manager Cloud Controlの完全な実装を次の図に示します。

図18-1 高可用性と障害時リカバリのトポロジ

図に示されたDRソリューションの重要な部分は次のとおりです。

- このソリューションにはサイトが2つあります。プライマリ・サイトは稼働中かつアクティブであり、スタンバイ・サイトはパッシブ・モードになっています。

- Enterprise Managerのユーザーおよびエージェントからのトラフィックは、グローバル・ロード・バランサまたはプライマリ・サイトでホストされるIPアドレスに解決するDNSエントリによって、プライマリ・サイトに送られます。

- スタンバイ・サイトは、フェイルオーバーの発生時にパフォーマンスが損なわれないように、ハードウェアとネットワークのリソースの点でプライマリ・サイトと同様です。

- スタンバイ・サイトでは、OMSのインストールを実行する必要はありません。Oracleインベントリ、OMSソフトウェア、エージェントおよびソフトウェア・ライブラリはすべてレプリケートされた記憶域にあります。本番サイトの記憶域がスタンバイ・サイトにレプリケートされると、同等のデータがスタンバイ・サイトに書き込まれます。

- OMSホスト名は、プライマリ・サイトからの問合せではプライマリOMSのIPアドレスに、セカンダリ・サイトからの問合せでは対応するスタンバイ・ホストのIPアドレスに解決できる必要があります。

- OMSソフトウェア、Oracleインベントリ、ソフトウェア・ライブラリ、およびすべてのOMSに対するエージェント・バイナリと構成ファイルが、レプリケートされた記憶域にあります。

- 各サイトのOMSホストは、同じマウント・ポイントを使用してレプリケートされた記憶域にアクセスします。

- サイト間のレプリケーションは、スケジュールした一定の間隔で実施し、構成の変更後にも実施する必要があります。

- Oracle Data Guard物理スタンバイを使用して、スタンバイ・サイトのリポジトリ・データベースをレプリケートします。

- 最大量のREDOデータの生成を処理するために、プライマリ・サイトとスタンバイ・サイト間に十分なネットワーク・バンド幅が必要です。

- プライマリ・サイトに障害または計画された停止が発生した場合には、次の手順を実行して、トポロジ内でスタンバイ・サイトがプライマリのロールを引き継げるようにします。

- プライマリ・サイトのOMSを停止します

- 記憶域のオンデマンド・レプリケーションを実行します(プライマリ・サイトを使用できる場合)

- データベースをスタンバイ・サイトにフェイルオーバー/スイッチオーバーします

- 記憶域レプリケーションを逆にして、スタンバイ・サイトでのレプリケートされた記憶域の読取り/書込みをアクティブ化します

- スタンバイ・サイトでOMSを起動します

- DNSまたはグローバル・ロード・バランサを更新して、ユーザー・リクエストをスタンバイ・サイトに再ルーティングします。この時点では、スタンバイ・サイトが本番のロールを引き継いでいます。

18.2 設計上の考慮事項

この項では、エンタープライズ・デプロイメントにおけるCloud Control障害時リカバリ・ソリューションに関する設計上の考慮事項について説明します。

この章では、次の項目について説明します。

- ネットワークに関する考慮事項

- 記憶域に関する考慮事項

- データベースに関する考慮事項

- 開始ポイント

18.2.1 ネットワークに関する考慮事項

次の各項では、記憶域レプリケーションを使用してスタンバイ管理サービスを実装するときに考慮する必要があるネットワークに関する事項について説明します。

18.2.1.1 ホスト名の計画

障害時リカバリ・トポロジでは、本番サイトのホスト名がスタンバイ・サイトの対応するピア・システムのIPアドレスに解決可能である必要があります。そのため、本番サイトとスタンバイ・サイトのホスト名を計画することが重要です。プライマリ・サイトからスタンバイ・サイトへのスイッチオーバーまたはフェイルオーバーの後、スタンバイ・サイトのホストのホスト名を変更しなくても、スタンバイ・ホストでアプリケーションを起動できる必要があります。

これは次のどちらかの方法で実施できます。

- オプション1: プライマリ・サイトでの物理ホスト名とスタンバイ・サイトでの別名: プライマリ・サイトのOMSは物理ホスト名を使用して構成され、これらのホスト名の別名はスタンバイ・サイトの対応するホストで構成されます。

- オプション2: 両方のサイトでの別名ホスト名: プライマリ・サイトのOMSは、プライマリおよびスタンバイの両方のサイトで構成できる別名ホスト名を使用して構成されます。

これらのオプションの選択は、ネットワーク・インフラストラクチャおよびコーポレート・ポリシーに依存します。設定プロシージャの観点から、物理ホスト名を使用する既存の単一サイトのCloud Controlインストールがある場合、DRの設定に既存サイトの変換を必要としないため、オプション1の方が実装が容易です。新しいCloud Controlインストールを設定中であり、別名ホスト名で起動する場合、または別名ホスト名を使用する既存のCloud Controlインストールがある場合は、オプション2の方が実装が容易になります。

注意:
オプション2を使用する場合、インストーラの起動時にホスト名の別名としてORACLE_HOSTNAMEを設定する必要があります。次に例を示します。
$ runInstaller ORACLE_HOSTNAME=oms1.example.com

Enterprise ManagerのrunInstaller UIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。

各サイトでのホスト名解決は、ローカル解決(/etc/hosts)またはDNSベースの解決、あるいは両方の組合せのいずれかを使用して行うことができます。次の例は、これらの物理ホスト名およびIPアドレスを使用しています。

HOSTNAME             IP ADDRESS      DESCRIPTION
oms1-p.example.com   123.1.2.111     Physical host for OMS1 on Primary site
oms2-p.example.com   123.1.2.112     Physical host for OMS2 on Primary site
oms1-s.example.com   123.2.2.111     Physical host for OMS1 on Standby site
oms2-s.example.com   123.2.2.112     Physical host for OMS2 on Standby site

注意:
オプション1またはオプション2でローカル解決を使用する場合は、次の例に示すように、サイトの各OMS上の/etc/hostsファイルに、そのサイトのすべてのOMSの物理ホスト名と別名ホスト名が含まれることを確認します(別名ホスト名が使用されるサイトの場合)。

オプション1の例: OMSが、プライマリ・サイト物理ホスト名(oms1-p.example.comおよびoms2-p.example.com)を使用してプライマリ・サイトにインストールされる場合の/etc/hostsの構成:

Primary Site

127.0.0.1     localhost.localdomain  localhost
123.1.2.111   oms1-p.example.com     oms1-p #OMS1
123.1.2.112   oms2-p.example.com     oms2-p #OMS2

Standby Site

127.0.0.1     localhost.localdomain  localhost
123.2.2.111   oms1-s.example.com     oms1-s      oms1-p.example.com #OMS1
123.2.2.112   oms2-s.example.com     oms2-s      oms2-p.example.com #OMS2

ネットワークが正しく構成されている場合、プライマリ・サイトからOMSホスト名をpingすると、プライマリ・ホストから応答がある必要があり、スタンバイ・サイトからOMSホスト名をpingすると、スタンバイ・ホストから応答がある必要があります。

プライマリ・サイトからのPing結果(プライマリ・サイトから応答):

[oracle@oms1-p ~]$ ping oms1-p.example.com
PING oms1-p.example.com (123.1.2.111) 56(84) bytes of data.
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=3 ttl=64 time=0.022 ms

スタンバイ・サイトからのPing結果(スタンバイ・サイトから応答)

[oracle@oms1-s ~]$ ping oms1-p.example.com
PING oms1-s.example.com (123.2.2.111) 56(84) bytes of data.
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=3 ttl=64 time=0.022 ms

オプション2の例: OMSが、別名ホスト名(oms1.example.comおよびoms2.example.com)を使用してインストールされる場合の/etc/hostsの構成:

Primary Site

127.0.0.1     localhost.localdomain   localhost
123.1.2.111   oms1-p.example.com      oms1-p     oms1.example.com #OMS1
123.1.2.112   oms2-p.example.com      oms2-p     oms2.example.com #OMS2

Standby Site

127.0.0.1    localhost.localdomain    localhost
123.2.2.111  oms1-s.example.com       oms1-s     oms1.example.com #OMS1
123.2.2.112  oms2-s.example.com       oms2-s     oms2.example.com #OMS2

ネットワークが正しく構成されている場合、プライマリ・サイトからOMSホスト名をpingすると、プライマリ・ホストから応答がある必要があり、スタンバイ・サイトからOMSホスト名をpingすると、スタンバイ・ホストから応答がある必要があります。

例:

プライマリ・サイトからのPing結果(プライマリ・サイトから応答):

[oracle@oms1-p ~]$ ping oms1.example.com
PING oms1-p.example.com (123.1.2.111) 56(84) bytes of data.
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=3 ttl=64 time=0.022 ms

スタンバイ・サイトからのPing結果(スタンバイ・サイトから応答)

[oracle@oms1-s ~]$ ping oms1.example.com
PING oms1-s.example.com (123.2.2.111) 56(84) bytes of data.
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=3 ttl=64 time=0.022 ms

18.2.1.2 ロード・バランサに関する考慮事項

各サイトに複数のOMSがある場合、プライマリおよびスタンバイの両方のサイトに自身のサーバー・ロード・バランサが必要です。「ロード・バランサの構成」を参照してください。各サイト上のSLBプールは、それぞれのOMSホストのIPアドレスを参照します。

18.2.1.3 アプリケーションの仮想ホスト名に関する考慮事項

Cloud Controlクライアント(エージェントおよびユーザー)がCloud Controlにアクセスするためのホスト名が必要です。プライマリ・サイトがアクティブなとき、このホスト名は、プライマリ・サイトSLBによってホストされるIPアドレスに解決されるようにDNSで構成する必要があります。スタンバイ・サイトがアクティブ化されているとき、ホスト名がスタンバイ・サイトSLBによってホストされるIPアドレスに解決されるように、DNSエントリを更新する必要があります。

各サイトで複数のOMSとSLBを使用する場合の、Cloud Controlアプリケーション・ホスト名のDNS構成の例を次の表に示します。

表18-1 DNS構成

DNS名

DNSレコード・タイプ

VALUE

コメント

em.example.com

CNAME

slb_primary.example.com

Cloud Controlクライアントが管理サービスと通信するために使用する仮想ホスト名。現在アクティブなサイトを指す必要があります

slb_primary.example.com

A

123.1.2.110

プライマリ・サイトのSLBアドレス

slb_standby.example.com

A

123.2.2.110

スタンバイ・サイトのSLBアドレス

DNSスイッチオーバーを実行するには、グローバル・ロード・バランサを使用するか、DNS名を手動で変更します。

- グローバル・ロード・バランサは、信頼できるDNSネーム・サーバーと同等の機能を提供できます。グローバル・ロード・バランサを使用する利点の1つは、名前とIPの新しいマッピングがほとんど即時に有効になる点です。マイナス面は、グローバル・ロード・バランサに対する追加投資が必要な点です

- DNS名の手動変更。Cloud ControlクライアントによってキャッシュされるDNSレコードが、更新の後すぐに更新されるようにするため、em.example.comのCNAMEのTTLを60秒などの低い値に設定することをお薦めします。このようにすると、DNSの変更がすべてのクライアントにただちに伝播されるようになります。ただし、キャッシュ時間が短くなるため、DNSリクエストが増加する可能性があります。

18.2.2 記憶域に関する考慮事項

Cloud Controlデプロイメントに対する障害時リカバリ・ソリューションには、レプリケートされた記憶域でのソフトウェア・ライブラリ、OMSインストール、エージェント・インストールおよびOracleインベントリのインストールが含まれます。

記憶域レプリケーションの要件

選択した記憶域レプリケーションの方法で、次がサポートされている必要があります。

- スナップショットおよび一貫性のあるファイルシステム・コピー

- サイト間でのスケジュール済レプリケーションおよびオンデマンド・レプリケーションを実行する機能

次の項では、お薦めする記憶域構造について詳しく説明します。

- OMSホストごとに1つのボリュームを作成します。

- 同じマウント・ポイント(例: /u01/app/oracle/OMS)を使用して、前述のボリュームを各OMSホストにマウントします。各ホストで、このボリュームはOMSインストール、エージェント・インストールおよびOracleインベントリを含みます。

- 前述のボリュームに対して整合性グループを作成し、すべてのボリュームに対して一貫性のあるレプリケーションを実行できるようにします。

- ソフトウェア・ライブラリに対して1つのボリュームを作成します。このボリュームは、同じマウント・ポイントを使用してすべてのOMSホストに同時にマウントされる必要があります。たとえば、/swlibなどです。

- BIPに1つのボリュームを作成します。このボリュームは、同じマウント・ポイントを使用してすべてのOMSホストに同時にマウントされる必要があります。たとえば、/bipなどです。

- インフラストラクチャに基づいて、OMSファイルシステム、ソフトウェア・ライブラリおよびBIPに適切なレプリケーション頻度を決定します。OMSファイルシステムには24時間の最小頻度、ソフトウェア・ライブラリには連続または毎時レプリケーションをお薦めします。

これらのボリュームがマウントされた後で、マウントされたディレクトリがOracleソフトウェア所有者ユーザー(通常、oracle)およびOracleインベントリ・グループ(通常、oinstall)によって所有されていることと、Oracleソフトウェア所有者ユーザーに、マウントされたディレクトリへの読取りおよび書込みアクセス権があることを確認してください。

例: 次の表に構成例を示します。

表18-2 記憶域構成

ボリューム

マウントされるホスト

マウント・ポイント

コメント

VOLOMS1

oms1-p.example.com

/u01/app/oracle/OMS

プライマリ・サイトOMS1上のEnterprise Managerのインストール

VOLOMS2

oms2-p.example.com

/u01/app/oracle/OMS

プライマリ・サイトOMS2上のEnterprise Managerのインストール

VOLSWLIB

oms1-p.example.comおよびoms2-p.example.com

/swlib

プライマリ・サイトOMS1およびOMS2上のソフトウェア・ライブラリ

VOLBIP

oms1-p.example.comおよびoms2-p.example.com

/bip

プライマリ・サイトOMS1およびOMS2のBIP共有記憶域(BIPが構成されている場合)

18.2.3 データベースに関する考慮事項

この項では、障害時リカバリに対するリポジトリ・データベースの設定に関する推奨事項と考慮事項を説明します。

- 本番サイトとスタンバイ・サイトの両方にReal Application Clusterデータベースを作成することをお薦めします。

- 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、これが正しく特定されていることを確認してください。

- ブローカ操作時にインスタンスを再起動するようにData Guardを有効にするには、特定の名前のサービスを、各インスタンスのローカル・リスナーに静的に登録する必要があります。

- リポジトリ・データベースのスイッチオーバーおよびフェイルオーバーの操作に対してdgmgrlを最大限に効率的に使用できるようにするには、すべてのプライマリ・リポジトリ・データベースおよびスタンバイ・リポジトリ・データベースのTNS別名を、tnsnames.ora内の各データベース・インスタンスのORACLE_HOMEの下に追加する必要があります。

- 中間層の同期が実行された場合は必ず、Data Guardでデータベースの手動同期を強制的に実行することを強くお薦めします。これは特に、メタデータ・リポジトリに構成データを格納するコンポーネントに該当します。

- 18.2.3.1項「11gリリース2よりも前のOracle Databaseに関する考慮事項」および18.2.3.2項「11gリリース2以降のOracle Databaseに関する考慮事項」で説明されている推奨事項に基づいて接続記述子を選択した後、プライマリ・サイトで各OMSに対して次のコマンドを実行して、接続記述子を構成します。

emctl config oms -store_repos_details -repos_conndesc <connect descriptor> -repos_user <username>

次の使用例は、18.2.3.2項に記載されている接続記述子の推奨事項に従ったものです。

emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=primary_cluster_scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=haemrep.example.com)))(DESCRIPTION=(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=standby_cluster_scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=haemrep.example.com))))" -repos_user SYSMAN

18.2.3.1 11gリリース2よりも前のOracle Databaseに関する考慮事項

本番サイトとスタンバイ・サイトの両方でデータベース・ホスト名の別名を設定することを強くお薦めします。これによって、シームレスなスイッチオーバー、スイッチバックおよびフェイルオーバーが実現します。次に例を示します。

サイト

リポジトリ・ホスト名

リポジトリ接続文字列

プライマリ

repos1-p.example.com

(DESCRIPTION=(ADDRESS_LIST=(FAILOVER=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=repos1-p.example.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=repos2-p.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=EMREP)))

repos2-p.example.com

スタンバイ

repos1-s.example.com

(DESCRIPTION=(ADDRESS_LIST=(FAILOVER=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=repos1-s.example.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=repos2-s.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=EMREP)))

repos2-s.example.com

前述の例では、フェイルオーバーまたはスイッチオーバー操作の後、スタンバイ・サイト上のOMSはスタンバイ・リポジトリ接続文字列を使用するように切り替えられる必要があります。オプションでリポジトリ・データベース・ホストのホスト名別名を設定することにより、接続文字列の変更を回避できます。次に例を示します。

サイト

リポジトリ・ホスト名

ホスト名別名

プライマリ

repos1-p.example.com

repos1.example.com

repos2-p.example.com

repos2.example.com

スタンバイ

repos1-s.example.com

repos1.example.com

repos2-s.example.com

repos2.example.com

フェイルオーバーまたはスイッチオーバー中の変更の必要を少なくするため、このようにサイトの接続文字列を同じにすることができます。

(DESCRIPTION=(ADDRESS_LIST=(FAILOVER=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=repos1.example.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=repos2.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=EMREP)))

18.2.3.2 11gリリース2以降のOracle Databaseに関する考慮事項

Oracle Database 11gリリース2では、Single Client Access Name (SCAN)アドレスおよびロールベース・データベース・サービスという2つのテクノロジが導入されています。これらによって、障害時リカバリ用のリポジトリ・データベースに関して接続文字列の管理が大幅に簡易化されます。

SCANアドレスによってRACクラスタの単一アドレスが提供され、接続文字列に複数のVIPアドレスを指定する必要がなくなります。SCANアドレスの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照する必要があります。

ロールベース・データベース・サービスにより、データベースのロールに基づいてRACクラスタで実行するデータベース・サービスを作成できるようになります。管理者がデータベース・トリガーを作成および保守して、データベース・サービスを管理する必要はありません。ロールベース・データベース・サービスでは、Oracle Clusterwareが、指定のロール(プライマリまたはスタンバイ)に基づいてデータベース・サービスを自動的に起動および停止します。ロールベース・データベース・サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』および『高可用性Oracle Databaseでのクライアント・フェイルオーバーのベスト・プラクティス: Oracle Database 12c』テクニカル・ホワイトペーパーを参照してください。

これら2つのテクノロジを組み合せることで、プライマリ・データベースに対する1つのエントリとスタンバイ・データベースに対する1つのエントリを含む、リポジトリ接続文字列を作成できます。この接続文字列はプライマリ・サイトとスタンバイ・サイトの両方から使用できるため、スイッチオーバーまたはフェイルオーバー操作時に接続文字列を手動で変更する必要がなくなります。

レベル4のMAA構成で、リポジトリへの接続で使用するロールベース・データベース・サービスを作成するには、次のようなコマンドを実行して、プライマリ・クラスタとスタンバイ・クラスタの両方にデータベース・サービスを作成します。

プライマリ・クラスタ:

srvctl add service -d emrepa -s haemrep.example.com -l PRIMARY -r emrepa1,emrepa2

スタンバイ・クラスタ:

srvctl add service -d emreps -s haemrep.example.com -l PRIMARY -r emreps1,emreps2

最初にプライマリ・クラスタのノードで次の操作を実行して、サービスを開始します。

srvctl start service -d emrepa -s haemrep.example.com

これでロールベース・データベース・サービスがアクティブになり、アクティブなデータベースをホストするいずれかのクラスタで稼働します。

Oracle Database 11.2、Data GuardおよびRACを使用する環境では、次のような接続文字列の使用をお薦めします。各クラスタのSCANアドレスの名前とロールベース・データベース・サービス名を、ご使用の環境の該当する値で置き換えてください。

(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=primary-cluster-scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=haemrep.example.com)))(DESCRIPTION=(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=standby-cluster-scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=haemrep.example.com))))

18.2.4 開始ポイント

スタンバイ・サイトを設定する前に、管理者はプロジェクトの開始ポイントを評価する必要があります。通常、Enterprise Manager Cloud Control障害時リカバリ・トポロジを設計する際の開始ポイントは次のいずれかです。

- プライマリ・サイトがすでに作成されており、スタンバイ・サイトが計画中です

- プライマリ・サイトがすでに作成されており、スタンバイ・サイトが非推奨の"スタンバイWLSドメイン"メソッドを使用してすでに作成されています

- インストールが存在せず、プライマリおよびスタンバイの両方のサイトが計画中です

18.2.4.1 プライマリ・サイトがすでに作成されており、スタンバイ・サイトが計画中です

開始ポイントが既存のプライマリ・サイトである場合、プライマリ・サイトのOMSインストールがファイルシステムにすでに存在します。また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。サイトを変換し障害時リカバリ・トポロジ用に準備するために、次のプロシージャを使用する必要があります。

1. ネットワークに関する考慮事項を確認し、ホスト名を計画します
オプション1を使用する場合、プライマリ・サイトでのホスト名変更は必要ありません。適切な別名ホスト名を追加することによって、スタンバイ・サイト・ホストを準備します。

オプション2を使用する場合、OMSホスト名を変更して、既存のOMSインストールを移動し別名ホスト名を使用するようにします。適切な別名ホスト名を追加することによって、スタンバイ・サイト・ホストを準備します。

2. 記憶域に関する考慮事項を確認し、OMSインストールを共有記憶域に移動します
プライマリ・サイトを共有記憶域に移行します。「共有記憶域への既存のサイトの移行」を参照してください。

3. データベースに関する考慮事項を確認し、リポジトリ・ホスト名および接続記述子を計画します
シームレスなフェイルオーバー/スイッチオーバーを実現するために、リポジトリ・データベースのホスト名別名を使用するかどうか考えてください。その場合、リポジトリ・データベースを移行して別名ホスト名を使用します。

4. プライマリ・サイトの準備ができたので、「管理リポジトリの障害時リカバリの設定」および「OMS、BI Publisher共有記憶域およびソフトウェア・ライブラリの障害時リカバリの設定」のプロシージャを使用してDR設定を完了します。

18.2.4.2 プライマリ・サイトがすでに作成されており、スタンバイ・サイトが非推奨の"スタンバイWLSドメイン"メソッドを使用してすでに作成されています。

1. スタンバイOMSの削除プロシージャを使用して、スタンバイOMSを削除します。『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』の追加のスタンバイOMSインスタンスの削除に関する説明を参照してください。

2. 「プライマリ・サイトがすでに作成されており、スタンバイ・サイトが計画中です」に記載されているプロシージャを使用します。

18.2.4.3 インストールが存在せず、プライマリおよびスタンバイの両方のサイトが計画中です

新しいプライマリ・サイトを(既存のプライマリ・サイトは使用せずに)設計している場合、ソフトウェアのインストールを開始する前にサイト計画を実行できるため容易です。

1. ネットワークに関する考慮事項を確認し、ホスト名を計画します。

2. 記憶域に関する考慮事項を確認し、記憶域ボリュームを準備します。

3. データベースに関する考慮事項を確認し、リポジトリ・ホスト名を準備します。

4. 第17章「Enterprise Managerの高可用性」に記載されている手順を使用して、正しいホスト名を使用して共有記憶域にインストールすることに注意して、プライマリ・サイトのインストールを実行します。

5. プライマリ・サイトの準備ができたので、次の項のプロシージャを使用してDR設定を完了します。

- 管理リポジトリの障害時リカバリの設定

- OMS、BI Publisher共有記憶域およびソフトウェア・ライブラリの障害時リカバリの設定

18.3 管理リポジトリの障害時リカバリの設定

管理リポジトリでは、障害時リカバリ・ソリューションとしてData Guardを使用する必要があります。

18.3.1 管理リポジトリのためのスタンバイ・データベースの構成

次に、スタンバイ管理リポジトリ・データベースを設定する手順を説明します。

1. Data Guard用のスタンバイ管理リポジトリ・ホストを準備します。
スタンバイ管理リポジトリの各ホストに管理エージェントをインストールします。プライマリ・サイトのSLBでアップロードするように管理エージェントを構成します。スタンバイ管理リポジトリ・ホストに、グリッド・インフラストラクチャおよびRACデータベース・ソフトウェアをインストールします。プライマリ・サイトと同じバージョンを使用してください。

2. Data Guard用のプライマリ管理リポジトリ・データベースを準備します。
プライマリ管理リポジトリ・データベースがまだ構成されていない場合、アーカイブ・ログ・モードを有効にして、フラッシュ・リカバリ領域を設定し、プライマリ管理リポジトリ・データベースのフラッシュバック・データベースを有効にします。

注意:
アップグレード中にスタンバイ・データベースの破損を防ぐためにデータベースがFORCE LOGGINGモードになっていることを確認してください。
プライマリ管理リポジトリ・データベースがFORCE LOGGINGモードである場合、一時表領域および一時セグメントに対する変更を除くすべてのデータベース変更が記録されます。FORCE LOGGINGモードは、スタンバイ・データベースがプライマリ管理リポジトリ・データベースと一貫性を維持することを保証します。

3. 物理スタンバイ・データベースを作成します。
Enterprise Managerコンソールを使用して、スタンバイ環境で物理スタンバイ・データベースを設定します。スタンバイ管理リポジトリ・データベースは物理スタンバイにします。ロジカル・スタンバイ管理リポジトリ・データベースはサポートされません。

Enterprise Managerコンソールでは、スタンバイRACデータベースの作成はサポートされていません。スタンバイ・データベースをRACにする必要がある場合、単一インスタンスを使用してスタンバイ・データベースを構成し、Enterprise Managerコンソールの「RACデータベースへの変換」オプションを使用して、単一インスタンスのスタンバイ・データベースをRACに変換します。「RACデータベースへの変換」オプションは、Oracle Databaseリリース10.2.0.5、11.1.0.7以上で使用できます。Oracle Databaseリリース11.1.0.7でRACへの変換オプションが機能するにはパッチ8824966が必要です。単一インスタンスのスタンバイ作成中、後でRACへの変換が容易になるようにデータベース・ファイルを共有記憶域(理想的にはASM)に作成しておくことがベスト・プラクティスです。

4. リスナーに静的サービスを追加します。
ブローカ操作時にインスタンスを再起動するようにData Guardを有効にするには、特定の名前のサービスを、各インスタンスのローカル・リスナーに静的に登録する必要があります。GLOBAL_DBNAME属性の値は、連結文字列<db_unique_name>_DGMGRL.<db_domain>に設定してください。たとえば、LISTENER.ORAファイルでは次のようになります。

SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME=sid_name)
(GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
(ORACLE_HOME=oracle_home)))

5. スタンバイ・データベースでフラッシュバック・データベースを有効にします。
フェイルオーバー後に古いプライマリ・データベースをスタンバイ・データベースとして修復できるようにするには、フラッシュバック・データベースを有効化する必要があります。そのために、プライマリおよびスタンバイ・データベースの両方に対して実行します。

6. Enterprise Managerが物理スタンバイ・データベース(通常はマウント状態)を監視できるようにするには、sysdba監視権限を指定します。これは、スタンバイの作成ウィザード中またはスタンバイ・データベース・ターゲットの「監視構成」の変更による作成後のどちらでも指定できます。

7. 物理スタンバイを検証します。
Enterprise Managerコンソールで物理スタンバイ・データベースを検証します。「Data Guard」ページで ログ切替え ボタンをクリックしてログを切り替え、切替えが受け入れられてスタンバイ・データベースに適用されていることを検証します。

18.4 OMS、BI Publisher共有記憶域およびソフトウェア・ライブラリの障害時リカバリの設定

Cloud Controlデプロイメントに対する障害時リカバリ・ソリューションには、レプリケートされたファイルシステムでのソフトウェア・ライブラリ、OMSインストール、エージェント・インストールおよびOracleインベントリのインストールが含まれます。このソリューションには、BI Publisher共有記憶域の構成が含まれることもあります。

スタンバイWebLogicドメインを使用して実装されたスタンバイOMSはまだサポートされていますが、非推奨になっており、将来のリリースでサポートされない可能性があります(詳細はMy Oracle Supportノート1563541.1を参照してください)。この章に記載されているように、記憶域レプリケーションを使用してスタンバイOMSを作成する方法をお薦めします。スタンバイWebLogicドメインを使用したスタンバイOMSの作成は、付録I「スタンバイWebLogicドメインを使用するスタンバイOMS」に記載されています。

記憶域レプリケーションの要件

選択した記憶域レプリケーションの方法で、次がサポートされている必要があります。

- スナップショットおよび一貫性のあるファイルシステム・コピー

- サイト間でのオンデマンド・レプリケーションを実行する機能

18.4.1 管理サービスの障害時リカバリ

1. プライマリOMSホスト名が、スタンバイ・サイトの対応するスタンバイ・ホストのIPアドレスに解決されることを確認します。これは次のどちらかの方法で実施できます。

- 物理ホスト名を使用してプライマリ・サイトでOMSをインストールし、スタンバイ・サイトの対応するホストでこれらのホスト名に別名を構成します。

- プライマリおよびスタンバイの両方のサイトで構成できる別名ホスト名を使用して各OMSをインストールします。

各サイトでのホスト名解決は、ローカル解決(/etc/hosts)またはDNSベースの解決、あるいは両方の組合せのいずれかを使用して行うことができます。

OMSが、プライマリ・サイト物理ホスト名(oms1-p.example.comおよびoms2-p.example.com)を使用してプライマリ・サイトにインストールされる場合の/etc/hostsの構成例:

プライマリ・サイト

127.0.0.1     localhost.localdomain
123.1.2.111   oms1-p.example.com  oms1-p #OMS1
123.1.2.112   oms2-p.example.com  oms2-p #

スタンバイ・サイト

127.0.0.1     localhost.localdomain
123.2.2.111   oms1-s.example.com  oms1-s oms1-p.example.com #OMS1
123.2.2.112   oms2-s.example.com  oms2-s oms2-p.example.com #OMS2

OMSが、別名ホスト名(oms1.example.comおよびoms2.example.com)を使用してインストールされる場合の/etc/hostsの構成例:

プライマリ・サイト

127.0.0.1     localhost.localdomain
123.1.2.111   oms1-p.example.com  oms1-p oms1.example.com #OMS1
123.1.2.112   oms2-p.example.com  oms2-p oms2.example.com #OMS2

スタンバイ・サイト

127.0.0.1    localhost.localdomain
123.2.2.111  oms1-s.example.com  oms1-s oms1.example.com #OMS1
123.2.2.112  oms2-s.example.com  oms2-s oms2.example.com #OMS2

ネットワークが正しく構成されている場合、プライマリ・サイトからOMSホスト名をpingすると、プライマリ・ホストから応答がある必要があり、スタンバイ・サイトからOMSホスト名をpingすると、スタンバイ・ホストから応答がある必要があります。

例

プライマリ・サイトからのPing結果(プライマリ・サイトから応答):

[oracle@oms1-p ~]$ ping oms1-p.example.com
PING oms1-p.example.com (123.1.2.111) 56(84) bytes of data.
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from oms1-p.example.com (123.1.2.111): icmp_seq=3 ttl=64 time=0.022 ms

スタンバイ・サイトからのPing結果(スタンバイ・サイトから応答)

[oracle@oms1-s ~]$ ping oms1-p.example.com
PING oms1-s.example.com (123.2.2.111) 56(84) bytes of data.
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from oms1-s.example.com (123.2.2.111): icmp_seq=3 ttl=64 time=0.022 ms

2. プライマリ・サイトの各OMSのOMSインストール、エージェント・インストールおよびOracleインベントリがレプリケートされた記憶域に置かれるようにします。これは、レプリケートされた記憶域をOMSインストール中に指定するか、インストール後にこれらのコンポーネントをレプリケートされた記憶域に移動することによって実行できます。

注意:
インストール後にコンポーネントを共有記憶域に移動した場合、それらは元のパス名を保持する必要があります。

3. プライマリ・サイトを指し示すようにDNSでアプリケーションの仮想ホスト名を構成します。

- プライマリ・サイトに単一OMSがある場合、アプリケーションの仮想ホスト名のDNSエントリはこのOMSを指し示す必要があります。

- プライマリ・サイトに複数OMSがある場合、アプリケーションの仮想ホスト名のDNSエントリはSLBを指し示す必要があります。

- このホスト名は、長時間、クライアントによってキャッシュされないよう短いTTL値(30から60秒)で構成される必要があります。

4. スタンバイ・サイトでSLBを構成します(スタンバイ・サイトで複数OMSが必要な場合のみ必要です)。詳細は、「ロード・バランサの構成」を参照してください。スタンバイ・サイト上のSLBプールは、スタンバイOMSホストのIPアドレスを参照します。

5. アプリケーションの仮想ホスト名を使用してすべてのエージェントおよびOMSを再保護します。
例

OMSの場合

emctl secure oms -sysman_pwd <sysman_pwd>
-reg_pwd <agent_reg_password>
-host em.example.com
-secure_port 4900
-slb_port 4900
-slb_console_port 443
-console
-lock_upload  -lock_console

エージェントの場合

emctl secure agent -emdWalletSrcUrl https://em.example.com:4901/em

6. 記憶域レプリケーション・スケジュールを、ネットワーク・インフラストラクチャに許可されるできるかぎり頻繁な値に構成します(最低限24時間ごと)。

注意:
ネットワーク・インフラストラクチャのリソース使用率のパフォーマンスを最大化するレプリケーション・スケジュールを決定するには、記憶域/ネットワークのドキュメントを参照してください。

7. HTTPロック・ファイルをローカル・ファイルシステムに移動します。詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

18.4.2 スタンバイOMSホストの監視

スタンバイOMSホストの可用性の監視は、スイッチオーバー/フェイルオーバー操作の準備ができていることを確認するために重要です。これらのホストを監視するために、各スタンバイOMSホストのローカル・ファイルシステムにエージェントをデプロイする必要があります。スイッチオーバー/フェイルオーバー後にスタンバイ・サイトで起動されるコンポーネントとの競合を回避するために、スタンバイOMSホストにエージェントをデプロイするとき次の点を考慮する必要があります。

- スタンバイOMSホストにデプロイされるエージェントは、レプリケートされたOracleインベントリを使用しないようにしてください。それらは、レプリケートされたOMSおよびエージェント・インストールを含まないローカル・インベントリを使用してインストールする必要があります。

- スタンバイOMSホストにデプロイされるエージェントは、レプリケートされたエージェントによって使用されるものとは異なるポートにデプロイされる必要があります。これにより、レプリケートされたOMSおよびエージェントがスタンバイOMSホストで起動したときにポートの競合が回避されます。

- 使用するネットワーク・トポロジ(両方のサイトで別名またはスタンバイ・サイトでのみ別名)にかかわらず、これらのエージェントはスタンバイOMSホストの物理ホスト名を使用してデプロイする必要があります。

- これらのエージェントは別のインベントリにデプロイして、OMSインストールに使用されるインベントリとは別にしておく必要があります。

- エージェントがスタンバイOMSホストにデプロイされた後で、すべてのOMSエージェント(レプリケートされた記憶域に別名ホスト名でインストールされたもの、およびローカル・ストレージに物理ホスト名でインストールされたもの)が同じタイムゾーンで一貫して構成されていることを確認してください。エージェントのタイムゾーン変更の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の管理エージェントのタイムゾーンの変更に関する説明を参照してください。

エージェント・インストールのインベントリの場所を指定すると、インストール中にインベントリ・ポインタ・ファイルを作成でき、-invPtrLocフラグを使用できます。

次の例に、インベントリの場所として/u01/oraInventory_standbyを指定するインベントリ・ポインタ・ファイルを示します

more /u01/oraInst_standby.loc

inventory_loc=/u01/oraInventory_standbyinst_group=dba

エージェント・インストール中に-invPtrLocフラグを渡すことができるようになります。

18.4.3 ソフトウェア・ライブラリ障害時リカバリ

1. ソフトウェア・ライブラリは記憶域レプリケーションを使用してレプリケートされるファイルシステムにある必要があります。ソフトウェア・ライブラリが現在別のファイルシステムにある場合、ソフトウェア・ライブラリ管理ページの「移行と削除」オプションを使用して移行することはできません。
詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』のソフトウェア・ライブラリの構成に関する説明を参照してください。

2. 記憶域レプリケーション・スケジュールを、ネットワーク・インフラストラクチャに許可されるできるかぎり頻繁な値に構成します。2時間ごとに発生する連続レプリケーションをお薦めします(最小)。

18.4.4 BI Publisherの共有記憶域の障害時リカバリ

BI Publisherが構成されている場合、BI Publisherの共有記憶域も障害時リカバリ・シナリオに含める必要があります。

1. BI Publisher共有記憶域の場所は、記憶域レプリケーションを使用してレプリケートされるファイルシステム上である必要があります。

2. 記憶域レプリケーション・スケジュールを、ネットワーク・インフラストラクチャに許可されるできるかぎり頻繁な値に構成します。2時間ごとに発生する連続レプリケーションをお薦めします(最小)。

18.4.5 共有記憶域への既存のサイトの移行

注意:
既存の環境の高可用性ソリューションのレベル4を使用する場合でも、既存のサイトから共有記憶域ファイル・システムに移行できます。

- ファイルシステム・バックアップを使用して、既存のOMSおよびエージェント・インストールを共有記憶域に移動します。

- 次のガイドラインを使用して、ローカル・ファイルシステムから共有記憶域に移行します

- すべてのバックアップはオフライン・バックアップである必要があり、つまり、バックアップおよびリストアの前にホスト上のOMSおよびエージェント・プロセスの停止を完了する必要があります。

- ルート・ユーザーとしてバックアップを実行する必要があり、その権限を保持している必要があります。

- Middlewareホームおよびインスタンス・ホームのディレクトリ・パスは変更しないでください。

- Cloud Controlが完全に停止することを回避するため、移行はローリング方式で実行できます。

- 「ソフトウェア・ライブラリの記憶域の場所の削除(および移行)」で説明するプロセスを使用して、ソフトウェア・ライブラリを共有記憶域に移動します。

18.5 スイッチオーバーおよびフェイルオーバー操作の実行

スタンバイ・サイトのアクティブ化は、スイッチオーバーまたはフェイルオーバーのいずれかを使用して実行できます。これらは、後述のように異なる状況で使用されます。

- スイッチオーバー - プライマリおよびスタンバイ・サイトの事前計画済ロール・リバーサルです。スイッチオーバーでは、機能がプライマリ・サイトからスタンバイ・サイトへ順序正しく調整された操作で転送されます。そのため、スイッチオーバーが完了するには両方のサイトが使用可能である必要があります。スイッチオーバーは、通常、障害時リカバリ(DR)シナリオのテストや検証、プライマリ・インフラストラクチャでの計画されたメンテナンス・アクティビティの場合に実行されます。スイッチオーバーは、スタンバイ・サイトをプライマリとしてアクティブ化するお薦めの方法です。

- フェイルオーバー - 元のプライマリ・サイトが使用不可になったときに、スタンバイ・サイトをプライマリ・サイトとしてアクティブ化することです。

注意:
BI Publisherが環境に構成されており、この章で説明するように障害時リカバリ・アプローチが記憶域レプリケーションを使用するスタンバイOMSである場合、スイッチオーバー/フェイルオーバーが発生すると、BI Publisherはスタンバイ・サイトで機能するようになります。

注意:
スイッチオーバーまたはフェイルオーバー操作の一部としてのOMSファイルシステムのアンマウント中にエラーが発生した場合、Oracle Configuration Manager (OCM)がOMSホームから構成されて実行中であることが原因である可能性があります。OCMが実行されている場合は、OMSファイルシステムのアンマウント前に停止する必要があります。OCMのステータスをチェックするには、次のコマンドを実行します。
<OMS_HOME>/ccr/bin/emCCR status

OCMを停止するには、次のコマンドを実行します。

<OMS_HOME>/ccr/bin/emCCR stop

スイッチオーバーまたはフェイルオーバー後にOCMを起動するには、次のコマンドを実行します。

<OMS_HOME>/ccr/bin/emCCR start

18.5.1 スイッチオーバーの手順

この項では、スタンバイ・サイトへのスイッチオーバーの手順について説明します。どの方向にスイッチオーバーする場合も同じ手順が適用されます。

1. プライマリ・サイトですべてのOMSコンポーネントを停止します。

2. プライマリ・サイトですべての仮想管理エージェントを停止します。

3. プライマリ・サイトでOMSホストからOMSファイルシステムおよびソフトウェア・ライブラリ・ファイルシステムをアンマウントします。

4. OMSおよびソフトウェア・ライブラリ・ファイルシステムのオンデマンド・レプリケーションを実行します。

注意:
オンデマンド・レプリケーションの実行に必要な手順は、記憶域のドキュメントを参照してください。

5. アプリケーションの仮想ホスト名に対するDNSエントリを更新します。

6. Data Guardスイッチオーバーを使用してOracle Databaseをスイッチオーバーします。
DGMGRLを使用してスタンバイ・データベースへのスイッチオーバーを実行します。このコマンドはプライマリ・サイトでもスタンバイ・サイトでも実行できます。スイッチオーバー・コマンドは、プライマリ・データベースおよびスタンバイ・データベースの状態を検証し、ロールのスイッチオーバーに影響を与えます。古いプライマリ・データベースを再起動して新しいスタンバイ・データベースとして設定します。

SWITCHOVER TO <standby database name>;

スイッチオーバー後の状態を検証します。スタンバイ・データベースを完全に監視するには、データベースを監視するユーザーにSYSDBA権限が必要です。スタンバイ・データベースはマウント専用状態であるため、この権限が必要になります。プライマリ・データベースとスタンバイ・データベースを監視するユーザーに両方のデータベースのSYSDBA権限があればベスト・プラクティスになります。

SHOW CONFIGURATION;

SHOW DATABASE <primary database name>;

SHOW DATABASE <standby database name>;

7. ソフトウェア・ライブラリおよびOMS記憶域のロール・リバーサルを実行します(手順については、記憶域のドキュメントを参照してください)。

8. SWLIBおよびOMS記憶域のレプリケーション・スケジュールを再び有効化します。
BI Publisherが構成されている場合、BI Publisherの共有記憶域のレプリケーション・スケジュールを再び有効化します。

9. スタンバイ・サイトのOMSホストにOMSおよびソフトウェア・ライブラリ・ファイルシステムをマウントします。
BI Publisherが構成されている場合、BI Publisherの共有記憶域のファイルシステムをスタンバイ・サイトのOMSホストにマウントします。

10. スタンバイ・サイトで最初のOMS管理サーバーを起動します。

注意:
18.2.3項「データベースに関する考慮事項」で説明したように、SCANアドレスおよびロールベースのデータベース・サービスを使用するなどしてプライマリ・サイトとスタンバイ・サイトの両方で機能する接続文字列を使用している場合、この手順は必要ありません。

11. 次のコマンドを使用して、OMSを新しいプライマリ・リポジトリ・データベースに向けます。

emctl config oms -store_repos_details -repos_conndesc <connect descriptor> -repos_user <username>

例

emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=newscan.domain)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=emreps.domain)))" -repos_user SYSMAN

注意:
第18.2.3項「データベースに関する考慮事項」で説明しているように、SCANアドレスおよびロールベース・データベース・サービスの使用など、プライマリ・サイトとスタンバイ・サイトの両方から機能する接続文字列を使用する場合、この手順は必要ありません。

各OMSでこの手順を繰り返します。

12. スタンバイ・サイトでOMSを起動します。

13. 次のコマンドを使用してスタンバイ・サイトで管理エージェントを起動します。

emctl start agent

14. 次のコマンドを使用して管理サービスおよびリポジトリ・ターゲットを再配置します。

emctl config emrep -agent <agent name> -conn_desc <repository connection>

管理サービスと管理リポジトリ・ターゲットは、プライマリ・サイトのいずれかの管理サービス上の管理エージェントで監視されます。スイッチオーバー/フェイルオーバー後にターゲットが監視されるようにするには、スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行して、そのターゲットをスタンバイ・サイトの管理サービスに再配置します。

注意:
次の2つの条件が満たされる場合、この手順は必要ありません。

- SCANアドレスとロールベース・データベース・サービスを使用した場合のように、プライマリ・サイトとスタンバイ・サイトの両方で機能するリポジトリ接続記述子を使用しているときこの状況では、管理サービスおよび管理リポジトリのターゲットを監視するために接続記述子を更新する必要はありません。

- 管理サービスおよび管理リポジトリのターゲットは、別名ホスト名を使用してレプリケート済記憶域にインストールされた管理エージェントによって監視されます。この状況では、同じエージェントがスタンバイ・サイトで実行されることになるため、別のエージェントを構成する必要はありません。

15. 管理サーバー・ホストの設定。これを行うには、GCDomainのターゲット・ホームページにナビゲートし、Cloud Control内から「WebLogicドメイン」→「ターゲット設定」→「モニタリング資格証明」を選択します。

18.5.2 フェイルオーバー手順

この項では、スタンバイ・サイトにフェイルオーバーして、Enterprise Managerのアプリケーション状態をリカバリする手順について説明します。これは、管理リポジトリ・データベースをすべての管理エージェントと再同期化し、元のプライマリ・データベースを最後に有効にすることで行います。

1. プライマリ・サイトでOMSコンポーネントが実行中である場合はすべて停止します。

2. プライマリ・サイトで仮想エージェントが実行中である場合はすべて停止します。

3. プライマリ・サイトのOMSホストからOMSおよびソフトウェア・ライブラリ・ファイルシステムをアンマウントします。
BI Publisherが構成されている場合、BI Publisherの共有記憶域のファイルシステムをプライマリ・サイトのOMSホストからアンマウントします。

4. OMSおよびソフトウェア・ライブラリ・ファイルシステムのオンデマンド・レプリケーションを実行します。(発生した障害の種類によって、実行できないこともあります。)BI Publisherが構成されている場合、BI Publisher共有記憶域のファイルシステムのオンデマンド・レプリケーションも実行します。

注意:
オンデマンド・レプリケーションの実行に必要な手順は、記憶域のドキュメントを参照してください。

5. アプリケーションの仮想ホスト名に対するDNSエントリを更新します。

6. Data Guardフェイルオーバーを使用してOracle Databaseをフェイルオーバーします。

7. ソフトウェア・ライブラリおよびOMS記憶域のロール・リバーサルを実行します。

8. SWLIBおよびOMS記憶域のレプリケーション・スケジュールを再び有効化します

9. スタンバイ・サイトのOMSホストにOMSおよびソフトウェア・ライブラリ・ファイルシステムをマウントします

10. 最初のOMS管理サーバーを起動します。

注意:
次の2つの条件が満たされる場合、この手順は必要ありません。

1. SCANアドレスとロールベース・データベース・サービスを使用した場合のように、プライマリ・サイトとスタンバイ・サイトの両方で機能するリポジトリ接続記述子を使用しているとき

2. Data Guardの最大保護または最大可用性レベルで実行しており、フェイルオーバーでデータ損失が発生しない場合

11. 新しいプライマリ・リポジトリ・データベースを指すように、OMS接続記述子を変更します。

emctl config oms -store_repos_details -repos_conndesc <connect descriptor> -repos_user <username>

例

emctl config oms -store_repos_details -repos_conndesc '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=newscan.domain)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=emreps.domain)))' -repos_user SYSMAN

注意:
SCANアドレスとロールベース・データベース・サービスを使用した場合のように、プライマリ・サイトとスタンバイ・サイトの両方で機能するリポジトリ接続記述子を使用しているときは、この手順は必要ありません。

各OMSでこの手順を繰り返します。

12. リポジトリの再同期化を実行して、エージェントを新しいプライマリ・データベースと再同期化します。
Data Guardの最大保護または最大可用性レベルで実行している場合、フェイルオーバーでのデータ損失はないため、この手順を省略します。ただし、データ損失がある場合は、新しいプライマリ・データベースとすべての管理エージェントを同期化します。

スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行します。

emctl resync repos -full -name "<name for recovery action>"

このコマンドは、スタンバイ・サイトの管理サービスの起動時に各管理エージェントで実行される再同期化ジョブを発行します。

13. スタンバイ・サイトでエージェントを起動します。

14. スタンバイ・サイトでOMSを起動します。

15. 「設定」→「Cloud Controlの管理」→「状態の概要」の順にナビゲートし、「ターゲット設定」→「モニタリング構成」を選択して、管理サービスとリポジトリ・ターゲットの接続記述子を変更します。
リポジトリ接続記述子を変更して、現在アクティブなデータベースに接続する必要があります。

注意:
SCANアドレスとロールベース・データベース・サービスを使用した場合のように、プライマリ・サイトとスタンバイ・サイトの両方で機能するリポジトリ接続記述子を使用しているときは、この手順は必要ありません。

16. 管理サーバー・ホストの設定。これを行うには、GCDomainのターゲット・ホームページにナビゲートし、Cloud Control内から「WebLogicドメイン」→「ターゲット設定」→「モニタリング資格証明」を選択します。

18.6 スタンバイ・サイトのプライマリとの同期の維持

Data Guardと記憶域レプリケーションの組合せによって、スタンバイ・サイトのプライマリとの同期は自動的に維持されます。

OMSまたはエージェントで次の操作が行われた前後に、スタンバイ・サイトへのオンデマンド・レプリケーションが実行されることを管理者は確認する必要があります。

- プラグインのデプロイメント/アンデプロイ、または既存のプラグインのアップグレード

- アップグレード

- パッチ

- emctlコマンド(ライフサイクル動詞(start/stop/status oms)以外)

- ADP/JVMD/BI Publisherの構成

注意:
オンデマンド・レプリケーションの実行に必要な手順は、記憶域のドキュメントを参照してください。

18.7 ACFSレプリケーションが可能な障害時リカバリ・ソリューション

自動ストレージ管理クラスタ・ファイル・システム(ACFS)レプリケーションによって、ネットワーク経由でのACFSファイル・システムのリモート・サイトへのレプリケーションが可能になります。この機能は、障害時リカバリ機能の実現に役立ちます。次の図では、Enterprise Managerのインストールで障害時リカバリを実現するためにこの機能を利用する方法を示しています。

図18-2 ACFSレプリケーション

ACFSレプリケーションの構成

1. グリッド・インフラストラクチャをインストールして、ACFSサーバーを作成します。
ACFS記憶域レプリケーションでは、クラスタに対してグリッド・インフラストラクチャがインストールされる必要がありますが、単一ノードでのインストールも可能です(単一ノード・クラスタ)。

2. OMSインストールおよびソフトウェア・ライブラリに使用するために、ACFSサーバー(手順1で作成済)上にACFSファイル・システムを作成します。

3. NFSを使用してACFSファイル・システムをエクスポートします。
ACFSマウント・ポイントに対してroot squashを無効にします(無効にしないと、Enterprise Managerがクライアントにインストールされた後でroot.shが動作しなくなります)。

4. 次のオプションを使用して、(OMS用に使用することになっている)別のノードにファイル・システムをマウントします。

Nfs rw,bg,hard,nointr,rsize=131072,wsize=131072,tcp,vers=3, timeo=300,actimeo=120

5. NFS (ACFS)ファイル・システムにEnterprise Managerをインストールします。

6. スタンバイ用として使用するために、別のACFSファイル・システムで2番目のACFSサーバー(単一ノード・クラスタ)を作成します。

7. プライマリACFSサーバーとスタンバイACFSサーバー間に、ACFSレプリケーションを設定します。

1. スタンバイ・サーバーでは、次のコマンドを使用してレプリケーションを開始します。
/sbin/acfsutil repl init standby -p

ルート・ユーザーによって実行されます。

2. 次のコマンドを使用して、スタンバイ・ファイル・システムが起動していることを確認します。
/sbin/acfsutil repl info

3. プライマリ・サーバーでは、次のコマンドを使用してレプリケーションを開始します。
/sbin/acfsutil repl init primary -s

4. 次のコマンドを使用して、プライマリ・ファイル・システムが起動していることを確認します。
/sbin/acfsutil repl info -c

8. プライマリ・サーバーからスタンバイにスイッチオーバーします。スイッチオーバー操作の実行に関する明示的な手順については、18.5.1項「スイッチオーバーの手順」を参照してください(ただし、次の変更があります)。
手順4:

次の手順を実行して、OMSおよびソフトウェア・ライブラリ・ファイル・システムのオンデマンド・レプリケーションを実行します。

次のコマンドを使用して、プライマリ・サーバーからEnterprise Managerファイル・システムへのACFS同期を実行します。

/sbin/asfsutil repl sync apply

手順7:

次の手順を実行して、ソフトウェア・ライブラリおよびOMS記憶域のロール・リバーサルを実行します。

次のコマンドを使用して、ACFSレプリケーションを停止します。

/sbin/acfsutil repl terminate standby

ACFSレプリケーションを再構成するには、この項で前述した手順7「プライマリACFSサーバーとスタンバイACFSサーバー間に、ACFSレプリケーションを設定します。」に示されている手順を実行します。

19 Enterprise Managerのバックアップとリカバリ

エコシステムの監視および管理フレームワークと同様に、高可用性計画の重要な部分は、Enterprise Managerの定期的なバックアップを確実に行い、障害発生時のリストアを可能にすることです。

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

- デプロイメントのバックアップ

- ソフトウェア・ライブラリのバックアップ

- リポジトリ・バックアップの管理

- Oracle Management Serviceのバックアップ

- エージェント・バックアップの管理

- 障害の発生したEnterprise Managerコンポーネントのリカバリ

- OMSと管理リポジトリの同時障害からのリカバリ

19.1 デプロイメントのバックアップ

Enterprise Managerは単一のエンティティとして機能しますが、技術的には、次のソフトウェア・コンポーネントで構成される分散型の多層ソフトウェア・アーキテクチャで構築されています。

- Oracle Management Services(OMS)

- 管理エージェント

- 管理リポジトリ

- ソフトウェア・ライブラリ

各コンポーネントは、構成と機能がそれぞれ異なり、バックアップとリカバリに対して異なるアプローチを必要とします。このため、バックアップ戦略について、この章では層別に説明します。Enterprise Managerアーキテクチャの概要については、『Oracle® Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

19.2 ソフトウェア・ライブラリのバックアップ

ソフトウェア・ライブラリは、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなどのEnterprise Managerソフトウェア・エンティティの集中メディア記憶域です。ソフトウェア・ライブラリはEnterprise Managerフレームワークの不可欠な部分であり、多くのEnterprise Manager機能が適切に機能するために必須です。ソフトウェア・ライブラリの記憶域の場所は、ファイルシステム・バックアップを使用して定期的にバックアップする必要があります。1時間から24時間の頻度でバックアップを実行することをお薦めします。

19.3 リポジトリ・バックアップの管理

管理リポジトリは、管理エージェントにより収集されたすべての情報が保管される記憶域です。データベース・ジョブ、パッケージ、プロシージャ、ビューおよび表領域などのオブジェクトで構成されます。これはOracle Databaseで構成されるため、管理リポジトリのバックアップおよびリカバリ戦略は、基本的にはOracle Databaseの戦略と同じになります。データベースのバックアップ・プロシージャは、十分に確立した標準であり、RMANバックアップ・ユーティリティを使用して実装でき、このユーティリティにはCloud Controlコンソールからアクセスできます。

リポジトリ・バックアップの管理

管理リポジトリ・データベースの計画外の停止を回避するために、高可用性のベスト・プラクティスを使用することをお薦めします。このためには、次の標準のデータベース・バックアップ戦略を使用します。

- データベースはarchivelogモードにします。リポジトリ・データベースをarchivelogモードで実行しないと、メディア障害後のリカバリ不能な状況でデータベースが脆弱なままになります。

- Cloud Controlコンソールを介して推奨バックアップ戦略オプションを使用し、RMANによる通常のホット・バックアップを実行します。他のユーティリティ(例: DataGuardやRAC)も、一般的にHAレベル3または4で実装される包括的なHAおよびデータ保護の計画の一部として利用できます。様々なHAレベルの詳細は、第16章の「高可用性レベルの実装」を参照してください。

これらの戦略に従うと、全体バックアップが作成された後、以降は毎回増分バックアップが作成されます。増分の変更はベースラインにロールアップされ、新しい全体バックアップ・ベースラインが作成されます。

推奨バックアップ戦略を使用すると、Enterprise Managerのバックアップ実行機能も利用でき、ジョブはEnterprise Managerのジョブ・サブシステムを通じて自動的にスケジュールされます。これで、バックアップの履歴がレビューで使用可能になり、バックアップのステータスがリポジトリ・データベース・ターゲットのホームページで表示されます。このバックアップ・ジョブとアーカイブおよびフラッシュバック・テクノロジを併用すると、リポジトリのいずれかの部分が失われた場合のリストア・ポイントが得られます。このタイプのバックアップ処理およびアーカイブ・ログとオンライン・ログにより、リポジトリを最後に完了したトランザクションまでリカバリできます。

最後のリポジトリのバックアップが発生した時間を「リポジトリの詳細」セクションの「管理サービスとリポジトリ概要」ページで表示できます。

Enterprise Managerを使用したバックアップの構成方法のサマリーは、『Oracle Database 2日でデータベース管理者』を参照してください。データベースの高可用性に関するベスト・プラクティスの付加情報は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

19.4 Oracle Management Serviceのバックアップ

Oracle Management Service(OMS)は管理エージェントを編成し、ターゲットを検出、監視および管理し、収集された情報を将来の参照および分析のためリポジトリに格納します。OMSは、Enterprise Managerコンソール用のWebインタフェースもレンダリングします。

OMSのバックアップ

OMSは通常、ステートレスです。構成データの一部は、OMSファイルシステムに格納されます。

OMS構成のスナップショットは、emctl exportconfig omsコマンドを使用して取得できます。

$ <OMS_HOME>/bin/emctl exportconfig oms [-sysman_pwd <sysman password>]
[-dir <backup dir>] Specify directory to store backup file
[-keep_host] Specify this parameter if the OMS was installed using a virtual hostname (using
ORACLE_HOSTNAME=<virtual_hostname>)

exportconfigを実行すると、特定の時点のOMSのスナップショットが取得されるため、最新のOMS構成を定期的にバックアップできます。exportconfigは常に、WebLogic管理サーバーを実行するOMSで実行します。必要に応じて、最新のスナップショットを同一または別のホスト上のフレッシュOMSインストールにリストアできます。

OMSコンポーネントのバックアップ戦略は次のとおりです。

- ソフトウェア・ホーム
Fusion Middlewareホーム、OMS Oracleホーム、Web層(OHS)Oracleホーム、および複数の管理プラグインOracleホームから構成されます。

ソフトウェア・ホームは、パッチやパッチセットが適用される場合および更新が新しい自己更新機能により提供される場合に変わります。このため、ファイルシステムレベルのバックアップは、各パッチ/パッチセットの適用後、または自己更新による更新の適用後に作成する必要があります。Oracleインベントリ・ファイルとソフトウェア・ホームをバックアップし、opatch lsinventory –detailの出力を保存して、バックアップしたOracleホームに適用したパッチを特定しやすくしてください。

注意:
ファイルシステムレベルのバックアップがない場合、ソフトウェア・ホームをInstalling Software Onlyインストール方法を使用して再インストールすることもできます。
重要: OMS Oracleホームの場所は、Cloud ControlデプロイメントのすべてのOMSインスタンスと同じにしてください。

- インスタンス・ホーム
gc_instディレクトリには、WebLogic Server、OMSおよびWeb層の構成ファイルがあります。

インスタンス・ホームはemctl exportconfig omsコマンドを使用してバックアップできます。

- 管理サーバー
管理サーバーは、OMSインスタンスのドメイン全体を構成するための集中管理エンティティとして動作します。管理サーバーは、Cloud Controlデプロイメントにインストールされる最初のOMSの不可欠な要素であり、ソフトウェア・ホームとインスタンス・ホームを共有します。

管理サーバーは、emctl exportconfig omsコマンド(管理サーバーのある最初のOMSでのみ実行)により、インスタンス・ホームと同時にバックアップされます。

19.5 管理エージェントのバックアップ

管理エージェントは、監視対象の各ホストにデプロイされている統合ソフトウェア・コンポーネントです。これらのホスト上で実行されているすべてのターゲットの監視、中間層のOMSへのこの監視情報の伝達、ホストおよびそのターゲットの管理およびメンテナンスを行います。

管理エージェントのバックアップ

管理エージェントのバックアップに関する特別な考慮事項はありません。ベスト・プラクティスとしては、管理エージェントの参照インストールを異なるプラットフォームに対して保持し、emd.propertiesファイルで実行済のカスタマイズと適用済のパッチが最新の状態に保たれるようにします。参照エージェント・インストールのインストールおよび保持には、Cloud Controlコンソールのデプロイメント・オプションを使用します。

管理エージェントが失われた場合、参照インストールからクローニングして再インストールする必要があります。

19.6 障害の発生したEnterprise Managerコンポーネントのリカバリ

Enterprise Managerのリカバリは、Enterprise Managerアーキテクチャの3つの基本的なコンポーネントのリストアを意味します。

- 管理リポジトリ

- 管理サービス

- 管理エージェント

- ソフトウェア・ライブラリ

19.6.1 リポジトリのリカバリ

リポジトリ・データベースの停止時はCloud Controlは使用できないため、リポジトリ・データベースのリカバリはRMANを使用して実行する必要があります。次の2種類のリカバリを考慮する必要があります。

- 完全リカバリ: Enterprise Managerに関する特別な考慮事項はありません。

- ポイント・イン・タイム/不完全リカバリ: リカバリされたリポジトリは、トランザクションの損失のため、エージェントと同期化されていない場合があります。この状況では、エージェントで使用できる最新の状態とリポジトリが同期化されないかぎり、一部のメトリックがCloud Controlで誤って表示される場合があります。

リポジトリの再同期化機能により、Enterprise Managerリポジトリを管理エージェントで使用可能な最新の状態と同期化するプロセスを自動化できます。

リポジトリを管理エージェントと再同期化するには、Enterprise Managerコマンドライン・ユーティリティ(emctl)のresync reposコマンドを使用します。

emctl resync repos -full -name "<descriptive name for the operation>"

このコマンドは、管理リポジトリをリストアした後、かつ、OMSを起動する前に、OMS Oracleホームから実行する必要があります。コマンドの発行後、すべてのOMSインスタンスを起動し、次の図に示すように、Enterprise Managerコンソールのリポジトリの再同期化ページからリポジトリの再同期化の進行状況を監視します。

図19-1 「リポジトリの同期化」ページ

管理リポジトリのリカバリが完了するのは、再同期化ジョブがすべての管理エージェントで完了したときです。

障害発生時にデータベースを最新のトランザクションまでリカバリできるように、管理リポジトリ・データベースをarchivelogモードで実行することをお薦めします。データベースを最後のトランザクションまでリカバリできない場合は、リポジトリの同期化を使用して、最後のバックアップの作成時に存在していたターゲットの監視機能をリストアできます。バックアップ後に行ったアクションは、自動的にはリカバリされません。リポジトリの同期化で自動的にリカバリされないアクションの例は次のとおりです。

- インシデント・ルール

- 優先資格証明

- グループ、サービス、システム

- ジョブ/デプロイメント手順

- カスタム・レポート

- 新しいエージェント

19.6.2 リカバリ・シナリオ

リポジトリ(または任意のデータベース)をリカバリする前提条件は、リポジトリの有効な一貫性バックアップがあることです。Enterprise Managerを使用してバックアップ・プロセスを自動化すると、リポジトリのリカバリが必要になった場合に備えて、通常の最新バックアップが常に用意されます。Recovery Manager(RMAN)は、Oracle Databaseのバックアップ、リストアおよびリカバリを行うユーティリティです。RMANのリカバリ・ジョブの構文は、安全な場所に保存する必要があります。これにより、Enterprise Managerリポジトリ・データベースの完全リカバリを実行できます。最も単純な形式では、構文は次のようになります。

run {
restore database;
recover database;
}

実際の構文は、環境によって長さや複雑さが異なります。構文をRMANのバックアップおよびリカバリ・ジョブから抽出する方法、またはRMANの一般的な使用方法は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

次の各シナリオでは、様々なリポジトリのリカバリ状況とそのリカバリ手順を示します。

19.6.2.1 同一ホスト上の完全リカバリ

リポジトリ・データベースはarchivelogモードで実行されています。最近のバックアップ、アーカイブ・ログ・ファイルおよびREDOログがあります。リカバリ・データベース・ディスクがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

1. emctl stop oms -allを使用して、すべてのOMSインスタンスを停止します。

2. RMANを使用してデータベースをリカバリします。

3. すべてのOMSインスタンスでコマンドemctl start omsを使用してサイトを起動します。

4. サイトが完全に動作していることを確認します。

19.6.2.2 同一ホスト上の不完全リカバリ

リポジトリ・データベースはnoarchivelogモードで実行されています。全体オフライン・バックアップがあります。リカバリ・データベース・ディスクがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

1. emctl stop oms -allを使用して、OMSインスタンスを停止します。

2. RMANを使用してデータベースをリカバリします。

3. emctl resync repos -full -name "<resync name>"を使用して、OMS Oracleホームの1つからリポジトリの再同期化を開始します。

4. emctl start omsを使用して、OMSインスタンスを起動します。

5. Cloud Controlにログインします。「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。管理サービスとリポジトリ・ページが表示されます。

6. 「OMSとリポジトリ」メニューから、「リポジトリの同期化」を選択します。

7. サイトが完全に動作していることを確認します。

19.6.2.3 別のホスト上の完全リカバリ

管理リポジトリ・データベースは、ホストAでarchivelogモードで実行中です。最近のバックアップ、アーカイブ・ログ・ファイルおよびREDOログがあります。リポジトリ・データベースがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

1. コマンドemctl stop omsを使用して、OMSインスタンスを停止します。

2. RMANを使用して、データベースを別のホスト(ホストB)上でリカバリします。

3. 各OMSで次のコマンドを実行して、リポジトリの接続記述子を修正します。

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

4. 次のコマンドを使用してOMSを停止します。
emctl stop oms -all

5. 次のコマンドを使用してOMSインスタンスを起動します
emctl start oms

6. 次のコマンドをOMSから実行し、管理リポジトリ・データベース・ターゲットをホストB上で実行されているエージェントに再配置します。

$emctl config repos -host <hostB> -oh <OH of repository on hostB>  -conn_desc "<TNS connect descriptor>"

注意:
このコマンドは、次の条件を満たしている場合にのみ、リポジトリ・データベースの再配置に使用できます。

- エージェントがこのマシン上ですでに実行されていること。

- ホストB上のデータベースが検出されていないこと。

7. 次のコマンドをOMSから実行し、OMSおよびリポジトリ・ターゲットの監視構成を変更します。

$emctl config emrep -conn_desc "<TNS connect descriptor>"

8. サイトが完全に動作していることを確認します。

19.6.2.4 別のホスト上の不完全リカバリ

管理リポジトリ・データベースは、ホストAでnoarchivelogモードで実行中です。全体オフライン・バックアップがあります。ホストAはハードウェア障害のために失われました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

1. emctl stop omsを使用して、OMSインスタンスを停止します。

2. RMANを使用して、データベースを別のホスト(ホストB)上でリカバリします。

3. 資格証明ストアのリポジトリの接続記述子を修正します。

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

このコマンドはomsを停止して起動するよう求めます。

4. リポジトリの再同期化を開始します。
$emctl resync repos -full -name "<resync name>"

これは、OMS Oracleホームの1つから開始します。

5. コマンドemctl start omsを使用して、OMSを起動します。

6. コマンドを実行して、リポジトリ・データベース・ターゲットをホストBで実行されている管理エージェントに再配置します。
$emctl config repos -agent <agent on host B> -host <hostB> -oh <OH of repository on hostB> -conn_desc "<TNS connect descriptor>"

7. 次のコマンドを実行し、OMSおよびリポジトリ・ターゲットの監視構成を変更します。
emctl config emrep -conn_desc "<TNS connect descriptor>"

8. Cloud Controlにログインします。「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。

9. 「OMSとリポジトリ」メニューから「リポジトリの同期化」を選択します。再同期化ジョブのステータスを監視します。前述のエラーの修正後、失敗したジョブがあれば、そのジョブを再発行します。

10. サイトが完全に動作していることを確認します。

19.6.3 OMSのリカバリ

Oracle Management Serviceのインスタンスが失われた場合、OMSのリカバリは基本的に、ソフトウェア・ホームのリカバリ、インスタンス・ホームの構成、およびソフトウェア・ライブラリがEnterprise Managerと同じホストで構成されている場合はソフトウェア・ライブラリのリカバリという3つの手順で構成されます。

19.6.3.1 ソフトウェア・ホームのリカバリ

同じホストでリストアする場合、ソフトウェア・ホームをファイルシステム・バックアップからリストアできます。バックアップが存在しない場合、または別のホストへインストールする場合、ソフトウェア・ホームは、Cloud Controlソフトウェアのディストリビューションから「ソフトウェアのみインストール」オプションを使用して再構築できます。クラッシュ前に環境に存在したすべての管理プラグインを選択してインストールする必要があることに注意してください。

1. 管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行して、インストール済のプラグインのリストを取得します。

SELECT epv.display_name, epv.plugin_id, epv.version, epv.rev_version,decode(su.aru_file, null, 'Media/External', 'https://updates.oracle.com/Orion/Services/download/'||aru_file||'?aru='||aru_id||chr(38)||'patch_file='||aru_file) URL
FROM em_plugin_version epv, em_current_deployed_plugin ecp, em_su_entities su
WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME')
AND ecp.dest_type='2'
AND epv.plugin_version_id = ecp.plugin_version_id
AND su.entity_id = epv.su_entity_id;

前述の問合せでは、プラグインのリストと、自己更新でダウンロードされた場合にはダウンロードするためのURLが返されます。プラグインがインストール・メディアにあるか、自己更新で取得できないサード・パーティのプラグインの場合、URLは"Media/Unknown"とマークされます。

2. 追加のプラグイン(ある場合)を、手順1の問合せで返されたリストのURLからダウンロードして、1つのディレクトリに配置します。ファイル名の拡張子を.zipから.oparに変更します。

3. インストーラを起動して、ソフトウェア専用のオプションを選択し、ミドルウェアおよびOMS Oracleホームをインストールします。

4. 必要なプラグインをインストールするには、PluginInstall.shスクリプト(OMS_HOME/sysman/install/PluginInstall.sh)を、ダウンロードしたプラグインの保存先ディレクトリへのパスを指定する-pluginLocation <プラグイン・ディレクトリへの絶対パス>を使用して、実行する必要があります。プラグインの選択を求められたら、必ずSQL問合せにリストされたプラグインと同じプラグインを選択してください。

注意:
すべての必要なプラグインがインストールされていない場合、リカバリは失敗します。

ソフトウェア専用モードの後で、クラッシュの前にインストールされたすべてのパッチを再度適用する必要があります。管理リポジトリが損傷していないと仮定した場合、リポジトリに対してSQLを実行する後処理スクリプトは、リポジトリにはそのようなパッチを適用済なので省略できます。

前述のように、OMS Oracleホームの場所は修正されるため、変更できません。そのため、以前に使用された場所でOMS Oracleホームをリストアするようにします。

19.6.3.2 OMSの再作成

ソフトウェア・ホームをリカバリすると、インスタンス・ホームはリカバリ・モードでomscaコマンドを使用して再構築できます。

omsca recover –as –ms -nostart –backup_file <exportconfig file>

次の項で示すemctl exportconfigコマンドで生成されるエクスポート・ファイルを使用します。

19.6.4 OMSのリカバリ・シナリオ

次の各シナリオでは、OMSの様々なリカバリ状況とそのリカバリ手順を示します。

重要:
OMSリカバリの前提条件は、最近の有効なOMS構成バックアップがあることです。OMS構成が変更されるたびに、emctl exportconfig omsコマンドを使用してOMSをバックアップすることをお薦めします。このコマンドは、WebLogic AdminServerを実行するプライマリOMSで実行する必要があります。
または、Enterprise Managerのジョブ・システムを使用して、このコマンドを定期的に実行できます。

次の各シナリオでは、ファイルシステムのバックアップ(使用可能な場合および同じホストへのリカバリの場合のみ)を使用、またはインストーラのソフトウェア専用オプションを使用したソフトウェア・ホームのリカバリについて示します。いずれの場合も、ベスト・プラクティスはファイルシステムのバックアップからではなく、omsca recoverコマンドを使用したインスタンス・ホーム(gc_inst)をリカバリすることです。これにより、インスタンス・ホームが有効で、最新であることが保証されます。

19.6.4.1 単一OMS、サーバー・ロード・バランサ(SLB)なし、OMSを同一ホスト上でリストア

サイトは単一OMSをホストします。SLBはありません。AdminServerを実行するプライマリAdminServerでemctl exportconfig omsコマンドを使用してOMS構成をバックアップしました。OMS Oracleホームが失われました。

解決方法:

1. 障害の発生したOMSホストでクリーンアップを実行します。
次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。

ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9

注意:
Middleware|gc_instを、自身のミドルウェアおよびインスタンスのホームと一致する文字列に変更します。

ソフトウェア専用インストール方法を使用してソフトウェア・ホームをリカバリしている場合、最初にCloud Controlソフトウェアのディストリビューション・インストーラを使用して既存のOracleホームを削除します。ソフトウェア・ホームが使用可能でなくなっている場合にも、失われたOracleホームのレコードをOracleインベントリから削除する必要があるので、これは必要です。

存在する場合、Middlewareおよびgc_instディレクトリを削除します。

2. ソフトウェア・ライブラリの場所にアクセスでき、有効であることを確認します。ソフトウェア・ライブラリがアクセス可能だが破損している場合、OMSCAリカバリに影響します。

3. ソフトウェア・ホームをリストアします。詳細は、第19.6.3.1項「ソフトウェア・ホームのリカバリ」を参照してください。
ファイルシステム・バックアップからリストアしている場合、次のファイルを削除します。

OMS_HOME/sysman/config/emInstanceMapping.properties

また、存在する場合はリストアされた可能性のあるgc_instを削除します。

4. 以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。

<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>

注意:
渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。

5. OMSを開始します。

OMS_HOME/bin/emctl start oms

6. エージェントをリカバリします(必要な場合)。
管理エージェント・ソフトウェア・ホームがOMSソフトウェア・ホームとともにリカバリされた場合(おそらくは単一OMSインストール・リカバリで、agentおよびagent_instディレクトリが一般的なMiddlewareホームの下にある場合)、管理エージェントとOMS間の整合性を保証するために、管理エージェント・インスタンス・ディレクトリを再作成する必要があります。

1. バックアップからリストアされた場合、agent_instディレクトリを削除します。

2. agentDeploy.shを使用してエージェントを構成します。

<AGENT_BASE_DIR>/core/12.1.0.4.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

管理エージェント構成が失敗した場合は、<AGENT_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.agent_<time_stamp>.logを参照してください。

3. OMSが管理エージェントをブロックすることがあります。次のコマンドを使用してエージェントをリポジトリと同期化します。
<OMS_HOME>/bin/emcli resyncAgent -agent=<agent target name myhost.example.com:3872>

管理エージェント・ソフトウェア・ホームがOMSとともにリカバリされず、引き続きエージェントをリカバリする必要がある場合、「同じポートを使用したエージェントの再インストール」の項の手順に従ってください。

注意:
これは、エージェント・ソフトウェア・ホームのバックアップを含まない、ファイルシステムのリカバリが実行された場合にのみ必要になる可能性があります。OMSソフトウェア・ホームがソフトウェア専用インストール方法を使用してリカバリされた場合、この手順は必要ありません。ソフトウェア専用インストールではMiddlewareホームの下のエージェント・ソフトウェア・ホームにインストールされるからです。

7. サイトが完全に動作していることを確認します。

19.6.4.2 単一OMS、SLBなし、OMSを別のホスト上でリストア

サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。

解決方法:

1. ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。

2. ホストBにソフトウェア・ホームをリストアします。詳細は、第19.6.3.1項「ソフトウェア・ホームのリカバリ」を参照してください。

3. 以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。

<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>

注意:
渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。

4. OMSを開始します。

<OMS_HOME>/bin/emctl start oms

エージェントはソフトウェア専用インストールの一部としてインストールされ、agentDeploy.shコマンドを使用して構成される必要があります。

5. エージェントを構成します。

<AGENT_BASE_DIR>/core/12.1.0.4.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

管理エージェント構成が失敗した場合は、<AGENT_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.agent_<time_stamp>.logを参照してください。

6. 次のコマンドを使用し、oracle_emrepターゲットを新しいOMSホストの管理エージェントに再配置します。

<OMS_HOME>/bin/emcli login –username=sysman
<OMS_HOME>/bin/emcli sync
<OMS_HOME>/bin/emctl config emrep -agent <agent on host "B", e.g myNewOMSHost.example.com:3872>

注意:
emctl config emrep -agentを実行し、フラグ-ignore_timeskewを設定した場合、管理サービスとリポジトリ・ターゲットが新しいエージェントに移動されたときに監視対象ターゲットの可用性が影響を受けて監視データが失われることがあります。

7. Cloud Controlコンソールで、Cloud ControlドメインのWebLogic Domainターゲットを再配置します。「監視資格証明」に移動して管理ホストをホストBに更新します。「WebLogicドメインのリフレッシュ」を実行して新しいホストでドメインを再構成します。

8. 重複したターゲットを、Enterprise Managerコンソールの「管理サービスとリポジトリ概要」ページで探します。「重複したターゲット」リンクをクリックして「重複したターゲット」ページにアクセスします。重複したターゲットのエラーを解決するには、重複したターゲットの名前を、競合が発生しているエージェントで変更する必要があります。重複したターゲットをエージェントAからエージェントBに再配置します。

9. すべての管理エージェントが指し示すOMSを変更してから、すべてのエージェントを再保護します。
新しいマシンでは、OMSをホストしていた以前のマシンとは異なるホスト名を使用するため、監視対象の環境内のすべてのエージェントに、新しいOMSを検索する場所を指示する必要があります。各管理エージェントから、次のコマンドを実行します。

<AGENT_INST_DIR>/bin/emctl secure agent -emdWalletSrcUrl "http://hostB:<http_port>/em"

10. 元のOMSが使用されなくなったと仮定し、「ターゲット」、「ホスト」ページの順に選択して「削除」をクリックすることで、ホスト・ターゲット(すべての残りの監視対象ターゲットを含む)をCloud Controlから削除します。最初にすべての管理対象ターゲットを削除することを知らせるエラーが表示されます。それらのターゲットを削除してから、ホスト・ターゲットを正常に削除する手順を繰り返します。

11. サイトが完全に動作していることを確認します。

19.6.4.3 単一OMS、SLBなし、OMSをオリジナルのホスト名を使用して別のホスト上でリストア

サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。リカバリはホストBで実行されますが、ホスト名Aはそのまま使用されます。

解決方法:

1. ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。

2. ホストBにソフトウェア・ホームをリストアします。詳細は、第19.6.3.1項「ソフトウェア・ホームのリカバリ」を参照してください。

3. ホストBもホスト名ホストAに反応するようにネットワーク構成を変更します。この構成方法の特別な手順については、本書では扱いません。ただし、いくつかの汎用的な構成方法を次に示します。
ホスト名ホストBとホスト名ホストAの両方のネットワーク・アドレスがホストBの物理IPに解決するようにDNSサーバーを変更します。

マルチホームのホストB。ホスト名Aが解決するIPアドレスに対するホストBに追加のIPを構成します。たとえば、ホストBで次のコマンドを実行します。

ifconfig eth0:1 <IP assigned to ”Hostname A”> netmask <netmask>
/sbin/arping -q -U -c 3 -I eth0 <IP of HostA>

4. 以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。

<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file> -AS_HOST <hostA> -EM_INSTANCE_HOST <hostA>

注意:
渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。

5. OMSを開始します。

<OMS_HOME>/bin/emctl start oms

6. エージェントを構成します。
エージェントはソフトウェア専用インストールの一部としてインストールされ、agentDeploy.shコマンドを使用して構成される必要があります。

<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

OMSが管理エージェントをブロックすることがあります。次のコマンドを使用してエージェントをリポジトリと同期化します。

<OMS_HOME>/bin/emcli resyncAgent -agent=<agent target name myhost.example.com:3872>

7. サイトが完全に動作していることを確認します。

19.6.4.4 複数OMS、サーバー・ロード・バランサ、プライマリOMSを同一ホスト上でリカバリ

サイトは複数のOMSインスタンスをホストします。すべてのOMSインスタンスの前にサーバー・ロード・バランサがあります。WebLogic AdminServerを実行するプライマリOMSでemctl exportconfig omsコマンドを使用してOMS構成をバックアップしました。プライマリOMSが失われました。

解決方法:

1. 障害の発生したOMSホストでクリーンアップを実行します。
次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。

ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9

注意:
Middleware|gc_instを、自身のミドルウェアおよびインスタンスのホームと一致する文字列に変更します。

ソフトウェア専用インストール方法を使用してソフトウェア・ホームをリカバリしている場合、最初にCloud Controlソフトウェアのディストリビューション・インストーラを使用して既存のOracleホームを削除します。ソフトウェア・ホームが使用可能でなくなっている場合にも、失われたOracleホームのレコードをOracleインベントリから削除する必要があるので、これは必要です。

存在する場合、Middlewareおよびgc_instディレクトリを削除します。

2. ソフトウェア・ライブラリの場所にアクセスできることを確認します。

3. ソフトウェア・ホームをリストアします。詳細は、第19.6.3.1項「ソフトウェア・ホームのリカバリ」を参照してください。
ファイルシステム・バックアップからリストアしている場合、次のファイルを削除します。

<OMS_HOME>/sysman/config/emInstanceMapping.properties

4. 以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。

<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>

注意:
渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。

5. OMSを開始します。

<OMS_HOME>/bin/emctl start oms

6. 管理エージェントのリカバリ
管理エージェント・ソフトウェア・ホームがOMSソフトウェア・ホームとともにリカバリされた場合(おそらくはプライマリOMSインストール・リカバリで、agentおよびagent_instディレクトリが一般的なMiddlewareホームの下にある場合)、管理エージェントとOMS間の整合性を保証するために、管理エージェント・インスタンス・ディレクトリを再作成する必要があります。

1. バックアップからリストアされた場合、agent_instディレクトリを削除します。

2. agentDeploy.shを使用して、次のように管理エージェントを構成します。

<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

3. OMSが管理エージェントをブロックすることがあります。次のコマンドを使用してエージェントをリポジトリと同期化します。
<OMS_HOME>/bin/emcli resyncAgent -agent=<agent target name e.g. myhost.example.com:3872>

管理エージェント・ソフトウェア・ホームがOMSとともにリカバリされず、引き続き管理エージェントをリカバリする必要がある場合、「同じポートを使用したエージェントの再インストール」の項の手順に従ってください。

注意:
これは、管理エージェント・ソフトウェア・ホームのバックアップを含まない、ファイルシステムのリカバリが実行された場合にのみ必要になる可能性があります。OMSソフトウェア・ホームがソフトウェア専用インストール方法を使用してリカバリされた場合は、Middlewareホームの下の管理エージェント・ソフトウェア・ホームにインストールされるため、この手順は必要ありません。

7. サイトが完全に動作していることを確認します。

19.6.4.5 複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ

サイトは複数のOMSインスタンスをホストします。OMSインスタンスの前にサーバー・ロード・バランサがあります。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAのプライマリOMSが失われたため、ホストBでリカバリする必要があります。

1. 必要ならば、障害の発生したOMSホストでクリーンアップを実行します。
次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。

ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9

2. ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。

3. ホストBにソフトウェア・ホームをリストアします。詳細は、第19.6.3.1項「ソフトウェア・ホームのリカバリ」を参照してください。

4. 以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。

<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>

注意:
渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。

5. OMSを開始します。

<OMS_HOME>/bin/emctl start oms

6. 管理エージェントを構成します。
エージェントはソフトウェア専用インストールの一部としてインストールされ、agentDeploy.shコマンドを使用して構成される必要があります。

<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

失敗したエージェントにデフォルト以外のプラグインが以前デプロイされていた場合、エージェントのリカバリ後にそれらを再デプロイする必要があります。これは、リカバリしているエージェントに失敗の前から存在したプラグインに関連し(OMS/リポジトリ・ターゲットには関連しません)、また、OMSエージェントが偶然監視していた追加ターゲットの任意のプラグインに関連することに注意してください。プラグインを再デプロイするには、次のコマンドを実行します(config emrepの一部としてではなく、また手動でもない)。

emcli relocate_targets

7. 追加の管理サービスがある場合は、現在ホストBで実行中の管理サーバーに再登録する必要があります。管理サービスを再登録するには、追加のOMSのそれぞれで次のコマンドを実行します。
<OMS-HOME>/bin/emctl enroll oms -as_host <new Admin Server host, i.e. host B> -as_port <admin server port>

8. 新しいOMSをSLB仮想サーバー・プールに追加して古いOMSを削除します。

9. 次のコマンドを使用し、oracle_emrepターゲットを新しいOMSホストの管理エージェントに再配置します。

<OMS_HOME>/bin/emcli sync
<OMS_HOME>/bin/emctl config emrep -agent <agent on host "B", e.g myNewOMSHost.example.com:3872>

注意:
emctl config emrep -agentを実行し、フラグ-ignore_timeskewを設定した場合、管理サービスとリポジトリ・ターゲットが新しいエージェントに移動されたときに監視対象ターゲットの可用性が影響を受けて監視データが失われることがあります。

10. Cloud Controlコンソールで、Cloud ControlドメインのWebLogic Domainターゲットを再配置します。「監視資格証明」に移動して管理ホストをホストBに更新します。「WebLogicドメインのリフレッシュ」を実行して新しいホストでドメインを再構成します。

11. 重複したターゲットを、Enterprise Managerコンソールの「管理サービスとリポジトリ概要」ページで探します。「重複したターゲット」リンクをクリックして「重複したターゲット」ページにアクセスします。重複したターゲットのエラーを解決するには、競合している管理エージェントで重複しているターゲットの名前を変更する必要があります。重複したターゲットを管理エージェントAから管理エージェントBに再配置します。

12. 元のOMSが使用されなくなったと仮定し、「ターゲット」、「ホスト」ページの順に選択して「削除」をクリックすることで、ホスト・ターゲット(すべての残りの監視対象ターゲットを含む)をCloud Controlから削除します。最初にすべての管理対象ターゲットを削除することを知らせるエラーが表示されます。それらのターゲットを削除してから、ホスト・ターゲットを正常に削除する手順を繰り返します。

13. システム内の他のすべてのOMSは、次のコマンドを使用して、新しくリカバリされたOMSに再登録する必要があります。

emctl enroll oms -as_host <new OMS host> -as_port <port #, default 7101>

14. サイトが完全に動作していることを確認します。

19.6.4.6 複数OMS、SLB構成済、追加OMSが同一または別のホスト上でリカバリ

OMSインスタンスがSLBの前にある、複数OMSサイト。OMS構成は最初のOMSでemctl exportconfig omsコマンドを使用してバックアップされました。追加のOMSが失われたため、同一または別のホストでリカバリする必要があります。

1. 同じホストにリカバリされている場合、障害の発生したOMSのクリーンアップが実行されたことを確認します。
次のコマンドに類似したコマンドを使用して、Middlewareホームから実行中のプロセスがないことを確認します。

ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9

Cloud Controlソフトウェアのディストリビューション・インストーラを使用して、最初に既存のOracleホームを削除します。ソフトウェア・ホームが使用可能でなくなっている場合にも、失われたOracleホームのレコードをOracleインベントリから削除する必要があるので、これは必要です。

存在する場合、Middlewareおよびgc_instディレクトリを削除します。

2. 共有ソフトウェア・ライブラリの場所がアクセスできることを確認します。

3. 必要なホスト(場合によって同じまたは異なる)に管理エージェントをインストールします。

4. 追加のOracle Management Serviceをインストールする手順については、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のサイレント・モードでの追加のOracle Management Serviceのインストールに関する説明を参照してください。

5. サイトが完全に動作していることを確認します。

19.6.5 ソフトウェア・ライブラリのリカバリ

ソフトウェア・ライブラリが失われた場合、使用可能な最後のバックアップからリストアする必要があります。バックアップをリストアした後、不足しているエンティティを検証および再インポートするために次のコマンドを実行する必要があります。

1. emcli verify_swlib - このコマンドは、ソフトウェア・ライブラリの記憶域の場所へのアクセシビリティを検証し、エンティティにファイルシステムのファイルがない場合には報告します。

2. emcli reimport_swlib_metadata - このコマンドは、製品とともに出荷されたオラクル社提供のすべてのエンティティを再インポートします。最新のバックアップがある場合、これは必要ありません。emcli verify_swlibコマンドによって、Oracle所有エンティティのファイルがファイルシステムからなくなっていることが報告された場合、emcli reimport_swlib_metadataを実行します。

3. emcli verify_updates - このコマンドは、自己更新によってダウンロードされたエンティティがソフトウェア・ライブラリからなくなっているかどうかを検証します。不足している各エンティティについて、ソフトウェア・ライブラリに再インポートする手順もコマンドによって表示されます。

19.6.6 管理エージェントのリカバリ

管理エージェントが失われた場合、参照インストールからクローニングして再インストールする必要があります。通常、参照インストールからのクローニングは、カスタマイズおよびパッチの追跡および再適用が不要なため、管理エージェント・インストールをリカバリする最速の方法です。同一ポートを使用して管理エージェントを再インストールする場合は、注意が必要です。Enterprise Managerの管理エージェントの再同期化機能を使用すると、再インストールされた管理エージェントを、管理リポジトリに存在するターゲット情報を使用して再構成できます。

注意:
管理エージェントの再同期化は、Enterprise Managerのスーパー管理者のみが実行できます。

同一ポートを使用して管理エージェントを再インストールする場合、OMSは、再インストールであることを検出し、以前に行われたカスタマイズが再インストールされる管理エージェント内の自動検出ターゲットによって上書きされるのを防ぐため、管理エージェントを一時的にブロックします。

ブロックされた管理エージェント:
これは、ブロックされた管理エージェントからのすべてのハートビートまたはアップロード・リクエストをOMSが拒否している状態です。このため、ブロックされたエージェントは、アラートまたはメトリック・データをOMSにアップロードできません。ただし、ブロックされた管理エージェントは、監視データの収集は続行します。
エージェントは、複数ある条件のいずれかが原因でブロックされることがあります。これらを次に示します。

- Enterprise Managerが、エージェントがバックアップからリストアされたことを検出しました。

- エージェント上のプラグインが、管理リポジトリの記録と一致しません。

- ユーザーが手動でエージェントをブロックしました。

最初の2つの条件では、エージェントの状態を消去し管理リポジトリからプラグインをプッシュして、エージェントのブロックを解除するために、エージェントの再同期化が必要になります。

emcli resyncAgent <agent target name>コマンドを使用すると、管理エージェントのホームページで管理エージェントを再同期化およびブロック解除できます。再同期化は、管理リポジトリから管理エージェントにすべてのターゲットをプッシュして、エージェントのブロックを解除します。

19.6.7 管理エージェントのリカバリ・シナリオ

次の各シナリオでは、様々な管理エージェントのリカバリ状況とそのリカバリ手順を示します。管理エージェントの再同期化機能では、再インストールした管理エージェントは、クラッシュした、前の管理エージェントと同じポートを使用する必要があります。

注意:
管理エージェントの再同期化は、Enterprise Managerのスーパー管理者のみが実行できます。

19.6.7.1 同じポートを使用した管理エージェントの再インストール

管理エージェントは複数のターゲットを監視しています。エージェント・インストールが失われました。

1. Oracle Universal Installerを使用して、エージェントのOracleホームを削除します。

注意:
この手順はインベントリをクリーンアップするために必要です。

2. 新しい管理エージェントをインストールするか管理エージェントのクローニング・オプションを使用して、Enterprise Manager経由で管理エージェントを再インストールします。クラッシュしたエージェントが使用していたものと同じポートを指定します。インストールの場所は、以前のインストールと同じである必要があります。
OMSによって、管理エージェントが再インストールされたことが検出され、管理エージェントがブロックされます。

3. 次のコマンドを使用して、管理エージェントの再同期化を開始します。
emcli resyncAgent -agent="Agent Host:Port"

管理リポジトリのすべてのターゲットが新しい管理エージェントにプッシュされます。エージェントはバックログ・ファイルのクリアを指示されるため、クリア状態にします。エージェントは非ブロック化されます。

4. ユーザー定義メトリックのスクリプトの場所が変更された場合は、ユーザー定義メトリックを再構成します。

5. 次のemctlコマンドを使用して、管理エージェントが操作可能で、すべてのターゲット構成がリストアされたことを確認します。

emctl status agent
emctl upload agent

エラーがなく、バックログにXMLファイルがないことを確認します。

19.6.7.2 ファイルシステム・バックアップからの管理エージェントのリストア

単一の管理エージェントが複数のターゲットを監視しています。エージェントOracleホームのファイルシステム・バックアップがあります。エージェント・インストールが失われました。

1. 管理エージェントをファイルシステム・バックアップからリストアして、管理エージェントを起動します。
OMSによって、管理エージェントがバックアップからリストアされたことが検出され、管理エージェントがブロックされます。

2. 次のコマンドを使用して、管理エージェントの再同期化を開始します。
emcli resyncAgent -agent="Agent Host:Port"

管理リポジトリのすべてのターゲットが新しい管理エージェントにプッシュされます。エージェントはバックログ・ファイルのクリアを指示されるため、クリア状態にします。管理エージェントはブロック解除されます。

3. 次のemctlコマンドを使用して、管理エージェントが機能しており、すべてのターゲット構成がリストアされたことを確認します。

emctl status agent
emctl upload agent

エラーがなく、バックログにXMLファイルがないことを確認します。

19.7 OMSと管理リポジトリの同時障害からのリカバリ

OMSと管理リポジトリの両方に障害が同時に発生した場合は、両方のリカバリを同一または別のホスト上で行う必要があるかどうか、複数のOMSインスタンスの前にSLBがあるかどうかなどの要因に応じて、リカバリ状況がより複雑になります。一般に、このタイプの複合障害のリカバリでは、前述の該当するリカバリ・シナリオで説明されている手順に従い、まず管理リポジトリを、次にOMSインスタンスをリカバリします。次の各シナリオでは、OMSと管理リポジトリの2つの障害と、それに必要なリカバリ手順を示します。

19.7.1 縮小構成: 管理リポジトリの不完全リカバリ、同じホスト上のプライマリOMS

管理リポジトリおよびプライマリOMSは同じホスト(ホストA)にインストールされています。管理リポジトリ・データベースは、ホストAでnoarchivelogモードで実行中です。全体コールド・バックアップがあります。最新のOMSバックアップ・ファイルがあります(emctl exportconfig oms)。管理リポジトリ、OMSおよび管理エージェントのクラッシュ。

1. 「同一ホスト上の不完全リカバリ」に示す管理リポジトリのリカバリ手順に従いますが、次の点が異なります。
OMS Oracleホームが使用できず、リストアした管理リポジトリに対してOMSを起動する前に管理リポジトリの再同期化を開始する必要があるため、PL/SQLブロックで「resync」を発行します。SQLplusを使用して管理リポジトリにSYSMANでログインし、次のコマンドを実行します。

begin emd_maintenance.full_repository_resync('<resync name>'); end;

2. 第19.6.4.1項「単一OMS、サーバー・ロード・バランサ(SLB)なし、OMSを同一ホスト上でリストア」に示すOMSリカバリ手順に従います。

3. サイトが完全に動作していることを確認します。

19.7.2 分散構成: 別のホスト上の管理リポジトリの不完全リカバリ、プライマリOMSおよび追加OMS、SLB構成済

管理リポジトリ、プライマリOMSおよび追加OMSはすべて、異なるホスト上にあります。管理リポジトリ・データベースは、ホストAでnoarchivelogモードで実行中でした。最新のバックアップのOMSバックアップ・ファイルがあります(emctl exportconfig oms)。データベースの全体コールド・バックアップがあります。3つのホストすべてが失われました。

1. 第19.6.2.2項「同一ホスト上の不完全リカバリ」に示す管理リポジトリのリカバリ手順に従いますが、次の点が異なります。
OMS Oracleホームが使用できず、リストアした管理リポジトリに対してOMSを起動する前に管理リポジトリの再同期化を開始する必要があるため、PL/SQLブロックで「resync」を発行します。SQLplusを使用して管理リポジトリにSYSMANでログインし、次のコマンドを実行します。

begin emd_maintenance.full_repository_resync('resync name'); end;

2. 第19.6.4.5項「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示すOMSリカバリ手順に従いますが、次の点が異なります。
バックアップ・ファイルにある管理リポジトリ接続記述をオーバーライドするには、追加のomscaパラメータを渡します。

-REPOS_CONN_STR <restored repos descriptor>

第19.6.4.5項「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示す他のパラメータとともにこのパラメータを追加する必要があります。

3. 第19.6.4.6項「複数OMS、SLB構成済、追加OMSを同一または別のホスト上でリカバリ」に示すOMSリカバリ手順に従います。

4. サイトが完全に動作していることを確認します。

20 複数のBI Publisherサーバーの実行

注意:
高可用性環境で(サーバー・ロード・バランサ(SLB)の背後で) Enterprise Managerを実行している場合は、次の点に注意してください。

- プライマリOMSシステム上でプライマリBI Publisherサーバーを構成した場合、追加のOMSシステムでもBI Publisherを構成し実行する必要があります。この章の以降の項を参照して、別の方法で追加のOMSシステムに追加のBI Publisherサーバーを構成します。

- Enterprise Managerシステムに動作中のOMSがある場合、対応するBI Publisherサーバーが動作していないと、Enterprise ManagerからのBI Publisherのレポート作成の実行が失敗することがあります。この場合、次を使用してそのシステムのBI Publisherを起動します。
emctl start oms -bip_only

または、次を使用してそのシステムのOMSを停止します。

emctl stop oms -all

Enterprise Manager 12cリリース4 (12.1.0.4)以降、複数のBI Publisherサーバーと連携するEnterprise Managerを構成できるようになりました。

重要:
それより前のバージョンのEnterprise Managerは、この章で説明するBI Publisherの複数サーバー環境をサポートしません。

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

- BI Publisher複数サーバー環境の概要

- 共有ストレージ・デバイスを使用するためのBI Publisherの再構成

- セカンダリBI Publisherサーバーの追加

- 追加OMSシステムでセカンダリBI Publisherサーバーが正しく動作することの確認

- セカンダリBI Publisherサーバーの詳細の確認

注意:
BI Publisherソフトウェアは、Enterprise Manager 12.1.0.4がインストールされているすべてのシステムに自動でインストールされます。この章では、このようなシステムでBI Publisherサーバーを構成する手順について説明します。

20.1 BI Publisher複数サーバー環境の概要

Enterprise Manager 12cリリース4 (12.1.0.4)以降、複数のBI PublisherサーバーのEnterprise Managerとの統合がサポートされるようになりました。

追加のBI Publisherサーバーを追加する前に、最初のBI Publisherを構成する必要があります。詳細は、Enterprise Managerアドバンスト・インストレーションおよび構成ガイドの、BI PublisherとEnterprise Managerとの統合に関する説明を参照してください。最初のBI PublisherサーバーはBIPと呼ばれ、プライマリBI Publisherサーバーとして参照されます。

注意:
BI Publisher複数サーバー環境は、Microsoft WindowsプラットフォームのEnterprise Manager 12cリリース4 (12.1.0.4)ではサポートされません。

BI Publisherは、すべての構成データおよびレポート定義を、オペレーティング・システムのファイルシステム・ベースのリポジトリに格納します。そのため、複数のBI Publisherサーバーをサポートするには、BI Publisherを実行するすべてのOMSシステムから、このファイルシステムへの読取り/書込み権限を有効にする必要があります。これは、標準のネットワーク・ファイルシステム・テクノロジを使用して実現します。

複数のBI Publisherサーバーを実装する場合は、BI Publisherの共有ストレージ・ファイルシステムでも高可用性を実現する必要があります。このファイルシステムは、標準のオペレーティング・システム・コマンドまたは業務用のバックアップ・ソリューションを使用して、定期的に(毎日または毎時などの頻度で)バックアップする必要があります。また、RAID (Redundant Array of Inexpensive Drives)ストレージ・デバイスなどの高可用性ディスク・ソリューションを使用することを強くお薦めします。少なくともRAID 1 (冗長性)を使用してください。その他のRAIDレベル(RAID5、RAID0+1など)も使用できます。RAID0は、冗長性ではなく速度を目的としているため、使用できません。RAID1自体はバックアップ・ソリューションではありません。RAID1は、ディスク・ドライブ障害からの保護を実現しますが、それでも定期的なバックアップは必要です。このネットワーク・ストレージ・デバイス上に保存されているファイルを損失すると、すべてのBI Publisherサーバー(プライマリとセカンダリの両方)が機能しなくなります。

RAIDストレージ・デバイスを構成したら、BI Publisherをインストールするすべてのシステムにマウントする必要があります。マウントには標準のオペレーティング・システム・コマンドを使用できます(NFSなど)。ストレージ・デバイス上の2つのディレクトリをBI Publisherファイル専用にする必要があります。これらはクラスタ・ボリュームおよび構成ボリュームと呼ばれます。

注意:
BI Publisher共有記憶域を構成するための領域要件は、レポート・カタログとそれに関連する管理情報の格納に必要な領域の容量に応じて異なります。
インストール時、BI Publisherリポジトリは約400MBの記憶域を使用します。最初は、BI Publisher共有記憶域として10Gを利用できるようにします。その後、追加のEnterprise Managerプラグインをインストールし、より多くのレポートを作成するにつれて、必要な領域は増大します。そのため、この記憶域は、将来容易に拡張できるようにしてください。

追加のBI PublisherサーバーをEnterprise Managerに追加する前に、BI Publisherを再構成して、この共有ストレージ・デバイスを使用できるようにする必要があります。これには、プライマリOMSシステムで次のコマンドを実行します。

emctl config oms -bip_shared_storage -config_volume <vol1> -cluster_volume <vol2>

プライマリBI Publisherサーバーを構成し、共有記憶域を構成したら、追加のOMSシステムでセカンダリBI Publisherサーバーを有効にしますが、これにはいくつかの方法があります。

- 標準の「Oracle Management Serviceの追加」プロビジョニング・ジョブを使用します。プライマリBI Publisherサーバーの構成後にこのプロビジョニング・ジョブを実行すると、セカンダリBI Publisherサーバーを使用して追加のOMSシステムが自動的に構成されます。

注意:
プライマリBI Publisherサーバーを構成する場合、「Oracle Management Serviceの追加」プロビジョニング・ジョブは、BI Publisherが再構成されて共有ストレージ・デバイスを使用できるようになるまで利用できません。

- 「Oracle Management Serviceの追加」プロビジョニング・ジョブがすでに実行されている場合、または追加のOMSシステムが構成済の場合は、次のコマンドを使用してセカンダリBI Publisherを既存の追加OMSシステムに追加できます。
configureBIP -addBIP

このコマンドは、追加のOMSが存在するシステム上で実行する必要があります。

BI Publisherの共有記憶域の場所の特定

BI Publisherの共有記憶域の場所は、Enterprise Manager OMSプロパティとして格納されています。次のemctlコマンドを使用して、共有記憶域の場所を問い合せることができます。

emctl get property -name
oracle.sysman.core.eml.ip.bip.SharedStorageConfigVolume

emctl get property -name
oracle.sysman.core.eml.ip.bip.SharedStorageClusterVolume

例:

-bash-3.2$ emctl get property -name
oracle.sysman.core.eml.ip.bip.SharedStorageConfigVolume

Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
SYSMAN password:
Value for property oracle.sysman.core.eml.ip.bip.SharedStorageConfigVolume at
Global level is /oracle/BIP/config

20.2 共有ストレージ・デバイスを使用するためのBI Publisherの再構成

重要:
UNIXのNetwork File System (NFS)をBI Publisher共有記憶域に使用する場合、NFSオートマウンタによって管理されるNFSボリュームを使用しないでください(NFSオートマウンタは通常、/netディレクトリ(固定でないマウント・ポイント)をマウントするため)。かわりに、固定のマウント・ポイントを使用するNFSマウントを使用します。たとえば、/oracle/em/BIPなどです。

前述の概要説明のとおり、複数のBI Publisherサーバーをサポートするには、次のコマンドを実行する必要があります。

emctl config oms -bip_shared_storage -config_volume <vol3> -cluster_volume <vol4>

これらのボリューム(前の項で示したvol1およびvol2など)の記憶域の場所は、いつでも使用できるように保持してください。これらのファイルを削除しないでください。

このコマンドは、WebLogic管理サーバーのパスワードと、リポジトリ・ユーザー(SYSMAN)のパスワードを求めるプロンプトを表示します。

コマンドは次の手順を実行します。

1. 指定された資格証明を検証します。

2. いくつかの前提条件テストを実行します。これには次のものがあります。

- 2つのボリュームが、以前に構成した共有ストレージ・ボリュームと同一であってはなりません(存在する場合)。

- 2つのボリュームが個別のものである必要があります。

- 2つのボリュームに対応するファイルシステムのマウント・ポイントが存在する必要があります。

- 2つのボリュームは完全に空である必要があります。

- 2つのボリュームが書込み可能である必要があります。

3. ローカル・システム上のBI Publisherサーバー(BIPという名前のBI Publisherサーバー)が停止されます。

4. 既存のBI Publisherファイルシステムベースのリポジトリ(BI Publisherの構成時にインストールされたもの)が、構成ボリューム(-config_volume)にコピーされます。

5. BIPという名前のプライマリBI Publisherサーバーが再構成されて、クラスタ・ボリューム(-cluster_volume)に格納されたWebLogic JMSキューおよびWebLogic永続ストア(BI Publisherのスケジューラによって使用される)を使用するようになります。

6. BI Publisherのスケジューラが再構成されて、複数のBI Publisherサーバーをサポートし、前述の新しい場所を使用できるようになります。

7. 2つのボリュームの値は、Enteprise Managerリポジトリ・データベースにOMSプロパティとして格納されます。

8. プライマリBI Publisherが構成されて、新しい構成ボリュームを指すようになります。

9. BI Publisherが起動されます。

10. 全体的なステータスが表示されます。

次の例は、emctl config oms -bip_shared_storageコマンドを実行すると生成される出力を示しています。

$ emctl config oms -bip_shared_storage -config_volume /BIP_STORAGE/config -cluster_volume /BIP_STORAGE/cluster
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
Enter Admin User's Password :
Enter Enterprise Manager Root (SYSMAN) Password :
Stopping BI Publisher Server...
BI Publisher Server Successfully Stopped
BI Publisher Server is Down
Copying The BI Publisher repository from the location '...........gc_inst/user_projects/domains/GCDomain/config/bipublisher/repository' to the location '/BIP_STORAGE/config/bipublisher/repository'. This can take some time.  Do not interrupt this command while it is running.
Copied BI Publisher repository to the location '/BIP_STORAGE/config/bipublisher/repository'
Configuring BI Publisher server named 'BIP' for use in a High Availability environment. This operation can take some time. Do not interrupt this command while it is running.
Updating BI Publisher Scheduler configuration ...
Updating BI Publisher shared storage properties ...
The BI Publisher properties have been updated.
The BI Publisher storage for configuration data is in the location '/BIP_STORAGE/config'
The BI Publisher storage for cluster data is '/BIP_STORAGE/cluster'
BI Publisher has been configured to point to the BI Publisher repository in the location '/BIP_STORAGE/config'
Starting BI Publisher Server ...
BI Publisher Server Successfully Started
BI Publisher Server is Up
BI Publisher storage has been configured for the BI Publisher server named 'BIP' running at the URL: https://em.example.com:9702/xmlpserver
Overall result of operations: SUCCESS

20.3 セカンダリBI Publisherサーバーの追加

前述したように、追加のBI Publisherサーバーを構成する方法は2つあります。使用する方法は、プライマリBI Publisherサーバーを構成するタイミングによって異なり、これは「OMSの追加」プロビジョニング・ジョブ(または他の方法)で追加のOMSサーバーを作成するタイミングに関連します。次のパスに、これらの方法を示します。

パスA

Enterprise Managerのインストール

1. configureBIPまたはconfigureBIP -upgradeを使用して、プライマリBI Publisherサーバーを構成します。

2. emctl config oms -bip_shared_storageを使用して、BI Publisherの共有記憶域を構成します。

3. 「OMSの追加」プロビジョニング・ジョブを使用してOMSを追加します。
セカンダリBI Publisherサーバーが追加のOMSシステムとともに自動的に構成されます。

パスB

Enterprise Managerのインストール

1. 「OMSの追加」プロビジョニング・ジョブ(または、ソフトウェアのみインストールするなどの他の手段)を使用してOMSを追加します。

2. configureBIPまたはconfigureBIP -upgradeを使用して、プライマリBI Publisherサーバーを構成します。

3. emctl config oms -bip_shared_storageを使用して、BI Publisherの共有記憶域を構成します。

4. 複数のBI Publisherサーバーを実行する追加のOMSシステム上で、configureBIP -addBIPを使用して追加のBI Publisherサーバーを構成します。

注意:
configureBIP -addBIPコマンドを実行するには、現在のシステムのOMSが実行されている必要があります。次の例に示すように、emctl status omsコマンドを実行してこれを確認できます。

$ emctl status oms
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
WebTier is Up
Oracle Management Server is Up

この2つのパスが示すとおり、プライマリBI Publisherサーバーをいつ構成するかを決定すると、セカンダリBI Publisherサーバーを追加するために必要な前提条件を確認できます。

20.3.1 パスA - 「OMSの追加」プロビジョニング・ジョブを使用したセカンダリBI Publisherサーバーの自動での構成

Enterprise ManagerのHAインストールを構築してBI Publisherのレポート作成機能を活用することを計画している場合は、パスAの方が簡単な方法です。追加したすべての追加OMSシステムに、セカンダリBI Publisherが自動的に構成されます。

20.3.1.1 プライマリBI Publisherサーバーの構成

アドバンスト・インストレーションおよび構成ガイドのBI PublisherとEnterprise Managerとの統合に関する説明を参照してください。

20.3.1.2 共有記憶域を使用するためのBI Publisherの再構成

プライマリBI Publisherサーバーをインストールし、正常に動作することを検証したら(詳細はこの章で説明)、共有記憶域を使用するためのBI Publisherの再構成に進むことができます。「共有ストレージ・デバイスを使用するためのBI Publisherの再構成」を参照してください。

20.3.1.3 追加OMSシステムの追加とセカンダリBI Publisherサーバーの自動での構成

BI Publisherの共有記憶域を構成すると、「OMSの追加」プロビジョニング・ジョブが、構成されたBI Publisherを認識するようになります。ここで必要な操作は、追加のOMSシステムで、プライマリBI Publisherサーバー用のHTTPおよびHTTPSポートを入力することのみです。「OMSの追加」プロビジョニング・ジョブが、前提条件の手順を実行して、BI Publisherの共有記憶域が構成されていることを確認します。セカンダリBI Publisherサーバーの自動構成でエラーが発生した場合は、パスBにフォールバックできます。

20.3.2 パスB: 追加OMSシステムの追加後のセカンダリBI Publisherサーバーの構成

Enterprise Managerトポロジにすでに追加OMSシステムが含まれていて、プライマリBI Publisherサーバーがまだ構成されていない場合には、プライマリBI Publisherサーバーを使用可能にするための追加の手順と、追加のOMSシステムでセカンダリBI Publisherサーバーを構成するための1つ以上の手順があります。

20.3.2.1 プライマリBI Publisherサーバーの構成

詳細は、Enterprise Managerアドバンスト・インストレーションおよび構成ガイドのBI PublisherとEnterprise Managerとの統合に関する説明を参照してください。

20.3.2.2 共有記憶域を使用するためのBI Publisherの再構成

プライマリBI Publisherサーバーをインストールしたら(また、前述したように正常に動作することを検証したら)、共有記憶域を使用するためのBI Publisherの再構成に進むことができます。

20.3.2.3 セカンダリBI Publisherサーバーの構成

セカンダリBI Publisherサーバーを実行する各追加OMSシステムで、configureBIP -addBIPコマンドを実行する必要があります。

注意:
このコマンドは、プライマリOMSシステムが存在するシステムではなく、追加のOMSシステムをホストするシステム上で実行します。

次の例に、追加のOMSシステムでセカンダリBI Publisherサーバーを構成するときのコマンド出力を示します。

$ configureBIP -addBIP
Configuring BI Publisher Version "11.1.1.7.0" to work with Enterprise Manager
Logging started at /oracle/Middleware/oms/cfgtoollogs/bip/bipca_20140221125351.log.
A new BI Publisher server is going to be added.
Do You really want to add a BI Publisher server (Y|N):y
Enter sysdba user name (sys):
Enter sysdba user password:
Enter Administration Server user password:
Configuring BI Publisher in Oracle Home located in /oracle/Middleware/Oracle_BI1 ...
Enter an integer between 9701 and 49152 for the BI Publisher HTTP server port. (9701):
Enter an integer between 9702 and 49152 for the BI Publisher HTTPS server port. (9702):
Configuring BI publisher on additional OMS system.  This operation can take some time. Do not interrupt this command while it is running...
Locking Enterprise Manager ...
OMS Console is locked. Access the console over HTTPS ports.
Restart OMS.
Restarting Enterprise Manager ...
Stopping Enterprise Manager, this can take some time  ...
Starting Enterprise Manager. This operation can take some time. Do not interrupt this command while it is running.
OMS Started Successfully
Successfully configured additional BI Publisher server.

20.4 追加OMSシステムでセカンダリBI Publisherサーバーが正しく動作することの確認

セカンダリBI Publisherサーバーの構成でパスAまたはBのどちらを選択したかに関係なく、emctl status omsコマンドを使用して、構成が正常であることを確認できます。

$ emctl status oms
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
WebTier is Up
Oracle Management Server is Up
BI Publisher Server is Up

20.5 セカンダリBI Publisherサーバーの詳細の確認

セカンダリBI Publisherサーバーの情報を取得するには、次のコマンドを実行します。

emctl status oms -details

セカンダリBI Publisherサーバーのサーバー名はBIPxで、xはOMSのサーバー番号と一致します(たとえば、EMGC_OMS2 : BIP2、EMGC_OMS3 : BIP3)。

$ emctl status oms -details
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host        : em.example.com
HTTP Console Port          : 7788
HTTPS Console Port         : 7799
HTTP Upload Port           : 4889
HTTPS Upload Port          : 4900
EM Instance Home           : /oracle/gc_inst/em/EMGC_OMS2
OMS Log Directory Location : /oracle/gc_inst/em/EMGC_OMS2/sysman/log
OMS is not configured with SLB or virtual hostname
Agent Upload is locked.
OMS Console is locked.
Active CA ID: 1
Console URL: https://em.example.com:7799/em
Upload URL: https://em.example.com:4900/empbs/upload

WLS Domain Information
Domain Name            : GCDomain
Admin Server Host      : emas.example.com
Admin Server HTTPS Port: 7101

Oracle Management Server Information
Managed Server Instance Name: EMGC_OMS2
Oracle Management Server Instance Host: em.example.com
WebTier is Up
Oracle Management Server is Up

BI Publisher Server is Up
BI Publisher Server named 'BIP2' running at local URL: https://em.example.com:7799/xmlpserver
BI Publisher Server Logs: /oracle/gc_inst/user_projects/domains/GCDomain/servers/BIP2/logs/
BI Publisher Log        : /oracle/gc_inst/user_projects/domains/GCDomain/servers/BIP2/logs/bipublisher/bipublisher.log

第VII部

削除

この部は、次の章で構成されています。

- 第21章「Enterprise Managerの削除(単一および複数OMS環境)」

- 第22章「Oracle Management Agentの削除」

- 第23章「ADPとJVMDの削除」

- 第24章「スタンバイOracle Management Serviceの削除」

21 Enterprise Managerの削除(単一および複数OMS環境)

この章では、Enterprise Managerシステム全体を削除する方法、およびOracle Management Service (OMS)を実行していたホストが失われた場合に、Oracle Management Repository(管理リポジトリ)からOMSのエントリを削除する方法について説明します。

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

- Enterprise Managerの削除

- OMSからのプラグインのみの削除またはアンデプロイ

- 管理リポジトリからのOMSエントリの削除

21.1 Enterprise Managerの削除

この項では、Enterprise Managerシステム全体(単一OMS環境または複数OMS環境と追加のOracle Management Service (OMS))を削除する方法について説明します。

- OMSのみを削除し管理リポジトリを保持するための前提条件

- Enterprise Managerシステム全体を削除するための前提条件

- Enterprise Managerを削除するための手順

- Enterprise Managerの削除後

注意:
ソフトウェアを削除する前に前提条件を満たしていることを確認してください。必ずこの章で説明するフローまたは手順に従ってください。たとえば、必ず前提条件の項に記載されたとおりにスキーマを削除してから、ソフトウェア・バイナリを削除してください。手順の順序は変えないでください。

21.1.1 OMSのみを削除し管理リポジトリを保持するための前提条件

Enterprise Managerを削除する前に、次の前提条件を満たしてください。

1. (複数OMS環境で、追加のOMSインスタンスにOracle BI Publisherが構成されている場合)各ホストのOMSホームから次のコマンドを実行して、追加OMSホストで実行中のすべてのOracle BI Publisher管理対象サーバーを停止します。
$<OMS_HOME>/bin/emctl stop oms -bip_only

注意:
Oracle BI Publisher管理対象サーバーの停止が失敗した場合は、オペレーティング・システムのコマンドを使用して手動で強制終了します。

2. (複数OMS環境で、追加のOMSインスタンスにOracle BI Publisherが構成されている場合)次のコマンドを実行して、前の手順で停止したすべてのOracle BI Publisher管理対象サーバーを削除します。
$<OMS_HOME>/bin/configureBIP -delete

3. (複数OMS環境の場合)それぞれのホームから次のコマンドを実行して、追加のOMSインスタンスをすべて構成解除し、削除します。
$<OMS_HOME>/bin/omsca delete -OMSNAME <oms_name>

注意:

- 各追加OMSインスタンスでこのコマンドを実行します。

- プロンプトが表示されたら、操作を確認し、AdminServer資格証明およびリポジトリ・データベースの詳細(データベース・ホスト名、リスナー・ポート、SIDおよびパスワードなど)を指定します。必要な詳細を指定すると、コマンドによりOMS、Oracle WebLogic ServerおよびOracle WebTierが自動的に停止されます。

たとえば、EMGC_Addln_OMS2およびEMGC_Addln_OMS3という2つの追加OMSインスタンスが2つの異なるホストに存在する場合、最初の追加OMSで次のコマンドを実行します。

/u01/app/Oracle/Middleware/oms/bin/omsca delete -OMSNAME EMGC_Addln_OMS2

次に、2番目の追加OMSで次のコマンドを実行します。

/u01/app/Oracle/Middleware/oms/bin/omsca delete -OMSNAME EMGC_Addln_OMS3

4. (複数OMS環境の場合)削除されたOMSの次のWebLogicターゲットを手動で削除します。

- /EMGC_GCDomain/GCDomain/EMGC_OMS2 (Oracle WebLogic Server)

- /EMGC_GCDomain/instance2/ohs2 (Oracle HTTP Server)

5. (複数OMS環境の場合)それぞれのホームから次のコマンドを実行して、追加OMSホストで実行中のすべてのOracle Management Agent (管理エージェント)を停止します。
$<AGENT_HOME>/bin/emctl stop agent

注意:
追加OMSインスタンスで構成されている各管理エージェントでこのコマンドを実行します。

たとえば、2つの追加OMSインスタンスとそのそれぞれに管理エージェントが存在する場合、最初の管理エージェントが実行されている最初の追加OMSホストで次のコマンドを実行します。

/u01/app/Oracle/agent/core/12.1.0.4.0/bin/emctl stop agent

次に、2番目の管理エージェントが実行されている2番目の追加OMSホストで次のコマンドを実行します。

/u01/app/Oracle/agent/core/12.1.0.4.0/bin/emctl stop agent

6. (最初の[メイン] OMS環境にOracle BI Publisherが構成されている場合) OMSホームから次のコマンドを実行して、最初の(メイン)OMSで実行中のOracle BI Publisher管理対象サーバーを停止します。
$<OMS_HOME>/bin/emctl stop oms -bip_only

注意:
Oracle BI Publisher管理対象サーバーの停止が失敗した場合は、オペレーティング・システムのコマンドを使用して手動で強制終了します。

7. 管理サーバーが構成されている最初の(メイン) OMSを構成解除して削除します。
$<OMS_HOME>/bin/omsca delete -full

次に例を示します。

/u01/app/Oracle/Middleware/oms/bin/omsca delete -full

プロンプトが表示されたら、操作を確認し、AdminServer資格証明およびリポジトリ・データベースの詳細(データベース・ホスト名、リスナー・ポート、SIDおよびパスワードなど)を指定します。必要な詳細を指定すると、コマンドによりOMS、Oracle WebLogic ServerおよびOracle WebTierが自動的に停止されます。

注意:
管理リポジトリが構成されているOracle Databaseでサービス名が設定されている場合、次のコマンドを実行します。
./omsca delete -full -REP_CONN_STR '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))'

次に例を示します。

/u01/app/Oracle/Middleware/oms/bin/omsca delete -full -REP_CONN_STR '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=srvc.example.com)))'

注意:
最初の(メイン) OMSでomsca delete -fullを実行したとき、このコマンドはプライマリOracle BI Publisherの管理対象サーバーも削除します(最初のOMSで構成されている場合)。

8. そのホームから次のコマンドを実行して最初の(メイン) OMSで実行されている管理エージェントを停止します。
$<AGENT_HOME>/bin/emctl stop agent

次に例を示します。

/u01/app/Oracle/agent/core/12.1.0.4.0/bin/emctl stop agent

9. 次の手順で削除するスキーマにOracle WebLogic Serverがアクセスしないように、Oracle WebLogic Serverを停止します。手順は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareコンポーネントの開始と停止に関する章を参照してください。

21.1.2 Enterprise Managerシステム全体を削除するための前提条件

Enterprise Managerを削除する前に、次の前提条件を満たしてください。

1. 第21.1.1項に示す次の手順を実行します。

2. Oracle Management Repository (管理リポジトリ)を削除します。

警告:

一度削除した管理リポジトリを取り戻すことはできません。このため、管理リポジトリを削除するのは、Enterprise Managerシステム全体(すべてのOMSインスタンス、管理エージェントおよび管理リポジトリ)を削除する場合のみにしてください。OMS (または任意の追加OMS)のみを削除する場合は、管理リポジトリを削除しないでください。

警告:

削除モードのRepManagerは、"ALTER SYSTEM QUIESCE RESTRICTED;"コマンドによりデータベースを静止モードにします。

1. ログインしているSYSMANユーザーがいないことを確認します。

2. OMSホームから次のコマンドを実行して、管理リポジトリからEnterprise Manager Cloud Controlスキーマ(SYSMANスキーマ)およびメタデータ・スキーマ(MDSスキーマ)を削除します。
$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <database_host> <repository_database_port> <repository_database_sid> -action drop -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -reposName <repository_name> -mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <OMS_HOME>

次に例を示します。

/u01/app/Oracle/Middleware/oms/sysman/admin/emdrep/bin/RepManager example.com 1234 sid_em -action drop -dbUser sys -dbPassword letmein -dbRole sysdba -reposName SYSMAN -mwHome /u01/app/Oracle/Middleware/ -mwOraHome /u01/app/Oracle/Middleware/ -oracleHome /u01/app/Oracle/Middleware/oms/

注意:

- Microsoft Windowsの場合は、RepManager.batを起動してください。

- Microsoft Windowsで、<OMS_HOME>\sysman\admin\emdrep\binディレクトリの外からRepManager.batを実行する場合は、ORACLE_HOME環境変数にOMSホームを設定します。
次に例を示します。

set ORACLE_HOME=c:\oracle\middleware\oms

- OMSホームまたは$<OMS_HOME>は、管理サーバーが構成されている最初の(メイン) OMSを示します。

- -mwHomeおよび-mwOraHomeは、最初の(メイン) OMSが構成されているミドルウェア・ホームを示します。最初の(メイン) OMSは、管理サーバーが構成されているOMSです。

- -oracleHomeは、管理サーバーが構成されている最初の(メイン) OMSのOracleホームを示します。

- 10gリリース2(10.2.x.x)管理リポジトリに属するスキーマを削除する場合、次の引数を指定せずにコマンドを実行します。-mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <oracle_home>
次に例を示します。

/u01/app/Oracle/Middleware/oms/sysman/admin/emdrep/bin/RepManager example.com 1234 sid_em -action drop -dbUser sys -dbPassword letmein -dbRole sysdba -reposName SYSMAN

- -action dropおよび-action dropallのサポートの詳細は、表2-3を参照してください。

- -action dropコマンドでは、すべてのスキーマが削除され確認メッセージが表示されます。アクションが成功しなかった場合、クリーンアップまたは削除できなかったすべてのエンティティが一覧されます。たとえば、Xスキーマがクリーンアップされないと、シノニムはクリーンアップされず、表領域もクリーンアップされません。この場合には、コマンドを再度実行します。
RepManagerがない、または残りのエンティティを手動でクリーンアップする場合には、My Oracle Supportノート1365820.1を参照してください。

- Enterprise Managerスキーマを完全に削除する場合は、OMSホームにあるRepManagerを使用します。データベース・ホーム内のものは、Enterprise Managerスキーマを完全には削除できないため、使用しないでください。

3. データベース・ホームから、データ・ファイルmgmt.dbfおよびmgmt_ecm_depot1.dbfを手動で削除します。

注意:
Microsoft Windowsで、.dbfファイルの削除中に次のエラーが表示された場合は、データベース・サービスを停止し、ファイルの削除を再試行します。
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

21.1.3 Enterprise Managerを削除するための手順

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

- グラフィック・モードでのEnterprise Managerの削除

- サイレント・モードでのEnterprise Managerの削除

21.1.3.1 グラフィック・モードでのEnterprise Managerの削除

グラフィック・モードでEnterprise Manager (単一OMS環境または複数OMS環境と追加OMSインスタンス)を削除するには、次の手順を実行します。

注意:

- この手順に示されている順序でコンポーネントを削除してください。そうでない場合、インストール・ウィザードにエラーが表示されます。

- 複数OMS環境の場合、各追加OMSインスタンスでこの項に説明されている手順を実行します。

1. 次のコマンドを実行して、OMSホームからインストーラを起動します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall ORACLE_HOME=<absolute_path_to_oms_home> -jreLoc <path> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

/u01/app/Oracle/Middleware/oms/oui/bin/runInstaller -deinstall ORACLE_HOME=/u01/app/Oracle/Middleware/oms/ -jreLoc /u01/app/Oracle/Middleware/jdk16/jdk -removeallfiles -invPtrLoc /u01/oraInst.loc

注意:

- ソフトウェアをダウンロードしたディレクトリからインストーラを起動することもできます。たとえば、<software_location>/となります。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- runInstaller -helpを実行すると、オプション-nowarningonremovefilesがリストに表示されます。このオプションは現在サポートされていないため、使用しても無効になります。

2. 「インベントリ」画面でプラグイン・ホームを選択し、「削除」をクリックします。

- 管理リポジトリの有無にかかわらず、Enterprise Managerシステム全体を削除する場合は、OMSおよび管理エージェントのプラグイン・ホームを含む、すべてのプラグイン・ホームを削除します。

- 追加のOMSを削除する場合は、OMSプラグイン・ホームのみを削除します。

3. 「インベントリ」画面でsbinホームを選択し、「削除」をクリックします。

4. 「インベントリ」画面で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>]

5. 「インベントリ」画面でOracle WebTierホームを選択し、「削除」をクリックします。

6. 「インベントリ」画面でOracle BI Publisherホームを選択し、「削除」をクリックします。

注意:
Oracle BI Publisherを構成していない場合でも、この手順を実行する必要があります。

7. 「インベントリ」画面でOMSホーム、管理エージェント・ホームおよびOracle共通ディレクトリを選択し、「削除」をクリックします。

- 管理リポジトリの有無にかかわらず、Enterprise Managerシステム全体を削除する場合は、OMSホーム、管理エージェント・ホームおよびOracle共通ディレクトリを選択して削除します。

- 追加OMSを削除するには、次のいずれかを実行します。

- 後でそのホストに別の追加のOMSをインストールすることを計画している場合は、OMSホームおよびOracle共通ディレクトリのみを選択して削除します。
この場合、管理エージェント・ホームは選択および削除しないでください。この管理エージェント・ホームは、追加のOMSインストールの前提条件としてインストールされたスタンドアロンの管理エージェントに属しています。この管理エージェントは、新しい追加のOMSをインストールするときに必要となります。今、この管理エージェントを削除する場合は、後で、新しい追加のOMSのインストールを計画するときに再インストールする必要があります。

- そのホストに別のOMSをインストールする計画がない場合は、OMSホーム、管理エージェント・ホームおよびOracle共通ディレクトリを選択して削除します。

8. 「インベントリ」画面で「閉じる」をクリックして、ウィザードを終了します。

9. ミドルウェア・ホームを手動で削除します。
UNIXプラットフォームの場合:

rm -rf <absolute_path_to_middleware_home>

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

del <absolute_path_to_middleware_home>

注意:
パスが長すぎてミドルウェア・ホームを削除できなかったことを示すエラー・メッセージが表示されたら、次のいずれかの方法でミドルウェア・ホーム名を短くします。

- ミドルウェア・ホーム名を短い名前に変更する。
たとえば、C:\Oracle\MiddlewareをC:\OR\MWのように変更します。

- ドライブをミドルウェア・ホームのパスにマウントする。
たとえば、C:\Oracle\Middleware\oms\binが問題の発生しているディレクトリだとすると、パス長が妥当な長さまで短縮されるようにパスを短くします(ファイル・パスの制限はオペレーティング・システムごとに異なります)。

C:\Oracle\Middleware\omsをドライブZにマウントします。

- ドライブZに移動し、ファイルを削除します。
prompt>Z:

prompt>del bin

- ミドルウェア・ホームに移動し、残存ファイルを削除します。
prompt:>C:

prompt>del C:\Oracle\Middleware\

21.1.3.2 サイレント・モードでのEnterprise Managerの削除

サイレント・モードでEnterprise Manager (単一OMS環境または複数OMS環境と追加OMSインスタンス)を削除するには、次の手順を実行します。

注意:

- この手順に示されている順序でコンポーネントを削除してください。そうでない場合、インストール・ウィザードにエラーが表示されます。

- 複数OMS環境の場合、各追加OMSインスタンスでこの項に説明されている手順を実行します。

1. 『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の指示に従って、Oracle WebLogic Server 11gリリース1 (10.3.6)を削除します。ソフトウェアの削除方法が説明されている章を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』は、次からアクセスできるOracle WebLogic Serverドキュメント・ライブラリで入手できます。

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

注意:
Enterprise Managerシステムのインストール時にインストール・ウィザードによってOracle WebLogic Server 11gリリース1 (10.3.6)がインストールされた場合のみ、これを削除します。

2. プラグイン・ホームを削除します。

- 管理リポジトリの有無にかかわらず、Enterprise Managerシステム全体を削除する場合は、OMSおよび管理エージェントのプラグイン・ホームを含む、すべてのプラグイン・ホームを削除します。

- 追加のOMSを削除する場合は、OMSプラグイン・ホームのみを削除します。

プラグイン・ホームを削除するには、次のコマンドを実行します。

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_plug-in_home}" ORACLE_HOME=<absolute_path_to_oms_home> -jreLoc <JDK_HOME> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

/u01/app/Oracle/Middleware/oms/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/plugins/oracle.sysman.db.oms.plugin_12.1.0.2.0,/u01/app/Oracle/agent/plugins/oracle.sysman.db.discovery.plugin_12.1.0.2.0}" ORACLE_HOME=/u01/app/Oracle/Middleware/oms -jreLoc /u01/app/Oracle/Middleware/jdk16/jdk -removeAllFiles -invPtrLoc /u01/oraInst.loc

注意:

- ソフトウェアをダウンロードしたディレクトリからインストーラを起動することもできます。その場合、-removeallfilesは渡さないでください。
たとえば、ソフトウェアを/u01/app/Oracle/Downloadsにダウンロードした場合、-removeallfiles引数を省略して次のコマンドを実行します。

/u01/app/Oracle/Downloads/Disk1/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/plugins/oracle.sysman.db.oms.plugin_12.1.0.2.0,/u01/app/Oracle/agent/plugins/oracle.sysman.db.discovery.plugin_12.1.0.2.0}" ORACLE_HOME=/u01/app/Oracle/Middleware/oms -jreLoc /u01/app/Oracle/Middleware/jdk16 -invPtrLoc /u01/oraInst.loc

- runInstaller -helpを実行すると、オプション-nowarningonremovefilesがリストに表示されます。このオプションは現在サポートされていないため、使用しても無効になります。

- 複数のプラグインを削除する場合は、プラグイン・ホームをカンマで区切って入力してください。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

3. sbinホームを削除します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_sbin_home}" ORACLE_HOME=<absolute_path_to_oms_home> -jreLoc <JDK_HOME> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

/u01/app/Oracle/Middleware/oms/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/agent/sbin}" ORACLE_HOME=/u01/app/Oracle/Middleware/oms -jreLoc /u01/app/Oracle/Middleware/jdk16 -removeAllFiles -invPtrLoc /u01/oraInst.loc

4. 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> -jreLoc <JDK_HOME> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

/u01/app/Oracle/Middleware/oms/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/jdk16}" ORACLE_HOME=/u01/app/Oracle/Middleware/oms -jreLoc /u01/app/Oracle/Middleware/jdk16 -removeAllFiles -invPtrLoc /u01/oraInst.loc

注意:
Enterprise Managerシステムのインストール時にインストール・ウィザードによってJDKがインストールされた場合のみ、JDKを削除します。そのようなリポジトリがない場合は、この手順をスキップできます。

5. JDK 1.6.0.43.0を手動でダウンロードし、OMSホストにインストールします。このサポートされているバージョンをすでに所有している場合、それを再利用できます。
インストーラはJDKに依存しているため、JDKを再インストールする必要があります。新しいJDKは、OMSホスト上であれば任意の場所にインストールできるので、前と同じ場所にインストールする必要はありません。ただし、インストーラの起動時に-jreLocパラメータを渡して(以降の手順で説明)、JDKがインストールされている場所を必ず示してください。

6. Oracle WebTierホームを削除します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_web_tier}" ORACLE_HOME=<absolute_path_to_oms_home> -jreLoc <JDK_HOME> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

/u01/app/Oracle/Middleware/oms/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/Oracle_WT}" ORACLE_HOME=/u01/app/Oracle/Middleware/oms -jreLoc /u01/app/Oracle/Middleware/jdk16 -removeAllFiles -invPtrLoc /u01/oraInst.loc

7. Oracle BI Publisherホームを削除します。
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_bip}" ORACLE_HOME=<absolute_path_to_oms_home> -jreLoc <JDK_HOME> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:
Oracle BI Publisherを構成していない場合でも、この手順を実行する必要があります。

次に例を示します。

/u01/app/Oracle/Middleware/oms/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/Oracle_BI1}" ORACLE_HOME=/u01/app/Oracle/Middleware/oms -jreLoc /u01/app/Oracle/Middleware/jdk16 -removeAllFiles -invPtrLoc /u01/oraInst.loc

8. OMSホーム、管理エージェント・ホームおよびOracle共通ディレクトリを削除します。

- 管理リポジトリの有無にかかわらず、Enterprise Managerシステム全体を削除する場合は、OMSホーム、管理エージェント・ホームおよびOracle共通ディレクトリを削除します。

- 追加OMSを削除するには、次のいずれかを実行します。

- 後でそのホストに別の追加のOMSをインストールすることを計画している場合は、OMSホームおよびOracle共通ディレクトリのみを削除します。
この場合、管理エージェント・ホームは選択および削除しないでください。この管理エージェント・ホームは、追加のOMSインストールの前提条件としてインストールされたスタンドアロンの管理エージェントに属しています。この管理エージェントは、新しい追加のOMSをインストールするときに必要となります。今、この管理エージェントを削除する場合は、後で、新しい追加のOMSのインストールを計画するときに再インストールする必要があります。

- そのホストに別のOMSをインストールする計画がない場合は、OMSホーム、管理エージェント・ホームおよびOracle共通ディレクトリを削除します。

OMSホーム、管理エージェント・ホームおよびOracle共通ディレクトリを削除するには、次のコマンドを実行します。

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_oracle_homes_and_directories_to_be_deinstalled}" ORACLE_HOME=<absolute_path_to_oms_home> -jreLoc <JDK_HOME> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:
引数REMOVE_HOMESでは、カンマで区切られた複数のパスを指定できます。

次に例を示します。

/u01/app/Oracle/Middleware/oms/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/oms,/u01/app/Oracle/agent/core/12.1.0.4.0,/u01/app/Oracle/Middleware/oracle_common}" ORACLE_HOME=/u01/app/Oracle/Middleware/oms -jreLoc /u01/app/Oracle/Middleware/jdk16 -removeAllFiles -invPtrLoc /u01/oraInst.loc

9. ミドルウェア・ホームを手動で削除します。
UNIXプラットフォームの場合:

rm -rf <absolute_path_to_middleware_home>

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

del <absolute_path_to_middleware_home>

21.1.4 Enterprise Managerの削除後

削除後に、次の手順を実行します。

1. 削除したOracleホームが、中央インベントリから登録解除されます。ただし、一部のファイルがこれらのOracleホームに残ることもあります。また、OMSインスタンス・ベース・ディレクトリおよびWeb TierのOracleホームが表示されることもあります。これらのファイルおよびディレクトリは、手動で削除できます。

2. 削除処理により、/etc/oragchomelistファイルから自動開始スクリプトであるS98gcstartupスクリプトのエントリが削除されますが、スクリプト自体は削除されません。このスクリプトとこのスクリプトに関連付けられたソフト・リンクは、Enterprise Managerを同じホストに再度インストールする際に、インストーラがスクリプトを自動的に上書きし、ソフト・リンクを再作成するため、そのまま残しておくことができます。
ただし、Oracle製品のホストをクリアする場合には、このスクリプトとスクリプトに関連付けられたソフト・リンクを手動で削除することをお薦めします。これを行うには、/etc/rc.d/ディレクトリに移動し、S98gcstartupスクリプトを検索します。このスクリプトは通常、/etc/rc.d/ディレクトリ内のサブディレクトリにあります。スクリプトが存在するサブディレクトリに移動し、スクリプトを削除します。たとえば、/etc/rc.d/rc3.d/S98gcstartupまたは/etc/rc.d/init.d/gcstartup/S98gcstartupなどにあります。

3. Enterprise Managerシステムを完全に削除するために第21.1.3.2項の手順(5)の一部としてインストールされたJDKは、他の目的で必要ではなくなった場合、およびシステム登録のJDKと置き換えられなかった場合、ここで手動で(インストール・ディレクトリを削除することによって)削除できます。

21.2 OMSからのプラグインのみの削除またはアンデプロイ

OMSからEnterprise Managerシステム全体ではなく、プラグインのみを削除またはアンデプロイするには、Enterprise Manager Cloud Controlコンソールのプラグインページを使用します。手順については、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。プラグインのみのアンデプロイには、runInstallerを使用しないでください。

21.3 管理リポジトリからのOMSエントリの削除

追加のOMSが稼働しているホストを失った場合、必ず管理リポジトリからOMS用のエントリを手動で削除します。次の手順を実行します。

1. 次のコマンドを実行して、WebLogic DomainからOracle WebLogic Serverやアプリケーションなどを再構成し、管理リポジトリからすべてのOMS関連のエントリを削除し、OMSのターゲットoracle_oms、oracle_oms_pbs、oracle_oms_consoleを削除します。
$ORACLE_HOME/bin/omsca delete

2. OMSの次のWebLogicターゲットを手動で削除します。

- /EMGC_GCDomain/GCDomain/EMGC_OMS2 (weblogic_j2eeserver)

- /EMGC_GCDomain/instance2/ohs2 (oracle_apache)

これで、削除された追加OMSの参照がEnterprise Managerからなくなりました。OMSを削除するには、第21.1項で説明されている手順に従います。

22 Oracle Management Agentの削除

この章では、Oracle Management Agent (管理エージェント)を削除する方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle Management Agentの削除

- Oracle Management Agentからのプラグインのみの削除またはアンデプロイ

注意:
クラスタで、管理エージェントをすべてのノードから1つずつ確実に削除するようにしてください。そのためには、この章で説明されている手順に従ってください。

注意:
古い管理エージェントを削除して同じホストに新しい管理エージェントをインストールすると、管理リポジトリからターゲットのすべての履歴情報が失われます。
履歴情報がすべて消失することを回避するには、最初に新しい管理エージェントをインストールし、emcli relocate targetsコマンドを実行して旧管理エージェントから新管理エージェントにターゲットを渡してから、旧管理エージェントを削除します。

emcli relocate targetsコマンドの詳細は、Oracle Enterprise Manager Cloud Controlコマンドライン・インタフェースに関するガイドを参照してください。

22.1 Oracle Management Agentの削除

この項では、様々な削除方法を使用してOracle Management Agentを削除する方法について説明します。内容は次のとおりです。

- Oracle Management Agentを削除するための前提条件

- Oracle Management Agentを削除するための手順

- Oracle Management Agentの削除後

22.1.1 Oracle Management Agentを削除するための前提条件

管理エージェントを削除する前に、次の作業を実行します。

1. そのホームから次のコマンドを実行して管理エージェントを停止します。すでに停止している場合、この手順はスキップしてください。
$<AGENT_HOME>/bin/emctl stop agent

2. Cloud Controlコンソールで管理エージェントが「停止中」または「使用不可」状態になるまで待機します。すでに「停止中」または「使用不可」状態の場合、次の手順に進んでください。

3. EM CLIがインストールされている任意のホストから、管理エージェントのターゲットおよび監視対象ターゲットを削除します。
emcli delete_target

-name="example.com:1836"

-type="oracle_emd"

-delete_monitored_targets

注意:
EM CLIの詳細および設定の手順は、『Oracle Enterprise Managerコマンドライン・インタフェース』ガイドを参照してください。

22.1.2 Oracle Management Agentを削除するための手順

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

- AgentDeinstall.plスクリプトを使用したOracle Management Agentの削除(推奨)

- インストール・ウィザードをグラフィカル・モードで使用したOracle Management Agentの削除

- インストール・ウィザードをサイレント・モードで使用したOracle Management Agentの削除

- 共有エージェントの削除

- RPMファイルを使用してインストールしたOracle Management Agentの削除

22.1.2.1 AgentDeinstall.plスクリプトを使用したOracle Management Agentの削除(推奨)

管理エージェントを削除するための最も簡単な方法として、AgentDeinstall.plスクリプトを使用することをお薦めします。スクリプトでは、管理エージェントのホームだけでなく、プラグイン・ホームやsbinホームなどの依存するホームの削除も編成できます。この章で説明する他の方法とは異なり、手動で明示的に各コンポーネントを決まった順に選択して削除する必要がないため、時間と労力を節約できます。スクリプトによって、削除操作全体が自動化されます。

AgentDeinstall.plスクリプトを使用して管理エージェントを削除するには、次の手順を実行します。

警告:

デフォルトでは、AgentDeinstall.plスクリプトによって管理エージェントが削除され、インベントリの依存エントリと、エージェント・ベース・ディレクトリ全体が削除されます。なんらかの理由でエージェント・ベース・ディレクトリを保持する場合、スクリプトに-skipRemoval引数を渡します。この引数によって、エージェント・ベース・ディレクトリから管理エージェント・ホームのみが削除され、エージェント・ベース・ディレクトリと残りのサブディレクトリは保持されることが保証されます。

1. AgentDeinstall.plスクリプトを起動します。
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/AgentDeinstall.pl -agentHome <AGENT_HOME>

たとえば、管理エージェントとともにエージェント・ベース・ディレクトリを削除する場合、次のコマンドを実行します。

$/u01/app/Oracle/core/12.1.0.4.0/perl/bin/perl /u01/app/Oracle/core/12.1.0.4.0/sysman/install/AgentDeinstall.pl -agentHome /u01/app/Oracle/core/12.1.0.4.0/

たとえば、管理エージェントを削除するが、エージェント・ベース・ディレクトリは削除しない場合、次のコマンドを実行します。

$/u01/app/Oracle/core/12.1.0.4.0/perl/bin/perl /u01/app/Oracle/core/12.1.0.4.0/sysman/install/AgentDeinstall.pl -agentHome /u01/app/Oracle/core/12.1.0.4.0/ -skipRemoval

2. 削除した管理エージェントによって監視されていたターゲットをEnterprise Manager Cloud Controlコンソールから手動で削除します。

3. エージェント・ベース・ディレクトリを手動で削除します。エージェント・ベース・ディレクトリの詳細は、第2.3.5項を参照してください。
UNIXプラットフォームの場合:

rm -rf <absolute_path_to_install_base_dir>

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

del <absolute_path_to_install_base_dir>

注意:
管理エージェントの削除プロセスで管理エージェント・サービスが自動的に削除されることはありません。次のコマンドを実行して、削除後に手動で削除する必要があります。
sc delete <service_name>

22.1.2.2 インストール・ウィザードをグラフィカル・モードで使用したOracle Management Agentの削除

Enterprise Manager Cloud Controlウィザードをグラフィカル・モードで使用して管理エージェントを削除するには、次の手順を実行します。

注意:
この手順に示されている順序でコンポーネントを削除してください。そうでない場合、インストール・ウィザードにエラーが表示されます。

1. 次のコマンドを実行して、管理エージェント・ホームからインストーラを起動します。
$<AGENT_HOME>/oui/bin/runInstaller -deinstall ORACLE_HOME=<absolute_path_to_agent_home> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

/u01/app/oracle/agent/core/12.1.0.4.0/oui/bin/runInstaller -deinstall ORACLE_HOME=/u01/app/oracle/agent/core/12.1.0.4.0/ -removeallfiles

注意:

- ソフトウェアをダウンロードしたディレクトリからインストーラを起動することもできます。たとえば、<software_location>/となります。

- runInstaller -helpを実行すると、オプション-nowarningonremovefilesがリストに表示されます。このオプションは現在サポートされていないため、使用しても無効になります。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- 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変数を、インストール・ユーザーがアクセス権を持つ場所に設定し、インストール・ウィザードを再起動します。

2. インストール・ウィザードで、「インストールされた製品」をクリックします。

3. 「インベントリ」画面で必要な管理エージェント・ホームの下でプラグイン・ホームを選択し、「削除」をクリックします。

4. 「インベントリ」画面でsbinホームを選択し、「削除」をクリックします。

5. 「インベントリ」画面で管理エージェントを選択し、「削除」をクリックします。

6. エージェント・ベース・ディレクトリを手動で削除します。インストール・ベース・ディレクトリの詳細は、第2.3.5項を参照してください。
UNIXプラットフォームの場合:

rm -rf <absolute_path_to_agent_base_dir>

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

del <absolute_path_to_agent_base_dir>

22.1.2.3 インストール・ウィザードをサイレント・モードで使用したOracle Management Agentの削除

Enterprise Manager Cloud Controlインストール・ウィザードをサイレント・モードで使用して管理エージェントを削除するには、次の手順を実行します。

注意:
この手順に示されている順序でコンポーネントを削除してください。そうでない場合、インストール・ウィザードにエラーが表示されます。

1. プラグイン・ホームを削除します。
$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_plug-in_home}" ORACLE_HOME=<absolute_path_to_agent_home> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- runInstaller -helpを実行すると、オプション-nowarningonremovefilesがリストに表示されます。このオプションは現在サポートされていないため、使用しても無効になります。

- Microsoft Windowsの場合は、setup.exeファイルを起動してください。

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- 複数のプラグインを削除する場合は、プラグイン・ホームをカンマで区切って入力してください。

次に例を示します。

/home/oracle/agent/core/12.1.0.4.0/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/agent/plugins/oracle.sysman.emas.oms.plugin_12.1.0.2.0,/home/oracle/agent/plugins/oracle.sysman.emct.oms.plugin_12.1.0.2.0}" ORACLE_HOME=/home/oracle/agent/core/12.1.0.4.0 -removeAllFiles -invPtrLoc /home/oracle/agent/core/12.1.0.4.0/oraInst.loc

2. sbinホームを削除します。
$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_sbin_directory}" ORACLE_HOME=<absolute_path_to_agent_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

次に例を示します。

/home/oracle/agent/core/12.1.0.4.0/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/agent/sbin}" ORACLE_HOME=/home/oracle/agent/core/12.1.0.4.0 -removeAllFiles -invPtrLoc /home/oracle/agent/core/12.1.0.4.0/oraInst.loc

3. 管理エージェントを削除します。
$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_agent_oracle_home}" ORACLE_HOME=<absolute_path_to_agent_home> -removeAllFiles -invPtrLoc <absolute_path_to_oraInst.loc>

次に例を示します。

/home/oracle/agent/core/12.1.0.4.0/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/agent/core/12.1.0.4.0}" ORACLE_HOME=/home/oracle/agent/core/12.1.0.4.0 -removeAllFiles -invPtrLoc /home/oracle/agent/core/12.1.0.4.0/oraInst.loc

4. エージェント・ベース・ディレクトリを手動で削除します。エージェント・ベース・ディレクトリの詳細は、第2.3.5項を参照してください。
UNIXプラットフォームの場合:

rm -rf <absolute_path_to_install_base_dir>

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

del <absolute_path_to_install_base_dir>

22.1.2.4 共有エージェントの削除

共有エージェントを削除するには、共有エージェントがインストールされているホストで認識可能なマスター・エージェント・ホームから次のコマンドを実行します。

$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=<absolute_path_to_agent_instance_home> ORACLE_HOME=<absolute_path_to_agent_home>

次に例を示します。

/home/john/software/oracle/agent/core/12.1.0.4.0/perl/bin/perl /home/john/software/oracle/agent/core/12.1.0.4.0/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=/home/john/software/oracle/agent/agent_inst ORACLE_HOME=/home/john/software/oracle/agent/core/12.1.0.4.0

注意:
共有エージェントの削除時にエラーが表示される場合、第J.4項を参照してください。

22.1.2.5 RPMファイルを使用してインストールしたOracle Management Agentの削除

.rpmファイルを使用してインストールされた管理エージェントを削除するには、Resource Package Manager (RPM)が管理エージェント・ホストにインストールされていることを確認し、次の手順を実行します。

1. 管理エージェントで次のコマンドを実行し、RPM名を取得します。
rpm -qa | grep oracle-agt

2. rootユーザーとして次のコマンドを実行し、管理エージェントを削除します。
rpm -e <rpm_name>

ここで、<rpm_name>は手順1で実行したコマンドの出力に表示されるRPM名を表します。

22.1.3 Oracle Management Agentの削除後

管理エージェントを削除した後は、次の手順を実行します。

1. (グラフィック・モードのみ)Oracleホームおよびその他のディレクトリが正常に削除されているかどうかを確認します。次の手順を実行します。

1. 管理エージェントのホームから次のコマンドを実行して、インストール・ウィザードを起動します。
<DVD>/runInstaller

注意:
Microsoft Windowsの場合は、setup.exeファイルを起動してください。

2. インストール・ウィザードで、「My Oracle Supportの詳細」画面から「インストールされた製品」をクリックします。

3. 「インベントリ」画面で、削除したOracleホームおよびその他のディレクトリが表示されるかどうかを確認します。正常に削除された場合、これらのOracleホームおよびディレクトリは表示されません。

2. 削除したOracleホームが、中央インベントリから登録解除されます。ただし、一部のファイルがこれらのOracleホームに残ることもあります。その場合は、手動でファイルを削除できます。
また、/etc/init.dディレクトリにあるgcstartupという名前の自動起動スクリプトを手動で削除する必要があります。

注意:
この自動開始スクリプトは、Microsoft Windowsでは提供されていません。

3. Microsoft Windowsプラットフォームで削除した場合は、次の手順を実行します。そのホストに対する管理者権限を持つユーザーとしてログインしていることを確認してください。
Microsoft Windowsレジストリからのエントリの削除

1. 「スタート」→「ファイル名を指定して実行」を選択して、レジストリ・エディタを起動します。「regedit」と入力し、「OK」をクリックします。

2. レジストリ・エディタ・ウィンドウの左ペインで、「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oracle」を展開します。「Oracle」ディレクトリで、次の項目を削除します。
(a)KEY_agent12gn

(b)KEY_sbin12gn

注意:
ここでのnは、エージェント・インスタンスを示す数値を表しています。たとえば、最初のエージェント・インストールの場合KEY_sbin12g9となります。

3. 「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oracle」→「Sysman」を展開します。「Sysman」ディレクトリで、管理エージェント・サービスを削除します。たとえば、Oracleagent12g9Agentとなります。

4. 「HKEY_LOCAL_MACHINE」→「SYSTEM」→「CurrentControlSet」→「Services」を展開します。「Services」ディレクトリで、管理エージェント・キーを削除します。

5. 「HKEY_LOCAL_MACHINE」→「SYSTEM」→「ControlSet002」→「Services」を展開します。「Services」ディレクトリで、管理エージェント・サービスを削除します。

6. レジストリ・エディタを閉じます。

環境設定のクリーンアップ

1. 「環境変数」ウィンドウを開きます。
Microsoft Windows NTの場合、「スタート」→「設定」→「コントロール パネル」→「システム」→「環境」を選択します。

Microsoft Windows XPまたは2000の場合、「スタート」→「設定」→「コントロール パネル」→「システム」→「詳細設定」→「環境変数」を選択します。

2. 「システム環境変数」セクションで、変数PATHをクリックし、値を変更します。

3. 管理エージェント・ホームを削除します。

4. 「適用」をクリックし、「OK」をクリックします。

5. 「コントロール パネル」ウィンドウを閉じます。

6. ホストを再起動します。

22.2 Oracle Management Agentからのプラグインのみの削除またはアンデプロイ

管理エージェント自体ではなく、管理エージェントからプラグインのみを削除またはアンデプロイするには、Enterprise Manager Cloud Controlコンソールのプラグインページを使用します。手順については、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。プラグインのみのアンデプロイには、runInstallerを使用しないでください。

23 ADPとJVMDの削除

この章では、Enterprise Manager Cloud Control環境でアプリケーションの依存性とパフォーマンス(ADP)およびJava仮想マシン診断(JVMD)を削除する方法を説明します。

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

- ADPの削除

- JVMDの削除

23.1 ADPの削除

この項では、アプリケーション・パフォーマンス管理ページを使用して手動でADPエンジンおよびエージェントを削除する方法について説明します。この項の内容は次のとおりです。

- ADPエンジンの削除

- ADPエージェントの削除

23.1.1 ADPエンジンの削除

この項では、ADPエンジンを削除する方法について説明します。内容は次のとおりです。

- アプリケーション・パフォーマンス管理ページを使用したADPエンジンの削除

- ADPエンジンの手動での削除

- ApmEngineSetup.plを使用したADPエンジンの手動での削除

23.1.1.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエンジンの削除

アプリケーション・パフォーマンス管理ページを使用して管理対象サーバー上で実行中のADPエンジン・アプリケーションを削除するには、次の手順を実行します。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページで単一のADPエンジンを削除する場合、削除するADPエンジンを選択して、「削除」をクリックします。
アプリケーション・パフォーマンス管理ページで複数のADPエンジンを削除する場合、「ADPエンジン」ノードを選択して、「削除」をクリックします。

3. ADPエンジンの削除ページで、削除するADPエンジンを選択します。

4. ADPエンジンがデプロイされているWebLogicが管理するサーバーを削除する場合、選択したADPエンジンごとに「Weblogic管理対象サーバーの削除」を選択します。

5. 「管理Weblogicホストの資格証明」および「管理Weblogic資格証明」の値を指定します。
管理WebLogicホストの資格証明は、(Enterprise Manager WebLogicドメインの) WebLogic管理サーバーがデプロイされているホストのホスト資格証明です。管理Weblogic資格証明は、Enterprise Manager WebLogicドメインの管理サーバーの資格証明です。

6. 「削除」をクリックします。

23.1.1.2 ADPエンジンの手動での削除

管理対象サーバー上で実行中のADPエンジン・アプリケーションを手動で削除するには、次の手順を実行します。

1. Cloud Controlで、「ターゲット」メニューから「ミドルウェア」を選択します。

2. 「ミドルウェア」ページの「ミドルウェアの機能」メニューで、「アプリケーションの依存性とパフォーマンス」を選択します。
「アプリケーションの依存性とパフォーマンス」が表示されます。

3. 「登録」タブで、ADPエンジン・アプリケーションを選択し、「削除」をクリックします。

4. Enterprise ManagerドメインのWebLogic管理コンソールにログインします。

5. ホームページで、「サーバー」をクリックします。

6. 「サーバーのサマリー」ページで「制御」タブをクリックし、「ADPエンジン・サーバー」を選択します。

7. 「停止」メニューから「ただちに強制停止」を選択してサーバーを停止します。

8. WebLogic管理コンソールに表示された「ロックと編集」ボタンをクリックします。

9. 「構成」タブをクリックし、「ADPエンジン・サーバー」を選択して、「削除」をクリックします。

10. ADPアプリケーションをアンデプロイします。たとえば、ADPのADPManager_EMGC_ADPMANAGER1です。

11. 管理対象サーバーが存在していたホスト・マシンに接続し、次の場所に移動して、管理対象サーバーを手動で削除します。

$DOMAIN_HOME/<ADP_managed_server>

$DOMAIN_HOMEは、Enterprise Manager Cloud Controlドメインの場所です。

23.1.1.3 ApmEngineSetup.plを使用したADPエンジンの手動での削除

ApmEngineSetup.plスクリプトを使用して、ADPエンジンを手動で削除できます。このスクリプトは次の方法で実行できます。

- 対話型モード: 対話形式で詳細を入力するようにプロンプト表示されます。

- サイレント・モード: プロパティ・ファイルを使用してすべての入力の詳細を指定します。

重要:
ApmEngineSetup.plスクリプトを使用して、リモート・ホストではなく、OMSを実行しているホスト上のみのADPエンジンを削除できます。

ApmEngineSetup.plスクリプトを使用してADPエンジンを手動で削除するには、次の手順に従います。

1. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.6.0/archives/jvmd/deployment_Scripts/engine/

2. README.txtファイルでApmEngineSetup.plスクリプトの使用についての情報を確認します。

3. ApmEngineSetup.plスクリプトを実行します。
ApmEngineSetup.plスクリプトを対話型モードで、プロンプト表示に従って詳細を入力するには、次のコマンドを使用します。

perl ApmEngineSetup.pl

必ず、操作をremoveとし、エンジン・タイプをADPとして指定します。

ApmEngineSetup.plスクリプトをサイレント・モードで実行するには、プロパティ・ファイルにすべての入力の詳細を指定し、次のコマンドを使用します。

perl ApmEngineSetup.pl -silent -file <properties_file_name> -password <password>

<properties_file_name>は、ADPエンジンおよび操作の詳細が記載されるプロパティ・ファイルの名前です。<password>は、WebLogicコンソールのパスワードです。

入力の詳細をプロパティ・ファイルに指定する方法は、サンプルのプロパティ・ファイルSAMPLE_engine.propertiesをご覧ください。

23.1.2 ADPエージェントの削除

この項では、ADPエージェントを削除する方法について説明します。内容は次のとおりです。

- アプリケーション・パフォーマンス管理ページを使用したADPエージェントの削除

- ADPエージェントの手動での削除

23.1.2.1 「アプリケーション・パフォーマンス管理」ページを使用したADPエージェントの削除

アプリケーション・パフォーマンス管理ページを使用して、(WebLogicドメインにデプロイされ監視された)ADPエージェントを削除するには、次の手順を実行します。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページの「アプリケーション・パフォーマンス管理エージェント」セクションで、「診断エージェントの管理」をクリックします。

注意:
アクティブのJVMDまたはADPエンジンがなく、JVMDまたはADPエージェントがデプロイされていない場合、「診断エージェントの管理」ボタンは無効になっています。

3. 「操作」で、「削除」を選択します。
「表示」メニューから「すべてを開く」を選択した場合は、JVMDまたはADPエージェントがデプロイされているすべての管理対象サーバーのターゲット名、ターゲット・タイプ、ターゲット・ホスト、ターゲット・ステータス、プラットフォームなどを表示できます。

削除するADPエージェントを選択します。「次へ」をクリックします。

4. ターゲットの資格証明ページで、WebLogicドメインごとに「Oracle WebLogic管理サーバー・ホストの資格証明」および「Oracle WebLogicドメインの資格証明」の値を指定し、「適用」をクリックします。
Oracle WebLogic管理サーバー・ホストの資格証明は、選択したWebLogicドメインを監視している管理エージェントが実行されているホストのホスト資格証明です。Oracle WebLogicドメインの資格証明は、選択されたWebLogicドメインの管理サーバーの資格証明です。

「次へ」をクリックします。

5. ADPエージェント構成ページで、「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. 確認ページですべての情報を確認し、「削除」をクリックします。

23.1.2.2 ADPエージェントの手動での削除

ターゲットにデプロイされたADPエージェントを手動で削除するには、次の手順を実行します。

1. Cloud Controlで、「ターゲット」メニューから「ミドルウェア」を選択します。

2. 「ミドルウェア」ページの「ミドルウェアの機能」メニューで、「アプリケーションの依存性とパフォーマンス」を選択します。
「アプリケーションの依存性とパフォーマンス」が表示されます。

3. 「構成」タブで、ADPエージェントがデプロイされているADPエンジン・アプリケーションを選択します。

4. 「ADPエンジン」メニューを展開し、「リソース構成」を選択します。

5. 「リソース」表からADPエージェント名を選択し、「リソースの編集」をクリックして、次に「デプロイ」をクリックします。

6. 「パラメータのデプロイ」表から、ADPエージェントをアンデプロイするサーバーを選択します。デフォルトのメニュー選択を「デプロイ」から次のものに変更します。

- 「削除」(管理対象サーバーからADPエージェント・ファイルをすべて消去する場合)

- 無効化(管理対象サーバーからADPエージェントの起動引数を削除する場合)

注意:
ノード・マネージャを使用している場合のみ、ノード・マネージャにより起動されたサーバー・オプションを選択します。

23.2 JVMDの削除

この項では、アプリケーション・パフォーマンス管理ページを使用して手動でJVMDエンジンおよびエージェントを削除する方法について説明します。この項の内容は次のとおりです。

- JVMDエンジンの削除

- JVMDエージェントの削除

23.2.1 JVMDエンジンの削除

この項では、JVMDエンジンを削除する方法について説明します。内容は次のとおりです。

- アプリケーション・パフォーマンス管理ページを使用したJVMDエンジンの削除

- JVMDエンジンの手動での削除

- ApmEngineSetup.plを使用したJVMDエンジンの手動での削除

23.2.1.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエンジンの削除

アプリケーション・パフォーマンス管理ページを使用して管理対象サーバー上で実行中のJVMDエンジン・アプリケーションを削除するには、次の手順を実行します。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページで単一のJVMDエンジンを削除する場合、削除するJVMDエンジンを選択して、「削除」をクリックします。
アプリケーション・パフォーマンス管理ページで複数のJVMDエンジンを削除する場合、「JVM診断エンジン」ノードを選択して、「削除」をクリックします。

3. JVMDエンジンの削除ページで、削除するJVMDエンジンを選択します。

4. JVMDエンジンがデプロイされているWebLogicが管理するサーバーを削除する場合、選択したJVMDエンジンごとに「Weblogic管理対象サーバーの削除」を選択します。

5. 「管理Weblogicホストの資格証明」および「管理Weblogic資格証明」の値を指定します。
管理WebLogicホストの資格証明は、(Enterprise Manager WebLogicドメインの) WebLogic管理サーバーがデプロイされているホストのホスト資格証明です。管理Weblogic資格証明は、Enterprise Manager WebLogicドメインの管理サーバーの資格証明です。

6. 「削除」をクリックします。

23.2.1.2 JVMDエンジンの手動での削除

管理対象サーバー上で実行中のJVMDエンジン・アプリケーションを手動で削除するには、次の手順を実行します。

1. Enterprise Manager Cloud ControlドメインのWebLogic管理コンソールにログインします。

2. ホームページで、「デプロイメント」をクリックします。

3. JVMDアプリケーション(たとえば、jammanagerEMGC_JVMDMANAGER1、jammanagerEMGC_JVMDMANAGER2)を選択します。「停止」メニューから「ただちに強制停止」を選択します。

4. WebLogic管理コンソールに表示された「ロックと編集」ボタンをクリックします。

5. アプリケーションが停止したら、同じアプリケーションを選択して「削除」をクリックします。

6. 「ホーム」をクリックしてWebLogic管理ホームページに戻ります。「環境」表から「サーバー」を選択します。

7. 「サーバーのサマリー」ページで「制御」タブを選択し、停止する必要のあるJVMDエンジン・サーバーを選択します。

8. 「停止」メニューから「ただちに強制停止」を選択してサーバーを停止します。

9. WebLogic管理コンソールに表示された「ロックと編集」ボタンをクリックします。

10. 「構成」タブをクリックし、JVMDエンジン・サーバーを選択して、「削除」をクリックします。

23.2.1.3 ApmEngineSetup.plを使用したJVMDエンジンの手動での削除

ApmEngineSetup.plスクリプトを使用して、JVMDエンジンを手動で削除できます。このスクリプトは次の方法で実行できます。

- 対話型モード: 対話形式で詳細を入力するようにプロンプト表示されます。

- サイレント・モード: プロパティ・ファイルを使用してすべての入力の詳細を指定します。

重要:
ApmEngineSetup.plスクリプトを使用して、リモート・ホストではなく、OMSを実行しているホスト上のみのJVMDエンジンを削除できます。

ApmEngineSetup.plスクリプトを使用してJVMDエンジンを手動で削除するには、次の手順に従います。

1. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.6.0/archives/jvmd/deployment_Scripts/engine/

2. README.txtファイルでApmEngineSetup.plスクリプトの使用についての情報を確認します。

3. ApmEngineSetup.plスクリプトを実行します。
ApmEngineSetup.plスクリプトを対話型モードで、プロンプト表示に従って詳細を入力するには、次のコマンドを使用します。

perl ApmEngineSetup.pl

必ず、操作をremoveとし、エンジン・タイプをJVMDとして指定します。

ApmEngineSetup.plスクリプトをサイレント・モードで実行するには、プロパティ・ファイルにすべての入力の詳細を指定し、次のコマンドを使用します。

perl ApmEngineSetup.pl -silent -file <properties_file_name> -password <password>

<properties_file_name>は、JVMDエンジンおよび操作の詳細が記載されるプロパティ・ファイルの名前です。<password>は、WebLogicコンソールのパスワードです。

入力の詳細をプロパティ・ファイルに指定する方法は、サンプルのプロパティ・ファイルSAMPLE_engine.propertiesをご覧ください。

23.2.2 JVMDエージェントの削除

この項では、JVMDエージェントを削除する方法について説明します。内容は次のとおりです。

- アプリケーション・パフォーマンス管理ページを使用したJVMDエージェントの削除

- JVMDエージェントの手動での削除

23.2.2.1 「アプリケーション・パフォーマンス管理」ページを使用したJVMDエージェントの削除

アプリケーション・パフォーマンス管理ページを使用して、(WebLogicドメインにデプロイされ監視された)JVMDエージェントを削除するには、次の手順を実行します。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページの「アプリケーション・パフォーマンス管理エージェント」セクションで、「診断エージェントの管理」をクリックします。

注意:
アクティブのJVMDまたはADPエンジンがなく、JVMDまたはADPエージェントがデプロイされていない場合、「診断エージェントの管理」ボタンは無効になっています。

3. 「操作」で、「削除」を選択します。
「表示」メニューから「すべてを開く」を選択した場合は、JVMDまたはADPエージェントがデプロイされているすべての管理対象サーバーのターゲット名、ターゲット・タイプ、ターゲット・ホスト、ターゲット・ステータス、プラットフォームなどを表示できます。

削除するJVMDエージェントを選択します。「次へ」をクリックします。

4. ターゲットの資格証明ページで、WebLogicドメインごとに「Oracle WebLogic管理サーバー・ホストの資格証明」および「Oracle WebLogicドメインの資格証明」の値を指定し、「適用」をクリックします。
Oracle WebLogic管理サーバー・ホストの資格証明は、選択したWebLogicドメインを監視している管理エージェントが実行されているホストのホスト資格証明です。Oracle WebLogicドメインの資格証明は、選択されたWebLogicドメインの管理サーバーの資格証明です。

「次へ」をクリックします。

5. JVMDエージェント構成ページで、「WebLogicホーム」および「ミドルウェア・ホーム」フィールドの値を指定します。
これらのフィールドは、値を内部的に取得できなかった場合のみ表示されます。また、WebLogic管理サーバーがファイアウォール内または仮想ホスト上にある場合に、アプリケーションがデフォルトのホスト値を使用して接続できないことがあります。この場合は、追加情報を「追加構成」セクションに入力する必要がある場合があります。たとえば、WebLogic管理サーバーが仮想ホスト上にあり、アプリケーションがデフォルトのホスト値を使用して接続できない場合は、「追加構成」セクションにその仮想ホストのIPアドレスを入力する必要がある場合があります。

6. 確認ページですべての情報を確認し、「削除」をクリックします。

23.2.2.2 JVMDエージェントの手動での削除

ターゲットにデプロイされたJVMDエージェントを手動で削除するには、次の手順を実行します。

1. ターゲット・サーバーの管理コンソールにログインします。

2. ホームページで、「デプロイメント」をクリックします。

3. JVMDエージェント・アプリケーション(javadiagnosticagent.ear or jamagent.war)を選択します。「停止」メニューから「ただちに強制停止」を選択します。

4. アプリケーションが停止したら、同じアプリケーションを選択して「削除」をクリックします。

5. Enterprise Manager Cloud Controlにログインします。

6. Cloud Controlで、「ターゲット」メニューから「ミドルウェア」を選択します。

7. ミドルウェアページの「検索」表で「Java仮想マシン」タイプのターゲットを検索し、サーバーに対応するターゲットを選択して「削除」をクリックします。

24 スタンバイOracle Management Serviceの削除

この章では、レベル4の高可用性(HA)構成からスタンバイOracle Management Service (OMS)を削除する方法について説明します。次のOMSの削除シナリオについて説明します。

- 追加のスタンバイOMSインスタンスの削除

- 最初のスタンバイOMSの削除

24.1 追加のスタンバイOMSインスタンスの削除

追加のスタンバイOMSインスタンスを削除するには、次の手順を実行します。

1. OMSホームから次のコマンドを実行して追加のスタンバイOMSインスタンスを構成解除して削除します。
$<OMS_HOME>/bin/omsca delete -OMSNAME <oms_name>

プロンプトが表示された場合は、リポジトリのログイン資格証明を入力します。

注意:
追加の各スタンバイOMSインスタンスでこのコマンドを実行します。

2. Enterprise Managerコンソールから、WebLogicドメインをリフレッシュします。

1. 「ターゲット」メニューから「ミドルウェア」を選択します。

図24-1 「ミドルウェア」メニュー

2. リフレッシュするWebLogicドメインをクリックします。ドメインのホームページが表示されます。

図24-2 ドメインのホームページ

3. 「ファーム」または「WebLogicドメイン」メニューから「WebLogicドメインのリフレッシュ」を選択します。

図24-3 WebLogicドメインのリフレッシュ

Enterprise Managerに、使用可能な「WebLogicドメインのリフレッシュ」オプションが表示されます。

図24-4 WebLogicドメインのリフレッシュ

4. 「ターゲットの追加/更新」をクリックします。管理エージェントは、管理サーバーに接続することでリフレッシュします。リフレッシュを行うには、管理サーバーを起動する必要があります。
「確認」ページで「閉じる」をクリックします。ドメイン内の新規および変更されたターゲットが検索されます。

3. OMSに関連付けられているOMSターゲットを削除します。

1. 「ターゲット・ナビゲーション」領域で、以前に構成解除した追加のスタンバイOMSに関連付けられているターゲットをクリックします。

2. 「WebLogic」メニューから、「ターゲット設定」、「ターゲットの削除」の順に選択します。Enterprise Managerに、続行するかどうかを尋ねる警告ダイアログが表示されます。「はい」をクリックします。

4. 残りの追加のスタンバイOMSすべてに対してこの削除手順を繰り返します。

24.2 最初のスタンバイOMSの削除

最初のスタンバイOMSを削除するには、次の手順を実行します。

重要:
環境内に残っている追加のスタンバイOMSが存在する場合は、最初のスタンバイOMSを削除しないでください。追加のスタンバイOMSを削除する手順は、「追加のスタンバイOMSインスタンスの削除」を参照してください。

1. OMSホームから次のコマンドを実行して最初のスタンバイOMSインスタンスを構成解除して削除します。
$<OMS_HOME>/bin/omsca delete -full

注意:
プロンプトが表示されたら、操作を確認し、AdminServer資格証明およびリポジトリ・データベースの詳細(データベース・ホスト名、リスナー・ポート、SIDおよびパスワードなど)を指定します。必要な詳細を指定すると、コマンドによりOMS、Oracle WebLogic ServerおよびOracle WebTierが自動的に停止されます。

2. OMSに関連付けられているOMSターゲットを削除します。

1. 「ターゲット・ナビゲーション」領域で、以前に構成解除した最初のスタンバイOMSに関連付けられているターゲットをクリックします。

2. 「WebLogic」メニューから、「ターゲット設定」、「ターゲットの削除」の順に選択します。Enterprise Managerに、続行するかどうかを尋ねる警告ダイアログが表示されます。「はい」をクリックします。

第VIII部

付録

この部は、次の付録で構成されています。

- 付録A「Enterprise Managerのディレクトリ構造の理解」

- 付録B 「インストールおよび構成ログ・ファイルの概要」

- 付録C「別のOracle Management ServiceへのOracle Management Agentのリダイレクト」

- 付録D「Oracle Management Agentのデプロイまたはアップグレード中のパッチの適用」

- 付録E「RepManagerユーティリティの使用」

- 付録F「Oracle Harvesterを使用したOCMデータの収集」

- 付録G「Enterprise Managerのアクセシビリティ機能の有効化」

- 付録H「アクティブおよびパッシブ環境でのフェイルオーバーのターゲットの構成」

- 付録J「トラブルシューティング」

A Enterprise Managerのディレクトリ構造の理解

メンテナンスと詳細構成タスクを実行する前に、Enterprise Managerをインストールするとディスクにコピーされるディレクトリおよびファイルについて理解しておく必要があります。各ファイルの場所を理解すると、インストールまたは構成上の問題の解決が必要な場合に役立ちます。

Enterprise Managerのインストール時にWebLogic Serverを含まない場所を選択すると、WebLogic Serverのインストール前に、JDKがjdk16ディレクトリにインストールされます。

Enterprise Managerをインストールするとディスクに作成されるディレクトリについて理解を深めるには、次の項を使用してください。

- Oracle Enterprise Manager Cloud Control 12cとともにインストールされるEnterprise Managerのディレクトリの理解

- Oracle Management ServiceとともにインストールされるEnterprise Managerのディレクトリの理解

- 管理エージェントとともにインストールされるEnterprise Managerのディレクトリの理解

A.1 Oracle Enterprise Manager Cloud Control 12cとともにインストールされるEnterprise Managerのディレクトリの理解

Oracle Enterprise Manager Cloud Control 12cをインストールする場合は、Oracle Management Serviceをインストールします。Oracle Management Serviceでは、次のOracleホーム・ディレクトリをインストールします。

- Oracle Management Serviceホーム・ディレクトリ

- ミドルウェアWebTierホーム・ディレクトリ

- ミドルウェア共通ホーム・ディレクトリ

- Oracle Management Serviceインスタンス・ホーム・ディレクトリ

- Oracle Management Agentホーム・ディレクトリ

- Oracle Management Agent Instanceホーム・ディレクトリ

- Oracle Management Serviceプラグイン・ホーム

- Oracle Management Agentプラグイン・ホーム

- Oracle Business Intelligence Publisherホーム

A.1.1 Oracle Management Serviceホーム・ディレクトリについて

Oracle Management Serviceは、Oracle WebLogic Serverを使用してインストールおよびデプロイされるJ2EEアプリケーションです。

インストール時には、Oracle Management Serviceを含むEnterprise ManagerコンポーネントがCloud Controlホーム内にインストールされます。

Fusion Middlewareインストールに固有のディレクトリの詳細は、Fusion Middlewareのドキュメントを参照してください。

A.1.2 Oracle Management Agentホーム(AGENT_HOME)ディレクトリについて

AGENT_HOMEディレクトリには、ホスト上でOracle Management Agentを構成および実行するために必要なすべてのバイナリが含まれています。

このディレクトリは、Oracle Management AgentのOracleホームとして使用されます。

Fusion Middlewareインストールに固有のディレクトリの詳細は、Fusion Middlewareのドキュメントを参照してください。

A.1.3 Business Intelligence Publisherホーム・ディレクトリについて

Business Intelligence Publisherは、Oracle_BI1ディレクトリにインストールされるJ2EEアプリケーションです。このディレクトリには、Business Intelligence Publisherのすべての構成ファイルおよびソフトウェア・バイナリが格納されます。

Middlewareホームの(middleware_home)ディレクトリにBusiness Intelligence Publisherのディレクトリが作成されます。

Business Intelligence Publisherを使用するには、第14章に従って構成します。

A.1.4 Oracle Management Serviceホーム内の重要なディレクトリの要約

図A-1は、基本的なCloud Controlインストールにおける、理解しておく必要のある重要なディレクトリの一部を示しています。この情報は、Oracle Management Serviceのインストールの管理、トラブルシューティングおよび構成を開始する際に使用してください。

図A-1

表A-1 Enterprise Managerとともにインストールされるディレクトリ

ディレクトリ

説明

wlserver_10.3、logs、utils、modules

これらのディレクトリにはFusion Middlewareファイルが含まれています。

jdk16

このディレクトリには、JDK構成ファイルが含まれています。

oms

このディレクトリには、OMS構成ファイルが含まれています。詳細は、第10.2.2項を参照してください。

plugins

このディレクトリには、OMSにインストールされるメタデータ・プラグイン構成ファイルが含まれています。

agent

このディレクトリには、エージェント構成ファイルが含まれています。詳細は、第10.2.3項を参照してください。

(オプション) Oracle_BI1

このディレクトリには、Oracle Business Intelligence Publisherの構成ファイルが格納されます。

oracle_WT

このディレクトリには、Oracle WebTier構成ファイルが含まれています。

oracle_common

このディレクトリには、OMS、Oracle WebTierおよびWebLogic Serverのディレクトリで使用される共通ファイルが含まれています。

A.2 管理サービスとともにインストールされるEnterprise Managerのディレクトリの理解

表A-2では、Oracle Management ServiceとともにインストールされるOracle Management Serviceのディレクトリについて詳しく説明します。この表で示されているORACLE_HOMEは、Oracle Management ServiceがインストールおよびデプロイされるOracle Management Serviceホーム・ディレクトリを指しています。

表A-2 管理サービスOracleホーム内の重要なディレクトリ

ディレクトリ

説明

ORACLE_HOME/bin

管理サービス・ホーム内のbinディレクトリには、Cloud Controlインストールのコンポーネントを制御するためのコマンドが含まれています。

OMS_INSTANCE_HOME/WebTierIH1

このディレクトリには、EMGC_OMS#に対応するWeb層インスタンスOracleホームが含まれます。

OMS_INSTANCE_HOME/NodeManager

このディレクトリには、WebLogicノード・マネージャのプロパティ、ログおよびドメイン情報が含まれます。

OMS_INSTANCE_HOME/em

これはOMSインスタンス・ディレクトリで、emgc.propertiesとEnterprise Managerログ・ファイルが含まれます。

OMS_INSTANCE_HOME/user_projects

このディレクトリには、EMGC_ADMINSERVERおよびEMGC_OMS#ドメインとそのログが含まれます。

ORACLE_HOME/sysman/log

このディレクトリには、スキーマ・ログ・ファイルが含まれています。リポジトリ・ログ・ファイルはsysman/log/schemamanagerの下にあります。インストール・ログはORACLE_HOME/cfgtoollogsの下にあります。操作ログはOMS_INSTANCE_HOME/em/EMGC_OMS1/sysman/logの下にあります。

A.3 管理エージェントとともにインストールされるEnterprise Managerのディレクトリの理解

Oracle Management Agentは、Oracle Management Serviceをインストールすると自動的にインストールされます。このOracle Management Agentのローカル・インスタンスにより、Oracle Management Serviceホスト上のターゲットに関する管理情報が収集されます。これにより、これらのターゲット(ホスト自身など)をCloud Controlコンソールから管理できます。

各種のインストール方法を使用して、追加のOracle Management Agentをインストールできます。このため、エンタープライズ全体の各ホストにOracle Management Agentをインストールできます。Oracle Management Agentでは、各ホスト上のターゲットに関する管理データを収集できるため、Cloud Controlコンソールからこれらのターゲットを管理できます。

具体的には、Oracle Management Agentのファイルは、Oracle Management Serviceをインストールした際のagentディレクトリ内の構造と同じディレクトリ構造(図A-1)にインストールされます。

スタンドアロン・エージェントまたはOMSをインストールする場合のエージェント・ディレクトリの構造は同じです。AGENT_BASE_DIRは、エージェントがインストールされるディレクトリで、次のメイン・ディレクトリが含まれます。

- AGENT_HOME

- AGENT_INSTANCE_HOME

- SBIN_HOME

- PLUGIN_HOME

Oracle Management Agentの実行に必要なファイルが含まれているディレクトリは、AGENT_INSTANCE_HOMEディレクトリと呼ばれます。たとえば、Oracle Management Agentを起動または停止するには、AGENT_INSTANCE_HOMEのbinディレクトリにあるemctlコマンドを使用します。同様に、Oracle Management Agentのファイルを構成するには、AGENT_INSTANCE_HOMEのsysman/configディレクトリにある構成ファイルを変更します。エージェントのディレクトリ構造については、図A-2を参照してください。

図A-2 エージェント・ディレクトリ構造

A.3.1 Oracle Management Agentホーム内の重要なディレクトリの要約

表A-3では、重要なエージェント・ディレクトリの一部について説明します。

表A-3 Oracle Management Agentホーム内の重要なディレクトリ

ディレクトリ

説明

AGENT_HOME

AGENT_HOMEディレクトリには、このホスト上でOracle Management Agentを構成および実行するために必要なすべてのバイナリが含まれています。

AGENT_HOMEのデフォルトの場所はAGENT_BASE_DIR/core/12.1.0.2.0です。

このディレクトリは、Oracle Management AgentのOracleホームとして使用されます。

AGENT_HOME/bin

このディレクトリには、Oracle Management Agentのバイナリが含まれています。

AGENT_HOME/install

このディレクトリには、エージェントをデプロイするためのインストール関連のファイルが含まれています。

AGENT_HOME/prereqs

このディレクトリには、EMPrereqKitの前提条件ファイルが含まれています。

AGENT_HOME/oui

このディレクトリには、インストーラ・フレーワークに関連するファイルが含まれています。

AGENT_HOME/cfgtoollogs

このディレクトリには、エージェントのデプロイおよび構成のログ・ファイルが含まれています。

AGENT_HOME/EMStage

このディレクトリは、プロビジョニング・アクティビティのプロビジョニング・フレームワークで使用されます。

AGENT_HOME/sysman/admin

このディレクトリには、エージェント・コアのターゲット・タイプ(データベースやホストなど)の定義、構成スクリプトの実行、および他の管理タスクを行う際にOracle Management Agentによって使用されるファイルが含まれています。

AGENT_INSTANCE_HOME

AGENT_INSTANCE_HOMEディレクトリには、エージェントのインストールおよび構成後のエージェント関連のファイルが含まれています。

AGENT_INSTANCE_HOMEのデフォルトの場所はAGENT_BASE_DIR/agent_instです。

AGENT_INSTANCE_HOME/bin

Cloud ControlホームのAGENT_INSTANCE_HOME/binディレクトリには、このホストでOracle Management Agentを制御するためのemctlコマンドが含まれています。

このホスト上でOracle Management Agentを起動および停止するには、このディレクトリ内の次のemctlコマンドを使用します。

<AGENT_INSTANCE_HOME>/bin/emctl start agent

<AGENT_INSTANCE_HOME>/bin/emctl stop agent

AGENT_INSTANCE_HOME/sysman/config

このディレクトリには、Oracle Management Agentの構成ファイルが含まれています。たとえば、Enterprise Managerではemd.propertiesファイルがここに格納されます。emd.propertiesファイルは、このエージェントのOracle Management ServiceアップロードURLなどの設定を定義するものです。

AGENT_INSTANCE_HOME/sysman/log

このディレクトリには、Oracle Management Agentのログ・ファイルが含まれています。

AGENT_INSTANCE_HOME/sysman/emd

emdディレクトリには、ホスト上で検出されたターゲットの情報が含まれています。

SBIN_HOME

このディレクトリには、エージェントのセットUIDが含まれています。デフォルトの場所はAGENT_BASE_DIR/sbinです。

PLUGIN_HOME

このディレクトリには、エージェントに必要な検出および監視のすべてのプラグインが含まれています。

デフォルトの場所はAGENT_BASE_DIR/pluginsです。

A.3.2 WindowsのOracle Management Agentディレクトリ構造の理解

WindowsシステムにOracle Management Agentをインストールした場合、AGENT_HOMEディレクトリのディレクトリ構造は、UNIXシステムにインストールした場合のディレクトリ構造と同様になります。

A.4 emctlコマンド使用時のエージェント・インスタンス・ホームの識別

Cloud Controlをインストールした結果として作成されるディレクトリ構造に、同じ名前のサブディレクトリが複数含まれる場合があります。たとえば、agent_instance_homeディレクトリ内にbinディレクトリが含まれる場合があります。agent_instance_home/binディレクトリ内のemctlコマンドは、Oracle Management Agentを制御するために使用します。

また、Oracle Management ServiceのOracleホームにもbinディレクトリが作成されます。このディレクトリ内のemctlコマンドは、Oracle Management Serviceを制御するために使用します。

特定のbinディレクトリ内のファイルによって制御されるエージェント・インスタンス・ホームを即座に識別するには、次のコマンドを使用します。

$PROMPT> emctl getemhome

このコマンドを使用すると、emctlコマンドのこのインスタンスによって実行されるコマンドの影響を受ける現行のエージェント・インスタンス・ホームへのパスが表示されます。

B インストールおよび構成ログ・ファイルの概要

この付録では、Enterprise Manager Cloud Controlコンポーネントの前提条件チェック、インストールおよび構成の各フェーズで作成される各種ログ・ファイルの場所を一覧表示します。

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

- Enterprise Manager Cloud Controlのインストール・ログ

- ホストの追加ログ・ファイル

- 手動の管理エージェント・インストール・ログ

- 追加のOMSインストール・ログ

B.1 Enterprise Manager Cloud Controlのインストール・ログ

この項では、Enterprise Manager Cloud Controlのインストール中に作成される次のログ・ファイルについて説明します。

- インストール・ログ

- 構成ログ

B.1.1 インストール・ログ

次のインストール・ログに、インストールのステータスに関する完全な情報が記録されます。

- <ORACLE_INVENTORY_HOME>/logs/installActions<timestamp>.log

- <ORACLE_HOME>/cfgtoollogs/oui/installActions<timestamp>.log

注意:
installActionsログ・ファイルは、デフォルトで<ORACLE_INVENTORY_HOME>ディレクトリ内に作成されます。このログ・ファイルは、インストールが完了すると、前述のOracleホームの場所にコピーされます。

B.1.2 構成ログ

この項では、次の構成ログについて説明します。

- 一般的な構成ログ

- リポジトリ構成ログ

- セキュア・ログ

B.1.2.1 一般的な構成ログ

Oracle Management Service (OMS)構成ログは、OMSのOracleホームの次の場所に作成されます。

<ORACLE_HOME>/cfgtoollogs/omsca

表B-1に、各種のインストール・タイプに対応する構成ログを一覧表示します。

表B-1 一般的な構成ログ

インストール・タイプ

場所

Enterprise Managerシステムの新規インストールまたはアップグレード

- <ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger<timestamp>.log

- <ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.oms.<timestamp>.log

注意: <ORACLE_HOME>は、OMSのOracleホームを指します。

追加管理サービスの追加

- <ORACLE_HOME>/cfgtoollogs/omsca/logs/omsca<timestamp.log>

- <ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.oms.<timestamp>.log

注意: <ORACLE_HOME>は、OMSのOracleホームを指します。

Oracle Management Agentのインストール

- <ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger

- <ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.agent.<timestamp>.log

注意: <ORACLE_HOME>は、管理エージェントのOracleホームを指します。

B.1.2.2 リポジトリ構成ログ

この項では、次のリポジトリ構成ログについて説明します。

- SYSMANスキーマ操作ログ

- MDSスキーマ操作ログ

B.1.2.2.1 SYSMANスキーマ操作ログ

SYSMANスキーマ操作ログは、OMSのOracleホームの次の場所にあります。このディレクトリには、RepManager実行のすべてのインスタンスにより実行されたすべてのアクションが記録される全体的なログ・ファイルemschema.logが格納されます。

$<ORACLE_HOME>/sysman/log/schemanager/

RepManagerが実行されるたびに、RepManagerの実行時刻に基づいて、このディレクトリ内に新しいサブディレクトリが作成されます。

たとえば、RepManagerが2007年9月29日の午後12:50に作成された場合、次のサブディレクトリが作成されます。

$<ORACLE_HOME>/sysman/log/schemananager/m_092907_1250_PM/

RepManager (またはRepManagerに相当する要素)のインスタンスは、スキーマ・アクション(主に、CREATE、DROP、UPGRADE、TRANSXおよびRESUME_RETRY)を持つことができます。アクションごとにサブディレクトリが作成されます。

たとえば、2006年9月29日の午後12時51分にRepManagerインスタンスによってCREATEアクションが実行された場合、次のサブディレクトリが作成されます。このサブディレクトリの下に、RCU関連のログ・ファイルと、CREATEアクションに固有のメッセージが記録されたemschema.log.CREATEログ・ファイルが格納されます。

$<ORACLE_HOME>/sysman/log/schemananager/m_092907_1250_PM/m_092907_1251PM.CREATE/

一般に、$<ORACLE_HOME>/sysman/log/schemananager/m_<time-stamp>/m_<time-stamp>.<schema-action>の中には次のファイルが作成されます。

- 各コンポーネントのRCU (init、common、modify、drop、config、outofbox、preupgradeログ)

- RCUログ

- スキーマ・アクションに固有のRCUログ

- TransXアクションに固有のログ(emrep_config.log)

SQL実行でいずれかのスキーマ操作(CREATE/UPGRADE/PREUPGRADE/DROP)が失敗した場合、「再試行」をクリックして操作を再試行すると、m_<time-stamp>.RESUME_RETRYという名前の個別のサブディレクトリが作成されます。

各種のスキーマ・アクションに対応するリポジトリ操作ログの全体的なディレクトリ構造を次に示します。

$<ORACLE_HOME>/sysman/log/schemamanager
emschema.log
m_030210_0349_AM
m_030210_0325_AM.TRANSX
emrep_config.log
emschema.log.TRANSX
m_030210_0438_AM
m_030210_0438_AM.DROP (Same structure for Drop and Dropall actions)
rcu.log
emschema.log.DROP
em_repos_drop.log
m_030210_0450_AM
m_030210_0450_AM.CREATE
custom_comp_create_tbs.log
em_repos_common.log
em_repos_init.log
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
emschema.log
rcu.log
emschema.log.CREATE
em_repos_config.log
m_030210_1006_PM
m_030210_1006_PM.RESUME_RETRY
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
emschema.log
rcu.log
emschema.log.RESUME_RETRY
em_repos_modify.log
m_030210_1021_PM
m_030210_1021_PM.UPGRADE
em_repos_init.log
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
emschema.log
rcu.log
emschema.log.UPGRADE
em_repos_modify.log
m_030210_1100_PM
m_030210_1100_PM.PREUPGRADE
em_repos_preupgrade.log
emschema.log.PREUPGRADE
rcu.log
em_repos_init.log
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
em_repos_common.log
m_030210_1125_PM
m_030210_1125_PM.MY_ORACLE_SUPPORT
emschema.log.MY_ORACLE_SUPPORTm_030210_1135_PM            m_030210_1135_PM.PLUGINPURGE                emschema.log.PLUGINPURGE
em_repos_pluginpurge.logrcu.log

B.1.2.2.2 EMPrereqKitログ

EMPrereqKitの場合、ログは<oraInventoryLoc>/logs/にあります。

前提条件コンポーネントの場所ごとの前提条件の実行詳細は、次の場所にあります。

<oraInventoryLoc>/logs/emdbprereqs/LATEST/componentLog/<log_filename>

次に例を示します。

<oraInventoryLoc>/logs/emdbprereqs/LATEST/componentLog/repository.log

EMPrereqkitの実行詳細は、次の場所にあります。

<oraInventoryLoc>/logs/emdbprereqs/LATEST/emprereqkit.log

エラーは次の場所にあります。

<oraInventoryLoc>/logs/emdbprereqs/LATEST/emprereqkit.err

B.1.2.2.3 MDSスキーマ操作ログ

MDSスキーマ作成ログ

MDSスキーマ作成操作では、OMSのOracleホーム内に次のログが作成されます。

$<ORACLE_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

詳細は、OMSのOracleホームから次のログを参照してください。

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/mds.log

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/rcu.log

MDSスキーマ削除ログ

MDSスキーマ削除操作では、MDSスキーマ削除コマンドの起動中に-logDir引数を使用して指定した場所に次のログが作成されます。

$<user_specified_location>/mds.log

$<user_specified_location>/emmdsdrop_<timestamp>.log

ただし、MDSスキーマ削除コマンドの起動中にカスタムの場所を指定しなかった場合、ログはOMSのOracleホーム内に作成されます。たとえば、/scratch/OracleHomes/oms12c/mds.logおよび/scratch/OracleHomes/oms12c/emmdsdrop_<timestamp>.logとなります。

B.1.2.3 セキュア・ログ

OMSの場合、次のセキュア・ログがOMSインスタンス・ベースの場所に作成されます。ここで、<oms_name>はたとえばEMGC_OMS1のようになります。

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/secure.log

管理エージェントの場合、次のセキュア・ログが管理エージェントのOracleホーム内に作成されます。

<Agent_Instance_Home/sysman/log/secure.log

B.1.2.4 Oracle Management Serviceログ

OMSの実行に関する情報が記録された次のログ・ファイルが、OMSインスタンス・ベースの場所に作成されます。ここで、<oms_name>はたとえばEMGC_OMS1のようになります。

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/emoms.trc

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/emoms.log

B.2 ホストの追加ログ・ファイル

この項では、次のホストの追加ログ・ファイルの場所について説明します。

- 初期化ログ

- アプリケーション前提条件ログ

- システム前提条件ログ

- エージェントのインストール・ログ

- ホストの追加のその他のログ

B.2.1 初期化ログ

表B-2に、リモート・ホストとその場所の初期化ログを一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表B-2 初期化ログ

ログ・ファイル

場所

<hostname>_deploy.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/applogs

B.2.2 アプリケーション前提条件ログ

表B-3に、アプリケーションの前提条件ログとその場所を一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。また、この表に示されている<install_type>は表B-4に示すインストール・タイプの1つです。

表B-3 前提条件ログ

ログ・ファイル

場所

prereq<time_stamp>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/<install_type>_logs/<hostname>/

prereq<time_stamp>.out

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/<install_type>_logs/<hostname>/

prereq<time_stamp>.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/<install_type>_logs/<hostname>/

表B-4 インストール・タイプ

インストール・タイプ

説明

ターゲット・オペレーティング・システム・タイプ

emagent_install

新規エージェント・インストール

UNIX

emagent_clone

エージェントのクローニング

UNIX

nfs_install

共有エージェントのインストール

UNIX

B.2.3 システム前提条件ログ

表B-5に、システム前提条件ログとその場所を一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表B-5 システム前提条件ログ

ログ・ファイル

場所

prereq<time_stamp>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/productprereq_logs/<hostname>/

prereq<time_stamp>.out

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/productprereq_logs/<hostname>/

prereq<time_stamp>.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/productprereq_logs/<hostname>/

B.2.4 エージェントのインストール・ログ

表B-6に、エージェントのインストール・ログとその場所を一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表B-6 エージェントのインストール・ログ

ログ・ファイル

場所

説明

install.log/.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/logs/<hostname>

新規およびクローニングされたエージェントのインストール・ログ

nfs_install.log/.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/logs/<hostname>

共有エージェントのインストール・ログ

cfgfw/*.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/cfgtoollogs/<hostname>

エージェントの構成ログ

B.2.5 ホストの追加のその他のログ

表B-7に、ホストの追加・ウィザードを使用してエージェントをインストールする間に作成されるその他すべてのインストール・ログを一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表B-7 ホストの追加のその他のログ

ログ

場所

説明

EMAgentPushLogger<TIMESTAMP>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/logs/

エージェント・デプロイ・アプリケーションのログ

remoteInterfaces<TIMESTAMP>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/logs/

リモート・インタフェース・レイヤーのログ

deployfwk.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/applogs/

ホストの追加デプロイメント・フレームワークのログ

ui.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/applogs/

ホストの追加ユーザー・インタフェースのログ

B.3 手動の管理エージェント・インストール・ログ

表B-8は、管理エージェントが手動でインストールされた(サイレント・モード)ときに作成されたインストール・ログの一覧です。この表に記載の<ORACLE_HOME>は、ターゲットの管理エージェントのOracleホーム、<AGENT_BASE_DIR>/core/12.1.0.4.0/を示しています。

表B-8 手動の管理エージェント・インストール・ログ

ログ

場所

説明

agentDeploy<TIMESTAMP>.log

<ORACLE_HOME>/cfgtoollogs/agentDeploy/

インストール・ログ

prereq<TIMESTAMP>.log

<ORACLE_HOME>/cfgtoollogs/agentDeploy/

インストール前提条件ログ

CfmLogger<TIMESTAMP>.log

<ORACLE_HOME>/cfgtoollogs/cfgfw/

構成ログ

AttachHome<TIMESTAMP>.log

<ORACLE_HOME>/cfgtoollogs/agentDeploy/

ホームのアタッチ・ログ

UpdateHomeDeps<TIMESTAMP>.log

<ORACLE_HOME>/cfgtoollogs/agentDeploy/

ホームの更新ログ

cloneActions<TIMESTAMP>.log

<ORACLE_HOME>/cfgtoollogs/agentDeploy/

クローン・アクション・ログ

B.4 追加のOMSインストール・ログ

表B-9は、OMSの追加が失敗した際に表示されるインストール・ログの一覧です。

注意:

- ORACLE_HOMEは、新規追加OMSのホームです。ただし、管理ログの場合、ORACLE_HOMEはプライマリOMSのホームです。

- INSTANCE_HOMEとは、OMSインスタンス・ディレクトリのことです(デフォルトでミドルウェア・ホームの親ディレクトリの下にあるgc_inst)。

表B-9 追加のOMSインストール・ログ

ログ

場所

omsca障害

$ORACLE_HOME/cfgtoollogs/omsca

プラグイン障害

$ORACLE_HOME/cfgtoollogs/pluginca

管理対象サーバーログ

- emLogs (emomsログ)

- msLogs (管理対象サーバー・ログ: サーバーの起動失敗の場合)

- nmLogs

$ORACLE_HOME/cfgtoollogs/omsca/log_<timestamp>/

管理ログ

$INSTANCE_HOME/user_projects/domains/GCDomain/servers/EMGC_ADMINSERVER/logs

(メモリー不足エラーまたは領域の問題が発生した場合、プライマリOMSにログオンします)

デプロイメント・プロシージャ出力

デプロイメント・プロシージャのスクリーンショット

クローン・ログ

$ORACLE_HOME/cfgtoollogs/clone

C Oracle Management Agentの別のOracle Management Serviceへのリダイレクト

この付録では、すでにOracle Management Service (OMS)と通信しているOracle Management Agent (管理エージェント)を、異なるEnterprise Manager Cloud Control (Cloud Control)のデプロイメントの一部である別のOMSにデータを通信またはアップロードするために、リダイレクトまたは再指定する方法を説明します。

注意:

- 別のCloud Controlデプロイメントの一部である別のOMSへの管理エージェントのリダイレクトは、新規にデプロイされ初期バージョンからアップグレードされていない管理エージェントの場合にのみサポートされています。初期バージョンからアップグレードされた管理エージェントはリダイレクトできません。

- 異なるCloud Controlデプロイメントの一部である別のOMSに管理エージェントをリダイレクトすると、ユーザー定義のメトリック収集やemd.propertiesファイルに加えられた変更などのエージェント・インスタンス・ホームへのすべての変更が失われます。

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

- 管理エージェントを別のOMSにリダイレクトするための前提条件

- 別のOMSへの管理エージェントのリダイレクト

C.1 管理エージェントを別のOMSにリダイレクトするための前提条件

管理エージェントをリダイレクトまたは再指定する前に、次の前提条件を満たしていることを確認してください。

- 管理エージェントを指定する新しいOMSが管理エージェントと同じまたはそれ以上のバージョンであることを確認します。
再指定する管理エージェントのバージョンを確認するには、「設定」メニューから「Cloud Controlの管理」を選択し、「エージェント」を選択します。管理エージェントの名前をクリックします。管理エージェントのバージョンが「サマリー」セクションに表示されます。

新しいOMSのバージョンを確認するには、「設定」メニューから、「Cloud Controlの管理」、「管理サービス」の順に選択します。新しいOMSの名前をクリックします。OMSのバージョンが「サマリー」セクションに表示されます。

新しいOMSが管理エージェントと互換性のある場合にのみ、管理エージェントを再指定できます。Enterprise Managerの動作保証マトリックスを使用すると、OMSのバージョンと管理エージェントのバージョンとの互換性を確認できます。このマトリックスのアクセス方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 管理エージェントで指定していた以前のOMSと、管理エージェントで指定しようとしている新しいOMSには、同じセットのプラグインがデプロイされており、管理エージェントに設定されているすべてのプラグインが新しいOMSにデプロイされていることを確認します。また、新しいOMSにデプロイされたこれらすべてのプラグインが同じバージョン(管理エージェントまたは以前のOMSで設定されたバージョン)か、それ以上のバージョンであることも確認します。
特定のOMSにデプロイされたプラグインの一覧を確認するには、Enterprise Managerシステムにログインし、「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

特定の管理エージェント上で設定されたプラグインの一覧を表示するには、次のコマンドを実行します。

$<AGENT_INSTANCE_HOME>/bin/emctl listplugins agent -type all

- リダイレクトする管理エージェントが稼働中であることを確認してから、次のコマンドを実行してplugins.txtファイルを再作成します。
$AGENT_HOME/perl/bin/perl $AGENT_HOME/sysman/install/create_plugin_list.pl -instancehome <AGENT_INSTANCE_HOME>

注意:
デフォルトでは、Perlインストールの場所はcreate_plugin_list.plで/usr/local/binとして指定されています。別の場所にある管理エージェントにPerlがインストールされている場合は必ず、create_plugin_list.plの最初の行を編集し、Perlがインストールされている場所を指定してください。

- ターゲット・タイプまたはコレクション・メタデータを変更する、管理エージェントに適用されたすべてのパッチも、管理エージェントで指定する新しいOMSに適用されます。
管理エージェントに適用されているすべてのパッチを確認するには、「ターゲット」メニューから「すべてのターゲット」を選択します。管理エージェントのOracleホーム・ターゲットの名前をクリックします。管理エージェントに適用されたすべてのパッチが「適用済パッチ」セクションに表示されます。

表示されたパッチの一覧から必要なパッチ(ターゲット・タイプまたはコレクション・メタデータを変更するパッチ)を新しいOMSに適用します。OMSへのパッチ適用方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「Enterprise Managerのパッチ適用」の章を参照してください。

- 再指定する管理エージェントに個別パッチを適用している場合には、必ず管理エージェントおよび新しいOMSにバグ15904425の修正を適用してください。

C.2 別のOMSへの管理エージェントのリダイレクト

管理エージェントをリダイレクトまたは再指定するには、次の手順を実行します。

1. 次のコマンドを実行し、管理エージェントを停止します。
$<AGENT_INSTANCE_HOME>/bin/emctl stop agent

2. 次のEM CLIコマンドを実行し、古いOMS上の管理エージェント・ターゲットを削除します。
$<OMS_HOME>/bin/emcli delete_target -delete_monitored_targets -name=<name_of_agent_target> -type="oracle_emd"

delete_target EMCLIコマンドの詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。

3. 次のコマンドを実行し、管理エージェントのインスタンス・ホームを削除します。
rm -rf <absolute_path_to_agent_instance_home>

エージェント・ベース・ディレクトリおよびエージェント・インスタンス・ホームが同じ物理的場所を指している場合には、このコマンドは実行しないでください。かわりに、<AGENT_INSTANCE_HOME>/bin, <AGENT_INSTANCE_HOME>/sysman, <AGENT_INSTANCE_HOME>/diag,および<AGENT_INSTANCE_HOME>/installディレクトリを削除してください。

4. 管理エージェントに対する新しいインスタンス・ホームを作成して新しいOMSにリダイレクトするには、-configOnlyオプションとともにagentDeploy.sh (Microsoft WindowsホストではagentDeploy.bat)スクリプトを実行します。
$<AGENT_BASE_DIR>/core/12.1.0.4.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agent_base_dir> AGENT_INSTANCE_HOME=<absolute_path_to_agent_base_dir>/agent_inst AGENT_PORT=<port_for_agent_process> OMS_HOST=<new_oms_host_name> EM_UPLOAD_PORT=<upload_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password> b_upgrade=false b_12cupgrade=false b_agentUpgrade=false b_noUpgrade=true -configOnly

agentDeploy.shまたはagentDeploy.batの実行時に指定できるパラメータの詳細は、表6-3を参照してください。-configOnlyオプションの詳細は、表 6-6を参照してください。

注意:
指定したエージェント・ベース・ディレクトリ位置および新しいエージェント・インスタンス・ホーム位置は、管理エージェントがすでに構成されているホストと同じホスト上にマップされます。当然、OMSホスト名は、新しいOMS(今回通信する管理エージェント)が構成されている他のホストにマップされます。

D Oracle Management Agentのデプロイまたはアップグレード中のパッチの適用

Enterprise Manager Cloud Control 12cリリース4 (12.1.0.4.0)では、管理エージェント・バイナリを管理エージェント・パッチおよびプラグイン・パッチと組み合せることができるため、管理エージェントをデプロイまたはアップグレードするたびにこれらのパッチを適用する必要がありません。管理エージェント・ソフトウェアの特定のバージョンに適用する管理エージェント個別パッチは、同じバージョンの新しい管理エージェントがデプロイされるとき、または古い管理エージェントがそのバージョンにアップグレードされるときに常にこれらのパッチが自動的にソフトウェアに割り当てられるように保存できます。これは一度の操作のため、管理エージェントをデプロイまたはアップグレードするたびにこの処理を行う必要はありません。

管理エージェント個別パッチをこの付録で説明したようにOMSホストに保存した場合、管理エージェントのデプロイまたはアップグレード処理は、管理エージェントのそれぞれのバージョンおよびプラットフォームに対してこれらのパッチを自動的に選択します。そのため、この機能を利用することにより時間と労力を大幅に節約できます。

プラグインにパッチを適用する方法、ならびに新規にデプロイするすべての管理エージェントおよびアップグレードするすべての旧管理エージェントにパッチ適用済プラグインがデプロイされることを確認する方法の詳細は、Oracle Enterprise Manager Cloud Controlの管理ガイドを参照してください。

管理エージェントに適用するパッチおよびプラグインが管理エージェントのデプロイまたはアップグレード後に自動的に適用されるようにするには、管理エージェントのデプロイまたはセッションのアップグレードを計画する前に、必ずこの付録および前の段落で参照された項に記載の手順に従ってください。

内容は次のとおりです。

- 管理エージェント・パッチのOMSホストへの保存

- 管理エージェントのデプロイまたはアップグレード後のパッチ適用の検証

D.1 管理エージェント・パッチのOMSホストへの保存

管理エージェント個別パッチを、新規の管理エージェントがデプロイされたときまたは管理エージェントがアップグレードされたときに常に適用されるように、OMSホストに保存するには、次の手順を実行します。

1. 次のURLで利用できるMy Oracle Supportから必要な管理エージェント個別パッチをダウンロードします。
https://support.oracle.com/

ダウンロードしたパッチzipファイルのサイズがMy Oracle Supportページに表示されているサイズと同じであることを確認します。

My Oracle Supportからパッチをダウンロードする方法の詳細は、『Oracle Enterprise Managerライフサイクル管理者ガイド』を参照してください。

2. OMSホストに次のディレクトリを作成し、そこにすべての汎用管理エージェント個別パッチを転送します。
$<OMS_HOME>/install/oneoffs/<agent_version>/Generic/

ここで、<agent_version>はパッチが適用される管理エージェントのバージョンです。このディレクトリの作成中、必ず5桁の管理エージェントのバージョンを使用してください。

たとえば、12.1.0.4.0管理エージェントをデプロイするとき、または旧管理エージェントを12.1.0.4.0にアップグレードするときには常に、12.1.0.4.0管理エージェント用の汎用管理エージェント個別パッチであるパッチ11180406を適用する場合、My Oracle Supportからこのパッチをダウンロードし、次のディレクトリを作成し、そこにパッチを転送します。

$<OMS_HOME>/install/oneoffs/12.1.0.4.0/Generic/

3. OMSホストに次のディレクトリを作成し、それらにすべてのプラットフォーム固有の管理エージェント個別パッチを転送します。
$<OMS_HOME>/install/oneoffs/<agent_version>/<platform>/

ここで、<agent_version>はパッチが適用される管理エージェントのバージョンです。これらのディレクトリの作成中、必ず5桁の管理エージェントのバージョンを使用してください。

<platform>はプラットフォームのディレクトリ名で、パッチ・プラットフォームにより異なります。表D-1は、様々なパッチ・プラットフォーム用に作成する必要のあるプラットフォーム・ディレクトリの一覧を示しています。

表D-1 プラットフォーム固有の管理エージェント・パッチ転送用のプラットフォーム・ディレクトリ名

パッチ・プラットフォーム

プラットフォーム・ディレクトリ名

Linux x86

linux

Linux x86-64

linux_x64

Oracle Solaris on SPARC (64ビット)

solaris

Oracle Solaris on x86-64 (64ビット)

solaris_x64

HP-UX PA-RISC (64ビット)

hpunix

HP-UX Itanium

hpi

IBM S/390ベースLinux (31ビット)

linux_zseries64

POWER Systems (64ビット)上のIBM AIX

aix

IBM: POWER Systems上のLinux

linux_ppc64

Microsoft Windows x64 (64ビット)

windows_x64

Microsoft Windows (32ビット)

win32

注意:
複数OMS環境の場合、必ずすべてのOMSホストに対してこれらの手順を実行します。すべてのOMSホストの同じディレクトリに同じパッチをダウンロードおよび転送してください。そうしないと、不整合や予期しないエラーが発生する場合があります。

たとえば、パッチ11878907 (12.1.0.4.0 Linux x86-64管理エージェント用)およびパッチ11993577 (12.1.0.4.0 Microsoft Windows x64管理エージェント用)を、これらの管理エージェントをデプロイするとき、またはこれらの管理エージェントを12.1.0.4.0にアップグレードするときに常に適用する場合には、My Oracle Supportからこれらのパッチをダウンロードし、次のディレクトリを作成し、それらにパッチを転送します。

パッチ11878907

$<OMS_HOME>/install/oneoffs/12.1.0.4.0/linux_x64/

パッチ11993577

$<OMS_HOME>/install/oneoffs/12.1.0.4.0/windows_x64/

D.2 管理エージェントのデプロイまたはアップグレード後のパッチ適用の検証

OMSホストに保存した管理エージェント個別パッチ(第D.1項で説明)がデプロイまたはアップグレードした管理エージェントに適用されたかどうかを検証するには、次の方法を使用できます。

- 管理エージェント・ホームから次のコマンドを実行します。
$<AGENT_HOME>/OPatch/opatch lsinventory -oh <AGENT_HOME> -invPtrLoc <AGENT_HOME>/oraInst.loc

このコマンドにより、管理エージェントに適用されたすべてのパッチが表示されます。

- Cloud Controlコンソールで、「設定」メニューから「Cloud Controlの管理」を選択し、「エージェント」を選択します。目的の管理エージェント名をクリックしてそのホームページに移動します。「構成」セクションで「Oracleホームとパッチの詳細」をクリックします。管理エージェントに適用されたパッチが「パッチ適用」セクションに表示されます。

E RepManagerユーティリティの使用

この付録では、RepManagerユーティリティについて説明します。特に、次の内容について説明します。

- RepManagerユーティリティの概要

- RepManagerユーティリティでサポートされる操作およびコマンド

E.1 RepManagerユーティリティの概要

RepManagerは、Oracle Management Repositoryのアップグレードおよび削除、プラグインの選択的なパージ、ならびにdlfメッセージのOracle Management Repositoryへのロードを行うユーティリティです。このユーティリティは、Oracle Management Service (OMS)のホーム内にあります。

UNIXオペレーティング・システムの場合:

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager

Microsoft Windowsオペレーティング・システムの場合:

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager.bat

このユーティリティは、完全なEnterprise Managerシステムのインストール中にリポジトリ・コンフィギュレーション・アシスタントによって、またEnterprise Manager Cloud Controlのアップグレード中にリポジトリ・アップグレード・コンフィギュレーション・アシスタントによって起動されます。

注意:
Enterprise Managerスキーマを完全に削除する場合は、OMSホームにあるRepManagerを使用します。データベース・ホーム内のものは、Enterprise Managerスキーマを完全には削除できないため、使用しないでください。

E.2 RepManagerユーティリティでサポートされる操作およびコマンド

表E-1に、RepManagerユーティリティでサポートされる操作およびそれに関連付けられたコマンドを一覧表示します。

警告:

削除モードのRepManagerは、"ALTER SYSTEM QUIESCE RESTRICTED;"コマンドによりデータベースを静止モードにします。

表E-1 RepManagerでサポートされる操作およびコマンド

操作

コマンド

説明

例

preupgrade

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action preupgrade <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman [-mwHome <Middleware home>] -pluginDepList "<pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>" -runAsReposUser <TRUE/FALSE> -dlfSources "<oms home>,<plugin1 home>,<plugin2home>"

この操作では、次のパラメータを指定してOracle Management Repositoryをアップグレードする前の手順を実行します。

- Oracle Management RepositoryリポジトリがアップグレードされるOracle RDBMSに接続するためのホスト、ポートおよびSIDを指定します。

- データベースのユーザーとパスワード、リポジトリ名(SYSMAN)とSYSMANユーザーのパスワード、およびOracle Management Repositoryをアップグレードするミドルウェア・ホームを指定します。

- 依存性に準じて、デプロイするプラグインのリストをカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラグインIDのリストです。-pluginDepListパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、プラグイン依存リストを取得するためデフォルトで次のものが読み取られます。
$<OMS_HOME>/sysman/admin/emdrep/plugininfo/pluginDepList

- プラグインをデプロイできる方法に応じて、SYSとしてデプロイするか、SYSMAN(リポジトリ・ユーザー)としてデプロイするかを指定します。SYSMANとしてデプロイするには、-runAsReposUserパラメータをTRUEに設定します。このパラメータを渡さない場合には、プラグインはデフォルトでSYSユーザーとしてデプロイされます。

- プラットフォーム/プラグインのDLFファイルの場所をカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラットフォーム/プラグインのDLFファイルの場所です。-dlfSourcesパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、dlfリソースの場所を取得するためデフォルトで次のものが読み取られます。
$<OMS_HOME>/sysman/admin/emdrep/plugininfo/dlfSources

このオプションが欠落しているかデフォルトのdlfSourcesファイルが存在しない場合、プラットフォームのdlfファイルのみが取得されます。デフォルトのdlfSourcesファイルが存在する場合、これらのソースの下のDLFのみが取得されます。

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action preupgrade example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -mwHome /scratch/weblogic/middleware -pluginDepList <pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>

upgrade

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action upgrade <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman [-mwHome <Middleware home>]-pluginDepList "<pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>" -runAsReposUser <TRUE/FALSE> -dlfSources "<oms home>,<plugin1 home>,<plugin2home>"

注意: アップグレード操作を実行する前にアップグレード前の操作を実行してください。

この操作では、次のパラメータを指定してOracle Management Repositoryをアップグレードします。

- Oracle Management RepositoryリポジトリがアップグレードされるOracle RDBMSに接続するためのホスト、ポートおよびSIDを指定します。

- データベースのユーザーとパスワード、リポジトリ名(SYSMAN)とSYSMANユーザーのパスワード、およびOracle Management Repositoryをアップグレードするミドルウェア・ホームを指定します。

- 依存性に準じて、デプロイするプラグインのリストをカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラグインIDのリストです。-pluginDepListパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、プラグイン依存リストを取得するためデフォルトで次のものが読み取られます。
$<OMS_HOME>/sysman/admin/emdrep/plugininfo/pluginDepList

- プラグインをデプロイできる方法に応じて、SYSとしてデプロイするか、SYSMAN(リポジトリ・ユーザー)としてデプロイするかを指定します。SYSMANとしてデプロイするには、-runAsReposUserパラメータをTRUEに設定します。このパラメータを渡さない場合、プラグインはデフォルトでSYSユーザーとしてデプロイされます。

- プラットフォーム/プラグインのDLFファイルの場所をカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラットフォーム/プラグインのDLFファイルの場所です。-dlfSourcesパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、dlfリソースの場所を取得するためデフォルトで次のものが読み取られます。
$<OMS_HOME>/sysman/admin/emdrep/plugininfo/dlfSources

このオプションが欠落しているかデフォルトのdlfSourcesファイルが存在しない場合、プラットフォームのdlfファイルのみが取得されます。デフォルトのdlfSourcesファイルが存在する場合、これらのソースの下のDLFのみが取得されます。

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action upgrade example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -mwHome /scratch/weblogic/middleware -pluginDepList <pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>

transX

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action transx <repository_database_host> <repository_database_port> <repository_database_sid> -reposName sysman [-mwHome <Middleware home>] -dlfSources "<oms home>,<plugin1 home>,<plugin2home>"

注意: -doTransXも実行できます。デフォルトでは、trueに設定されています。falseに設定すると、変換のバンドルがロードされません。これは、preupgradeおよびupgrade操作の-dlfSourcesに適用されます。

この操作では、次のパラメータを指定してOracle Management Repositoryに変換リソースをロードします。

- Oracle RDBMSに接続するためのホスト、ポートおよびSIDを指定し、Oracle Management Repositoryに変換リソースをロードします。

- データベースのユーザーとパスワード、リポジトリ名(SYSMAN)とSYSMANユーザーのパスワード、およびOracle Management Repositoryに変換リソースをロードするためのミドルウェア・ホームを指定します。

- プラットフォーム/プラグインのDLFファイルの場所をカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラットフォーム/プラグインのDLFファイルの場所です。-dlfSourcesパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、dlfリソースの場所を取得するためデフォルトで次のものが読み取られます。
$<OMS_HOME>/sysman/admin/emdrep/plugininfo/dlfSources

このオプションが欠落しているかデフォルトのdlfSourcesファイルが存在しない場合、プラットフォームのdlfファイルのみが取得されます。デフォルトのdlfSourcesファイルが存在する場合、これらのソースの下のDLFのみが取得されます。

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action transx example.com 1521 db3 -reposName sysman -mwHome /scratch/WLS/middleware

resume

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -resume retry <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman [-mwHome <Middleware home>] -checkpointLocation <directory where schemamanager stores checkpoints>

この操作では、最後に失敗した操作(たとえば、upgradeなど)を再開します。

- 操作を再開するOracle RDBMSに接続するためのホスト、ポートおよびSIDを指定します。

- データベースのユーザーとパスワード、リポジトリ名(SYSMAN)とSYSMANユーザーのパスワード、および操作が再開されるミドルウェア・ホームを指定します。

- 手順を再開する場所を指定します。チェックポイントの場所は、$<OMS_HOME>/sysman/log/schemamanagerです。

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -resume retry -checkpointLocation /scratch/weblogic/middleware/oms/sysman/log/schemamanager -mwHome /scratch/weblogic/middleware

drop

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action drop <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman [-mwHome <Middleware home>] [-mwOraHome <Oracle Home>]

または

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action drop <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman [-mwHome <Middleware home>] [-mwOraHome <Oracle Home>]

SYSMAN、SYSMAN_MDS、SYSMAN_OPSSおよびSYSMAN_APMに実行中のアクティブなセッション、スケジューラ・ジョブおよびdbms_jobsがないことを確認します。これらのユーザーがログインしていないことを確認します。これを確認するには、すべてのOMSインスタンスでコマンドemctl stop oms -allを使用して、OMSを停止します。

注意: BI Pubilsher (BIP)がインストールされ構成済の場合、このコマンドを実行する前に管理サーバーを使用してBIPを停止する必要があります。

この操作では、次のようにすべてのEnterprise Managerリポジトリを削除します。

- すべてのスキーマが削除されるOracle RDBMSに接続するためのホスト、ポートおよびSIDを指定します。

- データベースのユーザーとパスワード、リポジトリ名(SYSMAN)とSYSMANユーザーのパスワード、およびミドルウェア・ホームを指定します。

最後に、この操作のステータスを確認する確認メッセージが表示されます。すべてのスキーマが正常に削除されると、同様の確認メッセージが表示されます。そうでない場合は、各スキーマの詳細を示すメッセージが表示されます。

次に例を示します。

SYSMAN_OPSS schema is not cleaned.
EM_X synonyms are not dropped.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action drop -mwHome /scratch/weblogic/middleware

または

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action drop -mwHome /scratch/weblogic/middleware -mwOraHome /scratch/weblogic/middleware

pluginpurge

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager -action pluginpurge <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -pluginPurgeList "<plugin_name>=<plugin_location>" [-mwHome <Middleware home>] -mwOraHome <Oracle Home>

注意: 複数のプラグインをパージするには、-pluginPurgeList引数で、プラグインをカンマで区切って入力します。たとえば、<pluginid1>=<pluginid1 home>, <pluginid2>=<pluginid2 home>となります。

この操作では、次のようにリポジトリからプラグインを削除します。

- プラグインが削除されるOracle RDBMSに接続するためのホスト、ポートおよびSIDを指定します。

- EM-EXTモデルを持つEnterprise Managerリポジトリからパージされるプラグイン・リストをカンマで区切って指定します。

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action pluginpurge -pluginPurgeList "oracle.sysman.myyempwpax.oms.plugin_12.1.0.2.0=/scratch/weblogic/middleware/plugins/oracle.sysman.myyempwpax.oms.plugin_12.1.0.2.0" -mwHome /scratch/weblogic/middleware

注意:
-action dropおよび-action dropallコマンドのサポートの詳細は、表2-3を参照してください。

注意:
RepManager操作でパスワードを指定しない場合、パスワードの指定を求めるプロンプトが表示されます。

F Oracle Harvesterを使用したOCMデータの収集

この付録では、Oracle Harvesterを使用してMy Oracle Support (MOS)に送信するOracle Configuration Manager (OCM)データを収集するための情報を提供します。

My Oracle Supportでは、カスタマによるOracleサポートの利用を大幅に促進する一連の機能が提供されています。My Oracle Supportでは、カスタマの構成固有のコンテキスト内情報の他、予防的なサポートも提供することで、サービス・リクエストの発行プロセスを合理化しています。My Oracle Supportのこれらの機能を有効にするには、カスタマの構成情報をOracleにアップロードする必要があります。構成データが定期的にアップロードされると、カスタマ・サポート担当者はこのデータを分析してカスタマによりよいサービスを提供できます。

構成データを収集し、Oracleにアップロードするために、次のメカニズムが提供されています。

- Oracle Enterprise Manager Harvester (Oracle Harvester)

- Oracle Configuration Manager (OCM)

詳細は次のとおりです。

- Oracle Configuration Managerは、Oracle製品のインストール時に自動的にインストールおよび構成されます。
各製品をインストールする際、最初の画面でMy Oracle Supportの資格証明が求められます。これは、インストールにおいてきわめて重要な画面です。指定するユーザー名とパスワードは、構成データがOracleにアップロードされる際に使用される資格証明になります。

- 24時間ごとに構成の収集が実行され、構成データがアップロードされます。

- データがアップロードされた後は、製品のインストール時に指定した資格証明を使用して、My Oracle Support (https://support.oracle.com)にログインしデータを参照できます。

注意: Enterprise Managerを使用してアプリケーションを管理している場合、構成のOracleへのアップロードには、Oracle Harvesterを使用することをお薦めします。それ以外の場合は、OCMを使用してください。

次の項では、次のトピックの情報を提供します。

- Oracle Harvester

- Oracle Configuration Manager

- MOSおよびOCMの追加情報

- 構成データ収集ツールのトラブルシューティング

F.1 Oracle Harvester

Oracle Harvesterでは、Enterprise Managerによって管理されているターゲットのデータのみが収集されます。Oracle Harvesterは同じOCM依存性のため、Oracle Harvesterを使用すると、Enterprise Managerの収集メソッドを利用してターゲットの構成データを収集できます。このため、Oracle Harvesterが管理するターゲットのホームにOCMをインストールする必要がありません。次の項目について説明します。

- Oracle Harvesterの特徴

- Oracle HarvesterとOCM

- Enterprise Managerリリース12.1のサポート

- Enterprise ManagerでのCSIの表示

- Enterprise ManagerからのHarvesterターゲット・ライフサイクル・プロパティ

- ハーベスタ・ジョブ・ステータス・メトリック

- Oracle Harvesterでサポートされているターゲット

- My Oracle Supportで使用できない構成データ

F.1.1 Oracle Harvesterの特徴

Oracle Harvesterの特徴は次のとおりです。

- すべてのターゲットのデータは、Oracle Management Service (OMS)ホームのOCMが構成されている資格証明と同じ資格証明に対してデフォルトでアップロードされます。Enterprise Manager Cloud Control 12cで、CSI割当てページからCSIを割り当てて、ターゲットのこのデフォルト値を変更できます。「設定」、「My Oracle Support」の順にクリックして開始します。

- Enterprise ManagerのOMSホームでOCMが構成済で実行中である必要があります。

- 管理リポジトリからターゲットの構成データを収集します。

- 定期的に自動実行されるため、ユーザーが操作する必要はありません。

F.1.2 Oracle HarvesterとOCM

Enterprise Managerのインストール時、Oracle HarvesterおよびOracle Configuration Manager (OCM)が、必要なサブコンポーネントと同じく自動的にインストールされます。Oracle Harvesterは、OMSホームのOCMが構成および実行されているかぎり実行されます。

OCMがOMSのOracleホームで有効化され、OMSのインスタンス・ホームで構成(および接続モードで実行)されている必要があります。これはORACLE_CONFIG_HOMEが設定されていない場合、Oracle OMSターゲットがOCMコレクタによって検出されないためです。

次の手順を実行して、Oracle OMSターゲットが検出されるようにします。

1. OMSインスタンス・ホームを探します。
$ORACLE_HOME/sysman/config/emInstanceMapping.propertiesファイル(ここでのORACLE_HOMEはOMSのOracleホームです)に、emgc.propertiesという名前のファイルを参照するエントリがあります。

emgc.propertiesファイルが存在するディレクトリは、OMSのインスタンス・ホームです。次の例では、/u01/app/oracle/product/gc_inst/em/EMGC_OMS1がOMSのインスタンス・ホームです。

EMGC_OMS1=/u01/app/oracle/product/gc_inst/em/EMGC_OMS1/emgc.properties

2. 環境変数ORACLE_CONFIG_HOMEをこのemgc.propertiesファイルのディレクトリに設定します。
例:

$export ORACLE_CONFIG_HOME=/u01/app/oracle/product/gc_inst/em/EMGC_OMS1

3. Enterprise Managerのインストール時にMy Oracle Supportの資格証明が指定されなかった場合、次のコマンドを実行して設定します。

setupCCR

プロンプトでMy Oracle Support資格証明を指定します。

Oracle Configuration Manager (OCM)の詳細は、『Oracle® Configuration Managerインストレーションおよび管理ガイド』を参照してください。

http://docs.oracle.com/cd/E49269_01/doc.12/e48361/toc.htm

または、OCMドキュメント・ライブラリを参照します。

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

F.1.3 Enterprise Managerリリース12.1のサポート

デフォルトでは、すべてのターゲットが、OMSホームのOracle Configuration Managerの登録に使用した資格証明を使用してアップロードされます。Enterprise Managerリリース12.1では、各ターゲット・ホームにカスタマ・サポートID (CSI)を割り当てるオプションがあります。

Oracle Harvesterは、各Oracleホームのそれぞれ異なるCSIへの構成データのアップロードをサポートしています。

手順は次のとおりです。

1. Oracle Harvesterが実行されていることを確認します。このジョブは自動的に実行されます。実行のステータスは、「サポートID割当て」ページから監視できます。Enterprise Managerのホームページからこのページにアクセスするには、「設定」を選択し、次に「My Oracle Support」を選択します。メニューから「サポートID割当て」を選択します。

2. My Oracle Supportの優先資格証明を設定します。Enterprise Managerのホームページで「設定」を選択し、次に「My Oracle Support」を選択します。メニューから「資格証明の設定」を選択し、有効なMy Oracle Supportの資格証明を指定します。

3. サポートIDを割り当てます。

1. Enterprise Managerのホームページで「設定」を選択し、次に「My Oracle Support」を選択します。「サポートID割当て」を選択し、正しいユーザー名とパスワードを指定します。「資格証明の設定」を選択します。

2. 「ホーム」を選択します。「割当て」ボタンをクリックします。「CSI」を選択し、「OK」をクリックします。

4. 割当てが成功したことを示すメッセージが表示されることを確認します。メッセージは次のとおりです。

Support Identifier has been assigned for 1 Oracle homes. The changes in the Customer Support Identifiers will be reflected in My Oracle Support after the next Harvester run.

F.1.4 Enterprise ManagerでのCSIの表示

ターゲットに関連付けられているCSIを確認するには、ターゲットのプロパティを表示するか、または検索条件にCSIを設定して構成検索を行います。特定のOracleホームのすべてのターゲットに対してオペレータ権限を持つユーザーは、そのOracleホームに対するCSIを割り当てることができます。

詳細は、Enterprise Managerインタフェース上のヘルプを参照してください。

F.1.5 Enterprise ManagerからのHarvesterターゲット・ライフサイクル・プロパティ

Oracle Harvesterには、たとえばデプロイ、テストなどのターゲットの目的を識別できるターゲット・ライフサイクル・プロパティが用意されています。

一度定義されると、Oracle Harvesterはすべてのターゲットに対するターゲット・ライフサイクル・プロパティを収集し、そのプロパティをOracle Configuration Managerサーバーにアップロードします。

ターゲット・ライフサイクル・プロパティは、Enterprise ManagerのUIまたはMy Oracle SupportのUIのいずれかの任意のターゲットに割り当てることができます。

ターゲットのライフサイクル・プロパティの可能な値は、次のとおりです。

- Mission Critical

- Production

- Stage

- Test

- Development

F.1.6 ハーベスタ・ジョブ・ステータス・メトリック

Enterprise Manager Cloud Control 12cリリース12.1.0.3およびOCM 10.3.8.1.0から、OMSおよびリポジトリのターゲットにハーベスタ・ジョブ・ステータス・メトリックが追加されました。このメトリックでは、ハーベスタのジョブに関連する情報が提供されます。このメトリックの一部として次の情報が収集されます。

- ハーベスタ・ステータス: 最後に実行したハーベスタ・ジョブのステータスが示されます。可能な値は次のとおりです。

- SUCCESS: ジョブが正常に実行されたことを示します。

- ERROR: ジョブが失敗した場合に返されます。

- NOT CONFIGURED: OCMが構成されていないことを示します。

- NOT AUTHENTICATE: OCMは構成されていますが、認証モードではありません。

- ハーベスタ・エラー: ハーベスタ・ジョブの実行が失敗した場合にエラー・メッセージを示します。

- 最終ハーベスタ・ジョブ実行: 最後のハーベスタ・ジョブが実行された時間を示します。

- 次のハーベスタ・ジョブ実行: 次に実行するハーベスタ・ジョブの時間を示します。

- 処理されたターゲット合計数: 最後の実行の間にハーベスタ・ジョブにより処理されたターゲットの数を示します。

- 成功したターゲット合計数: 処理されたターゲット合計数からMOSに正常にアップロードされたターゲットの合計数。

- 失敗したターゲット合計数: 最終ハーベスタ・ジョブ実行の処理されたターゲット合計数のうち、MOSへのアップロードに失敗した合計数。

- OCMバージョン: Enterprise Managerで構成されたOCMのバージョンを示します。

ハーベスタのジョブ・ステータス・メトリック・データは、OMSとリポジトリのターゲット・メトリックのページにあります。ERRORしきい値はハーベスタ・ステータス・フィールドに定義されています。このフィールドの値が「ERROR」となった場合、インシデントが作成されます。これは、OMSとリポジトリのホームページおよびインシデント・マネージャのページの両方に表示されます。

F.1.7 Oracle Harvesterでサポートされているターゲット

Oracle Harvesterが実行されているEnterprise Managerのリリースに従って、様々なターゲット・タイプのセットから構成データが収集されます。表F-1に示されたターゲット・タイプの構成データのみがOracle Harvesterによって収集されます。

表F-1 Enterprise Manager 12.1リリースでサポートされているターゲット

ターゲット

プラグイン・リリース

Enterprise Managerリリース

12.1.0.1

12.1.0.2

12.1.0.3

BI

12.1.0.3

いいえ

はい

はい

ホスト

該当なし

はい

はい

はい

管理エージェント

該当なし

はい

はい

はい

管理リポジトリ

該当なし

はい

はい

はい

Oracle Application Server

すべてのバージョン

はい

はい

はい

Oracle Database

すべてのバージョン

はい

はい

はい

Oracle Database Machine

すべてのバージョン

はい

はい

はい

Oracle Exadata Storage Server

すべてのバージョン

はい

はい

はい

Oracle Exalogic

12.1.0.2

12.1.0.3

いいえ

いいえ

はい

いいえ

はい

はい

Oracle Fusion Applications

すべてのバージョン

はい

はい

はい

Oracle Fusion Middleware

すべてのバージョン

はい

はい

はい

Oracleホーム

該当なし

はい

はい

はい

構成用Oracle Identity Manager: OIF、OID、OVDおよびDIP

いいえ

はい

はい

構成用Oracle Identity Manager: OIM、OAMおよびOAAM

すべてのバージョン

はい

はい

はい

Oracle Management Service

該当なし

はい

はい

はい

Oracle SOA Suite

すべてのバージョン

はい

はい

はい

Oracle Virtual Manager

すべてのバージョン

はい

はい

はい

Oracle WebLogic Server

すべてのバージョン

はい

はい

はい

Siebel

12.1.0.3

いいえ

いいえ

はい

F.1.8 My Oracle Supportで使用できない構成データ

Enterprise Managerの以前のバージョンでは、構成データがMy Oracle Supportにすでにある場合、スタンドアロンOCMコレクタによるデータの最後のアップロードから30日経過すると、Oracle Harvester構成データがMy Oracle Supportにアップロードされていました。

この制限は、Enterprise Manager 12cではなくなりました。Enterprise Managerリリース12cで実行されているOracle Harvesterから収集されたターゲットの構成データは、スタンドアロンOCMコレクタによる最後のデータのアップロードがいつだったかに関係なく、My Oracle Supportにただちに表示されます。

F.2 Oracle Configuration Managerの構成

Oracle Configuration Managerは、Oracle製品のインストール時に自動的にインストールおよび構成されます。OCMは、製品のホームにインストールされ、そのホームにインストールされているすべてのターゲットの構成データを収集します。

OCMの設定で、My Oracle Supportのアカウントとパスワード、またはMy Oracle Supportのアカウントとカスタマ・サポートID (CSI)を指定する必要があります。構成データは、この情報を使用してアップロードされ、その後同じ資格証明を使用してMy Oracle Supportにログインすることで表示できます。

構成データのOracleへのアップロード元となるすべてのOracleホームに、OCMをインストールする必要があります。OCMは、製品のインストールの一部に含まれていますが、My Oracle Supportからダウンロードすることもできます。OCMをデータ・センター全体にデプロイする場合、一括デプロイメント・ツールの使用が便利です。OCMキットは、My Oracle Supportの「コレクタ」タブから入手できます。

OCMのインストール後、必要な追加作業はありません。デフォルトで自動更新が有効になるため、この機能を使用して、常に最新バージョンのOCMが実行されている状態を保てます。この機能は、セキュリティ上の理由などから必要に応じて無効にできます。この機能を無効にした場合、次のコマンドを実行して有効にできます。

<ocm_install_root>/ccr/bin/emCCR automatic_update on

注意: Enterprise ManagerまたはOps Centerを使用してアプリケーションを管理している場合、構成のOracleへのアップロードには、Oracle HarvesterまたはOps Center Harvesterをそれぞれ使用することをお薦めします。それ以外の場合は、OCMを使用してください。

F.3 MOSおよびOCMの追加情報

My Oracle Supportの詳細情報は、次のURLを参照してください。

https://support.oracle.com

OCMについてより詳細な情報を得るには、次の手順を実行してください。

1. My Oracle Support (https://support.oracle.com)にログインします。

2. 「コレクタ」タブにアクセスするには、「詳細」をクリックしてドロップダウン・メニューから「コレクタ」を選択します。「コレクタ」ページには役立つ情報が含まれています。

F.4 構成データ収集ツールのトラブルシューティング

Enterprise Managerリリース12.1.0.2では、emccr statusコマンドを使用して、収集データがOracleにアップロードされていることを確認します。最後にアップロードされた日付と時刻を参照してください。

注意: このemccr statusコマンドでは、収集されたデータがアップロードされたことは示されますが、Oracle Harvesterによる収集が成功しデータがアップロードされたことは確認されません。

エラー・ログの場所:

- Oracle Harvesterのエラー・ログ:

- Harvesterジョブのエラーについては、次を参照してください。

INSTANCE_HOME/sysman/log/emoms_pbs.trc

- UIエラー(CSI割当てエラーなど)の場合、次を参照してください。

INSTANCE_HOME/sysman/log/emoms.trc

次に例を示します。

/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/sysman/log/emoms.trc

- Oracle Configuration Managerログは、次の場所にあります。

ccr/hosts/<hostname>/log/collector.log

次の項では、構成データの収集に関する問題の解決方法について説明しています。

- state/upload/externaディレクトリが存在しない場合、Oracle Harvesterによる収集が失敗します。

- Oracle Configuration Managerが実行されていません。

- My Oracle Supportで使用できない構成データ

- ターゲットのサブセットしかOracle Harvesterによって収集されません。

F.4.1 state/upload/externalディレクトリが存在しない場合にOracle Harvesterによる収集が失敗する

Oracle Harvesterによる収集が次のエラーにより失敗すると、externalという名前の必須ディレクトリが存在しなくなります。

[JobWorker 75210:Thread-61] ERROR gcharvester.GcCollectionMgr initOcm.? - GC OCM
Harvester: Caught GC Harvester exception from GCInit.init(): The installed version
of Oracle Configuration Manager in the ORACLE_HOME
(/scratch/aime/work/midlwre8937/oms11g) is prior to 10.3.1. The Grid Control
Configuration harvesting requires at a minimum, 10.3.1

この問題を解決するには、externalディレクトリを作成します。

$ORACLE_INSTANCE_HOME/ccr/state/upload/external

(Oracle Bug#12795503)

F.4.2 Oracle Configuration Managerが実行されない

OCMが実行されていない場合、次のエラーが表示される場合があります。

2012-08-29 16:34:20,709 [JobWorker 97285:Thread-60] WARN
gcharvester.HarvesterJobUtils performOCMCollections.? - GC OCM Harvester: OCM was
stopped and is not running

この問題を解決するには、OCMが適切なディレクトリにインストールされ、構成されていることを確認します(emCCR statusを実行)。

具体的には、OCMがOMS Oracleホームにインストールされ、OMSインスタンス・ホームで構成(および接続モードで実行)されている必要があります。

F.4.3 My Oracle Supportで使用できない構成データ

My Oracle Supportで構成データが見つからない場合、Oracle Harvesterによる収集が実行されていない可能性があります。

この問題を解決するには、OCMが正しくインストールされ、適切なディレクトリ(emCCR statusを実行)に構成されていることを確認してください。具体的には、OCMがOMS Oracleホームにインストールされ、OMSインスタンス・ホームで構成(および接続モードで実行)されている必要があります。

OCMが実行中であることを確認するには、次の手順を実行します。

1. ORACLE_CONFIG_HOMEをINSTANCE HOMEに設定します。

2. $ORACLE_HOME/ccr/bin/emCCR statusを実行します。

F.4.4 Oracle Harvesterによってターゲットのサブセットのみが収集される

多くのターゲットが管理リポジトリにアップロードされているが、ターゲットのサブセットしかOracle Harvesterによって収集されない場合、収集中に同じエラーが10回発生し、Oracle Harvesterによる収集が停止したとが原因である可能性があります。適切なログ・ファイルを参照し、このエラーが発生したことを確認してください。

管理リポジトリに対して次のSQLスクリプトを実行し、問題を解決してください。このスクリプトにより、Oracle Harvesterはこの収集エラーを無視し、残りのターゲット情報の収集を続行します。

sql> insert into mgmt_ocm_upl_props (name,str_value) values('ignore_errors','true');
sql> commit;

SQLスクリプトを実行した後、OMSをバウンスします。

(Oracle Bug#11734389)

G Enterprise Managerのアクセシビリティ機能の有効化

Oracle製品、サービスおよびサポート・ドキュメントを無効なコミュニティでアクセスおよび利用可能にする取組みの一環として、Enterprise Managerには、管理データをアシスティブ・テクノロジのユーザーで利用可能にする複数の機能が用意されています。Enterprise Managerでは、次のアクセシビリティ機能が用意されています。

- スクリーン・リーダーのサポート

- 高コントラストのサポート

- 大きいフォントのサポート

この付録では、スクリーン・リーダーのサポートを有効にするために変更する必要がある、次の構成設定について説明します。

- Enterprise Managerのアクセシビリティ・モードの有効化

- uix-config.xmlフラグの設定

- web.xmlファイルの構成

- スクリーン・リーダーのサポートが有効になっていることの確認

注意:
スクリーン・リーダーのサポートを有効にするとPPRが無効になるため、処理のステータスのリフレッシュに関連するすべてのページが自動的にリフレッシュされなくなります。これは予測されている動作です。

G.1 Enterprise Managerのアクセシビリティ・モードの有効化

スクリーン・リーダー・モードを有効化するには、次の手順を実行します。

1. Cloud Controlホームページの「<user_name>」メニューから、「プリファレンス」→「アクセシビリティ」を選択します。

2. 「アクセシビリティ・プリファレンス」ページで、「スクリーン・リーダーを使用する」を選択します。「適用」をクリックします。
ADFアクセシビリティ・モードは、即座に実行されるセッション・ベースの設定で、Enterprise Manager管理サービスを再起動する必要はありません。

ADFの各ページでは、Cloud Controlに初めてログインした後に「アクセシビリティ・プリファレンス」ダイアログが表示されます。このダイアログの設定は、前述の「アクセシビリティ・プリファレンス」ページの設定と同じです。

G.2 uix-config.xmlフラグの設定

UIXの各ページでスクリーン・リーダー・モードを有効にするには、次の手順を実行します。

1. uix-config.xml構成ファイルを探します。
Cloud Controlインストールでuix-config.xmlファイルを探すには、ディレクトリをOracle Management Serviceホームの次の場所に変更します。

./oms/sysman/archives/emgc/deployments/EMGC_DOMAIN/emgc.ear/em.war/WEB-INF/uix-config.xml

2. テキスト・エディタを使用してuix-config.xmlファイルを開き、次のエントリを設定します。

<!-- An alternate configuration that disables accessibility features  -->
<default-configuration>
<accessibility-mode>screenReader</accessibility-mode>
</default-configuration>

3. ファイルを保存して閉じます。

4. Oracle Management Serviceを再起動します。

注意:
UIXアクセシビリティ・モードは、製品全体に適用される設定です。この設定を適用するには、Enterprise Manager管理サービスを再起動する必要があります。

注意:
uix-config.xmlファイルで、enable-auto-table-ctlr-labelsがtrueに設定されます。これにより、カーソルをUI要素(表内のチェック・ボックスやラジオ・ボタンなど)にかざすと、ラベルの付いたツール・チップ・ボックスが表示されるようになります。この機能を無効にするには、設定をfalseに変更します。

G.3 web.xmlファイルの構成

web.xmlファイルを構成するには、次の手順に従います。

1. web.xml構成ファイルを見つけます。
Cloud Controlインストールでweb.xmlファイルを探すには、ディレクトリをOracle Management Serviceホームの次の場所に変更します。

./oms/sysman/archives/emgc/deployments/EMGC_DOMAIN/emgc.ear/em.war/WEB-INF/web.xml

2. テキスト・エディタを使用してweb.xmlファイルを開き、ファイル内で次の6行を探します。

<!-- Uncomment this to enable textual chart descriptions
<context-param>
<param-name>enableChartDescription</param-name>
<param-value>true</param-value>
</context-param>
-->

3. このセクションの最初の行および最後の行を削除して4行のみを残し、このセクションからコメントを削除します。

<context-param>
<param-name>enableChartDescription</param-name>
<param-value>true</param-value>
</context-param>

4. ファイルを保存し、終了します。

5. Oracle Management Serviceを再起動します。

G.4 スクリーン・リーダーのサポートが有効になっていることの確認

Enterprise Managerでは、パフォーマンス・データの表示にグラフが使用されます。ほとんどのユーザーにとって、これらのグラフは、トレンドを理解し、パフォーマンス・メトリックの最小値および最大値の特定に役立つ、データのグラフィック表示となります。

しかし、グラフの情報はスクリーン・リーダーで読み取ることができません。この問題を解決するため、各パフォーマンス・グラフに完全な説明テキストが表示されるようにEnterprise Managerを構成できます。デフォルトでは、グラフのテキスト表示のサポートは無効になっています。グラフの説明テキストが有効になっている場合、Enterprise Managerでは各チャートに小さなアイコンが表示され、説明テキストへのドリルダウン・リンクとして使用できます。

ADFの各ページでスクリーン・リーダーのサポートが有効になっていることを確認するには、次の手順に従います。

1. Cloud Controlホームページで、「ヘルプ」をクリックし、「Enterprise Managerバージョン情報」を選択します。

2. 「Enterprise Managerバージョン情報」ダイアログ・ボックスで、「アクセシビリティ・プリファレンス - スクリーン・リーダーのサポート」が「有効」に設定されていることを確認します。

3. 「アクセシビリティ・プリファレンス - スクリーン・リーダーのサポート」が「無効」に設定されている場合は、「Enterprise Managerのアクセシビリティ機能の有効化」に記載されている手順に従います。

UIXの各ページでスクリーン・リーダーのサポートが有効になっていることを確認するには、次の手順に従います。

1. Cloud Controlホームページの「エンタープライズ」メニューから、「レポート」を選択し、「情報パブリッシャ・レポート」を選択します。

2. 「情報パブリッシャ・レポート」ページで、「ハードウェア・サマリー」を選択します。「ハードウェア・サマリー」ページが表示されます。アクセシビリティティ設定が有効になっている場合は、図G-1に示すアイコンが表示されます。

図G-1 チャートの説明テキストを示すアイコン

H アクティブおよびパッシブ環境でのフェイルオーバーのターゲットの構成

この項では、既存の管理エージェントから別のエージェントにコールド・フェイルオーバー・クラスタ(CFC)・ターゲットを再配置するCloud Control管理者向けに全般的な情報を提供します。ターゲットは複数のノードで実行可能ですが、CFC環境のアクティブなノードでのみ実行されます。

CFC環境は、通常、クラスタ・ソフトウェアを組み合せて使用することで、仮想ホスト名とIPアドレス、インターコネクト・ホストおよび記憶域システムを提供して情報を共有し、アプリケーションの高可用性(HA)を実現します。仮想ホスト名とIPのフェイルオーバーを自動化し、Enterprise Managerターゲットを再配置してパッシブ・ノードでアプリケーションを再起動する場合、Oracle Enterprise Managerのコマンドライン・インタフェース(EM CLI)と、オラクル社またはサードパーティのクラスタ・ソフトウェアを使用する必要があります。一部のOracleパートナ・ベンダーでは、この分野のクラスタウェア・ソリューションが提供されています。

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

- アクティブおよびパッシブ環境でのターゲットの再配置

- インストールと構成

- フェイルオーバー手順

- フェイルバック手順

- EM CLI relocate_targetsのパラメータ

- 再配置スクリプト

H.1 アクティブおよびパッシブ環境でのターゲットの再配置

Oracle Enterprise Manager 12cでは、クラスタの各ノードで実行されている単一のOracle Management Agentによって、アクティブおよびパッシブの高可用性で構成されているターゲットを監視できます。CFCクラスタの各物理ノードでは、1つの管理エージェントのみが必要ですが、その理由は、パッシブ・ノードへのフェイルオーバーの際に、Enterprise Managerは、一連のEMCLIコマンドを使用して、障害ノード上の管理エージェントから新しくアクティブ化されたノード上の別の管理エージェントにHA監視対象ターゲットを移動できるためです。詳細は、『Oracle® Enterprise Managerコマンドライン・インタフェース』を参照してください。

アクティブ/パッシブ環境でアプリケーションが実行している場合、アクティブなノードに障害が発生すると、クラスタウェアはパッシブ・ノードでアプリケーションを起動します。Enterprise Managerがこのタイプの構成でターゲットを引き続き監視する場合、既存の管理エージェントには追加の構成が必要です。

次の項では、新しいアクティブなノードでターゲットを自動化および再起動する環境を準備する方法について説明します。フェイルオーバーおよびフェイルバックの手順も示します。

H.2 インストールおよび構成

次の項では、Oracle Management Serviceプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするEnterprise Managerの構成方法について説明します。

- 前提条件

- 構成手順

H.2.1 前提条件

次の手順は、CFCでのフェイルオーバー用に監視対象ターゲットがすでにインストールおよび構成されていることが前提となります。

アクティブ/パッシブ環境を次のように準備します。

- オペレーティング・システム・クロックがクラスタのすべてのノード間で同期していることを確認します。(ネットワーク・タイム・プロトコル(NTP)または別のネットワーク同期化メソッドの使用を検討してください。)

- 物理ホスト名を使用して、クラスタの各ノードに管理エージェントをインストールします。クラスタの各ノードのローカル・ディスク・ボリュームに管理エージェントをインストールします。管理エージェントをインストールすると、Cloud Controlコンソールに表示されます。

- CFCクラスタの各ノードにEMCLIをインストールして構成します。詳細は、『Oracle® Enterprise Managerコマンドライン・インタフェース』を参照してください。

- ターゲットを再配置するときは、失敗したノードの管理エージェントと新しくアクティブ化したノードの管理エージェントでプラグインのバージョンとリビジョンが同じであることを確認します。

H.2.2 構成手順

次の項では、OMSプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするEnterprise Managerの構成方法について説明します。次に示す例は、2つのノードで構成されるクラスタに1つのフェイルオーバー・グループがある構成に基づいています。

構成には次の2つの手順が含まれます。

- ターゲットの検出

- プラグインのデプロイ

H.2.2.1 ターゲットの検出

アクティブ/パッシブ・ターゲットを構成した後、Cloud Controlコンソールの「ターゲットの手動追加」画面を使用して、ターゲット(データベース、リスナー、アプリケーション・サーバーなど)を追加します。この画面には、「設定」→「ターゲットの追加」→「ターゲットの手動追加」の順に移動してアクセスします。この手順は、アクティブ・ノード(追加するターゲットを現在ホストしているノード)を指定して実行する必要があります。

H.2.2.2 プラグインのデプロイ

ターゲットを追加した後、アクティブ・ホストのエージェントにデプロイされているプラグインを特定します。これは、エージェントのホームページに移動して「構成」リージョンの「プラグイン」タブを表示することでわかります。

図H-1 エージェント・ホーム・ページ

「検出コンテンツのみ」ボックスが選択されていないプラグインを書き留めます。これらのプラグインは、パッシブ・ノードのエージェントにデプロイする必要はありません。

パッシブ・ノードのエージェントのホームページを確認して存在しないプラグインを特定した後、存在しないプラグインをデプロイするために「設定」→「拡張性」→「プラグイン」に移動して、関連するプラグインを選択し、管理エージェントにデプロイ・メニューを使用してプラグインをデプロイします。

H.3 フェイルオーバー・プロシージャ

ノードのフェイルオーバー後にターゲットの再配置の速度を上げるには、ターゲットのフェイルオーバーの自動開始に必要なコマンドが含まれるスクリプトを使用して次の手順を構成します。通常、クラスタウェア・ソフトウェアには、Enterprise Managerのターゲットを再配置するスクリプトを自動的に実行できるメカニズムがあります。サンプル・スクリプトについては、「再配置スクリプト」も参照してください。

1. 障害が発生したアクティブ・ノードのターゲット・サービスを停止します。
ターゲットが実行しているアクティブ・ノードで、仮想IPで実行しているターゲット・サービスを停止します。

2. 必要に応じて、アクティブ・ノードでこのターゲットの記憶域の接続を解除します。
仮想IPと共有記憶域で実行しているすべてのアプリケーションを停止します。

3. 新しいアクティブ・ノードでターゲットのIPアドレスを有効にします。

4. 必要に応じて、現在アクティブなノードでターゲットの記憶域を接続します。

5. EM CLIを使用してCloud Controlにターゲットを再配置します。
新しいアクティブ・ノード上の管理エージェントにターゲットを再配置するには、フェイルオーバー操作後に再配置する必要のあるターゲット・タイプごとに(リスナーやアプリケーション・サーバーなど)、EM CLI relocate_targets動詞を実行します。

例:

emcli relocate_targets
-src_agent=<node 1>:3872
-dest_agent=<node 2>:3872
-target_name=<database_name>
-target_type=oracle_database
-copy_from_src
-force=yes

この例では、管理エージェントのデフォルト・ポートはポート3872です。構成に適したポート番号を検索するには、エージェントのURLパラメータの値を使用します。このパラメータを確認するには、管理エージェントに対して次のコマンドを実行します。

emctl status agent

注意:
フェイルオーバー・イベントの発生時に、ソース・エージェントは実行中でないことがあります。ただし、再配置操作を行うために、ソース管理エージェントを実行する必要はありません。EM CLIは、管理リポジトリに対して再配置操作を直接実行するOMSクライアントです。

6. 新しいアクティブ・ノードですべてのターゲットを起動します。

7. Enterprise Managerコンソールで、再配置されたすべてのターゲットが起動して実行されていることを確認します。

H.4 フェイルバック手順

HAターゲットを元のアクティブ・ノードまたはその他のクラスタ・メンバー・ノードに戻すには、次の手順を実行します。

1. HAターゲットをアクティブ・ノードに戻すには、「フェイルオーバー手順」の手順を繰り返します。

2. Enterprise Managerコンソールでターゲット・ステータスを確認します。

H.5 EM CLI relocate_targetsのパラメータ

第H.3項「フェイルオーバー手順」の説明に従って、再配置操作中にフェイルオーバー(またはスイッチオーバー)するターゲット・タイプごとにEM CLI relocate_targets動詞を実行します。表H-1「relocate_targets動詞のパラメータ」に、このEM CLI動詞に関連付けられている動詞のパラメータを示します。

表H-1 relocate_targets動詞のパラメータ

EM CLIパラメータ

説明

-src_agent

フェイルオーバーの発生前にターゲットが実行していた管理エージェント。

-dest_agent

フェイルオーバー後にターゲットを監視する管理エージェント。

-target_name

フェイルオーバーするターゲットの名前。

-target_type

フェイルオーバーするターゲットのタイプ(Enterprise Managerの内部ターゲット・タイプ)。たとえば、(スタンドアロン・データベースまたはOracle RACインスタンスの)Oracleデータベース、データベース・リスナーのOracleリスナーなど。

-copy_from_src

ソース管理エージェントと同じタイプのプロパティを使用してターゲットを特定します。これは必須パラメータです。このパラメータを指定しないと、ターゲット定義が破損する可能性があります。

-force

同様にフェイルオーバーする依存性を強制します(必要な場合)。

H.6 再配置スクリプト

次の例では、フェイルオーバー操作の発生時にクラスタウェア構成から実行できる再配置スクリプトを示します。

スクリプトを実行する前に:

- デフォルトの通常ホスト資格証明と通常ホスト資格証明を設定します。

- データベース・インスタンスのターゲット優先資格証明と、通常データベース資格証明、SYSDBAのデータベース資格証明およびデータベース・ホスト資格証明を設定します。

H.6.1 再配置スクリプトの例

#! /bin/ksh
#get the status of the targets

emcli get_targets
-targets="db1:oracle_database;listener_db1:oracle_listener"
-noheader

if [[ $? != 0 ]]; then exit 1; fi

# blackout the targets to stop false errors.  This blackout is set to expire in 30 minutes.

emcli create_blackout
-name="relocating active passive test targets"
-add_targets="db1:oracle_database;listener_db1:oracle_listener"
-reason="testing failover"
-schedule="frequency:once;duration:0:30"

if [[ $? != 0 ]]; then exit 1; fi

# relocate the targets to the new host

emcli relocate_targets
-src_agent=host1.example.com:3872
-dest_agent=host2.example.com:3872
-target_name=db1 -target_type=oracle_database
-copy_from_src -force=yes

if [[ $? != 0 ]]; then exit 1; fi

emcli relocate_targets
-src_agent=host1.example.com:3872
-dest_agent=host2.example.com:3872
-target_name=listener_db1
-target_type=oracle_listener
-copy_from_src -force=yes

if [[ $? != 0 ]]; then exit 1; fi

# End the blackout and let the targets become visible

emcli stop_blackout
-name="relocating active passive test targets"

if [[ $? != 0 ]]; then exit 1; fi

# Recheck the status of the targets

emcli get_targets
-targets="db1:oracle_database;listener_db1:oracle_listener"
-noheader

if [[ $? != 0 ]]; then exit 1; fi

I スタンバイWebLogicドメインを使用するスタンバイOMS

次のスタンバイOMS実装は、Enterprise Managerリリース12.1.0.2以前のインストールで使用されます。Enterprise Managerリリース12.1.0.3以上については、第18章「Enterprise Manager障害時リカバリ」を参照してください。

重要:
スタンバイWebLogicドメインを使用するスタンバイOMSはまだサポートされていますが、非推奨になっており、将来のリリースでサポートされない可能性があります(詳細はMy Oracle Supportノート1563541.1を参照してください)。
BI Publisherサーバーの構成は、Cloud Control 12.1.0.4以降のリリースに対応するスタンバイWeblogicドメインを使用するスタンバイOMSではサポートされていません。

I.1 スタンバイ・サイトでのスタンバイ管理サービスの構成

スタンバイ管理サービスをインストールする前に、次の内容を検討します。

このアクティビティは、限られた期間あるいは計画されたメンテナンスの時間帯に行うことをお薦めします。新しいOracle Management Serviceのインスタンスをスタンバイ・サイトにインストールする場合、その管理サービスはプライマリ・サイトの管理リポジトリ・データベースに接続するように最初に構成されます。一部のワークロードが新しい管理サービスによって引き継がれます。このため、スタンバイ・サイトの管理サービスの場所がプライマリ・サイトの管理リポジトリ・データベースとかなり離れている場合は、パフォーマンスが一時的に失われることがあります。ただし、データ損失はなく、スタンバイ管理サービスを構成後に停止すると、パフォーマンスは回復します。

前提条件

- 前述の項で説明したCloud Control MAAガイドラインのとおりにプライマリ・サイトを構成します。管理サービスの前にSLBがあり、すべての管理エージェントは、SLBによって管理サービスにアップロードするように構成されます。

- スタンバイ・サイトは、フェイルオーバーの発生時にパフォーマンスが損われないように、ハードウェアとネットワークのリソースの点でプライマリ・サイトと同様にしてください。

- プライマリ・サイトとスタンバイ・サイトでレプリケートするソフトウェア・ライブラリにより使用される記憶域を構成します。サイトで障害が発生した場合、ハードウェア・ベンダーのディスク・レベル・レプリケーション技術を使用して該当の記憶域の内容をスタンバイ・サイトで利用できるようにする必要があります。

- ソフトウェア・ライブラリに使用される共有記憶域は、プライマリ・サイトと同じパスを使用してスタンバイ・サイトで使用できるようにする必要があります。

- 障害リカバリ環境で完全な冗長性を確保するには、別のロード・バランサをスタンバイ・サイトにインストールしておきます。セカンダリSLBをプライマリと同じ方法で構成する必要があります。一部のSLBベンダー(F5 Networksなど)では、サイトで障害が発生した場合に、プライマリ・サイトのSLBで提供される仮想IPの制御を、スタンバイ・サイトのSLBに渡す際に使用可能な追加サービスが提供されます。このサービスを使用すると、プライマリ・サイトからスタンバイ・サイトへの管理エージェント・トラフィックの自動切替えが容易になります。

- Oracle Platform Security Services (OPSS)は基礎となるセキュリティ・プラットフォームであり、WebLogic Server、SOA、WebCenterなどの製品を含むOracle Fusion Middlewareにセキュリティを提供し、1つのセキュリティ・フレームワークでOracle環境とサード・パーティ環境の両方に対応できます。Weblogicドメイン名とOPSSファーム名が一致しない場合、Enterprise Managerのアップグレード後にスタンバイ・サイトを設定しようとすると、構成の問題が発生することがあります。具体的には、プライマリからスタンバイにスイッチオーバーし、新しいプライマリ・サイトをアップグレードした後、新しいスタンバイ・サイトを作成しようとすると、この問題が発生します。プライマリ・ドメインに使用される名前は元の名前であり、元のプライマリ・サイトのjps-config.xmlファイル内に設定されています。

I.1.1 最初のスタンバイ管理サービスのインストール

次の手順で最初のスタンバイ管理サービスをインストールします。

1. プライマリ・サイトの最初の管理サービスで次のコマンドを実行して、管理リポジトリにemkeyをコピーします。
emctl config emkey -copy_to_repos

2. 次のコマンドを使用して、プライマリ・サイトの最初の管理サービスから構成をエクスポートします。
emctl exportconfig oms -dir <エクスポートの場所>

構成のエクスポート後は、スタンバイ管理サービスが構成されるまで、プライマリ・サイトの構成を変更しないでください。

3. 管理エージェントが存在しない場合は、スタンバイ・ホストにインストールします。

4. 管理サービスの追加デプロイメント・プロシージャの変更されたバージョンを使用して、Enterprise Managerソフトウェアのソフトウェア専用インストールを実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「Oracle Management Serviceの追加」プロシージャを選択し、「類似作成」をクリックします。

3. 「プロシージャ・ステップ」タブに移動し、「Oracle Management Serviceの構成」、「ターゲットの検出」および「構成後のタスク」のステップを無効化します。

4. 変更したデプロイメント・プロシージャを保存し、それを使用してスタンバイOMSホストにEnterprise Managerソフトウェアをインストールします。

5. デプロイメント・プロシージャの完了後、スタンバイOMSホストの<OMS Oracle Home>/sysman/configからファイルemInstanceMapping.propertiesを削除します。

5. スタンバイ・モードでomscaを実行して管理サービスを構成します。スタンバイ用の別のドメイン名を選択します。たとえば、プライマリWebLogicドメインがGCDomainの場合、GCDomainStbyを選択します。
omsca standby -EM_PRIMARY_DOMAIN_NAME GCDomain -EM_DOMAIN_NAME GCDomainStby -NM_USER nodemanager -AS_USERNAME weblogic -nostart

管理サーバー・ホストおよびEMインスタンス・ホストが求められた場合、スタンバイOMSホスト名を入力します(またはデフォルトを受け入れます)。

パスワードが求められた場合、プライマリ・サイトと同じパスワードを指定します。

管理リポジトリの詳細が求められた場合、プライマリ・データベースの詳細を指定します。

重要:
omsca standbyの実行時、OMS Oracleホームがソフトウェア専用モードでインストールされている場合は、まずORACLE_HOME/sysman/config/farmkeyをプライマリOMSマシンからこの新しいOracleホームの同じ場所(ORACLE_HOME/sysman/config)にコピーする必要があります。

6. 次のコマンドを実行して、必要なプラグインを構成します。
pluginca -action deploy -isFirstOMS true -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>

ここで、plugin-listはSQL問合せから戻されたプラグインのリストで

SELECT epv.plugin_id, epv.version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ( 'BUILT_IN_TARGET_TYPE' , 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id;

<plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…という形式のカンマ区切りリストです。

例: oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0

7. 前述の手順2でプライマリ管理サービスからエクスポートした構成をスタンバイ管理サービス・ホストにコピーします。次のコマンドを使用して、エクスポートした構成をスタンバイ管理サービスにインポートします。
emctl importconfig oms -file <エクスポート・ファイルのフルパス>

このコマンドにより管理サービスが開始します。

8. 管理サービスを停止し、管理サーバーを実行したままにするには、次のコマンドを使用します。
emctl stop oms

9. スタンバイWeblogicドメインを追加し、ターゲットに関連付けます。
スタンバイWeblogicドメインおよび関連ターゲットは、ガイドされた検出の手順で追加できます。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ガイド付きプロセスを使用してターゲットを追加」を選択します。

3. 「ターゲット・タイプ」メニューから、「Oracle Fusion Middleware/WebLogicドメイン」を選択します。

4. セキュア・ポート(通常7101)を使用し、「拡張」の下で、「JMXプロトコル」を「t3s」に設定します。

注意:
スタンバイOMSがこの段階で停止しているのと同様に、管理サーバーを除くWeblogicターゲットは停止しているように見えます。

10. シングル・サインオンをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでSSOを構成します。

11. Real User Experience Insight、AD4JマネージャまたはBI Publisherをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでそれらを構成します。

I.1.2 最初のスタンバイ管理サービスのインストール(Oracle Installer、ソフトウェア専用モード)

1. プライマリ・サイトの最初のOMSで次のコマンドを実行して、管理リポジトリにemkeyをコピーします。

emctl config emkey -copy_to_repos

2. 次のコマンドを使用して、プライマリ・サイトの最初のOMSから構成をエクスポートします。

emctl exportconfig oms -dir <location for the export file>

構成のエクスポート後は、スタンバイOMSが構成されるまで、プライマリ・サイトの構成を変更しないでください。

3. 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のEnterprise Manager Softwareの即時インストールと後での構成(グラフィック・モードでのインストール)についての章の説明に従って、リモート・ホストでスタンバイOMSのソフトウェア専用インストールを実行します。必ずプライマリOMSと同じミドルウェアの場所にソフトウェア・バイナリをインストールします。

注意:
プライマリOMSと同じプラグインのセットを選択していることを確認します。

インストールに含まれない追加のプラグインをインストールした場合、次の手順を実行します。

1. リポジトリにログインし、次の問合せを実行して、インストール済のプラグインのリストを取得します。

SELECT epv.plugin_id "plugin id", epv.version "version", epv.rev_version "revision", epv.su_entity_id "update id"
FROM em_plugin_version epv, em_current_deployed_plugin ecp
WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME')
AND ecp.dest_type='2'
AND epv.plugin_version_id = ecp.plugin_version_id;

戻されたインストール済プラグインのリストを書き留めます。

2. プライマリ・サイトからプラグイン・アーカイブを抽出します。

emcli export_update -id=<update id> -host=<standby OMS host> -dir=<directory to export archives> <host credential options>

ここで、<update id>は前述の問合せの4列により戻された値です。

このコマンドを実行すると、拡張子が.zipのファイルが生成されることに注意してください。ファイルの名前を<file_name>.zipから<file_name>.oparに変更します。

すべてのプラグインに対しても前述の手順を繰り返します。スタンバイOMSホストでは、すべての.oparファイルを<plugin dir >ディレクトリに配置します。

3. runInstallerを起動し、ソフトウェア専用インストールを選択します。これによりミドルウェア・ホームおよびOMS Oracleホームのみがインストールされます。

4. 必要なプラグインをインストールするには、プラグイン・インストール・スクリプトを実行します。

<OMS_HOME>/sysman/install/PluginInstall.sh -pluginLocation <plugin dir>

ここで、<plugin dir>は前述の手順2で追加のプラグインを配置したディレクトリです。このコマンドを実行すると、インストールするプラグインを選択できる画面が表示されます。手順1でリストされたすべてのプラグインが表示され、それらを選択していることを確認します。一致しない場合、OMS構成が後の手順で失敗する可能性があります。

4. ソフトウェア専用インストールでは、プライマリOMSに適用したすべてのパッチを適用し、プライマリおよびスタンバイOMSの両方が同一で同期しているようにします。

5. スタンバイ・モードでomscaを実行してOMSを構成します。スタンバイ用の別のドメイン名を選択します。たとえば、プライマリWebLogicドメインがGCDomainの場合、GCDomainStbyを選択します。

omsca standby -EM_DOMAIN_NAME GCDomainStby -NM_USER nodemanager -AS_USERNAME weblogic -nostart

管理サーバー・ホストおよびEnterprise Managerインスタンス・ホストが求められた場合、スタンバイOMSホスト名を入力します(またはデフォルトを受け入れます)。

パスワードが求められた場合、プライマリ・サイトと同じパスワードを指定します。

管理リポジトリの詳細が求められた場合、プライマリ・データベースの詳細を指定します。

6. 次のコマンドを実行して、必要なプラグインを構成します。

pluginca -action deploy -isFirstOMS true -plugins <plug-in list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>

ここで、plug-in listはSQL問合せから戻されたプラグインのリストです。

SELECT epv.plugin_id, epv.version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ( 'BUILT_IN_TARGET_TYPE' , 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id;

プラグイン・リストは、次に示す形式のカンマ区切りリストである必要があります。

<plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…

例:

oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0

7. 前述の手順2でプライマリOMSからエクスポートした構成をスタンバイOMSホストにコピーします。エクスポートした構成をスタンバイOMSにインポートします。

emctl importconfig oms -file <full path of the export file>

このコマンドでは、エクスポートが失敗すると警告が生成され、続行するための確認が求められます。 "y"を入力すると警告を無視して続行することができます。

このコマンドは自動的にOMSを開始します。

8. 管理サービスを停止し、管理サーバーを実行したままにするには、次のコマンドを使用します。

emctl stop oms

9. OMSホームから次のコマンドを実行し、2番目のOMSホスト上に管理エージェントを構成します。

$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<middleware_home>/agent OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_port> AGENT_REGISTRATION_PASSWORD=<password> -configOnly

注意: SLBが構成されている場合、プライマリ・ロード・バランサのホストおよびポートを直接指定します。SLBが構成されていない場合、プライマリOMSの保護されたアップロード・ポートを使用します。

例:

./agentDeploy.sh AGENT_BASE_DIR=$MIDDLEWARE_BASE/agent OMS_HOST=prim_oms_hhost.domain.com EM_UPLOAD_PORT=4900 AGENT_REGISTRATION_PASSWORD=password -configOnly

10. 必要なプラグインを管理エージェントにデプロイします。
プラグインのデプロイの詳細は、Enterprise Manager Cloud Controlの管理者ガイドのプラグインの管理に関する章を参照してください。

11. スタンバイWWebLogicドメインを追加し、ターゲットに関連付けます。
スタンバイWebLogicドメインおよび関連ターゲットは、ガイドされた検出の手順で追加できます。

「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。「ターゲット・タイプ」メニューから、「Oracle Fusion Middleware」を選択します。セキュア・ポート(通常は7101)を使用し、「拡張」でJMXプロトコルをt3sに設定します。このステージではスタンバイOMSは停止しているので、WebLogicターゲットはAdministration Serverを除き"down"と表示されます。

12. シングル・サインオンをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでSSOを構成します。

13. Real User Experience Insight、AD4JマネージャまたはBI Publisherをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでそれらを構成します。

I.1.3 追加のスタンバイ管理サービスのインストール

スタンバイ・サイトはプライマリ・サイトと同じように構成することをお薦めします。これは、プライマリ・サイトと同様に、スタンバイ・サイトに複数のOMSを構成することを意味します。

1. 最初のスタンバイ管理サービスで次のコマンドを実行して、スタンバイ管理サーバーを起動します。
emctl start oms –admin_only

2. 次のコマンドを使用して、プライマリ・サイトの最初の管理サービスから構成をエクスポートします。
emctl exportconfig oms -dir <エクスポートの場所>

構成のエクスポート後は、スタンバイ管理サービスが構成されるまで、プライマリ・サイトの構成を変更しないでください。

3. スタンバイ・ホストで管理エージェントをインストールします。

4. 「Oracle Management Serviceの追加」デプロイメント・プロシージャの変更されたバージョンを使用して、Enterprise Managerソフトウェアのソフトウェア専用インストールを実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「Oracle Management Serviceの追加」プロシージャを選択し、「類似作成」をクリックします。

3. 「プロシージャ・ステップ」タブに移動し、「管理サービスを構成しています」、「ターゲットの検出」および「構成後のタスク」のステップを無効化します。

4. 変更したデプロイメント・プロシージャを保存し、それを使用してスタンバイOMSホストにEnterprise Managerソフトウェアをインストールします。

5. デプロイメント・プロシージャの完了後、スタンバイOMSホストの<OMS Oracle Home>/sysman/configからファイルemInstanceMapping.propertiesを削除します。

5. omscaを実行して管理サービスを構成します。
omsca add -nostart

管理リポジトリの詳細が求められた場合、プライマリ・データベースの詳細を指定します。管理サーバーの詳細が求められた場合、スタンバイ管理サーバーの詳細を指定します。

6. 次のコマンドを実行して、必要なプラグインを構成します。
pluginca -action deploy –isFirstOMS false -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>

ここで、plugin-listはSQL問合せから戻されたプラグインのリストで

SELECT epv.plugin_id, epv.version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ( 'BUILT_IN_TARGET_TYPE' , 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id;

<plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…という形式のカンマ区切りリストです。

例: oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0

7. 前述の手順1でプライマリ管理サービスからエクスポートした構成をスタンバイ管理サービス・ホストにコピーします。次のコマンドを使用して、エクスポートした構成をスタンバイ管理サービスにインポートします。
emctl importconfig oms -file <エクスポート・ファイルのフルパス>

このコマンドにより管理サービスが開始します。

8. 次のコマンドを使用して管理サービスを停止します。
emctl stop oms

9. コンソールからスタンバイ・ドメイン・ターゲットをリフレッシュします。これは、新しい管理対象サーバーと関連ターゲットを検出および追加するガイド付きワークフローを表します。

10. シングル・サインオンをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでSSOを構成します。

11. Real User Experience Insight、AD4JマネージャまたはBI Publisherをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでそれらを構成します。

I.1.4 追加のスタンバイ管理サービスのインストール(Oracle Installer、ソフトウェア専用モード)

1. 最初のスタンバイ管理サービスで次のコマンドを実行して、スタンバイ管理サーバーを起動します。
emctl start oms –admin_only

2. 次のコマンドを使用して、プライマリ・サイトの最初の管理サービスから構成をエクスポートします。
emctl exportconfig oms -dir <エクスポートの場所>

構成のエクスポート後は、スタンバイ管理サービスが構成されるまで、プライマリ・サイトの構成を変更しないでください。

3. 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のEnterprise Manager Softwareの即時インストールと後での構成(グラフィック・モードでのインストール)についての章の説明に従って、リモート・ホストでスタンバイOMSのソフトウェア専用インストールを実行します。必ずプライマリOMSと同じミドルウェアの場所にソフトウェア・バイナリをインストールします。

注意:
プライマリOMSと同じプラグインのセットを選択していることを確認します。

インストールに含まれない追加のプラグインをインストールした場合、次の手順を実行します。

1. リポジトリにログインし、次の問合せを実行して、インストール済のプラグインのリストを取得します。

SELECT epv.plugin_id "plugin id", epv.version "version", epv.rev_version "revision", epv.su_entity_id "update id"
FROM em_plugin_version epv, em_current_deployed_plugin ecp
WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME')
AND ecp.dest_type='2'
AND epv.plugin_version_id = ecp.plugin_version_id;

戻されたインストール済プラグインのリストを書き留めます。

2. プライマリ・サイトからプラグイン・アーカイブを抽出します。

emcli export_update -id=<update id> -host=<standby OMS host> -dir=<directory to export archives> <host credential options>

ここで、<update id>は前述の問合せの4列により戻された値です。

このコマンドを実行すると、拡張子が.zipのファイルが生成されることに注意してください。ファイルの名前を<file_name>.zipから<file_name>.oparに変更します。

すべてのプラグインに対しても前述の手順を繰り返します。スタンバイOMSホストでは、すべての.oparファイルを<plugin dir >ディレクトリに配置します。

3. runInstallerを起動し、ソフトウェア専用インストールを選択します。これによりミドルウェア・ホームおよびOMS Oracleホームのみがインストールされます。

4. 必要なプラグインをインストールするには、プラグイン・インストール・スクリプトを実行します。

<OMS_HOME>/sysman/install/PluginInstall.sh -pluginLocation <plugin dir>

ここで、<plugin dir>は前述の手順2で追加のプラグインを配置したディレクトリです。このコマンドを実行すると、インストールするプラグインを選択できる画面が表示されます。手順1でリストされたすべてのプラグインが表示され、それらを選択していることを確認します。一致しない場合、OMS構成が後の手順で失敗する可能性があります。

4. ソフトウェア専用インストールでは、プライマリOMSに適用したすべてのパッチを適用し、プライマリおよびスタンバイOMSの両方が同一で同期しているようにします。

5. omscaを実行して管理サービスを構成します。
omsca add –nostart

管理リポジトリの詳細が求められた場合、プライマリ・データベースの詳細を指定します。管理サーバーの詳細を求められたら、スタンバイ管理サーバーの詳細を入力します。プライマリ・サイトとのポートの一貫性を保つために、コマンドラインにすべてのポートを入力します。次に例を示します。

omsca add -MSPORT 7202 -MS_HTTPS_PORT 7301 -EM_NODEMGR_PORT 7403 -EM_UPLOAD_PORT 4889 -EM_UPLOAD_HTTPS_PORT 4900 -EM_CONSOLE_PORT 7788 -EM_CONSOLE_HTTPS_PORT 7799 -nostart

6. 次のコマンドを実行して、必要なプラグインを構成します。
pluginca -action deploy –isFirstOMS false -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>

ここで、plugin-listは前述のSQL問合せから戻されたプラグインのリストで、<plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…という形式のカンマ区切りリストです。

例: oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0

7. 前述の手順1でプライマリ管理サービスからエクスポートした構成をスタンバイ管理サービス・ホストにコピーします。次のコマンドを使用して、エクスポートした構成をスタンバイ管理サービスにインポートします。
emctl importconfig oms -file <エクスポート・ファイルのフルパス>

このコマンドでは、エクスポートが失敗すると警告が発生し、続行するかどうかの確認が求められます。 "y"を入力すると警告を無視して続行することができます。

このコマンドは自動的にOMSを開始することに注意してください。

8. 次を使用してOMSを停止します。
emctl stop oms

9. OMSホームから次のコマンドを実行し、2番目のOMSホスト上に管理エージェントを構成します。

$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<middleware_home>/agent OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_port> AGENT_REGISTRATION_PASSWORD=<password> -configOnly

注意:
SLBが構成済の場合は、プライマリ・ロード・バランサのホストおよびポートを直接指定します。

10. 必要なプラグインを管理エージェントにデプロイします。
プラグインのデプロイの詳細は、Enterprise Manager Cloud Controlの管理者ガイドのCloud Controlの更新に関する章を参照してください。

11. コンソールからスタンバイ・ドメイン・ターゲットをリフレッシュします。これは、新しい管理対象サーバーと関連ターゲットを検出および追加するガイド付きワークフローを表します。

12. シングル・サインオンをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでSSOを構成します。

13. Real User Experience Insight、AD4JマネージャまたはBI Publisherをプライマリ・サイトに構成した場合、同じ手順に従って、スタンバイOMSでそれらを構成します。

I.1.5 インストールの検証と設定の完了

SLBで別のプールにスタンバイ管理サービスを追加して、スタンバイSLB構成を更新します。新しい管理サービスのモニターを設定します。

I.1.5.1 スタンバイ・サイトの同期の維持

スタンバイ・サイトは最初の設定の後、プライマリ・サイトでの変更との同期を維持する必要があります。プライマリ管理リポジトリでのトランザクションはData Guardを介してスタンバイ管理リポジトリに自動的に伝播しますが、OMS側の変更はスタンバイ・サイトで手動で再実行する必要があります。次の項では、標準的なアクティビティに対するこの手順を説明します。

パッチの適用

パッチがプライマリ・サイト管理サービスに適用されるときには、スタンバイ・サイト管理サービスにも適用される必要があります。パッチは通常Oracleホームを(Opatchの適用コマンドにより)更新し、オプションで、管理リポジトリに対して実行するスクリプトを必要とする場合があります。データベースの変更はData Guardを使用してスタンバイ・サイトに自動的に伝播されるので、スタンバイ・サイトでは、(OPatchの適用コマンドにより) Oracleホームを更新し、管理リポジトリでのスクリプトの実行をスキップしても問題ありません。

プラグインの管理

新しいプラグインがプライマリ・サイトにデプロイされる、または既存のプラグインがアップグレードされるかプライマリ・サイトからアンデプロイされる場合、次のプロシージャをスタンバイ・サイトで実行して、スタンバイ管理サービスの同期を維持することも必要です。スタンバイ管理サービスは同期されていないと、スイッチオーバーまたはフェイルオーバー操作が試行されるときに、開始できません。

次のプロシージャは、スタンバイ・サイトがドキュメントに記載されたプロセスごとに設定され、スタンバイ管理サービスが現在停止しており、プライマリ・リポジトリを指していることを前提としています。プライマリ・サイトへのプラグインのデプロイメントが正常に完了しました。

スタンバイ・サイトへの新しいプラグインのデプロイまたはプラグインのアップグレード

1. プライマリ・サイトからプラグイン・アーカイブを抽出します。
自己更新ホームに移動し、「プラグイン」をクリックし、必要なプラグインを選択して「アクション」表メニューからエクスポートを選択します。表示されるポップアップのEM CLIコマンドに注意してください。

emcli export_update -id=<update id> -deep -host=<standby OMS host> -dir=<directory to export archives> <host credential options>

追加のオプション“-deep”が必要なことに注意してください。このコマンドにより、指定した宛先ディレクトリに4つのファイルが作成されます。ファイル名<version>_OMS_<platform>_<revision>.zipは次の手順で使用されるファイルです。

2. スタンバイ管理サーバーが停止していれば、起動します。
emctl start oms -admin_only

3. プラグインの前提条件チェックを実行し、次のコマンドの実行後、レポートされた必要なパッチを適用します。

./emctl plugin deploy -action prereqcheck -isFirstOMS false -archives <exported_plugin_archive>

ここで、<exported_plugin_archive>は手順1でエクスポートされたzipファイル<version>_OMS_<platform>_<revision>.zipです。

重要:
プラグイン・リビジョンのデプロイ
デプロイするプラグインにリビジョン・バージョンがある場合は、emctl plugin deployコマンドの実行時に-revisions <list_of_revisions>オプションを追加する必要があります。-revisionsオプションを指定しないと、プラグインCAが既存の正しいプラグインXMLにベース・リビジョンのプラグインXMLをコピーしようとするため、リビジョン情報が上書きされます。

たとえば、前提条件をチェックし、12.1.0.3.0 DBプラグイン・リビジョン20130402をスタンバイOMSにデプロイするコマンドは次のとおりです。

./emctl plugin deploy -action prereqcheck -isFirstOMS false
-archives 12.1.0.3.0_OMS_2000_20130402.zip -revisions 20130402

./emctl plugin deploy -action deploy -isFirstOMS false
-archives 12.1.0.3.0_OMS_2000_20130402.zip -revisions 20130402

4. 最初のスタンバイOMS Oracleホームにプラグインを構成します。

./emctl plugin deploy -action deploy -isFirstOMS false -archives <exported_plugin_archive>

ここで、exported_plugin_archiveはzipファイル<version>_OMS_<platform>_<revision>.zipを表します。

5. スタンバイの追加のOMS/それぞれに対して、ステップ3と4を繰り返します。

./emctl plugin deploy -action prereqcheck -isFirstOMS true -archives <exported_plugin_archive>

./emctl plugin deploy -action deploy -isFirstOMS true -archives <exported_plugin_archive>

これでスタンバイ・サイトへのプラグインのデプロイメントが完了しました。

sysman資格証明の同期化

管理者がプライマリ・サイトでsysman資格証明を変更する場合、sysman資格証明に関してスタンバイ管理サービスの同期を維持するために、次のプロシージャをスタンバイ・サイトで実行する必要があります。

sysman資格証明はプライマリ・サイトとスタンバイ・サイトで同期を維持していないと、スイッチオーバーまたはフェイルオーバー操作が試行されるときに、開始できません。さらに、スイッチオーバー操作が完了すると、管理者はスタンバイOMSにログインできません。

次のプロシージャは、スタンバイ・サイトがドキュメントに記載されたプロセスに従って設定され、スタンバイ管理サービスが現在停止しており、プライマリ・リポジトリを指していることを前提としています。プライマリ・サイトへのプラグインのデプロイメントが正常に完了しました。

次の手順をスタンバイ管理サービスで実行します。

1. スタンバイ管理サーバーが停止していれば、起動します。
emctl start oms –admin_only

2. sysmanユーザーのパスワードを変更します。SYSパスワードも指定する必要があります。
emctl config oms -change_repos_pwd -use_sys_pwd -sys_pwd <sys_pwd>

3. スタンバイ管理サーバーを停止します。
emctl stop oms –all

I.2 スイッチオーバー操作とフェイルオーバー操作の管理

停止はアップグレードまたは定期メンテナンスの実行時に計画され、ハードウェアやソフトウェアの障害の場合、またはなんらかの環境の激変の場合に計画外の停止が起こります。停止のタイプにかかわらず、できるだけ早くITインフラストラクチャを復旧して実行状態にする必要があります。

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

- スイッチオーバー

- フェイルオーバー

I.2.1 スイッチオーバー

警告:
次のスイッチオーバーの手順は、スタンバイWebLogicドメイン障害時リカバリ・アプローチを使用するスタンバイOMS専用です。このアプローチは本来Enterprise Managerリリース12.1.0.2以前のインストールで使用されているものです。この付録で詳しく説明します。
Enterprise Managerリリース12.1.0.3以上で使用される記憶域レプリケーション障害時リカバリ・アプローチを使用するスタンバイOMSのスイッチオーバー手順は、第18章「Enterprise Manager障害時リカバリ」を参照してください。

スイッチオーバーは、プライマリ・サイトからスタンバイ・サイトに操作が転送される計画的なアクティビティです。これは、通常、障害リカバリ(DR)・シナリオのテストや検証、プライマリ・インフラストラクチャでの計画されたメンテナンス・アクティビティの場合に行われます。

この項では、スタンバイ・サイトへのスイッチオーバーの手順について説明します。どの方向にスイッチオーバーする場合も同じ手順が適用されます。

Enterprise Managerコンソールを使用して、管理リポジトリ・データベースのスイッチオーバーを行うことはできません。Data Guard BrokerコマンドラインのツールDGMGRLをかわりに使用します。

1. スタンバイ・データベースを準備します。
リカバリが最新であることを検証します。Enterprise Managerコンソールを使用して、「Data Guardの概要」ページの「スタンバイ・データベース」セクションでスタンバイ・データベースの「適用ラグ」列の値を表示できます。

2. プライマリEnterprise Managerアプリケーション層を停止します。
次のコマンドを各管理サービスで実行して、プライマリ・サイトのすべての管理サービス・インスタンスを停止します。

emctl stop oms -all

3. ソフトウェア・ライブラリの可用性の検証
プライマリ・サイトのすべてのファイルがスタンバイ・サイトで使用できることを確認します。

4. スタンバイ・データベースへのスイッチオーバー
DGMGRLを使用してスタンバイ・データベースへのスイッチオーバーを実行します。このコマンドはプライマリ・サイトでもスタンバイ・サイトでも実行できます。スイッチオーバー・コマンドは、プライマリ・データベースおよびスタンバイ・データベースの状態を検証し、ロールのスイッチオーバーに影響を与えます。古いプライマリ・データベースを再起動して新しいスタンバイ・データベースとして設定します。

SWITCHOVER TO <standby database name>;

スイッチオーバー後の状態を検証します。スタンバイ・データベースを完全に監視するには、データベースを監視するユーザーにSYSDBA権限が必要です。スタンバイ・データベースはマウント専用状態であるため、この権限が必要になります。プライマリ・データベースとスタンバイ・データベースを監視するユーザーに両方のデータベースのSYSDBA権限があればベスト・プラクティスになります。

SHOW CONFIGURATION;

SHOW DATABASE <primary database name>;

SHOW DATABASE <standby database name>;

5. 管理サーバーがスタンバイ・サイトでまだ稼働していない場合は起動します。
emctl start oms -admin_only

6. 各スタンバイ管理サービスで次のコマンドを実行して、スタンバイ管理サービスが新しいプライマリとなったスタンバイ・データベースを指し示すようにします。
emctl config oms -store_repos_details -repos_conndesc <connect descriptor of new primary database> -repos_user sysman

7. Enterprise Managerアプリケーション層を起動します。
スタンバイ・サイトのすべての管理サービスを起動します。

emctl start oms

8. 管理サービスと管理リポジトリ・ターゲットを再配置します。
管理サービスと管理リポジトリ・ターゲットは、プライマリ・サイトのいずれかの管理サービス上の管理エージェントで監視されます。スイッチオーバー/フェイルオーバー後にターゲットが監視されるようにするには、スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行して、そのターゲットをスタンバイ・サイトの管理サービスに再配置します。

emctl config emrep -agent <agent name> -conn_desc <connect descriptor of new primary database>

9. スタンバイSLBにスイッチオーバーします。
プライマリSLBをスタンバイSLBにフェイルオーバーするには、ネットワークの適切な変更を行います。つまり、クライアント(ブラウザおよび管理エージェント)で変更を行わずに、すべてのリクエストをスタンバイSLBで処理するようにします。

10. 古いプライマリ管理サービスを新しいスタンバイ管理サービスとして確立し、スイッチオーバー・プロセスを完了します。
古いプライマリ・サイトで管理サーバーを起動します。

emctl start oms -admin_only

これでスイッチオーバー操作は完了です。アプリケーションにアクセスし、サイトが完全に機能してプライマリ・サイトの機能と同じであるかどうかをテストします。これ以外の方向にスイッチオーバーする場合も同じ手順を繰り返します。

I.2.2 フェイルオーバー

警告:
次のフェイルオーバーの手順は、スタンバイWebLogicドメイン障害時リカバリ・アプローチを使用するスタンバイOMS専用です。このアプローチは本来Enterprise Managerリリース12.1.0.2以前のインストールで使用されているものです。この付録で詳しく説明します。
Enterprise Managerリリース12.1.0.3以上で使用される記憶域レプリケーション障害時リカバリ・アプローチを使用するスタンバイOMSのフェイルオーバー手順は、第18章「Enterprise Manager障害時リカバリ」を参照してください。

この項では、管理リポジトリ・データベースをすべての管理エージェントと再同期化し、フラッシュバック・データベースを使用して元のプライマリ・データベースをスタンバイとして有効にすることで、スタンバイ・データベースにフェイルオーバーして、Enterprise Managerのアプリケーション状態をリカバリする手順について説明します。

1. プライマリ・サイトでOMSコンポーネントが実行中である場合はすべて停止します。

2. ソフトウェア・ライブラリの可用性を検証します。
プライマリ・サイトのすべてのファイルがスタンバイ・サイトで使用できることを確認します。

3. スタンバイ・データベースにフェイルオーバーします。
プライマリ・サイトでデータベースを停止します。DGMGRLを使用してスタンバイ・データベースに接続し、FAILOVERコマンドを実行します。

FAILOVER TO <standby database name>;

フェイルオーバー後の状態を検証します。

SHOW CONFIGURATION;

SHOW DATABASE <primary database name>;

SHOW DATABASE <standby database name>;

フェイルオーバーの完了後、元のプライマリ・データベースを再度有効にしないかぎり、そのデータベースを新しいプライマリ・データベースのスタンバイ・データベースとして使用することはできません。

4. 管理サーバーがまだ稼働していない場合は、スタンバイ・サイトで管理サーバーを起動します。
emctl start oms -admin_only

5. 各スタンバイ管理サービスで次のコマンドを実行して、スタンバイ管理サービスが新しいプライマリとなったスタンバイ・データベースを指し示すようにします。
emctl config oms -store_repos_details -repos_conndesc <connect descriptor of new primary database> -repos_user sysman

6. 新しいプライマリ・データベースと管理エージェントを再同期化します。
Data Guardの最大保護または最大可用性レベルで実行している場合、フェイルオーバーでのデータ損失はないため、この手順を省略します。ただし、データ損失がある場合は、新しいプライマリ・データベースとすべての管理エージェントを同期化します。

スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行します。

emctl resync repos -full -name "<name for recovery action>"

このコマンドは、スタンバイ・サイトの管理サービスの起動時に各管理エージェントで実行される再同期化ジョブを発行します。

リポジトリの再同期化はリソース集中型操作です。管理リポジトリが十分に調整されていれば、操作はできるだけ早く完了できます。特に、My Oracle Supportのノート271855.1の説明に従ってアドバンスト・キューイング表に関連するIOT/索引を日常的にまとめていない場合、再同期化の前に手順を実行すると、再同期化プロセスを大幅に高速化できます。

7. Enterprise Managerアプリケーション層を起動します。
各管理サービスで次のコマンドを実行して、スタンバイ・サイトのすべての管理サービスを起動します。

emctl start oms

8. 管理サービスと管理リポジトリ・ターゲットを再配置します。
管理サービスと管理リポジトリ・ターゲットは、プライマリ・サイトのいずれかの管理サービス上の管理エージェントで監視されます。スイッチオーバー/フェイルオーバー後にターゲットが監視されるようにするには、スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行して、そのターゲットをスタンバイ・サイトの管理エージェントに再配置します。

emctl config emrep -agent <agent name> -conn_desc <connect descriptor of new primary database>

9. スタンバイSLBにスイッチオーバーします。
プライマリSLBをスタンバイSLBにフェイルオーバーするには、ネットワークの適切な変更を行います。つまり、クライアント(ブラウザおよび管理エージェント)で変更を行わずに、すべてのリクエストをスタンバイSLBで処理するようにします。

10. フラッシュバックを使用して元のプライマリ・データベースをスタンバイ・データベースとして設定します。
障害が発生したサイトへのアクセスがリストアされると、フラッシュ・バックデータベースが有効な場合、次の手順を使用して、元のプライマリ・データベースを、新しいプライマリ・データベースの物理スタンバイとして回復できます。

1. 元のプライマリ・サイトですべての管理サービスを停止します。
emctl stop oms -all

2. 元のプライマリ・データベースをマウント状態で再起動します。
shutdown immediate;

startup mount;

3. 元のプライマリ・データベースを回復します。
DGMGRLを使用して古いプライマリ・データベースに接続し、REINSTATEコマンドを実行します。

REINSTATE DATABASE <old primary database name>;

4. 新たに回復されたスタンバイ・データベースは、新しいプライマリ・データベースに対するスタンバイ・データベースとしての機能を開始します。

5. 回復後の状態を検証します。
SHOW CONFIGURATION;

SHOW DATABASE <primary database name>;

SHOW DATABASE <standby database name>;

11. 元のプライマリ管理サービスをスタンバイ管理サービスとして確立します。
古いプライマリ・サイトで管理サーバーを起動します。

emctl start oms -admin_only

12. リポジトリの再同期化を監視して完了します。
Cloud Controlコンソールの「管理サービスとリポジトリ概要」ページにナビゲートします。「関連リンク」で 「リポジトリの同期化」 をクリックします。このページには、管理エージェントごとに再同期化操作の進捗状況が表示されます。進捗状況を監視します。

このページでは、表示されたエラーの修正後に、失敗した操作を手動で再発行する必要があります。一般的に通信関連のエラーは管理エージェントの停止が原因で発生するため、管理エージェントの再起動後にこのページで操作を再発行することでエラーを修正できます。

たとえば、停止した古い管理エージェントなど、管理エージェントがなんらかの理由で起動できない場合、このページで操作を手動で停止する必要があります。再同期化は、すべてのジョブのステータスが「完了」または「停止中」になると完了とみなされます。

これでフェイルオーバー操作は完了です。アプリケーションにアクセスし、サイトが完全に機能してプライマリ・サイトの機能と同じであるかどうかをテストします。

サイトの操作を元のプライマリ・サイトに戻す必要がある場合は、スイッチオーバー手順を実行します。

J トラブルシューティング

この付録では、Enterprise Manager Cloud Controlの操作中に発生する可能性がある問題のトラブルシューティング方法について説明します。

- コンフィギュレーション・アシスタント障害のトラブルシューティング

- ADPとJVMD障害のトラブルシューティング

- パッケージに関する問題のトラブルシューティング

- 削除の失敗のトラブルシューティング

- 管理エージェント・インストール失敗のトラブルシューティング

J.1 コンフィギュレーション・アシスタント障害のトラブルシューティング

この項では、次のコンフィギュレーション・アシスタントが失敗した場合に参照する必要があるログ・ファイルと実行する必要があるアクションについて説明しています。

- プラグイン前提条件チェック・コンフィギュレーション・アシスタント

- リポジトリ・コンフィギュレーション・アシスタント

- リポジトリ即時使用可能コンフィギュレーション・アシスタント

- MDSスキーマ・コンフィギュレーション・アシスタント

- OMSコンフィギュレーション・アシスタント

- プラグインのデプロイおよびコンフィギュレーション・アシスタント

- Oracle Management Serviceの起動コンフィギュレーション・アシスタント

- プラグイン・インベントリの移行コンフィギュレーション・アシスタント

- Oracle Configuration Managerリピーター・コンフィギュレーション・アシスタント

- OMSのOCM構成コンフィギュレーション・アシスタント

- エージェント・コンフィギュレーション・アシスタント

- エージェント・アップグレード・コンフィギュレーション・アシスタント

- リポジトリ・アップグレード・コンフィギュレーション・アシスタント

- APMエンジン・コンフィギュレーション・アシスタントの停止

- 管理サーバー・コンフィギュレーション・アシスタントの停止

J.1.1 プラグイン前提条件チェック・コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.1.1 ログ・ファイル

次のログ・ファイルを参照します。

- $<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- $<OMS_HOME>/cfgtoollogs/pluginca/configplugin_prereq_check_<timestamp>.log

J.1.1.2 回避手順

1. 次のプラグイン前提条件チェック・コンフィギュレーション・アシスタントを実行します。
$<OMS_HOME>/oms/bin/pluginca -action prereqCheck -oracleHome <oms_home_path> -middlewareHome <middleware_home_path> -plugins <plugin_id>=<plugin_version>

注意:
プラグインが複数ある場合、プラグインの詳細をカンマで区切ってください。たとえば、-plugins <plugin_id>=<plugin_version>, <plugin_id>=<plugin_version>となります。

2. 次のコマンドを実行して、インストールを完了します。
$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

J.1.2 リポジトリ・コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.2.1 ログ・ファイル

次のログ・ファイルを参照します。

- $<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- $<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

注意:
<ACTION>は、スキーマ・アクションのいずれか(CREATE、TRANSX、MY_ORACLE_SUPPORTなど)を指しています。

J.1.2.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. 次のコマンドを実行して、管理リポジトリをクリーンアップします。
$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action drop -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>

注意:

- Microsoft Windowsの場合は、RepManager.batを起動してください。

- -action dropおよび-action dropallのサポートの詳細は、表2-3を参照してください。

3. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールする場合は、OMSホームからrunConfig.shスクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.3 リポジトリ即時使用可能コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.3.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

J.1.3.2 回避手順

1. 問題の原因を解決します。

注意:
管理リポジトリはクリーンアップまたは削除しないでください。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールする場合は、OMSホームからrunConfig.shスクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.4 MDSスキーマ・コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.4.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

詳細は、次のログ・ファイルを参照してください。

- <OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/mds.log

- $<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/rcu.log

J.1.4.2 回避手順

次の手順を実行します。

1. OMSホームから次のコマンドを実行して、MDSスキーマを削除します。
$<OMS_HOME>/sysman/admin/emdrep/bin/mdsschemamanager.pl -action=-dropRepository -connectString=<database_connect_string> -dbUser= <database_user> -dbPassword=<database_password> -oracleHome=<OMS_oracle_home> -mwHome=<middleware_home>

ここで、<database_connect_string>は、<database_host>:<database_port>:<database_sid>という形式にします。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールしている場合は、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.5 OMSコンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.5.1 ログ・ファイル

次のログ・ファイルを参照します。

- OMSコンフィギュレーション・アシスタントの実行開始前にインストーラが失敗した場合は、次のログ・ファイルを参照してください。
$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- OMSコンフィギュレーション・アシスタントの実行開始後にインストーラが失敗した場合は、次のログ・ファイルを参照してください。
$<OMS_HOME>/cfgtoollogs/omsca/omsca_<timestamp>.log

J.1.5.2 回避手順

次の手順を実行します。

1. ミドルウェア・ホームからJavaプロセスが実行されているかどうかを確認します。これを行うには、OMSが実行されているホストから次のコマンドを実行します。
ps -ef | grep java | grep <Oracle_Middleware_Home>

2. 次のコマンドを実行して、インストーラ関連のJavaプロセスを除くすべての実行中プロセスを停止します。インストーラ関連のJavaプロセスは一時ディレクトリから実行されるため、そのディレクトリからのプロセスは無視してかまいません。
kill -9 <process_id>

3. 次のコマンドを実行して、Oracle Management Serviceインスタンス・ベースを削除します。
rm -rf <OMS_Instance_Home>

4. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールしている場合は、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.6 プラグインのデプロイおよびコンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.6.1 ログ・ファイル

次のログ・ファイルを参照します。

- $<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- $<OMS_HOME>/cfgtoollogs/pluginca/configplugin_deploy_<timestamp>.log

J.1.6.2 回避手順

次のコマンドを実行して、プラグインのデプロイとコンフィギュレーション、およびインストールを完了します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

J.1.7 Oracle Management Serviceの起動コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.7.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

J.1.7.2 回避手順

次のコマンドを実行します。

$<OMS_HOME>/bin/emctl start oms

J.1.8 プラグイン・インベントリの移行コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.8.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

J.1.8.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールする場合は、OMSホームからrunConfig.shスクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.9 Oracle Configuration Managerリピーター・コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.9.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

J.1.9.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールしている場合は、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.10 OMSのOCM構成コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.10.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

J.1.10.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールしている場合は、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.11 エージェント・コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.11.1 ログ・ファイル

次のログ・ファイルを参照します。

- $<AGENT_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- secureが失敗した場合、次のログ・ファイルを参照してください。
$<AGENT_INSTANCE_HOME>/sysman/log/secure.log

- ログ・ファイルで、次の文を検索します。
重度: プラグイン構成に失敗しました。

この文が見つかった場合、次のログ・ファイルを確認してください。

$<AGENT_INSTANCE_HOME>/install/logs/agentplugindeploy_<timestamp>.log

J.1.11.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

サイレント・モードでインストールする場合は、管理エージェント・ホームから次のコマンドを実行します。

$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<agent_base dir_path> OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_upload_https_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password> -configOnly

注意:
EM_UPLOAD_PORT引数のHTTPSポート(セキュア・ポート)を入力してください。

J.1.12 エージェント・アップグレード・コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.12.1 ログ・ファイル

エージェント・アップグレード・コンフィギュレーション・アシスタントが失敗した場合、次のログ・ファイルを参照してください。

$<AGENT_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

J.1.12.2 回避手順

問題の原因を解決し、Enterprise Manager Cloud Controlコンソールの「ジョブ」ページからコンフィギュレーション・アシスタントを再実行してください。

注意:
ここで言及されている「ジョブ」ページは、Enterprise Manager Cloud Controlコンソールの以前のリリースに含まれるページを指しています。

J.1.13 リポジトリ・アップグレード・コンフィギュレーション・アシスタント

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.13.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

$<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

注意:
(<ACTION>は、PREUPGRADE、UPGRADE、TRANSXなど、スキーマ・アクションのいずれかを指しています。)

J.1.13.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールしている場合は、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.14 APMエンジン・コンフィギュレーション・アシスタントの停止

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.14.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

J.1.14.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールしている場合は、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.1.15 管理サーバー・コンフィギュレーション・アシスタントの停止

ログ・ファイルを確認して、推奨された回避手順を実行します。

J.1.15.1 ログ・ファイル

次のログ・ファイルを参照します。

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

J.1.15.2 回避手順

次の手順を実行します。

1. 問題の原因を解決します。

2. コンフィギュレーション・アシスタントを再実行します。
グラフィック・モードでインストールする場合は、Enterprise Manager Cloud Controlのインストール・ウィザードに戻り、「再試行」をクリックします。

「再試行」をクリックする前にインストーラを誤って終了した場合、同じ画面を表示するためにインストーラを再起動しないでください。かわりに、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを起動してください。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

サイレント・モードでインストールしている場合は、OMSホームからrunConfig.sh (Microsoft Windowsの場合はrunConfig.bat)スクリプトを再実行します。

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

runConfig.shスクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

注意:
Microsoft Windowsの場合は、runConfig.batを実行します。

J.2 ADPとJVMD障害のトラブルシューティング

この項では、ADP/JVMDエンジンおよびADP/JVMDエージェントのデプロイ中に発生するエラーのトラブルシューティング方法を説明します。

- ADPエンジン名の競合

- ADPエージェント・デプロイメントの失敗

- WebLogic Server 12.1.2でのADPエージェント・デプロイメントの失敗

- JVMDエージェント・デプロイメントの失敗

- エージェント・デプロイメント中のSSLハンドシェイクの失敗

- ADPエージェントのZipまたはJavadiagnosticagent.earのコピーの失敗

- JVMプール作成の失敗

J.2.1 ADPエンジン名の競合

エラーを確認して、回避手順を実行します。

J.2.1.1 エラー

ADPエンジンをインスタンス(例: EMGC_ADPENGINE2)が完全に削除されていない既存の管理対象サーバーにデプロイすると、同じ名前を持つADPエンジンの新しいデプロイメントは、次のエラーにより解凍ステップで失敗します。

@ Are you sure you haven't deployed adp engine to a managed server with name
@ <ADP_managed_server> already?

J.2.1.2 回避手順

既存の管理対象サーバーを完全に削除するには、次の手順を実行します。

1. 第23章に記載されている手順に従って、ADPエンジン・アプリケーション、およびADPアプリケーションがデプロイされている管理対象サーバーを削除します。

2. 管理対象サーバーが存在していたホスト・マシンに接続し、次の場所に移動して、管理対象サーバー(EMGC_ENGINE2)を手動で削除します。

$DOMAIN_HOME/<ADP_managed_server>

Where, $DOMAIN_HOME is the location of the Cloud Control domain

J.2.2 ADPエージェント・デプロイメントの失敗

エラーを確認して、回避手順を実行します。

J.2.2.1 エラー

ADPエージェントのデプロイ中、次のエラーにより、ターゲットへのADPエージェントのデプロイ・ステップで、デプロイ・ジョブが失敗する場合があります。

https://<host>:<port>/HttpDeployer/HttpDeployerServletに接続できませんでした

また、ターゲットへのHttpDeployerのデプロイ(前のステップ)の出力をチェックすると、次のメッセージを確認できます。

操作は保留中です。進行中の編集セッションがアクティブ化されるとアクティブ化され、取り消されるとこの操作は取り消されます。

J.2.2.2 回避手順

このエラーを修正するには、次の手順を実行します。

1. ADPエージェントをデプロイする予定だったドメインのWebLogic管理コンソールにログインします。

2. 「管理」ホームページで、「変更の保存」または「変更の破棄」をクリックし、ADPエージェントのデプロイを再度開始します。

J.2.3 WebLogic Server 12.1.2でのADPエージェント・デプロイメントの失敗

エラーを確認して、回避手順を実行します。

J.2.3.1 エラー

ADPエージェント・デプロイメントは、WebLogic Server12.1.2ターゲットで失敗します。

J.2.3.2 回避手順

ADPエージェントをデプロイするWebLogic Serverターゲットにwlfullclient.jarを作成し、ADPエージェントのデプロイを再試行します。

wlfullclient.jarの作成方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントの開発を参照してください。

J.2.4 JVMDエージェント・デプロイメントの失敗

エラーを確認して、回避手順を実行します。

J.2.4.1 エラー

ターゲットにJVMDエージェントをデプロイする際、SSLハンドジェイク障害が原因で「ターゲットへのHttpDeployerのデプロイ」ジョブの手順が失敗します。このエラーは、WebLogic Serverヲフトウェアに適切なパッチが適用されていない場合に発生します。

J.2.4.2 回避手順

Oracle WebLogic Serverソフトウェアに適切なパッチを適用してから、デプロイメントを再試行してください。Oracle WebLogic Serverのそれぞれのバージョンに対する適切なパッチについては、表J-1を参照してください。JVMDエージェントをOracle WebLogic Server 9.2.4以上またはOracle WebLogic Server 10.3.2以上へデプロイするときは、これらのバージョンにはすでに修正が含まれているため、パッチを適用する必要はありません。

表J-1 Oracle WebLogic Serverへ適用するパッチ

Oracle WebLogic Serverのバージョン

適用するパッチ

9.1.0

パッチ8422724

9.2.0

パッチ9384535

9.2.1

パッチ9032735

9.2.2

パッチ9309512

9.2.3

パッチ8849418

10.0.0

パッチ8422724

10.0.1

パッチ8895699

10.0.2

パッチ8896127

10.3.0

パッチ8715553

10.3.1

パッチ9003716

J.2.5 エージェント・デプロイメント中のSSLハンドシェイクの失敗

エラーを確認して、回避手順を実行します。

J.2.5.1 エラー

WebLogicドメインでデモ用の証明書を使用してSSLが有効化されている場合、SSLハンドシェイクの失敗によりエージェントのデプロイメントが失敗する可能性があります。一般的に、デモ用の証明書がAgentTrust.jksにないため次のエラーが発生します。

Certificate chain received from myhost.acme.com - 123.34.11.11 was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.

注意: WebLogicドメインが本番の資格証明を使用している場合、AgentTrust.jksは有名なCAから取得した信頼できる資格証明を持つため、この問題は発生しません。

J.2.5.2 回避手順

このエラーを修正するには、次の手順に従って、WebLogicのデモ用証明書を管理エージェントのキーストアにインポートします。

1. WebLogicのデモ用の証明書をcacertsファイルからエクスポートします。このファイルは、ミドルウェア・インストールのWebLogicホームの下の次の場所にあります。
keytool -export -keystore $WEBLOGIC_HOME/server/lib/cacerts -alias certgencab -file mycert.cer

パスワードを求めるプロンプトが表示されたら、Enterキーを押します。

2. 次のようにWebLogicのデモ用の証明書をOracle Management Agentのトラストストアにインポートします。
keytool -import -keystore $ORACLE_HOME/core/12.1.0.0.0/stage/sysman/config/montrust/AgentTrust.jks -alias wlscertgencab -file mycert.cer

プロンプトが表示されたら、パスワードwelcomeを入力し、[Enter]を押します。

証明書が正しくインポートされたか確認するために、次のコマンドを実行します。

keytool -list -keystore $ORACLE_HOME/core/12.1.0.0.0/stage/sysman/config/montrust/AgentTrust.jks

ここでの$ORACLE_HOMEはOracle Management Agentホームです。

パスワードを求めるプロンプトが表示されたら、[Enter]を押します。名前がwlscertgencabの証明書が現在の日付で生成されます。

J.2.6 ADPエージェントのZipまたはJavadiagnosticagent.earのコピーの失敗

エラーを確認して、回避手順を実行します。

J.2.6.1 エラー

OMSをインストールしたユーザーと管理エージェントが同じグループに存在しない場合、次のエラーにより、ADPエージェントのエージェントZipのコピー・ステップ、およびJVMDエージェントのJavadiagnosticagent Earのコピー・ステップでジョブが失敗します。

oracle.sysman.emSDK.emd.comm.RemoteOperationException: Error while streaming
JobReader:java.io.IOException: Broken pipe

J.2.6.2 回避手順

エラーを修正するには、OMSホストのユーザー資格証明を使用してEnterprise Managerエージェントをインストールします。

または

ジョブがOMSホスト・ユーザーによって実行されているとみなされるように、エージェント・ホストのsudoまたはPowerbroker設定を有効にします。

sudoまたはPowerbrokerの設定を行うには、次を実行します。

1. Cloud Controlで、「設定」メニューから「セキュリティ」を選択し「権限委任」をクリックします。

2. 「権限委任設定の管理」ページで、次を実行します。

1. タイプ・メニューから「Sudo」または「Powerbroker」を選択します。

2. ホスト名を入力するか、ホスト・ターゲットのリストから名前を選択します。選択したホストが管理エージェントに対応していることを確認します。このエージェントは、ADP/JVMDエージェントをデプロイする必要があるWebLogicドメインを監視するエージェントである必要があります。

3. 「実行」をクリックします。

J.2.7 JVMプール作成の失敗

エラーを確認して、トラブルシューティングのヒント手順を実行します。

J.2.7.1 エラー

JVMDエージェントのデプロイが成功しても、JVMターゲットまたはプールは作成されません。

J.2.7.2 トラブルシューティングのヒント

このエラーの原因として、次のことが考えられます。

- JVMDエージェントが接続しているJVMDエンジンが停止している。
JVMDエンジンを再起動して、「アプリケーション・パフォーマンス管理」ページをリフレッシュして、ターゲットまたはプールが作成されているかどうかを確認します。

- ジョブを送信したユーザーには、WebLogicインストールの一時ディレクトリへの書込み権限がない可能性があります。
一時ディレクトリへの書込み権限をユーザーに付与してデプロイを再試行するか、別のユーザー・アカウントでデプロイを再試行します。

- JVMDエージェントがデプロイされているホストから、JVMDエンジンのホストおよびポートに到達できない。
ネットワーク管理者に連絡して、ネットワーク問題を解決してください。ファイアウォールが設定されている場合、設定されているファイアウォールに対してJVMDエンジンのポートが開かれていることを確認してください。

- JVMDエージェント・デプロイメントのステータスが誤ってSuccessfulとマークされている。
JVMDエージェントのデプロイメントの各ジョブ手順を慎重に検証し、誤ったステータスの状態の原因となっている、未確認のエラーまたは例外が存在していないことを確認してください。

J.3 パッケージに関する問題のトラブルシューティング

Enterprise Manager Cloud Controlのインストール中に、次のエラー・メッセージが表示される場合があります。

Lin.X64 SUSE 10 : Backup fails with the given below error
install_driver(Oracle) failed: Attempt to reload DBD/Oracle.pm aborted.
Compilation failed in require at (eval 15) line 3.

このエラーが表示されたら、次のパッケージをインストールして再試行してください。

- libaio-32bit-0.3.104-14.2

- libaio-devel-32bit-0.3.104-14.2

J.4 削除の失敗のトラブルシューティング

第22.1.2.4項の説明に従って共有エージェントを削除する際、次のエラーが表示されることがあります。

SEVERE:The home <AGENT_HOME> cannot be deinstalled. Please deinstall all referenced home(s) <REFERENCE_HOME>

次に例を示します。

SEVERE:The home /tmp/agt_install/core/12.1.0.1.0 cannot be deinstalled. Please deinstall all referenced home(s) /tmp/agt_install/plugins

エラーが表示される場合、次の手順に従って共有エージェントを削除します。

1. 中央インベントリからデタッチする依存プラグインおよびsbinホームを識別します。

1. 共有エージェントがインストールされているホストで、中央インベントリから次のファイルを開きます。
<absolute_path>/oraInventory/ContentsXML/inventory.xml

2. <REFHOMELIST>と</REFHOMELIST>タグ内にリストされている依存プラグインをメモします。
次に例を示します。

<HOME NAME="nfs5515" LOC="/home/john/software/oracle/agent/core/12.1.0.0.0" TYPE="O" IDX="1">
<REFHOMELIST>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.oh.discovery.plugin_12.1.0.0.0"/>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.db.discovery.plugin_12.1.0.0.0"/>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.emas.discovery.plugin_12.1.0.0.0"/>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.oh.agent.plugin_12.1.0.0.0"/>
</REFHOMELIST>
</HOME>

3. <REFHOMELIST>と</REFHOMELIST>タグ内にリストされているsbinディレクトリをメモします。
次に例を示します。

<HOME NAME="nfs5515" LOC="/home/john/software/oracle/agent/core/12.1.0.0.0" TYPE="O" IDX="1">
<REFHOMELIST>
<REFHOME LOC="home/john/software/oracle/agent/sbin"/>
</REFHOMELIST>

4. 手順1 (b)で識別した依存プラグインを中央インベントリからデタッチします。これを行うには、共有エージェントがインストールされているホストに表示されるマスター・エージェント・ホームから次のコマンドを実行します。
$<AGENT_HOME>/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc <absolute_path>/oraInst.loc ORACLE_HOME=<plug-in_home> -nogenerateGUID

次に例を示します。

/home/john/software/oracle/agent/core/12.1.0.3.0/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc /home/john/software/oracle/agent/core/12.1.0.3.0/oraInst.loc ORACLE_HOME=/home/john/software/oracle/agent/plugins/oracle.sysman.emas.discovery.plugin_12.1.0.3.0 -nogenerateGUID

注意:
この手順では一度に1つのプラグインのみがデタッチされます。したがって、複数のプラグインがある場合、この手順を繰り返してその他の依存プラグインをデタッチします。

5. 手順1 (c)で識別したsbinホームを中央インベントリからデタッチします。これを行うには、共有エージェントがインストールされているホストに表示されるマスター・エージェント・ホームから次のコマンドを実行します。
$<AGENT_HOME>/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc <absolute_path>/oraInst.loc ORACLE_HOME=<sbin_home> -nogenerateGUID

次に例を示します。

/home/john/software/oracle/agent/core/12.1.0.3.0/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc /home/john/software/oracle/agent/core/12.1.0.3.0/oraInst.loc ORACLE_HOME=/home/john/software/oracle/agent/sbin -nogenerateGUID

2. 共有エージェントを削除します。これを行うには、共有エージェントがインストールされているホストに表示されるマスター・エージェント・ホームから次のコマンドを実行します。
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=<absolute_path_to_agent_instance_home> ORACLE_HOME=<absolute_path_to_agent_home>

次に例を示します。

/home/john/software/oracle/agent/core/12.1.0.3.0/perl/bin/perl /home/john/software/oracle/agent/core/12.1.0.3.0/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=/home/john/software/oracle/agent/agent_inst ORACLE_HOME=/home/john/software/oracle/agent/core/12.1.0.3.0

J.5 管理エージェント・インストール失敗のトラブルシューティング

管理エージェントのデプロイ中に、次の障害が発生する場合があります。

- 管理エージェントのインストールが失敗し、<ORACLE_HOME>/cfgtoollogs/agentDeploy/agentDeploy<TIMESTAMP>.logにある管理エージェント・デプロイメント・ログによりポート・チェックが失敗したことが示された場合、agentDeploy.shスクリプトを-ignorePrereqsオプションを使用して再度実行します。
また、ホストDNSセットアップの一部として一覧されたIPv6アドレスを持つホストに対するポート・チェックが失敗した場合、そのIPv6アドレスがホスト上で有効になっていることを確認してください。

- Microsoft Windowsホストでの管理エージェントのインストールが、setup.exeを実行できないというエラー・メッセージで失敗する場合は、管理者アカウントを使用してログインし、ホストでの管理エージェントのインストールを再試行します。

索引
A B C D E F G H I J K L M N O P Q R S T U V W X

A

アクセシビリティ, G

アクセシビリティ・モード, G.1

web.xmlファイルの構成, G.3

アクセシビリティ・モードの有効化, G.1

スクリーン・リーダーのサポート, G.4

uix-config.xml, G.2

web.xmlファイル, G.3

ACFSレプリケーション, 18.7 ホストの追加ログ・ファイル, B.2 「ホスト・ステータスの追加」ページ, 7.4.1.1 ホスト・ターゲットの追加ウィザード

概要, 2.1.7

ホスト・ターゲットの追加ウィザード, 1.3

ベスト・プラクティス, 2.1.7

提供されるインストール・タイプ, 2.1.7

管理サービスの追加デプロイメント・プロシージャ, 2.1.9 追加のOMS

インストール, 5

追加のスタンバイOMS, 削除, 24.1 ADP

データ要件, 11.3.1

データ保持ポリシー, 11.3.1

監視, 11.3.1

ADPエージェント

インストールの前提条件, 12.3

手動によるインストール, 12.4.2

概要, 12.1

インストール後のタスク, 12.5

削除, 23.1.2

インストール前の留意点, 12.2

インストールの検証, 12.5.1

ADPのアーキテクチャ, 12.1 ADPエンジン

証明書のインポート, 12.5.4

インストールの前提条件, 12.3

手動によるインストール, 12.4.1

概要, 12.1

インストール後のタスク, 12.5

削除, 23.1.1

インストール前の留意点, 12.2

インストールの検証, 12.5.1

ADP Manager, 11.3 adpagent.propertiesファイル, 12.4.2 エージェント・ベース・ディレクトリ, 2.3.5

要件, 6.3, 7.3

Agentホーム, 2.3.4 エージェントのインストール・ログ, B.2.4 エージェント・インスタンス・ディレクトリ, 2.3.6 エージェント・インスタンス・ホーム, A.4

権限, 6.3

要件, 6.3

Agentプラグイン・ホーム, 2.3.4 agent_inst, 2.3.6 AgentDeinstall.plスクリプト, 22.1.2.1 (agentDeploy.bat script, C.2 agentDeploy.shスクリプト, C.2

制限事項, 6.2

場所, 6.2

目的, 6.1

ソフトウェアのみのインストール, 9.1

agentDeploy.shスクリプトのサポートされているオプション, 6.4.9 AgentNFS.plスクリプト

別の方法, 8.4.3

目的, 8.1

レスポンス・ファイル, 8.4.3

AgentPull.shスクリプト, 6.1

レスポンス・ファイル, 6.4.5

AgentPull.shスクリプトのサポートされているオプション, 6.4.8 エージェント

多数の処理, 11.1.3.4

アラート, 11.2.4.5, 11.2.4.7 allroot.shスクリプト, 2.8.2, 4.4.1.2, 4.4.2.2 ApmEngineSetup.plスクリプト, 12.4.1, 13.4.1, 23.1.1.3, 23.2.1.3 アプリケーションの依存性とパフォーマンス

ADPエージェントの概要, 12.1

ADPエンジンの概要, 12.1

アーキテクチャ, 12.1

証明書のインポート, 12.5.4

インストールの前提条件, 12.3

ADPエージェントを手動でインストール, 12.4.2

ADPエンジンを手動でインストール, 12.4.1

インストール後のタスク, 12.5

ADPエージェントの削除, 23.1.2

ADPエンジンの削除, 23.1.1

インストール前の留意点, 12.2

インストールの検証, 12.5.1

アプリケーション・パフォーマンス管理, 10.16, 12.1 アプリケーション前提条件ログ, B.2.2 アプリケーション・サービス・レベル管理, 10.16, 10.16 アプリケーション・サービス管理, 12.1 補助テクノロジ, G 非同期I/O, 11.2.4.6

B

バックグラウンド・サービス, 15

基本リリース, 1.1

ベースライン, 11.2.2

ビーコン

構成、11.2.4.7

ビーコン, 11.2.4.7 BI Publisher, 14

管理, 14.10

アクセスの許可, 14.6

構成, 11.1.3.7

リポジトリ・アクセス, 14.13

トラブルシューティング, 14.14

BI Publisherのインストール, 14.2 BI Publisherセキュリティ・モデル, 14.6.5 BI Publisherサーバー, 追加, 20.3 BI Publisherサーバー, セカンダリの構成, 20.3.1 BI Publisherサーバー, 詳細, 20.5 BI Publisherサーバー, 追加, 20.3 BI Publisher, デバッグ, 14.14.5 BI Publisher, SSL, 14.9 ボトルネック

排除, 11.2.3, 11.2.4

チューニング, 11.2.4

バッファ・キャッシュ, 11.2.4.3 バッファ・キャッシュのサイジング, 11.2.4.3 バンドル・パッチ1, 1.1 business intelligence publisher, A.1.3

C

容量

予測, 11.2

中央インベントリ, 2.3.1, 6.3 cksumコマンド, 1.2.2.2, 1.2.2.2, 1.2.2.2 Cloud Control

デプロイメント, 11.2.1

評価する, 11.2.1, 11.2.2

サイズ設定, 11.2

サイジングの手法, 11.2

プラットフォームの起動, 11.2.1

バイタル・サイン, 11.2.2, 11.2.4.5

コールド・フェイルオーバー・クラスタ構成, H.1 コールド・フェイルオーバー・クラスタ, HA, H コマンド

データ・ファイルのコマンド

データ・ファイルの削除, 21.1.2

データ・ファイルの削除, 2.1.12 Enterprise Managerのコマンド

GUIモードでの削除, 21.1.3.1, 21.1.3.1

サイレント・モードでの削除, 21.1.3.2

管理エージェントのコマンド

GUIモードでのすべてのノードからの削除, 22.1.2.2

サイレント・モードでのすべてのノードからの削除, 22.1.2.3, 22.1.2.3

管理エージェントの停止, 21.1.1

OMSのコマンド

OMSの削除, 21.1.1

ファイル・サイズの確認, 1.2.2.2 コンフィギュレーション・アシスタント

1システムのアップグレードの場合, 2.4.2.2

異なるホストの1システム・アップグレードの場合, 2.4.2.2

2システムのアップグレードの場合, 2.4.2.2

追加のOMSのアップグレードの場合, 2.4.2.3

新規のインストールの場合, 2.4.2.1

アップグレードの場合, 2.4.2.2

概要, 2.4.1

失敗の解決, 2.4.3

デフォルトで実行, 2.4.2

構成情報, 2.1.4 構成ログ, B.1.2

一般, B.1.2.1

リポジトリ, B.1.2.2

SYSMANスキーマ操作ログ, B.1.2.2.1

configureBIPスクリプト, 14.2.1.1 ConfigureGC.shスクリプト, 4.4.1.3 コンソール・ポート, 2.1.10.1 コンソール・サービス, 15 コンソール限定モード, 15, 15 CPU

使用率, 11.2.4.1

使用量分析, 11.2.4.1

CPUしきい値, 11.2.4.1

D

データファイル, 2.1.11, 3.4.4

削除, 2.1.12

Oracle Management Repository用, 2.1.11

概要, 2.1.11

データベース

パラメータの変更, 11.1.3.6

データベース・ロック, 11.2.4.1 データベース・テンプレート

エラーの処理, 3.4.1, 4.4.2.3

概要, 3.2, 3.2, 4.2

インストーラでの詳細の指定, 4.4.1.3

レスポンス・ファイルでの詳細の指定, 3.4.4

ユーザー・アカウント・パスワードのリセット, 3.4.4, 3.4.4, 4.4.1.3, 4.4.1.3, 4.4.2.3.1, 4.4.2.3.1

データベース

Enterprise Managerのデータ・ファイル, 2.1.11

削除

GUIモードでの削除

管理エージェントの削除, 22

RPMファイルを使用してインストールした管理エージェントの削除, 22.1.2.5

複数OMSの削除, 21.1, 21.1.3.1

OMSの削除, 21

Oracle Management Agentの削除, 22.1.2.2

単一OMSの削除, 21.1, 21.1.3.1, 21.1.3.1

OMSを削除するための前提条件, 21.1.1

管理エージェントを削除するための前提条件, 22.1.1

OMSを削除するための前提条件, 21.1.2

サイレント・モードでの削除

管理エージェントの削除, 22.1.2.3

AgentDeinstall.plスクリプトを使用した管理エージェントの削除, 22.1.2.1

RPMファイルを使用した管理エージェントの削除, 22.1.2.5

複数OMSの削除, 21.1.3.2

共有エージェントの削除, 22.1.2.4

共有エージェントの削除, 22.1.2.4

単一OMSの削除, 21.1.3.2

OMSエントリのリポジトリからの削除, 21.3 Oracle Management Agentからのプラグインのアンデプロイ, 22.2 OMSからのプラグインのアンデプロイ, 21.2 ADPの削除

エージェント, 23.1.2

engine、23.1

JVMDの削除

エージェント, 23.2.2

engine、23.2

DemoTrust.jksキーストア, 13.4.2.5 deploy_adpagent.plスクリプト, 12.4.2 deploy_jvmdagent.plスクリプト, 13.4.2.1, 13.4.2.2 デプロイメント・プロシージャ, 2.1.9, 2.1.9, 5 デプロイメント・サイズ

デプロイメント・サイズの変更, 2.1.6

エラーの処理, 3.2, 3.4.1

前提条件チェックの実行, 2.1.6

インストーラでの選択, 4.4.1.3

小, 中, 大, 2.1.6, 4.4.1.3, 4.4.1.3

ターゲット数, エージェント数, セッション数, 2.1.6, 4.4.1.3

デプロイメント・サイズ

大規模, 3.4.4

中規模, 3.4.4

概要, 2.1.6

設定, 3.4.4

小規模, 3.4.4

SQLスクリプト, 2.1.6

ターゲット数、エージェント数、同時ユーザー・セッション数, 2.1.6

DHCP, 2.6.2 ディレクトリ, A.1, A.1.4

ミドルウェア共通ホーム・ディレクトリ, A.1

ミドルウェアWeb層ホーム・ディレクトリ, A.1

Oracle Business Intelligence Publisherホーム, A.1

Oracle Management Agentホーム・ディレクトリ, A.1

Oracle Management Agentプラグイン・ホーム, A.1

Oracle Management Serviceホーム・ディレクトリ, A.1

Oracle Management Serviceインスタンス・ホーム・ディレクトリ, A.1

Oracle Management Serviceプラグイン・ホーム, A.1

ディレクトリ構造, A

Oracle Management Agent, A.3

Oracle Management Service, A.2

Oracle Management Serviceホーム, A.1.4

無効化されたコミュニティ, G 障害時リカバリ, 18.1 dontProxyForプロパティ, 10.12 -downloadUpdatesコマンド, 2.1.5.6

E

E2E監視, 11.2.4.7

EMBIP*ロール

フォルダ/カタログ・オブジェクトへのアクセス権, 14.12

EMBIPAdministrator, 14.6.5 EMBIPAuthor, 14.6.5 EMBIPScheduler, 14.6.5 EMBIPViewer, 14.6.5 EMCLI, 6.4.2.1, 6.4.2.2, 6.4.3.1 emctlコマンド, A.4 エンドツーエンド監視, 11.2.4.7 Enterprise Manager

「Oracle Enterprise Manager」を参照

Enterprise Manager Cloud Control

基本概念, 2

コンフィギュレーション・アシスタント, 2.4

削除

MDSスキーマの削除, 21.1.2

SYSMANスキーマの削除, 21.1.2

概要, 21

サイレント・モード, 21.1.3.2

データ・ファイルの削除, 2.1.12 ディレクトリ構造, A グローバリゼーション・サポート, 2.1.13 インストール

概要, 2.1.3.1

ソフトウェアのみのインストール, 2.1.3.3

インストール・モード, 2.1.1 インストール・タイプ, 2.1.3 インストール・ウィザード, 2.1.2 ポート

コンソール・ポート, 2.1.10.1

ポートのカスタマイズ, 2.1.10.3, 2.1.10.4

デフォルト・ポート, 2.1.10.1

HTTPポート, 2.1.10.1

HTTPSポート, 2.1.10.1

概要, 2.1.10

アップロード・ポート, 2.1.10.1

前提条件チェック, 2.5 OTNからの入手

内容の抽出, 1.2.2.3

ファイル・サイズの確認, 1.2.2.2

プラットフォーム情報の確認, 1.2.2.5

リリース, 1.1 サイレント・インストール

拡張インストーラ・オプション, 3.4.2

ファクト, 3.2

インストール後の手順, 3.5

前提条件, 3.3

ソフトウェア

ダウンロード, 1

ソフトウェアのみのインストール

構成フェーズ, 4.1

ファクト, 4.2

グラフィック・モード, 4.4.1

インストール・フェーズ, 4.1

概要, 4.1

前提条件, 4.3

サイレント・モード, 4.4.2

アップグレード

概要, 2.1.3.2

Enterprise Managerコンポーネント, リカバリ, 19.6 Enterprise Manager Framework Security, 10.8

ファイアウォール環境, 10.1

Enterprise Manager前提条件キット, B.1.2.2.2 /etc/hostsファイル, 6.3

F

フェイルオーバー, 18.5.2

フェイルオーバー, I.2.2

フェイルオーバー, アクティブおよびパッシブ環境, H

フェイルオーバー, Enterprise Manager, H.3

フェイルオーバー, relocate_targets動詞, H.3

ファイル

RepManager.bat, 21.1.2

ファイアウォール構成, 10

ICMPおよびUDPトラフィックを許可, 10.16

管理エージェントへの通信の受信を許可, 10.7

ブラウザとCloud Controlコンソールの間, 10.4

Cloud Controlと管理対象データベース・ターゲットの間, 10.14

OMSとリポジトリの間, 10.13

デフォルト・ポート, 10.2

ICMPエコー・リクエストの有効化, 10.17

ポートの要件, 10.3

ファイアウォール, 10

ブラウザとCloud Controlの間, 10.4

Cloud Controlと管理対象データベース・ターゲットの間, 10.14

管理サービスと管理リポジトリの間, 10.13

構成の考慮事項, 10.1

Enterprise Managerコンポーネントの構成, 10.3

ICMP通信のための構成, 10.16

UDP通信のための構成, 10.16

ファイアウォールで保護されたホスト上のOMSの構成, 10.8

管理エージェントへの通信を受信できるようにするための構成, 10.7

OMSへのデータを受信できるようにするための構成, 10.10

デフォルト・ポート, 10.2

ICMPエコー・リクエストの有効化, 10.17

複数の管理サービスの場合, 10.15

複数のOMSインスタンスの場合, 10.15

最初のスタンバイOMS, 削除, 24.2 Fusion Middleware, 11.3

検出, 11.3

監視, 11.3

G

gc_inst, 2.3.3

グローバリゼーション・サポート, 2.1.13

グラフィック・モード, 2.1.1, 2.1.1

H

ハードウェア要件, 11.1.1.4

ヒープ・サイズ, 11.1.3.1, 11.1.3.1

変更, 11.1.3.5

高可用性, 16.1 高可用性, エージェント, 17.1 高可用性, BI Publisher, 20 高可用性, レベル, 16.2.1 高可用性, OMS, 17.3 高可用性, リポジトリ, 17.2 高可用性システム, 16 ホスト・リスト・ファイル, 2.8.1 HTTPポート, 2.1.10.1 HTTPSポート, 2.1.10.1 ハイパースレッディング, 11.2.4.1

I

ICMP, 10.16

初期化ログ, B.2.1

インストール・ログ

installActions, B.1.1

INSTALL_UPDATES_SELECTION変数, 3.2, 4.2 インストール

互換性マトリックス, 3.2, 4.2

サイレント・モードのインストール

追加のOMSのインストール, 5

レスポンス・ファイルの編集, 3.4.4

複数OMSのインストール, 3, 3.4.1

単一OMSのインストール, 3, 3.1, 3.4.1

ソフトウェアのみのインストール, 4.1 インストール・ベース・ディレクトリ

権限, 7.3

インストール・モード, 2.1.1 インストール・タイプ, 2.1.3 インストール・ウィザード, 2.1.2 インストーラ, 2.1.2 JVMDのインストール, 13 インスタンス・ディレクトリ

権限, 7.3

要件, 8.3

BI Publisherの統合, 14.2.1.1 Internet Control Message Protocol, 10.16 -invPtrLocパラメータ, 2.3.1 I/Oチャネル

監視, 11.2.4.6

I/Oスループット

監視, 11.2.4.6

J

jamagent.war, 13.4.2.1, 13.4.2.1

Java Development Kit

インストールされるデフォルトのバージョン, 3.2

サポートされるバージョン, 2.2

javadiagnosticagent.ear, 13.4.2.1, 13.4.2.1 JDK

ダウンロード, 3.2, 4.2

バージョンの確認, 4.2

JDKのバージョンの確認, 3.2 ジョブ, 11.2.4.5

バックログ, 11.1.3.2

JROCKIT, 3.2, 4.2 JVM診断

アーキテクチャ, 13.1

インストールの前提条件, 13.3

JVMDエージェントを手動でインストール, 13.4.2.1

スクリプトを使用してJVMDエージェントを手動でインストール, 13.4.2.2

JVMDエンジンを手動でインストール, 13.4.1

JVMDエージェントの概要, 13.1

JVMDデータベース・エージェント, 13.4.2.4

JVMDエンジンの概要, 13.1

インストール後のタスク, 13.5

JVMDエージェントの削除, 23.2.2

JVMDエンジンの削除, 23.2.1

インストール前の留意点, 13.2

JVMエンジン

インストール後のタスク, 13.5

JVMD, 11.3, 11.3.2

ヒープ・ダンプ, 11.3.2

監視, 11.3.2

スレッド・トレース, 11.3.2

JVMDエージェント

セキュアなポートへの接続, 13.4.2.5

インストールの前提条件, 13.3

高可用性のためのインストール, 13.4.2.3

手動によるインストール, 13.4.2.1

スクリプトを使用して手動でインストール, 13.4.2.2

スタンドアロンJVMへのインストール, 13.4.2.1

GlassFishへのインストール, 13.4.2.1, 13.4.2.2

JBossへのインストール, 13.4.2.1

OC4Jへのインストール, 13.4.2.1

Tomcatへのインストール, 13.4.2.1

WebLogic Serverへのインストール, 13.4.2.1, 13.4.2.2

Websphereへのインストール, 13.4.2.1

JVMDデータベース・エージェント, 13.4.2.4

概要, 13.1

インストール後のタスク, 13.5

削除, 23.2.2

インストール前の留意点, 13.2

JVMDのアーキテクチャ, 13.1, 13.1 JVMDエンジン

インストールの前提条件, 13.3

手動によるインストール, 13.4.1

概要, 13.1

削除, 23.2.1

インストール前の留意点, 13.2

jvmdagent_deploy.propertiesファイル, 13.4.2.1

K

キーストア, 13.4.2.5

L

ライセンス, 2.6.1

ロード・バランサ, 18.2.1.2

ローダー, 11.2.4.2

レポート, 11.2.4.2

ローダー・スレッド, 11.2.4.2

デフォルト値, 11.2.4.2

ロックされたユーザー・アカウント, 7.2 ログ

ホストの追加ログ, B.2.5

追加のOMSインストール・ログ, B.4

エージェントのインストール・ログ, B.2.4

アプリケーション前提条件ログ, B.2.2, B.2.2

cfgfw/*.log, B.2.4

構成ログ, B.1.2, B.1.2.1

deployfwk.log, B.2.5

EMPrereqKitログ, B.1.2.2.2

一般的な構成ログ, B.1.2.1

初期化ログ, B.2.1, B.2.1

インストール・ログ, B.1.1, B.1.1

install.log/.err, B.2.4

手動のエージェント・インストール・ログ, B.3

MDSスキーマ操作ログ, B.1.2.2.3

nfs_install.log/.err, B.2.4

Oracle Management Serviceのログ・ファイル, B.1.2.4

Oracle Management Serviceのログ, B.1.2.4

リポジトリ構成ログ, B.1.2.2

セキュア・ログ, B.1.2.3, B.1.2.3

SYSMANスキーマ操作ログ, B.1.2.2.1

システム前提条件ログ, B.2.3, B.2.3

ui.log, B.2.5

longPoolSize

変更, 11.1.3.5

longSystemPoolSize

変更, 11.1.3.5

M

管理エージェント

GUIモードでの削除

概要,22

削除後のタスク, 22.1.3

インストール

検証, 6.5, 8.5

レスポンス・ファイルを使用したインストール

レスポンス・ファイルの作成, 6.4.5, 6.4.6, 6.4.7

前提条件, 6.3

管理エージェント, 11.1.1.5, 11.2.2

ファイアウォールで保護されたホスト上の構成, 10.5

OMSからの通信を受信できるようにするための構成, 10.7

プロキシ・サーバーを使用するための構成, 10.6

管理エージェントのバックアップ, 19.5 管理エージェント・ホーム, 2.3.4 管理エージェントのパッチ適用

パッチの保存, D.1

パッチ適用の確認, D.2

管理リポジトリ, 11.2.4.1, 11.2.4.1, 11.2.5 リポジトリ・バックアップの管理, 19.3 管理サーバー

追加、11.2.4.5

管理サービス, 11.1.1.5

「Oracle Management Service」を参照

管理サービス, 追加, 17.3.3 マスター・エージェント, 8.1, 8.2 maxConnForJobWorkers

変更, 11.1.3.5

MDSスキーマ, 2.1.12, 21.1.2 MDSスキーマ作成ログ, B.1.2.2.3 MDSスキーマ削除ログ, B.1.2.2.3 mgmt_deepdive.dbfデータ・ファイル, 2.1.11 mgmt_ecm_depot1.dbfデータ・ファイル, 2.1.11 mgmt.dbfデータ・ファイル, 2.1.11 ミドルウェア・ホーム, 2.3.2

N

名前付き資格証明, 7.2

ネットワーク

待機時間, 11.1.1.5

トポロジに関する考慮事項, 11.1.1.5

new_install.rspレスポンス・ファイル, 3.4.1, 3.4.4 new_install.rspスクリプト, 4.4.2.3 ノード・マネージャ, 2.2.5 ノード・マネージャの資格証明, 2.2.5 通知, 11.2.4.5

O

OMSのバックアップ, 19.4

OMSホーム, 2.3.4

OMSインスタンス・ベースの場所, 2.3.3

OMSプラグイン・ホーム, 2.3.4

OMSプロパティ

変更, 11.1.3.5, 11.1.3.5

OMSサーバー, 11.2.4.8

中間層, 11.2.4.8

最適な数, 11.2.4.8

OMS, ロード・バランサの内側, 17.3.4 1システム・アップグレード, 2.1.3.2 OpenSSH, 7.2, 8.2 オペレーティング・システム・グループ, 6.3, 7.3, 8.3 オペレーティング・システム要件, 8.3 オペレーティング・システム・ユーザー, 6.3, 7.3, 8.3 サポートされるオペレーティング・システム, 6.3 Oracle Advanced Security, 10.13 Oracle BI Publisher

削除, 21.1.1, 21.1.1, 21.1.1

Oracle BI Publisherホーム・ディレクトリ, A.1.3 Oracle Business Intelligence, 14 Oracle Configuration Manager

有効化, 2.1.4.2

手動による収集, アップロード, 2.1.4.1

概要, 2.1.4

Oracle Enterprise Manager

ディレクトリ構造, A

ロールアップ・プロセス, 11.2.4.3

Oracle Enterprise Manager

チューニング, 11.2.4

Oracleホーム, 2.3.4 Oracleインベントリ・ディレクトリ, 2.3.1 Oracle Management Agent

クローニング

ファクト, 7.2

グラフィック・モード, 7.4.1

サイレント・モード, 7.4.2

概要, 7.1

クローニング後の手順, 7.5

前提条件, 7.3

サポートされる追加パラメータ, 7.4.1.3, 8.4.2

削除

概要,22

前提条件, 22.1.1

インストール

パッケージ, 6.3

サイレント, 6, 6.1, 6.2, 6.3, 6.4, 6.5

共有エージェントのインストール

ファクト, 8.2

グラフィック・モード, 8.4.1

サイレント・モード, 8.4.3

インストール後の手順, 8.5

前提条件, 8.3

ポート, 2.1.10.1 ソフトウェア, 1.3 ソフトウェアのみのインストール

構成, 9.5

ファクト, 9.2

インストール, 9.4

概要, 9.1

インストール後の手順, 9.6

前提条件, 9.3

Oracle Management Agentホーム・ディレクトリ, A.1.2 Oracle Management Service, B.1.2.1

プロキシ・サーバーを使用するための構成, 10.9

管理エージェントからデータを受信できるようにするための構成, 10.10

ファイアウォールで保護された場合の構成, 10.8

コンソール限定モード, 15, 15

My Oracle Supportへのアクセスの有効化, 10.11

Oracle Management Serviceホーム・ディレクトリ, A.1.1 Oracleミドルウェア・ホーム, 2.3.2 Oracle Netのファイアウォール・プロキシ・アクセス, 10.13 Oracleソフトウェア・ライブラリ

デフォルトの記憶域の場所, 4.4.1.3

有効な場所の入力, 4.4.1.3

Oracle WebLogic Server, 2.2

管理サーバー

管理サーバー・ポート, 2.2.6

既存の管理サーバー, 2.2.3

管理サーバーの起動, 2.2.8

管理サーバーの確認, 2.2.7

クラスタのサポート, 2.2.2 資格証明, 2.2.4, 2.2.4 インストールされているデフォルトのバージョン, 3.2, 4.2 ドメイン, 2.2.3 ログ・ファイルの出力, 2.2.1 手動インストール, 3.2 ノード・マネージャ, 2.2.5 前提条件パッチ, 3.2, 4.2 検証, 2.2.1 インストールの確認, 2.2.1 Oracle WebLogic Serverクラスタ, 2.2.2 oraInst.locファイル, 4.4.1.2, 4.4.2.2 oraInstroot.shスクリプト, 4.4.1.2, 4.4.2.2 oraInstRoot.shスクリプト, 2.8.2 oraInventory, 2.3.1 その他のインストール・ログ, B.2.5

P

パッケージ, 6.3, 8.3

ページ・パフォーマンス, 11.2.4.7

パッチ・セット1, 1.1

パッチ・セット2, 1.1

パッチ・セット3, 1.1

パッチ

Oracle WebLogic Serverの前提条件パッチ, 3.2, 4.2

管理エージェントへのパッチの適用

パッチの保存, D.1

パッチ適用の確認, D.2

権限, 6.3, 6.3 ホスト名の計画, 18.2.1.1 プラグイン・アップデート1, 1.1, 1.1 プラグイン, 2.1.8

ソースOMSのプラグインの特定, 5

ソースOMSへの追加プラグインのインストール, 5

プラグインの選択, 4.4.1.3, 5

インストールの確認, 6.5

plugins.txtファイル, C.1 ポート, 2.1.10, 4.4.1.3

4888, 10.10

4889, 10.10

管理サーバー・ポート, 2.2.6

管理サーバー・ポート, 2.1.10.1, 2.2.6

アプリケーションの依存性とパフォーマンスのJavaプロバイダ, 2.1.10.1

アプリケーションの依存性とパフォーマンスのリモート・サービス・コントローラ, 2.1.10.1

アプリケーションの依存性とパフォーマンスのRMIレジストリ, 2.1.10.1

コンソール・ポート, 2.1.10.1

カスタムのEMポート, 2.1.10.3

ポートのカスタマイズ, 2.1.10.3

インストール後のポートのカスタマイズ, 2.1.10.3

デフォルト・ポート, 2.1.10.1

HTTPポート, 2.1.10.1

HTTPSポート, 2.1.10.1

管理対象サーバー・ポート, 2.1.10.1

ノード・マネージャのポート, 2.1.10.1

Oracle BI Publisher, 2.1.10.1

Oracle Management Repository, 2.1.10.1

Real User Experience Insight, 2.1.10.1

アップロード・ポート, 2.1.10.1

空きポートの確認, 2.1.10.2

インストール後スクリプト, 7.3, 8.3 インストール前スクリプト, 7.3, 8.3 前提条件チェック

デフォルトのチェック, 2.5.1

概要,2.5

デフォルトで実行, 2.5.1

スタンドアロン・モードでの実行, 2.5.2

スタンドアロン・モードでの実行, 2.5.2

権限委任設定, 7.3, 7.4.1.1, 7.4.1.1, 8.3, 8.4.1, 8.4.1 プロパティ

設定, 11.1.3.5

プロキシ・サーバー

管理エージェントの構成, 10.6

管理サービスの構成, 10.9

例外の定義, 10.12

Q

停止モード, E.2

R

RACインスタンス

ワークロード, 11.2.4.4

リカバリ, Enterprise Manager, 19.6 管理エージェントのリダイレクト

前提条件, C.1

プロシージャ, C.2

リリース, 1.1 レプリケーション, ACFS, 18.7 RepManager, 2.1.12, E

概要, E.1

サポートされる操作およびコマンド, E.2

RepManagerユーティリティ, E RepManagerユーティリティ

サポートされる操作, E.2

drop, E.2

pluginpurge, E.2

preupgrade, E.2

resume, E.2

transX, E.2

upgrade, E.2

リポジトリ

要件, 11.3

可用性, 11.1.3.1, 11.1.3.3

リポジトリの高可用性, ベスト・プラクティス, 17.2.1 レスポンス・ファイル, 3.1 管理エージェント・バイナリの再利用

前提条件, C.1

プロシージャ, C.2

ロールアップ・プロセス, 11.2.4.3, 11.2.4.4

ガイドライン, 11.2.4.4

ロールアップ統計, 11.2.4.3 root.shスクリプト, 2.8.2

S

保護, 11.2.6

パフォーマンスの向上, 11.2.6

SAMPLE_adpagent.propertiesファイル, 12.4.2 SAMPLE_engine.propertiesファイル, 12.4.1, 13.4.1, 23.1.1.3, 23.2.1.3 schemanager, B.1.2.2.1 スクリーン・リーダー, G スクリプト, 2.8.2 Secure Socket Layer, BI Publisher, 14.9 セグメント・アドバイザ, 11.2.3.1 セグメント

正常な状態の維持, 11.2.3.1

自己更新コンソール, 1.3 共有エージェント

ターゲットの自動検出, 8.2

インスタンス・ディレクトリの構成, 8.2

概要, 8.1

共有Oracleホーム, 8.3 共有記憶域, BI Publisher, 20.2 shortPoolSize

変更, 11.1.3.5

サイレント・モード, 2.1.1 サイジング, 11.1

利点, 11

将来的な外挿, 11.2.5

ガイドライン, 11, 11.1.1

ハードウェア情報, 11.1.1.1

リポジトリ表領域, 11.1.2.4, 11.1.2.5

要件, 11.2.5, 11.3

ソフトウェア構成, 11.1.2

指定, 11.1.1.2

アップグレード・インストール, 11.1.1.3

ソフトウェア

ダウンロード, 3.2, 4.2

Enterprise Managerソフトウェアのダウンロード, 1.2

OTNからのダウンロード, 1.2.2

DVD, 1.2.1, 1.2.1.1

Enterprise Manager Cloud Control, 1.2

解凍, 1.2.2.3

Oracle Management Agent, 1.3

マウント・ポイントの設定, 1.2.1.2

プラットフォームの詳細の確認, 1.2.2.5

リリースの説明の確認, 1.2.2.4

ソフトウェア構成

評価, 11.1.2.1

大規模, 11.1.2.4

中規模, 11.1.2.3

小規模, 11.1.2.2

ソフトウェア・ライブラリのバックアップ, 19.2 ソフトウェア更新

インストールまたはアップグレード後の適用, 2.1.5.7

修正されたバグの詳細, 2.1.5.4

自動ダウンロード, 2.1.5.6

ユーザーによるダウンロード, 2.1.5.6

ダウンロード, 2.1.5.6

適用されたパッチの識別, 2.1.5.8

オフライン・モード, 2.1.5.6

オンライン・モード, 2.1.5.6

概要, 2.1.5, 2.1.5.1, 2.1.5.2

タイプ, 2.1.5.3

software_only.rspスクリプト, 4.4.2.1, 4.4.2.1.1 ソフトウェアのみのインストール, 2.1.3.3

概要, 4.1

ソフトウェア

ファイル・サイズの確認, 1.2.2.2

SSH, 7.2, 7.3, 8.2, 8.3 SSH公開鍵認証, 7.2, 8.2 SSH1, 7.2, 8.2 SSH2, 7.2, 8.2 スタンバイ・サイト, 同期, 18.6 起動スクリプト

概要, 2.7

staticports.iniファイル, 2.1.10.3, 2.1.10.3, 2.1.10.3, 2.1.10.4, 2.1.10.4 SUDO, 7.3, 7.3, 8.3, 8.3 スイッチオーバー, 18.5.1 スイッチオーバー, I.2.1 symlink, 3.2 SYSMANスキーマ, 2.1.12, 21.1.2 SYSMAN_APM, 4.4.1.3 SYSMAN_MDS, 4.4.1.3 SYSMAN_OPSS, 4.4.1.3 システム前提条件ログ, B.2.3 systemPoolSize

変更, 11.1.3.5

T

ターゲットの再配置, アクティブおよびパッシブ, H.1

一時ディレクトリ

権限, 6.3

スペース, 6.3, 7.3, 8.3

しきい値, 11.2.2, 11.2.2 翻訳言語, 2.1.13 トラブルシューティング

ADPマネージャ名の競合, J.2.1

ADPエージェントのZipまたはJavadiagnosticagent Earのコピー・ステップ, J.2.6

ADPエージェントのデプロイの失敗, J.2.2

SSLハンドシェイク・エラー, J.2.5

ADPとJVMDのトラブルシューティング, J.2 2システム・アップグレード, 2.1.3.2

U

UDP, 10.16

uix-config.xml, G.2

uix-config.xmlフラグ, G.2

ライセンスのないコンポーネント, 2.6.1

アップロード・ポート, 2.1.10.1

ユーザー・データグラム・プロトコル, 10.16

ユーザー・インタフェース

パフォーマンス, 11.2.4.7

ユーザー

同時, 11.1.3.1

V

バイタル・サイン, 11.2.4.8

I/O, 11.2.4.6

W

web.xml, G.3

web.xmlファイル, 13.4.2.1

空白, 3.2, 4.2

X

XML DB, 3.2, 4.2

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。