Oracle Enterprise Manager

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

13cリリース1

E70367-03(原本部品番号:E63674-04)

2017年6月

Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド, 13cリリース1

E70367-03

Copyright © 2014, 2017, Oracle and/or its affiliatesAll rights reserved.

原本協力者: 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.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.5 Enterprise Manager Cloud Controlソフトウェア更新とは

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

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

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

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

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

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

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

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

- 2.1.7 エージェント・ゴールド・イメージとは

- 2.1.8 エージェント・ゴールド・イメージ・コンソールとは

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

- 2.1.10 プラグインとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 2.3.5 エージェント・ホームとは

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

- 2.3.7 プラグイン・ホームとは

- 2.3.8 /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 13cリリース1ソフトウェア・バイナリのインストール(グラフィック・モード)

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

- 4.4.1.2 rootスクリプトの実行

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

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

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

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

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

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

- 4.4.2.2 rootスクリプトの実行

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

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

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

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

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

- 5.1 サイレント・モードでの追加のOracle Management Serviceのインストールについて

- 5.2 サイレント・モードでの追加の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 AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストール

- 6.4.2.1 AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストールの前提条件の確認

- 6.4.2.2 AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストール

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

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

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

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

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

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

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

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

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

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

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

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

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

- 6.4.11 ダウンロードした管理エージェント・ソフトウェアの内容

- 6.4.12 管理エージェントの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 共有エージェントのスタンドアロン・エージェントへの変換

- 9.1 NFSまたは共有エージェントのスタンドアロン・エージェントへの変換

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

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

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

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

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

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

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

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

11 エージェント・ゴールド・イメージのライフサイクルの管理

- 11.1 エージェント・ゴールド・イメージの用語

- 11.2 エージェント・ゴールド・イメージを使用して実行できる操作

- 11.3 エージェント・ゴールド・イメージ・コンソールの理解

- 11.4 管理エージェント・ベース・ディレクトリ構造の理解

- 11.4.1 ゴールド・イメージを使用して管理エージェントがプロビジョニングされた後のエージェント・ベース・ディレクトリ構造

- 11.4.2 ゴールド・イメージを使用して管理エージェントが12cから13cへアップグレードまたは更新された後のエージェント・ベース・ディレクトリ構造

- 11.5 エージェント・ゴールド・イメージのライフサイクルの管理

- 11.5.1 エージェント・ゴールド・イメージの作成

- 11.5.1.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージの作成

- 11.5.1.2 EM CLIを使用したエージェント・ゴールド・イメージの作成

- 11.5.2 エージェント・ゴールド・イメージの編集

- 11.5.3 エージェント・ゴールド・イメージの削除

- 11.5.4 エージェント・ゴールド・イメージ・バージョンの作成

- 11.5.4.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンの作成

- 11.5.4.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンの作成

- 11.5.5 エージェント・ゴールド・イメージ・バージョンの削除

- 11.5.5.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンの削除

- 11.5.5.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンの削除

- 11.5.6 エージェント・ゴールド・イメージ・バージョンのステージング

- 11.5.6.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンのステージング

- 11.5.6.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンのステージング

- 11.5.7 特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

- 11.5.7.1 「ゴールド・エージェント・イメージ」ホームページを使用した特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

- 11.5.7.2 EM CLIを使用して特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

- 11.5.8 特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

- 11.5.8.1 「ゴールド・エージェント・イメージ」ホームページを使用して特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

- 11.5.8.2 EM CLIを使用して特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

- 11.5.9 エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

- 11.5.9.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

- 11.5.9.2 EM CLIを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

- 11.5.10 エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

- 11.5.10.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

- 11.5.10.2 EM CLIを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

- 11.5.11 エージェント・ゴールド・イメージを使用した管理エージェントのプロビジョニング

- 11.5.12 エージェント・ゴールド・イメージ・バージョンを使用した管理エージェントの更新

- 11.5.12.1 エージェント・ゴールド・イメージによる管理エージェントの更新

- 11.5.12.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンによる管理エージェントの更新

- 11.6 エージェント・ゴールド・イメージ・アクティビティ詳細の表示

- 11.6.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・アクティビティ詳細の表示

- 11.6.2 EM CLIを使用したエージェント・ゴールド・イメージ・アクティビティ詳細の表示

- 11.7 エージェント・ゴールド・イメージ・コンプライアンス・レベルのチェック

- 11.8 エージェント・ゴールド・イメージの詳細の表示

- 11.8.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージおよびエージェント・ゴールド・イメージ・バージョンの詳細の表示

- 11.8.2 EM CLIを使用したエージェント・ゴールド・イメージの詳細の表示

- 11.9 エージェント・ゴールド・イメージに関連する通知の表示

- 11.10 保留中の更新のあるエージェント・ゴールド・イメージの表示

- 11.11 最後に変更されたエージェント・ゴールド・イメージの表示

- 11.12 エージェント・ゴールド・イメージに関連するログ・ファイルの表示

- 11.13 EM CLIを使用したサブスクライブ解除操作のステータスの表示

- 11.14 EM CLIを使用した指定エージェント・ゴールド・イメージをサブスクライブする管理エージェント・リストの表示

- 11.15 エージェント・ゴールド・イメージ更新ポリシーの作成および管理エージェント・アップグレード用に設定するデフォルト値の定義

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

- 12.1 Enterprise Managerシステムのファイアウォールの構成計画

- 12.2 Enterprise Managerシステムの標準ファイアウォール構成

- 12.3 WebブラウザとEnterprise Managerシステムの間のファイアウォールの構成

- 12.4 ファイアウォールで保護されたホスト上のOMSの構成

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

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

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

- 12.6 OMSと管理リポジトリの間のファイアウォールの構成

- 12.7 Enterprise Manager Cloud Controlコンソールと管理対象データベース・ターゲットの間のファイアウォールの構成

- 12.8 複数OMSインスタンスのファイアウォールの構成

- 12.9 My Oracle SupportにアクセスするためのOMSの有効化

- 12.10 dontProxyforプロパティの構成

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

- 12.12 ファイアウォールでのICMPエコー・リクエストの有効化

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

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

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

- 13.1.1.1 ハードウェア情報

- 13.1.1.2 サイジングの仕様

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

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

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

- 13.1.2 ソフトウェア構成

- 13.1.2.1 評価の構成

- 13.1.2.2 小規模の構成

- 13.1.2.3 中規模の構成

- 13.1.2.4 大規模の構成

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

- 13.1.3 追加の構成

- 13.1.3.1 大規模な同時UI負荷

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

- 13.1.3.3 OMSプロパティの変更

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

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

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

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

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

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

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

- 13.2.4.1 高いCPU使用率

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

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

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

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

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

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

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

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

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

- 13.3 Fusion Middlewareの監視に対するサイジングの要件の概要

14 OMSおよび管理エージェントの通信用プロキシの構成

- 14.1 OMSおよび管理エージェントの通信用プロキシの使用について

- 14.2 OMSから管理エージェントへの通信用プロキシの構成

- 14.3 管理エージェントのデプロイ後における管理エージェントからOMSへの通信用プロキシの構成

- 14.4 管理エージェントのデプロイ中における管理エージェントからOMSへの通信用プロキシの構成

- 14.5 OMSからMy Oracle Supportへの通信用プロキシの構成

- 14.6 OMSから管理エージェントへの通信用に構成されているプロキシの更新

- 14.7 OMSと通信するために既存プロキシに追加の管理エージェントを関連付け

- 14.8 OMSとの通信にプロキシを使用しないよう管理エージェントを除外

- 14.9 プロキシ名または管理エージェント別のプロキシ・リストの表示

- 14.10 OMSから管理エージェントへの通信用に構成されているプロキシのモニタリング

- 14.11 OMSから管理エージェントへの通信用に構成されているプロキシの削除

- 14.12 OMSおよび管理エージェントの通信用プロキシの構成のためのEM CLI動詞

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

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

- 15.2 JVMDエージェントのインストールを開始する前に

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

- 15.4 拡張インストール・オプションを使用したJVMDエージェントのデプロイ

- 15.4.1 jamagent.warのダウンロードとデプロイによる手動でのJVMDエージェントのデプロイ

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

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

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

- 15.5 JVMDエージェントのインストール後

16 Enterprise ManagerでのBI Publisherの構成

- 16.1 概要

- 16.1.1 BI Publisherの機能

- 16.1.2 制限事項

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

- 16.3 BI Publisherを含むEnterprise Managerの使用

- 16.4 BI Publisherへのアクセス経路

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

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

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

- 16.5.3 BI Publisherの権限

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

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

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

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

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

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

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

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

- 16.9 BI Publisherの管理

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

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

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

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

- 16.13.1 configureBIPの再実行

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

- 16.13.2.1 BI Publisherの自動構成

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

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

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

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

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

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

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

- 16.15 BISystemUser資格証明のリセット

- 16.16 BI Publisherサーバーおよび他のEnterprise Managerコンポーネントの管理

- 16.17 BI Publisherの使用

- 16.18 Enterprise Manager 13cリリース1とともにインストールされなかったBI Publisherの削除

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

- 17.1 「コンソール限定モード」でのOMSの稼働について

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

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

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

- 18.1 高可用性の最新情報

- 18.2 高可用性の定義

- 18.2.1 高可用性のレベル

- 18.3 可用性レベルの比較

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

19 Enterprise Managerの高可用性

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

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

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

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

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

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

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

- 19.3 Oracle Management Serviceの高可用性

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

- 19.3.1.1 概要および要件

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

- 19.3.1.3 別名ホスト名の構成

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

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

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

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

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

- 19.3.2.1 概要および要件

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

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

- 19.3.2.4 共有記憶域の設定

- 19.3.2.5 環境の設定

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

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

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

- 19.3.2.9 サービスの起動

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

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

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

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

- 19.3.4.2.1 SLB側の設定

- 19.3.4.2.2 Enterprise Manager側の設定

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

20 Enterprise Manager障害時リカバリ

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

- 20.2 設計上の考慮事項

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

- 20.2.1.1 ホスト名の計画

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

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

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

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

- 20.2.3.1 接続記述子に関する考慮事項

- 20.2.4 開始ポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

- 20.5.2 フェイルオーバーの手順

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

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

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

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

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

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

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

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

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

- 21.6.2 リカバリ・シナリオ

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

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

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

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

- 21.6.3 OMSのリカバリ

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

- 21.6.3.2 OMSの再作成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22 BI Publisherの高可用性

- 22.1 BI Publisherの高可用性の概要

- 22.2 共有記憶域デバイスを使用するBI Publisherの手動構成

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

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

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

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

第VII部 削除

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

- 23.1 削除の範囲

- 23.2 Enterprise Managerシステムの削除

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

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

24 Oracle Management Agentの削除

- 24.1 Oracle Management Agentの削除

- 24.1.1 スタンドアロンOracle Management Agentの削除

- 24.1.1.1 AgentDeinstall.plスクリプトを使用したスタンドアロン管理エージェントの削除

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

- 24.1.1.3 RPMファイルを使用してインストールしたスタンドアロン管理エージェントの削除

- 24.1.2 スタンドアロン管理エージェントの削除後

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

25 JVMDエージェントの削除

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

- 25.1.1 「設定」ページを使用したJVMDエージェントの削除

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

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

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

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

第VIII部 付録

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

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

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

- A.1.2 構成ログ

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

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

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

- A.1.2.2.2 EMPrereqKitログ

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

- A.1.2.3 セキュア・ログ

- A.1.2.4 Oracle Management Serviceログ

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

- A.2.1 初期化ログ

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

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

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

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

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

- A.4 エージェント・ゴールド・イメージのログ・ファイル

- A.5 追加のOMSインストール・ログ

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

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

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

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

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

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

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

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

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

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

- E.1 Oracle Harvester

- E.1.1 Oracle Harvesterの特徴

- E.1.2 Oracle HarvesterとOCM

- E.1.3 Enterprise Managerのサポート

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

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

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

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

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

- E.2 Oracle Configuration Manager

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- G.2.1 前提条件

- G.2.2 構成手順

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

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

- G.3 フェイルオーバー手順

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

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

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

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

索引

はじめに

『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 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)で公開されます。

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

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

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

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

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

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

部、章または項番号

変更内容の説明

16.7項

事前に必要な手順が変更されました。

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

E63674-02に追加された変更点

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

部、章または項番号

変更内容の説明

すべての章

すべての章が、最新の作成者キット・テンプレートで更新されましたが、これによる内容の変更はありません。

第3章、第4章

サポートされているデータベース構成タイプをリストしました。

第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 13cリリース1

基本リリース

2015年10月

- 13cリリース1の新規インストール

- 12cリリース5 (12.1.0.5)、12cリリース4 (12.1.0.4)、12cリリース3 (12.1.0.3)からアップグレード

13cの最初のリリース。

注意:
これらのリリースおよびサポートしているプラットフォームの詳細は、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ドライブに挿入し、.binファイルを実行します。

ソフトウェアが複数のDVDに収録されている場合は、アーカイブされているソフトウェアを各DVDからローカル・ディスク内にコピーします。その後、.binファイルを実行します。アーカイブされたファイル(ZIP)を抽出する必要はありません。.binファイルおよび.zipファイルとして保持します。

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ファイルの内容の抽出

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

OTNからEnterprise Manager Cloud Controlソフトウェアをダウンロードするには、次の手順に従います。

1. 製品をインストールするインストール・ユーザーとして、Enterprise Manager Cloud Controlソフトウェア・ファイルをダウンロードして格納するためのディレクトリを作成します。

2. 次のOTN URLにアクセスします。
http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html

3. 次のファイルをダウンロードします。

- UNIXプラットフォームの場合:

- em13100_linux64.bin

- em13100_linux64-2.zip

- em13100_linux64-3.zip

- em13100_linux64-4.zip

- em13100_linux64-5.zip

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

- setup_em13100_win64.exe

- setup_em13100_win64-2.zip

- setup_em13100_win64-3.zip

- setup_em13100_win64-4.zip

- setup_em13100_win64-5.zip

警告:

以前のリリースのEnterprise Manager Cloud Controlで行ったように、ダウンロードしたアーカイブ済ファイル(ZIP)の内容は抽出しないでください。.binファイルおよび.zipファイルとして保持します。

4. 製品をインストールするインストール・ユーザーとして、.binまたは.exeファイルのexecute権限を設定します。
たとえば、UNIXプラットフォームではem13100_linux64.binファイルのexecute権限を設定します。

chmod +x em13100_linux64.bin

5. execute権限が.binファイルまたは.exeファイルに正しく設定されていることを確認します。
たとえば、UNIXプラットフォームでは、次のコマンドを実行します。

ls -ltr

次のようにファイル権限をリスト表示する出力が表示されます。

-r-xr-xr-x 1 user1 group1 2032373759 Jul 14 03:57 em13100_linux64.bin
-r--r--r-- 1 user1 group1 2022925751 Jul 14 03:57 em13100_linux64-2.zip
-r--r--r-- 1 user1 group1 2046336073 Jul 14 03:57 em13100_linux64-3.zip
-r--r--r-- 1 user1 group1 653990632 Jul 14 03:57 em13100_linux64-4.zip
-r--r--r-- 1 user1 group1 653990632 Jul 14 03:57 em13100_linux64-5.zip

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

ZIPファイルをダウンロードした後、cksumコマンドをZIPファイルに対して実行し、ダウンロードしたソフトウェアのファイル・チェックサムが、OTNで表示されているファイル・チェックサムと同じであるかどうかを確認します。

UNIXプラットフォーム用13cリリース1には、次のZIPファイルの形式がリリースされています。ここで、<platform>はオペレーティング・システム、NはZIPファイルの番号です。たとえば、em13100_linux64-2.zip、em13100_linux64-3.zip、em13100_linux64-4.zipおよびem13100_linux64-5.zipです。

em13100_<platform>-N.zip (<value> bytes) (cksum - <value>)

同様に、Microsoft Windowsプラットフォーム用13cリリース1には、次のZIPファイルの形式がリリースされています。ここでNはZIPファイルの番号です。たとえば、setup_em13100_win64-2.zip、setup_em13100_win64-3.zip、setup_em13100_win64-4.zipおよびsetup_em13100_win64-5.zipです。

setup_em13100_win64-N.zip (<value> bytes) (cksum - <value>)

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

$ cksum em13100_<platform>-N.zip

次に例を示します。

$ cksum em13100_linux64-2.zip

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.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 13cリリース1であり、Linuxプラットフォーム上で実行されている場合、この場所に存在する管理エージェント・ソフトウェアもそのリリースおよびそのプラットフォーム用のものです。

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

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

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プラットフォームでインストール・ウィザードを起動するには、em13100_<platform>.binを起動します。Microsoft Windowsプラットフォームで起動するには、setup_em_win64.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 13cリリース1にアップグレードできます。

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)

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

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

アップグレードの場合、選択できるのは「1システムのアップグレード」方法のみです。「1システムのアップグレード」方法では、旧リリースのEnterprise Managerを実行しているホストでアップグレードを実行できます。この方法では、既存のデータベースの管理リポジトリもアップグレードされます。アップグレードが同じホスト上で行われるため、ある程度の停止時間が発生します。

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

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

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

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

2.1.4 Oracle Configuration Managerとは

Enterprise Manager Cloud Controlをインストールしている場合に、Oracle Configuration Managerを有効化することを選択できます。

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

また、Oracle Configuration Managerではハーベスタ機能が有効になります。これは、Enterprise Manager Cloud Controlによって監視されているターゲットの構成情報を自動的に収集し、定期的にOracleリポジトリにアップロードします。これによって、Enterprise Manager Cloud Controlによって管理されるターゲットのすべてのOracleホームで、Oracle Configuration Managerコレクタをインストールして構成する必要がなくなります。Oracle Configuration Managerおよびハーベスタ機能の詳細は、Configuration Managerインストレーションおよび管理ガイドを参照してください。

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

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

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

インストール・ウィザードを実行しているホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールが終了した後で、Oracle Configuration Managerを構成する準備が整ったら、次のコマンドをOMSホストのOracleホームから実行します。

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

$<OMS_HOME>/oracle_common/ccr/bin/configCCR

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

$<OMS_HOME>\oracle_common\ccr\bin\configCCR.exe

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 fileを解析し、必要なすべての更新をダウンロードするために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 Oracle Management Repositoryが事前構成されたデータベースでもソフトウェア更新が自動的に適用されるか

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

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

次のいずれかの方法でソフトウェア更新をダウンロードできます。

- ユーザーによるダウンロード(オフライン・モード): Enterprise Managerをインストールするホストに、My Oracle Supportに接続するインターネット接続がない場合に、このオプションを使用します。
ソフトウェア更新をダウンロードするには、次の手順に従います。

注意:
ソフトウェア更新は、インストーラを使用してダウンロードおよび適用してください。My Oracle Supportから直接ダウンロードしないでください。

1. インターネットが接続されているホスト上で、次の方法で-downloadUpdates引数を指定して、Enterprise Manager Cloud Controlインストール・ウィザードを起動します。この引数を使用すると、ソフトウェア更新のダウンロード専用にインストール・ウィザードが起動されます。このコマンドは、既存のOMSホームやデータベース・ホームからではなく、ダウンロードしたEnterprise Manager Cloud Control 13cリリース1ソフトウェアの場所から実行してください。
<Software_Extracted_Location/Disk1>./em13100_<platform>.bin -downloadUpdates

注意:

- Microsoft Windowsの場合は、setup_em_win64.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>/em13100_<platform>.bin SHOW_PROXY=true

- インストール・ウィザードによる自動ダウンロード(オンライン・モード): 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.6 インストールまたはアップグレード後にこれらのパッチをダウンロードおよび適用できるかどうか

理想的には、ソフトウェア更新は、Enterprise Managerシステムのインストールまたはアップグレード時にのみダウンロードして適用する必要があります。ソフトウェア更新は、インストールまたはアップグレード・プロセスに関する問題を修正するため、Enterprise Managerシステムのインストールまたはアップグレード時に必要になります。

例外は、Oracleにより提供されるデータベース・テンプレートを使用して事前構成されたOracle Management Repositoryがすでに存在するデータベースの詳細を提供する場合のみです。その場合、インストール後にデータベースの更新を手動でダウンロードして適用する必要があります。

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

適用されているパッチを識別するには、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基本インストレーション・ガイド』を参照してください。

- 選択したデプロイメント・サイズをこの画面で選択し、「次へ」をクリックします。エラーが発生した場合には、データベースのパラメータを手動で修正し、この画面に戻ってインストールを続けます。

前提条件チェックは選択内容に関係なく実行されますが、様々なパラメータに設定される値は、選択内容に応じてチェックされます。これらのデプロイメント・サイズおよびそれぞれに設定されているデータベース・パラメータの詳細は、第13章を参照してください。

特定のデプロイメント・サイズを指定してEnterprise Manager Cloud Controlをインストールした後で、ターゲット数、管理エージェント数または同時ユーザー・セッション数を増減することも可能です。ただし、選択したデプロイメント・サイズに適していないレベルまで数量を増やすと、パフォーマンスが低下する可能性があります。そのような場合は、第13章の説明に従い、必要なデプロイメント・サイズに合せてデータベース・パラメータを変更することをお薦めします。

2.1.7 エージェント・ゴールド・イメージとは

以前から、Enterprise Manager Cloud Controlでは、ホスト・ターゲットの追加ウィザード、EM CLI、レスポンス・ファイル(インストールを暗黙に実行する)など、管理エージェントをインストールする方法がいくつか提供されています。13cリリース1以降のEnterprise Manager Cloud Controlでは、環境での管理エージェントの一括デプロイメントおよびアップグレードに使用できるエージェント・ゴールド・イメージが提供されます。

エージェント・ゴールド・イメージは、構成がカスタマイズされた必要なバージョンの管理エージェント・ソフトウェア、必要なバージョンのモニタリング・プラグインおよび必要なパッチがある、Enterprise Managerで管理されているデータ・センター内での管理エージェントの理想的な状態を示します。

エージェント・ゴールド・イメージ・バージョンは、Enterprise Managerユーザーによって、徹底的にテストおよび調整されたライブ・リファレンス管理エージェントを使用して作成されます。エージェント・ゴールド・イメージ・バージョンを使用し、多数のホスト上で新しい管理エージェントのプロビジョニングまたは既存の管理エージェントの更新を行うことができます。

エージェント・ゴールド・イメージの詳細は、第11章を参照してください。

2.1.8 エージェント・ゴールド・イメージ・コンソールとは

エージェント・ゴールド・イメージ・コンソールは、Enterprise Manager Cloud Controlコンソールからアクセスできる多様なGUIを備えたアプリケーションで、エージェント・ゴールド・イメージのライフサイクルの管理に使用されます。エージェント・ゴールド・イメージの詳細は、第2.1.7項を参照してください。

エージェント・ゴールド・イメージ・コンソールを使用すると、ゴールド・イメージの作成または削除、ゴールド・イメージ・バージョンの作成、削除またはステージング、ゴールド・イメージ・バージョンの現在のバージョンまたは制限されたバージョンとしての設定、ゴールド・イメージに対する管理エージェントのサブスクライブの設定と解除を行うことができます。最も重要な操作は、新しい管理エージェントのプロビジョニングまたは既存の管理エージェントのアップグレードです。

エージェント・ゴールド・イメージ・コンソールの詳細は、第11.3項を参照してください。

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

ホスト・ターゲットの追加ウィザード(図2-2)は、Enterprise Manager Cloud Controlコンソールからアクセスできる、GUIが豊富なアプリケーションで、管理対象外ホストに管理エージェントをインストールし、これらをEnterprise Managerシステムの管理対象ホストに変換するために使用されます。

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

ホスト・ターゲットの追加ウィザードにアクセスするには次のいずれかを実行します。

- 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。「ターゲットの手動追加」ページで「ホストにエージェントをインストール」をクリックします。

- 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順にクリックします。「サーバー、ストレージおよびネットワーク」タブにある、「自動検出の結果」ページに表示されているリストから、監視するホストを選択し、「昇格」をクリックします。

このウィザードを使用すると、各種プラットフォームの複数のホストで、インストール前スクリプトおよびインストール後スクリプトを実行するオプションとともに、次のことが可能です。

- 新しい管理エージェントのデプロイ

- 十分にテストされパッチを適用した管理エージェントのクローニング

- 既存の中央で共有された管理エージェント(マスター・エージェント)を使用した、管理エージェント(共有エージェント)のインストール

ホスト・ターゲットの追加ウィザードは単一の管理エージェントをリモートでインストールするのに使用できますが、このウィザードは、管理エージェントの一括デプロイ、特に、異なるプラットフォームのホストに異なるリリースの管理エージェントを一括デプロイするのに最も適しています。このウィザードには、管理エージェントをインストールするホストを選択できる柔軟性があります。この方法は、1回の操作で複数のホストに管理エージェントをインストールする場合に便利です。

2.1.10 プラグインとは

プラグインは、既存のEnterprise Manager Cloud Controlデプロイにプラグインされて、Enterprise Managerのターゲット管理またはその他の垂直方向の機能を拡張できるモジュールです。

上位レベルで、プラグインにはOMSインスタンスおよび管理エージェントの監視および検出のアーカイブが含まれます。アーカイブには、JavaおよびSQLコード、そしてメタデータが含まれます。

詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

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

デプロイメント・プロシージャは、階層構造になった一連のプロビジョニングまたはパッチ適用のステップを含むプロシージャであり、各ステップには一連の他のステップが含まれることもあります。つまり、特定のライフサイクル管理アクティビティに対して実行する必要があるすべてのタスクのワークフローは、デプロイメント・プロシージャでカプセル化されます。

Enterprise Manager Cloud Controlにはデプロイメント・プロシージャがあり、これらはすべてCloud Controlコンソールからアクセスできます。Enterprise Manager Cloud Controlのインストールのコンテキストに含まれるデプロイメント・プロシージャの1つが、管理サービスの追加デプロイメント・プロシージャです。

管理サービスの追加デプロイメント・プロシージャ(図2-3)は、管理サーバー・ホストで実行中の既存のOMSを使用して追加のOMSのインストールを可能にすることにより、高可用性の要件を満たすのに役立ちます。

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

簡単に言えば、管理サービスの追加デプロイメント・プロシージャにより、使用環境に追加のOMSインスタンスをインストールできます。デプロイメント・プロシージャにより既存のOMSのクローンが作成され、その構成が接続先ホストにレプリケートされます。

Enterprise Managerの旧リリースでは、このインストール・タイプはEnterprise Managerインストール・ウィザードで提供されました。しかし、Enterprise Manager Cloud Controlリリースの場合、このインストール・タイプはデプロイメント・プロシージャとして提供されます。

デプロイメント・プロシージャの詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の追加管理サービスの追加に関する章を参照してください。

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

この項では、Enterprise Manager Cloud Controlのインストール時に使用されるデフォルト・ポートについて説明します。この項の具体的な内容は次のとおりです。

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

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

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

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

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

インストールに使用されるデフォルト・ポートを次に示します。

- Enterprise Manager Cloud Control

アップロード・ポート

コンソール・ポート

HTTPポート

4889から4898の範囲で使用可能な最初の空きポートが選択されます。

7788から7798の範囲で使用可能な最初の空きポートが選択されます。

HTTPSポート

1159
1159が使用できない場合、4899から4908の範囲で使用可能な最初の空きポートが選択されます。

7799から7809の範囲で使用可能な最初の空きポートが選択されます。

- Oracle Management Agent
管理エージェント用のデフォルトのアップロード・ポートは、3872です。HTTPとHTTPSの両方に同じポートが使用されます。3872が使用できない場合、1830から1849の範囲で使用可能な最初の空きポートが選択されます。

- 管理サーバー
管理サーバー用のデフォルトのHTTPSポートは、7101です。7101が使用できない場合、7101から7200の範囲で使用可能な最初の空きポートが選択されます。

- ノード・マネージャ
デフォルトHTTPSポートとして、7401から7500の範囲で使用可能な最初の空きポートが選択されます。

- 管理対象サーバー
デフォルトHTTPポートとして、7201から7300の範囲で使用可能な最初の空きポートが選択されます。

デフォルトHTTPSポートとして、7301から7400の範囲で使用可能な最初の空きポートが選択されます。

- JVM診断管理対象サーバー
SLBが構成されていない場合、Enterprise Manager Cloud Controlの前述のHTTPおよびHTTPSアップロード・ポートが使用されます。SLBが構成されている場合、SLBの「JVM診断」で構成されたポートが使用されます。または、SLB構成に加えて、HTTPアップロード・ポートがEnterprise Manager Cloud Controlで有効になっている場合、JVM診断エージェントがJVM診断エンジンと通信するためにHTTPアップロード・ポートも使用されます。

- Oracle BI Publisher
Oracle BI PublisherのデフォルトのHTTPポートは9701です。9701が使用できない場合、9701から9750の範囲で使用可能な最初の空きポートが選択されます。

Oracle BI PublisherのデフォルトのHTTPSポートは9801です。9801が使用できない場合、9801から9850の範囲で使用可能な最初の空きポートが選択されます。

- Oracle HTTP Server
Oracle HTTP ServerのデフォルトHTTPポートは9788です。9788が使用できない場合、9751から9800の範囲で使用可能な最初の空きポートが選択されます。

Oracle HTTP ServerのデフォルトHTTPSポートは9899です。9899が使用できない場合、9851から9900の範囲で使用可能な最初の空きポートが選択されます。

- Javaオブジェクト・キャッシュ(JOC)
デフォルトのJOCポートは23456です。23456が使用できないときにかわりのポートは使用されないため、ポート23456を空けておいてください。

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

ポートが空いているかどうかを確認するには、次のコマンドを実行します。

- UNIXの場合:
netstat -an | grep <port no>

- Microsoft Windowsの場合:
netstat -an|findstr <port_no>

2.1.12.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をインストールする場合、つまり第II部で説明されているインストール手順を使用する場合は、適切なカスタム・ポートを指定して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ホストのOracleホームから次のコマンドを実行します。
$<ORACLE_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アップロード・ポート

<ORACLE_HOME>/bin/emctl set property -name oracle.sysman.emSDK.svlt.ConsoleServerPort -value <http_upload_new>

HTTPSアップロード・ポート

<ORACLE_HOME>/bin/emctl set property -name oracle.sysman.emSDK.svlt.ConsoleServerHTTPSPort -value <https_upload_new>

HTTPコンソール・ポート

<ORACLE_HOME>/bin/emctl set property -name oracle.sysman.emSDK.svlt.EMConsoleServerPort -value <http_console_new>

HTTPSコンソール・ポート

<ORACLE_HOME>/bin/emctl set property -name oracle.sysman.emSDK.svlt.EMConsoleServerHTTPSPort -value <https_console_new>

3. OMSインスタンスのベース・ディレクトリ(通常はgc_inst)にある次のファイルのバックアップを作成します。
$<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ホストのOracleホームから次のコマンドを実行します。
$<ORACLE_HOME>/bin/emctl start oms

$<ORACLE_HOME>/bin/emctl status oms -details

6. OMSにサーバー・ロード・バランサ(SLB)が構成済の場合は、SLBプールやモニターなどのポートを更新します。

7. OMSがSSOまたはOAMを使用するように構成されている場合は、SSOまたはOAM構成を再実行します。

8. エージェント・インスタンス・ホーム(通常はagent_inst)にある次のファイルのバックアップを作成します。
$<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.12.4 Enterprise Manager Cloud Controlポートのカスタマイズ中の注意事項

staticports.iniファイル内にエラーがあると、インストール・ウィザードで警告が表示されずにデフォルト・ポートが使用されるため、このファイルを更新するときは細心の注意を払ってください。したがって、staticports.iniファイルの更新前に、次の点を確認してください。

- どのポートも1024以下の値に設定しないでください。1024までのポートは、通常、ルート・ユーザー(スーパーユーザー)用に予約されています。そのため、カスタマイズするポートは、必ず1024より大きい値に設定してください。

- ポートがコンポーネントまたは他のアプリケーションによってすでに使用されている場合は、staticports.iniファイル内にそのポート(使用中のポート)を入力しないでください。そうした場合、関連の構成アシスタントも失敗します。

- 複数のコンポーネントに同じポートを入力した場合、インストールでは前提条件チェック・フェーズの後にエラーが表示されます。インストールを続行する前に、このエラーを修正する必要があります。

- staticports.iniファイル内に構文エラーがある場合(等記号(=)文字が欠落している行がある場合)、インストール・ウィザードではその行が無視されます。このような行で指定されたコンポーネントには、インストール・ウィザードによりデフォルト・ポートが割り当てられます。インストール・ウィザードでは、構文エラーのある行に対する警告は表示されません。

- コンポーネント名のスペルを間違えた場合、インストール・ウィザードではそのコンポーネントにデフォルト・ポートが割り当てられます。ファイル内のコンポーネントの名前の大文字/小文字は区別されます。インストール・ウィザードでは、認識されない名前を含む行に対する警告は表示されません。

- ポート番号に数字以外の値を指定した場合、インストール・ウィザードではその行が無視され、コンポーネントにデフォルトのポート番号が割り当てられます。これは警告の表示なしに行われます。

- コマンドラインでパラメータのスペルを間違えた場合、インストール・ウィザードでは警告が表示されません。そのまま続行され、すべてのコンポーネントにデフォルトのポートが割り当てられます。

- コマンドラインでstaticports.iniファイルの相対パス(たとえば、./staticports.ini)を入力すると、インストール・ウィザードではそのファイルが見つかりません。警告が表示されずにそのまま続行され、すべてのコンポーネントにデフォルトのポートが割り当てられます。staticports.iniファイルのフルパスを入力する必要があります。

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

Oracle Management Repositoryの構成中に作成されるデータ・ファイルを次に示します。

mgmt.dbf

監視対象のターゲット、それらのメトリックなどの情報を格納します。

mgmt_ecm_depot1.dbf

監視対象ターゲットから収集される構成情報を格納します。

mgmt_deepdive.dbf

JVM診断およびアプリケーションの依存性パフォーマンス(ADP)関連の監視データを格納します。

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

データ・ファイルを削除するには、SYSMAN/MDSスキーマを削除する必要があります。これを行うには、OMSホストのOracleホームから次のコマンドを実行します。

$<ORACLE_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 <middleware_home> -oracleHome <middleware_home>

注意:

- Microsoft Windowsの場合は、RepManager.batを起動してください。

- 10gリリース2 (10.2.x.x)の管理リポジトリに属するスキーマを削除する場合は、次の引数を指定せずにコマンドを実行します。
-mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <middleware_ora_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のバージョン

サポートされるコマンド

13cリリース1、12cリリース5 (12.1.0.5)、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.15 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 13cには、Oracle WebLogic Server 12cリリース1 (12.1.3.0)およびJava Development Kit 1.7.0_80が必要です。これらは、新しいEnterprise Managerシステムをインストールするとき、インストール・ウィザードによって自動的にインストールされます。

注意:
事前にインストールされたOracle WebLogic ServerおよびJava Development KitはEnterprise Manager Cloud Control 13cではサポートされません。これらはインストール・ウィザードでインストールしてください。

この項では、Enterprise Manager Cloud Controlをインストールする前に知っておく必要のある、Oracle WebLogic Serverに関連する重要な側面について説明します。

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

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

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

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

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

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

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

Enterprise Manager Cloud Controlをインストールまたはアップグレードするときには、Oracle WebLogic Serverの資格証明(ユーザー名とパスワード)を入力するように要求されます。資格証明は、WebLogicドメインおよびその他の関連コンポーネント(管理サーバー、管理対象サーバー、ノード・マネージャなど)を作成するために使用されます。

WebLogicユーザー名は、WebLogicドメイン用の管理ユーザーとして使用されるデフォルト・ユーザー名です。デフォルトのユーザー名は、weblogicです。また、WebLogicパスワードは、このデフォルトの管理ユーザー・アカウントのパスワードです。

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

Enterprise Manager Cloud Controlをインストールまたはアップグレードするときには、デフォルトのノード・マネージャ・ユーザー・アカウントのパスワード、nodemanagerを入力するよう要求されます。パスワードは、ノード・マネージャの構成に使用されます。ノード・マネージャを使用すると、Oracle WebLogic Serverインスタンスのリモートでの起動、停止または再起動が可能になるため、ノード・マネージャは高可用性の要件を持つアプリケーションに推奨されます。

注意:
Microsoft Windowsでは、ノード・マネージャ・サービスは作成されません。これは予測されている動作です。

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

管理サーバー・ポートを見つけるには、emgc.propertiesファイルのAS_HTTPS_PORTパラメータに設定された値を表示します。このファイルは、Oracle Management Serviceインスタンス・ベースの場所にあります。

次に例を示します。

/DATA/oracle/gc_inst/em/EMGC_OMS1/emgc.properties

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

追加の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.5 管理サーバーの起動方法

次のコマンドを実行して管理サーバーを起動できます。このコマンドは基本的にはOMSを起動するために使用するものですが、そのOMSが実行されている管理サーバーも起動します。このため、OMSがすでに実行されていることがわかっていても、このコマンドを実行してください。

emctl start oms -admin_only

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

この項では、Enterprise Manager Cloud Controlまたはそのコア・コンポーネントのインストール時に入力する必要のあるインストール・ディレクトリについて説明します。この項の具体的な内容は次のとおりです。

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

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

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

- エージェント・ホームとは

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

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

- /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プラットフォームではサポートされません。
次に例を示します。

./em13100_<platform>.bin -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 ミドルウェア・ホームまたはOracleホームとは

Enterprise Manager Cloud Controlをインストールまたはアップグレードするときには、Oracleミドルウェア・ホームを入力する必要があります。

Oracleミドルウェア・ホームまたはOracleホーム(ミドルウェア・ホームまたはOracleホーム)は、Oracle WebLogic Serverホーム、Java Development Kit、OMS、Web層インスタンス・ファイルおよびその他の関連ディレクトリやファイルが含まれる親ディレクトリです。OMSおよびプラグインは、ここにデプロイされます。

次に例を示します。

/u01/software/em13c/oraclehome

注意:
12cリリース5 (12.1.0.5)以前には、主にミドルウェア・ホームとOMSホームに相当する2つのディレクトリがありました。ミドルウェア・ホームはOracle WebLogic Serverホーム、Java Development Kit、Web層インスタンス・ファイルおよびその他の関連ディレクトリやファイルを含む親ディレクトリですが、OMSホームはミドルウェア・ホーム内のサブディレクトリです。ここにOMSがインストールされ、いくつかのコマンドが実行されます。
ただし、13cリリース1以降では、ミドルウェア・ホームとOMSホームは個別のホームとしては表示されず、Oracleホームと呼ばれる1つのホームとして示されます。OMSホームのディレクトリの内容はミドルウェア・ホームに移されました。これにより、13cリリース1以降ではOracleホーム(またはOMSホーム)はミドルウェア・ホームを指します。以前、OMSホームで実行する必要があったすべてのコマンドは、現在はミドルウェア・ホームから直接実行する必要があります。

デフォルトでは、Java Development Kit (JDK) 1.7.0_80およびOracle WebLogic Server 12cリリース1 (12.1.3.0)が、ユーザーが指定するミドルウェア・ホームにインストール・ウィザードによってインストールされます。この場合、これらをインストールする新しいミドルウェア・ホームの絶対パスを入力します。

入力したパスが、UNIXプラットフォームの場合は70文字、Microsoft Windowsプラットフォームの場合は25文字を超えていないことを確認してください。また、入力するディレクトリに書込み権限があり、ファイルまたはサブディレクトリが存在しないことを確認してください。2システムのアップグレードの場合も、旧リリースのEnterprise Managerシステムに使用していた古いミドルウェア・ホーム・ディレクトリではなく、新しいミドルウェア・ホームの場所を入力します。

たとえば、22文字のみを含むミドルウェア・ホームのパスC:\sw\em13c\oraclehomeは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

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

Enterprise Manager Cloud Controlをインストールするときには、Oracle Management Serviceインスタンス・ベースの場所を入力する必要があります。

Oracle Management Serviceインスタンス・ベースの場所は、OMSの構成ファイルが格納されているミドルウェア・ホーム外のディレクトリです。デフォルトではgc_instがOracle Management Serviceのベースの場所です。ただし、必要な場合には、カスタム名の使用を選択できます。

インストール・ウィザードでは、組込みアルゴリズムを使用してこの場所が特定され、ユーザーが検証できるようにその場所が表示されます。ミドルウェア・ホームが/u01/software/em13c/oraclehomeの場合、デフォルトではOracle Management Serviceインスタンス・ベースの場所は次のとおりです。

/u01/software/em13c/gc_inst

デフォルトの場所を受け入れるか、または書込み権限のある別の場所を指定できます。

注意:
Oracleミドルウェア・ホームの詳細は、第2.3.2項を参照してください。

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

Enterprise Manager Cloud Controlおよびスタンドアロンの管理エージェントをインストールする際、インストール・ベース・ディレクトリ(基本的にはエージェント・ベース・ディレクトリ)の入力を求められます。

エージェント・ベース・ディレクトリは、Oracleミドルウェア・ホーム(Oracleホーム)外のディレクトリで、管理エージェント・ホームが作成されます。

次に例を示します。

/u01/software/em13c/agentbasedir

Microsoft Windowsではエージェント・ベース・ディレクトリのパスの文字数が25文字を超えないようにします。たとえば、22文字のみを含むエージェント・ベース・ディレクトリのパスC:\sw\em13c\agntbsedirは、使用できます。ただし、25を超える文字を含むC:\Oracle\ManagementAgent\12c\newは、使用できません。

2.3.5 エージェント・ホームとは

エージェント・ホームは、管理エージェントがインストールされるエージェント・ベース・ディレクトリ内のサブディレクトリです。

たとえば、エージェント・ベース・ディレクトリが/u01/software/em13c/agentbasedirの場合、デフォルトでは、エージェント・ホームは次のようになります。

/u01/software/em13c/agentbasedir/agent_13.1.0.0.0

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

エージェント・インスタンス・ディレクトリは、管理エージェント関連のすべての構成ファイルを格納するために作成される、エージェント・ベース・ディレクトリ内のサブディレクトリ(agent_inst)です。

たとえば、エージェント・ベース・ディレクトリが/u01/software/em13c/agentbasedirの場合、デフォルトでは、エージェント・インスタンス・ディレクトリは次のようになります。

/u01/software/em13c/agentbasedir/agent_inst

2.3.7 プラグイン・ホームとは

プラグイン・ホームは、ミドルウェア・ホームまたはエージェント・ベース・ディレクトリ内のサブディレクトリで、OMSや管理エージェントそれぞれに関連するプラグインがデプロイされます。

表2-4は、デフォルトのプラグイン・ホームが作成される場所を示しています。

表2-4 プラグイン・ホーム

コンポーネント

デフォルトのOracleホーム

場所の例

プラグイン(OMS固有のプラグイン)

$<ORACLE_HOME>/plugins/<pluginID_Version>

/u01/software/em13c/oraclehome/plugins/oracle.sysman.db.agent.plugin_13.1.0.0.0

プラグイン(エージェント固有のプラグイン)

$<AGENT_BASE_DIR>/plugins

/u01/software/em13c/agentbasedir/plugins

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

Enterprise Manager Cloud Controlのインストール・ウィザードを起動すると、自動的にいくつかの実行可能ファイルおよびリンク・ファイルがホスト上の一時ディレクトリにコピーされます。

たとえば、UNIXホストでは/tmpディレクトリが、Microsoft WindowsホストではC:\Tempがデフォルトで使用されます。

定期的に実行される他の多数のプロセスとともにcronジョブを実行するようにホストが設定されている場合、これらのジョブによってデフォルトの一時ディレクトリのクリーンアップが試行されます。このため、一部のファイルが削除され、インストール・ウィザードは失敗します。

ホストで自動的に実行されて一時ディレクトリをクリーンアップするcronジョブまたはプロセスがある場合は、必ず、TMPまたはTEMP環境変数をデフォルトの場所とは別の場所に設定してください。デフォルト以外の場所を設定する場合は必ず、ハード・ドライブ上のセキュアな場所、つまりクリーンアップ・ジョブが実行されない場所に設定してください。また、この代替ディレクトリへの書込み権限を持っていることも確認してください。

これは、インストーラを実行してEnterprise Manager Cloud Controlインストール・ウィザードを起動する前に行う必要があります。(UNIXオペレーティング・システムの場合はem13100_<platform>.binを起動し、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の新規インストールで実行されるコンフィギュレーション・アシスタント

新しいOMSのインストール時に実行されるコンフィギュレーション・アシスタントは次のとおりです。

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

- リポジトリ構成

注意:
オラクル社提供のデータベース・テンプレートを使用し、事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、リポジトリ・コンフィギュレーションのかわりに、リポジトリ即時使用可能コンフィギュレーションが実行されます。

- MDSスキーマ構成

注意:
オラクル社提供のデータベース・テンプレートを使用し、事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、MDSスキーマ構成は実行されません。

- BI Publisherスキーマ構成

- OMS構成

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

- BI Publisher構成

- Oracle Management Serviceの起動

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

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

OMSのアップグレード時に実行されるコンフィギュレーション・アシスタントは次のとおりです。

- APMエンジンの停止

- アップグレードの前提条件

- プラグインの前提条件

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

- MDSスキーマ構成

- BI Publisherスキーマ構成

- OMS構成

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

- BI Publisher構成

- Oracle Management Serviceの起動

注意:
管理エージェントはエージェント・アップグレード・コンソールを使用してアップグレードされるため、エージェント・コンフィギュレーション・アシスタントは実行されません。

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

その他のOMSのアップグレード時に実行されるコンフィギュレーション・アシスタントは次のとおりです。

- APMエンジンの停止

- アップグレードの前提条件

- プラグインの前提条件

- OMS構成

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

- BI Publisher構成

- Oracle Management Serviceの起動

注意:
管理エージェントはエージェント・アップグレード・コンソールを使用してアップグレードされるため、エージェント・コンフィギュレーション・アシスタントは実行されません。

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

オプションのコンフィギュレーション・アシスタントが失敗した場合、インストール・ウィザードではその失敗は無視され、自動的に次のコンフィギュレーション・アシスタントが実行されます。ただし、必須のコンフィギュレーション・アシスタントが失敗した場合は、インストール・プロセスが停止します。この場合、問題を解決して、構成アシスタントを戻す必要があります。

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

インストール・ウィザードを使用してEnterprise Manager Cloud Controlをインストールするたびに、一連の前提条件チェックが実行され、環境がインストール成功のための最小要件を満たしているかどうかが確認されます。インストール・ウィザードによって、必要なオペレーティング・システム・パッチ、オペレーティング・システム・パッケージ、カーネル・パラメータを含む様々な要素が確認されます。

次の各項で、これらの前提条件チェックについて説明します。この項の具体的な内容は次のとおりです。

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

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

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

異なるインストール・タイプ(Enterprise Managerシステムの新規作成および既存のEnterprise Managerシステムのアップグレード)で実行されるデフォルトの前提条件チェックは、次のとおりです。

- インストールが動作保証済のオペレーティング・システムで実行されているかどうかを確認するための前提条件チェック。

- すべての動作保証済パッケージおよびライブラリがインストールされているかどうかを確認するための前提条件チェック。

- glibcパッケージがインストールされているかどうかを確認するための前提条件チェック。

- tempディレクトリに十分なディスク領域があるかどうかを確認するための前提条件チェック。

- インベントリ・ディレクトリに十分なディスク領域があるかどうかを確認するための前提条件チェック。

- インベントリ・ディレクトリに書込み権限があるかどうかを確認するための前提条件チェック。

- ソフトウェアが現在のオペレーティング・システムと互換性があるかどうかを確認するための前提条件チェック。

- 十分な物理メモリーがあるかどうかを確認するための前提条件チェック。

- 必須のulimit値を確認するための前提条件チェック。

- ホスト名を確認するための前提条件チェック。

- LD_ASSUME_KERNEL環境変数が設定されているかどうかを確認するための前提条件チェック。

- 適切なタイムゾーンが設定されているかどうかを確認するための前提条件チェック。

- 4GBのスワップ領域があるかどうかを確認するための前提条件チェック。

- http_proxy環境変数が設定されているかどうかを確認するための前提条件チェック。設定されないことが理想です。

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

インストール・ウィザードの起動前に、スタンドアロン・モードで前提条件チェックを実行できます。これにより、インストールの失敗の原因となる問題を特定して解決できます。

警告:

Oracle製品がインストールされていないホストで、前提条件チェックをスタンドアロン・モードで実行すると、中央インベントリのハード・ディスク容量をチェックする前提条件チェックが失敗します。ホスト上にOracle製品がインストールされていないため、これは予測された失敗です。この失敗は無視して、実際のインストールを続行できます。

表2-5に、スタンドアロン・モードで前提条件チェックを実行するために実行する必要のあるコマンドを示します。

表2-5 スタンドアロン・モードでの前提条件チェックの実行

インストール・タイプ

コマンド

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

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

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

<Software_Location>/em13100_<platform>.bin -prereqchecker -entryPoint "oracle.sysman.top.oms_Core" -prereqLogLoc <absolute_path_to_log_location> -silent -waitForCompletion

注意:
Microsoft Windowsの場合は、setup_em_win64.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が起動されます。

$<ORACLE_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-4に示す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. $<AGENT_HOME>/install/unix/scripts/gcroot.shファイルのSTART_PRIORITY_LEVELおよびSHUT_PRIORITY_LEVELパラメータを編集します。
これらのパラメータの詳細は、表6-4を参照してください。

4. 管理エージェント・ホームから、次のroot.shスクリプトを実行します。
$<AGENT_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ファイルを削除し、<AGENT_HOME>/install/unix/scripts/gcroot.shファイルにあるSTART_PRIORITY_LEVELおよびSHUT_PRIORITY_LEVELパラメータを編集して、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ホストのOracleホームからallroot.shスクリプトを実行します。
<ORACLE_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 13cのソフトウェア・バイナリおよびOMSインスタンス・ホーム・ファイル(gc_inst内の構成ファイル)を格納できます。ただし、OCFSは汎用ファイルシステムとみなさないため、このような用途での使用は考慮されていません。

警告:

Enterprise Manager Cloud Control 13cを、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システムのインストールを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているインストールの重要なポイントを理解してください。

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レスポンス・ファイルの編集

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

サイレント・モードで完全なEnterprise Managerシステムをインストールするには、次の手順を実行します。

注意:
インストーラを起動する前にEM前提条件キットを実行し、リポジトリの前提条件をすべて満たしていることをあらかじめ確認することをお薦めします。手動で実行していない場合でも、製品のインストール中はインストーラによってバックグラウンドで実行されています。ただし、事前に手動で実行すると、インストールまたはアップグレード・プロセスを開始できる前に、管理リポジトリが設定されます。キットの詳細とその実行方法、実行される前提条件チェックについては、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。
ただし、オラクル社提供のデータベース・テンプレートを使用して事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、EM前提条件キットの起動中に次のパラメータを渡します。

-componentVariables repository:EXECUTE_CHECKS_NOSEED_DB_FOUND:false

1. インストーラを起動して、サイレント・インストールを実行するために使用する必要があるレスポンス・ファイルを生成します。
./em13100_<platform>.bin -getResponseFileTemplates -outputLoc <absolute_path_to_a_directory_to_store_the_generated_response_file>

注意:
このコマンドによって3つのレスポンス・ファイルが生成されます。このサイレント・インストールではnew_install.rspファイルのみを使用する必要があります。

2. new_install.rspファイルを編集し、表3-2に示されたパラメータに適切な値を入力します。

3. インストーラをサイレント・モードで起動し、更新したレスポンス・ファイルを渡します。
(Unixでは、必ず作成したoinstallグループに属するユーザーとしてインストーラを起動します。オペレーティング・システム・グループおよびユーザーの作成の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。)

- これがホストにインストールする最初のOracle製品である場合は、次のコマンドを実行します。
./em13100_<platform>.bin -silent -responseFile <absolute_path_to_the_directory_where_the_generated_and_updated_response_file_is_stored>/new_install.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

- 最初のOracle製品でない場合は、次のコマンドを実行します。
./em13100_<platform>.bin -silent -responseFile <absolute_path_to_the_directory_where_the_generated_and_updated_response_file_is_stored>/new_install.rsp

注意:

- UNIXプラットフォームでインストール・ウィザードを起動するには、em13100_<platform>.binを起動します。Microsoft Windowsプラットフォームで起動するには、setup_em_win64.exeを起動します。

- インストーラでは一時ディレクトリに約10GBのハード・ディスク領域が必要です。一時ディレクトリにこの容量がない場合は、-J-Djava.io.tmpdirパラメータを渡して、10GBの領域があるかわりのディレクトリを指定します。
このパラメータで指定されたディレクトリは、デプロイメント・プロシージャに関連するソフトウェア・ライブラリ・エンティティをコピーするためのプロビジョニング・アドバイザ・フレームワーク(PAF)ステージング・ディレクトリの場所としても使用されます。PAFステージング・ディレクトリは、プロビジョニング・アクティビティのみに使用されます(デプロイメント手順に関連するエンティティがコピーされ、これらの手順が終了すると削除されます)。

次に例を示します。

./em13100_linux64.bin -J-Djava.io.tmpdir=/u01/software/em13c/stage/

- Enterprise Manager Cloud Controlソフトウェアをダウンロードして実行するディレクトリの名前に空白文字が含まれていないことを確認します。たとえば、EM Softwareという名前のディレクトリの場合、2つの語の間に空白文字が含まれているため、このディレクトリからはソフトウェアをダウンロードしないでください。

- オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合、選択したデプロイメント・サイズに合せるにはデータベース・パラメータを変更する必要があることを示すメッセージが表示されます。これは、テンプレートは基本的に簡易インストール用に設計され、データベース・パラメータは簡易インストールの要件に応じて設定されているためです。詳細インストールに使用する場合は、パラメータを別の値に設定する必要があります。メッセージを確認して続行します。インストール・ウィザードによって、自動的にパラメータが必要な値に設定されます。

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第3.4.2項を参照してください。

注意:
サーバー・ロード・バランサ(SLB)が環境に構成され、アップロード・ポートがロックされている場合、JVMDエンジンに対してSLBを構成し、OMSを保護します。
SLBが環境に構成されているが、アップロード・ポートのロックが解除されている場合、JVMDのトラフィックにSLBを経由させるかどうかを決定します。そのようにする場合、JVMDエンジンに対してSLBを構成し、OMSを保護します。

OMSを保護するには、OMSホストのOracleホームから次のコマンドを実行します。

<ORACLE_HOME>/bin/emctl secure oms -host <SLB host>-slb_jvmd_http_port <JVMD_SLB_HTTP_Port> -slb_jvmd_https_port <JVMD_SLB_HTTPS_Port> -sysman_pwd <system_password> -reg_pwd <agent_registration_password>

3.4.2 サイレント・モードでEnterprise Managerシステムをインストールするためにサポートされている拡張インストーラ・オプション

インストーラの起動中に渡すことができる追加の拡張オプションの一部は、次のとおりです。

- デフォルトでは、デプロイメント・プロシージャに関連するソフトウェア・ライブラリ・エンティティをコピーするためにプロビジョニング・アドバイザ・フレームワーク(PAF)ステージング・ディレクトリが作成されます。デフォルトでは、この場所はスクラッチ・パスの場所(/tmp)です。この場所はプロビジョニングのアクティビティにのみ使用されます。エンティティはデプロイメント・プロシージャ用にコピーされ、デプロイメント・プロシージャが終了すると削除されます。
カスタムの場所でこの場所をオーバーライドする場合、-J-Djava.io.tmpdirオプションを使用してインストーラを起動し、一意のカスタムの場所を入力します。

次に例を示します。

./em13100_linux64.bin -J-Djava.io.tmpdir=/u00/install/em/STAGE/ -silent -responseFile /u01/software/em/response/new_install.rsp

- インストールが正常に終了すると、OMSおよび管理エージェントが自動的に起動されます。これらを自動的に起動しないようにする場合は、START_OMSとSTART_AGENTのオプションを指定してインストーラを呼び出し、制御する対象に応じて、それらをtrueまたはfalseに設定します。
たとえば、管理エージェントを自動的に起動しない場合、次のコマンドを実行します。

./em13100_<platform>.bin START_OMS=true START_AGENT=false -silent -responseFile <absolute_path>/new_install.rsp

この拡張オプションに関連する制限を理解するには、第3.4.3項を参照してください。

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

OMSと管理エージェントの自動起動方法を制御する拡張オプションとしてSTART_OMSとSTART_AGENTを使用する場合、管理エージェントおよびそれがインストールされたホストがCloud Controlコンソールでターゲットとして表示されないことがあります。

表3-1は、これらの拡張オプションの異なる組合せおよび各組合せの回避策を示しています。

表3-1 拡張オプションおよび回避策

拡張オプション

回避策

START_OMS=false

START_AGENT=false

1. OMSを起動します。
$<ORACLE_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

START_AGENT=false

管理エージェントを起動します。

$<AGENT_HOME>/bin/emctl start agent

START_OMS=false

START_AGENT=true

1. OMSを起動します。
$<ORACLE_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-2は、編集する必要がある変数およびサイレント・モードでEnterprise Manager Cloud Controlをインストールするためのnew_install.rspレスポンス・ファイルでの編集方法を示しています。

表3-2 サイレント・モードでEnterprise Managerシステムをインストールするためのnew_install.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ディレクトリまで含めた絶対パスを二重引用符で囲んで入力します。

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 12cリリース1 (12.1.3.0)およびJava Development Kit (JDK) 1.7.0_80をインストールする場所を入力します。ミドルウェアの場所に書込み権限があることを確認します。ミドルウェアの場所は、基本的に13cリリースの1つのみのOracleホームであることに注意してください。

たとえば、"/u01/software/em13c/oraclehome"です

注意: ミドルウェア・ホームのパスの文字数が、Unixプラットフォームでは70文字、Microsoft Windowsプラットフォームでは25文字を超えていないことを確認してください。

たとえば、22文字のみを含むミドルウェア・ホームのパスC:\sw\em13c\oraclehomeは、使用できます。ただし、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ミドルウェア・ホーム外の場所)への絶対パスを入力します。

たとえば、"/u01/software/em13c/agentbasedir"です。

この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

注意: (Microsoft Windowsのみ)エージェント・ベース・ディレクトリのパスの文字数が、25文字を超えていないことを確認してください。たとえば、22文字のみを含むエージェント・ベース・ディレクトリのパスC:\sw\em13c\agntbsedirは、使用できます。ただし、25を超える文字を含むC:\Oracle\ManagementAgent\12c\newは、使用できません。

PLUGIN_SELECTION

文字列リスト

はい

(プラグイン名のカンマで区切ったリスト、プラグイン名は二重引用符で囲む必要があります)

デフォルトでは、Oracle Database Plug-in、Oracle Fusion Middleware Plug-in、Oracle Exadata Plug-in、Oracle Cloud Framework Plug-in、Oracle System Infrastructure Plug-inなどの必須プラグインは、Enterprise Managerシステムとともに自動的にインストールされます。

デフォルトのプラグインに加えてその他のプラグインをデプロイする場合は、それらのプラグインの名前をカンマ区切りリストで指定します。プラグインの名前は二重引用符で囲んでください。

13cリリース1でのみサポートされ、後続のリリースではサポートされない非推奨のプラグインをデプロイしようとする場合は、選択内容を確認し、そのプラグインのデプロイメントを続行するかどうかを決めます。

次に例を示します。

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

ソフトウェア・キット(DVDまたはダウンロードしたソフトウェア)にないプラグインをインストールする場合は、次の手順を実行します。

1. 必要なプラグインを次の場所から手動でダウンロードします。
http://www.oracle.com/technetwork/oem/extensions/index.html

また、パートナまたはカスタマ用のプラグインをダウンロードする場合は、次の場所からダウンロードします。

https://apex.oracle.com/pls/apex/f?p=53891:1

2. 次のオプションを使用してインストーラを起動し、追加のプラグインがダウンロードされた場所を渡します。
./em13100_<platform>.bin PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>

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項を参照してください。

DATABASE_HOSTNAME

文字列

はい

既存のデータベースが常駐するホストの完全修飾名を入力します。ホスト名にアンダースコアがないことを確認します。

たとえば、"example.com"です。

オラクル社提供のdデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスをすでに作成している場合は、そのデータベース・インスタンスの詳細を指定します。

Oracle RAC Databaseに接続する場合、ノードに仮想ホスト名が含まれていれば、ノードの1つの仮想ホスト名を指定します。

この仮想ホスト名のみで構成された接続文字列を使用してデータベースへの接続が確立され、インストールは正常に終了します。

ただし、クラスタの他のノードの接続文字列を更新する場合、インストール後に次のコマンドを実行します。

$<ORACLE_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リスナーを使用した接続文字列を入力できます。

ACFSを使用する場合は、ACFSディスクをマウントするクラスタに次のパラメータがあることを確認し、/etc/fstabファイルのインストールを開始します。

<mount_points_of_ACFS_storage> nfs rw,bg,hard,intr,nolock,rsize=32768,wsize=32768,tcp,noacl,vers=3,timeo=300,actimeo=120

次に例を示します。

example.com:/emfs/mpoint/oms1 /scratch/u01/oms nfs rw,bg,hard,intr,nolock,rsize=32768,wsize=32768,tcp,noacl,vers=3,timeo=300,actimeo=120

注意: オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、SYSMAN_PASSWORDパラメータに入力したSYSMANパスワードで自動的にリセットされます。

LISTENER_PORT

文字列

はい

既存のデータベースに接続するためのリスナー・ポートを入力します。

たとえば、"1521"です。

SERVICENAME_OR_SID

文字列

はい

既存のデータベースのサービス名またはシステムID (SID)を入力します。

たとえば、"orcl"などです。

プラガブル・データベース(PDB)の詳細を指定する場合は、別名ではなく完全なサービス名を使用してください。たとえば、pdb.example.comです。単独プラガブル・データベース(単独PDB)の詳細を指定する場合は、完全なサービス名を使用してください。たとえば、pdb.example.comです。非コンテナ・データベース(非CDB)の詳細を指定する場合は、SIDを使用してください。

SYS_PASSWORD

文字列

はい

SYSユーザー・アカウントのパスワードを入力します。

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基本インストレーション・ガイド』を参照してください。

SYSMAN_PASSWORD

文字列

はい

SYSMANユーザー・アカウントを作成するパスワードを入力します。このパスワードは、SYSMANユーザー(管理リポジトリ・スキーマのプライマリ所有者)を作成する場合に使用します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、このパラメータに入力したSYSMANパスワードで自動的にリセットされます。

SYSMAN_CONFIRM_PASSWORD

文字列

はい

SYSMANユーザー・アカウントのパスワードを確認します。

AGENT_REGISTRATION_PASSWORD

文字列

はい

OMSと管理エージェントの間の通信を保護するには、パスワードを入力します。管理エージェントを保護するためのパスワードと同じ登録パスワードを入力する必要があります。

AGENT_REGISTRATION_CONFIRM_PASSWORD

文字列

はい

エージェント登録パスワードを確認します。

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)に関連する監視データを格納するために、このデータ・ファイルが必要です。

CONFIGURE_ORACLE_SOFTWARE_LIBRARY

ブール

いいえ

インストール時にソフトウェア・ライブラリを構成するには、このパラメータをTRUEに設定します。それ以外の場合には、FALSEに設定します。

インストール時に構成しない場合でも、インストールは成功し、後ほどEnterprise Manager Cloud Controlコンソールからいつでも構成できます。ただし、インストーラによって自動的に構成が行われ、時間と労力を省くことができるため、インストール時にソフトウェア・ライブラリ構成することをお薦めします。

SOFTWARE_LIBRARY_LOCATION

文字列

はい

CONFIGURE_ORACLE_SOFTWARE_LIBRARYをTRUEに設定した場合、ソフトウェア・ライブラリを構成できるOMSホスト上に、一意のディレクトリ名となる絶対パスを入力します。入力する場所はOMSホスト上にマウントされた場所で、ミドルウェア・ホーム外であることを確認してください。また、OMSプロセスの所有者にその場所に対する読取り/書込みアクセス権があることも確認してください。マウントされた場所で構成を行うと、追加のOMSインスタンスのインストール時に役立ちます(インスタンスが、同じOMS共有ファイルシステムの記憶域の場所への読取り/書込みアクセス権を必要とするため)。

CONFIGURE_SHARED_LOCATION_BIP

ブール

いいえ

デフォルトでインストールおよび構成されるOracle BI Publisherの共有の場所を構成します。これには、パラメータをTRUEに設定します。

共有記憶域の場所は、レポート・カタログおよび現在インストールしている最初のOMSおよび今後インストールする予定の追加のOMSに関連する管理情報を格納するための共通の場所として機能します。

Oracle BI Publisherのために使用する共有場所を特定します。既存の共有場所がない場合、新たに作成し、最初のOMSをインストールするホストおよび追加のOMSインスタンスをインストールする予定のホストでそれが認識されることを確認します。

インストールが成功するように、インストール時に共有ディレクトリ用のハードディスク・ドライブを約400MB予約できます。ただし、追加のプラグインをインストールしたり、さらに多くのレポートを作成するにつれて、領域の使用率は時間とともに増えていくため、最終的に少なくとも10GBに拡張し、将来的にはさらに拡張できるようにすることをお薦めします。

CLUSTER_LOCATION

文字列

はい

これは、CONFIGURE_SHARED_LOCATION_BIPパラメータがTRUEに設定される場合のみ設定します。

Oracle BI Publisherが高可用性環境で動作するためにOracle BI Publisherスケジューラ記憶域が保持される共有記憶域の場所にある/clusterディレクトリまでのパスを指定します。たとえば、/u01/software/examplehost/shrd/BIP/clusterです。

CONFIG_LOCATION

文字列

はい

これは、CONFIGURE_SHARED_LOCATION_BIPパラメータがTRUEに設定される場合のみ設定します。

Oracle BI Publisherリポジトリおよび構成ファイルが格納される共有記憶域の場所にある/configディレクトリまでのパスを指定します。たとえば、/u01/software/examplehost/shrd/BIP/configです。

ENABLE_BI_PUBLISHER

ブール

いいえ

インストールおよび構成されているOracle BI Publisherを有効または無効にします。Oracle BI Publisherを有効にすると、ソフトウェアが起動され、Enterprise Managerシステム内で使用するための準備が整えられます。Oracle BI Publisherを無効にすると、ソフトウェアは起動されずにそのままになります。

Oracle BI Publisherを有効にするにはこのパラメータをTRUEに設定します。無効にするにはこのパラメータをFALSEに設定します。

STATIC_PORTS_FILE

文字列

はい

デフォルトでは、第2.1.12項で説明されているポートが適用されます。デフォルトのポートを受け入れる場合は、このフィールドを空白のままにしておきます。

カスタム・ポートを使用する場合、インストールに使用されるカスタム・ポートをリストしているstaticports.iniファイルの絶対パスを入力します。

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 13cのソフトウェア・バイナリおよびOMSインスタンス・ホーム・ファイル(gc_inst内の構成ファイル)を格納できます。ただし、OCFSは汎用ファイルシステムとみなさないため、このような用途での使用は考慮されていません。

警告:

Enterprise Manager Cloud Control 13cを、SPARCシリーズのサーバー(T1000、T2000、T5xx0およびT3-*)にインストールしないでください。詳細は、My Oracle Supportのノート1590556.1を参照してください。

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

Enterprise Manager Cloud Controlのソフトウェア・バイナリのみインストールして、既存の動作保証済Oracle Databaseで動作するよう後で構成できます。この方式では、インストール・プロセスを主にインストール・フェーズと構成フェーズの2つのフェーズに分割できます。当然のことながら、インストール・フェーズは、バイナリのコピーのみなので、構成フェーズに比べて時間はかかりません。この方式により、時間と優先度に従ってインストールを計画できます。

インストール・フェーズの実行中、インストーラを起動してOracleホームを作成し、次のようにインストールします。

- Oracle WebLogic Server 12cリリース1 (12.1.3.0)をインストールします。

- Java Development Kit (JDK) 1.7.0_80をインストールします。

- Oracle Management Service 13cリリース1をインストールします。

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

- Oracle JRF 12cリリース1 (12.1.3.0)をインストールします。これにはoracle_commonディレクトリが含まれます。

- Oracle Web Tier 12cリリース1 (12.1.3.0)をインストールします。

- Oracle BI Publisher 12cリリース1 (12.1.3.0)をインストールします。これにはbiディレクトリが含まれます。

構成フェーズの実行中、構成スクリプトを起動して、次の手順を実行します。

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

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

注意:
Microsoft Windowsでは、ノード・マネージャ・サービスは作成されません。これは予測されている動作です。

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

- 既存の動作保証済Oracle DatabaseのOracle Management Repositoryを構成します。データベース・インスタンスがオラクル社提供のデータベース・テンプレートを使用して作成される場合、この手順は省略されます。

- プラグイン・ディレクトリを作成し、次のデフォルトのプラグインをインストールします。

- Oracle Databaseプラグイン

- Oracle Fusion Middlewareプラグイン

注意:
13cリリース1以降、Oracle Fusion Middlewareプラグイン・デプロイメントの一部として、デフォルトでJava仮想マシン診断(JVMD)エンジンが1つOMSにインストールされるようになりました。デプロイする追加OMSごとに、そのOMSとともにデフォルトで1つのJVMDエンジンが提供されます。
JVMDを使用すると、管理者は本番環境でJavaアプリケーションのパフォーマンスの問題を診断できます。問題を再現する必要性がなくなることにより、こうした問題解決に必要な時間が短縮されるため、アプリケーションの可用性とパフォーマンスが向上されます。

JVMDエンジンはデフォルトではOMSホストにインストールされますが、JVMDエージェントはターゲットのJVMに手動でデプロイする必要があります。JVMDエージェントをデプロイする手順は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。または、高度なインストール・オプションを使用するインストール方法は、第15章を参照してください。

- Oracle Exadataプラグイン

- Oracle Cloud Frameworkプラグイン

- Oracle System Infrastructureプラグイン

- デプロイするよう選択したその他のプラグイン

- 次のコンフィギュレーション・アシスタントを実行して、簡易および拡張インストールでインストールしたコンポーネントを構成します。

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

- リポジトリ構成

注意:
オラクル社提供のデータベース・テンプレートを使用し、事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、リポジトリ・コンフィギュレーションのかわりに、リポジトリ即時使用可能コンフィギュレーションが実行されます。

- MDSスキーマ構成

注意:
オラクル社提供のデータベース・テンプレートを使用し、事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、MDSスキーマ構成は実行されません。

- BI Publisherスキーマ構成

- OMS構成

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

- BI Publisher構成

- Oracle Management Serviceの起動

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

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

サイレント・モードでのEnterprise Managerシステムのインストールを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されているインストールの重要なポイントを理解してください。

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 13cリリース1ソフトウェア・バイナリのインストール(グラフィック・モード)

- rootスクリプトの実行

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

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

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

グラフィック・モードで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>/em13100_<platform>.bin [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- UNIXプラットフォームでインストール・ウィザードを起動するには、em13100_<platform>.binを起動します。Microsoft Windowsプラットフォームで起動するには、setup_em_win64.exeを起動します。

- インストーラでは一時ディレクトリに約10GBのハード・ディスク領域が必要です。一時ディレクトリにこの容量がない場合は、-J-Djava.io.tmpdirパラメータを渡して、10GBの領域があるかわりのディレクトリを指定します。
このパラメータで指定されたディレクトリは、デプロイメント・プロシージャに関連するソフトウェア・ライブラリ・エンティティをコピーするためのプロビジョニング・アドバイザ・フレームワーク(PAF)ステージング・ディレクトリの場所としても使用されます。PAFステージング・ディレクトリは、プロビジョニング・アクティビティのみに使用されます(デプロイメント手順に関連するエンティティがコピーされ、これらの手順が終了すると削除されます)。

次に例を示します。

./em13100_linux64.bin -J-Djava.io.tmpdir=/u01/software/em13c/stage/

- -invPtrLocパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第4.4.1.1.1項を参照してください。

2. (オプション)「My Oracle Supportの詳細」に入力します。
「My Oracle Supportの詳細」画面で、My Oracle Support資格証明を入力し、Oracle Configuration Managerを有効にします。Oracle Configuration Managerをここで有効にしない場合、手順(3)に進みます。

インストール・ウィザードを実行しているホストがインターネットに接続されていない場合、電子メール・アドレスのみを入力し、他のフィールドは空白のままにしてください。インストールの完了後、構成情報を手動で収集し、My Oracle Supportにアップロードしてください。

3. 「次へ」をクリックします。

4. (推奨)ソフトウェア更新をインストールします。
「ソフトウェアの更新」画面で、「更新の検索」を選択し、次のいずれかのオプションを選択して最新のソフトウェア更新を適用します。

- インターネットに接続されていないホストで、オフラインモードでアップデートをダウンロードし、インストールの実行中にこれらを適用する場合は、ローカル・ディレクトリを選択します。

- インターネットに接続されているホストで、インストーラを介してMy Oracle Supportに直接接続してオンライン・モードでアップデートをダウンロードし、インストールの実行中にこれらを適用する場合は、My Oracle Supportを選択します。

これらのオプションの詳細、およびこれらのオプションを使用したソフトウェア更新のダウンロードと適用の手順は、第2.1.5.5項を参照してください。

注意:
この「ソフトウェアの更新」画面は、組込みの機能であるソフトウェア更新を使用して、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>/em13100_<platform>.bin INVENTORY_LOCATION=<absolute_path_to_inventory_directory>

または、-invPtrLocパラメータでインストーラを起動し、別のインベントリの場所を含むoraInst.locファイルに絶対パスを渡します。

次に例を示します。

<Software_Location>/em13100_<platform>.bin -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および他のコア・コンポーネントをインストールするミドルウェア・ホームを入力します。
次に例を示します。

/u01/software/em13c/oraclehome

注意:

- Enterprise Manager Cloud Controlのインストール・ウィザードによって、ここに入力したこのミドルウェア・ホーム・ディレクトリにOracle WebLogic Server 12cリリース1 (12.1.3.0)およびJDK 1.7.0_80が自動的にインストールされます。事前にインストールされたJDKまたはOracle WebLogic Serverは、13cリリース1以降ではサポートされません。

- ミドルウェア・ホームのパスの文字数が、Unixプラットフォームでは70文字、Microsoft Windowsプラットフォームでは25文字を超えていないことを確認してください。
たとえば、22文字のみを含むミドルウェア・ホームのパスC:\sw\em13c\oraclehomeは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

2. 管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。
たとえば、ミドルウェア・ホームが/u01/software/em13c/oraclehomeの場合、エージェント・ベース・ディレクトリを/u01/software/em13c/agentbasedirのように指定できます。

この場所が空で、書込み権限があることを確認してください。また、常に、ミドルウェア・ホーム外で管理されるようにしてください。

注意:
ミドルウェア・ホームのパスの文字数が、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リリース5 (12.1.0.5)ソフトウェアのインストール中の拡張インストーラ・オプションの使用

インストーラの起動中に渡すことができる追加の拡張オプションの一部は、次のとおりです。

- Oracle Enterprise Manager Cloud Control 13c以降の場合、GCDomainは、WebLogicドメインの作成でサポートされている唯一のドメイン名です。カスタマイズしたWebLogicドメイン名はサポートされていません。

- 中央インベントリを設定する場合、-invPtrLocパラメータを渡します。このパラメータでは、インベントリ・ポインタ・ファイル(oraInst.loc)のある場所のパスが考慮されます。ただし、このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。
次に例を示します。

./em13100_<platform>.bin -invPtrLoc /scratch/OracleHomes/oraInst.loc -silent -responseFile <absolute_path_response_file>

- ソフトウェア・バイナリをインストールした後、バイナリを構成します。構成が正常に終了すると、デフォルトで、OMSおよび管理エージェントが自動的に起動されます。これらを自動的に起動しないようにする場合は、START_OMSとSTART_AGENTのオプションを指定してインストール・ウィザードを呼び出し、制御する対象に応じて、それらをtrueまたはfalseに設定します。

注意:
第4.4.1.3項の説明に従って、ソフトウェア・バイナリを構成するためにConfigureGC.shを起動する場合でも、必ずSTART_OMSおよびSTART_AGENTオプションを使用してください。

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ホストのOracleホームでallroot.shスクリプトを実行します。
$<ORACLE_HOME>/allroot.sh

注意:
自身がrootユーザーではない場合、SUDOを使用して、rootユーザーに変更してください。たとえば、次のようなコマンドを実行します。
/usr/local/bin/sudo $<ORACLE_HOME>/allroot.sh

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

Enterprise Manager Cloud Controlを構成するには、次の手順に従います。

1. Enterprise Manager Cloud Controlインストール・ウィザードの起動
インストール・ウィザードを起動します。(Unixでは、必ず作成したoinstallグループに属するユーザーとしてインストール・ウィザードを起動します。オペレーティング・システム・グループおよびユーザーの作成の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。)

$<ORACLE_HOME>/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、ダウンロード済ソフトウェア)からインストールするオプションのプラグインを選択します。

事前に選択されている行は、デフォルトでインストールされる必須プラグインです。インストールするオプションを選択します。

注意:
13cリリース1でのみサポートされ、後続のリリースではサポートされない非推奨のプラグインを選択した場合、選択内容を確認し、そのプラグインのデプロイメントを続行するかどうかを決めるよう求められます。

注意:
インストール中にソフトウェア・キットで利用できないプラグインをインストールする場合、第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パスワードで自動的にリセットされます。

- プラガブル・データベース(PDB)の詳細を指定する場合は、別名ではなく完全なサービス名を使用してください。たとえば、pdb.example.comです。単独プラガブル・データベース(単独PDB)の詳細を指定する場合は、完全なサービス名を使用してください。たとえば、pdb.example.comです。非コンテナ・データベース(非CDB)の詳細を指定する場合は、SIDを使用してください。

- データベースが、動作保証マトリックスにリストされている動作保証済データベースであることを確認するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の説明に従って、動作保証マトリックスにアクセスしてください。

- 設定されるすべてのデータベース初期化パラメータおよび実行されるすべての前提条件チェックの詳細、ならびに前提条件チェックに失敗した場合に前提条件チェックを手動で実行する手順については、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEM前提条件キットに関する付録を参照してください。

2. 「デプロイメント・サイズ」・リストからデプロイメント・サイズを選択し、監視予定のターゲットの数、予定している管理エージェント数および予定している同時ユーザー・セッション数を指定します。
前提条件チェックは選択内容に関係なく実行されますが、様々なパラメータに設定される値は、選択内容に応じてチェックされます。

デプロイメント・サイズ、実行する前提条件チェック、設定するデータベース・パラメータ、およびインストール後にデプロイメント・サイズを変更する方法の詳細は、第2.1.6項を参照してください。

表4-1は、各デプロイメント・サイズを示しています。

表4-1 デプロイメント・サイズ

デプロイメント・サイズ

ターゲット数

管理エージェント数

同時ユーザー・セッション数

小

最大999

最大99

最大10

中

1000から9999

100から999

10から24

大

10,000以上

1000以上

25から50

9. 「次へ」をクリックします。

注意:
接続しているデータベースが、オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリで作成されたデータベース・インスタンスの場合、この画面で選択したデプロイメント・サイズが、データベース・インスタンスの作成中にOracle Database Configuration Assistant (DBCA)で選択したデプロイメント・サイズと一致するようにしてください。
DBCAを使用したデータベース・インスタンスの作成中に選択したデプロイメント・サイズとは異なるデプロイメント・サイズを選択する場合、次のいずれかを行います。

- 選択したデプロイメント・サイズをこの画面で選択し、「次へ」をクリックします。エラーが発生した場合には、データベースのパラメータを修正し、この画面に戻ってインストールを続けます。オラクル社提供のSQLスクリプトを使用して自動的にパラメータを修正するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- インストーラを最小化し、希望のデプロイメント・サイズのテンプレートで別のデータベース・インスタンスを作成し、この画面に戻り、一致するデプロイメント・サイズを選択します。手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

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などです。

11. 「次へ」をクリックします。

12. 共有の場所を構成します。
「Enterprise Manager共有場所の詳細」画面で、次の手順を実行します。

1. Oracleソフトウェア・ライブラリを構成します。Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)は、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなどのソフトウェア・エンティティを格納するリポジトリとして機能する、Enterprise Manager Cloud Control内の機能です。ソフトウェア・ライブラリは、プロビジョニングやパッチ適用などの操作に必要です。
「Oracleソフトウェア・ライブラリの構成」を選択します。一意のディレクトリ名を示す絶対パスを入力します。デフォルトでは、構成される記憶域の場所が、OMS共有ファイル・システムの場所であるため、OMSホストにマウントされた場所を入力することを強くお薦めします。これは、ソフトウェア・ライブラリの同じマウントされた場所を使用できるOMSインスタンスをさらにインストールする場合に役立ちます。

重要:
ソフトウェア・ライブラリは、主に「OMS共有ファイル・システム」の場所と「OMSエージェント・ファイル・システム」の場所の2つのタイプの記憶域の場所をサポートしています。これらの記憶域の場所を理解するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
なんらかの理由で、OMS共有ファイル・システムの場所を構成できない場合は、OMSエージェントの記憶域の場所を構成してください。詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』のOMSエージェントのファイル・システムの場所の構成に関する項を参照してください。

注意:

- インストール時のソフトウェア・ライブラリの構成はオプションです。このオプションを選択せずに、これを構成しなくても、インストールは成功します。ソフトウェア・ライブラリは、初期設定コンソールまたはソフトウェア・ライブラリ管理コンソール(Enterprise Manager Cloud Controlコンソール内で使用可能)を使用して後で構成できます。ただし、インストーラによって自動的に構成が行われるため、インストール時にこのオプションを選択し、ソフトウェア・ライブラリを構成することを強くお薦めします。これにより時間と労力を節約され、最初のOMSの直後に追加のOMSをインストールし、同じソフトウェア・ライブラリの場所を使用するように構成できます。

- ソフトウェア・ライブラリの構成後、ソフトウェア・ライブラリ管理コンソールで場所の詳細を表示できます。このコンソールにアクセスするには、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. デフォルトでインストールおよび構成されるOracle BI Publisherの共有の場所を構成します。共有記憶域の場所は、レポート・カタログおよび現在インストールしている最初のOMSおよび今後インストールする予定の追加のOMSに関連する管理情報を格納するための共通の場所として機能します。
(i) Oracle BI Publisherのために使用する共有場所を特定します。

既存の共有場所がない場合、新たに作成し、最初のOMSをインストールするホストおよび追加のOMSインスタンスをインストールする予定のホストでそれが認識されることを確認します。

インストールが成功するように、インストール時に共有ディレクトリ用のハードディスク・ドライブを約400MB予約できます。ただし、追加のプラグインをインストールしたり、さらに多くのレポートを作成するにつれて、領域の使用率は時間とともに増えていくため、最終的に少なくとも10GBに拡張し、将来的にはさらに拡張できるようにすることをお薦めします。

注意:
ソフトウェア・ライブラリ、または以前のリリースのEnterprise Managerのゴールド・イメージのステージング用に使用していた共有場所がすでにある場合、同じ場所を使用するよう選択できます。ただし、共有場所内のディレクトリがOracle BI Publisher、ソフトウェア・ライブラリおよびステージングされたゴールド・イメージで一意であることを確認してください。たとえば、共有場所/u01/software/examplehost/shrd/をすでに使用しており、そこでソフトウェア・ライブラリが/u01/software/examplehost/shrd/SWに構成されている場合、同じ場所を使用できますが、この共有場所内のOracle BI Publisher用のディレクトリが/u01/software/examplehost/shrd/BIPになるようにします。

(ii)この画面で「Oracle BI Publisherの共有場所の構成」を選択します。次のディレクトリ・パスを入力します。最初のOMSのインストールに使用するユーザー・アカウントに、これらのパスの読取りおよび書込み権限があることを確認します。

注意:
Microsoft Windowsでインストーラを起動すると、「Enterprise Manager共有場所の詳細」画面に「構成ボリューム」オプションと「クラスタ・ボリューム」オプションは表示されません。これは予測されている動作です。

「構成ボリューム」に、Oracle BI Publisherリポジトリおよび構成ファイルが格納される共有記憶域の場所にある/configディレクトリまでのパスを入力します。たとえば、/u01/software/examplehost/shrd/BIP/configです

「クラスタ・ボリューム」に、Oracle BI Publisherが高可用性環境で動作するためにOracle BI Publisherスケジューラ記憶域が保持される共有記憶域の場所にある/clusterディレクトリまでのパスを入力します。たとえば、/u01/software/examplehost/shrd/BIP/clusterです

警告:

インストール後、これらのディレクトリを削除しないでください。ディレクトリはOracle BI Publisherが適切に機能するために必要なため、インストール時およびインストール後も必要です。

3. インストールおよび構成されているOracle BI Publisherを有効または無効にします。Oracle BI Publisherを有効にすると、ソフトウェアが起動され、Enterprise Managerシステム内で使用するための準備が整えられます。Oracle BI Publisherを無効にすると、ソフトウェアは起動されずにそのままになります。
Oracle BI Publisherを有効にするには、「Oracle BI Publisherの有効化」を選択します。

注意:
インストール時にOracle BI Publisherを無効にするよう選択した場合、インストール後に次のEM CTLコマンドをOMSホストのOracleホームのbinディレクトリから実行して有効にできます。
$<ORACLE_HOME>/bin/emctl config oms -enable_bip

コマンドはOracle BI Publisherを有効にするのみで、起動はしません。開始するには、最初のOMSホストのOracleホームのbinディレクトリで次のコマンドを実行します。

$<ORACLE_HOME>/bin/emctl start oms -bip_only

13. ポートのカスタマイズ
「ポート構成の詳細」画面で、様々なコンポーネントに使用されるポートをカスタマイズします。

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

14. 「次へ」をクリックします。

15. 確認および構成
「確認」画面で、選択したインストール・タイプに指定した詳細を確認します。

- 詳細を変更するには、変更する画面に到達するまで、「戻る」を繰返しクリックします。

- 詳細を確認し問題がない場合、「構成」をクリックしてインストール・プロセスを開始します。

16. 進行状況の追跡
「インストールの進行状況」画面で、インストール全体の進行状況(パーセント表示)を確認します。

注意:

- コンフィギュレーション・アシスタントに失敗した場合、インストーラが停止し、後続のコンフィギュレーション・アシスタントは実行されません。問題を解決して、コンフィギュレーション・アシスタントを再試行してください。

- 「再試行」をクリックする前に誤ってインストーラを終了した場合は、同じ画面を表示するためにインストーラを再起動するのではなく、OMSホストのOracleホームからrunConfig.shスクリプトを呼び出して、サイレント・モードでコンフィギュレーション・アシスタントを再実行します。Microsoft Windowsプラットフォームの場合、runConfig.batスクリプトを起動します。
$<ORACLE_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スクリプトが失敗する場合は、使用環境をクリーンアップしてインストールを再実行してください。

17. インストールの終了
「終了」画面に、Enterprise Managerのインストールに関連する情報が表示されます。情報を確認し、「閉じる」をクリックして、インストール・ウィザードを終了します。

注意:
サーバー・ロード・バランサ(SLB)が環境に構成され、アップロード・ポートがロックされている場合、JVMDエンジンに対してSLBを構成し、OMSを保護します。
SLBが環境に構成されているが、アップロード・ポートのロックが解除されている場合、JVMDのトラフィックにSLBを経由させるかどうかを決定します。そのようにする場合、JVMDエンジンに対してSLBを構成し、OMSを保護します。

OMSを保護するには、OMSホストのOracleホームのbinディレクトリで次のコマンドを実行します。

<ORACLE_HOME>/bin/emctl secure oms -host <SLB host>-slb_jvmd_http_port <JVMD_SLB_HTTP_Port> -slb_jvmd_https_port <JVMD_SLB_HTTPS_Port> -sysman_pwd <system_password> -reg_pwd <agent_registration_password>

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

configureGC.sh (Microsoft Windowsの場合はconfigureGC.bat)スクリプトの起動中に渡すことができる、追加の拡張オプションを次に示します。

- Oracle Enterprise Manager Cloud Control 13c以降の場合、GCDomainは、WebLogicドメインの作成でサポートされている唯一のドメイン名です。カスタマイズしたWebLogicドメイン名はサポートされていません。

- ソフトウェア・キット(DVDまたはダウンロードしたソフトウェア)にないプラグインをインストールする場合は、次の手順を実行します。

1. 必要なプラグインを次の場所から手動でダウンロードします。
http://www.oracle.com/technetwork/oem/extensions/index.html

また、パートナまたはカスタマ用のプラグインをダウンロードする場合は、次の場所からダウンロードします。

https://apex.oracle.com/pls/apex/f?p=53891:1

2. 次のパラメータを使用してConfigureGC.shスクリプト(またはMicrosoft WindowsではConfigureGC.bat)を起動し、追加のプラグインがダウンロードされた場所を渡します。
UNIXプラットフォームの場合:

./ConfigureGC.sh PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>

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

./ConfigureGC.bat PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>

ここには、ソフトウェア・キット(DVD、ダウンロードしたソフトウェア)で使用可能なプラグインや、このカスタムの場所で使用可能なプラグインの一覧が表示されます。インストールするものを選択できます。

- 構成が正常に終了すると、OMSおよび管理エージェントが自動的に起動されます。これらを自動的に起動しないようにする場合は、START_OMSとSTART_AGENTのオプションを指定してスクリプトを呼び出し、制御する対象に応じて、それらをtrueまたはfalseに設定します。

注意:
第4.4.1.1項の説明に従って、ソフトウェア・バイナリをインストールするためにインストール・ウィザードを起動した場合でも、必ずSTART_OMSおよびSTART_AGENTオプションを使用してください。

たとえば、管理エージェントを自動的に起動しない場合、次のコマンドを実行します。

$<ORACLE_HOME>/sysman/install/ConfigureGC.sh START_OMS=true START_AGENT=false

この拡張オプションに関連する制限を理解するには、第3.4.3項を参照してください。

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

Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章に示されているインストール後の手順を実行します。

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

この項では、サイレント・モードでEnterprise Manager Cloud Controlのソフトウェア・バイナリのみインストールして、後でインストールを構成する方法について説明します。この項の具体的な内容は次のとおりです。

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

- rootスクリプトの実行

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

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

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

サイレント・モードでEnterprise Manager Cloud Controlのソフトウェア・バイナリのみをインストールするには、次の手順を実行します。

注意:
インストーラを起動する前にEM前提条件キットを実行し、リポジトリの前提条件をすべて満たしていることをあらかじめ確認することをお薦めします。手動で実行していない場合でも、製品のインストール中はインストーラによってバックグラウンドで実行されています。ただし、事前に手動で実行すると、インストールまたはアップグレード・プロセスを開始できる前に、管理リポジトリが設定されます。キットの詳細とその実行方法、キットで実行される前提条件チェックについては、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。
ただし、オラクル社提供のデータベース・テンプレートを使用して事前構成済の管理リポジトリで作成されたデータベース・インスタンスを使用する場合は、EM前提条件キットの起動中に次のパラメータを渡します。

-componentVariables repository:EXECUTE_CHECKS_NOSEED_DB_FOUND:false

1. インストーラを起動して、ソフトウェアのみのサイレント・インストールの実行で使用する必要があるレスポンス・ファイルを生成します。
./em13100_<platform>.bin -getResponseFileTemplates -outputLoc <absolute_path_to_a_directory_to_store_the_generated_response_file>

注意:
このコマンドによって3つのレスポンス・ファイルが生成されます。このソフトウェアのみのサイレント・インストールではsoftware_only.rspファイルのみを使用する必要があります。

2. software_only.rspファイルを編集し、表4-2に示された変数に適切な値を入力します。

3. インストーラをサイレント・モードで起動し、更新したレスポンス・ファイルを渡します。
(Unixでは、必ず作成したoinstallグループに属するユーザーとしてインストーラを起動します。オペレーティング・システム・グループおよびユーザーの作成の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。)

- これがホストにインストールする最初のOracle製品である場合は、次のコマンドを実行します。
./em13100_<platform>.bin -silent -responseFile <absolute_path_to_the_directory_where_the_generated_and_updated_response_file_is_stored>/software_only.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

- 最初のOracle製品でない場合は、次のコマンドを実行します。
./em13100_<platform>.bin -silent -responseFile <absolute_path_to_the_directory_where_the_generated_and_updated_response_file_is_stored>/software_only.rsp

注意:

- UNIXプラットフォームでインストール・ウィザードを起動するには、em13100_<platform>.binを起動します。Microsoft Windowsプラットフォームで起動するには、setup_em_win64.exeを起動します。

- インストーラでは一時ディレクトリに約10GBのハード・ディスク領域が必要です。一時ディレクトリにこの容量がない場合は、-J-Djava.io.tmpdirパラメータを渡して、10GBの領域があるかわりのディレクトリを指定します。
このパラメータで指定されたディレクトリは、デプロイメント・プロシージャに関連するソフトウェア・ライブラリ・エンティティをコピーするためのプロビジョニング・アドバイザ・フレームワーク(PAF)ステージング・ディレクトリの場所としても使用されます。PAFステージング・ディレクトリは、プロビジョニング・アクティビティのみに使用されます(デプロイメント手順に関連するエンティティがコピーされ、これらの手順が終了すると削除されます)。

次に例を示します。

./em13100_linux64.bin -J-Djava.io.tmpdir=/u01/software/em13c/stage/

- インストーラの起動時に渡すことができる追加の拡張オプションの詳細は、第3.4.2項を参照してください。

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

i

表4-2は、編集する必要がある変数およびソフトウェア・バイナリをインストールするためのsoftware_only.rspレスポンス・ファイルでの編集方法を示しています。

表4-2 サイレント・モードでのソフトウェアのみの方法を使用したEnterprise Manager 13cリリース1ソフトウェアをインストールするための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 12cリリース1 (12.1.3.0)およびJava Development Kit (JDK) 1.7.0_80をインストールする場所を入力します。ミドルウェアの場所に書込み権限があることを確認します。

たとえば、"/u01/software/em13c/oraclehome"です。

注意: ミドルウェア・ホームのパスの文字数が、Unixプラットフォームでは70文字、Microsoft Windowsプラットフォームでは25文字を超えていないことを確認してください。

たとえば、22文字のみを含むミドルウェア・ホームのパスC:\sw\em13c\oraclehomeは、使用できます。ただし、Microsoft Windowsプラットフォームにおいて、25文字を超えるC:\OracleSoftware\OracleMiddleware\OracleEnterpriseManager\OMS\newrelease\omsは使用できません。

AGENT_BASE_DIR

文字列

はい

管理エージェントをインストールできるエージェント・ベース・ディレクトリ(Oracleミドルウェア・ホーム外の場所)への絶対パスを入力します。

たとえば、"/u01/software/em13c/agentbasedir"です。

この場所が空で、書込み権限があることを確認してください。また、常に、Oracleミドルウェア・ホーム外で管理されるようにしてください。

注意: (Microsoft Windowsのみ)エージェント・ベース・ディレクトリのパスの文字数が、25文字を超えていないことを確認してください。たとえば、22文字のみを含むエージェント・ベース・ディレクトリのパスC:\sw\em13c\agntbsedirは、使用できます。ただし、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スクリプトを実行します。
$<ORACLE_HOME>/allroot.sh

注意:
自身がrootユーザーではない場合、SUDOを使用して、rootユーザーに変更してください。たとえば、次のようなコマンドを実行します。
/usr/local/bin/sudo $<ORACLE_HOME>/allroot.sh

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

Enterprise Manager Cloud Controlのソフトウェア・バイナリを構成するには、次の手順に従います。

1. 第4.4.2.1項の手順1で生成したnew_install.rspファイルにアクセスします。このファイルを編集し、表4-3に示された変数に適切な値を指定します。

2. ConfigureGC.sh (Microsoft Windowsの場合はConfigureGC.bat)スクリプトを起動し、前の手順で編集したレスポンス・ファイルを渡して、ソフトウェア・バイナリを構成します。
$<ORACLE_HOME>/sysman/install/ConfigureGC.sh -silent -responseFile <absolute_path_to_the_directory_where_the_generated_and_updated_response_file_is_stored>/new_install.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

注意:

- 第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ホーム)を構成済の場合、スクリプトまたは各コンフィギュレーション・アシスタントを使用して再構成しないでください。

- オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合、選択したデプロイメント・サイズに合せるにはデータベース・パラメータを変更する必要があることを示すメッセージが表示されます。これは、テンプレートは基本的に簡易インストール用に設計され、データベース・パラメータは簡易インストールの要件に応じて設定されているためです。詳細インストールに使用する場合は、パラメータを別の値に設定する必要があります。メッセージを確認して続行します。インストール・ウィザードによって、自動的にパラメータが必要な値に設定されます。

注意:
サーバー・ロード・バランサ(SLB)が環境に構成され、アップロード・ポートがロックされている場合、JVMDエンジンに対してSLBを構成し、OMSを保護します。
SLBが環境に構成されているが、アップロード・ポートのロックが解除されている場合、JVMDのトラフィックにSLBを経由させるかどうかを決定します。そのようにする場合、JVMDエンジンに対してSLBを構成し、OMSを保護します。

OMSを保護するには、OMSホストのOracleホームのbinディレクトリで次のコマンドを実行します。

<ORACLE_HOME>/bin/emctl secure oms -host <SLB host>-slb_jvmd_http_port <JVMD_SLB_HTTP_Port> -slb_jvmd_https_port <JVMD_SLB_HTTPS_Port> -sysman_pwd <system_password> -reg_pwd <agent_registration_password>

注意:

- 前提条件チェックがパッケージが不足していることを示して失敗した場合は、必要なパッケージをインストールしてインストールを再試行してください。インストーラによってパッケージ名およびバージョンが検証されるため、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に示す最小バージョンのパッケージをインストールしてください。インストーラがこれらのパッケージの検証に使用するロジックを理解するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- リポジトリ関連の前提条件チェックに失敗した場合、手動でチェックを実行してください。手順は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEM前提条件キットに関する付録を参照してください。

- コンフィギュレーション・アシスタントに失敗した場合、インストーラが停止し、後続のコンフィギュレーション・アシスタントは実行されません。問題を解決してコンフィギュレーション・アシスタントを再実行してください。

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

表4-3は、編集する必要がある変数およびソフトウェア・バイナリを構成するためのnew_install.rspファイルでの編集方法を示しています。

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

パラメータ

データ型

値に二重引用符が必要かどうか

説明

PLUGIN_SELECTION

デフォルトでは、Oracle Database Plug-in、Oracle Fusion Middleware Plug-in、Oracle Exadata Plug-in、Oracle Cloud Framework Plug-in、Oracle System Infrastructure Plug-inなどの必須プラグインは、Enterprise Managerシステムとともに自動的にインストールされます。

デフォルトのプラグインに加えてその他のプラグインをデプロイする場合は、それらのプラグインの名前をカンマ区切りリストで指定します。プラグインの名前は二重引用符で囲んでください。

13cリリース1でのみサポートされ、後続のリリースではサポートされない非推奨のプラグインをデプロイしようとする場合は、選択内容を確認し、そのプラグインのデプロイメントを続行するかどうかを決めます。

次に例を示します。

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

ソフトウェア・キット(DVDまたはダウンロードしたソフトウェア)にないプラグインをインストールする場合は、次の手順を実行します。

1. 必要なプラグインを次の場所から手動でダウンロードします。
http://www.oracle.com/technetwork/oem/extensions/index.html

また、パートナまたはカスタマ用のプラグインをダウンロードする場合は、次の場所からダウンロードします。

https://apex.oracle.com/pls/apex/f?p=53891:1

2. 次のオプションを使用してインストーラを起動し、追加のプラグインがダウンロードされた場所を渡します。
./em13100_<platform>.bin PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>

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マウントされたドライブからローカルのファイル・システムの場所に移動します。手順については、第4.4.2.4項を参照してください。

DATABASE_HOSTNAME

文字列

はい

既存のデータベースが常駐するホストの完全修飾名を入力します。ホスト名にアンダースコアがないことを確認します。

たとえば、"example.com"です。

オラクル社提供のデータベース・テンプレートを使用して、事前構成済の管理リポジトリでデータベース・インスタンスを作成している場合は、そのデータベース・インスタンスの詳細を指定します。

Oracle RAC Databaseに接続する場合、ノードに仮想ホスト名が含まれていれば、ノードの1つの仮想ホスト名を指定します。

この仮想ホスト名のみで構成された接続文字列を使用してデータベースへの接続が確立され、インストールは正常に終了します。

ただし、クラスタの他のノードの接続文字列を更新する場合、インストール後に次のコマンドを実行します。

$<ORACLE_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リスナーを使用した接続文字列を入力できます。

ACFSを使用する場合は、ACFSディスクをマウントするクラスタに次のパラメータがあることを確認し、/etc/fstabファイルのインストールを開始します。

<mount_points_of_ACFS_storage> nfs rw,bg,hard,intr,nolock,rsize=32768,wsize=32768,tcp,noacl,vers=3,timeo=300,actimeo=120

次に例を示します。

example.com:/emfs/mpoint/oms1 /scratch/u01/oms nfs rw,bg,hard,intr,nolock,rsize=32768,wsize=32768,tcp,noacl,vers=3,timeo=300,actimeo=120

注意: オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、SYSMAN_PASSWORDパラメータに入力したSYSMANパスワードで自動的にリセットされます。

LISTENER_PORT

文字列

はい

既存のデータベースに接続するためのリスナー・ポートを入力します。

たとえば、"1521"です。

SERVICENAME_OR_SID

文字列

はい

既存のデータベースのサービス名またはシステムID (SID)を入力します。

たとえば、"orcl"などです。

プラガブル・データベース(PDB)の詳細を指定する場合は、別名ではなく完全なサービス名を使用してください。たとえば、pdb.example.comです。単独プラガブル・データベース(単独PDB)の詳細を指定する場合は、完全なサービス名を使用してください。たとえば、pdb.example.comです。非コンテナ・データベース(非CDB)の詳細を指定する場合は、SIDを使用してください。

SYS_PASSWORD

文字列

はい

SYSユーザー・アカウントのパスワードを入力します。

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基本インストレーション・ガイド』を参照してください。

SYSMAN_PASSWORD

文字列

はい

SYSMANユーザー・アカウントを作成するパスワードを入力します。このパスワードは、SYSMANユーザー(管理リポジトリ・スキーマのプライマリ所有者)を作成する場合に使用します。

パスワードはスペースを含めず8文字以上で、先頭は文字とし、1つ以上の数字を含めるようにしてください。

注意: オラクル社提供のデータベース・テンプレートを使用して作成されたデータベース・インスタンスに接続する場合は、ユーザー・アカウントSYSMAN_MDS、SYSMAN_APMおよびSYSMAN_OPSS (管理リポジトリの事前構成中に作成されたもの)に割り当てられているパスワードが、この画面に入力したSYSMANパスワードで自動的にリセットされます。

SYSMAN_CONFIRM_PASSWORD

文字列

はい

SYSMANユーザー・アカウントのパスワードを確認します。

AGENT_REGISTRATION_PASSWORD

文字列

はい

OMSと管理エージェントの間の通信を保護するには、パスワードを入力します。管理エージェントを保護するためのパスワードと同じ登録パスワードを入力する必要があります。

AGENT_REGISTRATION_CONFIRM_PASSWORD

文字列

はい

エージェント登録パスワードを確認します。

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)に関連する監視データを格納するために、このデータ・ファイルが必要です。

CONFIGURE_ORACLE_SOFTWARE_LIBRARY

ブール

いいえ

インストール時にソフトウェア・ライブラリを構成するには、このパラメータをTRUEに設定します。それ以外の場合には、FALSEに設定します。

インストール時に構成しない場合でも、インストールは成功し、後ほどEnterprise Manager Cloud Controlコンソールからいつでも構成できます。ただし、インストーラによって自動的に構成が行われ、時間と労力を省くことができるため、インストール時にソフトウェア・ライブラリ構成することをお薦めします。

SOFTWARE_LIBRARY_LOCATION

文字列

はい

CONFIGURE_ORACLE_SOFTWARE_LIBRARYをTRUEに設定した場合、ソフトウェア・ライブラリを構成できるOMSホスト上に、一意のディレクトリ名となる絶対パスを入力します。入力する場所はOMSホスト上にマウントされた場所で、ミドルウェア・ホーム外であることを確認してください。また、OMSプロセスの所有者にその場所に対する読取り/書込みアクセス権があることも確認してください。マウントされた場所で構成を行うと、追加のOMSインスタンスのインストール時に役立ちます(インスタンスが、同じOMS共有ファイルシステムの記憶域の場所への読取り/書込みアクセス権を必要とするため)。

CONFIGURE_SHARED_LOCATION_BIP

ブール

いいえ

デフォルトでインストールおよび構成されるOracle BI Publisherの共有の場所を構成します。これには、パラメータをTRUEに設定します。

共有記憶域の場所は、レポート・カタログおよび現在インストールしている最初のOMSおよび今後インストールする予定の追加のOMSに関連する管理情報を格納するための共通の場所として機能します。

Oracle BI Publisherのために使用する共有場所を特定します。既存の共有場所がない場合、新たに作成し、最初のOMSをインストールするホストおよび追加のOMSインスタンスをインストールする予定のホストでそれが認識されることを確認します。

インストールが成功するように、インストール時に共有ディレクトリ用のハードディスク・ドライブを約400MB予約できます。ただし、追加のプラグインをインストールしたり、さらに多くのレポートを作成するにつれて、領域の使用率は時間とともに増えていくため、最終的に少なくとも10GBに拡張し、将来的にはさらに拡張できるようにすることをお薦めします。

CLUSTER_LOCATION

文字列

はい

これは、CONFIGURE_SHARED_LOCATION_BIPパラメータがTRUEに設定される場合のみ設定します。

Oracle BI Publisherが高可用性環境で動作するためにOracle BI Publisherスケジューラ記憶域が保持される共有記憶域の場所にある/clusterディレクトリまでのパスを指定します。たとえば、/u01/software/examplehost/BIP/cluster.です。

CONFIG_LOCATION

文字列

はい

これは、CONFIGURE_SHARED_LOCATION_BIPパラメータがTRUEに設定される場合のみ設定します。

Oracle BI Publisherリポジトリおよび構成ファイルが格納される共有記憶域の場所にある/configディレクトリまでのパスを指定します。たとえば、/u01/software/examplehost/BIP/config.です。

ENABLE_BI_PUBLISHER

ブール

いいえ

インストールおよび構成されているOracle BI Publisherを有効または無効にします。Oracle BI Publisherを有効にすると、ソフトウェアが起動され、Enterprise Managerシステム内で使用するための準備が整えられます。Oracle BI Publisherを無効にすると、ソフトウェアは起動されずにそのままになります。

Oracle BI Publisherを有効にするにはこのパラメータをTRUEに設定します。無効にするにはこのパラメータをFALSEに設定します。

STATIC_PORTS_FILE

文字列

はい

デフォルトでは、第2.1.12項で説明されているポートが適用されます。デフォルトのポートを受け入れる場合は、このフィールドを空白のままにしておきます。

カスタム・ポートを使用する場合、インストールに使用されるカスタム・ポートをリストしているstaticports.iniファイルの絶対パスを入力します。

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

Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Managerシステムのインストールに関する章に示されているインストール後の手順を実行します。

第III部

追加のOracle Management Serviceのインストール

この部は、次の章で構成されています。

- 第5章「サイレント・モードでの追加のOracle Management Serviceのインストール」

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

ご使用の環境に追加のOracle Management Service (OMS)をインストールして、Enterprise Managerシステムの高可用性を保証することをお薦めします。この章では、追加のOMSをサイレント・モードでインストールする方法について説明します。この章の具体的な内容は次のとおりです。

- サイレント・モードでの追加のOracle Management Serviceのインストールについて

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

5.1 サイレント・モードでの追加のOracle Management Serviceのインストールについて

ご使用の環境に追加のOMSインスタンスをインストールして、Enterprise Managerシステムの高可用性を保証することをお薦めします。追加のOMSをインストールするためには、管理サービスの追加デプロイメント・プロシージャを使用できます。管理サービスの追加デプロイメント・プロシージャでは、豊富なGUIを使用してインタラクティブに追加OMSをインストールできます。手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

ただし、環境にセキュリティ制限または監査要件がある場合、またはインストール用にネットワーク越しにOracle資格証明を使用してログインできない場合、サイレント(非インタラクティブ)モードでインストールできます。サイレント・インストールを開始する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に説明されているすべての前提条件を満たす必要があります。

警告:

Enterprise Manager Cloud Control 13cを、SPARCシリーズのサーバー(T1000、T2000、T5xx0およびT3-*)にインストールしないでください。詳細は、My Oracle Supportのノート1590556.1を参照してください。

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

サイレント・モードで追加OMSをインストールするには、次の手順を実行します。

1. Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)が、Oracle Enterprise Manager Cloud Controlで用意されているメインOMS上に構成されている場合、次のことを実行します。

- Unixプラットフォームの場合:

- 追加OMSのインストールを予定しているリモート・ホストから、ソフトウェア・ライブラリの読取り/書込みアクセスが可能であることを確認します。

- BI Publisher共有記憶域ボリューム(構成ボリュームとクラスタ・ボリュームの両方)が、追加OMSをインストールする予定のリモート・ホストにマウントされていることを確認します。すべてのファイルシステム権限によってこれらのボリュームの読取りと書込みが許可されることを確認します。
個別のconfigサブディレクトリとclusterサブディレクトリを含む1つのボリュームを使用することもできますが、独立した専用のボリュームを2つ使用することで障害シナリオでの信頼性が向上します。

- 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スクリプトを起動します。

$<ORACLE_HOME>/sysman/install/PluginInstall.sh

「プラグイン・デプロイメント」画面で、インストールするオプションのプラグインを選択します。

画面には、前の手順(ソフトウェア・バイナリをインストールする手順)で使用したソフトウェア・キット(DVD、ダウンロード済ソフトウェア)に含まれるプラグインのみが表示されます。

この画面で事前に選択されている行は、デフォルトでインストールされる必須プラグインです。インストールするオプションを選択します。

- サイレント・モードの場合(コマンドライン):
次の場所からPluginInstall.shスクリプトを起動します。

$<ORACLE_HOME>/sysman/install/PluginInstall.sh -silent PLUGIN_SELECTION="{PLUGIN_ID1,PLUGIN_ID2}"

次に例を示します。

/u01/software/em13c/oraclehome/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. 必要なプラグインを次の場所から手動でダウンロードします。
http://www.oracle.com/technetwork/oem/extensions/index.html

また、パートナまたはカスタマ用のプラグインをダウンロードする場合は、次の場所からダウンロードします。

https://apex.oracle.com/pls/apex/f?p=53891:1

2. 次のパラメータを使用してスクリプトを起動し、追加のプラグインがダウンロードされた場所を渡します。
GUIモードの場合(インストーラ画面使用):

$<ORACLE_HOME>/sysman/install/PluginInstall.sh PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>

「プラグイン・デプロイメント」画面には、ソフトウェア・キットに含まれていたプラグインおよびこのカスタムの場所にあるダウンロード済のプラグインのリストが表示されます。インストールするものを選択できます。

サイレント・モードの場合(コマンドライン):

$<ORACLE_HOME>/sysman/install/PluginInstall.sh -silent PLUGIN_SELECTION="{PLUGIN_ID1,PLUGIN_ID2}" PLUGIN_LOCATION=<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ホームから次のコマンドを実行し、構成の詳細をファイルとしてエクスポートできる場所を渡します。
$<ORACLE_HOME>/bin/emctl exportconfig oms -dir <absolute_path_to_directory>

6. エクスポートされた構成の詳細ファイルを第1のOMSのホストから追加OMSのホストにコピーします。

7. 別名ホスト名を使用して追加のOMSをインストールする場合は、ORACLE_HOSTNAME環境変数に別名ホスト名を設定します。

8. 追加OMSに構成の詳細をリカバリします。これを行うには、追加OMSホストのOracleホームから次のコマンドを実行します。
$<ORACLE_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> -EM_BIP_OHS_PORT <port> -EM_BIP_OHS_HTTPS_PORT <port>

次に例を示します。

/u01/software/em13c/oraclehome2/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 -EM_BIP_OHS_PORT 9788 -EM_BIP_OHS_HTTPS_PORT 9851

注意:
別名ホスト名を使用して追加のOMSをインストールする場合は、このサイトのすべてのOMSインスタンスについて/etc/hostsファイルに定義されている別名ホスト名を、EM_INSTANCE_HOSTパラメータに設定します。

9. (管理エージェントがまだホストにない場合にのみ適用) エージェント・ホームから次のコマンドを実行し、追加OMSホスト上で管理エージェントを構成します。
$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<agent_base_dir> 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. 手順9に従って管理エージェントを構成した追加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章「共有エージェントのインストール」

- 第10章「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 13c (13.1.0.x)では、Oracle Technology Network (OTN)から管理エージェント.rpmファイルをダウンロードして管理エージェントをインストールすることは、サポートされていません。

インストールが完了すると、エージェント・ベース・ディレクトリに次のデフォルトの内容が含まれています。

<agent_base_directory>
|_____agent_13.1.0.0.0
|_____sbin
|_____OPatch
|_____agent.rsp
|_____bin
|_____cfgtoollogs
|_____config
|_____install
|_____instalclient
|_____.
|_____.
|_____.
|_____agent_inst
|_____agentInstall.rsp
|_____agentimage.properties

注意:

- 既存の管理エージェントを新しいOracle Management Service (OMS)に再指定できます。手順は、付録Bを参照してください。
既存の管理エージェントを新しいOMSに対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

- (Microsoft Windowsホストの場合) 13.1.0.x管理エージェントをアップグレードし、異なるOMSを指定する別の管理エージェントを同じホストにインストールする場合、第6.4.7項に示すとおり、管理エージェントのインストール中にs_agentSrvcNameパラメータを指定してください。

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

サイレント・モードで管理エージェントをインストールする前に、次の点に留意してください。

- サイレント・モードでは、一度に1つのホストにのみ管理エージェントをインストールできます。このため、この方式は少数のホストに管理エージェントをインストールする場合に使用してください。

- 管理エージェントをインストールするホストのプラットフォーム用の管理エージェント・ソフトウェアは、自己更新を使用してダウンロードおよび適用する必要があります。OMSホスト・プラットフォーム用の管理エージェント・ソフトウェアのみが、デフォルトでダウンロードおよび適用されます。管理エージェント・ソフトウェアには、インストールに必要なコア・バイナリ、編集して渡されるレスポンス・ファイルおよびagentDeploy.sh (Microsoft Windowsの場合はagentDeploy.bat)スクリプトが含まれます。
自己更新を使用してプラットフォーム用の管理エージェント・ソフトウェアをダウンロードおよび適用する方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- Enterprise Manager Cloud Control 13cリリース1では、管理エージェントの特定のバージョンに適用する管理エージェントの個別パッチを保存でき、同じバージョンの管理エージェントをデプロイするたびに、または古い管理エージェントをそのバージョンへアップグレードするときに、そのパッチはソフトウェアへ自動的に適用されます。
この方法の詳細は、付録Cを参照してください。

また、プラグインに個別パッチを適用し、カスタムのパッチ適用プラグインを作成して、デプロイするすべての新規管理エージェントおよびアップグレードするすべての旧管理エージェントにこのカスタムのパッチ適用プラグインがデプロイされるようにできます。

この方法の詳細は、『Oracle Enterprise Manager Cloud Control管理ガイド』を参照してください。

- Enterprise Manager Cloud Control 13cリリース1からは、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 13cリリース1は最小アップデート・バージョンのSolaris 5.10アップデート9に基づいてビルド、テストおよび動作保証されていたため、Oracle Management AgentをSolaris 5.10アップデート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基本インストレーション・ガイド』で説明している手順を実行します。

ファイルシステム要件

宛先ホストにマウントされたファイルシステムでバッファに入れられた書込みが許可されないことを確認します。

ファイル記述子要件

- ユーザー・プロセスの上限が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

(Microsoft Windowsのみ) etc/hostsファイルでのローカル・ホストのエントリが、常に127.0.0.1と他の任意のアドレスに対して設定されていることを確認します。

タイムゾーン要件

ホストのタイムゾーンが正しく設定されていることを確認します。ホストのタイムゾーンを確認するには、次のコマンドを実行します。

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.12.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-7の説明に従って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:\以外のドライブにインストールされている場合は、ORACLE_HOME\oui\prov\resources\ssPaths_msplats.propertiesのSCRATCH_PATH変数を更新します。
たとえば、OMSソフトウェアがD:\にインストールされている場合は、SCRATCH_PATH変数をD:\tmpadaに更新してください。

- Oracle Linux 7 (64ビット)またはRed Hat Enterprise Linux 7 (64ビット)で実行されているホストに管理エージェントをインストールする場合、管理エージェントをインストールする前にOMSホームにパッチ20030085をデプロイする必要があります。
パッチのデプロイ方法に関する詳細は、『Oracle Enterprise Manager Lifecycle Management管理者ガイド』を参照してください。

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

AgentPullスクリプトを使用して管理エージェントをインストールするには、次の手順を実行します。

1. 管理エージェント・ソフトウェアを取得します。

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

3. AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストール

重要:
AgentPullスクリプトを使用して管理エージェントをインストールする場合、管理エージェント・ソフトウェアを宛先ホストにダウンロードする必要がありません。この処理は、AgentPullスクリプトにより自動的に行われます。

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

1. 宛先ホストがUNIXで稼働している場合は、ホストから次のURLにアクセスし、ファイルをAgentPull.shとして一時ディレクトリに保存します(Microsoft Windowsの場合はAgentPull.bat)。たとえば、/tmpに保存します(Microsoft Windowsではc:\temp)。
https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage

宛先ホストがMicrosoft Windows上で実行されている場合は、ホストから次のURLにアクセスします。

https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage?script=bat

注意:
AgentPull.shスクリプトは、次のコマンドを使用して取得することもできます。
curl "https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage" --insecure -o AgentPull.sh

このコマンドを使用するには、表6-1の説明に従ってCURLユーティリティがインストールされていることを確認します。

2. (UNIXオペレーティング・システムのみ)次のコマンドを実行して、AgentPull.shスクリプトにexecute権限を付与します。
chmod +x <absolute_path_to_AgentPull.sh>

たとえば、コマンドchmod +x /tmp/AgentPull.shを実行します。

3. 管理エージェント・ソフトウェアがOMSホストで使用できるプラットフォームを特定します。これには、-showPlatformsオプションを指定してAgentPull.shスクリプト(Microsoft WindowsではAgentPull.bat)を実行します。
<absolute_path_to_AgentPull.sh> -showPlatforms

次に、コマンドの出力例を示します。

Platforms Version
Linux x86-64 13.1.0.0.0
Microsoft Windows x64 (64-bit) 13.1.0.0.0
IBM AIX on POWER Systems (64-bit) 13.1.0.0.0

管理エージェントをインストールするプラットフォームの出力が示されている場合、第6.4.1.2項に進みます。それ以外の場合は、自己更新を使用して、必要なプラットフォーム用の管理エージェント・ソフトウェアを取得および適用します。

自己更新を使用してプラットフォーム用の管理エージェント・ソフトウェアを取得および適用する方法の詳細は、『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-3の説明に従ってパラメータを指定して、レスポンス・ファイルを(宛先ホスト上の任意の場所に)作成します。レスポンス・ファイルにagent.rspという名前を付けていないことを確認してください。
サンプル・レスポンス・ファイルagent.properties.の内容は次のとおりです。

LOGIN_USER=sysman
LOGIN_PASSWORD=welcome
PLATFORM="Linux x86-64"
AGENT_REGISTRATION_PASSWORD=wel246come

スクリプトが特定のレスポンス・ファイル・パラメータを無視するようにするには、パラメータの前に「#」を指定します。たとえば、#VERSIONです。

3. AGENT_BASE_DIRおよびRSPFILE_LOCパラメータを指定してAgentPull.shスクリプト(Unix)またはAgentPull.bat (Microsoft Windows)を実行します。
AgentPull.sh LOGIN_USER=<value> LOGIN_PASSWORD=<value> CURL_PATH=<value> PLATFORM=<value> [VERSION=<value> AGENT_BASE_DIR=<value> RSPFILE_LOC=<value> AGENT_REGISTRATION_PASSWORD=<value> -download_only -showPlatforms -ignoreDiscoveryPlugin]

AgentPull.bat AGENT_BASE_DIR=<value> RSPFILE_LOC=<value> CURL_PATH=<value> [AGENT_REGISTRATION_PASSWORD=<value> VERSION=<value> -download_only -showPlatforms -ignoreDiscoveryPlugin -help]

たとえば、次のようなコマンドを実行します。

/tmp/AgentPull.sh RSPFILE_LOC=/tmp/agent.properties AGENT_BASE_DIR=/scratch/agent

AgentPull.sh (およびAgentPull.bat)スクリプトは、(管理エージェント・ソフトウェアはダウンロードしても、管理エージェントはデプロイしない)-download_onlyのような特定のオプションをサポートしています。表6-6に、サポートされているオプションを示します。

AgentPull.batを使用して管理エージェントをMicrosoft Windowsホストにインストールする場合には、他のコマンド・プロンプトではなく必ずデフォルトのコマンド・プロンプトcmd.exeから、AgentPull.batを実行してください。

管理エージェントのインストールが失敗した場合、管理エージェントのインストール・ログを見て問題を診断してください。これらのログの場所の詳細は、A.3項を参照してください。

6.4.2 AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストール

AgentPullスクリプトを使用して管理エージェントをインストールするには、次の手順を実行します。

1. AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストールの前提条件の確認

2. AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストール

6.4.2.1 AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストールの前提条件の確認

1. 使用している環境にスタンドアロンの13c管理エージェントが少なくとも1つインストールされていることを確認します。

2. エージェント・ゴールド・イメージを作成します。第11.5.1項を参照してください。

3. エージェント・ゴールド・イメージ・バージョンを作成します。第11.5.4項を参照してください。

4. 特定のエージェント・ゴールド・イメージ・バージョンを、デプロイメントに使用できる現在のバージョンとして設定します。第11.5.7項。

5. 管理エージェント・ソフトウェアを入手するには、第6.4.1.1項の説明に従います。

6.4.2.2 AgentPullスクリプトを使用したエージェント・ゴールド・イメージによる管理エージェントのインストール

AgentPullスクリプトを使用してエージェント・ゴールド・イメージによって管理エージェントをインストールするには、次の手順に従います。

1. 宛先ホストがUNIX上で、OMSホストがMicrosoft Windows上で実行されている場合は、次のコマンドを実行します。
dos2unix <absolute_path_to_AgentPull.sh>

たとえば、コマンドdos2unix /tmp/AgentPull.shを実行します。

2. 表6-3の説明に従ってパラメータを指定して、レスポンス・ファイルを(宛先ホスト上の任意の場所に)作成します。レスポンス・ファイルにagent.rspという名前を付けていないことを確認してください。
サンプル・レスポンス・ファイルagent.properties.の内容は次のとおりです。

LOGIN_USER=sysman
LOGIN_PASSWORD=welcome
PLATFORM="Linux x86-64"
AGENT_REGISTRATION_PASSWORD=wel246come

スクリプトが特定のレスポンス・ファイル・パラメータを無視するようにするには、パラメータの前に「#」を指定します。たとえば、#VERSIONです。

3. 次のようにAgentPull.shスクリプト(Microsoft Windowsの場合はAgentPull.bat)を実行します。表6-2に、このコマンドに指定するパラメータを示します。
<absolute_path_to_AgentPull.sh> LOGIN_USER=<username> LOGIN_PASSWORD=<password> CURL_PATH=/usr/curl VERSION_NAME=<value>|IMAGE_NAME=<value> [ AGENT_BASE_DIR=<value> RSPFILE_LOC=<value> AGENT_REGISTRATION_PASSWORD=<password> -download_only -showGoldImages -showGoldImageVersions -ignoreAuthentication]

たとえば、次のコマンドは、本番システムにあるエージェント・ゴールド・イメージの最新バージョンをダウンロードして、管理エージェントのデプロイに使用します。

AgentPull.sh LOGIN_USER=username LOGIN_PASSWORD=password CURL_PATH=/usr/curl IMAGE_NAME=DB_MONITORING AGENT_BASE_DIR=/tmp/agentpull

表6-2 エージェント・ゴールド・イメージを使用した管理エージェントのインストール時にAgentPull.shスクリプトに渡されるパラメータ

パラメータ

説明

LOGIN_USER

Enterprise Manager Cloud Controlコンソールのログイン・ユーザー名。

CURL_PATH

curlソフトウェアの絶対パス。

LOGIN_PASSWORD

Enterprise Manager Cloud Controlコンソールのログイン・パスワード。

VERSION_NAME

デプロイメントに使用されるエージェント・ゴールド・イメージ・バージョン名。

IMAGE_NAME

デプロイメントに使用するエージェント・ゴールド・イメージ・バージョンのエージェント・ゴールド・イメージ名。

AGENT_BASE_DIR

エージェント・ゴールド・イメージをダウンロードし、管理エージェントをインストールするディレクトリ。

AGENT_REGISTRATION_PASSWORD

管理エージェントを保護するエージェント登録パスワード。

RSPFILE_LOC

レスポンス・ファイルの場所の絶対パス。

-download_only

エージェント・ゴールド・イメージをダウンロードするが、そのイメージを使用して管理エージェントをデプロイしません。

-showGoldImages

エージェント・ゴールド・イメージをリスト表示します。

-showGoldImageVersions IMAGE_NAME=<value>

特定のエージェント・ゴールド・イメージで使用可能なエージェント・ゴールド・イメージ・バージョンをリスト表示します。

-ignoreAuthentication

Enterprise Manager資格証明をバイパスします。

AgentPull.batを使用して管理エージェントをMicrosoft Windowsホストにインストールする場合には、他のコマンド・プロンプトではなく必ずデフォルトのコマンド・プロンプトcmd.exeから、AgentPull.batを実行してください。

管理エージェントのインストールが失敗した場合、管理エージェントのインストール・ログを見て問題を診断してください。これらのログの場所の詳細は、A.3項を参照してください。

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

管理エージェントは、agentDeploy.shスクリプトまたはagentDeploy.batスクリプトを使用して、次の方法でインストールできます。

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

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

6.4.3.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 = 13.1.0.0.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 13.1.0.0.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 13.1.0.0.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. ソフトウェア・ライブラリから宛先ホストの一時ディレクトリに管理エージェント・ソフトウェアをダウンロードします。このコマンドは、入力した宛先ディレクトリにコア管理エージェント・ソフトウェアをダウンロードします。たとえば、Linux x86-64の場合、13.1.0.0.0_AgentCore_226.zipファイルが表示されます。このコア・ソフトウェアの内容の詳細は、第6.4.11項を参照してください。
<emcli_install_location>/emcli get_agentimage -destination=<download_directory> -platform="<platform>" -version=<version>

次に例を示します。

./emcli get_agentimage -destination=/tmp/agentImage -platform="Linux x86-64" -version=13.1.0.0.0

コマンドでは、次のことに注意してください。

-destinationは、管理エージェント・ソフトウェアをダウンロードする宛先ホストのディレクトリです。この場所への書込み権限を持っていることを確認します。

-platformは、ソフトウェアをダウンロードするプラットフォームで、ソフトウェアがソフトウェア・ライブラリで入手可能な以前の手順で示されたプラットフォームのいずれかと一致する必要があります。

-versionは、ダウンロードする管理エージェント・ソフトウェアのバージョンで、オプションの引数です。この引数を渡さない場合、デフォルトのバージョンはOMSバージョンになります。

重要:

get_agentimage EM CLI動詞を使用して宛先ホストとは異なるプラットフォーム用の管理エージェント・ソフトウェアをダウンロードする場合、次の要件を満たす必要があります。

- ZIPユーティリティがバージョン3.0 2008ビルド以上、UNZIPユーティリティがバージョン6.0以上であることを確認します。

- ZIP_LOC環境変数に、ZIPユーティリティが存在するサブディレクトリを設定します。たとえば、ZIPユーティリティが/usr/bin/zipにある場合、ZIP_LOC=usr/bin/zipと設定します。

- UNZIP_LOC環境変数に、UNZIPユーティリティが存在するサブディレクトリの親ディレクトリを設定します。たとえば、UNZIPユーティリティがサブディレクトリ/usr/bin/unzipにある場合は、UNZIP_LOC=usr/bin/と設定します(usr/binが親ディレクトリです)。

同様に、get_agentimage EM CLI動詞を使用してOMSホストとは異なるプラットフォーム用の管理エージェント・ソフトウェアをダウンロードする場合、次の要件を満たす必要があります。

- ZIPユーティリティがバージョン3.0 2008ビルド以上、UNZIPユーティリティがバージョン6.0以上であることを確認します。

- ZIP_LOC環境変数を$OMS_HOME/bin/zip (OMSホスト上でZIPユーティリティがあるサブディレクトリ)に設定します。

- UNZIP_LOC環境変数を<ORACLE_HOME>/bin/ (OMSホストのOracleホームでUNZIPユーティリティが存在するサブディレクトリの親ディレクトリ)に設定します。

2. agentDeployスクリプトを使用して管理エージェントをインストールします。

1. 宛先ホストで、UNZIPユーティリティを使用して、ZIPファイルの内容を抽出します。
unzip <software_zip_file_location> -d <software_extract_location>

次に例を示します。

unzip /tmp/agentImage/13.1.0.0.0_AgentCore_226.zip -d /tmp/agtImg

2. 表6-4の説明に従って、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/agent13c 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=/u01/software/em13c/agentbasedir OMS_HOST=example.com EM_UPLOAD_PORT=14511 AGENT_REGISTRATION_PASSWORD=2bornot2b

- デプロイメント・スクリプトの起動中に引数を渡す場合、二重引用符でこれらの値を指定する必要はありません。ただし、レスポンス・ファイルで使用する場合、二重引用符で値を囲む必要があります(引数START_AGENTを除く)。

- エージェント・ベース・ディレクトリおよびレスポンス・ファイル(またはインストール詳細の個別の必須引数)を渡す以外に、デプロイメント・スクリプトでサポートされている他のオプションも渡すことができます。詳細は、6.4.10項を参照してください。

- agentDeploy.batを使用して管理エージェントをMicrosoft Windowsホストにインストールする場合には、他のコマンド・プロンプトではなく必ずデフォルトのコマンド・プロンプトcmd.exeから、agentDeploy.batを実行してください。

4. インストール後にルート・スクリプトを実行します。詳細は、第6.5項を参照してください。

管理エージェントを物理ホストにインストールし、その物理ホスト上にインストールされた仮想ホストに別の管理エージェントをインストールする場合に、両方の管理エージェントが通信用に同じポートを使用するようにするには、次の手順を実行します。

1. 物理ホストに管理エージェントをインストールします。管理エージェントを停止します。

2. 仮想ホストに管理エージェントをインストールします。管理エージェントを停止します。

3. $<AGENT_HOME>/sysman/config/emd.propertiesファイルで、AgentListenOnAllNICs=falseと設定します。この手順は、必ず両方の管理エージェントに対して実行します。

4. 両方の管理エージェントを起動します。

管理エージェントのインストールが失敗した場合、管理エージェントのインストール・ログを見て問題を診断してください。これらのログの場所の詳細は、A.3項を参照してください。

6.4.3.2 OMSホストからのEM CLIの使用

agentDeployスクリプトとOMSホストからのEM CLIを使用して管理エージェントをインストールするには、次の手順を実行します。

1. 管理エージェント・ソフトウェアを取得し、EM CLIを使用してOMSホストにこれをダウンロードします。

1. OMSホストで、OracleホームからEM CLIにログインします。各OMSインストールでEM CLIをデフォルトで使用できるため、クライアントをOMSホストに個別でインストールする必要はありません。
$<ORACLE_HOME>/bin/emcli login -username=<username>

次に例を示します。

/u01/software/em13c/oraclehome/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を同期します。
$<ORACLE_HOME>/bin/emcli sync

3. 管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なプラットフォームを特定します。
$<ORACLE_HOME>/bin/emcli get_supported_platforms

このコマンドは、管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なすべてのプラットフォームをリストします。次に、コマンドの出力例を示します。

---------------------------------------------------
Version = 13.1.0.0.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 13.1.0.0.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 13.1.0.0.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ホストの一時ディレクトリに管理エージェント・ソフトウェアをダウンロードします。
$<ORACLE_HOME>/bin/emcli get_agentimage -destination=<download_directory> -platform="<platform>" -version=<version>

次に例を示します。

./emcli get_agentimage -destination=/tmp -platform="Linux x86-64" -version=13.1.0.0.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の場合、13.1.0.0.0_AgentCore_226.zipファイルが表示されます。このコア・ソフトウェアの内容の詳細は、第6.4.11項を参照してください。

2. 管理エージェント・ソフトウェアを宛先ホストに転送します。
ダウンロードしたZIPファイルを管理エージェントをインストールする宛先ホストの一時ディレクトリ(/tmp)に転送します。ファイルの転送には、任意のファイル転送ユーティリティを使用できます。

3. agentDeployスクリプトを使用して管理エージェントをインストールします。
第6.4.3.1項で説明した手順2に従って、管理エージェントをインストールします。

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

.rpmファイルを使用して管理エージェントをインストールするには、次の手順を実行します。

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

2. RPMファイルを宛先ホストへ転送します。

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

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

1. OMSホストで、OracleホームからEM CLIにログインします。各OMSインストールでEM CLIをデフォルトで使用できるため、クライアントをOMSホストに個別でインストールする必要はありません。
$<ORACLE_HOME>/bin/emcli login -username=<username>

次に例を示します。

/u01/software/em13c/oraclehome/bin/emcli login -username=sysman

パスワードを求められたら、指定します。

注意:
EM CLIログイン・ユーザーにADD_TARGET権限があることを確認してください。

2. EM CLIを同期します。
$<ORACLE_HOME>/bin/emcli sync

3. 管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なプラットフォームを特定します。
$<ORACLE_HOME>/bin/emcli get_supported_platforms

このコマンドは、管理エージェント・ソフトウェアがソフトウェア・ライブラリで入手可能なすべてのプラットフォームをリストします。次に、コマンドの出力例を示します。

---------------------------------------------------
Version = 13.1.0.0.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 13.1.0.0.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 13.1.0.0.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ファイルをダウンロードします。
$<ORACLE_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=13.1.0.0.0

コマンドでは、次のことに注意してください。

- -destinationは、.rpmファイルをダウンロードするOMSホストのディレクトリです。この場所への書込み権限を持っていることを確認します。

- -platformは、.rpmファイルをダウンロードするプラットフォームで、ソフトウェアをOMSホストで使用できる以前の手順で示されたプラットフォームのいずれかと一致する必要があります。

- -versionは、.rpmファイルをダウンロードする管理エージェントのバージョンで、オプションの引数です。この引数を渡さない場合、デフォルトのバージョンはOMSバージョンになります。

このコマンドは、入力した宛先ディレクトリにコア管理エージェントの.rpmファイルをダウンロードします。たとえば、oracle-agt-13.1.0.0.0-1.0.i386.rpmです

また、このコマンドは、OMSホームに含まれる管理エージェント・ソフトウェア、パッチおよびプラグインを取得します。管理エージェントのパッチをOMSホームに保存して、管理エージェントがデプロイされたときに常に適用されるようにする方法については、C.1項を参照してください。

注意:
OMSがAIXで実行されている場合、Linux用のエージェントrpmファイルの作成はサポートされません。

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

1. ダウンロードした.rpmファイルを管理エージェントをインストールする宛先ホストの一時ディレクトリ(/tmp)に転送します。ファイルの転送には、任意のファイル転送ユーティリティを使用できます。

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

1. 宛先ホストで、rootユーザーとして.rpmファイルをインストールして、管理エージェントをインストールします。
rpm -ivh <download_directory>/<rpm_file>

次に例を示します。

rpm -ivh /tmp/oracle-agt-13.1.0.0.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-13.1.0.0.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-5の説明に従って、agent.propertiesファイルを編集します。ファイルは次の場所にあります。
/usr/lib/oracle/agent/agent.properties

3. 次のコマンドを実行して、インストールを完了します。
/etc/init.d/oracle-agt RESPONSE_FILE=<location_to_agent.properties>

管理エージェントのインストールが失敗した場合、管理エージェントのインストール・ログを見て問題を診断してください。これらのログの場所の詳細は、A.3項を参照してください。

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

仮想ホストに管理エージェントをインストールするには、次の手順を実行します。

1. 第6.4.3.1項または第6.4.3.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-4を参照してください。

2. 仮想ホストが仮想ネットワーク・インタフェース・コントローラ(NIC)に関連付けられている場合、$<AGENT_HOME>/sysman/config/emd.propertiesファイルにAgentListenOnAllNICs=falseを設定して、次のコマンドを実行します。
$<AGENT_HOME>/bin/emctl reload

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

表6-3は、AgentPullスクリプトを使用して管理エージェントをインストールする際、レスポンス・ファイルに含める必要のある必須パラメータと、含めることができるオプションのパラメータを示しています。

表6-3 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=13.1.0.0.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=/u01/software/em13c/agentbasedir/agent_instです

AGENT_PORT

(オプション)管理エージェント・プロセスを起動する空きポートを入力します。HTTPとHTTPSの両方に同じポートが使用されます。

たとえば、AGENT_PORT=1832です。

値を入力しない場合、3872または1830から1849の間の空きポートが適用されます。

START_AGENT

(オプション)管理エージェントをインストールして構成した後に自動的に起動する場合、TRUEを入力します。それ以外の場合はFALSEを入力します。

たとえば、START_AGENT=TRUEです

このパラメータを追加しないと、デフォルトでTRUEが設定されます。

ORACLE_HOSTNAME

(オプション)管理エージェントをインストールするホストの完全修飾ドメイン名を入力します。

たとえば、ORACLE_HOSTNAME=example.comです。

このパラメータを追加しないと、デフォルトで物理ホスト名が設定されます。

ALLOW_IPADDRESS

(オプション)ORACLE_HOSTNAMEにIPアドレスを指定する場合にはTRUEを入力します。ALLOW_IPADDRESSがFALSEに設定された場合には、管理エージェントのインストール中にORACLE_HOSTNAMEにIPアドレスを指定すると、前提条件チェックは失敗します。

たとえば、ALLOW_IPADDRESS=TRUEなどです。

このパラメータを追加しないと、デフォルトでFALSEが設定されます。

INVENTORY_LOCATION

(オプション)カスタム・インベントリの場所を入力します。

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_agentSrvcName

(Microsoft Windowsのホストのみ)

(オプション)カスタマイズされた管理エージェント・サービス名を入力します。

たとえば、s_agentSrvcName=agentsrvc1などです。

このパラメータを追加しないと、デフォルトでOracle+<oracle_home_name>+Agentが設定されます。

注意: (Microsoft Windowsホストの場合) ホストにインストールされた13.1.0.x管理エージェントをアップグレードし、異なるOMSを指定する別の管理エージェントを同じホストにインストールする場合、管理エージェントのインストール中にs_agentSrvcNameパラメータを指定してください。

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

表6-4は、agentDeployスクリプトを使用して管理エージェントをインストールする際、レスポンス・ファイルに含める必要のある必須パラメータと、含めることができるオプションのパラメータを示しています。

表6-4 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=/u01/software/em13c/agentbasedir/agent_instです

AGENT_PORT

(オプション)管理エージェント・プロセスを起動する空きポートを入力します。HTTPとHTTPSの両方に同じポートが使用されます。

たとえば、AGENT_PORT=1832です。

値を入力しない場合、3872または1830から1849の間の空きポートが適用されます。

START_AGENT

(オプション)管理エージェントをインストールして構成した後に自動的に起動する場合、TRUEを入力します。それ以外の場合はFALSEを入力します。

たとえば、START_AGENT=TRUEです

このパラメータを追加しないと、デフォルトでTRUEが設定されます。

ORACLE_HOSTNAME

(オプション)管理エージェントをインストールするホストの完全修飾ドメイン名を入力します。

たとえば、ORACLE_HOSTNAME=example.comです。

このパラメータを追加しないと、デフォルトで物理ホスト名が設定されます。

ALLOW_IPADDRESS

(オプション)ORACLE_HOSTNAMEにIPアドレスを指定する場合にはTRUEを入力します。ALLOW_IPADDRESSがFALSEに設定された場合には、管理エージェントのインストール中にORACLE_HOSTNAMEにIPアドレスを指定すると、前提条件チェックは失敗します。

たとえば、ALLOW_IPADDRESS=TRUEなどです。

このパラメータを追加しないと、デフォルトでFALSEが設定されます。

INVENTORY_LOCATION

(オプション)カスタム・インベントリの場所を入力します。

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_agentSrvcName

(Microsoft Windowsのホストのみ)

(オプション)カスタマイズされた管理エージェント・サービス名を入力します。

たとえば、s_agentSrvcName=agentsrvc1などです。

このパラメータを追加しないと、デフォルトでOracle+<oracle_home_name>+Agentが設定されます。

注意: (Microsoft Windowsホストの場合) ホストにインストールされた13.1.0.x管理エージェントをアップグレードし、異なるOMSを指定する別の管理エージェントを同じホストにインストールする場合、管理エージェントのインストール中にs_agentSrvcNameパラメータを指定してください。

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

表6-5は、.rpmファイルを使用して管理エージェントをインストールする際、レスポンス・ファイルに含める必要のある必須パラメータと、含めることができるオプションのパラメータを示しています。

表6-5 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.9 AgentPullスクリプトでサポートされているオプション

表6-6は、AgentPull.shスクリプトでサポートされるオプションを示しています。Microsoft Windowsでは、これらのオプションはAgentPull.batファイルで利用できます。

表6-6 AgentPull.sh/AgentPull.batでサポートされるオプションの理解

オプション

説明

-download_only

管理エージェント・ソフトウェアのダウンロードのみを実行します。管理エージェントはデプロイしません。

-showPlatforms

管理エージェント・ソフトウェアがOMSホストで使用できるプラットフォームを表示します。管理エージェントはインストールしません。

-help

コマンドライン・ヘルプを表示して、AgentPull.shスクリプトの使用方法を説明します。

-ignoreDiscoveryPlugin

すべての検出プラグインを無視し、Oracleホーム・プラグインのみを許可します。

-invPtrLoc

中央インベントリ(oraInventory)の場所を含むインベントリ・ファイルの絶対パスを入力します。

たとえば、-invPtrLoc /tmp/oraInst.locなどです。

重要:

- このオプションはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされません。

- 他のOracle製品がリモート・ホストにすでにインストールされており、セントラル・インベントリ・ポインタ/var/opt/oracle/oraInst.loc (SolarisおよびHP-UXプラットフォーム用)または/etc/oraInst.loc (他のUNIXプラットフォーム用)が存在していても、このオプションは使用できます。

- このオプションを使用する場合は、INVENTORY_LOCATIONオプションを使用しないでください。

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

表6-7は、agentDeploy.shスクリプトでサポートされるオプションを示しています。Microsoft Windowsでは、これらのオプションはagentDeploy.batファイルで利用できます。

表6-7 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

ソフトウェア・バイナリのみをインストールして、インストールを構成しません。管理エージェントのソフトウェアのみのインストールを実行する場合に使用してください。詳細は、第10章を参照してください。

注意: ZIPファイルを使用してクローニングしている場合、このオプションは適用されません。

-configOnly

ソフトウェア・バイナリを構成して、ソフトウェア・バイナリをインストールしません。構成のみがコピーされたソフトウェア・バイナリに実行されるため、-softwareOnlyオプションを使用してソフトウェアのみのインストールを実行した場合に使用してください。詳細は、第10章を参照してください。

注意: ZIPファイルを使用してクローニングしている場合、このオプションは適用されません。

-forceConfigure

OMSを使用できない場合でも、強制的に管理エージェントを構成します。OMSをインストールする前に管理エージェントをインストールし、渡すレスポンス・ファイルのパラメータOMS_HOSTおよびEM_UPLOAD_PORTにそれぞれ示されている同じホストおよびポートに後でOMSをインストールする場合のみ、このオプションを使用してください。

このオプションを渡す場合、-configOnly,、-softwareOnlyおよび-prereqOnlyを渡さないでください。

注意: このオプションを渡すと、HTTP (保護されていない)通信を使用するために管理エージェントが構成されます。管理エージェントおよびOMS間のセキュアなHTTPS通信を確立するため、OMSが使用可能になった後に管理エージェントを手動で保護する必要があります。

6.4.11 ダウンロードした管理エージェント・ソフトウェアの内容

表6-8は、agentDeployスクリプトを使用して管理エージェントをインストールする前にダウンロードするコア管理エージェント・ソフトウェアの内容を示しています。

表6-8 ダウンロードした管理エージェント・ソフトウェアの内容

ファイル

説明

PluginsOneoffs_<platform id> plugins

OMSとともにインストールされたすべての検出プラグイン、Oracleホームの検出プラグインおよびOracleホームの監視プラグインを含むプラグイン・ディレクトリ。

agentcore.bin

コア・エージェント・ビットおよびエージェントset-uidバイナリを含むバイナリ・ファイル。

agentDeploy.sh/agentDeploy.bat

管理エージェントをデプロイするために使用されるスクリプト。

unzip

ZIPファイルのアーカイブを解除するために使用されるユーティリティ。

agentimage.properties

バージョンやプラットフォームIDなどを取得するために使用されるプロパティ・ファイル。

agent.rsp

管理エージェントをインストールするために編集して渡すレスポンス・ファイル。

6.4.12 管理エージェントのRPMファイルの内容

.rpmファイルを使用して管理エージェントをインストールする場合、ダウンロードした.rpmファイルには、エージェント・ベース・ディレクトリが含まれます。このエージェント・ベース・ディレクトリの内容を表6-9に示します。

表6-9 RPMファイルに存在するエージェント・ベース・ディレクトリの内容

要素

説明

agent_13.1.0.0.0

管理エージェント・ソフトウェアが含まれます。

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の管理者ガイドのターゲットの追加に関する章を参照してください。

注意:

- 13c (13.1.0.x)管理エージェントが頻繁にハングする、またはSolaris 9uxおよび10uxオペレーティング・システムで応答しない場合、My Oracle SupportのドキュメントID 1427773.1を参照してください。

- Microsoft Windowsホストでの管理エージェントのデプロイ場所(管理エージェントのOracleホーム)を調べるには、<INVENTORY_LOCATION>\inventory.xmlにアクセスして、HOME NAME="agent13c2"を検索します。LOCパラメータの値が管理エージェントのOracleホームです。
たとえば、C:\Program Files\Oracle\inventory.xmlの次の行では、D:\agent13cr1\13.1.0.0.0が管理エージェントのOracleホームです。

<HOME NAME="agent13c2" LOC="D:\agent13cr1\13.1.0.0.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>
|_____agent_13.1.0.0.0
|_____sbin
|_____OPatch
|_____agent.rsp
|_____bin
|_____cfgtoollogs
|_____config
|_____install
|_____instalclient
|_____.
|_____.
|_____.
|_____agent_inst
|_____agentInstall.rsp
|_____agentimage.properties

注意:
既存の管理エージェントを新しいOracle Management Service (OMS)に再指定できます。手順は、付録Bを参照してください。
既存の管理エージェントを新しいOMSに対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

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

Oracle Management Agentのクローニングを開始する前に、次の点に留意してください。

- (グラフィック・モードのみ)ホスト・ターゲットの追加ウィザードでは、既存のOracle Management Agentをクローニングすることにより、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換します。

- 特定バージョンのOracle Management Agent 13cと特定バージョンのOracle Management Service 13c間の互換性の詳細は、『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ホストのOracleホーム内の次の場所に移動します。
$<ORACLE_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 13cリリース1は最小アップデート・バージョンのSolaris 5.10アップデート9に基づいてビルド、テストおよび動作保証されていたため、Oracle Management AgentをSolaris 5.10アップデート9にのみインストールし、パッチを使用してアップグレードした他のリリースにはインストールしないことをお薦めします。

- クローニング前にソース・ホストでemd.propertiesファイルに加えられた変更は、クローニング後に宛先ホストに反映されません。

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経由のリモート・コマンドの実行に擬似端末が必要な場合は、必ず$<ORACLE_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)、リリース5 (12.1.0.5)または13cリリース1の場合:

(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、em13100_<platform>.binおよび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/agent_13.1.0.0.0/oui/bin/em13100_<platform>.bin, /home/oracle/agentibd/*/unzip, /home/oracle/agentibd/*/unzipTmp/unzip, /home/oracle/agentibd/*/agentcore.bin

ここで、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プロパティを更新します。

$<ORACLE_HOME>/oui/prov/resources/Paths.properties

ソフトウェア可用性の要件

(グラフィック・モードのみ)

既存の管理エージェントをクローニングする場合

使用している環境でOracle Management Agent 13cがすでに実行されていることを確認します。実行されているプラットフォームが、クローニングの宛先ホストのプラットフォームと同じであることを確認します。

共有Oracleホームを使用して管理エージェントをインストールする場合

マウント済の共有場所にマスター・エージェントとしてすでにOracle Management Agent 13cがインストールされていることを確認します。

インストール・ベース・ディレクトリの要件

(グラフィック・モードのみ)

「インストールのベース・ディレクトリ」フィールドに指定するエージェント・ベース・ディレクトリが空であり、書込み権限を持っていることを確認します。

ジョブ・システム要件

クローニングするソース管理エージェントでジョブ・システムが有効になっていることを確認します。

インストール・ユーザーの要件

中央インベントリ所有者と管理エージェントをインストールするユーザーが異なる場合、両者が同じグループに属していることを確認します。

また、インベントリ所有者と所有者が属するグループに中央インベントリに対する読取りおよび書込み権限があることも確認します。

たとえば、インベントリ所有者が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.12.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ホスト、宛先ホストまたは宛先ホストにアクセスできる共有場所で使用可能であることを確認します。

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. ホスト・ターゲットの追加ウィザードで、デプロイメント・タイプ「共有エージェントへのホストの追加」を選択し、共有されているマウント済ドライブにアクセスできる他のすべてのホストに管理エージェントをインストールします。(ここでは、前の手順でマスター・エージェントまたは共有エージェントとしてクローニングした管理エージェントを選択します。)

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ホストのOracleホームの次のログ・ファイルを参照してください。
$<ORACLE_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管理エージェントを13cにアップグレードする場合、同じホスト上に別の管理エージェントをインストールして、異なるOMSにレポートするには、必ずs_agentSrvcNameパラメータを指定してください。

START_AGENT=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/software/em13c/agentbasedir

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

次に例を示します。

setenv AGENT_BASE_DIR /u01/software/em13c/agentbasedir

AGENT_HOME

管理エージェントのOracleホームに設定します。

次に例を示します。

/u01/software/em13c/agentbasedir/agent_13.1.0.0.0

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

次に例を示します。

export AGENT_HOME=/u01/software/em13c/agentbasedir/agent_13.1.0.0.0

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

次に例を示します。

setenv AGENT_HOME /u01/software/em13c/agentbasedir/agent_13.1.0.0.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 agent_13.1.0.0.0 plugins.txt

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_HOME/sysman/agentimage.properties

9. 転送されるすべての内容を含む最終的なZIPファイルを一時ディレクトリに作成します。
zip -r agent.zip $T_WORK/*

10. ファイル転送ユーティリティ(たとえば、FTPなど)を使用して、宛先ホストのインストール・ベース・ディレクトリにZIPファイルを転送します。

11. 宛先ホストの一時ディレクトリにZIPファイルの内容を解凍します(以降の手順でこの一時ディレクトリは<extracted_location>として示します)。

12. 表6-4の説明に従って、同じディレクトリに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> -clone

注意:

- レスポンス・ファイルを作成するかわりに個別の引数で値を渡す場合、次のように必須引数の一部を使用して、デプロイメント・スクリプトを起動します。
<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.10項を参照してください。

- ソース管理エージェントがホスト・ターゲットの追加ウィザードを使用してインストールされた場合、デプロイメント・スクリプトを起動する間、START_AGENT=trueおよびb_secureAgent=trueパラメータを指定してください。

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

管理エージェントのクローニング後、次の手順を実行します。

1. (グラフィック・モードのみ)「ホスト・ステータスの追加」ページのインストールを確認します。デプロイ操作のフェーズである初期化、リモートの前提条件チェックおよびエージェント・デプロイに行われた進行状況を確認します。

注意:
ホスト・ターゲットの追加ウィザードで、「エージェントのデプロイ」をクリックして、1つ以上の管理エージェントをインストールすると、ホスト・ステータスの追加ページが自動的に表示されます。
詳細を表示するか、すべてのデプロイメント・セッションの進行状況を追跡する場合、「設定」メニューから「ターゲットの追加」を選択して、「ターゲットの手動追加」をクリックします。「ターゲットの手動追加」ページで「エージェントのインストール結果」をクリックします。

特定のフェーズが失敗したか警告とともに終了した場合、エージェント・デプロイ詳細セクションの各フェーズに指定された詳細を確認し、次のうちの1つを実行します。

- 警告または失敗を無視し、必要な場合、セッションを続行します。

- チェックを正常にクリアしたリモート・ホストのみで管理エージェントのデプロイを続行することを選択し、警告または失敗のステータスを持つホストは無視できます。これを行うには、「続行」をクリックして、「失敗したホストは無視して続行」を選択します。

- 警告または失敗のステータスを持つホストを含むすべてのホストで、管理エージェントのデプロイを続行することを選択できます。これを行うには、「続行」をクリックして、「すべてのホストで続行」を選択します。

- エラーの説明を慎重に確認し、原因を理解し、Oracle推奨のアクションを実行することで、問題を解決します。

- インストール詳細が同じである管理エージェントのデプロイを再試行することを選択できます。これを行うには、「再試行」をクリックして、「同じ入力を使用して再試行」を選択します。

- インストール詳細が変更された管理エージェントのデプロイを再試行することを選択できます。これを行うには、「再試行」をクリックして、「入力を更新して再試行」を選択します。

注意:
ソース・エージェント・イメージのコピーに失敗しましたというエラー・メッセージが表示されている場合、OMSホストのOracleホームの次のログ・ファイルを参照してください。
$<ORACLE_HOME>/sysman/prov/agentpush/<timestampdir>/applogs/deployfwk.log

通常、このエラーは、クローニングしているソース管理エージェントでジョブ・システムが有効になっていない場合に発生します。ジョブ・システムが有効になっていることを確認してください。

2. 第6.5項の説明に従って、インストール後の手順を実行します。

注意:

- Oracle Management Agent 13c (13.1.0.x)が頻繁にハングする、またはSolaris 9uxおよび10uxオペレーティング・システムで応答しない場合、My Oracle SupportのドキュメントID 1427773.1を参照してください。

- 既存の管理エージェントを新しいOracle Management Service (OMS)に再指定できます。手順は、付録Bを参照してください。
既存の管理エージェントを新しい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のOracleホーム内の次の場所に移動します。
$<ORACLE_HOME>/oui/prov/resources/scripts

次に例を示します。

/u01/software/em13c/oraclehome/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 13cリリース1は最小アップデート・バージョンのSolaris 5.10アップデート9に基づいてビルド、テストおよび動作保証されていたため、Oracle Management AgentをSolaris 5.10アップデート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 13cがインストールされていることを確認します。

管理エージェントのインストール方法の詳細は、『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経由のリモート・コマンドの実行に擬似端末が必要な場合は、必ず$<ORACLE_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)、リリース5 (12.1.0.5)および13cリリース1の場合:

(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、em13100_<platform>.binおよび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/agent_13.1.0.0.0/perl/bin/perl, /home/oracle/agentibd/agent_13.1.0.0.0/oui/bin/em13100_<platform>.bin, /home/oracle/agentibd/agent_13.1.0.0.0/bin/unzip, /home/oracle/agentibd/*/agentcore.bin

ここで、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プロパティを更新します。

$<ORACLE_HOME>/oui/prov/resources/Paths.properties

ポート要件

第2.1.12.1項で説明されているデフォルトのポートを使用できることを確認します。

インストール・ユーザーの要件

- マスター・エージェントおよび共有エージェントは、同じユーザー・アカウントでインストールする必要があります。

- 中央インベントリ所有者と管理エージェントをインストールするユーザーが異なる場合、両者が同じグループに属していることを確認します。

- インベントリ所有者と所有者が属するグループが、インベントリ・ディレクトリに対する読取り権限と書込み権限を持つことを確認します。
たとえば、インベントリ所有者がabcで、管理エージェントをインストールするユーザーがxyzの場合、abcとxyzが同じグループに属し、双方が中央インベントリに対する読取りおよび書込みアクセスを持っていることを確認してください。

中央インベントリ(oraInventory)の要件

- すべての宛先ホストにおいて、中央インベントリに100MBの領域が割り当てられていることを確認します。

- 共有エージェントは、<MASTER_AGENT_BASE DIR>/13.1.0.0.0/ディレクトリ内にあるoraInst.locファイルに記述されているインベントリの場所を使用します。共有エージェント・ユーザーに、このディレクトリへの読取り/書込みアクセス権があることを確認します。

インストール前/インストール後スクリプトの要件

(グラフィック・モードのみ)

インストールとともに実行するインストール前スクリプトとインストール後スクリプトがOMSホスト、宛先ホストまたは宛先ホストにアクセスできる共有場所で使用可能であることを確認します。

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. 「デプロイメント・タイプ」セクションで、「共有エージェントへのホストの追加」を選択します。「ターゲットの選択」で、懐中電灯アイコンをクリックして、共有およびマウントする管理エージェントを選択します。この場所は、すべてのリモート・ホストで認識できる必要があります。

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 サポートされている追加パラメータ

パラメータ

説明

START_AGENT=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>

次に例を示します。

/shared/app/agentbasedir/agent_13.1.0.0.0/perl/bin/perl /shared/app/agentbasedir/agent_13.1.0.0.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>...

次に例を示します。

/shared/app/agentbasedir/agent_13.1.0.0.0/perl/bin/perl /shared/app/agentbasedir/agent_13.1.0.0.0/sysman/install/AgentNFS.pl AGENT_INSTANCE_HOME=/<local_location>/agent_inst ORACLE_HOME=/shared/app/agentbasedir/agent_13.1.0.0.0 AGENT_PORT=1832 AGENT_REGISTRATION_PASSWORD=welcome b_secureAgent=TRUE START_AGENT=TRUE

AGENT_INSTANCE_HOMEを指定するときに、指定した場所がホストに対してローカルで、他のホストから再使用されないことを確認します。

- ホスト・ターゲットの追加ウィザードを使用してマスター・エージェントがインストールされた場合、次の引数および値が渡されていることを確認します。
AGENT_REGISTRATION_PASSWORD=<password>

START_AGENT=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 /shared/app/agentbasedir/agent_inst/root.sh

4. 共有エージェントをインストールするその他のホストに対し、手順(2)から(4)を繰り返します。

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

サイレント・モードで共有エージェントをインストールするには、AgentNFS.plスクリプトを起動して、すべての必要な情報を取得するレスポンス・ファイルを渡す必要があります。表8-3は、レスポンス・ファイルに含む必要がある様々なパラメータを示しています。

表8-3 AgentNFS.plスクリプトを使用してOracle Management Agentをインストールするためのレスポンス・ファイルの作成

パラメータ

説明

ORACLE_HOME

宛先ホストで共有および表示されるマスター・エージェント・ホームの絶対パスを指定します。

たとえば、/shared/app/agentbasedir/agent_13.1.0.0.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_secureAgent=TRUE

これをTRUEに設定すると、共有エージェントが保護されます。

START_AGENT

インストールして構成した後に共有エージェントを自動的に起動するため、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)、リリース5 (12.1.0.5)および13cリリース1では、nmosudoはエージェント・ベース・ディレクトリ内のsbinディレクトリに格納されています。たとえば、<AGENT_BASE_DIRECTORY>/sbin/nmosudoなどです。Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)(バンドル・パッチ1あり/なし)では、nmosudoはエージェント・インスタンス・ディレクトリに格納されています。たとえば、<AGENT_INSTANCE_DIRECTORY>/bin/nmosudoなどです。

このため、13cリリース1管理エージェントをインストールする場合は、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 13c (13.1.0.x)が頻繁にハングする、またはSolaris 9uxおよび10uxオペレーティング・システムで応答しない場合、My Oracle SupportのドキュメントID 1427773.1を参照してください。

9 共有エージェントのスタンドアロン・エージェントへの変換

管理エージェントは組み込まれたソフトウェア・コンポーネントで、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換できます。管理エージェントはプラグインと連携することにより、管理対象ホスト上で実行されているターゲットを監視します。

最初にインストールするOracle Management Service (OMS)では、デフォルトでセントラル・エージェントと呼ばれる管理エージェントを受け取ります。セントラル・エージェントは、最初のOMSホスト、最初のOMS、および最初のOMSホストで実行する他のターゲットの監視のみに使用されます。他のホストやそこで実行するターゲットを監視するには、それらのホストごとに別のスタンドアロン管理エージェントをインストールする必要があります。

共有エージェントは、既存の管理エージェントのバイナリを使用して、リモート・ホストにインストールされる管理エージェントです。ここでは、ソフトウェア・バイナリを共有する管理エージェントはマスター・エージェントと呼ばれ、リモート・ホスト上でインスタンス・ディレクトリとともに構成される管理エージェントは共有エージェントまたはNFSエージェントと呼ばれます。

この章では、共有エージェントをスタンドアロン・エージェントに変換する方法について説明します。この章の具体的な内容は次のとおりです。

- NFSまたは共有エージェントのスタンドアロン・エージェントへの変換

9.1 NFSまたは共有エージェントのスタンドアロン・エージェントへの変換

注意:
スタンドアロン・エージェントに変換するすべての共有エージェントについてこの手順を実行する必要があります。

NFSまたは共有エージェントをスタンドアロン・エージェントに変換するには、次の手順に従います。

1. マスター・エージェント・ホストで、エージェント・ベース・ディレクトリに移動し、次のファイルを除外してディレクトリを圧縮します。

- agent_instディレクトリ

- sbinディレクトリ内のルート所有ファイル

これを行うには、次のコマンドを実行します。

cd <agent base directory>
zip -rq agentcoreimage.zip  * -x sbin/nmb sbin/nmgsshe sbin/nmhs sbin/nmo sbin/nmopdpx sbin/nmosudo agent_inst
For example,
cd /u01/app/oracle/agent_nfs/agentbasedir
zip -rq agentcoreimage.zip * -x sbin/nmb sbin/nmgsshe sbin/nmhs sbin/nmo sbin/nmopdpx sbin/nmosudo agent_inst

各共有エージェントで次の手順を実行します。

2. 次のコマンドを実行して、エージェントを停止します。

<sharedagent_inst>/bin/emctl stop agent
For example,
/u01/app/emstate/agent_inst/bin/emctl stop agent

3. 次のコマンドを実行して、圧縮したファイルを共有エージェント・ホストのローカル・フォルダにコピーします。

cp <agent base directory>/agentcoreimage.zip <local directory>
For example,
cp /u01/app/oracle/agent_nfs/agentbasedir/agentcoreimage.zip /u01/stage

4. 次のコマンドを実行して、エージェント・ベース・ディレクトリをマウント解除します。

umount <path to the agent base directory>
For example,
umount /u01/app/oracle/agent_nfs/agentbasedir

注意:
ルート・ユーザーでない場合はこのコマンドを実行できません。

5. 次のコマンドを実行して、ローカル・ディレクトリの圧縮ファイルをエージェント・ベース・ディレクトリに抽出します。

unzip agentcoreimage.zip -d <agent base directory>
For example,
unzip /u01/stage/agentcoreimage.zip -d /u01/app/oracle/agent_nfs/agentbasedir

6. <path to the agent home>/root.shスクリプトをルート・ユーザーとして実行します。

7. 次のコマンドを実行して、エージェント・ベース・ディレクトリのインスタンス・ホームをコピーし、マスター・エージェントの構造と一致するように名前をagent_instに変更します。

cp -r <local instance home> <agent base directory>/
For example,
cp -r /u01/app/emstate/agent_inst/* /u01/app/oracle/agent_nfs/agentbasedir/agent_inst/

8. 次のコマンドを実行して、パス<agent base directory>/agent_instでエージェントを起動します。

<agent base directory>/agent_inst/bin/emctl start agent
For example,
/u01/app/oracle/agent_nfs/agentbasedir/agent_inst/bin/emctl start agent

9. 次のコマンドを実行して、インベントリにエントリを作成します。
$ORACLE_HOME/oui/bin/attachHome.sh -silent ORACLE_HOME=<$ORACLE_HOME> -force

10. 次のコマンドを実行して、Oracleホーム・コレクションをリフレッシュします。
<Agent Instance Home>/bin/emctl control agent runCollection <ORACLEHOME_TARGET_NAME>: oracle_home oracle_home_config

例:

./u01/app/oracle/agent_nfs/agentbasedir/agent_inst/emctl control agent runCollection example.com:oracle_home oracle_home_config

注意:
<ORACLEHOME_TARGET_NAME>は<Agent Instance Home>/sysman/emd/targets.xmlファイルにあります。

グラフィカル・インタフェースを使用してOracleホーム・コレクションをリフレッシュするには、次の手順に従います。

1. 管理エージェントのホームページの「サマリー」セクションで「Oracleホームとパッチの詳細」をクリックします。

2. 次のページで「構成のリフレッシュ」をクリックします。

注意:
この手順は共有エージェントとマスター・エージェントの両方で実行します。

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

この章では、Oracle Management Agent (管理エージェント)のソフトウェア・バイナリのみインストールして、後でインストールを構成する方法について説明します。この章の具体的な内容は次のとおりです。

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

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

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

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

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

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

10.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に対して再指定する場合、管理エージェントの監視対象ターゲット、ターゲットの履歴および管理エージェントの履歴は移行できません。監視対象ターゲットおよび履歴データは失われます。

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

管理エージェントをインストールする前に、第6.2項に示されている点を確認してください。

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

管理エージェントをインストールする前に、第6.3項で説明されている前提条件を満たしていることを確認してください。

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

サイレント・モードで管理エージェントのソフトウェア・バイナリのみをインストールするには、第6.4.3項に記載されている手順のいずれかに従います。デプロイメント・スクリプトを起動する場合、必ず-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=//u01/software/em13c/agentbasedir RESPONSE_FILE=/tmp/agtImg/agent.rsp -softwareOnly

管理エージェントが正常にインストールされると、それを伝えるメッセージがコマンドラインに表示されます。

注意:
-forceConfigureオプションを渡さないでください。

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

サイレント・モードで管理エージェントのソフトウェア・バイナリを構成するには、管理エージェント・ホームから次のオプションを使用して、デプロイメント・スクリプトを起動します。

$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile> -configOnly

例: /u01/software/em13c/agentbasedir/agent_13.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=/u01/software/em13c/agentbasedir RESPONSE_FILE=/tmp/agtImg/agent.rsp -configOnly

管理エージェントが正常にインストールされると、それを伝えるメッセージがコマンドラインに表示されます。

注意:

- ここで渡すレスポンス・ファイルは、第10.4項で渡されたレスポンス・ファイルと同じです。

- -forceConfigureオプションを渡さないでください。

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

管理エージェントのインストール後は、第6.5項に示されている手順に従ってください。

第V部

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

この部では、Enterprise Manager Cloud Controlのインストールおよび製品の使用開始後に実行可能な拡張インストールおよび構成タスクについて説明します。

この部は、次の章で構成されています。

- 第11章「エージェント・ゴールド・イメージのライフサイクルの管理」

- 第12章「Enterprise Managerのファイアウォールの構成」

- 第13章「Enterprise Managerデプロイメントのサイジング」

- 第14章「OMSおよび管理エージェントの通信用プロキシの構成」

- 第15章「拡張インストール・オプションを使用したJVMDエージェントのインストール」

- 第16章「Enterprise ManagerでのBI Publisherの構成」

11 エージェント・ゴールド・イメージのライフサイクルの管理

Oracle Management Agent (管理エージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントの1つで、Enterprise Managerシステムで管理対象外ホストを管理対象ホストに変換できます。管理エージェントはプラグインと連携することにより、管理対象ホスト上で実行されているターゲットを監視します。したがって、ホスト上で実行されているターゲットを監視するにはいつでも、管理エージェントをインストールして最初にこの管理対象外ホストを管理対象ホストに変換する必要があります。

以前から、Enterprise Manager Cloud Controlでは、ホスト・ターゲットの追加ウィザード、EM CLI、レスポンス・ファイル(インストールを暗黙に実行する)など、管理エージェントをインストールする方法がいくつか提供されています。13c以降のEnterprise Manager Cloud Controlでは、環境での管理エージェントの一括デプロイメントおよびアップグレードに使用できるエージェント・ゴールド・イメージが提供されます。

エージェント・ゴールド・イメージは、構成がカスタマイズされた必要なバージョンの管理エージェント・ソフトウェア、必要なバージョンのモニタリング・プラグインおよび必要なパッチがある、Enterprise Managerで管理されているデータ・センター内での管理エージェントの理想的な状態を示します。

エージェント・ゴールド・イメージ・バージョンは、Enterprise Managerユーザーによって、徹底的にテストおよび調整されたライブ・リファレンス管理エージェントを使用して作成されます。エージェント・ゴールド・イメージ・バージョンを使用し、多数のホスト上で新しい管理エージェントのプロビジョニングまたは既存の管理エージェントの更新を行うことができます。

この章では、エージェント・ゴールド・イメージのライフサイクルを管理する方法について説明します。この章の具体的な内容は次のとおりです。

- エージェント・ゴールド・イメージの用語

- エージェント・ゴールド・イメージを使用して実行できる操作

- エージェント・ゴールド・イメージ・コンソールの理解

- 管理エージェント・ベース・ディレクトリ構造の理解

- エージェント・ゴールド・イメージのライフサイクルの管理

- エージェント・ゴールド・イメージ・アクティビティ詳細の表示

- エージェント・ゴールド・イメージ・コンプライアンス・レベルのチェック

- エージェント・ゴールド・イメージの詳細の表示

- エージェント・ゴールド・イメージに関連する通知の表示

- 保留中の更新のあるエージェント・ゴールド・イメージの表示

- 最後に変更されたエージェント・ゴールド・イメージの表示

- エージェント・ゴールド・イメージに関連するログ・ファイルの表示

11.1 エージェント・ゴールド・イメージの用語

次の用語は、エージェント・ゴールド・イメージについて説明する際に、一般的に使用されています。

- エージェント・ゴールド・イメージおよびエージェント・ゴールド・イメージ・バージョン: エージェント・ゴールド・イメージはデータ・センターの管理エージェントの理想的な状態を表し、管理エージェント・ソフトウェアの必要なバージョン、モニタリング・プラグインの必要なバージョンおよび必要なパッチのカスタマイズされた構成を持ちます。
エージェント・ゴールド・イメージは、管理エージェントのアップグレード、管理エージェント上のデプロイ済プラグインのアップグレード、管理エージェントへの新規プラグインのデプロイまたは管理エージェントやプラグインへの新規パッチのデプロイを実行するたびにリビジョンされることが期待されています。こうした各エージェント・ゴールド・イメージの順次リビジョンは、エージェント・ゴールド・イメージ・バージョンと呼ばれます。

- 管理エージェントの更新: これは、管理エージェントのアップグレード(つまり、管理エージェント・ソフトウェアのアップグレード)、管理エージェントへの新規プラグインのデプロイ、管理エージェントでの既存プラグインのアップグレード、管理エージェントおよびプラグイン・パッチの適用およびこれらの組合せを指します。エージェント・ゴールド・イメージ・バージョンを使用すると、こうしたタスクをどのような組合せでも実行できます。

- エージェント・ゴールド・イメージの現在のバージョン: 企業で管理エージェントを標準化するために使用するエージェント・ゴールド・イメージの最新バージョン。

- エージェント・ゴールド・イメージの制限されたバージョン: テストの目的で使用できるが大規模デプロイメントには使用しないなど、限定されたデプロイメントのみで使用する必要があるエージェント・ゴールド・イメージ・バージョンです。デフォルトでは、特定のエージェント・ゴールド・イメージの制限されたバージョンを使用して、最大で10個の管理エージェントをデプロイまたは更新できます。管理者は、ゴールド・イメージ・バージョンを使用して管理エージェントをデプロイまたは更新する前に、スーパー管理者の権限を取得することをお薦めします。常に1つの管理エージェント・ゴールド・イメージに対しては、制限されたバージョンを1つしか保持できません。

- 管理エージェントをエージェント・ゴールド・イメージにサブスクライブ: 管理エージェントを特定のエージェント・ゴールド・イメージに関連付けます。これは、特定のエージェント・ゴールド・イメージ・バージョンを使用して管理エージェントを更新する前提条件です。

- エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除: 管理エージェントとエージェント・ゴールド・イメージの関連付けを解除します。これ以上エージェント・ゴールド・イメージを使用して特定の管理エージェントの更新操作を管理しない場合には、このタスクを実行します。

- エージェント・ゴールド・イメージ・コンプライアンス: 特定のゴールド・イメージにサブスクライブしている全管理エージェントのうち、現在のバージョンのエージェント・ゴールド・イメージの管理エージェントの比率。

11.2 エージェント・ゴールド・イメージを使用して実行できる操作

エージェント・ゴールド・イメージを使用して、次のタスクを実行できます。

- 新しい管理エージェントをプロビジョニングします。

- 既存の管理エージェントを更新します。

- 管理エージェント(管理エージェント・ソフトウェア)をアップグレードします。

- 管理エージェントに新しいプラグインをデプロイします。

- 管理エージェントにデプロイされている既存のプラグインをアップグレードします。

- 管理エージェントにパッチをデプロイします。

- 管理エージェントにデプロイされているプラグインにパッチをデプロイします。

- エージェント・ゴールド・イメージのコンプライアンス・レベルを調べて、ご使用の環境でエージェント・ゴールド・イメージにすでに関連付けられている管理エージェントと関連付けられていない管理エージェントのパーセンテージを特定します。

- 発行されたゴールド・イメージ・ジョブ、それらのステータス、アクティビティの開始時刻と終了時刻など、エージェント・ゴールド・イメージのアクティビティを追跡します。

注意:
エージェント・ゴールド・イメージを使用して共有エージェント(NFSエージェント)のインストール、更新またはアップグレードを行うことはできません。共有エージェントの詳細は、第8.1項を参照してください。
また、セキュアでない管理エージェントを使用してエージェント・ゴールド・イメージ・バージョンを作成することはできません。したがって、エージェント・ゴールド・イメージ・バージョンを作成する場合は、必ずセキュアな管理エージェントを使用してください。

次の管理エージェントはエージェント・ゴールド・イメージをサブスクライブできません。

- セントラル・エージェント。

- すでにサブスクライブしている管理エージェント。

- 共有エージェント(NFSエージェント)。

- セキュアでない管理エージェント。

- エージェント・ゴールド・イメージがあるプラットフォームとは別のプラットフォーム上にある管理エージェント。
プラットフォームはOracleホーム・コレクションによって識別されるため、Oracleホーム・ターゲットの検出と収集が行われるように確認します。このためには、管理エージェントのホームページの「サマリー」セクションで「Oracleホームとパッチの詳細」をクリックし、次のページで「構成のリフレッシュ」をクリックします。

11.3 エージェント・ゴールド・イメージ・コンソールの理解

エージェント・ゴールド・イメージ・コンソールにアクセスするには、「設定」メニューで「Cloud Controlの管理」、「ゴールド・エージェント・イメージ」の順に選択します。

表11-1に、「ゴールド・エージェント・イメージ」コンソールの各部を説明します。

表11-1 「ゴールド・エージェント・イメージ」コンソールの説明

番号

説明

1

コンプライアンス・レベルを表す図。エージェント・ゴールド・イメージをサブスクライブしているすべての管理エージェントの中で、ゴールド・イメージによってデプロイまたは更新されている数と、まだゴールド・イメージによってデプロイまたは更新されていない数を示します。マウスをグラフに重ねると、管理エージェントの正確な数が表示されます。

2

エージェント・ゴールド・イメージの名前。

エージェント・ゴールド・イメージの詳細を表示するには、ゴールド・イメージをクリックします。「ゴールド・イメージ」ページに、そのゴールド・イメージに対して作成されたイメージ・バージョンの詳細が表示されます。また、ゴールド・イメージ・バージョンごとに、詳細、関連付けられたインスタンス・プロパティ、デプロイされているプラグインとパッチ、実行されたアクティビティ、構成されているステージングの場所が表示されます。

注意: 「ゴールド・イメージ」ページには、バージョン・ステータスが最新(アクティブ)または制限に設定されたゴールド・イメージ・バージョンのみが表示されます。他のステータスのゴールド・イメージ・バージョンは表示されません。ステータスにかかわらず特定のゴールド・イメージのすべてのゴールド・イメージ・バージョンを表示する場合は、エージェント・ゴールド・イメージ・ページで「イメージ・バージョンとサブスクリプションの管理」をクリックします。「イメージの管理」ページで「バージョンとドラフト」タブをクリックします。

3

エージェント・ゴールド・イメージに関連付けられている(サブスクラブしている)管理エージェントの数。これには、ゴールド・イメージで更新されていない管理エージェントだけでなく、更新されていないがゴールド・イメージをサブスクライブしている管理エージェントも含まれます。

管理エージェントがゴールド・イメージをサブスクライブすることは、特定のイメージ・バージョンを使用して管理エージェントを更新するための前提条件です。

4

ゴールド・イメージをサブスクライブし、そのゴールド・イメージによって更新された管理エージェントの数。

5

最新のゴールド・イメージ・バージョンと一致する管理エージェントのパーセンテージ。

6

管理エージェントがサブスクライブしているゴールド・イメージ・バージョンの数。これには、管理エージェントがサブスクライブしている最新バージョンを含め、すべてのゴールド・イメージが含まれます。

7

エージェント・ゴールド・イメージが作成されるプラットフォーム。

8

エージェント・ゴールド・イメージを管理できます。ゴールド・イメージを作成、編集または削除できます。これまでに作成されたゴールド・イメージの詳細も表示できます。

9

エージェント・ゴールド・イメージ・アクティビティのリスト。たとえば、Enterprise Managerジョブ・システムに発行されたジョブ、それらのステータス、アクティビティの開始時刻や終了時刻など。

10

エージェント・ゴールド・イメージの名前と最終変更日時。

11

更新が保留されているエージェント・ゴールド・イメージのリスト。

12

エージェント・ゴールド・イメージに関連する通知のリスト。

11.4 管理エージェント・ベース・ディレクトリ構造の理解

この項では、ゴールド・イメージを使用してプロビジョニング、アップグレードまたは更新が行われる管理エージェント・ベース・ディレクトリ構造について説明します。内容は次のとおりです。

- ゴールド・イメージを使用して管理エージェントがプロビジョニングされた後のエージェント・ベース・ディレクトリ構造

- ゴールド・イメージを使用して管理エージェントが12cから13cへアップグレードまたは更新された後のエージェント・ベース・ディレクトリ構造

11.4.1 ゴールド・イメージを使用して管理エージェントがプロビジョニングされた後のエージェント・ベース・ディレクトリ構造

次に示すのは、ゴールド・イメージを使用してプロビジョニングされた管理エージェント・ベース・ディレクトリ構造です。

<agent_base_directory>
|_____agent_13.1.0.0.0
|_____bin
|_____sysman
|_____root.sh
|_____agent.rsp
|_____oraInst.loc
|_____plugins
|_____OPatch
|_____oracle_common
|_____cfgtoollogs
|_____perl
|_____stage
|_____ocm
|_____lib
|_____inventory
|_____install
|_____config
|_____EMStage
|_____.
|_____.
|_____.
|_____oraInventory
|_____agent_inst
|_____sbin
|_____plugins.txt
|_____plugins.txt.status
|_____agentimage.properties

11.4.2 ゴールド・イメージを使用して管理エージェントが12cから13cへアップグレードまたは更新された後のエージェント・ベース・ディレクトリ構造

次に示すのは、ゴールド・イメージを使用してアップグレードまたは更新された管理エージェント・ベース・ディレクトリ構造です。

<agent_base_directory>
|_____GoldImage_<gold_image_name>
|_____agentInstall.rsp
|_____agent_13.1.0.0.0
|_____agentimage.properties
|_____backup_agtup
|_____plugins.txt
|_____plugins.txt.status
|_____agent_inst
|_____agentimage.properties
|_____core
|_____plugins
|_____plugins.txt
|_____plugins.txt.status
|_____sbin
|_____cfgtoollogs
|_____install
|_____inventory
|_____oraInst.loc
|_____.
|_____.
|_____.

11.5 エージェント・ゴールド・イメージのライフサイクルの管理

注意:
エージェント・ゴールド・イメージ・コンソールとその操作に関するデモを表示するには、次のURLにアクセスし、ビデオの開始をクリックします。
https://apexapps.oracle.com/pls/apex/f?p=44785:24:0:::24:P24_CONTENT_ID,P24_PREV_PAGE:12891,1

エージェント・ゴールド・イメージでは次のライフサイクル管理操作を実行できます。

- エージェント・ゴールド・イメージの作成

- エージェント・ゴールド・イメージの編集

- エージェント・ゴールド・イメージの削除

- エージェント・ゴールド・イメージ・バージョンの作成

- エージェント・ゴールド・イメージ・バージョンの削除

- エージェント・ゴールド・イメージ・バージョンのステージング

- 特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

- 特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

- エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

- エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

- エージェント・ゴールド・イメージを使用した管理エージェントのプロビジョニング

- エージェント・ゴールド・イメージ・バージョンを使用した管理エージェントの更新

11.5.1 エージェント・ゴールド・イメージの作成

エージェント・ゴールド・イメージを作成するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージの作成

- EM CLIを使用したエージェント・ゴールド・イメージの作成

11.5.1.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージの作成

エージェント・ゴールド・イメージを作成するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 「すべてのイメージの管理」をクリックします。

3. 「作成」をクリックします。

4. エージェント・ゴールド・イメージ・バージョンを作成するために使用するゴールド・イメージ名、説明(オプション)およびソース管理エージェントのプラットフォームを指定します。ソースとしてスタンドアロンの管理エージェントのみを使用し、セントラル・エージェントは使用しないでください。

5. 「発行」をクリックします。

11.5.1.2 EM CLIを使用したエージェント・ゴールド・イメージの作成

EM CLIを使用してエージェント・ゴールド・イメージ・バージョンを作成すると、エージェント・ゴールド・イメージが自動的に作成されます。

EM CLIを使用してエージェント・ゴールド・イメージ・バージョンを作成することでエージェント・ゴールド・イメージを作成するには、第11.5.4.2項を参照してください

11.5.2 エージェント・ゴールド・イメージの編集

注意:
エージェント・ゴールド・イメージ・バージョンを作成していない場合のみ、エージェント・ゴールド・イメージを編集できます。

エージェント・ゴールド・イメージを編集するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 「すべてのイメージの管理」をクリックします。

3. 編集するゴールド・イメージを選択し、「編集」をクリックします。

4. ゴールド・イメージ名、説明およびプラットフォーム詳細を編集します。

5. 「発行」をクリックします。

11.5.3 エージェント・ゴールド・イメージの削除

注意:
エージェント・ゴールド・イメージ・バージョンを作成していない場合のみ、エージェント・ゴールド・イメージを削除できます。

エージェント・ゴールド・イメージを削除するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 「すべてのイメージの管理」をクリックします。

3. 削除するゴールド・イメージを選択し、「削除」をクリックします。

11.5.4 エージェント・ゴールド・イメージ・バージョンの作成

エージェント・ゴールド・イメージ・バージョンを作成するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンの作成

- EM CLIを使用したエージェント・ゴールド・イメージ・バージョンの作成

11.5.4.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンの作成

エージェント・ゴールド・イメージ・バージョンを作成するには、次の手順に従います。

注意:
セキュアでない管理エージェントを使用してエージェント・ゴールド・イメージ・バージョンを作成することはできません。したがって、必ずセキュアな管理エージェントのみを使用してください。エージェント・ゴールド・イメージ・バージョンを作成する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章の説明に従ってハードウェア要件を満たす必要があります。
ソース管理エージェントの構成プロパティがなんらかの理由によりemd.propertiesファイルで変更された場合は、ソース管理エージェントを使用してエージェント・ゴールド・イメージ・バージョンを作成する前に、その管理エージェントの構成プロパティを再ロードしてください。これを行うには、次のコマンドを実行します。

emctl reload agent

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. 「バージョンとドラフト」タブを選択し、「アクション」メニューから「作成」を選択します。

5. 必要に応じて、イメージ・バージョン名およびイメージ・バージョンの説明を入力します。
イメージ・バージョンを作成し、それを使用して管理エージェントを更新するとき、Enterprise Manager Cloud Controlは、ここに指定されたイメージ・バージョン名を使用して、更新対象の管理エージェントのエージェント・ベース・ディレクトリにサブディレクトリを作成します。

たとえば、更新対象の管理エージェントのエージェント・ベース・ディレクトリが/u01/software/em13c/agentbasedirでエージェント・ホームが/u01/software/em13c/agentbasedir/agent_13.1.0.0.0の場合に、イメージ・バージョン名としてOPB_BP1を指定すると、このイメージ・バージョンで管理エージェントを更新するときに新しいサブディレクトリ/u01/software/em13c/agentbasedir/GoldImage_OPB_BP1/agent_13.1.0.0.0が作成されます。イメージ・バージョン名は20文字に制限されます。

6. ソース管理エージェントを使用してゴールド・イメージ・バージョンを作成する場合、「イメージの作成」では、「ソース・エージェントの選択」を選択し、次に使用するソース管理エージェントを指定します。この場合、次も指定できます。

- 作業ディレクトリ: エージェント・ゴールド・イメージを作成するために使用する必要がある作業ディレクトリ。デフォルトの作業ディレクトリは$AGENT_INSTANCE_HOME/installです。この場所に少なくとも750MB以上の空き領域があることを確認してください。

- 構成プロパティ: エージェント・ゴールド・イメージの作成時に取得する必要がある管理エージェントの構成プロパティをセミコロン(;)で区切って指定します。これらのプロパティの名前は$AGENT_INSTANCE_HOME/sysman/config/emd.propertiesファイルにあります。

- 除外ファイル: エージェント・ゴールド・イメージの作成時にソース・エージェントのエージェント・ベース・ディレクトリから除外するファイルのリスト。完全ファイル・パスを指定してください。複数のファイルがある場合はセミコロン(;)で区切ります。

ただし、既存のゴールド・イメージ・バージョンをインポートしてゴールド・イメージ・バージョンを作成する場合、「イメージの作成」では、「イメージのインポート」を選択し、次にインポートするゴールド・イメージ・バージョンの場所を指定します。イメージをインポートするためには、そのイメージがすでにステージングされている必要があります。この目的のためにイメージをまだステージングしていない場合は、第11.5.6.1項の説明に従ってステージングしてください。

7. 「OK」をクリックします。
エージェント・ゴールド・イメージ・バージョンを作成するジョブが、Enterprise Managerジョブ・システムに発行されます。ゴールド・エージェント・イメージ・アクティビティ・ページのイメージ・アクティビティ・タブでこのジョブのステータスを表示できます。

11.5.4.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンの作成

EM CLIを使用してエージェント・ゴールド・イメージ・バージョンを作成するには、次の手順に従います。

注意:
セキュアでない管理エージェントを使用してエージェント・ゴールド・イメージ・バージョンを作成することはできません。したがって、必ずセキュアな管理エージェントのみを使用してください。エージェント・ゴールド・イメージ・バージョンを作成する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章の説明に従ってハードウェア要件を満たす必要があります。
ソース管理エージェントの構成プロパティがなんらかの理由によりemd.propertiesファイルで変更された場合は、ソース管理エージェントを使用してエージェント・ゴールド・イメージ・バージョンを作成する前に、その管理エージェントの構成プロパティを再ロードしてください。これを行うには、次のコマンドを実行します。

emctl reload agent

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. create_gold_agent_image動詞を実行し、指定のソース管理エージェントを使用するか、すでに作成されたイメージを別のEnterprise Managementシステムからインポートして、エージェント・ゴールド・イメージを作成します。

$<OMS_HOME>/bin/emcli create_gold_agent_image
-image_name="gold_image_name"
-version_name="gold_image_version_name"
-source_agent|-import_location="source_agent|import_location"
[-gold_image_description="gold_image_description"]
[-working_directory="working_directory_location"]
[-config_properties= " agent_configuration_properties"]
[-exclude_files= "list_of_files_directories_to_exclude"]

[ ]内のパラメータはオプションであることに注意してください。

表11-2に、EM CLIを使用したエージェント・ゴールド・イメージ・バージョンの作成でサポートされるパラメータを示して説明します。

表11-2 エージェント・ゴールド・イメージ・バージョンの作成でサポートされるパラメータ

パラメータ

説明

-image_name

作成したエージェント・ゴールド・イメージの追加先エージェント・ゴールド・イメージ名。

-version_name

エージェント・ゴールド・イメージのバージョン名。

イメージ・バージョンを作成し、それを使用して管理エージェントを更新するとき、Enterprise Manager Cloud Controlは、ここに指定されたイメージ・バージョン名を使用して、更新対象の管理エージェントのエージェント・ベース・ディレクトリにサブディレクトリを作成します。

たとえば、更新対象の管理エージェントのエージェント・ベース・ディレクトリが/u01/software/em13c/agentbasedirでエージェント・ホームが/u01/software/em13c/agentbasedir/agent_13.1.0.0.0の場合に、イメージ・バージョン名としてOPB_BP1を指定すると、このイメージ・バージョンで管理エージェントを更新するときに新しいサブディレクトリ/u01/software/em13c/agentbasedir/GoldImage_OPB_BP1/agent_13.1.0.0.0が作成されます。イメージ・バージョン名は20文字に制限されます。

-source_agent

エージェント・ゴールド・イメージを作成するためのソースとして使用される管理エージェント。

ゴールド・イメージを作成するソースとして使用できる管理エージェントのリストを表示するには、emcli get_targets -target="oracle_emd"を実行します。

-import_location

ゴールド・エージェント・イメージ・バージョンを作成するためにエージェント・ゴールド・イメージがステージングされる場所。この場所は、すべてのOMSインスタンスからアクセスできます。

-gold_image_description

エージェント・ゴールド・イメージの説明。

-working_directory

エージェント・ゴールド・イメージの作成に使用される作業ディレクトリ。デフォルトの作業ディレクトリは$AGENT_INSTANCE_HOME/installです。少なくとも1GBの空き領域が必要です。

-config_properties

エージェント・ゴールド・イメージの作成時に取得する必要がある管理エージェントの構成プロパティをセミコロン(;)で区切って指定します。たとえば、MaxThread;GracefulShutdownです。

-exclude_files

ゴールド・エージェント・イメージ・バージョンから除外するファイルまたはディレクトリをセミコロン(;)で区切ったリスト。たとえば、agent_13.1.0.0.0/cfgtoollogs/agentDeploy;agent_13.1.0.0.0/ouiと指定します。ファイルやディレクトリの絶対パスではなく相対パスを指定してください。

例:

- 次の例では、ソース管理エージェントとしてexample.com:3872を使用するエージェント・ゴールド・イメージOPC_AGI_DB_JUL_13が作成され、そのゴールド・イメージ・バージョンがゴールド・イメージOPC_DB_MONITORINGに追加されます。

$<OMS_HOME>/bin/emcli create_gold_agent_image -source_agent=example.com:3872 -version_name=OPC_AGI_DB_JUL_13 -image_name=OPC_DB_MONITORING

- 次の例では、ソース管理エージェントとしてexample.com:3872を使用し作業ディレクトリとして/tmpするエージェント・ゴールド・イメージOPC_AGI_DB_JUL_13が作成され、そのゴールド・イメージ・バージョンがゴールド・イメージOPC_DB_MONITORINGに追加されます。

$<OMS_HOME>/bin/emcli create_gold_agent_image -source_agent=example.com:3872 -version_name=OPC_AGI_DB_JUL_13 -image_name=OPC_DB_MONITORING -working_directory=/tmp

- 次の例では、インポート場所/abc/stageにステージングされたゴールド・イメージ・ソフトウェアを使用してエージェント・ゴールド・イメージOPC_AGI_DB_JUL_13が作成されます。

$<OMS_HOME>/bin/emcli create_gold_agent_image -import_location=/abc/stage -version_name=OPC_AGI_DB_JUL_13 -image_name=OPC_DB_MONITORING

11.5.5 エージェント・ゴールド・イメージ・バージョンの削除

エージェント・ゴールド・イメージ・バージョンを削除するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンの削除

- EM CLIを使用したエージェント・ゴールド・イメージ・バージョンの削除

11.5.5.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンの削除

エージェント・ゴールド・イメージ・バージョンを削除するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. バージョンとドラフト・タブを選択します。

注意:
アクティブな(現在の)イメージは削除できません。

5. 削除するゴールド・イメージ・バージョンを選択し、次に「アクション」メニューから、「削除」を選択します。

11.5.5.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンの削除

EM CLIを使用してエージェント・ゴールド・イメージ・バージョンを削除するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. delete_gold_agent_image動詞を実行します。

$<OMS_HOME>/bin/emcli delete_gold_agent_image         -version_name="gold_image_version_name_to_delete"

-version_nameパラメータを使用して、削除するエージェント・ゴールド・イメージを指定します。

たとえば、エージェント・ゴールド・イメージOPC_AGI_DB_JUL_13を削除するには次を実行します。

$<OMS_HOME>/bin/emcli delete_gold_agent_image -version_name=OPC_AGI_DB_JUL_13

11.5.6 エージェント・ゴールド・イメージ・バージョンのステージング

機能しているエージェント・ゴールド・イメージ・バージョンをホストにステージングするには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンのステージング

- EM CLIを使用したエージェント・ゴールド・イメージ・バージョンのステージング

11.5.6.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・バージョンのステージング

ホストでエージェント・ゴールド・イメージ・バージョンをステージングするには、次の手順に従います。

注意:
エージェント・ゴールド・イメージ・バージョンをステージングする前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章の説明に従ってハードウェア要件を満たす必要があります。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. バージョンとドラフト・タブを選択します。ステージングするゴールド・イメージ・バージョンを選択し、次に「アクション」メニューから、「ステージング」を選択します。

5. エージェント・ゴールド・イメージ・バージョンをステージングするホストおよびホストの場所を入力します。「OK」をクリックします。
エージェント・ゴールド・イメージ・バージョンをステージングするジョブが、Enterprise Managerジョブ・システムに発行されます。ゴールド・エージェント・イメージ・アクティビティ・ページのイメージ・アクティビティ・タブでこのジョブのステータスを表示できます。

11.5.6.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンのステージング

EM CLIを使用してエージェント・ゴールド・イメージ・バージョンをステージングするには、次の手順に従います。

注意:
エージェント・ゴールド・イメージ・バージョンをステージングする前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章の説明に従ってハードウェア要件を満たす必要があります。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. stage_gold_agent_image動詞を実行して、宛先ホストでエージェント・ゴールド・イメージをステージングします。

$<OMS_HOME>/bin/ emcli stage_gold_agent_image         -version_name="gold_image_version_to_stage"        -image_name="gold_image_name "        -host_name="staging_destination_host"        -stage_location="stage_location_on_destination_host"

表11-3に、EM CLIを使用したエージェント・ゴールド・イメージ・バージョンのステージングでサポートされるパラメータを示して説明します。

表11-3 エージェント・ゴールド・イメージ・バージョンのステージングでサポートされるパラメータ

パラメータ

説明

-version_name

ステージングするエージェント・ゴールド・イメージ・バージョン。

-image_name

ステージングするエージェント・ゴールド・イメージ。

-host_name

エージェント・ゴールド・イメージをステージングする宛先ホスト。前提条件として管理エージェントはこのホストで実行している必要があります。

-stage_location

エージェント・ゴールド・イメージをステージングする宛先ホスト上の場所。該当のエージェント・ゴールド・イメージによって更新される管理エージェントからアクセスできる共有の場所を指定する必要があります。それ以外の場合、この場所からのエージェント・ゴールド・イメージのインポートに使用されるOMSがこの場所にアクセスできることが必要です。また、少なくとも1GBの空き領域が必要です。

たとえば、ゴールド・イメージOPC_AGI_DBのエージェント・ゴールド・イメージOPC_AGI_DB_JUL_13をホストexample.com上のステージング場所/net/stage/agentにステージングするには、次を実行します。

$<OMS_HOME>/bin/emcli stage_gold_agent_image -version_name=OPC_AGI_DB_JUL_13 -stage_location=/net/stage/agent -host_name=example.com

11.5.7 特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

企業で管理エージェントを標準化するために使用するエージェント・ゴールド・イメージの最新バージョンは、エージェント・ゴールド・イメージの現在のバージョンと呼ばれます。

エージェント・ゴールド・イメージ・バージョンが作成されると、ドラフト・バージョンとしてマークされます。エージェント・ゴールド・イメージのドラフト・バージョンを現在のバージョンとして設定することは、ゴールド・イメージ・バージョンが管理エージェントの大規模デプロイまたは大規模更新で使用できる準備ができていることを意味します。いったん「アクティブ」(「現在」)に設定されたイメージは、ドラフト・バージョンまたは制限されたバージョンに戻すことができません。

エージェント・ゴールド・イメージのドラフト・バージョンを現在のバージョンとして設定するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用した特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

- EM CLIを使用して特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

11.5.7.1 「ゴールド・エージェント・イメージ」ホームページを使用した特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

エージェント・ゴールド・イメージのドラフト・バージョンを現在のバージョンとして設定するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. バージョンとドラフト・タブを選択します。現在のバージョンとして設定するゴールド・イメージ・バージョンを選択して、「現行バージョンの設定」をクリックします。
エージェント・ゴールド・イメージ・ドラフト・バージョンを現在のバージョンに昇格するジョブはEnterprise Managerジョブ・システムに発行されます。ゴールド・エージェント・イメージ・アクティビティ・ページのイメージ・アクティビティ・タブでこのジョブのステータスを表示できます。

11.5.7.2 EM CLIを使用して特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定

EM CLIを使用して特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. promote_gold_agent_image動詞を実行して、エージェント・ゴールド・イメージ・バージョンをCurrent成熟度レベルに昇格します。

$<OMS_HOME>/bin/emcli promote_gold_agent_image         -version_name="gold_image_version_name"        -maturity="Current/Restricted/Draft"

-version_nameパラメータは、昇格するエージェント・ゴールド・イメージを定義します。

-maturityパラメータはゴールド・イメージの成熟度レベルを定義します。

たとえば、エージェント・ゴールド・イメージOPC_AGI_DB_JUL_13をCurrent成熟度レベルに昇格するには次を実行します。

$<OMS_HOME>/bin/emcli promote_gold_agent_image  -version_name=OPC_AGI_DB_JUL_13 -maturity=Current

11.5.8 特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

エージェント・ゴールド・イメージのドラフト・バージョンまたはアクティブ・バージョンを制限されたバージョンとして設定するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用して特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

- EM CLIを使用して特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

11.5.8.1 「ゴールド・エージェント・イメージ」ホームページを使用して特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

エージェント・ゴールド・イメージのドラフト・バージョンまたはアクティブ・バージョンを制限されたバージョンとして設定するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. バージョンとドラフト・タブを選択します。制限されたバージョンとして設定するゴールド・イメージ・バージョンを選択し、「制限されたバージョンの設定」をクリックします。

11.5.8.2 EM CLIを使用して特定のエージェント・ゴールド・イメージ・バージョンを制限されたバージョンとして設定

EM CLIを使用してエージェント・ゴールド・イメージ・バージョンのドラフト・バージョンまたはアクティブ・バージョンを制限されたバージョンとして設定するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. promote_gold_agent_image動詞を実行して、エージェント・ゴールド・イメージ・バージョンをRestricted成熟度レベルに昇格します。

$<OMS_HOME>/bin/emcli promote_gold_agent_image         -version_name="gold_image_version_name"        -maturity="Current/Restricted/Draft"

-version_nameパラメータは、昇格するエージェント・ゴールド・イメージを定義します。

-maturityパラメータはゴールド・イメージの成熟度レベルを定義します。

たとえば、エージェント・ゴールド・イメージOPC_AGI_DB_JUL_13をRestricted成熟度レベルに昇格するには次を実行します。

$<OMS_HOME>/bin/emcli promote_gold_agent_image  -version_name=OPC_AGI_DB_JUL_13 -maturity=Restricted

11.5.9 エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

エージェント・ゴールド・イメージをサブスクライブするように一連の管理エージェントを設定するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

- EM CLIを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

11.5.9.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

注意:

エージェント・ゴールド・イメージを使用して共有エージェント(NFSエージェント)のインストール、更新またはアップグレードを行うことはできません。

次の管理エージェントはエージェント・ゴールド・イメージをサブスクライブできません。

- セントラル・エージェント。

- すでにサブスクライブしている管理エージェント。

- 共有エージェント(NFSエージェント)。

- セキュアでない管理エージェント。

- エージェント・ゴールド・イメージがあるプラットフォームとは別のプラットフォーム上にある管理エージェント。
プラットフォームはOracleホーム・コレクションによって識別されるため、Oracleホーム・ターゲットの検出と収集が行われるように確認します。このためには、管理エージェントのホームページの「サマリー」セクションで「Oracleホームとパッチの詳細」をクリックし、次のページで「構成のリフレッシュ」をクリックします。

エージェント・ゴールド・イメージをサブスクライブするように一連の管理エージェントを設定するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. 「サブスクリプション」タブを選択します。「サブスクライブ」をクリックします。

5. 必要な管理エージェントを検索して選択し、「選択」をクリックします。

11.5.9.2 EM CLIを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ設定

注意:

エージェント・ゴールド・イメージを使用して共有エージェント(NFSエージェント)のインストール、更新またはアップグレードを行うことはできません。

次の管理エージェントはエージェント・ゴールド・イメージをサブスクライブできません。

- セントラル・エージェント。

- すでにサブスクライブしている管理エージェント。

- 共有エージェント(NFSエージェント)。

- セキュアでない管理エージェント。

- エージェント・ゴールド・イメージがあるプラットフォームとは別のプラットフォーム上にある管理エージェント。
プラットフォームはOracleホーム・コレクションによって識別されるため、Oracleホーム・ターゲットの検出と収集が行われるように確認します。このためには、管理エージェントのホームページの「サマリー」セクションで「Oracleホームとパッチの詳細」をクリックし、次のページで「構成のリフレッシュ」をクリックします。

EM CLIを使用してエージェント・ゴールド・イメージをサブスクライブするように管理エージェントを設定するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. subscribe_agents動詞を実行して、特定のエージェント・ゴールド・イメージに対する指定の管理エージェントのサブスクライブを設定します。

$<OMS_HOME>/bin/emcli subscribe_agents
-image_name="Image Name"
[-agents="agent_name_pattern"]
[-groups="group_name"]

[ ]内のパラメータはオプションであることに注意してください。

-image_nameパラメータに指定されたエージェント・ゴールド・イメージを管理エージェントがサブスクライブします。

-agentsパラメータに指定された名前パターンと一致する管理エージェントのみがサブスクライブします。

-groupsパラメータに指定されたグループに所属する管理エージェントのみがサブスクライブします。

例:

- 次の例では、名前パターンabc%またはxyz.domain.com:1243と一致する管理エージェントがエージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブします。

$<OMS_HOME>/bin/emcli subscribe_agents -image_name="OPC_AGT_ADC_POD" -agents="abc%,xyz.domain.com:1243"

- 次の例では、すべての管理エージェントがエージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブします。

$<OMS_HOME>/bin/emcli subscribe_agents -image_name="OPC_AGT_ADC_POD"

- 次の例では、グループGROUP1またはGRP2に所属するすべての管理エージェントがエージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブします。

$<OMS_HOME>/bin/emcli subscribe_agents -image_name="OPC_AGT_ADC_POD" -groups="GROUP1,GRP2"

11.5.10 エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブを解除するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

- EM CLIを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

11.5.10.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

管理エージェントのエージェント・ゴールド・イメージに対するサブスクライブを解除するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. 「サブスクリプション」タブを選択します。エージェント・ゴールド・イメージからサブスクライブ解除する管理エージェントを選択します。「サブスクライブ解除」をクリックします。「OK」を選択します。

11.5.10.2 EM CLIを使用したエージェント・ゴールド・イメージに対する管理エージェントのサブスクライブ解除

EM CLIを使用して管理エージェントのエージェント・ゴールド・イメージに対するサブスクライブを解除するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. unsubscribe_agents動詞を実行して、特定のエージェント・ゴールド・イメージに対する指定の管理エージェントのサブスクライブを解除します。

$<OMS_HOME>/bin/emcli unsubscribe_agents         -image_name="Image Name"         [-agents="Full Agent Name"]         [-groups="List of group names"]         [-closure_related="true/false"]        [-closure_nfs="true/false"]

[ ]内のパラメータはオプションであることに注意してください。

表11-4に、エージェント・ゴールド・イメージから管理エージェントをサブスクライブ解除するためにサポートされているパラメータを示して説明します。

表11-4 管理エージェントのサブスクライブ解除のためにサポートされているパラメータ

パラメータ

説明

-image_name

指定したエージェント・ゴールド・イメージをサブスクライブしている管理エージェントのサブスクライブを解除します。

-agents

指定したパターンと一致する管理エージェントのサブスクライブを解除します。

-groups

指定したグループに所属する管理エージェントのサブスクライブを解除します。

-closure_related

このパラメータに指定した値が「false」の場合、関連する管理エージェントはサブスクライブ解除されません。

-closure_shared

このパラメータに指定した値が「false」の場合、関連する共有エージェントはサブスクライブ解除されません。

例:

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブし、名前パターンabc%またはxyz.domain.com:1243と一致する管理エージェントのサブスクライブを解除します。

$<OMS_HOME>/bin/emcli unsubscribe_agents -image_name="OPC_AGT_ADC_POD" -agents="abc%,xyz.domain.com:1243"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブするすべての管理エージェントのサブスクライブを解除します。

$<OMS_HOME>/bin/emcli unsubscribe_agents -image_name="OPC_AGT_ADC_POD"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブし、グループGROUP1またはGRP2に所属する管理エージェントのサブスクライブを解除します。

$<OMS_HOME>/bin/emcli unsubscribe_agents -image_name="OPC_AGT_ADC_POD" -groups="GROUP1,GRP2"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブしている、xyz.domain.com:1243および関連する共有エージェントのサブスクライブを解除します。

$<OMS_HOME>/bin/emcli unsubscribe_agents -image_name="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -closure_shared="true"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_PODをサブスクライブしている、xyz.domain.com:1243および関連する管理エージェントのサブスクライブを解除します。

$<OMS_HOME>/bin/emcli unsubscribe_agents -image_name="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -closure_related="true"

11.5.11 エージェント・ゴールド・イメージを使用した管理エージェントのプロビジョニング

『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

注意:
エージェント・ゴールド・イメージを使用して共有エージェント(NFSエージェント)のインストール、更新またはアップグレードを行うことはできません。共有エージェントの詳細は、第8.1項を参照してください。

11.5.12 エージェント・ゴールド・イメージ・バージョンを使用した管理エージェントの更新

エージェント・ゴールド・イメージ・バージョンを使用して管理エージェントを更新するには、次の手順に従います。

1. エージェント・ゴールド・イメージを作成します。これには、第11.5.1項を参照してください。

2. エージェント・ゴールド・イメージ・バージョンを作成します。これには、第11.5.4項を参照してください。

3. 特定のエージェント・ゴールド・イメージ・バージョンを現在のバージョンとして設定します。これには、第11.5.7項を参照してください。

4. エージェント・ゴールド・イメージに対する管理エージェントのサブスクライブを設定します。これには、第11.5.9項を参照してください。

5. 管理エージェントを更新します。エージェント・ゴールド・イメージ・バージョンを使用して管理エージェントを更新するには、次のいずれかの方法を使用します。

- エージェント・ゴールド・イメージによる管理エージェントの更新

- EM CLIを使用したエージェント・ゴールド・イメージ・バージョンによる管理エージェントの更新

注意:
エージェント・ゴールド・イメージ・バージョンを使用してスタンドアロン管理エージェントを更新する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章の説明に従ってハードウェア要件を満たす必要があります。

注意:
関連する一連の管理エージェントをエージェント・ゴールド・イメージに更新する場合は、関連するエージェントをすべて更新する必要があります。ただし、選択した一部のエージェントのみをエージェント・ゴールド・イメージに更新する場合には、これをオーバーライドするオプションがあります。これをアーカイブするには、EM_GI_MASTER_INFO表のパラメータclosureRelatedをfalseに設定する必要があります。

注意:
エージェント・ゴールド・イメージを使用して共有エージェント(NFSエージェント)のインストール、更新またはアップグレードを行うことはできません。

11.5.12.1 エージェント・ゴールド・イメージによる管理エージェントの更新

エージェント・ゴールド・イメージ・バージョンを使用して管理エージェントを更新するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 目的のエージェント・ゴールド・イメージの名前をクリックします。

3. イメージ・バージョンおよびサブスクリプションの管理をクリックします。

4. 「サブスクリプション」タブを選択します。更新する管理エージェントを選択し、「更新」を選択してから「現行バージョン」または「制限されたバージョン」を選択します。

5. 管理エージェント更新ジョブのデフォルト・ジョブ名を受け入れます。これは必要に応じて変更できます。
前の手順で特定の管理エージェントを含めそびれ、ここで更新操作に含める場合には、「追加」を選択して追加管理エージェントを入力します。

sbinディレクトリが変更されている場合(特に完全エージェント・アップグレード)またはsbin固有のパッチがある場合は、管理エージェントの更新後、管理エージェント・ホストの特権優先資格証明を使用して、管理エージェントでroot.shスクリプトが実行されます。

このような資格証明がまだ設定されていない場合は、「優先資格証明のオーバーライド」をクリックして、かわりに使用する資格証明を入力します。

「次へ」をクリックします。

6. デフォルトでは「事前にステージングされたイメージ・バージョン」は選択されていません。この場合、宛先ホストのローカルのステージング場所を指定します。ただし、「事前にステージングされたイメージ・バージョン」を選択する場合は、すべての管理エージェントからアクセスできる、NFSマウントされた共有ステージング場所を指定します。
また、管理エージェント・デプロイメントのメソッドを入力します。デフォルト・オプション「プッシュ」を選択する場合、OMSは管理エージェント・ソフトウェアを更新操作用に選択されたすべてのホストに転送します。ただし、かわりにOMSから管理エージェント・ソフトウェアを取得するために管理エージェントを各宛先ホストに存在させる場合は、プルを選択します。

7. 「追加の入力」セクションで、更新操作前および更新操作後に実行するスクリプトを指定します。スクリプトがOMSホスト上に存在する場合、「OMSホスト上のスクリプト」を選択するようにしてください。さらに、更新操作で使用する追加パラメータも指定します。表11-5に、管理エージェントを更新する際に使用できるその他のパラメータを示します。

表11-5 13c管理エージェントの更新用の追加パラメータのリスト

パラメータ

説明

-ignorePrereqs

前提条件チェックの実行をスキップします。

すでに前提条件を確認しており、アップグレードの残りのプロセスを実行するだけの場合は、このパラメータを指定します。

-debug

デバッグとエラーの解決に役立つデバッグ・メッセージをログに記録します。

8. 「スケジュール」セクションで、次の値を指定します。

- 「バッチ・サイズ」: 管理エージェント更新アクティビティは、管理エージェントがバッチで更新される方法で実行されます。バッチ・サイズは、バッチに存在する管理エージェントの数を示します。

- ジョブの時間間隔: アプリケーションが現在のバッチ処理が完了したかどうかを確認するまでの時間(分)。

- 成功率: バッチが完了した後、次のバッチが開始するまでに更新する必要がある管理エージェントの合計数(つまり、現在の更新バッチの一部である管理エージェントと前の更新バッチの一部であった管理エージェント)の割合。
たとえば、会社に1000個のエージェントがデプロイされていて、バッチ・サイズが100、バッチ成功率が90に設定されており、エージェントが100個ずつのバッチで更新されるとします。このケースでは、1つのバッチが完了したときにアプリケーションが次のバッチに移動するのは、管理エージェントの合計数の90パーセントが正常に更新された場合のみです。

- 開始: 更新操作を開始する時間および更新操作を終了する時間。デフォルトでは時間設定は「即時」です。このコンテキストでは、これはOMS時間とみなされます。

- 期間: 更新操作の実行を続ける期間。

10. 「通知」セクションで、更新ジョブ進行状況について送信先となる電子メール・アドレスを指定します。

11. 新規の管理エージェントOracleホームの場所でシェル・プロファイルを更新する場合、「シェル・プロファイル」セクションで、「シェル・プロファイルの更新」を選択し、シェル・プロファイルの場所を入力します。
デフォルトではこれは選択されていません。必要に応じて選択します。

12. 「クリーンアップ・オプション」セクションで次のいずれかを選択します。

- クリーンアップ前: 管理エージェントを更新する前に、古いエージェント・ホームまたはアクティブではないエージェント・ホームをクリーンアップします。

- クリーンアップ後: 管理エージェントを更新した後で、古いエージェント・ホームまたはアクティブではないエージェント・ホームをクリーンアップします。

注意:
クリーンアップ処理がこの時点で実行されない場合、後からエージェント・アップグレード・コンソールを使用して実行できます。詳細は、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

管理エージェントを更新するジョブがEnterprise Managerジョブ・システムに発行されます。ゴールド・エージェント・イメージ・アクティビティ・ページのアクティビティの更新タブでこのジョブのステータスを表示できます。

13. 「更新」をクリックします。
管理エージェントを更新するジョブがEnterprise Managerジョブ・システムに発行されます。ゴールド・エージェント・イメージ・アクティビティ・ページのアクティビティの更新タブでこのジョブのステータスを表示できます。

11.5.12.2 EM CLIを使用したエージェント・ゴールド・イメージ・バージョンによる管理エージェントの更新

EM CLIを使用してエージェント・ゴールド・イメージ・バージョンで管理エージェントを更新するには、次の手順に従います。

注意:
エージェント・ゴールド・イメージ・バージョンを使用してスタンドアロン管理エージェントを更新する前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のハードウェア要件に関する章の説明に従ってハードウェア要件を満たす必要があります。

1. OMSのOracleホーム内の/binディレクトリからEM CLIにログインします。

$<ORACLE_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<ORACLE_HOME>/bin/emcli sync

3. get_updatable_agents動詞を実行して、特定のエージェント・ゴールド・イメージ・バージョンまたはエージェント・ゴールド・イメージを使用して更新できる管理エージェントを表示します。

$<ORACLE_HOME>/bin/emcli get_updatable_agents         -version_name  | -image_name         [-agents="Full Agent Name"]         [-versions="List of Versions"]        [-groups="List of group names"]        [-output_file="Location of the output file"]

[ ]内のパラメータはオプションであることに注意してください。

注意:
-version_nameパラメータまたは-image_nameパラメータを指定する必要があります。両方を指定すると、各パラメータを個別に指定した際の結果の和集合が表示されます。

注意:
更新できない管理エージェントのリストを表示するには、get_not_updatable_agents動詞を実行します。

emcli get_not_updatable_agents
[-version_name  | -image_name]

[ ]が付いているパラメータはオプションです。

表11-6に、特定の管理エージェント・イメージ・バージョンで更新可能な管理エージェントを表示するためにサポートされるパラメータを示して説明します。

表11-6 更新可能な管理エージェントの表示のためにサポートされているパラメータ

パラメータ

説明

-version_name

このオプションを指定すると、指定したエージェント・ゴールド・イメージ・バージョンを使用して更新できる管理エージェントが表示されます。

-image_name

このオプションを指定すると、指定したエージェント・ゴールド・イメージを使用して更新できる管理エージェントが表示されます。

-versions

このオプションを指定すると、指定したバージョンに含まれる更新可能な管理エージェントが表示されます。

-agents

このオプションを指定すると、指定した名前パターンと一致する更新可能な管理エージェントが表示されます。

-groups

このオプションを指定すると、指定した名前パターンと一致するグループに含まれる、更新可能な管理エージェントが表示されます。

-output_file

このオプションを指定すると、更新できる管理エージェントの表示リストが出力ファイルに追加されます。

例:

- 次の例では、最新のエージェント・ゴールド・イメージOPC_AGT_ADC_PODを使用して更新できる管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_updatable_agents -image_name="OPC_AGT_ADC_POD"

- 次の例では、エージェント・ゴールド・イメージ・バージョンOPC_AGT_ADC_POD_JUNEを使用して更新できる管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_updatable_agents -version_name="OPC_AGT_ADC_POD_JUNE"

- 次の例では、エージェント・ゴールド・イメージ・バージョンOPC_AGT_ADC_POD_JUNEを使用して更新できる、バージョン12.1.0.1.0または12.1.0.2.0の管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_updatable_agents -version_name="OPC_AGT_ADC_POD_JUNE" -versions="12.1.0.1.0,12.1.0.2.0"

- 次の例では、エージェント・ゴールド・イメージ・バージョンOPC_AGT_ADC_POD_JUNEを使用して更新できる、GROUP1またはGRP2に所属する管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_updatable_agents -version_name="OPC_AGT_ADC_POD_JUNE" -groups="GROUP1,GRP2"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用して更新できる管理エージェントが表示され、出力ファイル/scratch/agents_file.txtに追加されます。

<ORACLE_HOME>/bin/emcli get_updatable_agents -image_name="OPC_AGT_ADC_POD_JUNE" -output_file="/scratch/agents_file.txt"

4. update_agents動詞を実行して、管理エージェントを更新するための環境を準備し、管理エージェントの更新ジョブを発行します。

<ORACLE_HOME>/bin/emcli update_agents
-version_name | -image_name
-agents="agent_names" | -input_file="agents_file:input_file_location"
[-pre_script_loc="location_of_pre_script"]
[-pre_script_on_oms]
[-post_script_loc="location_of_post_script"]
[-post_script_on_oms]
[-op_name="custom_operation_name"]
[-override_credential="named_credential"]
[-additional_parameters]
[-stage_location="custom_stage_location"]
[-is_staged="true|false"]
[-stage_action="push|pull"]
[-batch_size]
[-start_time]
[-end_time]
[-frequency]<
[-success_rate]
[-runPrecleanup]
{-runPostcleanup]
[-email]
[-update_profile]
[-profile_path]

[ ]内のパラメータはオプションであることに注意してください。

注意:
-version_nameパラメータまたは-image_nameパラメータを指定する必要があります。また、-agentsパラメータまたは-input_fileパラメータを更新する必要があります。-agentsと-input_fileの両方を指定すると、各パラメータを個別に指定した際の結果の和集合が表示されます。
すべてのパラメータは-input_fileパラメータを使用してレスポンス・ファイルに渡すことができます。たとえば、-input_file="response_file:/scratch/response_file.txt"です。

レスポンス・ファイルでは、パラメータごとに改行して名前と値のペアを指定する必要があります。たとえば、op_name=UPDATE_AGT_121020です

同じパラメータが、コマンドラインとレスポンス・ファイルの両方で渡された場合、コマンドライン・パラメータの値が優先されます。

表11-7に、エージェント・ゴールド・イメージ・バージョンを使用して管理エージェントを更新するためにサポートされているパラメータを示して説明します。

表11-7 エージェント・ゴールド・イメージ・バージョンを使用した管理エージェントの更新のためにサポートされるパラメータ

パラメータ

説明

-version_name

管理エージェントの更新先のエージェント・ゴールド・イメージ・バージョン。

-image_name

管理エージェントの更新先のエージェント・ゴールド・イメージ。

-agents

更新する必要があるすべての管理エージェントの名前。

-input_file

更新対象の管理エージェントをリストするファイルの絶対パス。

-pre_script_loc

管理エージェントを更新する前に実行する必要があるスクリプトの絶対パス。

-pre_script_on_oms

前処理スクリプトがOMSホストに存在することを指定します。

-post_script_loc

管理エージェントを更新した後で実行する必要があるスクリプトの絶対パス。

-post_script_on_oms

後処理スクリプトがOMSホストに存在することを指定します。

-op_name

管理エージェント更新のカスタム操作名。

-override_credential

資格証明を別に指定して優先資格証明をオーバーライドします。通常、更新の後でroot.shを特定の管理エージェントで実行するために、管理エージェントのOracleホームの優先資格証明が使用されます。ただし、このオプションを指定すると優先資格証明がオーバーライドされます。

-additional_parameters

管理エージェントの更新に渡すその他のパラメータ。

-stage_location

管理エージェント更新のためのカスタムのステージング場所。イメージがまだステージングされていない場合、必要な最小空き領域は1GBです。イメージを事前ステージングする場合は、更新対象のすべての管理エージェントがこの場所にアクセスできるようにします。

-is_staged

エージェント・ゴールド・イメージをすでにステージングした場合は「true」に設定します。

-stage_action

エージェント・ゴールド・イメージをプルして管理エージェントを更新する場合は「pull」を設定します。通常、エージェント・ゴールド・イメージがステージングされていない場合、デフォルトではエージェント・ゴールド・イメージは更新対象の管理エージェントにプッシュされます。「pull」を設定するとエージェント・ゴールド・イメージがプルされます。

-batch_size

更新バッチに含まれる管理エージェントの数。デフォルト値は100です。

-start_time

更新ジョブの開始時刻。\" yyyy-mm-dd hh:mm:ss\"形式で指定します。

-end_time

更新ジョブの終了時刻。\" yyyy-mm-dd hh:mm:ss\"形式で指定します。

-frequency

現在のバッチが完了したかどうかをアプリケーションがチェックしてから、更新の次のバッチをスケジュールするまでの時間(分)。デフォルト値。

-success_rate

次のバッチが開始するために、前のバッチで正常に更新される必要がある管理エージェントの合計数に対するパーセンテージ。デフォルト値は90です。

-runPrecleanup

管理エージェントを更新する前に、古いエージェント・ホームをクリーンアップします。

-runPostcleanup

管理エージェントを更新した後で、古いエージェント・ホームをクリーンアップします。

-email

合致が完了した時点で通知を送信する電子メールIDをカンマ(,)で区切って指定します。

-update_profile

プロファイルがエージェントOracleホームで設定されていることを指定します。

-profile_path

更新プロファイル・オプションが選択された場合に、ユーザー・プロファイルの絶対パスをカンマ(,)で区切って指定します。

例:

- 次の例では、シリーズOPC_AGT_ADC_POD内の最新エージェント・ゴールド・イメージを使用してxyz.domain.com:1243を更新します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_series="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用してxyz.domain.com:1243を更新します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_name="OPC_AGT_ADC_POD_JUNE" -agents="xyz.domain.com:1243"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用して、入力ファイル/scratch/agents_file.txtにあるすべての管理エージェントを更新します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_name="OPC_AGT_ADC_POD_JUNE" -input_file="agents_file:/scratch/agents_file.txt"

- 次の例では、/scratch/pre_scriptを実行してから、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用してxyz.domain.com:1243を更新します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_name="OPC_AGT_ADC_POD_JUNE" -agents="xyz.domain.com:1243" -pre_script_loc="/scratch/pre_script"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用してxyz.domain.com:1243を更新してから、/scratch/post_scriptを実行します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_name="OPC_AGT_ADC_POD_JUNE" -agents="xyz.domain.com:1243" -post_script_loc="/scratch/post_script"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用してxyz.domain.com:1243を更新します(更新ジョブUPDATE_JOB123を作成します)。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_name="OPC_AGT_ADC_POD_JUNE" -agents="xyz.domain.com:1243" -op_name="UPDATE_JOB123"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用してxyz.domain.com:1243を更新し、更新後にNAMED_CRED123を使用してroot.shを実行します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_name="OPC_AGT_ADC_POD_JUNE" -agents="xyz.domain.com:1243" -override_credential="NAMED_CRED123"

- 次の例では、追加のパラメータを2つ渡し、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEを使用してxyz.domain.com:1243を更新します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_name="OPC_AGT_ADC_POD_JUNE" -agents="xyz.domain.com:1243" -additional_parameters="-ignorePrereqs -newParameter"

- 次の例では、追加のパラメータを2つ渡し、シリーズOPC_AGT_ADC_POD内の最新エージェント・ゴールド・イメージを使用してxyz.domain.com:1243を更新します。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_series="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -additional_parameters="-ignorePrereqs -newParameter"

- 次の例では、シリーズOPC_AGT_ADC_POD内の最新エージェント・ゴールド・イメージを使用してxyz.domain.com:1243を更新します。ゴールド・イメージはステージングしません。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_series="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -is_staged="true"

- 次の例では、シリーズOPC_AGT_ADC_POD内の最新エージェント・ゴールド・イメージを使用してxyz.domain.com:1243を更新します。ゴールド・イメージはxyz.domain.com:1243によってプルされます。

<ORACLE_HOME>/bin/emcli update_agents -gold_image_series="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -stage_action="pull"

- 次の例では、各バッチで最大150の管理エージェントを更新する設定で、管理エージェントの更新を実行します。

<ORACLE_HOME>/bin/emcli update_agents -image_name="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -batch_size=150

- 次の例では、各バッチで最大150の管理エージェントを更新する設定で、管理エージェントの更新を実行します。

注意:
次のバッチがスケジュールされるのは、前のバッチで管理エージェントの80%が正常に更新された場合のみです。

<ORACLE_HOME>/bin/emcli update_agents -image_name="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -batch_size=150 success_rate=80

- 次の例では、エージェント更新ジョブが5月7日10:00:00 AMに開始し5月8日10:00:00 AMに終了するようにスケジュールします。

<ORACLE_HOME>/bin/emcli update_agents -image_name="OPC_AGT_ADC_POD" -agents="xyz.domain.com:1243" -start_time="2014-05-07 10:00:00" -end_time="2014-05-08 10:00:00"

5. get_agent_update_status動詞を実行して、管理エージェントの更新結果を表示します。

<ORACLE_HOME>/bin/emcli get_agent_update_status
-version_name | -op_name
[-agent="agent_name_pattern"]
[-severity="ERROR|WARNING"]
[-severity_id="severity_id"]
[-status="PendingUpdateInprogress|Updatable|NotUpdatable|NotExecuted|Success|Inprogress|Failed"]

[ ]内のパラメータはオプションであることに注意してください。

注意:
-op_nameパラメータまたは-version_nameパラメータを指定する必要があります。-severityまたは-severity_idを指定した場合は、-version_nameまたは-statusは指定しないでください。

表11-8に、管理エージェントの更新ステータスを表示するためにサポートされているパラメータを示して説明します。

表11-8 管理エージェントの更新ステータスを表示するためにサポートされるパラメータ

パラメータ

説明

-version_name

指定したエージェント・ゴールド・イメージ・バージョン名について発行された更新操作の詳細を表示します。

-op_name

指定した更新操作の詳細を表示します。

-agent

指定した名前パターンの管理エージェントに対して発行された操作の詳細を表示します。

-status

指定したステータスの更新操作の詳細を表示します。

-severity

指定した重大度レベルの更新操作の詳細を表示します。

-severity_id

指定した重大度IDの更新操作の詳細を表示します。

例:

- 次の例では、エージェント・ゴールド・イメージ・バージョンOPC_AGT_ADC_POD_JUNEに対して発行された更新操作の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status -version_name="OPC_AGT_ADC_POD_JUNE"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEと管理エージェントxyz.domain.com:1243に対して発行された更新操作の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status -version_name="OPC_AGT_ADC_POD_JUNE" -agent="xyz.domain.com:1243"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEと、ステータスがFailedの管理エージェントxyz.domain.com:1243に対して発行された更新操作の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status -version_name="OPC_AGT_ADC_POD_JUNE" -agent="xyz.domain.com:1243" -status="Failed"

- 次の例では、更新操作UPDATE_JOB123の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123"

- 次の例では、管理エージェントxyz.domain.com:1243の更新操作UPDATE_JOB123の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status -op_name="UPDATE_JOB123" -agent="xyz.domain.com:1243"

- 次の例では、ステータスがFailedの管理エージェントについて更新操作UPDATE_JOB123の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status -op_name="UPDATE_JOB123" -status="Failed"

- 次の例では、ステータスがFailedの管理エージェントxyz.domain.com:1243について更新操作UPDATE_JOB123の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status -op_name="UPDATE_JOB123" -status="Failed" -agent="xyz.domain.com:1243"

- 次の例では、重大度がERRORの更新操作UPDATE_JOB123について管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123" -severity="ERROR"

- 次の例では、重大度がWARNINGで重大度IDがROOT_RUN_CHECKの更新操作UPDATE_JOB123について管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123" -severity="WARNING" -severity_id="ROOT_RUN_CHECK"

- 次の例では、重大度IDがROOT_RUN_CHECKの更新操作UPDATE_JOB123について管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123" -severity_id="ROOT_RUN_CHECK"

- 次の例では、重大度がERRORの管理エージェントxyz.domain.com:1243について更新操作UPDATE_JOB123の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123" -severity="ERROR"  -agent="xyz.domain.com:1243"

- 次の例では、重大度IDがROOT_RUN_CHECKの管理エージェントxyz.domain.com:1243について更新操作UPDATE_JOB123の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123" -severity_id="ROOT_RUN_CHECK"  -agent="xyz.domain.com:1243"

- 次の例では、重大度がWARNINGで重大度IDがROOT_RUN_CHECKの管理エージェントxyz.domain.com:1243について更新操作UPDATE_JOB123の詳細が表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123" -severity="WARNING" -severity_id="ROOT_RUN_CHECK"  -agent="xyz.domain.com:1243"

- 次の例では、重大度がERRORの更新操作UPDATE_JOB123について管理エージェントが表示されます。

<ORACLE_HOME>/bin/emcli get_agent_update_status  -op_name="UPDATE_JOB123" -severity="ERROR"

11.6 エージェント・ゴールド・イメージ・アクティビティ詳細の表示

エージェント・ゴールド・イメージ・アクティビティ(つまり、Enterprise Managerジョブ・システムに発行されるジョブ)およびステータス、アクティビティが開始した時刻、アクティビティが終了した時刻などの詳細を表示するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・アクティビティ詳細の表示

- EM CLIを使用したエージェント・ゴールド・イメージ・アクティビティ詳細の表示

11.6.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージ・アクティビティ詳細の表示

エージェント・ゴールド・イメージ・アクティビティのリストを表示するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. 「アクティビティ」セクションで、すべてのアクティビティを表示をクリックします。

3. エージェント・ゴールド・イメージ・アクティビティ、管理エージェント更新アクティビティまたは管理エージェント・サブスクライブ解除アクティビティのステータス詳細を表示するには、それぞれ「イメージ・アクティビティ」、「更新アクティビティ」または「サブスクライブ解除アクティビティ」タブを選択します。

4. 特定のエージェント・ゴールド・イメージ・アクティビティ、管理エージェント更新アクティビティまたは管理エージェント・サブスクライブ解除アクティビティの実行詳細を表示するには、ジョブ名をクリックします。

11.6.2 EM CLIを使用したエージェント・ゴールド・イメージ・アクティビティ詳細の表示

EM CLIを使用してエージェント・ゴールド・イメージのアクティビティ詳細を表示するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. list_gold_agent_image_activities動詞を実行して、指定したエージェント・ゴールド・イメージが含まれるアクティビティのリストを表示します。

$<OMS_HOME>/bin/emcli list_gold_agent_image_activities         -version_name="gold_image_version_name"        [-noheader]        [-script | -format=                           [name:<pretty|script|csv>];                           [column_separator:"column_sep_string"];                           [row_separator:"row_sep_string"];        ]

[ ]内のパラメータはオプションであることに注意してください。

表11-9に、エージェント・ゴールド・イメージの詳細を表示するためにサポートされているパラメータを示して説明します。

表11-9 エージェント・ゴールド・イメージの詳細を表示するためにサポートされているパラメータ

パラメータ

説明

-version_name

アクティビティを表示するエージェント・ゴールド・イメージ・バージョン。

-no_header

列見出しのない表形式の出力を表示します。

-script

このパラメータは、-format="name:script"と同じです。

-format

このパラメータは出力形式のタイプを定義します。このパラメータのデフォルト値は-format="name:pretty"です。

-format="name:pretty"は読取り可能な書式で出力表を出力します。スクリプトで解析することはできません。

-format="name:script"は、デフォルトの列セパレータをタブ文字に、デフォルトの行セパレータを改行文字に設定します。column_separator文字列およびrow_separator文字列を指定すると、これらのデフォルト文字を変更できます。

-format="name:csv"は、列セパレータをカンマに、行セパレータを改行文字に設定します。

たとえば、エージェント・ゴールド・イメージOPC_AGI_DB_JUL_13のアクティビティ詳細を表示するには次のコマンドを実行します。

$<OMS_HOME>/bin/emcli list_gold_agent_image_activities -version_name=OPC_AGI_DB_JUL_13

4. get_gold_agent_image_activity_statusを実行して、エージェント・ゴールド・イメージのアクティビティ・ステータスを確認することもできます。

$<OMS_HOME>/bin/emcli get_gold_agent_image_activity_status
-operation_name="gold_image_operation_name"
[-noheader]
[-script | -format=
[name:<pretty|script|csv>];
[column_separator:"column_sep_string"];
[row_separator:"row_sep_string"];
]

表11-10に、エージェント・ゴールド・イメージのアクティビティ・ステータスを表示するためにサポートされているパラメータを示して説明します。

表11-10 エージェント・ゴールド・イメージのアクティビティ・ステータスを表示するためにサポートされているパラメータ

パラメータ

説明

-operation_name

特定のエージェント・ゴールド・イメージ・アクティビティのステータスを表示します。

-no_header

列見出しのない表形式の出力を表示します。

-script

このパラメータは、-format="name:script"と同じです。

-format

このパラメータは出力形式のタイプを定義します。このパラメータのデフォルト値は-format="name:pretty"です。

-format="name:pretty"は読取り可能な書式で出力表を出力します。スクリプトで解析することはできません。

-format="name:script"は、デフォルトの列セパレータをタブ文字に、デフォルトの行セパレータを改行文字に設定します。column_separator文字列およびrow_separator文字列を指定すると、これらのデフォルト文字を変更できます。

-format="name:csv"は、列セパレータをカンマに、行セパレータを改行文字に設定します。

たとえば、エージェント・ゴールド・イメージ操作GOLDAGENTIMAGE_CREATE_2013_12_22_12_12_52_535のアクティビティ・ステータスを表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli get_gold_agent_image_activity_status  -operation_name=GOLDAGENTIMAGE_CREATE_2013_12_22_12_12_52_535

11.7 エージェント・ゴールド・イメージ・コンプライアンス・レベルのチェック

すべてのエージェント・ゴールド・イメージのコンプライアンス・レベルをチェックするには、「設定」メニューで「Cloud Controlの管理」、「ゴールド・エージェント・イメージ」の順に選択します。

ゴールド・イメージと一致する管理エージェントと、ゴールド・イメージと一致しない管理エージェントの数が図示されます(縦棒グラフ)。マウスを縦棒に重ねると、該当する管理エージェントの正確な数が表示されます。

縦棒グラフの下の表には、これまでに作成されたゴールド・イメージの詳細が表示されます。コンプライアンス・レベルをチェックするには、「コンプライアンス」列を確認します。

11.8 エージェント・ゴールド・イメージの詳細の表示

エージェント・ゴールド・イメージの詳細を表示するには、次のいずれかの方法を使用します。

- 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージおよびエージェント・ゴールド・イメージ・バージョンの詳細の表示

- EM CLIを使用したエージェント・ゴールド・イメージの詳細の表示

11.8.1 「ゴールド・エージェント・イメージ」ホームページを使用したエージェント・ゴールド・イメージおよびエージェント・ゴールド・イメージ・バージョンの詳細の表示

「ゴールド・エージェント・イメージ」ホームページを使用してエージェント・ゴールド・イメージおよびゴールド・イメージ・バージョンの詳細を表示するには、「設定」メニューで「Cloud Controlの管理」、「ゴールド・エージェント・イメージ」の順に選択します。

ゴールド・イメージと一致する管理エージェントと、ゴールド・イメージと一致しない管理エージェントの数が図示されます(縦棒グラフ)。マウスを縦棒に重ねると、該当する管理エージェントの正確な数が表示されます。

縦棒グラフの下の表には、これまでに作成されたゴールド・イメージの詳細が表示されます。表11-11に詳細を示します。

表11-11 ゴールド・エージェント・イメージの詳細

列名

説明

ゴールド・イメージ名

エージェント・ゴールド・イメージの名前。

エージェント・ゴールド・イメージとそのバージョンの詳細を表示するには、ゴールド・イメージをクリックします。「ゴールド・エージェント・イメージ」ページに、そのゴールド・イメージに対して作成されたデプロイメントとイメージ・バージョンの詳細が表示されます。また、ゴールド・イメージ・バージョンごとに、詳細、関連付けられたインスタンス・プロパティ、デプロイされているプラグインとパッチ、実行されたアクティビティ、構成されているステージングの場所が表示されます。

注意: 「ゴールド・イメージ」ページには、バージョン・ステータスが最新(アクティブ)または制限に設定されたゴールド・イメージ・バージョンのみが表示されます。他のステータスのゴールド・イメージ・バージョンは表示されません。ステータスにかかわらず特定のゴールド・イメージのすべてのゴールド・イメージ・バージョンを表示する場合は、エージェント・ゴールド・イメージ・ページで「イメージ・バージョンとサブスクリプションの管理」をクリックします。「イメージの管理」ページで「バージョンとドラフト」タブをクリックします。

サブスクライブされたエージェント

エージェント・ゴールド・イメージに関連付けられている(サブスクラブしている)管理エージェントの数。これには、ゴールド・イメージで更新されていない管理エージェントだけでなく、更新されていないがゴールド・イメージをサブスクライブしている管理エージェントも含まれます。

管理エージェントがゴールド・イメージをサブスクライブすることは、特定のイメージ・バージョンを使用して管理エージェントを更新するための前提条件です。

ゴールド・イメージ上のエージェント

ゴールド・イメージをサブスクライブし、そのゴールド・イメージによって更新された管理エージェントの数。

コンプライアンス

最新のゴールド・イメージ・バージョンと一致する管理エージェントのパーセンテージ。

デプロイされたゴールド・イメージのバージョンの数

管理エージェントがサブスクライブしているゴールド・イメージ・バージョンの数。これには、管理エージェントがサブスクライブしている最新バージョンを含め、すべてのゴールド・イメージが含まれます。

プラットフォーム名

エージェント・ゴールド・イメージが作成されるプラットフォーム。

11.8.2 EM CLIを使用したエージェント・ゴールド・イメージの詳細の表示

EM CLIを使用してエージェント・ゴールド・イメージの詳細を表示するには、次の手順に従います。

1. OMSホーム内の/binディレクトリからEM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<OMS_HOME>/bin/emcli sync

3. list_gold_agent_images動詞を実行して、これまでに作成された様々なエージェント・ゴールド・イメージをリスト表示します。

$<OMS_HOME>/bin/emcli list_gold_agent_images         [-noheader]        [-script | -format=                           [name:<pretty|script|csv>];                           [column_separator:"column_sep_string"];                           [row_separator:"row_sep_string"];        ]

[ ]内のパラメータはオプションであることに注意してください。

表11-12に、エージェント・ゴールド・イメージのリストを表示するためにサポートされているパラメータを示して説明します。

表11-12 エージェント・ゴールド・イメージのリストを表示するためにサポートされているパラメータ

パラメータ

説明

-no_header

列見出しのない表形式の出力を表示します。

-script

このパラメータは、-format="name:script"と同じです。

-format

このパラメータは出力形式のタイプを定義します。このパラメータのデフォルト値は-format="name:pretty"です。

-format="name:pretty"は読取り可能な書式で出力表を出力します。スクリプトで解析することはできません。

-format="name:script"は、デフォルトの列セパレータをタブ文字に、デフォルトの行セパレータを改行文字に設定します。column_separator文字列およびrow_separator文字列を指定すると、これらのデフォルト文字を変更できます。

-format="name:csv"は、列セパレータをカンマに、行セパレータを改行文字に設定します。

4. list_gold_agent_imageversions動詞を実行して、エージェント・ゴールド・イメージ・バージョンをリスト表示します。

$<OMS_HOME>/bin/emcli list_gold_agent_imageversions         [-image_name="gold_image_name"]        [-all]        [-noheader]        [-script | -format=                           [name:<pretty|script|csv>];                           [column_separator:"column_sep_string"];                           [row_separator:"row_sep_string"];        ]

[ ]内のパラメータはオプションであることに注意してください。

表11-13に、エージェント・ゴールド・イメージ・バージョンのリストを表示するためにサポートされているパラメータを示して説明します。

表11-13 エージェント・ゴールド・イメージ・バージョンのリストを表示するためにサポートされているパラメータ

パラメータ

説明

-image_name

特定のエージェント・ゴールド・イメージに含まれるエージェント・ゴールド・イメージ・バージョンを表示するパラメータ。

-all

すべてのエージェント・ゴールド・イメージを表示するパラメータ。

-no_header

列見出しのない表形式の出力を表示するパラメータ。

-script

このパラメータは、-format="name:script"と同じです。

-format

このパラメータは出力形式のタイプを定義します。このパラメータのデフォルト値は-format="name:pretty"です。

-format="name:pretty"は読取り可能な書式で出力表を出力します。スクリプトで解析することはできません。

-format="name:script"は、デフォルトの列セパレータをタブ文字に、デフォルトの行セパレータを改行文字に設定します。column_separator文字列およびrow_separator文字列を指定すると、これらのデフォルト文字を変更できます。

-format="name:csv"は、列セパレータをカンマに、行セパレータを改行文字に設定します。

たとえば、Currentに昇格されたエージェント・ゴールド・イメージを表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli list_gold_agent_imageversions

OPC_DB_MONITORINGに含まれ、Currentに昇格されたエージェント・ゴールド・イメージ・バージョンを表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli list_gold_agent_imageversions -image_name=OPC_DB_MONITORING

5. get_gold_agent_image_details動詞を実行して、エージェント・ゴールド・イメージのプラットフォーム、プラグイン、パッチ、構成プロパティおよび管理エージェントの詳細を表示します。

$<OMS_HOME>/bin/emcli get_gold_agent_image_details         -version_name="gold_image_version_name"        [-platform]        [-plugin]        [-patch]        [-config_properties]        [-agent]        [-noheader]        [-script | -format=                           [name:<pretty|script|csv>];                           [column_separator:"column_sep_string"];                           [row_separator:"row_sep_string"];        ]

[ ]内のパラメータはオプションであることに注意してください。

表11-14に、エージェント・ゴールド・イメージのプラットフォーム、プラグイン、パッチ、構成プロパティおよび管理エージェント詳細を表示するためにサポートされているパラメータを示して説明します。

表11-14 エージェント・ゴールド・イメージの詳細を表示するためにサポートされているパラメータ

パラメータ

説明

-version_name

詳細を表示するエージェント・ゴールド・イメージ・バージョンの名前。

-platform

エージェント・ゴールド・イメージのプラットフォームの詳細。

-plugin

エージェント・ゴールド・イメージのプラグインの詳細。

-patch

エージェント・ゴールド・イメージのパッチの詳細。

-config_properties

エージェント・ゴールド・イメージの構成プロパティ。

-agent

エージェント・ゴールド・イメージの管理エージェントの詳細。

-no_header

列見出しのない表形式の出力。

-script

このパラメータは、-format="name:script"と同じです。

-format

このパラメータは出力形式のタイプを定義します。このパラメータのデフォルト値は-format="name:pretty"です。

-format="name:pretty"は読取り可能な書式で出力表を出力します。スクリプトで解析することはできません。

-format="name:script"は、デフォルトの列セパレータをタブ文字に、デフォルトの行セパレータを改行文字に設定します。column_separator文字列およびrow_separator文字列を指定すると、これらのデフォルト文字を変更できます。

-format="name:csv"は、列セパレータをカンマに、行セパレータを改行文字に設定します。

たとえば、エージェント・ゴールド・イメージOPC_AGI_DB_JUL_13のプラットフォーム、プラグインおよびパッチの詳細を表示するには次のコマンドを実行します。

$<OMS_HOME>/bin/emcli get_gold_agent_image_details -version_name=OPC_AGI_DB_JUL_13

6. また、list_agents_on_gold_image動詞を実行して、特定のエージェント・ゴールド・イメージ・バージョンを使用してデプロイまたは更新された管理エージェントのリスト、すなわちエージェント・ゴールド・イメージの全体的なエージェント・デプロイメント・レポートを表示することもできます。

$<OMS_HOME>/bin/emcli list_agents_on_gold_image         -version_name|-image_name="gold_image_version_name|gold_image_name"        [-agent_name="agent_name_pattern"]

[ ]内のパラメータはオプションであることに注意してください。

-version_nameパラメータを指定して、特定のエージェント・ゴールド・イメージ・バージョンを使用してデプロイまたは更新された管理エージェントが表示します。

-image_nameパラメータを指定して、指定のエージェント・ゴールド・イメージについてデプロイされた管理エージェントの数を表示します。

-agent_nameパラメータを指定して、指定の名前パターンと一致する管理エージェントのみを表示します。

たとえば、エージェント・ゴールド・イメージOPC_AGI_DB_JUL_13を使用してデプロイまたは更新された管理エージェントを表示するには次のコマンドを実行します。

$<OMS_HOME>/bin/emcli list_agents_on_gold_image -version_name=OPC_AGI_DB_JUL_13

ゴールド・イメージOPC_DB_MONITORINGに含まれるエージェント・ゴールド・イメージ・バージョンのいずれかを使用してデプロイまたは更新された管理エージェントの数を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli list_agents_on_gold_image -image_name=OPC_DB_MONITORING

11.9 エージェント・ゴールド・イメージに関連する通知の表示

エージェント・ゴールド・イメージに関連する通知を表示するには、次の手順を実行します。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. ゴールド・エージェント・イメージ・ページの右側にある「通知」セクションでゴールド・イメージに関する通知を表示します。

11.10 保留中の更新のあるエージェント・ゴールド・イメージの表示

保留中の更新のあるエージェント・ゴールド・イメージを表示するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. ゴールド・エージェント・イメージ・ページの右側にある「アクション必須」セクションでゴールド・イメージに対する保留中の更新を表示します。

3. さらにドリルダウンして最新のゴールド・イメージ・バージョンで管理エージェントを更新するには、ゴールド・イメージ名をクリックします。

11.11 最後に変更されたエージェント・ゴールド・イメージの表示

最後に変更されたエージェント・ゴールド・イメージを表示するには、次の手順に従います。

1. 「設定」メニューで「Cloud Controlの管理」を選択し、次に「ゴールド・エージェント・イメージ」を選択します。

2. ゴールド・エージェント・イメージ・ページの右側にある「最後のイメージ変更」セクションで最後に変更されたゴールド・イメージの日付とタイムスタンプを表示します。

11.12 エージェント・ゴールド・イメージに関連するログ・ファイルの表示

エージェント・ゴールド・イメージに関連するログ・ファイルを表示するには、付録Aを参照してください。

11.13 EM CLIを使用したサブスクライブ解除操作のステータスの表示

サブスクライブ解除操作のステータスを表示するには、次の手順に従います。

1. Oracleホーム内の/binディレクトリからEM CLIにログインします。

$<ORACLE_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<ORACLE_HOME>/bin/emcli sync

3. emcli get_agent_unsubscribe_status動詞を実行して、サブスクライブ解除操作のステータスを表示します。

<ORACLE_HOME>/bin/emcli get_agent_unsubscribe_status
-version_name | -op_name
[-agent="agent_name_pattern"]
[-severity="ERROR|WARNING"]
[-severity_id="severity_id"]
[-status="PendingUpdateInprogress|Updatable|NotUpdatable|NotExecuted|Success|Inprogress|Failed"]

[ ]内のパラメータはオプションであることに注意してください。

表11-15に、EM CLIを使用したサブスクライブ解除操作ステータスの表示のためにサポートされているパラメータを示して説明します。

注意:
-op_nameパラメータまたは-version_nameパラメータを指定する必要があります。-severityまたは-severity_idを指定した場合は、-version_nameまたは-statusは指定しないでください。

表11-15 サブスクライブ解除操作のステータスを表示するためにサポートされているパラメータ

パラメータ

説明

-version_name

サブスクライブ解除されたエージェント・ゴールド・イメージのバージョン名。

--op_name

サブスクライブ解除されたエージェント・ゴールド・イメージの操作名。

-agent

サブスクライブ解除されたエージェント・ゴールド・イメージのエージェント名。

-severity

エージェント・ゴールド・イメージの重大度ステータス。

-severity_id

エージェント・ゴールド・イメージの重大度ID。

-status

サブスクライブ解除されたエージェント・ゴールド・イメージのステータス。

例:

- 次の例では、エージェント・ゴールド・イメージ・バージョンOPC_AGT_ADC_POD_JUNEに対して発行されたサブスクライブ解除操作の詳細が表示されます。

emcli get_agent_unsubscribe_status -version_name="OPC_AGT_ADC_POD_JUNE"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEと管理エージェントxyz.domain.com:1243に対して発行されたサブスクライブ解除操作の詳細が表示されます。

emcli get_agent_unsubscribe_status -version_name="OPC_AGT_ADC_POD_JUNE" -agent="xyz.domain.com:1243"

- 次の例では、エージェント・ゴールド・イメージOPC_AGT_ADC_POD_JUNEと、ステータスがFailedの管理エージェントxyz.domain.com:1243に対して発行されたサブスクライブ解除操作の詳細が表示されます。

emcli get_agent_unsubscribe_status -version_name="OPC_AGT_ADC_POD_JUNE" -agent="xyz.domain.com:1243" -status="Failed"

- 次の例では、サブスクライブ解除操作UNSUBSCRIBE_JOB123の詳細が表示されます。

emcli get_agent_unsubscribe_status  -op_name="UNSUBSCRIBE_JOB123"

- 次の例では、ステータスがFailedの管理エージェントxyz.domain.com:1243についてサブスクライブ解除操作UNSUBSCRIBE_JOB123の詳細が表示されます。

emcli get_agent_unsubscribe_status -op_name="UNSUBSCRIBE_JOB123" -status="Failed" -agent="xyz.domain.com:1243"

11.14 EM CLIを使用した指定エージェント・ゴールド・イメージをサブスクライブする管理エージェント・リストの表示

指定のエージェント・ゴールド・イメージをサブスクライブする管理エージェントのリストを表示するには、次の手順に従います。

1. Oracleホーム内の/binディレクトリからEM CLIにログインします。

$<ORACLE_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<ORACLE_HOME>/bin/emcli sync

3. emcli list_gold_image_subscribed_agent動詞を実行して、サブスクライブ解除操作のステータスを表示します。

<ORACLE_HOME>/bin/emcli list_gold_image_subscribed_agent
-image_name="gold_image_name"
[-noheader]
[-script | -format=
[name:<pretty|script|csv>];
[column_separator:"column_sep_string"];
[row_separator:"row_sep_string"];
]

[ ]内のパラメータはオプションであることに注意してください。

表11-16に、指定管理ゴールド・イメージをサブスクライブするすべてのエージェントのリスト表示のためにサポートされているパラメータを示して説明します。

表11-16 指定エージェント・ゴールド・イメージをサブスクライブする管理エージェント・リストを表示するためにサポートされているパラメータ

パラメータ

説明

-image_name

エージェント・ゴールド・イメージをサブスクライブする特定の管理エージェントのイメージ名。

-noheader

列見出しのない表形式の出力。

-script

これは、-format="name:script"と同じです。

-format

エージェント・ゴールド・イメージをサブスクライブする特定の管理エージェントの形式を定義します。

例:

次の例では、OPC_DB_MONITORINGイメージをサブスクライブするすべてのエージェントが表示されます。

emcli list_gold_image_subscribed_agent -image_name=OPC_DB_MONITORING

11.15 エージェント・ゴールド・イメージ更新ポリシーの作成および管理エージェント・アップグレード用に設定するデフォルト値の定義

エージェント・ゴールド・イメージ更新ポリシーを作成して、管理エージェント・アップグレードのデフォルト値を定義するには、次の手順に従います。

1. Oracleホーム内の/binディレクトリからEM CLIにログインします。

$<ORACLE_HOME>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

2. EM CLIを同期します。

$<ORACLE_HOME>/bin/emcli sync

3. emcli set_gold_agent_update_policy動詞を実行して、管理エージェント・アップグレードのデフォルト値を定義します。

<ORACLE_HOME>/bin/emcli set_gold_agent_update_policy
[-additional_parameters="Additional_parameters seperated by space"]
[-pre_script_loc="Absolute path of Prescript location"]
[-post_script_loc="Absolute path of Postscript location"]
[-is_pre_script_on_oms="true/false"]
[-is_post_script_on_oms="true/false"]
[-stage_location="Absolute path of stage location]
[-is_staged="true/false"]
[-stage_action="Stage action]
[-batch_size="Batch size"]
[-frequency="Frequency"]
[-success_rate="Success rate"]
[-update_profile="true/false"]
[-profile_path="Profile path"]
[-email="Email IDs separated by comma"]
[-run_preCleanup="true/false"]
[-run_postCleanup="true/false"]

[ ]内のパラメータはオプションであることに注意してください。

表11-17に、管理エージェントのアップグレードとデフォルト値の定義のためにサポートされているパラメータを示して説明します。

表11-17 エージェントのアップグレードとデフォルト値の定義のためにサポートされているパラメータ

パラメータ

説明

-additional_parameters

エージェント・ゴールド・イメージ・ポリシーを作成するためにリポジトリに設定される追加パラメータ。

-pre_script_loc

エージェント・ゴールド・イメージ・ポリシーを作成するためにリポジトリに設定される前処理スクリプトの場所。

-post_script_loc

エージェント・ゴールド・イメージ・ポリシーを作成するためにリポジトリに設定される後処理スクリプトの場所。

-is_pre_script_on_oms

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定されるこのパラメータの値。

-is_post_script_on_oms

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定されるこのパラメータの値。

-stage_location

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定されるステージング場所の値。

-is_staged

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定されるこのパラメータの値。

-stage_action

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定されるステージング・アクションの値。

-batch_size

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定されるバッチ・サイズの値。

-frequency

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定される間隔の値。

-success_rate

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定される成功率の値。

-update_profile

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定される更新プロファイルの値。

-profile_path

エージェント・ゴールド・イメージ・ポリシーを作成するために、リポジトリに設定されるプロファイル・パスの値。

-email

エージェント・ゴールド・イメージ・ポリシーを作成するためにリポジトリに設定される電子メール。

-run_preCleanup

エージェント・ゴールド・イメージ・ポリシーを作成するために、このパラメータに設定される値。

-run_postCleanup

エージェント・ゴールド・イメージ・ポリシーを作成するために、このパラメータに設定される値。

例:

- 次の例では、リポジトリに追加パラメータを設定します。

emcli set_gold_agent_update_policy -additional_parameters=-ignorePrereqs

- 次の例では、リポジトリに前処理スクリプトの場所を設定します。

emcli set_gold_agent_update_policy -pre_script_loc=/home/john/pretscript

- 次の例では、リポジトリにステージング場所を設定します。

emcli set_gold_agent_update_policy -stage_location=/scratch/tmp

- 次の例では、リポジトリにバッチ・サイズを設定します。

emcli set_gold_agent_update_policy -batch_size=100

- 次の例では、リポジトリに成功率を設定します。

emcli set_gold_agent_update_policy -success_rate=90

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

ファイアウォールは、各ネットワーク・パケットを調べ適切な処理を決定することでネットワーク通信量を制限し、それによって、企業の情報技術(IT)インフラストラクチャを保護します。

ファイアウォールの構成には通常、ファイアウォールの片側(インターネットなど)に有効なポートの制限が含まれます。HTTPなど、特定のポートを通過できる通信の種類を限定するように設定することもできます。クライアントが制限付きポート(セキュリティ・ルールの対象外のポート)に接続を試行したり、不適切なプロトコルを使用すると、クライアントは即座にファイアウォールによって切断されます。特定のサーバーへのユーザー・アクセスを制限するために、ファイアウォールを企業のイントラネット内で使用することもできます。

Enterprise Manager Cloud Controlコンポーネントはエンタープライズ全体の異なるホストにデプロイできます。これらのホストはファイアウォールによって分割されます。この章では、様々なEnterprise Managerコンポーネント間の通信を可能にするファイアウォールの構成方法について説明します。

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

- Enterprise Managerシステムのファイアウォールの構成計画

- Enterprise Managerシステムの標準ファイアウォール構成

- WebブラウザとEnterprise Managerシステムの間のファイアウォールの構成

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

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

- OMSと管理リポジトリの間のファイアウォールの構成

- Enterprise Manager Cloud Controlコンソールと管理対象データベース・ターゲットの間のファイアウォールの構成

- 複数OMSインスタンスのファイアウォールの構成

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

- dontProxyforプロパティの構成

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

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

12.1 Enterprise Managerシステムのファイアウォールの構成計画

ファイアウォールの構成はEnterprise Managerのデプロイの最後に行います。ファイアウォールを構成する前に、Enterprise Managerコンソールにログインできることと、Oracle Management Agent (管理エージェント)が稼働中でターゲットを監視していることを確認してください。確認したら、第2.1.12項の説明に従ってデフォルト・ポートのファイアウォールを構成します。通常、デフォルト・ポートはEnterprise Managerシステムのインストール時に割り当てられます。ただし、Enterprise Managerシステムをインストールするときにデフォルト・ポートではなくカスタム・ポートを使用した場合は、カスタム・ポートのファイアウォールを構成してください。

ファイアウォールがすでに使用可能な環境にEnterprise Managerシステムをデプロイする場合は、インストールおよび構成プロセスを終了してEnterprise Managerにログインできることと、管理エージェントが稼働中でターゲットを監視していることを確認できるまで、使用するデフォルト・ポートまたはカスタム・ポートを開いておきます。

Oracle Management Service (OMS)のEnterprise Manager Framework Securityを有効にしている場合、その構成プロセスの最終ステップは、管理エージェントからのアップロードをセキュアなチャネルのみに限定することです。そのステップを終了する前に、管理エージェントと管理リポジトリの間でHTTPおよびHTTPS通信の両方が可能となるようにファイアウォールを構成し、Enterprise Managerにログインできることとデータがリポジトリにアップロード中であることを確認するテストを行います。両方のプロトコルが有効な状態でOMSと管理エージェントが通信できることを確認した後、セキュア・モードへの移行を終了し、必要に応じてファイアウォール構成を変更します。ファイアウォールを段階的に構成していくと、構成上の問題をより簡単に解決できます。

12.2 Enterprise Managerシステムの標準ファイアウォール構成

Enterprise Managerをファイアウォール保護環境下で動作するように設定する際の主な作業は、可能な場合はプロキシ・サーバーを利用すること、必要なポートのみをセキュアな通信で使用可能にすること、およびビジネスの運営に必要なデータのみがファイアウォールを通過するようにすることです。

図12-1に、ファイアウォールを使用するEnterprise Manager環境のトポロジ、および使用可能なデフォルト・ポートを示します。

図12-1 ファイアウォール・ポートの要件(デフォルト)

上の図で使用している表記規則は次のとおりです。

表12-1 図で使用されている表記規則

規則

説明

C

コールを行う実体。

*

Enterprise Managerは、Enterprise Managerの設定範囲内の使用可能な最初のポートをデフォルトとして使用します。

**

Enterprise Managerは、使用可能な最初のポートをデフォルトとして使用します。

***

データベース・リスナー・ポート。

注意:

- ポート1159、4898-4989では、1159がデフォルトです。このポートを使用できない場合は、Oracle Management Serviceによって指定範囲内(4889から4897)の検索が行われます。

- ファイアウォールによって分割された2つのターゲット・ホスト間でクローニングを行うには、それらのエージェントがエージェント・ポートで通信する必要があります。開始管理エージェントがコールを行います。

- ファイアウォール内でICMP (0)エコー・リプライおよびICMP (8)エコー・リクエストを許可します。

12.3 WebブラウザとEnterprise Managerシステムの間のファイアウォールの構成

WebブラウザからEnterprise Managerシステムへの接続は、Oracle HTTP Serverで使用されるデフォルト・ポート経由で実行されます。

Oracle HTTP Serverのデフォルトの非セキュア・ポートは7788です。7788が使用できない場合、7788から7798の範囲で使用可能な最初の空きポートが選択されます。次のURLおよびポートを使用してEnterprise Manager Cloud Controlコンソールにアクセスする場合、Enterprise Manager Cloud Controlコンソールでポート7788を経由してHTTP通信を受信できるように、ファイアウォールを構成する必要があります。

http://omshost.example.com:7788/em

Oracle HTTP Serverのセキュリティを有効にした場合、Oracle HTTP Serverのセキュア・ポートは7799です。7799が使用できない場合、7799から7809の範囲で使用可能な最初の空きポートが選択されます。次のURLおよびポートを使用してEnterprise Manager Cloud Controlコンソールにアクセスする場合、Enterprise Manager Cloud Controlコンソールでポート7799を経由してHTTPS通信を受信できるように、ファイアウォールを構成する必要があります。

https://omshost.example.com:7799/em

12.4 ファイアウォールで保護されたホスト上のOMSの構成

OMSがファイアウォールで保護されたホスト上にインストールされ、管理データを提供する管理エージェントがファイアウォールの反対側にある場合は、次の作業を実行する必要があります。

- 第12.4.1項で説明するとおり、管理エージェントと通信するプロキシ・サーバーを使用するOMSの構成。

- 管理リポジトリ・アップロード・ポートの管理エージェントからHTTPおよびHTTPS通信を受信できるようにファイアウォールを構成します。
デフォルトの非セキュア・アップロード・ポートは4889です。4889が使用できない場合、4889から4897の範囲で使用可能な最初のポートが選択されます。

Enterprise Manager Framework Securityを有効にしている場合、セキュア・アップロード・ポートは1159です。1159が使用できない場合、4899から4908の範囲で使用可能な最初の空きポートが選択されます。

図12-2には、管理エージェントがファイアウォールで保護されている場合に設定する必要がある接続が示されています。

図12-2 管理サービスがファイアウォール内にある場合の構成タスク

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

この項では、ファイアウォール外の管理エージェントとの通信にプロキシ・サーバーを使用するようにOMSを構成する方法について説明します。

プロキシ・サーバーを使用するためにOMSを構成するには、次のようにします。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

注意:
エージェントのプロキシ設定ページでは、管理エージェントからOMSではなく、OMSから管理エージェントへのみの通信に使用できるプロキシ・サーバーを構成できます。構成するプロキシ・サーバーは、OMSとすべての管理エージェント間の通信に使用されます。

2. 「手動プロキシ構成」を選択します。

3. Specify values for 「プロトコル」、「プロキシ・サーバーのホスト」、「ポート」および「プロキシを使用しないドメイン」の値を指定します。指定したプロキシ・サーバーがセキュリティ・レルムまたはログイン資格証明(あるいはその両方)を使用して構成されている場合、「レルム」、「ユーザー名」および「パスワード」に値を指定します。

4. 「テストURL」セクションで、「URL」に管理エージェントのURLを指定し、「テスト」をクリックして、指定した管理エージェントとOMSが指定したプロキシ・サーバーを使用して通信できるかどうかをテストします。

5. 接続が成功した場合、「適用」をクリックしてプロキシ設定をリポジトリに保存します。

6. OMSを再起動します。複数OMSの設定を使用している場合、すべてのOMSを再起動します。
Unixベースのプラットフォームで稼働するOMSを再起動するには、次のコマンドを実行します。

<ORACLE_HOME>/bin/emctl stop oms
<ORACLE_HOME>/bin/emctl start oms

Microsoft Windowsのプラットフォームで稼働するOMSを再起動するには、次の手順を実行します。

1. 「マイ コンピュータ」を右クリックし、「管理」を選択します。

2. 「コンピュータの管理」ウィンドウの左側のペインで、「サービスとアプリケーション」を展開し、「サービス」を選択します。

3. 「OracleManagementServer_EMGC_OMS*」サービスを選択し、再起動ボタンをクリックします。

12.5 ファイアウォールで保護されたホスト上の管理エージェントの構成

管理エージェントがファイアウォールで保護されたホスト上にインストールされ、OMSがファイアウォールの反対側にある場合は、次の作業を実行する必要があります。

- 第12.5.1項で説明するとおり、OMSへのアップロードにプロキシ・サーバーを使用するように管理エージェントを構成します。

- 管理エージェント・ポートのOMSからHTTPおよびHTTPS通信を受信できるようにファイアウォールを構成します。
管理エージェント用のデフォルトのアップロード・ポートは、3872です。HTTPとHTTPSの両方に同じポートが使用されます。3872が使用できない場合、1830から1849の範囲で使用可能な最初の空きポートが選択されます。

図12-3には、管理エージェントがファイアウォールで保護されている場合に設定する必要がある接続が示されています。

図12-3 管理エージェントがファイアウォール内にある場合の構成タスク

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

ファイアウォール外のOMSとの通信にプロキシ・サーバーを使用するように、またはファイアウォール外のターゲットを管理するように管理エージェントを構成できます。次の手順を実行します。

1. 「設定」メニューから「エージェント」を選択します。

2. 「管理エージェント」表の「名前」列で、構成するエージェントをクリックします。管理エージェントのターゲット・ホームページが開きます。

3. 「エージェント」メニューから「プロパティ」を選択します。

4. プルダウン・メニューから「拡張プロパティ」を選択します。

5. REPOSITORY_PROXYHOSTおよびREPOSITORY_PROXYPORTプロパティの正しい値を指定します。

6. 「適用」をクリックします(変更はAGENT_HOME/sysman/config/emd.propertiesファイルに保存されます)。

注意:
プロキシ・パスワードは、管理エージェントを再起動する際に暗号化されます。

12.6 OMSと管理リポジトリの間のファイアウォールの構成

OMSと管理リポジトリの間のセキュアな接続はOracle Advanced Securityの機能を使用して実行されます。このため、OMSと管理リポジトリがファイアウォールで分割されている場合は、Oracle Netのファイアウォール・プロキシをOMSがリポジトリにアクセスできるように構成する必要があります。また、このファイアウォールにタイムアウトを構成した場合は、データベース側でSQLNET.EXPIRE_TIMEパラメータをDead Connection Detection (DCD)用に調整し、このパラメータ($ORACLE_HOME/network/admin/sqlnet.oraにある)をファイアウォールに構成したタイムアウトの値より小さい値に設定してください。

12.7 Enterprise Manager Cloud Controlコンソールと管理対象データベース・ターゲットの間のファイアウォールの構成

Enterprise Manager Cloud Controlコンソールを使用してデータベースを管理する場合、特定の監視および管理タスクを実行するには、Enterprise Managerコンソールからデータベースにログインする必要があります。ファイアウォールの反対側のデータベースにログインする場合は、Oracle Netのファイアウォール・プロキシ・アクセスを使用できるようにファイアウォールを構成する必要があります。

特に、管理対象データベースで管理アクティビティを実行する場合は、OMSがOracleリスナー・ポート経由でデータベースと通信するようにファイアウォールが構成されている必要があります。

リスナー・ポートは、Enterprise Managerコンソールのリスナー・ホームページを参照して取得できます。

12.8 複数OMSインスタンスのファイアウォールの構成

Enterprise Managerでは、共通の管理リポジトリと通信する複数のOMSインスタンスの使用がサポートされています。たとえば、複数のOMSを使用すると、E-Businessエンタープライズの成長に伴い集中管理機能を拡大していく場合のロード・バランシングに役立ちます。

ファイアウォールで保護された環境で複数のOMSインスタンスをデプロイするときは、次のことに注意してください。

- 各管理エージェントは、1つのOMSにデータをアップロードするように構成されています。このため、管理エージェントとそのOMSの間にファイアウォールがある場合、管理エージェントがアップロードURLを使用してOMSにデータをアップロードできるように、ファイアウォールを構成する必要があります。

関連項目:
第12.5項「ファイアウォールで保護されたホスト上の管理エージェントの構成」
第12.4項「ファイアウォールで保護されたホスト上のOMSの構成」

- また、管理エージェントの可用性のチェックのため、各OMSがエンタープライズ内のあらゆる管理エージェントに接続できるようにします。このため、デプロイする各OMSがHTTPまたはHTTPS経由でエンタープライズ内のあらゆる管理エージェントと通信できるように、ファイアウォールを構成する必要があります。
そうでない場合、特定の管理エージェントへアクセスしないOMSは、管理エージェントが実行中かどうかについて正しくない情報をレポートする可能性があります。

12.9 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)が使用されることを確認します。

12.10 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

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

Oracleビーコンにより、アプリケーションのパフォーマンス可用性およびパフォーマンス監視が提供されます。これらは、Enterprise Managerのアプリケーション・サービス・レベル管理機能の一部になります。

関連項目:
Enterprise Managerオンライン・ヘルプのアプリケーション・サービス・レベル管理に関する項

Enterprise Managerでは、業界標準のInternet Control Message Protocol (ICMP)およびユーザー・データグラム・プロトコル(UDP)を使用して、Oracleビーコンと監視対象のネットワーク・コンポーネントの間のデータ転送を行います。Webアプリケーション・コンポーネントとそのコンポーネントを監視するために使用しているビーコンが、ファイアウォールによって分割される場合があります。このようなケースでは、ICMP通信、UDP通信およびHTTP通信ができるようにファイアウォールを構成する必要があります。

12.12 ファイアウォールでのICMPエコー・リクエストの有効化

OMSは、Internet Control Message Protocol (ICMP)エコー・リクエストを使用してターゲット・ホスト・マシンのステータスを確認します。ICMPエコー・リクエストがファイアウォールによりブロックされると、ホスト・マシンが停止しているように見えます。

環境内のマシンのステータスを判別するには、ファイアウォールでICMPエコー・リクエストを有効にする必要があります。ICMPエコー・リクエストが有効になっている場合、OMSからpingコマンドを発行して、マシンのステータスを確認できます。

必ず、ファイアウォール内でICMP (0)エコー・リプライおよびICMP (8)エコー・リクエストを許可してください。

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

この項では、Oracle Enterprise Managerアプリケーションを使用する上で最適なパフォーマンスを得るための手法について説明します。また、大規模環境でのキャパシティ・プランニング、サイジング、Enterprise Managerのパフォーマンスの最大化にも役立ちます。

Oracle Enterprise Manager Cloud Controlには、1つの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の監視に対するサイジングの要件の概要

13.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およびリポジトリ層のハードウェア・リソースの最小要件と初期構成設定を決定する際に従うことのできる簡単な手順を示しています。

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

次の各項では、サイジング・ガイドラインの概要を説明します。

13.1.1.1 ハードウェア情報

この章で説明しているサイジング・ガイドラインは、次のハードウェアおよびオペレーティング・システムの組合せで仮想環境を実行し、取得したものです。

- ハードウェア: Oracle X4-2

- ハイパーバイザー: 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ユーザー・インタフェースのレスポンス時間を計る上で重要です。

13.1.1.2 サイジングの仕様

Oracle Enterprise Managerのサイジング・ガイドラインは、4つのサイズ(評価、小、中、大)に分かれています。表13-1に、各サイズの定義を示します。

表13-1 Oracle Enterprise Managerサイトのサイズ

サイズ

エージェント数

ターゲット数

同時ユーザー・セッション数

評価

< 10

< 100

<3

小

< 100

< 1000

<10

中

>= 100, < 1000

>= 1000, < 10,000

>= 10, < 25

大

>= 1000

>= 10,000

>= 25, <= 50*

大規模なユーザー負荷については、第13.1.3.1項「大規模な同時UI負荷」を参照してください。

評価の構成は本番環境には適していません。試行およびテスト環境のみに適しています。

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

Enterprise Managerの以前のリリースからEnterprise Manager 13cにアップグレードする場合、SYSMANユーザーとして次の問合せを実行し、表1で使用するための管理エージェントおよびターゲット数を取得できます。

- エージェント数: select count(*) from mgmt_targets where target_type = &rsquor;oracle_emd'

- ターゲット数: select count(*) from mgmt_targets where target_type = &rsquor;oracle_emd'

13.1.1.4 最小ハードウェア要件

表13-2に、4つの構成の最小ハードウェア要件を示します。

表13-2 Oracle Enterprise Managerの最小ハードウェア要件

サイズ

OMSマシン数*

OMS当たりのコア数

OMS当たりのメモリー(GB)

OMS当たりの記憶域(GB)

データベース・マシン数*

データベース・マシン当たりのコア数

データベース・マシン当たりのメモリー(GB)

評価

1

2

10

24

-

-

-

小

1

4

10

24

1

4

7

中

2

6

12

24

2 (Oracle RAC)

6

10

大

2

4

12

6

24

12

24

24

2 (Oracle RAC)

2 (Oracle RAC)

12

12

18

18

*OMSインスタンスおよびデータベース・インスタンスは、評価サイズを除き、同じ場所に配置できません。

表13-3 Oracle Enterprise Managerの最小記憶域要件

サイズ

MGMT_TABLESPACE (GB)

MGMT_AD4J_TS (GB)

MGMT_ECM_DEPOT_TS (GB)

TEMP

ARCHIVE LOG AREA (GB)

評価

15

3

1

3

アーカイブ・ログ・オフ

小

100

10

1

10

25

中

300

30

4

20

100

大

400

50

8

40

150

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

Enterprise Manager Cloud Controlをデプロイする際、各層間のネットワーク・パフォーマンスを第一に考慮する必要があります。Enterprise Manager Cloud Controlでは、各アプリケーション層間のネットワークの異常、障害および故障に対するトレランスが、エラー・トレランスおよびエラー・リカバリによって保証されています。特に管理エージェントは、Enterprise Manager全体のパフォーマンスに大きな影響を与えることなく、パフォーマンスや信頼性の低い、管理サービスへのネットワーク・リンクを処理できます。ネットワークの問題が原因で起こる1つの管理エージェント・データの遅延に関するかぎり、その影響はEnterprise Manager Cloud Controlのシステムワイドなレベルではほとんど気づかない程度のものです。

ただし、管理サービスと管理リポジトリの間のネットワーク待機時間については、わずかに増えるのみでその影響は大きくなります。Enterprise Manager Cloud Controlの実装では、管理サービスと管理リポジトリの間のネットワーク・リンクの品質が十分でない場合に、重大なパフォーマンス問題が発生することがわかっています。

管理サービスのホストとリポジトリのホストは、相互に近接した場所に配置します。理想的には、2つの間のラウンドトリップ・ネットワーク待機時間が1ミリ秒未満になるようにする必要があります。

13.1.2 ソフトウェア構成

次の各項では、評価、小規模、中規模、大規模の各構成について説明します。

13.1.2.1 評価の構成

評価の構成は簡易インストール・オプションを選択してインストールする必要があります。インストールは適切な値を使用して構成する必要があります。

最小OMS設定

Oracle Management Service (OMS)のヒープ・サイズを1GBに設定する必要があります。

最小リポジトリ・データベース設定

表13-4に、評価の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-4 評価の構成の最小データベース設定

パラメータ

最小値

プロセス

300

memory_target

1000MB

REDOログ・ファイルのサイズ

50MB

shared_pool_size

450MB

session_cached_cursors

remove

13.1.2.2 小規模の構成

小規模の構成は、Oracle Enterprise Managerのインストーラによって要求される最小要件に基づきます。

最小OMS設定

追加設定は不要です。

最小データベース設定

表13-5に、推奨される最小データベース設定を示します。

表13-5 小規模サイトの最小データベース設定

パラメータ

最小値

*sga_targetおよびpga_aggregate_targetのかわりに、4GBのmemory_targetを使用できます。

processes

300

pga_aggregate_target*

1024MB

sga_target*

3GB

REDOログ・ファイルのサイズ

300MB

shared_pool_size

600MB

db_securefile

PERMITTED

13.1.2.3 中規模の構成

中規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。

最小OMS設定

Oracle Management Service (OMS)のヒープ・サイズを4096MBに設定する必要があります。

最小リポジトリ・データベース設定

表13-6に、中規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-6 中規模サイトの最小データベース設定

パラメータ

最小値

*sga_targetおよびpga_aggregate_targetのかわりに、6.25GBのmemory_targetを使用できます。

processes

600

pga_aggregate_target*

1280MB

sga_target*

5GB

REDOログ・ファイルのサイズ

600MB

shared_pool_size

600MB

db_securefile

PERMITTED

13.1.2.4 大規模の構成

大規模の構成では、Oracle Enterprise Managerの即時使用可能な設定をいくつか変更します。

最小OMS設定

表13-7に、大規模の構成で推奨される最小OMS設定を示します。

表13-7 大規模サイトの最小OMS設定

OMS数

ヒープ・サイズの最小値

2

8192MB

4

4096MB

最小リポジトリ・データベース設定

表13-8に、大規模の構成で推奨される最小リポジトリ・データベース設定を示します。

表13-8 大規模サイトの最小データベース設定

パラメータ

最小値

*sga_targetおよびpga_aggregate_targetのかわりに、9.5GBのmemory_targetを使用できます。

processes

1000

pga_aggregate_target*

1536MB

sga_target*

8GB

REDOログ・ファイルのサイズ

1000MB

shared_pool_size

600MB

db_securefile

PERMITTED

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

表13-9は、管理リポジトリに必要な最小記憶域要件を示しています。

表13-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

100GB

1GB

10GB

10GB

中

600MB

300GB

4GB

30GB

20GB

大

600MB

400GB

8GBよりも大きい

50GB

40GB

13.1.3 追加の構成

Enterprise Managerのインストールでは、個々のシステム負荷が大きいと、追加のチューニング設定が必要になる場合があります。追加設定を次に示します。

13.1.3.1 大規模な同時UI負荷

OMSごとに50を超える同時ユーザーが予想される場合は、次の設定を表13-10のとおり修正する必要があります。

表13-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のサイトでは、表13-11に示した設定変更が最小限必要です(2 OMSの大規模な構成に基づく)。

表13-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

10GB

8GB (標準的な大規模設定) + (150ユーザー - 50大規模なユーザー負荷のデフォルト)* (1GB/50ユーザー)

表13-12に、追加ハードウェアの最小要件を示します。

表13-12 2 OMS構成の大規模な同時UI負荷の最小追加ハードウェアの例

層

パラメータ

値

計算

OMS

CPUコア数

32 (すべてのOMSホスト間の合計)

12コア * 2 OMS (大規模なコア数のデフォルト) + (150ユーザー - 50大規模なユーザー負荷のデフォルト) *(2コア * 2 OMS)/50ユーザー)

データベース

CPUコア数

32 (すべてのデータベース・ホスト間の合計)

12コア * 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"

リリース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値を変更することはお薦めしません。

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

ジョブ・システムに長期間バックログがある場合、またはバックログを速く処理する場合、次のパラメータにemctl set propertyコマンドを設定できます。

表13-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ノードのある大規模な構成で必要となる場合があります。

13.1.3.3 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

「デフォルト」の項と同じ。
これらはインストール後のデフォルト値であるため、推奨される設定です。

該当なし

次の2つのどちらかのコマンドを使用して、前述のプロパティのいずれかの値を設定できます。

emctl set property –name EM_JAVA_MEM_ARGS –value <complete memory parameter>

また、次のような指定もできます。

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の値を超えるアプリケーション・モジュールはアプリケーション・プールでタイムアウトします。デフォルト値は1です。

- JBO_POOL_TTL - アプリケーション・モジュール・インスタンスが存続するアプリケーション・モジュール・プールの時間を定義します。デフォルト値は-1です。

- JBO_LAZY_LOAD - コンポーネントの遅延ロードの有無を指定します。デフォルト値はTRUE。

- JBO_MAX_CURSORS - ビジネス・コンポーネントで開くことのできるカーソルの最大数です。カーソル数がこの数値に近づくと、フレームワークでは空のJDBC文がクリーンアップされます。デフォルト値は5です。

- JBO_RECYC_THRESHOLD - アプリケーション・モジュール・プールで使用されるリサイクルしきい値。デフォルト値は50です。

- JBO_MAX_POOL_SIZE - この制限を超えると、jbo.ampool.maxinactiveageの値に達していなくても、アクティブでない時間の最も長いアプリケーション・モジュールがアプリケーション・プールでタイムアウトします。デフォルト値は50です。

次の2つのどちらかのコマンドを使用して、前述のプロパティのいずれかの値を設定します。

emctl set property –name EM_JAVA_MEM_ARGS –value <complete memory parameter>

また、次のような指定もできます。

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を再起動する必要があります。

13.1.3.4 データベース設定の変更

事前構成済のリポジトリ用にデータベース・テンプレートをダウンロードしている場合、適切なSQLスクリプトを実行してデータベース・パラメータを推奨設定に調整できます。次の表に実行する必要のあるスクリプトを示します。

サイズ

スクリプト

小

<DB_HOME>/assistance/dbca/templates/set_repo_param_12.1.0.2.0_Database_SQL_for_EM13_1_0_0_0_Small_deployment.sql

中

<DB_HOME>/assistance/dbca/templates/set_repo_param_12.1.0.2.0_Database_SQL_for_EM13_1_0_0_0_Medium_deployment.sql

大

<DB_HOME>/assistance/dbca/templates/set_repo_param_12.1.0.2.0_Database_SQL_for_EM13_1_0_0_0_Large_deployment.sql

前述のスクリプトがMEMORY_TARGET/ SGA_TARGET/ PGA_AGGREGATE_TARGETを調整しないようにするために、これらのパラメータは手動で変更する必要があります。

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

拡大/縮小時に容量を正確に予測するために必要なのは、各Enterprise Manager Cloud Controlデプロイメントからの実際のメトリック傾向情報です。この情報と大まかな初期ホスト・システム・サイズの設定、チューニングとメンテナンスの繰返しの実行を組み合せることが、Enterprise Manager Cloud Controlデプロイメントの容量を予測する最も効果的な方法になります。また、デプロイメントのパフォーマンスを最適に保つことにも役立ちます。

Enterprise Manager Cloud Controlのサイジング手法の実施手順は、次のとおりです。

1. まだEnterprise Manager Cloud Controlをインストールしていない場合は、表13-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が必要となるのは、監視対象ターゲットの数を増やしてデプロイ・サイズを拡大しようとする場合のみです。ただし、これらの傾向を定期的に評価することは、デプロイに行われた他の変更を評価するうえでも役立ちます。

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

最初のプラットフォームのCloud Controlデプロイの選択については、第13.1.1項「サイジング・ガイドラインの概要」を参照してください。

13.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日間にわたるこれらの値の傾向を監視します。これにより、近い将来に起こりうる問題を発見し、将来のリソース要件の計画を立てることができます。

Enterprise Managerコンソールで監視するもう1つの重要なバイタル・サインは、メトリックやイベントのインフローを表示する、自己モニタリングの「マネージャの管理」リポジトリ・ページです。受け取るメトリックおよびイベント・データの微調整は、Enterprise Manager全体の状態とパフォーマンスを維持するために不可欠です。

次の手順では、自己モニタリング・ページのメトリックおよびイベント・データのインフロー傾向からは異常がわからないが、設定したベースラインしきい値の範囲にバイタル・サイン値が収まらない場合に何をすべきかというガイドラインを示します。また、ルーチン・ハウスキーピングを通してサイトのパフォーマンスを維持する方法についても説明します。

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

Enterprise Manager Cloud Controlサイトの動作を良好に保つために、ルーチン・ハウスキーピングが役立つことを覚えておくことが重要です。次に、ハウスキーピングのタスクとその適切な実行間隔を示します。

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

Enterprise Manager管理者は、Enterprise Managerリポジトリのセグメントの状態に関する推奨事項として、データベース内蔵のセグメント・アドバイザを監視する必要があります。セグメント・アドバイザは、どのセグメントを再構築/再編成する必要があるかを管理者に知らせ、その実行のためのコマンドを提供します。

セグメント・アドバイザと、システム状態に関連する問題の詳細は、My Oracle Supportナレッジ・ベースのノート242736.1および314112.1を参照してください。

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

Enterprise Manager Cloud Controlアプリケーションのパフォーマンスのボトルネックの代表的な原因を次に(頻度の高い順に)示します。

1. ハウスキーピングを実行していない(パフォーマンス問題の最大の原因)

2. ハードウェアまたはソフトウェアが適切に構成されていない

3. ハードウェア・リソースの枯渇

バイタル・サインが日常的に設定済しきい値の範囲外にある場合、または一定期間そのような傾向を示している場合は、2つの領域に対処する必要があります。まず、前述したすべてのハウスキーピングが最近行われていることを確認します。2番目に、Enterprise Manager Cloud Controlアプリケーションのリソース使用率に注意する必要があります。前出の表に列記したバイタル・サインは、Enterprise Manager Cloud Controlのリソース使用率およびスループットのキー・ポイントを反映しています。次の各項で、重要なバイタル・サインのいくつかを説明し、ベースライン値に基づいて設定されたしきい値を超えたバイタル・サインに対処するために使用可能なオプションを示します。

13.2.4.1 高いCPU使用率

サイトのパフォーマンスを評価するように求められ、高いCPU使用率に気づいた場合、どのリソースがどの場所で使用されているかを判断するために、いくつか手順を実行する必要があります。

1. Enterprise Managerホストのホームページの「プロセス」画面を使用して、CPUのしきい値を超えた管理サービス・ホストまたは管理リポジトリ・ホストで最も多くのCPUを消費しているプロセスを判別します。

2. Enterprise Managerが最も多くのCPUを消費していることが明確になった場合は、Enterprise Managerを使用して、最も多くのCPUを消費しているアクティビティを特定します。これは通常、管理サービスの処理のほとんどが実行される管理リポジトリ・ホスト上に存在します。管理リポジトリが過剰にリソースを使用していると考えられる場合、一般的に次の点を調べる必要があります。

1. Enterprise Managerリポジトリについて「上位の待機イベント」メトリックを確認します。

2. 管理リポジトリの「データベース・パフォーマンス」ページにリストされた「使用中のCPU」データベース・リソースをクリックして、管理リポジトリで最も多くCPUを使用しているSQLを調べます。

3. 管理リポジトリの「データベース・パフォーマンス」ページの「データベース・ロック」で、競合問題がないか確認します。

4. 管理リポジトリのデータベース上のSQL監視に、リソースを消費するSQLがないか確認します。

パフォーマンスのボトルネックの兆候として最も多いのは、高いCPU使用率です。通常は、管理リポジトリが最も多くCPUを消費しており、管理リポジトリを重点的に調べる必要があります。ハードウェア・リソースの制約が特になく、適切に構成およびメンテナンスが行われた管理リポジトリ・ホスト・システムの場合、CPU使用率の合計は平均して約40%以下になります。OMSホスト・システムのCPU使用率の合計は、平均して約20%以下である必要があります。平均値がこのように比較的低い場合は、アクティビティの急な増加にも十分に対応できます。アクティビティの急な増加を許容することで、ページ・パフォーマンスを長期間にわたって安定させることができます。Enterprise Manager Cloud Controlサイトのインタフェース・ページのレスポンスが良好(約3秒)で、大きなバックログが存在しない場合、CPUの使用率が推奨値を超えていても、大幅な上昇傾向にあると考えられる場合を除き、対処する必要はありません。

管理リポジトリのCPU使用率が高い場合、その根本的な原因を突き止めるために、前述の手順3.a、3b、3cおよび3.dを行うことをお薦めします。CPUは、常に最上位の待機イベントになります。I/Oパフォーマンスの低下を示すログ・ファイル同期待機イベントは、上位5件の待機として表示されないことが理想です。根本的な原因を突き止めるには、管理リポジトリの「パフォーマンス」ページから、処理で最も多くCPUを消費しているSQLを探します。このようにして明らかになったことをAWRレポートと関連付けます。この方法は、いくつかの実際のサイトで使用され、成功しています。

Intelベースのホスト上でEnterprise Managerを実行している場合は、Enterprise Manager Cloud Control管理サービスと管理リポジトリの両方が、デプロイ先のホスト上で有効になっているハイパースレッディング(HT)のメリットを得られます。HTはIntelプロセッサの特定の最新モデルの機能であり、一定量のCPU命令のパラレルな実行を可能にするものです。これによって、システム上で物理的に使用可能なCPUの数は倍増します。HTを使用した場合、HTが使用可能になっていない同じシステムに比べて、CPU処理能力が約1.5倍になることがテストで実証されています。これにより、大幅にシステム・パフォーマンスを向上させることができます。管理サービスと管理リポジトリはどちらも複数のプロセスを同時に実行することが多いため、HTを使用するメリットは非常に大きくなります。

13.2.4.2 ローダーのバイタル・サイン

ローダーのバイタル・サインは、すべてのEnterprise Managerエージェントからシステムに絶えず送り込まれるデータの正確な量を示します。ここで最も重要な項目は、「過去1時間に返信されたエージェント数」メトリックです。このメトリックは、各管理サービスの「すべてのメトリック」ページにあります。これは過去1時間にデータのロードを遅延するように指示されたエージェントの数です。ロードの遅延を指示されるエージェントがないことが理想ですが、ある程度の遅延ロードは正常です。この値がデプロイされたエージェント数の2パーセントを超え、増え続ける場合には、対処する必要があります。

複数OMS環境でバックオフ・リクエストがOMSに均等に分散していることを確認します。バックオフ・リクエストが特定のOMSに関連し、OMS上で均等になっていない場合、サーバー・ロード・バランサで設定されているロード・バランシング・アルゴリズムがラウンドロビンであることを確認します。1時間当たり数百件のペースで重要なチャネルに連続してバックオフがあり、データベースに十分な空き領域がある場合のみ、ローダー・スレッドを追加します。

ローダー・スレッドの数はデフォルトで常にOMSごとに20に設定されます。OMSにローダー・スレッドを追加すると、全体のホストCPU使用率が高くなります。この値は、サイトの必要性に応じて変更できます。

リポジトリに使用可能なリソースが十分にない場合、ローダー・スレッドを追加すると収穫逓減が起こります。ローダー・スレッドの追加時に、使用可能なリポジトリ・リソースがある場合には、「過去1時間に返信されたエージェント数」メトリックが減ります。改善が見られない場合には、他のチューニングまたはハウスキーピングの機会を探る必要があります。

ローダー・スレッドをさらに追加するには、次の構成パラメータを変更できます。

oracle.sysman.core.gcloader.max_recv_thread

デフォルト値は20です。これはOMSごとの設定です。

13.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と呼ばれる新機能にかわり、起動パラメータは必要なくなりました。

13.2.4.4 ロールアップ・プロセス

ロールアップの実行時間の割合が上昇傾向にある(またはベースラインを超えている)とき、バッファ・キャッシュがすでに最適に設定されているのに、多くのクラスタ待機イベントがAWRレポートで報告される場合、ロールアップ・データベース・サービスを構成し、単一インスタンスRACノードのみでロールアップ・サービスを実行するようにアフィニティを設定します。単一インスタンスRACノードが、大きなI/Oボリュームを処理できるようにサイズ設定されていることを確認します。

ロールアップ・データベース・サービスでは次の構成手順を使用します。

1. データベース・サービス「rollup」を作成し、RACインスタンスの1つをプライマリ・インスタンスとして「-r」に設定します。

- srvctl add service -d <dbname>-s rollup -r <primary instance> -a <the other instances> -y automatic

- srvctl start service -d <dbname>-s rollup
srvctl status service -d <dbname>

2. sysユーザーとしてDBMS_SCHEDULER.create_job_class (job_class_name => 'ROLLUP'、service => 'rollup')を実行します

3. GRANT EXECUTE ON sys.ROLLUP TO sysman;

4. sysmanユーザーとしてDBMS_SCHEDULER.SET_ATTRIBUTE (name => 'EM_ROLLUP_SCHED_JOB'、attribute => 'job_class'、value => 'ROLLUP')を実行します

5. sysmanユーザーとしてGC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS ('EM_ROLLUP_SCHED_JOB'、'ROLLUP')を実行します

ロールアップ・データベース・サービスを構成する他に、追加スレッドによるロードの増加をデータベースが処理できる場合は、ロールアップ・ワーカー・スレッドを追加します。自己モニタリングの「マネージャの管理」リポジトリ・ページにある「メトリック:・ロールアップ・パフォーマンス」チャートの構成オプションを使用して、追加のロールアップ・ワーカー・スレッドを構成します。

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

ジョブ、通知およびアラートは、Enterprise Manager Cloud Controlサイトの管理サービスの処理効率を示します。

ジョブ

リポジトリのスケジュール済ジョブ・ステップでバックログのサイズが増加するのは、リポジトリに十分なリソースがないことを意味します。ジョブ・ディスパッチャの処理時間(%)が高いのは、リポジトリのボトルネックを意味します。ジョブ・ディスパッチャの処理時間(%)が高くスループットが低いのは、処理のボトルネックを意味します。ジョブ・サブシステムは、ロックを使用してシーケンスを内部で管理するため、アプリケーション・ロック待機イベントおよびトランザクション・ロック待機イベントをリポジトリのAWRレポートで確認できます。ジョブ・システムが待機時間の5-8%を消費するのは正常ですが、その値が20-30%を超えるときわめて異常であり、トリアージする必要があります。AWRのジョブSQLにクラスタ待機が大量にある場合は、RACサービスを導入することでジョブ・システムを最適化できる可能性があります。ジョブのためにデータベース・サービスを作成し、最適なパフォーマンスのために2ノードRACインスタンスで実行するようにアフィニティを設定します。

次の構成手順を使用して、ロールアップ・データベース・サービスを設定します。

1. データベース・サービスemjobを作成し、RACインスタンスのうち2つをプライマリ・インスタンスとして「-r」に設定します

- srvctl add service -d <dbname>-s emjob -r <primary instances> -a <the the other instances> -y automatic

2. 次のDBMS_SCHEDULERジョブを実行します。

- sysユーザーとして、DBMS_SCHEDULER.create_job_class (job_class_name => 'EMJOB'、service => 'emjob ')を実行します

- GRANT EXECUTE ON sys.EMJOB TO sysman;

- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE (name => ' EM_JOBS_STEP_SCHED '、attribute => 'job_class'、value => 'EMJOB')を実行します

- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE (name => ' EM_JOB_PURGE_POLICIES '、attribute => 'job_class'、value => 'EMJOB')を実行します

- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_JOBS_STEP_SCHED', 'EMJOB')を実行します

- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_JOB_PURGE_POLICIES', 'EMJOB')を実行します

- INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('EM_jobs_step_sched_job_class', 'EMJOB')

3. pingサービス名の接続文字列をemctlプロパティに設定します
oracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptor

- サンプル
emctl set property -name "company.sysman.core.jobs.conn.service" -value "\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=emjob\)\)\)"

イベントおよび通知

バイタル・サインがベースラインしきい値を超えた場合は、自己モニタリングの「マネージャの管理」ページでバイタル・サインを確認します。メトリック・アラート・バックログ、メトリック収集エラー・バックログおよび通知バックログの急激な増大が続いていないかチャートで監視します。イベント・バックログをチェックする際に重要なメトリックは、「合計保留イベント」と「処理されたイベント合計(過去1時間)」です。「合計保留イベント」が多くても、「Total Events Processed (Last Hour)」で十分な進捗が見られる場合は、一時的な上昇として無視できる可能性があります。ただし、両方のメトリックが着実に増加している場合、データベース・サービスを導入して単一インスタンスRACノードのみで実行するようにアフィニティを設定するとイベント・サブシステムにメリットがあります。

イベント・データベース・サービスのために次の構成手順を使用します。

1. データベース・サービスeventを作成し、RACインスタンスの1つをプライマリ・インスタンスとして「-r」に設定します
srvctl add service -d <dbname>-s event -r <primary instance> -a <the the other instances> -y automatic

2. pingサービス名の接続文字列をemctlプロパティoracle.sysman.core.events.connectDescriptorに設定します
サンプル
emctl set property -name "oracle.sysman.core.events.connectDescriptor" -value "\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=event\)\)\)"

Pingアラート

Pingアラートのパフォーマンスは、ターゲットの可用性を判別するために重要です。バイタル・サインがベースラインしきい値を超え、AWRレポートに多数のクラスタ待機がある場合は、Pingのためにデータベース・サービスを導入し、単一インスタンスRACノードのみで実行するようにアフィニティを設定すると明らかなメリットがあります。

Pingsデータベース・サービスを定義するために次の構成手順を使用します。

1. データベース・サービスpingを作成し、RACインスタンスの1つをプライマリ・インスタンスとして「-r」に設定します
srvctl add service -d <dbname>-s ping -r <primary instance> -a <the the other instances> -y automatic

2. 次のDBMS_SCHEDULERジョブを実行します

- sysユーザーとして、DBMS_SCHEDULER.create_job_class ( job_class_name => 'PING'、service => 'ping')を実行します

- GRANT EXECUTE ON sys.PING TO sysman;

- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'EM_PING_MARK_NODE_STATUS'、attribute => 'job_class'、value => 'PING')を実行します

- sysmanユーザーとして、DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'EM_REPOS_SEV_EVAL'、attribute => 'job_class'、value => 'PING')を実行します

- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS ('EM_REPOS_SEV_EVAL'、'PING')を実行します

- sysmanユーザーとして、GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS ('EM_PING_MARK_NODE_STATUS'、'PING')を実行します

3. pingサービス名の接続文字列をemctlプロパティoracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptorに設定します
サンプル

emctl set property -name oracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptor" -value "\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=ping\)\)\)

13.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)をお薦めします。

13.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を停止した状態で、必要な文の再作成および再編成を実行できます。これにより、ページ・パフォーマンスは大幅に向上します。オープン・アラート、システム・エラーおよびメトリック・エラーの数が多すぎる場合など、再作成と再編成のみではページ・パフォーマンスが改善されないこともあります。このようなコールを改善するには、(たとえば、クリーンアップや削除を行って)これらの問題の数を減らすしかありません。これらの数を減らした後は、セグメントの再作成および再編成を実行して、パフォーマンスを最適化する必要があります。これらのシナリオは第13.2.3項で説明されています。最新状態が維持されていれば、UIページ・パフォーマンスをそれほど頻繁に分析する必要はありません。

Enterprise ManagerコンソールからSQLプロシージャのパフォーマンスを監視する場合の新機能の詳細は、Enterprise Managerの管理ガイドのEnterprise Managerの保守に関する章を参照してください。

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

中間層OMSサーバーの最適な数を決定することは、重要なタスクです。追加のOMSインスタンスの導入について、根拠のある、理にかなった、納得できる決定を下すには、様々な点を考慮する必要があります。監視対象ターゲットの数は最初に検討する項目の1つですが、決定に及ぼす影響は、通常大きくありません。

このタスクの一環として、次の点について検討し、確認する必要があります。

- 使用されるジョブの自動化とスケジューリングのボリューム

- コンソールで同時に作業する管理者の数

- エージェントとOMSサーバーとの間のネットワーク帯域幅とチャネルの堅牢性

- トリガーされる違反と通知の数

- OMSサーバーが使用するIOシステムの速度と安定性

情報に基づいた決定をするには、各カテゴリを詳細に調べることが重要です。単にOMSサーバーを追加したり、同一ホストにCPUやメモリーを増設しても、パフォーマンスの向上に変化が見られない場合があります。現在稼働しているOMSインスタンスを使用して、現在のOMSのパフォーマンスについて実際の統計を収集し、現在または今後のデプロイメントに必要なOMSサーバーの数を計算します。Enterprise Managerには、その状態を反映するバイタル・サインがあります。これらのバイタル・サインは、設定したベースラインしきい値と比較して、その傾向を一定期間監視する必要があります。

13.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使用率が増加します。

13.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の動作と一致し(かつ、既存のプロパティを再利用し)ます。

13.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表領域に格納されます。

14 OMSおよび管理エージェントの通信用プロキシの構成

Oracle Management Service (OMS)およびOracle Management Agent (管理エージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントです。管理エージェントが、環境内のターゲットを検出してモニタリングする一方、OMSは管理エージェントとの編成を行い、検出されたターゲットを管理し、収集された情報をリポジトリに格納して、今後の参照および分析に備えます。

このため、OMSと管理エージェントは、常にお互いとの通信を行っています。HTTPやHTTPSリクエストをより効率よく管理し、セキュリティの層を厚くするため、OMSと管理エージェントとの間にHTTPまたはHTTPSベースのプロキシを構成し、この通信を保護することができます。

この章では、OMSと管理エージェントの間の通信を保護するHTTPプロキシの構成方法について説明します。この章の具体的な内容は次のとおりです。

- OMSおよび管理エージェントの通信用プロキシの使用について

- OMSと管理エージェントとの通信用のプロキシの構成

- 管理エージェントのデプロイ後における管理エージェントからOMSへの通信用プロキシの構成

- 管理エージェントのデプロイ中における管理エージェントからOMSへの通信用プロキシの構成

- OMSからMy Oracle Supportへの通信用プロキシの構成

- OMSから管理エージェントへの通信用に構成されているプロキシの更新

- OMSと通信するために既存プロキシに追加の管理エージェントを関連付け

- OMSとの通信にプロキシを使用しないよう管理エージェントを除外

- プロキシ名または管理エージェント別のプロキシ・リストの表示

- OMSから管理エージェントへの通信用に構成されているプロキシのモニタリング

- OMSから管理エージェントへの通信用に構成されているプロキシの削除

- OMSおよび管理エージェントの通信用プロキシの構成のためのEM CLI動詞

14.1 OMSおよび管理エージェントの通信用プロキシの使用について

Oracle Management Service (OMS)およびOracle Management Agent (管理エージェント)は、Enterprise Manager Cloud Controlのコア・コンポーネントです。管理エージェントが、環境内のターゲットを検出してモニタリングする一方、OMSは管理エージェントとの編成を行い、検出されたターゲットを管理し、収集された情報をリポジトリに格納して、今後の参照および分析に備えます。このため、OMSと管理エージェントは、常にお互いとの通信を行っています。HTTPやHTTPSリクエストをより効率よく管理し、セキュリティの層を厚くするため、OMSと管理エージェントとの間にHTTPまたはHTTPSベースのプロキシを構成し、この通信を保護することができます。

プロキシは、Enterprise Manager Cloud Controlへのアプリケーション外部サーバーで、ネットワークの境界やファイアウォール越しにHTTPおよびHTTPSリクエストの管理を仲介します。ただし、プロキシを使用すると、2つ以上のコンポーネント間の通信で特定のポートのみを公開すればよいため、通信の安全性と信頼性が高まります。

Enterprise Manager Cloud Controlの旧リリースのオプションでは、管理エージェントと通信するためにOMSに構成できるプロキシは1つのみでした。しかし、13cリリース1以降には、次のプロキシ構成オプションがあります。

- プロキシがありません。

- すべての管理エージェントに1つのプロキシ。

- 一部の管理エージェントに対して1つのプロキシを構成し、残りにはプロキシなし。

- 同じグループの管理エージェントに複数のプロキシ(冗長プロキシ)。

- 異なるグループの管理エージェントに複数のプロキシ。

プロキシがEnterprise Manager Cloud Controlで管理可能なエンティティとしてモデル化および追加され、他のターゲット・タイプと同様に可用性が監視されます。そのため、管理者以外でも、Enterprise Manager Cloud Controlでプロキシの詳細を表示できます。ただし、プロキシ構成設定を変更できるのは、ターゲットに対するすべての権限が許可されている管理者のみです。

一方で、管理エージェントからOMSへの通信用と、OMSからMy Oracle Supportへの通信用に構成されたプロキシは、ターゲット・タイプとしてモデル化されず、Enterprise Manager Cloud Controlでモニタリングされません。また、これらに冗長プロキシを構成することはできません。

さらに、13cリリース1以降では、同じグループの管理エージェントに冗長プロキシとして複数のプロキシを構成し、OMSに構成されたプロキシの高可用性をサポートできます。この場合、OMSには、管理エージェントと通信するために複数のプロキシが構成されているため、その他のプロキシのステータスに関係なく、稼働中のプロキシが通信用に選択されます。

注意:

- NTLMベースのMicrosoftプロキシはサポートされていません。そのようなプロキシからアクセスできるようにするには、NTLMベースのMicrosoftプロキシ・サーバーの認証されていないサイト・プロパティに使用可能なすべてのエージェント・ホストを追加してください。

- 各OMSのローカル・アドレスは、プロキシを自動的にバイパスします。

14.2 OMSから管理エージェントへの通信用プロキシの構成

プロキシを構成することで、Oracle Management Service (OMS)とOracle Management Agent (管理エージェント)間の通信を保護できます。プロキシは、Enterprise Manager Cloud Controlへのアプリケーション外部サーバーで、ネットワークの境界やファイアウォール越しにHTTPおよびHTTPSリクエストの管理を仲介します。プロキシを使用すると、通信で特定のポートのみを公開すればよいため、OMSと管理エージェントの間の通信が、より安全で信頼性の高いものになります。

すべての管理エージェントに1つのプロキシを構成することも、管理エージェントのセットにプロキシを1つ構成して残りはなしにすることも可能ですし、異なる管理エージェントのセットに別々のプロキシを構成することもできます。

また、2つ以上のプロキシを冗長プロキシとして構成し、OMSと管理エージェントの通信に構成されたプロキシの高可用性をサポートすることも可能です。そのような状況の場合は、デフォルトで、その他のプロキシのステータスに関係なく、稼働中のプロキシが通信用に選択されます。通信を開始する前に、プロキシが非アクティブであるか停止していることがわかった場合は、その管理エージェントに構成されている別のプロキシが選択されます。ただし、特定のプロキシで通信を開始した後に、そのプロキシが非アクティブになったり停止したりした場合は、稼働中の別のプロキシを選択するフォールバック・メカニズムは、現在存在しないことに注意してください。

注意:

- NTLMベースのMicrosoftプロキシはサポートされていません。そのようなプロキシからアクセスできるようにするには、NTLMベースのMicrosoftプロキシ・サーバーの認証されていないサイト・プロパティに使用可能なすべてのエージェント・ホストを追加してください。

- 各OMSのローカル・アドレスは、プロキシを自動的にバイパスします。

OMSおよび管理エージェントの通信用にプロキシを構成するには、次の手順に従います。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

2. プロキシ・ページで、「作成」をクリックします。

3. プロキシの作成ページで、次を実行します。

1. 「名前」フィールドに、構成しているプロキシの一意の名前を入力します。これは、プロキシがEnterprise Manager Cloud Controlで、ターゲット・タイプとしてモデル化され、モニタリングされる名前です。たとえば、oms-agent_proxy1です。

2. 「ホスト」フィールドに、プロキシを配置するホストの名前を入力します。たとえば、www-proxy.example.comです。

3. 「ポート」フィールドに、プロキシが使用するポートを入力します。

4. 「プロトコル」オプションで適切なプロトコル(「HTTP」またはHTTPS)を選択します。

5. 指定したプロキシにOMSが正常に接続できるかどうかを検証するには、「プロキシのテスト」をクリックします。

4. レルムまたはログイン資格証明(あるいはその両方)を使用して、構成中のプロキシを設定している場合は、「名前付き資格証明の関連付け」を選択し、「名前付き資格証明」セクションで、使用する登録済の名前付き資格証明を選択します。

注意:
選択できる名前付き資格証明がない場合は、新しく作成します。これには、「設定」メニューから「セキュリティ」、「名前付き資格証明」の順に選択します。名前付き資格証明ページで、「作成」をクリックします。「資格証明の作成」ページの「一般プロパティ」セクションに、資格証明の一意の名前を入力し、「認証ターゲット・タイプ」を「ホスト」に、「資格証明のタイプ」を「ホスト資格証明」に、「有効範囲」を「グローバル」に設定します。「資格証明プロパティ」セクションに、ユーザー名とパスワードを入力します。「保存」をクリックします。

5. 関連付けられているエージェント・セクションで、構成しているプロキシを使用して、OMSと通信する管理エージェントを選択します。次のいずれかの方法で管理エージェントを選択してください。選択後に、その管理エージェントがプロキシと正常に通信できるかどうかを検証する場合は、「テスト」をクリックします。

- 「エージェントの選択」をクリックし、「ターゲットの選択」ダイアログで、管理エージェントを1つ以上選択します。
このオプションは、選択する管理エージェントのリストが少なく、名前がそれぞれ一意の場合に特に便利です。たとえば、agent1.example.com, agent2.example.com, agent3.example.comです。

- エージェント・パターン・フィールドに、管理エージェントのエージェント・パターンを入力します。個々のパターンを区切る場合は、カンマ(,)を使用します。0文字以上を表す場合はアスタリスク(*)を、1文字を表す場合は疑問符(?)を使用します。
このオプションは、選択する管理エージェントのリストが少なく、それぞれの一意の名前に共通の接頭辞が付いている場合に特に便利です。たとえば、オーストラリアで実行されている管理エージェントのうち、aus_agent1.example、aus_agent2.example、aus_agent3.example.comのように、接頭辞aus_agentで開始されるものすべてを選択する場合です。その場合には、aus_agent*と入力します。

注意:
パターンの中で、バックスラッシュ(\)文字をアスタリスク(*)、疑問符(?)、カンマ(,)またはバックスラッシュ(\)自体の前に付けると、次の文字に関連付けられている特別な意味がなくなります。たとえば、パターンabc*は、接頭辞が文字列abcの任意の文字列に一致しますが、パターンabc*は、abc*という文字列にのみ一致します。

- 「除外エージェント・パターン」フィールドに、構成しているプロキシとの関連付けから除外する管理エージェントのエージェント・パターンを入力すると、その他すべての管理エージェントが対象になります。個々のパターンを区切る場合は、カンマ(,)を使用します。0文字以上を表す場合はアスタリスク(*)を、1文字を表す場合は疑問符(?)を使用します。
このオプションは、除外する管理エージェントのリストが多く、それぞれに完全に一意の名前が付いているか、一意の名前に共通の接頭辞が付いている場合に特に便利です。たとえば、香港で実行されている管理エージェントのうち、hkg_agent1.example.com、hkg_agent2.example.com、hkg_agent3.example.comのように、接頭辞hkg_agentで開始されるものすべてを除外する場合です。

注意:
除外されたエージェント・パターンにより、名前で選択された管理エージェントのリストにある管理エージェントが除外されることはありません。除外されるのは、エージェント・パターン・フィールドに入力したエージェント・パターンから導出された管理エージェントのみです。

6. 「発行」をクリックします。

14.3 管理エージェントのデプロイ後における管理エージェントからOMSへの通信用プロキシの構成

プロキシを構成することで、管理エージェントとOMS間の通信を保護できます。プロキシは、Enterprise Manager Cloud Controlへのアプリケーション外部サーバーで、ネットワークの境界やファイアウォール越しにHTTPおよびHTTPSリクエストの管理を仲介します。プロキシを使用すると、通信で特定のポートのみを公開すればよいため、管理エージェントとOMSの間の通信が、より安全で信頼性の高いものになります。

管理エージェントのデプロイ後、Enterprise Manager Cloud Controlコンソールまたはコマンドライン・インタフェース(EMCTLコマンド)を使用して、管理エージェントとOMSの間にプロキシを構成できます。

管理エージェントのデプロイ後に、Enterprise Manager Cloud Controlコンソールを使用して、管理エージェントとOMSの間にプロキシを構成するには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. 「すべてのターゲット」ページの「検索の絞込み」ペインにあるヘッダーの「ターゲット・タイプ」で、下へスクロールして、サブヘッダーの「内部」を展開します。次に、「エージェント」をクリックします。

3. 管理エージェントのリストで、プロキシを構成する管理エージェントをクリックします。

4. エージェントのホームページの「エージェント」メニューから、「プロパティ」を選択します。

5. 「プロパティ」ページの「表示」ドロップダウン・リストで、「拡張プロパティ」を選択します。

6. 「ランタイム設定」を展開します。

7. 次のプロパティを設定します。
REPOSITORY_PROXYHOST

REPOSITORY_PROXYPORT

REPOSITORY_PROXYPWD

REPOSITORY_PROXYREALM

REPOSITORY_PROXYUSER

8. 「適用」をクリックします。

管理エージェントのデプロイ後に、コマンドライン・インタフェース(EMCTL)を使用して、管理エージェントとOMSの間にプロキシを構成するには、次の手順に従います。

1. <AGENT_HOME>/sysman/config/emd.propertiesファイルでプロキシ・プロパティを設定します。これを実行するには、管理エージェント・ホームから、次のEMCTLコマンドを実行します。
emctl setproperty agent -name REPOSITORY_PROXYHOST -value <proxy_host>

emctl setproperty agent -name REPOSITORY_PROXYPORT -value <proxy_port>

emctl setproperty agent -name REPOSITORY_PROXYREALM –value <proxy_realm>

emctl setproperty agent -name REPOSITORY_PROXYUSER –value <proxy_user>

emctl setproperty agent -name REPOSITORY_PROXYPWD –value <proxy_password>

次に例を示します。

emctl setproperty agent -name REPOSITORY_PROXYHOST -value www-proxy.example.com
emctl setproperty agent -name REPOSITORY_PROXYPORT -value 80
emctl setproperty agent -name REPOSITORY_PROXYREALM –value realm1
emctl setproperty agent -name REPOSITORY_PROXYUSER –value u01
emctl setproperty agent -name REPOSITORY_PROXYPWD –value password

2. 管理エージェントを再起動します。

14.4 管理エージェントのデプロイ中における管理エージェントからOMSへの通信用プロキシの構成

プロキシを構成することで、管理エージェントとOMS間の通信を保護できます。プロキシは、Enterprise Manager Cloud Controlへのアプリケーション外部サーバーで、ネットワークの境界やファイアウォール越しにHTTPおよびHTTPSリクエストの管理を仲介します。プロキシを使用すると、通信で特定のポートのみを公開すればよいため、管理エージェントとOMSの間の通信が、より安全で信頼性の高いものになります。

管理エージェントのデプロイ中に、管理エージェントとOMSの間にプロキシ・サーバーを構成するには、「新しいOracle Management Agentのインストール」または「エージェント・ゴールド・イメージを使用した管理エージェントのプロビジョニング」に説明されている手順に従って管理エージェントをデプロイします。管理エージェントのデプロイメントに関する詳細を入力する際、ターゲットの追加ウィザードのインストールの詳細・ページで、「オプションの詳細」セクションを展開し、「追加パラメータ」フィールドに、適切なプロキシ設定で次のパラメータを入力します。パラメータは、カンマ(,)で区切ります。

REPORSITORY_PROXYHOST=<proxy_host_name>, REPORSITORY_PROXYPORT=<proxy_host_port>

次に例を示します。

REPORSITORY_PROXYHOST=www-proxy.example.com, REPORSITORY_PROXYPORT=1523

14.5 OMSからMy Oracle Supportへの通信用プロキシの構成

Oracle Management Service (OMS)では、ホストのインターネット接続を使用してMy Oracle Supportに定期的に接続し、パッチやパッチ・セット、パッチ推奨および自動リリース更新(ARU)シード・データをダウンロードしています。この通信を保護するには、OMSとMy Oracle Supportの間にプロキシを追加します。

OMSおよびMy Oracle Supportの間にプロキシを構成するには、次の手順に従います。

1. 「設定」メニューから、「プロキシ設定」を選択してから、「My Oracle Support」を選択します。

2. 「My Oracle Supportのプロキシ設定」ページの「手動プロキシ構成」を選択します。

3. 「HTTPS」フィールドに、プロキシを配置するホストの名前を入力します。たとえば、www-proxy.example.comです。

4. 「ポート」フィールドに、プロキシが使用するポートを入力します。

5. セキュリティ・レルムまたはログイン資格証明(あるいはその両方)を使用して、指定されたプロキシを構成している場合は、「パスワード/拡張設定」を選択し、レルムと資格証明を入力します。

6. 指定したプロキシの詳細を使用して、OMSがMy Oracle Supportに正常に接続できるかどうかを検証するには、「テスト」をクリックします。

7. 接続が正常な場合は、「適用」をクリックします。

注意:

- 構成するプロキシは、マルチOMS環境のすべてのOMSインスタンスに適用されます。

- 設定でプロキシを使用している場合は、aru-akam.oracle.com、ccr.oracle.com、login.oracle.com、support.oracle.comおよびupdates.oracle.comに接続できることを確認します。
NTLMまたはNT LAN ManagerベースのMicrosoftプロキシはサポートされていません。NTLMベースのMicrosoftプロキシを使用して前述のサイトにアクセスできるようにしている場合は、プロキシの認証されていないサイト・プロパティに前述のURLを追加してください。

14.6 OMSから管理エージェントへの通信用に構成されているプロキシの更新

Oracle Management Service (OMS)とOracle Management Agent (管理エージェント)間の通信を保護するために構成したプロキシを変更できます。プロキシ・ポートやプロトコル、資格証明またはより一般的な要件を変更する必要がある場合、またはプロキシに関連付けられている管理エージェントの更なる追加や、一部の削除が必要な場合もあります。

注意:
Enterprise Manager Cloud Controlでモニタリングされているプロキシのプロキシ名を変更することや、プロキシ名に別のプロキシをマップすることはできません。

OMSおよび管理エージェントの通信用に構成されているプロキシの更新や変更を実行するには、次の手順に従います。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

2. プロキシ・ページで、更新するプロキシ(表の行)を選択し、「変更」をクリックします。

3. 「プロキシの変更」ページで、ポート、プロトコル、名前付き資格証明またはプロキシに関連付けられている管理エージェントを編集します。
ポート、プロトコルおよびプロキシ資格証明を更新する手順は、第14.2項を参照してください。

追加の管理エージェントを既存のプロキシに関連付ける手順は、第14.7項を参照してください。既存のプロキシの使用から管理エージェントを除外する手順は、第14.8項を参照してください。

14.7 OMSと通信するために既存プロキシに追加の管理エージェントを関連付け

プロキシを構成し、そのプロキシを介してのみOMSと通信するよう管理エージェントのセットを関連付けることで、Oracle Management Service (OMS)とOracle Management Agent (管理エージェント)間の通信を保護できます。特定の状況では、プロキシの構成後に、そのプロキシを使用して通信するよう追加の管理エージェントを含める変更が必要になる場合があります。

追加の管理エージェントを既存のプロキシに関連付けるには、次の手順に従います。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

2. プロキシ・ページで、管理エージェントを除外するよう変更するプロキシ(表の行)を選択し、「変更」をクリックします。

3. プロキシの変更ページで、次のいずれかを実行します。

- 関連付けられているエージェント・セクションで、「エージェントの選択」をクリックし、「ターゲットの選択」ダイアログで、管理エージェントを1つ以上選択します。
このオプションは、選択する管理エージェントのリストが少なく、名前がそれぞれ一意の場合に特に便利です。たとえば、agent1.example.com, agent2.example.com, agent3.example.comです。

- 関連付けられているエージェント・セクションのエージェント・パターン・フィールドに、管理エージェントのエージェント・パターンを入力します。個々のパターンを区切る場合は、カンマ(,)を使用します。0文字以上を表す場合はアスタリスク(*)を、1文字を表す場合は疑問符(?)を使用します。
このオプションは、選択する管理エージェントのリストが少なく、それぞれの一意の名前に共通の接頭辞が付いている場合に特に便利です。たとえば、オーストラリアで実行されている管理エージェントのうち、aus_agent1.example、aus_agent2.example、aus_agent3.example.comのように、接頭辞aus_agentで開始されるものすべてを選択する場合です。その場合には、aus_agent*と入力します。

注意:
パターンの中で、バックスラッシュ(\)文字をアスタリスク(*)、疑問符(?)、カンマ(,)またはバックスラッシュ(\)自体の前に付けると、次の文字に関連付けられている特別な意味がなくなります。たとえば、パターンabc*は、接頭辞が文字列abcの任意の文字列に一致しますが、パターンabc*は、abc*という文字列にのみ一致します。

「エージェント・パターン」フィールドと、「除外エージェント・パターン」フィールドを一緒に使用して、リストに追加の管理エージェントを加えることも可能です。たとえばオーストラリアに、接頭辞aus_agent,で始まる管理エージェントが100あり、aus_agent98.example、aus_agent99.example.comおよびaus_agent100.example.comを除外する場合は、「エージェント・パターン」フィールドにaus_agent*と入力し、「除外エージェント・パターン」フィールドにaus_agent98.example、aus_agent99.example.comおよびaus_agent100.example.comを入力します。

14.8 OMSとの通信にプロキシを使用しないよう管理エージェントを除外

プロキシを構成し、そのプロキシを介してのみOMSと通信するよう管理エージェントのセットを関連付けることで、Oracle Management Service (OMS)とOracle Management Agent (管理エージェント)間の通信を保護できます。ただし、特定の状況では、プロキシの構成後に、そのプロキシを使用しないよう一部の管理エージェントを除外し、残りの管理エージェントのみがそのプロキシを使用するよう変更が必要になる場合があります。

OMSとの通信に、あるプロキシを使用しないよう管理エージェントを除外するには、次の手順に従います。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

2. プロキシ・ページで、管理エージェントを除外するよう変更するプロキシ(表の行)を選択し、「変更」をクリックします。

3. プロキシの変更ページで、次のいずれかを実行します。

- 「関連エージェント」セクションで、除外する管理エージェントを選択し、「エージェントの削除」をクリックします。

- 関連付けられているエージェント・セクションの除外されたエージェント・パターン・フィールドに、除外する管理エージェントのエージェント・パターンを入力します。個々のパターンを区切る場合は、カンマ(,)を使用します。0文字以上を表す場合はアスタリスク(*)を、1文字を表す場合は疑問符(?)を使用します。
このオプションは、除外する管理エージェントのリストが多く、それぞれに完全に一意の名前が付いているか、一意の名前に共通の接頭辞が付いている場合に特に便利です。たとえば、香港で実行されている管理エージェントのうち、hkg_agent1.example.com、hkg_agent2.example.com、hkg_agent3.example.comのように、接頭辞hkg_agentで開始されるものすべてを除外するには、「除外エージェント・パターン」フィールドにhkg_agent*と入力します。

注意:
除外されたエージェント・パターンにより、名前で選択された管理エージェントのリストにある管理エージェントが除外されることはありません。除外されるのは、エージェント・パターン・フィールドに入力したエージェント・パターンから導出された管理エージェントのみです。

14.9 プロキシ名または管理エージェント別のプロキシ・リストの表示

OMSおよび管理エージェントの通信用に構成されているプロキシのリストを表示するには、「設定」メニューから、「プロキシ設定」、「エージェント」の順に選択します。

デフォルトで、プロキシはプロキシ名でソートされます。

- 特定のプロキシを検索するには、プロキシの検索セクションにプロキシ名を入力し、検索アイコンをクリックします。プロキシ名をすべて入力しても、プロキシ名の数文字を入力しても、パーセント(%)ワイルドカード文字を使用してもかまいません。表が自動的にフィルタされ、検索したプロキシがリストされます。

- ドリルダウンして、プロキシの詳細を表示するには、「プロキシ名」列でプロキシ名をクリックします。

- プロキシに関連付けられている管理エージェントのリストを表示するには、表のプロキシ名の行を選択し、「関連エージェント」表で詳細を表示します。

- さらにドリルダウンして、特定のプロキシに関連付けられている管理エージェントの詳細を表示するには、「関連エージェント」セクションの「エージェント名」列で、管理エージェント名をクリックします。

管理エージェント名でプロキシをソートするには、「表示方法」オプションから「エージェント」を選択します。

- ドリルダウンして、管理エージェントの詳細を表示するには、「エージェント名」列で管理エージェント名をクリックします。

- ドリルダウンして、プロキシの詳細を表示するには、「関連プロキシ・ターゲット」列でプロキシ名をクリックします。

14.10 OMSから管理エージェントへの通信用に構成されているプロキシのモニタリング

OMSから管理エージェントの通信用に構成されているすべてのプロキシが、Enterprise Manager Cloud Controlでターゲットとしてモデル化されます。プロキシをモニタリングするには、プロキシ・ページまたはすべてのターゲット・ページから、そのプロキシのホーム・ページにアクセスする必要があります。

プロキシ・ページから特定のプロキシのホーム・ページにアクセスするには、次の手順に従います。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

2. プロキシ・ページの「プロキシ名」列で、プロキシ名をクリックします。

すべてのターゲット・ページから特定のプロキシのホーム・ページにアクセスするには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. 「すべてのターゲット」ページの「検索の絞込み」ペインで、「その他」を展開し、「プロキシ」をクリックします。結果の表に、構成されているすべてのプロキシがリストされます。ホーム・ページにアクセスするには、プロキシ名をクリックします。

3. 詳細は、プロキシのホーム・ページで「ヘルプ」をクリックしてください。

14.11 OMSから管理エージェントへの通信用に構成されているプロキシの削除

OMSおよび管理エージェントの通信用に構成されているプロキシを削除するには、次の手順に従います。

1. 「設定」メニューから、「プロキシ設定」を選択し、「エージェント」を選択します。

2. 「プロキシ」ページの「プロキシ名」列で、削除するプロキシを選択し、「削除」をクリックします。

14.12 OMSおよび管理エージェントの通信用プロキシの構成のためのEM CLI動詞

表14-1に、OMSおよび管理エージェントの通信用プロキシの構成のためのEM CLI動詞を示します。これらの動詞の詳細は、Oracle Enterprise Manager Cloud Controlコマンドライン・インタフェース・ガイドを参照してください。

表14-1 OMSおよび管理エージェントの通信用プロキシの構成のためのEM CLI動詞

EM CLI動詞

説明

add_proxy

OMSから管理エージェントへのHTTPまたはHTTPSトラフィックを仲介するプロキシを追加します。このプロキシは、Enterprise Manager Cloud Controlではoracle_em_proxyターゲット・タイプとしてモデル化されます。

delete_proxy

OMSと管理エージェントの通信用に構成されているHTTPまたはHTTPSプロキシを削除します。

list_proxies

OMSと管理エージェントの通信用に構成されているすべてのHTTPおよびHTTPSプロキシをリスト表示します。デフォルトでは、この出力は表形式で、プロキシ名、プロトコル、ホスト名(ポート)およびステータスが表示されます。

modify_proxy

OMSと管理エージェントの通信用に構成されているHTTPまたはHTTPSプロキシを変更します。

show_proxy

OMSと管理エージェントの通信用に構成されているHTTPまたはHTTPSプロキシの詳細を表示します。

test_proxy

OMSと管理エージェントの通信用に構成されているHTTPまたはHTTPSプロキシにアクセスできるかどうかをテストします。

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

この章では、Enterprise Manager Cloud Control環境でJVM診断(JVMD)エージェントを手動でインストールする方法について説明します。

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

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

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

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

- 拡張インストール・オプションを使用したJVMDエージェントのデプロイ

- JVMDエージェントのインストール後

15.1 JVMDアーキテクチャの概要

JVM診断は、Oracle Enterprise Manager Cloud Controlに統合されています。これにより、管理者は本番環境でのJavaアプリケーションのパフォーマンスの問題を診断できます。問題を再現する必要性がなくなることにより、こうした問題解決に必要な時間が短縮されるため、アプリケーションの可用性とパフォーマンスが向上されます。JVMDを使用すると、管理者は、パフォーマンスの問題をテスト環境または開発環境で再現することなく、本番環境で問題の根本原因を特定できます。

次の図に、JVMDのアーキテクチャを示します。

図15-1 JVMDアーキテクチャ

JVMDエンジンは、JVMD監視システムのコア分析エンジンです。リリース13cでは即時使用可能な状態に構成されています。JVMDエンジンは、OMSからの要求に応じてJVMDエージェントからランタイム・データを収集し、そのデータをリポジトリに保存します。複数のJVMDエンジンを構成できます。

注意:
Cloud Controlアプリケーションを再起動せずにJVMDエンジン(OMSホストにデプロイされた)を再起動するには、WebLogic管理コンソールを使用します。

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)または非セキュアのどちらかになります。

15.2 JVMDエージェントのインストールを開始する前に

JVMDエージェントをインストールする前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の概要説明を確認してください。

15.3 JVMDエージェントをインストールするための前提条件

JVMDエージェントをインストールする前に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている前提条件を満たしていることを確認してください。

15.4 拡張インストール・オプションを使用したJVMDエージェントのデプロイ

この項では、JVMDエージェントを手動でデプロイする方法について説明します。

注意:
いったんエージェントを削除した後で再びデプロイする場合は、デプロイする前にJVMを再起動する必要があります。

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

- jamagent.warのダウンロードとデプロイによる手動でのJVMDエージェントのデプロイ

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

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

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

15.4.1 jamagent.warのダウンロードとデプロイによる手動でのJVMDエージェントのデプロイ

JVMDエージェントを手動でデプロイするには、次の手順を実行します。

1. jamagent.warをダウンロードします。
Cloud Controlを使用してjamagent.warをダウンロードするには、次の手順に従います。

1. Cloud Controlで、「設定」メニューから、「ミドルウェア管理」、「設定」の順に選択します。

2. 「設定」ページで「JVMDエージェントのダウンロード」をクリックします。「JVM診断コンポーネントのダウンロード」ダイアログ・ボックスが表示されます。

3. 「JVMDコンポーネント」メニューから、jamagent.warをダウンロードするために「JVMDエージェント」を選択し、「OK」をクリックします。「JVM診断エージェントWeb xmlパラメータ」ダイアログ・ボックスが表示されます。

4. 「使用可能なエンジン」メニューで、リストからオプションを選択します。
セキュアではない接続を使用して、JVMDエージェントがJVMDエンジンに接続するようにするには、HTTP URLを選択します。

セキュアな接続を使用して、JVMDエージェントがJVMDエンジンに接続するようにするには、HTTPS URLを選択します。

ロード・バランサまたはファイアウォールを介して、JVMDエージェントがJVMDエンジンに接続するようにするには、「カスタム」を選択します。JVMDエージェントを接続する必要のあるホスト名およびポートを指定します。

次に例を示します。

HTTP: http://sl1.us.example.com:3800

HTTPS: https://sl1.us.example.com:3801 (セキュアな通信)

5. 「ダウンロード」をクリックしてjamagent.warをダウンロードします。

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

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

deploy_jvmdagent.plスクリプトを使用して、JVMDエージェントを手動でデプロイできます。このスクリプトはサイレント・モードでのみ実行できます。つまり、プロパティ・ファイルを使用してすべての入力の詳細を指定する必要があります。

deploy_jvmdagent.plを使用してJVMDエージェントを手動でデプロイするには、次の手順を実行します。

1. 最新バージョンのjamagent.warがダウンロードされていることを確認します。
jamagent.warのダウンロード方法の詳細は、第15.4.1項の手順1を参照してください。

2. OMSホスト上の次の場所に移動します。
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_13.1.1.0.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をご覧ください。

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

セットアップに複数のJVMDエンジンがあり、それらに対してロード・バランサを構成している場合、JVMDエージェントを個々のJVMDエンジンのいずれかではなくロード・バランサに接続するようにしてデプロイできます。こうすることでJVMDエージェントの可用性を高め、フェイルオーバー・メカニズムが作成されます。つまり、特定のJVMDエンジンがダウンしても、JVMDエージェントはアクティブを保持できます。

「設定」ページを使用するか手動で高可用性を実現するJVMDエージェントをデプロイできます。

「設定」ページを使用した高可用性を実現するJVMDエージェントのデプロイ

「設定」ページを使用して高可用性を実現するJVMDエージェントをデプロイするには、次の手順を実行します。

1. 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載の手順に従って、JVMDエージェントをデプロイします。

注意:
デフォルトでは、JVMDエージェントはHTTPを使用してロード・バランサに接続します。HTTPSを使用してJVMDエージェントをロード・バランサに接続するには、第15.4.1項の手順2で説明するとおり、JVMDエージェントを手動でデプロイする必要があります。

2. JVMDエージェント構成ページの「使用可能なJVMDエンジン」で、「その他」を選択します。ロード・バランサのホスト名とポートを指定します。
「次へ」をクリックします。

3. 確認ページですべての情報を確認し、「デプロイ」をクリックします。

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

高可用性を実現するJVMDエージェントを手動でデプロイするには、次の手順を実行します。

1. 第15.4.1項の手順1に記載の手順に従って、jamagent.warをダウンロードします。

2. 「JVM診断エージェントWeb xmlパラメータ」ダイアログ・ボックスが表示された場合、「使用可能なエンジン」メニューから「カスタム」を選択します。ロード・バランサのホスト名とポートを指定します。
「ダウンロード」をクリックします。

3. 第15.4.1項の手順2で説明したとおりJVMDエージェントをデプロイします。

注意:
デフォルトでは、JVMDエージェントはHTTPを使用してロード・バランサに接続します。HTTPSを使用してJVMDエージェントをロード・バランサに接続するには、第15.4.4項で説明するとおり、証明書を使用する必要があります。使用する証明書の共通名は、ロード・バランサのホスト名と一致するようにしてください。

15.4.4 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

15.5 JVMDエージェントのインストール後

JVMDエージェントをインストールした後、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の概要説明の手順を実行します。

16 Enterprise ManagerでのBI Publisherの構成

Oracle Business Intelligence (BI) Publisherは、高度にフォーマットされたあらゆるドキュメントを作成、管理および配布するためのオラクル社の主要レポート・ツールです。BI Publisherは、Enterprise Manager Cloud Control 13cに標準で付属しています。

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

- 概要

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

- BI Publisherを含むEnterprise Managerの使用

- BI Publisherへのアクセス経路

- 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の接続資格証明

- BISystemUser資格証明のリセット

- BI Publisherサーバーおよび他のEnterprise Managerコンポーネントの管理

- BI Publisherの使用

- Enterprise Manager 13cリリース1とともにインストールされなかったBI Publisherの削除

16.1 概要

Enterprise Manager 13cリリース1 (13.1.0.0.0)以降、BI PublisherがEnterprise Managerとともにインストールされ自動的に構成されるようになりました。BI Publisherは、Enterprise Managerの基本フレームワーク・コンポーネントであるため、削除あるいは構成解除を行うことはできません。

重要:
どのような状況においてもBI Enterprise Edition (BIEE)のソフトウェアのみのインストールを実行する必要はありません。

注意:
BI Publisherを構成するためにconfigureBIPスクリプトを実行する必要もなくなりました。BI Publisherは、Enterprise Managerのインストール、アップグレードおよびリカバリのシナリオすべてで自動的に構成されます。

注意:
ごく一部の特殊なケースを除き、configureBIPスクリプトの手動実行はサポートされません。

16.1.1 BI Publisherの機能

BI Publisherの主要な機能は次のとおりです。

- ページ区切りおよびヘッダー/フッターを使用した、高度にフォーマットされた業務用レポート。

- PDF、Excel、PowerPoint、WordおよびHTMLの各レポート形式。

- Enterprise Managerリポジトリに対する独自のカスタム・レポートの開発(読取り専用のリポジトリ・アクセス)。

- Enterprise Managerセキュリティとの統合。

- Enterprise Managerの各管理者に対する異なるレベルのBI Publisher機能の付与。

- 電子メールやFTPなど、BI Publisherのスケジュール機能の使用および配信メカニズムの使用。

従来の情報パブリッシャ・レポート

情報パブリッシャ(IP)レポート作成フレームワークは、Enterprise Manager 13c Cloud Controlで引き続きサポートされますが、Enterprise Manager 12cリリース1 (12.1.0.1)では非推奨になりました。今後はIPフレームワークを使用したレポート開発は行われません。

また、カスタムIPレポート開発は将来のEnterprise Managerリリースでは非推奨になる予定です。Enterprise Manager 13cリリース1ではIPレポート開発は全面的にサポートされていますが、すべてのカスタムEnterprise Managerレポート開発にはBI Publisherを使用することをお薦めします。

現在、既存のIPレポートを実行する機能が非推奨になる予定はありません。

16.1.2 制限事項

レポートとデータ・ソースを使用する場合は、次の制限事項が適用されます。

- 即時使用可能なレポートは直接編集できません。

- 即時使用可能なレポートをコピーする場合、そのコピーが将来の製品リリースでも使用できる保証はありません。

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

Enterprise Managerの詳細やBI Publisherの自動構成に関する詳細は、Oracle Enterprise Manager基本インストレーション・ガイドおよびOracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイドを参照してください。

BI Publisherおよび「共有場所の詳細」ページの詳細は、Enterprise Managerインストレーションおよびアップグレード・ガイドを参照してください。

この例では、BI Publisherの共有記憶域は2つのボリューム/BIP_STORAGE/configおよび/BIP_STORAGE/clusterに自動的に構成されます。これら2つのボリュームはEnterprise Managerと同じシステムに配置できます。ただし、現在複数OMSを含む高可用性環境でEnterprise Managerを実行している場合、あるいは将来的にそうする計画がある場合は、これらの記憶域ボリュームを図16-1に示すようにリモート共有記憶域デバイスに配置する必要があります。この共有記憶域デバイスには、高可用性インストールを構成するすべてのEnterprise Managerシステムからアクセスできることが必要です。

図16-1 共有記憶域

BI Publisherレポート定義のすべておよび特定のBI Publisher構成アイテムは、「構成ボリューム」に格納されます。したがって、適切で定期的なバックアップ戦略を定めることが重要です。これらのバックアップの間隔はBI Publisherの使用方法によって変わります。

また、BI Publisherは、インストール手順の最後およびemctl start omsの実行のたびに起動するように自動的に「有効化」されます。

16.3 BI Publisherを含むEnterprise Managerの使用

新規の構成モードとアップグレード構成モードのいずれでも検証を実行できます。

1. スーパー管理者としてEnterprise Managerにログインします。

2. 「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。

3. BI Publisherは自動的に構成されるため、次の図のように、Enterprise Manager提供のすべてのBI Publisherレポートを表示したツリー・リストがこのページに表示されます。

この図は、プラグインがすべてインストールされた後のレポート・リストを示しています。レポート・リストは、インストールされたプラグインの数によってサイズが異なります。

4. 「BI Publisher」ページの一番上のリンクをクリックします。

5. Enterprise Manager資格証明を使用してBI Publisherにログインします。

16.4 BI Publisherへのアクセス経路

BI Publisherとの通信に使用される様々な経路があります。現在構成されている特定の経路を表示するには、emctl status oms -detailsコマンドを使用します。

注意:
企業ファイアウォールを効果的に使用すると、OMSまたはBI Publisherへのアクセスに使用される様々なTCP/IPポートを制限できます。

1. BI Publisherレポートのリスト(前項の図)からBI Publisherにアクセスします。これはBI Publisherにアクセスする最も簡単な方法です。以下に示す経路をよく理解したり構成したりする必要はありません。これは「直接チャネル」です。「直接チャネル」は、様々な構成設定に基づきヒューリスティック・アルゴリズムを使用して自動的に判別されます。

2. Oracle Management Server (OMS)からBI Publisherにアクセスします。OMSは、様々な処理(BI Publisherレポートのリスト表示や新しいレポートのデプロイなど)を実行するために、BI Publisherと通信する必要があります。これは内部チャネルです。内部チャネルはEnterprise Managerのインストールまたはアップグレード時に自動的に構成されます。内部チャネルは、emcli setup_bipublisherコマンドを使用していつでも手動で変更することもできます。このコマンドの詳細は、「BI Publisherサーバーおよび他のEnterprise Managerコンポーネントの管理」を参照してください。

2つのチャネルについて次に詳しく説明します。

1. 直接チャネル: 後で示すTCP/IPポートのいずれかと通信プロトコル(HTTPまたはHTTPS)が使用されます。Enterprise Managerのアクセスに使用される方法やEnterprise Manager認証モデルによって異なります。emctl status oms -detailsコマンドを使用すると、すべてのBI Publisherポートの値を表示できます。

2. Enterprise Managerがサーバー・ロード・バランサでの使用に対して構成されている場合、次のチャネルの1つまたは両方が使用されます。emctl secure omsコマンドの詳細や、Enterprise Managerとともに使用するためのサーバー・ロード・バランサの構成は、Enterprise Manager高可用性ガイドを参照してください。

1. 通常、サーバー・ロード・バランサのHTTPSポートを介してアクセスされます。このポートはemctl status oms -detailsコマンドを使用して判別できます。このポートはemctl secure omsコマンドを使用して再構成できます。このコマンドはローリング停止手順の際に各OMSシステムで実行する必要があります。
例: emctl secure oms -slb_bip_https_port 5443

2. Enterprise Managerが、emctl secure oms -unlock_consoleまたはemctl secure unlockを使用してロック解除されていた場合、HTTPモードでのサーバー・ロード・バランサ・ポートを介したアクセスもサポートされます。このチャネルが使用されるのは、Enterprise Managerが、HTTPを使用する非セキュア・モードでサーバー・ロード・バランサを使用してアクセスされた場合です。これは1つのOMSシステムのみで実行する必要があります。停止時間は不要です。次に例を示します。
emctl secure oms -slb_bip_http_port 8080

3. セキュアなOracle HTTPS Serverポート(OHS)を介してアクセスします。これが使用されるのは、サーバー・ロード・バランサが構成されているかどうかにかかわらず、Enterprise ManagerがOHS HTTPSポートを介してアクセスされた場合です。このポートは、Enterprise Managerに仮想ホスト名が構成されている場合にも使用されます。

4. Enterprise Managerがロック解除されていると、Enterprise ManagerがOHS HTTPポートを介してアクセスされた場合に、セキュアでないOracle HTTP Serverポート(OHS)を介したアクセスが使用されます。このポートは、Enterprise Managerに仮想ホスト名が構成されている場合にも使用されます。

5. Enterprise Managerがシングル・サインオンを使用するように構成され、Enterprise ManagerがOMS管理対象サーバー・ポートで直接アクセスされる場合、BI Publisherは常にセキュアなHTTPSポートでアクセスされます(つまり、SSOログイン画面は使用されません)。これは、Enterprise ManagerがHTTPモードとHTTPSモードのどちらでアクセスされた場合でも同じです。

3. 内部チャネル: 次のいずれかのTCP/IPポートが使用されます。このチャネルを介したすべての通信はHTTPSモードを使用する必要があります。
a.HTTPSモードでのサーバー・ロード・バランサを介したアクセス。b. セキュアHTTPSポートでのWebLogic管理対象サーバーへの直接アクセス。c. いずれかのOHSポートを介したアクセスは内部チャネルではサポートされません。

4. 補助チャネル: Enterprise Managerがロック解除されている場合、WebLogic管理対象サーバーへのアクセスはHTTPポートで行うことができます。

様々なチャネルを判別するemctl status oms -detailsの使用例:

emctl status oms -details
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host        : emoms1.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_OMS1
OMS Log Directory Location : /oracle/gc_inst/em/EMGC_OMS1/sysman/log
SLB or virtual hostname: slb.example.com
HTTPS SLB Upload Port : 4900
HTTPS SLB Console Port : 443
Agent Upload is unlocked.
OMS Console is unlocked.
Active CA ID: 1
Console URL: https://slb.example.com:443/em
Upload URL: https://slb.example.com:4900/empbs/upload

WLS Domain Information
Domain Name            : GCDomain
Admin Server Host      : emoms1.example.com
Admin Server HTTPS Port: 7101
Admin Server is RUNNING

Oracle Management Server Information
Managed Server Instance Name: EMGC_OMS1
Oracle Management Server Instance Host: emoms1.example.com
WebTier is Up
Oracle Management Server is Down
JVMD Engine is Down

BI Publisher Server Information
BI Publisher Managed Server Name: BIP
BI Publisher Server is Up

BI Publisher HTTP Managed Server Port   : 9701
BI Publisher HTTPS Managed Server Port  : 9803
BI Publisher HTTP OHS Port              : 9788
BI Publisher HTTPS OHS Port             : 9851
BI Publisher HTTPS SLB Port             : 5443
BI Publisher HTTP SLB Port              : 8080
BI Publisher is unlocked.
BI Publisher Server named 'BIP' running at URL: https://slb.example.com:5443/xmlpserver
BI Publisher Server Logs: /oracle/gc_inst/user_projects/domains/GCDomain/servers/BIP/logs/
BI Publisher Log        : /oracle/gc_inst/user_projects/domains/GCDomain/servers/BIP/logs/bipublisher/bipublisher.log

16.5 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機能へのアクセス認証とアクセス制限

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

統合すると、BI PublisherレポートがEnterprise Managerのセキュリティ・モデルに準拠します。Enterprise Managerは、Oracle® Enterprise Managerセキュリティ・ガイドで定義されている、様々なセキュリティ・モデルをサポートします。

Enterprise Manager 13cがサポートしているセキュリティ・モデルの概要は次のとおりです。

1. リポジトリベースの認証

2. エンタープライズ・ユーザー・セキュリティベース(EUS)の認証

3. Oracle Access Manager(OAM) SSO

4. Oracle Single Sign-On(OSSO)ベースの認証

5. LDAP認証オプション: Oracle Internet DirectoryおよびMicrosoft Active Directory

6. 他のLDAPプロバイダ(Enterprise Managerによってサポートされる)の手動WebLogic構成。

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

BI Publisherは、Enterprise Managerと統合されると、Enterprise Managerと同じセキュリティ・モデルを共有します。

セキュリティ・モデル1: リポジトリベースの認証(認証にOracle Databaseを使用)。

セキュリティ・モデル2: エンタープライズ・ユーザー・セキュリティ認証(EUS) (認証にOracle Databaseを使用)。このセキュリティ構成では、Oracle Databaseが認証をLDAPサーバーに委任します。ただし、このLDAPサーバーにWebLogicが直接アクセスすることはなく、そのためBI PublisherはLDAPサーバーに直接アクセスしません。

残り4つ(3から6まで)のセキュリティ・モデルでは、WebLogicが直接アクセスする、基礎となるLDAPサーバーを使用してユーザーを認証します。

このドキュメントでは、BI Publisherセキュリティ・モデルを次の2つのカテゴリのいずれかに分類します。

1. リポジトリベースの認証

2. 基礎となるLDAPベースの認証

注意:
BI Publisherが適切にEnterprise Managerと連動するためには、BI Publisher管理者画面を使用してBI Publisherセキュリティ・モデルを直接変更しないことが非常に重要です。Enterprise ManagerとBI Publisherは、同じWebLogicドメインで構成されているため、自動的に同じセキュリティおよび認証メカニズムを共有します。BI Publisherセキュリティ・モデルを直接変更すると、BI Publisherにログインできなくなります。

BI Publisherレポートに適用される主なセキュリティ属性は次のとおりです。

- BI Publisherの権限

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

これらの各セキュリティ属性の詳細を次の各項で説明します。

16.5.3 BI Publisherの権限

Enterprise Managerには、オラクル社提供の特定のBI Publisherカタログ・オブジェクトが付属しています。これらのカタログ・オブジェクトは次の要素で構成されています。

- フォルダ

- レポート(レイアウト定義および変換)

- データ・モデル(Enterprise Managerリポジトリに対するSQL問合せ)

- サブテンプレート(すべてのレポート出力の各ページの上部に表示される標準のEnterprise Managerヘッダー)

これらのカタログ・オブジェクトは、BI PublisherがインストールされてEnterprise Managerに統合されると作成されます。これらは、「Enterprise Manager Cloud Control」フォルダにあります。これらのカタログ・オブジェクトは、次に説明するロール/グループを組み合せた特定の権限で作成され、目的のセキュリティ・モデルを達成します。

16.5.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)が使用されます。

16.5.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管理者は、電子メールの受信とEnterprise Manager提供のBI Publisherレポートのスケジュール設定を行うことができます。ただし、この権限ではEnterprise Manager提供のBI Publisherレポートを表示することはできません。したがって、BI Publisherレポートをスケジュール設定する必要があるEnterprise Manager管理者には、通常はEMBIPViewer権限を付与する必要があります。

- 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.6 BI Publisher機能へのアクセス制限

前の項で説明した4つのOPSSアプリケーション・ロールの付与は、使用しているBI Publisherセキュリティ・モデルによって若干異なります。確認のため、BI Publisherがサポートしている2つのセキュリティ・モデルを次に示します。

- リポジトリベースの認証

- 基礎となるLDAPベースの認証

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

16.6.2 OPSSへの変更の伝播時間

Enterprise Manager管理者のBI Publisherアクセス権限(EMBIPViewer、EMBIPAdministrator、EMBIPScheduler、EMBIPAuthor)を変更する場合、スーパー管理者は、変更内容がOPSSに伝播して有効になるまで15分以上待機する必要があります。変更内容は、管理者が次にBI Publisherにログインした時点で有効になります。

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

事前に必要な手順

基礎となるLDAP認証セキュリティ環境でBI Publisherアクセス・モデルを使用できるようにするためには、Enterprise Manager管理者によるLDAP検索がサポートされるようにデフォルトのOracle Virtual Directory (OVD)構成を変更する必要があります。この変更は、Oracle Management Server (OMS)とBI Publisherの両方でLDAP検索が正常に機能するために必要です。

構成ファイルadapters.os_xmlには、構成する必要のある固有のプロパティが2つあります。

1. 次の3つのプロバイダの優先度には同じ値(通常は50)が設定されている必要があります。

- DefaultAuthenticator

- emgc_USER

- emgc_GROUP

- Enterprise Managerでの使用に対して構成されている任意のLDAPプロバイダ。たとえば、OID_Providerです。

2. 次のプロパティは値falseに設定されている必要があります
useCaseInsensitiveSearch

Enterprise Manager 13cの場合、adapters.os_xmlファイルはWebLogicドメインにあります。ファイルの正確な場所は次のとおりです。

gc_inst/user_projects/domains/GCDomain/config/fmwconfig/ovd/default/adapters.os_xml

このファイル編集は、プライマリOracle Management Server (OMS)およびWebLogic管理サーバーが格納されているシステム上で行う必要があります。

この編集を行った後、次の手順を使用して、完全なEnterprise Managerスタックのローリング・バウンスをすべてのEnterprise Managerシステムに対して実行する必要があります。

1. プライマリOMSシステムでadapters.os_xmlファイルを編集します。

2. すべてのEnterprise Managerシステムで、最初のOMSシステムから最後のOMSシステムの順に、次のコマンドを実行します。

1. emctl stop oms -all -force

2. emctl start oms

次のMOSノートに詳細情報と、この変更をサポートする簡単なシェル・スクリプトが記載されています。

基礎となるLDAP認証セキュリティ環境でBI PublisherをOMSとともに使用するためのEnterprise Manager 13cの要件。(ドキュメントID 3-2260665.1)

LDAPでのBI Publisherの使用方法の詳細

Enterprise ManagerとBI Publisherは個別のアプリケーションです。基礎となるLDAPベースの認証モデル(エンタープライズ・ユーザー・セキュリティ(EUS)を除く)を使用すると、外部LDAPサーバーに定義されたLDAPグループもBI Publisherへのアクセス権を管理するために使用できます。このようなLDAPグループを使用すると、BI Publisherに対する様々なレベルのアクセス権を複数のEnterprise Manager管理者に付与できます。これにより、1つ以上のLDAPグループのメンバーとしてLDAPユーザーを追加できるようになり、BI Publisherの適切な機能がそのユーザーに公開されます。これらのLDAPグループは、作成するか既存のものを使用する必要があり、「Enterprise Manager Cloud Control」フォルダのカタログ・オブジェクトの権限で調整されます。

企業標準のためにEnterprise Managerで使用する新しいLDAPグループを作成できなくても、「wlstを使用したリポジトリベースの認証モードによるEnterprise Manager管理者へのBI Publisher OPSSアプリケーション・ロールの付与」の手順を続行して、LDAPサーバーによって管理されるEnterprise Managerユーザーのために使用できます。

注意:
この項の説明は、エンタープライズ・ユーザー・セキュリティ(EUS)を使用するようにEnterprise Managerを構成している場合には適用されません。第16.6.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グループのメンバーにする必要があります。

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

前述のOPSSアプリケーション・ロールに4つのLDAPグループをマップするには、EM CLIを使用してLDAPグループをマップする必要があります。

注意:
Enterprise Managerに対するBI Publisherの以前のインストールから、Enterprise Manager 13cリリース1 (13.1.0.0.0)に対するBI Publisher 12.1.3にアップグレードして、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

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

BI Publisher WebLogic Serverには、デフォルト・アイデンティティ・キーストア(DemoIdentity.jks)とデフォルト信頼キーストア(DemoTrust.jks)が構成されています。また、WebLogic Serverは、JDKのcacertsファイルのCA証明書を信頼します。このデフォルトのキーストア構成は、テストや開発を目的とする場合に適しています。ただし、これらのキーストアは本番環境では使用しないでください。

Enterprise Managerが、emctl secure wls、emctl secure oms、emctl secure consoleなどのコマンドを使用してSSL証明書で保護されている場合、BI Publisherも同様に構成されます。このコマンドの使用方法の詳細は、Enterprise Managerのセキュリティ・ガイドを参照してください。

16.9 BI Publisherの管理

BI Publisherの設定の構成手順については、BI Publisherのマニュアルを参照してください。

共通の管理タスク:

- サーバー・プロパティ(電子メール・サーバーなど)の構成。

- レポート配信チャネル(FTPなど)の構成

16.10 BI Publisher構成後の構成後処理手順

Enterprise Managerに表示されるBI Publisherのいくつかのレポートは、特定のプラグインに属しています。これらのレポートを使用するには、これらのプラグインをインストールする必要があります。プラグインはEnterprise Manager 13cのインストールまたはアップグレードの前でも後でもインストールできます。

注意:
インストールの詳細は、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。

Enterprise Managerプラグインが、Enterprise Manager 13cの最初のインストールまたはアップグレードの後にインストールされる場合、これらの新しいBI PublisherレポートをEnterprise ManagerからBI Publisherにデプロイする必要があります。これには、次のコマンドを使用できます。

emcli deploy_bipublisher_reports

このコマンドの完全な使用方法と例を参照するには、次を実行します。

emcli help deploy_bipublisher_reports

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

デフォルトでは、付属のセキュリティ・モデル(第16.5.5項で説明)が「Enterprise Manager Cloud Control」フォルダ内のBI Publisherカタログ・オブジェクトに適用されます。これは、このフォルダ内に存在するカタログ・モデルがデフォルト設定の権限で設定されるためです。第16.5.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管理者にも表示されます。

16.12 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つのターゲットに関連付けられているターゲット・レベルのデータしか表示できません。

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

次の各項では、Enterprise Manager/BI Publisherの統合で問題が発生した場合に使用できる一般的な方法を説明します。

16.13.1 configureBIPの再実行

新規のBI Publisher構成中またはBI Publisher構成アップグレードの実行中に、configureBIPの再実行が必要になることがあります。configureBIPコマンドを実行する前に、次のコマンドを使用してBI Publisherを停止します。

emctl stop oms -bip_only

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

次のログ・ファイルを使用すると、問題の発生時点までトレースできます。次のコマンドを使用して、それぞれに対応するディレクトリを特定します。

emctl status oms -details

16.13.2.1 BI Publisherの自動構成

場所: ORACLE_HOME(oms)/cfgtoollogs/bip/*

- データベースでのBI Publisherスキーマの作成/アップグレード

- "emBIPLATFORM.log

- "emBIPLATFORMcreate_<date>.log

- "biplatform.log

- "emBIPLATFORMcreate.err

- BI Publisherが統合されたEnterprise Managerドメインの拡張

- "bipca_<date>.log

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

emoms.trc

emoms.log

ログ・ファイル内で「BIP」(すべて大文字)を検索すると、BI Publisher統合に固有のメッセージが見つかります。

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

16.13.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のレポートが破損した場合のリストアにも使用できます。

16.13.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のデバッグが終了したら、必ずデバッグを無効にしてください。

16.13.5.1 BI Publisherのデバッグの有効化

1. Enterprise ManagerにデモのSSL証明書がまだ構成されている場合、wlstを使用する前にまずシステム環境変数を設定する必要があります。したがって、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()
Please enter your username :weblogic
weblogic
Please enter your password :
Please enter your server URL [t3://localhost:7001] :t3s://em.example.com:7101
t3s://em.example.com:7101
...
...
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()

16.13.5.2 BI Publisherのデバッグの無効化

BI Publisherのデバッグが終了したら、ログ・レベルをデフォルト設定に戻す必要があります。

1. WLSTに接続します。

2. 次のWLSTセッション例に示すコマンドを実行して、デバッグを無効化します。

Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> connect()
Please enter your username :weblogic
weblogic
Please enter your password :
Please enter your server URL [t3://localhost:7001] :t3s://em.example.com:7101
t3s://em.example.com:7101
setLogLevel(target='BIP',logger='oracle.xdo',level=' 'WARNING:1')
wls:/GCDomain/serverConfig> getLogLevel(logger='oracle.xdo',target='BIP')
'WARNING:1'

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

Enterprise ManagerからBI Publisherにアクセスする場合、レポート定義を取得、表示および管理するために2つの製品間に直接接続が必要です。たとえば、「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。次の図に示すようなEnterprise Manager Cloud Control共有フォルダ内のBI Publisherレポートを示すツリー・ビューが表示されます。

Enterprise Manager Cloud Controlが最初にインストールされるとき、インストール/構成に必要な資格証明のみを持つ専用WebLogicユーザーが自動的に作成されます。Enterprise Manager 13c Cloud Controlリリース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ユーザーなどです。対応するアプリケーションやコンソールを使用して、インストールされている資格証明ストア内でユーザーの作成や管理を行います。たとえば、指定されるユーザーが、WebLogicに含まれる埋込みLDAPサーバーの一部である場合は、WebLogicコンソールを使用してパスワードを設定します。指定されるユーザーが企業LDAPサーバーの一部である場合は、そこでパスワードを設定します。

注意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の統合の詳細は、第16.7項「基礎となるLDAP認証セキュリティ環境でのEnterprise Manager管理者に対するBI Publisherへのアクセスの許可」を参照してください。

3. EMCTL config omsコマンドを実行します。

Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 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 13c Release 1
Copyright (c) 1996, 2015 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

16.15 BISystemUser資格証明のリセット

BI Publisherが適切に動作するために、特別なユーザーがEnterprise Managerインストールの一部として作成されます。このユーザーはBISystemUserです。このユーザーの資格証明は、Enterprise Managerのインストールまたはアップグレード時にBI Publisherが最初に構成されるときに、セキュアなランダム・パスワード・ジェネレータを使用して作成されます。

企業でのポリシーまたは手順のために、このパスワードをリセットする必要がある場合には、次のコマンドを実行できます。

emctl config oms -change_bisystemuser_pwd [-admin_pwd <pwd> {[-user_pwd <pwd>] | [-auto_generate]}

新しいパスワードは自動的に再生成されます。あるいは、コマンドラインに特定のパスワードを指定できます。

いくつか例を挙げます。

emctl config oms -change_bisystemuser_pwd
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Enter Admin User's Password :
Enter BISystemUser's Password :
Successfully updated credentials for BISystem account.

emctl config oms -change_bisystemuser_pwd -auto_generate
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Enter Admin User's Password :
Successfully updated credentials for BISystem account.

emctl config oms -change_bisystemuser_pwd -admin_pwd welcome1
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Enter BISystemUser's Password :
Successfully updated credentials for BISystem account.

emctl config oms -change_bisystemuser_pwd -admin_pwd welcome1 -user_pwd welcome1
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Successfully updated credentials for BISystem account.

emctl config oms -change_bisystemuser_pwd -admin_pwd welcome1 -auto_generate
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Successfully updated credentials for BISystem account.

16.16 BI Publisherサーバーおよび他のEnterprise Managerコンポーネントの管理

BI Publisherは、OMSおよびAdminServerを含む同じWebLogicドメインで個別の管理対象サーバーとして動作します。BI Publisherの構成後は、Enterprise Managerのemctlコマンドを使用し、OMSと独立してBI Publisherを管理することもできます。すべてのコマンドは、実行対象のコンポーネントの現在のステータスにかかわらず、適切に作動します。たとえば、OMSがすでに稼働している場合は、emctl start omsによってその状態がレポートされ、起動が再試行されることはありません。また、BI Publisherがすでに停止している場合は、emctl stop oms -allによってその状態がレポートされ、停止が再試行されることはありません。

コマンドの操作

emctl start oms

このコマンドは、Oracle Enterprise Managerを実行するために必要なコンポーネントすべてを起動します。特に、このコマンドは次のコンポーネントを次の順序で起動します。

- WebLogicノード・マネージャ

- WebLogic管理サーバー

- Oracle Management Service (JVMDマネージャを含む)

- Oracle WebTier

- BI Publisherサーバー

emctl start oms -bip_only

次のEnterprise Managerコンポーネントを起動します。

- WebLogicノード・マネージャ

- WebLogic管理サーバー

- Oracle WebTier

- BI Publisherサーバー

この後に示すemctl stop omsコマンドのすべての組合せで、オプション引数-forceを指定すると、コマンドがノード・マネージャを使用してEnterprise Managerのコンポーネントを停止します。

emctl stop oms [-force]

停止するEnterprise Managerコンポーネント: Oracle Management Service (JVMDマネージャを含む)。

注意: このコマンドはEnterprise Managerの他のコンポーネントでは作動しません。

emctl stop oms -bip_only [-force]

停止するEnterprise Managerコンポーネント: BI Publisherサーバー

注意: このコマンドはEnterprise Managerの他のコンポーネントでは作動しません。

emctl stop oms -all

このコマンドは、Enterprise Managerのすべてのコンポーネントを停止します。特に、このコマンドは次のコンポーネントを次の順序で停止します。

- Oracle WebTier

- Oracle Management Service (JVMDマネージャを含む)

- BI Publisherサーバー

- WebLogic管理サーバー

- WebLogicノード・マネージャ

emctl status oms

すべてのEnterprise Managerコンポーネントのステータスを示すメッセージを表示します

emctl status oms -bip_only

BI Publisherのステータスを示すメッセージを表示します。

emctl status oms -details [-sysman_pwd <pwd>]

このコマンドはすべてのEnterprise Managerコンポーネントのステータスを表示します。次を含む詳細情報を表示します。

- コンソールとPBSのHTTPおよびHTTPSアップロード・ポート、それぞれのURL。

- インスタンス・ホームの場所

- Oracle Management Serviceログ・ディレクトリ

- ソフトウェア・ロード・バランサまたは仮想サーバーの詳細

- 管理サーバー・マシン、ポートおよびURL

- Oracle BI Publisherの詳細(構成されているすべてのTCP/IPポート、BI Publisherログ・ファイルの場所など)。

16.17 BI Publisherの使用

BI Publisherの使用に関する包括的な情報は、BI Publisherドキュメント・ライブラリを参照してください。

http://www.oracle.com/technetwork/middleware/bi-publisher/documentation/index.html

16.18 Enterprise Manager 13cリリース1とともにインストールされなかったBI Publisherの削除

重要: Enterprise Manager 13cリリース1のインストールが完了するまで、この項の手順を開始しないでください。

以前のリリースのEnterprise ManagerにもBI Publisherが含まれていた場合、OMSホームの以前のインストールとともに、BI Publisher Oracleホームの以前のインストールを安全に削除できます。ベスト・プラクティスとしては、以前のBI Publisher Oracleホームと関連するOracleホームも削除することをお薦めします(膨大な量のディスク・スペースを使用する場合があるため)。

以前のEnterprise Managerソフトウェアを削除するタイミングおよび様々な削除方法など、Enterprise Managerのアップグレードの詳細は、『Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

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

Oracle Management Service (OMS)は、主にコンソール・サービスとバックグラウンド・サービスの2つのタイプのサービスを実行するように設計されています。この章では、コンソール限定モードでのOMSの稼働方法について説明します。この章の具体的な内容は次のとおりです。

- 「コンソール限定モード」でのOMSの稼働について

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

17.1 「コンソール限定モード」でのOMSの稼働について

Oracle Management Service (OMS)は、主にコンソール・サービスとバックグラウンド・サービスの2つのタイプのサービスを実行するように設計されています。コンソール・サービスはEnterprise Manager用のGUI豊富なコンソールの表示に必要とされ、バックグラウンド・サービスは重要なジョブ、アップロード操作およびビジネス・ロジックの実行で必要とされます。

図17-1は、コンソール・サービスとバックグラウンド・サービスの両方が実行しているOMSの機能を示しています。

図17-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はコンソール限定モードで実行できません。

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

OMSをコンソール限定モードで実行するには、次の手順を実行します。

1. 次のコマンドを使用して、OMSを停止します。
$<ORACLE_HOME>/bin/emctl stop oms

2. 次のコマンドを使用して、起動モードをコンソール専用に設定します。
$<ORACLE_HOME>/bin/emctl config oms -set_startup_mode console_only

3. 次のコマンドを使用してOMSを起動します。
$<ORACLE_HOME>/bin/emctl start oms

OMSインスタンスを標準モードに戻すには、次のコマンドを実行し、OMSを再起動します。

$<ORACLE_HOME>/bin/emctl config oms -set_startup_mode normal

第VI部

Enterprise Managerの高可用性の構成

この部では、Oracle Enterprise Managerインストールを保護できるEnterprise Manager高可用性のベスト・プラクティスおよび戦略について説明します。

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

- Enterprise Managerの高可用性

- Enterprise Manager障害時リカバリ

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

- BI Publisherの高可用性

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

高可用性システムは、実質的に今日のすべてのビジネスの成功に欠かせないものです。それと同時に、これらのミッションクリティカルなシステムを監視する管理インフラストラクチャの可用性が高いことも重要です。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の高可用性ソリューションの設定方法の詳細は、第22章「BI Publisherの高可用性」を参照してください。

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

18.2 高可用性の定義

Oracle Enterprise Managerの柔軟性の高い分散アーキテクチャにより、広範囲のデプロイメント構成が可能になるため、ビジネスの監視ニーズと管理ニーズを満たすだけでなく、ビジネス・ニーズの指示に従った拡張が可能になります。

このため、Enterprise Managerの高可用性を単一の実装として範囲を狭めて定義することはできませんが、使用可能なリソース、Oracleのテクノロジ、およびITインフラストラクチャへの投資を保護するベスト・プラクティスに基づく保護レベルの範囲で定義できます。Enterprise Managerのデプロイメントおよびビジネス・ニーズに応じて、ビジネスの維持に必要な高可用性のレベルを実装できます。Enterprise Managerの高可用性は、4つのレベルに分類できます。各レベルは、これまでの、拡大する実装コストや複雑さだけでなく、徐々に増加する可用性のレベルに基づきます。

18.2.1 高可用性のレベル

高可用性ソリューションの各レベルは、ビジネス要件と使用可能なITリソースで左右されます。しかし、このレベルは、使用可能な様々なオプションを示すのに便利な、可能なデプロイメントのサブセットを表していることに注意することが重要です。IT組織は、いずれかのレベルに正確に一致する必要のない、独自の構成をデプロイする可能性があります。

次の表に、Oracle Enterprise Managerインストールの4つの高可用性レベルの例を、一般的なリソース要件とともにまとめています。

表18-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

必須: サイトごとのローカル・ロード・バランサ。

オプション: グローバル・ロード・バランサ

18.3 可用性レベルの比較

次の表で、各HAレベルの保護レベルと復旧時間を比較します。

表18-2 保護の高可用性レベル

レベル

OMSホスト障害

OMSストレージ障害

データベース・ホスト障害

データベース・ストレージ障害

サイト障害/障害復旧

レベル1

いいえ

いいえ

いいえ

いいえ

いいえ

レベル2

はい

いいえ

はい

はい

いいえ

レベル3

はい

はい

はい

はい

いいえ

レベル4

はい

はい

はい

はい

はい

表18-3 高可用性レベルの復旧時間

レベル

ノード障害

ローカル・ストレージ障害

サイト障害

費用

レベル1

数時間から数日

数時間から数日

数時間から数日

$

レベル2

数分

数時間から数日

数時間から数日

$$

レベル3

停止なし

数分

数時間から数日

$$$

レベル4

停止なし

数分

数分

$$$$

この表に示されていない1つの基準はスケーラビリティです。レベル3と4には、ビジネス・ニーズの拡大に応じてEnterprise Managerのインストールを拡大する機能があります。RACデータベースとして実行しているリポジトリは、RACクラスタに新しいノードを追加することで容易に拡張できるので、OMSサーバーを追加するだけで、管理サービス層を拡大することができます。

スタンバイ・デプロイメントへのフェイルオーバー時にパフォーマンスを平準化する必要がある場合は、ローカル・スタンバイ・データベース、またはスタンバイRACデータベースおよびスタンバイOMSサーバーを含むレベル4スタンバイ・サイトのいずれであっても、デプロイメントのサイズが両方のサイトで対称的であることが重要です。これは特に、プライマリまたはセカンダリ・サイトで長時間アクティブに実行する計画フェイルオーバー・ルーチンを実行する場合に当てはまります。たとえば、一部の金融機関では、操作手順の一部としてこれを義務付けています。

プライマリ・サイトの損失時に生存性が必要な場合、レベル4のアーキテクチャで稼働する必要があります。

18.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アドバンスト・インストレーションおよび構成ガイド』
および

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

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

19 Enterprise Managerの高可用性

この章では、各Cloud Controlコンポーネントのインストールおよび構成に関するベスト・プラクティスについて説明し、次の項目を含みます。

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

- リポジトリの高可用性

- Oracle Management Serviceの高可用性

19.1 エージェントの高可用性

次の各項では、管理エージェントのインストールおよび構成に関するベスト・プラクティスについて説明します。

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

管理エージェントは手動で起動されます。管理対象ホスト上の重要なリソースが確実に監視されるように、ホストの起動時に管理エージェントが自動的に起動することが重要です。そのためには、あらゆるオペレーティング・システムのメカニズムを使用して、管理エージェントが自動的に開始するようにします。たとえば、UNIXシステムでは起動時に管理エージェントを呼び出すエントリをUNIXの/etc/init.dに配置することにより、またはWindowsサービスを自動的に開始するように設定することにより、これを行います。

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

管理エージェントを起動すると、ウォッチドッグ・プロセスは管理エージェントを監視し、障害が発生した場合にエージェントの再起動を試みます。ウォッチドッグの動作は、管理エージェント・プロセスの開始前に設定される環境変数で制御します。この動作を制御する環境変数は次のとおりです。ここで説明するテストはすべて、デフォルトの設定で行われました。

- EM_MAX_RETRIES - ウォッチドッグがEM_RETRY_WINDOW内で管理エージェントの再起動を試行する最大回数。デフォルトでは、管理エージェントを3回再起動します。

- EM_RETRY_WINDOW - EM_MAX_RETRIES環境変数と一緒に使用される時間間隔(秒単位)。管理エージェントを再起動するかどうかを判断します。デフォルトは600秒です。

ウォッチドッグが、EM_RETRY_WINDOW期間内でEM_MAX_RETRIESの回数を超えた管理エージェントの再起動が必要であることを検出すると、管理エージェントは再起動されません。

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

管理エージェントは、エージェントの状態ディレクトリのローカル・ファイルを使用して、その構成と中間状態、および収集された情報を保持します。

これらのファイルが管理リポジトリにアップロードされる前に損失または破損した場合、監視データの損失や、管理リポジトリにアップロードされていない保留中のアラートが発生します。

このような損失を防ぐために、冗長記憶域でエージェントの状態ディレクトリを構成します。エージェントの状態ディレクトリは、コマンド$AGENT_HOME/agent_inst/bin/emctl getemhomeを入力するか、Cloud Controlコンソールのエージェントのホームページで確認できます。

19.2 リポジトリの高可用性

次の項では、リポジトリ構成に関するベスト・プラクティスについて説明します。

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

Enterprise Managerをインストールする前に、管理リポジトリの設定に使用されるデータベースを準備する必要があります。Database Configuration Assistant (DBCA)を使用してデータベースをインストールし、Oracleインストールのすべてのベスト・プラクティスを継承することを確認します。

- 基本となるストレージ・テクノロジとして「自動ストレージ管理(ASM)」を選択します。

- ARCHIVELOGモードの有効化

- ブロック・チェックサムの有効化

- REDOログ・ファイルのサイズおよびグループの適切な構成

- フラッシュ・リカバリ領域の使用

- フラッシュバック・データベースの有効化

- ファスト・スタート・フォルト・リカバリを使用したインスタンス・リカバリ時間の制御

- データベース・ブロック・チェックの有効化

- DISK_ASYNCH_IOの設定

管理リポジトリへの適用が必要な高可用性の推奨事項については、MAAアドバイザを使用します。MAAアドバイザにアクセスするには、リポジトリ・データベースのホームページで「可用性」→「MAAアドバイザ」の順に選択します。

管理リポジトリをホストするデータベースが必要な可用性を実現するように構成するための、これらのベスト・プラクティスおよび他のベスト・プラクティスの詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

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

19.3 Oracle Management Serviceの高可用性

次の各項では、OMSの高可用性の構成について説明します。

OMSの高可用性を実現するには、まず、少なくとも1つのOMSを常に使用可能な状態にします。リカバリ時間目標(RTO)によって異なりますが、アクティブ/アクティブ構成では、少なくとも1つの追加OMSを追加することで、ノードの損失に伴う停止時間なしにこれを実現することができます。または、プライマリ・サーバーで障害が発生したときに別のサーバーの同じアドレスでOMSが実行できるようにすることで、アクティブ/パッシブ構成ではノードの損失に伴う停止時間が短縮します。高可用性を実現するアーキテクチャに関するオプションの詳細は、第18章「高可用性ソリューション」を参照してください。

障害時リカバリを含む、さらに高度な可用性レベルに将来移行できるように、環境を最適に準備するために実行できる手順がいくつもあります。これらは、高可用性を得るために選択した方法や、インストール時に最初に選択した可用性レベルには関係ありません。これらの手順の詳細は、「別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSを構成するためのベスト・プラクティス」を参照してください。

OMSの高可用性を保証するには、Enterprise Managerによって管理される環境のサイズと範囲およびEnterprise Managerの使用方法の規模と複雑さ(管理者の数や利用される機能の種類など)に対応できるように十分な数のOMSも必要です。

環境の十分なキャパシティを保証するため、またはパッシブ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)の内側への複数の管理サービスの構成」を参照してください。

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

この項では、別名ホスト名と記憶域レプリケーションを使用する障害時リカバリとの互換性を持つようにCloud Control OMSをインストールする、Cloud Control管理者のためのベスト・プラクティスを説明します。将来、障害時リカバリが必要になった場合、これらのベスト・プラクティスによって実装に必要な手順が少なくなります。これらのベスト・プラクティスは、すべてのMAA高可用性レベルのインストールに対応します。最高のMAA高可用性レベルのニーズを考慮してスタンドアロンOMSをインストールすると、最大限の柔軟性が得られ、将来的にさらに上のMAA高可用性レベルに簡単に移行することができます。

19.3.1.1 概要および要件

Cloud Control OMSインストールが、別名ホスト名と記憶域レプリケーションを使用する障害時リカバリをサポートするためには、次のインストール条件を満たす必要があります。

- ミドルウェア・ホーム、OMSインスタンス・ベース、エージェント・ベースおよびOracleインベントリ・ディレクトリが、スタンバイ・サイトにレプリケートできる記憶域にインストールされている必要があります。

- OMSのインストールは、OMSのプライマリ・サイト・ホストおよびスタンバイ・サイト・ホストと同じ別名ホスト名が維持されるような方法で実行する必要があります。別名ホスト名を使用してソフトウェアを構成すると、プライマリ・サイトまたはスタンバイ・サイトどちらのOMSホストでも変更なしで同じバイナリと構成を使用できます。

- ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースが、スタンバイ・サイトにレプリケートできる記憶域に、Oracleインベントリの場所を使用してインストールされる必要があります。

- ソフトウェア所有者とタイムゾーンのパラメータを、該当のOracle Management Service(OMS)をホストするすべてのノードで同じにする必要があります。

- ミドルウェア、インスタンス、OMSエージェントおよびOracleインベントリ・ディレクトリへのパスは、このOMSをホストするすべてのノードで同じである必要があります。

19.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インベントリがこのディレクトリの下にインストールされるように確認します。

19.3.1.3 別名ホスト名の構成

障害時リカバリをサポートするには、プライマリ・サイトのホストとスタンバイ・サイトのホストが、OMSインストールで使用されているのと同じホスト名で稼働できることが必要です。これは、別名ホスト名を使用して実現できます。

「ホスト名の計画」の手順を使用して、インストールで使用する別名ホスト名を構成します。この項の「オプション2: 両方のサイトでの別名ホスト名」は、柔軟性を最大限に高めることができるため、新しいインストール用のベスト・プラクティスとして使用することをお薦めします。

オプション2を実施するには、OMSをインストールするときに、ORACLE_HOSTNAME=<ALIAS_HOST_NAME>パラメータを指定するか、OUIインストールの「ホスト名」フィールドに別名ホスト名を指定します。たとえば、インストール・ウィザードのコマンドラインに次のパラメータを指定します。

ORACLE_HOSTNAME=oms1.example.com

19.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>パラメータを次のようにインストール・ウィザードのコマンドラインに指定して、OracleインベントリをOMSインストール・ベース・ディレクトリに指定します。

-invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc

インストーラによって、指定の場所にインベントリが作成されます。このOMSおよびOMSエージェントのすべてのインストール、パッチ適用およびアップグレード・アクティビティにこのインベントリを使用します。

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

プライマリ・サイトに複数のOMSをインストールする際に、同じソフトウェア所有者とグループを使用するように、障害時リカバリに対応するために、スタンバイ・サイトのOMSホストでもソフトウェア所有者とグループを同じように構成する必要があります。プライマリ・サイトのために選択した所有者名およびIDとグループ名およびIDを、スタンバイ・サイトでも使用できるようにしてください。

ソフトウェア所有者のユーザーとグループの構成がすべてのOMSノードで同一であることを確認するには、次の例のようにidコマンドを実行します。

$ id -a

uid=550(oracle) gid=50(oinstall) groups=501(dba)

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

プライマリ・サイトに複数のOMSをインストールする際に、同じタイムゾーンを使用するように、障害時リカバリに対応するために、スタンバイ・サイトのOMSホストでもタイムゾーンを同じように構成する必要があります。両方のサイトで使用できるタイムゾーンを選択して、すべてのOMSホストでタイムゾーンが同一になるようにします。

19.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基本インストレーション・ガイドのOracle Enterprise Manager Cloud Control 13cリリース1のインストールに関する項を参照して、詳しい準備とインストールの手順に従います。インストール・プロセスでは次の情報を指定します。

1. ミドルウェア・ホーム、OMSインスタンス・ベースおよびエージェント・ベースがOMSインストール・ベース・ディレクトリ内に配置されるように確認します。

2. インベントリの場所のファイルとOMSの別名ホスト名を指定します。これらは、コマンドラインに次の例のように指定できます。
$ <Software_Location>/em_<platform>.bin -invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=oms1.example.com

Enterprise Managerのインストール・ウィザードのUIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。

6. 引き続きインストールの残りの手順を実行します。

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

この項では、コールド・フェイルオーバー・クラスタ(CFC)環境でEnterprise Manager Cloud Controlを構成するCloud Control管理者向けの一般的な情報を提供します。

19.3.2.1 概要および要件

Cloud Controlが別のホストにフェイルオーバーするには、次の条件を満たす必要があります。

- インストールは、仮想ホスト名と関連する一意のIPアドレスを使用して行います。

- バイナリおよびgc_instディレクトリを保持する共有ディスクやボリュームにインストールします。

- 稼働中のノードにインベントリの場所をフェイルオーバーします。

- ソフトウェア所有者とタイムゾーンのパラメータは、該当のOracle Management Service(OMS)をホストするクラスタ・メンバーのすべてのノードで同じにします。

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

注意:
共有フェイルオーバー・ボリュームについては、フェイルオーバー後にアクティブなホストにマウントできる非共有フェイルオーバー・ボリュームにも当てはまります。

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

仮想ホスト名と仮想IPアドレスを設定するには、クラスタウェアで設定できるようにするか、Oracleサービスのインストールおよび起動前にユーザー自身が手動で設定します。仮想ホスト名は静的にして、ネットワークで常に解決できるようにします。設定に参加するすべてのノードは、仮想IPアドレスを同じホスト名に解決する必要があります。nslookupやtracerouteなどの標準のTCPツールを使用してホスト名を検証できます。次のコマンドを使用して検証します。

nslookup <virtual hostname>

このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。

nslookup <virtual IP>

このコマンドは、仮想IPアドレスと完全修飾ホスト名を返します。

必ずクラスタのすべてのノードでこれらのコマンドを実行し、正しい情報が返されることを検証します。

19.3.2.4 共有記憶域の設定

共有記憶域は、使用しているクラスタウェアで管理するか、あるいは、NFSなどの共有ファイルシステム(FS)ボリューム(OCFS V1などのサポート対象外のタイプを除く)を使用できます。

注意:
OCFS V1のみ、サポート対象外です。OCFSの他のすべてのバージョンがサポートされます。

OHSディレクトリが共有記憶域上にある場合、ローカル・ディスクを指し示すようにhttpd.confファイルのLockFileディレクティブを変更する必要があります。変更しない場合、ロック問題が発生する可能性があります。

19.3.2.5 環境の設定

一部のバージョンのオペレーティング・システムでは、13cをインストールする前に特定のオペレーティング・システム・パッチを適用する必要があります。ユーザーが13cソフトウェアをインストールして使用するには、十分なカーネル・リソースも使用できるようにしておく必要があります。詳細は、オペレーティング・システムのインストール・ガイドを参照してください。インストーラを起動する前に、特定の環境変数を検証する必要があります。各変数は、クラスタに参加するすべてのマシンにソフトウェアをインストールしているアカウントに対して同一に設定する必要があります。

- OS変数TZ
タイムゾーン設定。インストール前にこの変数の設定を解除してください。

- PERL変数
PERLライブラリの不正なセットへの関連付けが行われないように、PERL5LIBなどの変数の設定も解除してください。

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

ソフトウェア所有者のユーザーとグループは、クラスタのすべてのノードで同一に定義する必要があります。これは次のidコマンドを使用して検証できます。

$ id -a

uid=550(oracle) gid=50(oinstall) groups=501(dba)

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

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

ソフトウェアをインストールする場合は次の手順を参照してください。

1. ソフトウェア・バイナリの両方のノードで共有ディスクの場所を作成します。

2. インベントリの場所のファイルoraInst.loc(この場合はORACLE_BASEの下)を指し示し、仮想グループのホスト名を指定します。次に例を示します。
$ <Software_Location>/em_<platform>.bin -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.example.com -debug

Enterprise Managerインストール・ウィザードのUIからこの情報を求められた場合、ORACLE_HOSTNAMEを指定することもできます。

3. Oracle Management Serviceをクラスタ・メンバーのHost1にインストールします。

4. 引き続きインストールの残りの手順を通常どおりに実行します。

5. 完了したら、ファイルoraInst.locおよびoratabをすべてのクラスタ・メンバー・ホスト(Host2、Host3など)の/etcにコピーします。

19.3.2.9 サービスの起動

サービスは必ず正しい順序で起動してください。次の順序で行います。

1. アクティブなノードでIPアドレスを設定します。

2. TNSリスナー(同じフェイルオーバー・グループに含まれる場合)を起動します。

3. データベース(同じフェイルオーバー・グループに含まれる場合)を起動します。

4. emctl start omsを使用してCloud Controlを起動します。

5. 機能をテストします。

フェイルオーバーの場合は、「スイッチオーバーおよびフェイルオーバー操作の実行」を参照してください。

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

追加の管理サービスをインストールするには次の2つの方法があります。

- Oracle Management Serviceの追加デプロイメント・プロシージャの使用(推奨)。デプロイメント・プロシージャの使用の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のOracle Management Serviceの追加に関する章を参照してください。

- サイレント・モードでの追加のOracle Management Serviceのインストール(代替策)。サイレント・モードでのインストールの詳細は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』のサイレント・モードでの追加のOMSのインストールに関する説明を参照してください。

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

次の各項では、サーバー・ロード・バランサを使用してアクティブ/アクティブ構成でOMSの高可用性を構成する方法について説明します。

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

ソフトウェア・ライブラリの場所は、すべてのアクティブな管理サービスからアクセスできる必要があります。ソフトウェア・ライブラリがインストール中に構成されない場合、Enterprise Managerコンソールを使用してインストール後に構成する必要があります。

1. Enterprise Managerのホームページで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。

2. 「ソフトウェア・ライブラリ: 管理」ページで、「OMS共有ファイルシステム」を選択します。

3. 新しいOMS共有ファイルシステムを追加するには、「+」(追加)をクリックします。

4. 「OMS共有ファイル・システムの場所の追加」ダイアログ・ボックスで、場所の一意名を指定し、すべての管理サービス・ホストからアクセスできる共有記憶域に場所を設定します。

19.3.4.2 ロード・バランサの構成

この項では、使用可能な管理サービスにエージェントとブラウザのトラフィックを分散するサーバー・ロード・バランサ(SLB)を設定するためのガイドラインについて説明します。

サーバー・ロード・バランサの要件

SLBの背後にアクティブ/アクティブ構成でOMSを構成するために、SLBは次の要件を満たす必要があります。

- SLBは複数の仮想サーバー・ポートをサポートする必要があります。
構成によっては、SLBで最大5ポートが必要になる場合があります(セキュア・アップロード、エージェント登録、セキュア・コンソール、非保護コンソール、BI Publisher)。

- 永続性のサポート。
ブラウザとOMS間のHTTPおよびHTTPSトラフィックには永続性が必要です。

- アプリケーションの監視のサポート。
SLBはOMSの状態の監視と、障害の検知が可能である必要があるので、リクエストが使用できないOMSに転送されることはありません。

SLBの構成には次の2つの手順があります。

1. SLBを構成します。

2. 管理サービスで必要な変更の追加

19.3.4.2.1 SLB側の設定

次の表を参考にしてCloud Control管理サービスでSLBを設定します。

表19-1 管理サービスのポート

Cloud Controlサービス

TCPポート

モニター名

TCPプロファイル名

永続性プロファイル

プール名

仮想サーバー名

仮想サーバー・ポート

セキュア・コンソール

7799

mon_ccsc

tcp_ccsc

sourceip_ccsc

pool_ccsc

vs_ccsc443

443

セキュアBI Publisher

9851

mon_ccscbip

tcp_ccscbip

sourceip_ccscbip

pool_ccscbip

vs_ccscbip5443

5443

非保護コンソール

7788

mon_ccuc

tcp_ccuc

sourceip_ccuc

pool_ccuc

vs_ccuc80

80

非保護BI Publisher

9788

mon_ccucbip

tcp_ccucbip

sourceip_ccucbip

pool_ccucbip

vs_ccucbip8080

8080

セキュア・アップロード

4900

mon_ccsu

tcp_ccsu

なし

pool_ccsu

vs_ccsu4900

4900

エージェント登録

4889

mon_ccar

tcp_ccar

cookie_ccar

pool_ccar

vs_ccar4889

4889

Always-On Monitoringセキュア・アップロード

8081

mon_ccaom

tcp_ccaom

なし

pool_ccaom

vs_ccaom8081

8081

SLBにパッケージされている管理ツールを使用します。サンプル構成が付属しています。この例では、表33-1に示すデフォルトのポートを使用してホストAおよびホストBで2つの管理サービスが実行していると仮定します。

1. モニターの作成
モニターは、プール・メンバーの動作状況を検証する場合に使用されます。モニターは、ロード・バランシング・プールのメンバーであるノード上の接続やサービスを検証します。これは、規定の間隔でサービスのステータスを断続的に確認するように設計されます。確認するサービスが指定時間内に応答しない場合、ロード・バランサはプールから自動的にそのサービスを取り出し、プールの他のメンバーを選択します。ノードやサービスが再度使用可能になると、モニターはその状況を検出し、プールから自動的にアクセス可能なメンバーがトラフィックを処理できます。

表19-2 モニター

Cloud Controlサービス

TCPポート

モニター名

タイプ

間隔

タイムアウト

送信文字列

受信文字列

セキュア・コンソール(SSOを使用していない場合)

7799

mon_ccsc

https

5

16

GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n

Enterprise Manager Console is UP

セキュア・コンソール(SSOを使用している場合)

7799

mon_ccsc

https

5

15

GET /empbs/genwallet \r\n

GenWallet Servlet activated

セキュアBI Publisherコンソール

9851

mon_ccscbip

https

5

16

GET /xmlpserver/services HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n

And now... Some Services

非保護コンソール(SSOを使用していない場合)

7788

mon_ccuc

http

5

16

GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n

Enterprise Manager Console is UP

非保護コンソール(SSOを使用している場合)

7788

mon_ccuc

http

5

16

GET /empbs/genwallet \r\n

GenWallet Servlet activated

非保護BI Publisherコンソール

9788

mon_ccucbip

http

5

16

GET /xmlpserver/services HTTP/1.1\r\nHost: \r\nConnection: Close \r\n\r\n

And now... Some Services

セキュア・アップロード

4900

mon_ccsu

https

60

181

GET /empbs/upload \r\n

Http Receiver Servlet active!

エージェント登録

4889

mon_ccar

http

60

181

GET /empbs/genwallet \r\n

GenWallet Servlet activated

Always-On Monitoringセキュア・アップロード

8081

mon_ccaom

https

60

181

GET /upload \r\n

Always On Monitoring is active

注意:
一部のロード・バランサでは、リテラル\r\nを使用して送信文字列に明示的に追加するには、<CR><LF>文字が必要です。これはベンダー固有です。詳細は、SLBのドキュメントを参照してください。

2. プールの作成
プールは、ロード・バランシング方法を使用して特定のTCPポートでトラフィックを受信するためにグループ化された一連のサーバーです。各プールには、永続性の定義の独自の特性と、使用されるロード・バランシング・アルゴリズムがあります。

表19-3 プール

Cloud Controlサービス

プール名

関連付けられた状態モニター

ロード・バランシング

メンバー

セキュア・コンソール

pool_ccsc

mon_ccsc

最小接続(メンバー)

OMSホストA:7799

OMSホストB:7799

セキュアBI Publisher

pool_ccscbip

mon_ccscbip

最小接続(メンバー)

OMSホストA:9851

OMSホストB:9851

非保護コンソール

pool_ccuc

mon_ccuc

最小接続(メンバー)

OMSホストA:7788

OMSホストB:7788

非保護BI Publisher

pool_ccucbip

mon_ccucbip

最小接続(メンバー)

OMSホストA:9788

OMSホストB:9788

セキュア・アップロード

pool_ccsu

mon_ccsu

最小接続(メンバー)

OMSホストA:4900

OMSホストB:4900

エージェント登録

pool_ccar

mon_ccar

最小接続(メンバー)

OMSホストA:4889

OMSホストB:4889

Always-On Monitoringセキュア・アップロード

pool_ccaom

mon_ccaom

最小接続(メンバー)

OMSホストA:8081

OMSホストB:8081

3. TCPプロファイルの作成:
次の表に従って、Cloud ControlサービスごとにTCPプロファイルを作成する必要があります。

表19-4 TCPプロファイル

Cloud Controlサービス

TCPプロファイル名

セキュア・コンソール

tcp_ccsc

セキュアBIPコンソール

tcp_ccscbip

非保護コンソール

tcp_ccuc

非保護BIPコンソール

tcp_ccucbip

セキュア・アップロード

tcp_ccsu

エージェント登録

tcp_ccar

Always-On Monitoringセキュア・アップロード

tcp_ccaom

4. 永続性プロファイルの作成
特定のタイプのアプリケーションでは、同じクライアントが同じプール・メンバーに戻る必要があり、これを永続性または「固定性」と呼びます。これを、永続性プロファイルを使用して構成し、仮想サーバーに適用できます。ORACLE Cloud Controlサービスの場合、セキュア・アップロード・サービス以外の各サービスに対して永続性を構成する必要があります。

表19-5 永続性プロファイル

Cloud Controlサービス

F5永続性プロファイル名

タイプ

タイムアウト

有効期限

セキュア・コンソール

sourceip_ccsc

ソース・アドレス・アフィニティ

3600

該当なし

セキュアBIPコンソール

sourceip_ccscbip

ソース・アドレス・アフィニティ

3600

該当なし

非保護コンソール

sourceip_ccuc

ソース・アドレス・アフィニティ

3600

該当なし

非保護BIPコンソール

sourceip_ccucbip

ソース・アドレス・アフィニティ

3600

該当なし

エージェント登録

cookie_ccar

Cookie

該当なし

3600

5. 仮想サーバーの作成
仮想サーバー(仮想IPアドレスとポート番号を含む)は、クライアントのアドレス可能なホスト名またはIPアドレスであり、これによって、クライアントはロード・バランシング・プールのメンバーを利用できます。仮想サーバーがリクエストを受信すると、選択したロード・バランシング方法に基づいてそのリクエストをプールのメンバーに誘導します。

表19-6 必須仮想サーバー

Cloud Controlサービス

仮想サーバー名

仮想IPおよびポート

プロトコル・プロファイル(クライアント)

HTTPプロファイル

ソース・アドレス変換

iRule

デフォルト・プール

デフォルトの永続性プロファイル

セキュア・コンソール

vs_ccsc443

VIP:443

tcp_ccsc

なし

自動マップ

なし

pool_ccsc

sourceip_ccsc

セキュアBI Publisher

vs_ccscbip5443

VIP:5443

tcp_ccscbip

なし

自動マップ

なし

pool_ccscbip

Sourceip_ccscbip

非保護コンソール*

vs_ccuc80

VIP:80

tcp_ccuc

http

自動マップ

なし

pool_ccuc

sourceip_ccuc

非保護BI Publisher*

vs_ccucbip8080

VIP:8080

tcp_ccucbip

http

自動マップ

なし

pool_ccucbip

sourceip_ccucbip

セキュア・アップロード

vs_ccsu4900

VIP:4900

tcp_ccsu

なし

自動マップ

なし

pool_ccsu

なし

エージェント登録

vs_ccar4889

VIP:4889

tcp_ccar

http

自動マップ

なし

pool_ccar

cookie_ccar

Always-On Monitoringセキュア・アップロード

vs_ccaom8081

VIP:8081

tcp_ccaom

なし

自動マップ

なし

pool_ccaom

sourceip_aom

* これらのエントリはEnterprise Managerへの非保護および非暗号化アクセスを提供するため、ベスト・プラクティスとは見なされず、推奨されません。

19.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
-slb_jvmd_http_port/slb_jvmd_https_port 7301
-console
[-lock]  [-lock_console]

出力例:

Oracle Enterprise Manager Cloud Control 13c Release 1 Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Securing OMS... Started.
Securing OMS...
Restart OMS

2. すべての管理エージェントを再保護します。
SLB設定の前にインストールされた管理エージェント(管理サービス・インストールに付属する管理エージェントなど)は、管理サービスに直接アップロードしています。これらの管理エージェントは、SLBの設定後にアップロードできません。これらの管理エージェントを再保護してSLBにアップロードするには、各管理エージェントで次のコマンドを実行します。

emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em

3. Always-On Monitoringの構成
OMSを保護した後、Always-On Monitoringを構成する必要があります(パートナーOMSからHTTPS設定を取得するため)。emscaユーティリティを使用してAlways-on Monitoringアプリケーションを構成する方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

特定のOMSを保護した後、それらに対して次のコマンドを一度だけ実行します。

emctl set property -name "oracle.sysman.core.events.emsURL" -value "https://slb.example.com:8081/upload"

Enter Enterprise Manager Root (SYSMAN) Password :

Oracle Enterprise Manager Cloud Control 13c Release 1

Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.

Property oracle.sysman.core.events.emsURL has been set to value

https://slb.example.com:8081/upload for all Management Servers

OMS restart is not required to reflect the new property value

このコマンドを有効にするために、Enterprise Managerコンポーネントを再起動する必要はありません。

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

20 Enterprise Manager障害時リカバリ

前の章で説明する高可用性ソリューションは、通常、コンポーネントの障害やシステムレベルの問題などからEnterprise Managerを保護しますが、自然災害、火災、停電、排気、広範囲の妨害行為によるデータ・センターの壊滅的な障害などの大規模な故障からEnterprise Managerを保護することも必要です。

Enterprise Managerの最大可用性アーキテクチャには、プライマリ管理インフラストラクチャが災害による被害を受けた場合、セカンダリ・データ・センターが管理インフラストラクチャを引き継ぐことができるリモート・フェイルオーバー・アーキテクチャのデプロイが含まれます。

注意:
Enterprise Manager 13cではOMS障害時リカバリのために1つの方法がサポートされます。スタンバイWebLogicドメインを使用するスタンバイOMSの方法はCloud Control 12.1.0.3以降で非推奨となり、現在はサポートされていません。記憶域レプリケーションを使用するスタンバイOMSはサポートされている方法です。この章の後半で説明します。

記憶域レプリケーションを使用するスタンバイOMSは、Cloud Control 13cでの障害時リカバリ方法です。記憶域レプリケーションを使用するスタンバイOMSの利点は、次のとおりです。

- OMSパッチおよびアップグレードは1つのサイトで実行するだけで済みます。

- プラグインは1つのサイトで管理するだけで済みます。

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

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

- 設計上の考慮事項

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

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

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

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

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

Cloud Controlデプロイメントに対する障害時リカバリ・ソリューションには、OMS、ソフトウェア・ライブラリおよびリポジトリのコンポーネントのスタンバイ・サイトへのレプリケーションが含まれます。このソリューションは、前の章で説明した高可用性ソリューションと組み合せて、Cloud Controlの可用性の中断を最小限に抑えながら、コンポーネントの障害からサイト全体の停止までの多岐にわたる障害を確実にリカバリできるようにします。

前の章で説明した高可用性設計と、この章で説明する障害時リカバリ・ソリューションとを組み合せた、Enterprise Manager Cloud Controlの完全な実装を次の図に示します。

図20-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またはグローバル・ロード・バランサを更新して、ユーザー・リクエストをスタンバイ・サイトに再ルーティングします。この時点では、スタンバイ・サイトが本番のロールを引き継いでいます。

20.2 設計上の考慮事項

この項では、エンタープライズ・デプロイメントにおけるCloud Control障害時リカバリ・ソリューションに関する設計上の考慮事項について説明します。

この章では、次の項目について説明します。

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

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

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

- 開始ポイント

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

次の各項では、記憶域レプリケーションを使用してスタンバイ管理サービスを実装するときに考慮する必要があるネットワークに関する事項について説明します。

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

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

各サイトに複数のOMSがある場合、プライマリおよびスタンバイの両方のサイトに自身のサーバー・ロード・バランサが必要です。「ロード・バランサの構成」を参照してください。各サイト上のSLBプールは、それぞれのOMSホストのIPアドレスを参照します。

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

Cloud Controlクライアント(エージェントおよびユーザー)がCloud Controlにアクセスするためのホスト名が必要です。プライマリ・サイトがアクティブなとき、このホスト名は、プライマリ・サイトSLBによってホストされるIPアドレスに解決されるようにDNSで構成する必要があります。スタンバイ・サイトがアクティブ化されているとき、ホスト名がスタンバイ・サイトSLBによってホストされるIPアドレスに解決されるように、DNSエントリを更新する必要があります。

各サイトで複数のOMSとSLBを使用する場合の、Cloud Controlアプリケーション・ホスト名のDNS構成の例を次の表に示します。

表20-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リクエストが増加する可能性があります。

20.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ソフトウェア所有者ユーザーに、マウントされたディレクトリへの読取りおよび書込みアクセス権があることを確認してください。

例: 次の表に構成例を示します。

表20-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が構成されている場合)

VOLAOM1

oms1-p.example.com

/u01/app/oracle /AOM;

Always-On Monitoring

VOLAOM2

oms2-p.example.com

/u01/app/oracle/AOM

Always-On Monitoring

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

この項では、障害時リカバリに対するリポジトリ・データベースの設定に関する推奨事項と考慮事項を説明します。

- 本番サイトとスタンバイ・サイトの両方にReal Application Clusterデータベースを作成することをお薦めします。

- 使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、これが正しく特定されていることを確認してください。

- ブローカ操作時にインスタンスを再起動するようにData Guardを有効にするには、特定の名前のサービスを、各インスタンスのローカル・リスナーに静的に登録する必要があります。

- リポジトリ・データベースのスイッチオーバーおよびフェイルオーバーの操作に対してdgmgrlを最大限に効率的に使用できるようにするには、すべてのプライマリ・リポジトリ・データベースおよびスタンバイ・リポジトリ・データベースのTNS別名を、tnsnames.ora内の各データベース・インスタンスのORACLE_HOMEの下に追加する必要があります。

- 中間層の同期が実行された場合は必ず、Data Guardでデータベースの手動同期を強制的に実行することを強くお薦めします。これは特に、メタデータ・リポジトリに構成データを格納するコンポーネントに該当します。

- 20.2.3.1項「接続記述子に関する考慮事項」に説明されている推奨事項に基づいて接続記述子を選択した後、プライマリ・サイトで各OMSに対して次のコマンドを実行して、接続記述子を構成します。

emctl config oms -store_repos_details -repos_conndesc <connect descriptor> -repos_user <username>

次の使用例は、20.2.3.1項に記載されている接続記述子の推奨事項に従ったものです。

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

20.2.3.1 接続記述子に関する考慮事項

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 12、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))))

20.2.4 開始ポイント

スタンバイ・サイトを設定する前に、管理者はプロジェクトの開始ポイントを評価する必要があります。通常、Enterprise Manager Cloud Control障害時リカバリ・トポロジを設計する際の開始ポイントは次のいずれかです。

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

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

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

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

開始ポイントが既存のプライマリ・サイトである場合、プライマリ・サイトのOMSインストールがファイルシステムにすでに存在します。また、ホスト名、ポートおよびユーザー・アカウントもすでに定義されています。サイトを変換し障害時リカバリ・トポロジ用に準備するために、次のプロシージャを使用する必要があります。

1. ネットワークに関する考慮事項を確認し、ホスト名を計画します
オプション1を使用する場合、プライマリ・サイトでのホスト名変更は必要ありません。適切な別名ホスト名を追加することによって、スタンバイ・サイト・ホストを準備します。

オプション2を使用する場合、OMSホスト名を変更して、既存のOMSインストールを移動し別名ホスト名を使用するようにします。適切な別名ホスト名を追加することによって、スタンバイ・サイト・ホストを準備します。

2. 記憶域に関する考慮事項を確認し、OMSインストールを共有記憶域に移動します
プライマリ・サイトを共有記憶域に移行します。「共有記憶域への既存のサイトの移行」を参照してください。

3. データベースに関する考慮事項を確認し、リポジトリ・ホスト名および接続記述子を計画します
シームレスなフェイルオーバー/スイッチオーバーを実現するために、リポジトリ・データベースのホスト名別名を使用するかどうか考えてください。その場合、リポジトリ・データベースを移行して別名ホスト名を使用します。

4. プライマリ・サイトの準備ができたので、「管理リポジトリの障害時リカバリの設定」および「OMS、BI Publisher共有記憶域およびソフトウェア・ライブラリの障害時リカバリの設定」のプロシージャを使用してDR設定を完了します。

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

1. スタンバイOMSの削除プロシージャを使用して、スタンバイOMSを削除します。『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』の追加のスタンバイOMSインスタンスの削除に関する説明を参照してください。

2. 「プライマリ・サイトがすでに作成されており、スタンバイ・サイトが計画中です」に記載されているプロシージャを使用します。

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

新しいプライマリ・サイトを(既存のプライマリ・サイトは使用せずに)設計している場合、ソフトウェアのインストールを開始する前にサイト計画を実行できるため容易です。

1. ネットワークに関する考慮事項を確認し、ホスト名を計画します。

2. 記憶域に関する考慮事項を確認し、記憶域ボリュームを準備します。

3. データベースに関する考慮事項を確認し、リポジトリ・ホスト名を準備します。

4. 第19章「Enterprise Managerの高可用性」に記載されている手順を使用して、正しいホスト名を使用して共有記憶域にインストールすることに注意して、プライマリ・サイトのインストールを実行します。

5. プライマリ・サイトの準備ができたので、次の項のプロシージャを使用してDR設定を完了します。

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

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

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

管理リポジトリでは、障害時リカバリ・ソリューションとしてData Guardを使用する必要があります。

20.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に変換します。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」ページで ログ切替え ボタンをクリックしてログを切り替え、切替えが受け入れられてスタンバイ・データベースに適用されていることを検証します。

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

Cloud Controlデプロイメントに対する障害時リカバリ・ソリューションには、レプリケートされたファイルシステムでのソフトウェア・ライブラリ、OMSインストール、エージェント・インストールおよびOracleインベントリのインストールが含まれます。このソリューションには、BI Publisher共有記憶域の構成が含まれることもあります。

スタンバイWebLogicドメインを使用して実装されたスタンバイOMSはまだサポートされていますが、非推奨になっており、将来のリリースでサポートされない可能性があります(詳細はMy Oracle Supportノート1563541.1を参照してください)。この章に記載されているように、記憶域レプリケーションを使用してスタンバイOMSを作成する方法をお薦めします。

記憶域レプリケーションの要件

選択した記憶域レプリケーションの方法で、次がサポートされている必要があります。

- スナップショットおよび一貫性のあるファイルシステム・コピー

- サイト間でのオンデマンド・レプリケーションを実行する機能

20.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アドバンスト・インストレーションおよび構成ガイド』を参照してください。

20.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フラグを渡すことができるようになります。

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

1. ソフトウェア・ライブラリは記憶域レプリケーションを使用してレプリケートされるファイルシステムにある必要があります。ソフトウェア・ライブラリが現在別のファイルシステムにある場合、ソフトウェア・ライブラリ管理ページの「移行と削除」オプションを使用して移行することはできません。
詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』のソフトウェア・ライブラリの構成に関する説明を参照してください。

2. 記憶域レプリケーション・スケジュールを、ネットワーク・インフラストラクチャに許可されるできるかぎり頻繁な値に構成します。2時間ごとに発生する連続レプリケーションをお薦めします(最小)。

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

BI Publisherが構成されている場合、BI Publisherの共有記憶域も障害時リカバリ・シナリオに含める必要があります。

1. BI Publisher共有記憶域の場所は、記憶域レプリケーションを使用してレプリケートされるファイルシステム上である必要があります。

2. 記憶域レプリケーション・スケジュールを、ネットワーク・インフラストラクチャに許可されるできるかぎり頻繁な値に構成します。2時間ごとに発生する連続レプリケーションをお薦めします(最小)。

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

注意:
既存の環境の高可用性ソリューションのレベル4を使用する場合でも、既存のサイトから共有記憶域ファイル・システムに移行できます。

- ファイルシステム・バックアップを使用して、既存のOMSおよびエージェント・インストールを共有記憶域に移動します。

- 次のガイドラインを使用して、ローカル・ファイルシステムから共有記憶域に移行します

- すべてのバックアップはオフライン・バックアップである必要があり、つまり、バックアップおよびリストアの前にホスト上のOMSおよびエージェント・プロセスの停止を完了する必要があります。

- ルート・ユーザーとしてバックアップを実行する必要があり、その権限を保持している必要があります。

- Middlewareホームおよびインスタンス・ホームのディレクトリ・パスは変更しないでください。

- Cloud Controlが完全に停止することを回避するため、移行はローリング方式で実行できます。

- 「ソフトウェア・ライブラリの記憶域の場所の削除(および移行)」で説明するプロセスを使用して、ソフトウェア・ライブラリを共有記憶域に移動します。

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

20.5.1 スイッチオーバーの手順

この項では、スタンバイ・サイトへのスイッチオーバーの手順について説明します。どの方向にスイッチオーバーする場合も同じ手順が適用されます。

1. プライマリ・サイトですべてのOMSコンポーネントを停止します。

2. プライマリ・サイトですべての仮想管理エージェントを停止します。

3. 各OMSのAlways-On Monitoringサービスを停止します。
<AOM location>/scripts/emsctl stop

4. プライマリ・サイトでOMSホストからOMSファイルシステムおよびソフトウェア・ライブラリ・ファイルシステムをアンマウントします。
構成されている場合は、BIP共有記憶域およびAOM記憶域のファイルシステムをアンマウントします。

5. OMSおよびソフトウェア・ライブラリ・ファイルシステムのオンデマンド・レプリケーションを実行します。

注意:
オンデマンド・レプリケーションの実行に必要な手順は、記憶域のドキュメントを参照してください。

6. アプリケーションの仮想ホスト名に対するDNSエントリを更新します。

7. Data Guardスイッチオーバーを使用してOracle Databaseをスイッチオーバーします。
DGMGRLを使用してスタンバイ・データベースへのスイッチオーバーを実行します。このコマンドはプライマリ・サイトでもスタンバイ・サイトでも実行できます。スイッチオーバー・コマンドは、プライマリ・データベースおよびスタンバイ・データベースの状態を検証し、ロールのスイッチオーバーに影響を与えます。古いプライマリ・データベースを再起動して新しいスタンバイ・データベースとして設定します。

SWITCHOVER TO <standby database name>;

スイッチオーバー後の状態を検証します。スタンバイ・データベースを完全に監視するには、データベースを監視するユーザーにSYSDBA権限が必要です。スタンバイ・データベースはマウント専用状態であるため、この権限が必要になります。プライマリ・データベースとスタンバイ・データベースを監視するユーザーに両方のデータベースのSYSDBA権限があればベスト・プラクティスになります。

SHOW CONFIGURATION;

SHOW DATABASE <primary database name>;

SHOW DATABASE <standby database name>;

8. ソフトウェア・ライブラリおよびOMS記憶域のロール・リバーサルを実行します(手順については、記憶域のドキュメントを参照してください)。

9. SWLIBおよびOMS記憶域のレプリケーション・スケジュールを再び有効化します。
BI PublisherとAOMが構成されている場合、BI Publisher共有記憶域とAOM記憶域の場所のレプリケーション・スケジュールを再び有効化します。

10. スタンバイ・サイトのOMSホストにOMS、AOM (構成されている場合)およびソフトウェア・ライブラリ・ファイルシステムをマウントします。
BI Publisherが構成されている場合、BI Publisherの共有記憶域のファイルシステムをスタンバイ・サイトのOMSホストにマウントします。

11. スタンバイ・サイトで最初のOMS管理サーバーを起動します。

注意:
20.2.3項「データベースに関する考慮事項」で説明したように、SCANアドレスおよびロールベースのデータベース・サービスを使用するなどしてプライマリ・サイトとスタンバイ・サイトの両方で機能する接続文字列を使用している場合、この手順は必要ありません。

12. 次のコマンドを使用して、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

注意:
20.2.3項「データベースに関する考慮事項」で説明したように、SCANアドレスおよびロールベースのデータベース・サービスを使用するなどしてプライマリ・サイトとスタンバイ・サイトの両方で機能する接続文字列を使用している場合、この手順は必要ありません。

各OMSでこの手順を繰り返します。

13. 次のコマンドを使用して、AOMを新しいプライマリ・リポジトリ・データベースに向けます。

emsctl set_ems_repos_conn -username=<repository username> -password=<repository password> -connect_string=<repository connect descriptor>

注意: AOM接続情報の変更は、ローカルのAOMインスタンスにのみ適用されます。変更内容を反映させるには、このコマンドを各AOMインスタンスで実行する必要があります。

14. スタンバイ・サイトでOMSおよびAOM (構成されている場合)を起動します。

15. 次のコマンドを使用してスタンバイ・サイトで管理エージェントを起動します。

emctl start agent

16. 次のコマンドを使用して管理サービスおよびリポジトリ・ターゲットを再配置します。

emctl config emrep -agent <agent name> -conn_desc <repository connection>

管理サービスと管理リポジトリ・ターゲットは、プライマリ・サイトのいずれかの管理サービス上の管理エージェントで監視されます。スイッチオーバー/フェイルオーバー後にターゲットが監視されるようにするには、スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行して、そのターゲットをスタンバイ・サイトの管理サービスに再配置します。

注意:
次の2つの条件が満たされる場合、この手順は必要ありません。

- SCANアドレスとロールベース・データベース・サービスを使用した場合のように、プライマリ・サイトとスタンバイ・サイトの両方で機能するリポジトリ接続記述子を使用しているときこの状況では、管理サービスおよび管理リポジトリのターゲットを監視するために接続記述子を更新する必要はありません。

- 管理サービスおよび管理リポジトリのターゲットは、別名ホスト名を使用してレプリケート済記憶域にインストールされた管理エージェントによって監視されます。この状況では、同じエージェントがスタンバイ・サイトで実行されることになるため、別のエージェントを構成する必要はありません。

17. Cloud Control内からWebLogic管理コンソールのURIを更新します。
GCDomainのターゲット・ホームページに移動します。「WebLogicドメイン」メニューから「ターゲット設定」、「監視構成」の順に選択します。

20.5.2 フェイルオーバーの手順

この項では、スタンバイ・サイトにフェイルオーバーして、Enterprise Managerのアプリケーション状態をリカバリする手順について説明します。これは、管理リポジトリ・データベースをすべての管理エージェントと再同期化し、元のプライマリ・データベースを最後に有効にすることで行います。

1. プライマリ・サイトでOMSコンポーネントが実行中である場合はすべて停止します。

2. プライマリ・サイトで仮想エージェントが実行中である場合はすべて停止します。

3. すべてのAOMインスタンスを停止します(構成されている場合)。

4. プライマリ・サイトのOMSホストからOMSおよびソフトウェア・ライブラリ・ファイルシステムをアンマウントします。
BI Publisherが構成されている場合、BI Publisherの共有記憶域のファイルシステムをプライマリ・サイトのOMSホストからアンマウントします。

AOMが構成されている場合は、AOM記憶域のファイルシステムをアンマウントします。

5. OMSおよびソフトウェア・ライブラリ・ファイルシステムのオンデマンド・レプリケーションを実行します。(発生した障害の種類によって、実行できないこともあります。)BI Publisherが構成されている場合、BI Publisher共有記憶域のファイルシステムのオンデマンド・レプリケーションを実行します。AOMが構成されている場合、AOM記憶域のファイルシステムのオンデマンド・レプリケーションを実行します。

注意:
オンデマンド・レプリケーションの実行に必要な手順は、記憶域のドキュメントを参照してください。

6. アプリケーションの仮想ホスト名に対するDNSエントリを更新します。

7. Data Guardフェイルオーバーを使用してOracle Databaseをフェイルオーバーします。

8. ソフトウェア・ライブラリおよびOMS記憶域のロール・リバーサルを実行します。

9. SWLIBおよびOMS記憶域のレプリケーション・スケジュールを再び有効化します

10. スタンバイ・サイトのOMSホストにOMSおよびソフトウェア・ライブラリ・ファイルシステムをマウントします

11. 最初のOMS管理サーバーを起動します。

注意:
次の2つの条件が満たされる場合、この手順は必要ありません。

1. SCANアドレスとロールベース・データベース・サービスを使用した場合のように、プライマリ・サイトとスタンバイ・サイトの両方で機能するリポジトリ接続記述子を使用しているとき

2. Data Guardの最大保護または最大可用性レベルで実行しており、フェイルオーバーでデータ損失が発生しない場合

12. 新しいプライマリ・リポジトリ・データベースを指すように、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でこの手順を繰り返します。

13. 新しいプライマリ・リポジトリ・データベースを指すように、AOM接続記述子を変更します。

emsctl set_ems_repos_conn -username=<repository username> -password=<repository password> -connect_string=<repository connect descriptor>

AOM接続情報の変更は、ローカルのAOMインスタンスにのみ適用されます。

変更内容を反映させるには、このコマンドを各AOMインスタンスで実行する必要があります。

14. リポジトリの再同期化を実行して、エージェントを新しいプライマリ・データベースと再同期化します。
Data Guardの最大保護または最大可用性レベルで実行している場合、フェイルオーバーでのデータ損失はないため、この手順を省略します。ただし、データ損失がある場合は、新しいプライマリ・データベースとすべての管理エージェントを同期化します。

スタンバイ・サイトのいずれかの管理サービスで次のコマンドを実行します。

emctl resync repos -full -name "<name for recovery action>"

このコマンドは、スタンバイ・サイトの管理サービスの起動時に各管理エージェントで実行される再同期化ジョブを発行します。

15. スタンバイ・サイトでエージェントを起動します。

16. スタンバイ・サイトでOMSを起動します。

17. スタンバイ・サイトでAOMインスタンスを起動します。

18. 管理サービスと管理リポジトリ・ターゲットの接続記述子を変更します。
「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。管理サービスとリポジトリ・ページが表示されます。「OMS and Repository」メニューから、「ターゲット設定」を選択し、次に「監視構成」を選択します。

リポジトリ接続記述子を変更して、現在アクティブなデータベースに接続する必要があります。

注意:
SCANアドレスとロールベース・データベース・サービスを使用した場合のように、プライマリ・サイトとスタンバイ・サイトの両方で機能するリポジトリ接続記述子を使用しているときは、この手順は必要ありません。

19. Cloud Control内からWebLogic管理コンソールのURIを更新します。
GCDomainのターゲット・ホームページに移動します。「WebLogicドメイン」メニューから「ターゲット設定」、「監視構成」の順に選択します。

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

Data Guardと記憶域レプリケーションの組合せによって、スタンバイ・サイトのプライマリとの同期は自動的に維持されます。

OMSまたはエージェントで次の操作が行われた前後に、スタンバイ・サイトへのオンデマンド・レプリケーションが実行されることを管理者は確認する必要があります。

- プラグインのデプロイメント/アンデプロイ、または既存のプラグインのアップグレード

- アップグレード

- パッチ

- emctlコマンド(ライフサイクル動詞(start/stop/status oms)以外)

- ADP/JVMD/BI Publisherの構成

注意:
オンデマンド・レプリケーションの実行に必要な手順は、記憶域のドキュメントを参照してください。

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

エコシステムの監視および管理フレームワークと同様に、高可用性計画の重要な部分は、Enterprise Managerの定期的なバックアップを確実に行い、障害発生時のリストアを可能にすることです。

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

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

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

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

- Oracle Management Serviceのバックアップ

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

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

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

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

Enterprise Managerは単一のエンティティとして機能しますが、技術的には、次のソフトウェア・コンポーネントで構成される分散型の多層ソフトウェア・アーキテクチャで構築されています。

- Oracle Management Services(OMS)

- 管理エージェント

- 管理リポジトリ

- ソフトウェア・ライブラリ

各コンポーネントは、構成と機能がそれぞれ異なり、バックアップとリカバリに対して異なるアプローチを必要とします。このため、バックアップ戦略について、この章では層別に説明します。Enterprise Managerアーキテクチャの概要については、『Oracle® Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

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

ソフトウェア・ライブラリは、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなどのEnterprise Managerソフトウェア・エンティティの集中メディア記憶域です。ソフトウェア・ライブラリはEnterprise Managerフレームワークの不可欠な部分であり、多くのEnterprise Manager機能が適切に機能するために必須です。ソフトウェア・ライブラリの記憶域の場所は、ファイルシステム・バックアップを使用して定期的にバックアップする必要があります。1時間から24時間の頻度でバックアップを実行することをお薦めします。

21.3 管理リポジトリのバックアップ

管理リポジトリは、管理エージェントにより収集されたすべての情報が保管される記憶域です。データベース・ジョブ、パッケージ、プロシージャ、ビューおよび表領域などのオブジェクトで構成されます。これはOracle Databaseで構成されるため、管理リポジトリのバックアップおよびリカバリ戦略は、基本的にはOracle Databaseの戦略と同じになります。データベースのバックアップ・プロシージャは、十分に確立した標準であり、RMANバックアップ・ユーティリティを使用して実装でき、このユーティリティにはCloud Controlコンソールからアクセスできます。

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

管理リポジトリ・データベースの計画外の停止を回避するために、高可用性のベスト・プラクティスを使用することをお薦めします。このためには、次の標準のデータベース・バックアップ戦略を使用します。

- データベースはarchivelogモードにします。リポジトリ・データベースをarchivelogモードで実行しないと、メディア障害後のリカバリ不能な状況でデータベースが脆弱なままになります。

- Cloud Controlコンソールを介して推奨バックアップ戦略オプションを使用し、RMANによる通常のホット・バックアップを実行します。他のユーティリティ(例: DataGuardやRAC)も、一般的にHAレベル3または4で実装される包括的なHAおよびデータ保護の計画の一部として利用できます。様々なHAレベルの詳細は、第18章の「高可用性レベルの実装」を参照してください。

これらの戦略に従うと、全体バックアップが作成された後、以降は毎回増分バックアップが作成されます。増分の変更はベースラインにロールアップされ、新しい全体バックアップ・ベースラインが作成されます。

推奨バックアップ戦略を使用すると、Enterprise Managerのバックアップ実行機能も利用でき、ジョブはEnterprise Managerのジョブ・サブシステムを通じて自動的にスケジュールされます。これで、バックアップの履歴がレビューで使用可能になり、バックアップのステータスがリポジトリ・データベース・ターゲットのホームページで表示されます。このバックアップ・ジョブとアーカイブおよびフラッシュバック・テクノロジを併用すると、リポジトリのいずれかの部分が失われた場合のリストア・ポイントが得られます。このタイプのバックアップ処理およびアーカイブ・ログとオンライン・ログにより、リポジトリを最後に完了したトランザクションまでリカバリできます。

最後のリポジトリのバックアップが発生した時間を「リポジトリの詳細」セクションの「管理サービスとリポジトリ概要」ページで表示できます。

Enterprise Managerを使用したバックアップの構成方法のサマリーは、『Oracle Database 2日でデータベース管理者』を参照してください。データベースの高可用性に関するベスト・プラクティスの付加情報は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

21.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でのみ実行)により、インスタンス・ホームと同時にバックアップされます。

21.5 管理エージェントのバックアップ

管理エージェントは、監視対象の各ホストにデプロイされている統合ソフトウェア・コンポーネントです。これらのホスト上で実行されているすべてのターゲットの監視、中間層のOMSへのこの監視情報の伝達、ホストおよびそのターゲットの管理およびメンテナンスを行います。

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

管理エージェントのバックアップに関する特別な考慮事項はありません。ベスト・プラクティスとしては、管理エージェントの参照インストールを異なるプラットフォームに対して保持し、emd.propertiesファイルで実行済のカスタマイズと適用済のパッチが最新の状態に保たれるようにします。参照エージェント・インストールのインストールおよび保持には、Cloud Controlコンソールのデプロイメント・オプションを使用します。

管理エージェントが失われた場合、参照インストールからクローニングして再インストールする必要があります。

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

Enterprise Managerのリカバリは、Enterprise Managerアーキテクチャの3つの基本的なコンポーネントのリストアを意味します。

- 管理リポジトリ

- 管理サービス

- 管理エージェント

- ソフトウェア・ライブラリ

21.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コンソールのリポジトリの再同期化ページからリポジトリの再同期化の進行状況を監視します。

図21-1 「リポジトリの同期化」ページ

管理リポジトリのリカバリが完了するのは、再同期化ジョブがすべての管理エージェントで完了したときです。

障害発生時にデータベースを最新のトランザクションまでリカバリできるように、管理リポジトリ・データベースをarchivelogモードで実行することをお薦めします。データベースを最後のトランザクションまでリカバリできない場合は、リポジトリの同期化を使用して、最後のバックアップの作成時に存在していたターゲットの監視機能をリストアできます。バックアップ後に行ったアクションは、自動的にはリカバリされません。リポジトリの同期化で自動的にリカバリされないアクションの例は次のとおりです。

- インシデント・ルール

- 優先資格証明

- グループ、サービス、システム

- ジョブ/デプロイメント手順

- カスタム・レポート

- 新しいエージェント

21.6.2 リカバリ・シナリオ

リポジトリ(または任意のデータベース)をリカバリする前提条件は、リポジトリの有効な一貫性バックアップがあることです。Enterprise Managerを使用してバックアップ・プロセスを自動化すると、リポジトリのリカバリが必要になった場合に備えて、通常の最新バックアップが常に用意されます。Recovery Manager(RMAN)は、Oracle Databaseのバックアップ、リストアおよびリカバリを行うユーティリティです。RMANのリカバリ・ジョブの構文は、安全な場所に保存する必要があります。これにより、Enterprise Managerリポジトリ・データベースの完全リカバリを実行できます。最も単純な形式では、構文は次のようになります。

run {
restore database;
recover database;
}

実際の構文は、環境によって長さや複雑さが異なります。構文をRMANのバックアップおよびリカバリ・ジョブから抽出する方法、またはRMANの一般的な使用方法は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

次の各シナリオでは、様々なリポジトリのリカバリ状況とそのリカバリ手順を示します。

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

リポジトリ・データベースはarchivelogモードで実行されています。最近のバックアップ、アーカイブ・ログ・ファイルおよびREDOログがあります。リカバリ・データベース・ディスクがクラッシュしました。すべてのデータファイルと制御ファイルが失われました。

解決方法:

1. emctl stop oms -allを使用して、すべてのOMSインスタンスを停止します。

2. RMANを使用してデータベースをリカバリします。

3. すべてのOMSインスタンスでコマンドemctl start omsを使用してサイトを起動します。

4. サイトが完全に動作していることを確認します。

21.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. サイトが完全に動作していることを確認します。

21.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. サイトが完全に動作していることを確認します。

21.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. サイトが完全に動作していることを確認します。

21.6.3 OMSのリカバリ

Oracle Management Serviceのインスタンスが失われた場合、OMSのリカバリは基本的に、ソフトウェア・ホームのリカバリ、インスタンス・ホームの構成、およびソフトウェア・ライブラリがEnterprise Managerと同じホストで構成されている場合はソフトウェア・ライブラリのリカバリという3つの手順で構成されます。

21.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)を、ダウンロードしたプラグインの保存先ディレクトリへのパスを指定するPLUGIN_LOCATION=<プラグイン・ディレクトリへの絶対パス>を使用して、実行する必要があります。プラグインの選択を求められたら、必ずSQL問合せにリストされたプラグインと同じプラグインを選択してください。

注意:
すべての必要なプラグインがインストールされていない場合、リカバリは失敗します。

ソフトウェア専用モードの後で、クラッシュの前にインストールされたすべてのパッチを再度適用する必要があります。管理リポジトリが損傷していないと仮定した場合、リポジトリに対してSQLを実行する後処理スクリプトは、リポジトリにはそのようなパッチを適用済なので省略できます。

前述のように、OMS Oracleホームの場所は修正されるため、変更できません。そのため、以前に使用された場所でOMS Oracleホームをリストアするようにします。

21.6.3.2 OMSの再作成

ソフトウェア・ホームをリカバリすると、インスタンス・ホームはリカバリ・モードでomscaコマンドを使用して再構築できます。

omsca recover –as –ms -nostart –backup_file <exportconfig file>

次の項で示すemctl exportconfigコマンドで生成されるエクスポート・ファイルを使用します。

21.6.4 OMSのリカバリ・シナリオ

次の各シナリオでは、OMSの様々なリカバリ状況とそのリカバリ手順を示します。

重要:
OMSリカバリの前提条件は、最近の有効なOMS構成バックアップがあることです。OMS構成が変更されるたびに、emctl exportconfig omsコマンドを使用してOMSをバックアップすることをお薦めします。このコマンドは、WebLogic AdminServerを実行するプライマリOMSで実行する必要があります。
または、Enterprise Managerのジョブ・システムを使用して、このコマンドを定期的に実行できます。

次の各シナリオでは、ファイルシステムのバックアップ(使用可能な場合および同じホストへのリカバリの場合のみ)を使用、またはインストーラのソフトウェア専用オプションを使用したソフトウェア・ホームのリカバリについて示します。いずれの場合も、ベスト・プラクティスはファイルシステムのバックアップからではなく、omsca recoverコマンドを使用したインスタンス・ホーム(gc_inst)をリカバリすることです。これにより、インスタンス・ホームが有効で、最新であることが保証されます。

21.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. ソフトウェア・ホームをリストアします。詳細は、第21.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コマンドから生成された最新ファイルにしてください。

重要:
BIPが最初のOMSで構成された場合、次のポートも渡す必要があます。そうしないと、リカバリは失敗します。
次に例を示します。

<OMS_HOME>/bin/omsca recover -as -ms -nostart -backup_file /scratch/emga/opf_ADMIN_20151105_022311.bka -EM_BIP_PORT 9701 -EM_BIP_HTTPS_PORT 9803 -EM_BIP_OHS_PORT 9788 -EM_BIP_OHS_HTTPS_PORT 9851

5. OMSを開始します。

OMS_HOME/bin/emctl start oms

6. エージェントをリカバリします(必要な場合)。
管理エージェント・ソフトウェア・ホームがOMSソフトウェア・ホームとともにリカバリされた場合、管理エージェントと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. サイトが完全に動作していることを確認します。

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

サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。

解決方法:

1. ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。
注意: 構成されている場合、すべてのBIP共有場所(sharedLoc)にアクセスできることも必要です。

2. ホストBにソフトウェア・ホームをリストアします。詳細は、第21.6.3.1項「ソフトウェア・ホームのリカバリ」を参照してください。

3. 以前に取得されたエクスポート・ファイルを指定してomscaをリカバリ・モードで実行し、OMSを構成します。

<OMS_HOME>/bin/omsca recover –as –ms –nostart –backup_file <exportconfig file>

注意:
渡される-backup_fileは、emctl exportconfig omsコマンドから生成された最新ファイルにしてください。

重要:
BIPが最初のOMSで構成された場合、次のポートも渡す必要があます。そうしないと、リカバリは失敗します。
次に例を示します。

<OMS_HOME>/bin/omsca recover -as -ms -nostart -backup_file /scratch/emga/opf_ADMIN_20151105_022311.bka -EM_BIP_PORT 9701 -EM_BIP_HTTPS_PORT 9803 -EM_BIP_OHS_PORT 9788 -EM_BIP_OHS_HTTPS_PORT 9851

4. OMSを開始します。

<OMS_HOME>/bin/emctl start oms

エージェントはソフトウェア専用インストールの一部としてインストールされ、agentDeploy.shコマンドを使用して構成される必要があります。

5. エージェントを構成します。

<AGENT_BASE_DIR>/core/13.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>

管理エージェント構成が失敗した場合は、<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. サイトが完全に動作していることを確認します。

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

サイトは単一OMSをホストします。OMSはホストA上で実行されています。SLBはありません。OMS構成はemctl exportconfig omsコマンドを使用してバックアップされました。ホストAが失われました。リカバリはホストBで実行されますが、ホスト名Aはそのまま使用されます。

解決方法:

1. ソフトウェア・ライブラリの場所にホストBからアクセスできることを確認します。

2. ホストBにソフトウェア・ホームをリストアします。詳細は、第21.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. サイトが完全に動作していることを確認します。

21.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. ソフトウェア・ホームをリストアします。詳細は、第21.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. サイトが完全に動作していることを確認します。

21.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にソフトウェア・ホームをリストアします。詳細は、第21.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. サイトが完全に動作していることを確認します。

21.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. サイトが完全に動作していることを確認します。

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

ソフトウェア・ライブラリが失われた場合、使用可能な最後のバックアップからリストアする必要があります。バックアップをリストアした後、不足しているエンティティを検証および再インポートするために次のコマンドを実行する必要があります。

1. emcli verify_swlib - このコマンドは、ソフトウェア・ライブラリの記憶域の場所へのアクセシビリティを検証し、エンティティにファイルシステムのファイルがない場合には報告します。

2. emcli reimport_swlib_metadata - このコマンドは、製品とともに出荷されたオラクル社提供のすべてのエンティティを再インポートします。最新のバックアップがある場合、これは必要ありません。emcli verify_swlibコマンドによって、Oracle所有エンティティのファイルがファイルシステムからなくなっていることが報告された場合、emcli reimport_swlib_metadataを実行します。

3. emcli verify_updates - このコマンドは、自己更新によってダウンロードされたエンティティがソフトウェア・ライブラリからなくなっているかどうかを検証します。不足している各エンティティについて、ソフトウェア・ライブラリに再インポートする手順もコマンドによって表示されます。

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

管理エージェントが失われた場合、参照インストールからクローニングして再インストールする必要があります。通常、参照インストールからのクローニングは、カスタマイズおよびパッチの追跡および再適用が不要なため、管理エージェント・インストールをリカバリする最速の方法です。同一ポートを使用して管理エージェントを再インストールする場合は、注意が必要です。Enterprise Managerの管理エージェントの再同期化機能を使用すると、再インストールされた管理エージェントを、管理リポジトリに存在するターゲット情報を使用して再構成できます。

注意:
管理エージェントの再同期化は、Enterprise Managerのスーパー管理者のみが実行できます。

同一ポートを使用して管理エージェントを再インストールする場合、OMSは、再インストールであることを検出し、以前に行われたカスタマイズが再インストールされる管理エージェント内の自動検出ターゲットによって上書きされるのを防ぐため、管理エージェントを一時的にブロックします。

ブロックされた管理エージェント:
これは、ブロックされた管理エージェントからのすべてのハートビートまたはアップロード・リクエストをOMSが拒否している状態です。このため、ブロックされたエージェントは、アラートまたはメトリック・データをOMSにアップロードできません。ただし、ブロックされた管理エージェントは、監視データの収集は続行します。
エージェントは、複数ある条件のいずれかが原因でブロックされることがあります。これらを次に示します。

- Enterprise Managerが、エージェントがバックアップからリストアされたことを検出しました。

- エージェント上のプラグインが、管理リポジトリの記録と一致しません。

- ユーザーが手動でエージェントをブロックしました。

最初の2つの条件では、エージェントの状態を消去し管理リポジトリからプラグインをプッシュして、エージェントのブロックを解除するために、エージェントの再同期化が必要になります。

emcli resyncAgent <agent target name>コマンドを使用すると、管理エージェントのホームページで管理エージェントを再同期化およびブロック解除できます。再同期化は、管理リポジトリから管理エージェントにすべてのターゲットをプッシュして、エージェントのブロックを解除します。

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

次の各シナリオでは、様々な管理エージェントのリカバリ状況とそのリカバリ手順を示します。管理エージェントの再同期化機能では、再インストールした管理エージェントは、クラッシュした、前の管理エージェントと同じポートを使用する必要があります。

注意:
管理エージェントの再同期化は、Enterprise Managerのスーパー管理者のみが実行できます。

21.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ファイルがないことを確認します。

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

単一の管理エージェントが複数のターゲットを監視しています。エージェントOracleホームのファイルシステム・バックアップがあります。エージェント・インストールが失われました。

1. 管理エージェントをファイルシステム・バックアップからリストアして、管理エージェントを起動します。
OMSによって、管理エージェントがバックアップからリストアされたことが検出され、管理エージェントがブロックされます。

2. 次のコマンドを使用して、管理エージェントの再同期化を開始します。
emcli resyncAgent -agent="Agent Host:Port"

管理リポジトリのすべてのターゲットが新しい管理エージェントにプッシュされます。エージェントはバックログ・ファイルのクリアを指示されるため、クリア状態にします。管理エージェントはブロック解除されます。

3. 次のemctlコマンドを使用して、管理エージェントが機能しており、すべてのターゲット構成がリストアされたことを確認します。

emctl status agent
emctl upload agent

エラーがなく、バックログにXMLファイルがないことを確認します。

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

OMSと管理リポジトリの両方に障害が同時に発生した場合は、両方のリカバリを同一または別のホスト上で行う必要があるかどうか、複数のOMSインスタンスの前にSLBがあるかどうかなどの要因に応じて、リカバリ状況がより複雑になります。一般に、このタイプの複合障害のリカバリでは、前述の該当するリカバリ・シナリオで説明されている手順に従い、まず管理リポジトリを、次にOMSインスタンスをリカバリします。次の各シナリオでは、OMSと管理リポジトリの2つの障害と、それに必要なリカバリ手順を示します。

21.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. 第21.6.4.1項「単一OMS、サーバー・ロード・バランサ(SLB)なし、OMSを同一ホスト上でリストア」に示すOMSリカバリ手順に従います。

3. サイトが完全に動作していることを確認します。

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

管理リポジトリ、プライマリOMSおよび追加OMSはすべて、異なるホスト上にあります。管理リポジトリ・データベースは、ホストAでnoarchivelogモードで実行中でした。最新のバックアップのOMSバックアップ・ファイルがあります(emctl exportconfig oms)。データベースの全体コールド・バックアップがあります。3つのホストすべてが失われました。

1. 第21.6.2.2項「同一ホスト上の不完全リカバリ」に示す管理リポジトリのリカバリ手順に従いますが、次の点が異なります。
OMS Oracleホームが使用できず、リストアした管理リポジトリに対してOMSを起動する前に管理リポジトリの再同期化を開始する必要があるため、PL/SQLブロックで「resync」を発行します。SQLplusを使用して管理リポジトリにSYSMANでログインし、次のコマンドを実行します。

begin emd_maintenance.full_repository_resync('resync name'); end;

2. 第21.6.4.5項「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示すOMSリカバリ手順に従いますが、次の点が異なります。
バックアップ・ファイルにある管理リポジトリ接続記述をオーバーライドするには、追加のomscaパラメータを渡します。

-REPOS_CONN_STR <restored repos descriptor>

第21.6.4.5項「複数OMS、サーバー・ロード・バランサ構成済、プライマリOMSを別のホスト上でリカバリ」に示す他のパラメータとともにこのパラメータを追加する必要があります。

3. 第21.6.4.6項「複数OMS、SLB構成済、追加OMSを同一または別のホスト上でリカバリ」に示すOMSリカバリ手順に従います。

4. サイトが完全に動作していることを確認します。

22 BI Publisherの高可用性

Enterprise Manager 13cリリース1 (13.1.0.0.0)以降では、Enterprise Managerを実行するすべてのシステムでBI Publisherが自動的に構成されます。詳細は、第16章「Enterprise ManagerでのBI Publisherの構成」を参照してください。

また、このリリースではBI Publisherの高可用性の完全なサポートが導入されています。この利点は次のとおりです。

任意のEnterprise Managerシステムで、常に次のいずれかの組合せを実行できます。

- OMS (JVMDを含む)およびBI Publisher。これはデフォルトの構成です。

- OMS (JVMDを含む)のみ

- BI Publisherのみ

- OMSもBI Publisherも含まない

Enterprise Managerで複数のOMSがサーバー・ロード・バランサの背面に構成されている場合、この意味は重要です。詳細は、Enterprise Managerアドバンスト・インストレーションおよび構成ガイドの「Enterprise Managerで使用するためのサーバー・ロード・バランサ」を参照してください。

継続操作の完全なサポート(操作ステータスに関係しない):

Enterprise Managerを実行する個々のシステムで、計画停止または計画外停止によりOMS、BI Publisherまたはシステム全体が停止した場合でも、Enterprise ManagerとBI Publisherは引き続き使用可能です。

操作のスケーラビリティの完全なサポート:

Enterprise Managerを実行するシステムのシステム構成(メモリー、CPU数、ディスク容量など)に依存します

重要:
以前のバージョンのEnterprise Managerでは、BI Publisherの高可用性はサポートされません。ただし、Enterprise Manager 12cリリース4 (12.1.0.4)およびEnterprise Manager 12cリリース5 (12.1.0.5)では複数のBI Publisherサーバーの実行がサポートされていました。しかしながら、これらのリリースでは前述した信頼性やスケーラビリティのためのオプションはありませんでした。

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

- BI Publisherの高可用性の概要

- 共有記憶域デバイスを使用するBI Publisherの手動構成

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

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

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

注意:
BI Publisherソフトウェアは、Enterprise Manager 12.1.0.4がインストールされているすべてのシステムに自動でインストールされます。この章では、このようなシステムでBI Publisherサーバーを構成する手順について説明します。

22.1 BI Publisherの高可用性の概要

BI Publisherの構成は現在のEnterprise Manager 13cリリース1 (13.1.0.0.0)では自動的に行われます。詳細は、第16章「Enterprise ManagerでのBI Publisherの構成」を参照してください。Enterprise Managerで使用した場合にBI Publisherの高可用性がサポートされるようになりました。

Enterprise Managerを最初にインストールすると(新規インストール時、または以前のリリースのEnterprise Managerのアップグレード時)、「最初の」BI Publisherサーバー「BIP」が構成されます。これをプライマリBI Publisherサーバーと呼びます。

注意:
BI Publisherの高可用性は、Microsoft WindowsプラットフォームのEnterprise Manager 13cリリース1 (13.1.0.0.0)ではサポートされません。

BI Publisherは、すべての構成データおよびレポート定義を、オペレーティング・システムのファイルシステム・ベースのリポジトリに格納します。このボリュームは構成ボリュームと呼ばれます。

追加の共有ファイルシステムが、WebLogic関連のスケジューリング・バイナリを格納するために使用されます。このボリュームはクラスタ・ボリュームと呼ばれます。

注意:
構成ボリュームについて適切で定期的なバックアップ戦略を定めることが重要です。これらのバックアップの間隔はBI Publisherの使用方法によって変わります。

BI Publisherの高可用性が機能するようにサポートするには、これらのファイルシステムに対する読取り/書込み権限をすべてのOMSシステムに提供する必要があります。これは、次の図に示す標準のネットワーク・ファイルシステム・テクノロジを使用して実現します。

この画面の詳細は、Enterprise Managerアドバンスト・インストレーションおよび構成ガイドの「Enterprise ManagerとBI Publisherの統合」の章を参照してください。

BI Publisherの高可用性では、BI Publisherの共有記憶域ファイルシステムでも高可用性を実現する必要があります。また、構成ボリューム・システムは、標準のオペレーティング・システム・コマンドまたは業務用のバックアップ・ソリューションを使用して、定期的に(毎日または毎時などの頻度で)バックアップする必要があります。また、構成ボリュームのためにRAID (Redundant Array of Inexpensive Drives)ストレージ・デバイスなどの高可用性ディスク・ソリューションを使用することを強くお薦めします。少なくともRAID 1 (冗長性)を使用してください。その他のRAIDレベル(RAID5、RAID0+1、RAID 10など)も使用できます。冗長性ではなく速度を目的としているため、RAID 0は使用できません。RAID 1そのものとバックアップ・ソリューションを混同しないでください。RAIDではディスク・ドライブ障害や他のファイルシステムの破損に対する保護が提供されますが、定期的なバックアップは必要です。構成ボリューム上に保存されているファイルを損失すると、すべてのBI Publisherサーバー(プライマリとセカンダリの両方)が機能しなくなります。さらに、カスタマイズ・レポート定義もすべて失われます。

注意:
行っているBI Publisherレポート開発のレベルに合った頻度で構成ボリュームをバックアップすることが非常に重要です。定期的にレポートの作成や編集を行っている場合は、このようなバックアップを作成して開発作業の成果が失われないようにする必要があります。

共有記憶域ボリューム(構成ボリュームとクラスタ・ボリューム)はすべてのEnterprise Managerシステムにマウントする必要があります。マウントには標準のオペレーティング・システム・コマンドを使用できます(NFSなど)。ストレージ・デバイス上の2つのディレクトリをBI Publisherファイル専用にする必要があります。これらはクラスタ・ボリュームおよび構成ボリュームと呼ばれます。Enterprise Managerはオペレーティング・システムの起動時に自動的に起動するように構成されるため、これらの共有記憶域ボリュームがマウントされるように特定のオペレーティング・システム構成ファイルを編集する必要があります。たとえば、Linuxではファイル/etc/fstabがこの目的に使用されます。

注意:
BI Publisher共有記憶域を構成するための領域要件は、レポート・カタログとそれに関連する管理情報の格納に必要な領域の容量に応じて異なります。
インストール時、BI Publisherリポジトリは約400MBの記憶域を使用します。最初は、BI Publisher共有記憶域として10Gを利用できるようにします。その後、追加のEnterprise Managerプラグインをインストールし、より多くのレポートを作成するにつれて、必要な領域は増大します。そのため、この記憶域は、将来容易に拡張できるようにしてください。

Enterprise Managerがインストールされると、BI Publisher共有記憶域が自動的に構成されます。

ただし、Enterprise Managerのインストール時に、前に示したインストーラ画面の「Oracle BI Publisherの共有場所の構成」セクションを選択しないことも可能です。この場合は、追加のEnterprise Managerシステムが追加されるか前のリリースからアップグレードされる前に、次のコマンドを実行する必要があります。

emctl config oms -bip_shared_storage -config_volume <vol1> -cluster_volume <vol2>

追加のOMSシステムにセカンダリBI Publisherサーバーを構成するための手順はいくつかあります。

標準の「Oracle Management Serviceの追加」プロビジョニング・ジョブを使用します。追加のOMSシステムはセカンダリBI Publisherサーバーを含むように自動的に構成されます。

注意:
「Oracle Management Serviceの追加」プロビジョニング・ジョブが使用できるのは、Enterprise Managerのインストール時に自動的に、または前述のコマンドを使用して手動で、BI Publisherが構成されてからです。

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 13c Release 1
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

22.2 共有記憶域デバイスを使用するBI Publisherの手動構成

重要:
UNIXのNetwork File System (NFS)をBI Publisher共有記憶域ボリュームに使用する場合、NFSオートマウンタによって管理されるNFSボリュームを使用しないでください(NFSオートマウンタは通常、記憶域を動的にマウントするため)。BI PublisherまたはWebLogic (あるいは両方)で問題が発生する可能性があるためです。かわりに、固定のマウント・ポイントを使用するNFSマウントを使用します。たとえば、/oracle/em/BIPCluster/ /oracle/em/BIPConfigです。ファイルレベルの不一致が発生しないように、この共有記憶域はhard NFSオプションを使用してマウントしてください。

前述の概要説明のとおり、複数のBI Publisherサーバーをサポートするには、BI Publisher共有記憶域を構成する必要があります。この処理はインストール時にEnterprise Managerインストーラによって行うことを強くお薦めします。

ただし、後からこの共有記憶域を構成することもできます。その場合には次のコマンドを使用します。

emctl config oms -bip_shared_storage -config_volume <vol1> -cluster_volume <vol2>

これらのボリューム(前の項で示した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 13c Release 1
Copyright (c) 1996, 2015 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

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

前述したように、追加のBI Publisherサーバーを構成する方法は2つあります。使用される方法は、BI Publisher共有記憶域がいつ構成されるかによって異なります。

パスA

Enterprise Managerのインストール

1. プライマリBI Publisherサーバーが自動的に構成されます。オプションで無効にします。

2. BI Publisher共有記憶域が自動的に構成されます。

3. 「OMSの追加」プロビジョニング・ジョブを使用してOMSを追加します。
セカンダリBI Publisherサーバーが追加のOMSシステムとともに自動的に構成されます。

パスB

Enterprise Managerのインストール

1. プライマリBI Publisherサーバーが自動的に構成されます。オプションで無効にします。ただし、BI Publisher共有記憶域の自動構成は無効になります。

2. emctl config oms -bip_shared_storageを使用して、BI Publisherの共有記憶域を構成します。

3. 「OMSの追加」プロビジョニング・ジョブを使用してOMSを追加します。
セカンダリBI Publisherサーバーが追加のOMSシステムとともに自動的に構成されます。

これら2つの手順から、BI Publisherを含むセカンダリOMSシステムを追加するために必要な前提条件がわかります。

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

Enterprise Managerの高可用性インストールの構築を計画している場合、追加したすべての追加OMSシステムに、セカンダリBI Publisherが自動的に構成されます。

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

BI Publisher共有記憶域が自動または手動で構成されると、「OMSの追加」プロビジョニング・ジョブによって追加BI Publisherサーバーも構成されます。ここで必要な操作は、追加のOMSシステムについて、使用するHTTPおよびHTTPSポートを入力することのみです。「OMSの追加」プロビジョニング・ジョブが、前提条件の手順を実行して、BI Publisherの共有記憶域が構成されていることを確認します。また、この共有記憶域が正しくマウントされており、最初のOMSシステムでも、追加のOMS (およびBI Publisher)が構成されているシステムでも使用可能であることも確認されます。

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

「emctl status oms」コマンドを使用すると、セカンダリBI Publisherサーバーの構成が成功したことを確認できます。

$ emctl status oms
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
WebTier is Up
Oracle Management Server is Up
JVMD Engine is Up

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

セカンダリBI Publisherサーバーの情報を取得するには、次のコマンドを実行します。

emctl status oms -details

セカンダリBI Publisherサーバーのサーバー名はBIPxで、xはOMSのサーバー番号と一致します(たとえば、EMGC_OMS2 : BIP2、EMGC_OMS3 : BIP3)。EMGC_OMS1が実行しているプライマリBI Publisherサーバーの名前は必ず「BIP」です(数値の接尾辞はありません)。

$ emctl status oms -details
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host        : emoms2.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
SLB or virtual hostname: slb.example.com
HTTPS SLB Upload Port : 4900
HTTPS SLB Console Port : 443
Agent Upload is unlocked.
OMS Console is unlocked.
Active CA ID: 1
Console URL: https://slb.example.com:443/em
Upload URL: https://slb.example.com:4900/empbs/upload

WLS Domain Information
Domain Name            : GCDomain
Admin Server Host      : emoms1.example.com
Admin Server HTTPS Port: 7101

Oracle Management Server Information
Managed Server Instance Name: EMGC_OMS2
Oracle Management Server Instance Host: emoms2.example.com
WebTier is Up
Oracle Management Server is Up
JVMD Engine is Up

BI Publisher Server Information
BI Publisher Managed Server Name: BIP2
BI Publisher Server is Up

BI Publisher HTTP Managed Server Port   : 9701
BI Publisher HTTPS Managed Server Port  : 9803
BI Publisher HTTP OHS Port              : 9788
BI Publisher HTTPS OHS Port             : 9851
BI Publisher HTTPS SLB Port             : 5443
BI Publisher HTTP SLB Port              : 8080
BI Publisher is unlocked.
BI Publisher Server named 'BIP2' running at URL: https://slb.example.com:5443/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部

削除

この部は、次の章で構成されています。

- 第23章「Enterprise Managerの削除(単一および複数OMS環境)」

- 第24章「Oracle Management Agentの削除」

- 第25章「JVMDエージェントの削除」

- 第26章「スタンバイOracle Management Serviceの削除」

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

この章では、Enterprise Managerシステム全体を削除する方法、およびOracle Management Service (OMS)を実行していたホストが失われた場合に、Oracle Management Repository(管理リポジトリ)からOMSのエントリを削除する方法について説明します。

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

- 削除の範囲

- Enterprise Managerシステムの削除

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

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

23.1 削除の範囲

Enterprise Managerシステムのコンポーネントを削除する際の範囲について次に説明します。

表23-1 削除の範囲

環境タイプ

OMSタイプ

インストール・タイプ

削除されるコンポーネント

削除されないコンポーネント

単一OMS、複数OMS

最初のOMS

新規のインストール

- 最初のOMS (インスタンス・ホームを含む)

- セントラル・エージェント

- 管理リポジトリ

該当なし

単一OMS、複数OMS

最初のOMS

アップグレード

- 最初のOMS (インスタンス・ホームを含む)

- 管理リポジトリ

セントラル・エージェント。

セントラル・エージェントを削除するには、第24章を参照してください。

複数OMS

追加のOMS

新規のインストール

追加のOMS

- 管理リポジトリ

- 追加のOMSホストで稼働しているスタンドアロン管理エージェント。
セントラル・エージェントを削除するには、第24章を参照してください。

複数OMS

追加のOMS

アップグレード

追加のOMS

- 管理リポジトリ

- 追加のOMSホストで稼働しているスタンドアロン管理エージェント。
セントラル・エージェントを削除するには、第24章を参照してください。

23.2 Enterprise Managerシステムの削除

単一OMS環境または複数OMS環境でEnterprise Managerシステムを削除するには、次の手順に従います。

注意:

- 最初に、第23.1項で説明した削除の範囲を理解してください。

- 複数OMS環境では、追加のOMSインスタンスをまず削除してから、最初のOMSを削除します。

- この項で説明する手順では、OMSインスタンスが削除されるだけではなく、管理リポジトリも削除されます。

- 管理リポジトリがデータベースから削除されると、空のデータベースを他の任意の目的に再利用できます。Enterprise Managerスキーマのみがデータベースから削除され、物理ファイルまたはデータベース・ソフトウェアのソフトウェア・バイナリはホストに残ります。

- この項で説明する手順では、データベースに適用されたパッチの削除やロールバックは行われません。

- OMS (最初のOMSまたは追加のOMS)の新規インストールの場合、この項で説明する手順では、ミドルウェア、OMS、OMSインスタンス・ホームおよび管理エージェント・ディレクトリは自動的に削除されますが、Oracle BI Publisher用に構成された共有場所の内容は削除されません。内容を手動で削除する必要があります。

- OMS (最初のOMSまたは追加のOMS)のアップグレードの場合、この項で説明する手順では、ミドルウェア、OMSおよびOMSインスタンス・ホーム・ディレクトリは自動的に削除されますが、管理エージェント・ディレクトリとOracle BI Publisher用に構成された共有場所の内容は削除されません。管理エージェントは第24章の説明に従って削除し、Oracle BI Publisher用に構成された共有場所の内容は手動で削除する必要があります。

1. OMSホストのOracleホームの削除スクリプトを一時的な場所またはステージング場所にコピーします。
cp <ORACLE_HOME>/sysman/install/EMDeinstall.pl <temporary_location>

次に例を示します。

cp /u01/software/em13c/oraclehome/sysman/install/EMDeinstall.pl /u01/tmp_deinstall

2. OMSを削除します。
<ORACLE_HOME>/perl/bin/perl <temporary_location>/EMDeinstall.pl -mwHome <ORACLE_HOME> -stageLoc <temporary_location>

データベース資格証明(SYSおよびSYSMAN)とWebLogic Domain資格証明を入力するように求められます。資格証明を入力して、削除を進めます。

次に例を示します。

/u01/software/em13c/oraclehome/perl/bin/perl /u01/tmp_deinstall/EMDeinstall.pl -mwHome /u01/software/em13c/oraclehome -stageLoc /u01/tmp_deinstall

注意:
削除処理により、/etc/oragchomelistファイルから自動開始スクリプトであるS98gcstartupスクリプトのエントリが削除されますが、スクリプト自体は削除されません。このスクリプトとこのスクリプトに関連付けられたsymlinkは、Enterprise Managerを同じホストに再度インストールする際に、インストーラがスクリプトを自動的に上書きし、symlinkを再作成するため、そのまま残しておくことができます。
ただし、Oracle製品のホストをクリアする場合には、このスクリプトとスクリプトに関連付けられたsymlinkを手動で削除することをお薦めします。これを行うには、/etc/rc.d/ディレクトリに移動し、S98gcstartupスクリプトを検索します。このスクリプトは通常、/etc/rc.d/ディレクトリ内のサブディレクトリにあります。スクリプトが存在するサブディレクトリに移動し、スクリプトを削除します。たとえば、/etc/rc.d/rc3.d/S98gcstartupまたは/etc/rc.d/init.d/gcstartup/S98gcstartupなどにあります。

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

OMSからEnterprise Managerシステム全体ではなく、プラグインのみを削除またはアンデプロイするには、Enterprise Manager Cloud Controlコンソールのプラグインページを使用します。手順については、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。プラグインのみのアンデプロイには、この章を使用しないでください。

23.4 管理リポジトリからの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を削除するには、第23.2項で説明されている手順に従います。

24 Oracle Management Agentの削除

この章では、スタンドアロンOracle Management Agent (管理エージェント)を削除する方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle Management Agentの削除

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

注意:
クラスタで、管理エージェントをすべてのノードから1つずつ確実に削除するようにしてください。そのためには、この章で説明されている手順に従ってください。

注意:
古いスタンドアロン管理エージェントを削除して同じホストに新しいスタンドアロン管理エージェントをインストールすると、管理リポジトリからターゲットのすべての履歴情報が失われます。
履歴情報がすべて消失することを回避するには、最初に新しいスタンドアロン管理エージェントをインストールし、emcli relocate_targetsコマンドを実行して旧スタンドアロン管理エージェントから新スタンドアロン管理エージェントにターゲットを渡してから、旧スタンドアロン管理エージェントを削除します。

emcli relocate_targetsコマンドの詳細は、Oracle Enterprise Manager Cloud Controlコマンドライン・インタフェース・ガイドを参照してください。

24.1 Oracle Management Agentの削除

この項では、削除の前提条件を示し、スタンドアロン管理エージェントを削除する様々な方法について説明します。この項の具体的な内容は次のとおりです。

- スタンドアロンOracle Management Agentの削除

- スタンドアロン管理エージェントの削除後

24.1.1 スタンドアロンOracle Management Agentの削除

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

- AgentDeinstall.plスクリプトを使用したスタンドアロン管理エージェントの削除

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

- RPMファイルを使用してインストールしたスタンドアロン管理エージェントの削除

24.1.1.1 AgentDeinstall.plスクリプトを使用したスタンドアロン管理エージェントの削除

AgentDeinstall.plスクリプトを使用してスタンドアロン管理エージェントを削除するには、次の手順を実行します。

1. AgentDeinstall.plスクリプトを起動して、スタンドアロン管理エージェントを削除し、エージェント・ベース・ディレクトリも削除します。
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/AgentDeinstall.pl -agentHome <AGENT_HOME>

次に例を示します。

/u01/software/em13c/agentbasedir/agent_13.1.0.0.0/perl/bin/perl /u01/software/em13c/agentbasedir/agent_13.1.0.0.0/sysman/install/AgentDeinstall.pl -agentHome /u01/software/em13c/agentbasedir/agent_13.1.0.0.0

2. 削除したスタンドアロン管理エージェントによって監視されていたターゲットをEnterprise Manager Cloud Controlコンソールから手動で削除します。それには、EM CLIがインストールされている任意のホストで次のEM CTLコマンドを実行します。
emcli delete_target

-name="<host_name>:<agent_port>"

-type="oracle_emd"

-delete_monitored_targets

次に例を示します。

emcli delete_target

-name="example.com:1836"

-type="oracle_emd"

-delete_monitored_targets

3. エージェント・ベース・ディレクトリを手動で削除します。エージェント・ベース・ディレクトリの詳細は、第2.3.4項を参照してください。
UNIXプラットフォームの場合:

rm -rf <absolute_path_to_install_base_dir>

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

del <absolute_path_to_install_base_dir>

注意:
スタンドアロン管理エージェントを削除するとき、管理エージェント・サービスは自動的に削除されません。次のコマンドを実行して、削除後に手動で削除する必要があります。
sc delete <service_name>

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

次に例を示します。

/shared/app/agentbasedir/agent_13.1.0.0.0/perl/bin/perl /shared/app/agentbasedir/agent_13.1.0.0.0/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=/shared/app/agentbasedir/agent_inst ORACLE_HOME=/shared/app/agentbasedir/agent_13.1.0.0.0

24.1.1.3 RPMファイルを使用してインストールしたスタンドアロン管理エージェントの削除

.rpmファイルを使用してインストールされたスタンドアロン管理エージェントを削除するには、Resource Package Manager (RPM)が管理エージェント・ホストにインストールされていることを確認し、次の手順を実行します。

1. 管理エージェントで次のコマンドを実行し、RPM名を取得します。
rpm -qa | grep oracle-agt

2. rootユーザーとして次のコマンドを実行し、管理エージェントを削除します。
rpm -e <rpm_name>

ここで、<rpm_name>は手順1で実行したコマンドの出力に表示されるRPM名を表します。

24.1.2 スタンドアロン管理エージェントの削除後

スタンドアロン管理エージェントを削除した後は、次の手順を実行します。

1. 削除したOracleホームが、中央インベントリから登録解除されたことを確認します。ただし、一部のファイルがこれらのOracleホームに残ることもあります。その場合は、手動でファイルを削除できます。
また、/etc/init.dディレクトリにあるgcstartupという名前の自動起動スクリプトを手動で削除する必要があります。

注意:
この自動開始スクリプトは、Microsoft Windowsでは提供されていません。

2. 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. レジストリ・エディタを閉じます。

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

管理エージェント自体ではなく、管理エージェントからプラグインのみを削除またはアンデプロイするには、Enterprise Manager Cloud Controlコンソールのプラグインページを使用します。手順については、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。プラグインのみのアンデプロイには、インストーラを使用しないでください。

25 JVMDエージェントの削除

この章では、Java仮想マシン診断(JVMD)エージェントをEnterprise Manager Cloud Control環境から削除する方法について説明します。

25.1 JVMDエージェントの削除

この項では、JVMDエージェントを削除する方法について説明します。内容は次のとおりです。

- 「設定」ページを使用したJVMDエージェントの削除

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

25.1.1 「設定」ページを使用したJVMDエージェントの削除

「設定」ページを使用して、(WebLogicドメインにデプロイされ監視された)JVMDエージェントを削除するには、次の手順を実行します。

1. 「設定」メニューから、「ミドルウェア管理」、「設定」の順に選択します。

2. 「設定」ページで「JVMDエージェントの管理」をクリックします。

注意:
アクティブのJVMDエンジンがなく、JVMDエージェントがデプロイされていない場合、「JVMDエージェントの管理」ボタンは無効になっています。

3. 「操作」で、「削除」を選択します。
「表示」メニューから「すべてを開く」を選択した場合は、JVMDエージェントがデプロイされている管理対象サーバーすべてについて、ターゲット名、ターゲット・タイプ、ターゲット・ホスト、ターゲット・ステータスなどを表示できます。

削除するJVMDエージェントを選択します。「次へ」をクリックします。

4. 「ターゲットの資格証明」ページで、(管理サーバー・ターゲットに対応するように) WebLogicドメインごとに「Oracle EMAgentターゲット・ホスト資格証明」および「Oracle WebLogicドメインの資格証明」の値を指定し、「適用」をクリックします。

注意:
管理サーバー・ターゲットについてホストおよびドメインの優先資格証明がすでに設定されている場合は、ドメインに自動的に適用され、「適用」をクリックする必要はありません。

Oracle EMAgentターゲット・ホストの資格証明は、WebLogicドメインの管理サーバーの検出に使用された管理エージェントが実行されているホストのログイン資格証明です。Oracle WebLogicドメインの資格証明は、選択されたWebLogicドメインの管理サーバーの資格証明です。

WebLogicドメインの管理サーバーの優先資格証明(優先EMAgentターゲット・ホスト資格証明と優先Oracle WebLogicドメイン資格証明)を設定するには、「設定」メニューから、「セキュリティ」、「優先資格証明」の順に選択します。ターゲット・タイプとしてOracle Admin Serverを選択し、「優先資格証明の管理」をクリックします。「ターゲット優先資格証明」セクションで、必要なWebLogic管理サーバーの優先ホスト資格証明および優先WebLogic管理者資格証明を設定します。

「次へ」をクリックします。

5. JVMDエージェント構成ページで、「WebLogicホーム」および「ミドルウェア・ホーム」フィールドの値を指定します。
これらのフィールドは、値を内部的に取得できなかった場合のみ表示されます。また、WebLogic管理サーバーがファイアウォールの背後または仮想ホスト上にある場合、アプリケーションはデフォルト情報を使用して接続できない可能性があります。この場合、「拡張ドメイン構成」セクションで追加情報を指定する必要があります。たとえば、WebLogic管理サーバーが仮想ホスト上にあり、アプリケーションがデフォルトのホスト値を使用して接続できない場合は、「管理サーバー・ホスト」に仮想ホストのIPアドレスを指定することが必要な場合があります。

「次へ」をクリックします。

6. 確認ページですべての情報を確認し、「削除」をクリックします。

注意:
エージェントを削除した後でデプロイするには、JVMを再起動してからエージェントをデプロイする必要があります。

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

ターゲットにデプロイされたJVMDエージェントを手動で削除するには、次の手順を実行します。

1. ターゲット・サーバーの管理コンソールにログインします。

2. ホームページで、「デプロイメント」をクリックします。

3. JVMDエージェント・アプリケーション(jamagent.war)を選択します。「停止」メニューから「ただちに強制停止」を選択します。

4. アプリケーションが停止したら、同じアプリケーションを選択して「削除」をクリックします。

5. Enterprise Manager Cloud Controlにログインします。

6. Cloud Controlで、「ターゲット」メニューから「ミドルウェア」を選択します。

7. ミドルウェアページの「検索」表で「Java仮想マシン」タイプのターゲットを検索し、サーバーに対応するターゲットを選択して「削除」をクリックします。

注意:
エージェントを削除した後でデプロイするには、JVMを再起動してからエージェントをデプロイする必要があります。

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

この章では、レベル4の高可用性(HA)構成からスタンバイOracle Management Service (OMS)を削除する方法について説明します。次のOMSの削除シナリオについて説明します。

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

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

26.1 追加のスタンバイOMSインスタンスの削除

追加のスタンバイOMSインスタンスを削除するには、次の手順を実行します。

1. OMSホームから次のコマンドを実行して追加のスタンバイOMSインスタンスを構成解除して削除します。
$<OMS_HOME>/bin/omsca delete -OMSNAME <oms_name>

プロンプトが表示された場合は、リポジトリのログイン資格証明を入力します。

注意:
追加の各スタンバイOMSインスタンスでこのコマンドを実行します。

2. Enterprise Managerコンソールから、WebLogicドメインをリフレッシュします。

1. 「ターゲット」メニューから「ミドルウェア」を選択します。

図26-1 「ミドルウェア」メニュー

2. リフレッシュするWebLogicドメインをクリックします。ドメインのホームページが表示されます。

図26-2 ドメインのホームページ

3. 「ファーム」または「WebLogicドメイン」メニューから「WebLogicドメインのリフレッシュ」を選択します。

図26-3 WebLogicドメインのリフレッシュ

Enterprise Managerに、使用可能な「WebLogicドメインのリフレッシュ」オプションが表示されます。

図26-4 WebLogicドメインのリフレッシュ

4. 「ターゲットの追加/更新」をクリックします。管理エージェントは、管理サーバーに接続することでリフレッシュします。リフレッシュを行うには、管理サーバーを起動する必要があります。
「確認」ページで「閉じる」をクリックします。ドメイン内の新規および変更されたターゲットが検索されます。

3. OMSに関連付けられているOMSターゲットを削除します。

1. 「ターゲット・ナビゲーション」領域で、以前に構成解除した追加のスタンバイOMSに関連付けられているターゲットをクリックします。

2. 「WebLogic」メニューから、「ターゲット設定」、「ターゲットの削除」の順に選択します。Enterprise Managerに、続行するかどうかを尋ねる警告ダイアログが表示されます。「はい」をクリックします。

4. 残りの追加のスタンバイOMSすべてに対してこの削除手順を繰り返します。

26.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「インストールおよび構成ログ・ファイルの概要」

- 付録B「別のOracle Management ServiceへのOracle Management Agentのリダイレクト」

- 付録C「Oracle Management Agentのデプロイまたはアップグレード中のパッチの適用」

- 付録D「RepManagerユーティリティの使用」

- 付録E「Oracle Harvesterを使用したOCMデータの収集」

- 付録F「Enterprise Managerのアクセシビリティ機能の有効化」

- 付録G「アクティブおよびパッシブ環境でのフェイルオーバーのターゲットの構成」

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

この付録では、Enterprise Manager Cloud Controlコンポーネントの前提条件チェック、インストールおよび構成の各フェーズで作成される各種ログ・ファイルの場所を一覧表示します。

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

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

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

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

- エージェント・ゴールド・イメージのログ・ファイル

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

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

この項では、Enterprise Manager Cloud Controlのインストール中に作成される次のログ・ファイルについて説明します。

- インストール・ログ

- 構成ログ

A.1.1 インストール・ログ

次のインストール・ログに、インストールのステータスに関する完全な情報が記録されます。

- <ORACLE_INVENTORY_HOME>/logs/installActions<timestamp>.log

- <ORACLE_HOME>/cfgtoollogs/oui/installActions<timestamp>.log

注意:
installActionsログ・ファイルは、デフォルトで<ORACLE_INVENTORY_HOME>ディレクトリ内に作成されます。このログ・ファイルは、インストールが完了すると、前述のOracleホームの場所にコピーされます。

A.1.2 構成ログ

この項では、次の構成ログについて説明します。

- 一般的な構成ログ

- リポジトリ構成ログ

- セキュア・ログ

A.1.2.1 一般的な構成ログ

Oracle Management Service (OMS)構成ログは、OMSのOracleホームの次の場所に作成されます。

<ORACLE_HOME>/cfgtoollogs/omsca

表A-1に、各種のインストール・タイプに対応する構成ログを一覧表示します。

表A-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ホームを指します。

A.1.2.2 リポジトリ構成ログ

この項では、次のリポジトリ構成ログについて説明します。

- SYSMANスキーマ操作ログ

- MDSスキーマ操作ログ

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

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

A.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/oms13c/mds.logおよび/scratch/OracleHomes/oms13c/emmdsdrop_<timestamp>.logとなります。

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

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

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

この項では、次のホストの追加ログ・ファイルの場所について説明します。

- 初期化ログ

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

- システム前提条件ログ

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

- ホストの追加のその他のログ

A.2.1 初期化ログ

表A-2に、リモート・ホストとその場所の初期化ログを一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表A-2 初期化ログ

ログ・ファイル

場所

<hostname>_deploy.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/applogs

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

表A-3に、アプリケーションの前提条件ログとその場所を一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。また、この表に示されている<install_type>は表A-4に示すインストール・タイプの1つです。

表A-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>/

表A-4 インストール・タイプ

インストール・タイプ

説明

ターゲット・オペレーティング・システム・タイプ

emagent_install

新規エージェント・インストール

UNIX

emagent_clone

エージェントのクローニング

UNIX

nfs_install

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

UNIX

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

表A-5に、システム前提条件ログとその場所を一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表A-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>/

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

表A-6に、エージェントのインストール・ログとその場所を一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表A-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>

エージェントの構成ログ

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

表A-7に、ホストの追加・ウィザードを使用してエージェントをインストールする間に作成されるその他すべてのインストール・ログを一覧表示します。この表に示されている<OMS_INSTANCE_HOME>とは、OMSインスタンス・ベース・ディレクトリのことです(デフォルトではgc_inst/em/EMGC_OMS1、ミドルウェア・ホームの親ディレクトリの下にあります)。

表A-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/

ホストの追加ユーザー・インタフェースのログ

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

表A-8は、管理エージェントが手動でインストールされた(サイレント・モード)ときに作成されたインストール・ログの一覧です。この表に記載の<ORACLE_HOME>は、ターゲットの管理エージェントのOracleホーム、<AGENT_BASE_DIR>/13.1.0.0.0/を示しています。

表A-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/

クローン・アクション・ログ

A.4 エージェント・ゴールド・イメージのログ・ファイル

表A-9に、ゴールド・イメージ作成プロセスが失敗した際に詳しく調べる必要があるログ・ファイルを一覧表示します。

表A-9 エージェント・ゴールド・イメージの作成失敗ログ

ログ

場所

説明

出力ログ。

Enterprise Manger Cloud Controlホームページで、「設定」をクリックし、「Cloud Controlの管理」を選択してエージェント・ゴールド・イメージをクリックします。

エージェント・ゴールド・イメージ・ページで「すべてのアクティビティの表示」リンクをクリックしてすべてのジョブを表示します。ジョブ名をクリックして、ジョブの結果と出力ログを確認します。

実行されたエージェント・ゴールド・イメージ・ジョブの出力ログ。

GoldAgentImageLogger<timestamp>.log

<OMS_INSTANCE_HOME>/EMGC_OMS1/sysman/goldagentimage/logs/

OMS側のログ。

goldimagecreate<timestamp>.log

<AGENT_INSTANCE_HOME>/install/<TIMESTAMP>/

エージェント側のログ。

表A-10に、エージェントの更新が失敗した際に詳しく調べる必要があるログ・ファイルを一覧表示します。

表A-10 エージェントの更新失敗ログ

ログ

場所

説明

agentDeploy<timestamp>.log

<New oracle home>/cfgtoollogs/agentDeploy/

注意: 場所<New oracle home>/cfgtoollogs/agentDeploy/が編集できない場合、ログは<AGENT_INSTANCE_HOME>/install/logs/フォルダに作成されます。

エージェントのデプロイ・ログ。

すべてのログ・ファイル。

<AGENT_INSTANCE_HOME>/sysman/logs

追加情報ログ。

すべてのログ・ファイル。

<OMS_INSTANCE_HOME>/EMGC_OMS1/sysman/logs

OMS側の例外ログ。

すべてのログ・ファイル。

user_projects/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/

サーバー側のログ。

A.5 追加のOMSインストール・ログ

表A-11は、OMSの追加が失敗した際に表示されるインストール・ログの一覧です。

注意:

- ORACLE_HOMEは、新規追加OMSのホームです。ただし、管理ログの場合、ORACLE_HOMEはプライマリOMSのホームです。

- INSTANCE_HOMEとは、OMSインスタンス・ディレクトリのことです(デフォルトでミドルウェア・ホームの親ディレクトリの下にあるgc_inst)。

表A-11 追加の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

B 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への管理エージェントのリダイレクト

B.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の修正を適用してください。

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

管理エージェントをリダイレクトまたは再指定するには、次の手順を実行します。

1. 管理エージェントを停止します。
$<AGENT_INSTANCE_HOME>/bin/emctl stop agent

2. 元のOMSで管理エージェント・ターゲットを削除します。
$<ORACLE_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にリダイレクトします。これには、agentDeploy.shスクリプト(Microsoft WindowsホストではagentDeploy.bat)に-configOnlyオプションを指定して実行します。
$<AGENT_BASE_DIR>/agent_13.1.0.0.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> -configOnly

次に例を示します。

/scratch/emga/agt4agi/agent_13.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=/u01/software/em13c/agentbasedir AGENT_INSTANCE_HOME=/u01/software/em13c/agentbasedir/agent_inst AGENT_PORT=3880 OMS_HOST=newoms.example.com EM_UPLOAD_PORT=4900 AGENT_REGISTRATION_PASSWORD=<password> -configOnly

agentDeploy.shまたはagentDeploy.batの実行時に指定できるパラメータの詳細は、表6-4を参照してください。-configOnlyオプションの詳細は、表 6-7を参照してください。

注意:
指定したエージェント・ベース・ディレクトリ位置および新しいエージェント・インスタンス・ホーム位置は、管理エージェントがすでに構成されているホストと同じホスト上にマップされます。当然、OMSホスト名は、新しいOMS(今回通信する管理エージェント)が構成されている他のホストにマップされます。

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

Enterprise Manager Cloud Control 13cリリース1では、管理エージェント・バイナリを管理エージェント・パッチおよびプラグイン・パッチと組み合せることができるため、管理エージェントをデプロイまたはアップグレードするたびにこれらのパッチを適用する必要がありません。管理エージェント・ソフトウェアの特定のバージョンに適用する管理エージェント個別パッチは、同じバージョンの新しい管理エージェントがデプロイされるとき、または古い管理エージェントがそのバージョンにアップグレードされるときに常にこれらのパッチが自動的にソフトウェアに割り当てられるように保存できます。これは一度の操作のため、管理エージェントをデプロイまたはアップグレードするたびにこの処理を行う必要はありません。

管理エージェント個別パッチをこの付録で説明したようにOMSホストに保存した場合、管理エージェントのデプロイまたはアップグレード処理は、管理エージェントのそれぞれのバージョンおよびプラットフォームに対してこれらのパッチを自動的に選択します。そのため、この機能を利用することにより時間と労力を大幅に節約できます。

プラグインにパッチを適用する方法、ならびに新規にデプロイするすべての管理エージェントおよびアップグレードするすべての旧管理エージェントにパッチ適用済プラグインがデプロイされることを確認する方法の詳細は、Oracle Enterprise Manager Cloud Controlの管理ガイドを参照してください。

管理エージェントに適用するパッチおよびプラグインが管理エージェントのデプロイまたはアップグレード後に自動的に適用されるようにするには、管理エージェントのデプロイまたはセッションのアップグレードを計画する前に、必ずこの付録および前の段落で参照された項に記載の手順に従ってください。

内容は次のとおりです。

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

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

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

管理エージェント個別パッチを、新規の管理エージェントがデプロイされたときまたは管理エージェントがアップグレードされたときに常に適用されるように、OMSホストに保存するには、次の手順を実行します。

1. 次のURLで利用できるMy Oracle Supportから必要な管理エージェント個別パッチをダウンロードします。
https://support.oracle.com/

ダウンロードしたパッチzipファイルのサイズがMy Oracle Supportページに表示されているサイズと同じであることを確認します。

My Oracle Supportからパッチをダウンロードする方法の詳細は、『Oracle Enterprise Managerライフサイクル管理者ガイド』を参照してください。

2. OMSホストに次のディレクトリを作成し、そこにすべての汎用管理エージェント個別パッチを転送します。
$<ORACLE_HOME>/install/oneoffs/<agent_version>/Generic/

ここで、<agent_version>はパッチが適用される管理エージェントのバージョンです。このディレクトリの作成中、必ず5桁の管理エージェントのバージョンを使用してください。

たとえば、13cリリース1管理エージェントをデプロイするとき、または旧管理エージェントを13cリリース1にアップグレードするときには常に、13cリリース1管理エージェント用の汎用管理エージェント個別パッチであるパッチ11180406を適用する場合、My Oracle Supportからこのパッチをダウンロードし、次のディレクトリを作成し、そこにパッチを転送します。

/u01/software/em13c/oraclehome/install/oneoffs/13.1.0.0.0/Generic/

3. OMSホストに次のディレクトリを作成し、それらにすべてのプラットフォーム固有の管理エージェント個別パッチを転送します。
$<ORACLE_HOME>/install/oneoffs/<agent_version>/<platform>/

ここで、<agent_version>はパッチが適用される管理エージェントのバージョンです。これらのディレクトリの作成中、必ず5桁の管理エージェントのバージョンを使用してください。

<platform>はプラットフォームのディレクトリ名で、パッチ・プラットフォームにより異なります。表C-1は、様々なパッチ・プラットフォーム用に作成する必要のあるプラットフォーム・ディレクトリの一覧を示しています。

表C-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 (13cリリース1 Linux x86-64管理エージェント用)およびパッチ11993577 (13cリリース1 Microsoft Windows x64管理エージェント用)を、これらの管理エージェントをデプロイするとき、またはこれらの管理エージェントを13cリリース1にアップグレードするときに常に適用する場合には、My Oracle Supportからこれらのパッチをダウンロードし、次のディレクトリを作成し、それらにパッチを転送します。

パッチ11878907

/u01/software/em13c/oraclehome/install/oneoffs/13.1.0.0.0/linux_x64/

パッチ11993577

/u01/software/em13c/oraclehome/install/oneoffs/13.1.0.0.0/windows_x64/

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

OMSホストに保存した管理エージェント個別パッチ(C.1項で説明)がデプロイまたはアップグレードした管理エージェントに適用されたかどうかを検証するには、次の方法を使用できます。

- 管理エージェント・ホームから次のコマンドを実行します。
$<AGENT_HOME>/OPatch/opatch lsinventory -oh <AGENT_HOME> -invPtrLoc <AGENT_HOME>/oraInst.loc

このコマンドにより、管理エージェントに適用されたすべてのパッチが表示されます。

- Cloud Controlコンソールで、「設定」メニューから「Cloud Controlの管理」を選択し、「エージェント」を選択します。目的の管理エージェント名をクリックしてそのホームページに移動します。「構成」セクションで「Oracleホームとパッチの詳細」をクリックします。管理エージェントに適用されたパッチが「パッチ適用」セクションに表示されます。

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

この付録では、RepManagerユーティリティについて説明します。特に、次の内容について説明します。

- RepManagerユーティリティの概要

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

D.1 RepManagerユーティリティの概要

RepManagerは、Oracle Management Repository (管理リポジトリ)のアップグレードおよび削除、プラグインの選択的なパージ、ならびにdlfメッセージのOracle Management Repositoryへのロードを行うユーティリティです。このユーティリティは、Oracle Management Service (OMS)ホストのOracleホーム内にあります。

UNIXオペレーティング・システムの場合:

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager

Microsoft Windowsオペレーティング・システムの場合:

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager.bat

このユーティリティは、完全なEnterprise Managerシステムのインストール中にリポジトリ・コンフィギュレーション・アシスタントによって、またEnterprise Manager Cloud Controlのアップグレード中にリポジトリ・アップグレード・コンフィギュレーション・アシスタントによって起動されます。

注意:
Enterprise Managerスキーマを完全に削除する場合は、OMSホストのOracleホームにあるRepManagerを使用します。データベース・ホーム内のものは、Enterprise Managerスキーマを完全には削除できないため、使用しないでください。

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

表D-1に、RepManagerユーティリティでサポートされる操作およびそれに関連付けられたコマンドを一覧表示します。

警告:

削除モードのRepManagerは、"ALTER SYSTEM QUIESCE RESTRICTED;"コマンドによりデータベースを静止モードにします。

表D-1 RepManagerでサポートされる操作およびコマンド

操作

コマンド

説明

例

preupgrade

$<ORACLE_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>"

この操作では、次のパラメータを指定して、管理リポジトリをアップグレードするための前処理手順を実行します。

- 管理リポジトリをアップグレードする必要があるデータベースに接続するためのホスト、ポートおよびSIDを指定します。

- データベース・ユーザー(SYS)とパスワード、データベース・ロール(SYSDBA)、リポジトリ名(SYSMAN)とパスワード、および管理リポジトリをアップグレードするミドルウェア・ホームを指定します。ここで、ミドルウェア・ホームはWebLogic Server、OMSおよび他のコンポーネントが構成されているOracleホームです。

- 依存性に準じて、デプロイするプラグインのリストをカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラグインIDのリストです。-pluginDepListパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、プラグイン依存リストを取得するためデフォルトで次のものが読み取られます。
$<ORACLE_HOME>/sysman/admin/emdrep/plugininfo/pluginDepList

- プラグインをデプロイできる方法に応じて、SYSとしてデプロイするか、SYSMAN(リポジトリ・ユーザー)としてデプロイするかを指定します。SYSMANとしてデプロイするには、-runAsReposUserパラメータをTRUEに設定します。このパラメータを渡さない場合には、プラグインはデフォルトでSYSユーザーとしてデプロイされます。

- プラットフォーム/プラグインのDLFファイルの場所をカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラットフォーム/プラグインのDLFファイルの場所です。-dlfSourcesパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、dlfリソースの場所を取得するためデフォルトで次のものが読み取られます。
$<ORACLE_HOME>/sysman/admin/emdrep/plugininfo/dlfSources

このオプションが欠落しているかデフォルトのdlfSourcesファイルが存在しない場合、プラットフォームのdlfファイルのみが取得されます。デフォルトのdlfSourcesファイルが存在する場合、これらのソースの下のDLFのみが取得されます。

$<ORACLE_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

$<ORACLE_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>"

注意: アップグレード操作を実行する前にアップグレード前の操作を実行してください。

この操作では、次のパラメータを指定して、管理リポジトリをアップグレードします。

- 管理リポジトリをアップグレードする必要があるデータベースに接続するためのホスト、ポートおよびSIDを指定します。

- データベース・ユーザー(SYS)とパスワード、データベース・ロール(SYSDBA)、リポジトリ名(SYSMAN)とパスワード、および管理リポジトリをアップグレードするミドルウェア・ホームを指定します。ここで、ミドルウェア・ホームはWebLogic Server、OMSおよび他のコンポーネントが構成されているOracleホームです。

- 依存性に準じて、デプロイするプラグインのリストをカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラグインIDのリストです。-pluginDepListパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、プラグイン依存リストを取得するためデフォルトで次のものが読み取られます。
$<ORACLE_HOME>/sysman/admin/emdrep/plugininfo/pluginDepList

- プラグインをデプロイできる方法に応じて、SYSとしてデプロイするか、SYSMAN(リポジトリ・ユーザー)としてデプロイするかを指定します。SYSMANとしてデプロイするには、-runAsReposUserパラメータをTRUEに設定します。このパラメータを渡さない場合、プラグインはデフォルトでSYSユーザーとしてデプロイされます。

- プラットフォーム/プラグインのDLFファイルの場所をカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラットフォーム/プラグインのDLFファイルの場所です。-dlfSourcesパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、dlfリソースの場所を取得するためデフォルトで次のものが読み取られます。
$<ORACLE_HOME>/sysman/admin/emdrep/plugininfo/dlfSources

このオプションが欠落しているかデフォルトのdlfSourcesファイルが存在しない場合、プラットフォームのdlfファイルのみが取得されます。デフォルトのdlfSourcesファイルが存在する場合、これらのソースの下のDLFのみが取得されます。

$<ORACLE_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

$<ORACLE_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に適用されます。

この操作では、次のパラメータを指定して管理リポジトリに変換リソースをロードします。

- データベースに接続するためのホスト、ポートおよびSIDを指定し、管理リポジトリに変換リソースをロードします。

- リポジトリ名(SYSMAN)とパスワードおよびミドルウェア・ホームを指定して、Oracle Management Repositoryに変換リソースをロードします。ここで、ミドルウェア・ホームはWebLogic Server、OMSおよび他のコンポーネントが構成されているOracleホームです。

- プラットフォーム/プラグインのDLFファイルの場所をカンマで区切って指定します。このオプションでファイルを渡すことができます。内容は、カンマで区切られたプラットフォーム/プラグインのDLFファイルの場所です。-dlfSourcesパラメータが設定されない場合、またはリストが空白(たとえば、"{}")のままの場合、dlfリソースの場所を取得するためデフォルトで次のものが読み取られます。
$<ORACLE_HOME>/sysman/admin/emdrep/plugininfo/dlfSources

このオプションが欠落しているかデフォルトのdlfSourcesファイルが存在しない場合、プラットフォームのdlfファイルのみが取得されます。デフォルトのdlfSourcesファイルが存在する場合、これらのソースの下のDLFのみが取得されます。

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager -action transx example.com 1521 db3 -reposName sysman -mwHome /scratch/WLS/middleware

resume

$<ORACLE_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>

この操作では、次のパラメータを指定して、最後に失敗した操作(たとえばアップグレード操作)を再開します。

- 操作を再開する必要があるデータベースに接続するためのホスト、ポートおよびSIDを指定します。

- データベース・ユーザー(SYS)とパスワード、データベース・ロール(SYSDBA)、リポジトリ名(SYSMAN)とSYSMANユーザーのパスワード、および操作を再開する必要があるミドルウェア・ホームを指定します。ここで、ミドルウェア・ホームはWebLogic Server、OMSおよび他のコンポーネントが構成されているOracleホームです。

- 手順を再開する場所を指定します。チェックポイントの場所は、$<ORACLE_HOME>/sysman/log/schemamanagerです。

$<ORACLE_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

$<ORACLE_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>]

または

$<ORACLE_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 Publisher (BIP)がインストールされ構成済の場合、このコマンドを実行する前に管理サーバーを使用してBIPを停止する必要があります。

この操作では、次のパラメータを指定して、すべてのEnterprise Managerリポジトリ・スキーマを削除します。

- すべてのスキーマを削除する必要があるデータベースに接続するためのホスト、ポートおよびSIDを指定します。

- データベース・ユーザー(SYS)とパスワード、データベース・ロール(SYSDBA)、リポジトリ名(SYSMAN)とパスワードおよびミドルウェア・ホームを指定します。ここで、ミドルウェア・ホームはWebLogic Server、OMSおよび他のコンポーネントが構成されているOracleホームです。

最後に、この操作のステータスを確認する確認メッセージが表示されます。すべてのスキーマが正常に削除されると、同様の確認メッセージが表示されます。そうでない場合は、各スキーマの詳細を示すメッセージが表示されます。

次に例を示します。

SYSMAN_OPSS schema is not cleaned.
EM_X synonyms are not dropped.

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action drop -mwHome /scratch/weblogic/middleware

または

$<ORACLE_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

$<ORACLE_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>となります。

この操作では、次のパラメータを指定して、管理リポジトリからプラグインを削除します。

- プラグインを削除する必要があるデータベースに接続するためのホスト、ポートおよびSIDを指定します。

- データベース・ユーザー(SYS)とパスワード、データベース・ロール(SYSDBA)、リポジトリ名(SYSMAN)とパスワードおよびミドルウェア・ホームを指定します。ここで、ミドルウェア・ホームはWebLogic Server、OMSおよび他のコンポーネントが構成されているOracleホームです

- EM-EXTモデルを持つEnterprise Managerリポジトリからパージされるプラグイン・リストをカンマで区切って指定します。

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action pluginpurge -pluginPurgeList "oracle.sysman.myyempwpax.oms.plugin_13.1.1.0.0=/scratch/weblogic/middleware/plugins/oracle.sysman.myyempwpax.oms.plugin_13.1.1.0.0" -mwHome /scratch/weblogic/middleware

注意:
-action dropおよび-action dropallコマンドのサポートの詳細は、表2-3を参照してください。

注意:
RepManager操作でパスワードを指定しない場合、パスワードの指定を求めるプロンプトが表示されます。

E 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の追加情報

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

E.1 Oracle Harvester

Oracle Harvesterでは、Enterprise Managerによって管理されているターゲットのデータのみが収集されます。Oracle Harvesterは同じOCM依存性のため、Oracle Harvesterを使用すると、Enterprise Managerの収集メソッドを利用してターゲットの構成データを収集できます。このため、Oracle Harvesterが管理するターゲットのホームにOCMをインストールする必要がありません。次の項目について説明します。

- Oracle Harvesterの特徴

- Oracle HarvesterとOCM

- Enterprise Managerのサポート

- Enterprise ManagerでのCSIの表示

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

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

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

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

E.1.1 Oracle Harvesterの特徴

Oracle Harvesterの特徴は次のとおりです。

- すべてのターゲットのデータは、Oracle Management Service (OMS)ホームのOCMが構成されている資格証明と同じ資格証明に対してデフォルトでアップロードされます。Enterprise Manager Cloud Controlで、CSI割当てページからCSIを割り当てて、ターゲットのこのデフォルト値を変更できます。「設定」、「My Oracle Support」の順にクリックして開始します。

- Enterprise ManagerのOMSホームでOCMが構成済で実行中である必要があります。

- 管理リポジトリからターゲットの構成データを収集します。

- 定期的に自動実行されるため、ユーザーが操作する必要はありません。

E.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 Enterprise Manager Cloud Control 13c以降ではOCMは次のディレクトリにあります。

OMS_HOME/oracle_common

- Oracle Enterprise Manager Cloud Control 12c以前の場合:
$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

環境変数ORACLE_CONFIG_HOMEをこのemgc.propertiesファイルのディレクトリに設定します。(注意: この設定はCloud Control 13cでは必要ありません。)

次に例を示します。

$export ORACLE_CONFIG_HOME=/u01/app/oracle/product/gc_inst/em/EMGC_OMS1

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

E.1.3 Enterprise Managerのサポート

デフォルトでは、すべてのターゲットが、OMSホームのOracle Configuration Managerの登録に使用した資格証明を使用してアップロードされます。Enterprise Managerでは、各ターゲット・ホームにカスタマ・サポート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.

E.1.4 Enterprise ManagerでのCSIの表示

ターゲットに関連付けられているCSIを確認するには、ターゲットのプロパティを表示するか、または検索条件にCSIを設定して構成検索を行います。特定のOracleホームのすべてのターゲットに対してオペレータ権限を持つユーザーは、そのOracleホームに対するCSIを割り当てることができます。

詳細は、Enterprise Managerインタフェース上のヘルプを参照してください。

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

E.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とリポジトリのホームページおよびインシデント・マネージャのページの両方に表示されます。

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

Oracle Harvesterが実行されているEnterprise Managerのリリースに従って、様々なターゲット・タイプのセットから構成データが収集されます。表E-1に示されたターゲット・タイプの構成データのみがOracle Harvesterによって収集されます。

表E-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

いいえ

いいえ

はい

E.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にただちに表示されます。

E.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を使用してください。

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

My Oracle Supportの詳細情報は、次のURLを参照してください。

https://support.oracle.com

OCMについてより詳細な情報を得るには、次の手順を実行してください。

1. My Oracle Support (https://support.oracle.com)にログインします。

2. 「コレクタ」タブにアクセスするには、「詳細」をクリックしてドロップダウン・メニューから「コレクタ」を選択します。「コレクタ」ページには役立つ情報が含まれています。

E.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によって収集されません。

E.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)

E.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インスタンス・ホームで構成(および接続モードで実行)されている必要があります。

E.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を実行します。

E.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)

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

Oracle製品、サービスおよびサポート・ドキュメントを無効なコミュニティでアクセスおよび利用可能にする取組みの一環として、Enterprise Managerには、管理データをアシスティブ・テクノロジのユーザーで利用可能にする複数の機能が用意されています。Enterprise Managerでは、次のアクセシビリティ機能が用意されています。

- スクリーン・リーダーのサポート

- 高コントラストのサポート

- 大きいフォントのサポート

この付録では、スクリーン・リーダーのサポートを有効にするために変更する必要がある、次の構成設定について説明します。

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

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

- web.xmlファイルの構成

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

注意:
スクリーン・リーダーのサポートを有効にするとPPRが無効になるため、処理のステータスのリフレッシュに関連するすべてのページが自動的にリフレッシュされなくなります。これは予測されている動作です。

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

スクリーン・リーダー・モードを有効化するには、次の手順を実行します。

1. Cloud Controlホームページの「<user_name>」メニューから、「プリファレンス」→「アクセシビリティ」を選択します。

2. 「アクセシビリティ・プリファレンス」ページで、「スクリーン・リーダーを使用する」を選択します。「適用」をクリックします。
ADFアクセシビリティ・モードは、即座に実行されるセッション・ベースの設定で、Enterprise Manager管理サービスを再起動する必要はありません。

ADFの各ページでは、Cloud Controlに初めてログインした後に「アクセシビリティ・プリファレンス」ダイアログが表示されます。このダイアログの設定は、前述の「アクセシビリティ・プリファレンス」ページの設定と同じです。

F.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-ctrl-labelsはtrueに設定されています。これにより、カーソルをUI要素(表内のチェック・ボックスやラジオ・ボタンなど)にかざすと、ラベルの付いたツール・チップ・ボックスが表示されるようになります。この機能を無効にするには、設定をfalseに変更します。

F.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を再起動します。

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

Enterprise Managerでは、パフォーマンス・データの表示にグラフが使用されます。ほとんどのユーザーにとって、これらのグラフは、トレンドを理解し、パフォーマンス・メトリックの最小値および最大値の特定に役立つ、データのグラフィック表示となります。

しかし、グラフの情報はスクリーン・リーダーで読み取ることができません。この問題を解決するため、各パフォーマンス・グラフに完全な説明テキストが表示されるようにEnterprise Managerを構成できます。デフォルトでは、グラフのテキスト表示のサポートは無効になっています。グラフの説明テキストが有効になっている場合、Enterprise Managerでは各チャートに小さなアイコンが表示され、説明テキストへのドリルダウン・リンクとして使用できます。

ADFの各ページでスクリーン・リーダーのサポートが有効になっていることを確認するには、次の手順に従います。

1. Cloud Controlホームページで、「ヘルプ」をクリックし、「Enterprise Managerバージョン情報」を選択します。

2. 「Enterprise Managerバージョン情報」ダイアログ・ボックスで、「アクセシビリティ・プリファレンス - スクリーン・リーダーのサポート」が「有効」に設定されていることを確認します。

3. 「アクセシビリティ・プリファレンス - スクリーン・リーダーのサポート」が「無効」に設定されている場合は、「Enterprise Managerのアクセシビリティ機能の有効化」に記載されている手順に従います。

UIXの各ページでスクリーン・リーダーのサポートが有効になっていることを確認するには、次の手順に従います。

1. Cloud Controlホームページの「エンタープライズ」メニューから、「レポート」を選択し、「情報パブリッシャ・レポート」を選択します。

2. 「情報パブリッシャ・レポート」ページで、「ハードウェア・サマリー」を選択します。「ハードウェア・サマリー」ページが表示されます。アクセシビリティティ設定が有効になっている場合は、図F-1に示すアイコンが表示されます。

図F-1 グラフの説明テキストを示すアイコン

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

この項では、既存の管理エージェントから別のエージェントにコールド・フェイルオーバー・クラスタ(CFC)・ターゲットを再配置するCloud Control管理者向けに全般的な情報を提供します。ターゲットは複数のノードで実行可能ですが、CFC環境のアクティブなノードでのみ実行されます。

CFC環境は、通常、クラスタ・ソフトウェアを組み合せて使用することで、仮想ホスト名とIPアドレス、インターコネクト・ホストおよび記憶域システムを提供して情報を共有し、アプリケーションの高可用性(HA)を実現します。仮想ホスト名とIPのフェイルオーバーを自動化し、Enterprise Managerターゲットを再配置してパッシブ・ノードでアプリケーションを再起動する場合、Oracle Enterprise Managerのコマンドライン・インタフェース(EM CLI)と、オラクル社またはサードパーティのクラスタ・ソフトウェアを使用する必要があります。一部のOracleパートナ・ベンダーでは、この分野のクラスタウェア・ソリューションが提供されています。

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

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

- インストールと構成

- フェイルオーバー手順

- フェイルバック手順

- EM CLI relocate_targetsのパラメータ

- 再配置スクリプト

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

Oracle Enterprise Manager 12cでは、クラスタの各ノードで実行されている単一のOracle Management Agentによって、アクティブおよびパッシブの高可用性で構成されているターゲットを監視できます。CFCクラスタの各物理ノードでは、1つの管理エージェントのみが必要ですが、その理由は、パッシブ・ノードへのフェイルオーバーの際に、Enterprise Managerは、一連のEMCLIコマンドを使用して、障害ノード上の管理エージェントから新しくアクティブ化されたノード上の別の管理エージェントにHA監視対象ターゲットを移動できるためです。詳細は、『Oracle® Enterprise Managerコマンドライン・インタフェース』を参照してください。

アクティブ/パッシブ環境でアプリケーションが実行している場合、アクティブなノードに障害が発生すると、クラスタウェアはパッシブ・ノードでアプリケーションを起動します。Enterprise Managerがこのタイプの構成でターゲットを引き続き監視する場合、既存の管理エージェントには追加の構成が必要です。

次の項では、新しいアクティブなノードでターゲットを自動化および再起動する環境を準備する方法について説明します。フェイルオーバーおよびフェイルバックの手順も示します。

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

次の項では、Oracle Management Serviceプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするEnterprise Managerの構成方法について説明します。

- 前提条件

- 構成手順

G.2.1 前提条件

次の手順は、CFCでのフェイルオーバー用に監視対象ターゲットがすでにインストールおよび構成されていることが前提となります。

アクティブ/パッシブ環境を次のように準備します。

- オペレーティング・システム・クロックがクラスタのすべてのノード間で同期していることを確認します。(ネットワーク・タイム・プロトコル(NTP)または別のネットワーク同期化メソッドの使用を検討してください。)

- 物理ホスト名を使用して、クラスタの各ノードに管理エージェントをインストールします。クラスタの各ノードのローカル・ディスク・ボリュームに管理エージェントをインストールします。管理エージェントをインストールすると、Cloud Controlコンソールに表示されます。

- CFCクラスタの各ノードにEMCLIをインストールして構成します。詳細は、『Oracle® Enterprise Managerコマンドライン・インタフェース』を参照してください。

- ターゲットを再配置するときは、失敗したノードの管理エージェントと新しくアクティブ化したノードの管理エージェントでプラグインのバージョンとリビジョンが同じであることを確認します。

G.2.2 構成手順

次の項では、OMSプロセスと通信する既存の管理エージェントを使用してCFC構成をサポートするEnterprise Managerの構成方法について説明します。次に示す例は、2つのノードで構成されるクラスタに1つのフェイルオーバー・グループがある構成に基づいています。

構成には次の2つの手順が含まれます。

- ターゲットの検出

- プラグインのデプロイ

G.2.2.1 ターゲットの検出

アクティブ/パッシブ・ターゲットを構成した後、Cloud Controlコンソールの「ターゲットの手動追加」画面を使用して、ターゲット(データベース、リスナー、アプリケーション・サーバーなど)を追加します。この画面には、「設定」→「ターゲットの追加」→「ターゲットの手動追加」の順に移動してアクセスします。この手順は、アクティブ・ノード(追加するターゲットを現在ホストしているノード)を指定して実行する必要があります。

G.2.2.2 プラグインのデプロイ

ターゲットを追加した後、アクティブ・ホストのエージェントにデプロイされているプラグインを特定します。これは、エージェントのホームページに移動して「構成」リージョンの「プラグイン」タブを表示することでわかります。

図G-1 エージェントのホームページ

「検出コンテンツのみ」ボックスが選択されていないプラグインを書き留めます。これらのプラグインは、パッシブ・ノードのエージェントにデプロイする必要はありません。

パッシブ・ノードのエージェントのホームページを確認して存在しないプラグインを特定した後、存在しないプラグインをデプロイするために「設定」→「拡張性」→「プラグイン」に移動して、関連するプラグインを選択し、管理エージェントにデプロイ・メニューを使用してプラグインをデプロイします。

G.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コンソールで、再配置されたすべてのターゲットが起動して実行されていることを確認します。

G.4 フェイルバック手順

HAターゲットを元のアクティブ・ノードまたはその他のクラスタ・メンバー・ノードに戻すには、次の手順を実行します。

1. HAターゲットをアクティブ・ノードに戻すには、「フェイルオーバー手順」の手順を繰り返します。

2. Enterprise Managerコンソールでターゲット・ステータスを確認します。

G.5 EM CLI relocate_targetsのパラメータ

G.3項「フェイルオーバー手順」の説明に従って、再配置操作中にフェイルオーバー(またはスイッチオーバー)するターゲット・タイプごとにEM CLI relocate_targets動詞を実行します。表G-1「relocate_targets動詞のパラメータ」に、このEM CLI動詞に関連付けられている動詞のパラメータを示します。

表G-1 relocate_targets動詞のパラメータ

EM CLIパラメータ

説明

-src_agent

フェイルオーバーの発生前にターゲットが実行していた管理エージェント。

-dest_agent

フェイルオーバー後にターゲットを監視する管理エージェント。

-target_name

フェイルオーバーするターゲットの名前。

-target_type

フェイルオーバーするターゲットのタイプ(Enterprise Managerの内部ターゲット・タイプ)。たとえば、(スタンドアロン・データベースまたはOracle RACインスタンスの)Oracleデータベース、データベース・リスナーのOracleリスナーなど。

-copy_from_src

ソース管理エージェントと同じタイプのプロパティを使用してターゲットを特定します。これは必須パラメータです。このパラメータを指定しないと、ターゲット定義が破損する可能性があります。

-force

同様にフェイルオーバーする依存性を強制します(必要な場合)。

G.6 再配置スクリプト

次の例では、フェイルオーバー操作の発生時にクラスタウェア構成から実行できる再配置スクリプトを示します。

スクリプトを実行する前に:

- デフォルトの通常ホスト資格証明と通常ホスト資格証明を設定します。

- データベース・インスタンスのターゲット優先資格証明と、通常データベース資格証明、SYSDBAのデータベース資格証明およびデータベース・ホスト資格証明を設定します。

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

索引
A B C D E F G H I J K L M N O P Q R S T U V W

A

アクセシビリティ, F

アクセシビリティ・モード, F.1

web.xmlファイルの構成, F.3

アクセシビリティ・モードの有効化, F.1

スクリーン・リーダーのサポート, F.4

uix-config.xml, F.2

web.xmlファイル, F.3

ホストの追加ログ・ファイル, A.2 「ホスト・ステータスの追加」ページ, 7.4.1.1 ホスト・ターゲットの追加ウィザード

概要, 2.1.9

ホスト・ターゲットの追加ウィザード, 1.3

ベスト・プラクティス, 2.1.9

管理サービスの追加デプロイメント・プロシージャ, 2.1.11 追加のOMS

インストール, 5

追加のスタンバイOMS, 削除, 26.1 ADPマネージャ, 13.3 エージェント・ベース・ディレクトリ, 2.3.4

要件, 6.3, 7.3

エージェントのインストール・ログ, A.2.4 エージェント・インスタンス・ディレクトリ, 2.3.6 エージェント・インスタンス・ホーム

権限, 6.3

要件, 6.3

エージェントのプラグイン・ホーム, 2.3.7 agent_inst, 2.3.6 AgentDeinstall.plスクリプト, 24.1.1.1 agentDeploy.batスクリプト, B.2 agentDeploy.shスクリプト, B.2

制限事項, 6.2

場所, 6.2

目的, 6.1

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

agentDeploy.shスクリプトのサポートされているオプション, 6.4.10 AgentNFS.plスクリプト

別の方法, 8.4.3

目的, 8.1

レスポンス・ファイル, 8.4.3

AgentPull.shスクリプト, 6.1

レスポンス・ファイル, 6.4.6

AgentPull.shスクリプトのサポートされているオプション, 6.4.9 アラート, 13.2.4.5, 13.2.4.7 allroot.shスクリプト, 2.8.2, 4.4.1.2, 4.4.2.2 アプリケーション・パフォーマンス管理, 12.11 アプリケーション前提条件ログ, A.2.2 アプリケーション・サービス・レベル管理, 12.11, 12.11 補助テクノロジ, F 非同期I/O, 13.2.4.6

B

バックグラウンド・サービス, 17, 17.1

ベースライン, 13.2.2

ビーコン

構成, 13.2.4.7

ビーコン, 13.2.4.7 BI Publisher, 16

管理, 16.9

アクセスの許可, 16.5

リポジトリ・アクセス, 16.12

トラブルシューティング, 16.13

BI Publisherのインストール, 16.2 BI Publisherセキュリティ・モデル, 16.5.5 BI Publisherサーバー, 追加, 22.3 BI Publisherサーバー, セカンダリの構成, 22.3.1 BI Publisherサーバー, 詳細, 22.5 BI Publisher, デバッグ, 16.13.5 BI Publisher, SSL, 16.8 ボトルネック

排除, 13.2.3, 13.2.4

チューニング, 13.2.4

バッファ・キャッシュ, 13.2.4.3 バッファ・キャッシュのサイジング, 13.2.4.3

C

容量

予測, 13.2

中央インベントリ, 2.3.1, 6.3 cksumコマンド, 1.2.2.2, 1.2.2.2, 1.2.2.2 Cloud Control

デプロイメント, 13.2.1

評価, 13.2.1, 13.2.2

サイジング, 13.2

サイジングの手法, 13.2

プラットフォームの起動, 13.2.1

バイタル・サイン, 13.2.2, 13.2.4.5

コールド・フェイルオーバー・クラスタ構成, G.1 コールド・フェイルオーバー・クラスタ, HA, G コマンド

データ・ファイルの削除, 2.1.14

ファイル・サイズの確認, 1.2.2.2

コンフィギュレーション・アシスタント

追加のOMSのアップグレードの場合, 2.4.2.3

新規のインストールの場合, 2.4.2.1

アップグレードの場合, 2.4.2.2

概要, 2.4.1

失敗の解決, 2.4.3

デフォルトで実行, 2.4.2

実行

新しいEnterprise Managerのインストール, 4.1

構成情報, 2.1.4 構成ログ, A.1.2

一般的な, A.1.2.1

リポジトリ, A.1.2.2

SYSMANスキーマ操作ログ, A.1.2.2.1

ConfigureGC.shスクリプト, 4.4.1.3 コンソール・ポート, 2.1.12.1 コンソール・サービス, 17, 17.1 コンソール限定モード, 17, 17.2 CPU

使用率, 13.2.4.1

使用率分析, 13.2.4.1

CPUしきい値, 13.2.4.1

D

データ・ファイル, 2.1.13, 3.4.4

削除, 2.1.14

Oracle Management Repository用, 2.1.13

概要, 2.1.13

データベース

パラメータの変更, 13.1.3.4

データベース・ロック, 13.2.4.1 データベース・テンプレート

エラーの処理, 3.4.1, 4.4.2.3

インストーラでの詳細の指定, 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.13

削除

GUIモードでの削除

管理エージェントの削除, 24

RPMファイルを使用してインストールした管理エージェントの削除, 24.1.1.3

OMSの削除, 23

サイレント・モードでの削除

AgentDeinstall.plスクリプトを使用した管理エージェントの削除, 24.1.1.1

RPMファイルを使用した管理エージェントの削除, 24.1.1.3

共有エージェントの削除, 24.1.1.2

共有エージェントの削除, 24.1.1.2

OMSエントリのリポジトリからの削除, 23.4 Oracle Management Agentからのプラグインのアンデプロイ, 24.2 OMSからのプラグインのアンデプロイ, 23.3 JVMDの削除

エージェント, 25.1

DemoTrust.jksキーストア, 15.4.4 deploy_jvmdagent.plスクリプト, 15.4.1, 15.4.2 デプロイメント・プロシージャ, 2.1.11, 2.1.11, 5.1 デプロイメント・サイズ

デプロイメント・サイズの変更, 2.1.6

エラーの処理, 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 無効化されたコミュニティ, F 障害時リカバリ, 20.1 dontProxyForプロパティ, 12.10 -downloadUpdatesコマンド, 2.1.5.5

E

E2E監視, 13.2.4.7

EMBIP*ロール

フォルダ/カタログ・オブジェクトへのアクセス権, 16.11

EMBIPAdministrator, 16.5.5 EMBIPAuthor, 16.5.5 EMBIPScheduler, 16.5.5 EMBIPViewer, 16.5.5 EMCLI, 6.4.3.1, 6.4.3.2, 6.4.4.1 エンドツーエンド監視, 13.2.4.7 Enterprise Manager Cloud Control

基本概念, 2

コンフィギュレーション・アシスタント, 2.4

削除

概要, 23

データ・ファイルの削除, 2.1.14 グローバリゼーション・サポート, 2.1.15 インストール

概要, 2.1.3.1

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

インストール・モード, 2.1.1 インストール・タイプ, 2.1.3 インストール・ウィザード, 2.1.2 ポート

コンソール・ポート, 2.1.12.1

ポートのカスタマイズ, 2.1.12.3, 2.1.12.4

デフォルト・ポート, 2.1.12.1

HTTPポート, 2.1.12.1

HTTPSポート, 2.1.12.1

概要, 2.1.12

アップロード・ポート, 2.1.12.1

前提条件チェック, 2.5 OTNからの入手

内容の抽出, 1.2.2.3

ファイル・サイズの確認, 1.2.2.2

リリース, 1.1 サイレント・インストール

拡張インストーラ・オプション, 3.4.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コンポーネント, リカバリ, 21.6 Enterprise Manager Framework Security, 12.4

ファイアウォール環境, 12.1

Enterprise Manager前提条件キット, A.1.2.2.2 /etc/hostsファイル, 6.3

F

フェイルオーバー, 20.5.2

フェイルオーバー, アクティブおよびパッシブ環境, G

フェイルオーバー, Enterprise Manager, G.3

フェイルオーバー, relocate_targets動詞, G.3

ファイアウォール構成, 12

ICMPおよびUDPトラフィックを許可, 12.11

ブラウザとCloud Controlコンソールの間, 12.3

Cloud Controlと管理対象データベース・ターゲットの間, 12.7

OMSとリポジトリの間, 12.6

ICMPエコー・リクエストの有効化, 12.12

ポートの要件, 12.2

ファイアウォール, 12

ブラウザとCloud Controlの間, 12.3

Cloud Controlと管理対象データベース・ターゲットの間, 12.7

管理サービスと管理リポジトリの間, 12.6

構成の考慮事項, 12.1

Enterprise Managerコンポーネントの構成, 12.2

ICMP通信のための構成, 12.11

UDP通信のための構成, 12.11

ファイアウォールで保護されたホスト上のOMSの構成, 12.4

ICMPエコー・リクエストの有効化, 12.12

複数の管理サービスの場合, 12.8

複数のOMSインスタンスの場合, 12.8

最初のスタンバイOMS, 削除, 26.2 Fusion Middleware, 13.3

検出, 13.3

監視, 13.3

G

グローバリゼーション・サポート, 2.1.15

グラフィック・モード, 2.1.1, 2.1.1

H

ハードウェア要件, 13.1.1.4

ヒープ・サイズ, 13.1.3.1, 13.1.3.1

変更, 13.1.3.3

高可用性, 18.1 高可用性, エージェント, 19.1 高可用性, BI Publisher, 22 高可用性, レベル, 18.2.1 高可用性, OMS, 19.3 高可用性, リポジトリ, 19.2 高可用性システム, 18 ホスト・リスト・ファイル, 2.8.1 HTTPポート, 2.1.12.1 HTTPSポート, 2.1.12.1 ハイパースレッディング, 13.2.4.1

I

ICMP, 12.11

初期化ログ, A.2.1

インストール・ログ

installActions, A.1.1

インストール

サイレント・モードのインストール

追加のOMSのインストール, 5

レスポンス・ファイルの編集, 3.4.4

複数OMSのインストール, 3, 3.4.1

単一OMSのインストール, 3, 3.1, 3.4.1

管理エージェント, 11 ソフトウェアのみのインストール, 4.1 インストール・ベース・ディレクトリ

権限, 7.3

インストール・モード, 2.1.1 インストール・タイプ, 2.1.3 インストール・ウィザード, 2.1.2 インストーラ, 2.1.2 JVMDのインストール, 15 インスタンス・ディレクトリ

権限, 7.3

要件, 8.3

Internet Control Message Protocol, 12.11 -invPtrLocパラメータ, 2.3.1 I/Oチャネル

監視, 13.2.4.6

I/Oスループット

監視, 13.2.4.6

J

jamagent.war, 15.4.1

Java Development Kit

サポートされるバージョン, 2.2

ジョブ, 13.2.4.5

バックログ, 13.1.3.2

JVMエージェント

インストール後のタスク, 15.5

JVM診断

アーキテクチャ, 15.1

インストールの前提条件, 15.3

JVMDエージェントを手動でインストール, 15.4.1

スクリプトを使用してJVMDエージェントを手動でインストール, 15.4.2

JVMDエージェントの概要, 15.1

インストール後のタスク, 15.5

JVMDエージェントの削除, 25.1

インストール前の留意点, 15.2

JVMD, 13.3 JVMDエージェント

セキュアなポートへの接続, 15.4.4

インストールの前提条件, 15.3

高可用性のためのインストール, 15.4.3

手動によるインストール, 15.4.1

スクリプトを使用して手動でインストール, 15.4.2

スタンドアロンJVMへのインストール, 15.4.1

GlassFishへのインストール, 15.4.1, 15.4.2

JBossへのインストール, 15.4.1

OC4Jへのインストール, 15.4.1

Tomcatへのインストール, 15.4.1

WebLogic Serverへのインストール, 15.4.1, 15.4.2

Websphereへのインストール, 15.4.1

概要, 15.1

削除, 25.1

インストール前の留意点, 15.2

JVMDアーキテクチャ, 15.1, 15.1 jvmdagent_deploy.propertiesファイル, 15.4.1

K

キーストア, 15.4.4

L

ライセンス, 2.6.1

ロード・バランサ, 20.2.1.2

ローダー, 13.2.4.2

ローダー・スレッド, 13.2.4.2

デフォルト値, 13.2.4.2

ロックされたユーザー・アカウント, 7.2 ログ

ホストの追加ログ, A.2.5

追加のOMSインストール・ログ, A.5

エージェント・ゴールド・イメージのログ・ファイル, A.4

エージェントのインストール・ログ, A.2.4

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

cfgfw/*.log, A.2.4

構成ログ, A.1.2, A.1.2.1

deployfwk.log, A.2.5

EMPrereqKitログ, A.1.2.2.2

一般的な構成ログ, A.1.2.1

初期化ログ, A.2.1, A.2.1

インストール・ログ, A.1.1, A.1.1

install.log/.err, A.2.4

手動のエージェント・インストール・ログ, A.3

MDSスキーマ操作ログ, A.1.2.2.3

nfs_install.log/.err, A.2.4

Oracle Management Serviceのログ・ファイル, A.1.2.4

Oracle Management Serviceのログ, A.1.2.4

リポジトリ構成ログ, A.1.2.2

セキュア・ログ, A.1.2.3, A.1.2.3

SYSMANスキーマ操作ログ, A.1.2.2.1

システム前提条件ログ, A.2.3, A.2.3

ui.log, A.2.5

longPoolSize

変更, 13.1.3.3

longSystemPoolSize

変更, 13.1.3.3

M

管理エージェント

GUIモードでの削除

概要, 24

削除後のタスク, 24.1.2

インストール

検証, 6.5, 8.5

レスポンス・ファイルを使用したインストール

レスポンス・ファイルの作成, 6.4.6, 6.4.7, 6.4.8

前提条件, 6.3

管理エージェント, 13.1.1.5, 13.2.2

ファイアウォールで保護されたホスト上の構成, 12.5

プロキシ・サーバーを使用するための構成, 12.5.1

管理エージェントのバックアップ, 21.5 管理エージェントのパッチ適用

パッチの保存, C.1

パッチ適用の確認, C.2

管理リポジトリ, 13.2.4.1, 13.2.4.1, 13.2.5 管理リポジトリのバックアップ, 21.3 管理サービス, 13.1.1.5 管理サービス, 追加, 19.3.3 マスター・エージェント, 8.1, 8.2 maxConnForJobWorkers

変更, 13.1.3.3

MDSスキーマ, 2.1.14 MDSスキーマ作成ログ, A.1.2.2.3 MDSスキーマ削除ログ, A.1.2.2.3 mgmt_deepdive.dbfデータ・ファイル, 2.1.13 mgmt_ecm_depot1.dbfデータ・ファイル, 2.1.13 mgmt.dbfデータ・ファイル, 2.1.13 ミドルウェア・ホーム, 2.3.2

N

名前付き資格証明, 7.2

ネットワーク

待機時間, 13.1.1.5

トポロジに関する考慮事項, 13.1.1.5

new_install.rspレスポンス・ファイル, 3.4.4 ノード・マネージャ, 2.2.2 ノード・マネージャの資格証明, 2.2.2 通知, 13.2.4.5

O

OMSのバックアップ, 21.4

OMSインスタンス・ベースの場所, 2.3.3

OMSのプラグイン・ホーム, 2.3.7

OMSプロパティ

変更, 13.1.3.3, 13.1.3.3

OMSサーバー, 13.2.4.8

中間層, 13.2.4.8

最適な数, 13.2.4.8

OMS, ロード・バランサの内側, 19.3.4 OpenSSH, 7.2, 8.2 オペレーティング・システム・グループ, 6.3, 7.3, 8.3 オペレーティング・システム要件, 8.3 オペレーティング・システム・ユーザー, 6.3, 7.3, 8.3 サポートされるオペレーティング・システム, 6.3 Oracle Advanced Security, 12.6 Oracle Business Intelligence, 16 Oracle Configuration Manager

概要, 2.1.4

Oracle Enterprise Manager

ロールアップ・プロセス, 13.2.4.3

Oracle Enterprise Manager

チューニング, 13.2.4

Oracleホーム, 2.3.5 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

削除

概要, 24

インストール

クローニング, 2.1.9

新規のインストール, 2.1.9

NFSインストール, 2.1.9

パッケージ, 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.12.1 ソフトウェア, 1.3 ソフトウェアのみのインストール

構成, 10.5

ファクト, 10.2

インストール, 10.4

概要, 10.1

インストール後の手順, 10.6

前提条件, 10.3

Oracle Management Service, A.1.2.1

プロキシ・サーバーを使用するための構成, 12.4.1

ファイアウォールで保護された場合の構成, 12.4

コンソール限定モード, 17, 17.2

My Oracle Supportへのアクセスの有効化, 12.9

Oracleミドルウェア・ホーム, 2.3.2 Oracle Netのファイアウォール・プロキシ・アクセス, 12.6 Oracle WebLogic Server, 2.2

管理サーバー

管理サーバー・ポート, 2.2.3

管理サーバーの起動, 2.2.5

管理サーバーの確認, 2.2.4

資格証明, 2.2.1, 2.2.1 ノード・マネージャ, 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 その他のインストール・ログ, A.2.5

P

パッケージ, 6.3, 8.3

ページ・パフォーマンス, 13.2.4.7

管理エージェントへのパッチの適用

パッチの保存, C.1

パッチ適用の確認, C.2

権限, 6.3, 6.3 ホスト名の計画, 20.2.1.1 プラグイン, 2.1.10

プラグインのダウンロード, 3.4.4, 4.4.1.3.1, 4.4.2.3.1

ソースOMSのプラグインの特定, 5.2

ソースOMSへの追加プラグインのインストール, 5.2

プラグインの選択, 4.4.1.3, 5.2

インストールの確認, 6.5

plugins.txtファイル, B.1 ポート, 2.1.12, 4.4.1.3

管理サーバー・ポート, 2.2.3

管理サーバー・ポート, 2.1.12.1, 2.2.3

コンソール・ポート, 2.1.12.1

カスタムのEMポート, 2.1.12.3

ポートのカスタマイズ, 2.1.12.3

インストール後のポートのカスタマイズ, 2.1.12.3

デフォルト・ポート, 2.1.12.1

HTTPポート, 2.1.12.1

HTTPSポート, 2.1.12.1

管理対象サーバー・ポート, 2.1.12.1

ノード・マネージャのポート, 2.1.12.1

Oracle BI Publisher, 2.1.12.1

アップロード・ポート, 2.1.12.1

空きポートの確認, 2.1.12.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 プロパティ

設定, 13.1.3.3

プロキシ・サーバー

管理エージェントの構成, 12.5.1

管理サービスの構成, 12.4.1

例外の定義, 12.10

Q

停止モード, D.2

R

リカバリ, Enterprise Manager, 21.6

管理エージェントのリダイレクト

前提条件, B.1

手順, B.2

リリース, 1.1 RepManager, 2.1.14, D

概要, D.1

サポートされる操作およびコマンド, D.2

RepManagerユーティリティ, D RepManagerユーティリティ

サポートされる操作, D.2

drop, D.2

pluginpurge, D.2

preupgrade, D.2

resume, D.2

transX, D.2

upgrade, D.2

リポジトリ

可用性, 13.1.3.1

リポジトリの高可用性, ベスト・プラクティス, 19.2.1 レスポンス・ファイル, 3.1 管理エージェント・バイナリの再利用

前提条件, B.1

手順, B.2

ロールアップ・プロセス, 13.2.4.3, 13.2.4.4 ロールアップ統計, 13.2.4.3 root.shスクリプト, 2.8.2

S

保護, 13.2.6

パフォーマンスの向上, 13.2.6

schemanager, A.1.2.2.1 スクリーン・リーダー, F スクリプト, 2.8.2 Secure Socket Layer, BI Publisher, 16.8 セグメント・アドバイザ, 13.2.3.1 セグメント

正常な状態の維持, 13.2.3.1

自己更新コンソール, 1.3 共有エージェント

ターゲットの自動検出, 8.2

インスタンス・ディレクトリの構成, 8.2

概要, 8.1

共有Oracleホーム, 8.3 共有記憶域, BI Publisher, 22.2 shortPoolSize

変更, 13.1.3.3

サイレント・モード, 2.1.1 サイジング, 13.1

メリット, 13

将来的な外挿, 13.2.5

ガイドライン, 13, 13.1.1

ハードウェア情報, 13.1.1.1

リポジトリ表領域, 13.1.2.4, 13.1.2.5

要件, 13.2.5, 13.3

ソフトウェア構成, 13.1.2

仕様, 13.1.1.2

アップグレード・インストール, 13.1.1.3

ソフトウェア

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

ソフトウェア構成

評価, 13.1.2.1

大規模, 13.1.2.4

中規模, 13.1.2.3

小規模, 13.1.2.2

ソフトウェア・ライブラリのバックアップ, 21.2 ソフトウェア更新

インストールまたはアップグレード後の適用, 2.1.5.6

自動ダウンロード, 2.1.5.5

ユーザーによるダウンロード, 2.1.5.5

ダウンロード, 2.1.5.5

適用されたパッチの識別, 2.1.5.7

オフライン・モード, 2.1.5.5

オンライン・モード, 2.1.5.5

概要, 2.1.5, 2.1.5.1, 2.1.5.2

タイプ, 2.1.5.3

software_only.rspスクリプト, 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 スタンバイ・サイト, 同期, 20.6 起動スクリプト

概要, 2.7

staticports.iniファイル, 2.1.12.3, 2.1.12.3, 2.1.12.3, 2.1.12.4, 2.1.12.4 SUDO, 7.3, 7.3, 8.3, 8.3 スイッチオーバー, 20.5.1 SYSMANスキーマ, 2.1.14 SYSMAN_APM, 4.4.1.3 SYSMAN_MDS, 4.4.1.3 SYSMAN_OPSS, 4.4.1.3 システム前提条件ログ, A.2.3 systemPoolSize

変更, 13.1.3.3

T

ターゲットの再配置, アクティブおよびパッシブ, G.1

一時ディレクトリ

権限, 6.3

スペース, 6.3, 7.3, 8.3

しきい値, 13.2.2, 13.2.2 翻訳言語, 2.1.15

U

UDP, 12.11

uix-config.xml, F.2

uix-config.xmlフラグ, F.2

ライセンスのないコンポーネント, 2.6.1

アップロード・ポート, 2.1.12.1

ユーザー・データグラム・プロトコル, 12.11

ユーザー・インタフェース

パフォーマンス, 13.2.4.7

ユーザー

同時, 13.1.3.1

V

バイタル・サイン, 13.2.4.8

I/O, 13.2.4.6

W

web.xml, F.3

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

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

Oracle Supportへのアクセス

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